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

Table of Contents

背景：純軟體專案，但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並不會被納入到評鑑範圍。

Q1：該如何從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考慮到。

Q2：利益相關者需求(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等級的獲取。

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

同前一題所述。

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

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

額外參考

(v4.0)ASPICE標準: SWE.1 軟體需求分析 (Software Requirement Analysis)
(v4.0)ASPICE標準: SYS.2 系統需求分析(System Requirements Analysis)
(v4.0)ASPICE標準: SYS.3 系統架構設計(System Architectural Design)

ASPICE 標準解讀