Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem
Aktualisiert: 11. Sept.
Im ersten Teil über Use Cases habe ich dargestellt, dass die richtige Differenzierung zwischen Nutzerzielen und Unterfunktionen nicht ganz leicht aber überaus wichtig ist (Use Cases Teil 1: Nutzerziele und fliegende Fische). Erhebt man Unterfunktionen zu vermeintlichen Nutzerzielen, verlieren wir nicht nur den Überblick, das Projektmanagement kann sogar in große Schwierigkeiten geraten.
Da uns dies (hoffentlich) nicht mehr vorkommt, stellt sich nun die Frage, wie man denn Nutzerziele am besten formuliert. Wie ich schon schrieb, werden da häufig Fehler gemacht. Im Folgenden möchte ich ein paar Tipps geben, wie man diese umgeht.
Lösungs-fixiert?
In Stellenausschreibungen finden wir immer wieder die Anforderung, der Mitarbeiter solle lösungsorientiert denken und arbeiten. Das klingt zuerst plausibel. Denn schließlich geht es letztendlich darum, ein Problem zu lösen. Bei all der Konzentration auf die Lösung wird aber oft das Problem aus dem Auge verloren. Gerade Techniker neigen dazu, wie aus der Hüfte geschossen eine Lösung zu präsentieren. Da werden schnell Details zu Server-Konfiguration und Kommunikationsprotokollen geliefert. Kunden und Auftraggeber sind oftmals geradezu begeistert, wie schnell das geht. Die vermeintliche Lösung hat schon x-mal funktioniert – und so sollte es auch jetzt sein. Klappt schon! Wirklich?
Dieser Ansatz beeindruckt beizeiten, stellt aber eine sehr wacklige Basis für große Investitionsentscheidungen dar. Mir fehlt da etwas ganz entscheidendes: Das Problem! Bevor man mit Lösungen durch die Lande zieht, muss das Problem beschrieben werden. Erst wenn das fachliche Problem allen Beteiligten bekannt ist, kann nach einer Lösung gesucht werden. Und die kann sich erheblich von der ersten “Schnellschuss-Lösung” unterscheiden.
Use Cases sind Problem-orientiert
Analytiker sollten also vielmehr Problem-orientiert denken und weniger in Lösungen. Ein Problem ist nichts negatives. Analytiker müssen das WAS (Problem) beschreiben und nicht das WIE (Lösung). Und genau an diesem Punkt kommen Use Cases zum Zuge. Sie stellen eine sehr gute Möglichkeit dar, die fachliche Problemlage detailliert festzuhalten.
Um das besser zu verstehen, führen wir uns vor Augen, wozu Use Cases da sind.
Use Cases beschreiben fachliche Abläufe.
Use Cases sind sozusagen die Vertragsgrundlage zwischen Auftraggeber, Fachabteilung und Design / Entwicklung.
Use Cases sind das Maß, an dem sich das entwickelte Produkt letztendlich messen lassen muss.
Use Case dienen als Grundlage für einen Test Cases.
Use Case ermöglichen viele Lösungen.
Use Case-Aufbau
Ein textlicher Use Case ist in der Regel ein einfaches Textdokument, das einen Anwendungsfall beschreibt. Es gibt dazu viele Vorlagen im Netz. Man sollte versuchen, einen Use Case so einfach wie möglich aufzubauen. Die typischen Felder für Use Cases auf Ebene Nutzerziel und Unterfunktion sind:
ID und Name: Geben Sie dem Use Case eine eindeutige Nummer und einen aussagekräftigen Titel bestehend aus Objekt und Verb – z.B. UC001 – Vertrag anlegen
Beschreibung: Beschreiben Sie Sinn und Zweck des Use Cases in wenigen Sätzen. Seien Sie so ausführlich, dass Sie auch noch in einem Jahr wissen, worum es in dem Use Case geht. Die Beschreibung für “UC001 – Vertrag anlegen” “Mit diesem Use Case kann man einen Vertrag anlegen.” ist prinzipiell richtig aber nicht hilfreich. Gehen Sie etwas weiter ins Detail.
Ebene: Nutzerziel vs. Unterfunktion
Aktor: z.B. Sachbearbeiter Vertragsabwicklung
Vorbedingung: z.B. Die Kundendaten sind im Partnersystem abgelegt.
Nachbedingung: z.B. Es liegt im Bestandssystem ein neuer Vertrag vor.
Trigger: z.B. Es ist ein neues Antragsformular eingetroffen.
Hauptablauf: Beschreiben Sie hier die verschiedenen Schritte des fachlichen Ablaufs, der normalerweise zum Erfolg führt. Beachten Sie, dass es sich dabei um eine Interaktion zwischen Aktor und dem zu entwickelnden System geht.
Ausnahmen: Halten Sie hier fest, was geschieht, wenn ein Schritt des Hauptablaufs nicht erfolgreich ausgeführt werden kann. Nehmen Sie dabei Bezug zu dem entsprechenden Schritt des Hauptablaufs.
Anmerkungen: Hier ist Platz für Fragen und offene Punkte, die aktuell noch nicht beantwortet werden können.
Es gibt noch weitere Felder, die man in einen Use Case aufnehmen kann: Bspw. Alternativer Ablauf, Häufigkeit, Performanzaspekte etc. Halten Sie den Aufbau aber so einfach wie möglich. Zusammenfassungen (Use Cases auf Ebene Drachen und Wolke) können gerne knapper aufgebaut sein.
Sechs Tipps zur Formulierung
Im Internet gibt es sehr viele Anleitungen, wie man textliche Use Cases aufbaut (siehe oben). Da es aber nicht nur um die Form sondern vielmehr um den Inhalt geht, vermisse ich konkrete Tipps, wie man das am besten schreibt. Sehen Sie hier wie Sie häufige Fehler vermeiden.
1. Fachlichkeit pur: Denken Sie lösungsunabhängig
Das ist auch schon der schwierigste Punkt. Es ist nicht leicht, sich von bekannten Lösungen zu entfernen und die dahinter stehende Fachlichkeit zu beschreiben. Ich erlebe es immer wieder, dass Fachexperten bei der Erstellung von Use Cases die Handhabung der aktuell eingesetzten Software minutiös darlegen. So erfährt man zwar, wie die Bedienung der aktuellen Software Schritt für Schritt erfolgt. Wir lernen aber nicht, was da fachlich abläuft.
Lassen Sie mich das an einem Beispiel folgenden Hauptablaufs darstellen:
Falsch – Lösungsabhängig:
Der Aktor klickt links in der Navigation auf “Vertrag anlegen”.
Das System zeigt die Erfassungsmaske “Neuen Vertrag anlegen”.
Der Aktor gibt die Daten ein und klickt auf OK.
Das System speichert die Daten.
Das System zeigt die Vertragsübersicht an.
usw.
Wir haben nun eine Schwierigkeit. Dieser Ablauf beschreibt eine konkrete Lösung in einem konkreten User Interface. Es handelt sich dabei mehr um ein Storyboard als einen Use Case. Stellen Sie sich aber vor, die Designer planen als Lösung ein sprachgesteuertes System. Dieser “Use Case” wäre dann hinfällig, da man in einem sprachgesteuerten System nicht klicken kann. Es gibt auch links keine Navigation, genauso wenig einen Button namens “OK”. Man könnte diese Ablaufbeschreibung nicht als Basis für einen Test Case verwenden und das sprachgesteuerte System ließe sich nicht an diesem Use Case messen. Die ganze Arbeit wäre “für die Katz”. Und in Summe wird das richtig teuer.
Das kann man aber umgehen. Denken Sie abstrakt. Lösen Sie sich von der Oberfläche. Was liegt hinter dem Ablauf? Oder stellen Sie sich vor, es gäbe noch keine Computer. Wie sieht der Ablauf dann aus?
Besser – Lösungsunabhängig:
Der Aktor ruft die Funktion zur Anlage eines Vertrags auf.
Das System bietet die Möglichkeit, Vertragsdaten einzugeben.
Der Aktor gibt die Vertragsdaten ein und bestätigt die Eingabe.
Das System legt den Vertrag mit den angegebenen Daten an.
Das System bietet eine Zusammenfassung der erfassten Daten.
usw.
Sie sehen, wir haben durch eine etwas andere Formulierung den Use Case von jeglichen Oberflächenlösungen befreit. Einen solchen Use Case können Sie auch als Grundlage für ein sprachgesteuertes System verwenden. Sie können aber auch eine Browser-Oberfläche gestalten, oder eine HOST-Anwendung oder, oder, oder… Der Use Case bleibt gültig. Auf diese Weise kann sich der Analytiker / Fachexperte auf die Fachlichkeit konzentrieren und die nachfolgenden Designer und Architekten haben alle Freiheiten, eine passende Lösung zu gestalten. Und egal, welche Lösung gewählt wird, das System lässt sich an diesem Use Case messen.
Dieser Punkt ist von zentraler Bedeutung und der Grund, warum ich vielen vermeintlichen Use Cases abspreche ein Use Case zu sein. Wenn wir Oberflächenbeschreibungen in einen Use Case reinbringen, handelt es sich um die Beschreibung einer Lösung. Wir können also dann eher von einem Storyboard sprechen. An Storyboards ist nichts auszusetzen. Ich setze sie selbst sehr oft ein. Wir dürfen aber nicht vergessen: Storyboards sind ein Designwerkzeug, kein Analyseinstrument.
2. Beschreiben Sie Basisfunktionen außerhalb
Es gibt in jedem System verschiedene Basisfunktionen, die beinahe jeden Use Case betreffen. Das sind beispielsweise:
Zugangskontrolle
Logging aller Zugriffe und Datenänderungen
Fehlerhandhabung
Datenvalidierung und Plausibilisierung
Systemverhalten bei Abbrechen einer Operation durch den Aktor
Diese Basisfunktionen sollten Sie an zentraler Stelle einmal beschreiben. Das kann natürlich auch gerne in Form eines Use Cases geschehen, muss es aber nicht. Das hat den Vorteil, dass man nicht in jedem Use Case auf diese Basisfunktionen eingehen muss. Das erleichtert die Lesbarkeit ungemein.
In vielen Systemen muss der Aktor angemeldet sein, um überhaupt arbeiten zu können. Wenn dem so ist, können Sie die Vorbedingung “Der Aktor ist am System angemeldet.” sparen. Aber: Wenn man in dem zu beschreibenden System viele Dinge auch ohne vorherige Anmeldung machen kann, dürfen Sie auf die Vorbedingung in Use Cases, die eine Anmeldung erfordern, nicht verzichten. Wenn das Logging an zentraler Stelle beschrieben ist, können Sie sich die Nachbedingung “Das System hat alle Datenzugriffe und -veränderungen geloggt.” sparen.
Fehlerhandhabung, Datenvalidierung und das Verhalten beim Abbrechen der Operation blähen die Ablaufbeschreibung und die Ausnahmen häufig sehr stark auf. Wenn Sie das entsprechende Systemverhalten zentral definieren, entlasten Sie die Use Cases und steigern deren Lesbarkeit.
3. Vergessen Sie nicht das System im Hauptablauf
Häufig lese ich Use Cases, die im Hauptablauf und den Ausnahmen ausschließlich die Schritte des Aktors benennen. Wäre ich gehässig, könnte ich sagen: Prima, wir sind fertig. Das System muss ja nichts machen, da der Aktor alles erledigt. Das ist natürlich nicht der Fall. Bei Use Cases geht es um die Interaktion zwischen dem Nutzer und dem System. Und das, was das System machen muss, ist genau das spannende. Denken Sie an die Benachrichtigung anderer Systeme, Berechnung von Folgeschritten und derartige Operationen, die dem Nutzer verborgen im Hintergrund ablaufen. Wenn diese Schritte nicht im Use Case erwähnt werden, werden sie nicht entwickelt – und das System ist somit unbrauchbar.
4. Beschränken Sie den Hauptablauf auf maximal zehn Schritte
Die Verständlichkeit von Use Cases hängt in großem Maße davon ab, wie sie in der Gesamtheit strukturiert sind. Auf das Thema Nutzerziel vs. Unterfunktion bin ich schon eingegangen. Losgelöst von dieser Differenzierung gibt es eine Goldene Regel: Ein Use Case mit mehr als zehn Schritten im Hauptablauf ist falsch!
Das klingt radikal, ist aber eine gute Richtlinie. Sollte der Use Case mehr Schritte umfassen, überprüfen Sie die Granularität. Kann es sein, dass Sie zwei Use Cases in einem beschreiben? Hat sich da eine Unterfunktion eingeschlichen? Trennen Sie den Use Case auf. Das erleichtert es dem Leser sehr. Denn was nicht verstanden wird, wird nicht entwickelt.
5. Validieren statt prüfen, ob…
Häufig muss das System die Benutzereingaben über die normale Validierung hinaus prüfen und in Abhängigkeit davon spezielle Schritte einschlagen.
Man könnte das so schreiben:
Hauptablauf:
Der Nutzer gibt die Daten ein.
Das System prüft, ob die Daten gültig sind: a) Die Daten sind gültig: Das System macht… b) Die Daten sind ungültig: Das System macht…
So entstehen im Hauptablauf Unterabläufe, die schnell verwirren. Überlegen Sie stattdessen, welches der häufigste Fall ist. Nehmen Sie diesen in den Hauptablauf und die nicht so häufigen Fälle in die Rubrik Alternativer Ablauf auf. In dem konkreten Beispiel handelt es sich aber sogar um eine Ausnahme.
Besser modelliert man das so:
Hauptablauf:
Der Nutzer gibt die Daten ein.
Das System stellt sicher (validiert), dass die Daten gültig sind. Das System macht das…
Ausnahmen:
zu 2.a) Die Daten sind ungültig: Das System macht jenes…
6. Vemeiden Sie Datenattribute und zu viele Details
Manche Use Case-Autoren meinen es besonders gut und nehmen viele Details in den Use Case auf. Doch das ist kontraproduktiv.
Zu detailliert:
Der Aktor gibt den Namen ein.</>
Der Aktor gibt den Nachnamen ein.</>
Der Aktor gibt das Geburtsdatum ein.</>
…
Das ist extrem kleinteilig. Ein Use Case sollte nicht in diese Detailtiefe gehen. Auch eine direkte Auflistung von Fachattributen im Use Case ist nicht sinnvoll.
Auch zu detailliert:
Der Aktor gibt die Personendaten ein. Dazu gehören: Name, Nachname, Geburtsdatum, Geschlecht…
Besser:
Der Aktor gibt die Kunden- und Vertragsdaten ein.
Einerseits reduzieren zu viele Details die Lesbarkeit. Auf der anderen Seite ändern sich Fachattribute auch gerne mal. Sie müssten bei allen auch noch so kleinen Änderungen alle Use Cases durchgehen und die Attribute anpassen. Das ist eine müßige Tätigkeit. Beschreiben Sie die Attribute besser in einem Fachklassenmodell (UML). Das ist aufgrund der grafischen Darstellung übersichtlicher und lässt sich an einer Stelle zentral pflegen. Die folgende Abbildung zeigt ein solches Fachklassenmodell in vereinfachter Form. Versuchen Sie aber mal die darin enthaltenen Informationen textlich im Use Case zu beschreiben. Sie werden sofort sehen, wie viel Text da zusammenkommt. Das wird unverständlich.
Zum Vergrößern anklicken: Beispielhaftes Fachklassenmodell (UML) einer Vertragsverwaltung
Fazit
Use Cases sind nicht dadurch Use Cases, dass sie einer bestimmten Form folgen. Um ihrem Ziel zu dienen, müssen sie die Fachlichkeit lösungsunabhängig ohne Oberflächenmerkmale beschreiben. Andernfalls verlieren sie spätestens in der Designphase ihre Relevanz und können für spätere Qualitätssicherungsmaßnahmen nicht verwendet werden. Schlimmstenfalls könnte der Auftraggeber sogar die Abnahme des fertigen Produkts verweigern, da es mit größter Wahrscheinlichkeit mit den ursprünglichen (oberflächen-lastigen) “Use Cases” nicht mehr in Deckung zu bringen ist.
Jetzt sollte klar geworden sein, warum ein Use Cases keine Lösung ist. Stattdessen liefert er ein gut beschriebenes Problem. Es gibt noch viele Dinge bei der Use Case-Beschreibung zu bedenken. Auch wenn das Schema denkbar einfach ist, bedarf es einiger Übung, Use Cases zielführend zu entwickeln. Welche Tipps haben Sie zu Use Cases? Lassen Sie uns Ihre Ideen diskutieren.
#BusinessProcessAnalysis #Fachspezifikation #Storyboard #Methodik #Beratung #UseCase