本流程為ASPICE v4.0標準中的軟體工程流程 — SWE.1 Software Requirements Analysis 軟體需求分析；本文章為「ASPICE v4.0 標準解讀」系列文章，筆者將針對ASPICE標準條文提供解讀與說明，期許本篇文章能夠為讀者，解決標準導入時的疑惑。
流程目的(Process Purpose)
The purpose is to establish a structured and analyzed set of software requirements consistent with the system requirements, and the system architecture.
本流程的目的是根據系統需求和系統架構，建立一套結構化並經過分析的軟體需求。
流程結果(Process Outcome)
成功實作本流程，其相應的結果如下：[Outcome 1] 軟體需求已被明確指定[Outcome 2] 軟體需求已被結構化並按優先順序排列[Outcome 3] 軟體需求已被分析以確保正確性和技術可行性[Outcome 4] 軟體需求對操作環境的影響已被分析[Outcome 5] 軟體需求與系統需求之間建立了一致性和雙向追溯性[Outcome 6] 軟體需求與系統架構之間建立了一致性和雙向追溯性[Outcome 7] 軟體需求已被同意，且已經傳達給所有受影響的各方
基礎實踐(Base Practices)
SWE.1.BP1: Specify software requirements.
SWE.1.BP1: 具體描述軟體需求
Use the system requirements and the system architecture to identify and document the functional and non-functional requirements for the software 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 text), unambiguity/comprehensibility, freedom from design and implementation, and not contradicting any other requirement.
NOTE 3: In case of software-only development, the system requirements and the system architecture refer to a given operating environment. In that case, stakeholder requirements can be used as the basis for identifying the required functions and capabilities of the software.
NOTE 4: The hardware-software-interface (HSI) definition puts in context hardware and therefore it is an interface decision at the system design level. If such a HSI exists, then it may provide input to software requirements.
備註1: 在相關標準中有定義「需求特性」，例如: ISO IEEE 29148、ISO 26262-8:2018或INCOSE編寫需求指南。
備註2: 舉例來說，技術文件裡提到的「需求特性」都包含以下特性：
– 可驗證性（把 “驗證準則” 寫進需求裡)
– 清晰且容易懂
– 和設計或實現方法無關
– 和其他需求不衝突
備註3: 在純軟件開發的情況下，系統需求和系統架構指的是特定的操作環境。在這種情況下，可以使用利益相關者的需求作為確定軟件所需功能和能力的依據。
備註4: 硬體與軟體之間的介面（HSI）定義了硬體和軟體之間的關聯，這是在系統設計階段作出的一個介面決策。如果存在這樣的HSI，那麼它可以為軟體要求提供輸入。
額外說明 -- ISO IEEE 29148 針對需求特性的描述 請參考ASPICE v4.0 SYS.2 系統需求分析 針對需求特性的描述
額外說明 -- ISO IEEE 29148 針對需求撰寫格式的要求 請參考ASPICE v4.0 SYS.2 系統需求分析 針對需求撰寫格式的要求
額外說明 -- INCOSE REV: 4.1 請參考ASPICE v4.0 SYS.2 系統需求分析 針對INCOSE的說明
額外說明 -- HSI (Hardware Software Interface) ISO 26262 Part 4, Clause 6.4.7 提到: The HSI specification shall specify the hardware and software interaction and be consistent with the technical safety concept. The HSI specification shall include the component's hardware parts that are controlled by software and hardware resources that support the execution of the software. HSI規格書將明定硬體與軟體之間如何互動，保證其與安全技術原則(TSC)相符。這包括了那些由軟體控制的硬體部分，以及那些幫助軟體運行的硬體資源(例如: 記憶體、時脈、IO等)。 --- 在ISO 26262的標準中，系統設計階段有個關鍵任務就是確立HSI規格，它是架構藍圖的一部分，細節需精準定義。與ASPICE標準中的SYS.3流程相比，該流程中只要求定義系統元件間的介面，把之形成一份介面規格，軟硬體之間的介面是其中的一部分。 換言之，SYS.3的介面規格其實涵蓋了ISO 26262的HSI規格書；只是ISO 26262針對HSI的內容有更進一步的要求與描述。 如果團隊按照ISO 26262的要求，在系統架構階段制定了HSI規格，那麼這份文件自然而然應該成為SWE.1階段的輸入。
—
SWE.1.BP2: Structure software requirements.
SWE.1.BP2: 結構化軟體需求
Structure and prioritize the software requirements.
將軟體需求進行 結構化 並 排定優先順序。
NOTE 5: Examples for structuring criteria can be grouping (e.g. by functionality) or product variants identification.
NOTE 6: Prioritization can be done according to project or stakeholder needs via e.g. definition of release scopes. Refer to SPL.2.BP1
備註5: 舉例來說，結構化的準則可以是分組（例如，按功能分組）或產品差異的識別 (找出不同的產品版本)。
備註6: 根據專案或利益相關者的需求，可以通過定義產品發布範圍等方式進行優先排序。請參考SPL.2.BP1。
—
SWE.1.BP3: Analyze software requirements.
SWE.1.BP3: 分析軟體需求
Analyze the specified software requirements including their interdependencies to ensure correctness, technical feasibility, and to support project management regarding project estimates.
分析特定軟體需求，包括它們之間的相互依賴性，以確保其正確性、技術可行性，並幫助專案管理，以便進行專案估算。
NOTE 7: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.
NOTE 8: Technical feasibility can be evaluated based on e.g. platform or product line, or by prototyping.
備註7: 有關專案可行性，請參見MAN.3.BP3；有關專案預估，請參見MAN.3.BP5
備註8: 可以根據平台、產品線、或原型開發，來進行技術可行性評估
—
SWE.1.BP4: Analyze the impact on the operating environment
SWE.1.BP4: 分析運作環境的影響
Analyze the impact that the software requirements will have on elements in the operating environment.
分析軟體需求對操作環境中元件的影響。
—
SWE.1.BP5: Ensure consistency and establish bidirectional traceability.
SWE.1.BP5: 確保一致性並建立雙向追溯
Ensure consistency and establish bidirectional traceability between software requirements and system architecture.
Ensure consistency and establish bidirectional traceability between software requirements and system requirements.
在軟體需求和系統需求之間確保一致性並建立雙向追溯。
在軟體需求和系統架構之間確保一致性並建立雙向追溯。
NOTE 9: Redundant traceability is not intended.
NOTE 10: There may be non-functional system requirements that the software requirements do not trace to. Examples are process requirements or requirements related to later software product lifecycle phases such as incident handling. Such requirements are still subject to verification.
NOTE 11: Bidirectional traceability supports consistency, facilitates impact analyses of change requests, and demonstration of verification coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.
NOTE 12: In case of software development only, the system requirements and system architecture refer to a given operating environment. In that case, consistency and bidirectional traceability can be ensured between stakeholder requirements and software requirements.
備註9: 不需要冗餘的追溯。
備註10: 可能存在一些軟體需求沒有追蹤到的非功能性系統需求，如流程要求或與軟體產品生命周期後期階段相關的需求（例如: 事故處理）。這些要求仍需進行驗證。
備註11: 雙向追蹤性支持一致性，有助於變更請求的影響分析，並展示驗證覆蓋範圍。但是，僅僅追溯到資訊是不夠的，這不代表所有資訊都是互相一致的。
備註12: 在純軟件開發的情況下，系統需求和系統架構指的是特定的操作環境。在這種情況下，可以確保利益相關者需求與軟體需求之間的一致性和雙向追溯性。
額外說明 -- 軟體需求與系統需求及系統架構的追溯 如下圖所示，藍色表格為系統需求，綠色表格為系統架構，橘色表格則為軟體需求。 系統需求通過紅色線條被指派給系統架構。在這之中，SYSREQ_011到SYSREQ_013的需求無法被指派到系統架構，但它們中一些與軟體相關的需求（如SWREQ_010到SWREQ_012）可以直接分配給軟體需求。 系統架構則通過綠色線條將涉及軟體的部分分配給軟體需求，而與軟體無關的部分則無需分配。 圖中，雖然SWREQ_001能間接追溯到SYSREQ_005，但不需要建立直接的追溯關係，以避免不必要的重複追溯。
—
SWE.1.BP6: Communicate agreed software requirements and impact on the operating environment.
SWE.1.BP6: 溝通已同意的軟體需求及其對運作環境的影響
Communicate the agreed software requirements, and the results of the analysis of impact on the operating environment, to all affected parties.
將已同意的軟體需求以及對運作環境影響分析的結果，傳達給所有受影響的各方。
輸出資訊項目 (Output Information Item)
17–00 需求17-54 需求特性15–51 分析結果13–51 一致性證據13–52 溝通證據
