Über zehn Jahre ist es jetzt her, dass mir Anforderungsdiagramme (Requirements Diagrams) zum ersten Mal begegneten. Und was für welche! Sie waren in einem „echten“ Projekt entstanden. Es ging um die Entwicklung eines komplexen medizintechnischen Geräts. Ich erinnere mich, dass von mehreren tausend Stakeholder-Requirements für das Gerät die Rede war. Die Anforderungsdiagramme sahen eindrucksvoll aus: dicht bedruckte Tapeten voller Kästchen, offenbar mit einem Zeichenwerkzeug erstellt, ich vermute mit MS Visio. Welch ein Aufwand! Ob er sich gerechnet hat? Ich weiß es nicht. Damals war mir der Diagrammtyp unbekannt und von der Systems Modeling Language SysML, aus der er stammt, hatte ich nur flüchtig gehört. Sie war ein oder zwei Jahre zuvor (2007) von der OMG offiziell verabschiedet worden.
Heute weiß ich mehr: Zweck von Anforderungsdiagrammen der UML/SysML ist es, Anforderungen, ihre Beziehungen untereinander sowie zu anderen Elementen eines Systemmodells zu gestalten und sichtbar zu machen. Das klingt nützlich, nicht nur bei der Entwicklung von Geräten, sondern bei allen softwareintensiven Produkten. Aber sind Anforderungsdiagramme noch zeitgemäß? Ein Blick in die agilen Projekte von heute zeigt: User Story Maps, Backlogs, Kanban oder Task Boards sind die Mittel der Wahl, wenn es darum geht, Epics und Feature Requirements zu verfeinern und User Stories zu definieren. Deshalb will ich – wie zuvor schon im Falle von Use Cases und Blockdefinitionsdiagrammen – die Frage stellen: Sind Anforderungsdiagramme in heutigen Projekten noch sinnvoll oder sind sie schon Geschichte?
Fachliche Strukturierung als Herausforderung
Stakeholder sind in die agile Entwicklung fest eingebunden. Das hat das Bewusstsein dafür gestärkt, dass Software und softwareintensive Produkte die Anforderungen des Business optimal erfüllen müssen. Aber Stakeholder-Zufriedenheit ist nur eine Herausforderung, vor der agile Teams stehen. Hier ist eine weitere, ebenso wichtige: Die Fachlogik der zu entwickelnden Lösung darf nicht über alle möglichen Komponenten verstreut werden. Vielmehr muss die Lösung in Features zerlegt werden, die möglichst unabhängig voneinander sind. Denn damit wird u.a.
- der Entwurf von skalierbaren, wartbaren und änderbaren Architekturen unterstützt (andernfalls kann es später teuer werden),
- die Feature-Auswahl für ein Minimum Viable Product (MVP) vereinfacht (unverzichtbar, wenn es auf Time-to-Market ankommt),
- die Verteilung der Entwicklung auf Feature Teams möglich (eine wichtige Voraussetzung für große agile Projekte z.B. nach SAFe®).
Die Strukturierung der fachlichen Funktionen beginnt nicht erst beim Entwurf der Lösung, sondern bereits bei der Zerlegung von Epics in Feature Requirements. Dabei kommt es darauf an, dass Epics und Feature Requirements gut und – vor allem – einheitlich verstanden werden, um die richtigen fachlichen Abstraktionen zu finden und weitreichende Entwurfsentscheidungen treffen zu können.
Hier kommen die Anforderungsdiagramme ins Spiel
Beim Sichtbarmachen von Kontext und Abhängigkeiten, beim Entwickeln von Konzepten und Lösungsansätzen sowie beim Unterstützen von Entscheidungsprozessen sind Diagramme unschlagbar. Das gilt auch für das Anforderungsdiagramm im Verlauf des Requirements Engineering.
In Anforderungsdiagrammen kann man
- die Interessen von Stakeholdern an Anforderungen festhalten,
- mit fiktiven Anwendern, sogenannten Personas, Anforderungen für innovative Produkte entwickeln,
- Anforderungen schrittweise verfeinern,
- Zusammenhänge zwischen funktionalen und nicht-funktionalen Anforderungen abbilden,
- Abhängigkeiten von Anforderungen sichtbar machen, die sowohl für ein Minimum Viable Product als auch beim Einsatz von Feature Teams berücksichtigt werden müssen,
- Traceability zwischen Anforderungen und Architekturelementen herstellen.
Vor allem aber kann man mit Anforderungsdiagrammen die Weichen für die fachliche Strukturierung komplexer Lösungen stellen.
Struktur für die fachliche Domäne
Komplexe Lösungen besitzen viele, möglicherweise wie in dem anfangs erwähnten Beispiel sogar viele tausend Anforderungen. Sie brauchen Struktur. Anforderungen zu strukturieren beginnt damit, die fachliche Domäne in Subdomänen zu gliedern. Jede Subdomäne stellt einen Container für fachlich zusammengehörige Anforderungen dar. Für diese Strukturierungsaufgabe braucht man das Wissen von Domänenexperten, einen „Mini-Prozess“ für das gemeinsame Vorgehen und ein Tool.
Ich schlage Ihnen folgende Schritte vor, die – wie Sie anschließend sehen werden – von objectiF RPM unterstützt werden:
- Epics auf oberstem fachlichem Niveau gemeinsam mit den Stakeholdern ermitteln und im Product Backlog festhalten
- Epics in ein Anforderungsdiagramm übernehmen
- Abhängigkeiten zwischen den Epics analysieren. Sie dazu ggf. in Feature Requirements verfeinern.
- Abhängigkeitsbeziehungen im Anforderungsdiagramm darstellen
- Die fachliche Domäne unter Federführung von Domänenexperten zunächst auf oberster Ebene in Subdomänen gliedern, um so die Fachlichkeit zu strukturieren
- Subdomänen als Regionen im Anforderungsdiagramm abbilden
- Epics und ggf. Feature Requirements den Subdomänen zuordnen, indem sie im Anforderungsdiagramm grafisch in eine Region eingefügt werden. Abhängige Epics bzw. Feature Requirements sollten dabei in dieselbe Subdomäne übernommen werden
- Die Verfeinerung und Strukturierung pro Subdomäne fortsetzen.
Dieses Vorgehen ist nicht als Top-Down Prozess zu verstehen. Vielmehr wird man immer wieder zwischen dem Ergänzen und Verfeinern des Product Backlogs und dem grafischen Strukturieren in Anforderungsdiagrammen wechseln.
Und so sieht das Ganze live mit objectiF RPM aus:
Was denn nun – oll oder toll?
Meine Antwort lautet: toll! Anforderungsdiagramme sind für den kreativen Prozess auf hohen fachlichen Gestaltungsebenen sehr wertvoll, zumal sie die Kommunikation zwischen Business-Stakeholdern, Domänenexperten und Requirements Engineers leichter machen. Punktuell können sie auch bei der Zerlegung von kritischen Feature Requirements in User Stories hilfreich sein. Aber bei der vollständigen Verfeinerung von Anforderungen eines komplexen Systems mit Hilfe von Anforderungsdiagrammen rechtfertigt der Nutzen den erheblichen Aufwand in der Regel nicht. Strukturierte Backlogs, die konfiguriert, sortiert, gruppiert und gefiltert werden können, leisten hier bessere Dienste. Also keine Tapeten erzeugen, obwohl objectiF RPM sehr schöne Tapeten drucken kann. Sondern das Instrument der Anforderungsdiagramme bewusst und kreativ einsetzen. Das ist meine Empfehlung. Und natürlich objectiF RPM ausprobieren!
Hier geht es zum Download des kostenfreien Trials.