Die zwei Säulen der Anforderungen
Es ist Freitagnachmittag, 16:00 Uhr. Du hast gerade das Feature gemerged, die Pipeline ist grün, und du fühlst dich unbesiegbar. Dann kommt die Slack-Nachricht vom Product Owner: “Hey, sieht gut aus, aber warum passiert X, wenn ich Y mache? Das war doch ganz anders besprochen.”
Dein Wochenende löst sich gerade in Luft auf. Nicht, weil dein Code schlecht ist – technisch ist er wahrscheinlich brillant. Sondern weil du ein Problem gelöst hast, das niemand hatte, oder eine Anforderung anders verstanden hast, als sie gemeint war.
Genau hier kommt Requirements Engineering (RE) ins Spiel.
Ich habe vor Kurzem mein IREB CPRE FL Zertifikat (Certified Professional for Requirements Engineering Foundation Level) gemacht. Klingt trocken? Dachte ich auch erst. Aber eigentlich ist es Selbstverteidigung für Entwickler. RE ist nicht der Papierkram, den wir machen müssen, bevor wir coden dürfen. Es ist das Werkzeug, das sicherstellt, dass wir nicht Monate an Arbeit in die Tonne treten.
Lass uns die Theorie beiseite schieben und schauen, was du davon wirklich im Code-Alltag brauchst.
“Es funktioniert doch!” – Der Trugschluss (Funktionale vs. Nicht-funktionale Anforderungen)
Wir Entwickler lieben funktionale Anforderungen. Das ist die Logik, das Was.
- “Der User kann sich einloggen.”
- “Das System berechnet die Mehrwertsteuer.”
- “Der Warenkorb lässt sich leeren.”
Das lässt sich perfekt in if/else-Blöcke gießen. Haken dran. Aber warum scheitern Projekte trotzdem, obwohl alle funktionalen Anforderungen erfüllt sind? Weil wir die Qualitätsanforderungen (Nicht-funktionale Anforderungen, NFRs) und Randbedingungen vergessen haben.
Im IREB-Kontext unterscheiden wir strikt:
- Funktionale Anforderung: Was das System tut.
- Qualitätsanforderung: Wie gut das System es tut (Performance, Sicherheit, Usability).
- Randbedingung: Was uns einschränkt (DSGVO, Legacy-Schnittstellen, Budget).
Das Praxis-Beispiel: Du baust einen “Suchen”-Button. Funktional tut er genau das: Er findet Ergebnisse. Aber wenn die Suche 15 Sekunden dauert, ist das Feature für den User kaputt. Wenn die Suche funktioniert, aber die Datenbank dabei in die Knie zwingt, ist das System kaputt.
Als Engineer musst du derjenige sein, der die Hand hebt und fragt: “Okay, ich kann das bauen. Aber wie viele User müssen das gleichzeitig machen können? Und wie schnell muss die Antwort da sein?” Wenn du diese NFRs nicht klärst, sind sie implizit – und implizite Erwartungen sind die Mutter aller Hotfixes.
Super, dann halten wir das Tempo hoch. Jetzt kommen wir zum vielleicht wichtigsten Teil für das Mindset eines Entwicklers: Priorisierung. Wir neigen dazu, uns auf die coolen, technischen Herausforderungen zu stürzen. Das IREB-Wissen hilft hier, die rosarote Brille abzunehmen.
Hier ist der Entwurf für den Hauptteil (Kano & Kommunikation).
Das Kano-Modell: Warum der “Dark Mode” warten muss
Einer der größten Fehler, den wir machen können: Wir investieren Tage in ein cooles Feature (aka “Gold Plating”), während die Basics wackeln. Das Kano-Modell aus dem Requirements Engineering ist hier der beste Kompass, um Features einzuordnen. Es unterteilt Anforderungen in drei Kategorien:
- Basis-Faktoren (Must-haves):
Das sind die Dinge, für die dir niemand dankt, wenn sie funktionieren. Aber wenn sie fehlen oder kaputt sind, ist die Hölle los.
- Beispiel: Ein Passwort-Reset. Niemand sagt: “Wow, geiler Reset-Flow!”. Aber wenn die Mail nicht ankommt, ist deine App für den User tot.
- Leistungs-Faktoren (More is better):
Hier gilt: Je mehr/besser, desto zufriedener der User. Das sind oft die Dinge, die wir in Specs vergleichen.
- Beispiel: Ladezeiten, Speicherplatz, Batterielaufzeit.
- Begeisterungs-Faktoren (Delighters):
Damit rechnet der User nicht. Wenn es fehlt: egal. Wenn es da ist: Party.
- Beispiel: Der Dark Mode, lustige Lade-Animationen, Konfetti beim Absenden eines Formulars.
Das Learning für uns Devs: Wir lieben es, Begeisterungs-Faktoren zu bauen. Das macht Spaß. Aber im Sinne des Requirement Engineerings müssen wir diszipliniert sein: Erfülle die Basis zu 100%, bevor du die Begeisterung startest.
Ein Dark Mode rettet dich nicht vor 1-Stern-Bewertungen im App Store, wenn der Login (Basisfaktor) sporadisch timeouts wirft. Wenn du das nächste Mal ein Ticket ziehst, frag dich: Ist das Basis, Leistung oder Begeisterung? Und haben wir die Basis wirklich schon im Griff?
Weg von “Stakeholderisch”, hin zu Code: Die gemeinsame Sprache
Ein riesiger Teil des IREB-Lehrplans dreht sich darum, Anforderungen eindeutig zu formulieren. Missverständnisse sind teuer.
In der Theorie (IREB) lernen wir Satzschablonen. Das klingt sehr deutsch und bürokratisch, hat aber einen wahren Kern. Statt zu sagen: “Das System soll bei Fehlern den User informieren.” (Was für Fehler? Wie informieren? SMS? Pop-up?), zwingt uns eine Schablone zu Präzision:
“Das System muss dem [Rolle: Administrator] die Möglichkeit bieten, [Prozess: Fehlerlogs einzusehen], um [Nutzen: das Problem zu beheben].”
Die Brücke zur Praxis: Gherkin & BDD
Als Entwickler können wir dieses Prinzip noch einen Schritt weiter treiben – und hier verlassen wir den strikten IREB-Pfad und biegen in Richtung Modern Engineering ab. Wir nutzen die Präzision der Anforderung direkt für unsere Tests.
Statt Word-Dokumente zu wälzen, übersetzen wir Requirements oft in Gherkin (Given-When-Then). Das ist im Grunde die programmierbare Version einer IREB-Satzschablone.
Vage Anforderung: “Der Warenkorb-Rabatt soll funktionieren.”
Präzises RE (Gherkin-Style):
Feature: Warenkorb Rabatte
Scenario: 10% Rabatt ab 100 Euro Bestellwert
GIVEN der Warenkorb enthält Artikel im Wert von 95 Euro
WHEN ich einen Artikel für 10 Euro hinzufüge
THEN soll die Gesamtsumme 105 Euro betragen
AND ein Rabatt von 10% abgezogen werden
Das Geniale daran: Diese Anforderung ist gleichzeitig deine Dokumentation UND dein automatisierter Test. Wenn der Test grün ist, ist die Anforderung erfüllt. Punkt. Das ist der Moment, wo Requirements Engineering aufhört, “Papierkram” zu sein, und zum integralen Teil deiner CI/CD-Pipeline wird.