本文章為ASPICE案例篇 — SYS.1 需求獲取。本文將針對實際的案例進行探討說明，這些案例是筆者在顧問活動時遇到的狀況及相關做法，期許本篇文章能夠為讀者，解決標準導入時的疑惑。另外，也請讀者搭配參考「ASPICE v3.1標準解讀」系列文章中的「SYS.1 需求獲取標準解讀原文」。
SYS.1 基礎實踐(快速整理) SYS.1.BP1: 獲得利益相關方的需求與請求 SYS.1.BP2: 了解利益相關方的期望 SYS.1.BP3: 同意需求 SYS.1.BP4: 建立利益相關方需求基準 SYS.1.BP5: 管理利益相關方需求變更 SYS.1.BP6: 建立供應商-客戶查詢溝通機制 [詳細說明: 請參考 SYS.1 需求獲取 標準條文說明]
案例：需求獲取後的需求管理
[前情提要] 客戶授予專案後，專案經理快速組織專案成員，正式進入需求獲取流程。專案經理與客戶建立溝通機制，並從客戶窗口獲取需求。
[情境1] 獲取需求、了解期望、回饋需求問題
![[SYS.1:情境1] 獲取需求、了解期望、回饋需求問題](https://linchew.com/wp-content/uploads/2021/05/SYS.1_Scenario-1_Obtain-stakeholder-requirement-and-ask-for-feedback-1024x555.png "[SYS.1:情境1] 獲取需求、了解期望、回饋需求問題")
[步驟1] 客戶將需求第一版彙整成一份文件，透過溝通機制(BP6定義)將需求傳送給專案團隊。專案團隊收到需求後，即透過需求管理清單將客戶需求進行整理，並將客戶需求根據特性進行分類，安排各分類專業工程人員進行需求了解。
各分類專業工程人員將已了解，且沒問題的需求，註記為[OK]，針對有意見的需求，則註記[TBC]，並留下問題。如上圖所示，[ID:1、3、4]註記為[OK]；[ID:2、5、6]則註記為[TBC]且留有意見。
額外說明 -- 需求管理清單的參考格式 讀者請搭配參考「SYS.1 需求獲取 - BP1的額外說明 -- 需求管理清單的參考欄位」；註記為[TBC]，表示為「To Be Clarify」
[步驟2] 第一次需求了解完畢後(需求管理清單的版本為v1.0)，這份需求管理清單則透過溝通機制，由專案經理回饋給客戶，要求進一步的澄清。
—
[情境2] 根據回饋修改需求並進行需求基準
![[SYS.1:情境2] 根據回饋修改需求並進行需求基準](https://linchew.com/wp-content/uploads/2021/05/SYS.1_Scenario-2_Modify-and-baseline-requirement-1024x555.png "[SYS.1:情境2] 根據回饋修正需求並進行需求基準")
[步驟3] 客戶澄清後，透過溝通機制提供回饋給專案團隊。客戶的回饋可能導致需求的調整，需求的調整可能涉及新增、修改或刪除。
為了有效管理不同版本的需求，「需求管理清單」應進行版本管理，客戶的回饋也透過「變動表格」進行管理紀錄。如上圖所示，變動表格紀錄此次客戶回饋引起的需求調整，分別是[ID: 2、5、6]；根據記錄在「變動表格」的調整；如上圖所示，需求管理清單中的[ID:2]需求，因客戶回饋而刪除；[ID:5、6]則因客戶回饋而進行修改。(此時，需求管理清單的版本為v2.0)
因客戶回饋而修改的需求，應由專業工程人員再次進行需求了解(本次沒有發現新的問題)。
[步驟4] 需求了解後，專案經理透過溝通機制，將結果傳達給客戶。
[步驟5] 客戶回覆確認後，專案經理始可針對需求管理清單執行基準。(本案例中，被基準的需求管理清單版本為v2.0)
—
[情境3] 由客戶引起的需求變更
[前情提要] 情境1、2，來自客戶端的需求已被了解且已基準；真實專案中，客戶仍可能因為不同的原因，而變更需求。當收到客戶端的需求變更，該如何因應管理呢？
![[SYS.1:情境3] 由客戶引起的需求變更](https://linchew.com/wp-content/uploads/2021/05/SYS.1_Scenario-3_Requirement-change-from-stakeholder-1024x555.png "[SYS.1:情境3] 由客戶引起的需求變更")
[步驟6] 因為客戶內部的討論，決定調整之前提出的需求規格。爾後，專案團隊收到客戶的需求改版通知，並收到一份名為v2的需求規格。
由於先前的需求管理清單已經被基準，當收到客戶需求變更時，專案團隊應識別影響範圍，並找出兩份不同版本需求的相異之處。
額外說明 -- 如何判別不同版本的差異 通常來自客戶的文件，會將版本調整的差異紀錄在文件的「變更履歷」章節中。但是，客戶不一定會將所有的差異鉅細靡遺的紀錄，專案團隊仍然需要透過人力(或工具)來協助判別差異。
經專案團隊比對，兩份需求的相異點被識別且記錄在「變動表格」中。在「變動表格」中，不同版本的需求資訊亦被詳加紀錄，以利後續追溯與管理。如上圖所示，[ID:1(v2)、4(v2)]為比對後的版本差異，被記錄在「變動表格」中。
因應客戶需求變更，需求管理清單也應進行調整。如上圖所示，[ID:1、4]需求根據記錄在變動表格的相異點進行需求變更。需求變更完畢後，專業工程人員再次進行需求了解。這一次，工程人員只針對[ID:4]提出問題。(再次變更後，需求管理清單的版本為v3.0)
[步驟7] 專案經理將工程人員的問題回饋給客戶，並要求進一步澄清。
—
[情境4] 再次修改需求並進行需求基準
![[SYS.1:情境4] 再次修改需求並進行需求基準](https://linchew.com/wp-content/uploads/2021/05/SYS.1_Scenario-4_change-control-and-mitigation-actions-1024x555.png "[SYS.1:情境4] 再次修改需求並進行需求基準")
[步驟8] 專案團隊收到客戶澄清後，透過「變動表格」紀錄客戶回饋引起的變動，如上圖所示，[ID: 4(v2)]需求變動被記錄在「變動表格」中。
後續，按照「變動表格」的紀錄，需求管理清單修改了[ID: 4]的需求描述。經專業工程人員了解後，已經沒有後續的問題。(此時，需求管理清單的版本為v4.0)
[步驟9] 專案經理透過溝通機制，將了解的結果傳達給客戶。
[步驟10] 經客戶回覆確認後，專案經理再次針對需求管理清單進行基準。(在本情境中，被基準的需求管理清單版本為v4.0)
—
額外說明 -- 本案例中需求管理清單的版本控管方式 本案例中，四個情境結束後，共產生四個版本的需求管理清單，分別是： [v1.0] 收到客戶需求，第一次進行需求了解 (存在問題) [v2.0] 客戶回饋後，經確認後沒問題，進行第一次基準 [v3.0] 收到客戶需求變更，第一次進行需求了解 (存在問題) [v4.0] 客戶回饋後，經確認後沒問題，進行第二次基準 真實狀況下，與客戶來回的回饋次數，可能非常的頻繁。本案例為了精簡，單純採用「個位數」進版的版本管理，建議讀者可以根據貴司的真實情況，做不同的版本定義。
