需求追溯要解决的是需求、实现与验证三者之间能否相互核对：每条需求都能找到对应的设计、代码或配置项，也能找到验证它的用例和结果。本文按“定义对象与粒度—建立关联—分配角色—示例演示—覆盖检查”的顺序，给出可直接落地的建链方法、责任表和完成清单。文中示例为演示情景，ONES 作为承载需求与用例关联的工作项载体之一在相应环节提及。
要点总览（TL;DR）
- 需求追溯要建的是需求、实现物、验证物三者之间的双向链路：正向回答需求落地到哪里、由什么证明被验证，反向回答代码和用例服务于哪条需求。
- 粒度以需求条目级为主，用例级用于验证侧核对，变更级只在实质变更时启用；文案、探索性需求可豁免，但须标注类型和理由。
- 建链按五步执行：分配唯一标识、定义关系类型与必填字段、评审后建实现关联、用例设计时建验证关联、变更时更新并记录影响。
- 需求负责人、设计/开发负责人、测试负责人、配置管理员分别在需求评审、设计评审、用例评审、发布前检查四个节点承担对应动作与交付物。
- 完成标准是双向覆盖检查通过：非豁免需求实现与验证关联覆盖率100%，孤儿项有处置记录，变更单均有影响记录和复核结论。
需求追溯要建哪条链路：对象、方向与粒度
需求追溯的链路由三个锚点构成：需求条目、实现物、验证物。三者之间建立双向关系后，追溯才具备核对价值。只连需求与用例，无法回答“这条需求改动了哪些代码”；只连需求与代码，无法回答“这条需求是否被验证过”。
正向与反向追溯各自回答的问题
正向追溯从需求出发，沿实现物和验证物向下走，回答“这条需求落地到了哪里、由什么证明它被验证”。反向追溯从实现物或验证物出发，沿关联关系向上走，回答“这段代码、这个用例服务于哪条需求，是否存在无来源的实现或测试”。两个方向共用同一套关联关系，差别在于查询起点和检查目的。日常评审多用正向追溯确认覆盖，发布前检查和清理遗留物多用反向追溯发现孤儿项。
追溯粒度的选择
粒度决定追溯矩阵的规模和维护成本。常见三档选择如下：
| 粒度 | 适用情形 | 过细的代价 | 过粗的代价 |
|---|---|---|---|
| 需求条目级 | 需求已拆到可独立验证的条目，作为默认粒度 | 条目拆得过碎，关联数量膨胀，维护负担上升 | 一条需求覆盖多个功能点，缺口难以定位 |
| 用例级 | 需要确认每条需求至少有一个验证用例 | 一个用例覆盖多条需求时反复挂接，关系冗余 | 只关联到测试计划，无法判断单条需求的验证情况 |
| 变更级 | 需求变更频繁，需要评估每次改动的影响范围 | 每次小改动都建变更记录，记录成本高于收益 | 变更影响靠人工回忆，容易漏掉受影响的用例和实现 |
多数团队以需求条目级为主粒度，用例级用于验证侧核对，变更级只在需求发生实质变更时启用。粒度一旦确定，应在项目内保持一致，避免同一项目里部分需求追到用例、部分只追到模块，导致覆盖率无法横向比较。
可豁免细粒度追溯的需求及记录方式
纯文案调整、界面措辞修改、探索性预研等需求，可以豁免细粒度追溯，但豁免本身要留痕。建议在需求条目上标注豁免类型和理由，由需求负责人确认，并在覆盖检查时单独统计豁免清单，避免豁免成为漏追的默认出口。豁免规则应写进项目的过程定义，而不是每次临时判断。
把上述内容整理成一张定义表，团队在启动追溯前先填完，后续建链就有统一口径：
| 对象类型 | 唯一标识 | 追溯方向 | 粒度 | 豁免规则 |
|---|---|---|---|---|
| 需求条目 | 项目前缀+序号，评审通过后冻结 | 向下关联实现物与验证物 | 条目级 | 文案、探索性需求可豁免，需标注理由 |
| 设计/代码/配置项 | 设计文档编号、代码仓库路径或配置项标识 | 向上关联需求 | 条目级或模块级 | 公共组件可关联到多条需求 |
| 测试用例 | 用例编号 | 向上关联需求，向下关联执行结果 | 用例级 | 回归用例可关联到需求组 |
| 变更记录 | 变更单号 | 关联受影响的需求、实现与用例 | 变更级 | 无实质影响的小改动可不建变更单 |
建立追溯关系的操作步骤
建链可以拆成五步，每步都有明确的输入、动作、输出和完成标志。按顺序执行，能避免“先建关系再补标识”造成的返工。
步骤一：分配稳定唯一标识并冻结编号规则
输入是需求清单和项目编号规范。动作是为每条需求分配唯一标识，编号规则在项目启动时确定并冻结，后续新增需求按序追加，不复用已废弃编号。输出是带唯一标识的需求条目清单。完成标志是所有需求都有标识，且标识在评审、开发、测试各环节被引用时保持一致。
步骤二：定义追溯关系类型与必填字段
输入是追溯对象定义表。动作是明确四类关系：实现关系（需求到设计、代码、配置项）、验证关系（需求到用例与验证记录）、派生关系（需求由上层需求或法规条款派生）、冲突关系（需求之间或需求与实现之间存在矛盾需记录）。每类关系规定必填字段，例如关联人、关联时间、关联依据。输出是追溯关系类型说明。完成标志是团队对四类关系的使用场景没有歧义。
步骤三：需求评审通过后建立实现侧关联
输入是已通过评审的需求条目和设计任务。动作是在设计评审或开发任务拆分时，把设计文档、代码模块或配置项挂接到对应需求上。输出是实现侧关联记录。完成标志是每条非豁免需求至少有一条实现关联，且关联在设计评审记录中可查。
步骤四：用例设计阶段建立验证侧关联
输入是需求条目和用例设计稿。动作是在用例评审时，为每条需求挂接至少一个验证用例，并注明验证方式（功能测试、集成测试、评审确认等）。输出是用例关联记录。完成标志是每条非豁免需求都有验证关联，用例评审记录中能看到需求与用例的对应关系。
步骤五：需求变更时更新关联并记录影响
输入是变更申请和现有追溯关系。动作是沿关联关系找出受影响的设计、代码和用例，更新关联并记录变更影响范围。输出是变更影响记录和更新后的追溯关系。完成标志是变更单关闭时，影响范围内的关联已全部复核，无遗留断链。
把五步压缩成一张流程卡，便于在项目启动会上直接使用：
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、标识 | 需求清单、编号规范 | 分配唯一标识并冻结规则 | 带标识的需求条目 | 标识全环节一致 |
| 二、定义关系 | 追溯对象定义表 | 明确四类关系与必填字段 | 关系类型说明 | 使用场景无歧义 |
| 三、实现关联 | 评审通过的需求 | 挂接设计、代码、配置项 | 实现侧关联记录 | 非豁免需求均有实现关联 |
| 四、验证关联 | 需求条目、用例设计稿 | 挂接验证用例并注明方式 | 用例关联记录 | 非豁免需求均有验证关联 |
| 五、变更更新 | 变更申请、现有关系 | 沿关联分析影响并更新 | 变更影响记录 | 变更关闭时无断链 |
角色分工与各环节交付物
追溯关系无人维护，通常源于职责边界不清。把“谁在哪个节点负责哪段链路”写清楚，比反复强调追溯重要性更有效。
四类角色的职责边界
需求负责人对需求条目的完整性和标识稳定性负责，是追溯链路的起点责任人。设计/开发负责人对实现侧关联的准确性负责，确保设计项和代码模块挂接到正确的需求。测试负责人对验证侧关联和验证结果记录负责，确保用例与需求的对应关系可核对。配置管理员对基线、版本和变更记录的一致性负责，在需求变更时保证关联关系随基线同步更新。
四个节点的动作与交付物
| 节点 | 需求负责人 | 设计/开发负责人 | 测试负责人 | 配置管理员 |
|---|---|---|---|---|
| 需求评审 | 确认标识与粒度，标注豁免 | 评估实现可行性 | 评估可验证性 | 登记需求基线 |
| 设计评审 | 核对实现关联是否完整 | 建立实现侧关联 | 开始设计验证用例 | 记录设计基线 |
| 用例评审 | 确认验证覆盖 | 补充实现关联缺口 | 建立验证侧关联 | 登记用例版本 |
| 发布前检查 | 确认豁免清单 | 确认实现关联无遗漏 | 确认验证结果已记录 | 核对变更影响记录 |
更新责任与交接规则
关联关系的更新遵循“谁改动、谁更新”的原则：需求内容变更由需求负责人发起，实现物变更由开发负责人更新实现关联，用例变更由测试负责人更新验证关联。跨角色交接时，例如需求从需求负责人转给新负责人，应在交接记录中注明关联关系已复核，避免交接后出现无人认领的断链。
交付物清单
四个节点对应四类交付物：需求条目（含唯一标识和豁免标注）、追溯矩阵（需求与实现、验证的对应关系）、用例关联记录（含验证方式和执行结果）、变更影响记录（含受影响对象和复核结论）。这四类交付物构成发布前检查的证据基础。
当需求、开发任务、测试用例和变更记录放在同一工作项体系中管理时，关联关系可以随工作项状态流转而保留。ONES 的 ALM 方案以数字线程连接需求、开发、测试、变更与发布，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪依据；其测试发布场景也支持把测试用例、缺陷、版本和发布过程关联到需求链路中。这类承载方式适合希望减少跨工具手工同步的团队，具体关联字段和操作路径需结合实际部署确认。
示例：一条需求从提出到验证的追溯记录
以下为演示情景，用于说明链路如何串起来，不代表真实客户案例。
需求条目与初始关联
某项目提出需求“登录失败连续五次后锁定账户十分钟”，标识为 REQ-0142，粒度定为条目级，未豁免。需求评审通过后，开发负责人在设计文档《账户安全设计》中标注对应章节，并将代码模块 auth-lock 挂接到 REQ-0142，建立实现关联。测试负责人在用例评审时挂接用例 TC-0311（连续失败锁定）和 TC-0312（锁定到期解锁），建立验证关联，验证方式为功能测试。
一次变更后的回溯与更新
项目中期，安全团队要求把锁定时间从十分钟调整为三十分钟。变更单 CR-0087 发起后，需求负责人沿关联关系回溯：实现侧找到 auth-lock 模块和设计文档对应章节，验证侧找到 TC-0311 和 TC-0312。开发负责人更新设计文档和代码，测试负责人更新 TC-0312 的预期结果并补充一条边界用例 TC-0313（锁定期间重复登录）。变更影响记录中登记受影响对象为设计文档、auth-lock 模块、TC-0312、TC-0313，复核结论为关联已更新、无遗漏。
字段与状态变化
| 字段 | 变更前 | 变更后 |
|---|---|---|
| 需求状态 | 已评审 | 变更中→已评审 |
| 实现关联 | 设计文档第4章、auth-lock | 设计文档第4章（已更新）、auth-lock（已更新） |
| 验证关联 | TC-0311、TC-0312 | TC-0311、TC-0312（预期结果已更新）、TC-0313（新增） |
| 变更记录 | 无 | CR-0087，影响对象4项，复核通过 |
这个示例的关键在于：变更不是只改需求文本，而是沿已有链路逐项复核实现和验证，更新后再关闭变更单。链路在变更前已建好，变更时才有一张可回溯的关系网可用。
覆盖检查与完成标准
链路建完后，需要用检查判断它是否真的可用。检查分两个方向、三类缺口，并给出可量化的完成标准。
双向覆盖检查
正向检查看三类问题：无实现的需求（需求存在但没有挂接任何设计、代码或配置项）、无验证的需求（需求存在但没有挂接用例或验证记录）、验证未通过的需求（有用例但执行结果缺失或失败未处理）。反向检查看两类问题：无需求来源的实现（代码或设计项找不到对应需求）、无需求来源的用例（用例找不到对应需求，可能是遗留或重复）。检查结果按缺口类型分别统计，而不是只报一个总数。
追溯矩阵抽查方法与抽样比例
全量核对成本高时，可采用抽查。建议按需求条目随机抽取不低于20%的样本，覆盖不同模块和不同优先级；对高风险模块（安全、支付、合规相关）提高至50%以上或全量核对。抽查时沿正向和反向各走一遍，确认关联关系在两侧都能查到。抽查发现断链的，应扩大到该模块全量复核。
变更影响分析的可完成性
判断标准是：一次需求变更的影响分析能否在一轮内完成。如果沿关联关系能直接列出受影响的设计、代码和用例，说明链路可用；如果需要靠人工逐个询问开发或测试才能确定影响范围，说明关联关系存在缺口，应先补链再谈覆盖。
完成标准与常见缺口处置
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 需求实现覆盖 | 非豁免需求实现关联覆盖率100% | 存在无实现关联的非豁免需求 |
| 需求验证覆盖 | 非豁免需求验证关联覆盖率100%，验证结果已记录 | 存在无验证关联或验证结果缺失的需求 |
| 反向来源检查 | 孤儿实现、孤儿用例均有处置记录 | 存在未处置的孤儿项 |
| 变更影响记录 | 每个变更单均有影响记录和复核结论 | 变更单关闭但无影响记录 |
| 豁免清单 | 豁免需求均有类型和理由标注 | 存在无理由的豁免 |
常见缺口的处置方式：孤儿需求先确认是否漏建实现或验证关联，补建后复核；孤儿用例确认是否对应已废弃需求，对应则标注废弃并保留记录，不对应则补充需求来源或归档；断链变更回到变更单，沿原关联关系补齐受影响对象并更新记录。所有缺口处置完成后，由需求负责人和测试负责人共同确认，追溯链路才可视为建成并交付。
常见问题
需求条目拆得很细时，追溯关系数量膨胀怎么控制？
先检查拆分本身是否合理：需求条目应拆到可独立验证的程度，拆到界面元素或单个字段往往过细。若条目确实需要细拆，可把关联建在需求组或特性层级，组内条目共用实现关联，验证侧仍按条目挂接用例。另一种做法是对低风险模块采用模块级实现关联，对安全、支付、合规相关模块保持条目级，用风险分级控制维护成本。粒度调整后应在项目内统一口径，避免同一项目混用不同粒度导致覆盖率无法横向比较。
需求变更频繁时，每次都要走完整的五步更新吗？
不需要。步骤五的更新范围取决于变更是否影响实现或验证。纯文案、措辞类变更只需更新需求条目本身，在变更记录中注明无实现与验证影响即可；涉及行为、规则、边界条件变化的变更，才需要沿关联关系复核实现物和用例。判断依据可以写进变更单：变更是否改变可观察的系统行为。若改变，则逐项复核关联；若不改变，记录判断理由后关闭。这样既保证链路准确，也避免小改动带来过重的记录负担。
追溯链路建在文档表格里和建在工作项系统里，怎么选？
取决于变更频率和协作人数。需求少、变更少、参与角色单一的项目，用表格维护追溯矩阵即可，成本低、上手快。需求量大、跨角色协作、变更频繁的项目，表格容易与实际情况脱节，更适合把需求、开发任务、测试用例和变更记录放在同一工作项体系中，让关联关系随状态流转保留。ONES 的 ALM 方案以数字线程连接需求、开发、测试、变更与发布，需求变化时可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪依据；具体关联字段和操作路径需结合实际部署确认。无论选哪种载体，对象定义、关系类型和完成标准都应先确定。
反向追溯发现大量孤儿用例，应该怎么处理？
先分类再处置，不要直接删除。第一类是对应已废弃需求的用例，标注废弃并保留记录，便于后续审计追溯；第二类是对应现有需求但漏建关联的用例，补建关联后复核；第三类是无对应需求的探索性或回归用例，可归入需求组或建立独立的需求来源说明。处置完成后统计各类数量，若孤儿用例集中在某个模块，说明该模块的建链流程执行不到位，应回到用例评审节点检查关联是否被跳过。孤儿项全部有处置结论，才算通过反向检查。
豁免细粒度追溯的需求，发布前还需要检查什么？
豁免的是细粒度关联，不是检查本身。发布前应核对豁免清单：每条豁免需求是否标注了豁免类型和理由，是否经需求负责人确认，豁免理由是否仍成立。若某条需求在开发过程中从文案调整演变为功能改动，应取消豁免并补建关联。豁免清单建议在发布前检查中单独列一项，由需求负责人确认、测试负责人复核，避免豁免成为漏追的默认出口。
