SYS.2 System Requirements Analysis系統需求分析

(更新2020/2/20) ASPICE 標準解讀

目錄: Automotive SPICE(ASPICE)標準解讀 / 系統工程流程
SYS.1 系統需求獲取
SYS.2 系統需求分析
SYS.3 系統架構設計
SYS.4 系統整合與整合測試
SYS.5 系統合格測試

流程目的(Process Purpose)

The purpose of the System Requirements Analysis Process is to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system.

系统需求分析流程的目的是將已定義(確立)的利益相關方需求轉換成系統需求，作為設計系統的引導。

開始閱讀前：
在ASPICE 3.1標準中，替別把「系統工程」與「軟體工程」分別獨立，這裡面牽涉到插件的概念，相關內容請參考「ASPICE 關鍵觀念１: 插件的概念」，建議在閱讀本流程前，先閱讀相關內容。

流程結果(Process Outcome)

成功實作系統需求分析流程，其相應的結果如下：
1) [Outcome 1]一系列已定義的系統需求被建立
2) [Outcome 2]系統需求被分類，並分析其正確性及可驗證性;
3) [Outcome 3]系統需求與操作環境的影響已被分析
4) [Outcome 4]系統需求的實作順序被定義
5) [Outcome 5]系統需求根據需要被更新的(保持最新的狀態)
6) [Outcome 6]利益相關方需求與系統需求的一致性與雙向可追溯性被建立
7) [Outcome 7]評估系統需求的成本、時程及技術等影響
8) [Outcome 8]系統需求已商定，並向所有受影響的成員溝通

基礎實踐(Base Practices)

SYS.2.BP1: Specify system requirements.
SYS.2.BP1: 具體描述系統需求
[Outcome 1,5,7]

Use the stakeholder requirements and changes to the stakeholder requirements to identify the required functions and capabilities of the system. Specify functional and non-functional system requirements in a system requirements specification.

運用利益相關方需求及其變更請求去識別系統所需要的功能及性能；在系統需求規格書中具體描述功能性及非功能性。

NOTE 1: Application parameter influencing functions and capabilities are part of the system requirements.
NOTE 2: For changes to the stakeholder’s requirements SUP. 10 applies.

備註1:影響功能及性能的應用參數是系統需求的一部分；
備註2:如果利益相關方需求有任何變更，請應用SUP.10

額外說明：
利益相關方(stakeholder)一般可以是客戶、供應商、公司高層、各部門等。
系統需求通常會包含：
1) 機構、硬體或軟體的功能；或者包含機構、硬體及軟體的組合功能。
2) 影響系統作動(功能)的參數
3) 處理來自其他系統的訊號
4) 非功能性需求

SYS.2.BP2: Structure system requirements.
SYS.2.BP2: 結構化系統需求
[Outcome 2,4]

Structure the system requirements in the system requirements specification by e.g.
• grouping to project relevant clusters,
• sorting in a logical order for the project,
• categorizing based on relevant criteria for the project,
• prioritizing according to stakeholder needs

以結構化的方式將系統需求呈現在系統需求規格書中，請參考以下範例
• 分組到專案相關集群(clusters)
• 按照專案邏輯順序排序
• 基於專案相關準則分類
• 根據利益相關方要求排定優先順序

NOTE 3: Prioritizing typically includes the assignment of functional content to planned releases. Refer to SPL.2.BP1.

備註3: 排定優先順序通常會包含產品發佈計畫中指定的功能內容。請參照SPL.2.BP1

額外說明：
通常在產品發佈計畫書中會定義該專案的發佈次數與時機，例如：
產品的總功能數共計有10個；發佈時機共計有三個：A Sample, B Sample, C Sample。
A Sample: 
功能1~5
B Sample: 
功能1~8
C Sample:
功能1~10(全部)
在排定系統需求的優先順序時，可以參考發佈計畫書的說明。

SYS.2.BP3: Analyze system requirements.
SYS.2.BP3: 分析系統需求
[Outcome 1,2,7]

Analyze the specified system requirements including their interdependencies to ensure correctness, technical feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the technical impact.

分析具體描述的系統需求(BP.1的產出)，包含需求間的相互依存關係以確保正確性、技術可行性及可驗證性，並且支援風險識別。分析對於成本、時程及技術的影響。

NOTE 4: The analysis of impact on cost and schedule supports the adjustment of project estimates. Refer to MAN.3.BP5.

備註4: 成本及時程的影響分析可以支持專案估算的調整。請參照MAN.3.BP5

額外說明：
利益相關方需求可能存在不同的矛盾，系統需求分析的目的便是確保這些需求都能夠被實作，假設存在矛盾的問題，企業可與利益相關方溝通並修正需求的問題。
如何分析系統需求，通常會建立一個系統需求分析查檢表；並將該查檢表提供給所有的系統需求分析人員來進行分析，並透過會議整合大家的分析結果。倘若系統需求存在問題，則需要反覆修改到沒有問題。

SYS.2.BP4: Analyze the impact on the operating environment.
SYS.2.BP4: 分析對操作環境的影響
[Outcome 3,7]

Identify the interfaces between the specified system and other elements of the operating environment. Analyze the impact that the system requirements will have on these interfaces and the operating environment.

識別具體系統和其他操作環境要素的介面。分析系統需求在這些介面與操作環境的影響。

額外說明：
分析操作環境的影響，一般來說可以參考幾個面向：
1) 介面 (interface)
   -- 安裝 (Mounting)
   -- 能源流量 (機械、液、氣動、電動、溫度、等)
   -- 材料用量 (汽油、油液、水、等)
   -- 訊號及訊號品質
   -- 噪音 (Noise)
   -- 震動 (Vibration)
   -- 不平順性 (Harshness)
2) 環境 (Environment)
   -- 溫度
   -- 濕度
   -- 排氣 (Exhaust)
   -- EMC
   -- 輻射 (Radiation)
3) 性能 (Performance)
   -- 介面反應時間 (機械、液、氣動、電動、等)
   -- 子系統反應時間 (微控制器處理時間)
4) 資源 (Resources)
   -- 能源流量(Energy flow)
   -- 材料用量(Material flow)
   -- 記憶體使用量(RAM, ROM, EEPROM/DataFlash)

SYS.2.BP5: Develop verification criteria.
SYS.2.BP5: 制定驗證準則
[Outcome 2,7]

Develop the verification criteria for each system requirement that define the qualitative and quantitative measures for the verification of a requirement.

針對每個系統需求制定定性與定量的驗證準則。

NOTE 5: Verification criteria demonstrate that a requirement can be verified within agreed constraints and is typically used as the input for the development of the system test cases or other verification measures that ensures compliance with the system requirements.
NOTE 6: Verification which cannot be covered by testing is covered by SUP.2.

備註5: 驗證準則說明一個系統可以在一個商定的限制下被驗證。驗證準則通常是 開發系統測試案例 或 為了確保系統一致性的其他驗證量測 的輸入參考內容。(換言之，開發系統測試案例需要參照系統需求驗證準則；為了確保系統一致性要設計驗證測量時，也需要參照系統需求驗證準則。)
備註6: 無法透過測試來進行驗證的系統需求將透過SUP.2來執行驗證。

額外說明：
有些系統需求的驗證準則是沒辦法透過測試來達成，例如：
需求：在樣品上必須貼上OOOO的貼紙。
驗證方法：透過審查(Review)的方式來達成。

SYS.2.BP6: Establish bidirectional traceability.
SYS.2.BP6: 建立雙向可追溯性
[Outcome 6]

Establish bidirectional traceability between stakeholder requirements and system requirements.

建立利益相關方需求與系統需求的雙向追溯性。

NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.

備註7: 雙向追溯性支援覆蓋性、一致性和影響分析。

額外說明：
在這裡提到的覆蓋性，指的是「利益相關方需求」與「系統需求」之間對應的覆蓋性。通常亞洲的廠商僅被要求VDA Scope(16個流程)，而SYS.1是被排除在VDA Scope之外的；在這種情況下利益相關方需求通常很難被管理。建議要整理一份「利益相關方需求清單」，在這份清單中明確的標明所有的需求與來源文件的關係；系統需求再以這份文件為基礎發展追溯性。
另外一題，所有的來源文件需要被識別，而且透過SUP.8(組態管理)來進行管制。

SYS.2.BP7: Ensure consistency.
SYS.2.BP7: 確保一致性
[Outcome 6]

Ensure consistency between stakeholder requirements and system requirements.

確保利益相關方需求與系統需求的一致性。

NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

備註8: 可以透過利益相關方需求與系統需求的雙向追溯來比對文件之間的一致性；可以透過審查記錄來展示一致性的確保。

SYS.2.BP8: Communicate agreed system requirements.
SYS.2.BP8: 溝通商定的系統需求
[Outcome 8]

Communicate the agreed system requirements and updates to system requirements to all relevant parties.

溝通商定的系統需求及其更新給所有相關的成員。

額外說明：
所有相關的成員一般指的是專案成員；如果需要一般也會傳達給部門、公司管理階層；在我輔導的公司中，也有客戶要求企業將系統需求規格書透過客戶指定的文件格式提供，在這種情境下，客戶也是需要被溝通的成員。
為了因應不同專案、不同成員的特性，在專案之初，這些溝通將被定義在「溝通計畫書」中。

工作產出(Output Work product)

13-04 溝通記錄 [Outcome 8]
13-21 變更控制記錄 [Outcome 1]
13-19 審查記錄 [Outcome 6]
13-22 追溯記錄 [Outcome 6]
15-01 分析報告 [Outcome 2,3,4,7]
17-08 介面需求規格書 [Outcome 1,3]
17–12 系統需求規格書 [Outcome 1,5]
17–50 驗證準則 [Outcome 2]

* ASPICE網站
* ASPICE 3.1標準

感謝閱讀本文章！

如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.

mailto: linchewing@gmail.com