Requirements richtig verstehen, bevor man sie umsetzt

Viele Architektur- und Entwicklungsprobleme entstehen nicht im Code, sondern viel früher: beim falschen Verständnis von Requirements.

Was am Anfang wie eine klare Anforderung aussieht, ist in der Praxis oft nur eine Interpretation, eine Annahme oder eine unvollständige Beschreibung eines Problems.

1. Requirements sind selten vollständig

Ein klassischer Fehler ist die Annahme, dass Requirements bereits „fertig“ sind, sobald sie dokumentiert oder kommuniziert wurden.

In der Realität sind sie meist:

• unvollständig
• kontextabhängig
• implizit statt explizit

In der Softwareentwicklung gilt deshalb oft sinngemäß der Gedanke aus der agilen Praxis: Requirements sind keine Spezifikation der Wahrheit, sondern eine Momentaufnahme des Verständnisses.

2. Das Problem der Lösungsvoreingenommenheit

Ein häufiger Fehler ist, Requirements direkt als technische Lösung zu lesen.

Beispiel:

• „Wir brauchen ein Dashboard“ wird direkt als Frontend-Feature interpretiert
• „Wir brauchen eine API“ wird automatisch als REST-Service umgesetzt

Damit wird das eigentliche Problem übersprungen und die Lösung vorzeitig festgelegt.

Fachlich betrachtet ist das kritisch, weil laut gängigen Software-Engineering-Prinzipien (z. B. aus der IEEE-Definition von Requirements Engineering) zuerst das Problem und erst danach die Lösung modelliert werden sollte.

3. Gute Analyse beginnt mit Fragen, nicht mit Code

Bevor eine technische Entscheidung getroffen wird, sollten Requirements aktiv hinterfragt werden.

Hilfreiche Fragen sind:

• Welches Problem wird hier tatsächlich gelöst?
• Wer hat dieses Problem und in welchem Kontext?
• Woran würde man erkennen, dass das Problem gelöst ist?
• Ist die Anforderung eine Lösung oder wirklich ein Bedürfnis?

Diese Art von Analyse wird häufig im Requirements Engineering als „Problem Space Exploration“ beschrieben.

4. Implizite Requirements sind die gefährlichsten

Die schwierigsten Anforderungen stehen selten im Ticket.

Sie entstehen durch Annahmen wie:

• „Das muss schnell sein“
• „Das ist sicherheitskritisch“
• „Das wird später sicher erweitert“

Solche Aussagen sind ohne Definition wertlos, aber sie beeinflussen Architekturentscheidungen massiv.

Erfahrene Architekten versuchen deshalb, implizite Anforderungen explizit zu machen, bevor sie designen.

5. Best Practice: Trennung von Problem und Lösung

Ein zentrales Prinzip aus der Softwarearchitektur ist die klare Trennung zwischen Problemraum und Lösungsraum.

Im Problemraum wird beschrieben:

• Was soll erreicht werden
• Warum existiert dieses Bedürfnis
• Welche Einschränkungen gibt es

Im Lösungsraum wird dann entschieden:

• Welche Architektur passt dazu
• Welche Technologien sinnvoll sind
• Wie die Umsetzung konkret aussieht

Wenn diese Trennung fehlt, entstehen oft overengineerte oder falsch ausgerichtete Systeme.

6. Evolutionäre Klarheit statt perfekter Planung

In modernen Ansätzen wie agiler Softwareentwicklung oder Domain-Driven Design wird Requirements-Arbeit nicht als einmaliger Schritt verstanden.

Stattdessen entwickeln sich Requirements iterativ durch Feedback, Prototyping und reale Nutzung.

Das bedeutet:

• Verständnis wächst während der Umsetzung
• Architektur passt sich dem echten Bedarf an
• Frühe Annahmen werden aktiv überprüft

Fazit

Requirements zu verstehen ist keine reine Dokumentationsaufgabe, sondern ein aktiver Analyseprozess.

Die Qualität eines Systems hängt stark davon ab, wie gut das zugrunde liegende Problem verstanden wurde, bevor die erste Zeile Code geschrieben wird.

Oder anders gesagt: Gute Software entsteht nicht aus perfekten Requirements, sondern aus gut verstandenen Problemen.