Teaching Agile Requirements Engineering: A Stakeholder Simulation with Generative AI
This paper presents a teaching approach for Agile Requirements Engineering that utilizes Generative AI-powered stakeholder simulations to help students practice elicitation techniques while critically evaluating the technical and ethical limitations of AI tools.
Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are training a new chef. In the old days, you'd send them to a real restaurant kitchen to learn how to talk to customers, take orders, and handle complaints. But what if you can't get them into a real kitchen? What if the customers are too busy, or the restaurant is closed for renovations?
That's the problem these researchers faced with teaching Agile Requirements Engineering.
In software development, "Requirements Engineering" is the art of figuring out exactly what a user wants before writing a single line of code. The "Agile" part means doing this in small, quick loops, constantly talking to users to refine the plan. The problem? Real users are hard to find, and they don't always show up to class.
Here is how the authors (Eva-Maria, Michael, and Tiago) solved this using Generative AI (GenAI), explained through a simple story.
The Core Idea: The "Acting Class" for Software
Instead of hiring real actors to play customers, the professors created AI Personas. Think of these as highly advanced, digital method actors.
The researchers built a "meta-prompt" (a master instruction script) that tells an AI chatbot: "You are now a grumpy city clerk," or "You are now a tech-savvy teenager," or "You are now a citizen who needs big fonts to read."
The students, playing the role of Software Detectives, have to interview these digital actors to figure out what kind of app the city needs.
How the Class Works (The Three Acts)
1. The Interview (The Detective Work)
The students sit down with their AI "actors." They ask questions like, "What's the hardest part about renewing your ID card online?"
- The Magic: The AI answers in character. The "grumpy clerk" might complain about paperwork; the "teenager" might say, "Just make it work on my phone, please."
- The Catch: The AI isn't perfect. Sometimes it forgets what it said five minutes ago, or it gives a generic answer that sounds nice but isn't helpful. This is a feature, not a bug! It teaches students that AI can be a great helper, but you can't just trust it blindly.
2. The Blueprint (The Recipe)
After the interviews, the students have to write down what they learned. In the software world, they use tools like Story Maps (a visual timeline of a user's journey) or User Stories (short descriptions of features).
- The Lesson: The students tried to let the AI write these blueprints for them. It sounded great at first, but the AI's blueprints were often too shallow—like a recipe that says "cook the chicken" without saying how long or at what temperature. The students had to step in, fix the AI's work, and add the missing details. This taught them that AI is a draftsperson, not the architect.
3. The Debrief (The Reality Check)
Finally, the class gathers to talk. They discuss:
- "Did the AI act like a real person?"
- "Did the AI accidentally make a stereotype about a specific group of people?" (This is called bias).
- "What happens if the AI 'hallucinates' and invents a feature that doesn't exist?"
Why This is a Big Deal (The "Aha!" Moments)
The authors discovered a few surprising things while running this experiment:
- The "Too Good to Be True" Trap: When the AI wrote the requirements, they looked perfect. Students thought, "Wow, the AI did it all!" But when they tried to actually build the software, they realized the requirements were missing crucial details. It taught them that planning is hard work, and you can't just outsource your brain to a robot.
- The "Robot Voice" Problem: The researchers tried to make the AI smarter by tweaking the instructions. But the more "efficient" they made the AI, the less human it felt. It stopped asking follow-up questions and just gave short answers. The students realized that real human conversation is messy and full of questions, and a perfect, efficient robot isn't always a good simulation of a real person.
- The "Black Box" Risk: The professors realized that if they relied on one specific AI company (like OpenAI), they might run into problems (like students hitting a "paywall" or a limit on how many questions they could ask). So, they switched to a "Bring Your Own AI" model, where students can use any chatbot they want, as long as they use the same master instructions.
The Takeaway for Everyone
This paper isn't just about coding; it's about learning how to learn with AI.
Think of it like teaching someone to drive. You wouldn't just let them drive a real car on a highway immediately. You might put them in a simulator.
- The AI Personas are the simulator.
- The Students are the drivers.
- The Real World is the highway.
The simulator isn't perfect. Sometimes the tires don't feel real, or the traffic behaves strangely. But it's safe, cheap, and allows the students to crash (metaphorically) and learn without hurting anyone.
The Bottom Line:
The authors are saying: "Don't just use AI to do the homework for you. Use AI to practice the hard parts of your job, but always keep a critical eye on what it's saying. Learn to spot the difference between a helpful tool and a confident liar."
By the end of the course, the students aren't just better at making apps; they are better at understanding the limitations and ethics of the technology they are using. They learn that while AI can be a powerful co-pilot, they must remain the captain.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.