需求管理研究报告样本.doc

第第 8 章章 需求管理需求管理.2 8.1 介绍介绍.2 8.2 需求确定需求确定.3 8.2.1 目标.3 8.2.2 角色和职责.4 8.2.3 开启准则.4 8.2.4 输入.4 8.2.5 关键步骤.4 Step1 非正式需求评审.4 Step2 正式需求评审.4 Step3 获取需求承诺.4 8.2.6 输出.5 8.2.7 结束准则.5 8.2.8 度量.5 8.3 需求跟踪需求跟踪.5 8.3.1 目标.5 3.3.2 角色和职责.6 3.3.3 开启准则.6 3.3.4 输入.6 3.3.5 关键步骤.6 Step1 建立和维护需求跟踪矩阵.6 Step2 查找不一致.7 Step3 消除不一致.7 8.3.6 输出.7 8.3.7 结束准则.7 8.3.8 度量.8 8.4 需求变更控制需求变更控制.8 8.4.1 目标.8 8.4.2 角色和职责.8 8.4.3 开启准则.8 8.4.4 输入.8 8.4.5 关键步骤.8 Step1 需求变更申请.8 Step2 审批需求变更申请.9 Step3 更改需求文档.9 Step4 重新进行需求确定.9 8.4.6 输出.9 8.4.7 结束准则.9 8.4.8 度量.9 8.5 实施提议实施提议.10 第第 8 章章 需求管理需求管理 需求管理（Requirement Management,RM）目标在用户和开发方之间建立对需求共同了解，维护需求和其它工作结果一致性，并控制需求变更。需求管理过程域是 SPP 模型关键组成部分。本规范叙述了需求管理过程域三个关键规程：需求确定 SPP-PROC-RM-VALIDATE 需求跟踪 SPP-PROC-RM-TRACKING 需求变更控制 SPP-PROC-RM-CHANGE 上述每个规程“目标”、“角色和职责”、“开启准则”、“输入”、“关键步骤”、“输出”、“完成准则”和“度量”均已定义。本规范适适用于中国 IT 企业软件研发项目。提议用户依据本身情况（如商业目标、研发实力等）合适地修改本规范，然后推广使用。8.1 介绍介绍 我们把全部和需求相关活动通称为需求工程。需求工程中活动可分为两大类，一类属于需求开发，另一类属于需求管理。图 8-1 为需求工程结构图（步骤见图 9-1）。需求工程 需求开发 需求变更控制 需求管理 需求确定 需求跟踪 需求调查 需求分析 需求定义 图 8-1 需求工程结构图 需求管理过程域关键有 3 个规程：需求确定、需求跟踪和需求变更控制。一、需求确定一、需求确定 需求确定是指开发方和用户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档含有商业协议效果。二、需求跟踪二、需求跟踪 需求跟踪是指经过比较需求文档和后续工作结果之间对应关系，建立和维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。三、需求变更控制三、需求变更控制 需求变更控制是指依据“变更申请审批更改重新确定”步骤处理需求变更，确保需求变更不会失去控制而造成项目发生混乱。需求管理过程域产生关键文档有：需求评审汇报，同技术评审汇报模板 SPP-TEMP-TR-REPORT。需求跟踪汇报，模板见 SPP-TEMP-RM-TRACKING。需求变更控制汇报，模板见 SPP-TEMP-RM-CHANGE。8.2 需求确定需求确定 8.2.1 目标目标 开发方和用户对需求文档如用户需求说明书和产品需求规格说明书进行评审，并作书面承诺。补充说明：用户需求说明书和产品需求规格说明书能够分开也能够放在一起进行需求确定，视项目标具体情况而定。8.2.2 角色和职责角色和职责 开发方和用户共同组织人员对需求文档如用户需求说明书和产品需求规格说明书进行评审。开发方责任人（项目经理）和用户对需求文档作书面承诺，使之含有商业协议效果。8.2.3 开启准则开启准则 需求文档如用户需求说明书和产品需求规格说明书已经完成。8.2.4 输入输入 需求文档如用户需求说明书和产品需求规格说明书。8.2.5 关键步骤关键步骤 Step1 非正式需求评审非正式需求评审 项目经理先在项目内部组织人员进行非正式需求评审，以消除显著错误和分歧。非正式需求评审方法请参考技术评审过程域对应规程SPP-PROC-TR-ITR。Step2 正式需求评审正式需求评审 项目经理邀请同行教授和用户（包含用户和最终用户）一起评审需求文档，尽最大尽最大努力使需求文档能够正确无误地反应用户真实意愿。努力使需求文档能够正确无误地反应用户真实意愿。正式需求评审方法请参考技术评审过程域对应规程SPP-PROC-TR-FTR。Step3 获取需求承诺获取需求承诺 当需求文档经过正式评审以后，开发方责任人（项目经理）和用户对需求文档作书面承诺，使之含有商业协议效果。示例以下：本需求文档建立在双方对需求共同了解基础之上，我同意后续开发工作依据该需求文档开展。假如需求发生改变，我们将根据“需求变更控制规程”实施。我明白需求变更将造成双方重新协商成本、资源和进度等。甲方责任人签字 乙方责任人签字 8.2.6 输出输出 需求评审汇报 书面需求承诺 8.2.7 结束准则结束准则 需求文档经过了正式评审，而且取得开发方和用户书面承诺。8.2.8 度量度量 项目经理统计工作量和上述文档规模 8.3 需求跟踪需求跟踪 8.3.1 目标目标 将系统设计、编程、测试等阶段工作结果和需求文档进行比较，建立和维护“需求文档设计文档代码测试用例”之间一致性，确保产品依据需求文档进行开发。3.3.2 角色和职责角色和职责 项目经理跟踪需求。3.3.3 开启准则开启准则 需求文档已经经过正式评审并取得了承诺。系统设计、编程、测试等阶段工作结果如设计文档、代码、测试用例已经产生。3.3.4 输入输入 需求文档 设计文档、代码、测试用例等 3.3.5 关键步骤关键步骤 Step1 建立和维护需求跟踪矩阵建立和维护需求跟踪矩阵 正向跟踪。检验需求文档中每个需求是否全部能在后续工作结果中找到对应点。逆向跟踪。检验设计文档、代码、测试用例等工作结果是否全部能在需求文档中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪”。不管采取何种跟踪方法，全部要建立和维护需求跟踪矩阵（即表格）。需求跟踪矩阵保留了需求和后续工作结果对应关系。矩阵单元之间可能存在“一对一”、“一对多”或“多对多”关系。因为对应关系比较复杂，最好在表格中加必需文字解释。表 8-1 为简单需求跟踪矩阵格式。当需求文档或后续工作结果发生变更时，要立即更新需求跟踪矩阵。需求文档（版本，日期）设计文档（版本，日期）代码（版本，日期）测试用例（版本，日期）1 标题或标识符，说明 标题或标识符，说明 代码名称，说明 测试用例名称，说明 2 表 8-1 简单需求跟踪矩阵格式 Step2 查找不一致查找不一致 使用需求跟踪矩阵优点是很轻易发觉需求文档和后续工作结果之间不一致之处，比如：后续工作结果没有实现需求文档中一些需求；后续工作结果实现了需求文档中不存在需求；后续工作结果没有正确实现需求文档中需求；项目经理将发觉“不一致性”统计在需求跟踪汇报之中，并通报给相关责任人（工作结果开发者）。Step3 消除不一致消除不一致 相关责任人给出消除“不一致”方法和计划，项目经理将该方法和计划统计到需求跟踪汇报之中。相关责任人消除“不一致性”以后，项目经理更新“需求跟踪矩阵”。8.3.6 输出输出 需求跟踪汇报 8.3.7 结束准则结束准则 每个开发阶段“需求跟踪矩阵”全部已经建立。已经消除了需求文档和后续工作结果之间不一致性。8.3.8 度量度量 项目经理统计工作量和上述文档规模。8.4 需求变更控制需求变更控制 8.4.1 目标目标 修改“原需求文档”中不正确内容，产生新需求文档。控制需求文档变更，预防发生混乱。补充说明：本规程中“原需求文档”是指已经经过了评审并取得书面承诺需求文档。8.4.2 角色和职责角色和职责 开发方责任人（项目经理）和用户共同控制需求变更。8.4.3 开启准则开启准则 某人（来自开发方或用户方）提出变更“原需求文档”申请。8.4.4 输入输入 “原需求文档”8.4.5 关键步骤关键步骤 Step1 需求变更申请需求变更申请 需求变更申请人撰写“需求变更申请书”，递交给项目经理或用户方责任人。“需求变更申请书”必需叙述：（1）变更原因；（2）变更内容；（3）此变更对项目造成影响。Step2 审批需求变更申请审批需求变更申请 开发方责任人（项目经理）和用户共同审批“需求变更申请书”：假如任何一方不一样意变更，则退回变更请求，项目根据“原需求文档”实施。假如双方全部同意变更，转向 Step3。Step3 更改需求文档更改需求文档 需求分析员依据 Step1 和和 Step2 更改“原需求文档”，产生新需求文档。Step4 重新进行需求确定重新进行需求确定 重新进行需求评审，参见需求确定规程中 Step2。重新获取书面需求承诺，参见需求确定规程中 Step3。8.4.6 输出输出 需求变更控制汇报 8.4.7 结束准则结束准则 新需求文档已经被确定。8.4.8 度量度量 项目经理统计工作量。8.5 实施提议实施提议 先对项目经理和用户进行培训，让她们掌握必需需求管理知识。对需求管理过程域产生全部有价值文档进行配置管理。对于非协议项目，本规范中相关用户活动能够被淘汰掉。