MBSE – Model Based Systems Engineering – is experiencing a renaissance. Organizations are looking at MBSE to address the challenges of raising complexity and more stringent regulatory requirements. But proper MBSE takes a large investment over a long period of time. And unfortunately, many initiatives wither away due to full commitment from leadership, acceptance issues and underfunded initiatives.
To be successful with MBSE, the trick is to start with specific value-driven use cases. And here is the good news: It is possible to implement such value-driven use cases, without having to confront the team with having to to learn MBSE.
Requirements Engineering is a key discipline in product development. They are an enabler for communication. Customers and Suppliers use requirements to capture a common understanding on what needs to be done.
The space flight industry was pioneering this in the 1960s, when they started to practice systems engineering. This worked exceptionally well and put people on the moon, even though engineers were working only on paper.
From Documents to Requirements Items
With the advent of computers, engineers started to look for ways to boost efficiency. And they found something else: Word and Excel, the most popular tools for requirements engineering. Whether these are really better than paper is another question…
Unbelievable: Word and Excel are still the most popular tools for capturing requirements
For those who can afford it, more powerful tools are around. Telelogic pioneered requirements engineering tools in the 1990s with DOORS (acquired by IBM ever since). DOORS is still around, other popular requirements engineering tools include Polarion (Siemens), Jama Connect (Jama Software), Codebeamer (Intland) and Integrity (PTC).
All these tools work in a similar fashion: They allow the definition of “Item Types”: These are entities with properties. A “User Need” item type, for instance, may have properties for “Name”, “Description” and “Priority”, in addition to a system-generated unique ID.
Items can be connected through traceability. This supports activities like coverage or impact analysis and supports change management.
A Requirement is a Black Box
But all these tools have one thing in common: The actual content almost always resides in a rich text field. In DOORS, this is the “Object Text”, in Jama it is “Description”. Users can write anything they want into these fields.
Engineers like this, because they are not constraints in what they write. They can even include pictures. But the flip side is that engineers have to look at the actual content a lot. The tools help engineers to decide when to look at the content, but not why. To the tool, the requirement is a black box.
A simple example: For a web system, the stakeholder specifies a timeout of 10 minutes. A test engineer reads the requirement and writes a test case. For instance, the tester shall wait for a little less than 10 minutes and make sure the user is still logged in.
If the stakeholder changes the timeout to 20 minutes, then the test is making a potential problem: The test will still pass, but it would not test the revised requirement! A typical requirements engineering tool would mark the test as suspect, but a human has to look at it.
Is MBSE the Answer?
Model Based Systems Engineering (MBSE) uses a formal modeling notation to capture requirements. Depending on the notation, MBSE may in fact solve this.
Notations like SysML create transparency, but are so difficult to use that many stakeholders will reject them and few stakeholders will actually master them
There is just one catch: The notations used are difficult. The most popular notation is SysML, consisting of dozens of diagram types and hundreds of element types.
The Solution: Let AI Read Your Requirements
Fortunately, there is another options. Natural Language Processing (NLP) is now so powerful that systems can process the requirements text and do useful things with it. NLP is a subfield of artificial intelligence (AI) concerned with the interactions between computers and human language.
To pick up the example above where the timeout had changed. An NLP assistant like Semiant would recognize that two items connected by a trace (requirement and test) share a parameter (10 minutes). After the change of the requirement, Semiant could alert the engineer to the mismatch (10 minutes vs. 20 minutes) and even offer to change either parameter to the value chosen by the engineer.
MBSE Without Anybody Noticing
Semient can do this, because it builds a systems model behind the scenes. In other words, Semiant leverages the power of MBSE, without the stakeholders having to learn MBSE.
This combines the best of both worlds: Stakeholder can continue to articulate their requirements the way they are used to: human language. But behind the scenes, Semiant builds and maintains a model that takes advantage of 20 years of MBSE. Power users can take advantage of the model directly, but most stakeholders will simply benefit from the analysis of the model, which Semiant will articulate in natural language.
And this is how Semiant makes black box requirements transparent.
Traceability has many benefits in product development. It is also mandatory for regulatory compliance, no matter whether you build cars, trains, planes, medical devices, industrial tech. There are very few exceptions.
Traceability in product development is everywhere:
From regulatory compliance documents to your system description
Between user requirements and system requirements
Between requirements of any kind and tests
Traceability between risks and functions
… and many more
A Glossary is a First Step
Semiant, our automated quality assistant, already provides you with traceability between glossary terms and requirements. This is already useful for compliance activities:
Regulatory compliance requires a controlled vocabulary and a common language, which Semiant helps you establish.
The Glossary provides traceability between glossary term and requirements relating to the term.
Last, it provides traceability between terms, e.g. generalizations or associations between terms.
Risks of Not Having an up to Date Traceability
For products that require functional safety compliance, not having a sound traceability can lead to serious problems:
Missing or incorrect traceability can lead to a rejected audit, leading to delays in product launch and expensive rework.
In case of accident that involve your product, there will be an investigation. Gaps in your traceability could lead to heavy fines, even prison for executives or bankruptcy for the organization.
As an example, consider the cost of the Boeing 737-MAX disaster: Hundreds of people died, thousands of planes grounded for over a year, loss of sales, and a heavily damaged reputation. The investigation uncovered neglect of fulfilling regulatory requirements.
Would you Like to Automate Compliance Activities Related to Traceability?
Traceability is useful beyond compliance. However, creating and maintaining traceability is tedious. That’s why we are exploring how Semiant could help you with this.
We prepared a one-question survey below. We’d love to hear whether any of these ideas resonates, or whether you have even better ideas.