业务-产品-系统-子需求是需求分解中常用的一种四层结构：业务层说明为什么做、服务哪类业务目标；产品层说明做什么、面向哪类用户与场景；系统层说明由哪些系统或模块承载、边界在哪里；子需求层说明具体可交付、可验收的改动。下面用一条演示需求走完四层填写，并说明每层的拆分依据、换场景时的调整方法，以及落地前需要确认的边界。
要点总览（TL;DR）
- 业务-产品-系统-子需求四层分别回答“为什么做、做什么给谁用、由哪些系统承载、具体改什么如何验收”，用来源字段串成一条可追溯的链路。
- 示例以“缩短新客户开通等待时间”演示四层填写：业务层写受益角色与成功判断，产品层写能力与目标用户，系统层写承载模块与边界，子需求层写可独立交付验收的改动。
- 层数可增减：单一系统的小需求可省略系统层，多系统协同可增加模块层；来源、负责人、验收口径、状态四类字段建议保留，其余按流程裁剪。
- 选用前先判断需求是否跨越业务目标与系统实现、是否有多个角色分层评审、是否需快速判断变更影响，满足两点以上再套四层结构。
- 示例为演示情景，不构成对具体工具层级与字段能力的结论，落地前需结合团队流程和实际环境确认。
这个四层示例要解决什么问题
本文要回答一个具体问题：拿到一条来自业务侧的需求时，怎样把它写成业务、产品、系统、子需求四层，让每一层都能被上一层解释、被下一层承接。示例按“业务目标—产品能力—系统模块—子需求条目”的顺序逐层填写，每层保留来源、负责人、验收口径和状态字段，读者可以对照自己的需求直接套用表格结构。
需要先说明示例的性质：文中的业务背景、角色名称、系统模块和数值均为演示情景，用于展示填写方式，不代表任何真实客户案例，也不包含实测效果或量化收益。读者应关注字段的组织方式和拆分判断，而非示例中的具体内容。
本文的范围限定在需求层级的填写与拆分。把子需求继续拆成设计、开发、测试任务，以及跨研发对象的需求追溯与覆盖管理，属于另外的管理动作，本文只在衔接处点到为止，不展开具体做法。这样安排是为了让示例聚焦在“一条需求如何分层写清楚”这一件事上。
完整示例：一条业务需求拆到子需求
演示情景设定为一家提供在线服务的团队，业务侧提出“缩短新客户开通服务的等待时间”。这条需求经过产品与系统两层的细化，最终落到三条可交付的子需求上。下表按四层顺序给出填写结果，父子关系通过“上级来源”字段串联。
| 层级 | 条目名称 | 核心内容 | 上级来源 | 负责人 | 验收口径 | 状态 |
|---|---|---|---|---|---|---|
| 业务层 | 缩短新客户开通等待时间 | 业务目标：将新客户从签约到可用的等待时间压缩，受益角色为销售与客户成功团队；成功判断为开通环节的客户催问明显减少、销售能向客户给出明确的开通预期 | 业务方年度经营目标 | 业务负责人 | 业务方确认开通预期可对外承诺 | 已确认 |
| 产品层 | 开通进度可视化与自助查询 | 产品能力：为客户成功团队和客户提供开通进度查询入口，覆盖签约后到服务可用前的场景；目标用户为内部客户成功专员与外部客户联系人 | 业务层条目 | 产品经理 | 两类用户均能查到当前所处环节与预计完成时间 | 评审中 |
| 系统层 | 开通流程状态服务与查询页面 | 承载系统：开通流程状态服务负责汇总各环节状态，客户门户提供查询页面；边界为只读取状态、不改变开通流程本身；依赖开通流程各环节回传状态 | 产品层条目 | 系统负责人 | 状态服务能覆盖开通全流程环节，页面可展示 | 设计中 |
| 子需求 | 状态回传接口对接 | 具体改动：开通流程各环节按约定格式向状态服务回传当前环节与时间戳 | 系统层条目 | 后端开发 | 各环节回传字段完整，缺失时有告警 | 待开发 |
| 子需求 | 状态汇总与预计时间计算 | 具体改动：状态服务汇总各环节状态，按历史环节耗时给出预计完成时间 | 系统层条目 | 后端开发 | 给定一组环节状态，能输出当前环节与预计完成时间 | 待开发 |
| 子需求 | 客户门户开通进度页 | 具体改动：客户门户新增进度页，展示当前环节、已用时间与预计完成时间 | 系统层条目 | 前端开发 | 页面在客户联系人账号下可访问，信息与状态服务一致 | 待开发 |
这张表体现了两条关系：纵向看，每条下级条目都在“上级来源”中指向唯一的上级，形成一条从业务目标到具体改动的链路；横向看，每层都有自己的负责人和验收口径，验收口径的写法随层级变化——业务层验收的是业务方能否对外承诺，子需求层验收的是具体功能行为是否符合约定。
逐层解释：每层写什么、为什么这样拆
业务层与产品层的区分依据
业务层回答“为什么做”，写法应落到业务对象和业务结果上，例如哪类角色受益、哪个业务环节要改善、业务方用什么现象判断做成了。示例中业务层没有出现任何系统名称，因为这一层要能被业务负责人独立评审。产品层回答“做什么、给谁用”，把业务目标转译成一项产品能力，并明确目标用户和使用场景。区分两层的简单判断是：如果一句话里出现“页面、接口、模块”，它大概率属于产品层以下；如果一句话只描述业务角色的处境和期望，它属于业务层。
产品层到系统层的拆分判断
产品层到系统层的拆分依据是承载边界，而非功能数量。示例中的产品能力需要“汇总状态”和“对外展示”两件事，前者由状态服务承担，后者由客户门户承担，两者职责不同、可独立演进，因此系统层写成一个条目、内部区分两个模块，并在边界中写明“只读取状态、不改变开通流程”。如果一项产品能力只由一个系统承载，系统层可以只写一条；如果涉及多个团队分别维护的系统，则应按系统分别列出，并注明相互依赖。
系统层到子需求的粒度控制
子需求的粒度标准是“可独立交付、可独立验收”。示例把系统层拆成接口对接、状态汇总与预计时间计算、门户页面三条，每条都能由一名负责人完成并单独验证，合起来才构成系统层的完整能力。粒度太粗会让验收含糊，例如只写“完成开通进度功能”；粒度太细则会滑向任务拆解，例如把“写接口文档”也列为子需求。一个实用的检验方法是问：这条子需求完成后，能否对照验收口径给出通过或不通过的结论。
来源、负责人、验收口径与状态字段的作用
四类字段各自承担不同职责。来源字段保证向上追溯，任何一条子需求都能回答“为什么做这件事”；负责人字段保证向下分派时有明确承接人，避免多人共管导致无人推进；验收口径字段让每层在完成时有可核对的依据，且不同层级的验收主体不同；状态字段让业务方、产品、系统各方看到同一条链路的进展。缺少来源，需求会在传递中丢失业务理由；缺少验收口径，完成与否只能靠口头确认。
示例中关键取舍的解释
示例刻意把“预计完成时间”放在子需求层而非产品层，因为它是具体计算逻辑，产品层只承诺“用户能查到预计时间”这一能力。示例也没有在系统层下再设模块层，因为两个模块的职责已经能在一条系统条目内说清，增加一层只会提高维护成本。这些取舍说明：层级服务于沟通，而不是追求结构完整。
换一个场景怎么套用这套层级
这套四层结构的核心是“每层回答一个不同的问题”，层数和字段都可以按场景调整，调整时保持问题不重叠即可。
层级可增减的适用情形
- 小团队或单一系统内的需求，可省略系统层，由产品层直接拆到子需求，此时产品层需补充承载模块信息。
- 多系统协同的大型项目，可在系统层下增加模块层，再拆子需求，但每增加一层都要确认它承担了新的回答任务。
- 业务目标非常明确的内部优化需求，业务层可以写得简短，但仍需保留受益角色和成功判断，否则后续无法判断优先级。
- 纯技术类需求（如性能优化）可由系统层直接承接业务层的稳定性目标，产品层写清受影响的产品场景即可。
字段按团队与流程裁剪的方法
字段裁剪的原则是保留能支撑决策的最小集合。来源、负责人、验收口径、状态四类字段建议保留，它们分别对应追溯、分派、验收和同步四个动作。可以按流程增加优先级、目标版本、关联工单等字段；可以精简的是描述性字段，例如把“背景说明”合并进业务层内容。裁剪后应检查一遍：任意一条子需求能否沿来源字段走回业务层，能否找到唯一负责人，能否对照口径验收。
选用该结构前的判断条件
在决定采用四层结构前，可以先确认三点：需求是否涉及业务目标与系统实现之间的明显跨度；是否有多个角色需要分别评审不同层级；是否需要在需求变更时快速判断影响范围。三点中满足两点以上，四层结构的收益比较明显。如果需求本身只涉及一个系统内的小改动，直接用子需求条目加来源说明即可，强行套四层会增加填写负担。
与任务拆解、追溯管理的衔接点
子需求确认后，团队通常会继续拆成设计、开发、测试任务，此时子需求成为任务的上游依据，验收口径可直接作为测试用例的来源。在追溯管理方面，来源字段是向上追溯的起点，状态字段是向下同步的载体。ONES 提供业务、产品经理与研发团队三大视角，并通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发；对于功能复杂的需求，可利用子工作项进行拆解并关联研发和测试任务。若团队希望把上述四层落到同一套工作项体系中，可据此评估层级与字段的组织方式，具体配置需结合实际流程确认。
使用这套示例的边界与注意事项
这套示例是填写方法的演示，不构成对任何具体工具能力的结论。工具是否支持固定四层层级、子项可嵌套几层、字段能否自定义，需要以实际环境和官方说明为准，本文不对版本、价格或认证作判断。
- 层级过深的风险：每增加一层，维护来源与状态的工作量都会上升，层级过多时容易出现中间层长期不更新、追溯链路名存实亡的情况。判断标准是这一层是否有人真正阅读和评审。
- 层级过浅的风险：把业务目标和系统改动压在同一层，会导致业务方无法参与评审、技术方案缺少业务依据，需求变更时也难以判断影响范围。
- 字段缺失的影响：缺少来源字段，子需求在交接后容易失去业务理由；缺少验收口径，完成标准依赖口头共识；缺少负责人，多条子需求并行时容易出现空档；缺少状态字段，各方对进展的判断不一致。
- 落地前需确认的事项：团队由谁评审业务层、谁确认系统边界、子需求的验收由谁执行；需求变更时哪一层需要同步更新；现有工具中层级与字段如何对应。这些事项确定后，再按示例填写，结构才能真正运转起来。
把示例当作模板使用时，建议先用一条真实需求完整走一遍四层填写，检查每层是否都有独立负责人和可核对的验收口径，再决定是否推广到更多需求。
常见问题
业务层和产品层经常写混，有没有更直接的区分办法？
可以用“句子中是否出现系统名词”做快速判断：只描述业务角色的处境、期望和判断现象的内容放在业务层；出现页面、接口、模块、流程配置等内容时，通常已经进入产品层及以下。另一个检验方法是看评审人：业务层应能由业务负责人独立评审通过，产品层则需要产品经理与目标用户代表共同确认。两层写混往往是因为业务层里提前写了实现方式，导致业务方无法判断目标是否达成。
团队规模小、只有一个系统，还需要保留系统层吗？
可以省略系统层，由产品层直接拆到子需求，但要在产品层条目中补充承载模块和边界说明，避免后续开发时对改动范围产生分歧。省略系统层的前提是这项需求确实只涉及一个系统、一个团队维护。一旦需求牵涉到另一个团队负责的系统或外部依赖，建议恢复系统层，把依赖关系写清楚，否则子需求交接后容易出现责任空档。
子需求拆到什么程度算合适，怎样避免变成任务清单？
判断标准是“可独立交付、可独立验收”：每条子需求完成后，能对照验收口径给出通过或不通过的结论。如果一条子需求只能由某个人在某个时间段内完成、无法单独验证结果，它更接近任务而非子需求。出现“写文档”“开评审会”这类动作时，说明已经滑向任务拆解，应上移到任务层管理。子需求确认后再拆设计、开发、测试任务，子需求的验收口径可以直接作为测试用例的来源。
需求变更时，四层结构里应该从哪一层开始改？
先判断变更影响的是业务目标、产品能力还是实现方式。业务目标变化时从业务层改起，并逐层检查下级条目是否仍然成立；产品能力范围变化时从产品层改起，同步调整系统层边界和子需求；只是实现方式调整时，改动集中在系统层与子需求层，业务层和产品层保持不变。无论从哪层开始，都要沿来源字段向下同步状态，避免上层已更新、下级条目仍停留在旧口径。
把四层结构落到工具里，需要重点确认哪些配置？
需要确认三件事：工具中的工作项类型能否对应四层并建立父子关联；来源、负责人、验收口径、状态等字段能否按层配置；子项可嵌套的层数是否满足团队需要。ONES 提供业务、产品经理与研发团队三大视角，通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发；对于功能复杂的需求，可利用子工作项进行拆解并关联研发和测试任务。具体层级模板与字段配置需结合实际环境和官方说明确认。
