需求追溯断链，指的是需求与下游的设计、开发任务、代码提交、测试用例和验证结果之间出现缺失或失效的关联，导致无法从需求追到实现与验证，也无法从缺陷反查需求。处置时先界定断在哪一段、影响哪些决策，再按四类原因假设逐项取证，分批补齐关联并修复流程卡点，最后用双向抽样和门禁规则确认恢复、防止复发。
要点总览（TL;DR）
- 先把“追溯断了”拆成具体断点：需求无下游任务、任务无需求来源、用例未关联需求、缺陷无法反查需求、追溯矩阵出现空行，并按影响发布评审、影响变更分析、仅影响报表分级。
- 断链原因按四类假设取证：关联从未建立、关联曾存在但失效、流程绕过、迁移或字段变更丢失；证据不足时先小范围验证，不把猜测当结论。
- 处置顺序是先修高频断点、再补历史存量、最后改流程规则；批量补齐前导出关联数据并明确回滚方式，无法确认归属的需求标注待确认。
- 恢复验证要同时做正向追溯（需求→用例→验证结果）和反向追溯（缺陷→需求），以双向可追溯、矩阵无空行、可支撑发布评审为通过标准。
- 防复发靠关联字段必填、变更联动提示和按迭代节奏的断链巡检，并记录待人工确认的残余风险。
断链出现在哪一段：症状与影响范围界定
“追溯断了”是一个笼统感受，处置前要把它拆成可核查的具体断点。断链在系统中通常表现为几种固定形态：需求条目下没有任何下游任务；开发任务没有需求来源字段；测试用例与需求之间没有关联；缺陷记录无法回填到对应需求；追溯矩阵中某些需求行在下游列上出现空行。这些症状指向的断点位置不同，处置优先级也不同。
按链路分段定位，可以把追溯链路拆成五段：需求→设计/任务、任务→开发提交、开发提交→测试用例、测试用例→验证结果、缺陷→需求。逐段核对时，对每一段问两个问题：这一段是否存在关联记录，关联记录是否指向正确的对象。前者查“有没有”，后者查“对不对”，两类问题的修复动作不同。
影响范围决定处置顺序。可以用下表做初步分级：
| 影响级别 | 判断依据 | 处置优先级 |
|---|---|---|
| 影响发布评审 | 发布范围内的需求无法证明已被用例覆盖和验证 | 最高，发布前必须补齐 |
| 影响变更影响分析 | 需求变更时无法定位受影响的任务、用例和缺陷 | 高，变更启动前补齐 |
| 仅影响报表展示 | 追溯矩阵或覆盖率报表出现空行，但评审和变更可人工兜底 | 中，按批次补 |
界定范围时还要划清一条边界：追溯断链处理的是“关联是否存在、是否正确”，测试是否充分、用例设计是否覆盖业务场景属于测试覆盖评估的问题。两者可能同时出现，但混在一起处理会让断链清单失焦。本次处置的产出应是一份断点清单，写明断在哪一段、涉及多少条需求、影响哪类决策，作为后续取证和补齐的输入。
四类原因假设与排除证据
断链原因不能凭印象下结论。比较稳妥的做法是先列出假设，再为每个假设找可验证的证据，把“证据支持”和“尚未排除”分开记录。常见的原因可以归为四类。
假设一：关联从未建立
流程中没有要求填写关联字段，或填写靠自觉，导致任务创建、用例编写时跳过了关联步骤。取证方式是抽查断链需求的创建记录和任务创建表单，看关联字段是否为必填、历史任务中该字段的填写比例。如果大量任务在同一时期集中缺失关联，且表单当时没有校验，这一假设通常成立。
假设二：关联曾存在但失效
需求拆分、任务重派、用例重构之后，原有链接没有同步更新，指向了已废弃的对象或错误的需求。取证方式是查看需求的历史版本、任务的流转记录和用例的修改记录，确认关联对象是否在某个时间点被替换或删除。这类断链的特征是“曾经有、现在指向错”，与从未建立不同。
假设三：流程绕过
部分工作通过线下沟通、即时消息或外部表格承接，结果没有回写系统。取证方式是抽样访谈执行人员，比对系统记录与实际交付物，查看是否存在系统外流转的任务或验证记录。这类断链往往集中在特定团队或特定项目阶段。
假设四：工具迁移或字段变更导致关联丢失
系统迁移、字段结构调整、项目模板更换后，历史关联没有完整带入。取证方式是查阅迁移记录和字段变更记录，比对迁移前后的关联数量，抽取迁移前的导出数据核对。这类断链通常表现为某个时间点之前的数据大面积缺失，边界清晰。
| 原因假设 | 取证材料 | 典型特征 |
|---|---|---|
| 关联从未建立 | 表单配置、字段填写比例、创建记录 | 同一时期集中缺失，表单无校验 |
| 关联曾存在但失效 | 历史版本、流转记录、修改记录 | 有记录但指向废弃或错误对象 |
| 流程绕过 | 抽样访谈、系统外交付物比对 | 集中在特定团队或阶段 |
| 迁移或字段变更丢失 | 迁移记录、字段变更记录、迁移前导出数据 | 某时间点之前数据大面积缺失 |
取证不足时，不要急于把某个假设写成结论。可以先按最可能的假设做小范围验证：选十条左右断链需求，按假设对应的方式补一次关联，观察补齐后是否与现有流程冲突、是否还有新的断点暴露。小范围验证的结论再决定是否推广到全量处置。
按断点类型补齐关联并修复流程卡点
处置顺序建议是先修高频断点、再补历史存量、最后改流程规则。高频断点影响当前在研项目，优先处理可以尽快恢复发布评审和变更分析的可用性；历史存量按批次补，避免一次性大批量操作带来风险；流程规则放在最后，是因为规则要基于前面取证得到的真实断点类型来设计。
补齐关联的具体动作
补齐要顺着链路方向做，避免重复劳动：
- 从需求侧补下游：为无下游任务的需求创建或挂接对应任务，为无用例的需求补建用例关联。
- 从用例侧反挂需求：对已存在但未关联需求的用例，回填需求来源，适用于用例先行编写的团队。
- 从缺陷侧回填需求来源：对无法反查需求的缺陷，补充其对应的需求或任务，恢复反向追溯能力。
在需求、任务、用例、缺陷之间维护关联并生成追溯视图，是这类处置的常见承载方式。以 ONES 为例，需求工作项可以与任务、测试用例、缺陷建立关联，追溯矩阵按需求维度展示下游覆盖情况，处置时可以直接从矩阵的空行定位断点，补齐后在视图中复核。具体字段配置和视图形态以团队实际使用为准。
批量操作的风险边界
批量补齐关联属于破坏性较低但影响面大的操作，执行前要守住几条边界：
- 先备份或导出当前关联数据，明确回滚方式，确认导出内容包含关联双方的对象标识。
- 分批执行，每批完成后抽样核对，确认没有把关联挂到错误对象上。
- 对无法确认归属的历史需求，标注“待确认”并记录原因，不要为了消灭空行强行挂接。错误的关联比缺失的关联更难排查。
流程卡点修复
补齐之后要在关键节点设置校验，让新产生的数据不再断链：需求评审时确认下游任务已规划；任务创建时关联字段必填；用例编写时要求挂接需求；发布评审时以追溯矩阵作为影响范围判断依据。卡点设置要结合团队实际流程，校验过严会推动人员绕过系统，反而制造新的断链。
验证恢复与防复发：抽样回溯与门禁规则
补齐完成不等于追溯恢复。验证要同时做正向和反向两条路径：正向按需求抽样，从需求追到用例再到验证结果，确认每一跳都有记录且指向正确；反向从缺陷抽样，追到对应需求，确认缺陷能回到需求上下文。抽样应覆盖本次断链涉及的各个链路分段，而不是只抽关联最完整的那部分。
验证通过的标准可以定为三条：抽样需求双向可追溯；追溯矩阵在处置范围内无空行；发布评审能够依据追溯结果判断影响范围。三条同时满足，才可以把本次断链标记为已恢复。
防复发依靠规则和例行检查两层。规则层面，关联字段必填、需求变更时联动提示受影响的关联对象、发布前校验追溯完整性。检查层面，明确谁在哪个节点检查、多久巡检一次，例如需求负责人在评审前自查、测试负责人在用例评审时核对关联、项目负责人在每个迭代结束前做一次断链巡检。巡检频率按迭代节奏设定，不必统一。
| 防复发措施 | 执行角色 | 检查时点 |
|---|---|---|
| 关联字段必填校验 | 系统配置负责人 | 流程配置时设置，持续生效 |
| 需求变更联动提示 | 需求负责人 | 变更提交时 |
| 用例关联核对 | 测试负责人 | 用例评审时 |
| 断链巡检 | 项目负责人 | 每个迭代结束前 |
还要交代残余风险：历史数据补齐后，标注“待确认”的部分仍需业务人员人工确认归属，这部分在确认前不能作为发布评审的完整依据；流程绕过如果源于线下协作习惯，规则校验只能减少而不能消除，需要配合协作方式的调整。把这些残余项记录在处置结论中，下一次巡检时优先复核。
常见问题
追溯矩阵里只有少量空行，也需要按完整流程处置吗？
不必一律按完整流程走。先判断空行影响哪类决策：如果空行落在本次发布范围内，导致无法证明需求已被用例覆盖和验证，就按最高优先级补齐；如果只影响报表展示，评审和变更可以人工兜底，可以并入常规批次处理。范围界定清楚后，取证和补齐的工作量会明显下降。
需求拆分或任务重派之后，原来的关联为什么会指向错误对象？
需求拆分后，原需求可能被关闭或转为父需求，子需求需要重新挂接任务和用例；任务重派或用例重构时，如果关联字段随对象复制但未重新校验，链接就可能保留在旧对象上。这类断链的特征是“有记录但指向错”，取证时查看历史版本和流转记录，确认关联对象在哪个时间点被替换或删除。
批量补齐关联时，怎么避免把关系挂错？
执行前先导出当前关联数据，确认导出内容包含关联双方的对象标识，并明确回滚方式。然后分批执行，每批完成后抽样核对关联是否指向正确对象。对无法确认归属的历史需求，标注“待确认”并记录原因，不要为了消灭空行强行挂接，错误关联比缺失关联更难排查。
关联字段设为必填后，团队仍然在线下流转怎么办？
必填校验只能约束系统内操作，线下沟通和外部表格承接的工作仍可能不回写。处置时先通过抽样访谈确认绕过的范围和原因，再调整协作方式：把线下流转的交付物纳入系统记录，或在关键节点增加核对动作。校验过严也可能推动人员绕过系统，规则设计要结合团队实际流程。
历史数据补齐后，发布评审可以直接依据追溯结果吗？
要看补齐的完整程度。标注“待确认”的部分在业务人员确认归属前，不能作为发布评审的完整依据；抽样验证通过的范围可以作为依据，未覆盖的部分需要说明。建议把残余项记录在处置结论中，下一次巡检时优先复核。
