Freitag, 4. April 2014

Szenarien setzen sich zu Use Cases zusammen.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im Deutschen kann man einen Use Case auch Anwendungsfall nennen. "Ein Anwendungsfall beschreibt anhand eines zusammenhängenden Arbeitsablaufs die Interaktionen mit einem (geschäftlichen oder technischen) System. Ein Anwendungsfall wird stets durch einen Akteur initiiert und führt gewöhnlich zu einem für die Akteure wahrnehmbaren Ergebnis." [S.220, OEST06] "Ein Anwendungsfall spezifiziert Aktionsfolgen (Szenarien) einschließlich Alternativ- und Ausnahmeszenarien, die ein System oder eine Systemkomponente bei der Interaktion mit externen Objekten ausführt, um einen Mehrwert zu erbringen." [S.139, POHL08] Bei der Definition von [OEST06] als auch der von [POHL08] zählen Szenarien, Akteure und Ergebnis bzw. Mehrwert zu den Inhalten eines Use Cases.

Im letzten Post haben wir Szenarien entwickelt. Diese Szenarien waren Hauptszenarien, Alternativszenarien und Ausnahmeszenarien. Jetzt gilt es die Szenarien so zu ordnen, dass sie sich in einem Use Case wiederfinden. Dabei ist es sehr hilfreich, dass jeder Use Case nur ein einziges Hauptszenario enthält. Auf diese Art und Weise können wir recht einfach Use Cases bilden. Jedes Hauptszenario initiiert einen Use Case. Jetzt können wir die verbleibenden Szenarien den jeweiligen Use Cases zuordnen. Alternativszenarien sind andere Wege, das Ziel des Hauptszenarios zu erreichen, und Ausnahmeszenarien beschreiben den Ausstieg im Fehlerfall.

Jedes der zum Use Case zusammengefassten Szenarios war mit der Verwirklichung eines oder mehrerer Ziele verbunden. Dieser Zusammenhang ist auch im letzten Post beschrieben worden. Damit ergibt sich automatisch eine Menge von Zielen, die mit dem Use Case verbunden sind. Der Mehrwert des Use Cases ist somit gesichert.

Die Gesamtheit der Szenarios in einem Use Case nennt [POHL08] ein Use-Case-Szenario. "Ein Use-Case-Szenario ist eine gültige Interaktionsfolge, die sich aus den für den Use Case definierten Haupt-, Alternativ- und Ausnahmeszenarien ergibt und zu einer definierten Terminierung des Use Cases führt. Terminierung bedeutet dabei, dass das Use-Case-Szenario entweder zu der Erfüllung der mit dem Use Case assoziierten Ziele oder zu einem definierten Abbruch führt." [S.140, POHL08]

Die Visualisierung eines Use Cases besteht somit aus einem Use-Case-Diagramm und den Szenarien als Aktivitätsdiagramm. Dabei wäre es das Beste, wenn das Aktivitätsdiagramm aufklappbar wäre. Es wäre vorstellbar, dass man zuerst das Use-Case-Diagramm sieht. In diesem ist eine begrenzte Anzahl von Use Cases sichtbar. Nun könnte man einen Use Case anklicken und ein Aktivitätsdiagramm öffnet sich, welches nur das Hauptszenario zeigt. Auch dieses kann sukzessive um Alternativ- und Ausnahmeszenarios erweitert werden.


Der Use Case enthält ein Hauptszenario.

 Das Haupszenario wird durch Alternativszenarien erweitert.


Haupt- und Alternativszenarien werden durch Ausnahmeszenarien erweitert.



Zu jedem Diagramm gibt es eine tabellarische Beschreibung. Diese erläutert in Textform das Gesehene. Hier kann man auch die Referenzschablonen von [POHL08] verwenden. Er hat unter anderem Schablonen für Szenarien und für Use Cases entwickelt.

Der vorgestellte Weg zeigt eine eindeutige Entwicklungsrichtung auf. Ideen werden zu Themen geordnet. Themen werden Kontextobjekte, User Stories und Zielen zugeordnet. User Stories und Ziele gebären Szenarien und Szenarien werden zu Use Cases zusammengefasst. Diese eindeutige Richtung gibt es nicht. Der Denkprozess ist hier mehr oder weniger eine Kreisbewegung, die mit jedem erfolgten Schritt die Dinge genauer fasst. Ein ungenaues Ziel, eine ungenaue User Story initiiert ein grobes Szenario. Beim Entwickeln des Szenarios verfeinert sich die Zielvorstellung, die wiederum bessere Szenarien initiiert. Die Folgen dieses hin und hers im Denken sind ein immer besseres Modell. Auch später kann sich dieses Modell durch Change Requests ändern.

In unserem weiteren Prozess bilden die Use Cases, die mit Zielen und Szenarien verbunden sind, die geeigneten Denkmodelle, um Anforderungen zu entwickeln. Dabei werden wir die Anforderungen aus unterschiedlichen Perspektiven bedenken: der Datenperspektive, der Funktionsperspektive und der Verhaltensperspektive. Diese werden von [POHL08] als die traditionellen Perspektiven bezeichnet. Wir werden die Perspektiven mit den Modellen der UML im nächsten Post dieser Reihe durchsprechen.

Zum Schluss des Artikels möchte ich noch auf einige Attribute zu sprechen kommen, die zur Beschreibung eines Use Cases wichtig sind. Jeder Use Case sollte einen Namen besitzen. Dieser Name findet sich, genau wie der Akteur im Use-Case-Diagramm wieder. Die Priorität unserer Use Cases müssen wir nicht bestimmen, da die zugehörigen User Stories bereits eine Priorität besitzen und die Use Cases in der Folge als erster Entwicklungsschritt entwickelt wurden. Die Planungsphase ist somit mit den User Stories abgeschlossen. In der Entwicklung sehe ich die Einheit von WIE, GROßES WAS und WAS, in anderen Worten Requirements Engineering, Softwarearchitektur und Programmierung.

Die folgenden Attribute halte ich für die Entwicklung von Testfällen für besonders wichtig. Die Vorbedingung ist "eine Liste notwendiger Voraussetzungen, in denen sich das System unmittelbar vor der Ausführung des Use Case befindet." [S.149, POHL08] Die Nachbedingung ist "eine Liste von Zuständen, in denen sich das System unmittelbar nach der Ausführung des Use Case befindet." [S.149, POHL08] Und das Ergebnis ist die "Beschreibung der Ausgabe, die während der Ausführung des Use Case erzeugt werden." [S.149, POHL08] Auf der Grundlage dieser Attribute ist es möglich, Abnahmekriterien zu entwickeln. "Ein Abnahmekriterium ist eine Anweisung für den Test bezüglich einer Anforderung (oder eines Anforderungsteils), welche die Prüfung und Bewertung des erstellten Produktes oder durchgeführten Prozesses gegenüber dieser Anforderung (oder des Teils) beschreibt." [S.324, RUPP07] "[RUPP07] fordert drei Qualitätsmerkmale für Abnahmekriterien. Sie müssen testbar sein, also durchführbar, messbar und reproduzierbar. Sie müssen vollständig in Bezug auf die Anforderungen sein, für die sie entwickelt wurden, aber sie müssen auch minimal sein, damit der Testaufwand im Rahmen bleibt." [BAU09]

Das Entwickeln von Abnahmekriterien in Bezug auf Use Cases vermeidet eine Inflation von Abnahmekriterien. Der Kunde ist verpflichtet, eine überschaubare Menge von Kriterien anzugeben, unter denen er bereit wäre, das Produkt abzunehmen. Natürlich können auch zu den spezifischen Anforderungen Abnahmekriterien entwickelt werden. Meiner Erfahrung nach ist es jedoch oft sehr schwierig, den Kunden mit so hohen Verpflichtungen in ein Projekt einzubinden. Ganz aus der Verantwortung sollte man ihn jedoch auch nicht entlassen. Für den Idealfall bin ich sowieso der Meinung, dass die Hauptarbeit der Anforderungsentwicklung durch den Kunden mit Hilfe des Entwicklungsteams geschehen sollte. Der Kunde sollte die Farbe des Anzugs bestimmen und nicht der Schneider. Der kann den Kunden beraten, aber nicht bestimmen.

  • [BAU09] Ralf Baumann: "Entwicklung eines Arbeitsablaufes für die Entwicklung von Anforderungen an eine Software durch den Auftraggeber.", Diplomarbeit an der FH Trier, 2009
  • [OEST06] Bernd Oestereich: „Analyse und Design mit UML 2.1“, 8., aktualisierte Auf- lage, Oldenbourg Wissenschaftsverlag GmbH, München, 2006
  • [POHL08] Klaus Pohl: „Requirements Engineering“, 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008
  • [RUPP07] Chris Rupp & SOPHISTen: „Requirements Engineering und – Management“, 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen