需求评审基础模板：八个角度、行为约定与问题闭环

01 · 先明确评审要交付什么

需求评审围绕四个问题展开：需求是否合理、描述是否完整、系统风险是否可控、结果是否可验收。本模板面向软件与系统需求，尤其适合测试开发、系统测试和跨模块功能评审。

评审结果应能进入需求修订、设计和测试。每项可记录为“通过／待澄清／不适用”，并附依据；不适用时写明原因。对于未知项，保留“待确认”。

直接跳到可复制的 Markdown 模板 ↓

02 · 评审前：把目标和范围写清楚

先固定本轮评审依据的版本。后续发生范围或规则变化时，记录变化及其影响，重新评审受影响的部分。

03 · 八个角度：逐项找遗漏

04 · 将一句需求展开成行为约定

在什么条件下，由谁触发什么操作，系统经过哪些状态，最终保证什么；如果失败，留下什么状态，如何恢复。

操作被接受、任务执行中、任务完成，应分别定义。例如异步接口接受请求，不代表后台处理已经完成；验收需要观察约定的最终状态。

05 · 存储示例：怎样追问“不影响业务”

以下为假设需求，仅演示评审方法：

支持在线更换硬盘，不影响业务。

具体性能阈值、恢复时间和故障容忍范围，需要依据产品能力与业务目标确定；本例未替产品设定数值。未定义的指标是待澄清项。

06 · 问题记录：让每条意见都有关闭依据

建议至少记录：编号、需求位置与版本、具体缺口、依据、影响场景、待决定事项、负责人、截止日期、状态和关闭证据。

状态可采用：待确认 → 已决议 → 已修订 → 已复核关闭。仅有会议中的口头解释，仍不足以证明需求正文和验收依据已经同步。

风险与优先级应说明理由。例如，可能造成数据不一致、权限绕过或无法验收的问题，应优先明确其影响范围与处理方案。

07 · 评审结论：写清条件和剩余事项

通过表示本轮需求评审满足约定条件，不等于实现无缺陷，也不表示测试已经通过。“附条件通过”不能用于掩盖影响数据正确性、安全或核心验收的未决问题。

需求评审与设计评审的边界

需求评审明确必须保证什么、在什么条件下保证、怎样验收；设计评审检查具体实现如何兑现这些保证。技术约束可以用来挑战需求的可行性，并推动范围或指标调整。

08 · 可复制的 Markdown 基础模板

点击下方复制按钮，把模板放进你的需求文档或评审记录中填写。八个角度用于检查覆盖面，关键场景可复制多份“行为约定”，每条问题应保留关闭证据。

模板中的“待填写／待确认”是明确的填写项。建议按需求风险裁剪，并保留不适用项的理由。

# 需求评审记录

模板版本：v1.0
说明：本模板中的空白项用于填写；未确认内容保留为“待确认”，不预先勾选通过。

## 1. 基本信息
- 需求名称：
- 需求链接与文档版本：
- 产品／模块与适用版本：
- 评审日期与参与人：
- 需求负责人：
- 目标用户与业务问题：
- 成功标准：
- 本期范围：
- 明确排除的场景：
- 受影响的既有功能与依赖：

## 2. 八个评审角度
每项填写“通过／待澄清／不适用”，附需求条款或证据；不适用时说明原因。
- 业务目标与范围：
- 清晰性与一致性：
- 流程与状态完整性：
- 边界与异常处理：
- 系统交互与兼容性：
- 数据正确性与安全：
- 非功能与运行维护：
- 可实现性与可验收性：

## 3. 行为约定（每个关键场景复制一份）
- 场景名称与关联需求条款：
- 前置条件／支持范围：
- 触发者与所需权限：
- 输入／触发操作：
- 中间状态与可见进度：
- 成功终态与必须成立的数据约束：
- 失败反馈与失败后的状态：
- 超时／取消／重试／恢复规则：
- 并发与互斥规则：
- 验收负载、指标、阈值、观测窗口与统计口径：
- 验证环境、数据与预期结果：
- 需要采集的状态、日志和其他证据：

## 4. 评审问题记录
| 编号 | 需求位置／版本 | 具体缺口与依据 | 影响场景／风险 | 待决定事项 | 负责人 | 截止日期 | 状态与关闭证据 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| REQ-01 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待确认 |

状态建议：待确认 → 已决议 → 已修订 → 已复核关闭。
“已讨论”或“已口头解释”不单独作为关闭依据。

## 5. 评审结论
结论（选择一项）：通过／附条件通过／不通过
- 结论依据与对应需求版本：
- 阻塞问题：
- 未关闭问题及其影响范围：
- 附条件通过的适用范围与限制：
- 后续动作、负责人和截止日期：
- 复核人及复核结果：

评审通过表示本轮需求定义满足约定条件，不等于实现无缺陷或测试已经通过。