imported>Till.niermann: /* Use Case 2.0 */

2025-10-20T12:10:08Z

Use Case 2.0

Neue Seite

{{Dieser Artikel|behandelt den Anwendungsfall der Softwaretechnik. Zum Anwendungsfall als Diagrammelement siehe [[Anwendungsfall (UML)]].}}

[[Datei:Uml-UseCase-Beispiel3.svg|mini|hochkant=1.5|Beispiel eines [[Anwendungsfalldiagramm]]s in der [[Unified Modeling Language]]. Die beiden Anwendungsfälle <code>SMS verschicken</code> und <code>Fotomessage verschicken</code> eines <code>Mobilfunkbetreibers</code> sind spezifiziert.]]
[[Datei:Cockburnstyle use cases.svg|mini|Hierarchie von Anwendungsfällen im Cockburn-Stil]]

Ein '''Anwendungsfall''' ({{enS|use case}}) bündelt alle möglichen Szenarien, die eintreten können, wenn ein [[Akteur]] versucht, mithilfe des betrachteten Systems ein bestimmtes fachliches Ziel ({{enS|business goal}}) zu erreichen. Er beschreibt, was inhaltlich bei dem Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen. Das Ergebnis des Anwendungsfalls kann ein Erfolg oder Fehlschlag/Abbruch sein.

== Allgemeines ==
Anwendungsfälle werden typischerweise so benannt, wie die Ziele aus Sicht der Akteure heißen: ''Mitglied anmelden'', ''Geld abheben'', ''Auto zurückgeben''.

Die Granularität von Anwendungsfällen kann stark variieren. Ein Anwendungsfall beschreibt auf hohem Niveau grob und abstrakt, was passiert. Die Technik des Anwendungsfallschreibens kann jedoch bis auf die Ebene von IT-Prozessen verfeinert werden, um das Verhalten einer Anwendung detailliert wiederzugeben. Dies widerspricht zwar der ursprünglichen Intention von Use Cases, kann aber in manchen Fällen zweckmäßig sein.

Anwendungsfall und [[Geschäftsprozess]] werden oft ungenau voneinander abgegrenzt. Der Bezug zur [[Systemtheorie]] zeigt jedoch, dass Anwendungsfälle und Geschäftsprozesse jeweils eine andere Sicht auf das zu modellierende System darstellen:
* ''Anwendungsfälle'' beschreiben, was die Umwelt vom System erwartet.
* Ein ''[[Geschäftsprozess]]'' beschreibt eine Folge von Einzeltätigkeiten, die schrittweise ausgeführt werden, um ein geschäftliches oder betriebliches Ziel zu erreichen.
Diese Abgrenzung gilt unabhängig von der Art des zu modellierenden Systems für Unternehmen und Software gleichermaßen. Sie ist nicht mit der Unterscheidung zwischen [[White-Box-Test|White-Box-]] und [[Black-Box-Test|Black-Box-Modellierung]] gleichzusetzen.

Die Begriffe Geschäftsanwendungsfall ({{enS|business use case}}) und Systemanwendungsfall ({{enS|system use case}}) hingegen beschreiben den inhaltlichen Umfang des betrachteten Systems:
* Bei einem ''Systemanwendungsfall'' ist der inhaltliche Umfang durch das zu entwickelnde System gesetzt.
* Bei einem ''Geschäftsanwendungsfall'' ist der inhaltliche Umfang durch eine organisatorische Einheit gesetzt, beispielsweise eine Firma oder Abteilung.
Üblicherweise werden Geschäftsanwendungsfälle dafür genutzt, die Systemanwendungsfälle in einen gemeinsamen Kontext einzubetten und weitere Anforderungen aufzudecken.

Anwendungsfälle wurden bereits vor Etablierung der [[Unified Modeling Language|UML]] eingesetzt. Zusammenhängende Anwendungsfälle können in einem [[Anwendungsfalldiagramm]] dargestellt werden. Häufig wird mit diesem auch ein [[Kontextdiagramm|Systemkontextdiagramm]] erstellt.

== Aufbau eines Anwendungsfalls ==
Der inhaltliche Aufbau eines Anwendungsfalls erfolgt meist mittels einer zu definierenden Vorlage. Diese wird abhängig vom Kontext der späteren Benutzung des Anwendungsfalls ausgearbeitet. Oft werden für die verschiedenen Analysephasen unterschiedlich stark formalisierte Vorlagen verwendet. Die Bandbreite reicht von der rein [[Prosa|prosaischen]] Kurzbeschreibung bis zu einem vollständigen, ausgearbeiteten Anwendungsfall.

Exemplarisch soll hier eine Schablone nach [[Alistair Cockburn|Cockburn]] vorgestellt werden:
; Name und Identifikationsnummer
: 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 außerhalb (!) des beschriebenen Systems. Z. B. Anwender, angemeldeter Anwender, [[Kunde]], System, Abrechnungsprozess. Die Akteure werden zuvor in einem eigenen Abschnitt dargestellt. Jacobson unterscheidet zwei Arten von Akteuren: ''Primäre Akteure'' sind die eigentlichen Benutzer des Systems. Neben diesen gibt es noch ''sekundäre Akteure'' (auch: „unterstützende Akteure“), die das System überwachen, warten und den Primärakteur bei seiner Zielerreichung unterstützen.<ref name="Jacobson" />
; Status
: Der Status sagt aus, wie weit die Arbeit an dem Anwendungsfall gediehen ist. In Arbeit, bereit zum [[Review (Softwaretest)|Review]], im Review, abgelehnt und abgenommen sind Beispiele.
; Verwendete Anwendungsfälle ''(includes)''
: Wenn der Anwendungsfall auf andere Anwendungsfälle zurückgreift, werden diese Fälle hier aufgezählt. Zu nennen sind Name und Identifikationsnummer.
; Auslöser ''(rationale'' oder ''trigger)''
: Der fachliche Grund oder 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“.
; Invarianten
: Alle Bedingungen, die innerhalb und durch den Anwendungsfall nicht verändert werden dürfen. Diese müssen auch in einem [[Erfolg|Misserfolg]]s- oder Fehlerszenario immer noch gewährleistet werden können.
; Nachbedingung/Ergebnis ''(postconditions)''
: Der Zustand, der nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet wird.
; Standardablauf ''(normal flow)''
: Hier wird das typische Szenario dargestellt, das leicht zu verstehen oder der am häufigsten vorkommende Fall ist. An seinem Ende steht die Zielerreichung des Primärakteurs. Die Ablaufschritte werden nummeriert und meist in strukturierter Sprache beschrieben. Ablaufpläne können jedoch ebenfalls benutzt werden, wenn es angebracht erscheint. Mit der [[Unified Modeling Language|UML]] können diese Ablaufschritte in [[Aktivitätsdiagramm]]en oder anwendungsfallorientierten [[Sequenzdiagramm]]en dargestellt werden.
; Alternative Ablaufschritte ''(alternative flow)''
: Dies sind Szenarien, die sich außerhalb des Standardablaufs auch bei der (versuchten) Zielerreichung des Anwendungsfalls ereignen können. Sie werden meistens als konditionale Verzweigungen der normalen Ablaufschritte dargestellt. An ihrem Ende steht ein Misserfolg, die Zielerreichung des Primärakteurs oder eine Rückkehr zum Standardablauf.
; 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 ==
{{Überarbeiten}}
Ein Anwendungsfall beschreibt die Interaktionen zwischen Nutzer und System, die notwendig sind, um ''ein'' fachliches Ziel des Nutzers zu verwirklichen. Dabei dürfen die beschriebenen Abläufe nicht zu komplex werden. Als Anhaltspunkt kann der von [[Alistair Cockburn]] beschriebene Kaffeepausen-Test dienen: Der Anwendungsfall ist zu komplex, wenn „der Nutzer während der Interaktionen eine Kaffeepause einlegen“ würde.

== Abgrenzung zur User Story ==
In der agilen Softwareentwicklung, ursprünglich speziell im [[Extreme Programming|Extreme Programming (XP)]], werden Use Cases aufgrund der organisatorischen Besonderheiten in einer noch knapperen Form verfasst. Aufgrund dieser kürzeren Darstellungsform tragen sie nicht die Bezeichnung Use Case, sondern werden als [[User Story]] bezeichnet. Eine User Story in XP ähnelt eher der Kurzbeschreibung eines klassischen Use Cases.<ref>Cockburn: ''Use Cases effektiv erstellen''. mitp, Bonn 2003, S. 231.</ref>

== Use Case 2.0 ==
Im Dezember 2011 veröffentlichten Ivar Jacobson, Ian Spence und Kurt Bittner das Konzept ''Use Case 2.0''.<ref>{{Internetquelle |url=https://www.ivarjacobson.com/publications/white-papers/use-case-20-e-book |titel=Use-Case 2.0 – The Guide to Succeeding with Use Cases |werk=ivarjacobson.com |datum=2014-07-21 |sprache=en |abruf=2023-07-06 |format=E-Book}}</ref> Es beschreibt eine skalierbare, [[Agile Softwareentwicklung|agile]] Technik zur Entwicklung von Anforderungen, mit denen die inkrementelle Systementwicklung gesteuert werden kann. Die Prinzipien des neuen Konzeptes sind:
* Beschreibe Dinge einfach – mit Geschichten („stories“),
* Verstehe das „Big Picture“,
* Stelle den Nutzen in den Mittelpunkt,
* Baue das System scheibchenweise („in slices“),
* Liefere das System in Inkrementen,
* Passe dich den Bedürfnissen des Teams an.

Die [[Problemlösen|Problemlösung]] für agile [[Projektplanung]] mit Use Cases liefert die Technik des „Slicings“ – dem Aufschneiden eines Use Cases in kleinere Einheiten, die dann innerhalb eines [[Scrum#Sprint|Sprints]] realisiert werden können.

== Weiterführende Themen ==
* Mit der [[Robustheitsanalyse]] können spezielle Eigenschaften der Use Cases untersucht werden.

== Literatur ==
* Kurt Bittner, Ian Spence: ''Use Case Modeling''. Addison-Wesley Pearson Education, Boston 2003, ISBN 0-201-70913-9.
* [[Alistair Cockburn]]: ''Use Cases effektiv erstellen''. MITP, Bonn 2003, ISBN 3-8266-1344-9.
* {{Literatur
|Autor=[[Ivar Jacobson]] u. a.
|Titel=Object-Oriented Software Engineering
|Verlag=Addison-Wesley
|Ort=Wokingham UK
|Datum=1993
|ISBN=0-201-54435-0}}
* {{Literatur
|Autor=Christoph Kecher
|Titel=UML 2.0, Das umfassende Handbuch
|Verlag=Galileo Computing
|Datum=2006
|ISBN=3-89842-738-2}}
* Daryl Kulak, Eamonn Guiney: ''Use cases: requirements in context''. 2. Auflage. ACM Press, New York 2004, ISBN 0-201-65767-8.
* Robert Morys: [https://af3.fortiss.org/attachments/19/Morys2010.pdf ''Metrikbasierte Qualitätsmodellierung von Use-Case-basierten Anforderungsspezifikationen''.] (PDF; 1,5 MB) Diplomarbeit RWTH Aachen; abgerufen im Oktober 2012.
* {{Literatur
|Autor=Doug Rosenberg
|Titel=Use Case Driven Object Modeling with UML – Theory and Practice
|Verlag=Apress U.S.A
|Datum=2007
|ISBN=978-1-59059-774-3}}
* Chris Rupp und die SOPHISTen: ''Requirements-Engineering und Management – Professionelle Iterative Anforderungs-Analyse für die Praxis''. 6. Auflage. Hanser, München 2014, ISBN 978-3-446-43893-4.
* Hartmut Umbach, Pierre Metz: ''Use Cases vs. Geschäftsprozesse''. In: ''Informatik-Spektrum'', 2006, 29, Nr. 6, S. 424–432; [[doi:10.1007/s00287-006-0106-8]].

== Weblinks ==
* ''[[b:Software Engineering: Use Case Diagramm|Use Case Diagramme]]''. [[Wikibooks]].
* [http://www.ivarjacobson.com/uploadedFiles/Pages/Knowledge_Centre/Resources/White_Paper/Resources/IJI_Use-Case2.0.pdf Einführungs-Guide zu Use Case 2.0.] (PDF) ivarjacobson.com (englisch).
* [https://www.heise.de/developer/artikel/Use-Case-2-0-Agile-Projektplanung-mit-Use-Case-Slices-2535642.html ''Use Case 2.0: Agile Projektplanung mit Use Case Slices''.] heise.de

== Einzelnachweise ==
<references>
<ref name="Jacobson">
{{Literatur
|Autor=Ivar Jacobson u. a.
|Titel=Actors
|Sammelwerk=Object-Oriented Software Engineering
|Verlag=Addison-Wesley
|Ort=Wokingham UK
|Datum=1993
|ISBN=0-201-54435-0
|Seiten=157–159}}
</ref>
</references>

[[Kategorie:Planung und Organisation]]
[[Kategorie:Anforderungsmanagement]]

Anwendungsfall - Versionsgeschichte

imported>Till.niermann: /* Use Case 2.0 */