MBSE FAQ: What is MBSE?, Why use MBSE?, Who created MBSE?

The MBSE FAQ compiles Frequently Asked Questions related to Model-Based Systems Engineering (MBSE) and related topics.
Please contact us regarding any additions or corrections to be made to this page.

General Questions

Model-Based Systems Engineering (MBSE) is a Systems Engineering paradigm that emphasizes the application of rigorous visual modeling principles and best practices to Systems Engineering activities throughout the System Development Life Cycle (SDLC). These Systems Engineering activities include, but are not limited to: requirements analysis, validation and verification; functional analysis and allocations; performance analysis and trade studies; and system architecture specification.

Usage Note: The term Model-Based Systems Engineering (MBSE) is especially popular among Systems Engineers who advocate the use of the Systems Modeling Language (SysML) as a standard visual architecture modeling language for Systems Engineering applications, and who want to distinguish their approach from Model-Driven Development and its variants, which tend to be software centric.
An Model-Based Systems Engineering (MBSE) approach must strive to achieve the following process goals:

• Architecture-centric: The MBSE process must emphasize a system architecture model as the primary work artifact throughout the System Development Life Cycle (SDLC)
• Full SDLC support: The MBSE process must support all SDLC phases, Requirements, System Analysis, System Design, Implementation, System Integration, and Testing
• Requirements-driven & full V&V support: The MBSE process must support full SDLC requirements traceability, including comprehensive Verification & Validation of all functional and non-functional requirements.

In addition, it is desirable that an MBSE approach achieve the following process goals:

• Straightforward & systematic: The MBSE process should be explained in a straightforward and systematic manner, so that it is easy for Systems Engineers to learn and apply.
Promote the use of open standards: The MBSE process should support open standards for system architecture modeling and tool interoperability. These open standards include, but are not limited to SysML, UML 2, XMI, and AP233. These open standards should be used to specify the System Architecture Model and to serve as a lingua franca among Systems Engineers and other stakeholders (Software Engineers, Electrical Engineers, Mechanical Engineers, Customers, etc.).
If you are a Systems Engineer and want to improve the precision and efficiency of your communications with fellow Systems Engineers and other system and business stakeholders (e.g., Clients, Software Engineers), then you should consider using a visual modeling language standard as a lingua franca (common language). The most popular choice for MBSE applications is the SysML dialect of UML 2, which extends the UML standard for software-intensive applications so that it can be applied to Systems Engineering applications.

Here's a list of reasons why Systems Engineers may want to use a Model-Based Systems Engineering approach with a common modeling language such as SysML for their work:

• Facilitate communication among various stakeholders across the System Development Life Cycle
• Capture and manage corporate Intellectual Property related to system architectures, designs, and processes
• Compare and contrast “As Is” and “To Be” solutions
• Provide scalable structure for problem solving
• Furnish rich abstractions to manage size and complexity
• Explore multiple solutions or ideas concurrently with minimal risk
• Detect errors and omissions early in System Development Life Cycle
Model-based specification and simulation techniques have been associated with Systems Engineering since its inception as an interdisciplinary field of engineering, which can be traced to work at Bell Telephone Laboratories and US Department of Defense (DoD) during the 1940s

The term Model-Based Systems Engineering became popular during the standardization of the Systems Modeling Language (SysML), which was created by the SysML Partners consortium in 2005 (SysML 0.9) and eventually adopted by the Object Management Group as OMG SysML 1.0 in 2006. The standardization of SysML resulted in widespread tool support for the new visual language standard and associated MBSE processes.
Model-Based Systems Engineering (MBSE) is frequently confused with several other acronym expressions that begin with either "Model-Based" or "Model-Driven". The short answer is that Model-Based Systems Engineering is a subdiscipline of the more generic Model-Based Engineering system development paradigm. MBE is a system development paradigm that emphasizes the use of rigorous visual modeling techniques throughout the System Development Life Cycle (SDLC); MBSE is a specialization of MBE that applies MBE principles and best practices to Systems Engineering applications.

For a longer and more thorough explanation of the relationships among Model-Based Systems Engineering, Model-Based Engineering, and related MBE subdisciplines check out the Model-Based Engineering Forum and the Model-Based Engineering Visual Glossary.
The Systems Modeling Language (SysML) is general purpose visual modeling language for Systems Engineering applications.
  • SysML supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. These systems may include hardware, software, information, processes, personnel, and facilities.
  • SysML is a dialect of UML 2, and is defined as a UML 2 Profile (Profile = UML customization that uses Stereotypes, Tagged Values, and Constraints.)
  • SysML is an enabling technology for Model-Based Systems Engineering (MBSE)
SysML & Visual Modeling Language Evolution

SysML & Visual Modeling Language Evolution

Reproduced by Permission © 2003-2016 PivotPoint Technology Corp.


The SysML was originally developed as an open source specification project initiated in 2003 in response to OMG’s “UML for Systems Engineering” RFP. SysML contains nine diagram types, seven of which it shares in common with its parent language, along with one tabular notation (Allocation tables.) The SysML specification is publicly available for download, and includes an open source license for distribution and use. The most recent revision is OMG SysML v. 1.3. (See Specifications page.)

SysML Diagram Taxonomy

SysML Diagram Taxonomy

Reproduced by Permission © 2003-2016 PivotPoint Technology Corp.


A recommended best practice for any Model-Based Systems Engineering approach is the synergistic application of Model-Based Languages, Model-Based Tools, Model-Based Processes, and Model-Based Architecture Frameworks.

System Architecture Tetrad

System Architecture Tetrad


Reproduced by Permission © 2003-2016 PivotPoint Technology Corp.



As an open standard Architecture Description Language (ADL) for Systems Engineering applications, SysML is the Model-Based Language of choice for many MBSE endeavors. However, if you don't choose and apply the other key enabling MBSE technologies properly (Modeling Tools, Model-Based Processes, and Model-Based Architecture Frameworks) your MBSE project will likely achieve poor or mixed results.

For more information about SysML check out the SysML Forum.
MBSE enables performance analysis by supporting the specification and simulation of Trade Studies using SysML Parametric diagrams. For more information about how SysML Parametric diagrams facilitate Trade Studies check out the SysML Forum web.
In order to explain how MBSE enables Requirements Verification & Validation (V&V), let’s begin by clarifying the difference between these terms using Boehm's classic formal and informal definitions [Boehm 84]:
A. Definitions
Verification - to establish the truth of the correspondence between a software product and its specification. (Note: This definition is derived from the Latin word for "truth," veritas. Note also that data bases and documentation are fit subjects for verification, as well as programs.)
Validation - to establish the fitness or worth of a software product for its operational mission. (Note: This definition is derived from the Latin word for "to be worthy," valere.)
Informally, we might define these terms via the following questions:
Verification: "Am I building the product right?"
Validation: "Am I building the right product?"
Requirement Validation is typically the responsibility of system Stakeholders, who review Requirement specifications (e.g., SysML Requirement diagrams) to determine that they define "the right product" to be built,. Requirement qualities checked during Validation include, but are not limited to, the following: Correctness, Completeness, Consistency, Clarity (Unambiguousness), Conciseness, Feasibility, Necessity, and Prioritization.
SysML Support for Requirement Validation: SysML supports Requirement Validation by defining Requirements as first class visual modeling elements that can be classified (e.g., Functional, Performance, Interface, Design Constraints), organized into hierarchies (via Containment relationships), and assigned properties (TaggedValues) as needed (e.g., Risk, VerifyMethod, Priority, Level-of-Effort).

Requirement Verification is typically the responsibility of System Engineers and Systems Analysts, who (as per [Boehm 84]) "establish the truth of the correspondence between" the systems engineering product and its Requirement specification.
SysML Support for Requirement Verification: SysML primarily supports Requirement Verification via two complementary relationships:
  • Satisfy («satisfy») dependency: The client model element fulfills a supplier Requirement. e.g., An Optimize Subsystem Activity Satisfies the 2.3.5 Optimize Subsystems Functional Requirement. [See example below.]
  • Verify («verify») dependency: The client TestCase («testCase») determines whether a supplier Requirement has been fulfilled. e.g., A Test Subsystem Optimization Activity «testCase» Verifies the 2.3.5 Optimize Subsystems Functional Requirement and Tests the SmartCarController Block in the System Design «view». [See example below.]

SysML Requirements V&V

Requirements Verification & Validation


Reproduced by Permission © 2003-2016 PivotPoint Technology Corp.



Another Requirement Verification best practice is to define a VerifyMethod property (TaggedValue) for Requirements with appropriate values (e.g., Analysis, Demonstration, Inspection, Test).
To master MBSE requires the balanced mastery of the Systems Engineering disciple and a mature architecture modeling language, typically SysML.

You can find useful information about mastering Systems Engineering in the INCOSE Systems Engineering Handbook on the INCOSE (International Council on Systems Engineering) web site.

You can find useful information about mastering SysML in the What is the best way to learn SysML? FAQ on the SysML Forum web site.

if you want to accelerate your learning process, we recommend that you find a MBSE expert to mentor you. If you don't have ready access to a MBSE expert, check out the MBSE Training services on the MBSE Training page of this web.
Please email your questions using the Contact page.

MBSE Tools & Interoperability

You can find a selected list of SysML modeling tools that support Model-Based Systems Engineering (MBSE) on the MBSE.Tools web.
Although the answer to this question will dependent upon your particular MBSE team and project needs, you can find some pragmatic guidelines in the How to Select a SysML Modeling Tool for MBSE article.
Although the answer to this question will dependent upon your particular MBSE team and project needs, you can find some pragmatic guidelines in the How to Define SysML Tool Evaluation Criteria for MBSE article.

OMG SYSML, UML, and UNIFIED MODELING LANGUAGE are trademarks of the Object Management Group. All other product and service names mentioned are the trademarks of their respective companies.