Use-Case-Puzzeln für Fortgeschrittene

Dr.-Ing. Daniel Lübke

Implizites Prozesswissen muss nutzbar gemacht werden

Weil in den meisten Unternehmen keine aktuelle Prozessdokumentation verfügbar ist, sondern das Prozess-Know-How nur implizit durch die Mitarbeiter im Unternehmen vorhanden ist, stellt sich automatisch die Frage, wie man möglichst effizient Geschäftsprozesse erfassen kann, wenn man sie durch Software unterstützen will. Mitarbeiter kennen ihre täglichen Arbeitsabläufe und können diese aus ihrer Sicht beschreiben. Allerdings kennen Sie die vor- und nachgelagerten Schritte kaum bis gar nicht. Die erste Herausforderung ist also erst einmal die Dokumentation der Aktivität selber, welche dann auch in den Anforderungen verwendet werden kann, um das neue System zu beschreiben und daran Oberflächenentwürfe und benötigte Daten anzuhängen. Dazu können etablierte Anforderungstechniken wie tabellarische Use Cases verwendet werden, mit denen ein Softwareprojekt vertraut ist und die auch für die Fachseite gut verständlich sind. Die zweite Herausforderung ist dann das Zusammenfügen der vielen einzelnen lokalen Sichten zu einer globalen Perspektive.

Use Cases dokumentieren Anforderungen aus der Sicht des Hauptakteurs

Ein Use Case beschreibt die Interaktion zwischen einem Hauptakteur und evtl. Nebenakteuren mit dem System. Am Anfang ist hierbei vor allem das System als neu zu entwickelndes Element unklar. Dagegen können die Akteure, die oftmals bereits diese Aufgabe anders ausführen, sehr gut darüber Auskunft geben, wie der heutige Ist-Zustand ist. Ausgehend von diesem Ist-Zustand muss dann der Use Case weiterentwickelt werden, bis er den neuen Soll-Zustand beschreibt.

Die Dokumentation von Use Cases ist ziemlich frei. Der Hauptbestandteil eines Use Cases ist das Hauptszenario, in dem beschrieben wird, welche Interaktionen zwischen Akteuren und dem System in welcher Reihenfolge durchgeführt werden sollen. Somit sind auch verschiedene Techniken und eine Vielzahl von Vorlagen entstanden, die sich alle „Use Cases“ nennen. Schon Cockburn [1] beschreibt in seinem Buch viele Möglichkeiten, Use Cases zu dokumentieren. In der Praxis reicht die Bandbreite von Fließtext bis hin zu Formalismen wie Automaten.

Bewährt haben sich vor allem tabellarische Vorlagen. Eine für unseren Anwendungszweck ausreichende Vorlage ist in Tabelle 1 gezeigt. Die Tabellen geben durch die definierten Felder eine Hilfe und Checkliste für die zu ermittelnden Informationen und bieten eine sehr kompakte, standardisierte und schon halb-formale Form der Dokumentation.

Beim Erfassen der Use Cases werden sonst oftmals die Auslöser sowie Vor- und Nachbedingungen ziemlich stiefmütterlich behandelt. Teilweise findet man dort Standardtexte (z.B. „Use Case wurde korrekt ausgeführt“ als Nachbedingung) oder es werden nicht-funktionale Anforderungen in jedem Use Case wiederholt. Wir wollen an diesen Stellen nun wirklich die fachlichen Abhängigkeiten definieren: Welche Daten werden benötigt bzw. werden in diesem Use Case bereitgestellt („Antrag ist erfasst“, „Kundeninformationen erfasst“), welche zeitlichen Bedingungen gibt es („Erster eines jeden Monats“, „14 Tage nach Zustellung der Rechnung“), in welchem Fall kommt dieser Use Case zur Ausführung („Kunde hat VIP-Status“) oder welchen Zustand muss das System oder dessen Umwelt haben („Benutzer ist angemeldet“).

Anhang der Szenarienbeschreibung ist erkennbar, dass bereits im Use Case Abläufe beschrieben werden, wenn auch erstmal im Kleinen. Diese können schon graphisch dargestellt werden, wozu typischerweise UML-Sequenzdiagramme verwendet werden. Weil wir aber im Folgenden Geschäftsprozesse konstruieren wollen, verwenden wir an dieser Stelle stattdessen Ereignis-gesteuerte Prozessketten (EPK [2]), weil diese über ihr Ereignis-Element Zustände explizit ausdrücken können, was in anderen Notation, wie z.B. BPMN [3], nicht einfach möglich ist. Unser Hauptaugenmerkt liegt nicht auf den einzelnen Schritte im Szenario, sondern auf der Einbettung des Use Cases in seine Umgebung, d.h. seine Vor- und Nachbedingungen. Dazu konvertieren wir jede Vorbedingung und den Auslöser in je einen Zustand, also ein EPK-Ereignis. Existieren danach mehr als ein Ereignis, so verbinden wir dieses mittels eines Und-Konnektors. Danach folgt eine Funktion, die den Use Case repräsentiert. Abschließend werden alle Nachbedingungen zu Ereignissen konvertiert. Existieren wieder mehrere, so werden diese ebenfalls über einen Und-Konnektor an den Use Case angehängt, weil nach der Ausführung des Use Case all diese Bedindungen eingetreten sein müssen. Das Ergebnis für den Beispiel Use Case ist in Abbildung 1 dargestellt.

Sollten in Erweiterungen alternative Ausgänge des Use Cases dargestellt sein, so müssen diese ebenfalls über Endereignisse modelliert werden. Allerdings wird dann ein XOR-Konnektor benötigt, um die verschiedenen Ausgänge auszudrücken. Dies ist in Abbildung 2 illustriert.

Möchte der Requirements Engineer die UML-Sequenzdiagramme komplett ersetzen, so können auch die Details eines Use Cases ausmodelliert werden. Die prinzipielle Struktur ist in Abbildung 3 gezeigt. Dabei kommt eine weitere Eigenschaft der EPKs zum Tragen: Die Möglichkeit, Funktionen per hierarchischer Verfeinerung weiter zu detaillieren. Damit ist es möglich, weitere Details für die grobe Sicht auf den Use Case, die wir später für die globale Sicht benötigen, zu hinterlegen.

Vor- und Nachbedingungen bedingen eine Ausführungsreihenfolge

Mit diesen Informationen können die Use Cases, sofern sie einen Prozessablauf darstellen, in eine Reihenfolge gebracht werden, indem Use Cases, die eine Vorbedingung A haben, hinter die Use Cases gestellt werden, die A als Nachbedingung haben. Dies ist zu mindestens in der Theorie recht einfach: Muss für einen Use Case eine Vorbedingung vorhanden sein, so muss dieser Zustand durch mindestens einen anderen Use Case hergestellt worden sein.

Um diese globalen Zusammenhänge zu beschreiben, fügen wir im nächsten Schritt die kleinen EPKs zu einer Großen zusammen. Die EPK-Ereignisse werden nun benutzt, um die Vor-und Nachbedingungen sowie die Auslöser darzustellen. In Abbildung 4 ist das einfache Zusammenfügen von zwei Use Cases über eine gemeinsame Bedingung dargestellt.

Etwas komplizierter wird es, wenn mehrere Use Cases diese Bedingung als Vorbedingung haben bzw. mehrere Use Cases dieselbe Nachbedingung besitzen. In diesem Fall müssen logische Konnektoren verwendet werden, die den Prozessfluss aufspalten (split) oder zusammenführen (join). Hierzu gibt es in den EPKs drei verschiedene Konnektortypen: Exklusives Oder (XOR), Inklusives Oder (OR) und ein Und (AND).

Besitzen mehrere Use Cases dieselbe Vorbedingung so kann dies, wie in Abbildung 5 dargestellt, mit einem Und realisiert werden. Haben dagegen mehrere Use Cases dieselbe Nachbedingung, so muss dies mit einem der beiden Oder bewerkstelligt werden, wie in Abbildung 6 gezeigt ist. Welches Oder dabei das richtige ist, ist vom konkreten Prozess abhängig: Das XOR ist nicht blockierend, aber ausschließend, d.h. nur ein eingehender Zweig sollte aktiviert werden, während das OR blockierend ist, d.h. der Konnektor wartet, bis der Zustand von allen Zweigen bekannt ist und kann daher auch in Situationen verwendet werden, in denen mehrere eingehende Zweige aktiviert worden sind.

Beispiel

Um dieses Vorgehen zu demonstrieren, wird hier ein Ausschnitt von vier Use Cases aus einem größeren Projekt benutzt. Das Ziel ist die Unterstützung von Bewilligungen für Verbesserungsmaßnahmen. Dabei muss nach der Antragsstellung sowohl der Fachbereichsleiter als auch das Controlling zustimmen. Die Durchführung der Maßnahme wird hier vereinfacht als ein einzelner Use Case dargestellt. Die verkürzten, tabellarischen Use Cases sind in Tabellen 2–5 gezeigt.

Diese vier Use Cases können nun in die EPK-Notation überführt werden. Das Zwischenergebnis ist in Abbildung 7 gezeigt.

Im nächsten Schritt können diese zu einer EPK verschmolzen werden. Das Ergebnis ist in Abbildung 8 gezeigt. Dabei können in dieser Konstellation die beiden Bewilligungen parallel ausgeführt werden. Solche entstehenden parallelen Zweige sind für das Requirements Engineering sehr interessant, denn meistens werden in Unternehmen nur sequentielle Abläufe gelebt und dann auch ungefragt in die Softwarelösungen übernommen. Entstehen durch die Use- Case-Visualisierungen parallele Zweige, so sind dies entweder potentielle Optimierungen in Unternehmens- und damit den Softwareabläufen oder es fehlen noch Vor- oder Nachbedingungen in den Use Cases. In beiden Fällen ist deren Identifikation ein Vorteil für das Requirements Team.

Inkrementelles Vorgehen und Validierung

Mit diesem Vorgehen können Use Cases inkrementell erstellt und validiert werden. Dabei können die tabellarischen Use Cases genutzt werden, um durch initiale Use-Case-Interviews zu führen und deren Ergebnisse zu dokumentieren. Die Sicht aus der Perspektive der zu interviewenden Personen ist gut in der Textform zu erfassen und wird von allen Experten und Anwendern der Fachseite verstanden, weil sie keine zusätzliche und ihnen fremde Notation lernen und verstehen müssen.

Auf der anderen Seite hat der Requirements Engineer die Möglichkeit, Abhängigkeiten zwischen den Use Cases als Geschäftsprozess zu visualisieren. Damit ist es schon früh möglich, weitere Use Cases zu identifizieren. Diese liefern weitere Bedingungen, so dass sich die Requirements Engineers schrittweise durch die fachlichen Abläufe durcharbeiten können.

Durch die graphische Visualisierung wird zudem ein Perspektivenwechsel vorgenommen, mit denen die Fachseite konfrontiert werden kann: Teilweise sind mehr Abläufe parallelisierbar, als dies bislang gelebt worden ist, teilweise sind Schritte anders und besser gruppierbar und damit effizienter zu bearbeiten, weil sie in ein und derselben Oberfläche realisiert werden können. In einem Projekt, welches sehr ähnlich dem Beispiel war, wurde seit Jahrzehnten ein gewisser, eingespielter Prozess gelebt. Während der Requirementsphase für die Entwicklung einer Software stellte sich dabei heraus, dass der Prozess viel effizienter umgesetzt werden konnte, weil einige Schritte nicht voneinander abhängig waren, obwohl sie bislang in der Papierwelt rein sequentiell ausgeführt worden waren.

Durch den Perspektivenwechsel zwischen der lokalen Use-Case-zentrierten Sicht und der globalen Geschäftsprozesssicht können also etablierte Strukturen hinterfragt und aufgebrochen werden. Daher ist diese Technik ebenfalls geeignet, Requirements für ein zu entwickelndes System aus dem Ist-Zustand heraus zu entwickeln.

Über Konsistenz zur Automatisierung

Im Laufe des Projektes wächst die Anzahl der Use Cases und somit wird die manuelle Visualisierung immer aufwändiger. Mit einer einstelligen Anzahl an Use Cases ist die Erstellung der Geschäftsprozessmodelle noch Fleißarbeit, aber für eine größere Menge ist die manuelle Erstellung und Pflege weder praktikabel noch wirtschaftlich.

Der nächste Schritt ist daher die Automatisierung der Abbildung. Mittels Makros oder XSLT-Skripten ist es mit den meisten Tools möglich, die Erstellung der Geschäftsprozessmodelle zu automatisieren. Die aktuellen Dateiformate für Text (DOCX und ODT) sind XML-Dokumente und aus allen Requirements Tools können die Daten in ein maschinenlesbares Format exportiert werden. Im Gegenzug lesen die Geschäftsprozessmodellierungstools XML-Formate ein oder man kann mit Visio und VBA Visio-Diagramme erzeugen. Jedoch ist diese Automatisierung genauso abhängig von den eingesetzten Werkzeugen und ebenfalls den Vorlagen, so dass es (bisher) keine Lösung gibt, die zwischen verschiedenen Projekten portabel ist.

Die Automatisierung basiert auf dem oben beschriebenen Vorgehen und kann leicht algorithmisch umgesetzt werden. Damit dieses jedoch auch praktisch einsetzbar ist, müssen die Vor- und die Nachbedingungen überall exakt gleich geschrieben werden, denn ein Computer kann keine natürliche Sprache verstehen, um beliebige Bedingungen miteinander vergleichen zu können. Dies mag zunächst wie ein Nachteil klingen und setzt Disziplin voraus, hat jedoch auch Vorteile. Denn durch die konsistente Formulierung von Vor- und Nachbedingungen wird die Sprache in den Anforderungen exakter und Missverständnissen wird vorgebeugt, indem gleiche Dinge durch gleiche Begriffe und Ausdrücke beschrieben werden. Lediglich das Zerkleinern der Bedingungen in einzelne Bedingungen, die ohne „und“ und „oder“ ausgedrückt werden, ist gewöhnungsbedürftig: Statt der einen Vorbedingung „Antrag und Budget ist bewilligt“, müssen nun zwei Vorbedingungen „Antrag ist bewilligt“ und „Budget ist bewilligt“ formuliert werden.

Mittels Werkzeugunterstützung kann auch die Einarbeitung in größere Projekte erleichtert werden. Oftmals bestehen Spezifikationen aus einer großen Sammlung von Use Cases. In mittelgroßen Projekten kommen da schnell 100 Use Cases zusammen. Mittels der Visualisierung mit EPKs ist es möglich, schneller Zusammenhänge zu erkennen und so das Einarbeiten oder das Reviewen schneller vorzunehmen.

Fazit

Die Visualisierung von Use Cases mittels Geschäftsprozessmodellen ist ein lohnenswerter Ansatz, wenn Softwaresysteme Abläufe in Unternehmen unterstützen sollen und keine aktuelle Prozessdokumentation vorhanden ist. Somit ist es möglich, auf einfache Art und Weise mit den ohnehin im Projekt zu erfassenden Use Cases, die Geschäftsprozesse zu reverse engineeren. Auch wenn die Softwarelösung nicht mittels BPEL, BPMN2 oder Workflow Engines implementiert werden soll, bringt die Erstellung von Geschäftsprozessmodellen eine neue, globale Sicht, die sowohl die Requirements Engineers als auch die Fachseite dazu animieren kann, Annahmen und Gewohnheiten zu hinterfragen und somit bessere Lösungen anzustreben. Zusätzlich kann die globale Perspektive Lücken in den Use Cases sowie inkonsistente Vor- und Nachbedingungen aufzeigen.

Referenzen