需求跟踪矩阵

需求跟踪矩阵(RTM)

需求跟踪矩阵（RTM）有什么作用？ （1）在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的变更波及范围、影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。 （2）RTM也是验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态：是否设计了，是否实现了，是否测试了。 2 需求跟踪矩阵分为哪几类？ （1）纵向跟踪矩阵，包括如下的3种： 需求之间的派生关系，客户需求到产品需求 实现与验证关系：需求到设计，需求到测试用例等 需求的责任分配关系；需求由谁来实现 （2）横向跟踪矩阵：需求之间的接口关系 3 在实践中，如何把握该建立哪些RTM？ （1）在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM SP1.4无法通过。横向跟踪如果不作，则是大部分实施。 （2）对于纵向跟踪矩阵： 必需的： 客户需求与产品需求的跟踪，产品需求与测试用例的跟踪。 100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵。 全局性需求要建立跟踪矩阵，包括：客户需求-产品需求-设计-编码-测试用例的跟踪矩阵。 核心需求要建立跟踪矩阵

并非必需的： 性能需求可以不建立跟踪矩阵 不影响系统架构的功能需求 4 需求跟踪矩阵由谁来建立？ 有多个角色参与建立RTM。需求开发人员负责客户需求到产品需求的RTM建立，设计人员负责需求到设计的RTM的建立，测试用例的编写人员负责需求到测试用例的RTM建立等等。PPQA 负责检查是否建立了RTM，是否所有的需求都被覆盖了。 5 RTM是否纳入基线管理？ RTM要纳入基线管理。纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。 6 如何简化RTM的工作？ 由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RTM 的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。 如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就是比较大。要简化，就要平衡管理的投入与产出，平衡时，可以借鉴上面的问题3。 当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样RTM的作用就打了折扣，还是一个平衡问题。

需求跟踪矩阵编写指南

需求跟踪矩阵编写指南 山东中创软件工程股份有限公司 二ОО七年三月

文件变更记录*A–增加M–修改D–删节

目录 1目的 (1) 2角色和职责 (1) 3格式 (1) 4表格说明 (1) 4.1项目基本信息 (1) 4.1.1 角色等基本信息 (1) 4.2需求跟踪矩阵（纵向） (1) 4.2.1 基线标识 (1) 4.2.2 列值说明 (1) 4.2.3 注意事项 (3) 4.3 需求跟踪矩阵（横向） (4) 4.3.1 列值说明 (4) 5需求跟踪矩阵的不断完善 (4)

1目的 需求跟踪是需求管理的一项重要内容。需求跟踪的主要意义在于获得需求目前的实现状态，确保用户所有的需求都得到满足。 它的主要目标是: 维护软件工作产品间的一致性。 2角色和职责 3格式 需求跟踪矩阵采用EXCEL电子表格形式制作。具体格式请参考《需求跟踪矩阵模板》。 4表格说明 4.1项目基本信息 4.1.1 角色等基本信息 填写项目名称、项目经理、项目小组责任人、更新次数、最后更新日期、更新需求跟踪矩阵的工作量（多次更新累加）以及版本号（此为需求跟踪矩阵的版本号）等信息。 4.2需求跟踪矩阵（纵向） 4.2.1 基线标识 列出该需求跟踪矩阵中用到的各个工作产品的基线标识号。 4.2.2 列值说明 关于优先级的说明：优先级表示的是某项内容相对于同类的其他内容的优先级顺序，其取值范围为：高、中、低。如果某几项内容的优先级相同则将其优先级设为相同的值。 《用户需求说明书》 需求编号：《用户需求说明书》中描述软件需求的唯一代号（或标识）。 责任人：相关需求的责任人。 《软件需求规格说明书》

需求跟踪矩阵编号规则

作用：“需求跟踪矩阵”主要用于记录和跟踪需求的分析、设计、实现、验证的过程。注：客户需求与产品需求、测试用例、设计、代码之间为多对多的关系。 关于“需求跟踪矩阵”编号，建议编号规则如下: A.规则一: （1）用户需求编号(UR_001_001_001),其中UR是代表用户需求,001_001_001代表一级模块_二级模块_功能点 （2）软件需求编号(SR_001_001_001),其中SR是代表软件需求,001_001_001代表一级模块_二级模块_功能点 （3）概要设计编号(PSD_001_001_001),其中PSD是代表概要设计,001_001_001代表一级模块_二级模块_功能点 （4）详细设计编号(DSD_001_001_001),其中DSD是代表详细设计,001_001_001代表一级模块_二级模块_功能点 （5）代码编号(CODE_001_001_001),其中CODE是代表代码,001_001_001代表一级模块_二级模块_功能点 （6）集成测试用例编号(ITC_001_001_001),其中ITC是代表集成测试用例,001_001_001代表一级模块_二级模块_功能点 （7）单元测试用例编号(UTC_001_001_001),其中UTC是代表单元测试用例,001_001_001代表一级模块_二级模块_功能点 （8）系统测试用例编号(STC_001_001_001),其中STC是代表系统测试用例,001_001_001代表一级模块_二级模块_功能点 B.规则二: （1）用户需求编号(UR_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （2）软件需求编号(SR_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （3）概要设计编号(PSD_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （4）详细设计编号(DSD_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （5）代码设计编号(CODE_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （6）集成测试用例编号(ITC_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （7）单元测试用例编号(UTC_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)

需求追踪矩阵

关于需求跟踪矩阵的6个问题 1 需求跟踪矩阵（RTM）有什么作用？ （1）在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。 （2）RTM也是验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态：是否设计了，是否实现了，是否测试了。 2 需求跟踪矩阵分为哪几类？ （1）纵向跟踪矩阵，包括如下的3种： 需求之间的派生关系，客户需求到产品需求 实现与验证关系：需求到设计，需求到测试用例等 需求的责任分配关系；需求由谁来实现 （2）横向跟踪矩阵： 需求之间的接口关系 3 在实践中，如何把握该建立哪些RTM？ （1）在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM SP1.4无法通过。横向跟踪如果不作，则是大部分实施。 （2）对于纵向跟踪矩阵： 必需的： 客户需求与产品需求的跟踪? 产品需求与测试用例的跟踪? 100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵? ?全局性需求要建立跟踪矩阵,包括：客户需求-产品需求-设计-编码-测试用例的跟踪矩阵核心需求要建立跟踪矩阵? 并非必需的： ?性能需求可以不建立跟踪矩阵 不影响系统架构的功能需求? 4 需求跟踪矩阵由谁来建立？ 有多个角色参与建立RTM。需求开发人员负责客户需求到产品需求的RTM建立，测试用例的编写人员负责需求到测试用例的RTM建立，设计人员负责需求到设计的RTM的建立等等。PP QA负责检查是否建立了RTM，是否所有的需求都被覆盖了。 5 RTM是否纳入基线管理？ RTM要纳入基线管理。纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。

需求跟踪矩阵填写指南

本资料仅供内部使用！ 需求跟踪矩阵填写指南 xxxx信息技术有限公司 2016年01月16日 本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属xxxx信息技术有限公司所有，受到有关产权及版权法保护。任何个人、机构未经xxxx信息技术有限公司的书面授权许可，不得以任何方式复制或引用本文件的任何片断。

需求跟踪矩阵 仅供内部使用修改记录

目录 1需求跟踪矩阵填写说明 (1) 2需求跟踪矩阵的维护和使用 (1) 3裁剪指南 (2)

1需求跟踪矩阵填写说明 【需求跟踪矩阵】用以跟踪需求到设计、设计到编码、编码的测试的映射过程。项目组可以根据实际情况裁剪模板的格式来满足项目的要求。需求跟踪矩阵的填写遵循以下原则：需求号：为每条需求编制唯一的识别号，通过需求号可以与需求文档中描述的需求建立一一对应关系。建议不要使用章节号作为需求号。如果没有在编程规范或需求跟踪矩阵中说明编号的格式，则可以按一下格式编号： ●需求号＝一级功能编号.二级功能编号.三级功能编号.N级功能编号 ●建议最多不要超过5级； ●例子：需求号1.2.1表示：第一个一级功能的第二个二级功能的一个三级功能。 软件需求描述：简单描述需求内容。这个描述看是冗余，但有简单描述可以使得跟踪矩阵更具可读性和独立性。 概要设计：描述需求在概要设计中的实现情况。建议使用编号对应，也可以使用文字对应，建议不要使用章节号。如果使用编号，请在编程规范中说明编号规则。 详细设计：描述概要设计在详细设计中的实现情况。建议使用编号对应，也可以使用文字对应，建议不要使用章节号。如果使用编号，请在编程规范中说明编号规则。 编码：描述详细设计在编码时的实现情况。可以使用函数名称，文件名称，对象名称等。 单元测试用例：描述详细设计对应的测试用例。 集成测试用例：描述概要设计对应的测试用例。 系统测试用例：描述需求对应的测试用例。 2需求跟踪矩阵的维护和使用 跟踪矩阵有助于在各个生命周期阶段跟踪所有需求，以此来确保实现所有已并入的需求，这也避免了由于遗漏需求而进行的重复劳动。通过为评审专家提供一套机制，矩阵有助于评审，使得很容易检验是否已处理所有的需求。当需求变更时，矩阵中包含的信息可用于分析变更带来的影响。它也有助于向顾客验证所开发的软件满足所有需求而且已经得到了充分的测试。 除非正确维护跟踪矩阵，否则它的作用是有限的。由于矩阵的设计方式，它不可能一成不变，而是在生命周期的很多点上需要更新。开始，矩阵只有需求数据。随着开发的进行，其他域的数据不断被加进来。更新矩阵最简单的方式是在相关阶段评审结束后更新它。为了对一个项目的跟踪矩阵进行维护，在工作产品的所有文档中必须使用编号机制。 在矩阵构建后以及矩阵维护期，需要执行一些完整性检查。这里列出一些需要遵循的检查和步骤。根据项目或客户的需要可以很容易地设计出其他检查。 ●浏览矩阵中的需求数目和需求文档中的需求，确保矩阵中列出了所有的需求，没有遗漏。