需求层级图把业务需求、产品需求、系统需求和子需求按父子关系逐层展开，让团队看清一条业务目标如何落到可交付的工作上。本文给出一份可直接照填的示例：以“企业报销线上化”为业务需求，向下拆出产品需求、系统需求与子需求，并逐项说明每层写什么、父子关联怎么建、哪些内容应留在层级图之外。示例为演示情景，用于说明填写方法。
要点总览（TL;DR）
- 需求层级图按业务需求、产品需求、系统需求、子需求四层展开，用唯一编号和父编号记录父子关系，让一条业务目标落到可分配、可验收的工作上。
- 业务需求写目标与价值，产品需求写用户可见的能力边界，系统需求写支撑能力与依赖，子需求写到可分配、可验收、可估算的粒度。
- 父子关联遵循单父挂接、编号全局唯一、不跨层直挂的规则；需求改名时编号保持不变，便于评审与变更引用。
- 迁移到其他场景时先定层级数量，再逐层展开，用可分配、可验收、可估算三个条件控制拆分深度。
- 执行任务拆解和跨研发对象追溯不放进需求层级图，层级超过四到五层时应主动合并中间层。
示例目标：这份需求层级图要解决什么
这份示例的设定是：一家企业希望把员工报销从线下填单、纸质贴票改为线上办理，由产品与研发团队承接。示例要完成的任务是把“报销流程线上化”这一条业务需求，逐层拆到可以分配、可以验收的子需求，形成一张四层的需求层级图。示例中出现的组织、角色和周期均为演示设定，不对应真实客户案例，也不附带实测效果。
在动笔填写之前，先明确层级图要回答的三个问题，它们决定了图的深度和每层的内容边界：
- 谁提出：这条需求的来源方是谁，期望达成的业务结果是什么。示例中由财务与行政管理部门提出，目标是缩短报销周期、减少纸质单据流转。
- 由什么承载：业务目标由哪些产品能力承接，这些能力又依赖哪些系统能力。示例中承载方是报销应用及其表单、审批、票据识别能力。
- 拆到哪一层停：拆到子需求即可分配、可验收为止，再往下属于执行任务，不进入需求层级图。示例中子需求停在“字段校验规则”“多级审批配置”这一粒度。
把这三个问题先写下来，再开始填内容，可以避免两种常见偏差：一是层级图只写到产品需求就停，研发拿不到可执行的输入；二是无限向下拆，把开发任务也塞进需求层级，导致图越来越难维护。
完整示例：企业报销线上化的四层需求层级图
下面是一份已填写的完整示例。编号采用“层级前缀＋序号”的规则：业务需求用 BR，产品需求用 PR，系统需求用 SR，子需求用 CR；父编号写在子项中，形成可追溯的父子链。
| 层级 | 编号 | 需求名称 | 内容描述 | 父编号 |
|---|---|---|---|---|
| 业务需求 | BR-01 | 报销流程线上化 | 员工在线提交报销单，审批与票据核验在系统中完成，缩短从提交到到账的周期 | — |
| 产品需求 | PR-01 | 报销单在线提交 | 员工可填写费用明细、上传票据、暂存草稿并提交 | BR-01 |
| 产品需求 | PR-02 | 报销审批流 | 按金额与费用类型走不同审批路径，支持驳回与转交 | BR-01 |
| 产品需求 | PR-03 | 票据识别 | 上传票据后自动识别金额、日期、发票号等字段并回填 | BR-01 |
| 系统需求 | SR-01 | 表单引擎 | 支撑报销单的动态字段配置与校验 | PR-01 |
| 系统需求 | SR-02 | 审批引擎 | 支撑多级审批节点、条件分支与流转记录 | PR-02 |
| 系统需求 | SR-03 | OCR 服务对接 | 对接票据识别服务，完成图像上传、结果解析与字段回填 | PR-03 |
| 子需求 | CR-01 | 报销单字段校验规则 | 金额、日期、费用类型的必填与格式校验，提交前拦截错误 | SR-01 |
| 子需求 | CR-02 | 多级审批配置 | 按金额区间配置审批层级与审批人，支持条件分支 | SR-02 |
| 子需求 | CR-03 | 票据字段映射 | 定义识别结果与报销单字段的对应关系及异常处理 | SR-03 |
用层级结构表示，父子关系如下：
- BR-01 报销流程线上化
- PR-01 报销单在线提交 → SR-01 表单引擎 → CR-01 报销单字段校验规则
- PR-02 报销审批流 → SR-02 审批引擎 → CR-02 多级审批配置
- PR-03 票据识别 → SR-03 OCR 服务对接 → CR-03 票据字段映射
这份示例的父子关联遵循两条规则：每个子项只挂一个直接父项，跨层关系通过父链传递，不额外画跨层连线；编号全局唯一，需求改名时编号保持不变，便于在评审、变更和验收记录中稳定引用。示例中产品需求与系统需求并非一一对应，PR-01 只挂 SR-01，是因为提交能力主要依赖表单引擎；如果后续提交环节需要调用票据识别，应在 SR 层新增一条系统需求并挂到 PR-01 下，而不是把 SR-03 同时挂到两个产品需求上。
逐项解释：每层写什么、父子关联怎么建
示例中的每一行都对应一条填写判断。理解这些判断，比记住表格本身更有用。
业务需求：写目标与价值，不写实现方式
BR-01 写的是“报销流程线上化，缩短报销周期”，描述的是业务结果和期望改善，没有出现表单、审批引擎等实现词汇。业务需求层的读者是提出方和管理层，他们关心的是问题是否被解决。如果在这一层写“用 OCR 识别票据”，就把实现方案提前锁死，后续技术选型失去讨论空间。判断标准很简单：这句话能否在不提任何系统组件的情况下说清楚，能，就适合放在业务需求层。
产品需求：写用户可见的能力边界
PR-01 到 PR-03 分别对应员工提交、审批人审批、票据自动识别三类用户可见能力。每条产品需求都写清了谁在什么场景下能做什么，以及能力的边界，例如“支持驳回与转交”“自动识别并回填”。产品需求层不描述内部模块如何实现，也不细到字段级规则，那是子需求的事。三条产品需求共同覆盖 BR-01 的目标，检查方式是逐条问：去掉这条产品需求，业务目标还能达成吗？如果答案是不能，说明覆盖是完整的。
系统需求：写支撑能力与系统间依赖
SR-01 到 SR-03 描述的是支撑产品能力的系统组件和对接关系。这一层要写清依赖：SR-03 明确写了“对接票据识别服务”，说明存在外部服务依赖，评审时需要确认接口、配额和异常处理。系统需求的读者是架构与研发人员，写法上应能让人判断工作量和技术风险。系统需求与产品需求可以多对多，但示例中保持单父挂接，是为了让每条系统需求的归属清晰；确实需要被多个产品需求复用时，通过父链在评审中说明，而不是在图上画多条父线。
子需求：写到可分配、可验收的粒度
CR-01 到 CR-03 是示例中最细的一层。判断粒度是否合适，看三个条件：能否分配给一个明确的负责人；完成后是否有可检查的验收标准；工作量是否小到可以估算。CR-01“报销单字段校验规则”可以交给一名开发，验收时检查必填与格式校验是否生效，工作量可以按规则条数估算，符合条件。如果再往下写“金额输入框加千分位”，就进入了界面实现细节，属于任务层内容。
父子关联：唯一编号，逐层挂接
示例的关联规则可以归纳为四条：
- 每个需求有全局唯一编号，编号不随名称修改而变化。
- 子项只记录直接父项编号，不记录祖父项，层级关系通过父链推导。
- 跨层挂接要避免，例如子需求直接挂到业务需求下，会跳过产品与系统两层，导致中间层失去约束作用。
- 一条需求需要拆成多条时，新增同级编号，原编号保留，不把内容合并进旧条目。
在协作工具中承载这套结构时，可以把每层需求建成独立的工作项类型，用父子关联字段连接，编号由系统生成并保持稳定。ONES 支持工作项类型的自定义与层级关联，需求在评审、变更和验收中的状态可以沿父子链查看，适合把上面这份示例直接落成可维护的结构。工具只是承载方式，层级划分和填写规则仍按本文示例执行。
可迁移规律：换一个业务场景怎么照做
把示例迁移到自己的场景，可以按下面的步骤执行，每一步都有明确的完成标志。
- 先定层级数量，再填内容。根据业务复杂度决定用三层还是四层。中小型项目常用“业务—产品—子需求”三层；涉及多个系统对接时增加系统需求层。完成标志是团队对层数和每层名称达成一致。
- 每层用一句话写清职责。例如“业务需求回答为什么做，产品需求回答用户能做什么，系统需求回答靠什么支撑，子需求回答具体做什么”。这句话贴在填写模板顶部，作为填写时的自检依据。
- 从业务需求向下逐层展开。先写一条业务需求，再问“哪些产品能力能达成它”，逐条列出产品需求，然后为每条产品需求找支撑系统，最后把系统需求拆到可分配的子需求。完成标志是每条需求都有父项，除业务需求外没有孤立条目。
- 用停止条件控制深度。子需求满足可分配、可验收、可估算三个条件即停止拆分。任一条件不满足，继续拆一层；三个条件都满足仍继续拆，说明拆过头了。
- 划清与任务拆解的边界。需求层级图回答“做什么、为什么做”，任务拆解回答“谁在什么时候做哪一步”。开发排期、联调步骤、测试用例执行属于任务管理，不写进需求层级图。
- 建立变更更新规则。需求变更时，先改对应层级的内容，再检查父项描述是否仍然成立，最后同步子项。完成标志是变更记录中能追溯到受影响的父子链。
以一个演示性的招聘场景为例：业务需求是“缩短岗位到岗周期”，产品需求可拆为“职位发布”“候选人筛选”“面试安排”，系统需求对应“职位同步接口”“简历解析服务”“日历对接”，子需求落到“发布字段校验”“筛选条件配置”“面试时段冲突检测”。结构与报销示例一致，说明这套拆法不依赖具体业务领域。
适用边界：哪些内容不该放进需求层级图
需求层级图有明确的适用范围，越界使用会让图变得臃肿，失去作为沟通工具的价值。
- 执行任务拆解归任务管理。“开发报销单页面”“编写接口文档”“执行回归测试”这类工作安排属于任务层，放在任务管理工具中跟踪进度。把它们塞进需求层级图，会让需求图变成排期表，评审时难以聚焦需求本身。
- 跨研发对象追踪归需求追溯与覆盖管理。需求与设计稿、代码提交、测试用例之间的覆盖关系，属于追溯管理范畴。需求层级图只表达需求之间的父子关系，不承担覆盖度分析。需要确认某条子需求是否被测试覆盖时，应在追溯视图中查看，而不是在层级图上加连线。
- 层级过深要主动收敛。层级超过四到五层时，维护成本明显上升：每次变更要逐层检查，评审时读者难以定位。处理方式是合并中间层，把职责相近的系统需求归并，或把稳定的子需求提升为独立需求单独管理。判断依据是变更频率，频繁变动的部分保持细粒度，稳定的部分适当合并。
- 需求变更时明确更新责任。建议由需求负责人维护其名下需求的父子关系，变更评审时同步检查父项描述是否仍然准确。缺少明确责任人时，层级图容易在几轮迭代后与实际脱节，编号还在但内容已经过时。
常见误用还包括：把层级图当作汇报材料反复美化，而忽略内容准确性；为每条需求强行凑齐四层，导致系统需求层出现“无实际支撑内容”的空条目；以及用层级图替代需求评审，认为图画完需求就清楚了。层级图是结构化表达工具，需求是否成立、优先级如何，仍需通过评审和讨论确定。
常见问题
需求层级图一般分几层比较合适？
常见做法是三到四层。中小型项目用“业务—产品—子需求”三层即可；涉及多个系统对接时增加系统需求层，形成四层结构。层数取决于业务复杂度和系统依赖数量，判断标准是每一层都有明确的读者和职责，去掉任何一层都会让某类信息无处安放。层级超过四到五层时维护成本明显上升，应考虑合并中间层。
子需求拆到什么程度可以停？
用三个条件判断：能否分配给一个明确的负责人；完成后是否有可检查的验收标准；工作量是否小到可以估算。三个条件同时满足即可停止拆分。任一条件不满足，说明还需要再拆一层；三个条件都满足仍继续拆，说明拆过头了，继续往下就进入界面实现细节或开发任务，应放到任务管理中跟踪。
一条系统需求被多个产品需求复用时，父子关系怎么挂？
建议保持单父挂接，让每条需求只有一个直接父项，归属清晰。确实需要复用时，在评审中通过父链说明复用关系，不在图上画多条父线。如果复用导致归属难以判断，可以把这条系统需求提升为独立需求单独管理，再由各产品需求通过关联字段引用，避免层级图出现多父结构。
需求变更后，层级图由谁负责更新？
建议由需求负责人维护其名下需求的父子关系。变更发生时，先修改对应层级的内容，再检查父项描述是否仍然成立，最后同步受影响的子项，并在变更记录中保留可追溯的父子链。缺少明确责任人时，层级图容易在几轮迭代后与实际脱节，编号还在但内容已经过时。
需求层级图和需求追溯是什么关系？
两者回答的问题不同。需求层级图只表达需求之间的父子关系，说明一条业务目标如何逐层落到子需求；需求追溯关注需求与设计稿、代码提交、测试用例之间的覆盖关系，用于确认某条需求是否被实现和验证。需要检查覆盖度时应在追溯视图中查看，不必在层级图上增加跨对象连线，否则图会变得臃肿。
