2.5 需求跟踪矩阵 REQUIREMENTS_TRACEABILITY_MATRIX

REQUIREMENTS TRACEABILITY MATRIX Project Title: Date Prepared:

Page 1 of 1

需求跟踪矩阵(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需求跟踪矩阵的维护和使用 跟踪矩阵有助于在各个生命周期阶段跟踪所有需求，以此来确保实现所有已并入的需求，这也避免了由于遗漏需求而进行的重复劳动。通过为评审专家提供一套机制，矩阵有助于评审，使得很容易检验是否已处理所有的需求。当需求变更时，矩阵中包含的信息可用于分析变更带来的影响。它也有助于向顾客验证所开发的软件满足所有需求而且已经得到了充分的测试。 除非正确维护跟踪矩阵，否则它的作用是有限的。由于矩阵的设计方式，它不可能一成不变，而是在生命周期的很多点上需要更新。开始，矩阵只有需求数据。随着开发的进行，其他域的数据不断被加进来。更新矩阵最简单的方式是在相关阶段评审结束后更新它。为了对一个项目的跟踪矩阵进行维护，在工作产品的所有文档中必须使用编号机制。 在矩阵构建后以及矩阵维护期，需要执行一些完整性检查。这里列出一些需要遵循的检查和步骤。根据项目或客户的需要可以很容易地设计出其他检查。 ●浏览矩阵中的需求数目和需求文档中的需求，确保矩阵中列出了所有的需求，没有遗漏。

需求跟踪

需求跟踪

修订历史记录 日期版本说明作者2007年8月<1.0> 第1次发布Louis

1 目的 将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发。 2角色流程图 3 启动准则 ●需求文档已经通过正式评审并获得了承诺。 ●系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例部分或全部已经产 生。 4 输入 ●需求文档 ●设计文档、代码、测试用例等 5 主要活动 [Activity1] 初始化跟踪需求矩阵 ●在需求确认之后，需求分析工程师应根据项目的需求规则说明书初始化需求跟踪矩阵中“需

求文档“的部分，同时通知项目组成员及相关人员。 注：具体需求跟踪矩阵格式请参见《需求跟踪报告》模板。 ●需求跟踪矩阵中“设计文档”部分的需求跟踪的初始化工作应在程序员完成详细设计后完 成初始化工作。 ●需求跟踪矩阵中“代码”部分的需求跟踪的初始化工作应在系统编码人员在完成相应的需 求功能的编码工作后完成初始化工作。 ●需求跟踪矩阵中“测试用例”部分的需求跟踪的初始化工作应在《需求规格说明书》已撰 写完成并通过确认后，系统测试之前完成。 [Activity2] 更新需求矩阵 ●项目成员在提交任务时，如果所完成的工作成果与需求跟踪矩阵的内容相关，应提交工作 产品前更新需求跟踪矩阵的相关内容。 ●在需求发生变化后，由需求文档的矩阵更新负责人先更新需求跟踪矩阵，同时通知相关的 矩阵更新负责人，在各负责人完成相应设计、代码、测试用例等的变更后，更新需求跟踪矩阵。 [Activity3] 跟踪需求矩阵 ●对于需求跟踪矩阵中“需求文档”部分的跟踪，将放在需求走查及审查评审时，对与评审 的需求文档相关的需求跟踪矩阵部分进行走查和审查评审，并将发现的缺陷及问题记录到评审报告中。 ●对于需求跟踪矩阵中“设计文档”部分的跟踪，将放在详细设计走查评审时对与评审的设 计文档相关的需求跟踪矩阵部分中进行走查评审，并将发现的缺陷及问题记录到评审报告中。 ●对于需求跟踪矩阵中“代码”部分的跟踪，将放在代码走查时对与走查相关的需求跟踪矩 阵部分进行走查评审，并将发现的缺陷及问题记录到评审报告中。 ●对于需求跟踪矩阵中“测试用例”部分的跟踪，将放在系统测试开始前对系统测试用例进 行审查评审，并将发现的缺陷及问题记录到评审报告中。 ●跟踪需求矩阵的方法有以下几种： ?正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。 ?逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。 ?正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需