需求可验证性评估，是在需求评审阶段判断每条需求能否被客观检验：验收条件是否写明、判定依据是否可观测、度量口径是否可复算。评估结果用于形成评审结论和修改清单，不用于绩效排名。指标统计需要固定分母与时间窗，并用抽样复核校验判定一致性。需求单、验收条件字段和评审记录分散在文档与表格中时，可借助ONES的需求管理能力承载条目与评审记录，让取数有据可查。
要点总览（TL;DR）
- 需求可验证性评估在需求评审阶段进行，判断每条需求是否写有验收条件、判定依据是否可观测、度量口径是否可复算，产出评审结论与待修改清单。
- 用三个指标组合衡量：验收条件覆盖率（有验收条件需求数÷评审需求总数）、可测性达标率（可观测可判定需求数÷有验收条件需求数）、验收条件完备度（含判定标准、数据来源、边界条件三项的需求占比）。
- 统计前固定时间窗、需求来源、需求层级和是否含变更需求；分母为零时记为“不适用”并报告分子数量，不用0%或100%代替。
- 评估按确定范围、逐条判定、计算指标、抽样复核一致率、输出结论与清单五步执行，保留需求清单快照、判定记录和复核记录三份材料以保证可复算。
- 覆盖率与完备度反映验收条件的书写状态，需结合复核一致率解读；不同层级、不同团队口径不一致时不宜直接横向比较。
评估目标：评审阶段要判断需求是否可被检验
评估对象是进入评审环节的需求条目，包括新增需求和本次评审范围内的变更需求。评估要回答三个问题：这条需求有没有明确的验收条件；验收条件能否被观测和判定；判定所依赖的数据和口径能否被他人复算。三个问题都得到肯定回答，才可认为该需求具备可验证性。
评估产出有两项用途。一是支撑评审结论，对不满足条件的需求给出“补充验收条件”“明确判定依据”或“退回修改”的处理意见；二是形成待修改需求清单，作为下一轮评审的输入。评估结果反映的是需求文本和验收条件的完备程度，不衡量需求价值、优先级或团队绩效，也不应直接用于个人排名。
适用边界需要提前说明。本文讨论的是需求评审环节的可验证性判定，方案原型评审的具体方法、研发阶段的技术评审以及组织层面的阶段决策机制不在范围内。评估可以在单次评审批次内完成，也可以按固定周期汇总，两种用法共用同一套指标定义。
指标与范围：可验证性用哪几个指标衡量
可验证性适合用三个指标组合衡量，分别回答“有没有”“能不能测”“写得全不全”。三个指标共用同一批评审需求作为统计基础，但分母逐层收窄，解读时需要放在一起看。
| 指标 | 公式 | 分母 | 单位 | 回答的问题 |
|---|---|---|---|---|
| 验收条件覆盖率 | 有明确验收条件的需求数 ÷ 评审需求总数 | 本次评审范围内的全部需求条目 | 百分比 | 需求是否写明了验收条件 |
| 可测性达标率 | 验收条件可观测、可判定的需求数 ÷ 有验收条件的需求数 | 有验收条件的需求条目 | 百分比 | 写了的验收条件能否被检验 |
| 验收条件完备度 | 同时含判定标准、数据来源、边界条件三项的需求数 ÷ 有验收条件的需求数 | 有验收条件的需求条目 | 百分比 | 验收条件写得是否完整 |
统计范围需要在评估开始前固定，至少明确四项：时间窗，例如某次评审批次或某月内提交评审的需求；需求来源，例如业务方提出、内部优化或合规要求；需求层级，例如仅统计需求条目，或同时统计其下的子需求；是否包含变更需求。范围一旦确定，同一批次内不再调整，否则分子分母口径不一致，结果无法复算。
三个指标之间是递进关系。覆盖率低时，可测性达标率和完备度的分母变小，百分比可能虚高，此时应同时报告绝对数量。组织内首次使用时，建议先统一“明确验收条件”“可观测”“可判定”的判定说明，再开始统计，避免不同评审人按各自理解打分。
数据口径与证据：从哪些记录取数、如何判定
取数来源以需求单和评审记录为主。需求单提供需求条目、验收条件字段和需求层级；评审记录提供评审意见、评审结论和处理状态；测试用例关联信息可作为验收条件是否落到可执行检查的旁证。若验收条件写在需求描述正文而非独立字段，需要在取数时统一摘录到同一位置，否则统计时容易漏计。
定性证据用于支撑逐条判定，建议保留三类：评审意见记录，说明评审人对验收条件的质疑或确认；验收条件样例，作为“可观测、可判定、可复算”的参照；复核抽样记录，记录抽样条目、复核人和判定是否一致。判定标准可按三项分别给出可核验证据：
- 可观测：验收条件指向具体的业务对象、界面、数据或日志，评审人能在需求文本中指出对应位置。
- 可判定：验收条件给出通过与否的明确界限，例如数值区间、状态变化或可对照的清单，不依赖评审人主观感受。
- 可复算：验收条件写明数据来源和统计口径，换一个人按同样口径能得出相同结论。
缺失值需要事先归类，避免统计时随意取舍。验收条件字段为空，计入“无验收条件”，进入覆盖率分母但不进入可测性分母；字段填写了但内容为占位文字或“待补充”，按无验收条件处理；需求在评审中途变更，以评审时点的版本为准，变更后新增的验收条件不计入本批次；需求被撤回或合并，从本批次分母中剔除并单独记录数量。每类处理规则应在评估说明中写明，保证他人能按同一规则复算。
计算与评估步骤：从抽样到复算的完整流程
评估按固定步骤执行，每一步留下可核对的记录，最终结果才能被复核。以下流程适用于单次评审批次，周期汇总时按批次重复执行再合并。
- 确定统计范围与时间窗。写明批次名称、需求来源、需求层级和是否含变更需求，导出需求条目清单并锁定版本。
- 逐条判定验收条件。对每条需求记录三项信息：是否有验收条件、是否可观测可判定、是否含判定标准、数据来源和边界条件，并附上判定依据所在的字段或段落位置。
- 按公式计算各指标。先算覆盖率，再以有验收条件的需求为分母算可测性达标率和完备度。分母为零时，该指标记为“不适用”，同时报告分子数量，不用0%或100%代替。
- 抽样复核并计算一致率。从已判定条目中按需求层级分层抽取样本，由未参与初判的评审人独立复判，一致率等于复判结果与初判结果相同的条目数除以抽样条目数。一致率偏低时，先修订判定说明再重新统计。
- 输出评估结论与待修改需求清单。结论写明三个指标值、样本量、复核一致率和缺失值数量；清单逐条列出需求编号、缺失项和建议修改动作，交回需求提出方处理。
为保证可复算，评估过程应保留需求清单快照、逐条判定记录和抽样复核记录三份材料。任何人拿到这三份材料，按同一判定说明应能得出相同指标值。若两次计算结果不同，差异应能定位到具体条目或口径变化，而不是归因于“理解不同”。
例子：一个评审批次的可验证性计算
以下为演示情景，数字仅用于说明公式与分母处理，不代表任何真实项目数据。某次评审批次共有40条需求进入统计范围，其中32条填写了验收条件，8条验收条件为空或仅为占位文字。
| 项目 | 数值 | 计算 |
|---|---|---|
| 评审需求总数 | 40条 | 批次分母 |
| 有验收条件的需求 | 32条 | 覆盖率分子 |
| 验收条件覆盖率 | 80% | 32 ÷ 40 |
| 可观测且可判定的需求 | 24条 | 可测性分子 |
| 可测性达标率 | 75% | 24 ÷ 32 |
| 三项要素齐全的需求 | 18条 | 完备度分子 |
| 验收条件完备度 | 56.3% | 18 ÷ 32，保留一位小数 |
缺失值处理示例：8条无验收条件的需求计入覆盖率分母，不计入可测性和完备度分母；其中2条在评审中途变更，按评审时点版本判定为无验收条件，并在评估说明中单独记录变更数量。若某次评审全部需求均无验收条件，可测性达标率的分母为零，此时报告“不适用”，并说明32条中有0条可进入可测性判定，避免用0%造成误读。
结果转化为评审结论时，可以这样表述：本批次覆盖率80%，说明多数需求已写明验收条件；可测性达标率75%，说明已写条件中仍有四分之一无法客观判定；完备度56.3%，主要缺口在数据来源和边界条件。据此形成待修改清单，优先处理8条无验收条件的需求和8条不可判定的需求，其余需求补充数据来源与边界条件后进入下一轮评审。抽样复核若抽取10条，复判一致8条，一致率80%，则需在结论中注明判定说明仍需细化。
解读与限制：指标能说明什么、不能说明什么
覆盖率、可测性达标率和完备度描述的是需求文本和验收条件的书写状态，不直接代表需求本身的质量。覆盖率高的批次，仍可能存在验收条件写得笼统、无法执行的情况，因此需要结合复核一致率一起看。一致率低说明判定说明不够清晰，指标值本身的可信度下降，此时应先修订判定说明，再讨论指标高低。
不同需求层级、不同团队之间的指标不宜直接横向比较。需求层级不同，验收条件的写法要求不同；团队之间若判定说明、取数范围和缺失值规则不一致，百分比差异可能来自口径而非实际水平。跨团队比较前，应先对齐判定说明和统计范围，或只比较同一团队不同批次的变化趋势。
单个指标不能作为全部绩效依据。覆盖率可以通过补写验收条件快速提高，完备度可以通过模板化填写改善，这些动作反映的是文档完备程度，与需求交付效果之间没有必然因果关系。评估结果更适合用于改进验收条件的写法、优化评审检查项和调整评审流程，例如在评审模板中固定判定标准、数据来源、边界条件三个字段，或在评审前增加一次验收条件自检。
在需求条目和评审记录需要长期留痕、逐条追溯判定依据的场景中，ONES的需求管理能力可以承载需求单、验收条件字段与评审记录，使评估所需的取数来源和复核证据集中在同一处管理，减少跨文档摘录造成的口径偏差。具体字段配置和统计方式以团队实际使用为准。
常见问题
评审时间紧，能否只统计验收条件覆盖率一个指标？
可以只统计覆盖率，但要清楚它只回答“有没有写验收条件”。覆盖率高的批次里，验收条件仍可能笼统、无法判定，因此建议至少同时报告可测性达标率，或在结论中注明本次未评估可测性与完备度。若长期只用一个指标，容易把补写验收条件当成改进目标，而判定依据是否可观测、口径是否可复算得不到关注。
需求在评审中途变更，验收条件怎么计入本批次？
以评审时点的需求版本为准。变更后新增的验收条件不计入本批次，变更导致验收条件缺失的按评审时点版本判定为无验收条件，并在评估说明中单独记录变更数量。这样处理保证同一批次内分子分母口径一致，他人按同样规则能够复算。若变更频繁，可在下一批次单独统计变更需求的可验证性，观察其与新增需求的差异。
抽样复核的一致率多少才算可信？
一致率没有通用达标线，取决于判定说明的细化程度和样本量。实践中可先设定一个内部参考值，例如一致率低于80%时暂停解读指标高低，先修订判定说明并重新统计。样本按需求层级分层抽取，由未参与初判的评审人独立复判，抽样记录保留条目、复核人和判定结果，便于定位分歧集中在哪类验收条件上。
三个指标算出来之后，怎么落到评审动作上？
把指标拆回具体需求条目。无验收条件的需求进入“补充验收条件”处理；有验收条件但不可观测、不可判定的，进入“明确判定依据”处理；缺数据来源或边界条件的，补充后进入下一轮评审。待修改清单逐条列出需求编号、缺失项和建议动作，交回需求提出方，下一批次评估时对照清单检查改进情况。
在需求管理工具里做这套评估，需要准备哪些字段？
至少需要需求条目、验收条件、需求层级、需求来源、评审结论和处理状态几类信息，验收条件最好有独立字段而非混写在需求描述正文中，便于统一摘录和统计。测试用例关联信息可作为旁证。ONES 的需求管理能力可以承载需求单、验收条件字段与评审记录，使取数来源和复核证据集中管理；具体字段配置以团队实际使用为准。
