问题背景：
需求追踪（Traceability）作为一个工具产生，目的是为了防止商业期望与系统实际实现之间的偏差。最初，分析师依赖手动检查和清单，这非常低效。
问题：
缺乏追踪导致不同层级的需求之间失去联系：商业目标 → 功能需求 → 技术需求 → 测试场景。这会导致错误、"丢失"的需求和质量不佳的实现。
解决方案：
需求追踪通过使用矩阵、专业工具（Jama, DOORS, Jira/Zephyr）和模板构建相应链条：
创建追踪矩阵（traceability matrix），其最简单的结构为：
| 商业目标 | 功能需求 | 测试场景 |
|---|---|---|
| BC-1 | FR-1 | TC-1 |
在工具中对工件进行标签化。
在任何级别的更改时，需审查链条 — 必须有联系。
定期进行审核，以发现“悬而未决”的需求或没有与目标关联的测试。
关键特性：
在小项目中可以不使用追踪矩阵吗？
不能，即使是在小项目中，缺乏追踪往往导致需求丢失。
在项目开始时只构建一次追踪是否足够？
不够，随着需求和测试的变化，矩阵需要定期更新。
追踪仅影响测试完成吗？
不，它在所有阶段都很重要 — 从设计到维护，有助于评估变更的影响并计划工作。
负面案例：
在一个项目中没有构建追踪矩阵，测试人员仅依靠规格。一些需求被实现但未经过检查，导致功能在生产环境中工作不正常。
优点：
缺点：
积极案例：
在另一个项目中，保持着活跃的追踪矩阵。所有需求与测试和商业目标相连，任何更改都被追踪。没有未考虑的功能和“未记录”的测试。
优点：
缺点：