Was ist ein Use-Case? Definition und Nutzen im Überblick!

Stellen Sie sich vor, Sie sind als Projektleiter für ein System verantwortlich. Dieses System interagiert mit den verschiedensten Nutzern, dies können Kunden oder auch andere Systeme sein. Hierbei ist es also wichtig, dass Sie nicht nur das System von Ihnen als Projektmanager betrachten, sondern auch die Sichtweise von außen in die Entwicklung und Optimierung der Software integrieren.

Genau davon handelt ein Use-Case. Erfahren Sie hier mehr über die Definition, den Nutzen von sogenannten Anwendungsfällen und die Erstellung eines Use Case Diagramms.

Was ist ein Use-Case?

Einfach ausgedrückt wird mit einem Use Case die nach außen sichtbare Interaktion eines Nutzers mit einem System dokumentiert. Dieser Nutzer kann wie bereits erwähnt entweder eine Person, eine Organisation oder ein anderes System sein.

Dabei besteht am Anfang vom Anwendungsfall ein Auslöser, der den Nutzer dazu veranlasst, in Interaktion mit dem System zu treten. Der Nutzer tritt hierbei also als Akteur auf, der mit der Verwendung des Systems ein bestimmtes Ziel bzw. ein Ergebnis erreichen möchte. Dieses Ziel erreicht der Akteur, indem er eine gewissen Reihe an Aktionen durchführt.

Meist kann ein System mehrere Use Cases ausführen. Ein Beispiel hierfür wäre ein Geldautomat. Dieser erfüllt meist verschiedene Funktionen. Man kann den Kontostand einsehen, man kann Geld abheben oder auch bei manchen Automaten Geld einzahlen. Je nach Ziel, dass der Akteur erreichen will, muss er unterschiedlich mit dem System interagieren. Use Cases sind in der UML, der Unified Modeling Language, definiert.

Woher kommt der Begriff “Use Case”?

Das Prinzip der Anwendungsfälle existiert bereits seit längerer Zeit. Bereits Anfang 1990 wurden diese im Softwarebereich eingesetzt, denn sie liefern eine einfache Möglichkeit, die verschiedenen Funktionalität eines Systems zu dokumentieren. Ein Anwendungsfall zeigt dabei nicht nur die Art der Funktionalität, sondern auch die Interaktion bzw. Beziehung zwischen dem Akteur und dem System.

Der genaue Ursprung liegt im Jahr 1987, wo das Prinzip von Ivar Jacobson präsentiert wurde. Dieser stellte folgende Use Case Definition in Englisch auf (A use case is a special sequene of transcations, performed by a user and a system in a dialogue). Übersetzt bedeutet diese Definition: Ein Anwendungsfall ist eine spezielle Reihenfolge an Transaktionen, die von einem Nutzer und einem System im Dialog durchgeführt werden.

Welche Arten von Use-Cases gibt es?

Man unterscheidet prinzipiell zwischen zwei Arten von Anwendungsfällen.

• Black-Box: Bei dieser Art von Use-Case wird nur dokumentiert, was das System leisten soll. Hierbei wird nicht dargestellt, wie das System diese Leistungen bereitstellen kann. In der Praxis werden diese Anwendungsfälle bevorzugt dargestellt, da diese die Ansicht von außen zeigen.

• White-Box: Bei der White-Box hingegen werden alle Schnittstellen und Komponenten dokumentiert, damit sichtbar wird, wie eine Funktionalität bereitgestellt wird.

Im Bereich der Black-Box Use-Cases wird auch noch zwischen Geschäftsanwendungsfällen (business use case) und Systemanwendungsfällen (system use case) unterschieden. Ein Geschäftsanwendungsfall wäre zum Beispiel “Essen bestellen”, während ein Systemanwendungsfall zum Beispiel “Online Essen bestellen” wäre.

Wo liegt der Unterschied zur User Story?

In vielen Fällen wird der Begriff Use-Case mit User-Story verwechselt. Hierbei gibt es jedoch eine klare Abgrenzung.

Im agilen Projektmanagement, wie zum Beispiel Extreme Programming, werden Use-Cases in einer noch knapperen Form aufgeschrieben. Da diese Darstellung wirklich sehr kurz ist, wird sie nicht mehr als Use-Case bezeichnet, sondern als User-Story.

Daher ist eine User-Story quasi eine Kurzbeschreibung eines Anwendungsfalles.

Welchen Nutzen haben Use Cases?

Eine Software wird meist entwickelt mit dem Ziel, einen Nutzen für die Kunden zu schaffen. So kann beispielsweise ein Prozess durch eine neue Software bzw. ein neues System schneller, einfacher oder sicherer gestaltet werden. Hierbei steht im Mittelpunkt vor allem der Kundennutzen.

Wenn kein eindeutiges Ziel definiert wird bzw. das Ziel unklar ist, sehen die Kunden auch keinen Nutzen an der neuen Software. Infolgedessen wird das System vom Markt nicht akzeptiert und bringt keinen Erfolg.

Gerade deshalb sind Use Cases ein sehr beliebtes und mächtiges Tool im Projektmanagement. So sollten zu Beginn die wichtigsten Anwendungsfälle definiert werden mit den jeweiligen Zielen. Dies schafft ein Gesamtbild über den Zweck der Software und dient dem Projektmanager und dem Team dazu, eine Orientierung zu haben, wie die Software gestaltet werden sollte.

Wie erstellt man einen Use Case?

Grundsätzlich besteht ein Anwendungsfall aus zwei verschiedenen Bestandteilen:

• Use Case Spezifikation

• Use Case Diagramm

Use Case Spezifikation

Eine Use Case Beschreibung liefert Informationen über die Interaktion zwischen Nutzer und System in einer natürlichen Sprache. Somit lässt sich leicht ein Überblick schaffen über die grundlegenden Informationen. 

Die Beschreibung wird meist textuell auf Basis einer Vorlage erfasst. Folgende Punkte sollten dabei im Idealfall enthalten sein:

• Name des Anwendungsfalles + Identifier

• Kurzbeschreibung

• Beteiligte Akteure

• Auslöser

• Vorbedingungen (pre-conditions)

• Normalablauf

• Alternative Abläufe, falls notwendig

• Ergebnis

• Nachbedingung (post-conditions), falls vorhanden

• Hinweise, falls notwendig

Mit einer solchen Spezifikation lassen sich mehrere Anwendungsfälle verfassen, die bei einem System möglich sind. Hierbei lässt sich erschließen, ob das Endergebnis für den Kunden nutzenbringend ist, ob der Ablauf einfach und unkompliziert ist und ob Veränderungen vorgenommen werden sollten oder nicht.

Use Case Diagramm

Im Gegensatz zu der Spezifikation ist ein Use Case Diagram eine grobe visuelle Repräsentation der verschiedenen Akteure und Beziehungen. Hierbei steht an erster Stelle, dass ein Gesamtüberblick vom zu entwickelnden System geschaffen wird. Mit einem Anwendungsfalldiagramm, auch Verhaltensdiagramm genannt, erkennt man die Anzahl der Anwendungsfälle, die dabei beteiligten Akteure und wie diese in Beziehung zueinander stehen.

Die wichtigsten Elemente in dem Diagramm sind:

• Anwendungsfälle

• Akteure

• Beziehungen

• Systemgrenzen

Use Cases sind die Möglichkeiten, mit dem System zu interagieren, und Akteure sind die Nutzer, die in Interaktion mit dem System stehen. Wie man diese grafisch abbildet, bleibt jedem Projektleiter selbst überlassen. Oft werden die Akteure im Diagramm durch Strichmännchen abgebildet.

Um als Projektmanager ein erfolgreiches Use-Case-Diagramm erstellen zu können, müssen Sie aber auch die verschiedenen Beziehungen verstehen. Anwendungsfälle und Akteure stehen in einer bestimmten Beziehung zueinander. Meist wird dies durch eine einfache Linie ersichtlich.

Für detaillierte Angaben kann man hier auch eine Navigationsangabe geben mittels eines Pfeils. Hierbei wird angegeben, wer in dieser Beziehung der Initiator ist. Wenn also der Pfeil vom Akteur zum Anwendungsfall geht, dann ist der Akteur der aktive Teil dieser Beziehung und stößt die Kommunikation an.

Es gibt drei verschiedene Beziehungen:

• Die Include-Beziehung: HIerbei wird ein Anwendungsfall in einen anderen Fall eingebunden. Dies kann beispielsweise die PIN-Abfrage beim Geld abheben sein.

• Die Erweiterungsbeziehung: Hier wird ein Anwendungsfall unter bestimmten Umständen durch einen anderen Fall erweitert. Dies kann man mit einem Erweiterungspunkt kennzeichnen. Ein Beispiel wäre hier das Ausdrucken einer Quittung bei der Behebung von Bargeld.

• Spezialisierungs- und Generalisierungsbeziehung: Hier wird ein allgemeiner Anwendungsfall durch spezifische Use Cases detaillierter ausgeführt. Ein Beispiel wäre die Entsperrung vom eigenen Smartphone. Während die Entsperrung allgemein ist, ist die Authentifizierung mittels PIN oder Fingerabdruck spezifischer.

Der Prozess der Erstellung von Use Cases

Um einen Anwendungsfall erstellen zu können, müssen Sie als Projektmanager alle notwendigen Informationen vorliegen haben. Dazu ist es notwendig, so viele Mitarbeiter wie möglich in die Erstellung miteinzubeziehen wie notwendig. Denken Sie daran: Es ist zwar wichtig, alle Informationen zu haben, trotzdem sollten die Use Case Beschreibung und das Use Case Diagramm nur die wichtigsten Informationen beinhalten.

Wenn es um das Sammeln der Informationen geht, sollten die wichtigsten Punkte zu den Akteuren, den Vor- und Nachbedingungen, den eigentlichen Abläufen und den wichtigsten Beziehungen im Meeting gesammelt werden.

Zu den Akteuren sollten Sie sich nicht nur überlegen, welche Akteure in Interaktion mit dem System stehen. Es ist darüber hinaus auch wichtig, welches Ziel diese Akteure verfolgen.

Zu den Vor- und Nachbedingungen sollten Sie sich fragen, welche Bedingungen zu Beginn und zum Schluss erfüllt sein müssen. Dazu ist auch der Zustand wichtig, in welchem sich das System zu der gegebenen Zeit befinden sollte.

Beim Ablauf ist es wichtig herauszufinden, wie der Akteur mit dem System interagiert, also welche Schritte in welcher Reihenfolge stattfinden. Zudem ist es auch wichtig, Informationen über alternative Abläufe zu sammeln bzw. was passiert, wenn Fehler während dem Ablauf stattfinden.

Ansonsten ist es noch wichtig herauszufinden, wie oft ein gewisser Arbeitsablauf stattfindet. So können Sie herausfinden, welchem Anwendungsfall Sie mehr Aufmerksamkeit bei der Softwareentwicklung schenken müssen.

Welche Vorteile haben Use Cases?

Use Cases können dem Projektteam einer Software auf unterschiedlichste Art und Weise nützlich sein:

• Einfach zu erstellen: Die Erstellung ist nicht sehr kompliziert. Es ist einfach, die verschiedenen Akteure und Anwendungsfälle zu dokumentieren und grafisch in Beziehung zueinander zu stellen.

• Gute Gesamtübersicht: Use Cases bestehen aus der Spezifikation und dem Diagramm. Somit bekommt man nicht nur einen Gesamtüberblick über die Software und die verschiedenen Anwendungsfälle, man bekommt auch detaillierte Informationen zu den einzelnen Use Cases, wenn man diese benötigt.

• Orientierung: Zudem dienen sie auch hervorragend zur Orientierung. So weiß das Team, welche Anforderungen an das System gestellt werden und wie diese erfüllt werden können.

• Ableitung von weiteren Informationen: Aus den Use-Cases und den Zielen der Akteure lassen sich funktionale Anforderungen sowie Testfälle (test cases) ableiten.

Was ist ein Use Case 2.0?

Use Cases sind sehr nützlich, da sie eine gute Gesamtübersicht verschaffen und einfach in der Erstellung sind. Oftmals sind Anwendungsfälle jedoch sehr groß, wodurch Sie nicht mittels agilem Projektmanagement innerhalb kurzer Sprints durchgeführt werden können.

Der Gründer von Use Cases, Ivar Jacobson, stellte dazu 2011 seine Lösung vor: Use Case 2.0. Das Prinzip dahinter ist sehr einfach erklärt. Gerade bei großen Anwendungsfällen werden diese quasi in Scheiben geteilt, man spricht hier auch von Use Case Slices. Diese Teile können dann innerhalb eines Sprints realisiert werden. So bekommt man auch schneller Feedback und kann die restlichen Sprints dementsprechend anpassen.

Wie lassen sich Use Cases ins Projektmanagement integrieren?

Use Cases dienen zur Visualisierung und Beschreibung der verschiedenen Interaktionen zwischen Akteur und System. Man kann diese jedoch hervorragend nutzen, um auch konkrete Pläne zur Umsetzung zu gestalten. Dazu kann man die Anwendungsfälle in sogenannte Slices zerschneiden, welche innerhalb eines Sprints realisiert werden können. 

Ein Sprint ist ein essentieller Bestandteil von Scrum, einer Methode des agilen Projektmanagements. Die agile Methode zeichnet sich vor allem dadurch aus, dass schnell und effizient auf Veränderungen reagiert werden kann. Zur Hilfe für agiles Projektmanagement eignen sich hervorragend Tools wie Asana. Asana hilft dabei Projekte und Prozess digital abzubilden, wodurch ein zentraler Ort für alle wichtigen Informationen geschaffen wird.