关于ASPICE的介绍

1.追本溯源

我们通常在做ASPICE需求时，会碰到一个词。就是非功能性需求。那非功能性需求是指什么？

在VDA的《Automotive SPICE Process Assessment / Reference Model（ASPICE流程评估/参考模型）》3.1版中（以下简称APSICE3.1），“非功能性需求（non-functional requirement）”一词共出现了11次（包括系统需求和软件需求），列举如下。

按图索骥，搜索ISO/IEC/IEEE24765，被称为Systems and software engineering — Vocabulary （系统和软件工程词汇），在APSICE3.1的第1.2术语b中提到其被引用作为软件，并在“Annex E Reference standards（附录E 参考标准）”中说明引用的版本是2010。那么，追本溯源，到ISO/IEC/IEEE24765:2010的标准里去查找吧。

果然，ISO/IEC/IEEE24765:2010(E)的第1900项词条给出了非功能性需求的定义——

nonfunctional requirement – performance attribute, software requirement that describes not what the software will do but how the software will do it. EXAMPLE：software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Nonfunctional requirements are sometimes difficult to test, so they are usually evaluated subjectively.

非功能性需求：不描述软件做什么、而是描述软件如何做的软件需求。例如：软件性能需求、软件外部接口需求、软件设计约束和软件质量属性。非功能性需求有时很难测试，因此通常是主观评估的。

——在ISO/IEC/IEEE24765的定义中给出4个例子可以使我们略窥门径：

软件性能需求：CPU、RAM、ROM的占用率是最直观的度量之一。

软件外部接口需求：互操作性（Interoperability）需要考虑各种因素，譬如通信协议、外部系统的数据格式、交互频率等等。

软件设计约束：可维护性（Maintainability）、可靠性（Reliability）、安全性（Security）等。

软件质量属性：MISRA的代码准则就属于此类需求。

上述四项中的每一项拓展开来，都是一个比较大的话题，就在后面的系列中分别讨论吧。

2.性能需求

定义

提到非功能性需求，最直观的内容莫过于性能需求了。那么，什么是性能需求呢？俗语“路遥知马力”就是性能需求的实际场景之一，指的是路途遥远才能知道马的脚力好赖。而如果需要明白ASPICE中的明确定义，则需要参考前一篇《ASPICE中的非功能性需求（1）——追本溯源查定义》的定义查找方法，在ASPICE3.1所引述的ISO/IEC/IEEE24765:2010的标准中找到词条第2107项，关于Performance（性能）的定义如下：

Performance : the degree to which a system or component accomplishes its designated functions within given constraints, such as speed, accuracy, or memory usage

性能：系统或组件在给定的限制条件（如速度、精度或内存使用）内完成其指定功能的程度。

看到这3个举例中的限制条件，很容易联想到精简生产（LEAN）中的KPI三要素——QCD（Quality, Cost, and Delivery，品质、成本、与交付），比对列表如下：

那我们就从这几个限制条件入手，分析性能需求涵盖的内容——

速度

“任何屏幕都应该在3秒内显示”——响应时间就是典型速度相关性能需求，类似的示例还有每秒处理事务数、每小时要服务客户数等。在这类需求中，应用程序必须在特定的时间限制内响应外部事件，这不单在一般条件、更重要的是在峰值条件下仍然能满足需求，下的一些问题有助于帮助项目组获取速度方面的性能需求：

精度

在一般的软件应用程序中，精度（Accuracy）往往不会被作为需求单独提出来，然而在自动驾驶的项目中则是人命关天的事情。2018年3月，在美国亚利桑那州坦佩市，搭载了Uber自动驾驶系统的测试车正在以70km/h的速度行驶，行驶中不幸与过马路的49岁女子伊莱恩·赫兹伯格相撞，导致该女子身亡。该事件后，NTSB（美国国家运输安全委员会）公布了Uber去年自动驾驶车祸事件中的一些细节，以及Uber自动驾驶以往的一些碰撞事故。文件显示，Uber的自动驾驶汽车在发生撞击前5.6秒钟就检测到了行人，但将其错误识别为汽车，撞击前5.6秒时又将其归类为其他物体。（简要分析的PDF文件可在美国政府官 上下载，链接：go.usa.gov/xp9Eu ）

在自动驾驶方面，精度的重要性不言而喻，然而因其复杂性，这却不是一个通用的检查表（Checklist）或者问卷（Questionnaire）就能覆盖的，往往涵盖在算法团队的复杂需求中，例如过滤雷达的ghost target以避免探测到错误的物体，就是精度方面非功能需求的例子。当然，对精度的需求还有更多的应用场景，就不在这里更多讨论了。

资源使用

通常指定特定硬件组件上的使用量，通常以百分比表示，例如CPU利用率、内存利用率等。在应用程序/系统可扩展和运行时，系统资源利用率应保持在可接受的限制范围内。下的一些问题有助于帮助项目组获取资源使用方面的性能需求：

除了速度、精度和资源使用上述这三个主要方面之外，性能需求还包含其他的维度，比如表征系统处理负载增长的能力的可伸缩性（Scalability）。然而通俗的说，参考QCD（质量、成本、交付）的维度考虑，性能需求体现了系统如何“多快好省”地实现客户的功能需求。

3.外部接口需求

炎热的夏季，当一般用户在车里调节空调温度的时候，会在意温度的高低、风速和风向，而不会在意空调设置的通信协议是CAN、MOST、还是AVCLAN，数据格式是8位还是16位。在这里，前者（温度高低、风速风向）就是是我们常说的功能需求；而后者（通信协议、数据格式）相对于单个ECU而言，就是非功能性需求的第二类——外部接口需求，它明确系统与外部软硬件、数据库的交互内容。

ISO/IEC/IEEE24765:2010(E)的第1103项词条给出了外部接口需求（external interface requirement）的定义——

a system or software requirement that specifies a hardware, software, or database element with which a system/software system or system/software component must interface, or that sets forth constraints on formats, timing, or other factors caused by such an interface

一种系统或软件要求，其中规定了系统/软件系统或系统/软件组件必须与之接口的硬件、软件或数据库元素，以及由该接口引起的格式、时间或其它因素的限制

这在需求描述中可以被称为互操作性（Interoperability），其规定了系统与其他指定应用程序或组件成功集成的程度，用于描述不同程序通过一组通用交换格式交换数据、读写相同文件格式以及使用相同协议的能力。如下的一些问题有助于明确此类需求：

这篇写的比较短，毕竟只是概念性的介绍，关于接口的需求获取、架构设计、开发实现以及测试实施，将在未来的专题里进一步扩展。

4.设计约束

为写这篇文章专门在知乎制造了一个实际的业务场景，就从这个案例开始说起吧——

2021年6/23，本人向知乎提出了一个申诉“知乎创作中心说的是每发一个视频能加70分，上传了不止一个视频但分数却没什么提升，请问是什么原因？”

之前提到过，ISO/IEC/IEEE24765:2010(E)的第1900项词条给出了非功能性需求的定义——

nonfunctional requirement – performance attribute, software requirement that describes not what the software will do but how the software will do it. EXAMPLE：software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Nonfunctional requirements are sometimes difficult to test, so they are usually evaluated subjectively.

非功能性需求：不描述软件做什么、而是描述软件如何做的软件需求。例如：软件性能需求、软件外部接口需求、软件设计约束和软件质量属性。非功能性需求有时很难测试，因此通常是主观评估的。

当然，质量部门作为熟悉流程的一方固然可以提供有力支持，但开发部门是否落地又是另一回事了。

5.软件质量属性篇

结合在前面中引述的ISO/IEC/IEEE24765中关于非功能性需求的定义：不描述软件做什么、而是描述软件如何做的软件需求。例如：软件性能需求、软件外部接口需求、软件设计约束和软件质量属性。非功能性需求有时很难测试，因此通常是主观评估的。在第一篇追本溯源之后的几篇，就是根据定义中的几类例子进行解释，前三项已经做过分析，这部分就谈谈最后的——“软件质量属性（software quality attributes）”。

当我们讨论软件质量属性话题的时候，必须限定范围，否则由于行业、技术、标准等等的区别相应的定义和侧重也各有不同，无法达成一致。而“限定范围”这件事情，就成了软件质量模型（Software Quality Models）的使命，随着时代的发展质量模型也在不断演化，下面将参考维基百科中软件质量相关话题中的分类，并通过图例简要进行说明（链接：en.wikipedia.org/wiki/T ），如果有兴趣的话可以再进一步研究。

1. 早期质量模型: McCall, Boehm, Dromey
2. 行业质量标准: ISO 9126, ISO SQuaRE（ISO 25010）,
3. FLOSS质量模型: OSMM Capgemini, OSMM Navia, QSOS, OpenBRR, QualiPSo, QualOSS, SQO-OSS

早期质量模型: McCall, Boehm, Dromey

McCall质量模型（1977）

https://maisqual.squoring.com/wiki/index.php/McCall_Quality_Model

Boehm质量模型（1976）

https://maisqual.squoring.com/wiki/index.php/Boehm_Quality_Model

Dromey质量模型（1995）

行业质量标准:

ISO 9126

ISO SQuaRE（ISO/IEC 25000系列）

FLOSS质量模型

OSMM

QSOS

OpenBRR

https://www.researchgate.net/figure/Figura-6-Esquema-de-funcionamento-do-modelo-OpenBRR_fig5_274098118

QualiPSo

https://www.researchgate.net/figure/Trustworthiness-qualities-here-in-Qualipso-survey-14-and-ISO-9126_tbl1_310776065

QualOSS

https://maisqual.squoring.com/wiki/index.php/Free/Libre_Open_Source_Quality_Models

SQO-OSS

https://www.researchgate.net/figure/The-SQO-OSS-quality-model_fig1_225936124

列举了这许多的模型，那么该如何落地呢？各行业领域方式不同，如果事关汽车电子软件，那么作为质量模型的ISO SQuaRE（ISO 25010）在具体代码标准中就需要参考行业相关的MISRA、AUTOSAR，而查验代码质量则需要依托相应的工具链，在 东晓一家：ASPICE工具链整理（5）- 单元验证类 一文中，列举了静态代码验证的各类工具，而其中关于TICS中如何设定合理的软件代码质量目标介绍有一定借鉴意义，从以下几个方面综合打分给出代码质量等级（如图），可以相对有效地提高代码质量。该方法仅作为例子参考，不同项目需要根据各自的实际情况设置合理的软件质量目标、配置工具链并进行监控改进。

Code Coverage（代码覆盖率）

Abstract Interpretation（抽象解释）

Cyclomatic Complexity（圈复杂度）

Compiler Warnings（编译器警告）

Coding Standards（编码标准）

Code Duplication（代码重复）

Fan Out（扇出）

Security（安全性）

6.完结

在完结关于非功能性需求的话题时，让我们回顾下标准（ISO/IEC/IEEE24765:2010）给出的定义——

nonfunctional requirement – performance attribute, software requirement that describes not what the software will do but how the software will do it. EXAMPLE：software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Nonfunctional requirements are sometimes difficult to test, so they are usually evaluated subjectively.

非功能性需求：不描述软件做什么、而是描述软件如何做的软件需求。例如：软件性能需求、软件外部接口需求、软件设计约束和软件质量属性。非功能性需求有时很难测试，因此通常是主观评估的。

从定义所举的例子看，这里的“软件如何做（how the software will do it）”涵盖了两个视角：

终端用户视角（end user）：软件性能需求就是典型的终端用户视角，除性能外，软件的易用性、界面美观、安全性等等，能被终端用户直接感知到“功能运行得好不好”的内容均属此类，汽车行业的终端用户便是汽车的车主、司机和乘客等使用者了。此类需求被称为执行质量（Execution qualities），可以在系统运作时观察到的质量，例如安全性及易用性等。

非终端用户视角（end user）：外部接口需求、设计约束、质量属性等的内容，对于终端用户是不可见的，但对于供应链上的各个厂商却至关重要，如汽车电子产业的各家OEM、Tier1/2/3等。此类需求被称为发展质量（Evolution qualities），和软件系统结构及开发过程有关的质量，例如软件可测试性、可维护性、可扩展性、可伸缩性（scalability）等

可见，无论从终端用户视角抑或非终端用户视角，标准定义中的例子都没有穷举，在实际的应用中，考虑不同的行业、技术、环境等因素可以有不同的内涵，需要结合这些因素使用专业的方法论，以确保非功能性需求的覆盖率和执行度。

推荐阅读

国内主机整车EEA架构汇总

谈谈整车控制器对油门信 处理的理解

谈谈整车OTA系统的理解

五千字说清汽车基础软件及国产现状

带不带功能安全(IS26262)的区别，功能安全要做啥？

谈谈simulink自动代码生成

浅谈电机控制器及其功能

谈谈Bootloader自更新

电子电气架构设计需要考虑哪些方面？

汽车E/E架构的 络安全分析

深度解读汽车域控制器

自动驾驶域控制器信息梳理

深度分析整车控制域现状与发展

分享不易，恳请点个【】和【在看】

阅读原文阅读 684

分享收藏

赞在看