ASPICE 標準解讀

(v4.0)ASPICE標準: SYS.2 系統需求分析(System Requirements Analysis)

本文章源自於「Automotive SPICE v3.991」,內容與「Automotive SPICE v4.0」可能會有出入;屆時筆者會來修正這之中的差異

本流程為ASPICE v4.0標準中的系統工程流程 — SYS.2 System Requirements Analysis 系統需求分析;本文章為「ASPICE v4.0 標準解讀」系列文章,筆者將針對ASPICE標準條文提供解讀與說明,期許本篇文章能夠為讀者,解決標準導入時的疑惑。

目錄 > 系統工程流程

  1. (v4.0) SYS.1: 需求獲取
  2. (v4.0) SYS.2: 系統需求分析
  3. (v4.0) SYS.3: 系統架構設
  4. (v4.0) SYS.4: 系統整合及整合測試
  5. (v4.0) SYS.5: 系統合格測試

流程目的(Process Purpose)

The purpose is to establish a structured and analyzed set of system requirements consistent with the stakeholder requirements.

本流程的目的是建立一個已被結構化且已分析的一系列系統需求,以符合利益相關者的需求。


流程結果(Process Outcome)

成功實作本流程,其相應的結果如下:
[Outcome 1] 系統需求已被明確指定
[Outcome 2] 系統需求已被結構化並按優先順序排列
[Outcome 3] 系統需求已被分析以確保正確性和技術可行性
[Outcome 4] 系統需求對操作環境的影響已被分析


基礎實踐(Base Practices)

SYS.2.BP1: Specify system requirements.
SYS.2.BP1: 具體描述系統需求

Use the stakeholder requirements to identify and document the functional and non-functional requirements for the system according to defined characteristics for requirements.

根據利益相關者需求,依據已定義的需求特性,識別並記錄系統的功能和非功能需求。

NOTE 1: Characteristics of requirements are defined in standards such as ISO IEEE 29148, ISO 26262-8:2018, or the INCOSE Guide For Writing Requirements.
NOTE 2: Examples for defined characteristics of requirements shared by technical standards are verifiability (i.e. verification criteria being inherent in the requirements formulation), unambiguity/comprehensibility, freedom from design and implementation, and not contradicting any other requirement.

備註1: 在相關標準中有定義「需求特性」,例如: ISO IEEE 29148、ISO 26262-8:2018或INCOSE編寫需求指南。
備註2: 商定的利益相關方需求和對任何變更的評估應基於可行性研究和/或成本或時間的分析。

額外說明 -- ISO IEEE 29148 針對需求特性的描述

針對所撰寫的需求,其中的「特定關鍵字」和「術語」上達成共識是很重要的,這些關鍵字和術語能夠表明需求的存在。常見的方法是明確規定以下:

1. 需求是強制性的規定,使用「Shall」
2. 非需求,例如描述性文字,使用「一般Be動詞」,例如: are, is 和 was;最好避免使用「Must」這個術語,以免被誤解為需求
3. 使用「Will」來表達事實陳述、未來性陳述或目的聲明是非強制性、非約束性的規定;也可以用來確定使用的上下文或限制。
4. 使用「Should」來表達偏好或目標是期望的、非強制性、非約束性的規定
5. 使用「May」來表達建議或容許是非強制性、非約束性的規定
6. 使用肯定陳述,避免使用否定需求,如「Shall not」
7. 使用主動語態:避免使用被動語態,例如「It is required that」
8. 避免使用「Shall be able to」的術語
額外說明 -- ISO IEEE 29148 針對需求撰寫格式的要求

所有與需求工程相關的術語應該被正式地定義,並且在系統的所有需求中一致地應用。請參考以下需求範例圖片。

SYS.2.BP2: Structure system requirements.
SYS.2.BP2: 結構化系統需求

Structure and prioritize the system requirements.

針對系統需求進行結構化及排定優先順序。

NOTE 3: Examples for structuring criteria can be grouping (e.g. by functionality) or product variants identification.
NOTE 4: Prioritization can be done according to project or stakeholder needs via e.g. definition of release scopes. Refer to SPL.2.BP1

備註3: 舉例來說,結構化的準則可以是分組(例如: 功能)或產品差異的識別。
備註4: 根據專案或利益相關者的需求,可以通過定義產品發布範圍等方式進行優先排序。請參考SPL.2.BP1。

額外說明 -- v3.1版的結構化」系統需求

1. 將相關的群組分類為一個專案的群組
2. 按照邏輯順序進行排序
3. 根據專案的相關標準進行分類
4. 根據利益相關者的需求進行優先排序
額外說明 -- 需求分類的常見案例

請參考下圖。
額外說明 -- 排定優先順序的2種定義

定義1: 根據產品發布時機

在產品開發過程中,如果有多個樣品釋出的時機,例如:A Sample, B Sample, C Sample。則根據不同樣品釋出時應涵蓋的系統需求,來針對系統需求排定順序。

定義2: 根據該需求的實作邏輯

系統需求之間,可能會因為功能的實現存在先後順序,亦可根據此排序系統需求。

SYS.2.BP3: Analyze system requirements.
SYS.2.BP3: 分析系統需求

Analyze the specified system requirements including their interdependencies to ensure correctness, technical feasibility, and to support project management regarding project estimates.

分析已明定之系統需求,包括它們之間的相互依賴性,以確保正確性、技術可行性,並支持專案管理,以便進行專案估算。

NOTE 5: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.
NOTE 6: Technical feasibility can be evaluated based on e.g. platform or product line, or by means of prototype development or product demonstrators.

備註5: 有關專案可行性,請參見MAN.3.BP3;有關專案預估,請參見MAN.3.BP5
備註6: 可以根據平台或產品線進行技術可行性評估,也可以通過原型開發或產品展示進行評估 

SYS.2.BP4: Analyze the impact on the system context.
SYS.2.BP4: 分析系統環境的影響

Analyze the impact that the system requirements will have on elements in the relevant system context.

分析系統需求對相關系統環境中的元件所產生的影響。

SYS.2.BP5: Ensure consistency and establish bidirectional traceability.
SYS.2.BP5: 確保一致性並建立雙向追溯

Ensure consistency and establish bidirectional traceability between system requirements and stakeholder requirements.

在系統需求和利益相關者需求之間確保一致性並建立雙向追溯。

NOTE 7: Bidirectional traceability supports consistency, facilitates impact analyses of change requests, and supports the demonstration of coverage of stakeholder requirements.

備註7: 雙向追溯可以用來支援一致性、協助變更請求的影響分析、並支援展示對利益相關者需求的範圍覆蓋。

SYS.2.BP6: Communicate agreed system requirements and impact on the system context.
SYS.2.BP6: 溝通已同意的系統需求及其對系統全景的影響

Communicate the agreed system requirements, and results of the impact analysis on the system context, to all affected parties.

將已同意的系統需求以及對系統全景影響分析的結果,傳達給所有受影響的各方。


工作產出(Output Work product)

17–00 需求
17-54 需求特性
15–51 分析結果
13–51 一致性證據
13–52 溝通證據



感謝閱讀本文章!

如果你對文章內容有任何問題,請隨時與我交流聯絡。

歡迎訂閱我的文章,當有最新文章發布時,我將第一時間通知您 :)


WRITTEN BY
David Lin

現任國際標準輔導顧問及評鑑師;
在這個網站,我將分享一些產業新知、趨勢以及標準的解讀與看法。

歡迎與我交流:
Email:
linchewing@gmail.com
LinkedIn:
https://www.linkedin.com/in/linchew/