Ü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?
• Your Task
• Good Examples

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:
  • None of the artefacts I found were suitable as a “really good example”. Instead, you can have a look at the template text describing a professor as stakeholder.
• Stakeholder Role:
  • Rather than pointing out a single entry, have a look at the stakeholder role of “Artist” plus its sub-roles. This is very good example for a sensible role definition and structure. (The role descriptions each have their flaws, though, see the comments.)
• 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:
  • The PandArt domain model is the only one with a brief explanation. That helps! Image resolution too low, though.
• 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.