(更新2023/12/27) 本流程為ASPICE v4.0標準中的系統工程流程 — SYS.1 Requirements Elicitation 需求獲取；本文章為「ASPICE v4.0 標準解讀」系列文章，筆者將針對ASPICE標準條文提供解讀與說明，期許本篇文章能夠為讀者，解決標準導入時的疑惑。
流程目的(Process Purpose)
The purpose is to gather, analyze, and track evolving stakeholder needs and requirements throughout the lifecycle of the product and/or service to establish a set of agreed requirements.
本流程的目的是為了在產品和/或服務的生命週期中收集、分析和追蹤不斷變化的利益相關者需求和要求，以建立一組共識需求。
流程結果(Process Outcome)
成功實作本流程，其相應的結果如下：[Outcome 1] 建立與利益相關者的持續溝通[Outcome 2] 理解利益相關者的期望並確定需求，達成共識[Outcome 3] 分析來自利益相關者需求變更的需求變更，以便進行相關風險評估和影響管理[Outcome 4] 確保所有受影響方都能確定利害相關者的需求狀態
基礎實踐(Base Practices)
SYS.1.BP1: Obtain stakeholder expectations and requests.
SYS.1.BP1: 獲取利益相關者的期望和要求
Obtain and define stakeholder expectations and requests through direct solicitation of stakeholder input, and through review of stakeholder business proposals (where relevant) and other documents containing inputs to stakeholder requirements, and consideration of the target operating and hardware environment.
通過直接徵求利益相關者的意見，並通過審查利益相關者的商務提案（如果適用）以及其他包含利益相關者需求的輸入文件，並考慮目標運作和硬體環境，獲取並定義利益相關者的期望和要求。
NOTE 1: Documenting the stakeholder, or the source of a stakeholder requirement, supports stakeholder requirements agreement and change analysis (see BP2 and BP3).
備註1: 記錄利益相關者或利益相關者需求的來源，有助於支持利益相關者需求的協議和變更分析（請參見BP2和BP3）
額外說明 - 利益相關者需求清單 通常，需求獲取工作都在專案的早期階段。筆者建議透過一份需求管理清單來整合相關利益相關者的需求，並明確地列出需求的來源和內容。 如果利益相關者提出的需求不是以英文呈現，也可以在需求管理清單中記錄原始內容和翻譯後的版本，以便雙方更好地理解和管理這些需求。 如果公司內部已導入工具，則可以透過工具跟利益相關者介接，而不用透過額外的「需求管理清單」來增添管理的複雜度。
額外說明 -- 利益相關者包含哪些人？ 大多數的專案，主要的利益相關者為客戶。然而，由於專案開發牽涉多方參與者，因此常見的利益相關者還包括以下： 1. 供應商： 在車用組件的開發專案，供應商通常指的是微控制器（MCU）供應商；在車用IC的開發專案，則通常可以是IP的供應商。 2. 公司內部其他共同參與開發之部門： 這種情況通常發生於某些部門導入ASPICE，而其他部門則尚未採用。在這種情況下，其他部門的需求和意見也應視為利益相關者的需求。 3. 公司內部舊產品/組件之開發部門/人員： 如果現有的專案使用到舊產品/組件時，舊產品/組件的相關要求可以成為本專案的利益相關者需求。 4. 其他外部合作單位： 這包括共同合作開發的合作夥伴等。
—
SYS.1.BP2: Agree on requirements.
SYS.1.BP2: 同意需求
Formalize the stakeholder’s expectations and requests into requirements and obtain an explicit agreement from all affected parties to work on these requirements.
Formalize the stakeholder’s expectations and requests into requirements. Reach a common understanding of the set of stakeholder requirements among affected parties by obtaining an explicit agreement from all affected parties.
將利益相關者的期望和要求制定成需求。透過取得所有受影響方的明確同意，促成各影響方間對於利益相關者需求的共同理解。
NOTE 2: Examples of affected parties are customers, suppliers, design partners, joint venture partners, or outsourcing parties.
NOTE 3: The agreed stakeholder requirements may be based on feasibility studies and/or cost and schedule impact analysis.
備註2: 舉例來說，受影響方，包括客戶、供應商、設計合作夥伴、合資夥伴或外包供應商。
備註3: 所同意的利益相關者需求可能基於可行性研究和/或成本和進度影響分析。
額外說明 - SYS.1 BP3同意需求 與 MAN.3 BP3評估專案的可行性 請參照下圖。在需求獲取階段，為了與利益相關者達成共識，通常專案團隊可以透過可行性研究（或其他分析方法）來確認需求的可行性，並最終同意需求。 然而，在需求獲取階段，利益相關者的需求通常不會一次性全部提出，因此局部需求評估變成常態，這也導致可行性研究的次數可能會多次發生，如下圖所示。在星星(1)的時間點，專案團隊從利益相關者那裡獲得需求，並在SYS.1階段的可行性研究中共進行了三次評估(分別是1號、2號及3號評估點)： * 第一次的評估僅同意了10%的需求 * 第二次的評估同意了25%的需求 * 第三次的評估則同意了70%的需求 當大多數需求都已確認時，在星星(2)的時間點，專案團隊開始啟動專案管理流程，進入專案管理的初始階段。專案經理對已確認的70%需求進行評估（評估包括時間、資源等，即第4號評估點）。評估通過後，隨即開始後續的專案規劃、專案執行和專案監控。 在專案進行時，利益相關者也會在專案開發過程中逐步澄清和確認其需求。在第5號評估點，專案團隊再次對利益相關者的需求進行評估，此時80%的需求已被同意。 當新提出的需求評估完成且同意時，在星星(3)的時間點，這些額外確認的10%需求將形同專案的需求變更，觸發變更管理流程；變更管理流程要求針對變更進行分析（即第6號評估點），待分析完成並經變更控制委員會（CCB）批准後，變更將納入專案執行中（星星4的時間點）。
額外說明 - SYS.1與MAN.3共同可行性評估 為了簡化流程執行的複雜度，當然也可以選擇較簡單的方法來評估在初始階段獲取的需求。這種方法稱為「共同可行性評估」，請參考下圖。這種做法的優勢在於，在專案的初始階段和需求獲取階段同時進行，同時進行需求的可行性分析(分別是1號、2號及3號評估點)，最終可以更簡單地完成初始階段的可行性評估。 然後，在專案執行後，變更處理方式與上圖大同小異。
—
SYS.1.BP3: Analyze stakeholder requirements changes.
SYS.1.BP3: 分析利益相關者需求變更
Analyze and manage all changes made to the stakeholder requirements against the agreed stakeholder requirements. Assess the impact and risks and initiate appropriate change control and mitigation actions.
針對所有已同意的利益相關者需求所做的變更進行分析。評估影響和風險，並啟動適當的變更控制和緩解措施。
NOTE 4: Requirements changes may arise from different sources as for instance changing technology, stakeholder needs, or legal constraints.
NOTE 5: Refer to SUP.10 Change Request Management, if required.
備註4: 需求變更可能來自不同的來源，例如技術變化、利益相關者需求或法律限制。
備註5: 如有需要，請參閱SUP.10 變更請求管理。
額外說明 -- 變更的2種處理方式 關於變更的處理方式，筆者提出兩種處理方式，請參考下圖。 第一種處理方式 (圖片上方): SYS.1的變更與專案的變更分開處理 簡而言之，SYS.1具備獨立的變更管理機制，專注於控管涉及利益相關者需求的變動，每次變更後，SYS.1保留最新版本的利益相關者需求，並在變更後（如上圖1號評估點）啟動專案管理中的變更請求程序（如上圖星星2的時間點）。變更請求的執行與否將根據變更請求分析結果和CCB的決策來決定。 * 優點: 由利益相關者提出的需求變更可能數量龐大，因此將SYS.1的需求處理和專案層級的變更請求分開處理，有助於等到SYS.1的需求批次處理完成後再提出專案層級的變更請求，從而大幅減輕變更請求的處理工作量。其次，專案層級的變更請求經CCB決定不在本次產品發布階段實施時，可輕易管理後續流程。 * 缺點: 專案團隊有可能在變更處理時感到混淆。 --- 第二種處理方式 (圖片下方): SYS.1的變更與專案的變更合併處理 為了實現統一的變更管理，第二種方式將SYS.1的變更管理與專案層級的變更管理合併處理；當有利益相關者需求變更時，立即觸發變更請求程序（如下圖星星2的時間點），變更請求經過分析後，交由CCB決定。若CCB同意，相關需求變更可在SYS.1流程中先行評估且同意後，一併納入專案實施；反之，若CCB不同意，相關需求變更暫不處理，等待適當時機再進行處理。 值得注意的是，若利益相關者要求先對需求變更的部分進行同意和回覆，需額外規劃變更請求的處理方式。在這種特殊情況下，變更請求需經CCB核准執行（如下圖1號評估點），待利益相關者需求評估且同意後，未必要立即導入專案實施（如下圖星星3的時間點），這種特殊的變更狀態需要另行管理。 * 優點: 專案執行後，所有變更統一由SUP.10管理，可幫助專案團隊更清晰地處理變更。 * 缺點: 來自利益相關者需求的變更可能數量龐大，因此在專案期間可能會有大量的變更請求；另外，針對特殊情況，變更請求需要CCB同意後，先進行SYS.1流程的評估和同意，但未必要立即導入專案實施，需要特別管理。
—
SYS.1.BP4: Communicate requirements status.
SYS.1.BP4: 溝通需求狀態
Ensure all affected parties can be aware of the status and disposition of their requirements including changes and can communicate necessary information and data.
確保所有受影響方能夠了解其需求的狀態和處理情況 (包括變更)，並能夠傳達必要的資訊和資料。
輸出資訊項目(Output Information Item)
15–51 分析結果13–52 溝通證據17–00 需求17–54 需求特性
