Freitag, 30. Mai 2014

Die Vielfalt der Szenarien.

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.


In den letzten Posts wurden funktionale Anforderungen mit Hilfe von Szenarien entwickelt. Diese Szenarien wurden als Haupt-, Alternativ- und Ausnahmeszenarien in Use Cases zusammengefasst. Auch beim Auffinden von Qualitätsanforderungen können uns Szenarien erheblich weiterhelfen. Deshalb möchte ich als erstes vertiefend auf weitere Szenariotypen eingehen. Die unterschiedlichen Typen erlauben uns einen Betrachtungsgegenstand aus unterschiedlichen Perspektiven zu betrachten.

[POHL08] hat in seinem Buch eine sehr gute Kategorisierung von Szenariotypen durchgeführt. In einer ersten Überlegung suchen wir nach Szenarien, die immer zu einem positiven Ergebnis führen. Schon im nächsten Schritt entwickeln wir Szenarien, die das geforderte Ergebnis nicht erfüllen können. Ein letzter Gedankengang lässt uns Missbrauchsszenarien entwickeln. "Ein Missbrauchsszenario beschreibt eine unerwünschte Verwendung des Systems, d.h. eine Folge von Interaktionsschritten, die das System nicht gestatten soll." [S.128, POHL08] Diese Typisierung unterteilt Szenarien also in positive, negative und Missbrauchsszenarien.



In einer weiteren Typisierung findet [POHL08] deskriptive, explorative und erklärende Szenarien. "Ein deskriptives Szenario wird zu dem Zweck erstellt, Abläufe und Interaktionen zu verdeutlichen und dadurch Ziele und lösungsorientierte Anforderungen aufzudecken sowie zu konkretisieren." [S.128, POHL08] "Ein exploratives Szenario ist ein Szenario, das zum Zweck der Analyse und Bewertung alternativer Lösungsmöglichkeiten erstellt wird." [S.129, POHL08] "Ein erklärendes Szenario ist ein Szenario, das zum Zweck erstellt wird, Interaktion sowie Interaktionsfolgen zu erklären bzw. die Notwendigkeit einzelner Interaktionen und Interaktionsfolgen zu erläutern." [S.130, POHL08]



Eine weitere Unterteilung ist die Kategorisierung in Instanz- und Typszenarien. Ein Instanzszenario beschreibt dabei eine konkrete Interaktionsfolge mit einer Eingabe und einer Ausgabe. [POHL08] erwähnt, dass man solche Instanzszenarien auch als User Stories bezeichnet. Für mich ist die User Story eher die Erinnerung an die Aufgabe, ein solches Szenario zu entwickeln. Was hier allerdings nochmals deutlich wird, User Stories und Szenarien hängen eng zusammen. "Typszenarien beschreiben eine Menge von Instanzvariablen." [S.131, POHL08] Typszenarien fassen mehrere Instanzvariablen zusammen. Sie abstrahieren in Richtung der Zusammenfassung, z.B. eines Use Cases. Im Post Szenarien setzen sich zu Use Cases zusammen wurden jeweils ein Hauptszenario und die zugehörigen Alternativ- und Ausnahmeszenarien zu einem Use Case vereint. Dieses Gesamtszenario nennen wir Typszenario.



Eine weitere Unterteilung ordnet die Szenarien nach dem Ort, an dem sie stattfinden, im System, außerhalb des System oder als Kommunikation zwischen Kontext und System. Aus diesem Grund heißen diese Szenarien systeminterne-, Interaktions- und Kontextszenarien. "Ein systeminternes Szenario betrachtet systeminterne Interaktionen in Form von Interaktionsfolgen zwischen Systembestandteilen." [S.132, POHL08] "Ein Interaktionsszenario beschreibt Interaktionen zwischen dem System und den Systemnutzern [Personen und System] im Kontext des Systems." [S.134, POHL08] "Ein Kontextszenario beinhaltet neben den direkten Interaktionen zwischen dem System und dem Systemnutzern weitere Kontextinformationen, die für das System und seine Verwendung wichtig sind." [S.135, POHL08] Diese drei Szenarien werden in der vorher beschriebenen Reihenfolge auch als Typ-A-Szenario, Typ-B-Szenario und Typ-C-Szenario bezeichnet.



Die letzte Unterteilung, die [POHL08] vornimmt, ist die in Haupt-, Alternativ- und Ausnahmeszenarien. Diese haben wir bereits in den zurückliegenden Posts ausführlich besprochen. Wir stellten dabei fest, dass ein Use Case immer genau ein Hauptszenario besitzt. Betrachten wir dieses Hauptszenario unter Verwendung der anderen Szenariotypen, so ist es ebenfalls ein positives Szenario, ein deskriptives Szenario, ein Instanzszenario und ein Interaktionsszenario. Wie Eingangs erwähnt, helfen Szenarien jedoch nicht nur beim Finden und Beschreiben von Use Cases, sie helfen genauso beim Auffinden und beim Beschreiben von Qualitätsanforderungen.



Die Dokumentation von Szenarien erfolgte bei uns durch Aktivitätsdiagramme. Das wurde im Post Szenarien setzen sich zu Use Cases zusammen beschrieben. Weiterhin ist es möglich, eine tiefere tabellarische Erläuterung der Interaktionsschritte durchzuführen. Allerdings sollte man dabei vermeiden zu viele Redundanzen aufzubauen, weil diese natürlich zu mehrfacher Pflege führen. Die notwendige Änderung an mehreren Stellen kann jedoch vergessen werden und das führt in der Folge zu Widersprüchen in der Dokumentation.

Am Schluss möchte ich noch ein Wort über das Auffinden von Szenarien verlieren. Der beste Weg ist die gemeinsame Suche im Team. Dabei spielt der gemeinsame Sachverstand eine große Rolle. Wir verfügen vor dem Szenario über Zielmodelle, User Stories und ggf. über Checklisten. Anhand der Ziele, der User Stories und der Stichpunkte in den Checklisten können wir gemeinsam Szenarien entwickeln. Dies sollte in Räumen geschehen, die für eine solche Arbeit geeignet sind. Im Post Arbeitsumgebung kann Kreativität töten habe ich angedeutet, wie ich mir eine solche Umgebung vorstelle. Das Szenario wird im gemeinsamen Denk- und Diskussionsprozess auf Whiteboards oder Whiteboardfolien aufgezeichnet. Die oben erwähnten Kategorisierungen können dabei helfen das Szenario einzuordnen.

Jedes Meeting sollte immer aus einer Vorbereitung, einer Durchführung und einer Nachbereitung bestehen. In der Vorbereitung wird das Ziel des Meetings definiert. Die Teilnehmer können sich gründlich auf das Meeting vorbereiten. Es wäre z.B. möglich, sich schon vorher Gedanken zu Szenarien zu machen und die Ergebnisse zur Diskussion zu stellen. Zur Vorbereitung gehört auch die Auswahl der Räumlichkeit und des Termins. Die Nachbereitung umfasst vor allem die Dokumentation der Ergebnisse und die Aufbereitung neuer offener Fragen, die durch das Meeting entstanden sind. Solche Vor- und Nachbereitungen sollten genau die Länge haben, die nötig ist, um einen effektiven Prozess zu gewährleisten.

Im nächsten Post werden wir mit Hilfe dieses Wissens über Szenarien Qualitätsanforderungen entwickeln. Qualitätsanforderungen besitzen einen großen Einfluss auf die zu entwickelnde Architektur des Systems. Es gibt also eine enge Verzahnung zwischen Softwarearchitektur und Requirements Engineering. An dieser Stelle möchte ich deshalb dafür plädieren, diese Aufgaben nicht in separierten Teilprozessen durch unterschiedliche Einzelpersonen oder Teams durchführen zu lassen. Ich denke die Entwurfsarbeit ist ein nicht trennbarer, iterativer Gesamtprozess aus Requirements Engineering, Softwarearchitektur, Implementierung, Testen und Bauen.

  • [POHL08] Klaus Pohl: „Requirements Engineering“, 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


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