關于ASPICE的介紹

1.追本溯源

我們通常在做ASPICE需求時，會碰到一個詞。就是非功能性需求。那非功能性需求是指什麼？

在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的代碼準則就屬于此類需求。

上述四項中的每一項拓展開來，都是一個比較大的話題，就在後面的系列中分别讨論吧。

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自動駕駛以往的一些碰撞事故。（簡要分析的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分，上傳了不止一個視訊但分數卻沒什麼提升，請問是什麼原因？”

收獲的回答是“目前視訊分數主要以「原創」「優質」作為内容标準，使用者的「轉載」視訊是不計入的。除了使用者自标「原創」的視訊，也需要經過社群稽核，不滿足「原創」條件的将不計入分數計算。”

好，知乎内部有這樣的規則沒問題，但在頁面上并沒有将此規則公之于衆，以至于使用者會了解為非原創的視訊也能積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（政府）。

當然，品質部門作為熟悉流程的一方固然可以提供有力支援，但開發部門是否落地又是另一回事了。

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）

來源：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/

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架構的網絡安全分析

深度解讀汽車域控制器

自動駕駛域控制器資訊梳理

深度分析整車控制域現狀與發展

汽車ECU開發持續為您提供汽車科技、技術305篇原創内容

公衆号

分享不易，懇請點個【】和【在看】

閱讀原文閱讀 684

分享收藏

贊在看