一份汽车软件需求的生成过程

这是来源于ASPICE 3.1的一张追溯图，非常流行。

尽管ASPICE并不是绝对的标准，但我们可以作为讨论框架。今天讲的是软件需求。

1

生成软件需求的4个步骤

抛开理论，面对一个真实项目时，首先该思考的是如何一步一步展开工作。

1.1?分析系统需求和系统架构中与软件相关的部分

软件需求并非凭空而创，它的源头是系统，我们在这步要做的就是将软件的部分剥离出来。

这是一个看文档、分析、沟通、讨论的过程。

1.2 编写软件需求

经过一番脑力与paper工作后，我们会得到一份软件需求，按详略程度，可能是针对完整集成软件的，也有针对具体实现层面的软件组件的。

1.3 建立基线

走完第二步，不能算完。

软件需求是后续一系列工作的基础，我们得定个基准，也就是基线或baseline。

在Doors之类的工具里的话，基线是通过系统直接建立的。如果使用office，至少要有个版本管理。

1.4 对基线进行review

review也是必要的，毕竟这份文档涉众多，还是后续的源头。

如果review发现了问题，修改后应再次打基线。至此，一份软件需求文档正式生成。

下面我们看里面的一些细节。

2

一份软件需求的4个基本属性

我们经常喜欢用word来写需求。

word的段落式描述和多级标题会带来较好的顺序阅读体验，但非条目化和无属性拆分，这会让后续的筛选、追溯、修改、统计、查阅多有不便。

所以，尤其我们有需求管理工具支持时，最好拆分多个属性，这里提供4个最基本的。

2.1 类型

我们把整本需求拆分为很多条后，会知道有些条不是需求，或者是不同类型的需求，大体可分为如下类型：

标题：这基本就等同于word里的各级标题，这是基本要求，不用多解释。

用例：用例也是需求，但它作为承接系统需求和架构（如MBSE里的Use Case图）的环节，会写得不很“技术”、写得很“故事”，也就是外行和领导都能看得懂的，而这对于交流很必要。

比如，用户输入账号密码登录，如通过验证，系统进入主页，否则，提示错误。

功能需求：功能需求是最名正言顺的需求，描述了由某个软件组件实现的功能，并且从软件外部看，它是可观察的或可测试的。

功能需求经常会写得与更高一层级的需求、设计重复，这时，就需要我们做好裁剪。

组件需求：进一步的架构设计和开发，可能需要更细化的需求，即软件组件需求。

当然，架构设计与决策也伴随着组件的划分和需求的分配，这与组件需求是相互依托的。

非功能需求：提到非功能需求，我们最容易联想到性能需求，但不仅仅于此。整体来看，非功能需求可分为两大部分：质量特性和结构性需求。

质量特性基本可以参考ISO/IEC 25010里质量模型的划分，如图。

结构性需求可以理解为架构催生的，比如，接口需求。

定义：可用来对一些专业名词进行说明、澄清。

备注：一些提示或解释，主要为了增加可读性。

2.2 状态

需求是动态变化的，所以其状态会迁转。

Proposed（被提议）：需求已被编辑完成，可以进行review了。

Reviewed（已评审）：需求已经完成评审，可以进行问题处理和决策了。

Approved（已批准）：需求已经完成批准，准备好导入执行了。

Implemented（已执行）：需求已经执行，软件组件已释放。

Rejected（被拒绝）：需求暂不计划执行，或者技术上不可行。

2.3 验证标准

写需求时就考虑验证，这是V模型的一个显著特点。

需求工程师经常不愿意写这一部分，一者总觉得不好写，二者觉得是测试的活儿。

我们分别看这两个抱怨。

实际上，感觉验证标准不好写恰好反映了这部分工作的必要性。当你觉得很难简单描述清楚怎么去验证，这条需求就应该被返工，比如，重新描述、拆分、合并等。

那么，这是测试的活儿吗？也不合适，很显然，测试用例要比验证标准复杂得多。这里主要为了让需求工程师保证需求是可测的。

此外，也应提示验证阶段和方法。比如，单元测试、组件测试、需求测试、集成测试、评审。

2.4 配置

汽车有很多改款配置，软件也有很多分支。配置组合背后往往伴随着软件需求的复用关系。

于是，编写软件需求时，复用及配置工作很是必要。

我们可以增加配置属性来共用一版需求，而配置可以是车型项目，也可以是硬件配置。

然后，在有某条需求的配置处标记yes，或者可标定或软件参数化的部分也可标记具体参数值。

以上描述了一些基础的软件需求属性示例，可做参考。但我们实际项目中，可以根据需要增加很多其他的类别。

3

一份好软件需求的特点

需求是自然语言描述的，这让我们很难量化评价其好坏，且提供几个特性做参考：

完整性

可行性

可验证性

不含糊性

一致性

正确性

可理解性

可修改性

为了尽量实现这些特性目标，我们可以尝试按照如下的“公式”来书写。

即“在什么前提条件（逻辑条件或事件发生或时间段）下，什么系统（或组件）必须（或应该或将会，英文中常分别用具备法律强制意义的shall、可以有争论空间的should及一般性描述的will来对应）能够（或通过什么流程）实现什么目标以及其他细节”。

这会反映出前提、主体、强制性、方式及目标这些基本信息。

5

软件需求的评审

第一小节的最后一个步骤是评审，这里做一个扩充。

评审是我们解决个体能力不足的几乎唯一的手段，其主要涉及两部分：谁来评审和如何评审。

5.1?谁来评审

软件开发是个团队合作的过程，而需求更是几乎所有人都要关注的，我们要让团队来评审（角色定义可参考《汽车电子软件组织的“角色”大起底》）。

具体来看，不同角色要有不同的评审侧重点:

Feature Owner：确保软件需求满足更高层级的系统需求和系统架构设计。

软件架构：确保需求范围正确，满足内部guideline（对需求质量的定义），并遵循产品roadmap。

软件开发：确保需求是可理解的，并且可以被组件实现。

软件测试：关注需求的可理解性和可测试性。

5.2 如何评审

评审范围可以是全部内容，也可以是增量或变更评审。如果选择增量或变更评审，要注意检查它们对软件需求及下游架构其余部分的影响。

进一步地，我们给出一些checklist供参考。

是否遵循以下书写需求的规则：

必须清楚地确定主体；

每个需求都是“原子”级别的；

每项需求都应说得明确不含糊；

尽可能定量地表述需求；

描述系统在所有条件（如初始化、休眠、断电、正常运行、过压、欠压等）下的行为；

避免冗余和琐碎；

使用一致的术语；

在适当的地方使用非语言描述，如流程图。

不同的软件需求之间没有矛盾，以及与高层级需求与设计之间没有矛盾？

软件需求是否能够覆盖及满足所追溯的需求与设计？

是否都使用内部标准术语？

实现这些需求是否有任何风险？

需求是否有机会调整为复用现有设计？

时间相关事件的时间要求及公差是否定义？

是否描述了不同硬件之间存在的差异？

验证标准和验证方法是否明确?

是否有必要的需求属性被遗漏?

......

6

全文小结

本文从以下几个方面进行了简要解读：

生成需求的4个步骤（分析、编写、打基线、评审）。

需求所包含的4个基本属性（类型、状态、验证标准、配置）。

一份好需求的8个特点（完整性、可行性、可验证性、不含糊性、一致性、正确性、可理解性、可修改性）。

写好需求的公式（前提、主体、强制性、方式及目标）。

需求评审的4个角色及评审侧重点。

需求评审的9条checklist。

7

写在最后

从很多经验看下来，一个做得烂的项目基本都有一套混乱的需求。当想要治理项目时，几乎都应该从需求开始。

完

原文标题:一份汽车软件需求的生成过程