一份汽车软件需求的8个特点

我们可以将一份好需求整体总结为以下8个特点：完整性、可行性、可验证性、不含糊性、一致性、正确性、可理解性、可修改性。

1

完整性

• 所有外部需求都应被确认。

• 需求包含功能、性能、设计限制、接口等关键要素。

• 软件外部的输入数据类别应完整，要明确指定对有效和无效输入值的响应，比如，对于“电压大于20V时，......”，应该增加“电压小于20V时，......”。

• 术语应明确定义。

2

可行性

• 能够在系统及其使用环境的已知能力和限制范围内实现。

• 技术上能不能做。

• 不需要以过高的成本或其他突出损失来实现。

3

可验证性

• 每一条需求都是可验证的。

• 不需要以太高的成本去验证。

• 需求应定义明确，比如，“经常会出现”、“性能良好”、“HMI美观”就不可验证。

• 理论上要成立，比如，“车机永远不能死机”是无法去验证的。

4

不含糊性

• 每条需求只有一种解释。

• 应有明确定义的术语表。

• 对于创建者和使用者都是明确的。

• 动词更胜于名词。

• 应有主语，比如，“每50ms发送一次信号”就语焉不详。

• 不要使用“和”、“或”、“如果”、“但是”这些承接词，比如，“在遇到故障时，控制器应记录DTC，并点亮仪表灯”应拆分为两条。

• 自然语言自带含糊性，需独立第三方评审。

5

一致性

• 需求内部没有冲突。

• 需求与上级文档一致。

• 使用的术语要统一。

6

正确性

• 需求描述是针对产品的。

• 与相关文档进行比对，比如，上级规范、base项目文档以及相关标准。

• 客户或用户视角下的评审。

• 基于追溯关系来检查。

• 工具或流程无法确保正确性。

7

可理解性

• 足够精简，内容有任何删减都会导致含义变化。

• 不需要以过高的成本去理解。

• 应增加适当的注释。

• 使用这些需求的角色都能理解。

• 充分使用图和表，比如，时序图、功能块图、真值表等。

8

可修改性

• 容易修改并还能保持原有的结构和风格。

• 具有连贯且易于阅读的结构，包括目录和引用。

• 不冗余，即同一需求在需求规范中仅出现一次。

• 需要出现多次时，可以使用引用的方式。

• 每条需求都是独立的，而不是与其他需求混在一起。

9

写在最后

整体来说，撰写需求时，要干脆利落，要“毫无感情”。