需求双向追溯要解决的是“每条需求最后落到哪里、每个实现和验证结果又来自哪条需求”这两个方向都能查清的问题。正向链路从需求出发，经设计、任务、代码或配置项落到验证用例；反向链路从用例、缺陷或变更出发，能回到它覆盖的需求和上游来源。本文按对象与粒度、建链步骤、角色分工、示例和完成检查五部分展开，范围限定在链路建立本身，测试充分性判断和跨生命周期治理分别归入测试覆盖与需求验证、ALM治理主题。
要点总览（TL;DR）
- 先按需求条目追溯，把需求拆到可独立验证的最小单元，再为需求、设计、任务或配置项、用例、缺陷与变更分配唯一标识。
- 正向建链在需求拆解和用例设计时同步完成，反向建链要求用例与缺陷回填所覆盖的需求标识，变更时由需求负责人标记受影响对象并复核关联。
- 需求负责人、开发负责人、测试负责人各自填写所产生对象的上游关联，质量角色在需求评审、开发完成、测试执行三个时点抽样复核并签字。
- 用正向覆盖率、反向覆盖率和断链清单判断追溯是否可用，断链清单按无实现、无用例、无来源三类缺口分派关闭。
- 链路可由工作项关联和状态流转承载，覆盖率与断链清单从关联数据导出，减少离线表格的人工核对。
先定追溯对象与粒度：哪些需求、哪些实现、哪些验证
追溯体系的第一步是划定对象清单。对象选多了，维护成本会压垮执行；选少了，链路会在关键环节断开。对多数研发团队，一条完整的追溯链需要覆盖五类对象：需求条目、设计或方案、开发任务或配置项、验证用例、缺陷与变更。这五类对象分别承担“提出什么”“打算怎么做”“实际做了什么”“怎么证明做对了”“哪里出了问题或要改什么”的角色，缺任何一类都会让链路在某一段失去落点。
粒度规则决定追溯矩阵是否可维护。按整份需求文档追溯，一条文档对应几十个任务和上百条用例，关联关系会变成一团无法核对的关系网。可行的做法是按需求条目追溯，并把需求拆到可独立验证的最小单元：一条需求条目应当能用一组明确的用例判定通过或不通过。拆得过细同样有代价，一条需求拆成十几个子项会让关联工作量成倍上升，通常以“一个子项对应一个可交付的实现单元和一组验证用例”为宜。
分层策略让不同层级各司其职。业务需求描述业务目标，子需求描述系统或模块级能力，实现项对应任务、代码提交或配置项，用例对应验证活动。上层需求通过子需求向下分解，子需求与实现项、用例建立直接关联。这样既保留了业务视角的完整链路，也避免每条业务需求直接挂几十个底层任务。
下表给出可直接套用的对象与粒度定义，团队可按项目实际调整负责人列。
| 对象 | 层级 | 唯一标识示例 | 粒度规则 | 负责人 |
|---|---|---|---|---|
| 业务需求 | L1 | BR-001 | 一个业务目标一条，不拆分到功能细节 | 需求负责人 |
| 子需求 | L2 | SR-001-02 | 可独立验收的系统或模块能力 | 需求负责人 |
| 设计或方案 | L2 | DS-001-02 | 对应一条子需求的设计说明或技术方案 | 设计或开发负责人 |
| 开发任务或配置项 | L3 | TK-1024 / CFG-07 | 一个可交付的实现单元，能定位到代码或配置 | 开发负责人 |
| 验证用例 | L3 | TC-2048 | 可独立执行并给出通过/不通过结论 | 测试负责人 |
| 缺陷与变更 | L3 | BUG-315 / CR-022 | 一次问题或一次变更请求一条 | 提出人及对应模块负责人 |
需要明确本文边界：用例是否覆盖了足够的场景、覆盖率多高才算测试充分，属于测试覆盖与需求验证的评估范畴；需求、设计、测试、发布在全生命周期如何治理，属于ALM治理的范畴。本文只回答链路如何建立、如何维护、如何判断链路本身是否完整。
核心操作步骤：建立正向与反向两条链路
建链可以按四个步骤推进，每一步都应有明确的输入、动作、输出和完成标志。完成标志的作用是让“做完了”有可核对的依据，避免建链停留在口头约定。
步骤一：分配唯一标识与版本规则
输入是S1确定的对象清单和现有需求文档。动作是为每类对象设定编号前缀和流水号规则，并规定版本变更方式：需求条目修改后版本号递增，旧版本保留可查；标识一经分配不复用，需求作废时标记状态而非删除编号。输出是一份编号规则说明和已编号的对象清单。完成标志是所有在途需求、任务、用例都已获得唯一标识，且编号规则在团队内可查。
步骤二：正向建链——需求拆解时同步生成关联
输入是已编号的子需求和设计评审结论。动作是在需求拆解环节同步创建实现项和用例的关联：每条子需求拆出实现任务时，在任务上填写所属需求标识；测试负责人依据子需求编写用例时，在用例上回填覆盖的需求标识。关联在拆解和用例设计时一次建立，比事后集中补录更准确。输出是带有需求标识的任务清单和用例清单。完成标志是每条进入开发阶段的子需求都至少有一个实现项和一条用例与之关联。
步骤三：反向建链——用例与缺陷回填来源
输入是用例执行记录和缺陷单。动作是要求用例在执行前确认其覆盖的需求标识完整，缺陷单在提交时填写关联的需求或用例标识；由缺陷引发的需求调整，在需求条目上记录来源缺陷编号。输出是可反向查询的用例库和缺陷记录。完成标志是随机抽取的用例和缺陷都能在系统中追溯到对应的需求条目，追溯路径不超过两次跳转。
步骤四：变更时维护链路
输入是需求变更请求。动作是变更评审通过后，由需求负责人标记受影响的下游实现项和用例，通知对应负责人复核关联是否仍然成立；实现项调整后更新任务关联，用例失效则修订或新增用例并更新覆盖关系。输出是变更影响记录和更新后的追溯矩阵。完成标志是变更关闭时，受影响链路上的每个对象都已确认“仍然适用”或“已更新”，没有悬空的旧关联。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、标识与版本 | 对象清单、现有需求文档 | 设定编号前缀、流水号与版本规则 | 编号规则说明、已编号对象清单 | 在途对象全部有唯一标识 |
| 二、正向建链 | 已编号子需求、设计评审结论 | 拆解时同步关联实现项与用例 | 带需求标识的任务与用例清单 | 每条子需求至少一个实现项和一条用例 |
| 三、反向建链 | 用例执行记录、缺陷单 | 用例与缺陷回填需求标识 | 可反向查询的用例库与缺陷记录 | 抽样对象两次跳转内可回到需求 |
| 四、变更维护 | 需求变更请求 | 标记受影响对象并复核关联 | 变更影响记录、更新后的追溯矩阵 | 变更关闭时无悬空旧关联 |
角色分工与交付物：谁建链、谁复核、谁签字
建链动作分散在需求、开发、测试三个职能中，如果不把动作落到角色和时点，追溯矩阵很快会变成只有质量人员维护的台账。可行的分工是：谁产生对象，谁负责填写该对象的上游关联；谁批准阶段交付，谁负责复核该阶段的链路完整性。
需求负责人在需求评审时点承担两项动作：确认需求条目已按粒度规则拆分并分配标识，确认每条子需求在评审结论中明确了验收方式。开发负责人在开发完成时点确认实现任务已关联所属需求，代码或配置项变更时同步更新关联。测试负责人在用例设计完成和测试执行两个时点分别确认用例覆盖的需求标识完整、执行结果已回填。评审或质量角色在三个时点做抽样复核并签字，签字对象是当阶段的追溯矩阵和断链清单，而非单个关联记录。
| 角色 | 需求评审时点 | 开发完成时点 | 测试执行时点 | 主要交付物 |
|---|---|---|---|---|
| 需求负责人 | 确认拆分粒度与标识，明确验收方式 | 响应实现侧提出的需求疑问，确认关联 | 核对缺陷是否回指需求 | 需求条目清单、变更影响记录 |
| 设计或开发负责人 | 确认设计方案对应子需求 | 确认任务与代码/配置项已关联需求 | 配合定位缺陷对应的实现项 | 实现项关联记录 |
| 测试负责人 | 参与评审，识别可验证性 | 依据需求编写并关联用例 | 回填执行结果，提交缺陷并关联来源 | 用例库、缺陷关联记录 |
| 评审或质量角色 | 抽样复核链路完整性并签字 | 复核实现项关联并签字 | 复核反向链路并签字 | 追溯矩阵、断链清单、签字记录 |
复核节奏建议与阶段评审绑定，而不是另设独立会议：需求评审、开发完成、测试执行三个节点各做一次链路检查，检查结果随阶段交付物一并归档。签字确认采用“矩阵版本号+签字人+日期”的方式记录，便于后续变更时判断哪一版矩阵经过确认。
示例：一条需求从提出到验证的完整追溯记录
以下为演示情景，用于说明链路形态，不代表任何真实项目数据。某系统提出业务需求BR-001“支持订单批量导出”，拆解出子需求SR-001-01“导出任务创建”和SR-001-02“导出文件生成”。设计文档DS-001-01对应前者，开发任务TK-1024、TK-1025分别实现任务创建接口和异步队列，测试用例TC-2048验证创建成功场景、TC-2049验证并发上限。正向记录为：BR-001 → SR-001-01 → DS-001-01 → TK-1024/TK-1025 → TC-2048/TC-2049。反向记录写在用例和缺陷上：TC-2048覆盖SR-001-01，执行中发现的BUG-315回指SR-001-01和TK-1025。
变更发生时链路会被打断。假设评审后SR-001-01增加“导出任务可取消”的要求，变更请求CR-022通过。此时TK-1024的实现范围需要扩展，原TC-2048未覆盖取消场景，形成“有用例但覆盖不全”的缺口；同时新增任务TK-1030没有关联任何用例，形成“有实现无用例”的断链。修复过程是：需求负责人在CR-022上记录受影响对象清单，开发负责人更新TK-1024关联并创建TK-1030，测试负责人新增TC-2051覆盖取消场景并回填SR-001-01，质量角色在变更关闭评审中核对断链清单归零后签字。
从这个示例可以迁移的规律有三条：变更影响记录要列出受影响对象而不是只写变更描述；新增实现项必须同步触发用例补充，否则断链会在下一个检查点才暴露；反向关联写在用例和缺陷上，比集中维护一张大矩阵更容易在变更时定位缺口。适用边界是链路只覆盖到验证用例层面，用例本身的场景充分性仍需按测试覆盖方法单独评估。
完成检查：用覆盖率和断链清单判断追溯是否可用
追溯是否可用，可以用两个覆盖率和一张断链清单来判断。正向覆盖率指在检查范围内，已关联至少一个实现项和一条用例的需求条目占比；反向覆盖率指能回溯到需求条目的用例和缺陷占比。两个口径都应写明统计范围和统计时点，例如“本迭代进入开发阶段的需求条目”或“本季度提交的缺陷”，避免不同版本的数字无法比较。
断链清单按三类缺口归集：无实现（需求条目没有关联任何实现项）、无用例（实现项或子需求没有关联验证用例）、无来源（用例或缺陷无法回溯到需求）。三类缺口的处置动作不同：无实现的需求需要确认是否尚未排期或拆分遗漏；无用例的实现项需要测试负责人补充用例或说明豁免理由；无来源的记录需要补填关联或标记为探索性测试等例外并留痕。
| 检查项 | 口径 | 检查时点 | 责任人 | 不通过时处置 |
|---|---|---|---|---|
| 正向覆盖率 | 已关联实现项和用例的需求条目 / 检查范围内需求条目 | 开发完成、测试执行 | 需求负责人统计，质量角色复核 | 补齐关联或说明未排期原因 |
| 反向覆盖率 | 可回溯到需求的用例与缺陷 / 检查范围内用例与缺陷 | 测试执行、版本发布前 | 测试负责人统计，质量角色复核 | 补填来源或登记例外 |
| 断链清单 | 无实现、无用例、无来源三类缺口逐条列出 | 每次阶段评审 | 质量角色汇总 | 按缺口类型分派并限期关闭 |
| 变更影响记录 | 变更关闭时受影响对象均已确认 | 变更关闭评审 | 需求负责人 | 未确认对象不得关闭变更 |
检查结果应作为阶段放行的阻断项之一：断链清单中属于本次范围且无豁免说明的条目未清零，阶段评审不予通过。豁免需要记录理由和有效期，避免“暂时豁免”变成永久缺口。
工具层面，链路需要由工作项之间的关联关系承载，而不是靠离线表格维护。在ONES中，可以用工作项关联把需求、任务、用例和缺陷连接起来，用需求状态流转记录需求从评审到验证的推进过程，变更时保留历史记录，使正向查询和反向回溯都能在系统内完成。这样覆盖率统计和断链清单可以直接从关联数据中导出，减少人工核对的工作量。工具承载的是关联和记录，链路是否完整仍取决于前述的粒度规则、角色分工和检查节奏是否被执行。
常见问题
需求条目拆到多细才适合做追溯？
判断标准是可独立验证：一条需求条目应当能用一组明确的用例判定通过或不通过。拆得过粗，一条需求对应几十个任务和上百条用例，关联关系难以核对；拆得过细，关联工作量成倍上升。通常以“一个子项对应一个可交付的实现单元和一组验证用例”为宜，业务需求层保持一个业务目标一条，不拆到功能细节。
需求变更后，已经建立的追溯链路应该怎么处理？
变更评审通过后，由需求负责人列出受影响的下游实现项和用例，通知对应负责人逐项复核关联是否仍然成立。实现项调整后更新任务关联，用例失效则修订或新增用例并更新覆盖关系。变更关闭时，受影响链路上的每个对象都应确认“仍然适用”或“已更新”，存在悬空旧关联的变更不关闭。
探索性测试或临时验证没有对应需求，反向覆盖率怎么算？
这类记录可以作为例外登记，而不是直接计入缺口。做法是在断链清单中标记为探索性测试等例外类型，记录理由和有效期，由质量角色复核。反向覆盖率统计时写明口径，例如“可回溯到需求的用例与缺陷占检查范围内用例与缺陷的比例”，例外记录单独列示，避免“暂时豁免”长期沉淀为永久缺口。
追溯矩阵用离线表格维护可以吗？
小范围试点阶段可以用表格起步，但进入多迭代并行后，表格需要人工同步需求、任务、用例和缺陷四类对象的变化，容易与实际情况脱节。更稳妥的方式是让关联关系随工作项本身维护，在系统中建立需求、任务、用例和缺陷之间的关联，覆盖率统计和断链清单从关联数据导出。无论用哪种载体，粒度规则、角色分工和检查节奏仍需单独落实。
断链清单里的缺口一直关不掉，阶段评审要不要放行？
建议把断链清单作为阶段放行的阻断项：属于本次范围且无豁免说明的缺口未清零，阶段评审不予通过。确实无法在当期关闭的，按缺口类型分派责任人并登记豁免理由和有效期，由质量角色跟踪到期复核。这样既保留放行的弹性，也让缺口有明确的关闭路径。
