„Das habe ich mir ganz anders vorgestellt." – Wie Requirements-Engineering Projekte rettet, bevor sie scheitern

---

Eine Geschichte über verlorene Millionen, frustrierte Teams und die eine Disziplin, die den Unterschied zwischen Erfolg und Scheitern ausmacht.

Es ist Freitagabend, kurz vor 19 Uhr. Lisa starrt auf ihren Bildschirm. Seit acht Monaten arbeitet ihr Team an einer neuen Plattform für einen großen Versicherer. Acht Monate Nachtschichten, Pizza-Kartons und „Das schaffen wir schon"-Durchhalteparolen. Heute war die große Demo beim Kunden.

Der Projektleiter auf Kundenseite hat genau sieben Minuten gebraucht, um den Satz auszusprechen, den Lisa seitdem nicht mehr aus dem Kopf bekommt: „Das ist nicht das, was wir bestellt haben."

Nicht das, was sie bestellt haben. Acht Monate. Ein sechsstelliges Budget. Und ein Team, das alles gegeben hat.

Was ist passiert?

Der Fehler, der fast jedes Projekt bedroht

Lisas Geschichte ist kein Einzelfall. Sie ist der Normalfall. Studien zeigen seit Jahrzehnten dasselbe Bild: Die Mehrzahl aller folgenschweren Fehler in der Softwareentwicklung entsteht nicht beim Programmieren. Nicht beim Testen. Nicht beim Deployment. Sondern ganz am Anfang – bei den Anforderungen.

Denk mal kurz darüber nach. Das Team hat nicht schlecht programmiert. Die Architektur war solide. Die Tests waren grün. Aber das System, das sie gebaut haben, war das falsche System. Weil niemand genau genug hingehört hat. Weil niemand die richtigen Fragen gestellt hat. Weil die Anforderungen auf einem Bierdeckel Platz gefunden hätten – und ungefähr so präzise waren.

Genau hier beginnt die Geschichte des Requirements-Engineering. Und sie beginnt mit einer unbequemen Wahrheit: Technische Exzellenz rettet kein Projekt, das die falschen Dinge baut.

Was Requirements-Engineering wirklich bedeutet

Wenn ich Menschen erzähle, dass ich mich mit Requirements-Engineering beschäftige, sehe ich oft ein höfliches Nicken. „Ah, ihr schreibt die Anforderungen auf." Ja. Und nein. Das ist ungefähr so, als würde man sagen, ein Architekt zeichnet Striche auf Papier.

Requirements-Engineering ist ein systematischer Ansatz, um die Wünsche und Bedürfnisse aller Beteiligten zu verstehen, zu dokumentieren und sicherzustellen, dass am Ende ein System entsteht, das diesen Anforderungen wirklich entspricht. Es umfasst vier Haupttätigkeiten, die wie ein Herzschlag das Projekt am Leben halten: Ermitteln, Dokumentieren, Prüfen und Verwalten.

Ein wunderbares Bild aus der RE-Fachliteratur( z.B. die Veröffentlichungen der SOPHISTEN) macht das greifbar: das „Requirements-Brain“. Stell dir drei spezialisierte Gehirne vor, die zusammen ein Projekt tragen. Das Requirements-Brain weiß alles über das Problem. Das Architektur-Brain kennt die Lösung. Und das Management-Brain behält Pläne und Ressourcen im Blick. Keines dieser Gehirne kann allein funktionieren – sie brauchen einander, wie die Musiker in einem Orchester.

Und der Requirements-Engineer? Der ist der Dirigent. „Der Mittler zwischen den Welten“. Der Mensch, der morgens mit dem Fachabteilungsleiter über Geschäftsprozesse spricht, mittags mit dem Architekten über Schnittstellen diskutiert und nachmittags dem Tester erklärt, was eigentlich getestet werden soll. Er braucht analytisches Denken, Empathie, Kommunikationsstärke – und eine gehörige Portion Frusttoleranz.

Die Kunst des Zuhörens: Anforderungen ermitteln

Zurück zu Lisa. Wo genau ist es schiefgelaufen?

Am Anfang stand ein dreiseitiges Dokument. Der Kunde hatte seine „Anforderungen" in Prosa formuliert. Blumig, begeistert, voller Visionen. „Das System soll intuitiv sein." „Die Bearbeitung soll schnell gehen." „Alle relevanten Daten müssen verfügbar sein." Klingt vernünftig, oder? Aber versuch mal, daraus Software zu bauen.

Was Lisa fehlte, war ein systematischer Ermittlungsprozess. Und der beginnt weit vor der ersten Zeile Code – er beginnt mit den Menschen.

Stakeholder: Die unsichtbaren Entscheider

Wer hat eigentlich Anforderungen an das System? Die Antwort klingt einfach, ist es aber nicht. Natürlich die späteren Anwender. Aber auch der Datenschutzbeauftragte, der nachts schweißgebadet aufwacht, wenn er an die DSGVO denkt. Die IT-Abteilung, die das System später betreiben muss. Der Betriebsrat, der mitbestimmen will. Und manchmal sogar der Reinigungsdienst, der wissen muss, ob die neuen Terminals spritzwassergeschützt sind.

Stakeholder, die du übersiehst, rächen sich. Immer. Meistens drei Wochen vor Go-Live.

Was der Kunde wirklich will: Das Kano-Modell

Einer der faszinierendsten Aspekte der Anforderungsermittlung ist die Erkenntnis, dass Kunden oft gar nicht wissen, was sie wollen. Oder genauer: Sie können nicht artikulieren, was sie als selbstverständlich voraussetzen.

Das Kano-Modell macht das greifbar. Es unterscheidet drei Arten von Anforderungen:

Basisfaktoren sind die Dinge, über die niemand spricht – bis sie fehlen. Kein Hotelgast fragt an der Rezeption: „Gibt es bei euch auch Bettwäsche?" Aber wenn er ins Zimmer kommt und das Bett nackt ist, gibt es eine Eins-Stern-Bewertung auf allen Portalen. In der Software: Niemand fordert explizit, dass der Login funktioniert. Aber wehe, er tut es nicht.

Leistungsfaktoren sind das, worüber verhandelt wird. Schnellere Ladezeiten, mehr Speicherplatz, bessere Berichte. Je mehr, desto zufriedener. Diese Anforderungen kennen Kunden gut und sprechen sie aktiv an.

Und dann gibt es die Begeisterungsfaktoren – die Magie. Dinge, die niemand erwartet hat und die für leuchtende Augen sorgen. Die Sitzheizung im Auto war in den 1990ern ein solcher Faktor. Heute ist sie Standard. Der Begeisterungsfaktor von heute ist der Basisfaktor von morgen.

Die bittere Wahrheit: Wenn du nur fragst, was der Kunde will, bekommst du Leistungsfaktoren. Die Basisfaktoren musst du ausgraben. Die Begeisterungsfaktoren musst du erfinden.

Der Werkzeugkasten

Für die Ermittlung steht ein ganzer Werkzeugkasten bereit: Brainstorming-Sessions, die manchmal chaotisch und immer produktiv sind. Interviews, bei denen du mehr zuhörst als reden. Workshops, in denen Sticky Notes die Wände erobern. Feldbeobachtungen, bei denen du den Anwendern über die Schulter schauen und plötzlich verstehen, warum sie den Workaround mit der Excel-Tabelle so lieben. Und Prototypen, die mehr sagen als tausend Seiten Spezifikation.

Die Macht der Worte: Anforderungen formulieren

Angenommen, du hast zugehört. Wirklich zugehört. Du weißt jetzt, was das System können soll. Aber wie bringst du das zu Papier, ohne dass es in der Übersetzung verloren geht?

Hier kommt eines der wirkungsvollsten Werkzeuge des Requirements-Engineering ins Spiel: die Anforderungsschablone.

„Das System soll irgendwas machen" – und warum das nicht reicht.

Stell dir eine Anforderung vor wie einen Satz, den du in eine Form gießt. Die Schablone gibt jedem Baustein seinen Platz: Wer tut etwas? Was genau? Unter welcher Bedingung? Und wie verbindlich ist das?

„Wenn der Benutzer auf Speichern klickt, MUSS das System die Daten innerhalb von 2 Sekunden in der Datenbank persistieren."

Vergleich das mit: „Die Daten sollen gespeichert werden."

Der Unterschied? Im ersten Satz wissen Entwickler, Tester und Auftraggeber exakt, was erwartet wird. Im zweiten Satz weiß es niemand. Und jeder wird etwas anderes hineininterpretieren.

Die Verbindlichkeit wird dabei bewusst über Schlüsselwörter gesteuert: MUSS ist nicht verhandelbar. SOLL ist wichtig, aber es gibt Spielraum. WIRD ist ein Versprechen für die Zukunft. Diese drei kleinen Wörter sparen Unternehmen Millionen – weil plötzlich klar ist, worüber noch diskutiert werden kann und worüber nicht.

User Stories: Wenn der Mensch im Mittelpunkt steht

Im agilen Umfeld hat sich ein anderes Format durchgesetzt, das ich besonders liebe – nicht weil es perfekt ist, sondern weil es den Menschen in den Mittelpunkt stellt: die User Story.

„Als Bibliotheksbenutzer möchte ich Bücher online reservieren, damit ich sie bei meinem nächsten Besuch direkt abholen kann."

Drei Teile. Eine Rolle, ein Wunsch, ein Nutzen. Fertig? Nicht ganz. Eine User Story ist kein fertiges Dokument – sie ist ein Versprechen auf ein Gespräch. Die Details entstehen im Dialog, in der gemeinsamen Diskussion zwischen Product Owner, Team und Stakeholdern. Ergänzt wird sie durch Akzeptanzkriterien, die messbar machen, wann die Story wirklich fertig ist.

Die heimlichen Stars: Nicht-funktionale Anforderungen

Es gibt eine Kategorie von Anforderungen, die in fast jedem Projekt sträflich vernachlässigt wird. Und die für mehr gescheiterte Projekte verantwortlich ist, als die meisten Menschen ahnen: die nicht-funktionalen Anforderungen.

Funktionale Anforderungen sagen, was das System tun soll. Nicht-funktionale Anforderungen sagen, wie gut es das tun soll. Performance, Sicherheit, Benutzbarkeit, Skalierbarkeit, Barrierefreiheit, Datenschutz.

Stell dir vor, du bestellst ein Auto. „Es soll fahren" – das ist die funktionale Anforderung. Aber ob es 120 km/h oder 250 km/h schafft, ob es bei minus 20 Grad anspringt, ob der Airbag in 30 Millisekunden auslöst – das sind die nicht-funktionalen Anforderungen. Und die entscheiden darüber, ob du lebend ankommst.

Vertrauen ist gut, Prüfen ist besser

Hand aufs Herz: Wann hast du das letzte Mal deine Anforderungen wirklich geprüft? Nicht abgenickt. Geprüft.

Gute Anforderungen müssen eindeutig sein, konsistent, vollständig, korrekt, testbar und realisierbar. Das klingt selbstverständlich. Ist es aber nicht. In der Realität wimmelt es in den meisten Spezifikationen von vagen Formulierungen, versteckten Widersprüchen und Dingen, die zwar gut klingen, aber schlicht nicht umsetzbar sind.

Das RE-Regelwerk: Therapeut für kranke Anforderungen

Eines der cleversten Werkzeuge, das ich kenne, ist das sogenannte RE-Regelwerk. Es legt Anforderungen buchstäblich auf die Couch und analysiert ihre sprachlichen Schwächen. Die Methode basiert auf Erkenntnissen des Neurolinguistischen Programmierens und funktioniert verblüffend einfach:

Jemand schreibt: „Das System soll die Daten schnell verarbeiten."

Das RE-Regelwerk fragt gnadenlos nach: „Schnell" – wie schnell? In Millisekunden? Sekunden? „Verarbeiten" – was genau heißt das? Speichern? Transformieren? Weiterleiten? Und welche Daten eigentlich?

Am Ende wird aus dem schwammigen Satz eine präzise Anforderung: „Das System MUSS die eingehenden Schadensmeldungen innerhalb von 500 Millisekunden validieren und in der Datenbank persistieren."

Das ist der Unterschied zwischen einer Anforderung, die Wände schmückt, und einer, die Software formt.

Wenn Anforderungen sich widersprechen

Und dann gibt es Konflikte. Der Vertrieb will maximale Flexibilität, die Compliance-Abteilung will maximale Kontrolle. Der Anwender will es einfach, die Sicherheitsabteilung will es sicher. Diese Konflikte sind normal – gefährlich werden sie erst, wenn niemand sie anspricht.

Professionelles Requirements-Engineering kennt dafür einen klaren Prozess: Konflikte identifizieren, analysieren und auflösen. Manchmal durch Kompromisse. Manchmal durch Eskalation. Und manchmal durch eine kreative Neugestaltung, die beide Seiten glücklich macht. Aber immer transparent, immer dokumentiert.

Die Reise geht weiter: Anforderungen verwalten

Ein weit verbreiteter Irrtum: Anforderungen werden einmal geschrieben und dann umgesetzt. Die Realität? Anforderungen leben. Sie ändern sich, werden verfeinert, priorisiert, verschoben, verworfen. Ein System, das zu Beginn 50 Anforderungen hatte, hat am Ende oft 500 – und die Hälfte davon war am Anfang noch gar nicht denkbar.

Traceability: Den roten Faden nicht verlieren

Stell dir vor, ein Geschäftsziel ändert sich. Welche Anforderungen sind betroffen? Welche Testfälle müssen angepasst werden? Welcher Code muss geändert werden? Ohne Traceability – die Nachverfolgbarkeit von Anforderungen durch alle Ebenen hindurch – bist du blind. Mit Traceability hast du einen roten Faden, der von den Geschäftszielen über die Stakeholder-Anforderungen und Systemanforderungen bis hinunter zu den Testfällen führt.

Wenn sich alles ändert: Change-Management

Änderungen sind kein Feind. Sie sind ein Zeichen dafür, dass jemand nachdenkt. Aber unkontrollierte Änderungen sind ein Projektkiller. Deshalb braucht jedes Projekt ein Change-Management: Änderungen werden erfasst, bewertet, priorisiert und kontrolliert umgesetzt. Nicht um Bürokratie zu schaffen, sondern um sicherzustellen, dass niemand im Blindflug unterwegs ist.

Klassisch oder agil? Die falsche Frage.

„Machst du klassisches oder agiles RE?" Diese Frage höre ich ständig. Und meine Antwort ist immer dieselbe: Das ist die falsche Frage. Die richtige Frage lautet: Verstehst du deine Stakeholder? Formulierst du deine Anforderungen klar? Prüfst du deren Qualität? Behältst du den Überblick?

Im klassischen Umfeld geschieht das mit umfassenden Spezifikationen, formalen Reviews und phasenweisem Vorgehen. Im agilen Umfeld mit User Stories, Sprint Reviews und kontinuierlichem Backlog Refinement. Die Werkzeuge unterscheiden sich. Die Prinzipien sind dieselben.

Requirements-Engineering ist immer agil – weil es immer auf die Menschen hört, immer auf Veränderung reagiert und immer das Ziel im Blick behält.

Und Lisa?

Lisa hat übrigens aus dem Desaster gelernt. Beim nächsten Projekt hat sie als Erstes einen Stakeholder- Workshop organisiert. Hat Personas erstellt. Hat die Kontextgrenzen sauber definiert. Hat Anforderungen in Schablonen gegossen und mit dem REgelwerk geprüft. Hat Traceability aufgebaut, von den Geschäftszielen bis zu den Testfällen.

Das nächste Projekt? Wurde pünktlich ausgeliefert. Innerhalb des Budgets. Und der Kunde hat bei der Abnahme nicht den Kopf geschüttelt, sondern gelächelt.

Weil jemand die richtigen Fragen gestellt hat. Rechtzeitig.

Ich arbeite seit 2009 als RequirementEngineer und bin u.a. durch die SOPHISTen ausgebildet wurden und bin ein großes Fangirl von ihnen und kann sie nur empfehlen.

Dieser Artikel basiert auf dem Standardwerk „Requirements-Engineering und -Management" von Chris Rupp & die SOPHISTen, 6. Auflage, Carl Hanser Verlag.