How to Get Started with MBSE?

As a consultant on MBSE, the most common question that is posted to me is “How to get started with MBSE?”. The problem is that it is not an easy question to answer. As MBSE encompasses a blend of process methodology, language, role definition, responsibilities, baselining, governance, and deliveries, all put together. Adding to this chaos are a bunch of software tools, which bring their own complexity. Therefore, for those new to MBSE, it might seem overwhelming to understand all these elements at once.

This blog reflects my perspective on how to approach learning and implementing MBSE, a method I’ve personally adopted. While other experts may have their views, the process mentioned below is what I propose strongly.

An ideal way to begin the journey is to start with 15288 ISO/IEC 15288 Systems and Software Engineering — System life cycle processes. However, understanding this process and its workflows requires some familiarity with the product development process, which might be a hurdle for first-timers, especially engineering graduates.

First: Have a clear understanding of the difference between SE process and MBSE. It is very common to confuse the two since both are related. However, it is critical to understand the difference. To make things clear, SE is a product life cycle or development process, whereas MBSE is a methodology to document the SE process using software tools or languages like SysML.

For some both might mean the same, however, from my perspective, there is a difference. It is important to have a decent understanding of the SE process before undertaking the MBSE journey. Otherwise, the usual trend is to start with software tools and perform activities like mathematical modeling or software coding without having any understanding of the product development process.

Start with V-Model: The V-Model offers a simple representation of the product development process with easy-to-understand steps involving requirements capture, architecture definition, implementation, verification, and validation. It’s easy to understand and applicable across various product development processes including mechanical, electrical, electronics and software applications.

Now Map V-Model with 15288 Technical Process: Once you have a thorough understanding of the V-Model process, map the V-Model process with 15288 technical process. The 15288 technical process is not too different from the process followed under V-Model, e.g. BMA (Business & Mission Analysis), STNRD (Stakeholder Needs & Requirement Definition), and SRD (System Requirement Definition) can be mapped to the requirement phase in V-Model. However, the 15288 process goes in depth of executing other intermediate workflows within each process, like the STNRD process which consists of sb-process like stakeholder identification, use cases definition, and setting validation criteria, etc. Broadly it can be understood as a process wherein requirements are identified, defined, analyzed, verified, and managed. This is what forms the requirements phase of the V-Model. Similarly, other phases of the V-Model can be mapped with other workflows defined in 15288 technical process. The below-illustrated image provides a view of 15288 technical processes mapped with the V-model.

Mapping of V-Model with 15288 Technical Process

Caution: The V-Model is more focused on the technical aspects of the product development cycle. However, the standard SE or 15288 process covers other aspects of the development lifecycle which includes project management, risk management, configuration & issue management, quality, resource planning, etc. So, when you are looking at MBSE, you should not only look at the technical aspect but also understand other aspects of the product development process. Again, if you are starting new on SE/MBSE, try to get a firm grasp on technical aspects, before getting into non-technical aspects of the process.

Now SysML: Understanding the SE process might be the first hurdle, capturing the information related to the process is another. This is where the MBSE process along with SysML kicks in. SysML provides all the necessary things one expects to address during a product development process, i.e. provide means of performing requirement elicitation, stakeholder identification, use case & test case definition, early collaboration, risk mitigation, trade-off analysis, architecture definition, verification, etc. SysML can initially seem intimidating, in terms of syntax, rules, or workflows involved, however, the takeaway associated with it is colossal. One mistake that people make is to get started with SysML directly without having any basic understanding of SE processes or practices, and then struggling to understand the need for SysML. With that baggage, everything associated with SysML can look and feel very challenging.

What’s next after SysML. After grasping SysML, map the information collaged during the process with other product development processes like PLM for mechanical design, ALM for software development, etc. Establishing traceability throughout the processes is essential. This can be achieved by using an integrated application platform, where most of the product development process converges. One of the best examples of this integrated platform approach is the use of the 3DEXPERIENCE platform for SE process. More information on the same can be found in the following link. https://www.youtube.com/watch?v=BJdnK-k4QKk

Reference: Life Cycle Phase: https://en.wikipedia.org/wiki/ISO/IEC_15288