需求父子关联要落地，先定层级规则，再按“建父级、拆子级、挂关联、过评审”四步建立，最后用检查清单确认覆盖完整。本文聚焦需求层级本身，说明父需求与子需求各写什么、由谁拆分与评审、建立后如何维护，并给出可直接套用的填写示例。
要点总览（TL;DR）
- 父子关联的起点是层级规则：父需求写业务目标、范围边界与整体验收口径，子需求写到能独立安排负责人、独立开发验证、独立判断完成的粒度。
- 建立关联按四步走：登记父需求并分配唯一编号、按交付边界拆出子需求清单、逐条填写父级字段与层级、评审覆盖与粒度后冻结为基线。
- 拆分由需求负责人完成，覆盖完整性由业务或产品评审人确认，可交付性由研发与测试角色确认，编号、层级与变更记录由需求管理员维护。
- 父子结构建立后要持续维护：父需求范围变更时逐条同步子需求，子需求合并拆分时按规则改挂，并按迭代节奏筛查父级缺失或失效的孤儿需求。
- 用五项检查判断关联是否可用：子需求都有有效父级、验收口径被完整覆盖、层级粒度符合规则、无孤儿需求与循环引用、变更记录可追溯。
先定层级规则：父需求与子需求各写什么
父子关联做不好的常见原因，是拆分前没有约定层级含义，导致同一层里既有业务目标，又有开发任务。开始拆分前，先把层级定义写成一份规则，明确每一层承载什么内容、拆到什么程度算合适。规则一旦确定，后续拆分和评审都以它为准。
父需求承载业务目标与整体验收口径
父需求描述的是“为什么做、做到什么程度算完成”，通常包含三部分内容：业务目标，说明这条需求要解决什么问题、带来什么结果；范围边界，说明包含哪些场景、明确排除哪些场景；整体验收口径，说明全部子需求完成后如何统一验收。父需求不写具体实现方案，避免在拆分前锁死技术路径。
子需求承载可独立交付的粒度
子需求是父需求的交付单元，判断粒度是否合适，可以用三个标准检验：能否单独安排负责人、能否单独完成开发与验证、能否单独判断完成与否。三条都满足，说明粒度合适；只能满足其中一条，通常还需要继续拆分或合并。子需求标题应描述一个可交付的结果，例如“支持按部门筛选订单”，而不是“订单模块开发”这类笼统表述。
层级深度与命名规则
层级深度按团队交付节奏确定。多数团队采用两层：父需求对应一个业务目标或一个版本主题，子需求对应可独立交付的功能点。需求规模较大、跨多个子系统时，可以增加一层中间需求，但建议不超过三层，层级越深，覆盖校验和变更同步的成本越高。命名上统一采用“层级前缀＋业务对象＋动作”的结构，例如“需求-订单-支持批量导出”，让编号和标题本身就能看出层级归属。
区分父子关系与任务拆解、追溯关系
父子关系表达的是需求内容的包含关系：子需求是父需求的一部分，父需求的验收依赖全部子需求完成。任务拆解是把一条需求拆成开发、测试等执行动作，任务完成不改变需求本身的定义。追溯关系连接的是需求与设计、代码、测试用例等研发对象，用于证明覆盖。三者可以同时存在，但字段和用途不同，建立关联时不要混用，否则评审时无法判断覆盖是否完整。
建立父子关联的操作步骤
规则确定后，按以下四步建立关联。每一步都有明确的输入、动作、输出和完成标志，做完一步再进入下一步，避免边拆边改造成返工。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、登记父需求 | 业务目标、范围说明、验收要求 | 在需求库中创建父需求，填写目标、范围边界、整体验收口径，分配唯一编号 | 一条字段完整的父需求记录 | 编号唯一，目标与验收口径可被他人读懂 |
| 二、拆出子需求清单 | 父需求的范围与验收口径 | 按交付边界逐条列出子需求，每条写清交付内容与单独验收标准 | 子需求清单（尚未入库） | 每条子需求都能独立安排负责人和验证 |
| 三、挂接父级字段 | 子需求清单、父需求编号 | 逐条创建子需求，填写父级字段、层级和交付边界，核对编号与父级对应 | 带父级字段的子需求记录 | 每条子需求都能通过父级字段回溯到唯一父需求 |
| 四、评审并形成基线 | 父子需求全集 | 核对父需求验收口径是否被全部子需求覆盖，检查粒度与层级是否符合规则，确认后冻结为基线 | 评审通过的父子结构基线 | 覆盖无缺口、粒度一致，评审记录留存 |
第三步是最容易出错的环节。逐条填写父级字段时，要同时确认层级值，避免出现子需求挂在同级需求下、或父级字段指向已失效需求的情况。第四步评审的重点是覆盖：把父需求的每条验收口径逐项对应到子需求，找不到对应子需求的条目，要么补拆子需求，要么调整父需求范围。
在工具中承载这套结构时，需求层级需要由工作项类型和父级字段共同支撑。ONES 支持利用「子工作项」对功能复杂的需求进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；需求与验收标准达成一致后，设计、研发、测试人员也可以利用子任务继续拆分，便于后续处理和跟踪。落地时可以把父需求与子需求设为不同工作项类型，用父级字段建立关联，让层级关系在需求库中直接可见。
角色分工与各环节交付物
父子关联涉及拆分、评审、验证和维护四类动作，需要明确每个角色负责什么、交付什么。角色可以一人兼任，但职责要分开记录，避免拆分和评审由同一人完成而失去校验作用。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 需求负责人 | 登记父需求，按交付边界拆出子需求，逐条填写父级字段与层级 | 字段完整的父需求记录、子需求清单、父子关联关系 |
| 业务或产品评审人 | 确认父需求目标与验收口径，核对子需求是否完整覆盖 | 评审意见、覆盖核对结论、基线确认记录 |
| 研发与测试角色 | 确认每条子需求可交付、可验证，补充验收标准中的可测条件 | 子需求可行性确认、可验证的验收标准 |
| 需求管理员或配置管理员 | 维护编号规则、层级字段与变更记录，处理改挂与孤儿需求 | 编号台账、变更记录、孤儿需求清理记录 |
需求负责人对拆分质量负主要责任，评审人对覆盖完整性负责，研发与测试角色对子需求的可交付性负责，管理员对结构一致性负责。四类交付物合在一起，构成父子关联的完整记录，后续变更和审计都以这套记录为依据。
填写示例：一条父需求拆成三条子需求
以下示例为演示情景，编号和内容按通用格式编写，可替换为团队自己的业务对象。
父需求填写：编号 REQ-1024，标题“订单中心支持按部门维度统计”，业务目标为“让部门负责人能查看本部门订单数据，支撑月度经营分析”，范围边界为“包含订单列表筛选与统计导出，不含财务对账”，整体验收口径为“部门负责人登录后可按部门筛选订单，导出的统计数据与订单明细一致”。
| 子需求编号 | 标题 | 拆分依据 | 父级字段 | 单独验收标准 |
|---|---|---|---|---|
| REQ-1025 | 订单列表增加部门筛选条件 | 筛选能力可独立开发与验证 | REQ-1024 | 选择部门后列表只显示该部门订单 |
| REQ-1026 | 订单统计页按部门汇总数量与金额 | 统计口径独立于筛选，可单独验收 | REQ-1024 | 汇总结果与同条件下列表明细一致 |
| REQ-1027 | 统计结果支持导出 | 导出为独立交付能力，可单独测试 | REQ-1024 | 导出文件字段完整，数据与页面一致 |
评审时按父需求验收口径逐项检查：筛选能力对应 REQ-1025，统计一致性对应 REQ-1026，导出数据一致性对应 REQ-1027，三条子需求覆盖了父需求的全部验收点，没有遗漏。粒度判断上，三条子需求都能单独安排负责人、单独验证，符合两层结构规则；如果 REQ-1026 还需要区分多个统计维度，可以再拆一层，但当前规模不需要。
变更、拆分调整与孤儿需求处理
父子关联建立后，需求范围调整、子需求合并拆分都会影响结构，需要按规则同步维护，否则父子链会逐渐失真。
父需求范围变更时的向下同步
父需求的目标或验收口径发生变化时，先更新父需求字段，再逐条检查子需求：新增的验收点是否需要补拆子需求，被移除的范围对应的子需求是关闭还是改挂到其他父需求。同步完成后重新做一次覆盖核对，确认父需求验收口径仍能被现有子需求完整覆盖。
子需求合并或拆分时的改挂规则
两条子需求合并时，保留其中一条作为承接记录，把另一条的验收标准和关联信息并入，父级字段保持不变；一条子需求拆成多条时，新子需求统一挂到原父级下，原子需求关闭并注明拆分去向。改挂只能在同一父级内或经评审确认后跨父级进行，改挂后要更新层级字段和变更记录。
孤儿需求的识别与处置
孤儿需求指父级字段为空、指向已关闭或已删除父需求、或层级值与实际挂接位置不一致的需求。可以按父级字段定期筛查：父级字段为空的子需求，确认是补挂父级还是转为独立需求；父级已失效的，改挂到有效父需求或随父需求一并关闭。筛查频率建议与迭代节奏一致，在每次需求评审前完成。
变更记录需要保留的字段
每次结构调整至少记录：变更对象编号、变更类型（新增子需求、合并、拆分、改挂、关闭）、原父级与新父级、变更原因、操作人和时间。这些字段让后续评审能还原结构演变过程，也便于判断某条需求的覆盖关系是否仍然成立。
在 ONES 中，需求可以通过统一的需求池与工单流转承载，业务反馈经工单转化为需求后进入产品 Backlog，配合自定义工作流规范需求流转；需求状态与关联信息在统一视图中同步，便于在变更时核对父子链的当前状态。涉及批量改挂、孤儿需求自动识别等操作，建议在实际产品中确认具体支持方式后再纳入流程。
完成检查：父子关联是否可用的核对项
父子关联建立或调整后，用以下清单逐项核对。全部通过，说明结构可用于后续排期、开发和验收；存在未通过项，先修正再进入下一环节。
| 核对项 | 检查方法 | 通过标准 |
|---|---|---|
| 每条子需求都有有效父级 | 按父级字段筛查全部子需求 | 无空父级，父级均处于有效状态 |
| 父需求验收口径被完整覆盖 | 逐条验收点对应到子需求 | 每个验收点至少有一条子需求承接 |
| 层级深度与粒度符合规则 | 抽查子需求是否可独立交付、独立验收 | 层级不超过约定深度，粒度标准一致 |
| 无孤儿需求与循环引用 | 检查父级失效记录和父子指向 | 不存在父级缺失、失效或相互指向的情况 |
| 变更记录可追溯 | 抽查近期结构调整记录 | 变更对象、原因、操作人和时间齐全 |
这份清单适合在需求评审会和迭代规划前各执行一次。持续按清单核对，父子关联才能保持可用，需求层级也才能真正支撑后续的排期、交付与验收。
常见问题
需求只有一条、暂时不需要拆分时，还要建父子关联吗？
不需要为了形式强行拆出子需求。父子关联的价值在于让父需求的验收口径有明确的承接单元，如果一条需求本身就能独立交付、独立验收，把它作为单条需求管理即可，父级字段留空并在评审中说明原因。
需要留意的是后续变化：当这条需求的范围扩大、出现多个可独立交付的部分时，再按层级规则补建子需求，并把原有验收口径拆到各子需求上。判断标准是能否独立安排负责人和独立验证，而不是需求条数。
子需求拆到一半发现粒度不合适，应该合并还是继续往下拆？
先回到粒度标准判断：能单独安排负责人、能单独完成开发与验证、能单独判断完成与否，三条都满足就不必再动。只满足部分条件时，看缺口在哪一侧——如果一条子需求内部包含多个互不依赖的交付结果，继续往下拆；如果几条子需求必须一起交付才能验证，合并为一条。
调整后要同步更新父级字段和变更记录，并重新做一次覆盖核对，确认父需求的验收口径仍能被现有子需求完整承接。合并时保留一条作为承接记录，把另一条的验收标准并入；拆分时新子需求统一挂到原父级下，原子需求关闭并注明去向。
父需求在开发过程中被缩减范围，已经建好的子需求怎么处理？
先更新父需求的目标、范围边界和验收口径，再逐条检查子需求：落在被移除范围内的子需求，按实际情况关闭或改挂到其他父需求；新增的验收点，判断是否需要补拆子需求承接。
处理完成后重新做覆盖核对，确认父需求当前的每条验收口径都有子需求对应。改挂跨父级时建议经评审确认，改挂后更新层级字段，并在变更记录中写明变更对象编号、变更类型、原父级与新父级、变更原因、操作人和时间，便于后续还原结构演变过程。
孤儿需求多久筛查一次比较合适？
筛查频率与团队的迭代节奏对齐即可，常见做法是在每次需求评审会或迭代规划前执行一次，把父级字段为空、父级已关闭或已删除、层级值与实际挂接位置不一致的需求筛出来。
处置分两类：父级字段为空的子需求，确认是补挂父级还是转为独立需求；父级已失效的，改挂到有效父需求或随父需求一并关闭。筛查结果记入变更记录，避免同一问题在多个迭代中反复出现。
在工具里落地父子关联，需要配置哪些基础项？
至少需要三样：能区分层级的工作项类型、记录父级指向的父级字段、以及编号规则。ONES 支持利用「子工作项」对功能复杂的需求进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；需求与验收标准达成一致后，设计、研发、测试人员也可以利用子任务继续拆分，便于后续处理和跟踪。
需求侧还可以通过统一的需求池与工单流转承载：业务反馈经工单转化为需求后进入产品 Backlog，配合自定义工作流规范需求流转。层级深度上限、父子字段的具体配置方式，以及批量改挂、孤儿需求识别等操作，建议在实际产品中确认支持方式后再写入流程。
