3.4 写出并验证好需求

规格说明的价值不在于长。它的价值在于让下一步工程决策更安全。

好的需求足够清晰，能被评审、实现、测试和挑战。它不需要文学美感，它需要可操作的精确度。

好需求是什么样

好需求通常具备：

• 必要：连接到真实利益相关者目标。
• 无歧义：读者不会发明不同含义。
• 可测试：存在验证行为的方法。
• 可行：符合技术、法律和组织约束。
• 有边界：包含范围、条件和异常。
• 可追踪：连接到来源、设计、实现和测试。

弱需求：“系统应该安全。”

更好需求：“10 分钟内连续 5 次密码失败后，账号进入 15 分钟锁定状态，并记录包含用户 id、IP hash 和时间戳的安全事件。”

Validation 与 Verification

Validation 问的是：我们规格化的是正确的东西吗？

Verification 问的是：我们是否正确构建了规格化的东西？

两者都重要。完美实现一个错误需求，仍然是浪费。

实用验证方法

不要只用一种：

• 让工程、产品、设计、客服、安全或合规一起做需求评审。
• 对高风险流程假设做原型。
• 写例子和验收场景。
• 对不确定技术做可行性 spike。
• 对受监管或高风险系统做可追溯性评审。
• 在实现成本变高前做用户 walkthrough。

目标不是冻结一切。目标是在变更代价变痛之前，让不确定性可见。