判断一份需求文档是否完整、是否可测试，需要把两个模糊的质量印象拆成可逐项核验的检查项：完整性看要素是否齐全、边界与异常是否覆盖、角色与数据是否写明；可测试性看每条需求能否写出带预期结果的验证用例。两项都按“通过、不通过、待补”三档判定，并记录证据位置，让结论可以复核。本文给出指标清单、证据规则、计算公式和一个完整演算示例，适用于需求评审、开发交接和验收前的文档检查。
要点总览（TL;DR）
- 完整性以单条需求为判定单位，检查背景与目标、角色与权限、功能与规则、数据与字段、异常与边界、依赖与约束六类要素是否写明，缺项记不通过或待补。
- 可测试性用操作性标准判断：每条需求能否写出前置条件、输入数据、操作步骤和可观察的预期结果，写不出预期结果即判不通过。
- 两项指标都按通过、不通过、待补三档判定，并记录原文位置或缺失说明，使结论可复核。
- 完整率=完整性通过条目数÷纳入评估条目总数，可测试率=可测试性通过条目数÷同一分母；分母口径须在评估前固定。
- 分数只反映文档内容质量，不评价需求业务价值；跨文档比较需统一指标定义、分母口径和评估版本。
评估目标：判断什么算完整、什么算可测试
完整性评估的对象是需求文档的内容要素，判定单位是单条需求条目。一条需求被判为完整，意味着它写明了背景与目标、涉及的角色与权限、功能行为与业务规则、数据与字段、异常与边界情况、外部依赖与约束这六类信息，读者不需要再向作者追问关键细节就能理解要做什么。文档篇幅长、章节格式整齐，并不等于完整；反过来，一份简短但要素齐全的需求可以判为完整。
可测试性评估的对象同样是单条需求，判定标准是操作性的一条：能否据此写出验证用例。能写出前置条件、输入数据、操作步骤和可观察的预期结果，这条需求就可测试；写不出预期结果，或结果只能靠主观感受判断，就判为不可测试。这个标准把“描述清楚”与“可以验证”区分开来，避免把文字通顺当成可测试。
两个维度都采用三档判定。通过表示检查项已满足且有原文依据；不通过表示检查项缺失或明显不足；待补用于信息暂时缺失、但无法确认是遗漏还是另有出处的情况，需要登记待确认问题和跟进责任人。评估结论主要用于三个场景：需求评审前的准入检查，决定文档能否进入评审；开发与测试交接时的确认，明确哪些条目还缺信息；以及复评触发，在文档修改后按同一口径重新打分。
指标与范围：完整性和可测试性各看哪些项
完整性维度设六项指标，每项对应文档中应当能找到的内容。判定时逐条需求检查，不按整篇文档笼统打分。
| 维度 | 指标 | 检查对象 | 判定口径 |
|---|---|---|---|
| 完整性 | 背景与目标 | 需求来源、要解决的问题、期望达成的结果 | 能说明为什么做、做完后什么会改变 |
| 完整性 | 角色与权限 | 涉及的用户角色、各角色可执行的操作与数据范围 | 每个操作都能对应到明确的角色 |
| 完整性 | 功能与规则 | 功能行为描述、业务规则、状态变化 | 规则可判定，不出现“视情况处理”而无具体条件 |
| 完整性 | 数据与字段 | 输入输出数据、字段含义、格式、必填与取值范围 | 关键字段有定义，取值规则可查 |
| 完整性 | 异常与边界 | 错误输入、空值、超限、并发、失败重试等场景 | 主要异常路径有处理说明 |
| 完整性 | 依赖与约束 | 依赖的外部系统、接口、前置条件、时间或合规约束 | 依赖项被点名，约束条件写明 |
可测试性维度设四项指标，检查的是这条需求能否转化为验证用例。
| 维度 | 指标 | 检查对象 | 判定口径 |
|---|---|---|---|
| 可测试性 | 可观察的预期结果 | 操作完成后系统或数据应呈现的状态 | 结果可被观察或查询，不依赖主观评价 |
| 可测试性 | 前置条件 | 执行验证前必须满足的环境、数据、权限状态 | 前置条件可准备、可描述 |
| 可测试性 | 输入数据 | 验证时使用的具体输入及取值范围 | 输入可构造，边界值可确定 |
| 可测试性 | 判定标准 | 通过与否的明确界线 | 存在可对照的规则、阈值或状态定义 |
指标与文档章节存在对应关系，但不要求文档按固定模板组织。背景与目标通常出现在需求说明开头，角色与权限多在用户场景或权限章节，功能与规则是主体描述，数据与字段常在字段表或接口说明中，异常与边界散落在各功能段落，依赖与约束多在附录或备注。评估时按内容找位置，找不到即记录缺失，不因章节名称不同而放宽判定。
本文范围限于需求文档的内容质量。文档协同、权限管理与知识库组织方式，AI 生成需求文档与评估报告，以及需求价值排序和优先级决策，均不在本文讨论之列。
数据口径与证据：每条判定要留下什么凭据
判定必须附证据，否则结论无法复核。证据采用“原文位置加摘录”的形式：写明章节号或段落位置，摘录支撑判定的关键句；判为不通过时，写明缺失的是哪类要素；判为待补时，登记待确认问题和跟进责任人。无法在原文中定位的判定不进入统计，避免凭印象计分。
三档判定的使用规则需要统一。通过要求检查项内容明确且有原文依据；不通过用于确认缺失或描述不足以支撑理解的情况；待补只用于信息可能存在于其他文档、但当前文档未体现且尚未确认的情形。待补项应有明确的确认时限和责任人，超时未确认的转为不通过，防止待补成为长期挂账。
分母口径必须在评估开始前固定并写入评估说明。常用口径有两种：以纳入评估的需求条目总数为分母，衡量“有多少条需求达标”；以检查项总数为分母，衡量“所有检查点的覆盖比例”。两种口径回答的问题不同，同一份文档用不同分母会得到不同数值，因此一次评估只选一种口径，跨文档比较时也必须保持口径一致。建议以需求条目数为分母，因为它与评审和交接的实际单位一致。
缺失值和无法判定项的处理规则同样要事先约定。需求条目本身描述过于笼统、无法拆出检查对象的，整条记为不通过并注明原因；某检查项因业务尚未确定而暂时无法判断的，记待补并登记；评估期间文档发生修改的，以评估基准时点的版本为准，修改后另行复评，不混入本次统计。
计算与评估步骤：从逐条检查到整体结论
评估按四步执行，每一步都有明确产物，最终结论可以按公式复算。
步骤一：拆分需求条目并编号。把文档拆成可独立验证的需求条目，每条分配唯一编号，例如 R-01、R-02。拆分粒度以“一条需求对应一组可验证的行为”为准，过粗会导致检查项无法逐项判断，过细则增加统计成本。产物是带编号的需求条目清单，同时确定本次评估的分母。
步骤二：逐条按指标打档并记录证据。对每条需求，分别按完整性六项和可测试性四项打“通过、不通过、待补”，每项附原文位置或缺失说明。产物是逐条判定表。判定时以条目为单位，不因同文档其他条目写得好而放宽本条。
步骤三：按公式计算完整率与可测试率。公式如下：
- 完整率 = 完整性判定为通过的需求条目数 ÷ 纳入评估的需求条目总数 × 100%
- 可测试率 = 可测试性判定为通过的需求条目数 ÷ 纳入评估的需求条目总数 × 100%
两个指标的分母相同，均为纳入评估的条目总数；分子只计“通过”，待补不计入分子。单位为百分比，统计时间窗为本次评估所依据的文档版本，评估说明中应写明版本号或基准日期。若需要看单项要素的覆盖情况，可另算分项通过率，分子为该要素判为通过的条目数，分母不变。
步骤四：汇总不通过项并给出补全优先级。把不通过项按影响归类：影响范围广、阻塞多条需求验证的要素优先补，例如角色权限或核心数据字段缺失；只影响单条需求边界场景的次之。产物是一份补全清单，列出条目编号、缺失要素、建议补充内容和责任人。补全完成后按同一口径复评，形成前后对比。
例子：一份需求文档的完整性与可测试性打分
以下为演示情景，数据为虚构，仅用于说明指标、证据与公式如何串联。假设一份需求文档拆出 10 条需求条目，编号 R-01 至 R-10，评估口径为以条目数为分母。
逐条判定后得到如下汇总：完整性判为通过的条目有 7 条，不通过 2 条，待补 1 条；可测试性判为通过的条目有 6 条，不通过 3 条，待补 1 条。以 R-03 为例，该条描述“用户提交申请后进入审核队列”，完整性检查中角色与权限项缺失——未写明哪些角色可以提交、审核队列由谁处理，判为不通过，证据为第 3.2 节原文摘录；可测试性检查中预期结果项缺失——未说明提交成功后页面或数据的状态，判为不通过。R-07 的异常与边界项因业务规则尚未确定，记待补，登记待确认问题并指定责任人。
按公式计算：完整率 = 7 ÷ 10 × 100% = 70%；可测试率 = 6 ÷ 10 × 100% = 60%。待补项不计入分子，因此两项指标都低于“全部通过”的状态，但待补项与不通过项在补全清单中分开处理：不通过项需要补充内容，待补项需要先确认信息是否存在。
分母为零的情形需要单独约定。若文档尚未拆分出可评估的需求条目，完整率和可测试率均无定义，此时不输出百分比，结论记为“不具备评估条件”，先完成条目拆分再评估。若部分条目因信息严重不足无法判定，按前述规则整条记不通过，仍计入分母，保证分母稳定、结果可复算。
从分数到动作的解读要结合条目分布。完整率 70% 说明有三成条目在要素上存在缺口，补全清单应优先处理影响多条需求的角色权限和数据字段问题；可测试率 60% 说明有四成条目暂时写不出验证用例，测试团队可据此判断哪些条目需要作者补充预期结果后再进入用例设计。分数本身不评价需求价值，只反映文档当前的可读与可验证程度。
解读与限制：分数能说明什么、不能说明什么
完整率和可测试率反映的是文档内容质量，与需求本身的业务价值无关。一条需求可能写得完整、可测试，但优先级很低；另一条需求价值很高，文档却写得粗糙。评估结论用于判断文档能否进入下一环节，不用于判断该不该做这个需求。
跨文档比较存在明显限制。不同文档类型（如功能需求、接口需求、数据需求）的要素构成不同，规模差异也会影响分母，直接比较两个百分比意义有限。若确需横向对比，应保证指标定义、分母口径和评估版本一致，并在结论中注明文档类型与规模。同一文档在不同时间点的复评结果可比性更强，适合用来观察补全效果。
指标达标与后续实现质量之间没有必然的因果保证。文档完整、可测试，能减少开发和测试阶段的追问与返工，但实现质量还取决于设计、编码、测试执行等环节。把完整率或可测试率当作质量保证的证明，或直接作为个人绩效依据，都会超出指标本身的适用范围。
复核与复评需要设定触发条件。常见触发包括：文档版本发生实质性修改、评审中提出影响多条需求的异议、待补项超过约定时限未确认、以及进入验收前需要确认文档与实现的一致性。复评沿用同一口径和同一分母规则，结果与上次评估并列记录，便于观察变化。评估过程中涉及需求条目管理、逐条判定记录和评审状态流转时，可以在需求管理工具中承载：例如在 ONES 中按条目建立工作项、关联对应文档，把判定结果和待确认问题记录在条目上，评审通过后随状态流转进入下一环节，使证据位置和复评记录可追溯。
常见问题
需求条目拆分到什么粒度，评估结果才稳定？
拆分粒度以“一条需求对应一组可验证的行为”为准。拆得过粗，一条里混了多个行为，完整性和可测试性检查项无法逐项判断；拆得过细，统计成本上升，且容易把同一行为的多个描述重复计入分母。实际操作中可以先按功能点拆，再把包含独立判定规则或独立异常路径的部分单独列出。拆分结果形成带编号的条目清单，本次评估的分母就此固定，后续复评沿用同一拆分方式，结果才具备可比性。
待补项一直确认不下来，评估结论怎么处理？
待补项在登记时就应写明确认时限和责任人。超过约定时限仍未确认的，转为不通过并注明原因，避免待补长期挂账、稀释指标。如果待补项涉及业务规则尚未确定，可以在补全清单中标注为“需业务决策”，与文档写作缺失区分开，但统计口径不变：待补不计入分子，超时转不通过后同样不计入分子。复评时按新状态重新计算，并在记录中保留前后两次的判定结果。
同一份文档用条目数和检查项数做分母，结论会差多少？
两种口径回答的问题不同。以条目数为分母，衡量的是“有多少条需求整体达标”，与评审和交接的实际单位一致；以检查项数为分母，衡量的是“所有检查点的覆盖比例”，数值通常更高，因为一条需求只要多数检查项通过就可能拉高比例。同一份文档换分母会得到不同百分比，所以一次评估只选一种口径，跨文档比较时也必须保持一致。若需要看单项要素的覆盖情况，可以另算分项通过率，分母仍用条目数。
文档在评估过程中被修改了，本次统计要不要把新内容算进去？
以评估基准时点的文档版本为准，评估说明中写明版本号或基准日期。评估期间发生的修改不混入本次统计，修改后另行复评，两次结果并列记录。这样处理是为了保证分子和分母来自同一版本，结论可复算。如果修改涉及需求条目拆分的变化，复评时需要重新确定分母，并在记录中说明拆分调整的原因。
完整率和可测试率达标后，还需要做哪些衔接工作？
指标达标说明文档具备进入评审或交接的内容基础，后续仍需完成几件事：把补全清单中的不通过项落实到责任人和时间；把可测试性通过的条目交给测试团队设计用例，验证预期结果是否真的可观察；在评审中确认文档与实现的一致性。评估过程中涉及需求条目管理、逐条判定记录和评审状态流转时，可以在需求管理工具中承载，例如在 ONES 中按条目建立工作项、关联对应文档，把判定结果和待确认问题记录在条目上，评审通过后随状态流转进入下一环节。
