软件需求开发的最终文档经过评审比准后，则定义了开发工作的需求基线（baseline）。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定（agreement），需求约定是需求开发和需求管理之间的桥梁。
需求管理是一个对系统需求变更、了解和控制的过程。
1.需求管理的主要活动
当初始需求到处的同时就启动了需求管理规划，一旦形成了需求文档的初稿，需求管理活动就开始了。
需求管理的主要活动：
| 变更控制 | 版本控制 | 需求跟踪 | 需求状态跟踪 |
|---|---|---|---|
| （1）建议变更 | （1）确定需求文档版本 | （1）定义对其他需求的连接链 | （1）定义需求状态 |
| （2）分析影响 | （2）确定单个需求文档版本 | （2）定义对其他系统元素的连接链 | （2）跟踪需求每一个状态 |
| （3）做出决策 | |||
| （4）交流 | |||
| （5）合并 | |||
| （6）测量需求的稳定性 |
需求管理强调：
（1）控制对需求基线的改动。
（2）保持项目计划与需求一致。
（3）控制单个需求和需求文档的版本情况。
（4）管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系。
（5）跟踪基线中的需求状态。
2. 需求管理原则
过程能力成熟度模型（Capability Maturity Model，CMM）在软件开发机构中被广泛用来指导软件过程改进。该模型描述了软件处理能的5个成熟级别。为了达到过程能力成熟度模型的第二级，组织机构必须具有6个关键领域（Key Process Areas）。
需求管理是其中之一，其目标如下：
（1）为软件需求建立一个基线，提供给软件功能和管理使用。
（2）软件计划，管理和活动与软件需求保持一致。
关于软件需求过程与内的原则和策略：
（1）软件开发计划是基于已确定的需求。需求管理的关键过程领域不涉及收集和分析项目需求。
（2）不能承诺无法实现的事。承诺需求之前应该确认需求和约束条件、风险，偶然因素，假定条件等。
（3）通过版本控制和变更控制来管理需求文档。版本控制确保随时能知道在项目开发和计划中正在使用的需求的版本情况。变更控制提供了支配下的统一的规范的方式来统一需求变更。
3. 需求属性
除了文本，每一个功能需求应该有一些相关的信息和他联系，我们把这些信息称为需求属性：
（1） 创建需求的时间。
（2） 需求的版本号。
（3） 创建需求的作者。
（4） 负责认可该软件需求的人员。
（5） 需求状态。
（6） 需求的原因和根据。
（7） 需求涉及的子系统。
（8） 需求涉及的产品版本号。
（9） 使用经验方法或者接受的测试标准。
（10） 产品的优先级或者重要程度。
（11） 需求的稳定性。
4.需求变更
软件需求文档应该精确描述要交付的产品，这是一个基本的原则。为了使开发组织能够严格控制软件项目，应该确保：
（1）仔细评估已建立的变更。
（2）挑选合适的人选对变更做出决定。
（3）变更应及时通知所有涉及的人员。
（4）项目要按一定的程序来采纳需求变更。
4.1 变更控制过程
一个好的变更控制过程，会减少项目风险，会使项目负责人在信息充分的条件下做出决策，我们也可以通过变更控制过程来跟踪已建议变更的状态。一旦确定了需求基线，应该使所有已建立的变更都遵循变更控制过程。
需求变更控制过程，可分为3部分：
（1） 问题分析和变更描述。
生成一个明确的需求便跟提议。
（2） 变更分析和成本计算。
做影响分析和评估。成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。
（3） 变更实现。
需求文档和系统设计以及实现同时修改。
4.2 变更控制委员会
变更控制委员会负责决定哪些已建议需求变更或者新产品特性付诸于应用，决定在那些版本中纠正哪些错误。
变更控制委员会的成员应能代表变更涉及的团体。例如如下方面的代表：
（1）产品或者计划管理部门
（2）项目管理部门
（3）开发部门
（4）测试或质量保证部门
（5）市场部或客户代表
（6）制作用户文档的部门
（7）技术支持部门
（8）帮助桌面或者用户支持热线部门
（9）配置管理部门
变更控制委员会应该又一个总则，用于描述变更控制委员会的目的、授权范围、成员构成、做出决策的过程及操作步骤。
5. 需求跟踪
需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括别的需求体系结构、其他设计部件、源代码模块、测试、帮助文件和文档。