Anwendungsfall

Sowohl in der Software- als auch in der Systemtechnik ist ein Anwendungsfall eine strukturierte Beschreibung des Verhaltens eines Systems bei der Reaktion auf Anfragen externer Akteure mit dem Ziel, ein bestimmtes Ziel zu erreichen. Der Begriff wird auch außerhalb der Software-/Systemtechnik verwendet, um zu beschreiben, wie etwas genutzt werden kann. ^{[ 1 ]}

In der Softwareentwicklung (und der Entwicklung softwarebasierter Systeme) dient der Anwendungsfall der Definition und Validierung funktionaler Anforderungen. ^{[ 2 ]} Ein Anwendungsfall ist eine Liste von Aktionen oder Ereignisschritten, die typischerweise die Interaktionen zwischen einer Rolle (in der Unified Modeling Language (UML) als Akteur bezeichnet ) und einem System zur Erreichung eines Ziels beschreiben. Der Akteur kann ein Mensch oder ein anderes externes System sein. In der Systementwicklung werden Anwendungsfälle auf einer höheren Ebene als in der Softwareentwicklung verwendet und repräsentieren häufig Missionen oder Ziele von Stakeholdern . Die detaillierten Anforderungen können dann in der Systems Modeling Language (SysML) oder als vertragliche Aussagen erfasst werden .

In der Softwareentwicklung definiert ein Anwendungsfall mögliche Szenarien, in denen die Software auf eine externe Anfrage (z. B. Benutzereingaben) reagiert. In der Systementwicklung modelliert ein Anwendungsfall das funktionale Verhalten auf hoher Ebene über technische und menschliche Komponenten hinweg.

In der Software- und Systemtechnik ist der Begriff „Anwendungsfall“ ein Polysem mit zwei Bedeutungen :

1. Ein Anwendungsszenario für eine Software; wird oft im Plural verwendet, um Situationen zu beschreiben, in denen eine Software nützlich sein kann.
2. Ein mögliches Szenario, in dem ein System eine externe Anfrage (z. B. eine Benutzereingabe) empfängt und darauf reagiert.

Dieser Artikel behandelt die letztgenannte Bedeutung. (Mehr zur anderen Bedeutung finden Sie unter Persona (Nutzererfahrung) .)

1987 präsentierte Ivar Jacobson auf der OOPSLA '87-Konferenz den ersten Artikel über Anwendungsfälle . ^{[ 3 ]} Er beschrieb, wie diese Technik bei Ericsson eingesetzt wurde , um Systemanforderungen mithilfe textueller, struktureller und visueller Modellierungstechniken zu erfassen und zu spezifizieren und so die objektorientierte Analyse und das Design zu steuern. ^{[ 4 ]} Ursprünglich verwendete er die Begriffe „Use Scenarios“ und „Use Case“ – letzterer eine direkte Übersetzung seines schwedischen Begriffs „användningsfall “ –, stellte jedoch fest, dass keiner dieser Begriffe im Englischen natürlich klang, und entschied sich schließlich für „ Use Case“ . ^{[ 5 ]}

1992 war er Mitautor des Buches „Object-Oriented Software Engineering – A Use Case Driven Approach“ [ ^{6 ] ,} das die Grundlage für die OOSE -Systementwicklungsmethode legte und dazu beitrug, Anwendungsfälle zur Erfassung funktionaler Anforderungen , insbesondere in der Softwareentwicklung , zu popularisieren . 1994 veröffentlichte er ein Buch über Anwendungsfälle und objektorientierte Techniken, angewendet auf Geschäftsmodelle und Geschäftsprozessoptimierung . ^{[ 7 ]}

Gleichzeitig arbeiteten Grady Booch und James Rumbaugh an der Vereinheitlichung ihrer objektorientierten Analyse- und Entwurfsmethoden, der Booch-Methode bzw. der Objektmodellierungstechnik (OMT) . 1995 stieß Ivar Jacobson zu ihnen hinzu, und gemeinsam entwickelten sie die Unified Modeling Language (UML) , die auch die Modellierung von Anwendungsfällen umfasst. UML wurde 1997 von der Object Management Group (OMG) standardisiert. ^{[ 8 ]} Jacobson, Booch und Rumbaugh arbeiteten außerdem an einer Weiterentwicklung des Objectory -Softwareentwicklungsprozesses. Der daraus resultierende Unified Process wurde 1999 veröffentlicht und förderte einen anwendungsfallorientierten Ansatz. ^{[ 9 ]}

Seitdem haben zahlreiche Autoren zur Weiterentwicklung dieser Technik beigetragen, insbesondere: Larry Constantine entwickelte 1995 im Kontext des nutzungszentrierten Designs sogenannte „essentielle Anwendungsfälle“, die die Absichten der Nutzer beschreiben sollen, anstatt Handlungsabfolgen oder Szenarien, die die Gestaltung der Benutzeroberfläche einschränken oder verzerren könnten; ^{[ 10 ]} Alistair Cockburn veröffentlichte im Jahr 2000 eine zielorientierte Anwendungsfallpraxis, die auf Textbeschreibungen und tabellarischen Spezifikationen basiert; ^{[ 11 ]} Kurt Bittner und Ian Spence entwickelten 2002 fortgeschrittene Praktiken zur Analyse funktionaler Anforderungen mithilfe von Anwendungsfällen; ^{[ 12 ]} Dean Leffingwell und Don Widrig schlugen vor, Anwendungsfälle im Change-Management und in der Stakeholder-Kommunikation einzusetzen; ^{[ 13 ]} Gunnar Overgaard schlug 2004 vor, die Prinzipien von Entwurfsmustern auf Anwendungsfälle zu erweitern. ^{[ 14 ]}

Im Jahr 2011 veröffentlichte Jacobson zusammen mit Ian Spence und Kurt Bittner das E-Book Use Case 2.0 , um die Technik an einen agilen Kontext anzupassen, sie mit inkrementellen Use-Case-„Slices“ anzureichern und ihre Anwendung über den gesamten Entwicklungslebenszyklus hinweg zu fördern ^{[ 15 ]} , nachdem er den überarbeiteten Ansatz auf der jährlichen IIBA- Konferenz vorgestellt hatte. ^{[ 16 ] [ 17 ]}

Anwendungsfälle sind eine Technik zur Erfassung, Modellierung und Spezifizierung der Systemanforderungen. ^{[ 12 ]} Ein Anwendungsfall entspricht einer Menge von Verhaltensweisen, die das System in Interaktion mit seinen Akteuren ausführen kann und die ein beobachtbares Ergebnis erzeugen, das zu seinen Zielen beiträgt. Akteure repräsentieren die Rolle, die menschliche Benutzer oder andere Systeme in der Interaktion einnehmen.

Bei der Anforderungsanalyse wird ein Anwendungsfall nach dem spezifischen Nutzerziel benannt, das er für seinen Hauptakteur darstellt. Der Fall wird anschließend durch eine Textbeschreibung oder zusätzliche grafische Modelle detailliert ausgearbeitet, die den allgemeinen Ablauf von Aktivitäten und Ereignissen sowie Varianten wie Sonderbedingungen, Ausnahmen oder Fehlersituationen erläutern.

Gemäß dem Software Engineering Body of Knowledge ⁽ SWEBOK) [ ^{18 ]} gehören Anwendungsfälle zu den szenariobasierten Anforderungserhebungstechniken sowie zu den modellbasierten Analysetechniken . Sie unterstützen aber auch die narrative Anforderungserhebung, die inkrementelle Anforderungserfassung, die Systemdokumentation und die Abnahmetests. ^{[ 3 ]}

Es gibt verschiedene Anwendungsfälle und Variationen der Technik:

• Systemanwendungsfälle spezifizieren die Anforderungen an ein zu entwickelndes System. ^{[ 4 ]} Sie beschreiben detailliert nicht nur die Interaktionen mit den Akteuren, sondern auch die an der Verarbeitung beteiligten Entitäten. Sie bilden den Ausgangspunkt für weitere Analysemodelle und Designaktivitäten.
• Business Use Cases konzentrieren sich auf eine Unternehmensorganisation anstatt auf ein Softwaresystem. Sie dienen dazu, Geschäftsmodelle und Geschäftsprozessanforderungen im Kontext von Geschäftsprozessreengineering-Initiativen zu spezifizieren. ^{[ 7 ]}
• Essentielle Anwendungsfälle, auch abstrakte Anwendungsfälle genannt, beschreiben die potenziellen Absichten der Akteure und wie das System diese adressiert, ohne eine bestimmte Reihenfolge festzulegen oder ein Szenario zu beschreiben. ^{[ 10 ]} Diese Vorgehensweise wurde entwickelt, um ein nutzerzentriertes Design zu unterstützen und eine Voreingenommenheit gegenüber der Benutzeroberfläche in der frühen Phase der Systemspezifikation zu vermeiden. ^{[ 9 ]}
• Anwendungsfall 2.0 dient der Anpassung der Technik an den Kontext agiler Entwicklungsmethoden. ^{[ 3 ]} Diese Technik erweitert die Anforderungserhebung um die Unterstützung von User-Story-Narrativen. Sie stellt außerdem Anwendungsfall-„Slices“ bereit, um die inkrementelle Anforderungserhebung und -implementierung zu erleichtern.

Der Umfang eines Anwendungsfalls kann durch ein Thema und durch Ziele definiert werden:

• Das Subjekt identifiziert das System, das Teilsystem oder die Komponente, die die Interaktionen bereitstellen wird. ^{[ 19 ]}
• Die Ziele können hierarchisch strukturiert werden, wobei die für das Ziel relevante Organisationsebene (z. B. Unternehmen, Abteilung, Benutzer) und die Aufteilung des Benutzerziels in Teilziele berücksichtigt werden. ^{[ 11 ]} Die Zielaufteilung erfolgt aus der Sicht der Benutzer und unabhängig vom System, was sich von der traditionellen funktionalen Dekomposition unterscheidet. ^{[ 12 ]}

Anwendungsfälle werden bekanntermaßen in folgenden Kontexten angewendet:

• Objektorientierte Softwareentwicklung (OOSE) als treibende Kraft; ^{[ 6 ]}
• Unified Modeling Language (UML) als Instrument zur Verhaltensmodellierung; ^{[ 19 ]}
• Unified Software Development Process (UP) und sein Vorgänger, der IBM Rational Unified Process (RUP) ; ^{[ 9 ]}
• Vorabdokumentation der Software-Anforderungsspezifikation (SRS) als alternative Struktur für die funktionalen Anforderungen; ^{[ 20 ].}
• Ableitung des Designs aus den Anforderungen unter Verwendung des Entity-Control-Boundary- Ansatzes; ^{[ 9 ]}
• und agile Entwicklung . ^{[ 3 ] [ 21 ]}

Es gibt viele Möglichkeiten, einen Anwendungsfall in Textform zu beschreiben – von kurzen , informellen und detaillierten Beschreibungen bis hin zu ausführlichen Darstellungen . Dabei stehen verschiedene Vorlagen zur Verfügung. Die Verwendung von Vorlagen verschiedener Anbieter oder Experten ist in der Branche gängige Praxis, um qualitativ hochwertige funktionale Systemanforderungen zu erhalten.

Das von Alistair Cockburn in seinem Buch „Writing Effective Use Cases“ definierte Schema ist einer der am weitesten verbreiteten Schreibstile für Anwendungsfälle.

Cockburn schlägt vor, jeden Anwendungsfall mit einem Symbol zu versehen, um den „Designumfang“ anzuzeigen. Dieser kann als Blackbox (interne Details sind verborgen) oder Whitebox (interne Details sind sichtbar) dargestellt werden. Fünf Symbole stehen zur Verfügung: ^{[ 22 ]}

Umfang	Symbol	Symbol
Organisation (Blackbox)	Das Haus war voll
Organisation (White-Box)	Unbesetztes Haus
System (Blackbox)	Gefüllte Box
System (White-Box)	Unausgefülltes Feld
Komponente	Schraube oder Bolzen

Andere Autoren bezeichnen Anwendungsfälle auf Organisationsebene manchmal als „Geschäftsanwendungsfälle“. ^{[ 23 ]}

Cockburn schlägt vor, jeden Anwendungsfall mit einem Symbol zu versehen, um die „Zielebene“ anzuzeigen; ^{[ 24 ]} die bevorzugte Ebene ist „Benutzerziel“ (oder umgangssprachlich „Meeresspiegel“ ^{[ 25 ] : 101} ).

Zielniveau	Symbol	Textsymbol	Symbol
Sehr hohe Zusammenfassung	Wolke	++
Zusammenfassung	Drachensteigen	+
Nutzerziel	Wellen am Meer	!
Unterfunktion	Fisch	-
Zu niedrig	Meeresbodenmuschel	--

Manchmal ist es in Texten eine prägnantere und bequemere Art, Ebenen zu kennzeichnen, indem man einen Anwendungsfallnamen gefolgt von einem Alternativtextsymbol (! +, -, etc.) verwendet, z. B. Bestellung aufgeben! , anmelden- .

Cockburn beschreibt eine detailliertere Struktur für einen Anwendungsfall, erlaubt aber deren Vereinfachung, wenn weniger Details benötigt werden. Seine vollständige Anwendungsfallvorlage listet die folgenden Felder auf: ^{[ 26 ]}

• Titel: „eine aktive Verb-Zielphrase, die das Ziel des primären Akteurs benennt“ ^{[ 27 ]}
• Hauptdarsteller
• Ziel im Kontext
• Umfang
• Ebene
• Interessengruppen und Interessen
• Voraussetzung
• Minimale Garantien
• Erfolgsgarantien
• Auslösen
• Haupterfolgsszenario
• Erweiterungen
• Liste der Technologie- und Datenvarianten

Darüber hinaus schlägt Cockburn vor, zwei Mittel zu verwenden, um die Art jedes Anwendungsfalls anzuzeigen: Symbole für den Designumfang und die Zielebene.

Cockburns Ansatz hat andere Autoren beeinflusst; so haben beispielsweise Alexander und Beus-Dukic Cockburns Vorlage des "vollständig ausgearbeiteten Anwendungsfalls" von Software auf Systeme aller Art verallgemeinert, wobei sich die folgenden Bereiche von Cockburn unterscheiden: ^{[ 28 ]}

• Variationsszenarien (die sich möglicherweise vom Hauptszenario abzweigen und möglicherweise zum Hauptszenario zurückkehren)
• Ausnahmen „d. h. Ausnahmeereignisse und deren Ausnahmebehandlungsszenarien“

Cockburn erkennt an, dass Projekte nicht immer detaillierte, vollständig ausgearbeitete Anwendungsfälle benötigen. Er beschreibt einen Gelegenheitsanwendungsfall mit den folgenden Feldern: ^{[ 26 ]}

• Titel (Tor)
• Hauptdarsteller
• Umfang
• Ebene
• (Story): Der Hauptteil des Anwendungsfalls besteht aus ein oder zwei Absätzen Text, in denen informell beschrieben wird, was passiert.

Martin Fowler stellt fest: „Es gibt keine Standardmethode, um den Inhalt eines Anwendungsfalls zu verfassen, und verschiedene Formate eignen sich für unterschiedliche Fälle.“ ^{[ 25 ] : 100} Er beschreibt einen „gängigen Stil“ wie folgt: ^{[ 25 ] : 101}

• Titel: „Ziel, das der Anwendungsfall zu erreichen versucht“ ^{[ 25 ] : 101}
• Hauptszenario für den Erfolg: Nummerierte Liste der Schritte ^{[ 25 ] : 101}
  • Schritt: „eine einfache Beschreibung der Interaktion zwischen dem Akteur und einem System“ ^{[ 25 ] : 101}
• Erweiterungen: separat nummerierte Listen, eine pro Erweiterung ^{[ 25 ] : 101}
  • Erweiterung: „Eine Bedingung, die zu anderen Interaktionen führt als im Haupterfolgsszenario“. Eine Erweiterung von Hauptschritt 3 wird mit 3a usw. nummeriert ^{[ 25 ] : 101}

Der Fowler-Stil kann auch als vereinfachte Variante der Cockburn-Vorlage betrachtet werden. Diese Variante wird als User Story bezeichnet .

Alistair Cockburn erklärte: ^{[ 29 ]}

Betrachten Sie eine User Story als Anwendungsfall mit zwei Genauigkeitsbits. Bit 1 beschreibt das Ziel des Anwendungsfalls, Bit 2 das Hauptszenario. Bit 3 fügt die Fehlerbedingungen hinzu, Bit 4 die Fehleraktionen. Bit 5 beschreibt die ein- und ausgehenden Daten. Ich würde Catalysis mit sechs Genauigkeitsbits versehen, da sie auch ein Modell des Nachrichtenempfängers beinhalten. In der CrystalMethodology-Familie verwenden unterschiedlich strukturierte Projekte Anwendungsfälle mit unterschiedlicher Genauigkeit. Ein methodisch leichtes Projekt nutzt User Stories, ein methodisch umfangreicheres Projekt nutzt Anwendungsfälle mit vier Genauigkeitsbits und Catalysis verwendet sechs Genauigkeitsbits.

Martin Fowler erklärte: ^{[ 29 ]}

Es kommt ganz darauf an, wie man Anwendungsfälle verwendet. Ich habe schon oft erlebt, dass Anwendungsfälle sehr formalisiert eingesetzt werden. Kent gestaltet seine User Stories viel zugänglicher. Ich verwende Anwendungsfälle ähnlich wie Kent seine User Stories. Ich nenne sie Anwendungsfälle, um besser mit anderen Entwicklern zu kommunizieren und sie zu einem schlankeren Ansatz zu bewegen.

Ein Anwendungsfall definiert die Interaktionen zwischen externen Akteuren und dem betrachteten System zur Erreichung eines Ziels. Akteure müssen entscheidungsfähig sein, müssen aber nicht menschlich sein: „Ein Akteur kann eine Person, ein Unternehmen oder eine Organisation, ein Computerprogramm oder ein Computersystem – Hardware, Software oder beides – sein.“ ^{[ 30 ]} Akteure sind immer Stakeholder , aber nicht alle Stakeholder sind Akteure, da sie „möglicherweise nie direkt mit dem System interagieren, obwohl sie ein Recht darauf haben, sich für dessen Verhalten zu interessieren.“ ^{[ 30 ]} Beispielsweise könnten „die Eigentümer des Systems, der Vorstand des Unternehmens und Aufsichtsbehörden wie das Finanzamt und die Versicherungsaufsicht“ Stakeholder sein, sind aber wahrscheinlich keine Akteure. ^{[ 30 ]}

Ebenso kann eine Person, die ein System nutzt, aufgrund der Übernahme verschiedener Rollen als unterschiedlicher Akteur dargestellt werden. Beispielsweise könnte der Nutzer „Joe“ die Rolle eines Kunden einnehmen, wenn er an einem Geldautomaten Bargeld von seinem Konto abhebt, oder die Rolle eines Bankangestellten, wenn er das System im Auftrag der Bank nutzt, um die Kasse aufzufüllen.

Akteure handeln oft im Auftrag anderer. Cockburn schreibt: „Heutzutage schreibe ich ‚Vertriebsmitarbeiter für den Kunden‘ oder ‚Sachbearbeiter für die Marketingabteilung‘, um zu verdeutlichen, dass der Systemnutzer im Auftrag einer anderen Person handelt.“ Dies signalisiert dem Projekt, dass die Benutzeroberfläche und die Sicherheitsfreigaben für Vertriebsmitarbeiter und Sachbearbeiter ausgelegt sein sollten, während der Kunde und die Marketingabteilung für die Ergebnisse verantwortlich sind. ^{[ 31 ]}

Ein Stakeholder kann sowohl eine aktive als auch eine passive Rolle einnehmen: Beispielsweise ist ein Konsument sowohl ein „Massenmarktkäufer“ (der nicht mit dem System interagiert) als auch ein Nutzer (ein Akteur, der aktiv mit dem gekauften Produkt interagiert). ^{[ 32 ]} Ein Nutzer wiederum ist sowohl ein „normaler Bediener“ (ein Akteur, der das System bestimmungsgemäß nutzt) als auch ein „funktionaler Nutznießer“ (ein Stakeholder, der von der Nutzung des Systems profitiert). ^{[ 32 ]} Wenn beispielsweise Nutzer „Joe“ Bargeld von seinem Konto abhebt, bedient er den Geldautomaten und erhält das Ergebnis in eigenem Namen.

Cockburn empfiehlt, die Akteure unter den Stakeholdern eines Systems, den primären und unterstützenden (sekundären) Akteuren eines Anwendungsfalls, dem zu entwerfenden System (SuD) selbst und schließlich unter den „internen Akteuren“, d. h. den Komponenten des zu entwerfenden Systems, zu suchen. ^{[ 30 ]}

So wie ein Anwendungsfall eine Reihe von Ereignissen und Interaktionen zwischen einem Benutzer (oder anderen Akteuren) und einem System beschreibt, um ein Wertergebnis (Ziel) zu erzielen, beschreibt ein Geschäftsanwendungsfall die allgemeinere Interaktion zwischen einem Geschäftssystem und den Benutzern/Akteuren dieses Systems, um wertvolle Geschäftsergebnisse zu generieren. Der Hauptunterschied besteht darin, dass das in einem Geschäftsanwendungsfallmodell betrachtete System neben technologischen Systemen auch Personen umfassen kann. Diese „Personen im System“ werden als Mitarbeiter bezeichnet. Im Beispiel eines Restaurants muss entschieden werden, ob jede Person als Akteur (und damit außerhalb des Systems) oder als Mitarbeiter (innerhalb des Systems) behandelt wird. Wird ein Kellner, wie im folgenden Beispiel gezeigt, als Akteur betrachtet, so ist der Kellner nicht Teil des Restaurantsystems, und das Modell bildet die Interaktion zwischen dem Kellner und dem Restaurant ab. Alternativ könnte man den Kellner als Teil des Restaurantsystems (Mitarbeiter) betrachten, während der Gast als außerhalb des Systems (Akteur) betrachtet wird. ^{[ 33 ]}

Anwendungsfälle bestehen nicht nur aus Texten, sondern können bei Bedarf auch als Diagramme dargestellt werden. In der Unified Modeling Language (UML ) werden die Beziehungen zwischen Anwendungsfällen und Akteuren in Anwendungsfalldiagrammen abgebildet, die ursprünglich auf Ivar Jacobsons Objectory - Notation basieren . SysML verwendet dieselbe Notation auf Systemblockebene.

Darüber hinaus können auch andere Verhaltensdiagramme aus der UML-Architektur, wie Aktivitätsdiagramme , Sequenzdiagramme , Kommunikationsdiagramme und Zustandsdiagramme , zur Visualisierung von Anwendungsfällen verwendet werden. Ein Systemsequenzdiagramm (SSD) ist ein Sequenzdiagramm, das häufig die Interaktionen zwischen externen Akteuren und dem zu entwickelnden System (SuD) darstellt, üblicherweise zur Visualisierung eines bestimmten Szenarios eines Anwendungsfalls.

Die Anwendungsfallanalyse beginnt üblicherweise mit der Erstellung von Anwendungsfalldiagrammen. Für die agile Entwicklung ist ein Anforderungsmodell mit vielen UML-Diagrammen, die Anwendungsfälle darstellen, sowie einigen textlichen Beschreibungen, Notizen oder Anwendungsfallbeschreibungen sehr schlank und für kleine oder einfache Projekte völlig ausreichend. Als sinnvolle Ergänzung zu den Anwendungsfalltexten sind die visuellen Diagramme der Anwendungsfälle auch effektive Hilfsmittel, um das Verständnis, die Kommunikation und die Gestaltung komplexer Systemverhaltensanforderungen zu verbessern.

Nachfolgend finden Sie ein Beispiel für einen Anwendungsfall, der mit einer leicht modifizierten Version der Cockburn-Vorlage erstellt wurde. Beachten Sie, dass die grundlegende Anwendungsfallbeschreibung keine Schaltflächen, Steuerelemente, Formulare oder sonstige UI-Elemente und -Operationen enthält. Stattdessen werden in jedem Schritt des grundlegenden Ablaufs oder der Erweiterungen lediglich die Ziele, Teilziele oder Absichten des Benutzers ausgedrückt. Diese Vorgehensweise macht die Anforderungsspezifikation übersichtlicher und maximiert die Flexibilität von Design und Implementierung.

Anwendungsfall : Einen Artikel bearbeiten

Primärer Akteur : Mitglied (Registrierter Benutzer)

Geltungsbereich : ein Wiki- System

Level : ! (Benutzerziel oder Meeresspiegel)

Kurzfassung : (entspricht einer User Story oder einem Epos)

Das Mitglied kann jeden beliebigen Teil (den gesamten Artikel oder nur einen Abschnitt) eines Artikels bearbeiten, den es gerade liest. Vorschau und Vergleich der Änderungen sind während der Bearbeitung möglich.

Interessengruppen

...

Nachbedingungen

Minimale Garantien :

Erfolgsgarantien :

• Der Artikel wird gespeichert und eine aktualisierte Ansicht wird angezeigt.
• Das System erstellt einen Bearbeitungsdatensatz für den Artikel, sodass die Beobachter des Artikels später über die Aktualisierung informiert werden können.

Voraussetzungen :

Dem Mitglied wird der Artikel mit Bearbeitungsfunktion angezeigt.

Auslöser :

Das Mitglied stellt eine Bearbeitungsanfrage (für den gesamten Artikel oder nur einen Abschnitt) zum Artikel.

Grundlegender Ablauf :

1. Das System stellt einen neuen Bearbeitungsbereich bereit, der den gesamten relevanten Inhalt des Artikels sowie eine informative Bearbeitungszusammenfassung enthält. Möchte das Mitglied lediglich einen Abschnitt des Berichts bearbeiten, wird nur der Originalinhalt dieses Abschnitts angezeigt, wobei der Abschnittstitel automatisch in die Bearbeitungszusammenfassung eingefügt wird.
2. Das Mitglied ändert den Inhalt des Artikels so lange, bis es zufrieden ist.
3. Das Mitglied füllt die Bearbeitungszusammenfassung aus, teilt dem System mit, ob es diesen Artikel beobachten möchte, und sendet die Bearbeitung ab.
4. Das System speichert den Artikel, protokolliert das Bearbeitungsereignis und führt alle notwendigen Nachbearbeitungen durch.
5. Das System präsentiert dem Mitglied die aktualisierte Ansicht des Artikels.

Erweiterungen :

2–3.

a. Vorschau anzeigen:

1. Das Mitglied wählt „Vorschau anzeigen“ , wodurch der geänderte Inhalt übermittelt wird.
2. Das System wiederholt Schritt 1 mit dem hinzugefügten aktualisierten Inhalt zur Vorschau und informiert das Mitglied darüber, dass seine/ihre Änderungen noch nicht gespeichert wurden, und fährt dann fort.

b. Änderungen anzeigen:

1. Das Mitglied wählt „Änderungen anzeigen“ , wodurch der geänderte Inhalt übermittelt wird.
2. Das System wiederholt Schritt 1 und zeigt zusätzlich die Ergebnisse des Vergleichs der Unterschiede zwischen den aktuellen Bearbeitungen des Mitglieds und der zuletzt gespeicherten Version des Artikels an. Anschließend wird der Vorgang fortgesetzt.

c. Bearbeitung abbrechen:

1. Das Mitglied wählt Abbrechen .
2. Das System verwirft alle Änderungen, die das Mitglied vorgenommen hat, und fährt dann mit Schritt 5 fort.

4a. Auszeit:

...

Seit den Anfängen der agilen Bewegung ist die User-Story- Technik aus dem Extreme Programming so populär geworden, dass viele sie für die einzige und beste Lösung für die agilen Anforderungen aller Projekte halten. Alistair Cockburn nennt fünf Gründe, warum er im agilen Entwicklungsprozess weiterhin Anwendungsfälle schreibt . ^{[ 34 ]}

1. Die Liste der Zielnamen bietet die kürzeste Zusammenfassung dessen, was das System leisten wird (noch mehr als User Stories). Sie dient außerdem als Projektplanungsgerüst, anhand dessen erste Prioritäten, Aufwandsschätzungen, Teamzusammenstellung und Zeitplanung erstellt werden können.
2. Das Hauptszenario jedes Anwendungsfalls schafft für alle Beteiligten Einigkeit darüber, was das System grundsätzlich leisten soll und was nicht. Es liefert den Kontext für jede einzelne Anforderung (z. B. detaillierte User Stories) – einen Kontext, der anderswo kaum zu finden ist.
3. Die Erweiterungsbedingungen jedes Anwendungsfalls bieten einen Rahmen, um all die kleinen, scheinbar unbedeutenden Details zu untersuchen, die oft 80 % der Entwicklungszeit und des Budgets beanspruchen. Sie ermöglichen es den Beteiligten, vorausschauend Probleme zu erkennen, deren Lösung voraussichtlich viel Zeit in Anspruch nehmen wird. Diese Probleme können und sollten dann priorisiert werden, sodass die Lösungen bereitliegen, sobald das Entwicklungsteam sich damit befasst.
4. Die Fragmente der Anwendungsfallerweiterungsszenarien liefern Antworten auf die vielen detaillierten, oft kniffligen und vernachlässigten Geschäftsfragen: „Was sollen wir in diesem Fall tun?“ Es handelt sich um ein Denk- und Dokumentationsframework, das der Wenn…dann…sonst-Anweisung entspricht und Programmierern hilft, Probleme zu durchdenken. Der Unterschied besteht darin, dass dies während der Untersuchung und nicht während der Programmierung geschieht.
5. Die vollständige Sammlung von Anwendungsfällen zeigt, dass die Ermittler alle Bedürfnisse der Nutzer, alle Ziele, die sie in Bezug auf das System verfolgen, und alle damit verbundenen Geschäftsvarianten durchdacht haben.

Zusammenfassend lässt sich sagen, dass die Spezifizierung von Systemanforderungen in Anwendungsfällen im Vergleich zu traditionellen oder anderen Ansätzen folgende Vorteile bietet:

Nutzerorientiert

Anwendungsfälle stellen ein leistungsstarkes, nutzerzentriertes Werkzeug für die Spezifikation von Softwareanforderungen dar. ^{[ 35 ]} Die Modellierung von Anwendungsfällen beginnt typischerweise mit der Identifizierung der wichtigsten Stakeholder-Rollen ( Akteure ), die mit dem System interagieren, sowie ihrer Ziele oder Vorgaben, die das System erfüllen muss (eine externe Perspektive). Diese Nutzerziele eignen sich dann ideal für die Benennung oder den Titel der Anwendungsfälle, welche die gewünschten funktionalen Merkmale oder Dienste des Systems repräsentieren. Dieser nutzerzentrierte Ansatz stellt sicher, dass das entwickelt wird, was einen echten Geschäftswert besitzt und den Nutzern tatsächlich wünscht, und nicht etwa triviale Funktionen, die aus der Perspektive eines Entwicklers oder des Systems (intern) spekuliert werden.

Die Erstellung von Anwendungsfällen ist ein Analyseinstrument im Bereich des nutzerzentrierten Designs (User-Centered Design, UCD) .

Bessere Kommunikation

Anwendungsfälle werden häufig in natürlicher Sprache mithilfe strukturierter Vorlagen verfasst. Diese narrative Textform (verständliche Anforderungsbeschreibungen), ergänzt durch visuelle UML-Diagramme, fördert eine bessere und tiefere Kommunikation zwischen allen Beteiligten, darunter Kunden, Endnutzer, Entwickler, Tester und Manager. Eine verbesserte Kommunikation führt zu qualitativ hochwertigen Anforderungen und somit zu qualitativ hochwertigen Systemen.

Qualitätsanforderungen durch strukturierte Erkundung

Ein wichtiger Aspekt von Anwendungsfällen liegt in der Struktur ihrer Vorlagen , insbesondere im Hauptszenario (Basisablauf) und den Erweiterungsszenarien (Erweiterungen, Ausnahme- und Alternativabläufe). Die schrittweise Analyse eines Anwendungsfalls von den Vor- bis zu den Nachbedingungen, die Untersuchung jedes einzelnen Aktionsschritts im Ablauf – vom Basisablauf bis zu den Erweiterungen –, um jene kniffligen, normalerweise verborgenen und übersehenen, scheinbar trivialen, aber in Wirklichkeit oft kostspieligen Anforderungen zu identifizieren (wie Cockburn bereits erwähnte), ist ein strukturierter und vorteilhafter Weg, um systematisch klare, stabile und qualitativ hochwertige Anforderungen zu gewinnen.

Die Minimierung und Optimierung der Aktionsschritte eines Anwendungsfalls zur Erreichung des Benutzerziels trägt ebenfalls zu einem besseren Interaktionsdesign und einer besseren Benutzererfahrung des Systems bei.

Erleichterung von Tests und Benutzerdokumentation

Mit Inhalten, die auf einer Aktions- oder Ereignisablaufstruktur basieren, dient ein Modell gut formulierter Anwendungsfälle auch als Grundlage und Richtlinie für die Gestaltung von Testfällen und Benutzerhandbüchern des Systems oder Produkts. Es bestehen Verbindungen zwischen den Ablaufpfaden eines Anwendungsfalls und seinen Testfällen. Funktionale Testfälle lassen sich aus einem Anwendungsfall über sein Szenario (durchlaufende Instanzen eines Anwendungsfalls) unkompliziert ableiten. ^{[ 36 ]}

Zu den Einschränkungen der Anwendungsfälle gehören:

• Anwendungsfälle eignen sich nicht gut zur Erfassung von nicht-interaktionsbasierten Systemanforderungen (wie z. B. algorithmischen oder mathematischen Anforderungen) oder nicht-funktionalen Anforderungen (wie z. B. Plattform-, Leistungs-, Zeit- oder sicherheitskritischen Aspekten). Diese werden besser deklarativ an anderer Stelle spezifiziert.
• Da es keine allgemein gültigen Definitionen von Anwendungsfällen gibt, muss jedes Projekt seine eigene Interpretation entwickeln.
• Einige Anwendungsfallbeziehungen, wie z. B. „ extends“ , sind in ihrer Interpretation mehrdeutig und können für die Beteiligten schwer verständlich sein, wie Cockburn (Problem Nr. 6) ^{[ 37 ]} festgestellt hat.
• Entwickler von Anwendungsfällen haben oft Schwierigkeiten, den Grad der Abhängigkeit von der Benutzeroberfläche (UI) in einem Anwendungsfall festzulegen. Obwohl die Anwendungsfalltheorie nahelegt, dass die UI nicht in Anwendungsfällen abgebildet werden sollte, kann es schwierig sein, diesen Aspekt des Designs auszublenden, da dies die Visualisierung der Anwendungsfälle erschwert. In der Softwareentwicklung wird diese Schwierigkeit durch die Anwendung von Anforderungsrückverfolgbarkeit , beispielsweise mithilfe einer Rückverfolgbarkeitsmatrix , gelöst . Ein anderer Ansatz zur Verknüpfung von UI-Elementen mit Anwendungsfällen besteht darin, jedem Schritt im Anwendungsfall ein UI-Design zuzuordnen. Dies wird als Anwendungsfall-Storyboard bezeichnet.
• Anwendungsfälle können überbewertet werden. Bertrand Meyer erörtert Probleme wie die zu wörtliche Ableitung des Systemdesigns aus Anwendungsfällen und die Verwendung von Anwendungsfällen unter Ausschluss anderer, potenziell wertvoller Techniken der Anforderungsanalyse. ^{[ 38 ]}
• Anwendungsfälle bilden einen Ausgangspunkt für die Testentwicklung ^{[ 39 ]} , da jedoch jeder Test seine eigenen Erfolgskriterien benötigt, müssen die Anwendungsfälle gegebenenfalls angepasst werden, um für jeden Pfad separate Nachbedingungen bereitzustellen. ^{[ 40 ]}
• Obwohl Anwendungsfälle Ziele und Kontexte beinhalten, ist die Frage, ob diese Ziele und die Motivationen hinter den Zielen (Anliegen der Stakeholder und deren Einschätzungen einschließlich Nicht-Interaktion) mit anderen Systemzielen in Konflikt stehen oder diese negativ/positiv beeinflussen, Gegenstand zielorientierter Anforderungsmodellierungstechniken (wie BMM , I* , KAOS und ArchiMate ARMOR).

Häufige Missverständnisse bezüglich Anwendungsfällen sind:

User Stories sind agil; Anwendungsfälle nicht.

Agile und Scrum verhalten sich neutral gegenüber Anforderungstechniken. Wie im Scrum Primer ^{[ 41 ]} ausgeführt wird,

Product-Backlog-Einträge werden so formuliert, wie es klar und nachvollziehbar ist. Anders als oft angenommen, enthält der Product Backlog keine „User Stories“, sondern lediglich Einträge. Diese Einträge können als User Stories, Anwendungsfälle oder andere Anforderungsmodelle ausgedrückt werden, die das Team als sinnvoll erachtet. Unabhängig vom gewählten Ansatz sollten die meisten Einträge jedoch darauf ausgerichtet sein, den Kunden einen Mehrwert zu bieten.

Die Techniken zur Erstellung von Anwendungsfällen wurden weiterentwickelt, um agile Ansätze zu berücksichtigen, indem Anwendungsfallfragmente inkrementell erweitert werden. ^{[ 15 ]}

Anwendungsfälle sind hauptsächlich Diagramme.

Craig Larman betont, dass „Anwendungsfälle keine Diagramme, sondern Text sind“. ^{[ 42 ]}

Die Anwendungsfälle enthalten zu viele Inhalte, die sich auf die Benutzeroberfläche beziehen.

Wie manche es ausdrücken

Anwendungsfälle enthalten oft einen Detaillierungsgrad (z. B. Benennung von Beschriftungen und Schaltflächen), der sie ungeeignet macht, um die Anforderungen für ein neues System von Grund auf zu erfassen.

Missverständnisse von Anfängern. Jeder Schritt eines gut formulierten Anwendungsfalls sollte die Ziele oder Absichten der Akteure (das Wesen der funktionalen Anforderungen) darstellen und sollte normalerweise keine Details zur Benutzeroberfläche enthalten, z. B. die Benennung von Beschriftungen und Schaltflächen, UI-Operationen usw., da dies eine schlechte Vorgehensweise ist und das Schreiben des Anwendungsfalls unnötig verkompliziert und seine Implementierung einschränkt.

Wenn es darum geht, Anforderungen für ein neues System von Grund auf zu erfassen, werden Anwendungsfalldiagramme und Anwendungsfallbeschreibungen oft als praktische und wertvolle Werkzeuge verwendet, die mindestens genauso leichtgewichtig sind wie User Stories.

Das Schreiben von Anwendungsfällen für große Systeme ist mühsam und eine Zeitverschwendung.

Wie manche es ausdrücken

Das Format des Anwendungsfalls erschwert die Beschreibung eines großen Systems (z. B. eines CRM-Systems) auf weniger als einigen hundert Seiten. Das ist zeitaufwendig und führt zu unnötigen Nacharbeiten.

Viel Zeit mit dem Schreiben umständlicher Anwendungsfälle zu verbringen, die kaum oder gar keinen Mehrwert bieten und viel Nacharbeit verursachen, ist ein schlechtes Zeichen dafür, dass die Autoren nicht über ausreichende Fähigkeiten verfügen und wenig Erfahrung im effizienten und effektiven Verfassen qualitativ hochwertiger Anwendungsfälle haben. Anwendungsfälle sollten iterativ, inkrementell und evolutionär ( agil ) erstellt werden. Die Verwendung von Anwendungsfallvorlagen bedeutet nicht, dass alle Felder einer Vorlage von Anfang an oder in einer separaten Phase – wie der Anforderungsphase im traditionellen Wasserfallmodell – vollständig ausgefüllt werden müssen .

Die von gängigen Template-Stilen wie RUP und Cockburn (auch in der OUM-Methode verwendet) formulierten Anwendungsfallformate haben sich in der Praxis als hilfreiche Werkzeuge zur Erfassung, Analyse und Dokumentation komplexer Anforderungen großer Systeme erwiesen. Die Qualität einer guten Anwendungsfalldokumentation ( eines Modells ) sollte nicht primär oder ausschließlich an ihrem Umfang gemessen werden. Ein qualitativ hochwertiges und umfassendes Anwendungsfallmodell eines großen Systems kann durchaus Hunderte von Seiten umfassen, vor allem aufgrund der Komplexität des Problems und nicht aufgrund mangelnder Schreibfähigkeiten der Autoren.

Texteditoren und/oder Textverarbeitungsprogramme mit Vorlagenunterstützung werden häufig zum Schreiben von Anwendungsfällen verwendet. Für große und komplexe Systemanforderungen sind spezielle Tools für Anwendungsfälle hilfreich.

Zu den bekannten Anwendungsfalltools gehören:

• Fall abgeschlossen
• Unternehmensarchitekt
• Zauberzug
• RequisitePro von Rational Software – eines der ersten und bekanntesten Tools für Anwendungsfall- und Anforderungsmanagement in den 1990er Jahren.
• Software-Ideen-Modellierer
• Wiki-Software – gute Werkzeuge für Teams zur gemeinsamen Erstellung und Verwaltung von Anwendungsfällen.

Die meisten UML-Tools unterstützen sowohl die textuelle als auch die visuelle Modellierung von Anwendungsfällen.

• Missbrauchsfall
• Geschäftsmodell
• Entität-Kontrollgrenze
• Ereignispartitionierung
• Besonderheit
• Liste der UML-Tools
• Missbrauchsfall
• Erfordernis
• Anforderungserhebung
• Szenario
• Storyboard
• Testfall
• Anwendungsbeispiele

• Alexander, Ian und Beus-Dukic, Ljerka. Anforderungen ermitteln: Wie man Produkte und Dienstleistungen spezifiziert . Wiley, 2009.
• Alexander, Ian und Maiden, Neil. Szenarien, Geschichten, Anwendungsfälle . Wiley 2004.
• Armour, Frank und Granville Miller. Erweiterte Anwendungsfallmodellierung: Softwaresysteme . Addison-Wesley, 2000.
• Kurt Bittner, Ian Spence, Use Case Modeling , Addison-Wesley Professional, 20. August 2002.
• Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.
• Larry Constantine, Lucy Lockwood, Software for Use: A Practical Guide to the Essential Models and Methods of Usage-Centered Design , Addison-Wesley, 1999.
• Denney, Richard. Erfolgreich mit Anwendungsfällen: Intelligentes Arbeiten für höchste Qualität . Addison-Wesley, 2005.
• Fowler, Martin. UML Distilled (Dritte Auflage) . Addison-Wesley, 2004.
• Jacobson, Ivar; Christerson, M.; Jonsson, P.; Övergaard, G., Objektorientierte Softwareentwicklung – Ein anwendungsfallgetriebener Ansatz , Addison-Wesley, 1992.
• Jacobson, Ivar; Spence, I.; Bittner, K., Use Case 2.0: The Guide to Succeeding with Use Cases , IJI SA, 2011.
• Dean Leffingwell, Don Widrig, Managing Software Requirements: A Use Case Approach , Addison-Wesley Professional. 7. Dezember 2012.
• Kulak, Daryl und Eamonn Guiney. Anwendungsfälle: Anforderungen im Kontext. Addison-Wesley, 2012.
• Meyer, Bertrand. Objektorientierte Softwareentwicklung . (2. Auflage). Prentice Hall, 2000.
• Schneider, Geri und Winters, Jason P. Applying Use Cases 2nd Edition: A Practical Guide . Addison-Wesley, 2001.
• Wazlawick, Raul S. Objektorientierte Analyse und Entwurf für Informationssysteme: Modellierung mit UML, OCL und IFML . Morgan Kaufmann, 2014.

• Spalte „Anwendungsfall“ . Archiviert am 27. Januar 2016 in der Wayback Machine . Vorlage für grundlegende Anwendungsfälle . Archiviert am 13. September 2008 in der Wayback Machine von Alistair Cockburn.
• Anwendungsfälle auf GSA 's Usability.gov
• Anwendungsfälle für die Stakeholderanalyse im Rahmen des Projekts „Icarus“ auf Academia.edu
• Suchen Sie bei IBM Developer nach „Anwendungsfall“.