04-00-需求管理

需求管理 21.1 介绍 21.2 需求确认 31.2.1 目的 31.2.2 角色与职责 31.2.3 启动准则 31.2.4 输入 31.2.5 主要步骤 4[Step1] 非正式需求评审 4[Step2] 正式需求评审 4[Step3] 获取需求承诺 41.2.6 输出 41.2.7 结束准则 41.2.1 度量 41.3 需求跟踪 51.3.1 目的 53.3.2 角色与职责 53.3.3 启动准则 53.3.4 输入 53.3.5 主要步骤 5[Step1] 建立与维护需求跟踪矩阵 5[Step2] 查找不一致 6[Step3] 消除不一致 61.3.6 输出 61.3.7 结束准则 61.3.1 度量 61.4 需求变更控制 71.4.1 目的 71.4.2 角色与职责 71.4.3 启动准则 71.4.4 输入 71.4.5 主要步骤 7[Step1] 需求变更申请 7[Step2] 审批需求变更申请 7[Step3] 更改需求文档 7[Step4] 重新进行需求确认 11.4.6 输出 11.4.7 结束准则 11.4.1 度量 11.5 实施建议 1需求管理需求管理（Requirement Management, RM）的目的在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。

需求管理过程域是SPP模型的重要组成部分本规范阐述了需求管理过程域的三个主要规程：² 需求确认 [SPP-PROC-RM-VALIDATE]² 需求跟踪 [SPP-PROC-RM-TRACKING]² 需求变更控制 [SPP-PROC-RM-CHANGE]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义1.1 介绍我们把所有与需求相关的活动通称为需求工程需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理图1-1为需求工程的结构图（流程见图9-1）需求确认需求管理需求分析需求定义需求调查需求开发需求工程需求变更控制需求跟踪图1-1 需求工程结构图需求管理过程域主要有3个规程：需求确认、需求跟踪与需求变更控制一、需求确认需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果二、需求跟踪需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发三、需求变更控制需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。

需求管理过程域产生的主要文档有：² 《需求评审报告》，同技术评审报告的模板 [SPP-TEMP-TR-REPORT]² 《需求跟踪报告》，模板见 [SPP-TEMP-RM-TRACKING]² 《需求变更控制报告》，模板见 [SPP-TEMP-RM-CHANGE]1.2 需求确认1.2.1 目的l 开发方和客户对需求文档如《用户需求说明书》和《产品需求规格说明书》进行评审，并作书面承诺补充说明：《用户需求说明书》和《产品需求规格说明书》可以分开也可以放在一起进行需求确认，视项目的具体情况而定1.2.2 角色与职责l 开发方和客户共同组织人员对需求文档如《用户需求说明书》和《产品需求规格说明书》进行评审l 开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果1.2.3 启动准则l 需求文档如《用户需求说明书》和《产品需求规格说明书》已经完成1.2.4 输入l 需求文档如《用户需求说明书》和《产品需求规格说明书》1.2.5 主要步骤[Step1] 非正式需求评审l 项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧非正式的需求评审方式请参考技术评审过程域的对应规程[SPP-PROC-TR-ITR]。

[Step2] 正式需求评审l 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿正式需求评审方式请参考技术评审过程域的对应规程[SPP-PROC-TR-FTR][Step3] 获取需求承诺 当需求文档通过正式的评审之后，开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果示例如下： 本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求文档开展如果需求发生变化，我们将按照“需求变更控制规程”执行我明白需求的变更将导致双方重新协商成本、资源和进度等 甲方负责人签字乙方负责人签字1.2.6 输出l 《需求评审报告》l 书面的需求承诺1.2.7 结束准则l 需求文档通过了正式评审，并且获得开发方和客户的书面承诺1.2.1 度量l 项目经理统计工作量和上述文档的规模1.3 需求跟踪1.3.1 目的l 将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发3.3.2 角色与职责l 项目经理跟踪需求。

3.3.3 启动准则l 需求文档已经通过正式评审并获得了承诺l 系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例已经产生3.3.4 输入l 需求文档l 设计文档、代码、测试用例等3.3.5 主要步骤[Step1] 建立与维护需求跟踪矩阵l 正向跟踪检查需求文档中的每个需求是否都能在后续工作成果中找到对应点l 逆向跟踪检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处l 正向跟踪和逆向跟踪合称为“双向跟踪”不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）需求跟踪矩阵保存了需求与后续工作成果的对应关系矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系由于对应关系比较复杂，最好在表格中加必要的文字解释表1-1为简单的需求跟踪矩阵格式l 当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵＃需求文档（版本，日期）设计文档（版本，日期）代码（版本，日期）测试用例（版本，日期）1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明2…………表1-1 简单的需求跟踪矩阵格式[Step2] 查找不一致l 使用需求跟踪矩阵的优点是很容易发现需求文档与后续工作成果之间的不一致之处，例如：² 后续工作成果没有实现需求文档中的某些需求；² 后续工作成果实现了需求文档中的不存在的需求；² 后续工作成果没有正确实现需求文档中的的需求； l 项目经理将发现的“不一致性”记录在《需求跟踪报告》之中，并通报给相关责任人（工作成果的开发者）。

[Step3] 消除不一致l 相关责任人给出消除“不一致”的措施和计划，项目经理将该措施和计划记录到《需求跟踪报告》之中l 相关责任人消除“不一致性”之后，项目经理更新“需求跟踪矩阵”1.3.6 输出l 《需求跟踪报告》1.3.7 结束准则l 每个开发阶段的“需求跟踪矩阵”都已经建立l 已经消除了需求文档与后续工作成果之间的不一致性1.3.1 度量l 项目经理统计工作量和上述文档的规模1.4 需求变更控制1.4.1 目的l 修改“原需求文档”中不正确的内容，产生新的需求文档l 控制需求文档的变更，防止发生混乱补充说明：本规程中的“原需求文档”是指已经通过了评审并获得书面承诺的需求文档1.4.2 角色与职责l 开发方负责人（项目经理）和客户共同控制需求变更1.4.3 启动准则l 某人（来自开发方或客户方）提出变更“原需求文档”的申请1.4.4 输入l “原需求文档”1.4.5 主要步骤[Step1] 需求变更申请l 需求变更申请人撰写“需求变更申请书”，递交给项目经理或客户方负责人l “需求变更申请书”必须阐述：（1）变更原因；（2）变更的内容；（3）此变更对项目造成的影响[Step2] 审批需求变更申请 开发方负责人（项目经理）和客户共同审批“需求变更申请书”：l 如果任何一方不同意变更，则退回变更请求，项目按照“原需求文档”执行。

l 如果双方都同意变更，转向 [Step3][Step3] 更改需求文档l 需求分析员根据 [Step1] 和 [Step2] 更改“原需求文档”，产生新的需求文档[Step4] 重新进行需求确认l 重新进行需求评审，参见需求确认规程中的 [Step2]l 重新获取书面的需求承诺，参见需求确认规程中的 [Step3]1.4.6 输出l 《需求变更控制报告》1.4.7 结束准则l 新的需求文档已经被确认1.4.1 度量l 项目经理统计工作量1.5 实施建议l 先对项目经理和客户进行培训，让他们掌握必要的需求管理知识l 对需求管理过程域产生的所有有价值的文档进行配置管理l 对于非合同项目，本规范中有关客户的活动可以被裁减掉。