---
title: "需求评审怎么做？范围、业务规则与验收标准"
source: https://www.iowill.com/blog/2026/11/requirements-review/
date: 2026-11-11
updated: 2026-11-11
tags: [软件工程, 软件测试, 需求评审]
categories: [编程开发]
---

# 需求评审怎么做？范围、业务规则与验收标准

**需求评审是对需求内容的检查与确认：要解决什么问题，哪些事情属于本次范围，什么结果才算满足要求。** 它可以通过文档批注、异步讨论或会议完成。评审的价值体现在澄清了哪些问题、形成了哪些决定，以及这些决定是否已写回需求。

如果需求只有“增加批量导出，支持取消”，开发者仍然不知道该导出筛选结果还是已勾选记录，也无法判断取消以后应保留什么文件。此时直接进入开发，会把尚未确认的产品决定留给实现者。

本文面向个人开发者和小团队，用一个虚构的桌面应用功能说明评审方法。文中的需求、数字、评审记录和图示都是作者编写的教学材料，不来自真实业务评审，也未运行对应应用。公开资料支持通用原则，具体检查项和流程是本文的实践建议。

## 需求评审、技术评审和测试用例审核的分工

三类活动的检查对象不同，也会相互反馈。

| 活动 | 主要检查对象 | 需要形成的结论 |
| --- | --- | --- |
| 需求评审 | 目标、范围、业务规则和验收条件 | 要求是否清楚，有没有冲突和待定事项 |
| 技术方案评审 | 设计、接口、状态、依赖与实现风险 | 方案如何满足要求，哪些假设需要验证 |
| 测试用例审核 | 测试输入、步骤、覆盖与预期结果 | 用例是否有效、可执行，是否遗漏重要条件 |

需求中可以包含必要的技术约束，例如必须兼容现有文件格式；但“使用某个线程池”通常属于设计决定。若团队因运行环境或安全要求必须采用指定方案，应记录约束来源，避免把个人偏好写成需求。

[NASA 的系统设计说明，第4.2节](https://www.nasa.gov/reference/4-0-system-design-processes/)强调与相关方反复确认需求含义。这里借鉴的是沟通和需求澄清原则，不要求个人项目照搬航天工程的审批层级。

## 评审前需要准备哪些材料

评审至少需要一个可定位的需求版本，并提供理解它所必需的背景。材料可以很短，但应让参与者知道自己在审哪一版。

-   **目标与使用场景**：谁在什么情况下使用，现有方式有什么具体问题。
-   **范围与规则**：输入、输出、限制、异常行为，以及明确不做的内容。
-   **原型或示例**：涉及操作顺序、状态变化时，给出可理解的界面或文字流程。
-   **待定事项与已有约束**：哪些内容尚未决定，哪些来自兼容、安全或运行环境要求。

业务决策者负责确认规则和优先级，开发者检查可行性与系统约束，测试视角帮助发现边界和不可验证的表述。一个人可以承担多种角色；有权限确认业务规则的人没有参与时，评审只能记录问题，不能替他作决定。

## 把“批量导出”拆成可确认的要求

原始描述为：

> 在桌面应用中增加批量导出CSV，支持筛选和取消，不能影响正常使用。

下面是**假定经过讨论后形成的教学需求v1**，不是从原句自动推导出的唯一答案。5000条是为演示边界设定的产品限制，不代表经过容量测试。

| 编号 | 本例确认的要求 | 评审需要解决的问题 |
| --- | --- | --- |
| R1 | 提交成功时取得当前筛选结果的数据快照，按ID升序导出；后续页面筛选和源记录修改不改变本次内容 | “当前”对应哪个时间点；导出全部匹配项还是勾选项 |
| R2 | 数量为1–5000条才创建任务；0条提示无可导出数据，超过5000条拒绝，不静默截断 | 空结果、上限和超限分别如何处理 |
| R3 | 输出CSV，字段固定为id、name、status，使用UTF-8 BOM；保留含逗号、双引号、换行的文本内容 | 文件格式、字段与文本内容如何解释 |
| R4 | 写入过程中使用临时文件；只有成功完成才产生正式文件，不覆盖已有文件 | 半成品会不会被误认为成功，目标冲突怎么办 |
| R5 | 正式提交文件前允许申请取消；取消与完成竞争时只能有一种终态，取消成功不产生正式文件 | 何时还能取消，如何避免同时提示成功和取消 |
| R6 | 同一窗口最多一个活动导出任务；处理中保持界面可操作，拒绝重复启动 | 连续点击如何处理，是否允许并行任务 |
| R7 | 写入失败要报告失败并尝试清理本任务临时文件；清理失败须说明残留位置 | 错误信息、残留文件和其他已有文件如何处理 |

“快照”在本例中包括输出字段的值，不只是复制一份筛选条件。若产品允许任务执行期间读取最新值，需要采用另一套明确的约定，并同步修改方案和用例。

![批量导出需求从模糊描述变为范围规则和验收条件的原创示意](https://img.iowill.com/file/%E7%BC%96%E7%A8%8B%E5%BC%80%E5%8F%91/requirements-review/body1.png)

*原创教学示意：评审补齐的是可确认的行为，并非直接替需求选择技术实现。*

## 范围、业务规则与异常场景如何检查

### 范围同时写清包含项和排除项

本例只处理桌面应用当前窗口中的导出，不增加服务器任务队列、Excel格式或多窗口任务协调。这些排除项用于限制讨论范围，不表示相应能力永远不能做。

“导出所有数据”这样的表述需要进一步明确权限范围、筛选条件及字段。不能让开发者从现有界面猜测，也不能在测试时临时改变解释。

### 业务规则检查相互冲突的地方

“导出完成后自动覆盖旧文件”和“不丢失已有文件”无法同时直接成立；必须确认覆盖是否需要同意、何时确认以及失败时保留什么。

本例选择不覆盖已有文件，因此技术方案不能悄悄使用会替换目标文件的接口。若业务后来改为允许覆盖，就应作为需求变更处理，而不只是修改一个函数。

### 异常场景描述可观察行为

“失败时友好提示”没有说明失败后发生什么。更有用的描述是：不能写入目标目录时，任务报告失败、不产生正式文件，已有文件保持不变；本任务临时文件清理失败时，提示其位置。

对于关闭窗口、应用退出、磁盘空间不足等情况，需要按功能风险继续补充。本文的v1表不是适用于所有导出工具的完整规格，也没有承诺进程崩溃或断电后的恢复能力。

## 验收标准需要明确输入和可观察结果

验收标准描述接受实现所需的条件，不必把所有测试操作都塞进需求。下面是一组作者编写的示例：

```text
AC-R2：数量限制
当匹配结果为0条时，不创建导出任务，并提示无可导出数据。
当匹配结果为5000条时，允许创建任务，不因达到上限而拒绝。
当匹配结果为5001条时，拒绝创建任务，不自动截取前5000条。

AC-R1：提交快照
任务提交成功后改变页面筛选或修改源记录，
本次导出的记录集合、字段值和排序仍与提交时快照一致。

AC-R5：取消结果
正式文件提交前受理取消，并最终进入取消状态时，
不产生本任务正式文件；不能同时报告成功。
若文件已提交成功，后到达的取消请求不能把成功改为取消。
```

[ISTQB CTFL v4.0.1第4.5.2节](https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf)讨论了验收条件的用途及表达方式。本文采用规则和示例组合表达，不要求全部写成同一种句式。

界面可操作性仍需在目标平台和代表性数据下验证。“不影响正常使用”应在评审中补充需要保持的交互及性能目标；尚未确定响应时间指标时，记录为待确认，不能把任意数字当成已验证能力。

## 评审问题要落实到修改和复核

评审记录不宜只有“已讨论”。一条可以执行的问题，至少应包含位置、问题依据、影响及处理状态。

| 问题 | 处理决定 | 复核依据 |
| --- | --- | --- |
| Q1：原文没有明确导出范围 | 采用提交时筛选结果快照，不采用勾选项 | R1及AC-R1已写明，原型文字保持一致 |
| Q2：超过上限如何处理未知 | 超过5000条拒绝，禁止截断 | R2及AC-R2覆盖5000/5001 |
| Q3：取消与完成可能同时提示 | 要求单一终态，细节交技术评审 | R5已补充，方案需要解释竞争处理 |
| Q4：界面响应目标尚未确定 | 补充目标环境与交互要求后再确认 | 保持未关闭，不用“体验良好”代替结论 |

以上是示范记录，不代表本次真的召开过评审。实际使用时还应记录负责人、约定完成时间、修改版本和复核人。

![需求评审问题从发现到修改复核及交接的原创流程示意](https://img.iowill.com/file/%E7%BC%96%E7%A8%8B%E5%BC%80%E5%8F%91/requirements-review/body2.png)

*原创流程建议：未确认的问题保留状态，复核检查实际修改，不以口头答复代替。*

我建议用“通过、修改后复核、暂不通过”等结论表达处理状态，但它们不是所有团队通用的强制名称。涉及导出范围、数据保护或关键异常行为的问题未解决时，不应把评审写成无条件通过。

[NASA技术评估说明](https://www.nasa.gov/reference/6-7-technical-assessment/)将评审目标、进入与成功条件、参与者及后续行动项列为需明确的内容。个人项目可以把它压缩成需求版本、一张问题表和一次修改复核。

## 评审后的需求如何交给开发和测试

交接时保留已确认版本、需求编号、验收条件、未关闭问题和变更记录。技术设计引用R1–R7，测试用例也引用对应编号，避免两边各自形成一套不同解释。

[NASA需求管理说明](https://www.nasa.gov/reference/6-2-requirements-management/)讨论了需求、设计和测试材料之间的一致性及变更管理。对本例，一份轻量表格就可以记录“哪项要求对应哪段设计、哪些用例”，无需先引入大型管理系统。

需求发生变化后，重新检查受影响的设计和用例；已经确认过一次，不表示此后可以无记录地改动。后续技术评审负责解释这些要求如何实现，用例审核负责检查验证设计是否忠实反映它们。

## 参考资料

-   [NASA Systems Engineering Handbook：系统设计与技术需求定义，第4.2节](https://www.nasa.gov/reference/4-0-system-design-processes/)
-   [ISTQB CTFL Syllabus v4.0.1：验收条件，第4.5.2节](https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf)
-   [NASA：Requirements Management](https://www.nasa.gov/reference/6-2-requirements-management/)
-   [NASA：Technical Assessment](https://www.nasa.gov/reference/6-7-technical-assessment/)

资料核对日期：2026年11月9日。检查表、教学需求和结论命名为作者建议，不是上述机构对所有软件项目的统一规定。