Ein "Unified Model" vereint die Spezifikation (Beschreibung) unterschiedlicher Aspekte eines digitalen Produktes (Laufzeitkomponenten, Daten- und Beziehungsarchitektur, Abläufe, Abhängigkeiten von Modulen usw.) über Querverweise auf unterschiedliche Diagramme-Arten (z.B. "Anwendungsfalldiagramme") und strukturierte Texte (z.B. "Anwendungsfälle"). Die "Unified Modeling Language" (UML) ist die bekannteste Spezifikationstechnik und Modell-Sprache für die Dokumentation strukturierter Anforderungen und Lösungs-Designs.
In der Praxis erwies sich der von der von UML unterstützte "Model Driven" Ansatz in den meisten Domänen als zu schwerfällig und zu komplex, während viele der 13 Diagramm-Arten große Verbreitung bei der skizzenhaften Beschreibung von Anforderungen und Lösungs-Designs fanden. Nach der "agilen Revolution" in der Software Technik wurden diese Werkzeuge seltener benutzt und sind manchen jüngeren KollegInnen nicht mehr bekannt.
Der Beitrag Agile Missverständisse erläutert, dass "strukturierte Anforderungen" in den meisten Projekten nach wie vor unverzichtbar sind, unabhängig davon ob agile oder herkömmliche Management Rahmenwerke eingesetzt werden. Sie können entweder durch spezifische Epic-Typen ergänzt werden - vgl. "Erweiterte User Stories" oder mit Hilfe einer in der Folge präsentierten Untermenge von UML Diagrammen und der modernisierten Form der "Anwendungsfälle" (Use Case 2.0) dokumentiert werden.
Lean UML: Use Case 2.0 + erweiterte "Satz-Vorlagen" + Untermenge von UML Diagrammen
Diese Kombination wird hier als "Lean UML" bezeichnet und stellt eine Alternative zu den "Erweiterte User Stories" für das Management von strukturierten Anforderungen in agilen Projekten dar. Sie ist eng mit der Geschäftsprozess-Analyse und Domain-Analyse verbunden, bzw. kann als ihre Ergänzung angesehen werden. Die Ableitung der "Lean UML" aus der Unified Modeling Language folgt dem "Weniger ist mehr" Prinzip.
1. Teil: Vom Anwendungsfall zur "Use Case Story"
Die Use Case 2.0 Technik von Ivar Jacobson wird ausführlich in einem kostenlos bereit gestellten Whitepaper beschrieben, und deshalb hier nicht weiter vertieft. Es handelt sich um die für den agilen Einsatz erweiterte Methode der Anwendungsdall-Analyse, die über die weiterhin hilfreichen "Anwendungsfalldiagramme" in die UML Notation integriert wurde. Anwendungsfälle beschreiben in einer strukturierten Form wiederkehrende Abläufe aus Sicht von Akteuren bzw. daraus abstrahierten Rollen.
Wiederkehrende Abläufe stehen in engem Zusammenhang mit Ausschnitten von Geschäftsprozessen, und mit Workflows, die sich aus der Gestaltung grafischer Benutzermasken von digitalen Produkten ergeben - z.B. wenn über einen "Wizard" oder über "Reiter" in Benutzermasken diverse Daten zu erfassen sind. Daraus folgt, dass Anwendungsfälle eine strukturierte, detaillierte Text-Beschreibung von Abläufen bieten, die in verkürzter und übersichtlicherer Form auch als Prozess-Diagramme dargestellt werden können, und zwar als "Actiovity Diagramme" in der UML Notation, die semantisch gleichwertig mit der BPMN Notation sind. Es wird empfohlen, für diesen Zweck BPMN Diagramme einzusetzen, wobei in der Spezifikation eine möglichst einfache Untermenge von Elementen benutzt werden sollte: Start-End Event, X-Or Gate mit n Verzweigungen, Subprozesse sowie System-, User-, Message Tasks.
Die Besonderheit Use Case 2.0 Methode der liegt in der Dekomposition im "Use Case Slices" bzw. "Use Case Stories", die einen Umfang vergleichbar mit einer "User Story" aufweisen, d.h. sie müssen in 1 - 2 Tagen umsetzbar sein. Im Gegensatz zur alten "User Story" Methode geht bei dieser Dekomposition der urprüngliche Zusammenhang mit einem sinnvollen fachlichen Ablauf durch entsprechende Rückverweise nicht verloren. Deshalb handelt es sich um "strukturierte Anforderungen". Zudem erlauben Anwendungsfälle die systematische Beschreibung von Vor- und Nachbedingungen (letztere: vgl. Akzeptanzkriterien), und die Beschreibung von Ablauf-Alternativen, z.B. die Beschreibung was in unterschiedlichen Fehlerfällen passieren soll.
Die Erstellung unterschiedlicher Arten von Anwendungsfällen kann über gemeinsam erarbeitete Vorlagen (Templates) stark vereinfacht werden, darüber hinaus können auch Satz-Vorlagen (Templates) für einzelne Schritte eines Ablaufes bereit gestellt werden, siehe Beitrag "Agiles Anforderungsmanagement" - zum Bsp:
<Akteur/Rolle/IT-System> <Verb> <Geschäftsobjekt> in <IT-System/Produkt> [über <Schnittstelle> | in <Benutzermaske> | bei <Ereignis>]
2. Teil: Empfohlene UML Diagramme für schlanke, agile strukturierte Anforderungen
In der agilen Anforderungsanalyse gilt das Prinzip "Weniger ist mehr". Vorsicht, es kann aus Sicht des Lesers /Autors unterschiedlich interpretiert werden. Leser wünschen sich meist übersichtliche Grafiken und weniger Text, da diese Information schneller und intuitiver "verdaut" werden kann. Aus Autoren-Sicht ist es umgekehrt: strukturierte Text-Beschreibungen sind genauer, und können schneller erstellt werden als ausgefeilte Grafiken. Grafiken bzw. Diagramme sind meist eine optionale Ergänzung, ein "Komfort"-Feature. Unverzichtbar sind darüber hinaus DSL-Glossare [Domain specific Expert-Language] für ie einheitliche Verwendung von Bezeichnungen für Akteure, Rollen, IT-Systeme, Produkte, Geschäftsobjekte, Geschäftsprozesse und Ereignisse in den Prozessen.
Ist die Zeit zu knapp, kann auf die meisten der nachfolgenden Diagramme zu Gunsten einer groben, aber alles abdeckenden Anwendungsfall-Beschreibung, und eines Glossars für Akteuere, IT-Systeme sowie Geschäftsobjekte verzichtet werden. Unverzichtbar sind nur ein grobes "Composite Structue Diagramm" für die fachliche Architektur des digitalen Produktes und übergeordnete Geschäftsprozess Diagramme im BPMN Format, um den fachlichen Zusammenhang herzustellen. Prozess-Diagramme können mit der Kreativ-Technik des "Event-Stormings" und vergleichbaren Post-It Techniken für die Prozess-Analyse erstellt werden.
Es folgt eine kurze Beschreibung der für "Lean UML" empfohlenen Diagramm-Arten in der typischen Reihenfolge, wie sie im initialien Sprint und in den nachfolgenden Sprints erstellt und weiter verfeinert werden. Im Gegensatz zu herkömmlichen Managementmethoden werden strukturierte Anforderungen schrittweise iterativ für einen ausgewählten Teilbereich einer Subdomäne erstellt, die aus Sicht des Product Owners den höchsten Geschäftswert einbringt, und die aus Sicht des Teams ausreichend unabhängig ist, um damit zu starten. Ergänzend kann zu Beginn auch ein erster Überblick über die wichtigsten Domänen und Subdomänen erstellt werden, vgl. 2.b.
2.a Anwendungsfall Diagramm mit Package Notation:
Jedes Package beschreibt die Verbindung zwischen menschlichen Akteuren/Rollen einer Domäne und den identifizierten Anwendungsfällen (Funktionen) sowie zwischen beteiligten IT-Systemen. IT-Systeme sind in der Regel abstrahiert von einem konkreten IT-System vergleichbar mit der Rolle statt einem konkreten Akteur. Für die IT-Systeme eines Anwendungsfalles müssen immer ein oder mehrere edigitale Produkte inkl. der Release Version dokumentiert sein, z.B. Applikationen, Schnittstellen.
2.b Package Diagramme mit Domain-Struktur
Ein Übersichtsdiagramm enthält ein Package mit allen fachlichen und technischen Domänen als Unterpackages. Die Unterpackages jeder Domäne enthalten Verweise auf die zugeordneten Anwendungsfalldiagramme. Sie sollten zudem ein Package mit dem "Glossar der Akteure" und "IT-Systeme" enthalten. Diese Glossare sollten in Textform als Liste im Projekt-Wiki für alle Team-Mitglieder bereit gestellt werden.
2.c Composite Structue Diagramme:
Für jedes spezifizierte digitale Produkt, oder für eine Gruppe gleichwertiger Produkte (.B. APIs) wird ein "Composite Structue Diagramm" erstellt, in dem die digitalen Produkte und ihre wichtigsten fachlichen Komponenten und Schnittstellen in der Mitte dargestellt sind. Fachlich relevante Kompenenten sind Schnittstellen (als Lolly Symbol) - sowohl technische als auch GUI Schnittstellen, Service Komponenten mit Business-Logik und Komponenten zur Speicherung (Persistierung) von Daten.
Um das zentrale Produkt sind alle in Verbindung stehenden Produkte mit den relevanten Schnittstellen angeordnet, die konsumiert werden, oder die konsumieren (Lolly Symbol vs. Halbkreis-Symbol). Das kostenfreie Tool "UMLet" bietet Diagrammerweiterungen um die Hauptrichtung des Datenflusses an Schnittstellen anzudeuten, während die meisten teuren UML Tools wie der Enterprise Architect diese Diagrammart nur sehr marginal und nicht praxistauglich unterstützen.
Es wird zudem empfohlen, mit Hilfe von UML Boundaries die wichtigsten Netzwerk-Grenzen, Firewall-Zonen usw. zum besseren Verständis zu skizzieren. Auch Loadbalancer und Application Gateways und VPN Verbindungen können mit Hilfe der Komponenten und Schnittstellennotation skizziert werden.
2.d Composite Structue Diagramme mit Abläufen:
In der Praxis wird von den beliebten Sequence Diagrammen abgeraten, wenn der Sachverhalt in einem "Composite Structue Diagram" rascher und übersichtlicher gezeigt werden kann. Dabei werden zwischen den beteiligten Komponenten nummerierte Pfeile gezeichnet, die die Ablauf-Reihenfolge dokumentieren. Das erleichtert das Verständnis und verringert unnötige Details, die in der Regel rasch veralten.
2.e Composite Structue Diagramme mit Deployment Symbolen:
Die Komponenten und Subkomponenten eines digitalen Produktes werden auf rechteckige Deployment Artefakte (vgl Deployment Diagram) gezogen, um zu zeigen, auf welchen virtuellen Maschinen / Containern die Komponenten deployed werden. Das UML Deployment Diagramm wird aus verständlichen Gründen in der Praxis selten genutzt, weil die Symbole zu viel Platz brauchen, um die wesentlichen Komponenten darauf zu plazieren. Es ist deshalb sinnvoller, über das bereits erwähnte "Composite Structue Diagramm" mit dem digitalen Produkt in einem Zeichen- oder Office-Programm Rechtecke oder Formen zu zeichnen, die mit Hilfe einer Legende zeigen, welche Komponente wo deployed wird.
2.f BPMN Diagramme oder Activity Diagramme mit Swimlanes für wichtige Anwendungsfall-Ausschnitte:
Beide Diagrammarten sind gleichwertig. Für BPMN Diagramme stehen in der Regel komfortablere und stabilere Editoren bereit.
Damit können wichtige Abläufe aus sehr abstrakter Sicht (Vogelperspektive) als Geschäftsprozesse dargestellt werden, aber auch detaillierte Abläufe bis zur Navigation zwischen einzelnen Benutzermasken. Die Maskennavigation kann auch mit Hilfe von State-Diagrammen skizziiert werden. Auf der Geschäftsprozess-Ebene sind Swimlanes für organisatorische Einheiten oder Benutzer-Rollen (Akteure) hilfreich. Für die Definition von "ausführbaren technischen Prozessen" wird empfohlen, in Swimlanes ausschließlich das ausführende IT-System und andere beteiligte IT Systeme abzubilden, damit verständlich wird, wie die Prozess-Instanzen in den beteiligten Prozess-Engines ablaufen und wie sie sich sich im Fehlerfall verhalten.
Wenn in einer fachlichen Domäne "ausführbare technische Prozesse" in einer Prozess-Engine eingesetzt werden, kann die BPMN Notation z.B. für Prozess-Templates für die bewährte Camunda-Engine oder Zeebe Engine verwendet werden. Dabei ist zu beachten, dass ausführbare Prozesse einen anderen Scope und in der Regel auch andere Inhalte aufweisen, als die übergeordneten, abstrakten Geschäftsprozesse. Es muss jedoch eine genaue Zuordnung zwischen den vorgegeben fachlichen Tasks, Events und Entscheidungen aus dem Geschäftsprozess zu den Elementen des technischen Prozesses bekannt sein, da ansonsten keine korrekte Umsetzung vorliegt. Ein Beispiel: ein abstrakter fachlicher Task im Geschäftsprozess kann im technischen Prozess auf einem umfangreichen Subprozess verweisen. Umgekehrt können diverse Details aus einem übergeordneten Prozess im technischen Prozess in einem Task zusammengefasst werden, wenn dahinter ein Verweis auf eine Benutzermaske in einem digitalen Produkt steht, die alle fachlichen Details aus dem übergeordneten Prozess subsummiert.
2.g State Diagramme:
Sind in der Regel hilfreich, um die fachliche Status-Abfolge für ausgewählte Geschäftsobjekte oder Status-behafteten Komponenten zu spezifizieren, z.B.: "Entwurf" - "Antrag" - "Polizze" oder "Genehmigung". State Diagramme haben sich auch zur groben Beschreibung der Benutzermasken-Navigation bewährt, wobei die Status-Bezeichnungen für Masken/Submasken stehen, und die Übergänge die zulässige Navigation z.B. über Menüs, Buttons usw. beschreiben.
2.h Class Diagramme mit Package Notation
Diese Diagrammart kann aus POJO-Klassen zur Repräsentation von hierarchischen Daten-Bäumen mit Hilfe von Open Source Plugins wie Object-Aid automatisiert aus dem Code erzeugt werden, um effizient und aktuell Datenmodelle zu visualisieren. Automatisch erzeugten Layouts müssen dabei in der Praxis manuell überarbeitet werden. Auf ähnliche Weise können Service Facaden, Framework Architekturen usw. zur Dokumentation der Architektur und von Ausschnitten aus dem Lösungsdesign extrahiert werden. Wird Objekt-Relationales Mapping im Projekt verwendet, sollte auf die Wartung eines zusätzlichen E/R Diagramms gänzlich verzichtet werden.
Wenn der Code nicht zu komplex ist, können auch Abhängigkeiten zwischen Modulen und Packages visualisiert werden, was bei komplexen Projekten wenig hilfreich ist, außer wenn aus konkretem Anlass die Abhängigkeiten einzelner Klassen analysiert werden muss, z.B. wenn zyklische Abhängigkeiten vermutet werden. Dazu stehen jedoch bessere Werkzeuge zur Verfügung, z.B. Plugins für die Code-Analyse.
Hinweis: es gibt zahlreiche weitere Anwendungsmöglichkeiten und Diagrammarten, deren Aufwand- und Nutzen-Verhältnis für die agile Anforderungs-Erhebung aber weit hinter der für die hier beschriebenen Diagramme und Verwendung steht.