When AI writes the requirements …

The new role of requirements management tools in the age of generative AI

The capabilities of generative AI are impressive and have now reached the field of requirements engineering. Not only can requirements be formulated in seconds, but AI can also classify them, identify relationships, assess the quality of the description, and even provide suggestions for refinements or the derivation of test cases.

Against this backdrop, one question seems almost inevitable: If AI can do all that, do we still need dedicated requirements management tools (RM tools) at all?

At first glance, the answer seems obvious. After all, if a technology takes over precisely the tasks for which experts have previously used specialised tools, those tools could become redundant. Yet this conclusion falls short, as it overlooks what requirements engineering and management are actually about.

The limits of AI in requirements engineering

Modern approaches to artificial intelligence can not only formulate requirements, but also classify, compare and relate them to one another. [1] AI recognises patterns in existing requirements, identifies similarities, highlights potential conflicts and helps to systematically refine rough requirements or translate them into other development artefacts.

In doing so, it operates precisely in the area long considered the core of requirements engineering: the structuring, understanding and concretisation of requirements.

This is precisely why the initial question arises so clearly. If AI can take on these tasks, what is left for traditional RE tools?

The answer lies in a central aspect that is often overlooked in discussions: AI operates on the basis of probabilities:

• A requirement is assigned to the correct category (only) with a certain probability,
• a relationship is recognised (only) with a certain probability, and
• a conflict is identified (only) with a certain probability.

Admittedly, in many cases these results are now correct and accurate. Nevertheless, all these results remain, for the time being, merely suggestions.

In practice, this consequently always raises questions such as: “Who decides which of these suggestions actually apply and which of them the customer or market really needs?” Or: “Where is this decision recorded in such a way that all parties involved can build on it (even in the long term)?”

And there is yet another aspect that is frequently overlooked: “Who actually takes responsibility for individual decisions?”

Requirements are not non-binding suggestions; they form a defined basis for development, testing and, ultimately, for quality and liability. This is precisely why it is not enough for something to sound plausible; it must also be consciously decided upon and accounted for.

This is precisely where the limitations of AI in requirements engineering become apparent! AI can only analyse content and make recommendations. It can neither create binding commitments nor ensure that decisions made are correct and are implemented correctly within the project. Yet both are aspects that lie at the heart of all project work, including requirements engineering.

From models to structures

For requirements to be used effectively in a project, a clear foundation is required. This foundation is the model that underpins the work. This explicitly does not refer to an AI language model, but rather to the domain-specific and structural model according to which requirements are organised and interpreted within the project.

Such a model defines the types of requirements that exist, how they relate to one another, how they relate to system elements, and the rules according to which they may be refined or modified. It establishes a common methodology and ensures that they do not arise in isolation, but form part of a consistent overall picture of the artefacts of a development project.

Crucially, this model does not arise automatically through the use of AI. On the contrary: AI generally even requires such a structure in order to function effectively. Without defined categories, consistent terminology and clear rules, individual results that appear plausible may emerge, but no stable overall concept.

There is also a practical problem. Once a certain level of complexity is reached, such a model can no longer be reliably ‘maintained’ in documents, spreadsheets or tickets. As soon as several people are involved, and requirements grow and change, a purely document-based approach reaches its limits. Relationships are interpreted inconsistently, changes are lost or identified too late, and traceability suffers.

It is precisely at this point that it becomes clear why – even in the age of AI – a RM tool remains essential. It not only maps out this structure but also ensures that it can be adhered to in day-to-day project operations.

When complexity becomes a problem

Another aspect is often underestimated in many discussions. AI amplifies existing conditions. In a well-structured environment, it can significantly improve the quality of requirements and, in particular, the efficiency of related work. AI then helps to quickly identify inconsistencies, fill gaps and make interrelationships more transparent.

In an unstructured environment, however, and particularly where requirements are poorly and incompletely documented, the opposite often occurs. When they are refined, classified and linked on a poor foundation, AI tends to ‘hallucinate’. This results in more content lacking substance and structure, supposed relationships and variations, without it being clear what is actually relevant, correct and useful.

At this point, it becomes clear why specialised RM tools are not losing their importance, but are, on the contrary, becoming indispensable. Their key added value today lies no longer merely in the documentation of requirements, but in their role as the structural backbone of the entire development project.

Above all, an RM tool is not a passive repository. It is a system that actively dictates how information may be structured, linked and modified. It ensures that they are not created in isolation, but always within the context of the system to be developed. Relationships follow clear semantics rather than being set arbitrarily, and changes remain traceable at all times.

These characteristics do not arise through personal discipline alone, nor through processes on paper. They require a technical system that consistently enforces these rules and thereby creates binding standards.

Conclusion: AI needs a system to be effective when working with requirements

This provides a clear answer to the initial question. Generative AI does not render RM tools obsolete. Rather, they become a prerequisite for being able to make meaningful use of AI’s potential in project work at all.

The more powerful AI becomes, the easier it is to generate, analyse and further develop requirements. At the same time, however, there is a growing need to organise this content into a clear structure and maintain consistency throughout the entire lifecycle. Without an RM tool, this means less clarity and more uncertainty. With an RM tool, it means better decisions, higher quality and genuine traceability.

The future of requirements engineering is therefore not determined by how requirements are written, but by how well they are organised, managed and implemented. And that simply isn’t possible without specialised tools.

Notes:

Would you like to discuss artificial intelligence and RM tools with Dr Sebastian Adam? Then visit his website or contact him on LinkedIn.

[1] Goals and principles for gathering requirements

Would you like to discuss the present and future of RE tools in the context of artificial intelligence as an influencer or thought leader? Then share this post on your social media channels.

Dr Sebastian Adam has published two more posts on the t2informatik Blog: