Freitag, 14. März 2014

Wie User Stories Use Cases gebären.

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.


Zuletzt haben wir User Stories geschrieben, die zu lösenden Probleme analysiert, Randbedingungen ermittelt und ein Zielmodell aufgestellt. Diese Prozesse wurden in den Artikeln Die Geschichten der Benutzer - User Stories erstellen und Die Analyse des Problemraums führt zum Zielmodell beschrieben. Im Folgenden möchte ich mich mit der Möglichkeit beschäftigen, Use Cases zu entwickeln. Dazu müssen wir als erstes herausarbeiten, worin der Unterschied zwischen User Story und Use Case besteht.

"Einer der offensichtlichsten Unterschiede zwischen Stories und Use Cases ist deren Umfang. Beide sind größenmäßig so angelegt, dass sie einen Geschäftswert bieten, aber Stories werden kleiner gehalten, (beispielsweise nicht mehr als zehn Tage Entwicklungsarbeit), so dass sie zur Planung der Arbeit verwendet werden können. Ein Use Case deckt fast immer einen viel größeren Umfang als eine Story ab." [S.153, COHN10] [COHN10] stellt fest, dass User Stories einzelnen Szenarien eines Use Cases gleichen. Sie können z.B. das Hauptszenario darstellen, wenn auch nicht notwendigerweise. Festzustellen bleibt, dass der detaillierte Ablauf einer User Story einem Szenario gleicht.

"User Stories und Use Cases unterscheiden sich auch im Grad der Vollständigkeit. James Grenning führt aus, dass der Text auf einer Story Card >>plus Akzeptanztests im Grunde dasselbe ist, wie ein Use Case<<. Grenning meint damit, dass die Story dem Szenario für den Haupterfolg des Use Cases entspricht und dass die Tests der User Story den Erweiterungen der Use Cases entsprechen." [S.155, COHN10] Hier wird noch einmal erhärtet, dass aus einer User Story Szenarien abgeleitet werden können. In den Akzeptanztests vermutet Grenning Alternativ- und Ausnahmeszenarien. Auch wenn [COHN10] die 1:1 Entsprechung von User Story und Use Case anders sieht, so vermutet auch er zu entwickelnde Szenarien in einer User Story. Die abgeleiteten Szenarien einer oder mehrerer Stories können sich so zu einer User Story zusammensetzen.

"Ein weiterer wichtiger Unterschied zwischen Use Cases und User Stories ist deren Langlebigkeit. Use Cases sind häufig permanente Artefakte, die solange bestehen, wie das Produkt aktiv entwickelt oder gewartet wird. Stories sind andererseits nicht dazu gedacht, die Iteration zu überleben, in der sie der Software hinzugefügt werden." [S.155, COHN10] Im Arbeitsprozess entwickelt das Team gemeinsam Szenarien aus den User Sories. Diese Szenarien werden zu Use Cases hinzugefügt. Sie können ggf. Use Cases ändern, indem alte Szenarien geändert oder gelöscht werden und neue hinzukommen. Im Use Case verbirgt sich die langfristige Beschreibung eines umzusetzenden Zusammenhangs. Die Dokumentation ist dabei das Ergebnis gemeinsamer Wissensarbeit und sie ist zur späteren Erinnerung an diesen Prozess gedacht. Auch für die Einarbeitung neuer Mitarbeiter ist eine Dokumentation eine Frage der Fairness und der Effizienz.

Bei der Ableitung von Szenarien aus User Stories und deren Zusammensetzung zu Use Cases sollte man darauf achten, dass die Szenarien nicht aus Annahmen zur Benutzeroberfläche bestehen. Die Entwicklung einer geeigneten Benutzeroberfläche ist dem Ausformulieren von Anforderungen nachgelagert. Man verwendet hier eine Lösung zur Formulierung des WAS und versperrt sich die Sicht auf andere Lösungen. [COHN10] erwähnt, dass Constantine und Lockwood den Einsatz von Essential Use Cases vorgeschlagen haben. "Ein Essential Use Case ist ein Use Case ohne stillschweigende Annahmen zu Technologie und Implementierung." [S.156, COHN10]

[COHN10] zeigt außerdem auf, dass Use Cases und User Stories für unterschiedliche Zwecke geschrieben werden. Use Cases dokumentieren die Anforderung in einer für Kunden und Entwicklung akzeptablen und langfristigen Form. User Stories sind hingegen eher ein Planungsinstrument. Im beschriebenen Vorgehen bilden die User Stories einen Platzhalter zur Entwicklung von Use Cases und sie sind ein Mittel, das Vorgehen in Iterationen planbar zu machen. In diesem Vorgehen ist die User Story auch eine Erinnerung, Use Cases zu entwickeln.

Das Vorgehen soll nicht heißen, dass User Stories Szenarios sind. "Die primären Unterschiede zwischen User Stories und Szenarios sind Umfang und Ausführlichkeit. Szenarios enthalten viel mehr Einzelheiten und ihr Umfang deckt in der Regel mehrere Stories ab." [S.159, COHN10] Für die Arbeit im Team heißt das, Szenarios müssen entwickelt werden. Die User Stories sind nur der Anfang, der Ausgangspunkt der Arbeit, die in der Zusammenfassung der Szenarien in Use Cases endet.

"Ein Szenario beschreibt ein konkretes Beispiel für die Erfüllung bzw. Nichterfüllung eines oder mehrerer Ziele. Es konkretisiert dadurch eines oder mehrere Ziele. Ein Szenario enthält typischerweise eine Folge von Interaktionsschritten und setzt diese in Bezug zum Systemkontext." [S.123, POHL08] Bei der Entwicklung von Aktionsfolgen zwischen Anwendung und Kontext spielt das Ziel eine besondere Rolle. Finden wir zu einem Szenario kein zu verwirklichendes Ziel, so ist dieses Szenario für die Anwendung ohne Wert. Somit haben wir die Szenarien mindestens mit den User Stories und mit den Zielen zu verknüpfen, aus denen wir sie abgeleitet haben und die sie erfüllen müssen.



Für die Bildung von Use Cases spielen Haupt-, Alternativ- und Ausnahmeszenarien eine besondere Rolle. Wir kennen weitere Klassifizierungen für Szenarien, die in unserer Betrachtung aber erst einmal nicht untersucht werden. Im Folgenden die Definitionen dieser Szenarioarten von [POHL08]:

"Ein Hauptszenario ist ein Szenario, das die Interaktionsfolge dokumentiert, die normalerweise ausgeführt wird, um eines oder mehrere mit dem Szenario assoziierte Ziele zu erfüllen." [S.137, POHL08] Andere bezeichnen dieses Szenario auch als den Happy Path. Ein Use Case hat genau ein Hauptszenario.

"Ein Alternativszenario ist ein Szenario, das zu einem Hauptszenario eine alternative Interaktionsfolge definiert. Ein Alternativszenario erfüllt die gleichen Ziele wie das zugehörige Hauptszenario." [S.137, POHL08] Falls der normale Weg also nicht durchführbar ist, um das Ziel zu erreichen, werden Alternativen angeboten, die auf Umwegen zum Ziel führen.

"Ein Ausnahmeszenario ist ein Szenario, das eine Interaktionsfolge definiert, die ausgeführt wird, wenn in einem Szenario (Haupt-, Alternativ- oder anderes Ausnahmeszenario) ein Ereignis eintritt, das die Erfüllung eines oder mehrerer mit dem Szenario assoziierter Ziele verhindert." [S.138, POHL08] Ausnahmeszenarien zeigen also, wie im Fehlerfall gehandelt wird.



Wie sich diese Szenarien zu Use Cases zusammensetzen, wird im nächsten Artikel gezeigt. In diesem Artikel sollte klar geworden sein, dass wir die Planung verlassen und mit der Entwicklung begonnen haben. Ein strukturiertes Durchdenken der zu entwickelnden Features steht einer systematischen Softwareentwicklung nicht im Wege, sie bedingen einander. Die Entwicklung wird nachvollziehbar und sie ist Teamarbeit. Die gemeinsame Wissensarbeit führt zum Ziel.

  • [COHN10] Mike Cohn: "User Stories", 1. Auflage, mitp, Heidelberg, 2010


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