需求分解结构模板的核心是一张按层级展开的空白表：业务需求、产品需求、系统需求、子需求四层，每行记录层级、编号、名称、来源、验收口径、负责人和状态。使用时先复制空白表，再按字段说明逐列填写，最后用贯穿四层的示例对照检查层级归属是否清晰。本文适用于需要设计或参考需求分解结构的产品、研发与业务协作场景。
要点总览（TL;DR）
- 模板以业务需求、产品需求、系统需求、子需求四层展开，用编号前缀加上级编号在同一张表里建立父子关系。
- 必填字段为层级、编号、上级编号（业务需求除外）、需求名称、验收口径和负责人；描述、来源、状态、备注可按需选填。
- 验收口径要写成可独立核验的条件，与需求描述分工明确，避免两者混写。
- 小团队可先保留必填字段，跨部门协作时再补充来源与备注；层级压缩或增加时同步修改编号规则。
- 模板作为填写规范，需求的实际流转可在 ONES 中通过业务需求池、产品需求池与子工作项承载。
可复制的需求分解结构空白模板
下表为四层需求分解结构的空白模板，可直接复制到文档或表格工具中填写。层级通过“编号”前缀和“上级编号”两列共同体现：编号前缀标识层级，上级编号指向父级行，从而在同一张表内建立父子关系。填写时按业务需求、产品需求、系统需求、子需求的顺序自上而下展开，同一父级下的子行相邻排列。
| 层级 | 编号 | 上级编号 | 需求名称 | 需求描述 | 来源 | 验收口径 | 负责人 | 状态 |
|---|---|---|---|---|---|---|---|---|
| 业务需求 | BR-001 | — | ||||||
| 产品需求 | PR-001 | BR-001 | ||||||
| 系统需求 | SR-001 | PR-001 | ||||||
| 子需求 | SR-001-01 | SR-001 | ||||||
| 子需求 | SR-001-02 | SR-001 |
复制时按实际数量增删行即可。一个业务需求下可以挂多个产品需求，一个产品需求下可以挂多个系统需求，子需求则挂在系统需求之下。若团队习惯用缩进表示层级，可在“需求名称”列前加空格或使用表格工具的缩进功能，但编号与上级编号两列仍需保留，作为机器可读的父子关系依据。
模板字段说明：每一列记录什么
字段口径统一，不同角色填出来的表才能直接比对和汇总。以下逐列说明含义与填写方式。
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 层级 | 该行所属的需求层级 | 只填四个固定值之一：业务需求、产品需求、系统需求、子需求 |
| 编号 | 该需求的唯一标识 | 按层级设前缀：BR、PR、SR，子需求在父级编号后追加两位序号 |
| 上级编号 | 父级需求的编号 | 填写直接父级的编号，业务需求层留空或填“—” |
| 需求名称 | 一句话概括需求 | 用动宾结构，控制在二十字以内，避免与描述重复 |
| 需求描述 | 需求的背景、范围与约束 | 写清要解决什么问题、覆盖哪些场景、有哪些前提条件 |
| 来源 | 需求的提出方或依据 | 记录提出人、部门、工单号、调研记录或合同条款等可回溯信息 |
| 验收口径 | 判断需求完成的依据 | 写成可核验的条件，如指标阈值、操作结果、交付物清单 |
| 负责人 | 对该行需求负责的人 | 填具体姓名或角色，一个需求只设一名负责人 |
| 状态 | 需求当前所处阶段 | 使用团队统一的状态值，如待评审、已确认、开发中、已验收 |
编号规则是整张表的骨架。业务需求用 BR 加三位序号，产品需求用 PR 加三位序号，系统需求用 SR 加三位序号；子需求不另起前缀，直接在所属系统需求编号后追加“-01”“-02”。这样从编号本身就能看出层级和归属，上级编号列则用于校验和检索。
需求描述与验收口径承担不同任务。描述回答“要做什么、为什么做”，允许包含背景和范围；验收口径回答“做到什么程度算完成”，必须能被他人独立核验。例如描述写“支持按部门筛选报表”，验收口径写“选择任一部门后，报表仅显示该部门数据，切换部门后结果在刷新后更新”。
来源字段用于回溯，记录提出方或依据文件，便于后续确认需求变更的合理性。负责人字段明确单一责任人，避免多人都管、无人拍板。状态字段反映流转阶段，团队应约定固定的状态取值，不随意新增同义状态。
必填与选填：哪些字段不能空
必填字段保证需求可识别、可追溯、可验收；选填字段用于补充信息，允许在信息不足时暂缓填写。下表给出各字段的填写要求。
| 字段 | 填写要求 | 说明 |
|---|---|---|
| 层级 | 必填 | 四层中选一，不允许空值 |
| 编号 | 必填 | 全表唯一，按规则生成 |
| 上级编号 | 必填（业务需求除外） | 业务需求层留空或填“—”，其余层级必须指向已存在的父级编号 |
| 需求名称 | 必填 | 不可为空，不可只写“优化”“完善”等无对象词 |
| 验收口径 | 必填 | 没有验收口径的需求不进入开发 |
| 负责人 | 必填 | 填具体责任人，不填部门名称 |
| 需求描述 | 选填 | 业务需求与产品需求建议填写，子需求可省略 |
| 来源 | 选填 | 业务需求建议填写，便于回溯 |
| 状态 | 选填 | 未填时默认视为“待评审” |
| 备注 | 选填 | 记录依赖、风险或待确认事项 |
子需求层可以精简字段：需求描述、来源通常可省略，保留层级、编号、上级编号、需求名称、验收口径、负责人即可。子需求的验收口径可以写得更具体，直接对应可操作的结果。
字段留空需要约定处理方式。必填字段为空的行视为草稿，不进入评审和排期；选填字段为空时，在备注列标注“待补充”及补充时限，避免长期悬空。团队可在模板底部加一行说明，写明空值含义，减少口头解释成本。
填写示例：一条业务需求如何分解到子需求
以下示例为演示情景，用于说明字段填写方式，不代表真实项目。示例展示一条业务需求如何逐层分解，编号与上级编号的对应关系贯穿四层。
| 层级 | 编号 | 上级编号 | 需求名称 | 需求描述 | 来源 | 验收口径 | 负责人 | 状态 |
|---|---|---|---|---|---|---|---|---|
| 业务需求 | BR-001 | — | 缩短客户问题响应周期 | 客服收到的客户问题需经多轮转交才能到达产品团队，平均响应时间偏长，希望通过统一入口和分级处理改善 | 客服部季度反馈会记录 | 客户问题从提交到首次响应的平均时长较基线下降，且问题可追溯到处理人 | 张明 | 已确认 |
| 产品需求 | PR-001 | BR-001 | 建立客户问题统一受理入口 | 为客服提供统一提交入口，支持问题分类、优先级标记和自动分派规则 | BR-001 | 客服可通过统一入口提交问题，选择分类与优先级后系统按规则分派至对应处理人 | 李华 | 开发中 |
| 系统需求 | SR-001 | PR-001 | 实现问题分类与分派规则配置 | 提供分类字典维护和分派规则配置能力，规则按分类与优先级组合匹配处理人 | PR-001 | 管理员可新增、修改分类；配置规则后新提交问题按规则自动分派，分派结果可在详情页查看 | 王强 | 开发中 |
| 子需求 | SR-001-01 | SR-001 | 分类字典维护页面 | — | — | 管理员可增删改分类，保存后提交页分类下拉即时生效 | 赵敏 | 待评审 |
| 子需求 | SR-001-02 | SR-001 | 分派规则匹配逻辑 | — | — | 按分类与优先级组合匹配到唯一处理人，无匹配时进入默认队列并提示 | 陈磊 | 待评审 |
对照示例检查三点：每一行的上级编号都能在表中找到对应行；同一父级下的子行相邻排列；验收口径写成可核验的条件而非笼统描述。业务需求层没有上级编号，用“—”占位；子需求编号在系统需求编号后追加序号，与上级编号列相互印证。
当需求进入迭代规划、需求与验收标准达成一致后，设计、研发、测试人员可继续把需求拆成更细的执行项。ONES 在这类场景中提供业务需求池、产品需求池与工单的联动，并支持用子工作项拆解功能复杂的需求、关联研发和测试任务，使需求、研发、测试环节串联起来。模板中的层级、负责人和状态字段，可以在工具中对应为工作项字段与流转状态，减少表格与系统两套记录不一致的情况。
模板的调整与维护方法
模板落地后需要随团队协作方式变化而调整，调整应遵循“先约定、再修改、留记录”的顺序，避免各人手里的表结构不一致。
按团队规模增减字段。小团队可先保留必填字段加需求描述，减少填写负担；跨部门协作时再补充来源、备注等字段，用于回溯和风险记录。新增字段前先确认它解决什么具体问题，例如增加“依赖需求编号”是为了识别阻塞关系，而不是为了字段齐全。
层级数量的调整要看分解深度是否够用。四层结构适合业务、产品、系统、子需求分工明确的场景；若团队把系统需求与子需求合并管理，可压缩为三层，但需同步修改编号规则和上级编号的填写要求。增加层级同样要更新编号前缀，并在模板说明中写明新层级的归属关系。
模板版本与变更记录建议单独维护一张小表，记录版本号、修改日期、修改内容和生效范围。每次调整字段或编号规则都升一个版本号，旧表保留原版本标识，便于对照历史需求。变更后通知所有填写人，并在模板顶部标注当前版本。
定期清理与归档按状态执行。已验收且超过约定保留期的需求行移入归档表，主表只保留进行中和近期完成的需求；长期处于草稿状态且无人推进的行，由负责人确认后关闭或删除。归档表保留编号与上级编号，确保历史父子关系仍可追溯。
若团队使用 ONES 管理需求，可将模板中的层级与字段映射到业务需求池、产品需求池和子工作项上，用工作流承载状态流转，并按实际场景自定义字段。这样模板作为填写规范继续使用，需求的实际流转和状态更新在系统中完成，两者通过编号保持一致。
常见问题
业务需求层没有上级编号，表格里怎么处理才不影响后续筛选？
业务需求行的上级编号列留空或统一填“—”，两种做法选一种并在模板说明中固定下来。若表格工具支持筛选，建议填“—”而非留空，这样筛选“上级编号为空”时不会把业务需求与漏填的行混在一起。业务需求的父子关系由编号前缀 BR 本身表明，不依赖上级编号列。
团队已经有任务管理工具，这张表还需要单独维护吗？
这张表解决的是需求层级与验收口径的约定，任务管理工具解决的是执行项的分派与进度跟踪，两者记录的对象不同。可行做法是把模板作为填写规范，需求在工具中建好后，编号与层级字段保持一致，表格只保留评审和归档需要的快照。若团队使用 ONES，可将层级与字段映射到业务需求池、产品需求池和子工作项上，用工作流承载状态流转，减少两套记录不一致的情况。
子需求还需要写需求描述和来源吗？
通常可以省略。子需求挂在系统需求之下，背景和来源已由父级行承载，子需求保留层级、编号、上级编号、需求名称、验收口径和负责人即可。若某个子需求涉及外部依赖或独立的风险，可在备注列补充，不必为此恢复描述列。
需求在开发过程中验收口径发生变化，模板怎么记录？
验收口径变更属于需求变更，建议保留原口径并在备注列写明变更原因与确认人，同时更新状态。若变更影响父级需求的范围，需要回到上级行同步调整。模板版本记录中注明本次变更涉及的编号，便于后续对照历史需求。
四层结构对小型团队是否过重？
四层适合业务、产品、系统、子需求分工明确的场景。小团队若由同一批人兼顾业务与产品判断，可压缩为三层，把系统需求与子需求合并管理，但需同步修改编号规则和上级编号的填写要求，并在模板说明中写明新层级的归属关系。压缩后仍要保留验收口径和负责人两个字段。
