需求完整性评估要回答的是：一条需求在进入评审时，背景、目标、范围、验收条件、依赖与风险等要素是否已经写清，以及一个批次里有多少需求达到了这个标准。它限定在需求评审环节，产出的是可逐条复核的判定结果和可复算的完整率。开展评估前需要先约定“完整”的判定口径，否则不同评审人会对同一条需求给出不同结论。
要点总览（TL;DR）
- 需求完整性评估限定在需求评审环节，先约定“完整”的判定口径，再逐条判定、按批次汇总，避免不同评审人对同一条需求给出不同结论。
- 核心指标是需求完整率=完整需求数÷受评需求总数×100%，分母为进入评审议程的需求条目，草稿、重复条目和拆分后的子需求按规则排除。
- 判定依据是背景、目标、范围、验收条件、依赖、风险等要素清单，每项按写清、部分写清、缺失三档打分，证据来自需求文档、评审记录与评审结论。
- 部分完整可采用二值口径或要素得分折算口径，两者不可混用；分母为零或样本过小时标注不计算或仅作参考。
- 完整率只反映要素齐备程度，不说明需求是否正确或有价值，跨团队比较需口径一致，阈值按团队自身历史批次确定。
评估目标：评审时要判断需求完整到什么程度
需求完整性评估的直接目的，是判断单条需求的信息要素是否齐备，并定位一个批次中缺口集中在哪些要素上。它服务于三个具体用途：作为评审准入的检查依据，决定需求能否进入评审议程；作为返工定位工具，指出某条需求缺的是验收条件还是依赖说明；作为改进跟踪手段，观察后续批次的缺口类型是否减少。
评估对象是进入评审的需求条目本身，判定依据是需求文档中已经写下的内容。需求方案是否合理、原型是否可行、阶段决策是否通过，属于评审中的其他议题，不在完整性评估的范围内。把完整性判定与方案判断分开记录，可以避免“方案讨论很充分”掩盖“要素没写全”的情况。
评估结果应当能回答两个问题：这一批需求中，要素齐备的占多少；缺失主要发生在哪几类要素上。前者用于横向观察批次变化，后者用于安排具体的补充动作。
指标与范围：完整率怎么定义、统计哪些需求
核心指标是需求完整率，含义是在统计范围内，判定为完整的需求条目数占受评需求总数的比例。这个指标衡量的是文档要素的齐备程度，单位是百分比。为了让不同批次的结果可以放在一起看，需要同时固定统计对象、时间窗和纳入排除规则。
| 口径项 | 定义 | 说明 |
|---|---|---|
| 指标名称 | 需求完整率 | 单位：%，保留一位小数即可 |
| 统计对象 | 进入评审的需求条目 | 以评审议程中列出的条目为准，一条需求计一个单位 |
| 时间窗 | 按评审批次统计 | 例如“某月第2次需求评审会”，跨批次不合并计算 |
| 纳入规则 | 已提交评审材料、进入议程的条目 | 包括本次评审中因不完整被退回的条目 |
| 排除规则 | 草稿、重复条目、评审前已拆分的子需求 | 拆分后的子需求单独计数，避免与母需求重复 |
纳入与排除规则要在评估开始前写定，并在批次记录中注明。被退回的需求仍计入分母，因为退回本身说明该条目在评审时未达到完整标准；如果把它排除，完整率会偏高，缺口也会被隐藏。草稿尚未提交评审材料，不具备判定基础，应排除并在记录中说明数量。
统计单位统一为“需求条目”，不按页面数、字数或工作量加权。这样做的代价是大小需求权重相同，好处是判定简单、可复算，适合作为过程指标使用。
数据口径与证据：完整性靠哪些字段和记录判定
判定一条需求是否完整，需要一份事先约定的要素清单，以及每项要素的判定档位。下面是一份可直接调整使用的要素判定表，团队可以按需求类型增删要素，但同一批次内应使用同一版本。
| 要素 | 写清（2分） | 部分写清（1分） | 缺失（0分） |
|---|---|---|---|
| 背景 | 说明问题来源、受影响对象和当前做法 | 只提到问题，未说明影响范围 | 无背景描述 |
| 目标 | 给出可观察的目标结果或衡量方式 | 目标表述笼统，无法判断是否达成 | 无目标 |
| 范围 | 写明包含与不包含的内容 | 只写包含内容，边界不清 | 无范围说明 |
| 验收条件 | 列出可逐项核对的通过条件 | 有验收描述但不可核对 | 无验收条件 |
| 依赖 | 列出外部系统、团队或前置事项 | 提到存在依赖但未指明对象 | 未说明依赖 |
| 风险 | 写明主要风险及应对考虑 | 只列风险，无应对说明 | 未提及风险 |
判定证据来自三处：需求文档中的对应段落、评审记录中的讨论与提问、评审结论中的退回或补充要求。评审记录里出现的“验收条件待补”“依赖方未确认”等结论，可以作为该要素判为部分写清或缺失的依据。定性证据的通过标准是：两名评审人依据同一份文档独立判定，结论一致；出现分歧时以文档中可引用的原文为准，无法引用原文的按低档位计。
判定结果建议逐条记录要素得分、缺失类型和证据位置，形成可追溯的判定记录。这样在复核或解释完整率变化时，能回到具体条目而不是只看到一个总数。
计算与评估步骤：从逐条判定到批次完整率
完整率的计算公式为：需求完整率 = 完整需求数 ÷ 受评需求总数 × 100%。其中“完整需求数”指全部要素均判定为写清的需求条目数；“受评需求总数”指按纳入排除规则确定的条目数，即分母。
部分完整的需求如何处理，取决于评估目的。若只关心是否达到准入标准，采用二值判定：任一要素未写清即不计入完整需求数，完整率反映的是“一次通过”的比例。若希望观察补齐进度，可采用要素得分折算：单条需求得分除以满分，得到该条的完整度，再对批次求平均，得到平均完整度。两种口径不能混用，报告中应注明采用哪一种。
分母为零或样本过小时，应标注“不计算”或“仅作参考”，不与常规批次比较。例如某次评审只有2条需求，完整率只能是0%、50%或100%，波动来自样本量而非真实变化。可以约定一个最小样本量，低于该值时只记录逐条判定结果。
操作步骤可以按以下顺序执行：
- 确定批次与时间窗，按纳入排除规则列出受评需求清单，记录条目数和排除原因。
- 对每条需求按要素判定表逐项打分，记录证据位置和缺失类型。
- 汇总完整需求数，代入公式计算完整率；采用折算口径时同时计算平均完整度。
- 由另一名评审人抽取部分条目复核，核对判定与证据是否一致，分歧条目重新判定后更新结果。
- 将结果、分母、口径版本和复核情况一并记录，供后续批次对照。
当评审流程在协作工具中运行时，需求条目、要素字段和评审结论可以放在同一处管理：需求以工作项形式提交评审，完整性要素作为字段随条目填写，评审结论和退回原因记录在条目上，批次汇总时按评审状态筛选条目即可得到分母。ONES 支持在工作项中配置字段并记录评审相关状态，具体字段设置需按团队要素清单配置；这一衔接的作用是让判定记录与需求条目保持对应，减少汇总时的手工核对。
例子：一个评审批次的完整率计算
以下为演示情景，数字仅用于说明计算过程，不代表任何真实团队的数据。某次需求评审共列入12条需求，按纳入排除规则排除2条草稿和1条与已有条目重复的需求，受评需求总数为9条，即分母为9。
逐条判定采用二值口径，结果如下：6条需求六项要素均写清，计为完整；2条需求缺少验收条件，1条需求的范围与依赖两项为部分写清。完整需求数为6，完整率为6 ÷ 9 × 100% ≈ 66.7%。
按缺失类型拆分缺口：3条不完整需求中，验收条件缺失2条，占缺口条目的多数；范围不清1条；依赖说明不足1条（与范围不清为同一条需求）。据此可以判断，本批次的主要缺口集中在验收条件，改进动作应优先放在评审前的验收条件模板和提交检查上，而不是泛泛要求“写详细一点”。
若改用折算口径，6条完整需求各得12分，2条缺验收条件的需求各得10分，1条范围与依赖部分写清的需求得10分，批次总分为6×12+2×10+10=102，满分9×12=108，平均完整度约为94.4%。两个数字差异明显，说明二值口径对“差一项”的需求惩罚更重，报告中应说明采用哪种口径以及原因。
解读与限制：完整率能说明什么、不能说明什么
完整率说明的是要素齐备程度：在受评批次中，有多少需求把约定要素写清了。它不说明需求判断是否正确、方案是否有价值，也不说明交付后是否达到预期效果。一条要素齐全的需求仍可能在评审中被否决，一条要素不全的需求也可能方向正确。把完整率当作需求质量的唯一证据，会引导团队补文档而不是想清楚问题。
跨团队、跨需求类型比较时需要谨慎。不同团队约定的要素清单、判定档位和纳入规则不同，同一份文档在两套口径下可能得到不同结论；新建功能需求与缺陷修复类需求对背景、风险的要求本身不同。比较前应确认口径版本一致，否则只做各自批次内的纵向对照。
本文不给出通用达标线。阈值应基于团队自身的历史批次确定：先连续统计若干批次，观察完整率的分布和缺口类型，再设定一个需要触发补充动作的参考水平。阈值的作用是提示检查，不是考核排名。
完整率适合与其他信号结合使用，例如评审退回原因的分布、需求变更次数、验收阶段的返工情况。当完整率上升而返工没有减少时，需要检查要素清单是否覆盖了真正影响交付的信息，而不是继续提高完整率目标。
常见问题
需求评审会上时间有限，完整性判定应该放在会前还是会中做？
建议把逐条判定放在会前完成，会中只处理判定结果和分歧。评审人依据提交的需求文档独立打分，记录要素得分和证据位置；会上对判为缺失或部分写清的条目集中确认，重点讨论“验收条件待补”“依赖方未确认”这类结论是否成立。这样会议时间用于澄清缺口和决定是否退回，而不是现场逐项翻文档。判定记录随需求条目保存，会后可直接汇总成本批次完整率。
同一条需求在两次评审中判定结果不同，完整率还能比较吗？
先确认两次判定是否使用同一版本的要素清单和判定档位。如果口径一致而结论不同，通常是证据引用不充分：判定应以文档中可引用的原文为准，无法引用原文的按低档位计。若两次之间要素清单有增删，或纳入排除规则调整过，两个批次的完整率不具备直接可比性，应分别标注口径版本，只做各自批次内的纵向对照。复核环节抽取部分条目由第二名评审人独立判定，也有助于减少这类波动。
需求被评审退回后补充完整，完整率应该按退回时算还是按补充后算？
按退回时的判定结果计算。退回本身说明该条目在评审时未达到完整标准，它仍计入分母，否则完整率会偏高、缺口被隐藏。补充完成后可以在下一個批次重新纳入统计，作为新的一次判定记录。如果团队希望同时观察补齐效率，可以另外记录“退回后平均补齐时长”或“补充后复评通过率”，与完整率并列使用，但不要把补充后的结果回填到原批次，否则历史数据无法复算。
缺陷修复类需求要素少，和新建功能需求放在一起算完整率合理吗？
放在一起算会掩盖差异。缺陷修复类需求对背景、风险的要求与新建功能需求不同，用同一份要素清单判定，容易出现一类需求系统性偏低或偏高。可行的做法是按需求类型分组统计，各组使用适配的要素清单，报告时分别列出组内完整率和条目数；如果确需一个总数，应注明各组权重和口径差异，并避免用总数做跨团队比较。分组之后，缺口分析也更有针对性，例如修复类需求缺的往往是复现条件而不是目标描述。
完整率连续几个批次都很高，是否说明需求评审可以放松了？
完整率高只说明约定要素写得齐，不说明需求判断正确或交付顺利。此时应结合其他信号检查：评审退回原因的分布是否集中在方案层面、需求变更次数是否下降、验收阶段返工是否减少。如果完整率上升而返工没有变化，需要回头看要素清单是否覆盖了真正影响交付的信息，例如是否缺少对上下游接口的说明。阈值的作用是提示检查，不宜直接转为考核排名，否则容易引导团队补文档而不是把问题想清楚。
