SYS.1 Requirements Elicitation 需求獲取
ASPICE 標準解讀
目錄: Automotive SPICE(ASPICE)標準解讀 / 系統工程流程SYS.1 系統需求獲取
SYS.2 系統需求分析
SYS.3 系統架構設計
SYS.4 系統整合與整合測試
SYS.5 系統合格測試
流程目的(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.
需求獲取流程的目的在產品(和/或服務)的生命週期中收集、處理和追蹤不斷變化的利益相關方的需要與需求，並建立需求基準，作為定義所需工作產出的基礎。
流程結果(Process Outcome)
成功實作需求獲取流程，其相應的結果如下：
1) [Outcome 1]持續與利益相關方的溝通機制被建立;
2) [Outcome 2]商定的利益相關方需求被定義並建立基準;
3) [Outcome 3]建立一套變更機制，該機制要針對利益相關方的變動要求進行評估並將利益相關方的變動需求納入基準需求;
4) [Outcome 4]一套持續監控利益相關方要求的機制被建立;
5) [Outcome 5]一套確保客戶能夠容易確認他們的要求狀態和處理情況的機制被建立;
6) [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: 為每個客戶需求保持可追溯性所需的資訊必須被收集和記錄。
額外說明：利益相關方的需求與請求，除了泛指客戶提供的需求文件之外，通常也包含業界標準(如：IEEE標準)、國家法律要求(如：GDPR)、公司事業處要求、市場面競爭者標竿、供應商標準等。一般常見狀況，客戶發信來的需求變更也算是利益相關方的請求。各種需求文件，需要被整理歸檔，並且作為開案的參考文件。(常見的作法是透過公司的外來文件管理辦法，將這些外來文件納管)。利益相關方的需求應該要被整理成公司內部專屬的需求管理清單，該清單與上述利益相關方的需求應該保持可追溯性，且針對利益相關方的相關文件變更亦需要管理。
—
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.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.
將利益相關方的需求正式化並建立基準，並將其作為專案使用，及用於針對利益相關方需求監控。供應商可決定將不包含在利益相關方需求，但重要或潛在使用的相關需求納入需求清單中，並建立基準。
額外說明：初在BP4會所有同意的利益相關方需求納入需求管理清單中；但是也會額外考量跟本專案有關的需求(跟系統有關的重要需求，或系統潛在功能或運用)，這些需求也會納入需求管理清單中。最終，針對上述的所有需求(需求管理清單)建立基準。
—
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.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: 供應商傳達的資訊格式可包括電腦輔助設計數據和電子數據交換。
額外說明：客戶的需求，包含一開始提供的需求與後續的變更需求；可以使用工具來與客戶溝通這些需求的理解與接受狀態。如果沒有使用相關的工具，一般也可以透過Excel檔案中的Q-A記錄來追蹤記錄所有需求的狀態，透過Email來回溝通也是一種簡易的溝通機制。部分客戶會指定特定的資料格式，如：IBM 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]
感謝閱讀本文章！
如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.
