检查子需求可追溯性，核心是沿着“父需求—子需求—研发对象—验收证据”四段链路逐条核对，回答每个子需求能否向上归属、向下承接、横向找到验收依据。检查前要先固定需求范围、状态和时间窗，再用可追溯率、断链数、孤儿需求数把结果量化。本文给出一套可复算的口径与步骤，并说明指标能说明什么、不能说明什么。
要点总览（TL;DR）
- 检查子需求可追溯性，核心是沿“父需求—子需求—研发对象—验收证据”四段链路逐条核对，先固定需求层级、状态和时间窗再开始。
- 用可追溯率（完整链路子需求数÷纳入检查子需求总数）、断链数、孤儿需求数三个指标量化，报告时同时给出分子、分母和绝对数量。
- 断链项要记录缺失环节与原因分类，指定补链责任人和复查时点，复查时只核对原断链项并重算一次可追溯率。
- 可追溯率只反映链路完整程度，不说明拆分粒度是否合理，也不等同于需求质量或交付效果；不同团队、不同时间窗的结果不宜直接横比。
检查目标：判断分解结果是否可用、有无遗漏
这项检查的对象是需求分解后形成的层级结构，也就是父需求与子需求之间的归属关系，以及子需求与后续研发、验收环节的关联。它关注分解结果本身是否成立，任务如何分派、由谁在什么时间完成属于执行层面，不在本次检查范围内。
一次完整的检查要回答三个问题：
- 向上归属：每个子需求能否找到明确的父需求，并确认它处在哪一层级路径上。找不到父需求的子需求，无法判断它服务于哪个业务目标。
- 向下承接：子需求是否关联了具体的研发对象或交付项，例如开发任务、测试任务、工单。没有承接对象的子需求，分解后可能停留在文档里，没有进入交付流程。
- 横向验收依据：子需求是否有可核对的验收条件、评审记录或测试依据。缺少验收依据，子需求完成与否缺少判定标准。
检查结果用于三个判断：分解结构是否可用，即子需求能否支撑后续研发与验收；是否存在遗漏，即某些父需求下没有子需求、或子需求没有承接对象；需要补哪些链路，即为断链项指定补充动作。把检查目标限定在这三个判断上，可以避免把可追溯性检查做成一次笼统的需求评审，导致结论无法量化、也无法复查。
指标与范围：可追溯率、断链数与孤儿需求
指标只有在范围固定的前提下才有比较意义。检查开始前，先在检查说明中写明纳入范围：纳入哪些需求层级（例如只检查父需求下的第一层子需求）、哪些状态（例如已评审通过、开发中、已完成）、哪个时间窗（例如按子需求创建时间取最近一个季度），以及是否包含已关闭或已取消的需求。范围一经确定，同一轮检查内不再调整；下一轮检查如需调整，要在结果中注明，避免与上一轮直接对比。
核心指标及口径如下：
| 指标 | 定义 | 计数口径 |
|---|---|---|
| 可追溯率 | 已建立完整链路的子需求数 ÷ 纳入检查的子需求总数 | 分子只计四段链路全部具备的子需求；分母为按范围口径筛选出的子需求总数；结果以百分比表示 |
| 断链数 | 链路中至少一段缺失的子需求数量 | 按子需求计数，不按缺失段数计数；同一子需求缺多段仍计为1条断链 |
| 孤儿需求数 | 找不到父需求归属的子需求数量 | 属于断链的一种特殊情形，单独统计以便定位分解结构问题；孤儿需求同时计入断链数 |
三个指标的关系是：可追溯率反映链路完整程度，断链数反映需要补链的工作量，孤儿需求数反映分解结构本身的缺口。报告时应同时给出分子、分母和绝对数量，只给百分比容易掩盖样本规模。
几种边界情况需要事先约定处理方式：
- 分母为零：范围内没有符合条件的子需求时，不计算比率，直接说明“本期无纳入样本”，并记录范围口径，避免被误读为100%或0%。
- 需求被合并：原子需求合并后，以合并后的需求作为检查单元，原有关联关系并入新需求；若合并导致链路信息丢失，记为断链并注明“合并导致”。
- 需求被拆分：拆分产生的新子需求全部纳入检查，拆分前的父需求作为其上级归属；拆分后未及时补充承接对象的，按断链处理。
数据口径与证据：链路每一段看什么
四段链路各自需要可核对的字段或证据。检查时逐段确认“有、无、无法确认”三种状态，其中“无法确认”单独记录，不与“无”混同。
| 链路环节 | 需要核对的字段或证据 | 缺失时的记录方式 |
|---|---|---|
| 向上：父需求关联 | 父需求编号、层级路径（从顶层需求到当前子需求的层级） | 记录“父需求缺失”，并注明是字段为空还是关联指向已删除/已关闭需求 |
| 自身：子需求信息 | 子需求编号、当前状态、负责人、验收标准 | 逐项记录空值字段；验收标准为空单独标记，因为它同时影响横向验收环节 |
| 向下：研发承接 | 关联的研发对象或交付项，如开发任务、测试任务、工单编号 | 记录“无承接对象”；若存在关联但对象状态异常（如已关闭未交付），单独注明 |
| 横向：验收证据 | 验收条件、评审记录、测试用例或测试结果 | 记录“验收依据缺失”；仅有验收标准文本而无执行记录的，标注为“标准存在、证据待补” |
字段为空只说明当前记录中没有该信息，检查记录应写成“该子需求父需求字段为空”，不写成“系统不支持关联父需求”。前者是可以补链的数据问题，后者是对产品能力的判断，需要单独核实，不能由一次检查得出。对于关联关系存在但指向对象已失效的情况，也应保留原关联记录，便于追溯是何时断开的。
检查步骤：从抽样到逐条核对
检查流程要保证不同人按同一口径执行能得出可比结果。建议按以下顺序推进：
- 确定范围与时间窗，导出需求清单。按上一节约定的层级、状态、时间窗筛选子需求，导出包含子需求编号、父需求编号、状态、负责人、关联对象、验收信息的清单。导出后核对总数，与筛选条件预期一致再进入下一步。
- 按四段链路逐条核对，标记三类结果。对每条子需求依次检查向上归属、自身信息、向下承接、横向验收，标记为“完整”“断链”“孤儿”三类。孤儿需求是父需求缺失的子需求，单独标出；其余缺段标为断链。
- 对断链项记录缺失环节与原因分类。原因分类建议固定为几类，例如：未关联父需求、未创建承接任务、验收标准未填写、验收记录未归档、关联对象失效、合并拆分导致。分类固定后，汇总时可以直接看出问题集中在哪一段。
- 汇总指标并抽样复核。按公式计算可追溯率、断链数、孤儿需求数，再由未参与初检的人抽取一定比例（例如10%或不少于10条）复核，重点核对被判为“完整”的条目是否确实四段齐全，减少口径偏差。
在工具层面，这套核对依赖需求层级与关联关系能够被完整记录和查询。ONES 支持对功能复杂的需求使用子工作项进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；在迭代规划中，需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续处理和跟踪。检查时可以从需求池与任务看板中导出子需求及其关联对象，按上述四段逐条比对；断链项补链后，状态变化也能在同一处查看。具体字段名称与视图形态以实际环境为准。
算例：20条子需求的追溯检查
假设某产品团队检查最近一个季度创建的子需求，范围限定为“已评审通过”和“开发中”两种状态，共纳入20条。逐条核对后结果如下：
| 类别 | 数量 | 说明 |
|---|---|---|
| 四段链路完整 | 13条 | 父需求、自身信息、承接任务、验收依据均具备 |
| 断链（不含孤儿） | 5条 | 父需求存在，但缺承接任务或缺验收依据 |
| 孤儿需求 | 2条 | 父需求字段为空，无法确认归属 |
| 合计 | 20条 | 与纳入范围总数一致 |
按口径计算：可追溯率 = 13 ÷ 20 = 65%；断链数 = 5 + 2 = 7条（孤儿需求计入断链）；孤儿需求数 = 2条。
再看断链原因分布：5条非孤儿断链中，3条缺承接任务、2条缺验收依据；2条孤儿需求均为父需求字段为空。这个分布影响结论的落点：缺承接任务说明分解后没有及时进入研发流程，补链动作是创建或关联任务；缺验收依据说明验收标准或记录未跟上，补链动作是补充验收条件并安排评审；孤儿需求则要先确认归属，可能需要回到父需求层面重新整理分解结构。如果只看65%这个数字，无法判断应该先处理哪一类问题，因此断链原因分布应与比率一起报告。
结果解读与限制：指标说明什么、不说明什么
可追溯率高，说明纳入范围内的子需求大多能向上归属、向下承接并找到验收依据，链路是完整的。它不说明拆分粒度是否合理：一个父需求只拆出一条子需求，链路同样可以完整，但分解可能过于粗糙；反过来，拆得过细也会让链路完整却难以管理。粒度是否合适需要结合需求复杂度单独评审，不能由可追溯率推出。
指标也不等同于需求质量或交付效果。链路完整只表示关联关系存在，验收依据是否充分、承接任务是否按期完成，需要另外的证据判断。因此可追溯率适合作为分解结果可用性的检查指标，不宜单独作为团队绩效指标使用。
结果可比性有明确边界：不同团队的需求类型、拆分习惯和工具使用方式不同，可追溯率不宜直接横向比较；同一团队不同时间窗的结果，只有在范围口径一致时才可对比，口径调整过的时间窗要在报告中注明。分母为零或样本过小时（例如只有三五条子需求），比率波动很大，应改为逐条说明缺失情况，不给出百分比结论。
检查完成后要形成补链闭环：每条断链项指定补链责任人和复查时点，复查时只核对原断链项是否补齐，并重新计算一次可追溯率作为对照。复查周期可以与需求评审节奏对齐，避免检查结果停留在报告里。对于反复出现在同一原因分类下的断链，例如承接任务长期滞后创建，应回到分解流程中调整约定，而不是每轮检查后逐条补救。
常见问题
需求被合并或拆分后，追溯检查怎么处理才不会前后口径打架？
合并和拆分都会改变检查单元，处理原则是让每个子需求在检查时只有一个明确的归属和承接关系。
- 合并：以合并后的需求作为检查单元，原有关联关系并入新需求；如果合并过程中链路信息丢失，记为断链并注明“合并导致”，便于后续补链时定位。
- 拆分：拆分产生的新子需求全部纳入检查，拆分前的父需求作为其上级归属；拆分后未及时补充承接对象的，按断链处理。
两种情形都要在检查说明中事先约定，避免同一轮检查里有人按合并前、有人按合并后统计，导致分母不一致。
检查时发现子需求关联了已关闭或已失效的对象，算断链还是算完整？
这种情况应记为断链，并单独注明“关联对象失效”，不要直接判为完整。链路完整的前提是承接对象仍然有效、能够支撑后续交付；关联指向已关闭未交付的任务或已删除的对象，实际上已经无法继续跟踪。
记录时保留原关联信息，写清失效对象的编号和状态，便于追溯链路是何时断开的。补链动作通常是重新创建或关联有效的承接对象，而不是简单删除旧关联。若同一类失效反复出现，应回到需求变更或任务关闭流程中检查约定是否缺失。
样本只有几条子需求时，还能用可追溯率下结论吗？
样本过小时比率波动很大，不建议给出百分比结论。例如纳入检查的子需求只有三五条，少一条完整链路就会让比率变化十几个百分点，读者容易把偶然波动当成趋势。
更合适的做法是逐条说明缺失情况：哪几条缺父需求、哪几条缺承接任务、哪几条缺验收依据，直接列出清单和补链动作。分母为零时同样不计算比率，写明“本期无纳入样本”并记录范围口径，避免被误读为100%或0%。等样本量恢复到可比较的规模，再恢复比率统计。
可追溯率能不能直接作为团队的需求管理考核指标？
不建议单独作为考核指标。可追溯率衡量的是关联关系是否齐全，链路完整并不代表拆分粒度合理，也不代表验收依据充分或承接任务按期完成。把它与绩效直接挂钩，容易出现为了凑齐关联而补填字段的情况，指标好看但链路质量没有改善。
更稳妥的用法是把它作为分解结果可用性的检查工具：定期检查、公布断链原因分布、跟踪补链闭环。如果确实需要纳入团队度量，应与需求评审通过率、验收证据完备情况等指标一起看，并结合具体断链原因判断改进方向。
补链之后怎么确认问题真的解决了，而不是下一轮检查又出现同样的断链？
补链闭环要分两步看。第一步是逐项复查：每条断链项指定责任人和复查时点，复查时只核对原断链项是否补齐，并重新计算一次可追溯率作为对照，确认数字变化来自真实补链而非范围调整。
第二步是看原因分布是否收敛。如果某一类原因反复出现，例如承接任务长期滞后创建、验收记录长期不归档，说明问题出在分解流程的约定上，需要调整流程节点和角色分工，而不是每轮检查后逐条补救。复查周期可以与需求评审节奏对齐，让检查结果进入日常节奏。
