优秀需求 7 特性

目录

• 第一部分：优秀需求的 7 大特性检查清单（Checklist）
• 1. 正确性（Correctness）检查清单
• 2. 完整性（Completeness）检查清单
• 3. 一致性（Consistency）检查清单
• 4. 可验证性（Verifiability）检查清单
• 5. 可追踪性（Traceability）检查清单
• 6. 可理解性（Unambiguous）检查清单
• 7. 可行性（Feasibility）检查清单

来源： IEEE 830 / IEEE 29148（国际需求规范标准）

第一部分：优秀需求的 7 大特性检查清单（Checklist）

以下每一项都可作为需求评审时必须逐条打勾的规范。

---

1. 正确性（Correctness）检查清单

需求描述必须准确反映业务的真实要求，没有误解。

需求是否与业务逻辑真实一致？

• 是否已经和需求方确认流程无误？
• 是否与现有系统行为一致？如不一致是否明确说明？
• 是否避免使用主观、未经验证的业务假设？
• 是否已考虑异常流程？
• 是否避免“理想化流程”而遗漏边界条件？

不通过示例：
“订单提交自动算支付成功。”

通过示例：
“支付网关返回 SUCCESS 状态后记为支付成功。”

---

2. 完整性（Completeness）检查清单

需求必须描述清楚所有输入、输出、流程、条件，不能留空或依赖猜测。
需求是否包含全部必要信息？不得让开发自行脑补。

• 是否写明清楚的输入？
• 是否写明输出内容？
• 是否写清业务流程全链路？
• 是否覆盖异常场景？
• 是否包含数据结构与字段定义？
• 是否定义业务规则边界？
• 是否明确非功能性需求（性能、容量、安全等）？

不通过：
“注册成功后给用户发送邮件。”

通过：
“发送激活邮件，包含用户名、激活链接、有效期 24 小时。”

---

3. 一致性（Consistency）检查清单

需求内部以及与其他文档是否一致？

• 术语是否统一（SKU/商品编码不能混用）？
• 不同章节是否逻辑一致？
• 是否避免前后矛盾的数字（如 timeout=10min vs timeout=15min）？
• 是否避免重复需求？
• 是否避免多个需求互相冲突？

不通过：
“库存扣减用 SKU”，但在别处写“产品编号”。

通过：
全局统一使用 SKU。

---

4. 可验证性（Verifiability）检查清单

需求是否能够通过测试验证？

• 是否去除模糊词（快速、大概、尽量、适当…）？
• 是否包含可测量的量化指标？
• 是否包含验收标准（Acceptance Criteria）？
• 是否能编写出单测/接口测/性能测试？

不通过：
“系统必须非常快。”

通过：
“接口响应≤200 ms（95 分位）。”

---

5. 可追踪性（Traceability）检查清单

需求必须能追溯来源，并与设计、开发、测试关联。

• 是否包含需求编号？
• 是否标注来源（业务 PRD、用户访谈等）？
• 是否链接到功能设计文档？
• 是否链接到测试用例？
• 是否能追踪到代码实现位置？

不通过：
“系统应该更安全。”

通过：
“R-102：支持密码强度校验（来源：安全规范 v1.2）。”

---

6. 可理解性（Unambiguous）检查清单

需求是否清晰、无歧义、易理解？

• 是否避免模糊词（如可能、适当、大部分用户…）？
• 是否避免双重否定？
• 是否避免复杂句式？
• 是否定义专业术语？
• 是否避免多个解读空间？
• 是否配有流程图或时序图？

不通过：
“用户长时间不操作会自动退出。”

通过：
“用户空闲 30 分钟后自动退出。”

---

7. 可行性（Feasibility）检查清单

最好在获取（ e l i c i t a t i o n）需求(收集需求)过程中始终有一位软件工程小组的组员与
需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。
需求是否能在当前技术、成本和时间内实现？

• 是否评估技术可行性？
• 是否评估成本和资源可用性？
• 是否评估风险？
• 是否与现有架构未冲突？
• 是否在合理上线时间内可实现？

不通过：
“系统必须支持每分钟 1000 万订单写入（使用单机 MySQL）。”

通过：
“系统支持每分钟 5000 订单写入（使用分片 MySQL 集群）。”