Anwendungsfall

Ein Anwendungsfall, auch im Deutschen eher unter dem englischen Ausdruck use case bekannt, definiert die Interaktionen zwischen Akteuren und dem betrachteten System, die stattfinden, um ein bestimmtes fachliches Ziel (engl. business goal) zu erreichen. Anwendungsfälle beschreiben immer nur genau einen Ablauf oder einen Prozess.

Anwendungsfälle werden oft mit Geschäftsprozessen verwechselt, allerdings beinhalten Geschäftsprozesse auch Aktionen, Personen, Rollen oder Ressourcen, die nicht Teil des zu modellierenden Systems sind.

"Ein Use Case beschreibt eine abgeschlossene, ununterbrochene Abfolge von Aktionen eines Akteurs am System mit Ergebnis von fachlichem Wert"

Die Granularität kann verschieden sein. Auf sehr hohem Niveau beschreibt ein Anwendungsfall lediglich sehr grob und abstrakt, was passiert. Die Technik des Anwendungsfall-Schreibens kann jedoch bis auf Ebene von IT-Prozessen verfeinert werden, sodass das Verhalten einer Anwendung detailliert beschrieben wird. Dies widerspricht der ursprünglichen Intention von Use Cases, ist aber manchmal zweckmäßig.

Anwendungsfälle wurden bereits vor Etablierung der UML eingesetzt. Zusammenhängende Anwendungsfälle können in einem Anwendungsfalldiagramm dargestellt werden.

Aufbau eines Anwendungsfalls

Der Aufbau eines Anwendungsfalls kann etwa so aussehen:

Name und Identifier: Anwendungsfälle haben einen Namen und werden nach Sachgruppen geordnet durchnummeriert, z.B. UC 2.01.
Beschreibung (description): Hier erfolgt eine kurze Beschreibung, was im Anwendungsfall passiert. Kurz bedeutet, dass es zwei oder drei Zeilen sind, selten mehr.
Beteiligte Akteure (actors): Akteure sind beteiligte Personen oder Systeme. Z.B. Anwender, eingeloggter Anwender, Kunde, System, Abrechnungsprozess. Die Akteure werden zuvor in einem eigenen Abschnitt dargestellt.
Status: Der Status sagt aus, wie weit die Arbeit an dem Anwendungsfall gediehen ist. In Arbeit, bereit zum Review, im Review abgelehnt und abgenommen sind die üblichen Status.
Verwendete Anwendungsfälle (includes): Wenn der Anwendungsfall auf andere Anwendungsfälle zurückgreift, werden diese anderen Fälle hier aufgezählt. Aufzuzählen sind Name und Identifikationsnummer. Ggf. ist es eine gute Idee, den Verweis interaktiv zu gestalten, d.h. einen Link (bzw. interaktiven Querverweis) einzufügen.
Auslöser (rationale): Der Grund bzw. die Gründe dafür, dass dieser Anwendungsfall ausgeführt wird.
Vorbedingungen (preconditions): Alle Bedingungen, die erfüllt sein müssen, damit dieser Anwendungsfall ausgeführt werden kann. Gibt es keine Vorbedingungen, so steht hier "keine".
Nachbedingung / Ergebnis (postconditions): Das Ergebnis, das nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet wird.
Ablaufschritte (normal flow): Hier wird der eigentliche normale Ablauf dargestellt. Mit normal ist der Geradeausflug gemeint, also der Idealfall bzw. häufigste reguläre Ablauf. Die Ablaufschritte werden nummeriert und meist in strukturiertem Deutsch bzw. Englisch beschrieben. Ablaufpläne können jedoch ebenfalls benutzt werden, wenn es angebracht erscheint. Mittels der UML können diese Ablaufschritte in Aktivitätsdiagrammen oder Anwendungsfall-orientierten Sequenzdiagrammen dargestellt werden.
Alternative Ablaufschritte (alternative flow): Dies sind Abläufe außerhalb des Geradeausflugs. Sie stellen Abweichungen oder Verzweigungen der normalen Ablaufschritte dar.
Ausnahmen (exceptions): Dies sind die harten Ausnahmen, die allerdings noch immer auf fachlicher Ebene formuliert werden. Anstatt z.B. zu schreiben "Datenbank nicht verfügbar", wird eher "Kundenobjekt nicht verfügbar" geschrieben.
Erweiterungspunkte (extensions): Diese ermöglichen die Formulierung von Erweiterungen der Funktionalität eines Anwendungsfalles unter bestimmten Bedingungen. Beim Eintreten der jeweiligen Bedingung wird dann die Funktionalität eines weiteren Anwendungfalles in Anspruch genommen (der natürlich ebenfalls modelliert sein muss).
Hinweise: kurze Erklärungen zum besseren Verständnis, Hinweise zu Nebeneffekten, Mengengerüsten soweit erforderlich und alles andere, das nicht weiter oben dargestellt werden kann.
Änderungsgeschichte (use case history): Versionierung, Name des Autors, Datum

Methodische Hinweise

Ein Anwendungsfall beschreibt die Serie von Interaktionen zwischen Nutzer und System, die notwendig sind, ein fachliches Ziel des Nutzers zu verwirklichen. Dabei dürfen die beschriebenen Abläufe nicht zu komplex werden. Als Anhaltspunkt kann der von Cockburn beschriebene Kaffeepausen-Test dienen: solange der Anwendungsfall nicht zu komplex ist, wird die Frage „Würde der Nutzer während der Interaktionen eine Kaffeepause einlegen?“ mit "Nein" beantwortet.

Literatur

Alistair Cockburn: Use Cases effektiv erstellen. MITP Verlag, 2003 ISBN 3-8266-1344-9
Daryl Kulak, Eamonn Guiney: Use cases: requirements in context. 2. Auflage. ACM Press, New York 2004, ISBN 0-201-65767-8
Kurt Bittner, Ian Spence: Use Case Modeling". Addison-Wesley Pearson Education, Boston 2003, ISBN 0-201-70913-9