ASPICE 標準解讀

ASPICE問題集:純軟體專案,如何將SYS.2與SYS.3產出作為SWE.1輸入?

■ 背景: 純軟體專案,又期望練習SYS.2和SYS.3

在專案開始前,專案團隊根據ASPICE VDA Scope的要求,引進並建立了16個流程及其相關程序、範本、查檢表。

該團隊進行的第一個ASPICE專案是一個虛擬專案,其範圍限定於「純軟體開發」。這意味著,在已建立的ASPICE流程中,只選擇了與軟體工程相關的流程,即SWE.1到SWE.6。

由於這是團隊的首個專案,而且團隊也希望練習所有流程。

基於對產品的假設進行實踐練習,團隊會實作專案範圍之外的SYS.2和SYS.3流程,並產出相關證據,如規格書、設計圖和設計規格...等。

這些產出將作為專案的輸入,但不列入專案評鑑的考量。

■ 問題:SYS.2與SYS.3的產出,如何作為SWE.1輸入?

根據上述背景,專案團隊依據對產品 (軟體) 的預設想法,運用了SYS.2和SYS.3的流程來歸納總結出該軟體及其運作環境所需的需求與規格。

SYS.2與SYS.3的產出,無疑地,是SWE.1的輸入。

在這個情況下,

  • 該如何從SYS.2和SYS.3選擇需求? 該如何呈現其證據?

延伸問題,基於ASPICE SWE.1的定義:

  • 利益相關者需求(Stakeholder Requirement)又當如何作為 SWE.1 的輸入?
  • 利益相關者需求與SYS.2和SYS.3的產出,又當怎麼選擇? 如何作為證據呈現呢?

■ 參考解答:

由於本次的專案範圍是純軟體的開發,因此SYS.2及SYS.3並不會被納入到評鑑範圍。

該如何從SYS.2和SYS.3選擇需求? 該如何呈現其證據?

專案團隊已完成SYS.2與SYS.3的實作,並產出相關成果。當這些成果需要作為SWE.1的輸入時,應留意以下幾點:

首先,我們先來盤點SYS.2和SYS.3的相關成果。完成這兩個流程後,可能產出成果如下:

  • SYS.2 : 系統需求規格 (包含 功能性與非功能性需求、軟體需求、硬體需求、介面需求、等)
  • SYS.2 : 系統需求追溯表
  • SYS.2 : 系統需求規格審查報告
  • SYS.2 : 系統需求規格溝通證據
  • SYS.3 : 系統架構設計 (包含 動態及靜態架構圖,並歸納出 軟體規格 及 硬體規格)
  • SYS.3 : 系統介面規格 (包含 軟體之間的介面、硬體之間介面、軟硬體之間介面)
  • SYS.3 : 系統架構設計及系統介面追溯表
  • SYS.3 : 系統架構設計及系統介面審查報告
  • SYS.3 : 系統架構設計及系統介面溝通證據

由於本專案的範圍是「純軟體」,因此,真正可以被拿來當作產出物的僅鎖定在:

  • SYS.2 : 系統需求規格 (包含 功能與非功能性需求軟體需求硬體需求、介面需求、等)
  • SYS.3 : 系統架構設計 (包含 動態及靜態架構圖,並歸納出 軟體規格 及 硬體規格)
  • SYS.3 : 系統介面規格 (包含 軟體之間的介面、硬體之間介面、軟硬體之間介面)

確認產出物後,再來是要確認SYS.2的所有系統需求是否已完全分配到SYS.3:

如果是,則無需再考慮SYS.2的產出物。這是因為ASPICE標準中特別提到要避免不必要的重複追溯。在此情況下,只需關注SYS.3的相關產出物;具體來說,SWE.1可以直接使用:

  • SYS.3 : 系統架構設計 (軟體規格)
  • SYS.3 : 系統介面規格 (軟體之間的介面軟硬體之間介面)
如下圖所示,所有的系統需求均已被分配到SYS.3中(綠色表格)。

軟體需求可以從以下展出:
1. 系統架構中的軟體規格,即上方表格中分類為SW的系統元件;
2. 系統架構中的軟體相關介面規格,即下方表格中分類為SW Ext (軟體對外介面) 和 SW-HW (軟硬體之間介面)。

如果SYS.2的需求尚未完全分配到SYS.3,則應優先考慮SYS.3的產出物 (同上述),除此之外,也需要檢視SYS.2的產出物。SWE.1應該檢查:

  • SYS.3 : 系統架構設計 (軟體規格)
  • SYS.3 : 系統介面規格 (軟體之間的介面軟硬體之間介面)
  • SYS.2 : 系統需求規格 (未被分配到SYS.3分類為軟體需求)
如下圖所示,SYSREQ_010 到 SYSREQ_013 為未被分配到SYS.3的系統需求。

其中,SYSREQ_010及SYSREQ_013為分類為軟體的系統需求,這兩個需求可以直接被連結到軟體需求(橘色的表格)

總結上述,SWE.1軟體需求,可以從SYS.2和SYS.3中取得,在不同的情景中,要確保所有SYS.2和SYS.3的需求及規格都有被SWE.1考慮到。

利益相關者需求(Stakeholder Requirement)又當如何作為 SWE.1 的輸入?

ASPICE 標準 SWE.1中,有一段有趣的備註:

Note 3: In case of software-only development, the system requirements and the system architecture refer to a given operating environment. In that case, stakeholder requirements can be used as the basis for identifying the required functions and capabilities of the software.

備註3: 在純軟體開發的情況下,系統需求和系統架構是指"給定的操作環境" (意思是SYS.2和SYS.3所描述的範圍,包含軟體及其運作環境)。在這種情況下,利益相關者的需求可以用作識別軟體所需功能和能力的基礎。

專案團隊應特別確認。若利益相關者的需求已經在SYS.2與SYS.3的開發過程中被整理和統合,則這些需求不必直接作為SWE.1的輸入。

為了追溯利益相關者需求與SWE.1需求之間的關聯,可以透過SYS.2與SYS.3間接追溯來完成。具體來說:

  • SYS.2 : 系統需求追溯表
  • SYS.3 : 系統架構設計及系統介面追溯表

然而,如果專案團隊無法保證利益相關者需求與SYS.2及SYS.3之間的追溯是完整的,那麼SWE.1的軟體需求與利益相關者需求之間的追溯便是不完整的。在專案評鑑時,可能會因為追溯的不完整而扣分。這種扣分會影響到BP,進而影響到CL2等級的獲取。

利益相關者需求與SYS.2和SYS.3的產出,又當怎麼選擇? 如何作為證據呈現呢?

同前一題所述。

如果利益相關者的需求已經在SYS.2與SYS.3的開發過程中被整理和統合,則可以提供SYS.2和SYS.3的產出物與SWE.1之間的追溯即可。

如果無法保證利益相關者需求與SYS.2及SYS.3之間的追溯是完整的,則建議把SYS.2和SYS.3當作是參考,提供利益相關者需求與SWE.1之間的追溯。


■ 額外參考:


【ASPICE問題集】系列文章

是從我顧問、輔導及評鑑的經驗中彙集而來的問題。
這些問題經過精心挑選和整理,最後發表在我的網站上。
我也會分享我的觀點和解答,期待通過閱讀和腦力激盪,一起豐富我們的知識和見解 :)


感謝閱讀本文章!

如果你對文章內容有任何問題,請隨時與我交流聯絡。

歡迎訂閱我的文章,當有最新文章發布時,我將第一時間通知您 :)


WRITTEN BY
David Lin

現任國際標準輔導顧問及評鑑師;
在這個網站,我將分享一些產業新知、趨勢以及標準的解讀與看法。

歡迎與我交流:
Email:
linchewing@gmail.com
LinkedIn:
https://www.linkedin.com/in/linchew/