Modellieren von Benutzerberichten

Das Erstellen von Modellen kann dem Team helfen, ein besseres Verständnis beim Einschätzen oder Entwickeln von User Storys zu erlangen. Modelle können das Team auch bei der Erörterung hinreichend komplexer Fragen mit dem Produktbesitzer im Rahmen der Entwicklung unterstützen.

Beispielsweise kann das Projekt eine Reihe von Konzepten umfassen, mit denen das Team noch nicht vertraut ist. In Zusammenarbeit mit dem Produktbesitzer kann das Team ein Domänenklassendiagramm entwickeln, um diese Konzepte einschließlich der Beziehungen zu erfassen. Um die wichtigsten Sequenzen in der Aktivität eines Benutzers zu verstehen, kann das Team ein Aktivitätsdiagramm erstellen.

Weitere Informationen finden Sie unter Modellieren von Benutzeranforderungen.

Das Domänenmodell: die Sprache der Benutzer

Domänenklassendiagramme

In einem Domänenklassendiagramm werden die Konzepte und Beziehungen dargestellt, die der Anwendung zugeordnet sind. Jeder, der mit der Anwendung verbunden ist, kann diese Konzepte verwenden, und das Verständnis wird so vereinheitlicht.

Das Beispiel in der vorangehenden Abbildung entspricht nicht direkt einem Klassendiagramm der Softwarelösung, mit dem diese Beziehungen auf unterschiedliche Weise dargestellt werden könnten. Es handelt sich vielmehr um ein Vokabular zum Schreiben von User Storys:

Der Kunde wählt eine Speisekarte (Menu), aus der er eine Bestellung (Order) erstellt, und erstellt anschließend Bestellpositionen (Order Items) in der Bestellung (Order), indem er Gerichte (Menu Items) aus der Speisekarte (Menu) auswählt.

Da es sich um ein Modell von Konzepten anstelle von Objekten in einem Programm handelt, weisen Sie Klassen üblicherweise keine Vorgänge zu, wenn das Diagramm für diesen Zweck verwendet wird. Stattdessen können Sie Aktivitätsdiagramme verwenden, um die Aktionen beschreiben, die Benutzer ausführen.

Weitere Informationen finden Sie unter UML-Klassendiagramme: Richtlinien.

Aktivitätsdiagramme

Mithilfe von Aktivitätsdiagrammen kann das Team den Ablauf der möglichen Aktivitäten eines Benutzers erläutern und alternative Handlungsmöglichkeiten an den einzelnen Punkten aufzeigen.

Beim Erstellen von Tests kann das Team auf Aktivitätsdiagramme verweisen und einen Test für jeden Pfad im Aktivitätsdiagramm erstellen.

Durch einen Benutzertextabschnitt kann ein Pfad in einem vorhandenen Aktivitätsdiagramm eingefügt werden. Beispielsweise könnte eine User Story wie folgt lauten: "Als Kunde kann ich eine Bestellung speichern, anstatt sie gleich zu bezahlen." Wenn die Story in einen zu entwickelnden Sprint übernommen wird, kann das Aktivitätsdiagramm mit der neuen Funktion aktualisiert werden.

Im Aktivitätsdiagramm kann ein vollständiger Satz von Pfaden beschrieben werden, die vom Benutzer mit einer bestimmten Version der Anwendung verwendet werden können, wenn Sie das Diagramm aktualisieren, damit alle User Storys berücksichtigt werden, die vom Team implementiert wurden.

Weitere Informationen finden Sie unter UML-Aktivitätsdiagramme: Richtlinien.

Erkennen von Lücken mit dem Modell

Das Team kann die Anforderungen der Benutzer besser verstehen, wenn Missverständnisse in Konversationen vermieden werden, die von einem Diagramm nicht unterstützt werden. Beispielsweise würde in einem Diagramm klar zwischen einem Element in einer Bestellung und einem Element in einem Menü unterschieden.

Das Erstellen des Modells hilft dem Team, Fragen zu formulieren, die andernfalls erst zu einem viel späteren Zeitpunkt in der Entwicklung akut würden. Dazu gehören u. a.:

• Fragen zu den Kardinalitäten in einem Klassendiagramm (Beispiel: "Können Speisekartenelmente in mehreren Speisekarten angezeigt werden?").

• Fragen zu Schleifen im Klassendiagramm (Beispiel: "Stammen alle Elemente in einer Bestellung aus der gleichen Speisekarte?").

Antworten auf diese Fragen können dem Diagramm als Kommentare hinzugefügt werden.

Modellkonsistenz

Das Team kann Mehrdeutigkeiten vermeiden, indem es sicherstellt, dass das Modell und die User Storys übereinstimmen:

• In den User Storys werden die Begriffe verwendet, die im Modell definiert sind; außerdem sind diese mit den im Modell definierten Beziehungen konsistent. Wenn im Modell von Gerichten gesprochen wird, sollte in den User Storys nicht der Begriff "Produkte" dafür verwendet werden. Wenn das Klassendiagramm zeigt, dass ein Gericht zu genau einer Speisekarte gehört, darf in der Story nicht die gemeinsame Verwendung von Gerichten in mehreren Speisekarten beschrieben werden.

• Jede User Story beschreibt eine Reihe von Schritten, die von den Aktivitätsdiagrammen zugelassen ist.

• User Storys oder Aktivitäten beschreiben, wie jede Klasse und jede Beziehung im Klassendiagramm erstellt und zerstört werden. Welche User Story erstellt beispielsweise ein Gericht? Wann wird eine Bestellung zerstört?

Modelle und Produktrückstände

Das Team kann Modelle und Storyboards markieren, um die Bereiche zu kennzeichnen, die von der jeweiligen User Story geändert werden, oder kann mithilfe von Kommentaren oder Farben in einem Modell die Planung der Entwicklung unterstützen. Beispielsweise kann das Team die Aktionen in einem Aktivitätsdiagramm farblich kennzeichnen, um anzugeben, welche bereits abgeschlossen sind und welche im folgenden Sprint abgeschlossen werden.

Weitere Informationen finden Sie unter Modellieren von Benutzeranforderungen.

Modelle und Tests

Das Team kann ein Domänenmodell als Grundlage für Systemtests verwenden, in dem die Beziehungen zwischen den Tests und den Anforderungen für die Benutzer genau definiert werden. Diese Beziehungen helfen dem Team, die Tests schnell und ordnungsgemäß zu aktualisieren und sicherzustellen, dass das Produkt die neuen Anforderungen erfüllt.

Das Team kann ein beliebiges Element in einem Language-Modell UML (Unified Modeling Language) mit jeder Arbeitsaufgabe verknüpfen, z. B. mit einem Test. Wenn ein Teil des Modells geändert wird, erleichtert das Modell dem Team die Identifizierung der Tests, mit denen es verknüpft ist.

Erstellen Sie Tests mithilfe des Domänenmodells:

• Erstellen Sie mindestens einen Test für die Konstruktion jedes Typs oder jeder Zuordnung, beispielsweise ein Gericht oder eine Bestellposition, und erstellen Sie mindestens einen Test für die Zerstörung.

• Stellen Sie sicher, dass alle Pfade, die von Aktivitätsdiagrammen beschriebenen, getestet werden.

  Tipp

  Die Tests sollten auch Ausnahmepfade beinhalten, die normalerweise nicht in Aktivitätsdiagrammen dargestellt würden.

• Definieren Sie die Tests mithilfe des Vokabulars für das Domänenmodell. Beispielsweise können Sie die Aktion Gericht auswählen (Select Menu Item) testen. Dadurch wird überprüft, ob durch die Aktion eine Bestellung mit einem neuem Bestellelement generiert wird. Um automatisierte Tests zu schreiben, können Sie Klassen und Beziehungen verwenden, die direkt auf dem Diagramm basieren.

Weitere Informationen finden Sie unter Entwickeln von Tests aus einem Modell.