Use-Case: Anwendungsfälle und Aufgaben

Die Funktionalität einer Software oder Webseite gegenüber der Außenwelt wird in Use-Cases erfasst. Diese beschreiben sachlich und präzise, was in funktionaler Hinsicht geschieht. Ein Webshop beispielsweise enthält mehrere Use-Cases, die teilweise ineinander verschachtelt sind:

• Nutzer informieren sich über Produkte: Suchen, durch Kategorien stöbern, Detailinformationen aufrufen, mehrere Produkte vergleichen
• Nutzer bestellen Produkte: legen diese in den Warenkorb, ändern deren Menge, merken Produkte zum Bestellen auf einer Merkliste vor
• Nutzer legen ein Kundenkonto an: separat oder während der Bestellung, ggf. mit Zusatzfunktionen, wenn sie bestimmte Kriterien erfüllen (z.B. Privat- oder Firmenkunde)
• Nutzer bewerten Produkte: mit Sternchen, mit Text, kommentieren oder empfehlen andere Bewertungen

Jeder Use-Case besteht meist aus mehreren Anwendungsfällen. Jeder Anwendungsfall ist in sich abgeschlossen. Der Anwendungsfall „nach Produkten suchen“ ist sehr kurz: Besucher trägt in das Suchformular eine Suchphrase ein und erhält geeignete Suchergebnisse aufgelistet. In der Schriftform behandeln Anwendungsfälle das System wie eine Black Box und schweigen sich über konkrete Funktionsweisen oder Algorithmen aus; es werden nur die Momente angegeben, in denen eine Nutzer-Interaktion erfolgt (als Ein- oder Ausgabe). Ein- oder Ausgaben werden nur inhaltlich spezifiziert. Ein Anwendungsfall schildert den Ablauf und Informationsfluss, nicht die konkrete fertige Lösung.

Abstrakt umfasst ein Anwendungsfall folgende vier Schritte:

1. Auslösen des Use-Cases, entweder durch Aufrufen einer Funktion oder implizit durch Beginn der Nutzung
2. Eingaben des Nutzers (Aktionen), das können Tastatureingaben, Cursor- oder Fingerbewegungen und Klicks bzw. Taps sein, eben alle Nutzer-Aktionen
3. Ausgaben des Systems (Reaktionen), das können Bildschirmausgaben, Ergebnisse, Auswirkungen, Anzeigen o.ä. sein, eben alle Reaktionen des Systems auf die Nutzer-Aktionen
4. Ende des Use-Cases, entweder durch erlebbaren Abschluss oder implizit durch Erreichen des Ziels

In der agilen Entwicklung werden häufig nicht sämtliche möglichen Ein- und Ausgaben ausspezifiziert, sondern nur die Hauptfälle. Die übrigen (beispielsweise Fehlerbehandlung) werden erst während der Entwicklung detailliert. Der Anwendungsfall definiert das zu erreichende Ergebnis und bildet entweder allein oder als Anwendungsfall-Sammlung oder Use-Case-Sammlung das Projekt-Ziel. Für die Nutzer beispielsweise der Suche ist es egal, welche Suchtechnologie im Hintergrund zum Einsatz kommt – nur das Suchergebnis ist für diese entscheidend. Damit das Projekt-Team die passende wählen kann, muss in diesem Beispiel also eine sehr umfangreiche und relevante Anwendungsfall-Liste erstellt werden. Aus dieser destilliert das Entwickler-Team die Anforderungen an die verwendete Technologie.

Verkürzt definiert der Anwendungsfall bzw. Use-Case nur was erreicht wird – aber schweigt sich darüber aus, wie es erreicht wird. Entweder wird das im Rahmen des Projektes erarbeitet oder ist durch frühere Entscheidungen (beispielsweise für eine Suchtechnologie) bereits vorgegeben. Der Detailgrad solcher Anwendungsfälle bzw. Use-Cases wird in jedem Projekt zwischen den Umsetzern und Anforderern ausgehandelt und hängt von der jeweiligen Vertrautheit beider Parteien mit den Aufgaben und Zielen der jeweils anderen ab. Personas können dabei eine gute Ausgangslage bilden, da sie für alle Beteiligten ein gemeinsames Verständnis bilden.

Im Projekt-Alltag werden Anwendungsfälle häufig von Skizzen, Entwürfen, Mock-ups, Algorithmen oder anderen Dokumenten begleitet, die bestimmte Aspekte verdeutlichen. Wie beispielsweise die konkrete Suchergebnisseite aussieht, ist beispielsweise Aufgabe eines Designers in Absprache mit anderen Fachabteilungen. Der Anwendungsfall dient somit auch Nicht-Entwicklern dazu, benötigte Zuarbeit zu leisten, bzw. der Projektleiter kann anhand des Anwendungsfalls die jeweiligen Fachabteilungen mit der Zuarbeit beauftragen. Dazu gehören neben dem Design der Suchergebnisseite auch die Verständigung, welche Art von Ergebnissen in welcher Weise angezeigt werden soll, ob Produkte beispielsweise mit Preis und Verfügbarkeit ausgegeben werden oder nur als Name und Bild. Ob und wie Produktkategorien oder andere Shop-Inhalte ebenfalls als Suchergebnis erscheinen sollen. Der größte Aufwand dürfte die Verständigung über „geeignete Suchergebnisse“ sein. Aus dieser Klärung ergeben sich Anforderungen an den Suchalgorithmus oder die verwendete Suchtechnologie.

Aus der Definition eines Anforderungsfalls resultieren weitere Entscheidungen, die festgehalten werden: Ein Besucher ruft die Produktbewertung auf, dabei kann er das Produkt mit 0 bis 5 Sternen bewerten und eine Textbewertung abgeben (entweder beides oder eines von beidem); angemeldete Besucher können den Namen pseudonymisieren, nicht-angemeldete Besucher tragen einen Namen ein, der bei der Bewertung angezeigt wird. Je stärker man in die Materie eintaucht, desto mehr Entscheidungen sind zu treffen. Dabei beschleunigt die agile Software-Entwicklung, bei der Entwickler und Nutzer eng zusammenarbeiten, die Entscheidungen – diese werden beim Anwendungsfall dokumentiert. Die textliche Beschreibung wird durch das Design der Bewertungsabgabe begleitet, und die Textausgaben für den Nutzer werden formuliert.

Während Anwendungsfälle funktionale Anforderungen beschreiben, müssen Entwickler und andere in die Umsetzung involvierte Personen auch nicht-funktionale Anforderungen berücksichtigen. Dazu zählen beispielsweise eine maximale Reaktionszeit, technische Ressourcen, vorhandene Technologien, Budgetgrenzen und im Fall der Suche der entstehende Pflegeaufwand für die Suchdatenbasis.

Mitunter besteht ein Softwareprojekt nur aus einem Use-Case. Dann ist besonders zu prüfen, ob spätere Anwendungsfälle mit vertretbarem Aufwand integriert werden können. Oft fehlt die Verständigung, ob und welche plausiblen Anwendungsfälle nicht integriert werden, Use-Cases werden vergessen, die in der näheren Zukunft integriert werden sollen. Sind diese nicht zu Anfang bekannt, können technische oder andere Faktoren deren Umsetzung verhindern. Beispielsweise könnte ein Bedienmodell oder -konzept, das präzise auf den einen Use-Case zugeschnitten ist, bei einer Erweiterung die ursprünglich effiziente Bedienung in ihr Gegenteil verkehren. Die Grenzen jedes Projekts werden für Software und Webseite bewusst sowohl positiv als auch negativ gezogen: Was kann und bietet die Software oder Webseite, was wird sie später auch können – und was kann oder bietet sie bewusst nicht.

Autor: Alexander Florin bei LinkedIn