此文是对《一份汽车软件需求的生成过程》的简要扩充，以更具体地理解如何写好一份汽车软件需求。
我们可以将一份好需求整体总结为以下8个特点：完整性、可行性、可验证性、不含糊性、一致性、正确性、可理解性、可修改性。
1
完整性
所有外部需求都应被确认。
需求包含功能、性能、设计限制、接口等关键要素。
软件外部的输入数据类别应完整，要明确指定对有效和无效输入值的响应，比如，对于“电压大于20V时，......”，应该增加“电压小于20V时，......”。
术语应明确定义。
2
可行性
能够在系统及其使用环境的已知能力和限制范围内实现。
技术上能不能做。
不需要以过高的成本或其他突出损失来实现。
3
可验证性
每一条需求都是可验证的。
不需要以太高的成本去验证。
需求应定义明确，比如，“经常会出现”、“性能良好”、“HMI美观”就不可验证。
理论上要成立，比如，“车机永远不能死机”是无法去验证的。
4
不含糊性
每条需求只有一种解释。
应有明确定义的术语表。
对于创建者和使用者都是明确的。
动词更胜于名词。
应有主语，比如，“每50ms发送一次信号”就语焉不详。
不要使用“和”、“或”、“如果”、“但是”这些承接词，比如，“在遇到故障时，控制器应记录DTC，并点亮仪表灯”应拆分为两条。
自然语言自带含糊性，需独立第三方评审。
5
一致性
需求内部没有冲突。
需求与上级文档一致。
使用的术语要统一。
6
正确性
需求描述是针对产品的。
与相关文档进行比对，比如，上级规范、base项目文档以及相关标准。
客户或用户视角下的评审。
基于追溯关系来检查。
工具或流程无法确保正确性。
7
可理解性
足够精简，内容有任何删减都会导致含义变化。
不需要以过高的成本去理解。
应增加适当的注释。
使用这些需求的角色都能理解。
充分使用图和表，比如，时序图、功能块图、真值表等。
8
可修改性
容易修改并还能保持原有的结构和风格。
具有连贯且易于阅读的结构，包括目录和引用。
不冗余，即同一需求在需求规范中仅出现一次。
需要出现多次时，可以使用引用的方式。
每条需求都是独立的，而不是与其他需求混在一起。
9
写在最后
整体来说，撰写需求时，要干脆利落，要“毫无感情”。
但值得关注的是，这种要求更多是面向“工程师”的工程语言，而现在的汽车软件需求中有很大一部分是非工程的。
完
