Die Wissenschaftler Andrew Newberg, M.D. und Coach Mark Robert Waldman haben in ihrem Buch, Words Can Change Your Brain, die These aufgestellt, dass die richtigen Worte, auf die richtige Weise gesprochen, Liebe, Geld und Respekt bringen können, während die falschen Worte - oder sogar die richtigen Worte auf die falsche Weise gesprochen - das Potential haben, ein Land in den Krieg zu führen. Gerade in unserem Berufsumfeld der Informationstechnologie wissen wir, wie wichtig genaue Kommunikation ist und dass wir sensible Punkte wie Schwachstellen eineindeutig beschreiben müssen, damit andere uns verstehen und wir gemeinsam an einer Lösungen arbeiten können, die langfristig Bestand hat. Man kann eine schlechte Projektplanung überwinden, man kann eine schwache Software-Codierung überwinden, aber niemand hat jemals mit vagen Anforderungen Erfolg gehabt. Wenn das Falsche ermittelt wurde, wird das Falsche gebaut.

Leider sieht das Business Requirements Engineering (RE) immer noch als etwas, das im besten Fall die Softwareentwicklung verlangsamt und im schlimmsten Fall überflüssig ist. Der zunehmende Agile-Buzz hat RE eine Zeit lang stark beeinflusst und sogar unterdrückt. Einfach, weil die meisten den Begriff "Anforderung" mit dem Vorgehen in einem klassischen Wasserfallprojekt assoziieren. Der typische Kommentar ist: "Wir haben keine Anforderungen, wir haben User Stories!" Aber egal, welchen Namen man vergibt, es ist und bleibt eine Basis für die eigene Arbeit, die sorgfältig ausgearbeitet und geprüft werden muss. Tatsächlich bedeutet der Begriff "Anforderung" u.a. eine dokumentierte Darstellung der Bedürfnisse oder Wünsche der Stakeholder. Er impliziert in keinem Fall eine Aussage über das projektspezifische Entwicklungsmodell, in dem das Team arbeitet. Diese Fehlwahrnehmung, dass Anforderungen und Requirements Engineering nur etwas für klassische Projekte sind, kann in agilen Projekten zu finanziellen Einbußen oder Misstrauen der Stakeholder führen. 

Viele Agilisten sind überrascht, wie nah die Requirements-Engineering-Prozesse am agilen Mindset sind. Das IREB hat das erkannt und um beide Welten zu vereinen und Missverständnisse auszuräumen, wird im 2021 veröffentlichten CRPE-Lehrplan von Work-Products gesprochen. Darunter werden je nach Kontext sowohl die einzelnen Anforderungen und User Stories als auch die Beschreibungen von (externen) Schnittstellen, Use Cases, Epics, etc. verstanden.

Grundlegende Prinzipien des Requirements Engineering

Die bekannten vier Haupttätigkeiten des Requirements Engineers sind:

✔ Elicitation: Anforderungen ermitteln, spezifizieren und verfeinern 

✔ Dokumentation: Anforderungen beschreiben und klar und prägnant festhalten, in Prosa oder modellbasiert

✔ Validieren: Anforderungen validieren, um die Qualität der Anforderungen zu sichern

✔ Verwalten: Anforderungen organisieren und managen

Der seit 2021 veröffentlichte Lehrplan des IREB spezifiziert diese bekannten vier Haupttätigkeiten des Requirements Engineers mit neun Prinzipien:

Prinzip 1 Wertorientierung: Anforderungen sind ein Mittel zum Zweck,
kein Selbstzweck

Prinzip 2 Stakeholder: Im RE geht es darum, die Wünsche und Bedürfnisse der
Stakeholder zu befriedigen

Prinzip 3 Gemeinsames Verständnis: Erfolgreiche Systementwicklung ist ohne
eine gemeinsame Basis nicht möglich

Prinzip 4 Kontext: Systeme können nicht isoliert verstanden werden

Prinzip 5 Problem - Anforderung - Lösung: Ein unausweichlich ineinander-
greifendes Tripel

Prinzip 6 Validierung: Nicht-validierte Anforderungen sind nutzlos

Prinzip 7 – Evolution: Sich ändernde Anforderungen sind kein Unfall,
sondern der Normalfall

Prinzip 8 – Innovation: Mehr vom Gleichen ist nicht genug

Prinzip 9 – Systematische und disziplinierte Arbeit:
Wir können im RE nicht darauf verzichten

Für professionelle Requirements Engineers ist dies Alles nichts Neues. Diese neun Prinzipien stehen ähnlich wie das Agile Manifest, wie ein Wegweiser im hektischen Software-Herstellungsalltag.

Sollte ich Dich überzeugt haben, dass auch in Deinem agilen Arbeitsalltag das Überdenken der Requirements sinnvoll sein könnte, dann können Dir meine Kollegen viele praktische Tipps in unseren Requirements Engineering Trainings geben.