需求层级图用树状结构表达需求之间的父子归属关系：上层是业务需求，向下逐级分解为用户需求、产品需求或子需求，连线表示“由谁派生、为谁服务”。它回答需求的范围与归属，适合在需求梳理、评审和范围确认时使用。本文围绕层级构成、分层规则、父子关系表达，以及它与任务分解图的区别展开。
要点总览（TL;DR）
- 需求层级图用树状结构表达需求之间的父子归属关系：上层是业务需求，向下逐级分解为用户需求、产品需求或子需求，连线表示“由谁派生、为谁服务”。
- 常见分层是业务需求—用户需求或产品需求—子需求，每层分别写清目标与范围、使用场景、可交付的功能点；子需求能被单独评估与验收时即可停止分解。
- 父子关系通过连线方向、编号路径和状态汇总三处约定表达：一个子需求只保留一个直接父需求，父需求状态由子需求汇总，子需求变更需回看父需求范围。
- 需求层级图回答需求归属与范围，任务分解图回答执行分工与排期；工时、负责人等执行信息放在任务层，跨研发对象的追溯与覆盖关系归需求追溯管理。
- 常见误用包括把任务清单当层级图、子需求挂多个父需求、层级越深越好，避开这些才能让层级图稳定支撑范围评审与版本规划。
需求层级图的定义与核心要素
需求层级图是一种以树状结构组织需求条目的视图。它把业务需求放在上层，把由业务需求派生出的用户需求、产品需求和功能子需求逐级挂在下方，用父子连线保留“这个子需求来自哪个上层需求、服务于哪个业务目标”的归属信息。读者从任意一个节点向上可以追到业务来源，向下可以看到该需求被拆成了哪些可交付的部分。
构成一张可用的需求层级图，至少需要三个要素：
- 节点（需求条目）：每个节点是一条独立的需求记录，包含标题、描述、优先级、验收标准等基本信息。节点是层级图的最小单位，一条需求只对应一个节点。
- 父子连线：连线从父需求指向子需求，表示派生关系。连线的方向固定，一个子节点只连向一个直接父节点，避免同一需求出现两个归属来源。
- 层级深度：从根节点到最远叶子节点经过的层数。深度决定了分解的细致程度，也影响评审和变更时需要回看的范围。
层级图与需求清单的区别在于是否保留归属关系。需求清单把所有条目平铺成一张表，适合按优先级、状态或负责人筛选；层级图在平铺之外增加了父子结构，让“这条子需求属于哪个业务需求”成为可见信息。两者可以并存：清单用于日常跟踪，层级图用于范围梳理和评审沟通。
业务需求到子需求的层级如何划分
从业务需求向下分解，常见的层级是：业务需求—用户需求或产品需求—子需求（功能级或场景级）。这三层分别承担不同的表达任务，写清每层的内容，层级图才有评审价值。
| 层级 | 应写清的内容 | 典型表达 |
|---|---|---|
| 业务需求 | 业务目标、受益对象、范围边界、成功判断 | “缩短客户开户审批时长，覆盖线上与柜面两个渠道” |
| 用户需求或产品需求 | 具体使用场景、用户角色、期望结果 | “客户经理可在移动端提交开户申请并查看审批进度” |
| 子需求（功能或场景级） | 可交付的功能点、输入输出、验收条件 | “移动端开户申请表单支持证件拍照上传与必填校验” |
分解停止的判断标准是：子需求可以被单独评估与验收。也就是说，这个节点有明确的完成定义，能独立判断做没做完、做没做对，不需要再拆成更小的需求才能评审。达到这个程度就可以停止向下分解，继续拆下去往往进入设计与任务层面。
层级数量按项目复杂度取舍，不强制固定层数。范围清晰、交付周期短的项目，业务需求直接挂功能子需求也能用；涉及多角色、多渠道、多系统的项目，增加一层用户需求或场景需求，能让归属关系更清楚。层级过少会让子需求承担过多含义，层级过多会让每个节点信息稀薄、评审成本上升。
父子关系在图中怎么表达
父子关系通过连线、编号和状态三处约定来表达，三者配合才能让层级图在评审和变更时保持可读。
连线方向与唯一父节点。连线统一从父需求指向子需求，图中不出现双向箭头。每个子需求只保留一个直接父需求；如果一条子需求确实服务于多个业务目标，通常的做法是把它拆成两条子需求分别挂接，或者在父需求层面合并目标，避免一个节点出现多条入边导致归属不清。
编号或路径表达层级。用编号把层级写进标识里，脱离图形也能读出归属。例如：
- BR-01：业务需求，第 1 条；
- PR-01-2：BR-01 下的第 2 条产品需求；
- SR-01-2-1：PR-01-2 下的第 1 条子需求。
编号中的段数与层级深度对应，插入新需求时在末段递增，不打乱已有编号。这套编号是演示用的约定，团队可以按自己的规则调整，关键是保持段数与层级一致、全团队使用同一套规则。
状态汇总与变更回看。父需求的状态由子需求汇总得出：子需求全部完成，父需求才具备完成条件；有子需求被取消或延期，父需求的范围需要重新确认。子需求发生范围变更时，应回看父需求的描述和验收标准是否仍然成立，必要时同步修改父需求，避免上层写的目标和下层实际交付的内容脱节。
跨层级引用与依赖标注。当一条子需求需要另一条不同父需求下的条目配合时，用依赖标注而不是新增父子连线来表达。依赖关系单独标记方向和相关条目，与归属关系分开呈现，这样层级图仍然只回答“属于谁”，依赖信息作为附加说明供排期参考。
在工具中承载这套约定时，需要把业务需求、产品需求和子需求放在可关联的记录体系里。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，并提供业务、产品经理与研发团队三个视角，分别对应需求来源、产品规划和落地交付；对于功能复杂的需求，可用「子工作项」拆解并关联研发和测试任务。父子状态如何汇总、层级视图如何呈现，以实际产品配置为准。
需求层级图与任务分解图的区别
需求层级图表达需求归属，任务分解图表达执行分工与排期。两者结构相似，回答的问题不同，混用会让需求评审变成排期会，或者让任务计划承担范围管理的职责。
| 对比维度 | 需求层级图 | 任务分解图 |
|---|---|---|
| 回答的问题 | 这条需求来自哪个业务目标，被拆成哪些可验收的部分 | 谁在什么时间做什么，前后顺序如何 |
| 节点含义 | 需求条目，有范围与验收标准 | 任务或子任务，有负责人、工时和截止时间 |
| 父子关系 | 派生与归属，一个子需求一个直接父需求 | 执行拆解，可按阶段、角色或交付物组织 |
| 变更影响 | 影响范围与验收口径，需要回看上层目标 | 影响排期与资源分配 |
| 典型使用场景 | 需求梳理、范围评审、版本规划 | 迭代计划、日常派工、进度跟踪 |
需求层级不承担工时估算、负责人分配等执行信息。这些信息放在任务层更合适，因为同一需求在不同迭代可能由不同人员执行，而需求归属在较长时间内保持稳定。把负责人写进需求节点，会让层级图随人员变动频繁失效。
跨研发对象的需求追溯与覆盖关系属于需求追溯管理的范围，例如需求与设计、代码、测试用例之间的对应和覆盖检查。这类关系关注“是否被实现、是否被验证”，与层级图关注的“由谁派生”是两个问题，本文不展开。
一个示例与常见误解
以一个演示场景说明完整路径。某零售团队提出业务需求 BR-01“会员积分可在线上商城与门店收银台统一抵扣”，目标是让会员在两种渠道使用同一积分余额。向下分解出两条产品需求：PR-01-1“线上商城结算页支持积分抵扣”，PR-01-2“门店收银台支持积分抵扣并同步余额”。PR-01-2 再拆出子需求 SR-01-2-1“收银台读取会员积分余额”、SR-01-2-2“抵扣后实时回写积分流水”。每个子需求都写明了输入、输出和验收条件，可以单独测试，因此停止继续分解。整条路径读作：BR-01 派生 PR-01-2，PR-01-2 派生 SR-01-2-1 和 SR-01-2-2，编号段数与层级一一对应。
实际使用中，有三类误解比较常见：
- 把任务清单当层级图。把“写接口文档”“联调”“提测”这类执行动作挂在需求下面，当成子需求。这些动作没有独立的需求范围和验收口径，属于任务层内容，放进来会让层级图失去范围表达的作用。
- 子需求挂多个父需求。为了省事，把一条子需求同时连到两个业务需求下，看起来覆盖了两个目标，实际导致状态汇总和变更回看都无法判断归属。正确做法是拆成两条子需求，或在上层合并业务目标。
- 层级越深越好。把每条需求都拆到四五层，节点数量膨胀，评审时没人能读完，维护成本也高。层级深度应以“子需求可单独评估与验收”为停止条件，按项目复杂度决定，不追求形式上的完整。
把这三类问题避开，需求层级图就能稳定地回答两个问题：每个业务目标由哪些可验收的需求支撑，每条子需求服务于哪个业务目标。范围评审、版本规划和变更影响分析都可以在这张图上完成。
常见问题
需求层级图需要固定几层吗？
不需要固定层数。层级深度按项目复杂度取舍：范围清晰、交付周期短的项目，业务需求直接挂功能子需求也能用；涉及多角色、多渠道、多系统的项目，增加一层用户需求或场景需求，能让归属关系更清楚。
判断停止分解的标准是子需求可以被单独评估与验收，即这个节点有明确的完成定义，能独立判断做没做完、做没做对。层级过少会让子需求承担过多含义，层级过多会让每个节点信息稀薄、评审成本上升。
一条子需求同时服务两个业务需求，应该怎么处理？
常见做法有两种：把它拆成两条子需求，分别挂到各自的父需求下；或者在父需求层面合并业务目标，让这条子需求只有一个直接父节点。
不建议让一个子节点连向多个父需求。多条入边会让状态汇总和变更回看都无法判断归属，评审时也说不清这条需求到底为哪个目标服务。如果两条需求之间确实需要配合，用依赖标注单独表达，与归属关系分开呈现。
父需求的状态要不要跟着子需求自动变化？
从管理约定上看，父需求的状态应由子需求汇总得出：子需求全部完成，父需求才具备完成条件；有子需求被取消或延期，父需求的范围需要重新确认。这样上层目标与下层实际交付才不会脱节。
是否由工具自动汇总、汇总规则如何配置，取决于所用产品的实际能力，建议在选型或配置时向产品方确认。ONES 提供业务需求池、产品需求池与子工作项拆解，父子状态如何汇总、层级视图如何呈现，以实际产品配置为准。
需求层级图和需求追溯有什么区别，会不会重复维护？
两者回答的问题不同。需求层级图关注“由谁派生”，表达需求之间的父子归属与范围；需求追溯关注“是否被实现、是否被验证”，例如需求与设计、代码、测试用例之间的对应和覆盖检查。
实践中两者可以共用同一批需求条目，但关系类型分开维护：归属关系用父子连线，追溯关系用关联或覆盖标记。把两类关系混在一张图里，会让层级图承担过多信息，评审时难以聚焦范围问题。
层级图里的编号规则必须全团队统一吗？
建议统一。编号的作用是让层级脱离图形也能被读出，例如 BR-01 表示业务需求第 1 条，PR-01-2 表示 BR-01 下的第 2 条产品需求，SR-01-2-1 表示 PR-01-2 下的第 1 条子需求。段数与层级深度对应，插入新需求时在末段递增，不打乱已有编号。
具体规则可以由团队自行约定，关键是段数与层级保持一致、全团队使用同一套规则。规则不统一时，同一张图里会出现多种编号习惯，跨团队沟通和变更回看都会变慢。
