ASPICE v3.1 與 v4.0 版本差異：SYS.2 系統需求分析

本文為ASPICE v3.1與v4.0標準的差異性分析 — SYS.2 System Requirements Analysis 系統需求分析；本文章為「ASPICE v4.0 標準解讀」系列文章，筆者將針對ASPICE標準條文提供解讀與說明，期許本篇文章能夠為讀者，解決標準導入時的疑惑。

其他參照說明：

ASPICE v4.0文章目錄 / (v4.0)ASPICE標準: SYS.2 系統需求分析

BP差異比對表

如上表，多數v3.1的BP(Base Practise)都有在新版的v4.0提到，其中三個主要差異如下：

(1) 需求制定的統合

筆者引述ASPICE Guideline 2.0的部分內文：

在ASPICE標準中（版本4.0之前），加入BP「Verification Criteria」的初衷是根據需求工程領域的最新理念，強調需求必須是可驗證的，否則就無法被視為真正的需求。

然而，這一做法卻引發了許多誤解。

誤解1: 評分上的不一致

在SYS.2及SWE.1的評鑑過程中，常見的問題如下：

BP1 明確指定需求:  評分為F
BP5 定義驗證準則:  評分為N或P

這樣的評分顯示需求已撰寫，但其驗證準則卻未提及或有明顯缺漏。在這種情況下，若一個需求未能以可驗證的方式呈現，又如何能將其評為F呢？因此，存在相關的矛盾。

誤解2: 重複撰寫需求

BP中所提到的「Verification Criteria」似乎暗示著，要額外撰寫原有需求之外的資訊。然而，Verification Criteria實際上已經內含在需求陳述中，這導致內容的重複。

舉例來說：

The ECU shall be able to receive 100 to 110 bus messages within 1[s] with a tolerance of +0.2[s]

如果要針對這條需求額外撰寫「Verification Criteria」，則會發現這些驗證準則早已經被涵蓋在既有的需求中了。其中：

「... able to receive 100 to 110 bus messages ... 」提到驗證時的輸入範圍
「... within 1[s] with a tolerance of +0.2[s] 」提到驗證時的輸入限制(包含誤差範圍)

綜合結論

在最新版的標準中(即v4.0)，將v3.1版本中的BP5的「Verification Criteria」概念，整合到BP1之中。專案團隊在制定需求時，需要確保需求本身是可驗證的，而撰寫「Verification Criteria」可以是一個簡易的確認方法。

(2) 「系統全景」取代「運作環境」

在ASPICE標準中（版本4.0之前），BP4多半強調要識別系統(產品)對外的介面，並針對該介面進行影響分析，在最新版的標準中，將運作環境(Operating environement)置換成系統全景(System Context)，其概念是相似的。

所謂的「系統全景的影響分析」，意思是考慮「待開發產品」範圍之外的任何事物，也就是超出系統(產品)邊界的範疇。

筆者備註

值得一提的是，System Context在近幾年釋出的標準中，都有被提到:

ISO 26262 Part 3, 概念階段時，需要釐清系統全景
ISO/SAE 21434 Clause 9, 概念階段時，需要釐清系統全景
IEC 62443-4-1 SR-1: 定義產品安全全景

新版的ASPICE置換用詞的用意，也是為了未來跟其他車用標準做整合。

(3) 合併追溯及一致性

在ASPICE v2.5時，追溯與一致性是合在同一個BP之中，然而該標準在業界採用時，常發生漏掉評估的問題，因此，在ASPICE v3.1版本時，特別將追溯性與一致性分開成兩個獨立的BP。

然而，分開成兩個BP也造成了誤解，導致以下結果：

追溯性 = F ; 一致性 = N 

追溯性 = N; 一致性 = F

以上的結果，無論哪一個都呈現明顯的矛盾。在ASPICE模型中，強調資料之間的追溯性和一致性，事先必須確保追溯性才能確保後續的一致性。

在新版的ASPICE v4.0中，將追溯性和一致性合併為同一個基本原則，並再次強調，追溯性和一致性是密不可分的。