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.
Photo by Esther Jiao on Unsplash