需求跟踪矩阵（Requirement Tracking Matr

1. 什么是TM(Tracking Matrix)

       A Traceability Matrix is a document that co-relates any two-baseline documents that require a many-to-many relationship to check the completeness of the relationship.It is used to track the requirements and to check the current project requirements are met.
       可追溯性矩阵是一个文档，它与需要多对多关系的任何两个基线文档进行关联，以检查关系的完整性。它用于跟踪需求并检查是否满足当前项目需求。

2. 什么是RTM(Requirement Tracking Matrix)

       Requirement Traceability Matrix (RTM) is a document that maps and traces user requirement with test cases. It captures all requirements proposed by the client and requirement traceability in a single document, delivered at the conclusion of the Software devlopement life cycle. The main purpose of Requirement Traceability Matrix is to validate that all requirements are checked via test cases such that no functionality is unchecked during Software testing.

       需求跟踪矩阵（RTM）是用于通过测试用例映射和跟踪用户需求的文档。它在软件部署生命周期结束时提供的单个文档中捕获了客户提出的所有需求和需求可追溯性。需求跟踪矩阵的主要目的是验证是否通过测试用例检查了所有需求，以便在软件测试期间不取消任何功能。

       需求跟踪矩阵，简称RTM；Throughout the project Lifecycle list of project and product deliverables are created and these are developed based on agreed project & product requirements.（在整个项目中，将创建项目和产品可交付成果的生命周期清单，并根据商定的项目和产品需求来开发这些清单）

3. 作用

1. 确保100％的测试覆盖率。
2. 显示需求/文档不一致。
3. 显示整体缺陷/执行状态，重点放在业务需求上。
4. 如果要更改某些业务和/或功能要求，则TM可以通过重新测试/重用测试用例来帮助估计或分析对QA团队工作的影响。

保证了需求到实现的无遗漏和偏离。
* 需要注意的重要一点是，维护和更新需求跟踪矩阵的方式决定了其使用的有效性。如果不经常更新或更新不正确，该工具将成为负担而不是帮助，并给人留下这样的印象：该工具本身不值得使用。

4. 分类

4.1 纵向跟踪矩阵

       Vertical traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.

       “纵向跟踪”是指从其最初的来源（如：客户需求），通过不同层次的工作分解结构得以实现同样的内容，并最终交付给客户的过程。在需求被很好的管理的情况下，跟踪性可以通过从初始需求对应到低级别需求，以及从低级别的需求回溯到其根源来建立。这样的双向可追溯性有助于确定所有初始需求已完全实现，并且所有较低级别的需求可以追溯到一个有效的来源上。包括三种关系：

1. 需求之间的派生关系，客户需求到产品需求。
2. 实现与验证关系：需求到设计，需求到测试用例等。
3. 需求的责任分配关系；需求由谁来实现。

4.2 横向跟踪矩阵

       Horizontal traceability is also important and is mentioned in subpractice 3, but it is not required to satisfy bidirectional traceability. Horizontal traceability identifies the relationships among related items across work groups or product components for the purpose of avoiding potential conflicts. It enables the project to anticipate potential problems (and mitigate or solve them) before integration testing. For example, horizontal traceability would follow related requirements across two work groups working on two associated components of a product. The traceability across these two work groups enables the work groups to see when and how a change in a requirement for one of the components may affect the other component. Thus, horizontal traceability enables the project to anticipate potential problems (and mitigate or solve them) before integration testing.

       "水平跟踪”也是很重要的，在REQM的subpractice 3中提到 ，但它并不是需要满足双向可追溯性的必要条件。“水平跟踪”通过识别相关的工作组、产品组件的关系来避免潜在的冲突。这使项目可以在集成测试之前预计可能出现的问题（并且减轻或解决这些问题）。例如，同一个产品的两个相关部件，由两个工作组根据同一份需求分别负责。当一个组件对应的需求发生改变时，可能会影响到另一个组件。横跨两个组件的需求跟踪就能及时发现、规避或解决这些问题。因此，“水平跟踪”使项目可以在集成测试之前预计可能出现的问题（并且减轻或解决这些问题）。

       主要关注的就是“需求之间的接口关系”。

5. RTM参数

5.1. 基本参数

• Requirement ID（需求编号）
• Requirement Type and Description（需求类型和说明）
• Test Cases with Status（具有状态的测试用例）

例如：

Rep No	Rep Desc	TC ID	Test Status
101	登陆系统	TC01、TC02、TC03	TC01-Pass、TC02-Pass
102	注册账户	TC04、TC05、TC06	TC04-Pass、TC05-Fail、TC06-No Run

5.2. 典型软件开发项目基本参数

Sno	Rep ID	Rep Desc	TC ID	Test Design	Test Designer	UAT Test Rep?	Text Execution			Defects?	Defect ID	Defect Status	Rep Coverage Status
							Test Env	UAT Env	Prod Env
1	Rep01	登陆系统	TC01	Completed	yys	NO	Passed	No Run	No Run	None	None	N/A	Partial
2			TC02	Completed	yys	NO	Passed	No Run	No Run	None	None	N/A	Partial
3			TC03	Completed	yys	Yes	Passed	Passed	No Run	YES	DFCT001	Test OK	Partial

如上所述，需求跟踪矩阵可以:

• 在测试用例数量中显示需求覆盖率
• 特定测试用例的设计状态和执行状态
• 如果用户要做任何用户验收测试，那么 UAT 状态也可以在同一矩阵中捕获。
• 相关的缺陷和当前状态也可以在同一矩阵中提及。

这种矩阵将为所有测试活动提供一站式服务。
除了单独维护一个 excel。测试团队也可以选择需求跟踪可用的测试管理工具。

6. 组成部分

6.1 向前追溯(Forward traceability)

       This matrix is used to check whether the project progresses in the desired direction and for the right product. It makes sure that each requirement is applied to the product and that each requirement is tested thoroughly. It maps requirements to test cases.

       该矩阵用于检查项目是否朝着期望的方向发展，是否为正确的产品发展。它确保每个要求都适用于产品，并且每个要求都经过彻底测试。它将需求映射到测试用例。

6.2 向后追溯(Backward or reverse traceability)

       It is used to ensure whether the current product remains on the right track. The purpose behind this type of traceability is to verify that we are not expanding the scope of the project by adding code, design elements, test or other work that is not specified in the requirements. It maps test cases to requirements.

       用于确保当前产品是否保持在正确的轨道上。这种可追溯性背后的目的是验证我们没有通过添加代码、设计元素、测试或其他需求中未指定的工作来扩大项目范围。它将测试用例映射到需求。

6.3 双向追溯(Bi-directional traceability)

       This traceability matrix ensures that all requirements are covered by test cases. It analyzes the impact of a change in requirements affected by the Defect in a work product and vice versa.

       此可追溯性矩阵确保测试用例涵盖了所有要求。它分析了受工作产品缺陷影响的需求变化的影响，反之亦然。

7. 由谁来创建RTM?

• 需求开发人员负责客户需求到产品需求的RTM建立。
• 测试用例的编写人员负责需求到测试用例的RTM建立。
• 设计人员负责需求到设计的RTM的建立等等。
• PPQA（过程与产品质量保证）负责检查是否建立了RTM，是否所有的需求都被覆盖了。

8. RTM是否纳入基线管理？

       RTM要纳入基线管理。纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。

9. 在实践中，如何把握该建立哪些RTM？

1. 在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则 REQM SP1.4无法通过。横向跟踪如果不作，则是大部分实施。
2. 对于纵向跟踪矩阵：

• 必需的：
  • 客户需求与产品需求的跟踪
  • 产品需求与测试用例的跟踪
  • 100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵
  • 全局性需求要建立跟踪矩阵,包括：客户需求-产品需求-设计-编码-测试用例的跟踪矩阵
  • 核心需求要建立跟踪矩阵
• 并非必需的：
  • 性能需求可以不建立跟踪矩阵
  • 不影响系统架构的功能需求。

10. 如何简化RTM的工作？

       由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RTM的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪。如需求为：r1,r2,……等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：r1-t1,r1-t2等等。

       需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就是比较大。要简化，就要平衡管理的投入与产出，平衡时，可以借鉴上面的在实践中，如何把握该建立哪些RTM？<br />当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样RTM的作用就打了折扣，还是一个平衡问题。

11. RTM示例

11.1. 需求跟踪矩阵

用户需求项标号	用户需求标题	用户需求变更标识	需求列表编号	需求列表功能标题	软件需求变更标识	需求状态	变更序号	当前状态	概要设计状态	对应概要设计章节	详细设计状态	对应详细设计章节	单元测试用例	集成测试用例	系统测试用例	对应代码
B5HIS	医院管理	新增	7.1	病人身份管理	新增	已批准		系统验收
			7.2	挂号管理	原始	已批准		系统验收	修订		评审通过	6.1.2	E1	E5	T3.1	C6.1
			7.3	网上挂号预约管理	新增	已批准		系统验收	修订		评审通过	6.1.3	E2	E6	T3.2	C6.2
			7.4	系统管理	新增	已批准		系统验收	修订		评审通过	6.1.4	E3	E7	T3.3	C6.3
			7.5	费用管理	新增	已批准		系统验收
			7.6	厨房管理	新增	已批准		系统验收	评审通过		评审通过	6.1.5	E4	E8	T3.4	C6.4

11.2. 需求进度管理表

NO.	一级分类/(模块)	二级分类 /(子模块)	三级分类/(功能点)	详细说明	完成情况跟踪							担当者	责任人
					SD	PD	DD	COD	UT	IT	ST
1	客服模块	维修任务	新增维修	新增维修需要设置班主	○	N/A	△	×	×	×	×	张三	王总

○ ：已完成，△ ：进行中，×：未开始，N/A：不适合(没有此项活动)