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

1、CMMI需求管理说明及相关文档模板数据库变更管理 目的铁路客票安全系统的数据库由设计部委派专人负责管理，以防止出现混乱。修改“原数据库设计文档”中不正确的内容，产生新的数据库文档。控制数据库文档和脚本的变更，防止发生混乱。补充说明：本规程中的“原数据库设计文档”是指已经通过了评审并获得书面承诺的数据库设计文档。角色与职责设计部委派专人负责管理数据库，目前数据库管理项目的负责人为王雪晖启动准则某人（来自项目开发组或客户方）提出变更“原数据库设计”的申请。输入“原数据库设计文档”主要步骤Step1 数据库设计变更申请数据库设计变更申请人撰写“数据库设计申请书”，递交给项目经理或客户方负责人。“数据

2、库设计申请书”必须阐述：（1）变更原因；（2）变更的内容；（3）此变更对项目造成的影响。Step2 审批数据库设计变更申请 设计部、变更提出者的开发方负责人（项目经理）和数据库管理项目负责人共同审批“数据库设计变更申请书”：如果任何一方不同意变更，则退回变更请求，项目按照“原数据库设计文档”执行。如果双方都同意变更，转向 Step3。Step3 更改数据库设计文档数据库管理员根据 Step1 和 Step2 更改“原数据库设计文档”和SQL脚本，产生新的数据库设计文档和SQL脚本。Step4 重新进行数据库设计确认重新进行数据库设计评审，参见数据库设计确认规程中的 Step2。重新获取书面的数

3、据库设计承诺，参见需求确认规程中的 Step3。输出数据库设计变更控制报告新的数据库设计文档新的SQL脚本结束准则新的数据库设计文档已经被确认。度量数据库管理项目经理统计工作量。第8章 需求管理需求管理（Requirement Management, RM）的目的在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理过程域是SPP模型的重要组成部分。本规范阐述了需求管理过程域的三个主要规程：需求确认 SPP-PROC-RM-VALIDATE需求跟踪 SPP-PROC-RM-TRACKING需求变更控制 SPP-PROC-RM-CHANGE上述每个规程

4、的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。8.1 介绍我们把所有与需求相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。图8-1为需求工程的结构图（流程见图9-1）。图8-1 需求工程结构图需求管理过程域主要有3个规程：需求确认、需求跟踪与需求变更控制。一、需求确认需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效

5、果。二、需求跟踪需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。三、需求变更控制需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。需求管理过程域产生的主要文档有：需求评审报告，同技术评审报告的模板 SPP-TEMP-TR-REPORT。需求跟踪报告，模板见 SPP-TEMP-RM-TRACKING。需求变更控制报告，模板见 SPP-TEMP-RM-CHANGE。8.2 需求确认8.2.1 目的开发方和客户对需求文档如用户需求说明书和产品需求规格说明书进行评审，并

6、作书面承诺。补充说明：用户需求说明书和产品需求规格说明书可以分开也可以放在一起进行需求确认，视项目的具体情况而定。.2 角色与职责开发方和客户共同组织人员对需求文档如用户需求说明书和产品需求规格说明书进行评审。开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。.3 启动准则需求文档如用户需求说明书和产品需求规格说明书已经完成。.4 输入需求文档如用户需求说明书和产品需求规格说明书。.5 主要步骤Step1 非正式需求评审项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。非正式的需求评审方式请参考技术评审过程域的对应规程SPP-PROC-TR-IT

7、R。Step2 正式需求评审项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。正式需求评审方式请参考技术评审过程域的对应规程SPP-PROC-TR-FTR。Step3 获取需求承诺 当需求文档通过正式的评审之后，开发方负责人（项目经理）和客户对需求文档作书面承诺，使之具有商业合同效果。示例如下： 本需求文档建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。 甲方负责人签字乙方负责人签字.6 输

8、出需求评审报告书面的需求承诺.7 结束准则需求文档通过了正式评审，并且获得开发方和客户的书面承诺。.8 度量项目经理统计工作量和上述文档的规模8.3 需求跟踪8.3.1 目的将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档设计文档代码测试用例”之间的一致性，确保产品依据需求文档进行开发。.2 角色与职责项目经理跟踪需求。.3 启动准则需求文档已经通过正式评审并获得了承诺。系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例已经产生。.4 输入需求文档设计文档、代码、测试用例等.5 主要步骤Step1 建立与维护需求跟踪矩阵正向跟踪。检查需求文档中的每个需

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

10、称，说明测试用例名称，说明2表8-1 简单的需求跟踪矩阵格式Step2 查找不一致使用需求跟踪矩阵的优点是很容易发现需求文档与后续工作成果之间的不一致之处，例如：后续工作成果没有实现需求文档中的某些需求；后续工作成果实现了需求文档中的不存在的需求；后续工作成果没有正确实现需求文档中的的需求； 项目经理将发现的“不一致性”记录在需求跟踪报告之中，并通报给相关责任人（工作成果的开发者）。Step3 消除不一致相关责任人给出消除“不一致”的措施和计划，项目经理将该措施和计划记录到需求跟踪报告之中。相关责任人消除“不一致性”之后，项目经理更新“需求跟踪矩阵”。.6 输出需求跟踪报告.7 结束准则每个开

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

12、变更申请书”必须阐述：（1）变更原因；（2）变更的内容；（3）此变更对项目造成的影响。Step2 审批需求变更申请 开发方负责人（项目经理）和客户共同审批“需求变更申请书”：如果任何一方不同意变更，则退回变更请求，项目按照“原需求文档”执行。如果双方都同意变更，转向 Step3。Step3 更改需求文档需求分析员根据 Step1 和 Step2 更改“原需求文档”，产生新的需求文档。Step4 重新进行需求确认重新进行需求评审，参见需求确认规程中的 Step2。重新获取书面的需求承诺，参见需求确认规程中的 Step3。.6 输出需求变更控制报告.7 结束准则新的需求文档已经被确认。.8 度量项

13、目经理统计工作量。8.5 实施建议先对项目经理和客户进行培训，让他们掌握必要的需求管理知识。对需求管理过程域产生的所有有价值的文档进行配置管理。对于非合同项目，本规范中有关客户的活动可以被裁减掉。需求跟踪报告1. 需求跟踪矩阵提示：正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。 需求文档（版本，日期）设计文档（版本，日期）

14、代码（版本，日期）测试用例（版本，日期）1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明22. 需求问题处理提示：查找工作成果与需求文档之间的不一致性，分析原因，给出解决措施问题描述识别人、日期解决措施结果12数据库设计变更控制报告数据库设计变更申请申请变更的数据库设计文档输入名称，版本，日期等信息变更的内容及其理由评估数据库设计变更将对项目造成的影响申请人签字变更申请的审批意见变更申请方项目经理签字审批意见：签字，日期设计部签字审批意见：签字，日期更改需求文档变更后的数据库设计文档输入名称，版本，完成日期等信息更改人签字重新评审数据库设计文档数据库设计评审小组签字评审意见：签字，日期变更结束变更申请方项目经理签字签字日期：需求变更控制报告需求变更申请申请变更的需求文档输入名称，版本，日期等信息变更的内容及其理由评估需求变更将对项目造成的影响申请人签字变更申请的审批意见项目经理签字审批意见：签字，日期客户签字（合同项目）审批意见：签字，日期更改需求文档变更后的需求文档输入名称，版本，完成日期等信息更改人签字重新评审需求文档需求评审小组签字评审意见：签字，日期变更结束项目经理签字签字日期：