SWE.1 Software Requirements Analysis 軟體需求分析
ASPICE 標準解讀 — 軟體工程流程
目錄: Automotive SPICE(ASPICE)標準解讀 / 軟體工程流程SWE.1 軟體需求分析
SWE.2 軟體架構設計
SWE.3 軟體細部設計與單元開發
SWE.4 軟體單元驗證
SWE.5 軟體整合與整合測試
SWE.6 軟體合格測試
流程目的(Process Purpose)
The purpose of the Software Requirements Analysis Process is to transform the software related parts of the system requirements into a set of software requirements.
軟體需求分析流程的目的是將系統需求中的軟體相關部分轉換成一套軟體需求。
流程結果(Process Outcome)
成功實作軟體需求分析流程，其相應的結果如下：
1) 能被分配給軟體元件及其相關介面的軟體需求被定義;
2) 軟體需求被分類，並分析其正確性及可驗證性;
3) 軟體需求與操作環境的影響被分析;
4) 軟體需求的實作順序被定義;
5) 軟體需求根據需要被更新的; (保持最新的狀態)
6) 系統需求與軟體需求的一致性與雙向可追溯性被建立; 系統架構設計與軟體需求的一致性與雙向可追溯性被建立;
7) 評估軟體需求的成本、時程及技術等影響
8) 軟體需求已商定，並傳達給所有受影響的成員
基礎實踐(Base Practices)
SWE.1.BP1: Specify software requirements.
SWE.1.BP1: 具體描述軟體需求 [Outcome 1,5,7]
Use the system requirements and the system architecture and changes to system requirements and architecture to identify the required functions and capabilities of the software. Specify functional and non-functional software requirements in a software requirements specification.
運用系統需求和系統架構及這兩者的相關變更去識別軟體所需要的功能及性能；在軟體需求規格書中具體描述功能性及非功能性。
NOTE 1: Application parameter influencing functions and capabilities are part of the system requirements.
NOTE 2: In case of software development only, the system requirements and the system architecture refer to a given operating environment (see also note 5). In that case, stakeholder requirements should be used as the basis for identifying the required functions and capabilities of the software as well as for identifying application parameters influencing software functions and capabilities.備註1:影響功能及性能的應用參數是系統需求的一部分；
備註2: 在只有軟體的開發情況下，系統需求和系統架構將參照一個給定的運作環境(請同時參見 備註5)。在這種情況下，應以利益相關方需求作為基礎，來識別軟體所需功能、性能及相關應用參數。
額外說明:「只有軟體開發的情況」，在這個情境中，系統需求與系統架構便沒有存在的意義，硬要去做亦是多此一舉；在這個情況下，應跳過系統需求分析跟系統架構設計流程；在專案計畫書中，應該要將SYS.2, SYS.3, SYS.4 和 SYS.5 這四個流程移除。少掉了系統工程的部分，軟體需求應直接從利益相關方需求中進行識別。
—
SWE.1.BP2: Structure software requirements.
SWE.1.BP2: 結構化軟體需求[Outcome 2,4]
Structure the software requirements in the software 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 software content to planned releases. Refer to SPL.2.BP1.
備註3: 排定優先順序通常包括將是根據排定的發佈對應相關的軟體內容。請參照SPL.2.BP1
額外說明關於軟體需求與系統需求的差異，我將會特別寫一篇文章來說明。
—
SWE.1.BP3: Analyze software requirements.
SWE.1.BP3: 分析軟體需求 [Outcome 2,7]
Analyze the specified software 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
—
SWE.1.BP4: Analyze the impact on the operating environment.
SWE.1.BP4: 分析對操作環境的影響 [Outcome 3,7]
Analyze the impact that the software requirements will have on interfaces of system elements and the operating environment.
分析軟體需求在系統元件的介面與操作環境的影響。
NOTE 5: The operating environment is defined as the system in which the software executes (e.g. hardware, operating system, etc.).
備註5: 這裡要定義的操作環境指的是軟體所執行的系統(包含: 硬體、作業系統，等…)
額外說明這裡提到的操作環境，一般必須從系統架構中來進行識別。基本上，車用專案中的軟體通常會備燒入特定的硬體中，因此該硬體即為軟體的操作環境。一些特殊的狀況下，硬體內部也具備一些基礎的運作架構。一個比較容易明白的例子，如：寫作Android的APP，必須在Android的軟體架構上進行開發；當硬體存在這樣的軟體架構時，這也需要被識別出來。
—
SWE.1.BP5: Develop verification criteria.
SWE.1.BP5: 制定驗證準則 [Outcome 2,7]
Develop the verification criteria for each software requirement that define the qualitative and quantitative measures for the verification of a requirement.
針對每個軟體需求制定定性與定量的驗證準則。
NOTE 6: Verification criteria demonstrate that a requirement can be verified within agreed constraints and is typically used as the input for the development of the software test cases or other verification measures that should demonstrate compliance with the software requirements.
NOTE 7: Verification which cannot be covered by testing is covered by SUP.2.備註6: 驗證準則說明軟體需求可以在約束條件下被驗證。驗證準則通常被用來當作開發軟體測試案例(該軟體案例需與軟體需求保持一致性)的輸入資訊；驗證準則通常也被用當作其他驗證量測方法(方法需與軟體需求一致性)的輸入資訊；
備註7: 無法透過測試來進行驗證的軟體需求將透過SUP.2來執行驗證。
額外說明一個軟體需求可以被定義"驗證準則"；表示這個軟體需求是可以被驗證的。
—
SWE.1.BP6: Establish bidirectional traceability.
SWE.1.BP6: 建立雙向可追溯性 [Outcome 6]
Establish bidirectional traceability between system requirements and software requirements. Establish bidirectional traceability between the system architecture and software requirements.
建立系統需求與軟體需求的雙向追溯。建立系統架構與軟體需求的雙向追溯。
NOTE 8: Redundancy should be avoided by establishing a combination of these approaches that covers the project and the organizational needs
NOTE 9: Bidirectional traceability supports coverage, consistency and impact analysis.備註8: 建立涵蓋專案和組織需求的一套追溯管理方法，該方法應該盡量避免多餘的追溯。
備註9: 雙向追溯支援覆蓋性、一致性和影響分析。
額外說明:一般而言，系統需求中的功能性需求會被對照到系統架構中；非功能性的系統需求，當然也有部分能夠被分派到系統架構中，然而存在部分無法分派到系統架構的系統需求，因此軟體需求的建立必須同時參照系統需求及系統架構，也正因為如此，軟體需求的追溯性必須追到系統需求及系統架構。在備註中提到的避免多餘的追溯(請參考下圖)，圖中SWEREQ_001可以追溯回SYSELM_001，而SYSELM_001亦可以追溯回SYSREQ_001；基於這個案例，在建立雙向追溯性時，會準備兩張追溯表，分別為「系統架構-軟體需求 追溯表」及「系統需求-軟體需求 追溯表」，其中應這兩張追溯表應避免重覆的描述，例如：在「系統需求-軟體需求 追溯表」:
僅描述SYSREQ_010, 013 對應 SWEREQ_010, 011, 012的關係。在「系統架構-軟體需求 追溯表」:
僅描述SYSELM_001對應SWEREQ_001, 002, 003, 004, 005, 006的關係；及SYSITF_001, 002 對應SWEREQ_007, 008, 009的關係；※額外說明
在本範例中，SYSREQ_011及012沒有對應到任何的系統架構及軟體需求，並不表示這兩個需求不需要被實作，這兩個需求可能將對應到「硬體需求」或「機構需求」。
—
SWE.1.BP7: Ensure consistency.
SWE.1.BP7: 確保一致性 [Outcome 6]
Ensure consistency between system requirements and software requirements. Ensure consistency between the system architecture and software requirements.
確保系統需求與軟體需求的一致性。確保系統架構與軟體需求的一致性。
NOTE 10: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
NOTE 11: In case of software development only, the system requirements and system architecture refer to a given operating environment (see also note 2). In that case, consistency and bidirectional traceability have to be ensured between stakeholder requirements and software requirements.備註10: 可以透過BP6所建立的雙向追溯來確保一致性；審查記錄可以用來作為一致性的證明。
備註11:在只有軟體的開發情況下，系統需求和系統架構將參照一個給定的運作環境(請同時參見 備註2)。在這個情況下，應確保「利益相關方需求」與「軟體需求」間的一致性與雙向追溯性。
額外說明:標準中與評鑑標準中，亦提到在這樣的狀況下，軟體需求應該直接與利益相關方需求建立雙向追溯，並確保需求的一致性。
—
SWE.1.BP8: Communicate agreed software requirements.
SWE.1.BP8: 溝通商定的軟體需求 [Outcome 8]
Communicate the agreed software requirements and updates to software requirements to all relevant parties.
溝通商定的軟體需求及其更新給所有相關的成員。
額外說明：溝通的額外說明請參考SYS.2 BP.8的說明。一般來說，SWE.1完成時的主要溝通對象包含下列：目的：回報流程完成
MAN.3(專案管理) - 專案經理目的:通知準備開始接續的工作
SWE.2(軟體架構設計) - 架構設計師
SWE.6(軟體合格測試) - 測試工程師目的:通知建立基準 或 文件管控
SUP.8(組態管理) - 組態工程師目的:通知流程完成 及 準備被稽核
SUP.1(品質保證) - 品保工程師目的:通知進行品質控管 (LV2)
MAN.6(量測) - KPI管理工程師目的:回報流程改善 (Lv3)
PIM.3(流程改善) - EPG品管工程師
工作產出(Output Work product)
13-04 溝通記錄 [Outcome 8]13-19 審查記錄 [Outcome 6] 13-21 變更控制記錄 [Outcome 5,7] 13-22 追溯記錄 [Outcome 1,6]15-01 分析報告 [Outcome 2,3,4,7]17-08 介面需求規格書 [Outcome 1]17–11 軟體需求規格書 [Outcome 1]17–50 驗證準則 [Outcome 2]
感謝閱讀本文章！
如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.
mailto: linchewing@gmail.com
