需求分解规则要解决的核心问题，是让不同角色对“拆到哪一层、拆到什么程度、由谁确认”形成一致理解。本文围绕需求层级与分解规则制定，依次说明层级定义、拆分粒度与字段、角色与评审机制，并用一条业务需求走通拆分过程，最后给出可逐项核对的完成检查清单。执行任务拆解与排期不在本文范围内。
要点总览（TL;DR）
- 需求分解规则先定层级：业务需求回答为什么做，用户需求回答谁在什么场景要完成什么，系统/子需求回答系统提供什么能力，相邻两层的问题不能重叠。
- 拆分粒度用三条标准判断：可独立验收、可归属单一负责人、可对应一个明确交付物，三条同时满足即可停止拆分。
- 字段规范决定拆分结果是否可比，必填项至少包括编号、标题、层级、父需求、验收标准、优先级和来源，父子关系采用单父挂靠。
- 评审设拆分完成评审、进入开发前确认、变更时复审三个节点，变更权限按字段划分，规则文档指定维护人并按固定节奏评估修订。
- 规则是否可用，用一条真实需求走通拆分—评审—落地—回查，再按检查清单核对层级覆盖、粒度一致、变更可追溯等条目。
先定层级：需求分几层、每层回答什么问题
层级设计从“每层回答什么问题”入手，比先定层数更有效。常见做法是两层或三层：两层为业务需求—产品需求，三层为业务需求—用户需求—系统/子需求。层数取决于业务复杂度与交付链条长度，判断标准是相邻两层回答的问题是否重叠。如果两层都在描述“用户要完成什么”，说明层级职责没有分开。
每层需要明确回答对象。业务需求回答“为什么做、为哪类业务目标服务”，来源通常是业务方或管理层；用户需求回答“谁在什么场景下要完成什么”，来源是用户研究、业务反馈或工单；系统/子需求回答“系统提供什么能力来支撑上述场景”，来源是产品与研发的共同分析。颗粒度随层级下降而变细，但变细的程度由下一节的拆分标准约束，不靠感觉判断。
需要区分需求层级与任务拆解。需求层级描述“要做成什么”，任务拆解描述“由谁在什么时间怎么做”。一条系统需求可以对应多个开发任务，这些任务属于执行计划，不进入需求层级表。把任务写进需求层级，会让需求条目失去验收意义。
| 层级名称 | 回答的问题 | 典型颗粒度 | 上游来源 | 下游去向 |
|---|---|---|---|---|
| 业务需求 | 为什么做，支撑哪个业务目标 | 一个业务目标或业务场景，可覆盖多条用户需求 | 业务方、管理层、市场反馈 | 拆分为用户需求 |
| 用户需求 | 谁在什么场景下要完成什么 | 一类用户角色在一个场景下的完整诉求 | 业务需求、用户研究、工单反馈 | 拆分为系统/子需求 |
| 系统/子需求 | 系统提供什么能力支撑该场景 | 可独立开发与验收的一项系统能力 | 用户需求、产品分析 | 进入开发与测试，关联任务 |
层级过多会让填写成本上升，评审时难以判断每条需求该放哪一层；层级过少则业务目标与系统能力混在一条记录里，验收标准写不清。取舍方法是：先按现有交付流程画一遍从业务提出到开发接手的路径，路径上每个需要不同角色确认的节点，通常对应一个层级。
拆分规则怎么写：粒度、字段与父子关系
拆分规则要写成可检查的条目，每条规则包含触发条件、判断标准和检查动作。先定触发条件：当一条需求无法由单一负责人在一个交付周期内完成验收时，必须继续拆分；当一条需求包含两个以上可独立验收的能力时，必须拆成多条子需求；当需求描述中出现“以及”“同时支持”等并列内容且各部分验收方式不同时，应拆开。
粒度判断用三条可操作标准：可独立验收，即这条需求有明确的验收标准且不依赖兄弟需求的完成；可归属单一负责人，即能指定一位对结果负责的人；可对应一个明确交付物，即能说清交付的是页面、接口、规则配置还是数据报表。三条同时满足即可停止拆分，任一条不满足则继续拆或补充信息。
字段规范决定拆分结果是否可比。必填字段建议包括：需求编号、标题、层级、父需求、验收标准、优先级、来源。选填字段可包括：目标用户、关联业务目标、预计交付时间、关联工单号。验收标准要写成可验证的陈述，避免“体验良好”“性能优化”这类无法判定的表述。
| 字段 | 必填/选填 | 填写要求 |
|---|---|---|
| 需求编号 | 必填 | 按层级前缀加流水号，全局唯一，创建后不随层级调整而改变 |
| 标题 | 必填 | 一句话说明交付内容，不含实现方案 |
| 层级 | 必填 | 从层级定义表中取值，不允许自造层级名 |
| 父需求 | 必填（顶层除外） | 只填一个直接父需求，不跨层挂靠 |
| 验收标准 | 必填 | 可验证的条件，逐条列出 |
| 优先级 | 必填 | 按统一档位取值，与父需求优先级保持可解释关系 |
| 来源 | 必填 | 业务方、工单号、用户研究记录等可回溯信息 |
| 目标用户 | 选填 | 主要服务的角色或人群 |
| 关联工单号 | 选填 | 用于回溯原始反馈 |
父子关系采用单父挂靠：每条需求只归属一个直接父需求，需要表达多目标关联时，用关联字段或标签记录，不重复创建条目。编号规则与层级绑定，例如业务需求用 BR 前缀、用户需求用 UR 前缀、系统需求用 SR 前缀，流水号在各自层级内连续。层级调整时保留原编号并记录调整原因，便于回查。
拆分完成后做两项检查：一是覆盖检查，逐条对照父需求的验收标准，确认每条标准都有子需求承接；二是重复检查，按标题关键词和验收标准比对同级需求，发现描述重叠的合并或明确边界。检查由需求负责人执行，评审时抽查。
角色与评审机制：谁拆、谁审、谁改
角色划分围绕“提出、负责、参与、召集”四类职责。需求提出人负责说明业务背景和期望结果；需求负责人（通常由产品角色担任）负责按规则拆分、填写字段、维护父子关系；研发与测试代表参与拆分评审，确认可实现性与可测试性；评审召集人负责组织评审、记录结论、跟踪不通过项的修正。
评审设置三个节点。拆分完成评审：需求负责人提交拆分结果，评审人对照粒度标准和字段清单逐项检查，输出通过或不通过结论及修改意见。进入开发前确认：研发与测试确认验收标准可验证、依赖关系清楚，确认后需求状态进入待开发。变更时复审：需求层级、父需求、验收标准发生变更时触发复审，由原评审召集人组织，范围限于受影响条目。
评审通过标准写成条目：层级取值合法、必填字段完整、验收标准可验证、父子关系单挂靠、覆盖检查无遗漏。任一条不满足即不通过，由需求负责人修正后重新提交，修正记录保留在需求条目中。变更权限按字段划分：层级调整由需求负责人提出、评审召集人确认；父需求调整由需求负责人操作并通知原父需求负责人；需求关闭由需求负责人确认验收结果后执行，关闭前需有验收记录。
| 角色 | 主要职责 | 在评审中的动作 | 交付物 |
|---|---|---|---|
| 需求提出人 | 说明业务背景与期望结果 | 参加拆分完成评审，确认业务意图未失真 | 业务背景说明、来源信息 |
| 需求负责人 | 拆分需求、填写字段、维护父子关系 | 提交拆分结果，按意见修正 | 需求条目、覆盖检查记录 |
| 研发代表 | 确认可实现性与依赖 | 提出实现风险与技术依赖意见 | 评审意见 |
| 测试代表 | 确认验收标准可测试 | 提出验收标准补充意见 | 评审意见 |
| 评审召集人 | 组织评审、记录结论、跟踪修正 | 宣布通过结论，登记不通过项 | 评审记录、修正跟踪表 |
规则本身也需要维护责任人。建议由需求负责人所在团队指定一人负责规则文档的版本管理，收集试运行中的问题，按固定节奏（例如每季度或每完成一轮迭代复盘）评估是否需要修订。修订时记录变更条目、生效时间和影响范围，避免规则与实际做法脱节。
在工具承载上，需求层级、父子关系、字段与评审状态需要落在同一处，才能让规则可执行。ONES 提供业务需求池与产品需求池，并支持用子工作项对功能复杂的需求进行拆解、关联研发和测试任务；产品负责人可按优先级把需求规划到迭代，在迭代计划会议上完成需求评审；工作流可按实际场景自定义，用于规范需求流转。规则中的层级命名、字段必填范围和评审节点，需要结合团队实际配置在工具中落地。
示例：一条业务需求拆到可开发子需求
以下为演示情景，用于说明拆分规则的执行方式，不代表真实项目数据。
原始业务需求（BR-012）：“客服团队希望减少工单重复录入，让客服在处理咨询时能直接看到客户历史工单信息。”这条需求回答的是业务目标：降低客服重复操作、缩短处理时间。它暂时无法直接开发，因为“看到历史工单信息”涉及多个场景和系统能力。
第一层拆分到用户需求。按用户角色和场景拆出两条：UR-031“客服在受理咨询时，能在当前工单页面查看该客户近 90 天的历史工单列表”；UR-032“客服在查看历史工单时，能一键引用历史处理结论到当前工单”。判断依据是两条需求对应不同场景、可分别验收，且都能归属单一负责人。
第二层拆分到系统/子需求。UR-031 拆为 SR-101“工单详情页展示客户历史工单列表组件”、SR-102“按客户标识查询近 90 天工单的接口”；UR-032 拆为 SR-103“历史处理结论引用操作与内容填充规则”。每条子需求填写验收标准，例如 SR-101 的验收标准为“在工单详情页可见历史工单列表，展示工单号、处理结论、完成时间三列，无数据时显示空状态提示”。
评审中发现两个问题：SR-102 的查询范围未说明是否包含已关闭工单，验收标准无法判定；UR-032 与 SR-103 的边界不清，引用规则写在用户需求里会导致重复描述。修正方式是：在 SR-102 验收标准中补充“查询范围包含已关闭工单，按完成时间倒序”；将引用规则的具体内容下沉到 SR-103，UR-032 只保留场景与期望结果。修正后复审通过。
拆分结果交接时，SR-101 至 SR-103 进入待开发状态，各自关联开发任务与测试用例；UR-031、UR-032 保持开启，待子需求验收完成后逐条确认关闭；BR-012 在全部用户需求关闭后确认业务目标达成情况。交接时同步说明依赖关系：SR-101 依赖 SR-102 的查询结果，测试用例需覆盖空状态与有数据两种情形。
完成检查：规则可用的判断清单
规则制定完成后，用一份检查清单判断它是否能被不同角色一致执行。检查项要能给出证据，而不是凭印象判断。
| 检查项 | 通过标准 | 负责人 | 证据 |
|---|---|---|---|
| 层级覆盖 | 现有需求类型都能在层级定义表中找到归属，无“其他”兜底层级 | 规则维护人 | 层级定义表、近一轮需求抽样 |
| 字段完整 | 必填字段清单与需求模板一致，抽查条目无空缺 | 需求负责人 | 字段清单、抽查记录 |
| 粒度一致 | 不同角色对同一批需求按三条标准判断，结论一致率可接受 | 评审召集人 | 一致性比对记录 |
| 评审可执行 | 每个评审节点有明确负责人、输入和输出 | 评审召集人 | 评审记录模板、会议记录 |
| 变更可追溯 | 层级、父需求、验收标准的变更均有操作人和原因记录 | 需求负责人 | 变更日志 |
| 文档受控 | 规则文档有存放位置、版本号和生效时间 | 规则维护人 | 文档版本记录 |
试运行一段时间后做回查，关注三类指标：返工情况，即拆分完成后因粒度或字段问题被退回的比例及原因分布；层级错挂，即评审或开发阶段发现需求放错层级、挂错父需求的次数；评审驳回原因，即不通过项集中在哪些检查条目。回查结果用于修订规则条目，例如某类驳回反复出现，说明对应标准表述不够具体，应补充判断示例。
规则可用的标志是：新加入的需求负责人能按文档独立完成一次拆分并通过评审，评审人能用同一份清单给出可解释的结论，变更发生后能追溯到操作人和原因。达到这三点，规则即可进入常规维护，按既定节奏评估修订。
常见问题
团队规模较小，需求分解规则可以简化到什么程度？
小团队可以减少层级和评审节点，但几项基础内容建议保留：层级定义表（两层即可，业务需求—产品需求）、必填字段清单、单父挂靠的父子关系规则，以及一个明确的拆分完成确认动作。评审可以由需求负责人和研发、测试代表在一次短会中完成，不必单独设评审召集人，但结论和修正意见要记录在需求条目上。规则文档仍需指定维护人，否则试运行中出现的问题无人归集，规则很快与实际做法脱节。
需求拆分后，子需求验收标准与父需求不一致怎么办？
这通常说明拆分时的覆盖检查没有做到位。处理方式是回到父需求的验收标准逐条对照，确认每条标准都有子需求承接；如果子需求新增了父需求未覆盖的验收内容，需要判断是父需求描述不全还是子需求范围溢出，前者补充父需求验收标准，后者将溢出部分拆为独立需求或移出本次范围。修正后重新走一次拆分完成评审，并在需求条目中记录调整原因，便于后续回查。
规则试运行期间，需求负责人频繁在层级归属上产生分歧，如何收敛？
分歧多出现在相邻两层的边界上。可以先收集分歧案例，按“这条需求回答的是业务目标、用户场景还是系统能力”逐条归类，找出层级定义表中表述模糊的地方，补充判断示例而不是增加层级。同时用一致性比对检验：让几位需求负责人对同一批需求独立判断层级，统计结论差异，差异集中的条目就是需要细化的规则点。规则修订后记录变更条目和生效时间，避免新旧做法并行。
需求层级、父子关系和评审状态如何在工具中承载？
规则要能执行，层级、字段和评审状态需要落在同一处，避免在文档和表格之间反复同步。ONES 提供业务需求池与产品需求池，并支持用子工作项对功能复杂的需求进行拆解、关联研发和测试任务；产品负责人可按优先级把需求规划到迭代，在迭代计划会议上完成需求评审；工作流可按实际场景自定义，用于规范需求流转。层级命名、字段必填范围和评审节点需要结合团队实际在工具中配置，具体配置范围以产品实际能力为准。
规则制定完成后，多久评估一次是否需要修订？
建议按固定节奏评估，例如每季度一次，或在每轮迭代复盘时顺带检查。评估依据是回查指标：拆分完成后因粒度或字段问题被退回的比例及原因分布、评审或开发阶段发现层级错挂的次数、评审驳回集中在哪些检查条目。某类驳回反复出现，说明对应标准表述不够具体，应补充判断示例；如果指标平稳且新成员能按文档独立完成拆分并通过评审，可以维持现有规则，只做版本记录。
