Haben Sie sich auch schon mal gefragt, wie Sie Anforderungen in Ihrem Produktentwicklungskontext mit User Stories systematisch strukturieren sollten? Unter ständig einprasselnden Kundenäußerungen und neuen Erkenntnissen sollen alle Beteiligten wissen, was gefordert ist. Zudem soll genügend Information vorhanden sein, damit das Geforderte umgesetzt werden kann.
Die Grundlage für diese Fragestellungen bilden Anforderungen. Anforderungen stellen das Bindeglied zwischen Kundenwunsch und dem Produkt(inkrement) dar. In vielen Projekten wird die Frage nach einer Systematik zur Strukturierung von Anforderungen gestellt. An dieser Stelle will ich eine Vorgehensweise vorstellen, um mit Hilfe des sog. generischen Informationsmodells die erforderlichen Verantwortlichkeiten zu klären. Dabei kommen User Stories und Akzeptanzkriterien zum Einsatz.

Abbildung 1: Generisches Informationsmodell für Anforderungen (angelehnt an [2])

Im Gegensatz zur klassischen Entwicklung ist es im agilen Umfeld ausdrücklich erlaubt, Anforderungen so spät wie möglich zu detaillieren, z.B. in Form von Akzeptanzkriterien. Das generische Informationsmodell für Anforderungen ist auf agile und klassische Entwicklung gleichermaßen anwendbar, da es keine zeitlichen Aspekte berücksichtigt. 

Anforderungen haben verschiedene Darstellungsformen, z.B. natürlichsprachlicher Text, Modell, User Story, Use Case, ...
Abbildung 2: Verschiedene Darstellungsformen von Anforderungen

Zur Darstellung der Anforderungen sind sowohl im klassischen als auch im agilen Umfeld sehr unterschiedliche Formen möglich. Generell können uns Anforderungen in jeglicher Darstellungsform begegnen. Manchmal genügt es uns, dabei weniger Details zu transportieren (z.B. mittels des User-Story-Musters), in anderen Fällen wollen wir mit einer Darstellung mehr Details festhalten. In jedem Fall muss die Darstellung von Anforderungen zweckmäßig gewählt werden. Dazu finden Sie in folgendem Beitrag Hinweise, anhand welcher Kriterien Sie entscheiden können, welche Dokumentation zweckmäßig ist und welche nicht: Dokumentation ist nicht generell sinnvoll!

Abbildung 3: Projektion des generischen Informationsmodells auf User Stories und Akzeptanzkriterien

Der hier vorgestellte Ansatz nutzt für User-Stories das bekannte Textmuster (siehe Abbildung 3). Für Akzeptanzkriterien ist jede geeignete Darstellungsform erlaubt. Die User Story repräsentiert Problembereich und Lösungsbereich gleichzeitig. Im Text-Muster der User Story stecken bereits der Zweck und die abstrakte Lösungsbeschreibung. Der Problem- und Lösungsbereich sind dadurch klar voneinander getrennt.

Das im User-Story-Textmuster genannte Produktmerkmal stellt den ersten Schritt einer abstrakten Lösungsbeschreibung dar. Zu einer User Story entstehen Akzeptanzkriterien, die während des sogenannten Backlog Refinements detailliert werden. Die Akzeptanzkriterien sind eine Detaillierung der immer noch abstrakten Lösungsbeschreibung. Typischerweise entwirft das Development Team im Rahmen des Backlog Refinements Designskizzen, um die Größe der jeweiligen User Story besser abschätzen zu können. Designskizzen stellen eine detaillierte Lösungsbeschreibung dar.

Wir sehen also, wie sich das generische Informationsmodell auf eine Scrum-Welt projizieren lässt, in der User Stories verwendet werden. Die Implementierung entspricht dabei letztendlich dem Anteil des Produktinkrements, der für die User Story innerhalb eines Sprints entsteht.

Diese Anwendung des generischen Informationsmodells für Anforderungen auf User Stories und Akzeptanzkriterien hilft uns nun folgendermaßen: Den Abstraktionsebenen des generischen Informationsmodells weisen wir die Verantwortung durch verschiedene Rollen zu. Dann lassen sich Aussagen treffen, von welchen Rollen die jeweilige Information verstanden werden muss.

Abbildung 4: Rollen des Requirements Engineerings im Scrum-Umfeld

Für diese Betrachtung genügen uns die Scrum Rollen Product Owner und Development Team. Der Scrum Master ist in diesem Kontext uninteressant, da er inhaltlich beim Umgang mit Anforderungen keine Rolle spielt. Als zusätzliche Rolle benötigen wir noch den Stakeholder. Damit ist jede beliebige Person oder Rolle gemeint, die Anforderungen an das Produkt stellen kann.

Der Stakeholder ist ganz klar der Eigentümer des Zwecks. Er allein bestimmt, wozu er das Produkt nutzt. Obwohl der Product Owner in der Pflicht ist, User Stories zu identifizieren, kann er den Zweck nicht bestimmen. Er muss ihn herausfinden. Der Zweck muss vom Stakeholder und vom Product Owner verstanden werden.

Über die abstrakte Lösungsbeschreibung bestimmt der Product Owner. Selbst wenn ein Stakeholder Produktmerkmale explizit nennt, ist der Product Owner derjenige, der das Produktmerkmal zu bestimmen hat. Er ist dafür verantwortlich, dass ein Produktmerkmal dem Zweck des Stakeholders gerecht wird.

Die Akzeptanzkriterien dienen dem Product Owner sowohl zur Kommunikation mit den Stakeholdern als auch zur Kommunikation mit dem Development Team. Bei der Kommunikation mit den Stakeholdern geht es ihm darum, herauszufinden, unter welchen Einschränkungen seine abstrakte Lösung ihrem Zweck gerecht wird. Bei der Kommunikation mit dem Development Team geht es dem Product Owner darum, klar zu machen, was er sich unter dem Produktmerkmal vorstellt. Dadurch muss er das Development Team in die Lage versetzen, die Implementierung entsprechend zu gestalten. Daher müssen alle Akzeptanzkriterien vom Development Team verstanden werden, nicht jedoch von den Stakeholdern. Hinweis: Akzeptanzkriterien können auch vom Development Team vorgeschlagen werden. Das letzte Wort dabei hat in jedem Fall der Product Owner.

Die detaillierte Lösungsbeschreibung entspricht den vorweggenommenen Designansätzen, die ein Development Team während des Backlog Refinements erstellt, um den Aufwand für eine User Story besser bewerten zu können. Die detaillierte Lösungsbeschreibung gehört allein dem Development Team. Da das Development Team letztendlich für die Implementierung verantwortlich ist, hat der Product Owner bei der detaillierten Lösungsbeschreibung nicht reinzureden. Ihm sollte es egal sein, wie das System- bzw. Softwaredesign letztendlich aussieht. Daher muss er die detaillierte Lösungsbeschreibung auch nicht verstehen können.

Abbildung 5: Gegenüberstellung von Rollen und Anforderungsartefakten

Verschaffen wir uns nun einen Überblick über die verschiedenen Anforderungsartefakte hinsichtlich folgender zwei Aspekte:

  • Wer bestimmt den Inhalt?
  • Von wem muss es verstanden werden.

Die beteiligten Rollen rund um ein Anforderungsartefakt können wir nutzen, um zu bestimmen in welcher Sprache es gehalten werden muss, und ob wir dafür aktuell eine geeignete Sprache einsetzen.

Fazit: Das generische Informationsmodell für Anforderungen hilft uns, die Verantwortlichkeiten und Kommunikationswege der verschiedenen Informationsartefakte rund um eine User Story einzuordnen. Das generische Informationsmodell für Anforderungen ist ein mächtiges Werkzeug, um Transparenz in die Anforderungslandschaft (auch) in einer agilen Produktentwicklung zu bringen.

Weitere Literatur zu diesem Thema finden Sie unter:

  1. Akzeptanzkriterien für User Stories definieren – aber nur wie?
  2. C. Hood, R. Wiebel: Optimieren von Requirements Management & Engineering. Springer-Verlag Berlin Heidelberg 2005

Weitere Infos sowie Trainings und Veranstaltungen zum Thema Requirements Management im agilen Umfeld finden Sie unter www.Agile-by-HOOD.com.