AI requirements engineering, also known as AI-based requirements analysis, is the targeted use of AI systems across the whole requirements process, from elicitation through documentation to quality assurance. Effective prompts define context, scope and requirement level precisely and guide the AI step by step through feedback cycles. Vague wording produces weak results, while concrete instructions produce measurable, testable requirements.
Key Takeaways
- Good prompts for requirements engineering can run to about four pages: scope, context, role, templates and measurable acceptance criteria have to be spelled out, or the AI delivers quantity instead of quality.
- AI systems claim to know well-known requirements templates but get them wrong: if you don’t supply the template as concrete input, you get a made-up version back.
- Diagrams such as activity and state diagrams disappeared with the shift to agile, yet they are missing as the overarching structure for business-process-oriented testing and should be rebuilt as part of the requirements.
- Requirements that support testing need measurable non-functional requirements with concrete values instead of vague words like “clear” or “performant.”
Good Requirements Are the Foundation for Testing
Without requirements, testing is barely possible, at least not requirements-based testing. That is the starting point for AI requirements engineering. If you don’t have a clean test basis, you derive test cases from gut feeling and hope you are checking the right things. This is the crux: test quality depends directly on the quality of the requirements.
Andreas Guenther of the SOPHISTs puts the goal clearly. The idea is to use AI to build the best possible test basis, instead of staring into a void from a testing perspective. A measurable, testable requirement saves a lot of guesswork later.
Requirements engineering covers much more than writing down user stories. Elicitation, documentation, validation and management all belong to it. The most time-consuming part is often not the documentation but elicitation and validation: getting at the information scattered across people’s heads, documents and gut feelings in the first place.
Why Diagrams Belong Back in the Requirements
With the shift to agile, many hard-won diagrams disappeared. Epics, features, user stories and acceptance criteria took their place: text, text and more text. Andreas thinks that was a bad idea, because a picture is worth a thousand words.
The overall structure of a system is hard to capture in language alone. Use case diagrams, activity diagrams and state diagrams show which processes connect with each other. That structure is what lets you derive not just individual test steps but whole test scenarios and test procedures.
In practice, about 70 to 80 percent of requirements are written in natural language, whether in a classic or an agile setting. The rest, which carries the whole thing, is structure expressed in diagrams. Whether that is UML or, for technical systems, SysML matters less. What matters is that some structure exists at all.
What AI Requirements Analysis Really Delivers
AI produces a lot of output for every question, and that is impressive at first. Whether the output has any quality is a different matter. Look a little closer and most of it turns out to be nonsense, with the AI hallucinating.
The value only appears when the goal is quality, not quantity. AI is good at connecting things you hadn’t thought of yourself, which helps you slice features sensibly or bring in new ideas. With a good prompt, an initial interview or a product vision can be turned into a structured backlog.
The SOPHISTs have worked out a double-digit number of concrete use cases for this, drawn from a much larger collection of around 60 to 70 defined scenarios. They cover the entire process: elicitation, documentation, validation and management. AI also works well for brainstorming and for discovering new requirements.
What a Good Prompt for AI Requirements Engineering Looks Like
A good prompt works from the general to the specific, just like a classic requirements training course. First the scope, then the context, then the individual requirement levels.
It starts with the question of the test object and the context. Are we talking about the app alone or including the server? About a single component or the whole system? About functional or non-functional requirements? You have to teach the AI this classification step by step.
Precise terms make the difference. “Generate some requirements” is too vague. The output only becomes usable once you pin down the level (business, system or component) and whether the requirements are functional or non-functional. For non-functional requirements, that means no vague wishes like “clear” or “performant,” but concrete, measurable values.
That is the difference between a lot of text and real requirements quality. The prompt the SOPHISTs build step by step in their workshop runs to about four pages. The result: user stories that follow a template, acceptance criteria and testable non-functional requirements.
“You have to nudge the AI a bit with the prompt. But it works.”
(Andreas Guenther)
Treat the AI Like a New Employee
You can treat the AI like a new employee who brings knowledge but needs guidance on where to find it. Instead of generating everything at once, let the AI work in feedback cycles: first ask whether the interim result fits, then take the next step.
Breno Pinheiro recommends giving the AI a specific role, such as product owner or tester. That way it draws on the matching part of its training data and delivers output from the perspective you want. This saves iterations, although a few targeted ones remain useful.
A glossary with clearly defined domain terms cuts down on vague wording. Guidelines you provide, such as a requirements guideline as an upload, give the AI the framework it should work within.
Watch Your Sources: AI Lies with a Straight Face
AI always produces an answer, but not always an honest one. Ask it about a specific template and it will claim to know it. The lie only comes out when you ask about the exact structure.
That is why the source belongs in the prompt. “Generate a requirement using the template” is not enough. Which template? If you want a specific one, supply or upload it instead of relying on what the AI supposedly knows.
If the first output doesn’t fit, persistence pays off: provide the template again, adjust precisely, run another loop. With enough concrete input, you end up with solid requirements quality.
Diagrams from Text: The PlantUML Workaround
Text-based AI systems often refuse to produce graphics directly and explain that they only work with text. The workaround: ask for PlantUML code, because that is text too.
You then run the generated PlantUML code through a compiler and get a diagram. That way you get flowcharts and other diagrams through an intermediate step, even though the AI doesn’t output graphics itself. With many elements, it is worth a quick check whether everything is really needed.
Which AI Tool Works Best?
There is no clear front-runner for requirements engineering. The tools have generally improved with updates over time, but no system stands out in principle.
The common all-purpose tools can handle almost anything if you tailor the prompt. Some are better at images, presentations or story maps, but the choice is more a matter of preference. Confidentiality matters more than the tool.
| Factor | What matters |
|---|---|
| Data privacy | Open or closed system, depending on what your company approves |
| Confidential data | Do not paste confidential data into open systems |
| Training basis | The more good requirements as input, the more accurate the output |
| Tool fit | All-rounders for text, specialists for images or presentations |
The biggest lever is not the tool but the data. The more good requirements are available as a training basis, the better the AI understands what the company does and what typical requirements look like at each level. Internal projects often stay rough, while external fixed-price projects go into more depth. Without this information, the AI misses the mark.
How to Get Started
A simple starting point is a prompting guide with a step-by-step introduction. A two-pager like that shows what matters when prompting: define the scope, set the context, assign roles, use precise terms.
If you want to go deeper, a book by the SOPHISTs on using AI in requirements engineering collects proven use cases. It doesn’t include all of the roughly 70 scenarios they tested, only those with the most practical value, each with examples and a discussion of what works, what doesn’t and how to improve it. The book is published by dpunkt.verlag.
Frequently Asked Questions
What Happens During Testing When There Are No Clear Requirements?
Without requirements, there can be no requirements-based testing. Without a clear test basis, test cases are derived based on gut feelings, and one can only hope to be testing the right things. Test quality is therefore directly tied to the quality of the requirements. A measurable, testable requirement saves a lot of guesswork later on, for example with non-functional requirements that use concrete values instead of vague descriptions like “clear.”
Are user stories and acceptance criteria sufficient to fully describe a system?
No. About 70 to 80 percent of requirements are formulated in natural language, whether in a traditional or agile context. The rest is structure: use case diagrams, activity diagrams, and state diagrams. They show which processes are related and form the basis for entire test scenarios and test procedures, rather than just individual test steps. Whether UML or SysML is used is secondary.
Why does the output of AI systems often seem better than it actually is when it comes to requirements?
AI initially provides a lot of text for every question, and quantity makes an impression. Upon closer analysis, however, it becomes clear that much of it is nonsense and that the system is hallucinating. Value is only created when quality is the goal: AI connects things you hadn’t thought of yourself, sensibly breaks down features, or fills a structured backlog based on a product vision.
How detailed does a prompt need to be to produce usable requirements?
Significantly more detailed than a one-liner. The prompt that the Sophists build step by step in the workshop is about four pages long. It works from the broad to the specific: first the scope and test object, then the context, then the requirement level, that is, business, system, or component; functional or non-functional. The result is template-based user stories, acceptance criteria, and testable non-functional requirements.
Is there any benefit to assigning a specific role to AI?
Yes. Breno Pinheiro recommends having the AI act specifically as a Product Owner or tester. It then accesses the relevant portion of its training data and responds from the desired perspective, which saves time in the iteration process. In addition, a glossary with clearly defined domain terms and included guidelines (such as a requirements guideline available for upload) are helpful.
Does AI reliably recognize common requirements templates?
No. When asked about a specific template, the system claims to know it and provides a made-up version. This only becomes apparent when you ask about the exact structure. If you want a specific template, you must provide it as input or upload it. If the initial output isn’t correct, the only solution is to specify the template again and make adjustments.
How do you get diagrams if the AI system only outputs text?
Via the workaround of PlantUML. Text-based systems often refuse to output graphics directly but generate PlantUML code, since that, too, is text. This code is then run through a compiler that renders the diagram. This creates flowcharts via an intermediate step. With many elements, it’s worth checking whether everything is really needed.
What matters most when selecting an AI system for requirements engineering?
There is no clear frontrunner. The popular all-around systems cover almost everything when the prompt is tailored specifically; individual systems showcase their strengths with images, presentations, or story maps. More important than the tool itself is the level of confidentiality (whether it’s an open or closed system) and the data set: The more high-quality requirements are available as input, the more accurate the output will be.
