第4章 评审标准要素模板：检查项、通过条件、严重程度、责任人

适用场景

本模板适用于所有需标准化评审过程的场景，包括但不限于：

• 需求规格说明书评审
• 系统/软件架构设计评审
• 详细设计及数据库设计评审
• 代码审查（Code Review）
• 测试用例及测试计划评审

当评审团队需要在多个版本间保持一致的质量判定尺度时，必须使用本要素模板定义评审标准。

前置条件

1. 已明确本次评审的类型（如需求、设计、代码）。
2. 评审目标已书面化（例如“确认需求完整且无歧义”）。
3. 已有评审对象的基线版本（如文档草稿、代码分支）。
4. 评审组长已确定，并具备标准定义决策权。

操作步骤

1. 分解评审对象为可检查项
   将评审对象按模块、功能点或质量属性拆分为基本单元，确保每个检查项对应一个可独立验证的问题点。
2. 设定每个检查项的通过条件
   用可量化或可客观判断的语句描述“什么情况下该检查项视为通过”。避免模糊词如“合理”“适当”。
3. 分配严重程度等级
   建议采用四或五级制：Blocker、Critical、Major、Minor、Trivial。团队需统一等级定义词典。
4. 明确责任人
   每个检查项必须指定唯一责任人，通常是该部分的内容作者或领域专家。责任人负责在评审前预达标，在评审中解释，在评审后整改。

检查项 ID	检查项描述	通过条件	严重程度	责任人
REQ-001	每个功能需求是否有唯一标识	需求表格中每行均包含ReqID字段，且无重复	Major	需求分析师 A
REQ-002	非功能需求是否量化	响应时间、吞吐量等指标以<xx ms或>xx TPS形式描述	Critical	架构师 B
DES-003	接口定义是否包含输入输出格式	每个接口的请求/响应示例完整，数据类型明确	Blocker	开发组长 C

输入与输出物

方向	名称	说明
输入	评审对象（文档/代码/模型）	待评审的基线版本工件
输入	评审目标说明书	明确本次评审需要验证的核心质量维度
输出	评审标准要素模板表	包含检查项、通过条件、严重程度、责任人的标准化清单
输出	严重程度等级定义词典	团队内部对各级别的统一解释和示例

责任边界

• 检查项定义者： 评审组长或领域专家，负责分解和描述检查项。
• 通过条件设定者： 评审组长与质量保证（QA）共同确认，确保可执行、可验证。
• 严重程度定义者： 整个评审团队协商一致后固化，避免个人主观偏差。
• 责任人： 每个检查项对应的内容作者或维护者。
  注意： 责任人不得与评审员角色重叠，以保证独立性。

记录材料

• 评审标准要素模板表（电子表格或 Wiki 页面）
• 严重程度等级定义文档
• 评审计划（包含检查项责任人分配记录）

异常处理

• 检查项过多： 优先保留与评审目标直接相关的项，其余降级为“参考检查项”，不强制通过。
• 通过条件矛盾： 由评审组长和 QA 仲裁，必要时升级至项目决策委员会。
• 严重程度争议： 严重程度词典需预先审批；若仍存在争议，评审组长拥有最终裁定权。
• 责任人缺失： 若某项内容无单一责任人（如公共模块），需指定一名协调人负责。

验收标准

1. 模板表覆盖所有关键检查点，且每项均包含完整的四要素。
2. 每个通过条件可在评审会议中现场验证（如阅读、运行测试、检查清单）。
3. 严重程度等级严格对应预先定义的词典，无自定义或模糊等级。
4. 所有检查项责任人均已确认，且未出现同一个人同时是责任人又是评审员的情况。