4. 需求确认签字

1）在主要的业务清楚以后即可以进行需求确认

2）目的是确定需求基线

3）不要期望所有的需求在签字后不变

八、需求管理

1. 需求基线

1）软件需求规格说明及相关分析模型。经评审批准，这些文档定义了开发工作的需求基线；

2）建立需求基准版本和需求控制版本文档确定一个需求基准，这是一致性需求在特定时刻的快照；

3）之后的需求变更遵循变更控制过程；

4）每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

2. 需求变更控制

1）确定需求变更控制过程，确定一个选择、分析和决策需求变更的过程。

2）需求变更控制流程

3. 建立变更控制委员会

1）组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本；

2）变更控制委员会成员可以是甲方与乙方的人员共同组成；

3）定期进行需求变更评审会议；

4）每次评审要有评审报告。

4. 需求变更影响评估

1）进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。

2）明确与变更相关的任务并评估完成这些任务需要的工作量。

5. 需求变更时，修改需求跟踪能力矩阵

1）跟踪所有受需求变更影响的工作产品当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。

6. 维护需求变更的历史记录

1）记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。

2）在需求基线的基础上记录变更历史记录；

3）针对每一个需求形成一个单独记录；

通过对于软件需求分析的学习，知道需求分析要承担着很多风险，因此做好计划以及风险控制是非常重要的。