业务需求分解模板用一张表承载“业务需求—子需求—验收要点”三层信息：业务需求行记录目标、范围、优先级和负责人，向下拆出可独立交付的子需求，每条子需求写明验收要点与依赖关系。模板适合在需求评审前填写、评审中补齐、评审后作为交付依据使用。下文先给可复制的空白表，再逐字段说明填写口径，并用一条业务需求拆成三条子需求的示例演示完整填法，最后说明按团队情况裁剪与维护的方法。
要点总览（TL;DR）
- 模板用一张表承载“业务需求—子需求—验收要点”三层信息，业务需求与子需求同表记录，靠“层级”和“父需求”两个字段区分上下级。
- 表头共十列：需求编号、层级、父需求、描述、验收要点、优先级、负责人、状态、来源、备注；其中编号、层级、父需求、描述、验收要点、优先级、负责人为必填。
- 子需求编号沿用父需求编号加两位序号，父需求字段必须指向本表中已存在的业务需求编号，指向不存在的编号视为填写错误。
- 验收要点写成可观察、可判断的条件，依赖关系写在备注中并指向具体编号，排期时能直接看出先后顺序。
- 模板落地后按业务复杂度增减选填字段，必填七项保持稳定，并在文件头部记录版本号与生效日期。
可复制空白模板：业务需求分解表
业务需求与子需求放在同一张表里记录，靠“层级”和“父需求”两个字段区分上下级。业务需求行的父需求留空，子需求行的父需求填写所属业务需求的编号。这样一张表既能看全貌，也能按父需求筛选出某条业务需求下的全部子需求。将下表复制到文档或表格工具后，删除示例占位内容即可开始填写。
| 需求编号 | 层级 | 父需求 | 描述 | 验收要点 | 优先级 | 负责人 | 状态 | 来源 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| BR-001 | 业务需求 | （留空） | （填写业务目标与范围） | （填写整体达成标准） | （高/中/低） | （姓名） | （待评审/进行中/已完成） | （提出方或渠道） | （补充说明） |
| BR-001-01 | 子需求 | BR-001 | （填写可独立交付的内容） | （填写可核验的验收条件） | （高/中/低） | （姓名） | （待评审/进行中/已完成） | （提出方或渠道） | （依赖关系等） |
| BR-001-02 | 子需求 | BR-001 | （填写可独立交付的内容） | （填写可核验的验收条件） | （高/中/低） | （姓名） | （待评审/进行中/已完成） | （提出方或渠道） | （依赖关系等） |
| BR-001-03 | 子需求 | BR-001 | （填写可独立交付的内容） | （填写可核验的验收条件） | （高/中/低） | （姓名） | （待评审/进行中/已完成） | （提出方或渠道） | （依赖关系等） |
表头固定为十列，行数按实际拆解结果增减。一条业务需求下拆出几条子需求，就补几行子需求记录；子需求编号建议沿用父需求编号加两位序号，便于在筛选和排序时保持层级关系清晰。
字段说明：每个字段记录什么
十个字段各自承担一项记录职责，填写口径统一后，业务方、产品经理和研发人员看到同一行记录能得出相同理解。以下逐字段说明含义与填写方式。
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 需求编号 | 该行记录的唯一标识 | 业务需求用“BR-序号”，子需求用“父编号-两位序号”，全表不重复 |
| 层级 | 该行在分解结构中的位置 | 只取两个值：业务需求、子需求。业务需求行填“业务需求”，其下拆出的行填“子需求” |
| 父需求 | 该行所属的上级记录 | 业务需求行留空；子需求行填写所属业务需求的编号，且该编号必须在本表中存在 |
| 描述 | 需求要解决的问题或要交付的内容 | 业务需求写目标与范围，说明为什么做、覆盖到哪里；子需求写可独立交付的具体内容，一条子需求只讲一件事 |
| 验收要点 | 判断该行是否完成的核验条件 | 写成可观察、可判断的条目，避免“体验良好”这类无法核验的表述；业务需求行写整体达成标准，子需求行写本条交付的验收条件 |
| 优先级 | 相对重要程度 | 统一使用高、中、低三档，全表口径一致；子需求优先级可以不高于其父需求 |
| 负责人 | 对该行结果负责的人 | 填写具体姓名，不填团队或部门；业务需求负责人通常是业务或产品侧角色，子需求负责人是承接交付的角色 |
| 状态 | 该行当前进展 | 建议取值：待评审、进行中、已完成、已搁置；新建时统一填“待评审” |
| 来源 | 需求由谁或通过什么渠道提出 | 填写提出方名称、工单号或沟通渠道，便于后续回溯 |
| 备注 | 不适合放入其他字段的补充信息 | 常用于记录依赖关系、关联文档位置、待确认问题 |
层级取值只有“业务需求”和“子需求”两种，不再增设第三层。需要更细的拆分时，在子需求描述中说明交付边界，或把子需求继续拆成新的子需求行并指向同一父需求。父需求字段的填写规则是：业务需求行必须为空，子需求行必须指向本表中已存在的业务需求编号，指向不存在的编号视为填写错误。
必填与选填：哪些字段不能空
必填字段决定一条记录能否被理解和验收，选填字段服务于检索和补充说明。必填项缺失时该行不进入评审；选填项允许暂时留空，但要在备注中写明补齐时点。
| 字段 | 必填/选填 | 理由与空缺处理 |
|---|---|---|
| 需求编号 | 必填 | 唯一标识，缺失则无法被引用和关联 |
| 层级 | 必填 | 决定该行在结构中的位置，缺失则父子关系无法判断 |
| 父需求 | 必填（业务需求行填“无”） | 子需求必须指向父需求；业务需求行以“无”或留空表示顶层 |
| 描述 | 必填 | 没有描述就无法判断需求内容，评审无从开展 |
| 验收要点 | 必填 | 没有验收条件就无法判断是否完成，交付容易产生分歧 |
| 优先级 | 必填 | 用于排期和取舍，缺失会导致排序失真 |
| 负责人 | 必填 | 明确结果责任人，避免需求无人承接 |
| 状态 | 选填 | 新建时可统一默认“待评审”，进入评审流程后再逐行更新 |
| 来源 | 选填 | 需求来自工单或外部沟通时建议填写；内部规划产生的需求可留空 |
| 备注 | 选填 | 有依赖关系、待确认问题或关联资料时填写 |
状态字段的填写时点是：记录创建时统一置为“待评审”，评审通过后改为“进行中”，验收要点全部满足后改为“已完成”，评审未通过或暂缓的改为“已搁置”。来源字段在需求来自工单、客户反馈或跨部门提出时填写，便于后续按来源统计；内部规划类需求可以留空。选填字段留空不影响该行进入评审，但备注中写明的待补事项需要在下次评审前补齐。
填写示例：一条业务需求拆成三条子需求
以下示例为演示情景，用于说明填写方式，不代表真实项目数据。场景是某业务方提出“订单查询支持按时间段筛选”，产品经理将其拆为三条可独立交付的子需求。
| 需求编号 | 层级 | 父需求 | 描述 | 验收要点 | 优先级 | 负责人 | 状态 | 来源 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| BR-001 | 业务需求 | 无 | 订单查询页支持按时间段筛选订单，覆盖近一年订单数据，帮助客服快速定位客户订单 | 客服可在查询页选择起止日期并得到正确结果；近一年数据均可查询；查询响应在可接受范围内 | 高 | 张产品 | 进行中 | 客服部工单 #2317 | 需与数据组确认历史数据范围 |
| BR-001-01 | 子需求 | BR-001 | 查询页新增起止日期选择控件，支持清空与快捷选择近7天、近30天 | 控件可正常选择起止日期；快捷选项点击后日期正确回填；清空后恢复默认范围 | 高 | 李设计 | 进行中 | 客服部工单 #2317 | 无 |
| BR-001-02 | 子需求 | BR-001 | 查询接口支持按时间段参数过滤，返回结果与筛选条件一致 | 传入起止日期后返回结果均落在区间内；边界日期当天的订单被包含；无参数时行为与改造前一致 | 高 | 王后端 | 待评审 | 客服部工单 #2317 | 依赖 BR-001-01 确定参数格式 |
| BR-001-03 | 子需求 | BR-001 | 查询结果列表展示筛选条件与结果数量，便于客服核对 | 列表顶部显示当前筛选的起止日期；显示结果总条数；条件变更后展示同步更新 | 中 | 赵前端 | 待评审 | 客服部工单 #2317 | 依赖 BR-001-02 接口联调完成 |
示例中有三处写法值得注意。验收要点写成可判断的条件，例如“边界日期当天的订单被包含”，评审时可以直接对照检查。依赖关系写在备注中并指向具体编号，例如 BR-001-02 依赖 BR-001-01 确定参数格式，排期时能直接看出先后顺序。子需求优先级低于父需求，体现整体需求为高优先级、其中展示类子需求可稍后交付的取舍。业务需求行的验收要点写整体达成标准，子需求行只写本条交付的验收条件，两层不重复。
调整与维护方法：按团队情况改模板
模板落地后需要随业务复杂度调整，并保留变更痕迹，避免不同时期填写的记录口径不一致。以下规则可作为维护清单使用。
- 按业务复杂度增减字段：需求来源渠道多、需要按来源统计时保留“来源”；需求之间依赖频繁时在备注之外单独增加“依赖需求”列；单一团队内部使用且不需要回溯时，可暂不填来源和备注。
- 必填字段保持稳定：编号、层级、父需求、描述、验收要点、优先级、负责人七项不建议裁剪，裁剪后记录难以被验收和排期。
- 记录模板版本：在模板文件头部标注版本号与生效日期，例如“v1.1，2025-06 起生效”，每次调整字段或取值时递增版本并写明变更内容。
- 评审节奏：新拆解的需求在需求评审会上逐行确认描述与验收要点，评审通过后更新状态；迭代进行中每周检查一次状态与备注中的依赖是否仍然成立。
- 更新触发条件：业务目标变化、验收标准调整、子需求合并或拆分时，同步修改对应行并在备注中写明变更原因与日期，保留原编号不重复使用。
当团队在ONES中管理需求时，这张表的结构可以对应到需求池与子工作项的配置上。ONES通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，业务、产品经理与研发团队可以分别从需求来源、产品规划和落地交付的视角查看同一条需求的状态与信息。对于功能复杂、需要拆解的需求，可使用子工作项把需求向下拆分，并关联研发和测试任务；产品负责人按优先级把需求规划进迭代，团队就验收标准达成一致后再进行拆分。模板中的层级、父需求、优先级、负责人等字段，可以在需求类型与字段配置中落地，工作流则按团队实际流转环节自定义，使状态变化与模板中的状态取值对应。具体字段配置方式与可用范围以实际使用版本为准。
常见问题
业务需求行和子需求行放在同一张表里，筛选时会不会混在一起？
同表记录便于看全貌，筛选时用“层级”字段区分即可：只看业务需求时筛选层级为“业务需求”，只看某条业务需求下的拆解结果时筛选父需求等于该业务需求编号。子需求编号沿用父编号加两位序号，按编号排序时上下级会自然相邻，不会散落在表的不同位置。
子需求还能继续往下拆吗？模板里只有两级层级取值。
模板的层级字段只取“业务需求”和“子需求”两个值，不再增设第三层。需要更细的拆分时，有两种处理方式：一是在子需求描述中写清交付边界，把范围限定到可独立验收的程度；二是把该子需求继续拆成新的子需求行，这些行仍指向同一条业务需求的编号。两种方式都保持两级结构不变，避免层级越拆越深导致记录难以维护。
评审时发现某条子需求的验收要点写不出来，应该怎么处理？
验收要点写不出来，通常说明这条子需求的交付边界还不清楚。处理方式是把该行状态置为“待评审”，在备注中写明待确认的问题和补齐时点，暂不进入排期；等描述细化到可以写出可观察、可判断的条件后，再在下次评审会上确认。必填项缺失的行不进入评审，这条规则同样适用于验收要点为空的情况。
团队已经在用工具管理需求，这张表还需要单独维护吗？
表格适合在需求评审前后作为讨论和确认的载体，工具适合承载状态流转和后续的任务关联。两者可以衔接：评审确认后的记录录入工具，状态变化在工具中更新，表格保留作为当次评审的存档。当团队在ONES中管理需求时，模板中的层级、父需求、优先级、负责人等字段可以在需求类型与字段配置中落地，工作流按团队实际流转环节自定义，使状态变化与模板中的状态取值对应；具体字段配置方式与可用范围以实际使用版本为准。
模板调整后，之前按旧版填写的记录要不要统一改？
按变更影响范围决定。如果只是新增选填字段，旧记录保持原样，新记录按新版填写即可；如果修改了必填字段或层级、状态的取值口径，则需要对未完成评审的记录统一补齐，已完成评审的记录保留原填写内容并在备注中注明适用版本。每次调整都在模板文件头部递增版本号并写明变更内容，便于回溯某条记录是按哪一版填写的。
