Freitag, 2. Mai 2014

Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Im letzten Post der praktischen Beispiele zum Requirements Engineering haben wir zum Schluss eine Zielanalyse durchgeführt. Ziele sind extrem wichtig für ein Projekt. Sie verraten uns die eigentlichen Absichten, die wir mit einem Projekt verfolgen. Wenn wir irgendwann einmal Anforderungen finden, die sich auf kein Ziel zurückführen lassen, dann können wir diese getrost streichen. Nichts ist unwichtiger als Arbeit, die kein Ziel verfolgt. In dieser Zeit sollten wir lieber etwas anfertigen, was ein Ziel hat oder uns in die Hängematte legen. Arbeit, die den ganzen Tag nichts anderes fertig bekommt, als einen Stein von der einen auf die andere Seite zu räumen und wieder zurück ist sinnlos, wenn nicht Schikane.

Im besagten Post haben wir zumindest ein Zielmodell angedeutet. Einige Teilziele stehen in direktem Zusammenhang mit der User Story aus dem Post Praktisches Beispiel zu User Stories. Die gefundene User Story lautete: Als Entwickler A möchte ich, dass man Nutzerrollengruppen bilden kann und diesen Personas zugeordnet werden können, um virtuelle Personen für die Anforderungsermittlung zur Verfügung zu haben. Die Ziele Gruppenbildung von Stakeholdern und Bildung von Personas passen zu dieser User Story. Diese Ziele begründen also die Umsetzung der User Story.




Im Post Wie User Stories Use Cases gebären wurde gezeigt, wie Szenarien und User Stories zusammenhängen. Unter einem Szenario verstehen wir eine Folge von Interaktionsschritten, die konkret zeigen, wie ein oder mehrere Ziele umgesetzt werden oder auch nicht umgesetzt werden. Dabei richten wir zuerst unseren Blick auf den Weg, der das oder die Ziele erfolgreich umsetzt und zum anderen auch der Weg ist, der typisch für die Umsetzung ist. Diesen Weg nennen wir das Hauptszenario. Ein Hauptszenario ist eins zu eins mit einem Use Case verbunden, oder anders gesagt, ein Use Case besitzt genau ein Hauptszenario.

In unserem Fall können wir ein Hauptszenario für das Ziel Gruppenbildung von Stakeholdern bilden.



Der erste Schritt besteht aus dem Anlegen einer Gruppe. Danach können wir der Gruppe Stakeholder hinzufügen oder sie auch wieder entfernen. Auf diese Art und Weise besitzt die Gruppe nach einigen Schleifendurchläufen ein paar Stakeholder, zumindest, wenn das Hinzufügen das Entfernen übertrifft. Der letzte Schritt wäre das Speichern der Gruppe. Nun ist sie persistent und für alle Ewigkeit erhalten.



In einer intensiven Diskussion mit dem Kunden wird jedoch ein anderer Weg angedacht Gruppen zu bilden. Mit der Zeit sollten einige Gruppen im System sein. Da die Gruppenbildung nicht disjunkt sein muss und Stakeholder in mehreren Gruppen vertreten sein können, möchte ein maßgeblicher Kunde das man Gruppen dupliziere kann. Dabei soll der Gruppenname umbenannt werden und im weiteren Verlauf können natürlich wieder Stakeholder hinzugefügt und entfernt werden. Damit ist ein Szenario entstanden, welches nicht den normalen Weg durchläuft. Es ist ein Alternativszenario.



Zu diesen erfolgreichen Gruppenbildungen muss natürlich überlegt werden, welche Pfade nicht zum Erfolg führen. Beim ersten Betrachten verkleistern diese Ausnahmeszenarien den Blick fürs Wesentliche. Für eine ordnungsgemäße Umsetzung sind sie jedoch unverzichtbar. Im dargestellten Fall wird die Gruppe nicht gespeichert, wenn sie genau deckungsgleich mit einer schon gespeicherten Gruppe ist. Dadurch möchte man die wundersame Vermehrung von Gruppen verhindern.



Das letzte Aktivitätsdiagramm zeigt eine Gesamtdarstellung des Use Cases. Hier wurden Haupt-, Alternativ- und Ausnahmeszenario zusammengefügt. In einer guten Darstellung wäre wünschenswert, dass man solche Diagramme aufklappen könnte. Zuerst sollte nur die Sicht auf das Hauptszenario gewährt werden. Damit könnte man sich beim Durcharbeiten der Anforderungen auf das Wesentliche konzentrieren. Dann könnte man Schritt für Schritt ein Szenario nach dem anderen hinzufügen und so in der Umsetzungsphase einen immer besseren Einblick gewinnen.

Für das dargestellte Aktivitätsdiagramm sollte es eine tabellarische Darstellung geben, in der alles geklärt wird, was die Grafik nicht darstellen kann. In der unteren Tabelle möchte ich nur eine mögliche Form andeuten. Auch hier wären verschiedene Sichten auf die Tabelle sehr sinnvoll. In einem Wiki sollte man lieber eine Trennung nach Haupt-, Alternativ- und Ausnahmeszenarien durchführen, mindestens für die Grafiken.

Schritt Name Beschreibung
1 Gruppe anlegen Eine Gruppe wird mit einem eindeutigen Namen und einer Beschreibung angelegt.
2 Gruppe duplizieren Eine wird dupliziert. Dabei werden alle Stakeholder der Gruppe übernommen. Die neue Gruppe muss einen anderen Namen bekommen.
3 Stakeholder hinzufügen Im System enthaltene Stakeholder können einmalig zur Gruppe hinzugefügt werden.
... ... ...


Auch für das Ziel Bildung von Personas können wir ein Hauptszenario und ggf. Alternativ- und Ausnahmeszenarios finden. Damit haben wir zwei Use Cases mit zwei Hauptszenarien und mehreren Alternativ- und Ausnahmeszenarien. Die Use Cases bezeichne ich nun als Stakeholdergruppen anlegen und Personas anlegen. Für jeden Use Case gibt es eine Schablone, die es auszufüllen gilt.



ID UC0001
Name Gruppenbildung von Stakeholdern
Beschreibung Stakeholder können zu Gruppen zusammengefasst werden.
Akteure Benutzer
Vorbedingung Der Benutzer hat sich am System angemeldet und hat das Recht Gruppen zu bilden.
Nachbedingung -
Ergebnis Der Benutzer hat eine Gruppe gebildet.


ID UC0002
Name Bildung von Personas
Beschreibung Gruppen können Personas zugeordnet werden.
Akteure Benutzer
Vorbedingung Der Benutzer hat sich am System angemeldet und hat das Recht Personas zu bilden.
Nachbedingung -
Ergebnis Der Benutzer hat eine Persona gebildet.


Eine spezifische Nachbedingung habe ich nicht gefunden. Das Ergebnis sollte aber klar sein. Im ersten Fall hat der berechtigte Benutzer eine Gruppe gebildet und im zweiten Fall eine Persona. Für diese Fälle sollten nun gemeinsam mit dem Kunden Abnahmekriterien gebildet werden, unter denen der Kunde bereit wäre, die Software zum Gebrauch zu übernehmen. Einen Teil dieser Abnahmekriterien kann man einfach aus den Akzeptanzkriterien der User Story übernehmen.

Ich möchte an dieser Stelle noch einmal betonen, wie wichtig eine enge Zusammenarbeit zwischen Entwicklung und Kunden bei der beschriebenen Arbeit ist. Eigentlich sollte der Auftraggeber bestimmen, ob sein Mantel rot werden soll und nicht der Auftragnehmer. Dieser sollte eher in einer beratenden Funktion tätig sein. Leider ist die Kommunikation an dieser Stelle aus kurzsichtigen monetären Gründen oft gestört. Aber was kurzfristig Geld spart, kann langfristig viel Geld kosten. ( und Nerven :-( )

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