点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
1.追本溯源
“在ASPICE里，非功能性需求是指什么？”
——在进行APSPICE培训时，无论系统团队或是软件团队都提出过这个问题，一直没有给出具体的答案。用碎片时间进行了一些整理，写下本文作为回答。
在VDA的《Automotive SPICE Process Assessment / Reference Model（ASPICE流程评估/参考模型）》3.1版中（以下简称APSICE3.1），“非功能性需求（non-functional requirement）”一词共出现了11次（包括系统需求和软件需求），列举如下。
首先，我们直接在APSICE3.1搜索非功能性需求的定义，“not found（没有找到）”，但在“Annex C Terminology（附录C 术语）”中找到了线索——功能性需求（Functional requirement）的定义、以及定义的来源ISO/IEC/IEEE24765：
按图索骥，搜索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的代码准则就属于此类需求。
上述四项中的每一项拓展开来，都是一个比较大的话题，就在后面的系列中分别讨论吧。
定义
提到非功能性需求，最直观的内容莫过于性能需求了。那么，什么是性能需求呢？俗语“路遥知马力”就是性能需求的实际场景之一，指的是路途遥远才能知道马的脚力好赖。而如果需要明白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（质量、成本、交付）的维度考虑，性能需求体现了系统如何“多快好省”地实现客户的功能需求。
炎热的夏季，当一般用户在车里调节空调温度的时候，会在意温度的高低、风速和风向，而不会在意空调设置的通信协议是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），其规定了系统与其他指定应用程序或组件成功集成的程度，用于描述不同程序通过一组通用交换格式交换数据、读写相同文件格式以及使用相同协议的能力。如下的一些问题有助于明确此类需求：
这篇写的比较短，毕竟只是概念性的介绍，关于接口的需求获取、架构设计、开发实现以及测试实施，将在未来的专题里进一步扩展。
为写这篇文章专门在知乎制造了一个实际的业务场景，就从这个案例开始说起吧——
2021年6/23，本人向知乎提出了一个申诉“知乎创作中心说的是每发一个视频能加70分，上传了不止一个视频但分数却没什么提升，请问是什么原因？”
收获的回答是“目前视频分数主要以「原创」「优质」作为内容标准，用户的「转载」视频是不计入的。除了用户自标「原创」的视频，也需要经过社区审核，不满足「原创」条件的将不计入分数计算。”
好，知乎内部有这样的规则没问题，但在页面上并没有将此规则公之于众，以至于用户会理解为非原创的视频也能积70分，这在法律上会构成风险，于是追问“那为什么没有在规则中说明呢？按照用户的理解，没有附加条件下，上传转载的视频也是可以加至少70分的，而没有给加分属于违反知乎本身的规则。无论是存在规则误导用户，还是没有按照规则加分，都是不可接受的。”“为了避免其他相关的法律风险，应及时将“发 1 分钟以上视频创作分至少 +70 分”的规则说明加上附加说明即“目前视频分数主要以「原创」「优质」作为内容标准，用户的「转载」视频是不计入的。”这是作为一名负责任的用户的建议，请采纳并及时回复，谢谢。”
收获的回答依然是“目前视频分数主要以「原创」「优质」作为内容标准，用户的「转载」视频是不计入的。除了用户自标「原创」的视频，也需要经过社区审核，不满足「原创」条件的将不计入分数计算。”
作为用户只能认了，回复“了解了，存在法律风险但知乎仍然缺少整改意愿，既然这里不鼓励转载视频，以后转载视频就上b站，然后把链接在文中给出，言尽于此了。”
以上这个案例中，用户按业务场景提出申述、知乎的客服按内部规则办事、开发团队按需求开发，看上去都没有问题，但为什么最终的结果是让法律风险一直存在于知乎之中（至少2020/6/23之前），而且转载视频流量会流向竞争对手（如B站）呢？那是因为在最上游的需求开发中，非功能性需求中的设计约束部分（法律法规的因素）被忽略的原因。
之前提到过，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.
非功能性需求：不描述软件做什么、而是描述软件如何做的软件需求。例如：软件性能需求、软件外部接口需求、软件设计约束和软件质量属性。非功能性需求有时很难测试，因此通常是主观评估的。
转回到基于ASPICE的汽车电子开发场景，在开发过程中，Stakeholder Requirement（相关方需求）有事被简单的理解为Customer Requirement（客户需求），然而其他的相关方被忽略了，无论是功能安全ISO26262、还是信息安全或OTA强标，都因为开发时间紧等原因被直接忽略了，而这些来自行业或政策法规要求往往最终会带来不可估量的损失。Customer（客户）、Industry（行业）和Government（政府）三大方面，是设计约束的主要来源，是在SYS.1需求提取从源头上就应该关注的，否则滴滴在信息安全上的例子就是前车之鉴。
在项目实际开发中，需求工程师的素质非常重要，虽然有些公司的需求工程师经验不足只是把之前项目的需求拷贝过来修修补补了事，但真正要避免项目风险，应当着实分析客户需求、行业需求、法律法规的需求，将其都纳入Stakeholder Requirement（相关方需求）中，才能保证下游开发流程不会错过。例如在Polarion中，文件来源（Document Source）不但要考虑Customer，也要考虑Industry（行业）和Government（政府）。
当然，质量部门作为熟悉流程的一方固然可以提供有力支持，但开发部门是否落地又是另一回事了。
结合在前面中引述的ISO/IEC/IEEE24765中关于非功能性需求的定义：不描述软件做什么、而是描述软件如何做的软件需求。例如：软件性能需求、软件外部接口需求、软件设计约束和软件质量属性。非功能性需求有时很难测试，因此通常是主观评估的。在第一篇追本溯源之后的几篇，就是根据定义中的几类例子进行解释，前三项已经做过分析，这部分就谈谈最后的——“软件质量属性（software quality attributes）”。
当我们讨论软件质量属性话题的时候，必须限定范围，否则由于行业、技术、标准等等的区别相应的定义和侧重也各有不同，无法达成一致。而“限定范围”这件事情，就成了软件质量模型（Software Quality Models）的使命，随着时代的发展质量模型也在不断演化，下面将参考维基百科中软件质量相关话题中的分类，并通过图例简要进行说明（链接：en.wikipedia.org/wiki/T ），如果有兴趣的话可以再进一步研究。
早期质量模型: McCall, Boehm, Dromey
行业质量标准: ISO 9126, ISO SQuaRE（ISO 25010）,
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）
来源：https://www.researchgate.net/figure/Dromeys-Software-Quality-Model_fig4_260391390
行业质量标准:
ISO 9126
来源：https://en.wikipedia.org/wiki/ISO/IEC_9126
ISO SQuaRE（ISO/IEC 25000系列）
来源：https://maisqual.squoring.com/wiki/index.php/ISO/IEC_SQuaRE
FLOSS质量模型
OSMM
来源：https://en.wikipedia.org/wiki/OpenSource_Maturity_Model
QSOS
来源：https://en.wikipedia.org/wiki/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（安全性）
来源：https://www.tiobe.com/tics/tics-framework/
在完结关于非功能性需求的话题时，让我们回顾下标准（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）等
可见，无论从终端用户视角抑或非终端用户视角，标准定义中的例子都没有穷举，在实际的应用中，考虑不同的行业、技术、环境等因素可以有不同的内涵，需要结合这些因素使用专业的方法论，以确保非功能性需求的覆盖率和执行度。
文章来源：汽车ECU开发
会员权益: (点击可进入)谈思实验室VIP会员
END
微信入群
谈思实验室专注智能汽车信息安全、预期功能安全、自动驾驶、以太网等汽车创新技术，为汽车行业提供最优质的学习交流服务，并依托强大的产业及专家资源，致力于打造汽车产业一流高效的商务平台。
每年谈思实验室举办数十场线上线下品牌活动，拥有数十个智能汽车创新技术的精品专题社群，覆盖BMW、Daimler、PSA、Audi、Volvo、Nissan、广汽、一汽、上汽、蔚来等近百家国内国际领先的汽车厂商专家，已经服务上万名智能汽车行业上下游产业链从业者。专属社群有：信息安全、功能安全、自动驾驶、TARA、渗透测试、SOTIF、WP.29、以太网、物联网安全等，现专题社群仍然开放，入满即止。
扫描二维码添加微信，根据提示，可以进入有意向的专题交流群，享受最新资讯及与业内专家互动机会。
谈思实验室，为汽车科技赋能，推动产业创新发展！
如有侵权请联系:admin#unsafe.sh