CMMI需求管理说明及相关文档模板

1、0 数据库变更管理数据库变更管理.1 目的.1 角色与职责.1 启动准则.1 输入.1 主要步骤.1 step1 数据库设计变更申请.1 step2 审批数据库设计变更申请.1 step3 更改数据库设计文档.2 step4 重新进行数据库设计确认.2 输出.2 结束准则.2 度量.2 1 数据库变更管理数据库变更管理 目的目的 铁路客票安全系统的数据库由设计部委派专人负责管理，以防止出现混乱。 修改“原数据库设计文档”中不正确的内容，产生新的数据库文档。 控制数据库文档和脚本的变更，防止发生混乱。 补充说明：本规程中的“原数据库设计文档”是指已经通过了评审并获得书面承诺的数据库 设计文档。

2、角色与职责角色与职责 设计部委派专人负责管理数据库，目前数据库管理项目的负责人为王雪晖 启动准则启动准则 某人（来自项目开发组或客户方）提出变更“原数据库设计”的申请。 输入输入 “原数据库设计文档” 主要步骤主要步骤 step1 数据库设计变更申请数据库设计变更申请 数据库设计变更申请人撰写“数据库设计申请书” ，递交给项目经理或客户方负责人。 “数据库设计申请书”必须阐述：（1）变更原因；（2）变更的内容；（3）此变更对 项目造成的影响。 step2 审批数据库设计变更申请审批数据库设计变更申请 设计部、变更提出者的开发方负责人（项目经理）和数据库管理项目负责人共同审批 “数据库设计变更申

3、请书”： 如果任何一方不同意变更，则退回变更请求，项目按照“原数据库设计文档”执行。 如果双方都同意变更，转向 step3。 2 step3 更改数据库设计文档更改数据库设计文档 数据库管理员根据 step1 和和 step2 更改“原数据库设计文档”和 sql 脚本，产生 新的数据库设计文档和 sql 脚本。 step4 重新进行数据库设计确认重新进行数据库设计确认 重新进行数据库设计评审，参见数据库设计确认规程中的 step2。 重新获取书面的数据库设计承诺，参见需求确认规程中的 step3。 输出输出 数据库设计变更控制报告 新的数据库设计文档 新的 sql 脚本 结束准则结束准则 新的

4、数据库设计文档已经被确认。 度量度量 数据库管理项目经理统计工作量。 3 第第 8 章章 需求管理需求管理.2 8.1 介绍介绍.2 8.2 需求确认需求确认.3 8.2.1 目的.3 8.2.2 角色与职责.3 8.2.3 启动准则.3 8.2.4 输入.3 8.2.5 主要步骤.4 step1 非正式需求评审.4 step2 正式需求评审.4 step3 获取需求承诺.4 8.2.6 输出.4 8.2.7 结束准则.4 8.2.8 度量.4 8.3 需求跟踪需求跟踪.5 8.3.1 目的.5 3.3.2 角色与职责.5 3.3.3 启动准则.5 3.3.4 输入.5 3.3.5 主要步骤.

5、5 step1 建立与维护需求跟踪矩阵.5 step2 查找不一致.6 step3 消除不一致.6 8.3.6 输出.6 8.3.7 结束准则.6 8.3.8 度量.6 8.4 需求变更控制需求变更控制.7 8.4.1 目的.7 8.4.2 角色与职责.7 8.4.3 启动准则.7 8.4.4 输入.7 8.4.5 主要步骤.7 step1 需求变更申请.7 step2 审批需求变更申请.7 step3 更改需求文档.7 step4 重新进行需求确认.8 4 8.4.6 输出.8 8.4.7 结束准则.8 8.4.8 度量.8 8.5 实施建议实施建议.8 5 第第 8 章章 需求管理需求管理

6、 需求管理（requirement management, rm）的目的在客户与开发方之间建立对需求的共 同理解，维护需求与其他工作成果的一致性，并控制需求的变更。 需求管理过程域是 spp 模型的重要组成部分。本规范阐述了需求管理过程域的三个主要 规程： 需求确认 spp-proc-rm-validate 需求跟踪 spp-proc-rm-tracking 需求变更控制 spp-proc-rm-change 上述每个规程的“目标” 、 “角色与职责” 、 “启动准则” 、 “输入” 、 “主要步骤” 、 “输出” 、 “完成准则”和“度量”均已定义。 本规范适用于国内 it 企业的软件研发项

7、目。建议用户根据自身情况（如商业目标、研 发实力等）适当地修改本规范，然后推广使用。 8.1 介绍介绍 我们把所有与需求相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类 属于需求开发，另一类属于需求管理。图 8-1 为需求工程的结构图（流程见图 9-1） 。 图 8-1 需求工程结构图 需求管理过程域主要有 3 个规程：需求确认、需求跟踪与需求变更控制。 一、需求确认一、需求确认 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面 承诺，使需求文档具有商业合同效果。 二、需求跟踪二、需求跟踪 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与

8、维护“需求跟 需求工程 需求开发 需求变更控制 需求管理 需求确认 需求跟踪 需求调查 需求分析 需求定义 6 踪矩阵” ，确保产品依据需求文档进行开发。 三、需求变更控制三、需求变更控制 需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更， 确保需求的变更不会失去控制而导致项目发生混乱。 需求管理过程域产生的主要文档有： 需求评审报告 ，同技术评审报告的模板 spp-temp-tr-report。 需求跟踪报告 ，模板见 spp-temp-rm-tracking。 需求变更控制报告 ，模板见 spp-temp-rm-change。 8.2 需求确认需求确认 8.2.1 目的

9、目的 开发方和客户对需求文档如用户需求说明书和产品需求规格说明书进行评审， 并作书面承诺。 补充说明：用户需求说明书和产品需求规格说明书可以分开也可以放在一起进行需 求确认，视项目的具体情况而定。 8.2.2 角色与职责角色与职责 开发方和客户共同组织人员对需求文档如用户需求说明书和产品需求规格说明书 进行评审。 开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。 8.2.3 启动准则启动准则 需求文档如用户需求说明书和产品需求规格说明书已经完成。 8.2.4 输入输入 需求文档如用户需求说明书和产品需求规格说明书 。 7 8.2.5 主要步骤主要步骤 step1 非正

10、式需求评审非正式需求评审 项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。非 正式的需求评审方式请参考技术评审过程域的对应规程spp-proc-tr-itr。 step2 正式需求评审正式需求评审 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力尽最大努力 使需求文档能够正确无误地反映用户的真实意愿。使需求文档能够正确无误地反映用户的真实意愿。正式需求评审方式请参考技术评审过 程域的对应规程spp-proc-tr-ftr。 step3 获取需求承诺获取需求承诺 当需求文档通过正式的评审之后，开发方负责人（项目经理）和客户对需求文档作书面 承

11、诺，使之具有商业合同效果。示例如下： 本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求 文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导 致双方重新协商成本、资源和进度等。 甲方负责人签字 乙方负责人签字 8.2.6 输出输出 需求评审报告 书面的需求承诺 8.2.7 结束准则结束准则 需求文档通过了正式评审，并且获得开发方和客户的书面承诺。 8.2.8 度量度量 项目经理统计工作量和上述文档的规模 8 8.3 需求跟踪需求跟踪 8.3.1 目的目的 将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文 档

12、设计文档代码测试用例”之间的一致性，确保产品依据需求文档进行开发。 3.3.2 角色与职责角色与职责 项目经理跟踪需求。 3.3.3 启动准则启动准则 需求文档已经通过正式评审并获得了承诺。 系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例已经产生。 3.3.4 输入输入 需求文档 设计文档、代码、测试用例等 3.3.5 主要步骤主要步骤 step1 建立与维护需求跟踪矩阵建立与维护需求跟踪矩阵 正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。 正向跟踪和逆向跟踪合称为“双向跟踪

13、” 。不论采用何种跟踪方式，都要建立与维护需 求跟踪矩阵（即表格） 。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单 元之间的可能存在“一对一” 、 “一对多”或“多对多”的关系。由于对应关系比较复杂， 最好在表格中加必要的文字解释。表 8-1 为简单的需求跟踪矩阵格式。 当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。 需求文档 （版本，日期） 设计文档 （版本，日期） 代码 （版本，日期） 测试用例 （版本，日期） 1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明 9 2 表 8-1 简单的需求跟踪矩阵格式 step2 查找不一致查找不一致 使用需

14、求跟踪矩阵的优点是很容易发现需求文档与后续工作成果之间的不一致之处，例 如： 后续工作成果没有实现需求文档中的某些需求； 后续工作成果实现了需求文档中的不存在的需求； 后续工作成果没有正确实现需求文档中的的需求； 项目经理将发现的“不一致性”记录在需求跟踪报告之中，并通报给相关责任人 （工作成果的开发者） 。 step3 消除不一致消除不一致 相关责任人给出消除“不一致”的措施和计划，项目经理将该措施和计划记录到需求 跟踪报告之中。 相关责任人消除“不一致性”之后，项目经理更新“需求跟踪矩阵” 。 8.3.6 输出输出 需求跟踪报告 8.3.7 结束准则结束准则 每个开发阶段的“需求跟踪矩阵”

15、都已经建立。 已经消除了需求文档与后续工作成果之间的不一致性。 8.3.8 度量度量 项目经理统计工作量和上述文档的规模。 10 8.4 需求变更控制需求变更控制 8.4.1 目的目的 修改“原需求文档”中不正确的内容，产生新的需求文档。 控制需求文档的变更，防止发生混乱。 补充说明：本规程中的“原需求文档”是指已经通过了评审并获得书面承诺的需求文档。 8.4.2 角色与职责角色与职责 开发方负责人（项目经理）和客户共同控制需求变更。 8.4.3 启动准则启动准则 某人（来自开发方或客户方）提出变更“原需求文档”的申请。 8.4.4 输入输入 “原需求文档” 8.4.5 主要步骤主要步骤 st

16、ep1 需求变更需求变更申请申请 需求变更申请人撰写“需求变更申请书” ，递交给项目经理或客户方负责人。 “需求变更申请书”必须阐述：（1）变更原因；（2）变更的内容；（3）此变更对项 目造成的影响。 step2 审批需求变更申请审批需求变更申请 开发方负责人（项目经理）和客户共同审批“需求变更申请书”： 如果任何一方不同意变更，则退回变更请求，项目按照“原需求文档”执行。 如果双方都同意变更，转向 step3。 step3 更改更改需求文档需求文档 需求分析员根据 step1 和和 step2 更改“原需求文档” ，产生新的需求文档。 11 step4 重新进行需求确认重新进行需求确认 重新

17、进行需求评审，参见需求确认规程中的 step2。 重新获取书面的需求承诺，参见需求确认规程中的 step3。 8.4.6 输出输出 需求变更控制报告 8.4.7 结束准则结束准则 新的需求文档已经被确认。 8.4.8 度量度量 项目经理统计工作量。 8.5 实施建议实施建议 先对项目经理和客户进行培训，让他们掌握必要的需求管理知识。 对需求管理过程域产生的所有有价值的文档进行配置管理。 对于非合同项目，本规范中有关客户的活动可以被裁减掉。 12 需求跟踪报告 1. 需求跟踪矩阵需求跟踪矩阵 提示：提示：正向跟踪和逆向跟踪合称为“双向跟踪” 。不论采用何种跟踪方式，都要建立与维护 需求跟踪矩阵（

18、即表格） 。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元 之间的可能存在“一对一” 、 “一对多”或“多对多”的关系。由于对应关系比较复杂，最好 在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪 矩阵。 需求文档 （版本，日期） 设计文档 （版本，日期） 代码 （版本，日期） 测试用例 （版本，日期） 1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明 2 2. 需求问题处理需求问题处理 提示：提示：查找工作成果与需求文档之间的不一致性，分析原因，给出解决措施 问题描述识别人、日期解决措施结果 1 2 13 数据库设计数据库设计变更控制报告 数据库设计数据库设计变更申请变更申请 申请变更的 数据库设计文档 输入名称，版本，日期等信息 变更的内容 及其理由 评估数据库设计变更将 对 项目造成的影响 申请人签字 变更申请的审批意见变更申请的审批意见 变更申请方 项目经理签字 审批意见： 签字，日期 设计部签字 审批意见： 签字，日期 更改需求文档更改需求文档 变更后的 数据库设计文档 输入名称，版本，完成日期等信息 更改人签字 14 重新评审重新评审数据库设计数据库设计文档文档 数据库设计评审小组签