需求分解是把一条粗粒度需求按“业务目标—用户场景—可交付需求项—验收条件”逐层拆开，直到每一项都能单独估算、排期和验收。本文给出一套可直接执行的做法：先定层级与字段，再按五步操作，明确各角色交付物，最后用检查清单判定是否合格。讨论范围限于需求层级分解，执行层面的任务拆解与跨对象追溯不在本文展开。
要点总览（TL;DR）
- 需求分解按“业务目标—用户场景—可交付需求项—验收条件”四层展开，层数可按团队规模裁剪，但每层的必填字段不能省。
- 操作上按五步执行：确认目标与边界、拆出用户场景、拆成可独立交付的需求项、写验收条件、评审颗粒度并回填父子关系，每步都有明确的完成标志。
- 需求提出人确认目标，产品负责人主导拆分与评审，研发负责人判断可交付性并估算，测试负责人审核验收条件可验证性，评审决议需书面记录。
- 分解合格的判定标准是：每条需求项能独立估算排期、无重复交叉、验收条件可被测试直接转成用例、场景覆盖全部成功指标、编号与父子关系完整可追溯。
- 目标未确认、条目无法估算、验收条件缺失或场景覆盖不全时，应阻断进入排期并返工。
先定层级：需求分解分几层、每层写什么
动手拆之前，团队要先对“拆到哪一层、每层写什么”形成统一约定。层级不统一，后续估算和验收就会各说各话。推荐四层模型：业务目标层、用户场景层、需求项层、验收条件层。层数可以按团队规模和交付节奏裁剪，但裁剪的是层，不是字段。
划分依据是每层回答的问题不同。业务目标层回答“为什么做、做到什么算成功”；用户场景层回答“谁在什么情况下使用”；需求项层回答“交付什么、能独立完成什么”；验收条件层回答“怎么证明做对了”。上一层是下一层的来源，下一层是上一层的落地。
| 层级 | 回答的问题 | 必填字段 | 拆分依据 |
|---|---|---|---|
| 业务目标层 | 为什么做、成功标准是什么 | 目标标题、背景描述、来源、优先级、成功指标 | 一条原始需求对应一个目标，不按功能拆 |
| 用户场景层 | 谁在什么条件下完成什么任务 | 场景标题、角色、触发条件、操作路径、来源目标编号 | 按角色或使用路径拆，一个场景对应一类完整任务 |
| 需求项层 | 交付什么、能否独立完成 | 需求项标题、描述、来源场景编号、优先级、估算口径 | 按可独立开发、独立测试拆，一项对应一个可交付结果 |
| 验收条件层 | 怎么证明做对了 | 验收条件描述、验证方式、边界与异常情况 | 按可观察结果写，一条需求项对应一组验收条件 |
层级数量按交付节奏裁剪。小团队、短迭代可以把业务目标层与用户场景层合并为一条“目标场景说明”，需求项层和验收条件层保留；需求量大、跨角色协作多的团队则保留四层，避免场景遗漏。裁剪原则是：只要还有人需要据此判断“做不做、做什么、做完没有”，这一层的信息就不能省。
编号与父子关联要一次定好规则。建议采用“目标编号—场景序号—需求项序号”的层级编号，例如 G01-S02-R03，编号一经分配不随排序变化而改动。每条需求项只挂一个父场景，跨场景共用的能力单独建一条需求项并在描述中注明被哪些场景引用，避免同一需求重复挂载导致统计口径混乱。
需求分解的操作步骤：从一条原始需求到可验收条目
层级规则确定后，按以下五步顺序执行。每一步都明确输入、动作、输出和完成标志，前一步的输出即后一步的输入。
第一步：确认原始需求的业务目标与边界
输入是需求提出人提交的原始需求描述。动作是与提出人核对三件事：要解决什么业务问题、成功如何衡量、本次明确不做什么。输出是一段可评审的目标说明，包含成功指标和范围边界。完成标志是提出人确认目标描述无歧义，且边界外的事项已书面列出。
第二步：拆出用户场景或使用路径
输入是确认后的目标说明。动作是按角色和触发条件列出使用路径，每条路径写清谁、在什么情况下、完成什么任务、期望结果是什么。输出是场景清单，每个场景带来源目标编号。完成标志是场景清单能覆盖目标说明中的全部成功指标，且没有两个场景描述同一类任务。
第三步：把场景拆成可独立交付的需求项
输入是场景清单。动作是沿每条使用路径识别可独立开发、独立测试的交付点，一个交付点建一条需求项，写清描述、来源场景编号和优先级。输出是需求项清单。完成标志是每条需求项都能被单独估算工作量，且不存在“一条需求项横跨多个场景、无法判断何时算完成”的情况。
第四步：为每个需求项写验收条件
输入是需求项清单。动作是逐条写出可观察的验收条件，覆盖正常路径、边界值和异常情况，并注明验证方式（演示、测试用例或数据核对）。输出是带验收条件的需求项。完成标志是测试人员仅凭验收条件就能设计测试用例，无需再向产品负责人追问预期结果。
第五步：评审颗粒度并回填父子关系
输入是完整的需求项与验收条件。动作是组织评审，检查颗粒度是否一致、父子关系是否挂全、编号是否连续，发现过粗的条目当场拆细，过细的合并。输出是评审通过、层级关系完整的需求结构。完成标志是评审决议记录在案，所有需求项都能沿编号追溯到所属场景和目标。
分解结果需要有地方承载层级、验收条件和评审记录。在 ONES 中，功能复杂的需求可利用「子工作项」进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；产品负责人可按优先级把待办需求规划到对应迭代，在迭代计划会议上与团队共同评审。这样，第三步产出的需求项和第四步写下的验收条件就有了统一的状态与归属，评审结论也能随工作项流转保留。
角色分工与各环节交付物
需求分解涉及四类角色，各自在不同层级承担不同交付物。分工不清时，最常见的问题是验收条件由产品单方面写完、测试到提测阶段才发现口径不一致。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求提出人 | 说明业务问题、确认目标与边界 | 原始需求描述、目标确认意见 | 第一步开始前与完成后 |
| 产品负责人 | 主导场景拆分与需求项定义，组织评审 | 目标说明、场景清单、需求项清单、评审决议 | 第二至第五步 |
| 研发负责人 | 判断需求项能否独立交付，参与估算 | 颗粒度意见、工作量估算 | 第三步输出后、第五步评审时 |
| 测试负责人 | 审核验收条件可验证性，据此设计用例 | 验收条件补充意见、测试用例 | 第四步输出后、第五步评审时 |
评审会议建议由产品负责人主持，需求提出人、研发负责人、测试负责人参加。会议只做三件事：确认目标与边界、逐条过需求项的颗粒度、确认验收条件可验证。决议记录写明通过项、待修改项和责任人，待修改项明确返工期限，避免评审结论停留在口头。
需求变更时，层级关系由产品负责人维护：新增场景挂到对应目标下，新增需求项挂到对应场景下，取消的需求项保留编号并标注状态，不直接删除，以便追溯历史口径。研发和测试发现验收条件无法验证时，反馈给产品负责人补充，由测试负责人复核后更新。
示例：一条“订单导出”需求如何拆到可验收
以下为演示情景，用于说明层级与验收条件的写法，不代表真实客户案例。
原始需求：运营人员反映对账效率低，希望系统支持导出订单数据。业务目标层记为 G01“将对账数据准备时间从人工整理缩短为系统导出”，成功指标是运营能按日、按状态导出订单并直接用于对账，边界是本次不做自动对账，只做数据导出。
用户场景层拆出两条：S01“运营按日期范围导出订单用于日终对账”，S02“客服按订单状态导出异常订单用于核查”。两条场景角色和触发条件不同，分别挂到 G01 下。
需求项层继续拆分。S01 下拆出 R01“按日期范围筛选并导出订单列表”、R02“导出文件包含对账所需字段”；S02 下拆出 R03“按订单状态筛选并导出”。每条需求项都能独立开发和测试，编号形如 G01-S01-R01。
验收条件层示例：R01 的验收条件写为“选择起止日期后导出，文件行数与列表筛选结果一致；起止日期为空时提示必填；跨月范围导出不报错”。R02 写为“导出文件包含订单号、下单时间、金额、状态四列，列名与页面一致”。R03 写为“按状态筛选后导出，文件仅含所选状态订单；无匹配数据时导出空文件并给出提示”。
颗粒度判断依据是：每条需求项对应一个可独立演示的结果，验收条件能被测试直接转成用例。如果 R01 和 R02 合并成一条，测试无法判断“字段缺失”和“筛选错误”分别何时算完成，因此保持拆分。
在 ONES 中，这类拆解可通过子工作项承载父子层级，并在需求与验收标准达成一致后，由设计、研发、测试人员用子任务继续拆分以便跟踪；测试工程师依据迭代内需求与验收标准编写并执行测试用例。层级关系与验收口径因此落在同一处，评审和变更都有据可查。
完成检查：分解到什么程度算合格
分解完成后，用以下清单逐项核对。任一项不通过即视为未完成，需返工后再进入排期。
- 颗粒度检查：每条需求项能否被单独估算工作量并排入一个迭代？存在无法估算或必须与其他项捆绑才能交付的条目，需继续拆分或合并。
- 唯一性检查：是否存在两条需求项描述同一交付结果，或两条场景交叉覆盖同一任务？重复项合并，交叉项明确归属。
- 可验收性检查：每条需求项是否都有可观察的验收条件，且测试人员无需追问即可设计用例？缺少边界和异常情况的，补充完整。
- 完整性检查：场景清单是否覆盖目标说明中的全部成功指标？有指标无对应场景的，补拆场景。
- 层级与编号检查：每条需求项是否只挂一个父场景，编号是否连续可追溯？重复挂载或断号需修正。
出现以下情况应阻断进入排期：目标或边界未获提出人确认；存在无法估算的需求项；验收条件缺失或不可验证；场景覆盖不全导致成功指标无落点。返工由产品负责人牵头，涉及颗粒度的问题与研发负责人确认，涉及验收口径的问题与测试负责人确认，修改后重新走第五步评审。
常见问题
需求层级一定要分四层吗？小团队能不能只分两层？
层数可以裁剪，常见做法是小团队、短迭代把业务目标层与用户场景层合并成一条“目标场景说明”，保留需求项层和验收条件层。判断依据是信息是否还有人用：只要仍有人据此判断“做不做、做什么、做完没有”，对应信息就不能省。裁剪的是层，不是字段，成功指标、来源编号、验收口径这些内容仍需写清。
一条需求项同时被多个场景用到，父子关系怎么挂？
建议为这条共用能力单独建一条需求项，挂在一个主场景下，并在描述中注明被哪些场景引用，其他场景通过引用关系关联，不重复建条目。这样统计工作量时不会重复计算，追溯时也能看到全部使用方。编号一经分配不随排序调整，避免历史记录对不上。
评审会上意见不一致，验收条件由谁定？
验收条件的业务口径由产品负责人牵头确定，测试负责人负责审核其可验证性，即能否仅凭条件设计出测试用例。出现分歧时，回到业务目标层的成功指标判断：哪种写法能证明目标达成，就采用哪种。会议决议要写明通过项、待修改项、责任人和返工期限，避免结论停留在口头。
需求中途变更，已经拆好的层级怎么维护？
由产品负责人维护层级关系：新增场景挂到对应目标下，新增需求项挂到对应场景下；取消的需求项保留编号并标注状态，不直接删除，以便追溯历史口径。研发或测试发现验收条件无法验证时，反馈给产品负责人补充，测试负责人复核后更新，更新后重新走评审确认。
分解完成后，需求项在工具里怎么承载层级和验收条件？
分解结果需要落到能保留父子关系和状态流转的地方。在 ONES 中，功能复杂的需求可利用「子工作项」进行拆解，并关联研发和测试任务；产品负责人可按优先级把待办需求规划到对应迭代，在迭代计划会议上与团队共同评审；需求与验收标准达成一致后，设计、研发、测试人员可用子任务继续拆分以便跟踪，测试工程师依据迭代内需求与验收标准编写并执行测试用例。
