“Write user stories for an ordering portal.” Most requirements prompts look like this. The answer looks plausible, reads well, and nobody can say whether it is good. The next person asks the same thing in different words and gets a different answer. That is not requirements engineering. That is a chat.
The IREB special interest group #AIREB has published the AI4RE Prompt Guide: free prompt templates for typical requirements engineering tasks. This post shows what is in it, what a good template looks like, and why I think the next step after a prompt template is a skill in the repository.
23 Prompts Along the RE Activities
The guide follows the four activities of requirements engineering. At the time of writing, it has 23 prompts:
- Elicitation: introduce a new domain, identify stakeholders, prepare an interview, plan a workshop, refine a transcription, transcribe whiteboard images, identify requirements
- Documentation: specify a requirement, generate a synonym table, decompose a requirement, generate a model from text and text from a model, explain requirements in simple language, generate a persona, generate test cases, generate requirements from source code
- Validation: compare a specification with source code, analyze requirements consistency, check model consistency, generate a wireframe
- Management: analyze the impact of a change request, tag requirements, trace requirements
Each prompt has its own page with the same structure: the RE task, the AI approach and a short conclusion, then the prompt template with variables to configure, pitfalls and tips, and a filled example with sample output. The guide is clear that it reflects a field that moves fast and is meant for inspiration and discussion, not as a standard. And it starts with two rules that every team should put on the wall: never put sensitive data in a prompt, and always validate the output before you use it.
Anatomy of a Prompt Template
The template for Specify Requirement shows the structure well. Shortened:
AI's role: Requirements specification expert
My role: Requirements engineer
Purpose: Requirement formulated in an optimized way to increase
readability and comprehensibility.
Task: Optimize the formulation of the following requirement.
Formulation standard: [FORMULATION]
Quality standard: [QUALITY]
Step 1: Identify the standard used for the input requirement.
Step 2: If there are more appropriate standards, stop, suggest
alternatives and ask which one should be used.
Step 3: Formulate the requirement according to the chosen standard.
Step 4: Validate the requirement according to the quality standard.
Request missing information and repeat step 3.
Format: [FORMAT]
Input: [REQUIREMENT]
Five building blocks make the difference to a chat prompt:
- Roles. Who the AI is and who you are. This sets the vocabulary and the level of the answer.
- Purpose and task. What good output looks like, not only what to do.
- Variables.
[FORMULATION]can be a user story, a use case, IEEE or the SOPHIST template.[QUALITY]can be INVEST, ISO/IEC/IEEE 29148 or IREB CPRE. The template stays the same, the standard is a decision you make. - A checkpoint. Step 2 tells the model to stop and ask instead of picking a format on its own. This is the most underrated line in the template. A model that guesses quietly produces confident output in the wrong form.
- A format. The Identify Requirements template asks for a table with the requirement in one column and a quote from the stakeholder input in the other. That one column gives you traceability for free: you can check every requirement against what the stakeholder actually said.
The Pitfalls Are the Best Part
Templates are easy to copy. The pitfalls sections are where the experience is. For Specify Requirement, the guide lists, among others:
- Ambiguity in the input. A vague requirement leads to wrong assumptions. Give context: system boundary, stakeholders, intended behaviour.
- Overfitting to patterns. The model falls back on templates it has seen in training, even when they don’t fit your domain. Add domain examples and constraints.
- Lack of domain knowledge. Regulatory and technical details get simplified. Use the model for the first pass, and let an expert review.
- Limits of quality validation. The model will not enforce every criterion of ISO/IEC/IEEE 29148, especially verifiability and traceability. Use a checklist.
None of this is new to a requirements engineer. That is the point. The guide doesn’t replace RE knowledge, it shows where to apply it when an AI writes the first draft.
From Prompt Template to Skill
A prompt template that you copy into a chat has one weakness: it lives in someone’s clipboard. Everybody adapts it a little, nobody knows which version produced which document, and the output stays in the chat history.
A skill for a coding agent is the same idea, one step further. It has the same building blocks: a role, steps, checkpoints, a template and an output format. But it lives in the repository. It is versioned, reviewed like code and runs the same way for everyone on the team. And the result is not a chat answer but a file in docs/, next to the code that implements it.
Many prompts of the guide have a direct counterpart in the skills of the AI Unified Process:
| AI4RE Prompt Guide | AI Unified Process skill |
|---|---|
| Identify requirements | /requirements |
| Generate model from text | /entity-model, /use-case-diagram |
| Specify requirement | /use-case-spec |
| Analyze requirements consistency | /spec-review |
| Generate test cases | /test-case |
| Compare specification with source code | /coverage-check |
| Generate requirements from source code | /reverse-engineer |
The guide and the skills come from different directions and arrive at the same structure. I take that as a good sign for both.
How to Use the Guide
- If you work in a chat: stop writing requirements prompts from scratch. Copy the template, set the variables and keep the checkpoint.
- If you work with an agent and skills: read the pitfalls and compare them with your skills. Does your skill stop and ask when the input is ambiguous? Does its output reference the source?
- If you train people: the filled examples are good material to discuss. Where is the output good, where would you push back?
In my Spec-Driven Development workshop, I close the first day with the guide. After an afternoon of writing requirements, use cases and reviews with skills, the participants see the same building blocks in a tool-independent form.
Conclusion
The AI4RE Prompt Guide turns requirements prompts from improvisation into craft: roles, variables, a checkpoint and an output format you can check. The pitfalls sections are worth reading even if you never copy a template. And once a template works for your team, move it into the repository as a skill, where it is versioned, reviewed and the same for everyone.
