需求评审清单
评审会前逐项核对背景、范围、验收与依赖,避免会上才发现信息缺失。
可整段复制 占位符用双大括号标出,替换成你的内容即可
# 需求评审清单|{{需求名称}}
## 一、会前检查
- [ ] 需求文档已提前 {{1 个工作日}} 发给参会人
- [ ] 明确评审目标:{{确认范围 / 确认方案 / 排期评估}}
- [ ] 参会人包含:{{产品、研发、设计、测试、运营、业务方}}
- [ ] 关键数据与原型已准备
## 二、背景与问题
- 用户问题:{{谁在什么场景遇到什么问题}}
- 业务目标:{{希望改善的指标}}
- 不做会怎样:{{影响与代价}}
- 已有证据:{{数据、访谈、工单}}
## 三、范围
- 本次做:{{功能点一}}、{{功能点二}}、{{功能点三}}
- 本次不做:{{明确排除项}}
- 受影响系统:{{系统与接口}}
- 兼容与迁移:{{老数据/老版本/老客户端}}
## 四、验收标准
| 场景 | 输入/操作 | 预期结果 | 验收方式 |
| --- | --- | --- | --- |
| {{正常流程}} | {{操作}} | {{结果}} | {{测试用例}} |
| {{异常流程}} | {{操作}} | {{结果}} | {{测试用例}} |
| {{边界条件}} | {{操作}} | {{结果}} | {{测试用例}} |
## 五、依赖与风险
- 依赖:{{团队/系统}} 需在 {{日期}} 前提供 {{能力}}
- 技术风险:{{风险}},验证方式 {{方式}}
- 合规风险:{{隐私/权限/审计}},确认人 {{姓名}}
- 排期风险:{{人力/时间}},预案 {{预案}}
## 六、会议决议
| 事项 | 结论 | 负责人 | 时间 |
| --- | --- | --- | --- |
| {{范围确认}} | {{通过/调整}} | {{姓名}} | {{日期}} |
| {{方案选择}} | {{方案 A/B}} | {{姓名}} | {{日期}} |
| {{排期}} | {{确认/待定}} | {{姓名}} | {{日期}} |
## 七、待办
- [ ] {{补充原型}},负责人 {{姓名}},{{日期}}
- [ ] {{确认接口}},负责人 {{姓名}},{{日期}}
- [ ] {{更新文档}},负责人 {{姓名}},{{日期}}
复制与下载都在浏览器本地完成,不会上传内容,也不需要登录。
怎么用
- 会前把清单发给参会人,让大家带着问题来,而不是会上才开始读文档。
- 范围与不做项必须写清,评审会最常见的争议是「这个算不算本次范围」。
- 验收标准用场景表,比「功能正常」更容易达成一致。
为什么这么写
- 评审清单把隐性信息要求显性化,减少会上反复确认背景。
- 不做项能防止范围蔓延,也方便后续排期。
- 验收场景提前写,测试与开发能在会上就发现理解差异。
- 决议与待办分开记录,避免会上说过了但没人跟进。
常见错误
- 文档会上才发,参会人现场阅读,评审变成宣讲。
- 只讨论方案,不确认范围与验收。
- 待办没有负责人和日期,会后无人推进。