背景：純軟體專案，但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)
