Ü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.
- Ca. 40 min
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.
- Meet with your subteam in a Zoom breakout room.
- Pick one of your artefacts.
- Analyze what is wrong with it. Use …
- error and warning messages,
- your own judgement, and
- the list of good examples (see below).
- Improve it: Fix the errors and warnings, and work on the text to address the comments and own concerns.
- Afterwards, we meet in the whole group, and each team presents its artefact.
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 Role:
- “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:
- 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)
- 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.
- “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.