Agiles Requirements Engineering

by | 11.02.2022 | Requirements Engineering

Anforderungen richtig zu erfassen und umzusetzen, ist der Schlüssel zum Projekterfolg. Aber wie gelingt das? Im klassischen Projektmanagement wird ein Projekt typischerweise mit dem Erstellen eines Business-Cases und dem Schreiben eines Projekt-Charters begonnen. In diesen beiden Dokumenten werden die groben Anforderungen an das Projekt fixiert. Danach beginnt die Detailplanung, bei der eine Work-Breakdown-Structure erstellt wird, auf der die Planung der Aufgaben und die Kostenschätzung beruhen. Dieses Vorgehen basiert auf einer Reihe von Vorannahmen und bringt zahlreiche Probleme mit sich, die ich im Zuge dieses Beitrags genauer beleuchten werde.

Klassisches Requirements Engineering

Bis in die 2000er Jahre und sogar noch länger wurden Softwareentwicklungsprojekte mit klassischen Projektmanagement-Methoden umgesetzt. Diese Projekte wurden wie Architekturprojekte geplant, spezifiziert und strukturiert sequenziell umgesetzt. Im Jahr 2001 setzte sich jedoch eine Handvoll andersdenkender IT-Fachexperten zusammen und entwickelte das agile Manifest, weil sie frustriert waren von der Starrheit, die das klassische Projektmanagement erzwang. Dieses macht nämlich immer gewisse Vorannahmen;  beispielsweise, dass Softwareprojekte von Anfang an durchgeplant werden können, sich Anforderungen während des Projekts nicht ändern und alle wichtigen Stakeholder und Business-Cases von Beginn an richtig analysiert werden und wurden. Man ging also davon aus, dass, wenn ein Projekt nach der Spezifikation und Planung in die Umsetzung geht, alle wichtigen Dinge vollständig erfasst und kommuniziert wurden, sich nicht mehr ändern und das Team diese genau eins zu eins so umsetzt, wie sie geplant wurden. Ein Plan, der nur bei wenigen Projekten, die vor allem eine geringe Komplexität aufweisen, aufgeht.

Welche Probleme können also beim klassischen Projektmanagement auftreten?

In Bezug auf die spezifizierten Anforderungen könnte es sein, dass

  • nicht alle wichtigen Stakeholder zu Beginn des Projekts bekannt sind.
  • sich wichtige Stakeholder oder User-Gruppen ändern.
  • der Business-Case falsch erstellt wurde.
  • die User sich anders verhalten als erwartet.
  • die Erwartungen der User sich im Laufe des Projekts ändern.

Im Bezug auf die Kommunikation der Anforderungen könnte es sein, dass

  • bei der Übergabe der Anforderungen von Business Analysten und Requirements Engineers an das Umsetzungsteam wichtige Informationen verloren gehen.
  • Anforderungen vom Umsetzungsteam falsch oder anders verstanden werden.
  • Anforderungen aus technischer Sicht nicht so umsetzbar sind, wie sie spezifiziert wurden.

Im Laufe der Umsetzung kann es sein, dass

  • Anforderungen an das System sich in den Augen der User ändern, das Entwicklungsteam und die Business Analysten bzw. Requirements Engineers diese Information aber nicht mitbekommen.
  • Anforderungen schleichend zum Produkt hinzugebaut werden oder sich ändern, ohne dass es dem Team, dem Projektleiter oder dem Requirements Engineer auffällt (Scope Creep).
  • fehlerhafte Implementierungen von Anforderungen durch einen schlechten Wissensstand der Tester oder eine fehlerhafte Kommunikation mit den Testern, fälschlicherweise als korrekt abgenommen werden.

Ein weiteres Problem beim klassischen Projektmanagement ist, dass die Entwicklung monolithisch stattfindet. Das heißt, das Testen und Releasen der Anwendung erfolgt nur einmal und erst am Projektende. Somit kann kein frühzeitiges Feedback durch die User erfolgen und Änderungen können nicht zeitgerecht eingepflegt werden. Das Produkt wird so implementiert, wie es zu Beginn spezifiziert wurde.

Agiles Requirements Engineering

Verantwortung, Kommunikation und Beteiligung

Im Gegensatz zum klassischen Projektmanagement, bei dem Business Analysten und Requirements Engineers nur am Beginn des Projekts aktiv eingebunden sind und danach im besten Fall nur mehr für Fragen zur Verfügung stehen,  gibt es bei agilen Vorgehensmodellen wie Scrum Cross-Functional-Teams. Solche Teams unterstützen einen aktiven Wissenstransfer. Bei Scrum gibt es die Rolle des Product Owners, der die Aufgabe hat, alle Stakeholder zu managen und die Anforderungen an das zu entwickelnde Produkt Just-in-Time zu erfassen. Der Product Owner ist dabei nicht wie der Business Analyst beim klassischen Projektmanagement nur in einer Vorphase des Projekts beteiligt, sondern sitzt mit dem Entwicklungsteam in einem Boot und arbeitet gemeinsam mit dem Team an der Entstehung des Produkts.

Dabei ist er für die Klärung einer wesentlichen Frage verantwortlich: Bauen wir als Scrum-Team das richtige Produkt? Er kümmert sich also voll und ganz um das Was und ist ständig auf der Suche nach den nächsten Requirements.

Der Product Owner:

  • analysiert Geschäftsprozesse,
  • leitet Visionen von der Unternehmensstrategie ab,
  • kümmert sich um die Auswahl der richtigen Stakeholder,
  • managt die Kommunikation mit den Stakeholdern,
  • erfasst durch den Einsatz unterschiedlicher Requirements Engineering-Methoden und -Werkzeuge die Requirements der Stakeholder,
  • wählt Key-User aus und lädt sie zu Review-Meetings ein,
  • pflegt laufend die neu gesammelten Erkenntnisse in das Product Backlog ein und priorisiert die vorhandenen Anforderungen neu.

Inspect and Adapt

Darüber hinaus haben agile Vorgehensmodelle einen großen Vorteil: Feedback.

Agiles Projektmanagement und vor allem Scrum verlangt, dass das Team seine Arbeit in Mikro-Projekte unterteilt. Diese Sprints werden wie kleine Projekte zu Beginn geplant und am Ende abgenommen und den Usern präsentiert und freigegeben. Dadurch können Key-User, die beim Sprint-Review eingebunden sein sollten, aktiv Feedback geben. Sollten sich Anforderungen der User in der Zwischenzeit geändert haben, so kann das Scrum-Team darauf reagieren und die neuen Erkenntnisse in das Projekt einpflegen. Im agilen Projektmanagement sieht man Fehler als Lernerfahrung und empfindet Feedback als etwas sehr Positives. Beim sogenannten “Inspect and Adapt” geht es vor allem darum, Transparenz zu schaffen und möglichst viel Feedback zu generieren, das sofort in die Entwicklung einfließt.

Anforderungen versus User Stories

Auch beim Erfassen der Anforderungen gibt es gravierende Unterschiede. Im klassischen Projektmanagement werden Anforderungen als Forderung formuliert:

Das System muss Daten von Personen halten können. Diese personenbezogenen Daten müssen bearbeitbar sein, verschlüsselt gespeichert und mit Zahlungskonditionen hinterlegt werden können.

Die Anforderungen sind sehr starr und nicht problembezogen. Es wird beschrieben, wie etwas zu tun ist und wie sich etwas verhalten muss, jedoch nicht, warum etwas zu tun ist. Diese Kriterien sollen erfüllt sein:

  • vollständig
  • testbar
  • konsistent
  • Design-frei (Design-Phase wird erst nach der Spezifikationsphase im Wasserfallmodell abgehalten)
  • unmissverständlich und eindeutig

Im Gegensatz dazu werden Anforderungen in agilen Projekten als User Stories erfasst:

Als User der App möchte ich im ersten Schritt nach dem Öffnen der App meine personenbezogenen Daten erfassen, um im weiteren Verlauf alle gesendeten Dokumente mit meiner Signatur zu unterzeichnen.

User Stories werden immer nach folgenden Pattern definiert und dienen der Klärung des Warums:

Als … möchte ich … um … zu erreichen.

User-Stories werden dabei gesehen als:

  • unabhängig
  • verhandelbar
  • wertvoll
  • schätzbar
  • klein und abgeschlossen
  • testbar

Um diesen Zweck, also das Warum, zu erreichen, wird dem Team nicht viel vorgegeben. Die User Story wird jedoch noch um Akzeptanz-Kriterien ergänzt, um die Testbarkeit und die Minimal-Anforderung sicherzustellen.

Fazit

Agiles Requirements Engineering unterscheidet sich vom klassischen Requirements Engineering vor allem darin, dass es den laufenden Umsetzungsprozess begleitet und ständig Just-In-Time Anforderungen liefert. Somit kann besser auf Veränderungen reagiert werden und Feedback von Usern jederzeit in die Produktentwicklung mit einfließen. In der Regel entstehen dadurch bessere Produkte mit hoher Usability.

Lesen Sie mehr von David Theil in seinem Blog: https://digitalisierungscoach.com/