需求从业务层逐级分解到产品、系统和子需求，核心是让每一层只回答本层该回答的问题：业务层说清目标、受益对象和成功度量；产品层把目标转成可交付的能力范围与优先级；系统层把能力落到系统边界、接口与约束；子需求层把系统职责拆成可独立实现、可验证的工作单元。每层保留唯一编号、来源链接、验收口径和负责人，分解完成以“下层可独立评审、上层可回溯验证”为标志。下文按四层顺序给出输入、动作、输出与完成标志，并说明颗粒度判断和角色分工。
要点总览（TL;DR）
- 四层分解的核心是让每层只回答本层问题：业务层说清目标与成功度量，产品层转成可交付能力范围，系统层落到系统边界与接口，子需求层拆成可独立实现与验证的工作单元。
- 每层按“输入—动作—输出—完成标志”推进，完成标志统一为下层可独立评审、上层可回溯验证，来源编号贯穿四层。
- 颗粒度判断以能否独立评审、独立实现、独立验收为界，不以工时或人数为界；业务层写界面细节、子需求重复业务目标都属于层级错位。
- 角色分工按层落实：业务负责人、产品负责人、系统负责人、开发与测试分别主责一层，评审时点与交付物状态（草稿、评审中、已确认、变更）同步管理。
- 分解完成后用覆盖性、回溯性、颗粒度、一致性、变更同步五项清单核对，发现问题回到对应层级修正，不在子需求层打补丁。
四层需求各回答什么问题：一张分层定义表
分层分解首先要统一每层的职责边界。层级数量可以按组织规模调整，例如在系统层与子需求之间增加模块层，或在小型团队中合并系统层与子需求层，但相邻两层之间必须保留明确的父子对应关系和来源编号，否则回溯就会断链。
| 层级 | 回答的问题 | 典型产出物 | 颗粒度判断 | 不应包含的内容 |
|---|---|---|---|---|
| 业务需求 | 为什么做、为谁做、做到什么程度算成功 | 业务目标说明、受益角色、成功度量、约束条件 | 以目标与度量收敛：一个业务需求对应一组可观测的业务结果 | 界面细节、技术方案、具体功能清单 |
| 产品需求 | 用哪些可交付的能力支撑该目标，优先级如何 | 产品需求清单、能力范围、优先级、范围边界 | 以可交付能力收敛：一条产品需求对应一块可被用户感知或可被验收的能力 | 系统内部实现方式、接口协议细节 |
| 系统需求 | 该能力由哪些系统承担，边界、接口与约束是什么 | 系统需求条目、所属系统、接口说明、非功能约束、依赖 | 以系统边界与接口收敛：一条系统需求能落到明确的系统责任人 | 重复业务目标、替代产品优先级判断 |
| 子需求 | 系统职责如何拆成可独立实现和验证的工作单元 | 子需求列表、验收条件、依赖、责任人 | 以可独立实现与验证收敛：能单独排期、单独测试 | 重复业务目标、跨系统的整体方案描述 |
判断颗粒度是否合适，可以用一个简单测试：把这条需求交给下一层的负责人，对方能否在不追问上层意图的情况下开始评审或设计。能，说明颗粒度基本到位；不能，说明要么上层信息不足，要么这条需求还混着下一层的内容。业务层写界面细节、子需求重复业务目标，都是层级错位的典型表现。
从业务需求到产品需求：把目标转成能力范围
第一步分解的任务是把业务语言转成产品语言，关键是让每条产品需求都能回答“它支撑哪个业务目标”。
输入：业务需求中已确认的目标、受益角色、成功度量与约束条件。开始分解前，业务负责人和产品负责人需要就成功度量达成一致，度量口径不清会导致后续产品范围反复摇摆。
动作：先识别支撑目标所需的能力域，例如获客、下单、履约、结算这类能力分组；再在每个能力域内划分产品需求，为每条需求标注优先级和范围边界，明确本期做什么、不做什么。划分时以“用户可感知或可验收的能力”为单位，避免把一条能力拆成多个只描述操作步骤的条目。
输出：产品需求清单，每条包含唯一编号、来源业务需求编号、能力描述、优先级、范围边界和产品负责人。
完成标志：每条产品需求都能说明它支撑哪个业务目标；反过来，每个业务目标都有至少一条产品需求承接。出现“有目标无承接”或“有需求无来源”的情况，说明这一步尚未完成。
从产品需求到系统需求：落到系统边界与接口
产品需求描述的是能力，系统需求描述的是由谁来实现这项能力。这一步最容易出问题的地方是跨系统职责划分不清，导致接口双方都以为对方负责。
输入：范围已确认、优先级已标注的产品需求。
动作：按现有系统边界拆分职责，逐条明确该产品需求涉及哪些系统、每个系统承担什么、系统之间传递什么数据、依赖哪些外部条件。同时把非功能约束写进系统需求，例如响应时间、数据保留要求、权限要求。跨系统部分要单独列出接口说明，写明调用方、提供方、数据流向和异常处理约定。
输出：系统需求条目，每条包含所属系统、对应产品需求编号、接口说明、约束条件和系统负责人。
完成标志：系统需求可以交由对应系统负责人评审；接口双方对各自职责没有歧义，评审时不需要再回头讨论“这块归谁”。如果评审中反复出现职责争议，说明系统边界划分需要先解决，而不是继续往下拆。
从系统需求到子需求：拆到可独立实现与验证
最后一层分解的目标是形成可以单独排期、单独测试的工作单元。拆得过粗，开发和测试无法并行；拆得过细，管理成本超过收益。
输入：通过系统负责人评审的系统需求。
动作：按可独立实现、可独立验证的原则拆分子需求。每条子需求写清验收条件，标注与其他子需求的依赖关系，指定责任人。拆分时优先按可交付的行为切分，例如“支持按订单号查询物流状态”比“编写查询接口的控制器层”更适合作为子需求，因为前者可以被独立验收。
输出：子需求列表，每条包含验收口径、依赖、责任人和来源系统需求编号。
完成标志：子需求可以单独排期与测试，并且能回溯到所属系统需求。颗粒度以能否独立验收为界，不以工时或人数为界：一条子需求即使工作量很小，只要无法独立验收，就应考虑与相邻条目合并；反之，工作量大的子需求只要验收边界清晰，也可以保持为一条。
角色分工与各层交付物
分层分解能否持续执行，取决于每层是否有明确的责任人和评审时点。下表给出一种常见分工，组织可按实际岗位名称调整。
| 层级 | 主责角色 | 评审角色 | 评审时点 | 交付物 |
|---|---|---|---|---|
| 业务需求 | 业务负责人 | 业务决策人、产品负责人 | 立项或规划启动时 | 业务目标、成功度量、约束条件 |
| 产品需求 | 产品负责人 | 业务负责人、系统负责人 | 产品规划评审会 | 产品需求清单与来源映射 |
| 系统需求 | 系统负责人 | 产品负责人、接口相关系统负责人 | 系统方案评审 | 系统需求条目与接口职责说明 |
| 子需求 | 开发与测试负责人 | 系统负责人、产品负责人 | 迭代计划或开发启动前 | 子需求列表与验收条件 |
每层交付物建议设置统一的状态：草稿、评审中、已确认、变更。状态流转由主责角色发起，评审通过后进入已确认，已确认的条目才能作为下一层分解的输入。
变更处理需要明确两个方向的责任：向上回溯由发现变更的角色发起，通知受影响的上级需求负责人评估目标或范围是否调整；向下通知由该上级需求负责人执行，把变更同步给所有已分解的下层条目负责人。变更记录保留在原条目上，避免只改下层不改上层造成来源失真。
在工具承载上，ONES 提供业务、产品经理与研发团队三大视角，聚焦需求来源、产品规划及落地交付，并通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发。对于功能复杂的需求，可利用「子工作项」进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；统一的需求池、工单与任务看板可以同步状态与信息，便于追溯需求与问题。这些能力对应的是分层分解后的承载与回溯动作，分层规则本身仍需团队在评审中确定。
一个完整示例：从业务目标拆到子需求
以下为演示情景，用于说明四层写法和颗粒度取舍，不代表真实项目数据。
业务需求（编号 BR-01）：降低企业客户在采购下单环节的流失。受益角色为采购专员与采购经理，成功度量为下单流程完成率提升、下单环节平均耗时下降，约束为不改变现有合同审批规则。
产品需求（编号 PR-01，来源 BR-01）：支持采购专员在下单页保存常用商品清单并一键复用。优先级高，范围边界为本期只覆盖已登录企业客户，不包含跨企业共享清单。这条需求支撑“降低下单流失”目标，因为重复录入是耗时的主要来源之一。
系统需求（编号 SR-01，来源 PR-01）：订单系统提供常用清单的存储与读取能力；商品系统提供商品信息的实时校验接口；权限系统负责清单的企业内可见范围控制。接口说明写明订单系统调用商品系统校验时的入参与失败处理，非功能约束为清单读取响应时间要求。系统负责人分别为订单系统与商品系统负责人。
子需求（来源 SR-01）：子需求一，订单系统支持保存常用清单并返回保存结果，验收条件为保存后再次进入下单页可读取到该清单；子需求二，下单页支持从常用清单一键带入商品，验收条件为带入后商品数量与价格与清单一致；子需求三，商品信息变更时清单内商品标记为待确认，验收条件为变更后清单展示待确认状态且不阻断下单。三条子需求均可独立排期与测试，依赖关系为子需求二依赖子需求一。
颗粒度取舍说明：示例没有把“编写清单存储表结构”单列为子需求，因为它无法独立验收；也没有把整个下单流程优化作为一条子需求，因为范围过大、验收边界不清。每条子需求都标注了来源系统需求编号，保证向上可回溯。
完成检查：分解质量的核对清单
分解完成后，用以下清单逐项核对，全部通过才进入排期与开发。
- 覆盖性：每个业务目标是否都有产品需求承接；每条产品需求是否都有系统需求落地；每条系统需求是否都有子需求覆盖。存在无下层承接的条目时，要么补拆，要么明确标注本期不做的原因。
- 回溯性：随机抽取若干子需求，能否沿来源编号逐级找到所属系统需求、产品需求和业务需求；反向抽取业务目标，能否列出全部承接条目。
- 颗粒度：每条子需求是否可独立排期、独立测试；是否存在明显过粗（无法验收）或过细（仅为操作步骤）的条目。
- 一致性：编号是否唯一且连续；状态是否与实际评审进度一致；每条需求是否都有明确负责人；接口说明的双方是否都已确认。
- 变更同步：近期发生的变更是否同时更新了上下层条目；是否存在只改下层未评估上层的记录；变更通知是否已送达相关责任人。
核对中发现的问题应当回到对应层级修正，而不是在子需求层打补丁。分层分解的质量最终体现在两个可观察的结果上：下层条目可以被独立评审和排期，上层目标可以随时通过来源编号验证覆盖情况。
常见问题
团队规模较小，是否必须保留业务、产品、系统、子需求四层？
层级数量可以按组织规模调整。小型团队可以把系统层与子需求层合并，或在系统层与子需求之间增加模块层，前提是相邻两层保留明确的父子对应关系和来源编号。判断是否可合并的标准是：合并后这一层是否还能同时回答“由谁实现”和“如何独立验收”两个问题。如果合并后评审时仍需反复区分系统职责与实现细节，说明分层还不够清晰，应保留原层级或重新划分边界。
业务目标在分解过程中发生变化，已经拆下去的产品需求和系统需求怎么处理？
变更处理分两个方向：向上回溯由发现变更的角色发起，通知受影响的上级需求负责人评估目标或范围是否调整；向下通知由该上级需求负责人执行，把变更同步给所有已分解的下层条目负责人。变更记录保留在原条目上，避免只改下层不改上层造成来源失真。如果业务目标的成功度量本身发生变化，应回到业务层重新确认，再逐层评估产品范围与系统职责是否需要调整，而不是直接在子需求层修改验收条件。
系统需求评审时接口双方对职责有争议，应该先解决什么？
接口职责争议通常说明系统边界划分尚未完成，此时继续往下拆子需求只会把问题带到开发阶段。建议先回到系统层，逐条明确该产品需求涉及哪些系统、每个系统承担什么、系统之间传递什么数据以及异常由谁处理，形成书面的接口说明并写明调用方与提供方。双方负责人确认后再进入子需求拆分。如果争议涉及产品范围本身，则需要产品负责人先确认范围边界，再重新划分系统职责。
子需求拆到多细比较合适，能否按开发工时来定？
颗粒度以能否独立验收为界，不以工时或人数为界。一条子需求即使工作量很小，只要无法独立验收，就应考虑与相邻条目合并；工作量大的子需求只要验收边界清晰，也可以保持为一条。实际操作中可以用两个测试判断：这条子需求能否单独排期、单独测试；开发和测试能否在不追问上层意图的情况下开始工作。两个测试都通过，颗粒度基本到位。
分层分解完成后，如何用工具承载层级关系并保持可回溯？
分层规则由团队在评审中确定，工具承担的是承载与回溯动作。以 ONES 为例，它提供业务、产品经理与研发团队三大视角，聚焦需求来源、产品规划及落地交付，并通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发；对于功能复杂的需求，可利用「子工作项」进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来。统一的需求池、工单与任务看板可以同步状态与信息，便于追溯需求与问题。具体层级配置与回溯视图的呈现方式，建议结合团队实际流程在试用中确认。
