AI-supported requirements engineering refers to the targeted use of AI systems along the entire requirements process: from elicitation to documentation and quality assurance. Effective prompts precisely define the context, scope and requirements level and guide the AI step by step with feedback cycles. Vague formulations deliver weak results, concrete specifications deliver measurable, testable requirements.
Key Takeaways
- Good prompts for requirements engineering are four pages long: scope, context, role specification, templates and measurable acceptance criteria must be explicitly specified, otherwise the AI will produce quantity instead of quality.
- AI systems claim to know known requirements templates, but deliver incorrect results: if the template is not provided as concrete input, a fictitious variant is returned.
- Diagrams such as activity and state diagrams have been eliminated in agile working, but are missing as a superstructure for business process-oriented testing and should be rebuilt as part of the requirements.
- Requirements quality for testing requires measurable non-functional testing with concrete values instead of vague formulations such as “clear” or “performant”.
Good requirements are the prerequisite for testing
It is almost impossible to test without requirements, at least not requirements-based testing. If you don’t have a clean test basis, you derive test cases from your gut feeling and hope to test the right thing. This is precisely the crux of the matter: test quality depends directly on the quality of the requirements.
Andreas Guenther from the Sophists describes the goal clearly. It’s about using AI to create the best possible test basis instead of looking into a content void from a testing perspective. A measurable, testable requirement saves a lot of guesswork later on.
Requirements engineering covers more than just writing down user stories. Determining, documenting, validating and managing are all part of it. The most time-consuming part is often not the documentation, but the elicitation and validation: getting to the scattered information in heads, documents and gut feelings in the first place.
Why diagrams belong back in the requirements
With agilization, many hard-won diagrams have disappeared. They were replaced by epics, features, user stories and acceptance criteria: Text, text and more text. Andreas thinks this is a bad idea, because a picture is worth a thousand words.
The superstructure of a system is difficult to depict with language alone. Use case frameworks, activity diagrams and status diagrams show which processes are connected. This structure is the basis for deriving not only individual test steps, but also entire test scenarios and test procedures.
In practice, around 70 to 80 percent of requirements are formulated in language, either classic or agile. The rest is structure, represented in diagrams. Whether UML or, in the case of technical systems, SysML, plays a subordinate role. What is important is that structure is created at all.
What AI really does in requirements engineering
AI initially delivers a lot of output for every question, and that makes an impression. Whether this output is of quality is another question. A closer analysis reveals that most of it is nonsense and the AI is hallucinating.
Value is only created when the goal is quality rather than quantity. AI is strong at linking things that you haven’t thought of yourself and thus cutting features in a meaningful way or introducing innovations. An initial interview or a product vision can be turned into a structured backlog with a good prompt.
The sophists have worked out a two-digit number of concrete application scenarios for this, from an even larger collection of around 60 to 70 defined scenarios. The entire process is covered: determining, documenting, validating and managing. AI is also suitable for brainstorming and identifying new requirements.
What a good prompt for requirements engineering looks like
A good prompt works from the rough to the fine, just like a classic requirements training course. First comes the scope, then the context, then the individual requirement levels.
This starts with the question of the test object and the context. Are we talking about the app alone or including the server? Are we talking about a component or the entire system? Functional or non-functional requirements? You have to teach the AI this classification step by step.
Precise terms are the lever here. “Generate requirements” is too vague. The output is only usable if it is defined at functional, system or component level, functional or non-functional. For non-functional requirements, this means: no vague wishes such as “clear” or “performant”, but concrete, measurable values.
This is the difference between a lot of text and real requirements quality. The prompt, which the sophists build up step by step in the workshop, comprises around four pages. The result is user stories based on templates, acceptance criteria and testable non-functional requirements.
You have to push the AI a bit with a prompt. But it works. Andreas Guenther
Work with the AI as you would with a new employee
AI can be treated like a new employee who brings knowledge with them but needs guidance on where to access it. Instead of generating everything at once, let the AI work in feedback cycles: first ask whether the interim result is suitable, then take the next step.
Breno Pinheiro recommends assigning the AI a specific role, such as product owner or tester. This allows it to access the appropriate part of its training data and deliver output from the desired perspective. This saves loops, even if a few targeted loops remain useful.
A glossary with clearly defined domain terms reduces vague formulations. Supplied specifications, such as a requirements guideline as an upload, give the AI the framework within which it should work.
Be careful with sources: AI is a stone-cold liar
AI always generates an answer, but not always an honest one. When asked about a specific template, the system claims to know it, and the lie is only revealed when you ask about the exact structure.
This is why the source belongs in the prompt. “Generate a requirement according to template” is not enough, because according to which template? If you want a specific template, you have to supply or upload it instead of relying on the supposed knowledge of the AI.
If the first output doesn’t fit, persistence helps: specify the template again, make precise adjustments, turn the loop. With enough concrete specifications, the end result is reliable requirements quality.
Diagrams from text: the detour via PlantUML
Text-based AI systems often refuse to output graphics directly, claiming that they are only text-based. The solution: request PlantUML code, because this is also text.
The generated PlantUML code is then run through a compiler to produce a diagram. This creates flowcharts and other representations via an intermediate step, even if the AI does not provide any graphics directly. For many elements, it is worth taking a quick look to see whether everything is really needed.
Which AI tool is best suited?
There is no clear frontrunner for requirements engineering. Over time, the tools have developed more positively with updates, but no system stands out in principle.
The common all-rounders can be used for almost anything if the prompt is specifically adapted. Some systems are better suited to images, presentations or story maps, but the choice is more a matter of preference. More decisive than the tool is the question of confidentiality.
| Factor | What matters |
|---|---|
| Data privacy | Open or closed system, depending on company approval |
| Confidentiality | Do not blindly tip into open systems |
| Training basis | The more good requirements as input, the more accurate the output |
| Tool suitability | All-rounder for text, specialists for images or presentations |
The most important lever is not in the tool, but in the data. The more good requirements there are as a basis for training, the better the AI understands what the company does and what the typical requirements are at each level. Internal projects often remain rough, external projects with a fixed price go deeper. Without this information, the AI misses the mark.
How to get into the topic
A simple starting point is a prompting guide with a step-by-step introduction. Such a two-pager shows what is important when prompting: define scope, set context, assign roles, use precise terms.
If you want to delve deeper, you will find a collection of tried and tested application scenarios in a book by the sophists on the use of AI in requirements engineering. It does not bundle all of the more than 70 tested scenarios, but those with the best practical benefits, each with examples and a discussion of what is good or bad and how to improve it. The book is published by dpunkt.verlag.
