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

此文是对《一份汽车软件需求的生成过程》的简要扩充，以更具体地理解如何写好一份汽车软件需求。

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

1

完整性

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

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

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

术语应明确定义。

2

可行性

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

技术上能不能做。

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

3

可验证性

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

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

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

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

4

不含糊性

每条需求只有一种解释。

应有明确定义的术语表。

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

动词更胜于名词。

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

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

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

5

一致性

需求内部没有冲突。

需求与上级文档一致。

使用的术语要统一。

6

正确性

需求描述是针对产品的。

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

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

基于追溯关系来检查。

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

7

可理解性

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

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

应增加适当的注释。

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

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

8

可修改性

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

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

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

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

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

9

写在最后

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

但值得关注的是，这种要求更多是面向“工程师”的工程语言，而现在的汽车软件需求中有很大一部分是非工程的。

完