需求规格说明书要进入评审，先要过“可评审”门槛：阻断项清零、关键检查项通过率达到团队约定线；评审通过后，还要等意见闭环、缺陷关闭、版本冻结，才具备“可基线化”条件。本文给出一套按条目打分的检查口径和可复算的判定步骤，达标线由团队结合项目风险约定，文中数字均为演示假设。
要点总览（TL;DR）
- 可评审看文档是否具备被审查的基础：阻断项清零、关键检查项通过率达到团队约定线；可基线化在此基础上叠加评审意见闭环、缺陷关闭和版本冻结。
- 质量检查项按完整性、一致性、可测试性、可追溯性四类组织，每条需求逐项给出通过、不通过、不适用三态结论，检查项清单在评审前锁定。
- 通过率按适用项数作分母计算，不适用项不计入分母，证据缺失记为不通过并单独标注；阻断项实行一票否决，通过率再高也不进入评审。
- 判定顺序为逐条打分、汇总通过率、识别阻断项、判定可评审，评审后按缺陷关闭率和意见闭环情况判定可基线化。
- 通过率只说明文档符合检查项的程度，不证明需求本身正确；分母过小或口径不一致时，跨版本比较的解释力有限。
评审与基线化各自要过哪道质量门槛
评审和基线化是两道递进的门槛，判断对象不同。可评审看的是“这份说明书是否具备被审查的基础”：条目齐全、表述可读、关键信息不缺，评审者能在有限时间内做出有效判断。可基线化看的是“评审结论是否已经落实”：意见逐条回应、缺陷关闭、版本冻结并留下变更记录。前者不通过，评审会变成边补文档边讨论，结论难以稳定；后者不通过，基线化会把未闭环的问题固化进受控版本。
可评审的准入条件通常包括两类。一类是阻断项清零，例如存在空白需求条目、关键术语未定义、需求无验收标准、引用来源失效等，这类问题会让评审无法形成有效结论，出现一项即不进入评审。另一类是关键检查项通过率达到约定线，例如完整性、可测试性等关键类别的通过率不低于团队设定阈值。阈值由团队按项目风险约定，风险高的项目可以设得更严。
可基线化的条件在评审准入之上叠加闭环要求：每条评审意见有处理结论（采纳、修改、驳回并说明理由），评审中发现的缺陷全部关闭或有明确延期记录，说明书版本冻结并标注基线标识，基线后的变更走变更记录。两阶段的先后顺序不能颠倒：先判定可评审，再组织评审，评审通过并完成缺陷关闭后才判定可基线化。
| 门槛 | 判断对象 | 核心条件 | 不通过的典型后果 |
|---|---|---|---|
| 可评审 | 说明书本身的质量基础 | 阻断项为零；关键检查项通过率达到约定线 | 评审效率低、结论反复，意见集中在补文档而非需求本身 |
| 可基线化 | 评审结论的落实情况 | 评审意见闭环；缺陷关闭；版本冻结；变更记录完整 | 未闭环问题进入受控版本，后续变更缺少依据 |
质量检查项与评分口径：完整性、一致性、可测试性怎么量化
量化质量的前提是把“写得好不好”拆成可逐条判断的检查项。建议按四类组织：完整性、一致性、可测试性、可追溯性。每个检查项对每条需求条目给出三态结论——通过、不通过、不适用，避免用模糊分数掩盖具体缺陷。检查项清单在评审前固定下来，同一版本内不随意增删，否则通过率无法复算。
| 类别 | 检查项示例 | 判定依据 | 是否关键项 |
|---|---|---|---|
| 完整性 | 需求描述、输入输出、边界条件、异常场景是否填写 | 条目字段无空缺，必填项有实质内容 | 是 |
| 完整性 | 优先级、来源、关联需求是否标注 | 字段有值且取值在约定枚举内 | 否 |
| 一致性 | 术语与术语表一致，同一概念全文同名 | 对照术语表逐条核对 | 是 |
| 一致性 | 引用文档、接口、数据定义与来源一致 | 引用可定位，版本与来源匹配 | 是 |
| 可测试性 | 每条需求有可验证的验收标准 | 验收标准可转化为测试用例或检查动作 | 是 |
| 可测试性 | 需求表述无歧义，量化指标带单位与范围 | 不存在“较快”“适当”等无法判定的表述 | 是 |
| 可追溯性 | 需求可追溯到来源（业务目标、上游需求、用户反馈） | 追溯矩阵中存在有效链接 | 是 |
| 可追溯性 | 需求可向下关联到设计或测试项 | 追溯矩阵中存在下游关联 | 否 |
计分口径需要明确三件事。第一，分母按“适用检查项数”计算，不适用项不计入分母，例如某条需求不涉及接口，则接口一致性检查记为不适用。第二，统计范围限定为本版本说明书的全部条目，跨版本比较时须说明各自范围。第三，缺失值按不通过处理并单独标注“证据缺失”，不能因为没查到证据就记为通过或跳过。通过率公式为：通过率 = 通过项数 ÷ 适用项数 × 100%，结果保留一位小数。
数据来源与证据：每条结论靠什么支撑
评估结论要能复核，每个“通过”或“不通过”都应有对应证据。主要证据来源包括：说明书文档条目本身（字段内容、术语表、附录）、评审记录（意见、结论、参会角色）、缺陷单（发现的问题、严重程度、关闭状态）、追溯矩阵（需求与来源、下游项的链接关系）。定性检查项同样需要证据，例如术语一致性以术语表为基准逐条比对，引用一致性以引用来源的实际版本为准。
证据缺失时的处理方式要事先约定：无法取得证据的检查项记为不通过并标注“证据缺失”，在评估结果中单列，供评审时优先确认；不适用项需写明理由，例如“本需求不涉及外部接口”，避免用不适用规避检查。评估完成后保留打分表与证据索引，使任何人可以按同一口径复算通过率。
在工具层面，需求条目、评审记录与文档版本如果分散在多个地方，复核成本会明显上升。ONES Wiki 支持页面组关联项目、需求与文档互相对应，文档实时同步并记录所有页面版本、支持查看与回滚，页面模板库可用于统一说明书结构；这些能力有助于把条目、评审依据和版本状态放在同一处管理，减少证据查找的断点。
计算与评估步骤：从逐条打分到准入判定
评估按固定顺序执行，保证结果可复算。第一步，确定本版本说明书的条目清单和检查项清单，锁定统计范围。第二步，逐条逐项打分，记录通过、不通过、不适用及对应证据。第三步，汇总各类别通过率，公式为通过项数除以适用项数再乘100%，同时统计阻断项数量。第四步，按规则判定准入：阻断项大于零则不通过；阻断项为零且关键检查项通过率达到约定线，则判定可评审。第五步，评审结束后统计缺陷关闭率，公式为已关闭缺陷数除以评审发现缺陷总数再乘100%，结合意见闭环情况判定是否可基线化。
- 阻断项实行一票否决：存在任一阻断项时，无论总体通过率多高，都不进入评审或基线化。
- 关键项与一般项分开统计，准入判定以关键项通过率为准，一般项通过率作为改进参考。
- 缺陷关闭率统计时，延期关闭的缺陷须有责任人和计划关闭时间，不能直接计入已关闭。
- 每次判定保留打分表、阻断项清单和评审记录，作为基线化前的检查依据。
一个算例：40条需求如何判定能否评审
以下数字为演示假设。某版本说明书共40条需求，检查项共10项，其中关键项6项、一般项4项。逐条打分后，适用项合计380项（部分条目存在不适用项，共20项不适用），通过项合计342项，总体通过率约为90.0%。关键项适用228项，通过205项，关键项通过率约为89.9%。阻断项检查发现2条需求缺少验收标准、1条需求引用了已失效的接口文档，共3个阻断项。
| 统计项 | 数值 | 说明 |
|---|---|---|
| 需求条目数 | 40 | 本版本全部条目 |
| 检查项数 | 10（关键6、一般4） | 评审前锁定 |
| 适用项数 | 380 | 400减去20个不适用项 |
| 通过项数 | 342 | 总体通过率90.0% |
| 关键项通过率 | 89.9% | 205÷228 |
| 阻断项 | 3 | 缺验收标准2项、引用失效1项 |
判定结论：尽管总体通过率和关键项通过率都接近90%，但阻断项为3，按一票否决规则，本版本不进入评审。需返工项为：为2条缺验收标准的需求补充可验证的验收标准，更新1条需求的接口引用至有效版本，并重新核对该条需求的一致性检查项。返工完成后重新打分，阻断项清零且关键项通过率达到约定线，方可提交评审。假设团队约定关键项通过率不低于90%，则返工后还需至少再通过1个关键项才能达标。
结果怎么解读：常见误判与限制
通过率反映的是文档符合既定检查项的程度，不能等同于需求本身的正确性。一条需求可能字段齐全、表述清晰、验收标准可测，但业务方向判断错误，这类问题只能通过评审中的业务判断发现。把高通过率当作质量保证，会削弱评审环节的实质审查。
分母过小或不适用项过多时，通过率的解释力下降。例如某类别只有3个适用项，通过2项得到66.7%，与上百个适用项的同类指标不具备可比性，应标注样本量。不同版本、不同团队之间比较时，需确认检查项清单、关键项定义和统计范围一致，否则差异可能来自口径而非质量。指标与后续需求变更频率、缺陷数量的关联需要另行观察，单次评估结果不构成对需求质量的长期结论。
评估结论落地时，评审意见、缺陷状态和版本冻结需要与文档条目保持对应。ONES Wiki 的页面版本记录与回滚能力，配合文档与项目任务的关联，可以帮助团队在基线化后追溯某条需求的修改过程；基线后的变更仍应通过变更记录留痕，使下一次评估有据可查。
常见问题
团队第一次做需求规格说明书质量评估，达标线怎么定比较稳妥？
达标线没有通用数值，建议从两个方向起步。先统计一到两个版本的实际通过率作为基线，再结合项目风险上调：对外交付、安全相关或返工代价高的需求，关键项通过率阈值可以设得更严；内部试验性需求可以适当放宽。阻断项清单建议一开始就固定，例如缺验收标准、术语未定义、引用失效，这类问题出现即不进入评审。阈值和清单确定后写进团队约定，后续版本沿用同一口径，通过率才有可比性。
检查项清单能不能在评审过程中临时增加？
不建议。检查项清单一旦在评审前锁定，同一版本内的通过率才能复算，评审者也才有统一的判断依据。如果评审中确实发现了清单未覆盖的问题，可以作为评审意见记录，纳入下一版本的检查项清单，并在版本说明中注明口径变化。临时加项会让已完成的打分失效，也容易让不同条目的分母不一致，导致通过率无法横向比较。
不适用项太多时，通过率还能直接用吗？
需要看具体类别。如果某个类别适用项只有个位数，通过率波动会很大，两三个条目的差异就能让比例变化十几个百分点，此时应同时标注样本量，避免直接与其他版本比较。如果整份说明书的不适用项占比明显偏高，建议先复核判定理由是否成立，例如“本需求不涉及接口”是否真的成立，防止用不适用规避检查。分母过小的类别，更适合逐条看缺陷内容，而不是只看比例。
评审通过了但缺陷没关闭，能不能先基线化？
按本文的门槛设定，不能。可基线化的条件是评审意见逐条有处理结论、缺陷全部关闭或有明确延期记录、版本冻结并标注基线标识。延期关闭的缺陷须写明责任人和计划关闭时间，单独列出，不能直接计入已关闭。把未闭环的问题固化进受控版本，后续变更会缺少依据，追溯时也难以判断某条需求的最终状态。如果项目进度压力大，可以考虑缩小基线范围，把已闭环的部分先冻结，未闭环部分留在下一批次。
评估结果和后续需求变更、缺陷有什么关系？
单次评估只反映当前版本文档符合检查项的程度，与后续变更频率、线上缺陷数量的关联需要另行观察。可以做的动作是把每次评估的通过率、阻断项数量与后续版本的变更次数、缺陷数放在一起对照，观察几个版本后再判断指标是否有参考价值。这种关联分析需要足够样本，短期内不宜据此调整阈值。评估结论落地时，保留打分表、阻断项清单和评审记录，配合文档版本记录，可以让下一次评估有据可查。
