需求跟踪矩阵

出处不详，欢迎补充！

1.变更影响分析

如果需求正在变更，跟踪链接会帮助我们了解与之相关以及有依赖关系的工件。这样就可以很容易验证这些工件，如果需要还可以对它们进行调整。大大降低了忽略相关工件的概率。

2.覆盖率分析

确保不忽略任何需求。

3.项目状态分析

跟踪项目状态是可能的：分析跟踪数据可以查看需求的完成状态。没有链接或跟踪链不完整的需求（例如，有实现但没有测试的需求）表明需要进一步的工作。缺失的链接显示哪些具体工件缺失，需要实现。

4.产品组件的重用

可以把需求及其关联的工件打包。可以把这样的包可以由不同的产品共用。

5.将关联永久保存下来

通常项目或产品的知识掌握在特定人员的头脑中。通过使用需求追踪，通过可视化不同工件之间的关系来保存这些知识。即使一个人离开了项目，这种知识仍然存在。

6.测试优化

通过链接需求、源代码、测试用例和测试结果，如果测试失败，很容易识别源代码中受影响的部分。此外，可以识别并消除冗余测试用例。

在研发的整个过程中。

纵向跟踪矩阵，包括如下的3种：

• 需求之间的派生关系，客户需求到产品需求

• 实现与验证关系：需求到设计，需求到测试用例等

• 需求的责任分配关系；需求由谁来实现

横向跟踪矩阵：需求之间的接口关系

在SEI的调查中达成的基本共识是：纵向跟踪是必须的。对于纵向跟踪矩阵：
必需的：

• 客户需求与产品需求的跟踪

• 产品需求与测试用例的跟踪

• 100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵

• 全局性需求要建立跟踪矩阵,包括：客户需求-产品需求-设计-编码-测试用例的跟踪矩阵

• 核心需求要建立跟踪矩阵

并非必需的：

• 性能需求可以不建立跟踪矩阵。

• 不影响系统架构的功能需求。

由于在需求跟踪矩阵中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护需求跟踪矩阵的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。

在实践中，为了简化需求跟踪矩阵的建立与维护工作，有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。 如果不借助专门的需求管理工具，一般只能通过EXCEL来维护需求跟踪矩阵，工作量就是比较大。

1. https://en.wikipedia.org/wiki/Requirements_traceability

2. https://baike.baidu.com/item/%E9%9C%80%E6%B1%82%E8%B7%9F%E8%B8%AA%E7%9F%A9%E9%98%B5/6155948?fr=aladdin

3. https://www.softwaretestinghelp.com/requirements-traceability-matrix/