Use Cases Teil 1: Nutzerziele und fliegende Fische

, , ,

Use Cases gehören zum Alltag der IT. Kein größeres Projekt kommt ohne sie aus. Die ganze Welt schreibt Use Cases. Wirklich? Dass ich diesen Artikel schreibe, mag erkennen lassen, dass ich da meine Zweifel habe. Meine These: Viele sogenannte Use Cases sind gar keine. Ich möchte im Folgenden darstellen, wie ich dazu komme. Da das Thema umfangreich ist, teile ich die Betrachtung in zwei Artikel auf:

  1. Differenzierung zwischen Nutzerziel und Unterfunktion.
  2. Wie beschreibe ich ein Nutzerziel (Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem).

Der Begriff Use Case lässt sich im Deutschen am besten mit Anwendungsfall übersetzen. Hier passt die wortgetreue Übersetzung sogar ganz gut. Ein Use Case beschreibt, wie ein Nutzer (Aktor) mit einem System in Interaktion tritt, um ein bestimmtes Ziel zu erreichen. Wenn ich hier vom Erreichen eines Ziels spreche, so steckt dahinter zweifelsohne eine Intention. Und die können nur Menschen bzw. Gruppen von Menschen haben. Genau genommen können Use Cases aber auch die Interaktion zwischen verschiedenen Systemen beschreiben. Diese spezielle Form von Use Cases möchte ich hier nicht diskutieren. Mir geht es an dieser Stelle ausschließlich um die Use Cases, die beschreiben, wie ein menschlicher User mit einem System interagiert, um ein fachliches Ziel zu erreichen. Warum ich das fachliche Ziel hervorhebe, lege ich später dar.

Use Cases gemäß Alistair Cockburn

Alistair Cockburn hat 2001 das Buch „Writing Effective Use Cases“ herausgebracht. Es ist bemerkenswert, und ich kann es jedem interessierten Leser wärmstens empfehlen. Er stellt darin verschiedene Granularitäten von Use Cases dar. Da gibt es welche für sehr große Zusammenhänge und welche für die winzigen Details. Alistair Cockburn findet für die Kategorisierung das Bild eines vertikalen Querschnitts unser Erlebniswelt: Ganz oben die Wolken, darunter lassen Kinder Drachen am Himmel fliegen, dann kommt die Oberfläche eines netten Sees mit seinen kleinen Wellen, im See schwimmen Fische und am Seegrund leben Muscheln.

Zum Vergrößern anklicken: Verschiedene Use Case-Ebenen

  • Globale Zusammenfassung (Wolke): Diese Use Cases beschreiben, wie Organisationen miteinander interagieren. Dabei werden die Organisationen lediglich von außen betrachtet.
  • Zusammenfassung (Drachen): Mit diesen Use Cases werden Abläufe innerhalb einer Organisation beschrieben. Auf dieser Ebene wird auch beschrieben, wie Nutzerziel-Use Cases miteinander in Beziehung stehen. Eine solche Zusammenfassung verschafft einen guten Überblick über die Organisationsprozesse.
  • Nutzerziel (Welle): Diese Use Cases beschreiben die Interaktion eines konkreten Nutzers mit dem System. Diese Ebene verdeutlicht, warum wir das System entwickeln, warum der Anwender das System braucht. Dabei wird das System als Blackbox von außen betrachtet. Technische Details des Systems sind irrelevant. Da hier „die Musik spielt“, werden unter Use Cases häufig diese Nutzerziele verstanden. Sie sind also DIE Use Cases.
  • Unterfunktion (Fisch): Die Unterfunktionen beschreiben Funktionalitäten, die zur Erreichung der Nutzerziele erforderlich sind und von diesen benutzt werden. Der Nutzer würde diese Unterfunktionen aber nie ohne einen größeren Zusammenhang (Nutzerziel-Use Case) aufrufen oder aufrufen dürfen.
  • Zu detailliert (Muschel): Viele Funktionalitäten sind derart kleinteilig, dass sie im Rahmen einer Use Case-Betrachtung vernachlässigt werden können. Wenn Sie während der Autofahrt den Gang wechseln, möchten Sie nicht wissen, wie Ritzel A in B greift. Der Use Case „Kraftübertragung Ritzel A nach B veranlassen“ kann bei der Konzeption eines Fahrzeugs als Muschel vernachlässigt werden.

Ich habe diesen kleinen Ausflug zu Alistair Cockburn gemacht, um ein besseres Verständnis der verschiedenen Use Case-Granularitäten zu vermitteln. Wie ich schon eingangs erwähne, stoße ich bei der Beschreibung von Use Cases immer wieder auf zwei Schwierigkeiten:

  1. Es wird nicht hinreichend zwischen Nutzerziel und Unterfunktion differenziert.
  2. Die Beschreibung der Nutzerziele beschränken sich nicht auf die Fachlichkeit sondern beinhalten schon eine vermeintliche Lösung. Dazu aber in Teil 2…

Was ist ein Nutzerziel, was eine Unterfunktion?

Ein Nutzerziel-Use Case beschreibt eine Funktion, deretwegen der Nutzer mit dem System arbeitet. Die erfolgreiche Erledigung eines Use Cases dieser Ebene bringt einen fachlichen Mehrwert. Stellen wir uns einen Sachbearbeiter in einer Versicherung vor, der für die Vertragsverwaltung zuständig ist. Er wird dafür bezahlt, Verträge aufzunehmen, aktuell zu halten und im Falle einer Vertragskündigung den entsprechenden Vertrag zu inaktivieren (Löschen wird vermutlich keine gute Lösung sein). Wir können hieraus drei wichtige Use Cases ableiten:

  • Vertrag anlegen
  • Vertrag bearbeiten
  • Vertrag inaktivieren

Diese drei Use Cases bringen zweifelsohne einen fachlichen Mehrwert im Sinne des Unternehmens und der Mitarbeiterverantwortlichkeit. Nun gibt es aber über diese drei Nutzerziele hinaus weitere Funktionen, die der Sachbearbeiter nutzt, um seine fachliche Arbeit bewerkstelligen zu können. Kommt ein neuer Vertrag auf den Tisch, wird der Sachbearbeiter bestimmt wissen wollen, ob der Kunde schon im System erfasst ist. Er wird also nach der Person suchen. Das ist in vielen Systemen eine sehr wichtige Funktion. Wir haben also eine weitere Funktion:

  • Person suchen

Ist das aber ein Nutzerziel? Nein – auf keinen Fall! Der Sachbearbeiter wird ja nicht für das Suchen bezahlt. Die Suche bietet keinen fachlichen Mehrwert. Ja, es ist meistens sogar aus Datenschutzgründen verboten ohne größeren Kontext (Nutzerziel) im System zu suchen. Es gibt wenige Berufe, die das ermöglichen. Mir fallen da bestenfalls Geheimdienste und reine Rechercheunternehmen ein. In der Regel ist eine anlassunabhängige Suche untersagt. Und auch als privater Onlineshopper wollen wir nicht einfach suchen. Suchen ist nicht per se eine tolle Sache. Nein, wir möchten ein passendes Produkt bestellen – und genau zu diesem Zweck (Nutzerziel Produkt bestellen) suchen wir.

Jetzt wird vermutlich deutlich, dass es sich bei der Suche in den seltensten Fällen um ein Nutzerziel handelt. Was ist es dann? In fast allen Systemen ist die Suche eine Unterfunktion (Fisch), die in den Kontext übergeordneter Nutzerziele (Welle) eingebunden ist. Ein typisches Merkmal von Unterfunktionen ist auch, dass sie von mehreren Nutzerzielen verwendet / aufgerufen werden. In unserem Beispiel der Vertragsverwaltung wird der Sachbearbeiter die Unterfunktion Person suchen in allen drei Nutzerzielen verwenden.

Tipps zur Unterscheidung

Die klare Differenzierung zwischen Nutzerzielen und Unterfunktionen ist nicht immer ganz leicht. Es gibt aber ein paar Anhaltspunkte, die dabei helfen:

Nutzerziele
  • Der Nutzer hat sich nach diesem Use Case eine Kaffeepause verdient.
  • Der Nutzer wird dafür bezahlt, dass er diesen Use Case ausführt.
  • Der Kunde bezahlt dafür, dass er diesen Use Case ausführen kann.
  • Dieser Use Case bietet einen fachlichen Mehrwert.
  • Der Use Case darf ohne übergeordneten Kontext ausgeführt werden.
  • Es ist sinnvoll, diesen Use Case ohne übergeordneten Kontext auszuführen.

Unterfunktionen

  • Der Nutzer darf die Unterfunktion nur im Rahmen eines übergeordneten Nutzerziels ausführen.
  • Die Unterfunktion ist zu kleinteilig, als dass das Management sich damit beschäftigen würde.
  • Der Nutzer wird nicht dafür bezahlt, dass er die Unterfunktion ausführt.
  • Die Unterfunktion bringt keinen Mehrwert, der in Rechnung gestellt werden kann.
  • Die Unterfunktion wird von mehreren Nutzerzielen verwendet.
  • Die Unterfunktion ist in wenigen Sekunden erledigt.

Problem „Fliegende Fische“

Use Cases haben das Ziel, ein System übersichtlich zu beschreiben. Sie dienen als Kommunikationsgrundlage zwischen Auftraggeber und Auftragnehmer, zwischen Fachabteilung und Entwicklung. Verschiedentlich wird auch beschrieben, dass die Use Cases als Übereinkunft zwischen den beteiligten Parteien dienen: Ja, das will ich gelöst haben. Ja, das können wir lösen.

Um das zu gewährleisten, muss die Gesamtheit der Use Cases (alle Ebenen) klar gegliedert sein. Nur so entsteht eine verständliche Use Case-Landschaft, welche auch für das Projektmanagement wichtig ist. Häufig werden Unterfunktionen irrtümlicherweise als Nutzerziele definiert. Das geschieht oft aufgrund der Einschätzung, dass eine bestimmte Unterfunktion unverzichtbar und wichtig ist. Das ist aber ein Fehler: Niemand hat behauptet, Unterfunktionen seien unwichtig oder verzichtbar. Ganz im Gegenteil. Ohne manche Unterfunktionen wie beispielsweise die Suche lässt sich das System gar nicht vernünftig nutzen.

Dieser Irrtum führt manchmal sogar dazu, dass Unterfunktionen nicht nur zu Nutzerzielen erhoben werden, sondern ihnen sogar noch eine eigenständige Zusammenfassungsebene (Drachen) eingeräumt wird:

  • Zusammenfassung: Suchen
    • Nutzerziel: Person nach Name suchen
    • Nutzerziel: Person nach Alter suchen
    • etc.

Das Problem wird deutlich, wenn wir uns vergegenwärtigen, wie das Projektmanagement das Projekt in kleinere Entwicklungshäppchen aufteilt. Diese Aufteilung orientiert sich häufig an der Zusammenfassungsebene. Zuerst machen wir die Bestandsverwaltung, dann die Partnerverwaltung usw. Wenn nun die Suche ein Paket auf Drachen-Ebene einnimmt, kann es passieren, dass die Suche erst später -oder gar nicht- entwickelt wird. Wir hätten dann möglicherweise unterhalb der Ebene Bestandsverwaltung (Drachen) ein Nutzerziel Vertrag bearbeiten (Welle), das es uns nicht ermöglicht nach einer Person zu suchen, da das Paket Suche (fälschlicherweise auch Drachen) erst für das nächste Release betrachtet wird. Versuchen Sie nun die Suche nachträglich in die Bestandsverwaltung hinzubringen! Das wird teuer…

In diesem Fall spreche ich von Fliegenden Fischen. Die falsche Differenzierung zwischen Nutzerzielen und Unterfunktionen wird zu einem ernsthaften Managementproblem. Und letztendlich bleibt der Nutzer auf der Strecke.

So, und nun Hand auf’s Herz: Sind Ihre Nutzerziel-Use Cases wirklich immer Nutzerziele? Oder hat sich da auch schon mal eine Unterfunktion in den Vordergrund gedrängelt? Ich freue mich auf Ihre Anmerkungen.

Tipps zur Formulierung von Nutzerzielen gebe ich demnächst im zweiten Teil: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem

5 Kommentare
  1. Bernd Lohmeyer
    Bernd Lohmeyer says:

    Das freut mich, Herr Bald. Die Use Case-Mdellierung hat eben wirklich so ihre Tücken. Bei Fragen helfe ich gerne weiter.

  2. Hartmut König says:

    Hallo Herr Lohmeyer,

    eine Frage: Und welche Use Cases würden Sie bei einem Projekt „Entwicklung einer systemweiten Suche“ definieren?

  3. Bernd Lohmeyer says:

    Hallo Herr König,

    das ist aus der Ferne schwer zu beantworten. Was ist das primäre Ziel des Systems? Hieraus leitet sich ab, ob es sich bei der Suche um ein Nutzerziel oder eine Unterfunktion handelt. Handelt es sich um eine “normale” Unternehmensanwendung, sind die verschiedenen Suchen (Freitext-, Detailsuche etc.) in der Regel Unterfunktionen. Ein Suchmaschinenbetreiber, dessen Geschäftsziel es ist, Suchfunktionen anzubieten, wird das anders sehen. Für diesen werden die unterschiedlichen Suchen Nutzerziele sein.

    Das Thema Suche kann aus Nutzersicht sehr einfach aber leider auch sehr kniffelig sein. Letzteres habe ich beim Europäischen Patentamt erfahren.

    Vielleicht können wir das telefonisch vertiefen. Rufen Sie mich doch einfach mal an.

    Viele Grüße,

    Bernd Lohmeyer

Trackbacks & Pingbacks

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.