Agiles Anforderungsmanagement 202X

Themeneinführung Spezifikation Agile SE

Was agiles Anforderungsmanagement auszeichnet:

  • Agile Grundwerte der Organisation: vgl. agiles Manifest
  • Die konsequente Vermeidung von Wegwerf-Artefakten und die Reduktion von Planungs-Overhead durch emprische Prozessverbesserung
  • Die Zuordnung von Anforderungen und Domänen/Subdomänen zu Produkten und der Verzicht auf weitere Vorgaben an die Rückverfolgbarkeit
  • Die eingesetzten Management Rahmenwerken und Werkzeugen zur Produkt-Entwicklung und Weiterentwicklung: vgl. Scrum, Kanban mit Produkt-Backlog und Kanban Board und Begriff-Glossare
  • Die eingesetzen Methoden, Notationen und Ziele zur Erhebung strukturierter Anforderungen: vgl. z.B. Klassische und "erweiterte User Stories" und "Lean UML" mit "Use Case 2.0".
  • Der Zeitpunkt der Erstellung, d.h. wann und wie oft strukturierte Anforderungen erhoben bzw. verfeinert werden: Ziel ist eine schrittweise, durch den Geschäftswert gesteuerte Verfeinerung, über die Priorisierung im Product-Backlog

Methoden und Notationen für agiles Anforderungsmanagement

Von Beginn an strukturiert

Die im agilen Umfeld hoch geschätzen Werte "Individuen und Interaktionen" sowie "Zusammenarbeit mit dem Kunden" (vgl. Agiles Manifest) mahnen zum sparsamen Umgang mit schriftlicher/bildlicher Dokumentation, die in enger Zusammenarbeit mit dem Kunden erarbeitet und aktuell gehalten werden muss. Das Prinzip "Weniger ist mehr" kann aus Sicht des Lesers /Autors unterschiedlich interpretiert werden. Leser wünschen sich übersichtliche Grafiken und weniger Text, Autoren sehen es anders herum: strukturierte Text-Beschreibungen sind genauer und leichter zu erstellen als ausgefeilte Grafiken. Grafiken/Diagramme sind aus pragmatischer Sicht meist ein optionales "Komfort"-Feature - aber es gibt Ausnahmen: siehe z.B. Beitrag zu "Lean UML".

Jede zusätzliche Dokumentation muss einen nachvollziehbaren Wert im Zusammenhang mit einem Produkt beisteuern, der über die Lebensdauer eines konkreten Produktes hinaus zu erhalten ist: z.B. dürfen bestehende Schnittstellen-Designs, Anwendungsfälle und Testszenarien nicht verloren gehen, wenn aus strategischen Gründen zwei bestehende Produkte in ein neues, schlankeres Produkt transformiert werden.

Weiters muss lebende Produkt Dokumentation eine für das Änderungs-Management von Produkten und Domänen geeignete Struktur, Ordnung und Einheitlichkeit aufweisen. Die Verwendung einheitlicher Begriffe aus einer domänen spezifischen Expertensprache (DSL) kann im agilen Umfeld ohne formale oder schwergewichtige Werkzeuge über Glossare gefördert werden, z.B. die Liste aller Domänen/Subdomänen, Produkte, Rollen, Geschäftsobjekte, Ereignisse usw.

Daraus ergeben sich folgende Empfehlungen:

  1. Unstrukturierte Anforderungen sind in der Regel "Wegwerfprodukte". Wegwerfprodukte sind im agilen Anforderungsmanagement konsequent zu vermeiden.
  2. Strukturierte Anforderungen müssen mit Produkten über das Produkt-Backlog verbunden sein, denn "das Product Backlog dient als einzige Anforderungsquelle für alle Änderungen am Produkt" - vgl. Scrum Guide.
  3. Eine wichtige Ordnung (Struktur) für funktionale Anforderungen ist die Zuordnung zu fachlichen Themen, die als  fachliche oder technische Domänen, bzw. untergeordneten Subdomänen dokumentiert werden. Sie weisen in der Regel eine längere Lebensdauer als Produkte auf. Domänen können Akteure, Abläufe (Prozesse), Funktionalitäten und damit verbundene Daten (Geschäftsobjekte) aufweisen. Sie bilden damit auch die Grundlage für übergeordnetes Portfolio Management.
  4. Produkte müssen unmissverständlich fachlichen Domänen/Subdomänen zugeordnet werden, zusammen mit den damit verbundenen Verantwortlichkeiten - vgl. Punkt 2 im Beitrag "Lean UML".
  5. Fachliche Produkt-Verantwortung und Domänen-Verantwortung sind mit möglichst wenig Überschneidungen zu klären, zu dokumentieren und zu kommunizieren.
  6. Wird ein Produkt verworfen oder geändert, dürfen die zugeordneten fachliche Domänen, Verantwortlichkeiten und strukturierten Anforderungen nicht unkontrolliert verloren gehen. Sie können neuen Produkten zugeordnet werden, oder müssen explizit ausgeschlossen werden, z.B. wenn entsprechende Geschäftsbereiche aufgelöst wurden.
  7. Verfügbare Produkte weisen zwingend eine fachliche und technische Architektur auf, für die strukturierte Anforderungen zu erheben und laufend zu verfeinern sind. Das schließt auch nicht funktionale Anforderungen ein z.B. erwartete Antwortzeiten für bestimmte Benutzer oder die Verfügbarkeit von Schnittstellen für marktübliche Technologien (z.B. REST API, cloud ready Services).
  8. Eine wichtige Ordnung (Struktur) für technische Anforderungen ist die Zuordnung zu technischen Themen, die als technische Domänen, bzw. Subdomänen dokumentiert werden, z.B. Anforderungen zur Codequalität, Entwickler-Knowhow wie Programmiersprachen, technische Standards und deren Version, Vorgaben zu technischen Produkten und deren Version, technische Sicherheitsstandards usw.
  9. Pflege von Glossaren mit vereinbarten Begriffen zur Vereinheitlichung, z.B. die Liste aller Bezeichnungen für Domänen/Subdomänen, Produkte, Rollen usw.
  10. Strukturierte agile Anforderungen digitaler Produkte berücksichtigen folgende Erkenntnisse der kognitiven Psychologie: Menschen ordnen ihre Welt in Akteure, Objekte, Beziehungen zwischen Objekten und deren Verhalten mit Hilfe von Abstraktion - vgl. auch "Lean UML" mit "Use Case 2.0"


Strukturierte agile Anforderungen beschreiben Funktionalitäten (Subdomänen) von Produkten mit Hilfe von:

  • abstrahierten (Rollen) und konkreten Akteueren (Menschen, Maschinen, IT Systeme = digitale Produkte)
  • identifizierten Ereignissen (Events) und damit verbundenen Vor- und Nachbedingungen
  • Geschäftsobjekten mit fachlichen Informationen und damit verbundene Schnittstellen (Entitäten, Daten, Aggregates, Datenservices)
  • mit Hilfe von wiederkehrenden Abläufen (Anwendungsfälle, Geschichten, Geschäftsprozesse, Workflows usw.) und deren
  • Schritte und Varianten (z.B. alternativer Ablauf im Fehlerfall).

Als Satzvorlage für einzelne Schritte von Abläufen (Anwendungsfällen) wird folgendes Muster empfohlen:

<Akteur/Rolle/IT-System> <Verb> <Geschäftsobjekt> in <IT-System/Produkt> [über <Schnittstelle> | in <Benutzermaske> | bei <Ereignis>]


Ältere LeserInnen kennen diese bewährten Konzepte aus der Zeit schwerfälliger Projekte im "Wasserfall-Stil" [Waterfall], der von seinem Erfinder übrigens von Beginn für eine iterative Entwicklung gedacht war. Aber im agilen Umfeld sollten derartig aufwendige Spezifikation doch vermieden werden?

Der Beitrag "agile Missverständisse" beschäftigt sich mit dieser Frage. Soll ein digitales Produkt in einer typischen Systemlandschaft mittelständischer und großer Firmen realisiert werden, sind besondere Anforderungen im Portfolio- und Release-Managment und in der laufenden Wartung (DevOps, Test) z.B. durch öfter ausgewechselte Teams zu beachten. In diesem Zusammenhang werden die zuvor beschriebenen, funktionalen/nicht funktionalen fachlichen und technischen Anforderungen unverzichtbar. Bei komplexen Vorhaben geht in der Regel bereits während der Implementierung der Überblick über getroffene Entscheidungen verloren, insbesonders wenn mehrere Scrum Teams gemeinsam an einem Produkt, oder an abhängigen Produkten arbeiten.

Applikations- und Schnittstellen-Code kann aus technischen Gründen nur begrenzt nach der eingangs geforderten "Ordnung" über fachlichen Themen strukturiert werden. Dieser Code ist von TesterInnen und fachlichen EntscheiderInnen nur soweit nutzbar, wie er in Benutzermasken sichtbar wird. Geschäftslogik, die weder in Prozessdiagrammen, noch in Benutzermasken aufscheint, bleibt fachlichen AnsprechpartnerInnen, TesterInnen, Portfolio-ManagerInnen und nachfolgenden DevOps nach der ersten Umsetzung verborgen, wenn dazu keine fachliche Spezifikation verfügbar ist.