(v3.1)ASPICE標準: SYS.1 需求獲取(Requirements Elicitation)

本流程為ASPICE標準中的系統工程流程 — SYS.1 Requirements Elicitation 需求獲取，本流程被涵蓋在ASPICE VDA延伸範圍(VDA Extended Scope)中；本文章為「ASPICE v3.1標準解讀」系列文章，筆者將針對ASPICE標準條文提供解讀與說明，期許本篇文章能夠為讀者，解決標準導入時的疑惑。

---

流程目的(Process Purpose)

The purpose of the Requirements Elicitation Process is to gather, process, and track evolving stakeholder needs and requirements throughout the lifecycle of the product and/or service so as to establish a requirements baseline that serves as the basis for defining the needed work products.

需求獲取流程的目的在產品(和/或服務)的生命週期中收集、處理和追蹤不斷變化的利益相關方的需要與需求，並建立需求基準，作為定義所需工作產出的基礎。

額外說明 -- 什麼時候開始需求獲取？

常見的需求獲取的起點是客戶授予協議/合約的時候(請參見SPL供應流程概述)。

在客戶尚未授予合約時，公司方通常只能拿到徵求建議書(RFP)或報價邀請書(RFQ)，這兩份文件僅包含關鍵需求，研讀這兩份文件的目的是評估接案可行性及報價，且評估與報價的時限通常都非常短。

SYS.1需求獲取的目的在於釐清利益相關方的需求，並且要做到需求基準(備註: 需要將客戶提供的文件整理成詳細的需求清單)。在尚未取得客戶合約的情況下，通常公司方也不願意花費太多的資源整理未成案的專案。因此，通常不會把SYS.1考慮在報價及評估階段。

當客戶正式授予合約後，客戶通常會再進一步的提供更細部的需求。從此刻起，公司方會相對地安排資源(例: 專案團隊)來處理及釐清客戶的需求。

備註：筆者所提出的觀點僅為參考。建議讀者在導入SYS.1流程時，自行定義本流程的起始點。

---

流程結果(Process Outcome)

成功實作「需求獲取」，其相應的結果如下：
[Outcome 1]建立與利益相關方的持續溝通機制
[Outcome 2]定義並基準商定的利益相關方需求
[Outcome 3]建立一套變更機制，以便針對利益相關方的變動要求，進行評估並將利益相關方的變動需求納入基準需求
[Outcome 4]建立一套機制，以便持續監控利益相關方要求
[Outcome 5]建立一套機制，以便確保客戶可以容易地確認其要求狀態和處理情況
[Outcome 6]識別因技術或利益相關方要求變更而引發的變更，評估相關的風險並管理其帶來的影響

---

基礎實踐(Base Practices)

SYS.1.BP1: Obtain stakeholder requirements and requests.
SYS.1.BP1: 獲得利益相關方的需求與請求
[Outcome 1,4]

Obtain and define stakeholder requirements and requests through direct solicitation of customer input and through review of customer business proposals (where relevant), target operating and hardware environment, and other documents bearing on customer requirements.

通過直接徵求客戶意見、審查客戶業務提案(有相關的部分)、目標運作和硬體環境及其他符合客戶要求的文件來獲取和定義利益相關方的需求與請求。

NOTE 1: Requirements elicitation may involve the customer and the supplier.
NOTE 2: The agreed stakeholder requirements and evaluation of any change may be based on feasibility studies and/or cost and time analyzes.
NOTE 3: The information needed to keep traceability for each customer requirement has to be gathered and documented.

備註1: 需求獲取可能涉及客戶和供應商。
備註2: 商定的利益相關方需求和對任何變更的評估應基於可行性研究和/或成本或時間的分析。
備註3: 必須收集和記錄保持每個客戶需求可追溯性所需的資訊。

額外說明 -- 利益相關方的需求與請求

這裡所提到的「利益相關方」，一般泛指客戶、供應商、公司自身(包含事業處、部門)、國家法規與標準(例：資通安全法)、國際法規標準(例：UNECE R155、R156)等。

額外說明 -- 需求管理清單 

需求管理的清單的目的是將利益相關方所提出的需求進行整理與評估，這個產出物亦可符合(WP15-01 分析報告、WP 17-03 利益相關方需求)。請參考下圖，需求管理清單中的需求應與利益相關方所提供的原始文件保持可追溯性。

請參考下圖，標示(1)為客戶所提供的需求文件，在該文件中可能會提到額外的需求文件(e.g. 標示(3))；標示(2)為客戶需求以外的其他需求(即上一段備註所提到非客戶的其他需求)。

所有的需求均需要納入需求管理清單中，進行評估與控管。

(備註: 客戶所提出的需求，有可能與內部需求衝突。當所有的需求都被納管在需求管理清單中，需求評估過程即可標註有衝突的部分，並執行進一步的澄清)

額外說明 -- 需求管理清單的參考欄位

針對上圖中的需求管理清單，簡列參考欄位供讀者參考。
(備註：本文僅列出參考欄位，實際操作方式可由讀者再進一步定義)

---
ID: 標註該需求的編號

每個需求都有唯一的編號。

Source: 來源文件及其章節與段落

標記該需求的來源。針對不同的文件類型，可以有不同的標記方式，讀者可考慮：
- Word、PDF文件 (請參考圖中A)
- Excel文件 (請參考圖中B)
- PowerPoint文件 (請參考圖中C)
- Email
- 其他工具格式(e.g. DOORs)

STR: 客戶需求 (註: STR 為 STakeholder Requirement的縮寫)

將需求的內文條列陳述。這邊要特別注意的是，需求的細緻度；如果需求列的太粗，屆時系統需求的負責人將會需要再從來源文件中擷取內容。

Type: 需求種類

利益相關方所提供的文件中，可能存在技術性與非技術性需求。進行需求整理時，建議可以將需求簡單地分成技術性需求及非技術性需求。針對這兩種不同種類的需求，後續也應由不同的單位進一步的評估。

Category: 需求分類

此欄位的需求分類，是基於該需求所提到的內容而定，且為初步分類。這個分類的目的，是為了協助分派需求評估負責人。

Owner: 負責人

此欄位為負責評估需求的負責人，通常可根據上述的「需求分類欄位」而定。在獲取需求這個階段，專案會指派一群跨功能小組(Cross Function Team)，該小組由公司各部門的同仁所組成，根據不同需求的分類，應指派熟悉該領域的同仁來協助評估。

Status-Note: 狀態及註記

此欄位為公司自身的評估結果，常見的標註包含：Open、OK、Delete、TBC(To Be Clarify)、等。如果需求狀態屬於TBC，通常會再追加註記對需求的問題，以利於和利益相關方進一步的澄清。(備註：BP3: 同意需求，公司自身可以採用需求管理清單來同意需求，但針對不同的利益相關方，應有其他的管理方式)

—

SYS.1.BP2: Understand stakeholder expectations.
SYS.1.BP2: 了解利益相關方的期望
[Outcome 2]

Ensure that both supplier and customer understand each requirement in the same way.

確保供應商和客戶以同樣的方式了解彼此的需求。

NOTE 4: Reviewing the requirements and requests with the customer supports a better understanding of customer needs and expectations. Refer to the process SUP.4 Joint Review.

備註4: 與客戶一起審查需求與要求，以助於理解客戶的需要與期望。請參照SUP.4聯合審查流程。

額外說明 -- 如何確保利益相關方的期望被了解

這邊提到的了解指的是公司自身對利益相關方提供的需求的了解。一般建議的方式，是透過可行性評估表(考量範圍包含：技術、時間、費用、材料、適法性、等)。在SYS.1流程，需求會經常變動，因此可行性評估可能會重複進行許多次。

—

SYS.1.BP3: Agree on requirements.
SYS.1.BP3: 同意需求
[Outcome 2]

Obtain an explicit agreement from all relevant parties to work on these requirements.

從所有相關單位獲得明確同意，以便開展工作。

—

SYS.1.BP4: Establish stakeholder requirements baseline.
SYS.1.BP4: 建立利益相關方需求基準
[Outcome 2, 3]

Formalize the stakeholder’s requirements and establish them as a baseline for project use and monitoring against stakeholder needs. The supplier should determine the requirements not stated by the stakeholder but necessary for specified and intended use and include them in the baseline.

將利益相關方的需求正式化並建立基準，以便於專案使用及監控(對照利益相關方需求)。供應商可決定將不包含在利益相關方需求，但重要或潛在使用的相關需求納入需求清單中，並建立基準。

額外說明 -- 何時該建立基準？

針對需求獲取階段的需求建立基準，是為了進入下一個工程開發階段(e.g. SYS.2 系統需求分析)，然而，在此階段時，常常會遇到一個狀況，導致需求無法被基準。

常見的狀況包含：
- 客戶的需求經常變動
- 客戶尚未澄清有問題的需求
- 存在一些潛在的相關需求，但尚未獲得客戶的確認

現實中，上述的狀況可能影響需求基準；因為專案時程限制，專案團隊不可能等到所有的需求都底定，才開始進行其他的工程階段。

因此，筆者的建議如下：
1) 匡列已確定的需求
2) 匡列有關聯但待澄清的需求(先行假設)
3) 匡列潛在但未確認的需求
4) 排除無關聯但待澄清的需求

針對上述匡列的需求先進行基準，並依此進入工程開發；但是，特別針對(2), (3), (4)進行監控，並注意從這三點而來的需求變更。

—

SYS.1.BP5: Manage stakeholder requirements changes.
SYS.1.BP5: 管理利益相關方需求變更
[Outcome 3,6]

Manage all changes made to the stakeholder requirements against the stakeholder requirements baseline to ensure enhancements resulting from changing technology and stakeholder needs are identified and that those who are affected by the changes are able to assess the impact and risks and initiate appropriate change control and mitigation actions.

根據利益相關方需求基準，來管理所有利益相關方的需求變更，以確保下述成果：識別技術變更及利益相關方的需求變更、受變更影響的人員能夠評估影響與風險、並啟動適當的變更控制和緩解計畫。

NOTE 5: Requirements change may arise from different sources as for instance changing technology and stakeholder needs, legal constraints.
NOTE 6: An information management system may be needed to manage, store and reference any information gained and needed in defining agreed stakeholder requirements.

備註5: 需求變更可能會來自不同的來源。例如：技術變更、利益相關方需求、和法律約束。
備註6: 可以使用資訊管理系統來管理、儲存和參照在任何在商定的利益相關方需求過程所獲得和需要的資訊。

額外說明 -- 需求變更管理的時機

在標準條文中，需求變更時間僅限於需求基準之後，但實務上，SYS.1需求獲取階段，公司與利益相關方針對需求的確認會來回進行相當多次。需求來回確認的過程中，並不一定走到需求基準，但是這個過程中的變更仍需要被記錄與管理。

筆者建議的方法有兩種：
(1) 設立一個需求變更管理表單，蒐集及整理需求獲取階段的任何變更，並依此留下變更控制與緩解計畫的證據。
(2) 在此階段即導入SUP.10 變更請求管理，並留下相對應的證據。

上述兩個方法的採用，應根據公司專案的開案時間及人力配置。倘若在需求獲取階段

—

SYS.1.BP6: Establish customer-supplier query communication mechanism.
SYS.1.BP6: 建立供應商-客戶查詢溝通機制
[Outcome 5]

Provide means by which the customer can be aware of the status and disposition of their requirements changes and the supplier can have the ability to communicate necessary information, including data, in a customer-specified language and format.

提供一個機制讓客戶能了解變更請求的狀態和處置；提供一個機制讓供應商能夠以客戶指定的語言和格式傳達必要的資訊，包含數據資料。

NOTE 7: Any changes should be communicated to the customer before implementation in order that the impact, in terms of time, cost and functionality can be evaluated.
NOTE 8: This may include joint meetings with the customer or formal communication to review the status for their requirements and requests; Refer to the process SUP.4 Joint Review.
NOTE 9: The formats of the information communicated by the supplier may include computer-aided design data and electronic data exchange.

備註7: 實施任一變更，應先和客戶溝通，以便評估時間、成本和功能方面的影響。
備註8: 溝通機制包含與客戶的聯合會議或需求與要求的正式審查溝通。請參照SUP.4聯合審查。
備註9: 供應商傳達的資訊格式可包括電腦輔助設計數據和電子數據交換。

額外說明 -- 資料交換格式

在筆者顧問活動中，常見客戶提供工具輸出的格式(e.g. DOORs)，因此，如果公司本身也具備相同的工具(或可以轉檔的工具)，將可以更有助於資訊的交換。

---

工作產出(Output Work product)

08–19 風險管理計畫 [Outcome 6]
08-20 風險緩解計畫 [Outcome 6]
13–04 溝通記錄 [Outcome 1,4]
13–19 審查記錄 [Outcome 4,5]
13–21 變更控制記錄 [Outcome 3,4]
15–01 分析報告 [Outcome 2,3,6]
17–03 利益相關方需求 [Outcome 1,2]

---