Choosing the right MBSE tool is a challenge that many of us have to face at one point or another. With the work performed by the INCOSE SE Tools Database Working Group, that might soon be a bit easier. From the INCOSE website: “The Systems Engineering Tools Database Project is underway to provide the systems engineering community with a ‘Wikipedia” of known, researched and verified tool data; evaluate tool capabilities to support the MBSE Initiative and data exchange standards.”

Although the new database is certainly something to look forward to, the problem still remains how to choose the right MBSE tool. Having recently evaluated a tool to determine its usability, I realized once again that this is no different to any other SE problem for which we seek a solution. Start by defining the need!

Most importantly, who will be using the tool and what are their skills, what are the intended uses of the tool, how and where will the tool be used, and what are the representative scenarios of use? In short, define the Operational Concept Description (OCD) for the tool.

An OCD for a tool may state: “The tool will be used by the engineering team during system design to:

• Facilitate Requirements Analysis (RA) at all levels of the product breakdown structure,
• Capture the results of RA – the specified requirements that define the stakeholder needs,
• Score the quality of requirements to facilitate writing better requirements,
• Capture requirements traceability between different levels of abstraction of the architecture,
• Capture requirements traceability between requirements and verification requirements,
• Generate requirements specifications,
• Baseline requirements and formally control changes to requirements,
• Capture both logical and physical conceptual design(s),
• Capture design traceability to the requirements that drive the design,
• Communicate the requirements and design to the whole design team,
• Share conceptual designs with stakeholders for review purposes,
• Baseline design and formally control changes to design.”

Having a good OCD enables us to better focus on the specific requirements that will enable the identified scenarios of use. Examples of some of the questions that will drive these requirements are:

• What does our RA process look like and what steps/techniques need to be supported by the tool in order to facilitate the identification and capturing of requirements?
• Can the tool automatically score the quality of requirements? How does the tool do that? Is the framework for scoring user definable?
• Does the tool enable requirements traceability and visualize it clearly?
• Does the tool support design visualizations that is understandable by the whole team?
• Does the tool enable design traceability and visualize it clearly?
• Does the tool support design visualizations that is understandable by all of the stakeholders?
• Does the tool formally enable baselining and recordkeeping of any changes made after a baseline?

Hopefully, these guidelines will set you on your path to select a suitable MBSE tool for your specific purpose. It is perhaps not impossible but unlikely that you will find a tool that can always meet all of your requirements, but careful consideration of the intended use may go a long way to avoid choosing a tool that later turns out to be a white elephant.