第2章 验收标准制定的基本原则
适用场景
- 从零开始制定验收标准时，需要建立原则框架作为编写依据
- 评审已有验收标准，判断其是否合格、是否需要修订
- 跨职能团队（需求、开发、测试、运维）对齐验收标准认知，减少后续争议
- 需求变更或范围调整后，同步更新验收标准并验
证其依然满足五大原则
前置条件
- 已完成需求分析，形成《需求规格说明书》或用户故事清单
- 已明确验收目标和范围（功能、性能、安全、合规等维度）
- 已识别关键利益相关方（业务方、开发负责人、测试负责人、架构师）
- 团队已就“验收标准是质量门禁”达成共识，不跳过原则检查
操作步骤
制定验收标准时，必须依次通过以下五项原则的检查。每一条标准都应当同时满足全部原则，缺一不可。
| 原则 | 核心要求 | 典型反例 | 正确写法要点 |
|---|---|---|---|
| 可验证性 | 通过客观手段（测试、度量、检查）可重复判定是否满足 | “系统响应速度要快” → 无法量化，各人标准不同 | 使用量化阈值： “95%的请求响应时间 ≤ 200ms” |
| 无歧义性 | 所有利益相关方对标准只有一种理解 | “界面设计美观大方” → 美观是主观感受，无统一标准 | 使用精确描述： “主色为#2C3E50，按钮圆角4px，字号16px” |
| 完整性 | 覆盖正常流程、异常流程、边界条件、性能指标 | 仅描述登录成功流程，未提及密码错误、账号锁定、网络超时等场景 | 列出所有分支：成功、失败（含错误码）、超时、并发上限 |
| 一致性 | 验收标准内部及与需求、设计文档无矛盾 | 需求文档写“支持1000并发”，验收标准写“支持500并发” | 逐条对照需求与设计文档，确保数字、范围、行为完全一致 |
| 可追溯性 | 每项标准都能追溯到原始需求、设计依据或用户故事 | 验收条目未关联任何需求编号，无法确认验收目的 | 每条标注来源： “对应需求REQ-2025-003，设计章节3.2” |
实践建议： 在编写验收标准草稿后，逐条对照上表五项原则进行自检。任何一条原则不满足，都应修订标准直至全部通过。
步骤详解与正确示例
步骤1 · 检查可验证性
为每项验收标准确定可观测、可量化的验证手段。避免使用“良好”“快速”“稳定”等不可测量的词汇。
反例（不可验证）：
“系统在高并发下表现稳定。”
正例（可验证）：
“在500并发用户下，持续运行30分钟，CPU使用率 ≤ 75%，内存泄漏率 ≤ 0.1%/小时，无500错误。” 步骤2 · 消除歧义性
使用精确数字、枚举值、状态定义替代模糊形容词。必要时应补充示例或图解。
反例（歧义）：
“文件上传功能要支持常见格式。”
正例（无歧义）：
“文件上传支持 .pdf、.docx、.xlsx、.png 四种格式，单文件 ≤ 20MB，命名规则为 时间戳_原始文件名。” 步骤3 · 补全完整性
在正常路径之外，补充边界值、异常分支、性能拐点、安全约束。
反例（不完整）：
“用户可成功提交订单。”
正例（完整）：
“1. 提交订单时库存充足 → 订单状态变更为‘待支付’；
2. 提交订单时库存不足 → 返回‘库存不足’提示，订单不生成；
3. 提交订单时网络中断 → 本地保存草稿，恢复后自动重试最多3次。” 步骤4 · 校准一致性
逐条对照《需求规格说明书》《设计文档》《接口规范》，确保数字、术语、逻辑无冲突。
反例（不一致）：
需求文档：密码长度 8~16 位，含大小写字母和数字。
验收标准：密码长度 6~12 位，含字母和数字。
正例（一致）：
验收标准与需求文档完全对齐：密码长度 8~16 位，必须包含大写字母、小写字母、数字，可选特殊字符。 步骤5 · 建立可追溯性
为每条验收标准标注需求编号、设计章节、变更记录。变更时必须同步更新追溯关系。
反例（不可追溯）：
验收条目：“系统支持导出Excel报表。”
正例（可追溯）：
“[REQ-FIN-042] 系统支持导出Excel报表，对应设计文档 §4.3.2，格式模板见附件《财务导出模板_v2.xlsx》。”
☞ 核心要点： 五项原则不是可选清单，而是验收标准的最低质量门槛。缺失任意一项，都意味着标准可能存在缺陷，交付后极易引发争议或返工。
输入输出物
| 类型 | 内容 |
|---|---|
| 输入 | 《需求规格说明书》、用户故事清单、《系统设计文档》、 接口规范、行业标准/法规要求、历史验收标准（如有） |
| 输出 | 《验收标准清单》（每条标注原则检查结果）、 《原则合规评审报告》（含通过/不通过项及修订建议） |
责任边界
- 需求方（产品/业务）： 提供清晰、无歧义的需求描述，确保需求具备可追溯标识；参与原则评审，确认标准符合业务预期。
- 开发方： 确保验收标准可验证、无歧义；对标准的完整性和一致性提出技术视角的修订建议。
- 测试方： 主导原则合规检查，重点验证可验证性（是否有客观判定手段）和完整性（是否覆盖所有测试场景）。
- 评审委员会（三方代表）： 对存在争议的标准条目进行仲裁，确认最终版本满足五项原则后签字生效。
记录材料
- 《验收标准五项原则合规检查表》 — 每条标准对应一个检查行，逐项勾选是否满足各原则，不满足项记录修订措施。
- 《原则评审会议纪要》 — 记录评审时间、参与人、争议条目、最终决议及遗留问题。
- 《验收标准基线版本》 — 通过原则评审后的正式版本，纳入配置管理，后续变更需重新走原则检查流程。
模板片段示例：合规检查表
| 编号 | 验收标准描述 | 可验证性 | 无歧义性 | 完整性 | 一致性 | 可追溯性 | 修订措施 |
|------|-----------------------------------|----------|----------|--------|--------|----------|------------------|
| AC01 | 登录响应时间 ≤ 2s (95%) | ✅ 通过 | ✅ 通过 | ✅ 通过| ✅ 通过| ✅ 通过 | - |
| AC02 | 界面风格优雅 | ❌ 不通过| ❌ 不通过| ✅ 通过| ✅ 通过| ✅ 通过 | 改为量化配色规范 |
| AC03 | 支持导出Excel报表（REQ-FIN-042） | ✅ 通过 | ✅ 通过 | ❌ 不通过| ✅ 通过| ✅ 通过 | 补充异常场景 |异常处理
| 异常类型 | 典型表现 | 处理措施 |
|---|---|---|
| 标准不可验证 | 使用“良好”“快速”“稳定”等定性描述，无量化指标或测试手段 | 与测试方共同确定可观测指标（响应时间、错误率、资源阈值等），替换定性描述 |
| 标准存在歧义 | 不同角色对同一标准理解不同，评审时产生争议 | 组织三方会议统一理解，使用精确术语、枚举值、示例或图解消除歧义 |
| 标准不完整 | 仅覆盖正常流程，缺少异常分支、边界值、性能场景 | 使用场景树或决策表系统性梳理所有分支，逐条补充至标准清单 |
| 标准不一致 | 与需求文档、设计文档或标准内部条目之间存在矛盾 | 追溯原始需求与设计文档，以需求为准校准标准；内部矛盾通过评审仲裁 |
| 标准不可追溯 | 验收条目未关联任何需求编号、设计章节或变更记录 | 由需求方和设计方协助补充来源标识，必要时补充追溯矩阵 |
| 多项原则同时不满足 | 一条标准同时存在可验证性、歧义性、完整性等问题 | 将该条标准标记为“重新起草”，按照操作步骤逐一修正后再次评审 |
⚠️ 重要提醒： 异常处理不是事后补救，而应在标准起草过程中同步进行。建议在编写每条标准后立即执行五项原则自检，避免积压大量不合格标准到评审阶段。
验收标准（本章适用）
对“验收标准制定是否合格”进行判定的检查依据，即元验收标准：
- 每项验收标准均明确标注了可验证的量化指标或客观判定方法（通过/不通过标准清晰）。
- 标准文本中不包含任何主观模糊词汇（如“良好”“合理”“充分”），所有术语在团队中有统一定义。
- 功能、性能、边界、异常、安全等维度无遗漏，覆盖所有已识别场景。
- 标准内容与《需求规格说明书》《设计文档》逐条对照无矛盾，标准内部条目之间无冲突。
- 每条标准均关联了唯一的需求编号或设计依据，变更记录可查。
- 以上五项检查全部通过，且已记录在《五项原则合规检查表》中，方可进入下一阶段。
质检口诀： “能量化、无模糊、全覆盖、无矛盾、有来源” — 五句话对应五项原则，每条标准过一遍口诀，不过关不放过。