Automatically model requirements without anyone noticing

Traditionally, requirements are recorded in natural language and are therefore accessible to humans. However, they can only be processed by machines to a limited extent. This means that a human still has to read the requirements for many activities. And again. And again. Highly paid engineers often work through checklists that could be handled by a student trainee. This drives up costs and frustrates the team. And it doesn't even work reliably.

Requirements models, on the other hand, enable a completely different level of automation. The problem with this is that proper requirements modeling is very demanding. The team must be able to handle the modeling language, be methodically fit and be proficient in the tools used. And if the whole thing is not set up properly and the initial architecture is not right, the work can quickly fizzle out.

But there is a third way: we can stick with the natural language description, but also analyze it automatically. The result of the analysis is a requirements model. From this model, the system can identify weak points in the textual description, such as gaps or contradictions. We can then present this list to the users. The users do not even have to know that the model exists.

In the following, I will show you an example of what a generated model could look like and how we can use it to find weaknesses in the requirements. The article is tool-neutral. On October 19/20, I will present these concepts tool-specifically in two webinars (English/German).

Registration for the webinar on 19.10.2022 in English and on 20.10.2022 in German >>

Complexity requires a rethink

Due to increasing Complexity and stricter Compliance-Many teams in product development are facing major challenges due to the new requirements. Many of the classic measures (team enlargement, training, coaching, consulting) are labor-intensive, costly and take many months before positive results are seen.

Model-Based Systems Engineering (MBSE) is a promising way to deal better with complexity. However, MBSE requires rethinking and further training. Employees have to learn a new language, for example SysML. But you don't learn a language overnight - apart from the fact that methodological knowledge also needs to be internalized. And experts with many years of experience who can help with this are in short supply.

Even worse: Classic MBSE stores the costs up front. Decision-makers are reluctant to make more advance investments than seem necessary. In addition, there are enough anecdotes about projects that have gone to the wall.

But just as we already use tools such as Google Translate to read foreign-language texts, we can use AI to model for us. Even if AI-generated models are still comparatively simple today, they are already highly useful for specific applications.

Analyze textual requirements in context

There are now many tools that analyze texts, including requirements. These generally use Natural Language Processing (NLP) in. However, at least the tools I am familiar with ignore the context and only analyze individual requirements.

This can be useful: We can use these techniques to check sentence structures, require certain completeness criteria, recognize weak words and much more. But if we include the context, we can check many more relevant criteria. Here is a concrete example:

Example: Requirements from building safety

The "requirements" shown here come from a real customer in the building security sector. Therefore, some parts of the sentences are grayed out, but they are not really relevant for the following discussion. Furthermore, not all sentences are requirements.

What could an automatically extracted model look like behind the scenes and what can we do with it?

Modeling requirements

To say it right away: we certainly cannot derive a complete system model at the push of a button. It makes more sense to model a relevant subdomain in order to derive a benefit from it. Before I show the extracted domain model, a few other possibilities:

• Behavioral model in the form of activities and control flows. We can use such a model to identify blockages or endless loops.
• State model in the form of states and state transitions. We could use such a model to analyze data sheets for microchips.
• Interface model in the form of components and interfaces or ports. This allows us to identify unused or incorrectly linked ports.
• Parameterization in the form of named parameters and units of measurement. This would allow us to find inconsistencies between requirements and tests.

Extracted domain model

At least theoretically, the text shown contains enough information to extract entities and their relations. This could look like this:

Even though this diagram was inspired by UML, it is far from a reasonable class model. For example, it is not clear from the requirement text whether an entity is a class or an object.

Nevertheless, we can use such a model to ask interesting questions and improve the requirements on this basis. For example:

• What is the relationship between "Fire Alarm" and the overall system? Is there possibly a missing relation?
• Are there any similarities between "Smoke Alarm" and "Heat Alarm" that we might be able to use?
• If a system architecture already exists, the model could be used to partially automate the allocation of requirements to the model.
• With the help of the model, the user can analyze requirements in context without having to create an explicit traceability.
• The model can form the basis for an automatically maintained glossary, or Ontology form.

What is relevant here is that for all these use cases we do not confront the users with the model, but with the knowledge gained from the model in the form of context information, suggestions for improvement or comprehension questions (the answers to which improve the requirements).

State of the art

There is already a lot of research activity on the ideas presented here, but surprisingly few ready-to-use solutions. I work with Semiant itself on a corresponding solution. It currently supports a simple quality check as well as AI-supported glossary extraction and integration into common requirements management tools such as Polarion, DOORS Next or Jama Connect.

Conclusion

Most importantly, users do not necessarily need to learn modeling languages to benefit from the results. Automated modeling has the potential to support developers with valuable results and automation of monotonous (but important) tasks so that they can focus on the creative aspects of development.

I'll tell you more about modeling requirements live in the webinar on October 19/20. Register now >>

Image source: FreePik