评估需求分解质量，先要明确评估对象是需求层级——父需求、子需求与验收条件之间的关系，而非执行层的任务拆解。可用四个维度建立可复算指标：层级完整性、可追溯性、可执行性、粒度合理性，再配合抽样人工复核交叉验证。本文给出每个指标的公式、取数字段、分母为零与缺失值的处理规则，并用一组假设数据完整演算，帮助判断某次分解结果是否可用、是否存在遗漏。
要点总览（TL;DR）
- 评估需求分解质量，对象限定在需求层级：父需求、子需求与验收条件之间的关系，执行层任务拆解和跨研发对象追溯不纳入同一套指标。
- 四个维度各有公式：层级完整性看验收点被覆盖比例，可追溯性看子需求能否回指父需求与来源，可执行性看验收标准与责任人是否齐备，粒度合理性看规模是否落在团队约定区间。
- 分母为零时记为不适用而非0%，缺失字段单独计数、不默认按通过处理；结构指标全量统计，内容判断类指标按不低于20%或至少10个父需求抽样人工复核。
- 执行顺序为定范围、取数、校验数据、算指标、抽样复核、判定留档，每个数字都要能用导出表复算，结论指向具体需求编号和补充动作。
- 指标反映结构质量，不等同于交付质量；粒度约定因团队而异，跨团队不可比；不设通用达标线，也不宜直接用于个人绩效考核。
评估目标：判断分解结果是否可用、是否遗漏
需求分解质量评估要回答两个问题：父需求拆出的子需求是否覆盖了全部验收点，以及每条子需求是否具备继续流转的条件。结论用于决定这份分解结果能否进入评审、排期或开发，以及哪些部分需要退回补充。评估产出是一份带数据的结论，而非笼统的“拆得还行”。
评估对象限定在需求层级内部：父需求、其下的子需求、以及挂在需求上的验收条件。判断依据是这些对象之间的覆盖与关联关系，以及子需求自身字段的完整程度。执行阶段的任务拆解、研发任务与测试用例的覆盖关系、跨研发对象的追溯管理，属于另外的管理动作，不纳入本文指标，避免把不同层级的问题混在一张表里计算。
评估开始前需要写一份范围声明，至少包含：本次评估覆盖哪些父需求（按版本、模块或时间窗圈定）、评估基准日期、参与复核的人员、以及团队事先约定的通过标准。范围声明的作用是让后续数字有明确边界，不同批次评估之间可以对照。
指标与范围：四个维度及计算口径
四个维度分别回答不同问题，计算时都要写清分子、分母、单位和统计时间窗。建议以“父需求”为统计单位，时间窗取评估基准日前已进入“待评审”或之后状态的父需求集合，排除已取消和草稿状态，避免未定稿内容拉低指标。
| 维度 | 回答的问题 | 计算公式 | 单位与时间窗 |
|---|---|---|---|
| 层级完整性 | 子需求是否覆盖父需求全部验收点 | 被至少一条子需求覆盖的验收点数量 ÷ 父需求验收点总数 | 百分比；按父需求逐个计算后可汇总为加权平均 |
| 可追溯性 | 每条子需求能否回指父需求与来源 | 同时具备父需求关联和来源记录的子需求数 ÷ 子需求总数 | 百分比；统计窗口内全部子需求 |
| 可执行性 | 子需求是否具备验收标准与责任人 | 验收标准与责任人均已填写的子需求数 ÷ 子需求总数 | 百分比；统计窗口内全部子需求 |
| 粒度合理性 | 单条子需求规模是否落在约定区间 | 规模落在团队约定区间内的子需求数 ÷ 子需求总数 | 百分比；规模口径需团队事先定义（如故事点、预计工时区间） |
分母为零的处理规则要统一：某个父需求没有任何验收点时，层级完整性对该父需求记为“不适用”，不计入汇总分母，并在结论中单独列出这类父需求的数量，因为它们本身就是分解前的输入缺陷。子需求总数为零时，可追溯性、可执行性、粒度合理性三项均记为不适用，不能按 0% 处理，否则会把“没拆”误判为“拆得差”。
缺失值单独计数，不默认按通过处理。例如子需求未填责任人，在可执行性中计为未通过，同时在缺失清单中记录字段名，便于区分“填了但不合格”和“根本没填”。抽样范围与全量统计的取舍：结构类指标（可追溯性、可执行性）适合全量统计，成本低且口径稳定；层级完整性和粒度合理性涉及内容判断，可先全量算结构部分，再按不低于 20% 的比例或至少 10 个父需求抽样做人工核对，样本量不足时全量复核。
数据口径与证据：从哪些字段取数、如何人工复核
取数依赖四类字段：父子关联字段（子需求指向父需求的关联关系）、验收条件字段（父需求下的验收点条目）、责任人字段、状态字段。导出时按父需求分组，保留子需求的创建时间与当前状态，便于区分评估窗口内新增和窗口前遗留的内容。
数据一致性校验在算指标之前完成，重点查三类问题：孤儿需求，即子需求关联的父需求已被删除或不存在；循环关联，即 A 关联 B 的同时 B 又关联 A；重复关联，即同一子需求被重复挂到多个父需求下导致重复计数。发现这三类问题先修正数据再计算，修正记录随评估结果一并留档，否则指标会失真。
定性证据通过抽样评审采集：复核人逐条打开抽中的父需求，对照验收点检查子需求是否真正覆盖，而非只看关联字段是否存在。评审记录至少写明父需求编号、抽中的子需求、发现的问题类型（漏覆盖、覆盖但无验收标准、粒度明显过大或过小）、复核人姓名与日期。定性通过标准建议写成可判断的形式，例如“抽中样本中，存在漏覆盖的父需求不超过 1 个，且无验收标准的子需求占比低于 10%”，具体数值由团队在评估前约定。
当需求、子工作项与验收信息在同一套系统中管理时，取数和关联核对会顺畅很多。ONES 支持用子工作项对复杂需求进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来；在迭代规划阶段，团队就需求与验收标准达成一致后，设计、研发、测试人员可利用子任务拆分需求，便于后续处理和跟踪。评估所需的父子关联、验收条件、责任人与状态字段因此可以在同一需求池内导出核对，减少跨表比对的工作量。
计算与评估步骤：从取数到出结论
按以下顺序执行，每步都有明确输入和产出，前一步产出是后一步输入。
- 定范围。输入：版本或模块清单、评估基准日。产出：范围声明，含父需求清单和通过标准。完成标志是清单数量与系统筛选结果一致。
- 取数。输入：范围声明。产出：父需求、子需求、验收条件、责任人、状态的导出表。完成标志是导出条数与系统计数一致。
- 校验数据。输入：导出表。产出：孤儿、循环、重复关联的修正记录。完成标志是三类问题清零或已标注处理方式。
- 算指标。输入：修正后的数据。产出：四个维度的数值、分母、不适用项清单、缺失字段清单。完成标志是每个数字都能用导出表复算。
- 抽样复核。输入：抽样清单与评审记录模板。产出：定性证据与问题分类统计。完成标志是复核人签字、问题可回指具体需求编号。
- 判定与留档。输入：指标结果、复核证据、通过标准。产出：结论（可用、有条件可用、退回补充）及后续动作清单。完成标志是结论与证据一一对应，文件归档到评估记录目录。
异常数据的回退处理：若取数后发现范围声明中的父需求在系统中被合并或拆分，按基准日的实际状态重新圈定并更新范围声明，不沿用旧清单硬算。若抽样复核发现的问题集中在某一类需求（如接口类需求普遍缺验收标准），在结论中单列该类问题，不把它摊平到总体百分比里掩盖。
例子：一次分解质量评估的完整演算
以下为演示情景，数据为假设值。某团队评估一个版本内的需求分解，范围声明圈定 20 个父需求，共 60 条子需求，验收点合计 100 个。
层级完整性：100 个验收点中，被至少一条子需求覆盖的有 86 个，指标为 86 ÷ 100 = 86%。另有 2 个父需求没有任何验收点，按规则记为不适用，不计入分母，但在结论中单列。
可追溯性：60 条子需求中，同时具备父需求关联和来源记录的有 54 条，指标为 54 ÷ 60 = 90%。剩余 6 条中有 4 条缺来源记录、2 条父需求关联为空。
可执行性：验收标准与责任人均已填写的子需求为 48 条，指标为 48 ÷ 60 = 80%。缺失清单显示 9 条缺验收标准、3 条缺责任人，其中 1 条两项都缺，故未通过合计 12 条。
粒度合理性：团队约定单条子需求规模在 2 至 8 个故事点之间。60 条中落在区间内的有 51 条，指标为 51 ÷ 60 = 85%。超出区间的 9 条中，6 条超过 8 点，3 条低于 2 点。
抽样复核抽取 12 个父需求，发现 2 个父需求存在验收点被关联但子需求描述未真正覆盖的情况，1 个子需求粒度标注为 5 点但实际包含两个独立功能。按事先约定的通过标准（漏覆盖父需求不超过 1 个、无验收标准子需求占比低于 10%），漏覆盖数量超标，结论为“有条件可用”：整体结构指标达到约定水平，但需退回补充 2 个父需求的子需求描述，并复核 6 条超大规模子需求是否继续拆分。后续动作连同修正记录归档。
解读与限制：指标能说明什么、不能说明什么
四个指标反映的是分解结果的结构质量：覆盖是否完整、关联是否清楚、字段是否齐备、规模是否落在约定区间。它们不能直接说明交付质量，一个覆盖率和可执行性都很高的分解结果，仍可能因为需求理解偏差或技术方案问题导致交付不达预期。把结构指标当作交付质量的替代信号，会得出错误结论。
不同团队的粒度约定不同，粒度合理性指标在团队之间不可比。A 团队约定 2 至 8 点，B 团队约定 1 至 3 天，两者的百分比放在一起比较没有意义。跨团队汇总时只合并可追溯性和可执行性这类口径相对统一的指标，粒度类指标分团队呈现。
不设通用达标线。通过标准由团队在评估前约定，并随需求类型调整，例如探索型需求的验收点本身较难提前写全，标准应单独设定。指标也不适合直接用于个人绩效考核：一旦与考核挂钩，容易出现为凑覆盖率而过度拆细、为凑可执行性而补填字段的情况，指标数值上升但分解质量并未改善。评估结论应指向具体需求编号和补充动作，让改进落在内容上。
常见问题
父需求本身没有写验收条件，层级完整性该怎么算？
这类父需求按“不适用”处理，不计入层级完整性的汇总分母，同时在结论中单独列出数量。原因是验收条件缺失属于分解前的输入缺陷，把它算成0%覆盖会拉低整体指标，掩盖真正的问题来源。评估结论里应把这类父需求列为退回补充项，先补验收条件，再进入下一轮分解质量评估。
抽样复核抽多少个父需求合适，样本太少怎么办？
常见做法是按不低于20%的比例抽取，并保证至少10个父需求；当范围内父需求总数不足10个时，直接全量复核。抽样时按模块或需求类型分层，避免只抽到同一类需求。如果复核发现某类需求问题集中，可对该类追加抽样，追加部分单独记录，不与原样本混算通过率。
四个指标都达标，是否就可以判定分解结果可用？
不能只看指标数值。四个指标衡量的是覆盖、关联、字段和规模这些结构特征，抽样复核中发现的“关联存在但描述未真正覆盖”这类问题，指标本身反映不出来。判定时要同时满足两个条件：指标达到团队事先约定的通过标准，且抽样复核未发现超出约定数量的实质性问题。任一条件不满足，结论应写成“有条件可用”或“退回补充”，并列出具体需求编号。
评估中发现孤儿需求或重复关联，应该先修数据还是先算指标？
先修数据再算指标。孤儿需求会让可追溯性的分子分母同时失真，重复关联会让同一条子需求被多次计数，直接计算得到的数字无法复算。修正时保留修改前后的对照记录，随评估结果一并归档；如果问题量大到无法在本次评估窗口内修完，就把受影响的需求从统计范围中剔除并单独说明，不带着已知错误数据出结论。
需求分解质量指标能不能用来考核产品经理或需求负责人？
不建议直接挂钩个人绩效。指标一旦与考核绑定，容易出现为凑覆盖率过度拆细子需求、为凑可执行性补填字段的情况，数值上升但分解质量没有改善。更稳妥的用法是把评估结论落到具体需求编号和补充动作上，作为评审前的检查环节；如果确实需要团队级度量，也应结合抽样复核的问题类型分布一起看，避免单指标排名。
