Requirements Engineering (RE) wird im Geschäftsalltag oft übersehen oder falsch verstanden. Dabei sind klare Anforderungen entscheidend für den Projekterfolg und dessen Verlauf. RE wird jedoch entweder ignoriert oder mit Overkill erschlagen. Ich plädiere für mehr Pragmatismus, Iteration und kritischer Hinterfragung: Brauchen wir das wirklich? Wozu?
In vielen Projekten beobachte ich dasselbe Muster: Alle wollen möglichst schnell vorankommen. Anforderungen festhalten und Dokumentieren? Das macht schon jemand — oder niemand. Bestenfalls sind die Anforderungen in Köpfen, Mails, Excels oder PowerPoints verteilt. Die Zeit fehlt und das Business drängt. Mit diesem klassischen Setup begeben sich alle auf eine spannende Reise mit gefährlichem Halbwissen und über Annahmen gesteuert.
Dabei wollen später alle nachvollziehbare Anforderungen, aussagekräftige Spezifikationen und gute Dokumentation. Die Krux dabei ist, dass diese nicht von selbst entstehen. Wobei:
Was ist eigentlich RE?
Unter Requirements Engineering versteht man das strukturierte Erheben, Dokumentieren, Prüfen und Verwalten von Anforderungen an ein System, Produkt oder Projekt. Es ist mehr als nur „etwas aufschreiben“. Vielmehr geht es darum, gemeinsames Verständnis zu schaffen, was wirklich benötigt wird. Funktional wie auch fachlich. Und das so früh wie möglich, um später keine teuren Überraschungen zu erleben. Denn — Spoiler — diese werden kommen, mit mehr oder weniger ernstgenommenen RE. Spätestens beim Testing, im Change Management oder mit unzufriedenen Endnutzern.
Da war doch was…
Ein prägendes Beispiel: Ein umfangreiches Digitalisierungsprojekt wurde mir zur Leitung übergeben. Ich sollte „nur noch umsetzen und implementieren“. Bei genauerem Hinsehen stellte ich fest, dass die fachlichen wie auch funktionalen Anforderungen seitens Kunde (interne Abteilung) diffus und teils nicht sauber erhoben waren.
Also zurück auf Feld eins. Stakeholdergespräche, Zielklärung, Scope definieren. Aufwändig, aber nötig, denn ohne diese Grundlagen hätte das Projekt blind geliefert. Und das ist in meinen Augen einer der grössten Irrtümer im Business: Lieber irgendwie weitermachen, statt mutig zu hinterfragen.
RE wird nicht zum Spass gemacht
Selbstverständlich kann RE auch übertrieben werden. Das ist nicht mein Punkt. Wir alle kennen die Arsenale an Vorlagen, komplexen Modellen und Methodenzirkus, welche nicht immer zielführend sind. Fünfseitige Use Cases, die an der Realität vorbeizielen, nützen niemandem. Das Business versteht darin den Sinn nicht, die Entwickler:innen fühlen sich abgehängt.
Doch das ist kein Argument gegen RE — sondern eines für ein pragmatisches, angepasstes Vorgehen. Wir müssen einander verstehen und gemeinsam den Konsens finden, was effektiv gebraucht wird. Der Schlüssel liegt im Dialog. Anforderungen iterativ erheben, mit gesundem Menschenverstand priorisieren und dokumentieren, was wirklich gebraucht wird und dabei den Menschen nicht ausser Acht lassen. Nicht mehr, nicht weniger.
Gutes RE ist unbequem. Es zwingt dazu, Klartext zu reden und Transparenz zu schaffen. Und manchmal auch Dinge zu sagen, die niemand gerne hört: „Warum?“, „Wieso?“, „Wozu?“ oder ein ganz simples „Nein, nicht umsetzbar“.
Dies erfordert Mut. Und Demut. RE ist kein Ort für Selbstdarstellung oder Eitelkeit. RE steht für echtes Zuhören und Verstehen und stellt ein klärendes und partizipatives Konstrukt zur Verfügung. Kein bürokratischer Klotz, wie manche sagen würden, sondern vielmehr den Grundstein für erfolgreiche Projekte.
RE beginnt mit deiner Einstellung, nicht mit Tools
Requirements Engineering wird oft unterschätzt. Und oft falsch gemacht. Meine Erfahrung hat mir gezeigt: Wer seine Projekte mit Erfolg zu Ende bringen will, kommt an RE nicht vorbei. Ich rede nicht von Word-Vorlagen oder Checklisten, sondern als bewusster und dialogorientierter Prozess. Von Menschen für Menschen.
Deshalb mein Appell: Mehr Mut zum Hinterfragen. Mehr Pragmatismus statt Perfektionismus. Und die Bereitschaft, RE als das zu sehen, was es wirklich ist. Der erste Schritt zu besseren Lösungen.
