Kontakt
Mail: stefan.bente@th-koeln.de
Tel.: +49 2261 8196 6367
Skype: stefan.bente
Discord Server
Adresse:
Steinmüllerallee 4
51643 Gummersbach
Gebäude LC4
Raum 1708
Sprechstunde nach Vereinbarung
Terminanfrage: calendly.com Wenn Sie dieses Tool nicht nutzen wollen, schicken Sie eine Mail und ich weise Ihnen einen Termin zu.

Übung »Improve one of your requirement artefacts, based on comments and good examples«

In this exercise, you select one of your own requirement artefacts - be it a stakeholder role, a goal, a persona, or anything else. You can have a look at good examples from other teams.

Dauer
Ca. 40 min

Inhalt

Worum geht es?

This exercise is about looking in detail at one specific requirement artefact. Give it 15 min of attention, and analyze it. What is missing, inconsistent, redundant? The “todo” comments may help. Then, improve it.

Your Task

  1. Meet with your subteam in a Zoom breakout room.
  2. Pick one of your artefacts.
  3. Analyze what is wrong with it. Use …
    • error and warning messages,
    • todos,
    • your own judgement, and
    • the list of good examples (see below).
  4. Improve it: Fix the errors and warnings, and work on the text to address the comments and own concerns.
  5. Afterwards, we meet in the whole group, and each team presents its artefact.

Good Examples

There are a couple of good examples for each artefact type that I found during my “midterm review”. This list is not exhaustive (so I may have missed some good ones).

  • Stakeholder:
  • Stakeholder Role:
  • Goal:
    • “Great customer experience” is (despite a number of flaws) a good example for what a goal should be: It describes an overall property of the whole system (customer experience), and gives a business reason for it. It should be easy to assign functional requirements “paying into” this goal.
  • System Context Element:
    • Although the competitor description for DevianArt is listed under the wrong category (stakeholder instead of system context), it is a nice example of some basic research done on a system context element. I assume that the information can be obtained in a couple of minutes - but it makes a lot of difference to “validate” a system context element.
  • Domain Model:
  • Glossary:
    • Rather than pointing at a glossary entry, have a look at the glossary for YamShare (YumShare?). It is a good example of a continously maintained glossary, although each entry has some formal flaws still (a bit short, no sources).
  • Interview / Survey / Workshop:
    • basically all ok, apart from some flaws (see comments)
  • Persona:
    • Although the persona description of bakery owner Julia Milovic is too short and lacks e.g. a foto, it is a good example of how a persona can illustrate a typical user.
  • Scenario:
    • “Following the tutorial of the AR tool” is a pretty good example of an compact yet exhaustive scenario that tells a lot about the application planned. It has a number of formal flaws though, as visible from the errors / warnings list.