需求层级图把一条需求按“目标—子需求—验收点”逐层展开，用统一编号、父子关系和验收标准把层级关系固定下来。下面给出一份可直接参照填写的已填写示例，逐层说明每列填什么、为什么这样拆，以及拆到哪一层应当停止。示例为演示情景，用于说明填写方式，不代表真实客户案例或实测效果。
要点总览（TL;DR）
- 需求层级图按“业务目标—子需求—验收点”三层展开，层级划分依据是能否独立验收，而不是按人员或模块切分。
- 示例采用“层级前缀＋序号”的编号规则，配合父级编号固定归属，表格行序打乱也能还原树形结构。
- 验收标准写到“换一个人也能判断通过与否”的颗粒度即可，过细会与测试用例重复，过粗则无法验收。
- 层级深度建议控制在三层左右，继续下拆已进入执行安排，应转入任务拆解与组织处理。
- 需求一次性、边界未定或需求之间是横向依赖关系时，不适合套用层级图，需要调整做法。
示例目标：这张需求层级图要解决什么问题
这张图要回答一个具体问题：一条偏宏观的业务需求，怎样拆成若干条可以分别交付、分别验收的子需求，并且让每条子需求都能追溯到它服务的上层目标。示例设定为一家公司内部的审批流程优化，需求来源是行政与财务部门的共同反馈，读者可以把它替换成自己业务中的任意一条中等复杂度需求。
示例覆盖三层结构。第一层是业务目标，描述为什么要做、期望改变什么；第二层是子需求，把目标拆成若干可独立交付的成果；第三层是验收点，为每条子需求写明判断完成与否的标准。三层之间通过编号和父级字段建立归属关系，形成一棵可读的树。
读者可以从示例中复用的产出有三项：一是层级结构本身，即三层如何划分、每层放什么；二是字段设置，包括编号、层级、父级编号、需求描述、验收标准、责任角色；三是编号规则，让新增子需求时能自然落到正确位置，后续调整也不至于出现无归属的条目。
完整示例：一份已填写的需求层级图
示例背景：某公司现有审批依赖邮件与即时通讯工具，审批人经常漏看，申请人无法判断进度。业务方提出“让审批更快更清楚”。这条原始诉求过于笼统，无法直接排期，需要先拆成层级图再进入后续规划。
下表是完整填写结果。编号采用“层级前缀＋序号”的规则：L1 表示业务目标，L2 表示子需求，L3 表示验收点；父级编号指向直接上层条目，形成父子关系。
| 编号 | 层级 | 父级编号 | 条目名称 | 需求描述 | 验收标准 | 责任角色 |
|---|---|---|---|---|---|---|
| L1-01 | 业务目标 | — | 缩短内部审批平均处理时长 | 将常见审批事项的平均处理时长从现状压缩，并让申请人随时可见当前节点 | 上线后一个完整统计周期内，常见审批事项平均处理时长较基线下降，且申请人可在系统中查到当前审批节点 | 流程负责人 |
| L2-01 | 子需求 | L1-01 | 审批单在线提交与流转 | 申请人通过统一表单提交审批，系统按预设规则自动流转至对应审批人 | 申请人提交后系统自动生成审批单并推送至第一审批人；审批人可在待办中看到并处理 | 产品经理 |
| L3-01 | 验收点 | L2-01 | 提交即生成单据 | 提交动作完成后立即生成带唯一编号的审批单 | 提交成功后 5 秒内可在“我的申请”中查到该单据及编号 | 测试工程师 |
| L3-02 | 验收点 | L2-01 | 按规则自动指派审批人 | 依据申请人所属部门与审批类型匹配审批人 | 覆盖示例中列出的三类审批类型，每类均能指派到正确审批人，无人工干预 | 测试工程师 |
| L2-02 | 子需求 | L1-01 | 审批进度对申请人可见 | 申请人可查看审批单当前所处节点、已处理人与待处理人 | 审批单详情页展示节点时间线与当前处理人，状态变更后页面同步更新 | 产品经理 |
| L3-03 | 验收点 | L2-02 | 节点时间线完整 | 每次节点流转记录时间与处理人 | 任一审批单可看到从提交到当前的全部节点记录，无缺失 | 测试工程师 |
| L2-03 | 子需求 | L1-01 | 超时提醒与催办 | 审批单在节点停留超过设定时长后向审批人发送提醒，申请人可主动催办 | 超过设定时长后审批人收到提醒；申请人点击催办后审批人收到催办通知 | 产品经理 |
| L3-04 | 验收点 | L2-03 | 超时提醒可触发 | 按配置的时长阈值触发提醒 | 将阈值设为测试值后，到达阈值即产生一条提醒记录，且不重复发送 | 测试工程师 |
从表中可以看到父子关系的实际作用：L1-01 只有一个，它下面挂三条子需求；每条子需求再挂一到两个验收点。编号前缀与父级编号相互印证，即使表格行序被打乱，也能还原出树形结构。验收标准一栏写的是可判断通过与否的条件，而不是“体验良好”“响应及时”这类无法核对的描述。
当这类层级需要在系统中长期维护时，可以把业务目标、子需求、验收点分别作为不同层级的工作项承载，用父子关系字段固定归属。ONES 支持对功能复杂的需求使用子工作项进行拆解，并关联研发和测试任务，把需求、研发、测试等环节串联起来；在迭代开始前对需求与验收标准达成一致后，设计、研发、测试人员可继续用子任务拆分，便于后续处理和跟踪。示例中的三层结构正好对应这一承载方式，具体字段配置以实际环境为准。
逐项解释：每一层和每个字段为什么这样填
层级划分的依据是“能否独立验收”，而不是按人员分工或时间先后切分。L2-01 在线提交与流转、L2-02 进度可见、L2-03 超时提醒，三者各自可以单独上线、单独判断是否达标，因此并列为子需求。如果按“前端部分”“后端部分”来拆，任何一条都无法独立验收，层级图就失去了判断交付完成的作用。
编号与父子关系字段承担两项职责。编号让条目在口头沟通、文档引用和缺陷记录中有唯一指称，避免“那个审批的需求”这类含糊表达；父级编号则固定归属，新增条目时必须先确定父级，防止出现游离在目标之外的子需求。示例采用层级前缀加序号，好处是看编号即知层级，代价是插入新条目时序号可能不连续，这属于可接受的取舍，规则本身应在拆分前约定并保持一致。
验收标准写到“可判断通过与否”的颗粒度即可。L3-01 写“提交成功后 5 秒内可查到单据及编号”，测试人员据此可以设计一条用例并给出通过或失败的结论；如果再细到接口返回字段的每个取值，就与测试用例重复，层级图会变得臃肿。反过来，若只写“提交功能正常”，则无法验收。判断标准是：换一个不了解背景的人来读，能否独立判断这条是否完成。
内容留在上层还是下沉到子需求，取决于它是否需要在不同交付批次中分别安排。业务目标层保留的是方向性描述和整体衡量口径，例如“平均处理时长下降”，它不绑定某一次发布；具体到“按规则自动指派审批人”这种有明确实现边界的成果，下沉为子需求；而“覆盖三类审批类型均指派正确”这种验证条件，再下沉为验收点。把实现细节写进业务目标，会让目标层失去稳定性，每次方案调整都要改目标。
可迁移规律：换一个业务场景怎么套用
从示例可以提炼出一套通用拆分顺序，换到其他场景时按此推进即可：
- 先用一句话写清业务目标，并给出一个可观察的整体衡量口径，例如时长、完成率、错误数量。
- 问“要达成这个目标，需要哪些可以分别交付的成果”，每个成果写成一条子需求，确保它能单独上线或单独验收。
- 为每条子需求写验收标准，标准中包含触发条件、预期结果和判断方式。
- 检查每条子需求是否都挂了父级编号，确认没有游离条目，也没有一条子需求同时服务两个互斥目标。
- 对仍无法独立验收的子需求继续下拆一层，拆到能验收为止。
层级深度建议控制在三层左右。到了验收点这一层，条目已经足够具体，继续下拆通常进入“谁在什么时间做什么”的执行安排，那属于任务拆解与组织的范畴，放在需求层级图里会让图变成排期表。若某条子需求确实过于庞大，优先考虑把它拆成两条并列子需求，而不是加深层级。
父子关系与验收标准的通用写法有两条经验。父子关系上，一条条目只设一个直接父级，需要跨目标复用时通过引用而非重复建条目，避免同一件事在两棵树里各自演化。验收标准上，统一采用“条件＋结果＋判断方式”的句式，例如“当满足某条件时，系统应产生某结果，可通过某处查证”，这样不同人写出的标准具备可比性。
常见填写错误及修正方式如下表：
| 常见错误 | 表现 | 修正方式 |
|---|---|---|
| 按人员或系统模块拆分 | 子需求写成“前端开发”“接口开发”，无法独立验收 | 改为按可交付成果拆分，人员分工放到任务层 |
| 验收标准不可判断 | 写“体验流畅”“及时响应” | 补充触发条件、预期结果与查证位置 |
| 层级过深 | 出现第四、第五层，内容已是执行步骤 | 在验收点层停止，执行安排转入任务拆解 |
| 父子关系缺失 | 存在没有父级编号的条目 | 补挂父级，或确认其为独立目标并单列 |
| 目标层写实现方案 | 业务目标里出现具体页面与字段 | 目标层只保留方向与衡量口径，方案下沉到子需求 |
适用边界：哪些情况不适合用需求层级图
需求层级图适合需求之间存在明确的父子交付关系、且需要分别验收的场景。典型情况是一条业务目标需要多个成果共同支撑，各成果由不同角色推进、在不同时间点交付，此时层级图能固定归属并支撑后续的进度判断与验收核对。示例中的审批流程优化正属于这一类。
以下情况需要调整做法或改用其他方式。需求本身是一次性、不可再分的小改动时，画层级图只会增加维护成本，直接写成一条带验收标准的需求即可。目标尚在探索、交付物边界未定时，过早固定层级会限制调整空间，可以先记录目标与假设，待方案收敛后再拆。多个需求之间是依赖或关联关系而非父子关系时，层级图表达不了这种横向联系，应改用依赖标注或关联字段。
还需要划清两处相邻边界。任务执行层面的拆解与排期，包括谁在哪个迭代做什么、工时如何分配，归任务拆解与组织处理，不放进需求层级图；跨研发对象的需求追溯与覆盖度统计，例如需求与测试用例、缺陷之间的对应关系与覆盖情况，归需求追溯与覆盖管理处理。层级图负责把“需求树”本身写清楚，这两类工作在其上展开，但方法与产物不同。
在系统中落地时，ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，研发团队通过任务和工单完成开发、测试与修复，形成需求—任务—测试—缺陷的闭环；测试工程师可依据迭代要完成的需求与验收标准编写并执行测试用例。示例中的验收点可以直接作为编写测试用例的输入，使层级图与后续验证衔接起来。涉及版本、套餐与部署方式的信息，需按实际环境另行确认。
常见问题
需求层级图拆到第几层就该停？
一般停在验收点这一层，也就是每条条目都能回答“怎么判断它完成了”。到了这一层，条目已经足够具体，再往下写通常就是谁在什么时间做什么，属于执行安排。如果某条子需求仍然太大、无法独立验收，优先把它拆成两条并列子需求，而不是继续加深层级。层级过深的直接后果是维护成本上升，每次方案调整都要同步改动多层内容。
一条子需求同时服务两个业务目标，该怎么处理？
建议只设一个直接父级，把它挂在主要服务的目标下，另一处通过引用或关联字段标注，而不是在两个目标下各建一条。重复建条目会让同一件事在两棵树里各自演化，后续进度和验收口径容易对不上。如果两个目标本身互斥、无法判断主次，说明目标层还没有想清楚，应先回到目标层重新界定，再继续下拆。
验收标准写到什么程度算合适？
判断标准是：换一个不了解背景的人来读，能否独立给出通过或失败的结论。可以采用“条件＋结果＋判断方式”的句式，例如说明在什么条件下、系统应产生什么结果、可以从哪里查证。写到这个程度，测试人员就能据此设计用例；如果再细到接口字段的每个取值，就与测试用例重复，层级图会变得臃肿。
层级图里的验收点和测试用例是什么关系？
验收点是需求层面的判断条件，测试用例是验证这些条件的具体执行设计，两者颗粒度不同。层级图写清验收点后，测试工程师可以据此编写并执行测试用例。ONES 支持测试工程师根据迭代要完成的需求与验收标准编写测试用例，就提测的需求执行测试用例，示例中的验收点可以直接作为编写用例的输入。
在系统里维护这类层级，需要额外做哪些准备？
先约定编号规则和父子关系字段的用法，再开始录入，避免中途改规则导致条目归属混乱。对于功能复杂的需求，ONES 支持利用子工作项进行拆解，并关联研发和测试任务，把需求、研发、测试等环节串联起来；在迭代开始前对需求与验收标准达成一致后，设计、研发、测试人员可继续用子任务拆分，便于后续处理和跟踪。子工作项的嵌套层数与具体字段配置，以实际环境为准。
