Ein gemeinsames Verständnis der Konzepte und eine gemeinsame Sprache sind von grundlegender Bedeutung: Welche Attribute hat eine Anforderung? Wie hängen Anforderungen und Testfälle zusammen? Stehen Anforderungen in einer Beziehung zu Change Requests? Wenn solche Fragen ungeklärt sind, kann kaum effektiv über Lösungen diskutiert werden. In einem weiteren Workshop wird daher die erste Version eines
Domänenmodells erarbeitet (Bild 1). Da dieses von zentraler Bedeutung für das Projekt ist, aktualisiert Reiner Fahrung das Domänenmodell, wann immer sich Änderungen oder neue Erkenntnisse ergeben.
May Leinstein und Reiner Fahrung definieren nun eine Liste von Funktionen. Die Funktionen orientieren sich an einzelnen Schritten aus der vorher definierten Geschichte, wie z.B. „Anforderungen erstellen“, „Testfall erstellen und mit Anforderung verknüpfen“, „Bericht über Anforderungen ohne Testfall erstellen“ oder „Verantwortlichen für Change Requests automatisch zuordnen“. Dabei müssen auch Ausnahmen und Fehlerfälle berücksichtigt werden. Wichtig ist jedoch, sich nicht zu verzetteln und deshalb zunächst nur die wichtigsten zu betrachten.
Jede Funktion wird mit einer ersten Aufwandsschätzung versehen und priorisiert – analog dem Product Backlog bei der Scrum-Entwicklung. Dabei achten May Leinstein und Reiner Fahrung darauf, dass Benutzer möglichst früh Erfahrungen mit dem System sammeln können. Die daraus resultierenden Rückmeldungen sind unverzichtbar, um festzustellen, ob die eingeschlagene Richtung stimmt. Deshalb werden vor allem solche Funktionen hoch priorisiert, die einfach umgesetzt werden können und ein erstes Ausprobieren des Systems ermöglichen. Aufwendige Automatisierungen und Überprüfungen können dagegen warten, bis das Datenmodell weitgehend stabil ist, denn sie generieren viel Aufwand und machen das System schwerer änderbar. Deshalb versehen May Leinstein und Reiner Fahrung die Funktion „Verantwortlichen für Change Requests automatisch zuordnen“ mit einer niedrigen Priorität.