Requirements Engineering Game - Theory is dead, long live the game!

Inquiry via web form: Half-day workshop on the topic of 'Requirements Engineering'

Me: I picked up the phone and called Barbara from Techface . After all, I'm a full-blooded requirements engineer and I have to get to the bottom of the requirements here, too.

Barbara: We're developing a new program for women who want to switch to IT. Can you teach the rather theoretical and boring subject of requirements engineering in a way that's fun?

Me (utterly outraged!): Boring?!?! Challenge accepted!

Together with Stefan Böhni and Patrick Steiger from Infometis , I embarked on a quest for the holy grail of playful learning. Each of us researched like Sherlock Holmes, developed ideas like Wickie the Viking, and fought for our ideas like Lancelot. Finally, the board game was chosen as the winning project and released for its first play within the group.

Unfortunately, the board game was shipwrecked and, like the Titanic, disappeared into the depths of discarded ideas. Since we lacked Hermione Granger's Time-Turner, the conception of a functioning board game exceeded our available time.

But we wouldn't be Infometen if we had given up or started from scratch. We cleverly, like a fox, and with solid RE work, extracted the card-drawing mechanic from the board game and reworked the concept into a card game.

Building on the prototype and full of enthusiasm, I then developed three variants in one fell swoop, as the first game variant developed without random factors had too few gameplay aspects for me.

What do all game variations have in common?

• They follow the typical RE lifecycle: 'Context', 'Define requirements', 'Visualize/Build prototype', 'Validate'
• In all games, the interests of the stakeholders must be taken into account.
• Four to n rounds can be played.
• The complexity of the context, requirements, and methods increases from round to round.
• There are three piles of stakeholders.
• There are action cards.
• The action cards trigger the drawing of method cards.

What distinguishes the different game variations?

Game variant 1: Works entirely without random factors; only cards are drawn.

Game variant 2: In addition, dice are rolled, so there is also a little bit of luck involved.

Game variant 3: Dice are rolled at various points, but the element of chance can be compensated for by strategic action.

Now all I had to do was design the playing cards, and then presto, Stefan Böhni to create them in Adobe InDesign. And here's the result:

At our next meeting with all Infometis members, Patrick Steiger fearlessly tested the three game variations with our Infometis guinea pigs.

And which version ultimately won? That can't be answered quite so clearly!

In principle, all three variations work. However, which variation is used depends primarily on the participants. If the players have little to no prior knowledge, the complexity of variation 1 (without random elements) is sufficient. If there are also players with more knowledge, or a mix of players with and without prior knowledge, variation 2 is a good choice. Variation 3 should only be played by players who can handle losing well and already have some experience in requirements engineering.

I'm sure I've piqued your curiosity now! Let's play together!

Still not sure if this is for you? Then read my next blog post on 'Requirements Engineering Game in Action'