检查需求规格说明书的完整性、一致性和可测试性，可以把三项质量目标拆成逐条核验的检查项，为每项定义证据来源、判定标准和统计口径，再按“逐条检查—汇总计数—评审判定”的顺序执行。完整性看要素、场景与追溯是否齐全，一致性看术语、编号和跨条目引用是否冲突，可测试性看每条需求能否写出可观察的验收条件。三项结果都达到项目事先约定的通过标准，文档才具备进入正式评审和基线化的条件。
要点总览（TL;DR）
- 三项检查分别回答不同问题：完整性看要素、场景与追溯是否齐全，一致性看术语、编号与跨条目引用是否冲突，可测试性看每条需求能否写出可观察的验收条件。
- 检查以需求条目为最小单位逐条打标，再汇总到文档级；分母在检查前锁定，缺失值计入分母，不适用项剔除并注明理由。
- 通过率 = 通过条目数 ÷ 适用条目数 × 100%，分母为零时标注“不适用”，不记为满分。
- 可评审与可基线化分两级判断：三项均达约定阈值进入评审，评审意见关闭且复检达标才允许基线化；阈值由项目在检查前书面约定。
- 通过率反映文档内容质量的一个切面，不能说明需求价值高或实现无风险，不同粒度、不同文档之间的结果不可直接比较。
检查目标：什么状态算可评审、可基线化
三项检查各自回答一类质量缺陷。完整性回答“该有的内容是否都在”，典型缺陷是需求缺验收条件、异常场景未覆盖、上下游引用断裂；一致性回答“不同位置的说法是否互相矛盾”，典型缺陷是同一对象两种叫法、编号重复或引用指向已删除条目；可测试性回答“这条需求能否被验证”，典型缺陷是只写“系统应友好高效”这类无法观察的表述。
可评审与可基线化是两个不同门槛。可评审指文档内容达到可以组织正式评审的程度，允许存在少量待确认项，但每项都应有明确的负责人和关闭计划；可基线化指评审意见已处理完毕、检查结果达到约定阈值、文档内容冻结为后续变更的基准。前者是过程门槛，后者是状态门槛，不能合并成一次判断。
三项结果合成放行判断时，建议采用“全部达标才放行”的规则，而非加权平均。完整性通过率再高，只要存在关键条目不可测试，基线化后仍会在测试阶段暴露争议。实际操作中可设两级：三项均达到约定阈值进入评审；评审意见关闭且三项复检仍达标，才允许基线化。阈值由项目在检查前书面约定，本文不给出通用达标线。
检查范围与指标口径
检查对象应明确到条目级。整份文档作为检查单位只能给出“通过/不通过”的粗结论，无法定位问题；以需求条目为基本单位逐条打标，再汇总到文档级，结果才可复算、可追溯。建议在检查开始前填写下表，固定范围与分母。
| 口径项 | 建议定义 | 记录方式 |
|---|---|---|
| 检查对象 | 指定版本的需求规格说明书，逐条需求为最小单位 | 记录文档名称、版本号、条目总数 |
| 统计分母 | 完整性、一致性以“适用需求条目数”为分母；可测试性以“适用需求条目数”为分母；场景覆盖类检查项以“应覆盖场景数”为分母 | 分母在检查前锁定，检查中不因发现新条目随意调整 |
| 版本与时间窗 | 以某一基线候选版本为检查对象，记录检查起止日期 | 版本号与日期同时写入检查记录 |
| 缺失值 | 条目存在但字段为空，记为“缺失”，计入分母、不计为通过 | 单独统计缺失数量 |
| 不适用项 | 该检查项对某条目确实不适用，记为“不适用”，从分母中剔除并注明理由 | 不适用数量与理由逐条记录 |
分母不清是结果不可比的常见原因。同一份文档，按“全部条目”和“剔除不适用项后的条目”计算，通过率可能相差明显。检查开始前锁定分母，检查过程中新增或拆分条目，应记录在变更说明中，并在汇总时说明对分母的影响。
完整性检查项与证据要求
完整性分三个层面检查：要素是否齐全、场景是否覆盖、追溯是否闭合。每项都要有可指认的证据，不能凭印象打勾。
| 检查项 | 证据形式 | 通过标准 |
|---|---|---|
| 要素完整性：标识、描述、优先级、来源、验收条件 | 需求条目字段截图或导出清单 | 约定必填字段全部有值，空字段数为零 |
| 场景完整性：正常流、异常流、边界条件、角色覆盖 | 场景清单与需求条目的对应矩阵 | 约定应覆盖的场景均有对应条目，无空白格 |
| 追溯完整性：上游来源与下游设计、测试的引用 | 追溯矩阵或引用关系导出 | 每条需求至少有一条上游来源，关键需求有下游引用，无孤立条目 |
要素完整性最容易核验，按字段逐条比对即可。场景完整性需要先列出应覆盖的场景集合，再检查每个场景是否有需求承接，矩阵中出现空白格即为缺口。追溯完整性关注闭合：上游来源指向业务目标或用户诉求，下游引用指向设计文档或测试用例，任一方向断裂都记为不完整。证据应保存为可复查的文件或系统记录，便于复核时逐条对照。
一致性检查项与冲突识别
一致性检查的核心是发现同一事实在不同位置的矛盾表述。可按四类逐项排查，每发现一处冲突记录冲突双方的位置、原文和判定依据。
| 检查项 | 识别方法 | 冲突记录内容 |
|---|---|---|
| 术语与定义 | 提取全文术语，与术语表比对；同一概念出现多种叫法即标记 | 术语、出现位置、建议统一写法 |
| 编号与引用 | 检查编号是否唯一、引用是否指向存在的条目 | 重复编号、悬空引用、循环引用 |
| 同一对象跨条目描述 | 按业务对象聚合相关条目，比对字段取值、取值范围、状态定义 | 对象名称、冲突字段、两处原文 |
| 与上下游文档对应 | 与上游来源文档、下游设计或测试用例逐项对照 | 对应关系、差异点、需确认方 |
术语冲突往往最隐蔽，建议在检查前先建立术语表，再全文检索同义表述。编号与引用冲突可以用清单方式机械核对，效率较高。跨条目描述冲突需要按业务对象重新聚合阅读，单条通读容易漏掉。与上下游文档的对应关系检查，重点看同一需求在上游来源和下游测试中的表述是否一致，差异处应明确以哪份文档为准并记录确认人。
可测试性检查项与验收条件写法
判断一条需求是否可测试，标准是：给定明确输入和前提，能否观察到一个确定结果，并能据此判定通过或失败。验收条件应包含四个要素：触发条件或输入、执行动作、可观察结果、判定阈值与单位。
- 可观察结果与明确前提：写明在什么环境、什么数据条件下，系统输出什么。例如“提交订单金额超过账户余额时，系统拒绝提交并提示余额不足”。
- 量化阈值、单位与判定方式：涉及性能、容量、精度时给出数值和单位，并说明测量方法。例如“单次查询响应时间不超过2秒，在100万条数据量下测量”。
- 验收条件与测试用例的对应：每条验收条件应能映射到至少一个测试用例，映射关系记录在追溯矩阵中，无法映射的验收条件视为不可测试。
- 不可测试表述的改写方向：把“友好”“高效”“尽量”“适当”等词替换为具体行为、数值或可观察状态；无法量化的主观要求，改为可检查的规则或评审确认项。
改写时保留原意，补充判定依据。例如“系统应快速响应用户操作”可改为“用户点击查询后，结果在2秒内展示；超过2秒显示加载提示”。后者给出了输入、可观察结果和阈值，测试人员可以直接设计用例。
计算与评估步骤：从逐条检查到汇总判定
执行流程分五步，顺序固定，便于复算和复核。
- 锁定范围与分母：按第二节口径表确定条目总数、适用条目数和不适用项，写入检查记录。
- 逐条打标：对每条需求，按完整性、一致性、可测试性三组检查项分别标记“通过”“不通过”或“不适用”，不通过项附证据位置和问题描述。
- 汇总计数：分别统计三项的通过条目数、不通过条目数、不适用条目数。
- 计算通过率：通过率 = 通过条目数 ÷ 适用条目数 × 100%，适用条目数 = 条目总数 − 不适用条目数。分母为零时标注“不适用”，不记为100%。
- 评审判定：评审会依据三项通过率和未关闭问题清单做决定。三项均达到约定阈值且无阻断级问题，判定放行进入基线化；任一项未达标，退回修改并约定复检时间。
复核与抽样验证用于控制检查质量。建议由未参与初检的人员抽取一定比例条目重新判定，比对初检结果；差异条目逐条讨论并修正。抽样比例和复核结论一并写入检查记录，作为结果可信度的说明。
检查过程涉及大量条目、验收条件和评审记录，承载方式会影响复核效率。ONES Wiki 支持文档关联项目任务、页面组关联项目，需求与文档可以互相对应；文档实时同步并记录页面版本，便于查看和回滚检查所依据的版本。在研发管理场景中，ONES 方案覆盖项目管理、知识库、测试管理等模块，可支撑从需求条目到评审记录的连续管理。检查项本身仍需按本文方法逐条判定，工具承担的是记录、关联与版本留痕。
示例：一份需求规格说明书的检查演算
以下为演示用假设数据，不代表真实项目结果。假设某版本需求规格说明书共120条需求，其中8条经确认不适用可测试性检查（如纯文档类说明条目），适用条目数为112条。
| 指标 | 条目总数 | 不适用 | 适用条目数 | 通过条目数 | 通过率 |
|---|---|---|---|---|---|
| 完整性 | 120 | 0 | 120 | 108 | 90.0% |
| 一致性 | 120 | 0 | 120 | 114 | 95.0% |
| 可测试性 | 120 | 8 | 112 | 98 | 87.5% |
计算过程：完整性 108 ÷ 120 = 90.0%；一致性 114 ÷ 120 = 95.0%；可测试性 98 ÷ 112 ≈ 87.5%。假设项目约定三项通过率均不低于90%方可基线化，则完整性达标、一致性达标、可测试性未达标，判定退回修改，重点补充14条不可测试需求的验收条件，修改后复检可测试性。
若某类条目全部不适用，例如某文档不含性能类需求，则对应检查项分母为零，记录为“不适用”，在汇总表中单列，不参与通过率计算，也不视为满分。不适用项的理由需逐条可查，避免用“不适用”掩盖实际缺失。
结果解读与限制
三项通过率反映的是文档内容质量的一个切面。通过率高说明要素、表述和引用关系较完整，不能说明需求价值高，也不能说明实现无风险。需求选错方向、业务规则本身有误，仍可能三项全部通过。检查结论应与业务评审、技术评审结合使用。
不同粒度、不同文档之间的结果不可直接比较。条目拆分粗细不同，分母差异明显；不同产品线的文档约定字段不同，通过率高低不能简单横向排名。比较应在同一口径、同一检查项版本下进行，并说明分母构成。
检查项权重与阈值应结合项目约定设定。关键系统可对可测试性设更高阈值，探索型项目可适当放宽完整性要求，但放宽理由和适用范围应书面记录。阈值一旦确定，同一基线周期内保持一致，避免事后调整口径。
检查结论有更新时机。基线化后发生需求变更，应对变更条目重新执行三项检查，并评估对追溯关系的影响；变更累积到一定数量时，建议对整份文档复检。检查记录、证据和评审结论随版本留存，作为后续审计和复盘的依据。
常见问题
检查开始后新增或拆分了需求条目，分母还能调整吗？
可以调整，但需要留下记录。建议在检查记录中写明新增或拆分条目的时间、原因和对分母的影响，汇总时说明调整前后的口径。更稳妥的做法是：检查启动时锁定分母，检查过程中发现的新条目先登记为待纳入项，等本轮检查结束后统一处理，下一轮复检时纳入分母。这样同一轮检查结果内部可比，也便于复核人员复算。
哪些条目可以记为“不适用”，会不会被用来掩盖缺失？
“不适用”指该检查项对某条目确实不成立，例如纯说明性条目没有可测试的行为要求，或某文档不含性能类需求。判定时应逐条写明理由，并由复核人员抽查确认。为避免用“不适用”掩盖缺失，可以设一条约束：不适用项数量超过一定比例时，要求检查人说明原因并提交评审确认。字段为空属于“缺失”，计入分母、不计为通过，与“不适用”严格区分。
三项通过率都达标，是否就可以直接基线化？
通过率达标是必要条件，不是充分条件。基线化还需满足：评审意见已全部关闭或有明确关闭计划，无阻断级问题，追溯关系在变更后仍然闭合。实际操作中建议先以三项通过率进入正式评审，评审通过并处理完意见后再做一次复检，复检仍达标才冻结为基线。若评审中发现业务规则本身有误，即使三项指标都高，也应退回修改。
检查由谁执行、如何保证结果可信？
初检可由需求作者之外的人员执行，减少自查偏差；复核由未参与初检的人员抽取一定比例条目重新判定，差异条目逐条讨论并修正。抽样比例和复核结论写入检查记录，作为结果可信度的说明。检查项清单、证据文件和判定结果随版本留存，便于后续审计和复盘时逐条对照。
基线化之后需求发生变更，检查结论怎么处理？
变更条目需要重新执行三项检查，并评估对追溯关系的影响：上游来源是否仍成立，下游设计与测试用例是否需要同步调整。变更累积到一定数量时，建议对整份文档复检，而不是只检查变更条目。检查记录、证据和评审结论随版本留存，使每次基线都有对应的检查结果可查。
