Smarter requirements for MBSE [5 steps to a model-based approach]

Systems Engineering is a multidisciplinary and integrative management approach to system development. When we add formal (digital) representations of a system to the approach, we talk about Model-Based Systems Engineering (MBSE). These digital models are made of structured data, preferably interchangeable between software. Although the term model focuses mostly on geometric data and data for calculation and simulation, there are more types of information to consider for a full model-based approach.

It starts with Requirements Management. The process of describing requirements, their subjects, like functions and objects, descriptions of activities and stakeholders, and different hierarchies, like decompositions and collections. Although Requirements Management is only a part of MBSE, it is also one of the most crucial processes in getting a project right. Everything depends on how requirements are specified, how they change during a project, and how compliance with the requirements is proven.

This blog explains a five-step plan for model-based Requirements Management as part of MBSE.

Step 1: dissect your document

Requirements have to fulfill certain rules, which make them Specific, Measurable, Achievable, Relevant, and Testable. But this SMART rule, which everybody uses, applies to individual requirements only and doesn’t take all requirements into account. To create coherent and consistent requirements, they must be Mutually Exclusive and Collectively Exhaustive, or MECE for short (based on Minto, ‘The Pyramid Principle’, 1987 and Oostinga, ‘SEm Infra’ 2014).

Complying with these quality rules for requirements can’t be done document-based anymore. You need to adopt MBSE. This is simply because Word, Excel, and other document-based tools don’t understand what is meant by the text and can’t help you check if the rules have been followed. You need requirements to be structured and cut up into smaller pieces so that software can make sense of them and help you compose a coherent and consistent whole of requirements: a (part of a) contract.

Step 2: enrich your requirements

Depending on how ‘dissected’ the requirements are, software applications for MBSE can interpret the information and help you better navigate them, infer what subject requirements apply to, and even reason if a requirement is SMART and MECE.

To help the MBSE tools, you sometimes need to enrich the requirements. For example, by adding attributes such as ‘status’, and if the original requirements weren’t SMART already, you might add a verification method. This means that a requirement should be unambiguous, complementary, and unique.

Step 3: validate your requirements

Validating requirements is key. This means that you do the following (UFACTI) checks:

• Uniqueness: not similar to or overlapping other requirements?
• Feasibility: are you certain that the requirement can be realized?
• Ambiguity: is there only one way to interpret the requirement?
• Cohesion: does a derived requirement have a narrower subject than its original?
• Testability: is there a method to verify the required performance?
• Integrity: is the requirement exhaustive?

If you are using smart requirements for MBSE, your software can help. The application can give you overviews of requirements that are not yet complete, that have the same subject, or even subjects that are contradictory or redundant.

When you are confident that all requirements are validated, you share the information with others.

Step 4: publish your requirements

It could involve other disciplines or teams specifying different parts of the project. You might also share the final requirements with those designing specific system components. This can include other organizations, such as tender candidates, who are part of the project. But how? Of course, you can plot the requirements on a document again and send a PDF by email. But there are more innovative, model-based ways.

The key is to publish the requirements as an interoperable model. This means you publish the requirements model in an Open Standard (format) for exchanging information. Using an Open Standard format means that the data can be understood by any Requirements Management and MBSE tool, free from any proprietary format from software vendors.

In this case we are not talking about a standard that transcends industries and domains, and has been developed to make data Findable, Accessible, Interoperable, and Reusable (FAIR). This standard is called the Resource Description Framework (RDF) and is widely adopted as format for engineering standards (e.g. in parts of ISO standards).

If you were already writing requirements within a project context, this is where the first stage stops, and the change process starts. But these four steps could apply to standards describing requirements and all sorts of specifications. In that case, after step four, you have published a requirements library or a Smart Standard to be used in any project by any application.

Step 5: reuse your requirements

Most MBSE projects don’t start from scratch. Many laws, rules, regulations, and industry standards specify what to create and how to create it. If these standards are created by following the first four steps, you could easily navigate through a coherent web of requirements and ‘configure’ your project requirements. Instead of copying and pasting from a document. This will not only save time but will also prevent a lack of consistency and coherency in contracts.  

Are you inspired to manage Smart Requirements for FAIR Model-Based Systems Engineering? Please get in touch and receive a copy of the booklet ‘SEm infra: Model-Based Systems Engineering on how to create SMART and MECE model-based Requirements with a demonstration of Laces‘.