The Essential Guide to Requirements Management and Traceability
What is MBSE? Model-Based Systems Engineering Explained
In the following chapter, we will set out to answer some of the most common questions around Model-Based Systems Engineering (MBSE), including: What is MBSE? What is the real intent of MBSE? And is MBSE the same thing as SysML?
Editors Note: This subchapter was written by Lou Wheatcraft, Senior Consultant & Managing Member at Wheatland Consulting, LLC, and current co-chair of the INCOSE Requirements Working Group (RWG).
What is MBSE?
If you ask 20 people to define MBSE, you might get 20 different answers. The core of confusion is the word “model.”
Data-centric Practice of SE Data & Information Model Bidirectional Traceability is critical to document relationships, assess change, and show compliance The INCOSE Systems Engineering Handbook (SE HB) states that “a model that represents a system and its environment is of particular importance to the systems engineer who must analyze, specify, design, and verify systems, as well as share information with other stakeholders. Different types of models are used to represent systems for different modeling purposes.”
In the INCOSE SE HB, the word “model” shows up over 680 times! The term is used to refer to the various kinds of models, visualizations of the data and information contained the various types of models, as well as documents, diagrams, drawings, or any other representation of a system.
In this context, a “model” can be any representation or abstraction of the system of interest that best suits the purpose for which it was created. Thus, there are various kinds of models including analytical, logical, behavioral, and architectural models, textual descriptions, as well as documents, functional flow diagrams, data flow diagrams, interface diagrams, architectural diagrams, drawings, or any other representation of a system.
The common denominator of all these representations is that they are all visualizations of the underlying data and information that is used to construct and represent the model.
Again, referring to the INCOSE SE HB:
“MBSE is often contrasted with a traditional document-based approach to SE. In a document-based SE approach, there is often considerable information generated about the system that is contained in documents and other artifacts such as specifications, interface control documents, system description documents, trade studies, analysis reports, and verification plans, procedures, and reports. The information contained within these documents is often difficult to maintain and synchronize, and difficult to assess in terms of its quality (correctness, completeness, and consistency).”
“In an MBSE approach, much of this information is captured [electronically] in a system model or set of models. The system model is a primary artifact of the SE process. MBSE formalizes the application of SE through the use of models. The degree to which this information is captured in models and maintained throughout the life cycle depends on the scope of the MBSE effort. Leveraging an MBSE approach to SE is intended to result in significant improvements in system requirements, architecture, and design quality; lower the risk and cost of system development by surfacing issues early in the system definition; enhance productivity through reuse of system artifacts; and improve communications among the system development team.”
Given there can be multiple types of models, and visualizations of the data and information in those models generated while progressing through the system life cycle processes, a 10,000-foot level view of SE from a data-centric perspective helps stakeholders understand the context in which various artifacts and their underlying data and information are generated and used.
MBSE is not really about drawing diagrams that contain boxes and lines but rather is about the underlying data and information model itself that enables consistency across the data and information that represents the various models and visualizations.
What is the Real Intent of MBSE?
The goal of an organization adopting MBSE is to move from a 20th century document-centric practice of systems engineering (SE) toward a data-centric practice of SE to realize the real intent of MBSE which is to develop, maintain, and manage a data and information model of the system being developed along with a model of all the system life cycle process activities, resulting artifacts, and their underlying data and information.
“MBSE, from a data-centric perspective, involves the formalized application of shareable sets of data to represent the SE work products and underlying data and information generated to support lifecycle concept maturation, needs and requirements definition, design, analysis, and verification and validation activities throughout the system life cycle, from conceptual design to retirement.”1
With this data-centric perspective of SE, the capability to capture, manage, access data, and manage the interrelationships between SE work products can be accomplished through a variety of methodologies, which range from the establishment of a single relational database to a virtually integrated, but distributed, database by means of a federation (or data map/ index) of disparate data sources.
This data and information can be captured using a variety of SE tools and applications. To effectively manage the development of our ever-increasing complex, software-centric systems there are benefits to managing this underlying data and information in such a way it can be shared across the system lifecycle process activities, shared between the various SE tools used to create and manage this data and information, and shared between organizations involved in the development and operations of the system of interest. This sharing will help ensure correctness, consistency, and completeness of the data and information typical of our ever increasingly complex systems. It will also enable collaboration between not only the project team members, but also external stakeholders involved in the development of the system.
To manage the development of increasingly complex software-centric systems, managing data in a way that can be shared across the system lifecycle process activities, and between all key stakeholders involved, can ensure consistency and correctness.
SE cannot be effectively practiced when viewed from just one perspective (requirements, models, patterns, standards, industry specific application, etc.). To successfully practice SE, wise systems engineers recognize and use each perspective as appropriate to the activity they are performing. Based on their needs they choose the appropriate tool and visualization that will meet their needs.
The degree to which the data and information is captured and managed is driven by the needs of the organization and programs from a business and technical perspective based on the size and complexity of their programs, their product line, culture, processes, workforce, their diversity and complexity of supply chains, and types of engineering information that comprises a technical baseline for their system of interest.
MBSE is NOT SysML!
To some practitioners, MBSE is equated to the use of SysML and other language-based modeling tools. However, as discussed above, MBSE is much more than using language-based modeling tools to develop analytical, logical, behavioral, and architectural models. To others, what they are calling MBSE is really Model-based Design (MBD).
MBD design starts with a set of requirements and using various language-based modeling tools to architect and design a system, develop simulations to assess the behavior of the system, and then develop a set of design output specifications to which the system is built or coded. Often the MBD activities are completed in a silo separate from the other SE lifecycle process activities.
However, this approach does not address the true intent of MBSE. The data and information model that must be developed must represent all the SE artifacts generated during the product development process activities across all lifecycle stage activities. Thus, information associated with the elicitation of stakeholder needs and requirements, lifecycle concept definition, analysis, and maturation, deriving an integrated set of needs, and transforming those needs into sets of design input requirements, defining an architecture, designing the system, verification the system meets those requirements, and validation that the system meets the needs must also be captured within the data and information model. In addition, relationships and dependencies of the individual data items must be captured (traceability) in order to help determine and ensure consistency across all lifecycle stages as well as help assess the impact of changes made to any of the data items. Design inputs must be traceable to design outputs.
Benefits of Implementing Systems Engineering from a Data-Centric Perspective
A data-centric perspective of SE complements the system life cycle process activities by enabling the opportunity for system development with increased quality, lower cost, and lower risk. Adopting MBSE and implementing a data-centric perspective enables organizations to realize the following benefits:
- Meet the challenges associated with increasing complexity for current and future systems discussed in the previous section.
- Provide greater consistency of all products because any single piece of design data and information can be expressed authoritatively within integrated/federated, shareable sets of data that can later be referred to by others for decisions or formation of other work products.
- Provide better visibility into the principal characteristics of the whole integrated system because multiple views from the data and information model can be created that succinctly address specific stakeholder needs, concerns, and interests.
- Provide greater congruence and configuration management between documentation and reality. Differing views of the underlying data and information model can be automatically generated into SE artifacts, reducing the effort to keep the artifacts and their underlying data and information up to date and consistent, resulting in artifacts that match the best available, current data and information.
- Establish “single source of truth.” Single source of truth (SSoT) represents the official state or baseline version of data and information — regardless of what someone says or thinks, no matter what they “remember” or what perspective they have concerning what is being done or built or a decision that was made, if it isn’t in the project’s configuration managed, data and information model, it isn’t the truth. (Requires all the underlying data and information to be configuration managed and kept current and consistent.)
- Facilitate the navigation, traceability, and interrogation of data and information across all system life cycle stage activities. Managers and engineers can have access to the correct, complete, and consistent data and information more quickly, and on an as-needed basis, without going through manual distribution or search processes.
- Enable the reuse of SE and PM artifacts and underlying data and information. Considerable time and expense can be saved when an organization can reuse SE and PM data and information and not have to start from scratch for each new project (brown field systems). This reuse ability is key to effective product line management.
- Facilitate the management of the stakeholder needs, requirement definition, design, build/ code, system verification, and system validation activities in an integrated, consistent manner. Data and information associated with verification and validation activities across all system life cycle process activities can have higher quality and provide greater insight concerning the status of verification and validation activities. This makes it easier to show compliance and that stakeholder needs are being met.
- Reduce the costs associated with erroneous design and resulting rework. Analysis of the SE work products and underlying data and information can reveal a flaw or inconsistency as soon as it is created, enabling correction before downstream work is done, work that would be invalid, and costly and time consuming to correct if the upstream mistake were not corrected immediately. This also helps to avoid huge expenses associated with recalls, returns, warranty work, and negative comments on social media.
- Facilitate the identification of interactions (interfaces), helping to ensure the system of interest can be successfully integrated into the macro system it is a part and reducing integration issues and costly rework and schedule slips associated with these issues.
- Provide identification, management, interoperability, and integration of artifacts and underlying data and information across business or organizational elements needed to support program budget and schedule goals. For example, with the ability to metatag data, information, and work products, they can directly be linked to the Work Breakdown Structure (WBS), budget, schedule, and risk management activities.
- Ensure data and information needed by programs and projects (e.g., for milestones, gate reviews, mission operations, risk mitigation, and anomaly investigations, decisions, and outcomes) are identified and managed to provide traceability of the data and information used in decision-making.
- Use measures to better manage SE activities across all system life cycle process activities. Measures allow managers and systems engineers to monitor trends, assess progress, identify issues to help ensure the system being developed will meet stakeholder needs and expectations.
In Conclusion
In order to effectively develop today’s increasingly complex and software intensive systems and avoid the many negative consequences of the outdated document-centric practice of SE, organizations must move to a data-centric practice of SE which is the real intent of MBSE. Organizations need to develop a level of organizational SE capability that will enable them to realize the benefits listed above.
Since one size doesn’t fit all, an organization needs to assess the SE capabilities that best fit its domain, product line (degree of complexity), and culture. The level of SE capability an organization establishes needs to be tailored to the size and complexity of systems developed by the organization, whether small, medium, or large projects.
Based on the needs of the organization and the level of SE capability, they will need to choose the appropriate SE toolset, update their processes, and train their people in these tools and processes.
REFERENCES:
¹ INCOSE INCOSE-TP-2018-001-01, 2018, Integrated Data as a Foundation of Systems Engineering, prepared by the Requirements Working Group, INCOSE.
2 INCOSE-TP-2010-006-03, 2019, Guide to Writing Requirements, prepared by the Requirements Working Group, INCOSE.
3 Wheatcraft, L., Ryan, M., Dick, J., Llorens, J., 2019. “The Need for an Information-based Approach to Requirement Development and Management”, paper and poster presentation at INCOSE IS 2019.
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started by filling out this form so we can connect!