需求分解规则示例要能直接对照填写：一条业务需求如何拆成用户需求、子需求，每层写哪些字段，父子关系怎么编号，验收条件如何对应。本文用“订单支持部分退款”的演示情景，给出四层填写范例，并说明拆分粒度、字段作用与换场景套用的方法。示例仅用于说明写法，ONES可承载需求层级与状态流转。
要点总览（TL;DR）
- 需求分解规则示例按四层组织：业务需求写背景、目标与成功度量，用户需求写角色、场景与期望结果，子需求写交付内容与范围边界，验收条件写可观察的完成判定。
- 拆分深度以可独立排期与验收为准，子需求之下不再继续拆成开发任务；判断粒度可用“能否不依赖其他子需求被验收”来检验。
- 父子关系采用“父编号 / 子编号”的路径写法，验收条件用 AC 编号与子需求一一对应，变更时便于回溯影响范围。
- 换场景套用时，层级数量随需求复杂度调整，子需求切分遵循独立验收、边界清晰、无重复覆盖三条判断。
- 简单需求可合并层级；执行任务拆解与跨研发对象追溯分别属于其他主题，不套用本文结构。
示例目标：这条需求要拆到什么程度
本文示例设定为演示情景，围绕一家电商平台的售后能力展开，不指向任何真实客户。选择“订单支持部分退款”作为主题，是因为它同时包含业务动机、用户场景、功能交付和验收判定，能完整展示需求分解的层级写法。
拆分深度目标是拆到可独立排期与验收的子需求层。到达这一层后，每个子需求应能单独进入开发排期、单独判定完成，不再继续向下拆成开发任务。判断拆分是否合格，使用三条标准：每层有明确的对象，即这条需求作用于哪个业务对象；每层有清晰的范围，即做什么、不做什么；每个子需求有可判定的验收条件。
本文的范围止于需求层级。子需求之下如何拆成开发任务、如何分配给具体人员、如何估算工时，属于执行任务拆解，不在本文展开。读者可以把本文示例当作需求层的填写参照，任务层另行处理。
完整示例：订单部分退款需求的四层填写
下面给出完整示例。为便于对照，先看四层结构与字段总表，再逐层展开填写内容。
| 层级 | 编号 | 核心字段 | 填写内容（示例） |
|---|---|---|---|
| 业务需求 | BR-001 | 背景、目标、成功度量 | 整单退款导致部分商品无法单独退，售后成本高；目标是支持按商品行部分退款；度量部分退款订单占比与售后处理时长 |
| 用户需求 | UR-001 | 角色、场景、期望结果 | 买家在收到部分商品有质量问题时，希望只退问题商品并保留其余商品 |
| 子需求 | SR-001 | 交付内容、范围边界 | 订单详情页支持按商品行选择退款数量并提交部分退款申请 |
| 子需求 | SR-002 | 交付内容、范围边界 | 退款金额按所选商品行金额与优惠分摊规则计算 |
| 子需求 | SR-003 | 交付内容、范围边界 | 客服后台展示部分退款申请并支持审核通过或驳回 |
| 验收条件 | AC-001 至 AC-003 | 可观察结果 | 分别对应 SR-001、SR-002、SR-003 的完成判定 |
业务需求层：BR-001
背景：当前订单只支持整单退款，买家收到部分商品存在质量问题时，只能整单退回，未出问题的商品也被一并退回，造成重复下单和售后沟通成本。目标：让买家可以按商品行申请部分退款，客服可以按申请审核处理。成功度量：部分退款申请能够走通审核流程，部分退款订单在售后订单中可单独统计，售后处理时长可按部分退款与整单退款分别观察。
用户需求层：UR-001
角色：已下单并收到部分问题商品的买家。场景：买家签收后发现其中一件商品存在质量问题，其余商品正常可用。期望结果：买家在订单详情中选中问题商品、填写退款数量与原因，提交后能看到申请状态，并只退回问题商品对应的金额。该用户需求挂在 BR-001 之下，编号写作 BR-001 / UR-001。
子需求层：SR-001 至 SR-003
SR-001（BR-001 / UR-001 / SR-001）：订单详情页支持按商品行选择退款数量并提交部分退款申请。范围边界是提交申请入口与表单校验，不包含金额计算与后台审核。
SR-002（BR-001 / UR-001 / SR-002）：退款金额按所选商品行金额与优惠分摊规则计算。范围边界是金额计算逻辑与结果展示，不包含退款打款通道。
SR-003（BR-001 / UR-001 / SR-003）：客服后台展示部分退款申请，支持审核通过或驳回。范围边界是后台列表、详情与审核动作，不包含财务对账。
验收条件：AC-001 至 AC-003
AC-001 对应 SR-001：买家可在订单详情中选择单个商品行、填写不超过该行购买数量的退款数量并成功提交，提交后订单状态显示为部分退款申请中。AC-002 对应 SR-002：提交部分退款后，页面展示的退款金额等于所选商品行金额按既定优惠分摊规则计算的结果，且与订单应付金额的扣减一致。AC-003 对应 SR-003：客服后台可查到该申请，审核通过后买家侧状态更新为退款处理中，驳回后状态回到已完成并展示驳回原因。
编号与父子关系采用“父编号 / 子编号”的路径写法，验收条件用 AC 编号与子需求一一对应。这样在评审或变更时，看到任一编号即可回溯到所属业务需求。
逐项解释：每层字段为什么这样填
业务需求层写目标而非方案，是为了保留解决空间。BR-001 写“支持按商品行部分退款”，没有写“在订单详情页加一个复选框”，因为具体交互属于子需求层的设计决策。若业务需求层直接写死方案，后续交互调整就要改动需求源头，层级之间的对应关系也会混乱。常见填错是把业务需求写成功能清单，导致目标与手段混在一起，无法判断是否达成。
用户需求层区分角色与场景，作用是让子需求有明确的适用对象。UR-001 指明角色是买家、场景是签收后发现部分商品质量问题，这决定了 SR-001 的入口放在买家侧订单详情，而不是客服后台。若省略角色与场景，子需求容易写成“系统支持部分退款”这类无主语描述，评审时无法判断谁在什么条件下使用。常见填错是把多个角色塞进一条用户需求，导致验收时无法分别确认。
子需求按可独立验收切分，而非按人员分工切分。SR-001、SR-002、SR-003 分别对应提交入口、金额计算、后台审核，每一块都能单独排期、单独验收。如果按“前端一个人、后端一个人”来切，会出现两个子需求互相依赖、都无法单独判定完成的情况。粒度判断可以用一句话检验：这个子需求能否在不依赖其他子需求完成的情况下被验收。
验收条件写成可观察结果，而不是“功能正常”“体验良好”这类判断。AC-001 写的是提交后状态显示为部分退款申请中，AC-002 写的是金额与分摊规则计算结果一致，都是可以在界面上或数据中确认的结果。常见填错是把验收条件写成测试步骤，步骤描述操作过程，结果描述完成状态，两者作用不同。
父子关系与编号在变更时的维护意义体现在回溯能力上。当 SR-002 的优惠分摊规则调整时，通过编号可以立即定位它所属的 UR-001 与 BR-001，判断这次调整是否影响业务目标或用户场景。若编号随意或父子关系只靠标题文字关联，变更影响范围就只能靠人工回忆。
可迁移规律：换一个业务场景怎么套
层级数量随需求复杂度调整。本文示例使用业务需求、用户需求、子需求、验收条件四层，是因为它涉及买家侧与客服侧两个使用面。若需求只服务单一角色、交付内容集中，可以合并用户需求层，把角色与场景写进业务需求的背景中，形成三层结构。层级的作用是分离“为什么做”“谁需要”“交付什么”“怎么算完成”，数量服务于这个分离目的。
子需求切分使用三条判断：独立验收，即每个子需求能单独判定完成；边界清晰，即写明做什么与不做什么；无重复覆盖，即两个子需求不描述同一交付内容。换到“会员积分兑换优惠券”场景，可以切为兑换入口与校验、积分扣减与券发放、兑换记录查询三个子需求，分别对应上述三条判断。
验收条件与子需求一一对应，编号成对出现。每个子需求至少一条验收条件，验收条件只描述该子需求的完成判定，不跨子需求合并。这样在子需求被拆分或合并时，验收条件可以随之调整而不牵连其他部分。
需求变更时，层级增删遵循两条做法：新增交付内容时新增子需求并分配新编号，不复用已关闭子需求的编号；删除子需求时保留编号记录并标注取消原因，避免历史验收条件失去归属。重新编号只在层级结构调整时进行，并同步更新验收条件的对应关系。
层级与状态流转需要有承载的地方。以 ONES 为例，业务需求、用户需求、子需求可以分别作为工作项类型建立父子关联，子需求在各自状态间流转，验收条件作为子需求的完成判定字段或检查项随状态推进被逐条确认。这样需求层级、状态与验收记录在同一处维护，评审时可以直接看到某个子需求的验收条件是否全部满足。是否采用这种承载方式，取决于团队已有的需求管理流程与工具习惯。
适用边界：哪些情况不按这个示例拆
简单需求可以合并层级。若一条需求只涉及单一角色、交付内容在一处完成、验收判定只有一条，可以只保留业务需求与子需求两层，把角色场景写进背景，把验收条件直接挂在子需求下。强行套用四层会让字段填写变成形式，增加评审负担而不增加信息。
执行任务拆解与本文需求层级是两件事。本文的子需求回答“交付什么、怎么算完成”，任务拆解回答“由谁在什么时间做哪些步骤”。把任务拆解写进子需求，会让需求层混入排期与人员信息，变更时难以区分是需求范围变了还是执行安排变了。任务拆解应另按任务管理的方式组织。
跨研发对象的需求追溯与覆盖管理属于另一主题。当需求需要关联到设计、代码提交、测试用例并检查覆盖情况时，涉及追溯关系的建立与覆盖度统计，本文的层级写法只提供分解结构，不展开追溯方法。
示例中的字段可以按团队规范增删。优先级、负责人、目标版本等字段是否出现在需求层，取决于团队的评审习惯与发布节奏。本文示例展示的是分解所需的最小字段集，不构成强制模板；团队可以在此基础上增加字段，也可以精简表述，只要保持每层对象、范围与验收条件清晰即可。
常见问题
需求分解时，子需求拆到多细就该停？
停下来的判断标准是“能否独立排期与验收”。当一个子需求可以单独进入排期、单独判定完成，并且验收条件只描述它自己的交付结果时，就到达了需求层的合适粒度。继续往下拆会进入开发任务层，涉及人员分工与工时估算，属于任务拆解的范围。
如果两个子需求必须同时完成才能验收，说明切分点选错了，应合并或重新按交付内容划分。
业务需求层可以写具体方案吗？
业务需求层写目标与成功度量，具体交互方案留给子需求层。原因是方案会随评审和设计调整，若写进业务需求源头，每次交互变化都要改动上层需求，层级之间的对应关系容易混乱。
当业务目标本身包含明确的合规或流程约束时，可以把约束写成范围边界，方案细节仍放在子需求中描述。
需求变更后，编号和验收条件怎么维护？
新增交付内容时新增子需求并分配新编号，不复用已关闭子需求的编号；删除子需求时保留编号记录并标注取消原因，让历史验收条件仍有归属。重新编号只在层级结构调整时进行，并同步更新验收条件的对应关系。
验收条件与子需求成对出现，子需求拆分或合并时，验收条件随之调整，避免一条验收条件跨多个子需求。
团队已有需求模板，还需要按这个示例改吗？
示例展示的是分解所需的最小字段集，不构成强制模板。团队可以在现有模板上对照检查三点：每层是否有明确的对象与范围，每个子需求是否有可判定的验收条件，父子关系是否能通过编号回溯。
优先级、负责人、目标版本等字段是否出现在需求层，取决于团队的评审习惯与发布节奏，按需增删即可。
用管理工具承载需求层级时，重点看什么？
重点看三件事：不同层级能否作为不同类型的工作项建立父子关联，子需求能否在各自状态间独立流转，验收条件能否随状态推进被逐条确认。以 ONES 为例，业务需求、用户需求、子需求可分别作为工作项类型建立父子关联，验收条件作为子需求的完成判定字段或检查项随状态推进确认。
是否采用这种承载方式，取决于团队已有的需求管理流程与工具习惯，工具承载的是层级与状态，分解规则本身仍需团队约定。
