國際標準 ISO/IEC/IEEE 15288
第二版 2023-05 【第 2 部分（共 2 部分）】中文版

**國際標準 系統與軟體工程 — 系統生命週期流程**

*Ingénierie des systèmes et dulogiciel — Processus du Cycle de vie du système*

譯者翻譯註解：
1. 持續翻譯中...，歡迎提供任何修改建議
2. 英文版佔128頁，所以需用掉兩個連結 (Part 1 & Part 2)
3. Part 1 of 2 的連結：https://hackmd.io/MlvN2B9qRN2AiCtma3EMRg
4. 修改錯誤專有名詞：如System譯成係統，改為系統

LOG:
1. 2025-12-30 將英文版內容(出處: IEEE，https://standards.ieee.org/ieee/15288/10424/)，送Google翻譯系統，進行初步翻譯。
2.

目錄

[ToC]

### 6.4 技術過程

#### 6.4.1 業務或任務分析過程

##### 6.4.1.1 目的

業務或任務分析過程的目的是定義整體策略問題或機遇，描述解決方案空間，並確定能夠解決問題或抓住機會的潛在解決方案類別。

註 1：可能需要系統解決方案的組織的組織策略和營運理念決定了業務或任務分析的開展背景。組織運作理念反映了領導階層對組織運作方式的預期。它描述了組織的假設，以及組織計劃如何使用待開發的系統、現有系統和可能的未來系統來支援業務的整體運作或一系列營運。如果組織本身就是系統定義物件 (SoI)，則組織的策略是系統定義的一部分。

註 2：在某些領域，這與識別和分析組織所需或期望的能力的概念相關。此過程著重於必要的能力，並與組合管理流程交互，以確定能夠滿足該能力需求的權衡空間。已識別的問題或機會通常會轉化為目標能力。在特定領域內，問題或機會空間包含目標能力。

註 3：業務或任務分析是概念定義活動的一部分－概念定義是一系列系統工程活動，其中對問題空間以及業務或企業和利害關係人的需求進行深入研究。

##### 6.4.1.2 成果

成功完成業務或任務分析流程後：

a) 問題或機會空間定義；

b) 確定解決方案空間；

c) 定義初步運作概念和生命週期各階段的其他概念；

d) 分析備選解決方案類別；

e) 選擇首選備選解決方案類別；

f) 確保業務或任務分析所需的支援系統或服務可用；

g) 建立策略問題和機會以及首選備選解決方案類別的可追溯性。

##### 6.4.1.3 活動與任務

以下活動和任務應根據適用於業務或任務分析流程的組織政策和程序執行。

a) 為業務或任務分析做好準備。此活動包括以下任務。

1) 檢視組織策略和運作概念的變更，以識別與預期組織使命、願景、目標和目的相關的潛在問題和機會。

註1：這包括識別現有能力、系統、產品或服務中的缺陷或差距。

2) 定義業務或任務分析策略。

註2：這包括用於識別和定義問題空間、描述解決方案空間以及選擇解決方案類別的方法。

3) 識別並規劃支援業務或任務分析所需的必要啟用系統或服務。

註3：這包括識別使能系統的需求和介面。用於業務或任務分析的使能系統包括組織的業務系統和儲存庫。

4) 取得或取得所要使用的啟用系統或服務的存取權限。

註4：驗證過程用於客觀確認使能系統是否實現了其預期的使能功能。

b) 定義問題或機會空間。此活動包含以下任務。

1) 在相關的權衡因素背景下分析問題和機會。

註5：此分析著重於理解問題或機會的範圍、基礎或驅動因素，而不是像權衡研究所需的系統分析和決策管理那樣著重於綜合分析。此處重點在於任務需求的變化、業務需求和機會、能力、性能改進或現有系統的不足、安全保障改進、成本和效益等因素、法規變更、用戶不滿以及PESTEL（政治、經濟、社會、技術、環境和法律）因素。這可以透過外部分析、內部分析或SWOT（優勢、劣勢、機會和威脅）分析來實現。

註6：分析結果被視為投資組合的一部分。管理決策。

2) 明確解決方案要解決的任務、業務或營運問題或機會。

註 7：此定義包含背景、任何關鍵參數和關鍵業務成功指標，而不考慮特定解決方案，因為解決方案可以是營運變更、現有產品或服務的變更，也可以是新系統。

3) 根據其他業務需求，對潛在問題或機會進行優先排序。

註 8：此任務旨在了解解決此新業務需求（問題或機會）相對於其他不屬於新解決方案的業務需求的重要性。當可用資源有限時，這一點尤其重要。

c) 描述解決方案空間。此活動包含以下任務。

1) 定義初步營運概念和其他生命週期概念。

註 9：這涉及識別主要利害關係人群體，例如客戶、使用者、管理人員、監管機構和系統所有者，這些群體在利害關係人需求和要求定義過程中已定義。

註10：初步生命週期概念包括初步採購概念、初步部署概念、初步運作概念、初步支援概念和初步退役概念。運行概念包括高級運行模式或狀態、運行場景、潛在用例或在擬議業務策略中的使用情況。這些概念有助於進行可行性分析和替代方案評估。這些概念將在利害關係人需求定義過程中進一步完善。

註11：運作環境可能存在與特定安全威脅和安全隱患相關的漏洞。這些漏洞將與正在開發的產品一起進行審查。系統和人機介面是系統保障環境的一個組成部分，相關漏洞將在關鍵任務執行緒的背景下進行審查。

2) 識別涵蓋潛在解決方案空間的備選解決方案類別。

註12：這些類別涵蓋範圍廣泛，從簡單的運行變更到各種系統開發或修改。解決方案空間可以包括識別適合重複使用的現有資產、系統和軟體產品，以及可以滿足運作或功能修改需求的服務變更。這包括推斷可能需要哪些潛在預期服務。解決方案空間特徵描述通常會呼叫系統架構定義過程，從使用者架構的角度出發，產生架構視圖（例如，能力視圖、程序視圖、操作視圖和使用者或人員視圖），如 ISO/IEC/IEEE 42010 所建議的。

d) 評估備選解決方案類別。此活動包含以下任務。

註 13：如果評估結果中不存在單一的系統解決方案備選方案，則可以將系統之系統 (SoS) 解決方案識別並評估為備選解決方案類別。有關 SoS 的更多信息，請參閱 [5.4](#_bookmark62)、ISO/IEC/IEEE 21840 和 ISO/IEC/IEEE 21841。

1) 評估每個備選解決方案類別。

註 14：解決方案類別是指實現解決方案的手段，例如新建系統、調整或修改現有系統、連接來自不同系統的系統元素、考慮操作因素等。解決方案類別著重於提供解決方案的不同方法。

註15：每類備選方案均根據基於組織策略制定的既定標準進行評估。方案的可行性及其滿足策略需求和要求的能力是關鍵決策標準。組合管理流程提供了一些可供參考的標準。

註16：系統分析流程用於評估每類備選方案中各項標準的價值。建議採用結構化的成本權衡方法。將成本納入考量有助於成本決策。備選方案的評估可包括建模、模擬、分析技術或專家判斷，以了解各類備選方案的風險、可行性及價值。

2) 選擇首選的備選方案。

註17：決策管理流程用於評估備選方案並指導選擇。選定的備選方案將在組織策略的背景下進行驗證。針對風險、可行性、市場因素和備選方案的回饋將用於更新組織策略。

3) 向策略層面的生命週期概念提供回饋，以反映所選的解決方案類別。

e) 管理業務或任務分析。此項活動包含以下任務：

1) 記錄關鍵的業務或任務分析決策及其理由。註18：理由部分包含有關主要備選方案和促成因素的資訊。

2) 維持業務或任務分析以及備選解決方案類別的可追溯性。

註19：在整個生命週期中，業務或任務問題和機會與首選備選解決方案類別之間，以及支援決策的組織策略、利害關係人需求和要求和系統分析結果之間，保持雙向可追溯性。

3) 提供已選定用於基線的關鍵工件。

註20：配置管理流程用於建立和維護配置項目和基準。業務或任務分析流程確定基準候選方案，然後將工件提供給組態管理。

#### 6.4.2 利害關係人需求與要求定義流程

##### 6.4.2.1 目的

利害關係人需求和要求定義流程的目的是定義利害關係人對系統的需求和要求，該系統能夠在特定環境中提供使用者和其他利害關係人所需的功能。

它識別系統生命週期中涉及的利害關係人或利害關係人類別及其需求。它分析這些需求，並將其轉化為一套通用的利害關係人需求，這些需求表達了系統與其運行環境的預期交互，並作為驗證每項最終運作能力的參考。利害關係人需求的定義考慮了系統應用領域（SoI）的背景，包括互操作系統和使能系統。這也包括對法律法規、環境限制和倫理價值的考量。

##### 6.4.2.2 成果

成功完成利害關係人需求定義過程後，將達成以下目標：

a) 辨識系統的利害關係人；

b) 定義所需特性、能力使用背景、運作概念和其他生命週期概念；

c) 辨識系統約束；

d) 定義利害關係人需求；

e) 將優先排序的利害關係人需求轉化為利害關係人需求；

f) 定義關鍵性能指標和品質特性；

g) 利害關係人同意其需求和期望已充分體現在需求中；

h) 滿足利害關係人需求所需的系統或服務可用；

i) 已建立利害關係人需求與其自身需求之間的可追溯性。

##### 6.4.2.3 活動與任務

以下活動和任務應根據適用的組織政策和程序，針對利害關係人需求定義流程實施。

a) 為利害關係人需求定義做好準備。此活動包含以下任務。

1) 識別在解決方案的整個生命週期中對其感興趣的利害關係人。

註1：這包括使用者、營運商、支持者、開發人員、生產商、培訓人員、維護人員、處置人員、採購者和供應商組織、負責外部介面實體的各方、監管機構以及其他對系統解決方案具有合法權益的個人和利害關係人類別。在無法直接溝通的情況下（例如，對於消費產品和服務），應選擇代表或指定的代理利害關係人。

1) 定義利害關係人需求和要求定義策略。

註2：某些利害關係人的利益可能與系統相衝突，或彼此衝突。當利害關係人的利益彼此衝突，但不反對系統時，此過程旨在促使各類利害關係人達成共識，從而建立一套共同可接受的要求。對於反對系統者或系統批評者的意圖或願望，可透過風險管理流程、系統分析流程中的威脅分析，或系統的安全、適應性或韌性要求來解決。在這種情況下，利害關係人的需求並未得到滿足，而是以一種有助於確保系統在遭遇批評者行動時仍能保持可靠性和完整性的方式來解決。

3) 識別並規劃支援利害關係人需求和要求定義所需的必要使能系統或服務。

註3：這包括識別使能系統的需求和介面。用於利害關係人需求和要求定義的使能系統包括促進和需求管理的工具。

4) 取得或取得所需支援系統或服務的存取權限。

註 4：驗證過程用於客觀地確認支持系統是否實現了其預期的功能。

b) 制定運行概念及其他生命週期概念。此活動包含以下任務。

註 5：其他生命週期概念可以包括採購概念、部署概念、支援概念、安全概念和退役概念。在此活動中，在業務或任務分析過程中定義的初步生命週期概念，將根據特定利害關係人的需求，結合相關場景和互動進行進一步發展。有關運行概念的更多信息，請參閱 ISO/IEC/IEEE 29148:2018 第 5 條和第 6 條；系統運行概念的註釋大綱，請參閱 ISO/IEC/IEEE 29148:2018 附錄 A。

1) 在運作概念、初步生命週期概念和首選解決方案類別中定義使用環境。

註 6：使用環境通常使用使用環境描述 (ISO/IEC 25063) 來描述。初步生命週期概念和首選替代解決方案類別由業務或任務分析過程製定。

2) 定義使用環境和一系列場景（或使用案例），以識別與預期運行概念和其他生命週期概念相對應的所有必要功能。

註 7：情境用於分析系統在其預期環境中的運作情況，以識別利害關係人可能未明確指出的其他需求或要求，例如法律、監管和社會義務。系統使用環境的識別和分析包括使用者為實現系統目標而執行的活動、系統最終用戶的相關特徵（例如預期培訓、疲勞程度）、物理環境（例如可用光照、溫度）以及任何將要使用的設備（例如防護設備或通訊設備）。

註 8：這些場景通常會促使對運行概念或其他生命週期概念進行更新。濫用和故障情境凸顯了需要額外的功能需求（或更具體的衍生需求）來降低在濫用或故障情境中識別出的風險。

3) 描述運行環境和預期使用者。

4) 辨識使用者與系統之間的互動以及影響互動的因素。

註 9：可用性要求考慮了人的能力和技能限制。盡可能使用適用的標準（例如 ISO 9241-210）和公認的專業實踐來定義：

a) 生理、心理和學習能力；

b) 工作場所、環境和設施，包括使用環境中的其他設備；

c) 正常、異常和緊急情況；

d) 操作員和使用者的招募、訓練和文化。

註 10：如果可用性很重要，則應在生命週期過程中規劃、規定和實施可用性要求。有關人機互動問題的更多信息，請參閱 ISO TS 18152；有關可用性的信息，請參閱 ISO/IEC TR 25060。

5) 識別 SoI 與外部系統互動的所有介面邊界。

註11：辨識SoI與介面系統、啟用系統和互操作系統之間的交互作用有助於辨識介面邊界（另見[5.2.3](#_bookmark54)）。

6) 識別系統解決方案的約束。

註12：這些約束源自於：

- 利害關係人定義的解決方案實例或領域；

- 系統結構中其他位置所做的實施決策；

- 必須使用已定義的啟用系統、遺留系統或介面系統或系統元素、資源和人員；或

- 利害關係人定義的可負擔性目標。包括現有協議、管理決策和技術決策不可避免的後果。

c) 定義利害關係人的需求。此活動包含以下任務。

1) 在生命週期概念所施加的約束範圍內辨識出利害關係人的需求。

註13：識別利害關係人的需求包括：收集已識別利害關係人的需求、願望、期望和感知到的限制；基於領域知識和背景理解識別隱含的利害關係人需求；以及記錄先前活動中存在的差距。需求通常包括有效性衡量指標（更多資訊請參閱 ISO/IEC/IEEE 24748-2）和關鍵運行問題的識別。功能分析常用於輔助需求取得。 ISO/IEC 25010 中品質模型的品質特性以及 ISO/IEC 25030 中品質模型在需求分析中的應用也有助於獲取和識別品質特性需求，這些需求通常是利害關係人的隱性需求。此外，需求還可以包括 SoI 在參與系統之系統時與其他系統互動的考慮因素（更多資訊請參見 I）。（ISO/IEC/IEEE 21839）。

註14：基於對不利或敵對利害關係人影響的分析，可以得出能夠降低風險的限制條件。

2）確定需求的優先順序並進行篩選。

註15：決策管理流程通常用於支援優先排序。系統分析流程用於分析需求的可行性或其他因素。

3）記錄利害關係人的需求及其理由。

註16：需求著重於系統用途和行為，並在運作環境和條件的背景下進行描述。追溯需求的來源和理由非常有用。

註17：審查需求的格式和品質是一種良好的實踐。

d）將利害關係人的需求轉化為利害關係人的要求。此活動包含以下任務。

1）識別與關鍵品質特性（例如保證、安全、安保、環境或健康）相關的利害關係人的要求和功能。

註18：ISO/IEC/IEEE 15026系列提供了有關系統和軟體保證的更多資訊。

註19：識別安全風險有助於確定安全要求和功能。安全風險包括與操作和支援方法、健康與安全、財產威脅以及環境影響相關的風險。可採用適用的標準，例如IEC 61508系列標準，以及公認的專業實務。

註20：識別安全風險有助於確定安全要求和功能。安全風險包括系統安全的適用領域（例如實體安全、程式安全、通訊安全、電腦安全）；對受保護人員、財產和資訊的存取和損害；敏感資訊外洩；以及拒絕授權存取財產和資訊。緩解和遏制等安全功能是典型的考慮因素。

註21：ISO/IEC 25030從使用品質的角度提供了更多有關品質特性的資訊。

2) 根據生命週期概念、場景、互動、約束、關鍵品質特性和系統安全 (SoS) 考慮因素，定義利害關係人的要求。

註22：有關利害關係人需求的更多信息，請參閱ISO/IEC/IEEE 29148:2018第5條和第6條；ISO/IEC/IEEE 29148:2018第8條和第9條提供了利益相關者需求規範的描述和帶註釋的概要。

註23：在生命週期的關鍵決策階段審查利害關係人需求，以確保考慮任何需求變化。包含利害關係人需求的支持性理由有助於未來的分析工作。

註24：利害關係人需求以適合在整個生命週期中進行需求管理的形式記錄。這些記錄建立了利害關係人需求基線，並保留了整個系統生命週期中需求的變化及其來源。這些記錄是追溯業務或任務分析過程所做決策以及利害關係人需求、系統需求和後續系統元素的基礎。

註25：關於SoI的系統系統（SoS）考慮因素的信息，請參見[5.4.4](#_bookmark66)和ISO/IEC/IEEE 21839。

e) 分析利害關係人的需求和要求。此活動包含以下任務：

1) 分析完整的利害關係人需求集合。

註26：利害關係人需求的分析包括單一需求的特徵以及需求集的特徵。潛在的分析特徵包括：需求是必要的、與實現無關的、明確的、完整的、單一的、可實現的、可驗證的和符合規範的。對於需求集，其特徵是完整、一致、可行（或可負擔）和有界的。 ISO/IEC/IEEE 29148提供了更多關於需求特徵的資訊。

註27：系統分析過程用於評估可行性和可負擔性。驗證和確認過程用於審查利害關係人的需求。

2) 定義關鍵績效指標和品質特性，以便評估技術成果。

註28：這包括定義與利害關係人需求中確定的每項有效性指標相關的技術和品質指標以及關鍵績效參數。關鍵績效指標（例如，有效性指標和適用性指標）的定義、分析和審查旨在確保滿足利害關係人的需求，並有助於識別與任何不合規情況相關的專案成本、進度或績效風險。 ISO/IEC/IEEE 15939 提供了一個識別、定義和使用適當指標的流程。 INCOSE-TP-2003-020-01 提供了關鍵績效指標的選擇、定義和實施的資訊。ISO/IEC 25000 系列標準提供了相關的品質衡量指標。

3) 將分析後的需求回饋給相關利害關係人，以驗證他們的需求和期望是否已充分的捕捉和表達。

4) 解決利害關係人的需求問題。

註 29：這包括違反單一需求或需求集特徵的需求。

f) 管理利害關係人的需求和需求定義。此活動包含以下任務。

1) 就利害關係人的需求達成明確共識。

註 30：這包括確認利害關係人的需求符合其自身需求，表達正確，易於發起人理解，且需求衝突的解決沒有損害或破壞利害關係人的意圖。

2) 記錄關鍵的利害關係人需求決策及其理由。

註 31：理由包括有關主要替代方案和促成因素的資訊。

3) 維護利害關係人需求和需求的可追溯性。

註32：在整個生命週期中，利害關係人的需求和要求與利害關係人和資源、組織策略以及業務或任務問題和機會之間保持雙向可追溯性。對構成系統解決方案的各個系統的額外可追溯性有助於過渡到系統需求定義過程。這通常由適當的資料儲存庫來促進。

4) 提供已選定用於基線的關鍵工件。

註33：配置管理過程用於建立和維護配置項和基準。利害關係人的需求和要求定義過程確定基線候選項，然後將工件提供給組態管理。對於利害關係人的需求和要求定義過程，利害關係人的需求、利害關係人的要求和運作概念是典型的基準工件。

#### 6.4.3 系統需求定義過程

##### 6.4.3.1 目的

系統需求定義過程的目的是將利害關係人和使用者對所需能力的觀點轉換為滿足使用者運作需求的解決方案的技術觀點。

此流程創建了一組可衡量的系統需求，從供應商的角度明確了系統為滿足利害關係人需求而應具備的特性、屬性以及功能和性能要求。在約束條件允許的情況下，這些需求不應包含任何具體的實作方式。

##### 6.4.3.2 成果

成功完成系統需求定義流程後，將達成以下目標：

a) 定義了系統解決方案的系統描述，包括系統外部介面、功能和邊界；

b) 定義了系統需求（功能、效能、流程、品質和介面）和設計限制；

c) 定義了關鍵績效指標；

d) 分析了系統需求；

e) 提供了系統需求定義所需的支援系統或服務；

f) 建立了系統需求與利害關係人需求之間的可追溯性。

##### 6.4.3.3 活動與任務

以下活動和任務應根據組織關於系統需求定義過程的適用政策和程序執行。

a) 準備系統需求定義。此活動包含以下任務：

1) 根據系統需求提供的行為和屬性，定義系統的功能邊界。

註 1：功能邊界的定義部分是基於利害關係人需求定義過程中定義的使用環境和運作場景。這包括系統的刺激及其對使用者和環境行為的反應，以及對系統與其環境之間所需互動的分析和描述，包括介面屬性和約束，例如機械、電氣、品質、熱力、資料和流程流。這確定了系統在其邊界處的預期行為，並以量化方式表達。

註 2：這包括對備選邊界進行評估並從中選擇。

2) 定義系統需求定義策略。

註 3：這包括用於識別和定義系統需求，以及在系統生命週期中管理需求的方法。

3) 辨識並規劃支援系統需求定義所需的必要啟用系統或服務。

註4：這包括識別使能系統的需求和介面。用於系統需求定義的使能系統包括輔助工具和需求管理工具。

4) 取得或取得存取權限使能系統或服務得以使用。

註 5：驗證過程用於客觀地確認使能系統是否實現了其預期的使能功能。

b) 定義系統需求。此活動包含以下任務：

1) 定義系統需要執行的每項功能。

註 6：這包括系統（包括其操作人員）執行每項功能的程度要求、系統能夠執行該功能的條件、系統開始執行該功能的條件以及系統停止執行該功能的條件。在某些情況下，功能源自於關鍵品質特性的分析（例如，系統診斷功能或用於可靠性的高頻資料備份功能）。功能之間可能存在不利的相互作用。

註 7：執行功能的條件可以參考系統所需的運作狀態和模式。系統需求很大程度上依賴對建議系統特性的抽象表示，有時會採用多種建模技術和視角，以充分完整地描述所需的系統需求。

註8：為支援系統功能實現所需的使能功能，應與系統功能同步識別與定義。這對於確保使能功能被識別和考慮至關重要。

註9：這包括對備選功能和功能集進行評估，並從中選擇備選方案。

2) 定義必要的實施約束。

註10：這包括從系統結構更高層級的架構定義中分配的實施決策，以及由利害關係人需求引入或作為解決方案限制的實施決策。

3) 辨識與風險、系統關鍵性或關鍵品質特性相關的系統需求。

註11：關鍵品質特性通常包括與健康、安全、安保、保證、可靠性、彈性、可用性和可支援性相關的特性。哪些品質特性重要取決於專案和領域。這包括對以下內容的分析和定義：

a) 安全考量因素，包括與使用和支援方法、環境影響和人員傷害相關的考慮因素（請參閱 IEC 61508 系列功能安全標準和 ISO 14001 環境安全標準）；

b) 安全考量因素，包括與敏感資訊、資料和材料的洩漏和保護相關的考慮因素（請參閱 ISO/IEC/IEEE 15026-4 系統和軟體保障標準以及 ISO/IEC 27036 系列產品和服務外包資訊安全要求標準）；

c) 外部系統品質因素（參見 ISO/IEC 25030）；

d) 人機互動與人因工程（人體工學）考量（請參閱 ISO 9241-210 可用性標準）。

4) 定義系統需求和理由。

註 12：這包括定義與利害關係人需求、功能邊界、功能、限制、成本目標、已識別的介面、關鍵品質特性和系統之系統 (SoS) 考慮因素一致的系統需求。執行此任務可受益於透過系統結構與其他生命週期流程並行執行的迭代和遞歸步驟。有關系統需求的更多信息，請參閱 ISO/IEC/IEEE 29148:2018 第 5 條和第 6 條；有關系統需求規範的描述和帶註釋的概要，請參閱 ISO/IEC/IEEE 29148:2018 第 8 條和第 9 條。

註 13：系統需求以適合在整個生命週期中進行需求管理的形式記錄。這些記錄建立了系統需求基線，並包含相關的理由、決策和假設。它們是追溯到資訊項和後續系統元素的基礎。

註 14：系統分析過程用於確定需求參數的適當值，同時考慮系統的預期成本、進度和技術性能。驗證過程用於確定需求是否滿足利害關係人的需求。確認過程根據良好需求的屬性和特徵來確定需求的品質。

c) 分析系統需求。此活動包含以下任務。

1) 分析完整的系統需求集。

註 15：系統需求分析不僅包括單一需求的特徵，還包括需求集的整體特徵。潛在的分析特徵包括：需求是否必要、無需實現、明確、一致、完整、單一、可行、可追溯、可驗證、可負擔，以及有界。 ISO/IEC/IEEE 29148 提供了需求特性的補充資訊。缺陷、衝突和弱點將在完整的系統需求集中進行識別和解決。

註 16：系統分析過程用於評估可行性、可負擔性和其他需求特性。

2) 定義關鍵性能指標，以便評估技術成果。

註 17：這包括定義技術和品質指標，以及與系統需求中確定的每個有效性指標相關的關鍵效能參數。對關鍵性能指標（例如，性能指標和技術性能指標）進行分析和審查，以幫助確保滿足系統需求，並幫助識別與任何不符合項目相關的專案成本、進度或性能風險。 ISO/IEC/IEEE 15939 提供了一個識別、定義和使用適當指標的過程。 INCOSE-TP-2003-020-01 提供了關鍵效能指標的選擇、定義和實施的資訊。 ISO/IEC 25000 系列標準提供了相關的品質指標。

3) 將分析後的需求回饋給相關利害關係人進行審查。

註 18：回饋有助於確保已充分捕捉和表達指定的系統需求。確認這些需求是對利害關係人需求的必要且充分的回應，也是其他流程（特別是架構和設計）的必要且充分的輸入。這是針對特定需求所應用的驗證流程的一個實例。

4) 解決系統需求問題。

註 19：這包括違反單一需求或需求集特徵的需求。

d) 管理系統需求。此活動包含以下任務。

註 20：維護系統需求包括定義、記錄和控制基準（通常在正式配置管理下進行），以及管理因應用其他生命週期流程（例如架構或設計）而產生的任何變更。

1) 就系統需求達成明確共識。

註21：這包括確認系統需求滿足利害關係人的需求，表達正確，易於發起人理解，且需求衝突的解決沒有損害或破壞利害關係人的意圖。

2) 記錄關鍵系統需求決策及其理由。

註22：理由包括主要替代方案和促成因素的資訊。

3) 維護系統需求的可追溯性。

註23：在整個生命週期中，系統需求與利害關係人的需求、架構元素、介面定義、分析結果、驗證方法或技術以及已指派、已分解與已衍生的需求之間保持雙向可追溯性。這有助於確保所有可實現的利害關係人需求都由一個或多個系統需求滿足，並且所有系統需求都滿足或有助於滿足至少一個利害關係人需求。這通常可以透過適當的資料儲存庫來實現。

4) 提供已選定用於基線的關鍵工件。

註24：配置管理流程用於建立和維護配置項和基準。系統需求定義流程首先確定基線候選方案，然後將相關工件提供給組態管理部門。對於系統需求定義過程而言，系統需求是典型的基準工件。

#### 6.4.4 系統架構定義流程

##### 6.4.4.1 目的

系統架構定義過程的目的是產生系統架構備選方案，選擇一個或多個能夠滿足利害關係人關注點和系統需求的替代方案，並以一致的視圖和模型表達這些方案。

系統架構定義活動是基於邏輯相關且彼此一致的原則、概念和屬性來定義解決方案。解決方案架構具有盡可能滿足系統需求集（可追溯至任務、業務和利害關係人需求）和生命週期概念（例如，運作、支援）所表達的問題或機會的特性、屬性和特徵。

此流程將相關架構（例如策略架構、企業架構、參考架構和系統之系統 (SoS) 架構）、組織和專案政策及指令、生命週期概念和限制、利害關係人關注點和需求以及系統需求和約束轉化為系統的基本概念和屬性，以及系統演化的管理原則及其相關的生命週期流程。

註：當企業或系統之系統 (SoS)如果SoI是系統架構，那麼企業架構或SoS架構就是系統架構。

##### 6.4.4.2 成果

系統架構定義程序成功實施後，將達成以下目標：

a) 根據關鍵利害關係人的關注點、背景和視角，細化問題空間；

b) 實現架構與適用的政策、指令、目標和限制的一致性；

c) 將對系統架構決策至關重要的概念、屬性、特徵、行為、功能或限制分配給架構實體；

d) 系統架構解決了已識別的利害關係人關注點；

e) 建立系統架構元素與關鍵架構相關利害關係人與系統需求之間的可追溯性；

f) 開發系統架構視圖和模型；

g) 定義系統元素及其相互介面；

h) 提供系統架構定義所需的啟用系統或服務。

##### 6.4.4.3 活動與任務

以下活動和任務應根據組織適用的政策和程序，針對系統架構定義過程實施。

註 1：系統架構定義過程的活動 b) 至 d) 對應於 ISO/IEC/IEEE 42020 中的三個核心流程。每個活動下方的任務對應於 42020 架構流程中的對應活動。此處的活動和任務僅針對系統範圍進行了編輯。 ISO/IEC/IEEE 42020 對以下活動和任務提供了更多詳細資訊。

a) 為系統架構定義做準備。此活動包含以下任務：

1) 確定關鍵里程碑和決策，這些里程碑和決策將受到系統架構工作的指導。

2) 定義系統架構定義策略。

3) 為組織架構治理和架構管理工作提供支援並做好規劃。

4) 確定並規劃支援系統架構定義工作所需的必要啟用系統或服務。

5) 取得或取得用於系統架構定義工作的支援系統或服務的存取權限。

註2：驗證過程用於客觀確認支持系統是否實現了其預期的功能。

b) 構思系統架構。此活動包含以下任務：

1) 描述問題空間。

註3：此步驟與業務或任務分析流程結合進行，後者用於識別和定義問題（或機會）空間。它包括任何關鍵考慮因素，例如系統之系統 (SoS) 互動、所需的品質特性等。

2) 建立架構目標和關鍵成功標準。

3) 在解決方案空間中綜合潛在解決方案。

註4：業務或任務分析流程為解決方案空間建立首選的備選解決方案類別。識別並分析首選備選解決方案類別中的潛在解決方案。

4) 描述解決方案及其權衡空間。

5) 制定候選架構。

6) 捕獲架構概念和屬性。

7) 將架構與其他架構以及相關的受影響實體關聯起來，以確保一致性。

8) 協調目標使用者對架構的使用。

c) 評估系統架構。此活動包含以下任務。

註 5：此活動與系統分析和決策管理流程協同進行。

1) 確定評估目標和標準。

2) 確定評估方法並將其與評估目標和標準結合。

註 6：測量過程用於建立衡量指標以及相關的測量技術、方法和工具，以支援評估。

3) 收集和審查與評估相關的資訊。

4) 分析架構概念和屬性，並評估架構的價值。

5) 將分析和評估結果結合起來，形成總體評估，以選擇最佳的系統架構解決方案。

6) 根據評估結果描述架構。

7) 形成調查結果和建議。

8) 收集並傳達評估結果。

d) 完善系統架構。此活動包含以下任務。 1) 辨識或發展架構視角，並確定受這些架構視角約束的模型類型和圖例。

2) 開發架構模型和視圖。

註7：模型包括系統、系統元素、介面、活動、角色、人員、技術、流程、策略、規則、原則、目標、能力、節點、連結、資料元素、層、協定、硬體項目和軟體項目等。架構視角應將人作為系統的一部分。系統視圖捕捉人類需求，以指導人類如何影響系統定義（即使用者或人類視角）。

註 8：以下是識別或開發架構視圖的典型考慮因素：

a) 基於利害關係人的關注點，選擇、調整或發展視圖和模型類型；

b) 辨識架構詳解資訊的預期用戶，包括相關的架構描述、模型和資料；

c) 識別用於開發模型和視圖的潛在架構框架或參考架構。

註 9：以下是定義系統上下文和邊界（包括與外部實體的介面和互動）的典型考慮因素：

a) 根據與外部實體的介面和互動定義系統上下文和邊界；

b) 辨識架構實體以及實體之間的關係，以滿足關鍵利害關係人的關注點和關鍵系統需求；

c) 將對系統架構決策至關重要的概念、屬性、特徵、行為、功能或限制分配給架構實體；

d) 選擇、調整或發展系統候選架構的模型；

e) 根據已識別的視角，從模型中組合視圖，以表達架構如何解決利害關係人的關注點並滿足利害關係人和系統需求；

f) 在架構模型和視圖的開發過程中，協調架構模型和視圖之間的一致性。

3) 將架構與其他架構以及相關的受影響實體關聯起來，以協助確保已詳細闡述的系統架構的一致性。

4) 評估架構的詳細闡述。

5) 協調目標使用者對已詳細闡述的架構的使用。

e) 管理系統架構定義的成果。此活動包含以下任務：

1) 監控、評估和控制系統架構定義的活動和任務。

2) 就架構定義達成一致。

3) 為組織架構治理和架構管理工作提供支援。

4) 記錄關鍵的系統架構決策及其理由。

註10：理由包括有關主要替代方案和促成因素的資訊。

5) 維護系統架構的可追溯性。

註11：在生命週期中，架構實體（模型、視圖和視點）與需求（包括分配的需求、分解的需求和派生的需求）、介面定義、分析結果以及驗證方法或技術之間保持雙向可追溯性。如果可能，架構實體與利害關係人關注點之間也保持可追溯性。

6) 提供已選定用於基線的關鍵工件。

註12：配置管理過程用於建立和維護配置項和基準。系統架構定義程序識別基線候選項，然後將工件提供給組態管理。

#### 6.4.5 設計定義流程

##### 6.4.5.1 目的

設計定義過程的目的是提供關於系統及其元素的足夠詳細的數據和信息，以便根據系統需求和架構實現解決方案。

此過程將架構和需求轉換為可實現的系統設計。此流程可產生足夠詳細的系統及其元素資料和信息，從而能夠按照系統架構模型和視圖中定義的架構實體、符合適用的系統需求以及與組織或專案採用的設計指南和標準保持一致的方式進行實施。

註 1：設計定義考慮所有適用的技術及其對系統解決方案的貢獻。設計提供定義的“實施層面”，例如圖紙和詳細的設計描述。

註 2：此程序向系統架構定義過程提供回饋，以鞏固或確認架構實體到構成系統的系統元素的分配、劃分和對齊。

##### 6.4.5.2 成果

成功執行設計定義流程後，將達成以下目標：

a) 評估系統元素的各種設計方案；

b) 將系統需求分配給系統設計或其元素；

c) 定義構成系統的系統設計元素之間的介面；

d) 定義每個系統元素的設計特性；

e) 提供設計定義所需的啟用系統或服務；

f) 明確設計定義工作所需的必要設計使能因素；

g) 評估系統設計；

h) 可追溯性設計方案已確定。

##### 6.4.5.3 活動與任務

以下活動和任務應根據組織適用的政策和程序，在設計定義過程中實施。

a) 為設計定義做準備。此活動包含以下任務。

1) 定義設計定義策略。

2) 確定構成系統的每個系統元素所需的技術。

3) 確定設計中所體現的必要系統特性類別。

註 1：系統特性類別的範例（其中許多是架構描述的結果）包括：經濟性、敏捷性、保障性、自主性、可用性、複雜性、靈活性、互通性、可維護性、模組化、可靠性、彈性、安全性和易用性。還有許多其他特性。

4) 定義設計演進原則。

註2：這包括定義在系統及其架構演進的情況下對設計特性進行定期評估，以及預測系統元素和技術的潛在過時情況、它們在系統生命週期中隨時間推移被其他元素替代的情況，以及對系統設計的影響。

5) 識別並規劃支援設計定義工作所需的必要啟用系統或服務。

6) 取得或取得用於設計定義工作的啟用系統或服務的存取權限。

註3：驗證過程用於客觀確認使能系統是否實現了其使能功能的預期用途。

b) 創建系統設計。此活動包含以下任務。

1) 將系統需求分配給系統元素。

註4：一些系統需求通常在系統架構定義過程中分配給系統元素。此任務的目的是完成分配，以滿足所有系統需求和架構目標。

2) 將架構實體和關係轉換為設計元素。

註5：此任務有助於確保每個架構實體（例如企業或專案目標、能力和影響、營運活動、資源功能）及其關係都對應到相應的系統設計元素中，從而確保設計能夠滿足所有架構目標。 ISO/IEC/IEEE 42020 提供了更多關於架構實體的詳細資訊。

3) 將架構特性轉換為設計特性。

註6：設計特性包括功能、行為、尺寸、形狀、材料、關鍵品質特性、資料處理結構等。應考慮應用所需的適當餘裕。

4) 定義必要的設計使能因素。

註7：設計使能因素包括與分配的系統特性相關的產品標準與規格、模型、方程式、演算法、計算、參數的形式化表達式和值、模式、啟發式方法等。在定義必要的設計使能因素時，應考慮關鍵屬性在其計畫運作環境中的適用性。

5) 審查設計方案。

註8：當分配的系統特性無法輕易實現，或有重大設計或實現挑戰時，需要評估已分配系統特性的可行性，並在架構和需求之間進行權衡。

註9：除了新的設計方案外，通常還會辨識出所有候選的非開發項 (NDI) 以供考慮。這包括現成商用元件 (COTS)、先前設計的重複使用或採購者提供的元件。出於可靠性、成本和互通性的考慮，使用 NDI 通常更可取，除非現有元件無法實現設計特性。

6) 完善或定義系統元素之間以及與外部實體之間的介面。

註10：在系統架構定義過程中，根據架構意圖和理解所需的等級或範圍，識別和定義介面。在設計定義過程中，根據系統元素與其他系統元素以及外部實體（例如系統之系統 (SoS) 的組成系統）的設計特性、介面和交互，對介面進行完善。可能需要識別和定義一些在系統架構定義過程中未涉及的其他介面。

7) 建立設計文檔。

註 11：此任務透過專用文件（取決於實現技術）正式化系統元素的設計特性。文件範例包括資料手冊（電子元件）、資料庫（軟體）、文件（操作員角色）和可匯出資料檔案（機械元件）。

8)記錄設計。

註 12：這包括以可用於採購或實現構成系統的系統元素的形式記錄設計描述。

c) 評估系統設計。此活動包含以下任務。

註 13：此設計評估活動可為驗證過程提供有用的資訊。

1) 根據從預期設計屬性和特徵中製定的標準，分析每個系統設計方案。

2) 評估每個系統設計方案滿足利害關係人需求和系統需求的程度。

註 14：評估包括與預期應用相關的任何風險。

註 15：設計適用性包括考慮整合的便利性、操作的易用性、維護的便利性以及最終的系統處置。

3) 將分析和評估結果綜合起來，形成整體評估，以選擇最佳的系統設計方案。

d) 管理設計定義的結果。此活動包含以下任務。

1) 就設計達成一致意見。

2) 將設計特性對應到系統元素。

註 16：此任務旨在建立詳細設計特性與系統架構的架構實體之間的可追溯性。

註 17：這有助於向系統架構定義過程提供回饋，以便根據需要修改系統元素的實體佈局，從而獲得符合父系統架構預期、滿足利害關係人關注的架構特性（例如模組化、可用性、互通性、安全性）。

3) 記錄關鍵設計決策及其理由。

註 18：理由包括有關主要實現選項和使能因素的資訊。

4) 維護系統設計的可追溯性。

註 19：在整個生命週期中，設計特性與架構實體、已識別的介面、分析結果、驗證方法或技術以及系統元素需求之間保持雙向可追溯性。

5) 提供已選定用於基線的關鍵工件。

註 20：配置管理過程用於建立和維護配置項和基準。設計定義過程確定基線候選方案，並將相關工件提供給組態管理。

#### 6.4.6 系統分析過程

##### 6.4.6.1 目的

系統分析過程的目的是為技術理解提供嚴謹的數據和資訊基礎，以輔助整個生命週期中的決策和技術評估。

系統分析涵蓋各種不同的分析功能、複雜度和嚴謹程度。它用於為各種技術評估和分析需求提供輸入，這些需求涉及運行概念、需求值確定、需求衝突解決、替代架構或系統元素評估、性能和風險分析以及工程策略（整合、驗證、確認和維護）評估。分析的正式性和嚴謹性取決於所需資訊或所支援工件的關鍵性、可用資訊/資料量、專案規模以及結果交付進度。

註1：此過程通常與決策管理、專案評估與控制、風險管理過程結合使用。

註2：典型方法包括數學分析、建模、模擬、實驗和其他技術，用於分析技術性能、系統行為、可行性、經濟性、關鍵品質特性、系統狀態 (SoS) 考慮因素、技術風險、生命週期成本，並對生命週期各階段參數的潛在值範圍進行敏感度分析。

##### 6.4.6.2 成果

系統分析過程成功執行後，將達成以下目標：

a) 辨識所需的系統分析；

b) 驗證系統分析的假設和結果；

c) 提供系統分析結果，以滿足決策或技術評估需求；

d) 提供系統分析所需的支援系統或服務；

e) 建立系統分析結果的可追溯性。

##### 6.4.6.3 活動與任務

以下活動和任務應根據組織關於系統分析過程的適用政策和程序執行。

a) 準備系統分析。此活動包含以下任務：

1) 定義系統分析策略。

2) 確定需要進行系統分析的問題或疑問。

註1：這包括技術與功能目標、關鍵品質特性、各種屬性、技術成熟度、製造成熟度、技術風險等。問題陳述或疑問分析需要解答的問題對於確定分析目標以及預期結果及其效用至關重要。

3) 識別系統分析的利害關係人。

4) 定義系統分析的範圍、目標和精確度。

註2：必要的精度（準確度或精確度）是決定適當嚴謹程度的重要因素。

5) 選擇系統分析方法。

註3：方法的選擇取決於時間、成本、精確度、技術驅動因素和分析的關鍵性。分析方法的嚴謹程度各不相同，包括專家判斷、粗略估算、電子表格計算、歷史資料和趨勢分析、工程模型、模擬、視覺化和原型設計。由於成本和進度限制，組織通常只針對關鍵特性進行系統性分析。

6) 識別並規劃支援系統分析所需的必要啟用系統或服務。

註4：這包括識別使能系統的需求和介面。系統分析啟用系統包括支援分析所需的工具、相關模型和潛在資料儲存庫。所選方法將是決定哪些工具適合支援分析的重要因素。這也包括確定相關模型和數據的可用性。

7) 取得或取得所用啟用系統或服務的存取權限。

註5：驗證過程用於客觀確認使能系統是否實現了其預期功能。

8) 辨識並驗證假設。

註6：假設的驗證是一個持續的過程。如果假設隨著時間的推移而發生變化或被確定為不正確，則需要修訂分析。

9) 規劃並收集分析所需的資料和輸入。

註7：資料的來源、品質和有效性對於分析的發展和執行至關重要。需要建立分析所需資料的可信度標準。審查資料和輸入的品質和有效性（即可信資料）。使用權威來源。

b) 執行系統分析。此活動包含以下任務：

1) 應用選定的分析方法執行所需的系統分析。

2) 審查分析結果的品質和有效性。

註 8：分析結果與先前完成的相關分析相協調。審查將確定結果的可信度。

3) 得出結論和建議。

註 9：確定並邀請相關領域的專家和利害關係人參與此任務。

4) 記錄系統分析結果。

c) 管理系統分析。此活動包含以下任務：

1) 維護系統分析結果的可追溯性。

註 10：在整個生命週期中，系統分析結果與任何系統定義項（分析結果用於支援決策或提供依據，例如系統需求值、架構方案）之間保持雙向可追溯性。這通常可以透過適當的資料儲存庫來實現。可信任資料包括維護用於分析的資料的可追溯性此要求。

2) 提供已選定用於基線的關鍵工件。

註 11：配置管理流程用於建立和維護配置項目和基準。系統分析流程識別基線候選項，然後將工件提供給組態管理。對於系統分析流程，分析結果或報告是典型的基準工件。

#### 6.4.7 實作流程

##### 6.4.7.1 目的

實現流程的目的是實現指定的系統元素。

此流程將需求、架構和設計（包括介面）轉化為根據所選實現技術的實踐，並運用適當的技術專長或學科來創建系統元素的操作。此流程最終會產生滿足指定系統需求（包括分配需求和衍生需求）、架構和設計的系統元素。

對於需要製造的系統元素，在系統元素的定義細化到可以建構的程度後，根據系統元素定義和所需的生產率，制定或調整製造方法或流程。系統元件的製造隨後在品質控制和生產最佳化的框架下進行。

註1：當需要生產大批量產品時，高效率的製造方法至關重要。在這種情況下，首批產品的驗收通常與以下情況有所不同：批量生產。

註2：實施適用於概念、開發與生產階段的各個要素。生產可以包括單一要素的製造或批量生產。

##### 6.4.7.2 成果

成功完成實施過程後，將達成以下目標：

a) 辨識影響需求、架構或設計的實施限制；

b) 實現系統要素；

c) 提供實施所需的支援系統或服務；

d) 辨識實施結果和異常情況；

e) 建立可追溯性。

##### 6.4.7.3 活動與任務

以下活動和任務應根據組織適用的政策和程序，針對實施過程執行。

a) 實施準備。此活動包含以下任務。

1) 制定實施策略。

註1：實施策略包括建構新要素、取得新要素以及重複使用現有要素（無論是否進行修改）。如果策略是重複使用，則項目需確定重複使用系統元素的範圍、來源和適用性。實施策略包括程序、製造流程、工具和設備、公差以及驗證不確定性。對於重複實施系統元素的情況（例如，大量生產、更換系統元素），需定義程序和製造工藝，以實現一致且可重複的生產性。

註2：實施策略通常涉及協定流程，或需要包括專門的生命週期開發和支援環境在內的支援系統和服務。

2) 確定實施對系統需求、架構和設計特性或實施技術的限制和目標。

註3：限制包括所選實施技術的當前或預期限制、採購方提供的用於適配的材料或系統元素，以及使用所需實施支援系統所帶來的限制。

3) 確定並規劃支持實施所需的必要支援系統或服務。

註4：這包括確定支援系統的需求和介面。

4) 取得或取得所需系統或服務以及資料的存取權限。

註5：驗證過程用於客觀確認整合使能系統（包括工具）是否實現了其預期的使能功能。

b) 執行實施。此活動包括以下任務。

註6：在整個實施過程中，驗證過程用於客觀地確認系統元素是否符合要求以及產品品質特性。確認過程用於客觀地確認該元素是否已準備好在其預期運作環境中使用，並符合利害關係人的要求。

1) 根據策略、約束條件和已定義的實施程序，實現或調整系統元素。

註7：此過程使用實施使能系統和指定的資源完成。實現系統元素可以包括開發或取得。調整包括對重複使用或修改的系統元素進行配置。實現或調整應遵循適用的安全、安保、隱私、品質、環境準則或法規以及相關實施技術的實務。

註8：系統要素可以包括以下內容。

a) 硬體：硬體要素可以是採購的，也可以是製造的。硬體要素的製造採用與所選物理實現技術和材料相關的適用技術。 ISO 22400系列標準規定了適用於製造系統的關鍵性能指標 (KPI) 的要求。

b) 軟體：以軟體形式實現的系統要素可以是採購的，也可以是開發的。 ISO/IEC/IEEE 12207適用於以軟體形式實現的系統要素。

c) 服務：服務要素（包括一組待提供的服務）可以是採購的，也可以是開發的。 ISO/IEC 20000系列標準適用於以服務形式實現的系統要素。

d) 利用和支援資源：其他系統要素包括利用和支援資源，例如操作規程、維護規程以及人員和使用者訓練。

e) 原型：原型可以是採購的，也可以是製造的。通常，原型用於早期階段，以便更好地理解策略問題或機會以及解決方案空間。

2) 根據需要，將系統要素置於將來使用的狀態。

註9：系統元件受到保護，以確保其特性得以延續。輸送、包裝和儲存及其持續時間都會影響規定的保護程度。系統元素儲存時，配置和產品資訊由組態管理和資訊管理流程擷取。

3) 記錄檢出過程中系統元素滿足要求的客觀證據。

註 10：證據應依據供應協議、法規和組織政策提供。證據包括因流程變更而對元素進行的修改，或在檢出或驗證過程中發現的任何不符合項。客觀證據是系統元素已實施配置基線的一部分，該基線透過配置管理流程建立，包括單元測試、分析、檢查、演練、演示、產品或技術評審或其他驗證活動的結果。

c) 管理實施結果。此活動包括以下任務。

1) 記錄實施結果和遇到的任何異常情況。

註 11：這包括因實施策略、實施支援系統或系統定義錯誤而導致的異常情況。專案評估與控制流程用於分析數據，以識別根本原因，從而採取糾正、預防、適應、補充或完善措施，並記錄經驗教訓。

2) 維護已實施系統元素的可追溯性。

註 12：已實施的系統元素與系統架構、設計和系統需求（包括實施所需的介面需求和定義）之間保持雙向可追溯性。

3) 提供已選定的基線關鍵工件。

註 13：配置管理流程用於建立和維護配置項目和基準。實施流程識別基線候選項，然後將工件提供給組態管理。對於實施流程而言，系統元素是典型的基線工件。

#### 6.4.8 整合流程

##### 6.4.8.1 目的

整合流程的目的是將一組系統元素整合到一個滿足系統需求的已實現系統中。

此流程包括規劃、準備和逐步整合更完整的系統元素或工件集。識別並啟動接口，以實現互通，並隨後驗證和確認系統元素或工件的需求（包括特性），確保其符合預期。此過程還將SoI與直接互動的使能系統連接並檢查介面。

註：整合過程的詳細描述請參閱ISO/IEC/IEEE 24748-6。

##### 6.4.8.2 成果

成功完成整合過程後：

a) 辨識影響系統需求、架構或設計（包括介面）的整合限制；

b) 定義正確啟動已識別介面和系統功能的方法和檢查點；

c) 提供整合所需的啟用系統或服務；

d) 整合由已實現的系統元素或工件組成的系統；

e) 檢查系統外部介面（系統與外部環境的介面）和系統內部介面（已實現系統元素之間的介面）；

f) 辨識整合結果和異常情況；

g) 建立整合系統元素的可追溯性。

##### 6.4.8.3 活動與任務

以下活動和任務應根據組織適用的政策和程序，針對整合過程執行。

a) 準備整合。此活動包含以下任務。

1) 在系統元素整合過程中，識別並定義介面和選定系統功能的正確啟動和完整性檢查點。

註 1：驗證過程用於對介面進行詳細驗證。

註 2：ISO/IEC/IEEE 15026 系列和 ISO/IEC 27000 提供了有關保證、完整性和安全性的資訊。在識別和定義檢查點時，通常需要考慮防偽、防篡改、系統和軟體保證以及互通性等要素。

2) 定義集成策略。

註3：整合是根據預先定義的整合策略執行的，該策略根據系統需求和系統架構定義的優先級，對不斷演進的系統元素（實際系統、概念、需求、模型、模擬、原型、流程、計劃或其他文件）的聚合順序進行排序，重點關注接口，同時最大限度地減少集成時間和成本，並提供適當的風險應對措施。

註4：此策略通常會提供後續的驗證步驟。並非一系列逐步完善的系統元素配置。它取決於系統元素的可用性，並且與故障隔離和診斷策略一致。

3) 辨識整合過程中需要納入系統需求、架構或設計的限制和目標。

註5：這包括可訪問性、整合人員的安全性、已實現系統元素集和使能器的必要介面以及介面約束等要求。

4) 辨識並規劃支援整合所需的必要啟用系統或服務。

註6：這包括識別使能系統的需求和介面。整合使能系統包括整合設施、組裝設備、訓練系統、差異報告系統、模擬器、測量設備和設施安全系統。

5) 取得或取得使能系統或服務以及所需材料的存取權限。

註7：驗證過程用於客觀確認整合使能系統（包括工具）是否實現了其使能功能的預期用途。

b) 執行整合。此活動包含以下任務。

1) 根據介面定義和整合計劃，檢查介面的可用性和一致性。

註 8：這包括 SoI 內部的介面（例如，系統元素之間，包括操作員之間的介面），以及 SoI 與外部系統或實體之間的介面（包括介面系統、啟用系統、互操作系統以及 SoI 的使用者）。

2) 採取措施解決任何一致性或可用性問題。

3) 依照計畫順序組合已實現的系統元素或工件。

4) 整合系統元素配置，直到整個系統合成完成。

5) 檢查介面、選定功能和關鍵品質特性是否達到預期結果。

註 9：此步驟在不同的整合層級重複執行多次，以確認特定介面已建立。

c) 管理集成結果。此活動包含以下任務：

1) 記錄整合結果和遇到的任何異常情況。

註10：這包括由於整合策略、整合啟用系統（包括工具）、整合執行或系統或元素定義錯誤而導致的異常。如果系統、其指定的運作環境以及任何支援利用階段的系統之間的介面存在不一致，則這些偏差會導致糾正措施或需求變更。專案評估和控制流程用於分析數據，以確定根本原因，從而採取糾正、預防、適應、補充或完善措施，並記錄經驗教訓。

2) 保持整合系統元素的可追溯性。

註11：在整合系統元素與整合策略、系統架構、設計以及利害關係人和系統需求（包括整合所需的介面需求和定義）之間保持雙向可追溯性。

3) 提供已選定用於基線的關鍵工件。

註12：配置管理流程用於建立和維護配置項和基準。整合流程識別基線候選項，然後將工件提供給組態管理。對於整合過程而言，整合策略是典型的基線工件。

#### 6.4.9 驗證過程

##### 6.4.9.1 目的

驗證過程的目的是提供客觀證據，證明系統、系統元素或工件滿足其規定的要求和特性。

驗證過程使用適當的方法、技術、標準或規則，識別任何工件（例如系統需求、架構描述或設計描述）、已實現的系統元素或生命週期過程中的異常。此過程提供必要的信息，以確定已識別異常的解決方案。

註 1：驗證過程確定「解決方案建置正確」。確認過程確定“構建了正確的解決方案”。

註 2：建立保證案例（參見 [5.10](#_bookmark88)）有助於深入了解驗證活動並展示驗證結果。

##### 6.4.9.2 結果

驗證過程成功執行後，將達成以下目標：

a) 辨識影響需求、架構或設計的驗證限制條件；

b) 驗證所需的啟用系統或服務可用；

c) 驗證系統、系統元素或工件；

d) 報告用於採取糾正措施的資料；

e) 提供客觀證據，證明已實現的系統符合要求。m 滿足需求，架構和設計均已提供；

f) 已辨識驗證結果和異常情況；

g) 已建立已驗證系統元素的可追溯性。

##### 6.4.9.3 活動與任務

以下活動和任務應根據組織適用的驗證流程政策和程序執行。

a) 驗證準備。此活動包含以下任務。

1) 確定驗證範圍和對應的驗證操作。

註 1：範圍包括將根據適用需求、特性或其他屬性進行驗證的系統、系統元素、工件或資訊項目。對於每個驗證操作，策略應描述將要驗證的內容（實際系統、模型、樣機、原型、程序、計劃或其他文件）、驗證方法以及根據成功標準定義的預期結果。

2) 確定可能限制驗證操作可行性的限制條件。

註2：限制條件包括技術可行性、成本、時間、驗證啟用工具或合格人員的可用性、合約約束以及任務關鍵性等特性。

3) 為每項驗證行動選擇適當的驗證方法和相關的成功標準。

註3：驗證方法包括：檢查（包括同儕審查）、分析（包括建模、模擬和類比/相似性分析）、演示和測試。根據系統類型、被驗證專案的需求、專案目標和可接受的風險，選擇一種或多種驗證方法。所選方法和成功標準需與相關利害關係人協調，以確保驗證策略的可接受性。

4) 定義驗證策略。

註4：定義驗證策略包括權衡待驗證內容（範圍）與限制條件或限制，並推導出要使用的驗證行動。對於可能被刪除的驗證行動，需評估其撤回所帶來的風險。優先驗證策略涵蓋了針對每項驗證操作的最合適驗證方法，以及根據所選驗證方法所需的驗證支援系統（模擬器、測試平台、合格人員、場地、設施等）。在某些監管情況下，該策略可以包括對所有系統元素的驗證。該策略還識別系統生命週期中任何需要提供證據證明系統滿足其要求的節點。

註5：驗證策略和進度計畫會根據專案進度進行更新；特別是，當發生意外事件或系統演變時，計畫的驗證操作會重新定義或重新安排。

註6：此策略通常著重於最大限度地降低成本、進度和/或風險，從而提供一種平衡的方法來確認系統或系統元素是否「正確建構」。

5) 從驗證策略中辨識出需要納入系統需求、架構和設計的限制和目標。

註7：這包括驗證支援因素帶來的精確度、不確定性或可重複性方面的實際限制；相關的測量方法；系統整合程度；以及與支援因素的可用性、可近性和互連性。 6) 識別並規劃支援驗證所需的必要啟用系統或服務。

註8：驗證使能系統包括驗證設備、模擬器、測試自動化工具、設施等。

7) 取得或取得用於支援驗證的啟用系統或服務的存取權限。

註9：使能系統的取得方式多種多樣，例如租賃、採購、開發、再利用、分包；通常，取得全套啟用系統是這些方式的混合。驗證過程用於客觀地確認驗證使能系統是否實現了其預期的使能功能。

b) 執行驗證。此活動包含以下任務。

1) 定義驗證程序，每個程序支援一項或一組驗證操作。

註10：程序應明確驗證的目的和成功標準（預期結果）、要應用的驗證方法、必要的使能系統（設施、設備等）以及執行每個驗證程序的環境條件（資源、合格人員等）。

2) 執行驗證程序。

註 11：根據驗證策略，驗證將在計畫中的適當時間進行。驗證活動將在系統生命週期的適當階段執行。在已定義的支援系統和資源的環境中執行驗證操作。驗證操作包括：取得驗證程序執行結果，將所得結果與根據成功標準定義的預期結果進行比較，並推斷所提交元素的正確程度和結果的置信度。是否需要重複驗證操作取決於異常情況的解決。

c) 管理驗證結果。此活動包含以下任務：

1) 記錄驗證結果和遇到的任何異常情況。

註 12：這包括由於驗證策略、驗證支援系統、驗證操作的執行或系統定義錯誤而導致的異常情況。專案評估和控制流程用於分析數據，以確定根本原因，從而採取糾正、預防、適應、補充或完善措施，並記錄經驗教訓。

註 13：專案評估和控制流程中對驗證結果的評估以及後續糾正措施可能因驗證目的的不同而有很大差異。對於系統元素而言，這可能意味著採取簡單的故障排除措施來解決系統元素驗證失敗的問題，然後進行重新驗證；也可能意味著採取更重要的措施，例如基於未能達到關鍵里程碑（例如系統測試失敗）而對專案進行重大調整。

2) 記錄驗證期間的運行事件和問題，並追蹤其解決情況。

註 14：問題解決透過品質保證和專案評估與控制流程進行。對需求、架構、設計或系統元素的任何實際變更均在其他技術流程中完成。

註 15：運行事件是指在運作環境中發生的事件。

3) 取得審批機構的同意，確認系統、系統元素或工件符合規定的要求。

4) 維護驗證的可追溯性。

註 16：在已驗證的系統元素與驗證策略、系統架構、設計和系統需求之間維護雙向可追溯性。已驗證系統、系統元素或工件的可追溯性通常包括可追溯的驗證結果或證據，例如異常、偏差或需求滿足情況。

5) 提供已選定用於基線的關鍵工件。

註 17：配置管理流程用於建立和維護配置項目和基準。驗證流程識別基線候選項，然後將工件提供給組態管理。對於驗證流程，驗證策略是典型的基線工件。

#### 6.4.10 過渡流程

##### 6.4.10.1 目的

過渡流程的目的是使系統具備在運作環境中提供利害關係人需求所指定服務的能力。

此流程以有序、規劃的方式將系統遷移到目標環境中，使其能夠在目標環境中運行，該環境可能是新的或已變更的環境，例如運行環境或驗證環境。過渡完成後，系統功能正常，並與環境中的其他啟用系統、介面系統和互操作系統相容。系統將安裝經過驗證的系統，以及相關的啟用系統（例如，規劃系統、支援系統、操作員訓練系統、使用者訓練系統），具體定義請參閱協議。

每次系統或系統元件從一個實體或環境過渡到另一個實體或環境時，都可以使用此過渡流程。

注意：對於系統升級，通常的目標是在盡可能減少對現有運作中斷的情況下完成過渡活動。

##### 6.4.10.2 成果

成功完成過渡流程後：

a) 辨識出影響系統需求、架構或設計的過渡限制；

b) 過渡所需的使能系統或服務可用；

c) 場地準備就緒；

d) 安裝在運作環境中的系統能夠實現其規定的功能；

e) 對系統使用和支援所需的操作員、使用者和其他利害關係人進行培訓；

f) 辨識出過渡結果和異常情況；

g) 已安裝的系統已啟動並準備就緒；

h) 已建立過渡元素的可追溯性。

##### 6.4.10.3 活動與任務

以下活動和任務應根據適用的組織政策和程序，針對過渡流程執行。

a) 過渡準備。此活動包含以下任務。

1) 制定過渡策略。

註1：過渡策略涵蓋從現場交付和安裝到部署的所有活動。根據協議，採用適當機制對系統進行調試，以確保系統完整性。該策略涉及所有利益相關者，包括操作人員。策略內容包括角色和職責、設施考慮、收發貨、緊急回退計劃、培訓、安裝驗收演示任務、運行準備情況審查、運行啟動、過渡成功標準、存取權限、資料權限以及與其他計劃的整合。系統調試與舊系統（如有）的退役同時進行。在這種情況下，過渡和處置流程將同時進行。

2) 識別並定義所需的任何設施或場地變更。

註2：這包括安裝或使用所需的變更。

3) 識別並安排操作人員、使用者和其他利害關係人的培訓，以確保系統利用和支援。

註3：除了正式或非正式訓練外，組織變革管理活動也有助於適應過渡系統使用所需的變更。

4) 辨識過渡過程中產生的系統約束，並將其納入系統需求、架構或設計中。

5) 辨識並規劃支持過渡所需的必要使能系統或服務。

註 4：這包括識別使能系統的需求和介面。

6) 取得或取得所用啟用系統或服務的存取權限。

註 5：驗證過程用於客觀地確認過渡使能系統是否實現了其預期的使能功能。

7) 辨識並安排系統組件和使能系統的運輸和接收。

b) 執行過渡。此活動包括以下任務：

1) 根據安裝要求準備運行場地。

註 6：假定場地準備工作符合適用的健康、安全、保全和環境法規。

2) 將系統交付到正確的地點和時間進行安裝。

註 7：有時，交付前的中間儲存是必要的。

3) 將系統安裝到其運作環境中並與其環境進行介面連接。

註8：系統安裝包括使用必要的運作資料進行配置，並考慮運作環境或組織流程的變更。有時需要考慮資料遷移，包括將儲存在雲端資源或已儲存在雲端資源中的資料。

4) 演示系統已正確安裝。

註9：驗收測試通常在協議中定義，以證明安裝令人滿意。如果無法獲得確切的運行位置或環境，則選擇一個具有代表性的範例。特別注意實體接口，包括與虛擬資源（例如雲）提供的任何功能的接口。

5) 為操作員、使用者和其他利害關係人提供系統使用和支援所需的訓練。

6) 執行系統啟動和檢查。

註10：此任務包括執行將系統啟動至運作狀態所需的所有步驟，包括上電、儀器檢查、環境條件評估、與外部系統的連接評估以及其他準備就緒評估，所有步驟應符合操作規程和組織政策，並考慮相關法規。此任務還與驗證過程交互，以客觀地確認系統在運行環境中滿足利益相關者的需求。

註 11：此任務包括完整性檢查和技術標準符合性檢查。在識別和定義檢查點時，通常會考慮防偽、系統和軟體保障以及互通性等要素。

7) 證明已安裝的系統能夠提供其所需的功能。

註 12：根據協議規定，驗收測試可以定義相關標準，以證明系統或系統組件在安裝到運作環境並由操作人員操作後，具備提供所需功能和服務的能力。特別關注關鍵功能和邏輯接口，以確保其能夠充分應對業務流程和工作流程的變化。

註 13：這是一項運行準備任務，用於檢查功能是否已準備好進入運行狀態。驗證過程評估系統是否滿足利害關係人的需求。

8) 證明系統提供的功能能夠由支援系統持續運作。

註14：這是一項作戰準備任務，旨在檢查使能系統是否已準備好進入作戰狀態。

9) 檢查系統是否已準備好進入作戰狀態。準備就緒。

註 15：這包括功能演示、驗證活動和維護演示的結果。

10) 系統調試運行。

註 16：這包括在系統運行啟動（調試）期間為使用者和操作人員提供支援。

c) 管理過渡結果。此活動包括以下任務。

1) 記錄過渡結果和遇到的任何異常情況。

註 17：這包括由於過渡策略、過渡支持系統、過渡執行或系統定義錯誤而導致的異常情況。如果系統、其指定的運作環境以及任何支援利用階段的系統之間的介面存在不一致，則透過糾正措施或更改需求來解決偏差。專案評估和控制流程用於分析數據以確定根本原因，從而採取糾正、預防、適應、補充或完善措施，並記錄經驗教訓。

2) 記錄過渡期間的運作事件和問題，並追蹤其解決情況。

註18：問題解決透過品質保證和專案評估與控制流程進行。對需求、架構、設計或系統元素的任何實際變更均在其他技術流程中完成。

3) 維護已轉換系統元素的可追溯性。

註19：在已轉換的系統元素與轉換策略、系統架構、設計和系統需求之間維護雙向可追溯性。當系統元素發生變更時，可追溯性記錄會進行更新。

4) 提供已選定用於基線的關鍵工件。

註20：配置管理流程用於建立和維護配置項目和基準。轉換流程識別基線候選項，然後將工件提供給組態管理。對於轉換流程而言，轉換策略是典型的基準工件。

#### 6.4.11 驗證過程

##### 6.4.11.1 目的

驗證過程的目的是提供客觀證據，證明系統在使用過程中能夠滿足其業務或任務目標以及利害關係人的需求和要求，並在其預期的運作環境中實現預期用途。

驗證系統、系統元素或工件的目標是確保其能夠滿足驗證標準。驗證結果由利害關係人確認。此過程提供必要的信息，以便透過產生異常的相應技術流程來解決已識別的異常。

註 1：驗證過程確定「建構了正確的解決方案」。確認過程確定“解決方案建置正確”。

註 2：驗證也適用於在系統定義和實作過程中產生的工件（例如，需求、架構、設計、設計特性或系統元素）。

註3：建構保證案例（參見[5.10](#_bookmark88)）有助於深入了解驗證活動並展示驗證結果。

##### 6.4.11.2 成果

成功完成驗證過程後，將實現以下目標：

a) 定義驗證標準；

b) 確認利害關係人所需服務的可用性；

c) 辨識影響需求、架構或設計的驗證約束；

d) 驗證系統、系統元素或工件；

e) 驗證所需的啟用系統或服務可用；

f) 辨識驗證結果和異常情況；

g) 提供驗證成功的客觀證據；

h) 建立已驗證系統元素的可追溯性。

##### 6.4.11.3 活動與任務

以下活動和任務應根據組織關於驗證過程的適用政策和程序執行。

a) 為驗證做好準備。此活動包含以下任務。

1) 確定驗證範圍和相應的驗證措施。

註 1：範圍包括將根據適用的驗證標準進行驗證的系統、系統元素或工件。對於每項驗證措施，策略應描述驗證內容（例如，實際系統、模型、樣機、原型、流程、計劃或其他文件）、驗證方法以及根據成功標準定義的預期結果。範圍還包括評估產品或服務在其預期環境中的可預測性，以及是否允許任何可能對系統預期用途產生負面影響的非預期使用者存取。

註 2：供應商、採購方或採購方的代理人參與或執行驗證。通常情況下，責任由採購方承擔。協議中已明確規定。

2) 辨識可能限制驗證行動可行性的限制條件。

註3：約束條件包括技術可行性、成本、時間、驗證支援人員或合格人員的可用性、合約約束以及任務關鍵性等特徵。

3) 為每項驗證行動選擇適當的驗證方法和相關的成功標準。

註4：驗證方法包括：檢查、分析、類比/相似性、演示、模擬、同儕審查、測試或認證。驗證方法的選擇取決於系統的類型和用途、專案目標、法規或法律要求以及驗證行動可接受的風險。

註5：在適當情況下，應定義驗證步驟或狀態（例如，內部驗證、現場驗證、運作驗證），以逐步建立對已交付系統、已安裝系統和在役系統的一致性信心，並協助診斷遇到的任何差異。根據每項驗證操作的目的、條件和成功標準，選擇執行驗證操作所需的適當驗證方法。

4) 定義驗證策略。

註 6：定義驗證策略包括對驗證範圍與限製或限制進行權衡分析，並推斷出需要保留的驗證操作。對於可能被刪除的驗證操作，評估其撤銷所帶來的風險。優先驗證策略的製定需同時確定：每項驗證作業最適當的驗證方法；以及根據所選驗證方法確定必要的驗證支援要素（模擬器、測試平台、合格人員、地點、設施等）。

註 7：根據專案進度更新驗證策略和進度計畫；特別是，當發生意外事件或系統演變時，需要重新定義或重新安排已規劃的驗證操作。

5) 從驗證策略中識別系統約束，並將其納入利害關係人的需求和需求中，這些需求和需求將轉化為具體要求。

註 8：這包括驗證支援要素帶來的精確度、不確定性或可重複性方面的實際限制；相關的測量方法；以及可用性、可訪問性和與啟用器的互連性。

6) 識別並規劃支援驗證所需的必要啟用系統或服務。

註 9：這包括識別使能系統的需求和介面。驗證使能系統包括驗證設備、模擬器、測試自動化工具、設施等。

7) 取得或取得用於支援驗證的啟用系統或服務的存取權限。

註 10：取得啟用系統存取權限的方式多種多樣，例如租賃、採購、開發、重複使用或分包。通常，取得全套使能器需要結合多種方式。驗證過程也用於客觀地確認驗證使能系統是否實現了其使能功能的預期用途。

b) 執行驗證。此活動包括以下任務。

1) 定義驗證程序，每個程序支援一項或一組驗證操作。

註11：這包括確定成功標準（預期結果）、要應用的驗證方法、相應的驗證促成因素（設施、設備等）以及執行驗證程序的環境條件（資源、合格人員等）。

2) 執行驗證程序。

註12：執行驗證操作包括：取得驗證程序執行結果；將所得結果與成功標準定義的預期結果進行比較；推斷要素的符合程度；以及在可能的情況下，確定符合程度的可接受性（如果仍存在不確定性，即缺乏置信度）。

註13：系統驗證活動在系統生命週期的適當階段，在已定義的環境中（盡可能接近運作環境或具有代表性），由預期使用者或可接受的替代人員，以及已定義的促成因素和資源執行。審查驗證結果，以確認利害關係人所需的系統服務可用。

c) 管理驗證結果。此活動包括以下任務。

1) 記錄驗證結果和遇到的任何異常情況。

註 14：這包括由於驗證策略、驗證支援系統、驗證操作的執行或系統定義錯誤而導致的異常情況。專案評估和控制流程用於分析資料以識別異常情況。找出根本原因，以便採取糾正、預防、適應、補充或完善措施，並記錄教訓。

2) 記錄驗證期間的運行事件和問題，並追蹤其解決情況。

註 15：問題解決透過品質保證和專案評估與控制流程進行。對需求、架構、設計或系統元素的任何實際變更均在其他技術流程中完成。

3) 確認已符合驗證標準。

4) 保持驗證的可追溯性。

註 16：在已驗證的系統元素與驗證策略、任務或業務分析、生命週期概念、利害關係人需求、系統架構、設計和系統需求之間保持雙向可追溯性。已驗證的系統、系統元素或工件的可追溯性通常包括可追溯的驗證結果或證據，例如系統預期用途的偏差或實現。

5) 提供已選定用於基線的關鍵工件。

註 17：配置管理流程用於建立和維護配置項目和基準。驗證過程識別基線候選對象，並將相關工件提供給組態管理。對於驗證過程而言，驗證策略是典型的基線工件。

#### 6.4.12 運行過程

##### 6.4.12.1 目的

運作過程的目的是利用系統提供其產品或服務。

此過程確定作業系統的運作需求並分配人員，同時監控產品或服務以及操作員與系統之間的效能。為了維持產品或服務的運行，它會識別並分析與協議、利害關係人要求和組織約束相關的運作異常。

註：ISO/IEC 20000-1 詳細說明了服務管理系統的運行，包括受管運行服務的運作和改進。

##### 6.4.12.2 成果

成功執行運行過程後，將實現以下目標：

a) 辨識影響系統需求、架構或設計的運作約束；

b) 運作所需的支援系統、服務和材料均已到位；

c) 已配備訓練有素、資質合格的操作人員；

d) 已交付符合利害關係人要求的系統產品或服務；

e) 已監控系統運作期間的效能；

f) 已向利害關係人提供支援。

##### 6.4.12.3 活動與任務

以下活動和任務應根據適用於運作流程的組織政策和程序執行。

a) 運行準備。此活動包含以下任務。

1) 制定運行策略。

註1：運行策略定義了執行系統運作所需的方法、進度安排、資源和具體注意事項，通常在生命週期的早期階段製定。它通常包括：

a) 產品或服務在引進、日常運作和處置過程中的容量、可用性、進度安排和安全性；

b) 人力資源策略和資格要求；

c) 系統的發布和重新驗收標準及時間表，以便進行必要的修改，從而維持現有或增強的產品或服務；

d) 系統運作概念中運作模式的實施方法，包括正常運作和緊急運作；這可以包括關鍵運作問題的應對方法以及應對網路安全威脅和攻擊的復原能力；

e) 能夠提供性能水準洞察的運作措施。

註2：ISO 22400系列標準規定了適用於製造系統的關鍵性能指標 (KPI) 的要求。

a) 操作人員和其他在運作期間使用或接觸系統的人員的運作和職業安全策略，並考慮所有安全法規。

b) 系統運作的環境保護和永續性策略。

c) 外部條件變化（例如威脅、性能改進需求）的監測程序以及運行監測活動的結果。

2) 從運作中辨識系統限制和目標，並將其納入系統需求、架構或設計中。

註3：通常，識別以下內容會有所幫助：與營運相關的網路安全威脅；營運所需的彈性目標；以及為滿足營運需求而優先自動化的領域。

2) 識別並規劃支援營運所需的必要使能系統或服務。

註4：這包括識別使能系統的需求和介面。

3) 取得或取得啟用系統或服務的存取權限。待使用。

註 5：驗證過程用於客觀地確認運行使能系統是否實現了其預期的使能功能。

4) 確定或定義訓練和資格要求，以維持系統運作所需的人員隊伍。

5) 指派經過訓練且合格的人員擔任操作員。

註 6：培訓和資格包括了解系統在其運作環境中的情況，以及製定熟悉系統的操作流程，並提供相應的故障檢測和隔離指導。操作員的知識、技能和經驗要求指導人員選拔標準，並在相關情況下確認其操作授權。資格範圍取決於系統使用協定 (SoI) 及其運作環境。例如，在某些環境中，監管要求包括操作員認證，而在其他環境中則沒有認證要求。運行系統的培訓模式有時會影響產品或服務的可用性。

b) 執行運行。此活動包括以下任務。

1) 在預期的運作環境中使用系統。

註 7：運行策略指導系統的使用。在達成協議的情況下，當系統取代即將退役的現有系統時，應保持持續的服務能力和品質。 2) 根據需要，應用材料和其他資源來運作系統並維持其產品和服務能力。

註8：這包括硬體所需的能源、軟體所需的連接以及操作人員所需的資源。

3) 監控系統運作。

註9：這通常包括：

a) 管理對運作策略和操作規程的遵守；

b) 監控系統運作是否安全，並符合職業安全和環境保護的法律法規。

4) 使用策略中定義的措施並進行分析，以確認系統效能在可接受的範圍內。

註10：監控系統包括審查性能是否在既定閾值範圍內、定期儀器讀數是否可接受以及服務和響應時間是否可接受。操作人員的回饋和建議對於改善系統運作性能是有益的。

註11：還需根據目標和限制條件監控運作成本，並確定潛在的改善措施。

5) 辨識並記錄系統或服務效能超出可接受範圍的情況。

註12：當硬體中實現的系統元件超過其使用壽命，或系統運作環境影響操作和維護人員（包括人員流動、操作員壓力和疲勞）時，系統有時會出現性能不佳的情況。

6) 必要時執行系統應急操作。

註13：這包括以降級模式運行系統、執行回滾和恢復操作、系統關機、實施變通程序以恢復運行，或針對特殊情況採取其他模式。如有必要，操作員應執行必要的步驟以進入緊急操作，並可能關閉系統電源。應急操作應根據預先制定的此類事件程序執行。通常，這些程序會附帶一份連續性計劃。

c) 管理運作結果。此活動包括以下任務。

1) 記錄運行結果和遇到的任何異常情況。

註14：這包括由於運作策略、運作啟用系統、操作執行或系統定義錯誤而導致的異常情況。專案評估和控制流程用於分析數據以確定根本原因；以便採取糾正、預防、適應、補充或完善措施；並記錄經驗教訓。

2) 記錄運行事件和問題，並追蹤其解決情況。

註 15：問題解決透過品質保證和專案評估與控制流程進行。對需求、架構、設計或系統元素的任何實際變更均在其他技術流程中完成。

註 16：如果在運行過程中發生事件，操作員應記錄該事件，並執行已驗證的操作規程中規定的操作以恢復正常運作。

3) 保持運作的可追溯性。

註 17：維持對運作結果和工件、策略需求、系統運作概念、運作概念和利害關係人需求的雙向可追溯性。運行結果和工件的可追溯性通常包括證據、事件和問題。

4) 提供已選定用於基線的關鍵工件。

註 18：配置管理流程用於建立和維護配置項目和基準。運作流程此流程識別基線候選方案，然後將工件提供給組態管理。

d) 支持利害關係人。此活動包含以下任務：

1) 根據要求向利害關係人提供協助和諮詢。

註 19：提供協助和諮詢包括提供或推薦培訓、文件、漏洞修復、網路安全報告以及其他支援產品或服務有效使用的資源。

2) 記錄和監控支援請求及其後續行動。

3) 確定交付的產品或服務在多大程度上滿足了利害關係人的需求。

註 20：分析結果，並確定恢復或修改系統或服務以持續提升顧客滿意度所需的措施。盡可能讓利害關係人或其代表就此類措施的益處達成一致。客戶滿意度數據也作為品質管理流程的輸入。

#### 6.4.13 維護流程

##### 6.4.13.1 目的

維護流程的目的是維持系統提供產品或服務的能力。

此流程監控系統交付產品或服務的能力，記錄事件以供分析，採取糾正、預防、適應、補充和完善措施，並確認能力已恢復。此流程包括所需替換系統組件的包裝、搬運、儲存和運輸。這通常是為了支援整合和過渡流程的目標，包括必要的系統和軟體保障。

維護需求可能由多種原因引起，而不僅僅是故障，例如介面系統或基礎設施的變更、不斷演變的安全威脅，以及系統組件和啟用系統在系統生命週期內的技術過時。

注意：有關軟體維護的更多詳細信息，請參閱 ISO/IEC/IEEE 14764。

##### 6.4.13.2 成果

成功執行維護流程後，將達成以下目標：

a) 辨識影響系統需求、架構或設計的維護和物流限制；

b) 提供維護和物流所需的使能系統或服務；

c) 提供替換、修復或修訂後的系統組件；

d) 報告所需的維護和後勤措施；

e) 確定故障和生命週期數據，包括相關成本。

##### 6.4.13.3 活動與任務

以下活動和任務應根據適用的組織政策和程序，針對維護流程執行。

a) 為維修和後勤做好準備。此活動包含以下任務。

1) 制定維護策略。

註1：維護策略（也稱為維護概念）定義了為滿足運行可用性要求而執行維護所需的方法、優先順序、計劃、資源和具體考慮因素。它通常包括：

a) 為確保產品或服務在運作環境中持續運作以實現客戶滿意度而製定的糾正性、預防性、適應性、補充性和完善性維護策略；

b) 為降低系統故障的可能性而不造成不必要的服務損失或對正常運作造成影響（例如，暫停或限制產品或服務）而製定的計劃性預防性維護措施；

c) 確保不符合規定品質、來源和功能要求的採購材料和系統元件（例如仿冒品）不會被引入系統的方法。

d) 進行維修、更換和恢復所需的技能和人員水平，並考慮維護人員需求以及任何與健康與安全、安保和環境相關的法規；

e) 能夠深入了解性能水準、有效性和效率的維護措施。

註2：在大多數情況下，擴展功能、中期升級或傳統系統的演進會成為一個新的系統開發項目，該項目將應用適用的生命週期內流程集。

註3：以可靠性為中心的維護 (RCM) 是一種經濟高效的維護策略，旨在解決設備故障的主要原因[以故障模式、影響及嚴重性分析 (FMECA) 和故障樹分析為支撐]。它提供了一種系統化的方法，用於定義由經濟高效的任務組成的日常維護計劃，以保持重要功能。 SAE JA1011 提供了詳細資訊。基於狀態的維護 (CBM) 是一種透過減少系統在進行例行或糾正性維護期間的不可用時間來提高系統可靠性的策略。

註 4：ISO 18435 系列標準規定了一系列方法。r 用於將診斷、能力評估和維護應用程式與生產、控制和其他製造作業中的其他應用程式整合。

2) 定義後勤策略。

註 5：後勤策略定義了在整個生命週期中執行後勤所需的方法、計畫、資源和具體考慮因素。它通常包括：

a) 購買後勤，以協助確保在開發階段早期就考慮可維護性的影響；

b) 運行後勤，以幫助確保在整個使用和支援階段，在正確的時間和地點提供數量和適當品質的必要材料和資源；

c) 待儲存的替換系統元件的數量和類型、它們的儲存位置和條件、它們的預期更換率以及它們的儲存壽命和更新頻率。

3) 確定要納入系統需求、架構或設計的維護或後勤方面的限制和目標。

註 6：這些限制和目標通常源自於以下需求：

- 重複使用現有的維護支援系統；

- 重複使用現有的可替換系統元件並適應補給限制；

- 在特定地點或環境中進行維護；或

- 增強或簡化現有維護活動。

4) 確定權衡取捨，使系統及相關維護和後勤措施能夠提供經濟、可操作、可支援且可持續的解決方案。

註7：系統分析和決策管理流程用於執行評估和權衡決策。

5) 識別並規劃支援維護和後勤所需的必要啟用系統、產品或服務。

註8：這包括識別使能系統的需求和介面。

6) 取得或取得所用啟用系統或服務的存取權限。

註9：驗證流程用於客觀地確認維護使能系統是否實現了其使能功能的預期用途。

b) 執行維護。此活動包括以下任務。

1) 監控和審查利害關係人的需求以及事件和問題報告，以確定未來糾正性、預防性、適應性、補充性或完善性維護需求。

註10：運作過程中系統監控產生的異常、事件和問題是觸發維護措施的主要因素。

2) 記錄維護事件和問題，並追蹤其解決情況。

註11：如果在維護過程中發生事件，維護人員應記錄該事件，並依照已驗證的維護程序執行規定的操作。

註12：維護問題的識別和解決透過品質保證和專案評估與控制流程進行。

3) 分析維護措施所引入的變更對系統和系統元素的影響。

註13：系統和系統元素的變更可能包括資料結構、資料、相關功能、文件和介面。

註14：審查和分析通常包括以下因素：維護措施的類別；修改規模；涉及的成本；修改所需時間；以及對性能、安全或安保的影響。

4) 如果遇到導致系統故障的故障，應將系統恢復到運作狀態。

註15：有時，在故障原因修正之前，系統無法恢復到完全運作狀態。在這種情況下，系統將恢復到符合應急計畫的降級模式。

註16：通常，在恢復系統時，會考慮網路安全因素，以將惡意威脅降低到可接受的程度。

5) 修正異常（缺陷、錯誤和故障），更換或升級系統組件。

註17：對於隨機系統故障，故障將被隔離到計畫的系統組件更換、維修、修訂或重新配置等級。然後，對系統組件執行糾正措施，並驗證系統效能是否正確。記錄操作以估算可降級系統組件的使用壽命。

6) 在故障發生之前，透過更換、升級或維修系統組件來執行預防性維護。

7) 根據需要執行適應性維護、附加維護或完善性維護。

註18：適應性維護、附加維護和完善性維護通常涉及系統需求、架構或設計的變更。可能需要啟動一個新專案來修改現有系統。如果需要，專案組合管理流程可以作為啟動開發階段工作的起點。

c) 執行後勤支援。此項活動包含以下任務。

註 19：後勤保障行動能夠達成以下目標：為維持系統運作就緒狀態，需要採取以下措施。這些措施包括人員配備、物資供應、支援設備、技術資料需求（使用者文件）和商定的資料權限、培訓支援、通訊、設備/計算資源支援以及設施等方面的保障措施。

1) 執行採購後勤。

註20：採購後勤在定義系統需求的同時，也考慮系統的可維護性需求。這包括進行分析，以確定影響系統初始設計或在使用過程中規劃備件和維修更具成本效益。這還包括驗證在系統預期壽命期間，針對所選硬體和軟體，供應商是否能夠提供支援和技術更新。這些決策通常受可用性要求的限制，並影響供應鏈管理和承諾。採購後勤方面的考慮因素包含在協議流程最終形成的協議中。在開發階段也會考慮可維護性的影響。

2) 執行運轉後勤。

註21：運轉後勤是指在整個運轉壽命期間，對系統需求和使能系統進行同步調整，以確保系統功能的有效和高效交付。它還包括採取必要措施，以確保在正確的時間和地點提供數量和適當品質的必要材料和資源。

3) 實施生命週期內所需的後勤措施。

註22：這通常包括包裝、搬運、儲存、運輸、安裝、監控和通訊。

4) 確認後勤措施已實施。

註23：後勤措施可以包括滿足所需的補給水平，以確保儲存的系統元件滿足維修速度和計畫進度。這可能包括監控備件的品質和可用性、運輸以及儲存期間的完整性。後勤措施還可以包括滿足保障性要求，以實現作戰準備狀態。這可能包括人員配備、物資供應、保障設備、技術資料需求（手冊、說明、清單等）、人員和培訓、設備/計算資源以及設施。

d) 管理維護和後勤結果。此項活動包括以下任務。

1) 記錄維護和後勤結果以及遇到的任何異常情況。

註24：這包括由於維護策略、維護支援系統、維護和後勤執行或系統定義錯誤而導致的異常情況。專案評估和控制流程用於分析數據以識別根本原因；以便採取糾正、預防、適應、補充或完善措施；並記錄經驗教訓。

2) 記錄維護和後勤事件及問題，並追蹤其解決情況。

註25：問題解決透過品質保證和專案評估與控制流程進行。對需求、架構、設計或系統元素的任何實際變更均在其他技術流程中完成。

3) 識別並記錄事件、問題以及維護和後勤措施的趨勢。

註26：這用於向運行和維護人員以及創建或使用類似系統實體的其他項目提供資訊。

註27：事件和問題報告（包括採取的後續措施）透過品質保證流程的事件和流程管理活動進行追蹤（[6.3.8.3](#_bookmark110)）。

4) 維護和物流的可追溯性。

註 28：維護、物流、系統元素和生命週期工件之間保持雙向可追溯性。

5) 提供已選定的關鍵基線工件。

註 29：配置管理流程用於建立和維護配置項目和基準。維護流程識別基線候選項，然後將工件提供給組態管理。例如，維護計劃和生命週期支援計劃。

6) 監控客戶對系統、維護和物流的滿意度。

註 30：客戶滿意度資料用於品質管理流程。 ISO 10004 包含監控和衡量顧客滿意度的指南。

#### 6.4.14 處置流程

##### 6.4.14.1 目的

處置流程的目的是終止系統元件或系統在特定預期用途下的存在，妥善處理已更換或已報廢的元件，妥善處理所有廢棄物，並妥善滿足已確定的關鍵處置需求（例如，根據協議、組織政策或出於環境、法律、安全或安保方面的考慮）。

此流程用於停用系統拆解、拆卸並移除系統或其任何組件，使其不再用於特定用途。系統處理所有廢棄物，將其送至最終狀態，並將環境恢復到原始狀態或可接受的狀態。廢棄物可能來自生命週期的任何階段，例如製造過程中產生的廢料。該流程以環保的方式銷毀、儲存或回收系統組件和廢棄物，並符合相關法律法規、協議、組織約束和利害關係人的要求。處置包括防止過期、不可重複使用或不合格的組件重新進入供應鏈。必要時，系統會保存記錄，以便監測操作人員和使用者的健康狀況以及環境安全。當系統的一部分將以修改後的形式繼續使用時，處置流程有助於確保妥善處理待處置部分。

註1：處置流程旨在適用於系統的整個生命週期，包括概念和開發階段的原型處置、生產階段的廢棄物處理、使用和支援階段的改造元件退役，以及最終在退役階段將系統從服務中移除。

註2：在退役階段，處置流程可用於在系統生命週期結束時處置系統；或者，如果系統仍然可用，則可用於管理其從當前生命週期到新生命週期的過渡，無論是在組織的不同部門還是轉移到不同的組織。

##### 6.4.14.2 成果

成功執行處置流程後，將達成以下目標：

a) 將處置約束視為需求、架構、設計和實施的輸入；

b) 提供處置所需的支援系統或服務；

c) 依安全要求銷毀、儲存、回收或循環利用系統元件或廢棄物；

d) 將環境恢復到原始狀態或約定的狀態； e) 處置行動和分析記錄可供查閱。

##### 6.4.14.3 活動與任務

以下活動和任務應根據組織適用的處置流程政策和程序執行。

a) 準備處置。此活動包括以下任務。

1) 為系統制定處置策略，包括每個系統組件及其產生的任何廢棄物。

註1：此策略定義了以下的計畫、行動和資源：

a) 永久終止系統的功能和服務交付；

b) 將系統轉換為或使其保持在社會和物理上可接受的狀態，從而避免對利害關係人、社會和環境造成後續不利影響；

c) 考慮適用於處置行動以及最終產生的實物和資訊的長期狀況的健康、安全、安保和隱私問題；

d) 考慮以修改或調整後的形式將系統過渡到未來使用，包括遺留系統遷移。

2) 確定處置對系統需求、架構和設計特性或實現技術的限制和目標。

註2：這包括拆卸問題，包括其相關的支援系統、儲存地點的取得和可用性以及可用的技能等級。

3) 識別並規劃支援處置所需的必要支援系統或服務。

註3：這包括識別支援系統的需求和介面。

4) 取得或取得將要使用的支援系統或服務的存取權限。

註4：驗證過程用於客觀確認處置支持系統是否實現了其預期的功能。

5) 如果系統需要存儲，則需明確密封設施、儲存地點、檢查標準和儲存期限。

6) 制定預防措施，防止不應再利用、回收或再使用的已處置零件和材料重新進入供應鏈。

b) 執行處置。此活動包括以下任務：

1) 使系統或系統部件失效，以便進行移除。

註5：應考慮與其他系統的接口，例如，根據拆卸說明斷開電源或燃料，並遵守相關的健康、安全、保全和隱私法規。當對SoI進行技術或功能升級時，僅停用並移除受影響的系統元件。這適用於SoI在概念或開發階段的原型。

2) 將系統、系統元件或廢棄物停止使用或生產，以便進行適當的處置和處理。

註6：處置包括再利用、回收、翻新、大修、銷毀或轉入其他生命週期。前提是處置和後續行動均依照相關的安全、安保、隱私和環境標準、指示和法律執行。系統中仍具有使用壽命的組件，無論其處於當前狀態還是經過大修或改造後，都會轉移到其他相關系統或轉移到其他組織的生命週期中。在適當情況下，系統組件將被翻新以延長其使用壽命。服務和訂閱（包括基於雲端的資產）將被釋放或停止。操作人員將被重新分配、重新部署或退休。此任務包括從生產或其他階段清除廢棄物。

3) 將受影響的操作人員從系統或系統元件中撤出，並記錄相關的操作知識。

註7：此操作應依照相關的安全、安保、隱私和環境標準、指示和法律執行。此行動旨在保護操作人員所掌握的知識和技能。這可能與知識管理流程有關。

4) 將系統或系統組件拆解成易於處理的零件，以便於移除，進行再利用、回收、翻新、大修、存檔或銷毀。

5) 妥善處理不打算再利用的系統組件及其零件，確保它們不會重新進入供應鏈。

6) 根據需要銷毀系統組件，以減少廢棄物處理量或使廢棄物更易於處理。

註8：此項活動包括取得必要的銷毀服務，以便根據需要熔化、破碎、焚燒、拆除或清除系統或其組件。

c) 完成處置。此項活動包括以下任務：

1) 確認處置後不存在任何有害的健康、安全、保全和環境因素。

2) 將環境恢復到原始狀態或協定規定的狀態。

3) 辨識並記錄有關已處置系統或系統組件的資訊。

註9：資訊包括系統生命週期內收集的處置記錄，以便在出現對健康、安全、安保和環境的長期危害時進行審計和審查；維護處置物流（方法和地點）方面的知識；並使未來的系統創建者和用戶能夠根據經驗建立知識庫。此資訊提供處置的可追溯性。

4) 提供已選定用於基線的關鍵工件。

註10：配置管理流程用於建立和維護配置項目和基準。處置流程識別基線候選項，然後將工件提供給組態管理。例如，處置計劃和記錄。

# 附錄A（規範性）客製化流程

### A.1 總則

本附件規定了本文檔所包含流程的客製化要求。

註1：客製化並非符合本文檔的必要條件。事實上，如果要聲稱“完全符合”，則不允許進行自訂。如果提出「自訂符合性」的聲明，則應用此流程進行客製化。

註 2：有關客製化的更多指導，請參閱 ISO/IEC/IEEE 24748-1 和 ISO/IEC/IEEE 24748-2，它們提供了生命週期過程應用的指南。

### A.2 自訂流程

#### A.2.1 目的

客製化流程的目的是調整本文件中包含的生命週期流程，以滿足以下特定情況或因素：

a) 與在協議中使用本文件的組織相關的情況或因素；

b) 影響為履行引用本文件的協議而必須進行的項目；

c) 反映組織提供產品或服務的需求。

#### A.2.2 結果

成功執行客製化流程後：

a) 定義修改後的或新的生命週期過程，以實現生命週期模型的目的和結果。

#### A.2.3 活動與任務

如果本文檔中包含的生命週期流程需要進行客製化，則組織或專案應根據適用的客製化流程政策和程序，按需執行以下任務。

a) 辨識並記錄影響客製化的因素。這些因素包括但不限於：

1) 營運環境的穩定性和多樣性；

2) 利害關係人關注的商業或績效風險；

3) 新穎性、規模和複雜性；

4) 開始使用日期和持續時間；

5) 完整性問題，例如安全性、保全性、隱私性、可用性；

6) 新興科技機會；

7) 可用預算和組織資源狀況能力；

8) 使能系統服務的可用性；

9) 系統整個生命週期中的角色、職責、問責制和權限；

10) 是否需要符合其他標準。

b) 對於對系統至關重要的屬性，應充分考慮與關鍵性維度相關的標準所建議或強制規定的生命週期結構。

c) 徵求受調整決策影響的各方的意見。這包括但不限於：

1) 系統利害關係人；

2) 組織所達成協議的相關方；

3) 參與的組織職能部門。

d) 根據決策管理流程做出調整決策，以實現所選生命週期模型的目標和預期結果。

註1：組織在生命週期模型管理流程中建立標準生命週期模型。有時，組織可以根據待建立的生命週期模型各階段的目標和預期結果，對本文檔中的流程進行調整。

註2：專案在專案規劃過程中選擇組織已建立的生命週期模型。有時，為了實現所選生命週期模型各階段的目標和成果，需要對組織已採用的流程進行調整。

註3：如果專案直接應用本文檔，有時也需要對本文檔中的流程進行調整，以達到適當的生命週期模型各階段的目標和成果。

e) 選擇需要調整的生命週期流程，並刪除選定的成果、活動或任務。

註4：無論是否進行調整，組織和專案始終可以實施流程以實現額外的成果，或實施超出本文檔要求範圍的額外活動和任務。

註5：組織或專案有時會遇到需要修改本文檔條款的情況。由於此類修改可能會對其他流程、成果、活動或任務產生意想不到的影響，因此通常應避免進行此類修改。如有必要，可透過刪除相關條款（並做出適當的客製化符合性聲明）進行修改，並在仔細考慮後果後，實施一個流程，以實現超出定制標準範圍的額外成果或執行額外的活動和任務。

# 附錄 B（資料性） 流程工件和資訊項目範例

[表 B.1](#table-b1--sample-artefacts-and-information-items-by-process) 提供了與每個流程相關的可能工作產品集合，包括工件和資訊項目。此清單並非詳盡無遺：對於每個流程，組織可以決定制定政策、計劃、程序、報告和記錄，以展示成果或執行活動和任務。如果認為文檔量較少即可滿足要求，則可以合併資訊項。此外，組織政策和程序可以應用於每個流程和項目，或進行相應調整。表中列出了典型標題，括號內為常用替代標題範例和詳細資訊。工件是指任何類型的工作產品，包括資訊項。資訊項是指可供人類使用、向利害關係人傳達的可識別資訊集合。

註1：ISO/IEC/IEEE 15289 提供了有關資訊項的內容和管理方面的資訊。

註2：每個流程都有其策略，無論是否已形成文件。如果已形成文檔，則該文檔即成為一種成果。

**流程組**

##### 表 B.1 — 依流程劃分的範例工件與資訊項

**流程 典型標題 類型**

**協議流程 採購流程**

供貨請求（徵求建議書、招標書） 資訊項

協議（合約） 資訊項

**供應流程**

採購記錄和報告（採購方法、協議變更、供應商選擇報告、供貨驗收、交付驗收）

資訊項

供應響應（提案、投標） 資訊項

協議（合約） 資訊項

供應記錄和報告（供應方法、系統和組件交付記錄、變更請求）

資訊項

**組織專案支援流程**

**生命週期模型管理流程**

生命週期管理政策與程序 資訊項

已授權的生命週期模式和流程 工件

生命週期模型管理記錄和報告（模型和流程評估、改進）

**基礎架構**管理流程**

資訊項

基礎設施要素工件

基礎設施記錄和報告（基礎設施需求、變更請求、描述）

**專案組合管理流程**

資訊項

專案組合工件

專案授權工件

項目收尾報告資訊項

**流程組**

**表 B.1** *(續)（已使用）*

**流程典型標題類型**

專案組合管理記錄和報告（專案組合分析、評估、專案指導）

**人力資源管理流程**

資訊項

技能發展資產（訓練教材）資訊項

人力資源記錄和報告（技能需求、技能清單、訓練記錄、人員分配）

**品質管理流程**

資訊項

品質管理政策和程序資訊項

品質管理記錄和報告（標準和方法、資訊項

評估結果、糾正和預防措施報告）

**知識管理流程**

知識管理要素（資產）工件

知識資產記錄及報告資訊項

**技術管理流程專案規劃流程**

專案計劃（管理、技術和流程特定）資訊項

專案生命週期模型（客製化）工件

分解結構工件

資源請求資訊項

專案規劃記錄和報告（目標、限制、進度、預算）

**專案評估與控制流程**

資訊項

授權進入下一里程碑（記錄）資訊項

變更請求資訊項

專案評估與控制記錄和報告（專案績效資料、專案控制請求、會議記錄、評審、狀態、偏差、糾正措施）

**決策管理流程**

資訊項

決策登記表工件

決策記錄與報告（決策請求、權衡分析）

**風險管理流程**

資訊項

風險登記表工件

風險記錄和報告（概況）資訊項

**設定管理流程**

配置基線工件

組態管理記錄（偏差、變更要求、變更）

配置管理報告（狀態、評估、稽核、結果、發布）

**資訊管理流程**

資訊項資訊項

資訊項登記表工件

資訊管理記錄資訊項目和報告

**測量過程**

測量記錄表（工件）

**過程群組**

**表 B.1**（續）*

**過程 典型標題 類型**

測量記錄和報告（資訊需求、評估）

**品質保證過程**

資訊項

事件記錄和報告（資訊項目）

問題記錄和報告（資訊項目）

品質保證記錄和報告（標準和方法、評估、糾正措施）

**技術流程 通用（適用於所有技術流程）**

資訊項

使能系統需求（記錄）（工件）

可追溯性映射（工件）

**業務或任務分析流程**

生命週期概念（資訊項）

問題或機會陳述（工件） 解決方案備選方案（包含初步操作概念）（工件） 業務或任務分析報告（解決方案備選方案分析和建議）（資訊項目）

利害關係人需求和要求定義過程**

系統生命週期概念（運作、採購、支援、部署、安全性等）

利害關係人需求（關鍵績效需求、產品需求評估）

資訊項 資訊項

利害關係人需求與要求 工件

利害關係人需求和要求報告（利害關係人和需求的識別）

**系統需求定義流程**

資訊項

系統需求 工件

需求記錄（系統、系統元素） 資訊項

系統需求報告（定義、理由、變更） 資訊項

**系統架構定義流程**

架構視圖、視點和模型 工件

介面定義（初始） 工件

架構描述 工件

架構報告（評估、理由） 資訊項

**設計定義流程**

設計基線（設計特性） 工件

設計描述 工件

介面定義 工件

設計報告（設計評估、理由） 資訊項

**系統分析流程**

系統分析模型 工件

系統分析記錄和報告（評估、結果、建議）

**實施過程**

資訊項

系統元素 工件

**過程群組**

**表 B.1**（續）*

**過程 典型標題 類型**

實施記錄和報告（解決方案約束、

單元測試結果）

**整合過程**

資訊項

整合系統元素 工件

介面控制描述 工件

整合記錄和報告（差異） 資訊項

**驗證過程**

已驗證系統 工件

驗證記錄和報告（方法、標準、結果、差異）

**過渡過程**

資訊項

已準備的目標環境（運行站點） 工件

已過渡的系統/元素 工件

過渡記錄和報告（方法、約束、差異、安裝、發布方法、應急/回滾）方法）

**驗證過程**

資訊項

已驗證系統工件

驗證記錄和報告（方法、約束、差異）

**操作流程**

操作規程（使用者）文件、使用者資訊、連續性程序、安全程序）

資訊項

資訊項

客戶支援記錄（請求、問題報告）資訊項

運行記錄和報告（方法、限制、差異、監控、評估、客戶滿意度））

**維修流程**

資訊項

替換系統組件工件

維護/物流記錄和報告（方法、限制、維護/供應請求、差異）

**處置流程**

資訊項

已處置/已歸檔的系統和組件工件

處置/歸檔記錄和報告（方法、限制、

結果）

資訊項

# 附錄 C （資料性）用於評估的流程參考模型

## 概述

據了解，本文件的部分使用者希望根據 ISO/IEC 33004:2015 標準評估已實施的流程。本附件提供了一個適用於與 ISO/IEC 33004:2015 配合使用的製程參考模型。

此過程參考模型由本文件正文中的過程組成，包括每個過程的名稱、目的說明和結果說明。 [條款 C.3](#the-process-reference-model) 標識了過程參考模型中的各個過程以及定義這些過程的條款。

## 符合 ISO/IEC 33004

#### 總則

ISO/IEC 33004:2015 第 5.3 條對適用於該文件評估的過程參考模型提出了要求。 [表 C.1](#_bookmark130) 和 [C.2.3](#process-descriptions) 列出了過程參考模型的要求，並描述了本文件如何滿足這些要求。

#### 過程參考模型的要求

**表 C.1 — ISO/IEC 33004 中製程參考模型要求的實施**

|過程參考模型要求（參見 ISO/IEC 33004:2015，5.3.1）| ISO/IEC/IEEE 15288 實現 |
|----------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| a) 域聲明 | 請參閱[條款 1](#_bookmark2)。 |
| b) 過程參考模型與使用環境之間關係的描述 | 請參閱[條款 5](#_bookmark47)。 |
| c) 過程描述 | 請參閱[條款 C.3](#the-process-reference-model)。 |
| d) 過程之間關係的描述 | 請參閱[條款 C.3](#the-process-reference-model)，並在每個過程的描述中予以說明。例如，某些過程描述包含該過程包含較低層級過程的聲明。 |
|過程參考模型利害關係人群體與共識（參見 ISO/IEC 33004:2015，5.3.2）| |
| a) 利害關係人群體的特徵 | 相關利害關係人群體是本文件和 ISO/IEC/IEEE 12207 的使用者。 |
| b) 達成共識 | 本文件及 ISO/IEC/IEEE 12207 均為國際標準，符合 ISO、IEC 和 IEEE 的共識要求。 |
| c) 若未採取任何行動以達成共識，則記錄行動 | 不適用 |
| 唯一過程描述（參見 ISO/IEC 33004:2015，5.3.3）| 過程描述是唯一的。過程描述符合 ISO/IEC/IEEE 24774 的要求。 |

#### 過程描述

ISO/IEC 33004:2015 第 5.4 條規定了製程描述的以下要求：

1. 過程的描述應包含其目的和結果；
2. 過程結果集應是實現過程目的的必要且充分條件；
3. 過程描述不得包含或暗示超出符合 ISO/IEC 33003 的任何相關製程測量架構基本層面的製程品質特性。

過程結果包括：

- 產生工件；
- 狀態發生顯著變化；
- 滿足特定限制條件，例如要求、目標和目的。

[條款 6](#_bookmark90) 中的過程描述符合這些要求。某些結果可以被解讀為有助於提升至高於 1 級的能力水準。然而，相關流程的合規實施並不要求達到這些更高的能力水準。

## 流程參考模型

流程參考模型由[條款 6](#_bookmark90)中所列各流程的目標說明和結果所組成。系統生命週期的流程參考模型由[圖 4](#_bookmark77)中的流程集合所組成。

# 附錄 D（資料性附錄） 基於模型的系統和軟體工程 (MBSSE)

## MBSE 描述

MBSE 是將建模方法正式應用於支援 SoI 整個生命週期中的系統工程。

通常，在數位化環境中需要同時處理系統工程和軟體工程。因此，本附錄的範圍和內容涵蓋 MBSE 和 MBSSE。

## 基於模型的系統工程 (MBSE) 方法中的系統生命週期流程實施

本文檔提供了一個通用的系統工程流程參考模型。它提供了一套全面的流程，組織可以利用這些流程開發適用於其產品和服務的系統生命週期模型，並為生命週期過程的開發、評估、支援和改進提供框架。

採用 MBSE 可以大幅簡化這些生命週期過程的執行。 ISO/IEC/IEEE 24641 規定了一個基於模型的系統和軟體工程參考框架。在這種方法中，系統工程活動依賴不斷演進的模型，這些模型作為系統和軟體及其生命週期過程的「主要知識來源」。

本文檔中包含的系統生命週期過程集及其與支援性 ISO/IEC/IEEE 24641 參考框架的關係（作為基於模型的支援活動）包含在 ISO/IEC/IEEE 24641:2023 的附錄 A 和附錄 E 中。 MBSE 的採用和應用通常包含一系列能力和成熟度提升的里程碑，供 MBSE 實踐者參考。例如，請參閱參考文獻 [[58](#_bookmark136)]。

## MBSE 實踐

MBSE 利用建模環境將工程資料表示為模型，用於執行系統工程框架中詳述的過程，這些過程和關係在 [5.7](#_bookmark75) 至 [5.9](#_bookmark87) 中有所闡述。除了整合概念、需求、架構和設計資料外，這些模型還支援測量、專案評估和控制、系統分析、決策管理、驗證和確認流程。

這種建模方法可實現以下目標：

- 單一資料來源用於系統定義，加速資料成熟、整合和應用。這個單一資料來源使得更積極的開發進度得以實現。例如，如[5.2](#_bookmark49)所述，一個系統元素在一個上下文中可能是一個SoI（系統資訊）。在基於模型的系統工程（MBSE）中，SoI的模型可以有效地與啟用系統或互操作系統的模型集成，從而提供完整的解決方案模型。
- 支持多方利害關係人的觀點和觀點。如[5.2](#_bookmark49)所述，SoI可能需要表示為層次分解或網路。透過在MBSE中使用自訂的模型元素關係，可以使用構成SoI的相同資料集來實現這兩種表示方式。
- 透過查詢快速、全面地分析整合的基於模型的資料集，有助於確保模型的完整性和準確性，並大幅減少手動資料驗證所需的時間和引入的錯誤。

此功能大大促進了[6.4.6](#_bookmark117)中所述的規範性和嚴謹性。

## 在基於模型的系統工程 (MBSE) 環境中執行系統生命週期流程的優勢

使用 MBSE 的確可以加速系統生命週期流程。 MBSE 的一個關鍵價值在驗證和確認過程中得以體現（參見[6.4.9](#_bookmark120)和[6.4.11](#_bookmark122))。

MBSE 資料集也為運行中系統的服務支援提供了寶貴的資訊。

將 MBSE 支援活動納入系統生命週期流程所帶來的更完整益處列表，請參閱[表 D.1](#table-d1--system-life-cycle-processes-supported-by-an-mbse-environment)。

##### 表 D.1 — MBSE 環境支援的系統生命週期流程

| **MBSE 益處** | **MBSE 支援活動說明** | **本文件中的參考資訊** |
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------|
| 更深入地理解概念和系統定義 | 提供系統工程數據，增強數據的特異性、清晰度和準確解讀。 | [6.4.1](#_bookmark112) 至 [6.4.5](#_bookmark116) |
| 更佳的權衡能力 | 透過資料查詢和分析，建模能夠比人工審查資料更快捷、更全面、更準確地比較各種解決方案。可以透過查詢和分析，將各種解決方案與一組通用的需求函數和關鍵效能參數進行比較。 | [6.3.3](#_bookmark104) [6.4.6](#_bookmark117) |
| 更有效、更有效率的測量 | 與手動審查數據相比，建模能夠更快捷、更全面、更準確地收集數據，以支援對建議的SoI和系統元素解決方案進行測量和分析。可以透過查詢分析建議的解決方案，以確定解決方案在多大程度上達到了技術指標的目標值（例如，有效性指標、效能指標、技術效能指標）。 | [6.3.7](#_bookmark108) |
| 更有效地進行影響分析 | 整合系統定義資料集中的關係允許透過模型查詢快速確定系統定義變更的影響，包括系統元素內部和元素之間、介面處、整個系統定義域 (SoI) 以及系統定義域與互操作系統/使能系統之間可能的影響。 | [6.4.6](#_bookmark117) |
| 有助於確保需求的一致性和完整性 | 例如，模型分析可以快速且徹底確定需求、架構和設計是否完整地指定了系統元素；系統和系統元素是否完全滿足分配的需求和功能；以及系統介面是否已完全定義並協調一致。 | [6.4.1](#_bookmark112) [6.4.2](#_bookmark113) [6.4.3](#_bookmark114) |
| 可協助確保架構和設計的一致性和完整性 | 透過建立資料關係，建模可以更有效地整合架構和設計資料。查詢整合資料可以快速識別缺少的資料元素和模型建構錯誤。 | [6.4.4](#_bookmark115) [6.4.5](#_bookmark116) [6.4.6](#_bookmark117) |
| 實現重複使用和適應性 | 將系統工程資料以模型的形式交付，從而增強資料的特定性、清晰度和準確解釋，並促進資料的重用。基於模型的系統元素表示（模型、視圖、架構和設計模式等）的知識資產可在整個組織內利用。這些模型能夠更好地捕捉可重複使用模式的整合技術資訊。此外，這些模型還可用於探索各種方案及其影響，從而識別出能夠提高適應性的方案。 | [6.2.6](#_bookmark100) [6.4.4](#_bookmark115) [6.4.5](#_bookmark116) [6.4.6](#_bookmark117) |

**表 D.1** *(續)*

| **MBSE 優點** | **MBSE 支援活動描述** | **本文件中的參考資訊** |
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------|
| 驗證和確認活動的替代方法 |模型分析可以透過模型驗證和確認，在生產和整合實體系統組件之前檢測需求、架構和設計錯誤。經過驗證的模型允許在無法使用實際系統時，透過模擬和建模表示進行驗證和確認活動。 | [6.3.8](#_bookmark109) [6.4.9](#_bookmark120) [6.4.11](#_bookmark122) |
| 降低風險 | 模型可以分析以識別原本不明顯的技術和程序風險。此外，可以利用在模型中開發和整合的系統定義元素（需求、架構、設計、介面）來影響風險處理決策。 | [6.3.4](#_bookmark105) |
| 及早發現介面/整合問題 | 透過模型查詢，可以利用整合系統定義資料集中的關係快速確定缺失、定義不當和不相容的介面。 | [6.4.8](#_bookmark119) [6.4.4](#_bookmark115) [6.4.5](#_bookmark116) |
| 更能理解和管理依賴關係 | 將系統工程資料以模型形式交付，可以增強資料的特異性、清晰度和準確解釋，從而評估生命週期過程和技術依賴關係。 | [6.3.1](#_bookmark102) [6.3.2](#_bookmark103) |

## MBSE 中常用的模型類型

MBSE 中使用了多種模型類型，其中包括以下幾種：

1. 規範模型：用於表達採購方的需要或需求，或供應商的承諾需求。它們透過分析、驗證和優化系統架構模型來降低風險，並以數學為基礎，支援數學分析或模擬。

2. 描述性模型（有時稱為建構性模型或系統架構模型）：用於捕捉系統的行為、結構、限制、介面和需求，並作為定義產品實體及其關係的儲存庫。

3. 驗證模型：由描述性模型和規範模型提供支持，用於驗證系統架構和分析模型是否滿足客戶的需求。

4. 認知模型：用來簡化表示心理或認知過程。它們可以與虛擬實境表示結合，以表示人為因素。認知模型模擬人類的推理和問題解決過程，用於預測目的。

以上所有模型都可以根據其所代表的領域進一步分類，稱為「領域特定模型」。例如，模型可能與系統的屬性（性能、可靠性、品質特性、功耗等）、技術實現（電氣、機械、軟體、人為因素等）以及應用領域（汽車、航太、醫療、國防等）相關。

不同的抽象程度（概念模型、邏輯模型、技術模型和物理模型）和形式化程度取決於模型的用途。根據用途的不同，可以使用以下模型：

- 正式化模型用於提供可驗證的證據或直接產生系統元素（例如硬體或軟體元素）。

- 半正式化模型通常用作進一步描述或開發活動的規格。

- 當完整的正式化規範不切實際時，可以使用非正式化模型，它可以基於啟發式方法或專家判斷。

如架構描述框架所提出的，模型可以根據利害關係人的觀點或視點進行細化。它們還可以細化以反映目標實體的各個方面（參見 ISO/IEC/IEEE 42010）。此外，從業者可以使用工具支援的建模框架，根據抽象層級和覆蓋範圍組織模型。透過使用這種框架，可以產生這些模型的各種視圖，並將其打包供利害關係人使用。這種方法經濟高效，因為同一個模型通常可以反映多種視圖（根據利害關係人的觀點，在形式和詳細程度上均可不同），並且可以消除許多在純粹基於描述的視圖中可能出現的視圖間對應關係問題。

可以對模型進行驗證和確認，以預先執行系統本身的這些活動。特別是，這些活動允許評估需要和需求，根據這些需求評估系統定義，以及評估系統的品質特性。

注意：驗證和確認的附加價值取決於模型的準確性和傳真度。建模工作常常受限於對解決方案的了解程度有限，以及時間和資源的匱乏。

# 參考書目

1. ISO 9000:2015，《品質管理系統－基礎與術語》

2. ISO 9001:2015，《品質管理系統—要求》

3. ISO 9004，《品質管理－組織的品質－實現持續成功的指南》

4. ISO 9241-210，《人機互動的人體工學－第210部分：以人為中心的互動系統設計》

5. ISO 10004，《品質管理－顧客滿意度－監控與測量指南》

6. ISO 10007，《品質管理－配置管理指南》

7. ISO/IEC/IEEE 12207:2017，《系統與軟體工程－軟體生命週期過程》

8. ISO 14001，《環境管理系統－要求及使用指南》

9. ISO/IEC/IEEE 14764 *軟體工程 — 軟體生命週期流程 — 維修*

10. ISO/IEC/IEEE 15026（所有部分），*系統與軟體工程 — 系統與軟體保障*

11. ISO/IEC/IEEE 15289:2019，*系統與軟體工程 — 生命週期資訊項目的內容（文件）*

12. ISO/IEC 15408-3，*資訊安全、網路安全與隱私保護 — IT 安全評估標準 — 第 3 部分：安全保障組件*

13. ISO 15704，*企業建模與架構 — 企業參考架構與方法的要求*

14. ISO/IEC/IEEE 15939，*系統與軟體工程g — 測量過程*

15. ISO/IEC/IEEE 16085，《系統與軟體工程 — 生命週期流程 — 風險管理》

16. ISO/IEC/IEEE 16326，《系統與軟體工程 — 生命週期流程 — 專案管理》

17. ISO/TS 18152，《人機互動人體工學 — 製程評估規範》

*人機互動問題*

18. ISO 18435（所有部分），《工業自動化系統與整合 — 診斷、能力評估與維護應用整合》

19. ISO 19014-4:2020，《土方機械 — 功能安全 — 第 4 部分：控制系統安全相關部分的軟體和資料傳輸的設計與評估》

20. ISO/IEC 20000（所有部分），《資訊科技 — 服務管理》

21. ISO/IEC/IEEE 21839:2019，《系統與軟體工程－系統生命週期階段的系統之系統 (SoS) 考量*

22. ISO/IEC/IEEE 21840:2019，《系統與軟體工程－在系統之系統 (SoS) 背景下使用 ISO/IEC/IEEE 15288 的指南》*

23. ISO/IEC/IEEE 21841，《系統與軟體工程－系統之系統的分類》*

1. ISO 22400（所有部分），《自動化系統與整合－製造營運管理的關鍵績效指標 (KPI)》*

2. ISO/IEC/IEEE 24641:2023，《系統與軟體工程－基於模型的系統與軟體工程的方法與工具》*

3. ISO/IEC/IEEE 24748-1:2018，《系統與軟體工程－生命週期管理－第 1 部分：生命週期管理指南》*

4. ISO/IEC/IEEE 24748-2，《系統與軟體工程－生命週期管理－第 1 部分：生命週期管理指南》*工程 — 生命週期管理 — 第 2 部分：ISO/IEC/IEEE 15288 應用指南（系統生命週期流程）*

5. ISO/IEC/IEEE 24748-4:2016，《系統與軟體工程 — 生命週期管理 — 第 4 部分：系統工程規劃》*

6. ISO/IEC/IEEE 24748-5，《系統與軟體工程 — 生命週期管理 — 第 5 部分：》*

*軟體開發規劃*

7. ISO/IEC/IEEE 24748-6:3)，《系統與軟體工程 — 生命週期管理 — 第 6 部分：》*

*系統和軟體整合*

[28] ISO/IEC/IEEE 24748-8:2019，《系統與軟體工程 — 生命週期管理 — 第 8 部分：國防專案技術評審與審核》*

8. ISO/IEC/IEEE 24765，《系統與軟體工程 — 字彙表》*

9. ISO/IEC/IEEE 24774:2021，《系統與軟體工程－生命週期管理》

*過程描述規範*

10. ISO/IEC 25000，《系統與軟體工程－系統與軟體品質要求與評估（SQuaRE）－SQuaRE 指南》

11. ISO/IEC 25010:2011，《系統與軟體工程－系統與軟體品質要求與評估（SQuaRE）－系統與軟體品質模型》

12. ISO/IEC 25030，《系統與軟體工程－系統與軟體品質要求與評估（SQuaRE）－品質要求架構》

13. ISO/IEC/TR 25060，《系統與軟體工程－系統與軟體產品品質要求與評估（SQuaRE）－可用性通用產業格式（CIF）：可用性相關資訊的一般架構》

14. ISO/IEC 25063，《系統與軟體工程－系統與軟體產品品質要求》可用性評估 (SQuaRE) — 通用產業格式 (CIF)：使用情境描述*

15. ISO/IEC/IEEE 26531，《系統與軟體工程 — 產品生命週期、使用者和服務管理文件的內容管理》

16. ISO/IEC 26550，《軟體與系統工程 — 產品線工程與管理的參考模型》

17. ISO/IEC 26580，《軟體與系統工程 — 基於特徵的軟體與系統產品線工程方法與工具》

18. ISO/IEC 27000，《資訊科技 — 安全科技 — 資訊安全管理系統 — 概述與詞彙》

19. ISO/IEC 27036（所有部分），《網路安全 — 供應商關係》

1. 可在 [www.iso.org](http://www.iso.org/) 網站免費取得。

2. 正在編寫中。發佈時的階段：ISO/IEC/IEEE FDIS 24748-6:2023。

1. ISO/IEC/TR 29110-1:2016，《系統與軟體工程－超小型實體（VSE）生命週期概況》

第1部分：概述

2. ISO/IEC/IEEE 29148:2018，《系統與軟體工程－生命週期過程》

需求工程

3. ISO 31000，《風險管理－指南》

4. IEC 31010，《風險管理－風險評估技術》

5. ISO/IEC 33002:2015，《資訊科技—過程評估—過程評估要求》

6. ISO/IEC 33004:2015，《資訊科技—過程評估—流程參考、流程評估與成熟度模型要求》

7. ISO/IEC/IEEE 42010，《系統與軟體工程－架構描述》

8. ISO/IEC/IEEE 42020:2019，*軟體、系統與企業－架構專家流程*

9. ISO/IEC/IEEE 42030，《軟體、系統與企業架構評估架構》

10. IEC 60300-1，《可靠性管理 - 第 1 部分：管理與應用指南》

11. IEC 61508（所有部分），《電氣/電子/可程式電子安全相關系統的功能安全》

12. IEC 62741，《可靠性要求論證 - 可靠性案例》

13. ISO 指南 73:2009，《風險管理 - 字彙表》

14. ANSI/AIAA G-043B-2018，《ANSI/AIAA 運行概念文件編製指南》

15. SAE EIA-649-C-2019，《配置管理標準》

16. IEEE Std 828-2012，《IEEE 系統配置管理標準》軟體*

*工程*

17. INCOSE-MBCM-2020-001.1，《基於模型的能力矩陣與使用者指南》，版本 1.0，2020 年 1 月

18. INCOSE-TP-2003-002-5，《系統工程手冊》，《系統生命週期流程與活動指南》，2023 年

19. INCOSE-TP-2003-020-01，《技術測量》，版本 1.0，2005 年 12 月 27 日

20. INCOSE-TP-2020-002-06，《系統工程與系統定義》，版本 1.0，2020 年 1 月 8 日

21. 北約 AEP-67，《北約工程系統保障工程》

22. SAE ARP4754A *民用飛機及系統開髮指南*

23. SAE JA1011，*以可靠性為中心的維護 (RCM) 流程評估標準*

24. Tukker A. 2004，《八種產品服務系統：實現永續發展的八種途徑？ 》，

《商業策略與環境》**13**，第 246 頁

25. ANSI/AAMI/IEC 62304:2006/A1:2016，*醫療器材軟體－軟體生命週期流程*

26. ISO 13485，*醫療器材－品質管理系統－監理要求*

1. 正在編寫中。

1. PMI《工作分解結構實務標準》，2006

2. STANAG 4427《系統生命週期管理中的組態管理》

3. ISO/IEC 19770（所有部分），《資訊科技—IT資產管理》

# IEEE 通知和摘要

##### 關於 IEEE 標準文件的重要通知和免責聲明

IEEE 標準文件的使用受重要通知和法律免責聲明的約束。這些通知和免責聲明，或指向此頁面 ([https://standards.ieee.org/ipr/disclaimers](https://standards.ieee.org/ipr/disclaimers.html)) 的鏈接，出現在所有標準中，並可在“關於 IEEE 標準文檔的重要通知和免責聲明”標題下找到。

##### 關於使用 IEEE 標準文件的通知和免責聲明

IEEE 標準文件由 IEEE 各學會和 IEEE 標準協會 (IEEE SA) 標準委員會的標準協調委員會制定。 IEEE 透過經認可的共識制定流程製定標準，該流程匯集了代表不同觀點和利益的志願者，最終形成標準。 IEEE 標準是由具有科學、學術和行業專業知識的志工在技術工作小組中製定的文件。志工不一定是 IEEE 或 IEEE SA 的成員，並且不從 IEEE 獲得任何報酬。雖然 IEEE 負責管理該流程並製定規則以促進共識制定過程的公平性，但 IEEE 不會獨立評估、測試或驗證其標準中包含的任何資訊的準確性或任何判斷的合理性。

IEEE 不保證或聲明其標準中所含資料的準確性或完整性，並明確否認所有未包含在本標準或任何其他與此標準相關的文件中的保證（明示、默示和法定保證），包括但不限於以下保證：適銷性；特定用途的適用性；不侵權；以及資料的品質、準確性、有效性、時效性或完整性。此外，IEEE 否認與結果和製程水準相關的任何及所有條件。此外，IEEE 不保證或聲明使用其標準中所含材料不侵犯專利權。 IEEE 標準文件以「原樣」提供，且「包含所有缺陷」。

使用 IEEE 標準完全出於自願。 IEEE 標準的存在並不意味著不存在其他方式來生產、測試、測量、購買、銷售或提供與 IEEE 標準範圍相關的其他商品和服務。此外，標準批准和發佈時所表達的觀點可能會因技術發展和用戶回饋而改變。

IEEE 發布和提供其標準，並不代表任何個人或實體提供或推薦任何專業或其他服務，也不承擔任何其他個人或實體對其他個人或實體所負的任何義務。任何使用 IEEE 標準文檔的人員在任何情況下，都應依靠自身獨立的判斷，盡到合理的注意義務；或者，在適當情況下，尋求合格專業人士的建議，以確定特定IEEE標準的適用性。

在任何情況下，IEEE均不對任何直接、間接、附帶、特殊、懲罰性或後果性損害（包括但不限於：採購替代商品或服務的需求；使用、數據或利潤的損失；或業務中斷）承擔責任，無論此類損害的起因和責任理論如何，亦無論其是基於合同、嚴格責任還是侵權（包括過失或其他），即使已被告知此類損害或其他損害的可能性。

##### 翻譯

IEEE 共識制定流程僅涉及英文文件的審查。如果 IEEE 標準被翻譯，則只有 IEEE 發布的英文版本才是經批准的 IEEE 標準。

##### 官方聲明

任何未經 IEEE SA 標準委員會操作手冊處理的任何書面或口頭聲明，均不得被視為或推斷為 IEEE 或其任何委員會的官方立場，也不得被視為或依賴為 IEEE 的正式立場。在講座、研討會、研討班或培訓課程中，任何介紹 IEEE 標準資訊的人員都應明確說明，其觀點僅代表其個人立場，而非 IEEE、IEEE SA、標準委員會或工作小組的正式立場。

##### 標準意見

**IEEE 不提供與 IEEE 標準文件相關的解釋、諮詢資訊或建議。 **

對文件修改的建議應以文本修改提案的形式提出，並附上相應的支持性意見。由於 IEEE 標準代表了相關利益方的共識，因此對意見和問題的任何回應都必須獲得各方利益的平衡認可。正因如此，IEEE 及其學會和標準協調委員會的成員無法立即回覆意見或問題，除非該事項先前已處理。同樣，IEEE 也不回應解釋請求。任何希望參與評估意見或修訂 IEEE 標準的人員，都歡迎加入相關的 IEEE 工作小組。您可以透過 [IEEE SA myProject 系統](https://development.standards.ieee.org/myproject-web/public/view.html#landing) 中「管理個人資料和興趣」區域的「興趣」標籤來表明您對某個工作小組的興趣。存取此應用程式需要 IEEE 帳戶。

有關標準的意見應使用[聯絡我們](https://standards.ieee.org/content/ieee-standards/en/about/contact/index.html)表單提交。

##### 法律法規

IEEE 標準文件的使用者應查閱所有適用的法律法規。遵守任何 IEEE 標準文件的規定並不構成對任何適用法規要求的遵守。標準的實施者有責任遵守或參考適用的法規要求。 IEEE 發布其標準的目的並非敦促採取不符合適用法律的行動，這些文件也不應被解釋為敦促採取不符合適用法律的行動。

##### 資料隱私

IEEE 標準文件的使用者應在評估和使用標準時，考慮資料隱私和資料所有權問題，以確保符合適用的法律法規。

##### 版權

IEEE 草案和已批准的標準均受美國和國際版權法保護，版權歸 IEEE 所有。這些標準由 IEEE 提供，並廣泛應用於公共和私人領域。這些用途包括法律法規中的引用，以及私人自律、標準化和工程實踐與方法推廣。 IEEE 提供這些文件供公共機構和私人使用者使用和採用，並不代表其放棄對這些文件的任何版權。

##### 複印

在支付相應的許可費後，IEEE 將授予用戶有限的、非獨佔性的許可，允許用戶複印任何單一標準的部分內容，僅限公司或組織內部使用或個人非商業用途。如需安排支付許可費，請聯絡版權結算中心客戶服務部，地址：222 Rosewood Drive, Danvers, MA 01923 USA；電話：+1 978

750 8400；網址：<https://www.copyright.com/>。您也可以透過版權結算中心取得影印任何單一標準部分內容用於課堂教學的許可。

##### 更新中IEEE 標準文檔

IEEE 標準文件的使用者應注意，這些文件可能隨時因發布新版本而被取代，也可能透過發布修訂、勘誤或更正進行修訂。任何官方 IEEE 文件均包含其當前版本以及當時生效的任何修訂、勘誤或更正。

每項 IEEE 標準至少每 10 年進行一次審查。如果一份文件發布超過 10 年且未進行修訂，則可以合理地認為其內容雖然仍具有一定的價值，但已無法完全反映當前的技術水平。使用者應注意檢查以確保其擁有任何 IEEE 標準的最新版本。

為了確定某個文件是否為最新版本，以及是否已透過發佈修訂、更正或勘誤進行過修改，請造訪 [IEEE Xplore](https://ieeexplore.ieee.org/browse/standards/collection/ieee/) 或 [聯絡 IEEE](https://standards.ieee.org/content/ieee-dart/aboutenee-有關 IEEE 標準協會 (IEEE SA) 或 IEEE 標準制定流程的更多信息，請訪問 IEEE SA 網站。

##### 勘誤

所有 IEEE 標準的勘誤（如有）均可在 [IEEE SA 網站](https://standards.ieee.org/standard/index.html) 上查閱。搜尋標準編號和核准年份即可造訪已發布標準的網頁。勘誤連結位於「其他資源詳情」部分。勘誤表也可在 [IEEE Xplore](https://ieeexplore.ieee.org/browse/standards/collection/ieee/) 中找到。建議使用者定期查看勘誤表。

##### 專利

IEEE 標準的製定符合 [IEEE SA 專利政策](https://standards.ieee.org/about/sasb/patcom/index.html)。

##### 重要提示

IEEE 標準不保證或確保安全、保全、健康或環境保護，也不保證免受其他設備或網路的干擾。 IEEE 標準制定活動在製定任何安全建議時，會考慮提交給標準制定小組的研究和資訊。有關安全實踐、技術或技術實現的變更，或外圍系統的影響等其他信息，也可能與標準實施過程中的安全考慮因素相關。 IEEE 標準文件的實施者和使用者有責任確定並遵守所有適當的安全、保全、環境、健康和乾擾防護措施以及所有適用的法律法規。

**摘要**

本文檔建立了一個通用的流程描述框架，用於描述人類創建的系統的生命週期，並從工程角度定義了一系列流程及其相關術語。這些流程可應用於感興趣的系統、其系統元素以及系統之系統。在系統生命週期的各個階段，都可以應用這些流程的特定組合。這需要利害關係人的參與，最終目標是實現客戶滿意。

本文檔也規定了支援組織或專案內部系統生命週期流程的定義、控制和改進的流程。組織和專案在獲取和供應系統時可以使用這些流程。

本文檔涉及的系統可以配置以下一個或多個系統元素：硬體元素、軟體元素、資料、人員、流程、服務、程序、設施、材料和自然實體。