本流程為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] 系統需求對操作環境的影響已被分析
基礎實踐(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 溝通證據
