需求完整性评估的核心，是把“完整”拆成一组可核验的检查项，再按统一口径统计通过率：以评审时点提交的需求条目为分母，以必填检查项是否具备可验证内容为分子，统计首次通过率与返工率，并用后续变更和缺陷回溯验证指标是否有效。评估范围限于需求评审环节，结果用于判断需求是否具备进入开发的条件，不能单独当作需求质量的因果保证。
要点总览（TL;DR）
- 需求完整性评估把“完整”拆成可核验的检查项，以评审时点提交的需求条目为分母，统计条目完整度、批次完整率、首次通过率和返工率。
- 判定检查项“具备”要求有可验证的实质内容；待定项不计入通过项，不适用项从分母中扣除，缺失、待定、不适用三类分开记录。
- 计算分三步：逐条算条目完整度，按“全部适用项通过”判定完整条目，再汇总批次完整率与评审过程指标；分母为零时标记为不适用。
- 完整率只说明要素齐备程度，不代表需求价值高或实现风险低；不同检查项版本之间的结果不可直接比较。
- 指标有效性需用后续变更频次和需求类缺陷回溯验证，团队应先用两三个批次的历史数据建立自身基线，再讨论改进目标。
评估目标：完整性要回答哪几个判断
完整性评估服务于需求评审的放行与返工决策。评审会上需要回答的具体问题是：这条需求现在能不能进入开发？如果不能，缺的是哪一项，由谁补齐，什么时候再评？评估指标应当直接支撑这三个判断，而不是笼统地给需求打一个“质量分”。
评估需要区分两个层次。条目级完整看单条需求是否具备可核验的必填要素，例如背景、目标、范围、验收条件、优先级和依赖是否都有实质内容。需求集完整看一批需求在范围边界、相互依赖和优先级排序上是否自洽，例如两条需求是否描述了同一功能、A 需求的依赖是否已在 B 需求中覆盖。两个层次使用不同的检查项，统计时也应分开呈现，避免用条目级通过率掩盖需求集层面的冲突。
评估范围止于需求评审。方案原型评审关注交互与视觉方案是否成立，研发阶段决策关注技术路径与资源投入，这两类评审有各自的检查标准和参与角色，不纳入完整性指标的统计。把不同评审环节的结果混在一个指标里，会让数据无法解释，也无法定位问题。
指标与范围：分母、时间窗与检查项集合
指标要能复算，前提是固定三件事：分母、时间窗和检查项集合版本。三者任一变化，历史结果就不能直接比较。建议在指标定义表中把这三项与公式、单位一起写明，评审前公示，评审后按同一口径统计。
| 指标名 | 公式 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|
| 条目完整度 | 通过检查项数 ÷ 适用检查项数 | 该条目适用的检查项数 | 单次评审 | 百分比 |
| 批次完整率 | 完整条目数 ÷ 参评条目数 | 评审时点提交的参评需求条目数 | 一个评审批次或一个自然月 | 百分比 |
| 首次通过率 | 首次评审即通过条目数 ÷ 参评条目数 | 同上 | 同上 | 百分比 |
| 返工率 | 评审后需修改再评条目数 ÷ 参评条目数 | 同上 | 同上 | 百分比 |
分母取评审时点提交的参评需求条目数，而不是评审通过后的条目数，也不是开发排期中的条目数。这样统计的是“提交评审的需求有多完整”，避免把评审中被拆分的需求重复计数。时间窗按评审批次或自然月界定，两种口径不要混用：按批次适合观察单次评审质量，按自然月适合观察趋势，切换口径时应在报表中注明。
检查项集合需要版本管理。每次调整检查项（新增、删除或修改判定标准）都应记录版本号和生效时间，统计结果标注所用版本。跨团队对比完整率之前，先确认双方使用同一版本的检查项集合；版本不同，结果不可直接比较。
数据口径：必填字段与证据要求
判定一个检查项“具备”，标准是该字段有可验证的实质内容，而不是填了占位文字。以下字段清单可作为起点，团队可按业务类型增删，但增删需走版本管理。
| 检查项 | 通过标准 | 证据形式 |
|---|---|---|
| 背景 | 说明问题来源、影响对象和当前处理方式 | 需求文档中的背景段落，可引用数据或用户反馈 |
| 目标 | 给出可判断是否达成的结果描述 | 目标条目，含可观察的结果或指标 |
| 范围 | 明确包含与不包含的内容 | 范围清单或边界说明 |
| 验收条件 | 每条可被测试或演示验证 | 验收条件列表，与测试用例可对应 |
| 优先级 | 给出优先级取值及判断依据 | 优先级字段与排序理由 |
| 依赖 | 列出上下游系统、团队或前置需求，并说明影响 | 依赖清单，标注已确认或待确认 |
定性检查项同样需要证据。例如“范围明确”不能只凭评审人主观印象，应要求需求文档中写出包含项与不包含项，评审记录中注明确认人。证据形式可以是文档段落、评审会议记录中的确认结论，或关联的测试用例。评审记录与需求文档要建立对应关系：每条需求的评审结论、缺失项和责任人记录在同一条目下，便于后续按条目回溯，而不是散落在会议纪要里。
缺失值、待定项与不适用项要分开记录。缺失指应有内容但未填写；待定指已识别但尚未确认，需注明责任人和确认时间；不适用指该检查项对这条需求不成立，例如纯内部配置需求可能没有外部依赖。待定项不计入通过项，不适用项从该条目的分母中扣除。三类记录方式不同，统计结果才能解释清楚缺的是“没写”“没定”还是“不需要”。
计算步骤：从条目打分到批次汇总
计算分三步：先算条目，再算批次，最后算评审过程指标。每一步都保留原始分子分母，便于复核。
- 逐条计算条目完整度：条目完整度 = 通过检查项数 ÷ 适用检查项数。适用检查项数 = 检查项总数 − 不适用项数。待定项和缺失项都不计入通过项。
- 判定条目是否完整：建议将条目完整度达到 100%（即所有适用检查项均通过）记为完整条目。若团队希望设置部分通过档位，需在口径中明确档位阈值，并保持跨批次一致。
- 汇总批次完整率：批次完整率 = 完整条目数 ÷ 参评条目数。
- 计算首次通过率：首次通过率 = 首次评审即判定通过的条目数 ÷ 参评条目数。首次评审后被要求补充或修改的条目，不计入首次通过。
- 计算返工率：返工率 = 评审后需修改再评的条目数 ÷ 参评条目数。同一批次内多次返工的条目按条目计一次，返工次数可另设字段记录。
- 处理分母为零：当批次没有参评条目，或某条目的全部检查项均不适用时，结果标记为“不适用”，不记为零分，也不并入整体平均。汇总多个批次时，不适用批次从分母中剔除，并在报表中单列数量。
计算完成后保留条目级明细表，包含每条需求的通过项数、适用项数、缺失项清单和评审结论。批次汇总值应能由明细表复算得出，出现差异时以明细为准排查。
例子：一个评审批次的完整度核算
以下为演示情景，数据为假设，用于说明计算过程。某评审批次提交 6 条需求，检查项集合为 6 项（背景、目标、范围、验收条件、优先级、依赖），版本 v1.2。
| 需求条目 | 通过项数 | 不适用项数 | 适用项数 | 条目完整度 | 评审结论 |
|---|---|---|---|---|---|
| R1 | 6 | 0 | 6 | 100% | 首次通过 |
| R2 | 5 | 0 | 6 | 83% | 返工：缺验收条件 |
| R3 | 4 | 1 | 5 | 80% | 返工：依赖待定 |
| R4 | 5 | 1 | 5 | 100% | 首次通过 |
| R5 | 3 | 0 | 6 | 50% | 返工：目标、范围、验收条件缺失 |
| R6 | 6 | 0 | 6 | 100% | 首次通过 |
按“全部适用检查项通过”判定完整条目，完整条目为 R1、R4、R6，共 3 条。批次完整率 = 3 ÷ 6 = 50%。首次通过率为 3 ÷ 6 = 50%。返工率为 3 ÷ 6 = 50%，返工条目为 R2、R3、R5。
缺失项分布显示：验收条件缺失出现在 R2 和 R5，共 2 次；目标与范围缺失集中在 R5；依赖待定出现在 R3。这一分布提示检查项集合中“验收条件”的填写质量是主要短板，下一批次可针对该字段补充填写指引或示例。R4 因依赖项不适用而分母减少，其 100% 只代表 5 个适用项全部通过，与 R1 的 6 项全通过含义不同，解读时需注意。
解读与限制：指标能说明什么、不能说明什么
完整率说明的是要素齐备程度，即需求在评审时点是否具备进入开发所需的信息。它不能说明需求价值高、实现风险低或用户一定需要。一条完整率 100% 的需求，仍可能在开发中因技术方案不成立而返工；一条完整率较低的需求，也可能因为业务紧迫而优先排期。指标用于放行判断和缺口定位，不用于评价需求本身的商业价值。
不同检查项集合之间结果不可直接比较。检查项从 6 项增加到 8 项、判定标准从“有内容”收紧为“可测试”，都会改变通过率。跨团队或跨季度对比前，先核对检查项版本和分母口径；口径不一致时，应分别呈现或重新按统一口径计算，而不是直接比较百分比。
指标有效性需要回溯验证。可以观察完整率较高的批次在后续开发中的变更频次和需求类缺陷分布：如果完整率提升后，因需求描述不清导致的变更和缺陷仍然集中，说明检查项集合没有覆盖真正的风险点，应调整检查项而不是继续追求通过率。验证周期建议覆盖至少一个完整的开发迭代，并与变更记录、缺陷记录按需求条目关联。
避免把单一完整率当作需求绩效的全部。评审放行判断可以以完整率为主要依据，但需求绩效还涉及交付结果、变更控制和缺陷情况，应组合使用。团队首次建立该指标时，可先统计两三个批次的历史数据形成自身基线，再讨论改进目标；通用达标线并不存在，阈值应来自团队数据而非外部套用。
在评审执行层面，需求条目、检查项字段和评审结论需要落在同一处可追溯的记录中。ONES 的工作项可以承载需求条目及其字段，评审记录与需求文档可在条目下关联，使每条需求的通过项、缺失项和返工结论有据可查，批次汇总时可直接从条目明细复算，减少口径漂移。具体字段配置和报表能力可结合团队现有流程向厂商确认后落地。
常见问题
检查项集合调整后，历史完整率还能直接和新的结果比较吗？
不能直接比较。新增、删除检查项或收紧判定标准，都会改变通过率和分母，历史结果对应的是旧版本口径。建议每次调整都记录版本号和生效时间，报表中标注所用版本；需要看趋势时，可以按新版本口径重算历史批次，或者把调整前后的数据分段呈现，在分段处注明口径变化。
评审时有些字段确实还没定，应该算缺失还是待定？
看是否已经识别并安排了确认动作。缺失指应有内容但未填写；待定指内容已识别但尚未确认，需要注明责任人和确认时间。两者都不计入通过项，区别在于后续跟进方式：缺失要回到需求编写环节补齐，待定要在约定时间前完成确认。如果某检查项对这条需求本身不成立，例如纯内部配置需求没有外部依赖，则记为不适用，从该条目的分母中扣除。
批次里只有一两条需求时，完整率还有参考价值吗？
样本很小时，百分比波动会被放大，一条需求的差异就能让完整率变化几十个百分点。这种情况下建议同时呈现分子分母的原始数量，例如“3 条中 2 条完整”，而不是只给一个百分比；也可以把相邻几个批次合并统计，扩大样本后再看趋势。合并时需确认各批次使用同一版本的检查项集合。
完整率提升了，但开发阶段的需求变更没有减少，问题出在哪？
这通常说明检查项集合没有覆盖真正的风险点。可以按需求条目关联后续变更记录和缺陷记录，看变更集中在哪些字段或哪类需求上：如果变更多来自技术方案不成立，属于方案评审环节的问题；如果来自验收条件理解不一致，则应加强验收条件的可测试性要求。调整检查项后重新观察一个完整开发迭代，再判断指标是否有效。
条目完整度和批次完整率应该看哪个？
两者回答的问题不同。条目完整度定位单条需求的缺口，适合评审会上逐条讨论；批次完整率反映一批需求的整体提交质量，适合观察趋势和对比批次。建议在报表中同时保留条目级明细和批次汇总，批次值应能由明细复算得出，出现差异时以明细为准排查。
