需求完整性评估要回答的是：一条需求在进入开发前，是否具备可评审、可实现、可验证的信息。做法是把“完整”拆成背景与目标、用户与场景、功能描述、边界与异常、验收条件、依赖与约束等可核验要素，为每类要素设定二值检查项，再按评审批次统计完整率与缺失分布。本文给出指标定义、取数口径、计算公式、示例核算和结果解读边界，帮助团队得到可复算、可复核的评估结果。
要点总览（TL;DR）
- 需求完整性评估把“完整”拆成背景与目标、用户与场景、功能描述、边界与异常、验收条件、依赖与约束六类二值检查项，逐条判定通过与否。
- 单条需求完整度=通过检查项数÷适用检查项数；批次完整率=完整需求条数÷纳入评估需求条数，报告时须注明时间窗、需求类型和单位。
- 分母口径要事先写明纳入与排除规则，未评审、信息缺失、评审未结论三类缺失值分别计数，分母为零的批次只报告样本不足。
- 抽样复核由第二人独立判定并计算一致率，用于验证评估结果可信；完整率需与返工率、评审问题关闭情况结合解读。
- 完整率高只说明要素齐全，不说明需求方向正确或价值高；检查项口径固定后不同批次才可比较。
评估目标：需求完整性要回答什么问题
完整性评估的对象是需求条目本身，判断目的是它在进入开发前是否具备足够的信息支撑评审、实现和验证。评估不评价需求的价值高低，也不替代方案评审和商业判断，它只回答“信息是否齐全、是否可核验”这一层问题。
评估需要区分两个层级。单条需求完整性针对一条需求，看它是否包含全部适用要素，结论用于该需求能否通过评审准入。一批需求的整体完整率针对一个评审批次或一个时间窗内的需求集合，结论用于观察需求质量的整体水平和改进方向。两者口径不同，不能混用：单条结论是“通过/不通过”，批次结论是比例。
评估目的要在开始前写明，常见有三种。用于评审准入时，完整性结论作为需求能否进入开发的前置条件；用于质量改进时，重点看缺失项分布和返工情况，找出需求编写环节的薄弱点；用于验收核对时，重点核对验收条件是否明确、是否可测试。目的不同，检查项的取舍和统计范围会有差异，同一批数据按不同目的解读可能得出不同结论，因此评估开始前应固定目的并记录在评估说明中。
适用边界也需要说明。完整性评估覆盖需求文档和评审记录层面的信息要素，不覆盖原型交互细节、技术方案可行性、排期合理性等内容，这些属于其他评审环节的判断范围。
指标与范围：把完整性拆成可统计的检查项
把完整性拆成检查项，关键是每类要素对应一个可以判定“通过/不通过”的二值检查项，判定标准写在检查项定义里，避免不同评审人凭印象打分。下表给出一组常见要素与检查项的对应关系，团队可按需求类型增删，但同一评估周期内应保持稳定。
| 要素 | 检查项（二值判定） | 通过标准示例 |
|---|---|---|
| 背景与目标 | 是否说明需求来源与要达成的业务目标 | 能指出提出方、要解决的问题和期望结果 |
| 用户与场景 | 是否明确目标用户与使用场景 | 写明角色、触发条件和操作路径 |
| 功能描述 | 是否描述功能行为与输入输出 | 关键操作、数据项和结果可被理解 |
| 边界与异常 | 是否说明范围边界与异常处理 | 列出不做的范围及主要异常分支 |
| 验收条件 | 是否给出可验证的验收标准 | 每条标准可被测试或核对 |
| 依赖与约束 | 是否标明上下游依赖与限制条件 | 列出关联系统、前置条件和约束 |
统计范围要事先界定，通常按评审批次、需求类型和时间窗三个维度确定。例如“2025年3月第一次需求评审会纳入的、类型为业务需求的全部条目”。范围写清楚，分母才有意义，跨批次比较也才有基础。
分母口径是纳入评估的需求条目数。纳入规则和排除规则都要事先写明，例如排除重复提交的条目、排除仅做文案调整的条目。排除项必须有书面理由，不能因为“看起来不完整”而临时剔除，否则完整率会被系统性抬高。分母为零时该批次不计算完整率，只报告样本不足。
数据口径与证据：评审记录怎么取数
取数来源包括需求文档、评审记录、评审问题清单和返工记录。需求文档提供要素内容，评审记录和问题清单提供判定依据，返工记录用于后续验证评估结果是否可信。每条需求的每个检查项结果，都应能追溯到具体评审意见或文档位置，例如“验收条件缺失，见评审问题第7条”或“边界说明见文档第3.2节”。
缺失值要分开处理，不能默认按通过或按缺失计入。常见三类情况：需求未进入评审，单独计数，不计入完整率分子；需求已评审但某项信息缺失，该项判定为不通过；评审已进行但未形成结论，单独标记为“待定”，在报告中单列数量，不并入通过也不并入缺失。三类数量之和应与纳入评估的条目数一致，便于核对。
证据形式建议统一为三种：检查表记录每个检查项的判定结果和依据位置；评审纪要记录评审结论和遗留问题；问题关闭记录记录缺失项是否补齐、何时补齐。三种证据互相印证，复核时可以直接定位到原始记录。评审记录与问题跟踪如果分散在多个工具中，取数成本会明显上升，这也是评估能否持续执行的关键条件之一。
在评审记录与问题跟踪环节，ONES 可以承载检查项记录、评审结论和问题状态，使每条需求的判定结果与后续补齐动作留在同一处，便于按批次汇总和复核。ONES Assistant 智能助手可基于项目、工作项和 Wiki 页面等已有上下文回答问题并执行操作，例如将 PRD 拆解为需求和任务并按模块分配负责人，结果保存为工作项或 Wiki 页面，为需求条目和评审材料提供统一的记录位置。具体检查表模板和评审问题清单的组织方式，需结合团队现有流程在 ONES 中配置。
计算与评估步骤：从检查项到完整率
计算分两个层级。单条需求完整度 = 通过检查项数 ÷ 适用检查项数。适用检查项指对该需求类型确实需要判定的项，不适用项从分母中剔除并注明原因。批次完整率 = 完整需求条数 ÷ 纳入评估需求条数，其中“完整需求”指全部适用检查项均通过的需求。报告完整率时必须同时注明时间窗、需求类型和单位（条），否则数字无法比较。
执行步骤建议按以下顺序进行：
- 确定评估目的和统计范围，写入评估说明，固定纳入与排除规则。
- 按需求类型确定适用检查项清单，逐项写明通过标准。
- 由评审人逐条判定并记录依据位置，缺失值按未评审、信息缺失、评审未结论三类标记。
- 计算单条完整度和批次完整率，核对三类缺失数量与纳入条目数是否一致。
- 按要素统计缺陷分布，即每个检查项的不通过条数占纳入条数的比例，识别高频缺失项。
- 进行抽样复核，抽取一定比例需求由第二人独立判定，计算一致率 = 两人判定相同的检查项数 ÷ 复核检查项总数。
分母为零的批次不计算完整率，只报告样本不足及原因。抽样比例和一致率的可接受范围由团队在评估说明中约定，本文不给出通用阈值；一致率偏低时，应先检查检查项定义是否清晰，再判断评审质量。
例子：一个评审批次的完整性核算
以下为演示情景，数字为假设，用于说明公式和缺失值处理。某批次纳入20条需求，设定6个适用检查项，共120个检查项判定。判定结果为：通过96项，缺失18项，不适用6项。按适用检查项计算，适用判定数为114项，通过率为96÷114≈84.2%。
其中完整需求（6项全部通过）为14条，批次完整率 = 14 ÷ 20 = 70%。另有2条需求因信息缺失未进入评审，按口径单独计数，不计入完整率分子，但仍计入分母20条，因为它们属于本批次纳入评估的范围。剩余4条为部分检查项不通过，计入分母但不计入完整需求。
按要素统计缺陷分布，假设验收条件缺失出现在6条需求中，边界与异常缺失出现在5条需求中，两项合计占缺失项的多数，说明需求编写环节在这两类要素上最薄弱，可作为下一轮改进的重点。
抽样复核抽取5条需求、共30个检查项，由第二人独立判定，其中27项判定相同，一致率 = 27 ÷ 30 = 90%。复核中出现的3项分歧集中在“验收条件是否可验证”的判定上，说明该检查项的通过标准需要进一步细化。这个例子展示了完整率、缺失分布和一致率三个结果如何从同一批记录中算出，任何一步的原始判定都可以回溯到评审记录。
解读与限制：完整率说明什么、不说明什么
完整率高表示需求要素齐全、描述具备可核验的基础，它不直接说明需求方向正确、价值高或优先级合理。一条要素齐全的需求仍可能在评审中被否决，也可能在开发中因外部依赖变化而返工。完整率是需求质量的输入条件之一，不能当作质量保证或绩效结论单独使用。
跨批次比较有前提。检查项设计、通过标准和分母口径发生变化后，不同批次的完整率不可直接比较，需要固定口径后再看趋势。样本量小或评审人单一也会导致结果波动，几條需求的判定差异就可能让完整率大幅变化，此时更适合看具体缺失项而不是比例。
解读时应结合其他数据。完整率与返工率、评审问题关闭情况一起看，能判断缺失项是否在评审后得到补齐；如果完整率上升但返工率没有下降，说明检查项可能没有覆盖真正影响开发的信息。检查项也需要定期校准，随着需求类型和业务复杂度变化，过时的检查项会让指标失去区分度。评估说明中应记录每次口径调整的时间和原因，保证历史数据可追溯。
常见问题
需求条目在评审前被临时补充信息，完整性结果应该按补充前还是补充后计算？
按评估说明中约定的判定时点计算。常见做法是以评审会开始时的文档版本为准，补充内容记入评审问题关闭记录，作为下一批次或返工数据使用。如果团队希望观察“评审推动补齐”的效果，可以同时记录补充前和补充后的判定结果，但两个数字要分开报告，不能混入同一个完整率。判定时点一旦确定，同一批次内所有需求都按同一时点取数，避免口径漂移。
不同需求类型的检查项数量不一样，批次完整率还能直接比较吗？
检查项数量不同本身不影响批次完整率的定义，因为完整率的分母是纳入评估的需求条数，分子是全部适用检查项均通过的需求条数。需要注意的是检查项清单和通过标准是否一致：如果业务需求和技术需求使用不同的检查项，两类需求的完整率应分类报告，或者先按需求类型分别统计再汇总。跨批次比较的前提是检查项设计、通过标准和分母口径都保持稳定，口径调整后应记录调整时间和原因，历史数据只做参考。
抽样复核的一致率偏低时，应该先改检查项还是先换评审人？
先检查检查项定义是否清晰。一致率低通常说明判定标准存在歧义，例如“验收条件是否可验证”这类检查项，不同评审人对“可验证”的理解可能不同。处理顺序建议是：先复核分歧集中的检查项，把通过标准改写成可对照的具体条件；再对同一批需求重新判定，看一致率是否改善。如果标准已经明确、分歧仍然集中，再考虑评审人培训或调整复核范围。本文不给出通用的一致率阈值，可接受范围由团队在评估说明中约定。
完整率连续几个批次上升，但开发返工没有减少，说明什么？
可能说明检查项覆盖的信息与开发实际需要之间存在偏差。完整率衡量的是检查项是否通过，如果检查项集中在文档格式或背景描述，而开发返工主要来自接口依赖、异常分支或验收标准不清，指标上升就不会带来返工下降。此时应回看缺陷分布和返工原因，把高频返工对应的要素补进检查项，并定期校准。另一种可能是缺失项在评审后补齐了，但补齐的内容质量不足，需要结合评审问题关闭记录判断补齐是否真正解决了问题。
团队规模较小、每批次需求只有几条时，还有必要计算完整率吗？
样本量很小时，完整率的比例波动会很大，一条需求的判定变化就可能让结果大幅跳动，此时比例的说服力有限。更实用的做法是逐条列出缺失项和补齐动作，按要素统计缺失次数，观察哪类信息反复缺失。等批次需求条数积累到一定规模，再计算完整率并看趋势。无论规模大小，纳入与排除规则、缺失值分类和判定依据都应保持一致，这样后续数据才能衔接使用。
