CMMI5文档之需求跟踪矩阵维护规程

需求跟踪矩阵维护规程文档编号：FHI_CMMI_RM_PRD_FV A文档信息：需求跟踪矩阵维护规程文档名称：需求跟踪矩阵维护规程文档类别：CMMI规程密级：内部秘密版本信息：1.0建立日期：2016-1-5创建人：EPG批准人：李庆林批准日期：2016.2.25存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版文档修订记录目录1简介 (4)1.1文档目的 (4)1.2适用范围 (4)1.3术语表 (4)1.4参考资料 (4)2需求跟踪矩阵建立 (4)2.1《需求跟踪矩阵》概述 (4)2.2需求跟踪矩阵建立流程 (4)2.2.1创建《需求跟踪矩阵》 (6)2.2.2需求定义和需求分析阶段《需求跟踪矩阵》的填写 (6)2.2.3设计阶段《需求跟踪矩阵》的填写 (7)2.2.4编码阶段《需求跟踪矩阵》的填写 (7)2.2.5测试阶段《需求跟踪矩阵》的填写 (7)3需求跟踪矩阵变更 (8)3.1需求跟踪矩阵变更概述 (8)3.2需求跟踪矩阵变更流程................................................... 错误！未定义书签。

3.2.1设计阶段需求变更.................................................... 错误！未定义书签。

3.2.2编码阶段需求变更.................................................... 错误！未定义书签。

3.2.3测试阶段需求变更.................................................... 错误！未定义书签。

3.2.4维护阶段需求变更.................................................... 错误！未定义书签。

4需求功能编号的编写规则 (8)1简介1.1文档目的需求追溯包括正向追溯（追溯）和反向追溯（回溯）。

通过实施追溯将会使项目在审核、变更影响分析、维护、跟踪、再设计、重用、减小风险、测试等方面受益，需求追溯的具体方法是维护《需求跟踪矩阵》，通过维护《需求跟踪矩阵》需求项、功能项、设计项、代码项、测试项等之间的关联来获得需求追溯的能力。

项目经理负责并组织在项目的整个工程过程中，对客户需求进行追溯，以保证系统或产品的完整性和准确性。

本规程的目的是为了定义在软件生命周期内维护《需求跟踪矩阵》的时机，并规定软件生命周期各阶段维护《需求跟踪矩阵》的主要内容、入口、出口和人员等。

1.2适用范围本规程适用于公司的所有软件项目。

1.3术语表无。

1.4参考资料1.《软件需求管理过程》2.《软件需求》，Karl E. Wiegers著，陆丽娜、王忠民、王志敏等译，机械工业出版社，2000年7月2需求跟踪矩阵建立2.1《需求跟踪矩阵》概述需求追溯贯穿项目的整个生命周期，即在项目的各个阶段均要进行软件需求的追溯，通过不同阶段填写《需求跟踪矩阵》，建立软件需求与开发过程的追溯关系，这样可以根据软件需求追溯到开发工作产品，从而确保每个工作产品满足每个需求。

2.2《需求跟踪矩阵》模板使用说明2.2.1需求跟踪矩阵1、在每次需求变更或者相关工作成果发生变更时，应当及时更新“矩阵跟踪信息”sheet页当中对应项的“最后更新日期”。

2、项目组在跟踪过程中，项目组将相应需求、概要设计、详细设计、实现、测试用例的内容填写到对应项中，如果有多个设计等对应同一个需求，可以填写在同一栏中。

每次需求跟踪矩阵更新后，请小组负责人将日期、工作量填写在“矩阵跟踪信息”相应的栏目中，以便进行需求的跟踪度量。

3、需求管理人员应该检查需求跟踪的结果，并生成需求状态统计表（即需求变更），在完成需求检查后，应该将需求验证的日期及产生的工作量填写在相应的栏目中。

4、关于优先级的说明：优先级表示的是某项内容相对于同类的其他内容的优先级顺序，其取值范围为：高、中、低。

如果某几项内容的优先级相同则将其优先级设为相同的值。

5、填写“需求跟踪矩阵”sheet页中“《用户需求说明书》、《软件需求规格说明书》”相应的内容后，会自动将所录入的需求编号、优先级、责任人信息增加到“需求状态统计”sheet页中。

6、需求跟踪矩阵内容发生变化后，要进行审批。

2.2.2需求状态统计1、变更次数是指需求从增加开始的变化次数。

例如：从“增加”变为“修改”为一次，再次修改，为两次；从“增加”变为“删除”为一次，后又重新“增加”，为两次。

2、需求项状态的含义如下：已建议：该需求已被有权提出需求的人建议已批准：该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该项需求已实现：已实现需求代码的设计、编写和单元测试已验证：使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。

该需求现在被认为完成已删除：计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员下版本：该需求已被有权提出需求的人（客户或系统分析组成员）接受，但在下个版本实现。

此状态是需求项最新的状态，不是需求项的历史状态。

2.3需求跟踪矩阵建立流程2.3.1创建《需求跟踪矩阵》1.创建人：项目经理2.前提：项目经理指定了项目成员角色，包括需求人员（填写《需求跟踪矩阵》的需求项），设计人员（填写设计项），开发人员（填写实现项），测试负责人（填写测试项）。

3.步骤创建《需求跟踪矩阵》将《需求跟踪矩阵》交给需求人员2.3.2需求定义阶段《需求跟踪矩阵》的填写1.填写人：项目经理或其指定的项目组成员2.参与人：项目经理3.前提：《用户需求说明书》已经纳入基线4.步骤填写《用户需求说明书》中描述软件需求的唯一代号（或标识）及需求名称填写需求状态项（已建议或下版本）填写责任人相关负责人审批需求跟踪矩阵2.3.3需求分析阶段《需求跟踪矩阵》的填写1.填写人：项目经理或其指定的项目组成员2.参与人：项目经理3.前提：《软件需求规格说明书》已经纳入基线4.步骤填写《软件需求规格说明书》编号及需求名称填写需求状态项（已接受或已建议）填写优先级提交《需求跟踪矩阵》给项目经理确认填写责任人项目经理确认需求项和需求状态项相关负责人审批需求跟踪矩阵说明：“已建议”指用户需求已经确认，但是未进行需求分析的状态。

2.3.4概要设计阶段《需求跟踪矩阵》的填写1.填写人：项目经理或其指定的项目组成员2.参与人：项目经理3.前提：《概要设计》已经纳入基线4.步骤：填写《概要设计》编号填写责任人相关负责人审批需求跟踪矩阵2.3.5详细设计阶段《需求跟踪矩阵》的填写5.填写人：项目经理或其指定的项目组成员6.参与人：项目经理7.前提：《详细设计》已经纳入基线8.步骤：填写《详细设计》编号填写责任人相关负责人审批需求跟踪矩阵2.3.6编码阶段《需求跟踪矩阵》的填写1.填写人：项目经理或其指定的项目组成员2.参与人：项目经理3.前提：已经实现某个需求的编码工作4.步骤：以下步骤可以在实现阶段分阶段完成填写需求编号对应的实现程序编号填写需求状态项（已实现）填写责任人项目经理确认需求项和需求状态项相关负责人审批需求跟踪矩阵2.3.7集成测试阶段《需求跟踪矩阵》的填写5.填写人：项目经理或其指定的项目组成员6.参与人：测试负责人、项目经理7.前提：完成集成测试用例评审8.步骤：以下步骤可以在测试设计阶段分阶段完成填写需求编号对应的集成测试用例编号、名称填写责任人相关负责人审批需求跟踪矩阵2.3.8系统测试阶段《需求跟踪矩阵》的填写1.填写人：项目经理或其指定的项目组成员2.参与人：测试负责人、项目经理3.前提：完成系统测试用例评审4.步骤：以下步骤可以在测试设计阶段分阶段完成填写需求编号对应的系统测试用例编号、名称填写责任人测试完成后，填写需求状态项（已验证）相关负责人审批需求跟踪矩阵3需求跟踪矩阵变更3.1需求跟踪矩阵变更概述当发生需求变更时，通过《需求跟踪矩阵》从需求向后追溯到下游关联的工作产品，可分析出这些关联项是否需要变更，根据分析结果变更《需求跟踪矩阵》，该活动主要由项目经理执行。

有需求变更发生时，应按照《变更控制规程》的规定进行变更，并填写《需求跟踪矩阵》，“需求状态统计”中对“变更情况”进行设置。

需求跟踪矩阵内容发生变化后，要进行审批。

4需求功能编号的编写规则在《需求跟踪矩阵》的需求项是层次化的填写，要求需求功能编号的编写规则如下：功能性需求：每一层编号由1开始，顺序加一第二层编号规则：[父层编号].[本次由1开始的流水号]第三层编号规则：[第一次编号].父层编号].[本次由1开始的流水号]依此类推。

非功能性需求：与功能性需求类似，前面加上前缀NF例如：NF1.1接口需求：与功能性需求类似，前面加上前缀I例如：I1.1。