7、需求量化与测试追踪全解析

需求量化与测试追踪全解析

1. 需求量化的重要性与挑战

在制定需求时，我们常常会写出听起来很不错但却无法验证的内容。比如“用户友好”这一常见需求，到底多友好才算友好，又该如何衡量呢？实际上，嵌入式设计师所说的“用户友好”，往往只是“设计工程师所认为的用户友好”，而没有考虑到普通用户与设计工程师的差异。

一个好的需求必须是可量化的。像“软件要快”“软件要易用”这样的表述，根本无法让人明确其具体含义。因此，每个需求都应量化，以便作为成功的通过/失败标准，或者用可测量的数字来表示。

然而，量化需求并非易事，我们需要创建有实际意义且可操作的衡量标准。例如，“软件永远不会崩溃”这样的需求虽然诱人，但却不切实际，因为“永远”是一个极长的时间概念。所以，我们要制定能反映真实需求，或者至少能合理替代目标需求的量化方法。

1.1 避免追求完美的需求

我们都希望系统是完美的，但这在大多数情况下是不现实的。除非是开发最高安全完整性级别的安全关键系统，否则就不能假定完美是可行的。因此，需求应避免对完美的要求和假设。

以下是一些假定完美的需求示例：
| 示例类型 | 需求内容 | 问题分析 |
| ---- | ---- | ---- |
| 不良示例 | “软件永远不会崩溃” | 不现实，没有系统能保证永远不崩溃 |
| 不完整示例 | “硬件故障的平均间隔时间至少为 5000 小时” | 未提及软件故障，整个系统的故障率才是关键 |
| 不良示例 | “系统应安全” | “安全”的定义不明确，没有绝对安全的系统 |
| 不良示例 | “系统应安全可靠” | 没人知道如何使系统完全