需求规格说明书要进入评审，先要保证内容可读、可讨论、关键项没有空白；要通过评审并进入基线，还要保证评审意见已闭环、版本已冻结、变更入口已明确。本文给出完整性、一致性、可测试性三类检查项，以及可复算的通过率口径和从检查到基线冻结的操作步骤，帮助团队判断一份文档当前处于哪道门槛之前。
要点总览（TL;DR）
- 评审门槛看文档是否可读、可讨论、关键项无空白；基线化门槛看评审问题是否闭环、版本是否冻结、变更入口是否明确，两者不能混为一谈。
- 完整性、一致性、可测试性三类检查项要逐条记录判定结果和证据位置，不适用项需登记理由后从分母中剔除。
- 质量得分用通过率表示：通过项数÷适用检查项数×100%；采用加权口径时权重须在检查前固定，分母为零时报告为不适用而非0分。
- 基线化不能只看得分，判定依据是问题闭环状态与门槛条件；未关闭项须登记为已知风险、指定责任人和确认时限。
- 通过率只反映文档对检查表的符合程度，不能证明需求正确或价值合理，不同规模与复杂度的文档得分不宜直接横向比较。
评审与基线化分别要过哪道质量门槛
评审和基线化是两道先后衔接、判定标准不同的门槛。评审解决“这份文档是否值得组织专家讨论、讨论能否形成有效结论”；基线化解决“讨论产生的问题是否已经处置、当前版本能否作为后续开发和变更的参照基准”。把两者混为一谈，最常见的后果是评审会上意见很多、会后无人跟踪，文档却因为“已经评审过”被直接当作基线使用。
评审门槛的判断条件可以归纳为三条：文档结构完整，读者能按章节找到范围、角色、流程、规则和数据；关键项没有空白，即不存在“待补充”“TBD”占位的核心需求条目；术语和编号基本统一，评审人不会因为同一对象多种叫法而反复确认。满足这三条，文档具备可讨论的基础，可以发起评审。此时允许存在待确认问题和表述粗糙之处，评审的目的正是暴露并收敛它们。
基线化门槛建立在评审结论之上，判断条件同样可以归纳为三条：评审提出的问题已关闭，或者未关闭项已明确登记为已知风险并指定责任人；文档版本已冻结，基线对应的版本号、日期和范围可查；变更入口已明确，后续修改走哪条申请、由谁审批、如何记录，团队有统一约定。三条同时满足才可基线化，缺一条都应停留在“评审通过、待基线”的状态。
| 对比项 | 评审门槛 | 基线化门槛 |
|---|---|---|
| 核心问题 | 文档是否可读、可讨论 | 评审结论是否已闭环、版本是否可参照 |
| 关键条件 | 结构完整、关键项无空白、术语编号基本统一 | 问题关闭或登记风险、版本冻结、变更入口明确 |
| 允许的遗留 | 允许存在待确认问题和表述问题 | 不允许存在无责任人、无处置结论的遗留问题 |
| 主要责任角色 | 需求负责人组织，评审专家参与 | 需求负责人提交，评审组或项目负责人确认 |
| 产出物 | 评审记录、问题清单 | 冻结版本、基线说明、变更入口约定 |
顺序上，评审在前、基线化在后，中间隔着问题处置环节。责任分工上，需求负责人对文档内容和问题闭环负责，评审专家对评审意见的专业性负责，项目负责人或评审组对是否允许基线作出确认。三者职责分开，才能避免“写文档的人自己宣布基线完成”。
完整性、一致性、可测试性各查哪些项
三类质量要求需要落到可逐项勾选的检查项上，每项都给出判定依据，检查人才能给出稳定结论，而不是凭印象打分。以下检查项按文档实际适用范围选用，不适用的项应登记理由后从统计中剔除。
完整性检查项
- 范围边界：文档写明本次需求覆盖的业务范围和不覆盖的部分，判定依据是能找到明确的范围陈述句。
- 角色：列出使用系统的角色及其职责差异，判定依据是每个角色都能对应到至少一个使用场景。
- 主流程与异常流程：核心场景有正常路径描述，同时说明失败、超时、重复提交等异常路径的处理方式。
- 业务规则：金额计算、状态流转、审批条件等规则有明确表述，判定依据是规则可以被独立引用和验证。
- 数据项：关键输入输出字段的名称、类型、取值范围、必填性有说明。
- 非功能需求：性能、可用性、安全、兼容性等有可描述的指标或约束，判定依据是指标带有对象和条件。
一致性检查项
- 术语表：同一业务对象在全文中使用统一名称，判定依据是术语表与正文用词可对照。
- 需求编号：每条需求有唯一编号，判定依据是编号不重复、不跳号且有规则可循。
- 状态字段：需求条目的状态（草稿、待评审、已确认等）标注一致，判定依据是状态取值来自同一套定义。
- 上下游引用：引用的外部文档、接口、关联需求有准确指向，判定依据是引用可定位到具体条目。
- 重复与冲突：不存在两条需求描述同一功能却给出不同规则的情况，判定依据是交叉比对后无矛盾结论。
可测试性检查项
- 验收条件：每条需求配有可观察的验收条件，判定依据是条件能被转化为测试用例。
- 输入输出：需求写明触发条件、输入数据和预期输出，判定依据是给定输入能推出确定结果。
- 边界与异常：数值边界、空值、权限不足等情形有明确预期行为。
- 可观察结果：结果可以通过界面、日志、接口返回等方式确认，判定依据是不依赖“内部实现正确”这类不可验证表述。
每项检查记录三样东西：判定结果（通过、不通过、不适用）、证据位置（章节或条目编号）、问题描述（不通过时填写）。证据位置是复检和争议处理的关键，缺少位置的检查结论在复核时无法采信。
质量得分怎么算：口径、公式与分母处理
质量得分建议用检查项通过率表示，公式为：通过率 = 通过项数 ÷ 适用检查项数 × 100%。分子是判定为通过的检查项数量，分母是扣除不适用项后的检查项总数。不适用项必须单独登记理由，例如纯后台批处理需求不涉及界面角色，相关角色检查项可标为不适用，但不能直接算作通过。
当检查项严重程度差异较大时，可采用加权得分：加权得分 = Σ（检查项得分 × 权重）÷ Σ权重。权重在检查开始前确定并写入检查表，同一版本内不中途调整，否则前后得分不可复算。一种常见口径是把影响范围边界、业务规则、验收条件的检查项设为高权重，把术语统一、格式规范类检查项设为低权重，具体数值由组织根据自身风险偏好设定，本文不给出通用达标线。
缺失值和分母为零需要单独处理。检查项未执行时记为“未检查”，不计入分子也不计入分母，并在报告中单列未检查项数量；全部检查项都不适用时，报告为“不适用”，不输出0分，避免把不适用误读为质量差。统计时间窗和版本范围要在评分前写明，例如“统计对象为V1.2版本需求规格说明书，检查执行日期为评审会前三个工作日”，跨版本合并统计会掩盖版本间的质量波动。
| 口径要素 | 定义 | 处理规则 |
|---|---|---|
| 分子 | 判定为通过的检查项数 | 仅有证据支撑的通过才计入 |
| 分母 | 适用检查项数 | 不适用项登记理由后剔除，未检查项不计入 |
| 权重 | 按严重程度预设 | 检查前固定，版本内不调整 |
| 分母为零 | 无适用检查项 | 报告为不适用，不记0分 |
| 时间窗 | 检查执行日期与文档版本 | 评分报告中必须写明 |
从检查到评审通过、基线冻结的操作步骤
检查、评审、基线化是一条有先后依赖的流程，每一步都有明确的执行角色、记录证据和判定动作。下面按操作顺序展开。
- 需求负责人自检。按检查表逐项核对，填写判定结果和证据位置，把不通过项转为问题单，标注严重程度和责任人。完成标志是检查表填写完整、问题单已建立。
- 检查人复核。由未参与编写的评审成员抽查关键项，重点核对高权重检查项的证据是否成立。完成标志是复核意见记录在检查表或问题单中。
- 发起评审。需求负责人提交文档、检查表、问题单和评审议程，评审专家提前阅读。完成标志是评审会按期召开并形成评审记录。
- 评审结论判定。评审组逐条确认问题，区分必须修改、可以后续优化、不予采纳三类，并给出结论：通过、有条件通过、退回修改。完成标志是评审记录中有明确结论和签署人。
- 问题闭环。需求负责人修改文档并更新问题单状态，必须修改项全部关闭或有条件通过项登记为已知风险并指定责任人。完成标志是问题单中无未处置的必须修改项。
- 基线冻结。确认版本号、冻结日期和基线范围，锁定当前文档版本，明确后续变更的申请入口和审批人。完成标志是基线说明发布，团队可查到冻结版本和变更入口。
- 退回与复检。评审结论为退回的文档，修改后重新执行自检和复核，再提交复评；复评只针对上次问题及受影响章节，避免全量重审拖慢节奏。
证据记录贯穿全流程：检查表记录逐项判定，问题单记录问题描述、责任人和关闭状态，评审记录记录结论和签署。三类记录相互引用，复检时可以直接定位到上次未通过项。文档与检查记录分散在多个工具中时，版本对应关系容易断裂。ONES Wiki 支持页面组关联项目、需求与文档互相对应，并记录页面版本、支持查看与回滚，可用于承载冻结版本和检查记录的对应关系；评审问题单的流转则可在项目任务中跟踪，使问题关闭状态与文档版本保持关联。具体评审流程和基线标记的操作方式，以团队实际配置为准。
一个算例：12项检查如何得出可否基线化
假设某版本需求规格说明书共设置12项检查，其中1项因该需求不涉及界面角色被登记为不适用，实际适用11项。检查结果如下：完整性4项中3项通过、1项不通过（异常流程缺失）；一致性4项中3项通过、1项不通过（两处术语不一致）；可测试性3项中2项通过、1项不通过（一条需求缺少验收条件）。
按不加权口径计算：通过项数为3+3+2=8，适用项数为11，通过率 = 8 ÷ 11 × 100% ≈ 72.7%。若采用加权口径，设完整性权重为3、一致性权重为2、可测试性权重为3，则加权得分 =（3×3 + 3×2 + 2×3）÷（4×3 + 4×2 + 3×3）=（9+6+6）÷（12+8+9）= 21 ÷ 29 ≈ 72.4%。两种口径结果接近，说明本例中问题分布较均匀；若高权重项集中不通过，加权得分会明显低于简单通过率，这正是加权口径的作用。
| 检查类别 | 适用项数 | 通过项数 | 不通过项 | 权重 |
|---|---|---|---|---|
| 完整性 | 4 | 3 | 异常流程缺失 | 3 |
| 一致性 | 4 | 3 | 术语不一致 | 2 |
| 可测试性 | 3 | 2 | 缺少验收条件 | 3 |
| 合计 | 11 | 8 | 3项 | — |
能否基线化不能只看得分。本例中三项不通过分别涉及异常流程、术语和验收条件，其中异常流程和验收条件属于影响开发与测试的高权重问题。若评审后这三项均已修改关闭，且版本已冻结、变更入口已明确，则可基线化；若其中一项因业务方未确认而保留，则应登记为已知风险、指定责任人和确认时限，再由项目负责人决定是否带风险基线。通过率72.7%本身不构成通过或不通过的结论，判定依据是问题闭环状态和门槛条件。
结果怎么解读：指标边界与常见误判
通过率和加权得分衡量的是文档对检查表的符合程度，不能证明需求本身正确或价值合理。一份检查项全部通过的文档，仍可能描述了错误的目标用户或遗漏了真实业务约束，这类问题依赖评审专家的领域判断，指标无法替代。
检查项的覆盖范围直接决定结论的适用范围。只检查格式和编号的检查表，通过率高只说明文档规范；把范围边界、业务规则、验收条件纳入检查后，得分才更接近内容质量。引用得分时应同时说明检查表版本，否则不同时期的分数没有可比性。
不同规模、不同复杂度的文档得分不宜直接横向比较。一个涉及多系统集成的需求，其异常流程和接口一致性检查项天然更多、更难通过；简单内部工具需求则相反。跨团队比较时应按需求类型分层，或者只比较同一文档不同版本之间的变化趋势。
指标与后续缺陷、变更的关系需要另行验证。文档通过率高是否带来更少的开发返工，要用缺陷数据、变更次数等结果指标做相关性分析，且需排除需求变更频繁等外部因素。把单次检查得分直接用于个人绩效评价，容易诱导检查人放宽判定，反而削弱指标的可信度。合理的做法是把得分作为评审输入的参考，把问题闭环率和基线后变更情况作为过程改进的依据。
常见问题
评审会上允许保留待确认问题，那这些问题什么时候必须处理完？
评审阶段允许存在待确认问题，这正是评审要收敛的内容。评审结论应把问题分为必须修改、可以后续优化、不予采纳三类，必须修改项须在基线化之前关闭。若某项因业务方未确认而无法关闭，应登记为已知风险，写明责任人、确认时限和影响范围，再由项目负责人或评审组决定是否带风险基线。没有责任人、没有处置结论的遗留问题不应进入基线。
检查项不适用时直接算通过可以吗？
不建议。不适用项应单独登记理由，例如纯后台批处理需求不涉及界面角色，相关角色检查项可标为不适用，并从分母中剔除。把不适用直接算作通过会虚高通过率，让得分失去区分度。若全部检查项都不适用，报告应写“不适用”，不输出0分，避免被误读为质量差。
通过率定多少才算达标？有没有通用标准？
本文不给出通用达标线。通过率是检查表符合程度的度量，达标线应由组织结合需求类型、风险偏好和历史数据自行设定，并在检查前写入检查表。引用得分时须同时说明检查表版本和统计时间窗，否则不同时期的分数无法比较。更稳妥的做法是把通过率作为评审输入的参考，把问题闭环率和基线后变更情况作为过程改进依据。
评审通过后文档又改了，基线怎么处理？
基线冻结后，文档修改应走已约定的变更入口：提交变更申请、说明影响范围、由指定审批人确认，并记录新版本号与变更内容。冻结版本保留可查，便于后续对照。若修改涉及已关闭的评审问题或影响验收条件，应重新执行相关检查项的复核，避免变更绕开质量门槛。
检查记录和问题单分散在不同工具里，怎么保证版本对应？
关键是让文档版本、检查表、问题单和评审记录之间可以相互定位。ONES Wiki 的页面组可关联项目，需求与文档互相对应，并记录页面版本、支持查看与回滚，可用于承载冻结版本与检查记录的对应关系；评审问题单的流转可在项目任务中跟踪，使问题关闭状态与文档版本保持关联。具体评审流程和基线标记的操作方式，以团队实际配置为准。
