Defintion „Anwendungsfall“ Was ist ein Use Case?

Ein System ist nie ganz geschlossen, denn es wird von Akteuren benutzt, um Ziele zu erreichen. Use Cases, auch als Anwendungsfälle bekannt, verdeutlichen diese grundlegende Interaktion mit Informationstechnik.

In der Softwareentwicklung wird der Begriff Use Case immer dann genutzt, wenn beschrieben werden soll, wie ein System mit einem externen Input umgeht. Hierbei handelt es sich während der Entwicklungsphase um potenzielle Szenarien, ein solcher Anwendungsfall soll verdeutlichen, wie ein System reagiert, wenn es von User einen bestimmten Input erhält.

Dabei ist nicht ganz eindeutig geregelt, wie granular die Beschreibung eines Use Cases tatsächlich erfolgen sollte. Vielmehr muss unterschieden werden, ob es sich um gröbere oder detailliertere Use Cases handelt, die exemplarisch dargestellt werden sollen.

In der Regel wird in der Softwareentwicklung eher mit granulareren Use Cases gearbeitet als bei der Systementwicklung oder dem Projektmanagement – bei letzteren beiden Beispielen geht es häufig um globale Ziele oder Business Goals der Stakeholder, Softwareentwicklung nutzt hingegen eher präzise Inputs und klar definierte Ziele.

Dass der Begriff Use Case nicht nur in der Softwareentwicklung gebraucht wird, sondern generell in der Projektplanung zum Einsatz kommt, verdeutlicht die Logik hinter dem Aufbau der Diagramme und Beispiele.

Was genau ist ein Use Case und welche Begriffe sind wichtig?

Um zu verstehen, wie ein Use Case genau strukturiert ist, müssen die drei Elemente aus dem Anwendungsfall klar definiert werden.

• Actor (Akteur) – die ausführende Entität des Use Cases. Hierbei kann es sich generisch um User*innen handeln, es könnte aber auch eine spezifische Persona oder aber eine Gruppe (registrierte Newsletterabonnent*innen) genutzt werden. Auch andere Systeme als das im Use Case beschrieben System können Actors sein.

• System – der Prozess, der benötigt wird, um das vom Actor gewünschte Ergebnis zu erzielen.

• Goal (Ziel) – die Beschreibung des gewünschten Ziels.

Ein kurzes Beispiel verdeutlich den Anwendungsfall am besten: Eine iPhone-Benutzerin (Actor) möchte innerhalb von WhatsApp (System) ein Bild an eine Gruppe verschicken (Goal). Das System kann hierbei auf verschiedene Stufen heruntergebrochen werden, um den Prozess klarer wiederzugeben und die einzelnen Schritte zu verdeutlichen.

Use Cases in Unified Modelling Language darstellen

Anhand der Beschreibung lässt sich nun klar feststellen, dass ein Use Case eine sehr grundlegende Beschreibung eines Anwendungsfalles ist und Kürze wichtiger ist als Tiefe. Entsprechend erfolgt die Darstellung als Diagramm in UML (Unified Modelling Language), diese ist einfach zu lesen und (auch ohne tiefere Kenntnisse in visueller Kommunikation oder Grafikdesign) einfach aufzuzeichnen.

• Actors werden zumeist als Strichmännchen dargestellt, wenn es sich bei ihnen um ausführende Personen handelt. Sind die Actors andere Systeme oder Organisationen, so können auch Logos zum Einsatz kommen.

• Ein Use Case wird als kurzer Textschnipsel in einem Oval wiedergegeben und die Beziehung von Actors und Use Cases erfolgt über Pfeile. Systeme und Subsysteme fassen dabei Use Cases als Rechtecke zusammen.

• Ein System wie ein Online-Shop würde als Use Cases wie Waren einkaufen, Waren reklamieren oder den Bezahlvorgang beinhalten, sie alle würden von Kunden und Kundinnen als Actors ausgehen.

• Der Bezahlvorgang würde dann an andere Actors wie PayPal oder einen Kreditkarten-Log-In weiterleiten.

All dies wäre als UML-Diagramm dargestellt, das Diagramm fasst dabei in der Regel mehrere Use Cases eines Systems zusammen. Hier müssen Kompromisse zwischen Lesbarkeit und Umfang des dargestellten Szenarios gefunden werden.

Use Case 2.0 – die agile und skalierbare Form des Use Cases

Während der Use Case in UML eine beliebte und wichtige Möglichkeit ist, um die Nutzbarkeit eines Systems durch Akteure darzustellen, lässt diese dennoch die Skalierbarkeit und die Dynamik eines agilen Modells vermissen. 2011 wurde der Use Case durch den Use Case 2.0 erweitert, diese Praxis geht auf Ian Spence, Ivar Jacobson und Kurt Bittner zurück.

Der Use Case 2.0 spezifiziert die Darstellung für (vorrangig) die Softwareentwicklung sowie andere Systeme als leicht, skalierbar, vielseitig und einfach zu nutzen. Um den Use Case in agile Modelle zu implementieren, sollten Entwicklerinnen und Entwickler sowie das Projektmanagement einige Punkte beachten:

Storytelling: Der Use Case 2.0 nutzt Stories, um ein System mit jedem einzelnen Anwendungsfall klarer zu umreißen. Die Geschichten machen die Ziele der Akteure verständlicher.

The Big Picture: Um den Use Case 2.0 klar zu umreißen, muss das System als Ganzes betrachtet werden, um das Erreichen unterschiedlichster Ziele zu gewährleisten.

Value: Ein System hat nur dann einen Mehrwert, wenn es genutzt wird. Der Value-Aspekt fokussiert ein System auf die Ziele, die Akteure tatsächlich damit erreichen wollen.

Slices: Slices (Scheibchen) teilen ein System in Subsysteme auf und beginnen mit dem für die Akteure nützlichsten. Jede Slice kann dabei in einem Sprint fertiggestellt werden.

Increments: Systeme sollten in inkrementellen Updates produziert werden und Qualität, Funktionalität und Features des letzten Inkrements optimieren. Der Use Case 2.0 nutzt Slices und Increments, um von Release zu Release eine funktionierende und verbesserte Version zu erhalten.

Team Needs: Auch die Darstellung von Use Cases muss ich an das zur Verfügung stehende Team adaptieren. Teamgröße, Kollaboration und Mittel definieren den Umgang mit der Komplexität von Use Cases.

Use Cases als Überblick

Wie genau ein System sich in welchen Anwendungsfällen verhält und welche Use Cases von einem System zur Erreichung welcher Ziele bedient werden, sollte in der Entwicklung unbedingt veranschaulicht werden. Bereits in Planung und Entwicklung lassen sich die Anforderungen an ein System so besser verdeutlichen und gewichten – auch für externe Stakeholder ist der Anwendungsfall in UML ein wertvoller Einblick in die Arbeit eines Systems.

(ID:47962324)