Agiles Anforderungsmanagement:

  • Agile Grundwerte der Organisation werden verstanden und gelebt: vgl. Agiles Manifest
  • Die konsequente Vermeidung von Wegwerf-Artefakten und die Reduktion von Planungs-Overhead durch empirische Prozessverbesserung
  • Fachlichen und technischen Anforderungen sind unter Berücksichtigung ihrer Testbarkeit zu erheben. 
  • Die langfristige Zuordnung von Anforderungen und Domänen/Subdomänen zu Produkten ohne Overhead für kurzfristige Management Bedürfnisse und temporäre Planungsinitiativen

Was agiles Anforderungsmanagement noch auszeichnet:

  • 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. User Stories - und Erweiterungen, 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

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.
  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.

Anforderungen strukturieren

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ändnisse 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-Management 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 sowie 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 (vgl. hier) gemeinsam an einem Produkt oder an mehreren abhängigen Produkten arbeiten.

Grenzen der fachlichen Sichtweise von Funktionalität

Applikations- und Schnittstellen-Code kann aus technischen Gründen nur begrenzt nach der eingangs geforderten Ordnung über fachlichen Themen strukturiert werden. Der damit verbundene Programm-Code ist von TesterInnen und fachlichen EntscheiderInnen nur soweit abrufbar, wie er in Benutzermasken sichtbar wird. Darüber hinaus sind FachanwenderInnen in der Regel keine Ansprechpartner für typische technische Anforderungen  und die Integration mit bestehender technischer Infrastruktur. In diesem Fall besteht die Möglichkeit, zusätzlich technisch motivierte User Stories einzuführen.

Geschäftslogik, die weder in Prozessdiagrammen, noch in Benutzermasken aufscheint, bleibt fachlichen AnsprechpartnerInnen, TesterInnen, Portfolio-ManagerInnen und nachfolgenden DevOps ansonsten nach der ersten Umsetzung verborgen, wenn dazu keine  unabhängige Spezifikation verfügbar ist. Alle spezifizierten fachlichen und technischen Aspekte sollten in diesem Fall gemeinsam getestet werden, und im Backlog verknüpft werden, um Wechselwirkungen z.B. bei späteren Änderungen berücksichtigen zu können.