3.1 需求类型与层次

需求不是愿望清单。它是人类目标和工程承诺之间的桥。桥一旦模糊，团队可能构建出技术上正确、业务上错误的软件。

一条需求应该帮助团队回答三个问题：

• 需要什么结果？
• 谁需要它，在什么条件下需要？
• 我们如何知道系统满足了它？

常见需求类型

非功能需求常常在后期伤害团队，因为大家写了“快”“安全”“可扩展”，却没有决定这些词到底是什么意思。

需求层次

层次能防止大家在错误高度争论。

• 业务需要：组织想得到的结果。
• 用户需求：用户用自然语言表达的目标。
• 系统需求：系统必须实现的行为。
• 设计约束：对解决方案的限制。
• 验收证据：测试、指标、演示、审计或评审结果。

一个高级习惯

当有人说“这个需求很明显”时，请他给出三个例子：

• 一个正常成功场景。
• 一个边界场景。
• 一个必须拒绝的场景。

例子常常比抽象陈述更能暴露问题。它们会暴露缺失角色、隐藏权限、时间限制、异常路径，以及利益相关者之间的分歧。