需求基线是需求管理活动中最为基础的一个，通常也是在项目中首先应该引入的管理活动。但许多相关书籍中对需求基线的介绍相对比较理论化，很少给出具体的操作方法，往往使得许多软件开发团队无从入手。为了帮助大家更好地引入需求基线，本章的重点将是结合具体的实例来说明需求基线的划分方法。
需求变更频繁恐怕是困扰无数软件开发团队的恶魔之首，而且在美国权威的第三方机构standish group的chaos报告中，也将其列为困扰软件开发团队、导致项目失败的5大原因之一，其中原因实际上也充分暴露了整个产业的不成熟。需求变更在chaos报告中是排名第四的问题，而在中国软件开发团队中却是排名第一的问题，这里面就意味着存在距离，本章的目的就是希望帮助大家找到其中的差距。
需求跟踪是一个高阶的管理活动，它的目标是为了更好地管理需求的状态、更好地分析需求变更产生的影响。虽然执行需求跟踪会带来不错的效益，但其所需付出的工作量也是巨大的。本章我们就对跟踪的一些要点做一简要的说明。
经常说一个观点：“我们并不缺乏软件工程、需求工程的理论、技术，缺乏的是将这些理论与技术有效地应用到实践中去的具体方法”。而贯穿全书的seru过程框架（也称为seru模型）正是笔者基于多年不同领域、不同规模的软件项目实践的基础上，通过对许多重型方法的剪裁而得到的一个清晰、实用的软件需求过程框架。
在你被逼在需求描述中增加how的信息之前，先确认自己已经尝试过为需求添加了why。
对于非功能需求而言，应该抛弃定性，改用场景化描述；并通过选取指标、积累经验值的方法过渡到定量描述。
需求跟踪是高阶管理活动，所需的工作量很大，特别是软件需求到设计元素的跟踪，因此一定要考虑投入与产出是否成正比。