需求父子关联要解决的是“一条需求从哪里来、往下拆成什么、拆完还能不能对上”的问题。建立这套机制时，先定层级模型和拆分粒度，再设计父子字段与状态规则，最后落到角色分工、操作步骤和检查项上。本文按这条路径展开，并说明这些管理动作如何在ONES需求管理中承载。
要点总览（TL;DR）
- 先定需求层级模型：常见为业务需求—产品需求—系统需求—子需求，团队规模小、迭代快时可合并为三层，层级数量与交付节奏匹配。
- 拆分粒度按层级对应判断：业务需求按业务能力或目标，产品需求按用户场景或功能域，系统需求按模块、接口或数据边界，子需求按可独立交付和验证的工作单元。
- 父子关联靠字段承载：子需求设父需求字段并设为必填，父需求通过子需求列表双向可查；编号全局唯一，层级用前缀或独立字段标识；状态联动或独立规则提前约定。
- 操作按创建父需求、拆出子需求、一致性检查、评审确认、变更同步五步推进，每步有输入、输出和完成标志，拆分人与确认人可按风险选择分离或合并。
- 用五项检查判断是否可用：层级覆盖全部需求类型、子需求都有父需求、状态规则被执行、变更后关联同步、评审记录与责任人可查。
需求父子关联先定什么：层级模型与拆分粒度
需求父子关联的第一步是确定层级模型。层级模型回答两个问题：团队需要几层需求，每一层按什么依据拆分。层级定得过多，填写和评审成本会上升；层级过少，业务意图和实现细节容易混在一条需求里，后续变更难以判断影响范围。
常见做法是采用四层结构：业务需求、产品需求、系统需求、子需求。业务需求描述业务目标与价值，产品需求描述为达成目标要提供的产品能力，系统需求描述产品能力在系统中的实现边界，子需求则是可独立安排分析、开发或验证的最小需求单元。团队规模较小、交付节奏较快时，可以合并为三层，例如业务需求—产品需求—子需求，把系统需求的内容并入产品需求或子需求描述中。
拆分粒度的判断依据要与层级对应。业务需求按业务能力或业务目标拆分，一条业务需求应对应一个可描述的价值结果；产品需求按用户场景或产品功能域拆分，一条产品需求应能说清“谁在什么场景下完成什么”；系统需求按系统模块、接口或数据边界拆分；子需求按可独立交付和验证的工作单元拆分。粒度判断可以用一个简单标准：如果一条需求无法单独安排负责人、无法单独判断完成与否，通常还需要继续拆；如果一条需求已经小到无法说明业务价值，说明拆得过细，应向上合并。
层级数量还要与团队规模和交付节奏匹配。跨多个业务线、需求来源分散的团队，保留业务需求层有助于区分价值优先级；单一产品团队可以把业务需求与产品需求合并。迭代周期短、需求变化频繁时，层级宜少、字段宜精简，把评审重点放在父子范围一致性上；交付周期长、涉及多系统协作时，保留系统需求层更有利于识别接口和依赖。
需要明确边界：执行任务拆解与组织不属于需求层级设计，任务由谁做、几天完成、如何排期，应在需求确认之后另行处理；跨研发对象的需求追溯与覆盖管理也不在本篇展开，它关注需求与设计、代码、测试用例之间的覆盖关系，与父子层级是两套管理动作。
| 层级名称 | 定义 | 拆分依据 | 示例 |
|---|---|---|---|
| 业务需求 | 描述业务目标、价值与范围 | 业务能力或业务目标 | 降低客户退款处理时长 |
| 产品需求 | 描述为达成业务目标提供的产品能力 | 用户场景或产品功能域 | 支持退款申请在线提交与进度查询 |
| 系统需求 | 描述产品能力在系统中的实现边界 | 系统模块、接口或数据边界 | 退款单状态流转与消息通知 |
| 子需求 | 可独立安排分析、开发或验证的最小需求单元 | 可独立交付和验证的工作单元 | 退款单状态变更时触发客户通知 |
父子关联字段怎么设：必填项、编号与状态规则
层级模型确定后，需要在需求条目上设计承载父子关系的字段。字段设计的目标是让关联可查、可校验、可追责，避免只靠标题或描述里的文字说明来体现层级。
父需求字段与子需求列表是一组对应关系。子需求条目上设置“父需求”字段，指向其直接上级需求；父需求条目上通过子需求列表展示其下所有直接子项。两者应保持双向可查：从子需求能定位父需求，从父需求能展开子项。只做单向关联时，容易出现子需求挂错父项而无人发现的情况。
需求编号与层级标识用于快速识别条目位置。常见做法是编号保持全局唯一，层级通过前缀或独立字段标识，例如业务需求用BR、产品需求用PR、系统需求用SR、子需求用SUB，编号本身不承载层级含义。这样调整层级时不需要重新编号，历史记录也不会断裂。编号规则应在团队内统一，并写入需求填写规范。
状态规则需要提前约定父子之间是联动还是独立。联动规则适合父需求作为交付承诺的场景，例如所有子需求关闭后父需求才可进入待验收；独立规则适合父需求仅作为归集容器的场景，父需求状态由负责人根据整体进展手动维护。两种规则各有适用条件，关键是写清楚并在评审中执行，避免同一层级出现两套口径。
必填与选填要区分清楚。子需求的父需求字段通常设为必填，保证每条子需求都有归属；父需求的子需求列表为系统展示，不需要人工填写。层级标识、需求来源、负责人建议设为必填，优先级、目标版本可按团队需要设为选填。必填项过多会拖慢录入，必填项过少则关联质量无法保证，建议只把影响关联完整性的字段设为必填。
变更父需求时，子需求的处置规则要事先定义。常见规则包括：父需求范围调整时，逐条检查子需求是否仍在范围内，超出范围的子需求解除关联并说明原因；父需求拆分或合并时，子需求整体迁移到新父项并保留变更记录；父需求关闭时，未完成的子需求需要明确是转出、挂起还是随父项关闭。规则应写明触发条件、处理动作和记录要求。
| 字段名 | 类型 | 必填性 | 填写规则 | 示例值 |
|---|---|---|---|---|
| 需求编号 | 文本，系统生成 | 必填 | 全局唯一，不随层级调整变化 | PR-0142 |
| 层级标识 | 单选 | 必填 | 从业务需求、产品需求、系统需求、子需求中选择 | 产品需求 |
| 父需求 | 关联字段 | 子需求必填，顶层需求为空 | 指向直接上级需求，不跨层挂接 | BR-0031 |
| 子需求列表 | 系统展示 | 不需填写 | 自动汇总直接子项 | SR-0207、SR-0208 |
| 需求来源 | 单选或文本 | 必填 | 记录提出方或反馈渠道 | 客户工单 |
| 负责人 | 人员字段 | 必填 | 对该条需求内容和变更负责 | 产品负责人A |
| 目标版本 | 单选 | 选填 | 按规划填写，未规划可留空 | V2.3 |
拆分与关联的操作步骤：从父需求到子需求
操作步骤按“先建父项、再拆子项、后做校验”的顺序推进，每一步都应有明确输入、动作、输出和完成标志，避免拆分完成后才发现范围对不上。
第一步，创建父需求并确认层级归属。输入是业务目标或需求来源记录，动作是填写需求编号、层级标识、需求描述、负责人和来源，输出是一条层级明确的父需求条目。完成标志是该条目在需求池中可被检索，且层级标识与团队层级模型一致。这一步由需求提出者或产品负责人完成。
第二步，按粒度规则拆出子需求并挂接父需求。输入是已确认的父需求，动作是逐条创建子需求，填写父需求字段、层级标识和需求描述，输出是一组挂在父需求下的子需求条目。完成标志是父需求的子需求列表完整展示所有直接子项，且每条子需求都能通过父需求字段反查回父项。
第三步，做子需求内容与父需求范围的一致性检查。输入是父需求描述和全部子需求，动作是逐条核对子需求是否落在父需求范围内、是否存在重复或遗漏、子需求之间边界是否清晰。输出是一致性检查结论，完成标志是检查人确认无超范围子项，或对超范围项完成调整并记录原因。
第四步，组织关联后的评审与确认。输入是父子需求清单和一致性检查结论，动作是在需求评审会上由相关角色确认层级归属、拆分粒度和字段填写是否符合规范，输出是评审结论和待修改项。完成标志是评审记录可查，待修改项有明确责任人和关闭时间。
第五步，处理父需求变更时的同步更新。输入是变更申请或范围调整说明，动作是按预设规则逐条处理子需求：保留、解除关联、迁移或关闭，并更新父需求描述和子需求字段，输出是变更后的父子关联清单和变更记录。完成标志是变更记录中能追溯到每条子需求的处置结果。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 创建父需求 | 业务目标、需求来源记录 | 填写编号、层级、描述、负责人 | 父需求条目 | 条目可检索，层级标识正确 | 需求提出者或产品负责人 |
| 拆出子需求 | 已确认的父需求 | 逐条创建子需求并挂接父项 | 子需求条目组 | 父子双向可查 | 产品负责人或系统分析人员 |
| 一致性检查 | 父需求描述、全部子需求 | 核对范围、重复与遗漏 | 检查结论 | 无未处理超范围项 | 系统分析人员或评审人 |
| 评审确认 | 父子清单、检查结论 | 评审层级、粒度与字段规范 | 评审结论、待修改项 | 评审记录可查，修改项有责任人 | 产品负责人组织 |
| 变更同步 | 变更申请、范围调整说明 | 逐条处置子需求并更新字段 | 变更后关联清单、变更记录 | 处置结果可追溯 | 父需求负责人 |
在ONES中，需求池可以承载业务需求与产品需求的归集，功能复杂的需求可通过子工作项拆解，并把需求与后续研发、测试环节串联起来。团队可以据此把上述步骤中的父子条目和评审动作放到同一套需求管理流程里执行；字段名称、层级数量和状态联动方式需按实际配置确定。
角色与交付物：谁负责拆、谁负责确认
需求父子关联的质量取决于拆分与确认职责是否清楚。角色分工不必按岗位名称固定，但每类动作要有明确责任人，并留下可查的交付物。
业务需求提出者负责说明业务目标、范围和价值判断，交付物是业务需求描述和验收期望。产品负责人负责把业务需求转化为产品需求，确定拆分粒度和优先级，交付物是产品需求条目和子需求清单。系统分析人员负责系统需求层的拆分，识别模块、接口和数据边界，交付物是系统需求描述和一致性检查结论。研发负责人参与评审，确认子需求在技术上可独立安排，交付物是评审意见和待确认的技术约束。
拆分人与确认人可以分离，也可以合并，取决于团队规模和风险要求。需求变更频繁、跨团队协作多的场景，建议拆分与确认分离，由未参与拆分的人做一致性检查，减少范围遗漏；小团队或低风险需求可以合并，由产品负责人自查后在评审中说明。无论是否分离，评审记录都应保留参与角色、结论和待修改项。
父子关联的日常维护需要有明确责任人。通常由产品负责人或需求管理员负责定期检查是否存在无父需求的子需求、父需求关闭后仍挂着的子需求、以及长期未评审的关联条目。维护动作包括补挂父项、解除失效关联、更新状态和记录变更原因。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 业务需求提出者 | 说明业务目标、范围与验收期望 | 业务需求描述 |
| 产品负责人 | 转化产品需求、确定拆分粒度与优先级 | 产品需求条目、子需求清单 |
| 系统分析人员 | 拆分系统需求、检查范围一致性 | 系统需求描述、一致性检查结论 |
| 研发负责人 | 参与评审、确认技术可执行性 | 评审意见、技术约束说明 |
| 需求管理员 | 维护关联完整性、跟踪待修改项 | 关联检查记录、变更记录 |
示例：一条业务需求拆到子需求的完整关联
以下示例为演示情景，用于说明层级拆分、字段填写和关联确认的过程，不代表真实项目数据。
背景：某团队收到客户反馈，退款处理时长偏长，业务方提出业务需求“降低客户退款处理时长”，范围限定在线上退款申请和进度查询，不涉及线下渠道改造。
第一层，业务需求BR-0031，描述为“降低客户退款处理时长”，拆分依据是业务目标，负责人为业务需求提出者。第二层，拆出产品需求PR-0142“支持退款申请在线提交与进度查询”，父需求填写BR-0031，负责人为产品负责人。第三层，拆出系统需求SR-0207“退款单状态流转与消息通知”和SR-0208“退款进度查询接口”，父需求均填写PR-0142，负责人为系统分析人员。第四层，在SR-0207下拆出子需求SUB-0311“退款单状态变更时触发客户通知”，父需求填写SR-0207。
拆分过程中发现一处范围冲突：产品需求PR-0142最初包含“退款原因智能归类”，但业务需求BR-0031的范围只涉及处理时长和进度查询，智能归类属于新的分析能力。处理方式是将其从PR-0142中移出，另建产品需求并挂到其他业务需求下，同时在评审记录中注明移出原因。
关联完成后的评审记录包含：评审时间、参与角色（业务提出者、产品负责人、系统分析人员、研发负责人）、评审结论（层级归属正确、拆分粒度符合规则、字段填写完整）、待修改项（SUB-0311的描述需补充通知渠道范围）及责任人。评审通过后，父需求与子需求列表双向可查，变更记录中保留了范围冲突的处理过程。
完成检查：父子关联是否可用的核对项
父子关联是否达到可用状态，可以通过逐项核对来判断。检查的重点是层级覆盖、关联完整性、状态规则执行、变更同步和记录可查，而不是条目数量多少。
检查时建议由需求管理员或未参与拆分的人执行，逐项记录通过标准和证据。发现不通过项时，明确整改责任人和完成时间，整改后复查同一检查项。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 层级定义覆盖全部需求类型 | 每条需求都能归入已定义层级，无游离条目 | 需求池层级分布清单 | 需求管理员 |
| 每条子需求都有明确父需求 | 子需求的父需求字段无空值，且指向正确上级 | 父子关联检查记录 | 产品负责人 |
| 父子状态规则被执行 | 联动或独立规则与约定一致，无口径混用 | 状态变更记录、评审结论 | 需求管理员 |
| 变更后关联同步更新 | 父需求变更后子需求处置有记录，无失效关联 | 变更记录、关联清单 | 父需求负责人 |
| 评审记录与责任人可查 | 评审参与角色、结论、待修改项均可追溯 | 评审记录 | 产品负责人 |
五项检查全部通过，说明需求父子关联在层级、字段、流程和记录上形成了闭环，可以支撑后续的需求评审、排期和变更管理。若某项反复不通过，应回到对应的层级规则或字段规则上调整，而不是只靠增加检查频次解决。
常见问题
团队规模小、迭代节奏快，还需要保留系统需求这一层吗？
可以合并。三层结构（业务需求—产品需求—子需求）适合单一产品团队或迭代周期短、需求变化频繁的场景，把系统需求的内容并入产品需求或子需求描述中即可。判断依据是：如果产品能力基本在一个系统内实现、接口和依赖关系简单，合并后不影响范围判断，就可以省去这一层；如果涉及多系统协作、需要单独识别接口和数据边界，保留系统需求层更有利于变更影响分析。
父需求状态和子需求状态应该联动还是各自独立？
取决于父需求的角色。父需求作为交付承诺、需要对外给出完成时间时，适合联动规则，例如全部子需求关闭后父需求才进入待验收；父需求仅作为归集容器、用于组织需求分类时，适合独立规则，由负责人根据整体进展手动维护状态。关键是同一层级只用一套口径，并写进需求填写规范，评审时按同一标准检查，避免不同团队各按各的习惯填写。
父需求范围调整后，已经挂接的子需求怎么处理？
按事先定义的规则逐条处置，常见有四类动作：仍在范围内的子需求保留；超出范围的解除关联并记录原因；父需求拆分或合并时，子需求整体迁移到新父项并保留变更记录；父需求关闭时，未完成的子需求明确转出、挂起或随父项关闭。处置完成后更新父需求描述和子需求字段，变更记录中要能追溯到每条子需求的处置结果，便于后续复查。
拆分人和确认人必须分开吗？
不强制。需求变更频繁、跨团队协作多的场景，建议拆分与确认分离，由未参与拆分的人做一致性检查，减少范围遗漏和视角盲区；小团队或低风险需求可以合并，由产品负责人自查后在评审中说明。无论是否分离，评审记录都应保留参与角色、结论和待修改项，保证事后可追溯。
在ONES中落地这套父子关联，需要提前确认哪些配置？
ONES的需求池可以承载业务需求与产品需求的归集，功能复杂的需求可通过子工作项拆解，并把需求与研发、测试环节串联起来。落地前建议确认三件事：需求条目上父子关联字段的名称与必填规则、层级标识的取值方式、父需求与子需求状态是否联动。这些属于具体配置项，需按团队实际流程在系统中设定，本文给出的字段清单和状态规则可作为配置讨论的起点。
