在基於模型的系統工程（MBSE）的領域中，清晰度至關重要。工程師與架構師不斷在系統設計的複雜領域中尋找方向，力求以精確的方式呈現系統的結構與意圖。系統建模語言（SysML）工具箱中兩個最重要的工具分別是需求圖與方塊定義圖。儘管兩者都是標準的基本組成部分，但各自具有不同的用途，並在不同抽象層次上運作。
在正確的時機選擇正確的圖表，可防止模型膨脹，並確保利害關係人能無歧義地理解系統定義。本指南深入探討這兩種圖表類型在機制、應用與戰略差異方面的內容。我們將探討它們的結構元素、關係類型，以及其中一種圖表優於另一種的具體情境。無論您是在定義高階架構，還是追蹤特定的安全需求，理解這項區別對於建立穩健的系統定義至關重要。
理解 SysML 基礎知識 🏗️
SysML 是一種通用的建模語言，旨在指定、分析、設計與驗證複雜系統。它擴展了統一建模語言（UML），以滿足系統工程的特定需求。SysML 的核心原則之一是關注點分離。不同的圖表專注於系統的不同方面，以確保模型可管理。
建立模型時，您必須決定如何呈現系統。您是在定義什麼系統必須執行的內容，還是您正在定義如何系統是如何構建的？這個根本性問題通常決定了您應選擇需求圖還是方塊定義圖。
- 需求圖：專注於系統必須滿足的需求、限制與條件。它是可追溯性與驗證的主要載體。
- 方塊定義圖：專注於系統的組成、結構與內部組織。它定義了構成整體的物理或邏輯部分。
混淆經常產生，因為這兩種圖表都涉及「項目」。然而，在 SysML 中，需求情境下的項目是一種邏輯需求，而方塊情境下的項目則是一種結構元件。明確區分這兩者，是有效建模的第一步。
方塊定義圖（BDD） 🧱
方塊定義圖是 SysML 中系統架構的基石。它提供了系統結構的高階視圖。可將其視為系統骨架的藍圖。它定義了方塊、其屬性，以及方塊之間的關係。
BDD 的核心元素
多個特定元素構成了 BDD。理解這些元素對於準確建模至關重要。
- 方塊：結構的基本單位。方塊代表一個物理或邏輯元件。它可以是一塊獨立的硬體、一個軟體模組、一個子系統，甚至是一個抽象概念。
- 屬性： 這些定義了方塊的特徵。屬性是方塊的一部分。例如，引擎是一個方塊，其燃油箱是該引擎的一個屬性。
- 埠： 埠定義了方塊與其環境或其他方塊互動的介面。它們指定流入或流出的資訊或能量類型。
- 操作： 方塊可以定義其執行的行為。操作是與方塊相關的功能或方法。
- 約束： 雖然 BDD 主要處理結構，但可以對方塊應用約束，以定義屬性的數學限制或邏輯條件。
BDD 中的關係
BDD 的力量在於模塊之間的相互關係。這些關係定義了系統的組成。
- 關聯： 模塊之間的一種通用連結。表示一個模塊的實例與另一個模塊的實例相連接。這並不代表擁有權。
- 聚合： 組合的一種較弱形式。它暗示了一種「整體-部分」關係，其中部分可以獨立於整體存在。例如，圖書館擁有書籍，但書籍可以在沒有圖書館的情況下存在。
- 組成： 聚合的一種強形式。它暗示部分無法在沒有整體的情況下存在。如果整體被破壞，部分也會被破壞。這對於定義系統層次結構至關重要。
- 泛化： 定義繼承。特定模塊是更一般模塊的特殊化版本。這有助於重複使用結構定義。
何時使用 BDD
當您需要定義架構時，應使用模塊定義圖。它是以下用途的首選圖表：
- 建立系統層次結構與分解。
- 定義子系統之間的介面。
- 指定系統的物理或邏輯組成。
- 可視化資料或能量透過結構連接的流動。
- 記錄特定子系統的內部結構。
例如，如果您正在設計一艘太空船，BDD 會定義主車架、電力分配單元、熱控系統及其物理連接方式。它回答了這個問題：「系統由什麼組成？」
需求圖（ReqD）📋
需求圖是管理系統需求生命周期的主要工具。它允許您組織需求、定義其層次結構，並將其與模型中的其他元素關聯。與專注於物理結構的 BDD 不同，ReqD 則專注於意圖與義務。
ReqD 的核心元素
ReqD 擁有一組特定元素，專為管理邏輯與可追溯性而設計。
- 需求： 對需求或需滿足條件的陳述。需求按類型分類（例如：功能、性能、介面）。
- 需求圖： 用來存放需求及其關係的容器。單一系統模型可包含多個需求圖，以適用於不同領域。
- 需求屬性： 可附加至需求的屬性，例如 ID、優先級、狀態和驗證方法。
- 約束： 限制系統行為或狀態的數學或邏輯表達式。
ReqD 中的關係
可追溯性是需求圖的超能力。SysML 定義了四種特定的需求關係類型：
- 細化：將高階需求連結至更詳細的次級需求。它顯示了需求如何被分解為可管理的單元。
- 追溯：連結兩個在邏輯上相關但不一定具有層級關係的需求。例如，來自客戶的需求可能追溯至子系統所衍生的需求。
- 滿足：將需求連結至滿足該需求的設計元素（如塊或活動）。這對於驗證至關重要。
- 推導：將需求連結至其邏輯上推導出的另一項需求。這通常發生在分解過程中。
何時使用需求圖（ReqD）
當您需要管理系統的「原因」與「內容」時，需求圖至關重要。請用於：
- 捕捉利害關係人的需求與限制。
- 建立需求與設計之間的可追溯性矩陣。
- 確保每一項需求都由設計元素滿足。
- 管理需求變更對整個模型的影響。
- 驗證系統中不存在孤立的需求。
使用需求圖可確保系統是根據使命而建構的。它回答了這個問題：「系統必須達成什麼？」
關鍵結構差異 🆚
為了強化區別，讓我們並列比較這些圖表如何處理資料、關係與範圍。
| 功能 | 塊定義圖（BDD） | 需求圖（ReqD） |
|---|---|---|
| 主要重點 | 系統結構與組成 | 系統需求與可追溯性 |
| 核心元素 | 塊、介面、屬性、操作 | 需求、約束、關係 |
| 關鍵關係 | 組成、聚合、關聯 | 精細化、滿足、追溯、推導 |
| 範圍 | 實體/邏輯架構 | 功能/效能意圖 |
| 驗證連結 | 由……滿足（透過滿足關係） | 滿足（透過滿足關係） |
| 變更影響 | 結構變更影響介面 | 需求變更影響驗證 |
此表格強調，儘管它們相互作用，但在功能上並無重疊。BDD 描述的是容器，而 ReqD 則描述任務的內容。
何時應選擇 BDD 而非 ReqD 🏗️
在系統工程生命週期的特定階段，方塊定義圖是更優的選擇。若依賴 ReqD 進行結構定義，將導致混淆。
1. 定義系統層級
當您處於專案的頂層時，需要將系統分解為可管理的子系統。BDD 允許您定義頂層方塊，並與底層方塊組合，從而建立清晰的分解樹。
- 使用組合來表示擁有權。
- 使用泛化來表示可重複使用的子系統。
- 使用屬性來定義系統的清單。
2. 指定介面
介面是系統相互接觸的邊界。在 SysML 中，介面通常使用 BDD 上的埠與流來建模。若需定義電壓、資料通訊協定或機械安裝點，BDD 是正確的繪圖工具。
- 定義標準介面以確保相容性。
- 視覺化方塊之間的訊號流動。
- 確保實體連接與邏輯連接一致。
3. 建模物理限制
若系統具有物理限制，例如重量、體積或功率消耗，這些通常會作為 BDD 中方塊的屬性來建模。雖然您可以在 ReqD 中使用約束，但結構性約束最好直接放置在方塊本身上。
4. 架構審查
在架構審查期間，利害關係人需要看到系統的結構。他們會詢問元件及其組合方式。BDD 提供了架構決策的視覺證據，是系統實體現實的地圖。
何時應選擇 ReqD 而非 BDD 🎯
相反地，有些情境下 BDD 不足夠。若重點在合規性、驗證或任務成功，則需求圖具有優先權。
1. 捕捉利害關係人需求
任何專案的第一步是了解客戶的需求。這是一個邏輯上的練習，而非結構上的。你無法為「客戶滿意度」繪製一個模組。你必須使用需求來捕捉此意圖。
- 記錄所有功能性和非功能性需求。
- 立即分配優先順序和驗證方法。
- 確保在設計過程中不會遺失任何需求。
2. 管理可追溯性
可追溯性是指從需求的來源追蹤至其實現的能力。需求圖（ReqD）是唯一專門設計用以清晰顯示此脈絡的圖表。它將利害關係人的需求連結至衍生需求，再連結至設計模組。
- 將高階需求連結至低階規格。
- 將需求連結至滿足它們的模組。
- 將需求連結至驗證它們的測試。
3. 確保完整性
系統工程中最大的風險之一，就是擁有沒有需求的設計，或擁有沒有設計的需求。需求圖（ReqD）能幫助你進行審核。你可以檢查每個需求是否都具有指向模組或活動的「滿足」關係。
4. 處理變更管理
當需求變更時，你需要知道其影響。需求圖（ReqD）讓你能追蹤需求至所有相依元素。若性能需求變更，你可以看出哪些模組依賴該性能指標。
整合結構與需求 🔗
當這兩個圖表協同使用時，SysML 的真正威力才會顯現。它們並非互斥，而是互補的。一個穩健的模型會透過特定關係將BDD與ReqD連結起來。
1. 分配
分配是指將需求指派給結構元素的過程。在模型中，這通常透過從需求圖（ReqD）中的需求，建立指向結構圖（BDD）中模組的「滿足」關係來實現。這可驗證結構的存在是為了滿足需求。
- 確保每個需求都已分配。
- 確保每個模組都有其目的。
- 使用分配來驗證覆蓋範圍。
2. 結構的細化
當您於結構圖（BDD）中分解一個模組時，也應同時在需求圖（ReqD）中分解相應的需求。這可確保結構與意圖保持一致。若將一個模組拆分成兩個，則必須確保需求也正確地拆分或分配至新部分。
3. 參數傳播
模組上的屬性可連結至需求上的參數。這讓您可以從需求的限制條件驅動設計值。例如，需求圖（ReqD）中的重量限制可傳播至結構圖（BDD）中模組的質量屬性。
常見的建模陷阱 ⚠️
即使經驗豐富的建模者，在區分這些圖表時也可能出錯。識別常見錯誤有助於維持模型的完整性。
1. 混淆邏輯與結構
一個常見錯誤是將需求放置於模組定義圖（BDD）中。需求是邏輯實體，而非結構元件。將它們放在BDD中會混淆「要什麼」與「如何做」。應將它們保留在需求圖（ReqD）中。
- 不要將需求視為一個模組。
- 不要將需求置於組合關係中。
- 將結構層次與需求層次分開。
2. 需求圖過度複雜化
由於需求圖關注的是邏輯，因此很容易變成錯綜複雜的線條網絡。避免為整個系統建立單一且龐大的需求圖。相反地，應針對不同領域或子系統使用多個圖表。
- 將相關的需求歸類在一起。
- 使用細化來建立子圖。
- 專注於可追溯性，而不僅僅是列出文字。
3. 忽略滿足關係
許多模型僅列出需求與模塊，卻未能將它們連結起來。若缺少「滿足」關係，就無法證明系統符合需求。這會在設計與驗證之間產生斷層。
- 始終將需求與模塊連結。
- 盡可能確保連結為雙向。
- 在審查過程中審核連結。
4. 使用BDD表示功能流程
雖然BDD能顯示連結，但並非用來呈現順序或控制流程。應使用活動圖或序列圖來表示。若使用BDD來展示系統隨時間的運作方式，會導致靜態行為與動態行為之間產生混淆。
有效建模的最佳實務 ✅
為確保您的SysML模型具備穩健性與實用性，請遵循以下管理需求與模塊的指導原則。
- 維持一致性：若在BDD中更改模塊名稱，請確保引用該模塊的需求也隨之更新。一致性對於自動化分析至關重要。
- 命名規範：採用嚴格的命名規範。模塊使用物理名稱（例如：「液壓泵」），需求使用邏輯名稱（例如：「維持壓力 > 100 PSI」）。
- 分層：不要在同張圖表中混合高階與低階細節。為架構建立頂層BDD，為子系統建立詳細BDD。需求也應採取同樣做法。
- 使用範本：若您的組織有特定標準，應將其定義為範本。如此可確保模塊與需求遵循公司級標準，而不會使核心模型變得雜亂。
- 定期審查：定期執行可追溯性檢查。確保已滿足的需求比例高，且無孤立的模塊。
戰略選擇總結 📝
在需求圖與模塊定義圖之間進行選擇，取決於您所要回答的具體工程問題。BDD回答有關組成、介面與物理結構的問題，它是系統身體的地圖。
需求圖回答有關意圖、合規性與驗證的問題。它是系統使命的地圖。透過理解兩者的獨特優勢，您可以建立既結構穩固又具使命關鍵性的模型。
有效的系統工程需要取得平衡。您需要結構來維持系統的整合，也需要需求來確保系統正常運作。單獨任一者皆不夠。當正確使用時，BDD與需求圖能協同運作，確保複雜系統按時且符合規格地交付。
在您持續進行建模之旅時，請記住要保持關注點分離。使用BDD來表達硬體與軟體架構，使用需求圖來表達邏輯與需求。這種關注點的分離將降低複雜度，並提升模型的可靠性。
遵循這些實踐，您就能確保您的SysML模型始終清晰、易於維護，並成為工程團隊的寶貴資產。選擇非常明確：為建造而設計結構，為目的而定需求。