We have been developing products more or less successfully for centuries. There have been several disruptive innovations during that time, like the production line the rigorous approach of systems engineering and the introduction of electronics and now software.
Dealing with foreign languages has gotten so much easier recently. Even free translation tools produce superb results. Machine translation is a great example of the digital transformation that we are experiencing.
But why should we stop at translating text into human languages? Languages for describing systems, like SysML, have been around for decades. The method of applying such languages is called MBSE (Model Based Systems Engineering). While MBSE can have benefits when developing complex products, it requires significant investment for tools, training, consulting and configuration.
Model Based Systems Engineering (MBSE) Without the Overhead
Semiant provides you with the benefits of MBSE, but without the investment. Semiant “translates” specifications into a machine-readable system model. From the model, it extracts useful information, makes suggestions or even performs mundane but important activities. This prevents waste, reduces risk and speeds up development.
The idea of automatic translation into machine-readable languages is not new. For instance, asking a voice assistant like Amazon’s Alexa would first translate the question or command from the user into a query that the system would then execute. The user never sees the (automatically translated) query, only the outcome. This is how Semiant works, except that it translates the text into a systems modeling language.
Alexa is a general purpose virtual assistant while Semiant is a product development specific virtual assistant. The following figure shows the similarities between Amazon’s Alexa and Semiant:
This approach allows Semiant to immediately provide the benefits of MBSE to the practitioners without having to learn a new modeling language or tool. It provides value that is convincing to decision makers as well. Specifically, Semiant:
- Prevents waste: For instance, creating a glossary (or controlled vocabulary) makes sense to support compliance activities. But a glossary created by a human will almost certainly be incomplete and outdated on day one. Semiant will create it automatically, and it will always be up to date.
- Reduces risk: Having an understanding of open issues reduces the risk of slipping of delivery dates, organizational risk due to undetected gaps in compliance and so on. Semiant even makes suggestions on how to fix issues.
- Speeds up product development: By automating mundane tasks, like the creation of the initial traceability, you get more done faster with your existing team. Onboarding efficiency will also increase, as new team members get answers to many early questions from Semiant, rather than jamming expert’s time.
More Skills on the Way
Today, Semiant can extract glossaries from specifications. The system model is the foundation for this capability. But in the same way that MBSE has many benefits, we’re just scratching the surface. We will soon add more and more Semiant “Skills” over time to unlock the full potential of MBSE, without anybody having to learn a modeling language.
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.
Survey not showing? Open on separate page >>
Call them robots, Skynet or Artificial Intelligence (AI): Literature is full of machines that have a life of their own. The big question is: Will these machines create heaven on earth? Will they strive to destroy us? Or will they just be indifferent?
The scientist Ray Kurzweil introduces the concept of the “Singularity”: This is the point in time where machines will be as intelligent in humans. At this point, these machines will build even better machines. In other words, machine intelligence will surpass human intelligence. This is the runaway-point: We have no idea what will happen thereafter.
Our sole responsibility is to produce something smarter than we are; any problems beyond that are not ours to solve …”Ray Kurzweil, The Singularity is Near: When Humans Transcend Biology
However, we are still years, if not decades away from this point. At least for now, this is good news: While Artificial Intelligence is far from showing human intelligence, it is smart enough to take over more and more mundane tasks.
One such skill is the ability to process human language. Not “understand”, mind you: A machine today can understand the structure of a sentence, extract concepts and put it in relationship to others. It can even find unusual outliers and point them out to a human. But it cannot understand.
But this still helps: We humans can do the creative work, while the AI tells us where to look.
This is where Semiant, our virtual quality assistant helps experts in product development. Semiant performs the mundane tasks, so that the humans can do the interesting work.