MBSE需求
關注創建者：王靖雯 創建時間：2023-06-02
MBSE需求的實例教程
需求數量的統計，是包括最上層的“總需求”，所以總數是6個，2個沒有改善，總的改善率是“66.66%”。
文章來源：智睿思維MBSE
可以看出，需求分析是進行 MBSE 的首要步驟，同時需求分析和系統設計在 MBSE 的全流程之中也是緊密耦合的。為了使 MBSE 全流程建模方法更加實用化，達索公司配合 MagicDraw 軟件給出了基于 SysML 的 Magic Grid 方法論[10,11]，將問題用域來描述，每個系統設計都包含了問題域、解決域、實施域三層，每層都由需求、行為、結構體和參數四個維度的定義來完成描述，形成了方案矩陣，需求分析在每一層中都是首要的。目前，在航空[12,13]、汽車[14]與航天[15,16]等領域，都是結合自身工程實際，在上述方法的基礎上通過適當的裁剪或改進，完成系統設計。
從方法論和應用層面來看，系統需求分析有較為成熟的體系，尤其是系統正常功能的設計。即從利益攸關者的要求出發，逐層分解、推導，給出子系統或分系統的設計要求。
2. 基于模型的可靠性、安全性分析
隨著 MBSE 在工程領域的成功運用，基于模型的可靠性、安全性分析方法也越來越得到重視。作為系統工程的一部分，可靠性安全性分析也應該融入到 MBSE 的流程之中。
在現有的文獻中，以基于 SysML 的設計模型為基礎，開展了許多關于基于模型的可靠性安全性分析方法的研究，形成了包括文獻[17, 18]在內的方法論。目前的研究重點是如何運用系統正向設計的產物，定義故障模式和故障傳遞關系，從而自動開展可靠性安全性分析，生成失效模式及其影響后果分析表和故障樹[19?21]。這些分析方法均需要從頂層的可靠性安全性需求出發， 如何梳理復雜系統的可靠性安全性需求，開展系統設計，則成了復雜系統頂層設計中的重要問題。
在傳統的 MBSE 流程中，可靠性安全性需求屬于通用需求的一部分。
展開 （4）需求評審/ 批準
針對收集來的需求，包括直升機級分配的、適用的適航條款、適用的行業/ 企業規范要進行相關方評審，以確保沒有遺漏和沖突。需求評審需要召集相關方人員參與，包括直升機級代表、適航代表、項目管理代表、航電系統專家等。通過評審的需求，要經過正式的批準程序作為航電系統開發的輸入。
需求收集階段的主要任務是記錄和匯總各方需求，這些輸入需求是后續建模分析設計的基礎。若使用模型的方式完成需求收集工作，可使用SysML 語言的“需求”元素來記錄這些收集匯總的需求。
展開 圖 5 需求條目化與結構化
3
導彈需求屬性定義
簡單的文本不足以充分定義需求，為需求指派屬性，可以對需求所描述的信息進行良好組織和展示。屬性使與單一需求關聯的信息能夠被結構化，以便于處理、過濾、排序等。例如在描述一條需求時，可以從編號、名稱、內容、優先級、類型、編寫人、編寫時間等多維度進行編輯，從而使需求更加清晰。針對導彈系統的研制任務書中的需求，定義了需求編號、需求類型、分配部門等屬性項。通過在需求管理工具ORM中進行配置，從而形成多屬性描述的導彈需求矩陣。
圖 6 需求屬性定義
4
建立需求追溯關系
當按照需求信息架構定義了所有需求文件后，可維護用戶層、系統層和各設備之間的需求關聯關系。當需求關聯建立后，從一個需求可以迅速定位到與其關聯的其它需求項，并且可以通過影響分析視圖和需求矩陣的形式展示需求間的直接與間接關聯關系，從中可以很直觀的發現“孤島”需求，以及進行全面的需求追蹤與影響分析，有效輔助變更決策。當需求條目產生變更時，與其具有上下游關聯關系的需求自動標記為可疑關系，提示相關人員排除需求變更對相關數據產生的影響。
在該案例中，建立從總體室細化的導彈系統需求到軍方下發的導彈研制任務之間的追溯關系。
展開 圖3 基于文檔和基于模型的區別
所以，開篇提到的把“系統工程”等價為MBSE，或者簡單的認為MBSE就是SysML建模都是片面的，也是不準確的。
那為什么這么多人都認為MBSE就是SysML建模的等同概念呢？
其實這主要是以下幾個方面的原因疊加造成的認知片面導致的。
系統建模工具廠商刻意宣傳的效果，尤其是SysML工具的供應商基本宣傳策略就是構建MBSE能力就是掌握SysML系統建模應用；
產品設計經歷了逆向仿制到正向創新的發展過程，在正向創新的產品開發流程中亟需提高和完善的能力是需求工程和系統功能分析與分配。主要集中在V流程的左半邊，越往上越欠缺。如圖 4黃色虛線圈的位置。因為欠缺，所以更關注，也就造成了用MBSE“指代”需要提高能力的那部分內容；
MBSE應用的最大優勢之一是在設計的前期充分的開展需求分析和功能分析，通過架構權衡實現早期設計缺陷的識別，并及時修復。這是一種研發范式的轉變，如圖 5所示。通過這種新范式可減少后期缺陷的數量，降低修復缺陷的經濟成本和時間成本。
一般，以上對應的MBSE內容我們姑且定義為狹義的MBSE，那么，狹義的MBSE包括需求捕獲、需求撰寫、需求分析、系統建模、功能和邏輯分析、系統仿真、需求驗證、需求和模型管理等。如此，勉強可以認為（狹義的）MBSE就是SysML建模與分析。這也是目前大多數人對MBSE概念認知的范圍。在此還是倡議溝通交流中能明確界定概念，避免造成MBSE概念和范圍的混亂，甚至認知誤區，這對于長遠發展MBSE是不利的。
展開 
MBSE需求的相關專題、標簽、搜索
MBSE需求的最新內容
MBSE 從需求階段開始即通過模型(而非文檔)的不斷演化、迭代遞增而實現產品的系統設計，具有顯著優勢。1993 年， Wymore[4]出版了專著 Model-based Systems Engineering，標志著 MBSE 的正式問世。但由于軟硬件環境的限制，MBSE 并未取得突破性進展。
行業應用
國外在MBSE的方法及應用方面開展了廣泛研究與實踐：空客公司在A350系列飛機的開發中全面采用MBSE，在飛機研制中逐層細化需求并進行功能分析和設計綜合；洛克希德·馬丁公司采用MBSE統一進行需求管理和系統架構模型，并向后延伸到機械、電子設備以及軟件等的設計與分析之中；羅·羅公司依據 INCOSE系統工程手冊制定了其自身的系統工程能力框架
圖11 “V”形開發流程
基于模型的系統工程（MBSE）屬于“需求驅動型”研發模式，在需求分析階段進行系統需求的捕獲、分析和驗證，在早期暴露并全部解決需求存在的隱患和問題，并基于驗證后的需求開展后續研制，大大減少了研制過程中的反復和浪費。
這就造成Harmony MBSE并不完全符合系統工程最新標準（ISO 15288:2015）對系統工程過程的定義，如Harmony MBSE以涉眾需求作為輸入，而忽略了涉眾需求定義過程。另外，Harmony MBSE的作者Peter Hoffman退休離開IBM，以及IBM公司的業務轉型，對Harmony MBSE方法學及其系統工程解決方案的發展和完善的影響，尚待評估。
第一階段的基本前提條件是，組織內部必須確定對MBSE的某種基本需求。
編者：對MBSE的需求是組織邁向MBSE后續階段的動力。假如沒有這種需求，將不會有后續所有階段。
階段2–以文檔為中心的系統工程
MBSE演變的第二階段被稱為以文檔為中心的系統工程。圖3中的階段2再次描繪了一大堆文檔，但是這次有兩個主要的變化。第一，文件數量略有增加。
圖表32 ModelCenter的MBSE模塊支持用戶直接在最熟悉的環境中工作
ModelCenter MBSE支持需求一致性分析，提供用于執行ModelCenter工作流的圖形用戶界面。
1
背景及總體方案分析與定義
隨著大型、復雜系統的發展，系統工程方法被用于管理系統的復雜性，并確保交付的系統能滿足所有需求。MBSE是一種通過使用系統模型改善傳統的基于文檔的系統工程的方法。SysML是一種圖形化的建模語言，作為一種國際標準支持MBSE。
(3)COMAC文化變革的需求
a.COMAC進程需要
·衡量MBSE/MBD(有形價值)影響的流程方法
·使用一級、二級和三級培訓優秀的建模者
·確保MBSE/MBD持久性的過程方法
·建模指南和標準
b.COMAC MBSE工具需求-與工具供應商一起
·為所有企業中的分布式用戶提供工具支持
·對參考模型和模型化rouse的工具支持
·所有對象的配置和版本控制工具
一般，以上對應的MBSE內容我們姑且定義為狹義的MBSE，那么，狹義的MBSE包括需求捕獲、需求撰寫、需求分析、系統建模、功能和邏輯分析、系統仿真、需求驗證、需求和模型管理等。如此，勉強可以認為（狹義的）MBSE就是SysML建模與分析。這也是目前大多數人對MBSE概念認知的范圍。
文本形式的需求本身就屬于一種模型，對于MBSE而言，需求模型也還是以文本表達為主，只不過對于MBSE而言，R(需求)Viewpoint強調兩個方面:
1
導出需求:
借助相關的視圖
