第1章：评审Checklist的价值定位——适用范围、核心原则、与需求原型的关系
1.1 适用场景
| 场景 | 说明 | 典型触发条件 |
|---|---|---|
| 需求评审会议 | 正式或非正式的需求原型讲解与讨论，确保各方理解一致 | 原型初版提交、里程碑节点 |
| 原型边界确认 | 专门检查需求原型的功能边界、输入输出、异常分支是否明确 | 原型交付前、Sprint开始前 |
| 变更影响分析 | 需求变更时，使用Checklist快速评估原型变更对已确认边界的影响范围 | 需求变更请求触发 |
| 跨团队对齐 | 多个团队（前端、后端、测试）对同一原型边界理解对齐 | 跨团队协作启动 |
⚠️ 适用范围不包括：产品战略讨论、技术实现细节评审、非功能性需求验证。
1.2 前置条件
- 已完成需求原型（线框图、可交互原型、或业务规则描述），且经过内部一致性检查。
- 评审团队已确认并锁定至少 3 名具有决策权的角色（产品负责人、开发代表、测试代表）。
- 已建立统一的边界描述符号体系（如：必填字段、数值范围、状态流转图例）。
- 准备好Checklist模板（至少包含边界项、验收标准、归属角色三列）。
📌 关键检查点：若原型尚未定义任何「边界值」或「异常路径」，需先补充最小集，否则评审Checklist无法有效执行。
1.3 操作步骤
- 确定评审目标：明确本次评审聚焦的功能边界等级（核心/扩展/废弃）。
- 提取关键边界要素：从原型中摘出所有与边界相关的节点（如：最大输入长度、金额阈值、状态机转换条件）。
- 逐项匹配Checklist：将提取的要素填入Checklist模板，生成初步Checklist。
- 团队评审与确认：逐项过Checklist，每个边界项必须得到至少 2 个角色认可。
- 记录争议项：对于无法当场确认的边界，标记为争议并录入记录材料。
- 输出结论：生成已确认的边界清单和待处理争议边界列表。
❌ 避免跳过步骤2直接评审原型整体，会导致Checklist缺乏焦点，效率降低。
1.4 输入输出物
| 方向 | 物料名称 | 格式要求 |
|---|---|---|
| 输入 | 需求原型（含业务规则说明） | PDF / Axure/ Figma 导出件 / Markdown 文档 |
| 输入 | 历史评审Checklist（如有） | Excel 或 CSV |
| 输出 | 已确认的边界Checklist | CSV / Excel，包含边界ID、要素描述、确认角色、状态 |
| 输出 | 边界争议记录表 | MD / Excel，含争议项、各方观点、计划解决时间 |
1.5 责任边界
- 产品经理/需求分析师：提供完整原型，解释边界定义的业务逻辑，对每个边界项的业务正确性负责。
- 开发代表：评估边界的技术可行性、实现成本，对边界项的实现风险负责。
- 测试代表：验收边界可测试性，确保所有边界项有明确判定标准。
- 评审主持人（通常为Team Lead或Scrum Master）：把控会议节奏，确保按Checklist逐项完成，记录争议。
- 项目决策者（如产品总监）：对争议边界进行最终裁决（若需升级）。
🤝 所有角色共同承担「边界遗漏」的最终结果，避免仅由某一角色兜底。
1.6 记录材料
- Checklist执行过程录像或会议纪要自动转写文本（若远程会议）。
- 每项边界确认的截屏/原型高亮标记。
- 争议边界项的详细讨论记录（包括否决理由）。
- Checklist版本号及对应的需求原型版本号。
1.7 异常处理
| 异常类型 | 标识 | 处理措施 |
|---|---|---|
| 原型信息不足 | 边界项无法判断 | 标注为“需补充”，暂停该项评审，设定补充完成时间 |
| 边界争议升级 | 团队无法在 10 分钟内达成共识 | 记录反对意见，升级至决策者，给出最终答复截止日 |
| Checklist模板不匹配 | 原型边界类型超出模板定义 | 临时创建新边界分类，并记录模板修订建议 |
| 时间超限 | 评审超过预定时间仍未完成 | 提前协商选择压缩或拆分评审场次，不得匆忙收尾 |
1.8 验收标准
- 边界Checklist覆盖所有原型中出现的交互节点与数据约束。
- 每个边界项至少获得 2 个角色的确认签字（或确认评论）。
- 争议边界项数量少于总边界项数的 10%，且已制定下一步处理时间表。
- Checklist记录中无「空白待定」的必填字段。
- 已生成边界确认报告并归档至项目知识库。
📊 上图展示了评审Checklist作为工具，串联「适用范围」「核心原则」与「需求原型」三大价值支柱。所有节点均取自本章1.1至1.3节内容。