RE@Agile - Working Software over Comprehensive Documentation
Was genau ist Requirements Engineering?
Das grundsätzliche Ziel von Requirements Engineering ist es Fehler in Soft- und Hardware so früh wie möglich aufzudecken, bzw. gar nicht erst entstehen zu lassen. Im Idealfall spart das eine Menge Ressourchen (Mitarbeiter, Kapital, Zeit), deren Aufwendungen exponentiell steigen, je später man den Fehler entdeckt.
Von der Idee zum Produkt und zurück?
Requirements Engineering (RE) findet überall im agilen Prozess statt. Die folgenden zwei Dimensionen helfen, RE im agilen Prozess besser zu verstehen:
- Die zeitliche Dimension gibt an, mit welchem Zeithorizont gearbeitet wird. Strategische Aktivitäten sind langfristig, operative Aktivitäten eher kurzfristig.
- Die Arbeitsdimension gibt an, woran gearbeitet wird. Konzeptuelle Arbeit fokussiert auf die Entwicklung von Ideen, Konzepten und Spezifikationen, (Weiter-)Entwicklungsarbeit fokussiert auf das Produkt. RE dient in der Entwicklung dazu, die Entwicklungsarbeiten mit möglichst konkreten Informationen über das Produkt zu versorgen und ggf. Dokumente/Spezifikationen zur Erfüllung regulatorischer Vorgaben zu erstellen.
Wert durch Anforderungen
Arbeiten mit Anforderungen ist ein Erkenntnisprozess, der längere Zeit in Anspruch nehmen kann. Im agilen Kontext findet Anforderungsarbeit in jeder Iteration (Time Box) statt. Entscheidend ist, dass den Kosten für die Anforderungen ein angemessener Wert gegenübersteht. Anforderungen generieren Wert beispielsweise durch:
- Besseres Verständnis und Risikominimierung: Verstehen einer Idee oder eines Problems vor der Implementierung verhindert, dass Unnützes oder Unbrauchbares realisiert wird
- Erhöhung des Werts eines Produkts: Das entwickeln, was den Kunden wirklich wichtig ist und Kundenbindung schafft
- Erfüllung regulatorischer Erfordernisse: Schaffung der Voraussetzungen, damit ein Produkt zugelassen werden kann
In jeder Iteration muss bewertet werden, ob durch die konzeptuelle Arbeit mit Anforderungen ein angemessener Wert generiert wird. Dies erfolgt in der Regel risikobasiert: Mit welchen Mitteln (Konzeption oder Entwicklung) lässt sich das Risiko, das falsche Produkt/System zu realisieren entwickeln, am wirkungsvollsten beherrschen?
RE und Agilie: So wenig wie möglich – so viel wie nötig
Das agile Prinzip „Working software over comprehensive documentation“ drückt eine Wertpriorität aus. Es bedeutet nicht, dass Dokumentation überflüssig oder wertlos ist. Oftmals wird angenommen, dass RE Anforderungen und deren Dokumentation über alles setzt – aber dies ist ein Irrglaube. Gutes Requirements Engineering ermittelt und dokumentiert Anforderungen genau in dem Umfang, der notwendig ist, um das Entwicklungsrisiko auf ein akzeptables Maß zu senken.
Was sich genau hinter diesem Konzept verbirgt, aus welchen Teilen es besteht und wie es angewandt wird, soll im Folgenden erläutert werden.
Strategisch konzeptuelle Arbeit nimmt das Produkt als Ganzes ins Auge und arbeitet langfristig. Wesentliche Elemente sind die Produktvision, die Roadmap sowie Anforderungsartefakte wie zum Beispiel Epics, Uses Cases oder auch Modelle. Wichtig ist, dass die Stakeholder und der Produkteigner eine Form finden, welche die Bedürfnisse der Stakeholder angemessen und mit sinnvollem Aufwand beschreibt. Requirements Engineering stellt die hierfür notwendigen Techniken und Dokumentationsformen bereit. Die strategisch-konzeptuellen Artefakte bilden die Grundlage für die strategischen Entscheidungen des Produkteigners.
Operativ konzeptuelle Arbeit fokussiert auf die Erarbeitung und kontinuierliche Pflege der Vorgaben für die Entwicklung. Der Product Owner spielt hier die zentrale Rolle: Er pflegt und priorisiert den Produkt-Backlog. Auf dieser Basis, sowie unter Berücksichtigung strategischer Vorgaben, definiert er zusammen mit dem Entwicklungsteam Produktinkremente und Releases. Damit steuert er die Entwicklung sowohl fachlich wie auch wertmäßig. Der Produkt-Backlog enthält konkrete Anforderungen, beispielsweise in Form von User Stories. Dabei zieht der Produkteigner meist die Unterstützung von Fachexperten ebenso von Requirements-Engineering-Experten heran.
Wozu brauchen wir RE?
Strategische (Weiter-)Entwicklung setzt sich mit dem bestehenden Produkt (bzw. Produktinkrement) und seinem Kontext auseinander. Es geht darum, Feedback aus der Nutzung eines Produktes zu erhalten, um das Produkt langfristig weiterentwickeln zu können. Requirements Engineering kümmert sich hier um die Erhebung und Auswertung von Benutzerfeedback sowie die Analyse der Produktnutzung und deren (positive und negative) Auswirkungen im Produktkontext. Neben eigenen Produkten kann sich strategische Entwicklung auch mit der Analyse von Fremdprodukten beschäftigen.
Operative (Weiter-)Entwicklung kümmert sich um die konkrete Realisierung des Produktes in Form von Inkrementen bzw. die Weiterentwicklung bereits realisierter Produktbestandteile. Wesentlich für agile Entwicklung ist hier der Fokus auf funktions- und releasefähigen Produktinkrementen, welche ein zeitnahes Feedback durch die Stakeholder erlauben. Requirements Engineering hilft bei der Detaillierung von Anforderungen sowie der Erfüllung regulatorischer Vorgaben, zum Beispiel der Dokumentation von Anforderungen und deren Verfolgung (Traceability) zum Code und den Testfällen bei sicherheitskritischen Systemen.
Nun stellt sich also die Frage, warum brauchen wir überhaupt Requirements Engineering und warum bauen wir dann nicht alle Systeme gleich? In der Regel ist das Risiko einer direkten Entwicklung zu hoch. Die Ebene der Anforderungen ist von Nöten, da die meisten Systeme zu groß und umfassend sind, um sie auf einer rein technischen Ebene intellektuell zu erfassen und zu gestalten. Um agil entwickeln zu können, muss vorher abgeklärt werden, was die Stakeholder wollen. Denk Kosten für das RE steht ein messbarer Nutzen gegenüber: Auf der Grundlage guter Anforderungen können Systeme entwickelt werden, die den Wünschen und Bedürfnissen der Stakeholder passgenau entsprechen. Durch eine wertorientierte, iterativ-inkrementelle Vorgehensweise reduziert RE die Kosten für Korrekturen, Fehlerbehebungen und das Neuschreiben von nicht brauchbarem Code.
Zusammenfassend kann man also sagen, dass durch Requirements-Engineering das Risiko gesenkt wird, Ressourcen und Zeit zu verschwenden, beziehungsweise ein Produkt im schlimmsten Fall zurückrufen zu müssen.
