5 possibilities for automation in requirements management with AI

Even if AI - Artificial Intelligence - is a platitudinous term, AI is undoubtedly finding its way into systems engineering. AI is generally about the automation of intelligent behavior. The important keyword is "automation". AI enables a degree of automation that would not have been possible even five years ago. For requirements management, this means that people can focus on the creative work of development rather than on mundane tasks for which they are actually overqualified.

Here is a list of 5 activities in requirements management that will hopefully soon be taken over by machines.

I think this topic is so exciting that I have created Semiant develop a virtual quality assistant. Read more at the end of the article. Answers to these questions Survey I would be very pleased.

Why requirements management?

In this article, I am talking explicitly about requirements management. The reason is that requirements are recorded in natural language. Until recently, natural language could not really be processed by machines. But that is exactly what is currently changing: toolkits for processing natural language are now fully developed (Natural Language ProcessingNLP).

Of course, there are also approaches that work without NLP, but I know of few that have gained widespread acceptance. One way, for example, is modeling: a state model can represent a behavior better than prose in some situations, and it can be processed further by machine. However, many users feel too restricted, especially in requirements management - apart from the training required. Formal modeling of requirements therefore remains a niche solution. The same applies to Text templates such as the Master stencils from Sophist. These are somewhat more widespread, as they do not require expensive tools. But here too, training and discipline are required. In addition, templates alone are not sufficient for machine processing.

But NLP can also cope with requirements that were written without templates. This in turn means that users do not have to retrain to benefit from automation in requirements management with AI. And here are a few possibilities:

1. find contradictions between requirements

If page 5 of the specification states that the system should react in 10 ms and page 95 states 15 ms, how likely is it that this will be detected in time - or perhaps even completely overlooked? In order to automatically recognize such contradictions, a corresponding system must analyze all requirements together, recognize concepts across the board and relate their properties. The currently available systems can analyze individual requirements, but not requirements in an overall context. This will soon change.

2. generate and maintain a list of concepts (glossary)

A glossary of terms in the product is a powerful tool. However, I have often seen that attempts to create one by hand fail: there are quickly long discussions about what a term actually means. And when the glossary is finished, it is incomplete and already out of date.

Our development teams often start a new project with the creation of a glossary. And in no time at all, half the budget was used up without reaching an agreement.

Dr. Veit Lauterberg, Chief System Architect, Thales Group

But this is a task that an NLP system can take on automatically with comparative ease. It is true that such a system cannot make a statement about the meaning of a term. Instead, it can show the context of the term: How does this term relate to others? Which requirements relate to the same term? Suddenly, developers have the ability to see and discuss the concepts in context, which leads to clarity. More importantly, the glossary is complete and up-to-date.

3. support traceability

As just indicated, automatic glossary generation tumbles out certain links as a side effect. The glossary shows many links that only exist implicitly. For example, it links all requirements that deal with the same concept. Automation with an AI system could go one step further here and suggest new links to the user or question existing ones.

4. derive models

In another articleI have already mentioned how we can derive models from requirements. Here is an example:

Here we can see that the relationship between the simulator and session has been identified, as well as the specialization of the session. In other words, a class or Block model created automatically.

In addition to extracting the static model (classes, blocks), a system could even extract a dynamic model (states, activities). There are already tools that do this for individual requirements.

However, we should not expect miracles when automatically deriving models. Even if the requirements are clearly formulated - and often they are not - there is always room for interpretation. A system must therefore request user feedback in order to resolve the ambiguities.

4. find and identify ambiguities

And that brings us to the next point: although an automated system cannot really understand content, it can certainly recognize ambiguities and gaps. Existing tools such as IBM Watson do this by looking out for "weak words". Terms such as "a few", "sometimes", "on time", etc. express vagueness. But here, too, there is no reference to all requirements in the overall context.

Once the system has identified the ambiguities, the user must resolve them. But here too, we can go one step further:

5. reformulate requirements

Converting aspects of models into requirements is much easier than the other way around, since every aspect of the model can be described in words. Especially in the case of ambiguities, an automated system can ask questions and insert or update requirements based on the answer, as shown here:

The example shows how the tool recognizes a relationship but does not know how to represent it in the model. After the selection, the tool can add the requirements accordingly.