Like any team member, a virtual quality assistant has to access data. Semiant will access the same tools that the other team members use. The question is: What tools are relevant, and which are the most important tools? Which tool shall we integrate with first?
Please help us to answer this question in this poll. And please read on to find out what Semiant would use the integration for.
Integrate with Data Sources
The primary use case for integration is to access data sources. Semiant will analyze the integrated data source to extract glossary terms. This will also allow to establish traceability between the glossary terms and the “items” in that specification.
What exactly an item is depends on the integrated tool. In a classical requirements management tool (Polarion, Jama, etc.), this would be an individual requirement. In a document system or Wiki (Confluence, Google Docs), this could be a sentence, a paragraph or section.
Integration for Other Use Cases
Eventually, we need integrations for other use cases. For instance, Semiant might integration with a task management system to communicate with users. This could be anything like build-in collaboration, which many tools provide. But it could also be an external collaboration platform, like Slack.
Any other thoughts?
If you have an important use case or integration need that is not covered here, then please reach out by using the contact button at the bottom of this page. Also, check out our 2021 roadmap.
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.