t2informatik » Wissen kompakt » Use Case

Was ist ein Use Case?

Welche Konzepte von Use Cases gibt es, wie werden sie visualisiert und in der Entwicklung genutzt?

Use Case Definition

Mit einem Use Case – auch Anwendungsfall genannt – wird das Verhalten eines Systems aus Anwendersicht beschrieben. Use Cases dokumentieren die Funktionalität eines vorhandenen oder geplanten Systems mit einfachen Modellen. Der Anwender bzw. Nutzer ist eine Person, eine Rolle, eine Organisation oder ein anderes System. Er tritt als Akteur mit einem System in Interaktion, um ein bestimmtes Ziel in einer definierten Folge von Aktionen zu erreichen. Aus dem Ziel ergibt sich normalerweise der Name des Anwendungsfalls.

Use Cases werden bereits seit Anfang der 90er Jahr in der Softwareentwicklung, bei der Systemerstellung und auch in der Produktentwicklung genutzt. Auch heutzutage sind sie sehr beliebt, denn das gemeinsame Verständnis der Interaktion zwischen Akteur und System wird durch ihre Verwendung deutlich erhöht und aus den Zielen der Akteure lassen sich funktionale Anforderungen und entsprechende Testfälle ableiten.

Use Case Konzept

Ivar Jacobson präsentierte 1987 das Konzept der Use Cases. Er definierte einen Use Case als „a special sequence of transactions, performed by a user and a system in a dialogue“. Das Konzept umfasst zwei Ansätze, die sich gemeinsam nutzen lassen:

Use Case Spezifikationen enthalten natürlich-sprachliche Informationen zur Systematik der Interaktionen eines Anwendungsfalls (sogenannte „Narratives“). Idealerweise werden diese Informationen mit einer Vorlage textuell erfasst. Diese Vorlage sollte mindestens folgende Elemente umfassen:

  • Name des Use Cases und Use Case Nummer zwecks eindeutiger Identifizierung
  • Akteure
  • Auslöser
  • Kurzbeschreibung
  • Beschreibung der essentiellen Schritte als Standardablauf
  • Beschreibung von alternativen Abfolgen
  • Vorbedingungen und Nachbedingungen
  • Beschreibung der Systemgrenzen

Zusätzlich empfiehlt es sich, Referenzen auf andere Use Cases oder Dokumente, die Häufigkeit, die Priorität und gegebenenfalls auch Invarianten als nicht abänderbare Bedingungen zu erfassen. Hier finden Sie eine Use Case Vorlage zum Download »

Use Case Diagramme visualisieren Anwendungsfälle und Akteure mit ihren jeweiligen Beziehungen. Sie liefern einen guten Überblick über das Gesamtsystem, beschreiben aber im Gegensatz zu den Use Case Spezifikationen keine Abläufe, sondern die Zusammenhänge zwischen einer Menge von Anwendungsfällen und den daran beteiligten Akteuren. Sie gelten damit als grafische Repräsentation von Use Cases und die Unified Modeling Language (UML) definiert sie als Verhaltensdiagramm. Die wichtigsten Modellelemente sind hierbei:

  • Akteure
  • Anwendungsfälle
  • Beziehungen
  • Systemgrenzen

Spezifikationen und Diagramme lassen sich gemeinsam verwenden und bieten so eine sich ergänzende Sicht auf das Verhalten eines Systems.

Arten von Use Cases

Es gibt zwei Arten von Use Cases: Black-Box und White-Box Use Cases. Bei einem Black-Box Use Case wird dokumentiert, was ein System leisten soll und nichtwie es dies leisten soll. Die Black-Box-Ansicht zeigt, wie ein System von außen aussieht, einschließlich der erforderlichen und bereitgestellten Schnittstellen, sowie der Beziehung zu anderen Systemen. Eine Black-Box-Ansicht beschreibt aber nicht die interne Implementierung eines Systems. Ein White-Box Use Case dokumentiert hingegen, welche Klassen, Schnittstellen und anderen Komponenten einer Komponente helfen, die gewünschte Funktionalität bereitzustellen. In der Praxis werden Use Cases meist als Black-Box beschrieben.

Use Cases werden auch in Geschäftsanwendungsfälle und Systemanwendungsfälle aufgeteilt. So kann es bspw. für den Geschäftsanwendungsfall „Reise reservieren“ mehrere Systemanwendungsfälle wie bspw. „Telefonische Reise reservieren“ oder  „Online Reise reservieren“ geben.

Testen mit Use Cases

Die Verwendung von Black-Box Use Cases stellt Unternehmen vor Herausforderungen bei der Ableitung von Testfällen. Hier können bspw. formale Notationen wie Aktivitäts- oder Zustandsdiagramme als Ergänzung helfen, denn aus ihnen lassen sich Test Cases relativ leicht ableiten. Zusätzlich sind die Vor- und Nachbedingungen eines Use Cases eine gute Quelle für Testfälle. Da Anwendungsfälle aber untereinander Beziehungen oder parallele Abläufe haben, reicht es nicht aus, jeden Use Case getrennt zu betrachten, um ein Gesamtsystem zu testen.

Der Nutzen von Use Cases

Unternehmen entwickeln Produkte, Software oder Systeme, die einen Nutzen stiften sollen. Häufig sollen Aufgaben schneller, besser, sicherer oder einfacher erfüllt werden. Der Kunde soll das Produkt nutzen, um damit sein Ziel zu erreichen. Was passiert aber, wenn das Ziel unklar und nicht eindeutig definiert ist? Im schlimmsten Fall wird der Kunde das Produkt nicht verwenden, da es ihm keinen oder nur einen geringen Nutzen bietet.

Anwendungsfälle zeigen das Big Picture eines zu entwickelnden Systems. Ohne dieses Big Picture fehlt es oftmals an Orientierung und in der Folge lassen sich Entscheidungen über den Scope – was ist zu entwickeln, was lässt sich später entwickeln oder was kann sogar weggelassen werden – nur schwer treffen. Unvollständige oder unklare Anforderungen behindern die Entwicklung und den Markterfolg. Änderungen müssen nachträglich implementiert werden. Je später dies geschieht, desto schwieriger und teurer wird die Entwicklung.

Hilfreiche Fragen für die Erstellung

Es gibt einige Fragen, die bei der Erstellung von Use Cases helfen:

Fragen zum Akteur

  • Wer nutzt das System?
  • Was ist das Ziel des Akteurs?
  • Welche anderen Systeme interagieren mit dem System?
  • Wer liefert dem System Informationen oder erhält Information?

Fragen zu den Vor- und Nachbedingungen

  • Welche Bedingung muss erfüllt sein, damit der Use Case eintritt?
  • In welchem Zustand befindet sich das System, wenn der Use Case eintritt?
  • Wie und unter welcher Bedingung wird der Anwendungsfall abgeschlossen?
  • In welchem Zustand muss sich das System befinden, so dass der Anwendungsfall abgeschlossen wird?

Fragen zu den Abläufen

  • Welcher Akteur und welches Event initiiert die Ablauffolge?
  • Wie interagiert der Akteur mit dem System und wie reagiert das System?
  • Welche alternativen Aktionen kann der Akteur bei jedem Schritt initiieren?
  • Welche Unterbrechungen oder Fehler können bei jedem Schritt des Use Cases auftreten?
  • Was passiert, wenn der Akteur den Vorgang abbricht?

Sonstige Fragen

  • Mit welcher Frequenz wird der Anwendungsfall ausgeführt?
  • Welche Beziehungen gibt es zu anderen Anwendungsfällen?

Use Case Vorteile

Ein Use Case ist leicht zu verstehen und relativ einfach zu erstellen, denn sowohl die Interaktion zwischen Akteur und System als auch die Beziehung zwischen verschiedenen Use Cases lassen sich gut abstrahieren. Dabei eignen sich Anwendungsfälle als Quelle für die Ermittlung von Anforderungen, die sich aus diesen Interaktionen ergeben. Zusätzlich nutzen Unternehmen Use Cases auch oft für Verfeinerungen von umfangreichen Anforderungen mittels Zerlegung der Interaktionen zwischen Akteur und System, denn dadurch steigt das Verständnis der Beteiligten. Und mit der Kombination von textuellen Beschreibungen in Spezifikationsdokumenten und der Visualisierung per Diagramm gewinnen Organisationen gleichzeitig nützliche Detailinformationen und einen guten Überblick über das gesamte System. 

Was sind Use Case Diagramme?

Die Idee von Use Case Diagrammen

Ein Use Case Diagramm ist eine Darstellung, die das Verhalten eines Systems aus Anwendersicht visualisiert. Es ist eine grafische Repräsentation von Anwendungsfällen inklusive deren Beziehungen zur Umwelt und zu anderen Anwendungsfällen. Damit beschreibt ein Use Case Diagramm – auch Anwendungsfall- oder Nutzfalldiagramm genannt – in einer hohen Abstraktion, welche Funktionen und Dienste ein System für einen Anwender bereitstellt. Mit einem Use Case Diagramm werden aber weder die Abläufe des Systems beschrieben, noch die Reihenfolge der Funktionen oder Dienste dargestellt. Für die Definition einer Ablaufreihenfolge bieten sich andere Verhaltensdiagramme der UML an, wie bspw. Aktivitäts-, Zustands-, Sequenz- oder Kommunikationsdiagramme. Ein Use Case Diagramm visualisiert lediglich die Zusammenhänge zwischen einer Menge von Use Cases und den involvierten Akteuren. Damit eignet es sich sehr gut zur Anforderungsanalyse, also zur Ermittlung oder Verfeinerung von Anforderungen.

Die Diagramm Elemente

Folgende Elemente werden in einem Nutzfalldiagramm visualisiert:

  • Das System ist an sich kein logisches Modellelement, sondern grenzt den Kontext ab. Dieser Systemkontext wird durch einen Rahmen im Diagramm repräsentiert, in dem das System seine Funktionen und Dienste zur Verfügung stellt.
  • Der Akteur befindet sich außerhalb des Systems. Er wird als Strichmännchen gezeichnet und kann eine konkrete Person aber auch ein abstraktes Element wie bspw. ein Sensor sein. Die Verfeinerung von Akteuren kann per UML Profil erfolgen. Wird ein Akteur definiert, muss dieser auch immer mit mindestens einem Use Case in Verbindung stehen. Sind mehrere Akteure involviert, wird dies durch die Multiplizität ausgedrückt. Ohne weitere Angabe ist diese standardmäßig 1. 
  • Ein Anwendungsfall wird meist als Ellipse visualisiert, wobei sein Name auch außerhalb der Ellipse stehen kann. Ein Diagramm kann mehrere Anwendungsfälle umfassen. Ist ein Use Case nur durch andere Anwendungsfälle ausführbar, wird er als abstrakt bezeichnet. Auch für Use Cases lässt sich die Multiplizität darstellen; sie gibt Auskunft darüber, wie häufig der Anwendungsfall gleichzeitig ausgeführt werden kann.
  • Akteure und Anwendungsfälle stehen ebenso miteinander in Beziehung wie Anwendungsfälle untereinander. Grundsätzlich können vier verschiedene Beziehungen bzw. Beziehungsarten in einem Diagramm verwendet werden: Assoziation, Include-Beziehung, Extend-Beziehung und Generalisierung. Beziehungen werden mit gestrichelten oder durchgezogenen Linien und Pfeilen modelliert. Die Richtung der Beziehung sollte nicht als Datenfluss verstanden werden; sie beschreibt bspw. welcher Use Case einen anderen erweitert.
  • Mit Notizen lassen sich Informationen hinzufügen, um das Verständnis zu erhören. Sie werden mit einem Rechteck dargestellt, dessen obere rechte Ecke eingeknickt ist. Eine gestichelte Linie verbindet die Notiz mit dem zu erklärenden Element.

Die Assoziationsbeziehung

Wenn ein Akteur mit einem Anwendungsfall kommuniziert, wird dies als Kommunikationsbeziehung oder Assoziation bezeichnet. Die Richtung der Linie beschreibt welcher Teil aktiv und welcher passiv ist. Fließt der Pfeil vom Akteur zum Use Case ist der Akteur aktiv und stößt den Use Case an. Fließt der Pfeil vom Use Case zum Akteur ist der Use Case aktiv und fordert den Akteur auf teilzunehmen.  

Die Include-Beziehung

Die Include-Beziehung verbindet einen primären bzw. Basis-Use Case mit einem oder mehreren sekundären Use Cases. Die Modellierung einer Include-Beziehung bietet sich an, wenn Teile von Anwendungsfällen in mehreren Use Cases vorkommen. So lassen sich redundante Beschreibungen vermeiden. Sekundäre Use Cases werden in der Praxis häufig mit dem Stereotyp «secondary» gekennzeichnet, auch wenn die UML dies nicht vorsieht. Fünf Aspekte sind bei Include-Beziehungen zu beachten:

  1. Ein inkludierter Use Case wird IMMER ausgeführt, wenn der einbindende Use Case ausgeführt wird. Der Zeitpunkt der Ausführung lässt sich jedoch im Diagramm nicht spezifizieren; hierfür bietet sich die Spezifikation an.
  2. Ein inkludierter Use Case kann auch separat ausgeführt werden.
  3. Primäre und sekundäre Use Cases sollten auf ähnlichen Abstraktionsniveaus beschrieben werden. Eine Detaillierung in inkludierten Use Cases gilt es zu vermeiden.
  4. Beschreibungen können durch Include-Beziehungen beliebig oft verwendet werden.
  5. Im Gegensatz zu einer Generalisierung werden keine Eigenschaften vererbt.

Die Enthält-Beziehung ist in einem Use Case-Diagramm durch einen gestrichelten Pfeil und der Beschriftung include dargestellt. Der Pfeil zeigt auf den inkludierten Use Case.

Die Extend-Beziehung

Werden Teile eines Anwendungsfalls nur unter definierten Bedingungen ausgeführt, bietet sich die Verwendung der Extend-Beziehung an. Die Extend-Beziehung erweitert also den Basis-Use Case um eine Funktionalität. Beispiel: Sie müssen jedes Jahr Ihre Einkünfte per Steuererklärung deklarieren (Basis-Use Case) und ab einer definierten Einkommenshöhe müssen Sie Belege beifügen (Erweiterung des Basis-Use Cases). Der Basis-Use Case entscheidet somit, ob der erweiternde Anwendungsfall – mit dem nicht zwingend ein Akteur verbunden sein muss – ausgeführt wird. Beide Fälle lassen sich separat ausführen. Eine Extend-Beziehung wird durch einen gestrichelten Pfeil mit der Beschriftung extend visualisiert. Der Pfeil zeigt immer auf den Basis-Use Case.

Der erweiterte Anwendungsfall kann durch sogenannte Erweiterungspunkte bzw. Extension Points detailliert beschreiben werden. So lässt sich das Ereignis oder der Zeitpunkt dokumentieren, an dem das ursprüngliche Verhalten erweitert wird. Auch Bedingungen können definiert werden; tritt eine Bedingung ein, wird die Erweiterung ausgeführt. Ein Anwendungsfall kann beliebig viele Erweiterungspunkte besitzen.

Die Generalisierung

Es gibt zwei Ausprägungen einer Generalisierung in einem Nutzfalldiagramm:

  1. Zwischen Akteuren und
  2. zwischen Anwendungsfällen.

Stellen Sie sich vor, es gibt zwei Akteure: einen Obst- und einen Salatverkäufer. Da beide Eigenschaften besitzen, die sie sich teilen, lässt sich daraus ein allgemeiner Akteur ableiten: ein Verkäufer. Der Vorteil einer solchen Generalisierung liegt in der allgemeinen und abstrakten Beschreibung des neuen Akteurs Verkäufer und in der Verbindung der mit anderen Use Cases, die nur für die Spezialisten (Obst- oder Salatverkäufer) gelten. Häufig spricht man daher auch von Spezialisierung.

Genauso wie Akteure lassen sich auch Anwendungsfälle generalisieren. Im Use Case Diagramm zeigt die Generalisierung immer in Richtung des generelleren Elements, daher stammt auch die Bezeichnung Generalisierung. Diese Art der Verbindung wird auch ist-eine-Art-Beziehung genannt, da die spezielleren Use Cases und Akteure alles vom generelleren Element „erben“.

Was ist Use Case 2.0?

Die Idee von Use Case 2.0

Anwendungsfälle sind sehr nützlich bei der Identifikation von Anforderungen. In der Praxis sind sie aber oftmals zu umfangreich, um bspw. innerhalb eines Sprints in Scrum realisiert werden zu können. Die Frage lautet also: Wie können Unternehmen mit Anwendungsfällen agil planen? Die Antwort haben Ivar  Jacobsen und seine Mitautoren Ian Spence und Kurt Bittner im Dezember 2011 mit dem Buch USE-CASE 2.0 – The Guide to Succeeding with Use Cases geliefert. Sie lautet: Ein Use Case wird entlang seiner Abläufe in Scheiben geschnitten, die jeweils innerhalb eines Sprints realisiert werden können. Das Vorgehen nennt sich slicing, das Ergebnis sind Use Case Slices.

Prinzipien von Use Case 2.0

Use Case 2.0 basiert insgesamt auf sechs Prinzipien:

  • Beschreibe Dinge einfach mit Storys
  • Verstehe das Big Picture
  • Stelle den Nutzen des Akteurs in den Mittelpunkt
  • Erstelle das System in Slices
  • Liefere das System in Inkrementen
  • Passe das Vorgehen an die Bedürfnisse des Teams an

Wie lassen sich diese Use Case 2.0 Prinzipien in der Produktentwicklung nutzen? Zuerst gilt es die Akteure zu identifizieren, die mit dem System arbeiten.  Welche Ziele verfolgen diese Akteure? Es ist wichtig, diese Ziele zu verstehen, denn Anwendungsfälle dienen immer dazu, Ziele der Anwender zu erreichen. Auf dieser Grundlage können Sie damit beginnen, Use Cases zu ermitteln. Dazu gibt es zwei Optionen:

  1. Top Down – also vom Use Case ausgehend einzelne Schritte, Abläufe und Alternativen ermitteln.
  2. Bottom Up – also beispielsweise per Brainstorming, Brainwriting oder Braindumping verschiedene Abläufe sammeln und zu Anwendungsfällen zusammenfassen.

Beide Optionen lassen sich auch miteinander kombinieren. Es ist hilfreich, gleichzeitig zur Beschreibung der Abläufe – jeder sinnvolle Weg durch einen Anwendungsfall wird als Use Case Story bezeichnet – Testfälle zu entwickeln. Sobald Use Case Storys definiert sind, können Use Case Slices gebildet werden. 

Use Case 2.0 setzt nicht voraus, dass alle Anwendungsfälle vollständig definiert werden, bevor Ihre Realisierung beginnt. Ein solches Vorgehen wäre alles andere als agil. Die Identifikation einiger zentraler Use Cases ist die Basis für die Definition der ersten Slices, die als solche direkt in das Backlog aufgenommen werden können. Ein Use Case muss auch nicht komplett in Slices zerlegt werden – es reicht aus, die Slices, die für die Planung des nächsten Sprints notwendig sind, nach Bedarf zu definieren.

Den drei Autoren von Use Case 2.0 war natürlich bekannt, dass es keine einheitliche Lösung für alle Herausforderungen bei der Entwicklung von Software und Systemen gibt. Kleine, kollaborative Teams können mit einfachen Karteikarten, große, verteilte Teams mit umfassenden Anwendungsfalldokumenten und spezialisierten Tools arbeiten. Für eine Organisation ist es wichtig, ein Vorgehen zu wählen, dass zur Organisation passt und den größten Nutzen bietet.

Use Case Slices definieren

Es gelten die folgenden Regeln zur Bildung von Use Case Slices:

  • Use Case Slices müssen so klein geschnitten werden, dass sie in einem Sprint umgesetzt werden können.
  • Die erste Use Case Story wird als Basic Flow bezeichnet. Sie wird als erstes realisiert.
  • Ein Slice wird immer vertikal, also entlang einer oder mehrerer Use Case Storys, geschnitten. Er kann auch mehrere Use Case Storys umfassen.
  • Jeder Slice benötigt mindestens einen Testfall
  • Wenn zwei Use Case Slices dieselben Use Case Storys enthalten, müssen sie sich durch ihre Testfälle unterscheiden.
  • Unklare Use Case Storys können nicht in die agile Planung aufgenommen werden. Hier macht die Verwendung von Technical Storys oder Spike Storys Sinn.

Slice the Slice

Was passiert, wenn ein Use Case Slice für einen Sprint zu groß ist? Die Antwort lautet: Slice the Slice. Oder auf Deutsch: Verkleinern Sie den Slice so weit wie möglich. Lässt er sich aber nicht weiter verkleinern, sollten Organisation bei der Einplanung und Realisierung folgende agile Regeln beachten:

  • Durch die Implementierung des Slices entsteht ein Stück funktionierende Software.
  • Durch die Implementierung des Slices entsteht ein Wert für den Anwender.
  • Die Implementierung des Slices ermöglicht ein Feedback des Anwenders.

Sind diese Regeln erfüllt, kann ein zu großer Use Case Slice durch mehrere kleine Use Case Slices ersetzt werden, die jeweils Teil-Storys mit zugehörigen Testfällen enthalten. Diese Use Case Slices für die Teil-Stories werden im Backlog Grooming aufbereitet und priorisiert, im Sprint Planning eingeplant, im Sprint implementiert und im Sprint Review geprüft. Sind alle Teil-Storys implementiert, müssen die Testfälle des ursprünglichen Use Case Slices durchlaufen werden. Sind alle Use Case Storys implementiert, müssen die Testfälle des ursprünglichen Use Cases geprüft werden.

Was sind Misuse Cases?

Die Idee von Misuse Cases

Die Verwendung von Misuse Cases ergänzt die Idee der Use Cases um einen zusätzlichen Blickwinkel. Ein Misuse Case ist ein missbräuchlicher Anwendungsfall. Er beschreibt eine Interaktion, die ein System nicht zulassen und sogar verhindern sollte. Erstmals beschrieben wurden missbräuchliche Anwendungsfälle 2001 von Guttorm Sindre und Andreas Lothe Opdahl. Die beiden norwegischen Professoren waren im Bereich der Entwicklung von Informationssystemen tätig und veröffentlichten Capturing Security Requirements through Misuse Cases. Genau wie ein Use Case eine Interaktionsfolge mit dem System darstellt, durch die ein Akteur ein Ziel verfolgt und die einen Wert für ihn schafft, beschreibt auch ein Misuse Case eine Interaktionsfolge – allerdings eine, die mit einem Verlust für den Akteur, für die Organisation, die das System zur Verfügung stellt, oder für Stakeholder endet.

Beispiele für Misuse Cases

Gerade im Bereich Safety & Security sind Misuse Cases leicht zu verstehen und anzuwenden. Sie bieten Organisationen die Chance, wichtige Qualitätsanforderungen für die Entwicklung von sicheren Systemen zu entdecken. Hier finden Sie eine Liste mit einigen Misuse Cases – die Namensgebung orientiert sich am Ziel des MisActors:

  • Daten und Identitäten von Internetnutzern nutzen, um …
  • Mit fremden Kreditkartendaten Waren bestellen und bezahlen.
  • Die Bewegungsdaten von Handys oder Autos ohne Zustimmung verwenden, um …
  • Mit Abmahnungen wegen möglicher Urheberrechtsverletzungen Geld verdienen.
  • Autos mittels Signalverlängerungen bei „Keyless“-Systemen entwenden, um …

Im Wesentlichen lässt sich jede Zweckentfremdung eines Produkts und jeder Diebstahl als Misuse Case verstehen. Bei manchen Misuse Cases werden Unternehmen versuchen, sichernde Maßnahmen zu ergreifen. Anfang 2018 eröffnete in China die weltweit erste Solar-Autobahn. Kurze Zeit später wurden die ersten Solar-Panel gestohlen. Gegen solche Missbräuche werden sich Organisationen sicherlich schützen, bei anderen kann der Staat Regeln und Gesetze erlassen (Spraydosen nur an Lackierereien verkaufen und somit Sachbeschädigungen durch Graffiti reduzieren) und bei manchen kann nichts dagegen unternommen werden (mit Benzin werden Autos angetrieben und mancherorts auch angezündet).

Vorteile von Misuse Cases

Misuse Cases sind leicht anzuwenden und bieten eine Reihe von Vorteilen:

  • Die Qualität der Entwicklung steigt, da sich nicht-funktionale Anforderungen leichter identifizieren lassen.
  • Projektbeteiligte verstehen das zu entwickelnde System besser und umfassender.
  • Eine Gefahrenanalyse ist frühzeitig möglich und ein Wertverlust für die Organisation bzw. Stakeholder lässt sich verhindern.
  • Potentielle Angriffspunkte und Schwächen im System lassen sich leichter identifizieren.
  • Misuse Cases sind durch Testfälle prüfbar – im Sinne von: Verhinderung einer unerwünschten Funktionalität.

Misuse Cases visualisieren

Misuse Cases lassen sich in Form von Use Case Diagrammen am Flipchart oder mit einer professionellen Software erstellen. Manche Tools bieten die Verwendung von Sub-Stereotypen der Enthält- und Erweiterungsbeziehung an: Aus «include» und «extend» werden «attacks» und «prevents». Idealerweise handelt es dabei nicht nur um „freien Text“, denn dadurch lassen sich Misuse Cases und ihre Beziehungen auswerten und in der Folge Qualitätsanforderungen ableiten. Der Akteur im Misuse Case, der einen Schaden verursacht, wird übrigens als MisActor bezeichnet.

Misuse Cases erstellen

Häufig werden Sicherheitsanforderungen an ein System sehr allgemein formuliert. Dadurch sind sie schwer zu realisieren und zu überprüfen. Selbst die Erstellung von Use Cases fällt so schwer, denn normalerweise eignen sich Anwendungsfälle nur für die Ermittlung von funktionalen Anforderungen. Hier hilft eine Frage: Was soll das System nicht können? Oder: was soll das System verhindern?

Folgendes Vorgehen hat sich etabliert:

  • Use Cases definieren und visualisieren, sowie Anforderungen ermitteln.
  • Potenzielle Gefahren auf Basis der einzelnen Use Cases inklusive der MisActors ableiten.
  • Misuse Cases mit den bedrohten Use Cases in Beziehung setzen.
  • Ableiten von Anforderungen, die Misuse Cases verhindern.
  • Beschreiben von Testfällen – dabei ist zu bedenken, dass ein Misuse Case in einer Weise überprüft wird, ob eine unerwünschte Funktionalität erfolgreich verhindert wird.

Misuse Cases implementieren

Misuse Cases werden nicht implementiert und eine Beschreibung mit Hilfe von Use Case Storys ist auch nicht sinnvoll, aber der etwas andere Blickwinkel auf ein System ermöglicht es, zusätzliche Anforderungen zu ermitteln. Gerade im Bereich Safety & Security ist diese Herangehensweise leicht zu verstehen und anzuwenden. Sie bietet Organisationen die Chance, wichtige Qualitätsanforderungen für die Entwicklung von sicheren Systemen zu entdecken. Laut dem Kano-Modell haben solche Anforderungen eine große Bedeutung für die Zufriedenheit der Kunden.

Use Case Whitepaper - t2informatik Download Vorschau

Jetzt das Use Case Whitepaper kostenlos downloaden.

Alles Wichtige über Use Cases, Use Case Diagramme, Use Case Diagramme und Misuse Case auf 14 Seiten zum Mitnehmen.

Hier klicken »

Herausforderungen für Unternehmen

Die konsequente Nutzung von Use Cases

Mit Use Cases lässt sich ein System aus Anwendersicht gut beschreiben und verstehen. Die erste Herausforderung für Unternehmen beim Arbeiten mit Use Cases ist das Finden der Themen und Inhalte. Je mehr Mitarbeiter daran beteiligt sind, desto aufwendiger wird dieser Schritt. Gleichzeitig werden die Ergebnisse und die daraus gewonnenen Anforderungen detaillierter. Beim Formulieren von Anwendungsfällen sollten Organisationen darauf achten, detaillierte Beschreibungen zu erstellen, die nicht zu kompliziert formuliert werden. Hier ist etwas Übung gefragt. Die Verwendung von Standardtexten bei der Beschreibung der Auslöser und der Vor- und Nachbedingungen ist nicht zu empfehlen. Oftmals lassen sich auch aus den Vor- und Nachbedingungen Reihenfolgen zur Umsetzung ableiten: ein Use Case mit der Nachbedingungen X  kann vor einem Use Case mit der Vorbedingung X  umgesetzt werden. Bei der Umsetzung selbst ist das Zerschneiden von Anwendungsfällen in Slices, die innerhalb eines Sprints realisiert werden, sehr nützlich. Auch die Verwendung von Misuse Cases trägt in der Praxis aktiv zur Kundenzufriedenheit bei, zumal sie sich auch per Anwendungsfalldiagramm visualisieren lassen. Durch die Visualisierung können sich Hersteller besser in die Lage Ihrer Anwender versetzen und spezifische Anforderungen ermitteln. 

Eine große Herausforderung für Unternehmen ist die Bewertung der Anwendungsfälle – sowohl in wirtschaftlicher als auch technischer Hinsicht. Hier müssen Unternehmen regelmäßig abwägen, ob sie diejenigen Use Cases zuerst realisieren, die technisch oder fachlich einen großen Anwenderkreis adressieren, oder solche, die einen kleineren Kreis ansprechen, der gegebenenfalls eine größere finanzielle Auswirkung hat.

Grundsätzlich bietet das Arbeiten mit Use Cases, Anwendungsfalldiagrammen, Use Case 2.0 und Misuse Cases ein umfassendes Konzept, um Systeme nicht nur im Detail sondern als Ganzes gut zu verstehen. Unternehmen müssen lediglich die Konzepte konsequent und passend zur Organisation anwenden.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Beschreibung von Use Cases und der Erhebung, Strukturierung und Verwaltung von Anforderungen. Dabei achten wird auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir unterstützen Sie beim Identifizieren von technischen Zusammenhängen und berücksichtigen Stakeholder, Ziele und Randbedingungen. Und wir planen und steuern Ihre Projekte mit diesen Anforderungen auf Basis definierter Prozesse.

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe

 

Share This