7、需求量化与测试追踪的关键要点

需求量化与测试追踪的关键要点

一、需求量化的重要性与方法

1.1 可量化需求的必要性

在撰写需求时，很容易写出听起来不错但无法验证的需求。例如“用户友好”这一常见需求，我们很难明确它的具体衡量标准，也不清楚如何去测量。一个好的需求需要是可量化的，像“软件要快”“软件要易于使用”这样的表述并不能让人理解具体含义，因为“快”和“易于使用”没有明确的界定。每个需求都应被量化，这样才能作为成功与否的判定标准，或者成为一个可测量的数值。

1.2 避免追求完美的需求

我们都希望系统是完美的，但这并不现实。除非是开发最高安全完整性级别的安全关键系统，否则不应设定完美的需求。以下是一些假设完美的需求示例：
| 类型 | 示例 | 问题 |
| ---- | ---- | ---- |
| 不良示例 | “软件永远不会崩溃” | “永远”不现实，没有系统能保证绝对不崩溃 |
| 不完整示例 | “硬件故障平均间隔时间至少为 5000 小时” | 未提及软件故障，应关注整个系统的故障率 |
| 不良示例 | “系统应安全” | “安全”含义不明确，没有绝对安全的系统 |
| 不良示例 | “系统应安全” | 没人知道如何使系统完全抵御攻击，且新攻击不断出现 |
| 不良示例 | “系统应易于使用” | 表述不精确，未指定用户群体 |

避免追求完美的需求可能会很棘手，不能在每个需求中都包含异常和错误响应情况。可以在需求中单独设置故障响应部分来解决这个问题。例如：
- 好的示例：“软件崩溃平均间隔时间应超过 1000 运行小时。至少 90%的软件崩溃后应在一分钟内自动重启以恢复