4 theses on requirements engineering in the age of AI

On this occasion: I will be taking part in an online panel discussion with Chris Rupp, Jens Kawelke and Henning Femmer on September 19 (register here for free). In preparation for the event, I organized my thoughts on the topic once again. The result is 4 theses on requirements engineering in the age of AI.

And while we're on the subject of events: In a few weeks, on September 21, the next systems.camp Nord of the GfSE will take place in Hamburg. I've always enjoyed attending the systems.camps and have even helped organize them myself a few times. Click here to register.

And now, as promised, my 4 theses on requirements engineering in the age of AI:

4 theses

Admittedly: At SE-Trends I already have a lot on the topic of AI and Requirements management published. In particular, I have been working with AI since 2020 (i.e. before ChatGPT) and with requirements since 2006.

In recent years, developments have come thick and fast, with one piece of news following the next and hype barely distinguishable from serious reporting. The following four theses are intended to help bring some structure to the chaos.

A long, long time ago (2006) I worked as a consultant for the HOOD Group. Even back then, HOOD offered a small utility called DESIRe for DOORS and Word free of charge. The utility identified weak words and, if I remember correctly, at least rudimentary sentence structures. It wasn't AI-based, but it was very useful with little effort.

There were also quality checkers for requests long before ChatGPT. Quite well known is probably reQlab for Polarion, which has been around since at least 2019. IBM also developed the AI back in 2011 Watson have long been unleashed on requirements.

With the success of ChatGPT, many tool manufacturers incorporated a chat interface into their tools. Consultants and researchers also regularly present AI extensions for requirements management tools. However, these tools often have the character of prototypes or gimmicks. At least I am not yet aware of any AI that speeds up work by orders of magnitude. But that's what it's all about: revolutionary, not evolutionary improvement.

In order to really increase productivity by an order of magnitude, major problems need to be tackled. I see traceability and reuse as the issues that have the potential.

Functioning Traceability (Traceability is enormously powerful: only if it works can we handle changes with confidence and ensure that all dependencies are taken into account. In some industries, such as automotive, the number of requirements is so high that traceability can only be managed with partial automation anyway. (Whether specifications with tens of thousands of requirements make sense remains to be seen).

Reuse is a nightmare for many companies: copy-and-paste reuse results in costly maintenance and products that are frustratingly inconsistent for customers. The trend towards modular systems and product lines that are developed over decades makes reuse increasingly important.

The two topics are related and AI has great potential here, as recognizing similarities and relationships has always been a strength of AI, even before the success of generative AIs. So far, I haven't seen anything convincing from the tool manufacturers. However, there are some start-ups that are integrating themselves into existing tools, such as Raiqon.ai.

Going one step further trace.spaceThe start-up is developing a requirements management tool from scratch in which AI is firmly anchored in the architecture. But it's not just about requirements, as we'll see in point 3.

Product development is about much more than just requirements. In design, circuits have to be designed, mechanics constructed and software written. Effective requirements management is certainly helpful, but we can only achieve a quantum leap in productivity if we include the other areas.

And once product development has been completed, the entire product life cycle remains, i.e. operation, support, disposal and much more.

There are specialized AI solutions in each of these areas, but they only cover that specific area. Truly comprehensive AI tools are hard to find. This brings us back to the topic of traceability, except that point 2 was about traceability between requirements and this point is about traceability between all data sources.

In this segment Spread.ai is an interesting candidate, even if the tool does not (yet) support requirements traceability.

If we want to scale point 3, then we need modeling, at least behind the scenes. Without a (semi-)formal model, an AI will not be able to make reliable statements. A model is based on a modeling language that specifies syntax and (partial) semantics. A generative AI can hallucinate, but a statement based on a formally correct model is at least correct with regard to the model semantics.

In practice, this means that the AI maintains a model and can also use it for verification purposes. This would give us a central model that serves as a "single source of truth". This suddenly brings us to the topic of MBSE:

MBSE has enormous potential, but overwhelms many users. For this reason, I had already put forward the thesis several years ago that MBSE not successful in this decade will be. This is where AI has the potential to take the burden off the user: instead of letting humans do the modeling, AI does it "behind the scenes".

It is important to note that this does not have to be a SysML-model (or another standardized modeling language). It is only important that the model can accurately represent the information of the model in a way that allows formal reasoning.

Conclusion

These are my four theses on AI and requirements engineering. I am curious to see what other perspectives Chris Rupp, Jens Kawelke and Henning Femmer will bring into play on September 19: The more different our views are, the more interesting the discussion will be.