需求管理分析和总结.docx

第8章需求管理

需求管理（RequirementManagement，RM）的目的是在客户与开发之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。

需求管理过程域是SPP模型的重要组成部分。本规范阐述了需求管理过程域的三个重要规程：

☆需求确认[SPP_PROC_RM_VALIDATE]

☆需求跟踪[SPP_PROC_RM_TRACKING]

☆需求变更控制[SPP_PROC_RM_CHANGE]

上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。

介 绍

所有与需求相关地活动统称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。图8-1为需求工程的结构图。

图8.1需求工程结构图

需求管理过程域主要有3个规程：需求确认、需求跟踪与需求变更控制。

1、需求确认

需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。

2、需求跟踪

需求跟踪是指通过比较需求文档与后继工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依照需求文档进行开发。

3、需求变更控制

需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。

需求管理过程域产生的主要文档有：

☆《需求评审报告》，同技术评审报告的模板[SPP_TEMP_TR_REPORT]。

☆《需求跟踪报告》，模板见[SPP_TEMP_RM_TRACKING]。

☆《需求变更控制报告》，模板见[SPP_TEMP_RM_CHANGE]。

需求确认

目的

开发方和客户对需求文档如《用户需求说明书》和《产品需求规格说明书》进行评审，并作出书面承诺。

提示 ： 《用户需求说明书》和《产品需求规格说明书》可以分开也可以放在一起进行需求确认，视项目的具体情况而定。

角色与职责

开发方和客户共同组织人员对需求文档如《用户需求说明书》和《产品需求规格说明书》进行评审。

开发方负责人和客户对需求文档作书面承诺，使之具有商业合同效果。

启动准则

需求文档如《用户需求说明书》和《产品需求规格说明书》已经完成。

输入

需求文档如《用户需求说明书》和《产品需求规格说明书》。

主要步骤

『Step1』非正式需求评审

项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。非正式的需求评审方式请参考技术评审过程域的对应规程[SPP_PROC_TR_ITR]。

『Step2』正是需求评审

项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误的反映用户的真实意愿。正式需求评审偾事请参考技术评审过程域的对应规程[SPP_PROC_TR_FTR]。

『Step3』获取需求承诺

当需求文档通过正式的评审之后，开发方负责人）（项目经理）和客户对需求文档做书面承诺，使之具有商业合同效果。示例如下：

本需求文档建立在双方需求的共同理解基础上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制程序”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。

甲方负责人签字

乙方负责人签字

输出

《需求评审报告》。

书面的需求承诺。

结束准则

需求文档通过了正式评审，并且获得了开发方和客户的书面承诺。

度量

项目经理统计工作量和上述文档的规模。

需求跟踪

目的

将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档-设计文档-代码-测试用例”之间的一致性，确保产品依据需求文档进行开发。

角色与职责

项目经理更总需求。

启动准则

需求文档已经通过正式评审并获得了承诺。

系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例已经产生。

输入

需求文档

设计文档、代码、测试用例等。

主要步骤

『Step1』建立与维护需求跟踪矩阵

正向跟踪。检查需求文档中的每个需求是否能在后续工作成果中找到对应点。

逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求文档中昭到出去。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间可能存在“一对一”、“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。表8-1为简单的需求跟踪矩阵格式。

当需求文档或后续工作成