如何写一份牛X的汽车软件需求

一份差的需求会带来什么影响呢？在开发阶段，软件工程师看不懂需求，反反复复跟需求工程师确认需求，需求工程师有要跟客户确认需求，在测试阶段，测试工程师看不懂需求，拉着开发和需求开始三方扯皮。这种情况太常见了。一份好的软件需求重要性就不言而喻了。

坦白的说需求工程师(系统工程师)是项目中最重要的职位之一。一份清晰而又准确的需求文档是一个项目是否优秀的基石，而一个优秀的需求工程师团队更能够直接大幅提升整个项目的效率开项目进度。需求工程师本来应该是由经验丰富的老工程师担任。

但实际呢？绝大多数车企往往是新员工们照着前人留下的模板依葫芦画瓢，没有对其进行过系统的需求撰写培训，而且有时。

软件需求是软件工程师直接跟客户理需求，甚至自己给自己提需求，太难了。

一份好的软件需求，就像一份干锅牛蛙，远观赏心悦目、食欲大增，细尝色味俱全、营养丰富。牛蛙尽是精华没有杂肉，又辅以葱椒花生，调节口感、丰富层次。

那么什么样的需求文档才可当此美喻？

好的软件需求要符合以下六个条件。下面通过一个例子来逐一讲解。

01.

干净利落

软件需求只写必要信息，只能包含描述性、定义性的内容，而不能包含解释性的内容。需求内容可以用不同字体表示不同含义，使整体阅读起来干净、清晰、有序。

这里举一个我前面文章里用过的例子：

如果满足以下条件，信号 ACC Active State 应设置为 SUPPRESSED[ACC-Req 002]:

• 信号Safe Vehicle Speed小于30kph OR

• 信号Safe Vehicle Speed大于120kph.

这段需求中的“应”、“设置”、“如果满足...条件”都是定义性的用词，不拖泥带水，用最简单的语句描述完软件行为。很多新手写需求时会带上学生时代写作文的拖沓毛病，写成这样：

如果满足以下【**所有的**】条件，信号 ACC Active State 应【**总是**】设置为 SUPPRESSED。

注意中括号里的内容，完全是废话，且容易引起歧义。这种内容是要尽量避免在需求文档中出现。

另外，这段需求中斜体，代表“信号”；加粗黑体，代表“状态”。很多需求里不会出现“30”、“120”这种具体数字，因为这是标定数据，以后可能会修改，那么就可以用大写加下划线的形式来替代，比如 “MIN_ACC_ACT_SPD”、“MAX_ACC_ACT_SPD”，说明该变量为可标定数据。这些格式的调整可以显著地提升需求文档的可阅读性以及阅读效率。并且需求一目了然，方便读者理解需求。

干净利落

02.

简单明确

需求工程师在写软件需求时不能使用有二义性的，或带主观色彩的语句或词组。另外，尽量定义软件在什么情况下“做什么”，而不是定义在什么情况下“不做什么”，因为前者更简单完备，不容易有遗漏。

就着前面的例子。

如果满足以下【**每个**】条件时，信号 ACC Active State 应设置为DEACTIVATED [ACC-Req 002]:

• 摄像头状态为无效，

• 雷达状态为无效 .

中括号里的 "每个" 就是引入二义性的用词。你告诉我读完上述需求后，你觉得前述两个条件彼此是“与”，还是“或”的关系？

正确的写法是删除【**每个**】， 并明确的写出关系词 or , 来消除二义性：

如果满足以下条件时，信号 ACC Active State 应设置为DEACTIVATED [ACC-Req 002]:

• 摄像头状态为无效，OR

• 雷达状态为无效 .

偶尔也有新手会写成这样：

如果满足以下条件时，信号 ACC Active State 应设置为DEACTIVATED [ACC-Req 002]:

• 信号Safe Vehicle Speed [***足够小***], OR

• 信号Safe Vehicle Speed [**太大***].

上述例子列举的有些极端。但经常有工程师不以为然的用一些主观的、完全没有明确定义的概念来描述软件需求。

最后，不要把需求按照否定定义去写。比如不要把上面这个需求写成这样:

如果满足以下条件，信号 ACC Active State 应 [***NOT***] 设置为 DEACTIVATED[ACC-Req 002]：

• 摄像头状态为无效，OR

• 雷达状态为无效 .

"只要雷达或者摄像头有一个状态为无效，信号 ACC Active State 就不设置为DEACTIVATED"。这样的写法会不会觉得读起来很费劲，而且容易造成需求理解有偏差，因此不要写这种否定型的需求。

简单明确

03.

不可分解

每条需求都必须是组成某个功能的最基本单元，不能够再继续分解。

如果满足以下条件，信号 ACC Active State 应设置为 SUPPRESSED[ACC-Req 002]：

• 信号Safe Vehicle Speed小于30kph OR

• 信号Safe Vehicle Speed大于120kph.

大家仔细看我用的这个例子。它其实不能被认定成一条需求，因为如果你仔细分析，这段话是可以分解的。我可以用以下两条需求来完全替代它:

• 如果信号Safe Vehicle Speed小于30kph，信号 ACC Active State 应设置为 SUPPRESSED。

• 如果信号Safe Vehicle Speed大于120kph，信号 ACC Active State 应设置为 SUPPRESSED。

所以我们虽然在行文上可以把这段描述写成一段话，但必须赋予它两个需求编码需求编号，每个条件一个。只赋予一个编码是错误的，并且会在测试和链接的时候出现问题。

不可分解

04.

便于测试

每条软件需求都必须能直接测试。这里“直接”的意思是需求里描述的信号或其他接口是完备的，测试设备可以直接控制的。例如上述例子：

• 如果信号Safe Vehicle Speed小于30kph，信号 ACC Active State 应设置为 SUPPRESSED。

上述需求中输入信号为Safe Vehicle Speed, 输出信号为 ACC Active State。HIL测试人员能够通过测试设备改变输入信号，并且可以观察输出信号的变化的情况下，这条需求的设计才算是合理的。

这个例子里Safe Vehicle Speed 可以通过改变CAN总线上的车速信号，并且能通过XCP观察，输出信号也是一个CAN信号，则可以直接观察，于是这才是一条好的需求。如果信号不能直接观察，就需要改变需求的描述方式。这就是为什么HIL测试工程师一定要参与需求评审。

还有一种情况是需求内容根本无法测试。例如最好不要在软件需求里写PI控制器的详细控制特性，因为很多情况下HIL测试是不容易设计出测试用例的。这部分需求最好写到软件需求的下一级，也就是设计需求中，用SIL的方式测试。

便于测试

05.

可溯源性

所有的软件需求向上必须要映射一条系统需求，向下必须链接一条设计需求。平级必须链接一条HIL测试用例。

一个值得注意的点是，一些具有安全等级ASIL的系统需求，会分解降级为若干个低等级软件需求。我经常在项目中看到某个需求后面标着 “B(D)”, 但是既不知道这是哪个ASIL D需求分解来的，也不知道分解出的另外一个 “B(D)” 需求死哪去了，最后不了了之，这是应该极力避免的。

有ASIL等级的需求要格外注意映射到它的上级安全需求中去。

溯源连丝

06.

需正确区分“需求”和“信息”

做到前面这些要求，还不足以评为一份完美的需求文档。完美的需求文档除了定义软件行为，还要有足够的解释性内容，帮助阅读者理解软件需求，做到仅看文档就能知其然、知其所以然。这就是需求文档的“信息“部分。

前面提到了，需求只能包含描述性、定义性的内容，因此除这部分内容以外，所有的其他内容都因属于信息。其主要分成三类：

• 解释软件行为的原因，举例子、作类比等，用于帮助读者理解；
• 重复定义的软件行为。为了解释行为A，把其他需求文档中的相关软件行为B再复述一遍。由于行为B已经作为需求在别处出现过了，它的复述虽然是定义性语言，但也只能作为信息。

• 给HIL测试团队留下的建议。很多公司的HIL测试是外包的，他们对软件接口并不熟悉。有时软件需求的作者会在需求文档中写下一些备注，指导HIL团队找到正确的接口。

前面的例子中提到了ACC的状态“SUPPRESSED”。好的需求文档在正式定义这些状态之前，需先描述定义了哪些状态、为什么定义这些状态，以及状态的含义和各状态之间的跳转关系，做完这些之后就可以写软件需求了。有时候觉得这些信息才是需求文档里画龙点睛的地方。