(更新2024/03/05) 本流程為ASPICE v4.0標準中的系統工程流程 — SYS.2 System Requirements Analysis 系統需求分析；本文章為「ASPICE v4.0 標準解讀」系列文章，筆者將針對ASPICE標準條文提供解讀與說明，期許本篇文章能夠為讀者，解決標準導入時的疑惑。
流程目的(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] 系統需求對操作環境的影響已被分析[Outcome 5] 系統需求與利益相關者需求之間建立了一致性和雙向追溯性[Outcome 6] 系統需求已被同意，且已經傳達給所有受影響的各方
基礎實踐(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 針對需求撰寫格式的要求 所有與需求工程相關的術語應該被正式地定義，並且在系統的所有需求中一致地應用。請參考以下需求範例圖片。
額外說明 -- INCOSE REV: 4.1 INCOSE Guide to Writing Requirements 編寫需求指南在最新的ASPICE v4.0中被特別強調，因此在撰寫需求時，請一定要好好的閱讀，並確認需求有符合其中的規範。 值得一提的是，ISO IEEE 29148 的需求撰寫格式要求，僅僅只是INCOSE 規則的一項，如果要符合INCOSE，還有其他更多的41條要求。 筆者後續會再節錄INCOSE的部分內容，跟大家分享。
—
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. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.
NOTE 8: here may be non-functional stakeholder requirements that the system requirements do not trace to. Examples are process requirements. Such stakeholder requirements are still subject to verification.
備註7: 雙向追溯可以用來支援一致性、協助變更請求的影響分析、並支援展示對利益相關者需求的範圍覆蓋。但是，僅僅追踪到資訊是不夠的，這不代表所有資訊都是互相一致的。
備註8: 系統需求可能無法追溯到某些”非功能性”的利益相關者需求，例如: 流程需求。但這些利益相關者的需求仍需要進行驗證。
額外說明: 利益相關者需求與系統需求之間的追溯 通常，與產品直接相關的需求會成為系統需求的主要來源。而那些與產品不直接相關的要求，如流程、工作方法、管理方式、時間、預算和資源等，則不會被納入系統需求的範疇。 儘管這些與產品不直接相關的需求在標準文件中被稱為「非功能性需求」，筆者更傾向於將它們視為「非技術性」或「與產品無關」的需求，這有助於我們更清晰地理解系統需求中所定義的非功能性需求概念。
—
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 Information Item)
17–00 需求17-54 需求特性15–51 分析結果13–51 一致性證據13–52 溝通證據
