需求追踪矩阵是什么
需求追踪矩阵把需求与设计、代码、测试用例双向关联起来，用来回答三件事：每条需求是否有人实现、是否被验证、改动会影响哪些模块。它也是审计场景的必需证据，例如 ISO 9001、CMMI 以及医疗、汽车行业合规。形式上通常是一张需求 ID 与工作项、用例、测试用例的对照表，关键是双向可查而非单面清单。
基本信息
| 正向追踪 | 需求 → 设计 → 代码 → 测试用例 |
|---|---|
| 反向追踪 | 测试与代码 → 需求，用来发现无来源的工作项 |
| 标识规则 | 需求条目唯一 ID，全生命周期不变 |
| 常见载体 | 需求管理工具，或配置管理下的表格 |
| 更新时机 | 需求变更、评审通过、测试用例增删 |
追踪方向
| 链路 | 回答的问题 | 失效表现 |
|---|---|---|
| 需求 → 设计/代码 | 每条需求是否都有实现载体 | 出现无人认领的需求 |
| 需求 → 测试 | 每条需求是否都被验证 | 上线后才暴露漏测 |
| 变更 → 影响面 | 改一条需求要动哪些模块与用例 | 漏改下游，回归范围靠拍脑袋 |
| 测试 → 需求 | 是否存在无来源的测试 | 测试对不上需求，或需求被悄悄丢掉 |
典型使用场景
- 合规审计：需要证明每条需求都已被设计与测试覆盖
- 变更影响分析：修改需求前先看清波及的模块与用例
- 覆盖度体检：用反向追踪找出既无实现也无测试的孤儿需求
- 验收准备：把需求、验收标准与测试用例逐条对应
- 外包交付验收：以矩阵作为交付物完整性的依据
为什么要双向
只做正向追踪只能证明需求被实现了，无法发现凭空出现的代码与测试。反向追踪从测试和提交记录回查需求来源，能暴露无人认领的功能，以及已经被悄悄丢弃的需求。两个方向都做，矩阵才具备覆盖度体检的价值，否则只是一份为了交付而填的表格。
追踪矩阵靠人工维护极易过期，应尽量由需求工具、提交信息（提交说明里带需求 ID）与自动化用例自动关联生成，人工只维护例外项。