父子需求挂接检查表用于在需求录入后、评审前和开发启动前，逐项确认需求层级与父子关系是否正确。它覆盖层级定义、挂接前准备、挂接执行和挂接后核验四个阶段，每项写明检查内容、通过标准、证据和负责人，并把层级越级、父需求缺失、验收口径冲突列为阻断项。本文给出的表格可直接填写使用，范围限于需求层级与父子挂接，任务拆解和跨对象追溯不在其中。
要点总览（TL;DR）
- 检查表按“层级定义—挂接前准备—挂接执行—挂接后核验”四段组织，每项写明检查内容、通过标准、证据和负责人，可直接填写使用。
- 挂接前先定稿层级定义表，明确层级名称、编号规则、粒度与拆分依据、父级约束，后续检查项以它为判定基准。
- 挂接后采用“全部通过才通过”的判定规则：三项核验全部满足且阻断项清零，才允许进入评审或开发。
- 层级越级、父需求缺失、验收口径冲突、多父级属于阻断项，修正后重新执行对应阶段检查并复检清零。
- 证据按“需求编号_检查阶段_日期_版本”命名归档，检查人提交、复核人确认、批准人签字放行。
谁在什么时点使用这张检查表
这张表由需求负责人主检、产品经理复核、评审人批准，在三个时点各用一次：需求录入后检查层级归属，评审前检查挂接完整性，开发启动前做最终放行确认。三个时点对应不同的检查重点，混用会漏项。
| 使用角色 | 触发时点 | 主要动作 | 输出 |
|---|---|---|---|
| 需求负责人 | 需求录入后 | 对照层级定义表确认层级归属，完成挂接前准备检查 | 填写完整的准备检查表 |
| 产品经理 | 评审前 | 复核父子关系方向、唯一父级、字段同步，核对验收口径 | 复核意见与修正记录 |
| 评审人 | 开发启动前 | 核验层级树完整性，确认阻断项清零，签字放行 | 放行签字与证据归档 |
检查范围只包括需求层级与父子挂接本身。任务拆解、子任务派发、需求到测试用例的追溯覆盖属于相邻主题，由对应流程另行检查，不并入本表，避免一张表承担过多判定责任而失去可操作性。
先统一需求层级定义再谈挂接
挂接检查的前提是团队对“哪一层是什么”有共同答案。层级定义表要先于检查表定稿，后续所有检查项都以它为判定基准。下表给出一个可直接沿用的四层结构，团队可按自身规模增减层级，但增减后必须同步修订检查项。
| 层级 | 编号规则 | 粒度与拆分依据 | 父级约束 |
|---|---|---|---|
| 史诗（Epic） | EP-三位序号 | 对应一条业务方向或一个季度级目标，可跨多个版本交付 | 无父级，位于层级顶端 |
| 特性（Feature） | FT-三位序号 | 史诗下可独立规划交付的能力单元，通常在一个版本内完成 | 唯一父级为史诗 |
| 用户故事（Story） | US-三位序号 | 具备独立验收条件的用户价值单元，可由一名负责人在一个迭代内完成 | 唯一父级为特性 |
| 子需求（Sub） | US-三位序号-S序号 | 用户故事中需要单独跟踪的实现或验收片段 | 唯一父级为用户故事 |
填写层级定义表时至少包含四个字段：层级名称、编号规则、粒度与拆分依据、父级约束。编号规则要保证全局唯一，子需求编号建议继承父编号加后缀，便于从编号直接看出挂接关系。父子关系方向统一为“子指向父”，每个需求只允许一个父级；需要表达多归属时，用标签或关联关系表达，不改父子结构。粒度描述要写成可判断的条件，例如“一个迭代内可完成”“具备独立验收条件”，避免“较大”“较复杂”这类无法核对的表述。
挂接前准备检查项
准备阶段的目标是让每条待挂接的需求在建立关系前就具备合格输入。以下四项未通过时，先修正再挂接，不要带着缺陷建立父子关系。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 父需求已评审通过且有唯一编号 | 父需求状态为已评审通过，编号在需求库中唯一，无重号 | 评审记录链接、编号检索结果 | 需求负责人 |
| 子需求描述完整、可独立验收 | 包含背景、目标、验收条件三部分；验收条件可逐条判断通过与否 | 需求详情页导出或截图 | 需求负责人 |
| 层级归属符合定义表 | 按粒度与拆分依据判定层级正确，编号规则与层级一致 | 层级定义表比对记录 | 产品经理 |
| 重复或近似需求已合并 | 按标题与关键词检索无重复项；近似项已合并或注明差异理由 | 检索结果截图、合并说明 | 需求负责人 |
“可独立验收”是准备阶段最容易放水的检查项。判定方法是让测试人员只看子需求描述就能写出验收步骤；写不出来，说明描述不完整，退回补充。重复需求检查建议在挂接前统一做一次关键词检索，把标题相近、验收条件重叠的条目列出来逐条确认，合并结论记录在需求备注中。
挂接执行检查项
执行阶段检查的是操作本身是否正确。挂接动作完成后立即逐项核对，发现问题当场修正，不要留到评审时处理。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 父子关系方向正确 | 子需求挂在定义表规定的上一层之下，无跨层直挂 | 层级视图截图 | 需求负责人 |
| 每层只有一个父级 | 逐条查看子需求，父级字段有且仅有一个值 | 字段导出（含父级列） | 产品经理 |
| 关联字段同步 | 负责人、优先级、目标版本与父需求规划一致；有意不一致的已注明理由 | 字段导出对比表 | 产品经理 |
| 挂接操作留痕 | 挂接时间、操作人、变更前后父级可查 | 操作日志或变更记录截图 | 需求负责人 |
字段同步不等于全部照抄父需求。优先级和版本通常需要与父需求规划对齐，负责人则按实际执行人填写。检查时关注的是“不一致是否有理由”，把有意差异写在需求备注里，复核人据此判断，而不是机械要求所有字段相同。留痕项依赖工具的操作记录能力，若当前环境无法提供变更历史，改用挂接当日的层级视图截图加操作人签字作为替代证据，并在证据说明中注明替代原因。
在工具层面，ONES 支持用「子工作项」对功能复杂的需求进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；其业务需求池与产品需求池的分层管理，也可作为父子挂接的承载结构。层级深度、层级视图配置和操作留痕的具体形态，需在實際环境中核验后再写入团队规范。
挂接后核验与通过标准
挂接完成后做结果核验，判断的是整体结构是否成立，而非单条操作是否正确。核验通过才允许进入评审或开发。
| 核验项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 层级树完整、无孤儿需求 | 范围内每条需求都能在层级树中找到位置；无父级的顶层需求均为史诗 | 完整层级树截图或导出 | 产品经理 |
| 父子验收口径一致 | 子需求验收条件之和能覆盖父需求验收条件；无冲突表述 | 验收条件对照表 | 评审人 |
| 需求清单与层级视图对得上 | 清单条数与层级视图节点数一致，编号一一对应 | 清单导出与视图截图 | 需求负责人 |
整体判定采用“全部通过才通过”的规则：三项核验全部满足通过标准，且阻断项清单为零，判定为通过；任一项不满足，判定为不通过，退回对应阶段修正后重新核验。验收口径一致性按覆盖关系判断，子需求可以比父需求更细，但不能出现父需求要求而所有子需求都未覆盖的验收点，也不能出现子需求之间互相矛盾的验收条件。
证据留存与负责人分工
每类检查项都要留下可复核的证据，证据与检查项一一对应，避免事后无法判断当时是否真的检查过。
| 证据类型 | 对应检查阶段 | 检查人 | 复核人 | 批准人 |
|---|---|---|---|---|
| 评审记录 | 挂接前准备 | 需求负责人 | 产品经理 | 评审人 |
| 层级视图截图 | 挂接执行、挂接后核验 | 需求负责人 | 产品经理 | 评审人 |
| 字段导出（含父级、负责人、优先级、版本列） | 挂接执行 | 产品经理 | 评审人 | 评审人 |
| 验收条件对照表 | 挂接后核验 | 评审人 | 产品经理 | 评审人 |
证据存放位置统一到需求库的附件区或团队约定的共享目录，命名规则建议为“需求编号_检查阶段_日期_版本”，例如“FT-012_挂接后核验_20250610_v1”。同一需求多次核验时保留各版本，不覆盖旧文件，便于回溯。检查人负责提交证据，复核人确认证据与检查项匹配，批准人签字后证据转为归档状态。
阻断项与完成条件
阻断项是必须清零才能放行的检查结果。出现任一项，需求不得进入评审或开发，修正后重新执行对应阶段的检查。
| 阻断项 | 判定条件 | 处理方式 | 复检要求 |
|---|---|---|---|
| 层级越级 | 子需求直接挂在隔层父级下，跳过定义表中的中间层 | 调整父级至规定层级，或补充中间层需求 | 重新核验层级树 |
| 父需求缺失 | 子需求无父级，或父级编号在需求库中不存在 | 补建或指定父需求，修正编号 | 重新核验唯一父级 |
| 验收口径冲突 | 子需求验收条件与父需求矛盾，或父需求验收点无子需求覆盖 | 修订验收条件，补充覆盖子需求 | 重新做验收条件对照 |
| 多父级 | 同一子需求挂接两个及以上父级 | 保留唯一父级，其余改为关联关系 | 重新导出父级字段核对 |
阻断项处理流程为：检查人记录问题与责任需求编号，修正后在原检查表上标注复检结果，由复核人确认清零。整体完成条件包括四项：准备、执行、核验三阶段检查项全部通过；阻断项清单为零；证据已按命名规则归档；批准人完成放行签字。四项同时满足，该批需求才可进入评审或开发。放行签字按批次进行，批次内任一需求存在未清零阻断项，整批暂缓，避免部分放行造成层级结构不一致。
常见问题
团队层级比四层多或少，检查表怎么调整？
层级定义表是判定基准，团队增减层级后必须同步修订检查项，不能只改定义表。调整时重点核对三处：挂接执行中的“父子关系方向正确”要按新层级重新写明允许的挂接路径；挂接后核验中的“无孤儿需求”要更新顶层需求的判定条件；阻断项中的“层级越级”要按新定义重新界定隔层情形。层级数量变化后，建议先用一批历史需求试跑一遍检查表，确认各检查项仍可判定，再正式启用。
挂接检查发现父需求本身描述不完整，应该先修父需求还是先挂子需求？
先修父需求。父需求未评审通过或验收条件不完整时，子需求的验收口径无法与之对齐，此时挂接会把缺陷带入层级结构，后续核验阶段仍会被判为不通过。处理方式是暂停该子需求的挂接，把父需求退回补充并重新评审，评审通过后再执行挂接前准备检查。若父需求短期内无法修订，可先将子需求保留在待挂接清单中，注明阻塞原因和责任人，不建立临时父子关系。
工具无法提供挂接操作的变更历史，留痕检查项怎么处理？
留痕检查项的目的是证明挂接操作可追溯，变更历史只是其中一种证据形式。当前环境无法提供操作日志时，改用挂接当日的层级视图截图加操作人签字作为替代证据，并在证据说明中注明替代原因和截图时间。替代证据同样按命名规则归档，复核人核对截图中的父子关系与字段导出是否一致。若后续工具具备变更记录能力，再恢复使用操作日志作为标准证据。
一个批次里部分需求阻断项未清零，能否先放行其余需求？
不建议按需求拆分放行。父子挂接的检查对象是层级结构的整体一致性，同一批次内部分需求未清零时放行，会造成层级树中部分节点已进入评审或开发、部分仍待修正，后续核验“需求清单与层级视图对得上”时无法给出稳定结论。处理方式是整批暂缓，把未清零的阻断项按责任需求编号列出，修正并复检通过后再整批签字放行。若业务确有时限压力，可将已清零的需求拆分为独立批次重新走检查流程，而不是在同一批次内部分放行。
检查表需要每次全量执行吗，还是可以按需求规模裁剪？
阻断项相关的检查不能裁剪，包括父需求缺失、层级越级、多父级和验收口径冲突，这四项在任何规模下都必须检查。准备阶段和执行阶段的其余检查项可按需求规模调整执行深度，例如小规模需求可合并重复需求检索与层级归属比对为一次操作，但结论仍需逐项记录。裁剪决定由产品经理在批次启动时确认并写入检查表备注，评审人放行时核对裁剪范围是否合理，避免以规模小为由跳过关键判定。
