Requirements Engineering in drei Tagen

Dominik Neff ist Berichsleiter für IT-Management Consulting und Requirements Engineering bei MaibornWolff et al. Marcel Altherr ist CEO Schweiz.

Wird ein neues Software-System entwickelt, haben die verschiedenen Stakeholder oft ganz unterschiedliche Erwartungen. Es ist daher wichtig, diese zeitnah und umfassend aufzunehmen, um sie entsprechend berücksichtigen zu können. Im herkömmlichen Requirements Engineering werden die Anforderungen durch nacheinander stattfindende Befragungen der Bezugsgruppen erhoben. Dieser Prozess gestaltet sich meist zeitintensiv und kann zu Missverständnissen führen, da es nur selten zu einer Vernetzung des Wissens kommt. Die Anforderungen erscheinen unklar, Abhängigkeiten werden häufig zu spät identifiziert und Prioritäten folglich falsch eingeschätzt. Im Projektverlauf kommt es dann zu aufwendigen Nachbesserungen.

In agilen Projekten, etwa nach Scrum, werden deshalb von Beginn an die Stakeholder stärker einbezogen. Um möglichst schnell einen differenzierten Überblick über die grundlegenden Anforderungen zu erhalten, bedarf es einer geeigneten Methode, welche diesen Prozess optimiert und effizient gestaltet. Auf diese Weise lassen sich später notwendige Änderungen auf ein Minimum reduzieren.

Die Drei-Tages-Methode

Anstelle der sonst üblichen seriellen Befragung der Stakeholder sollte gleich zu Beginn ein Workshop initiiert werden, der alle an einen Tisch bringt. Hier können die Fokusthemen des Projekts in drei Tagen anhand eines strukturierten Fahrplans gemeinsam identifiziert und diskutiert werden. Der erste Tag sollte neben der Einführung in die Zielsetzung und Methode ein gemeinsames Brainstorming beinhalten, bei dem alle wesentlichen Aspekte identifiziert werden.

Diese müssen im nächsten Schritt hinsichtlich der einzelnen Stakeholder-Gruppen geordnet werden. Der Vorteil: Die einzelnen «User Stories» werden in parallelen Arbeitsgruppen diskutiert und dokumentiert.

Die Pausen dienen voll und ganz der Vernetzung. Durch die gezielte Vermischung der Gruppen erhalten Teilnehmer die Chance, sich auszutauschen und gewinnen so einen kompletten Überblick über die Ergebnisse der Workshops. Kehren die Teilnehmer in ihre Arbeitsgruppen zurück, können sie auf Basis ihrer Gespräche die Erfolgsfaktoren für das Projekt mit neuen Erkenntnissen diskutieren. Dadurch kommen in der Regel weitere Aspekte zum Vorschein.

Am dritten Tag stellen die jeweiligen Product-Owner ihre User Stories vor, welche die Teilnehmer parallel dazu hierarchisieren. Das Ergebnis ist eine priorisierte Gesamtliste, die von allen Teilnehmern des Workshops final verabschiedet wird.

An diesem Punkt wird der entscheidende Vorteil der beschriebenen Vorgehensweise deutlich: Durch die konsequente Vernetzung der Teilnehmer entsteht eine umfassende und aufeinander abgestimmte Liste der Anforderungen. Es lassen sich so schon frühzeitig Abhängigkeiten identifizieren, und die Beteiligten können ein gegenseitiges Verständnis für die Anforderungen des anderen entwickeln. Auf diese Weise fügt sich ein Gesamtbild zusammen, das mehr Einblicke in das Projekt gewährt, als dies üblicherweise der Fall ist. Möglich wird dies durch die während des Workshops geführten Diskussionen, sowohl innerhalb der gemeinsamen Pausen als auch bei der gegenseitigen Vorstellung der User Stories. Hinzu kommt die spezielle Rollenverteilung der Arbeitsgruppen während der Diskussion: Hier beobachten eigens eingesetzte Kritiker die Gespräche, ohne sich zunächst aktiv daran zu beteiligen. Zu definierten Zeitpunkten geben sie ihr Feedback. Es entsteht ein «Big Picture», das alle wesentlichen Aspekte berücksichtigt.