„Das haben wir schon immer so gemacht“ ist keine Anforderung

Dieter Goetz — Fri, 25 Sep 2026 14:56:17 +0000

In fast jedem länger bestehenden System gibt es Dinge, die niemand mehr hinterfragt.

Ein Feld ist Pflichtfeld.
Eine Freigabe braucht drei Unterschriften.
Eine Maschine wartet auf ein bestimmtes Signal.
Ein Datensatz enthält einen Wert, den niemand zu verwenden scheint.
Ein Prozess hat sieben Schritte, obwohl fünf offensichtlich genügen würden.

Fragt man nach dem Grund, kommt irgendwann eine bemerkenswert ehrliche Antwort:

„Das haben wir schon immer so gemacht.“

Das klingt harmlos.

Für Requirements Engineering ist es ein Warnsignal.

Eine vernünftige Entscheidung kann ihre Begründung überleben

Viele solcher Regeln waren ursprünglich keineswegs unsinnig.

Vielleicht gab es eine technische Einschränkung. Vielleicht verlangte ein früherer Kunde diesen Ablauf. Vielleicht musste eine alte Schnittstelle unterstützt werden. Vielleicht löste der zusätzliche Prozessschritt einmal ein echtes Problem.

Die Organisation passte sich an.

Der Ablauf funktionierte.

Er wurde wiederholt.

Und irgendwann verschwand der ursprüngliche Grund.

Was blieb, war das Verhalten.

Mit genügend Zeit verändert sich dann auch die Sprache:

„Das System muss …“

Aus einer früheren Entscheidung ist scheinbar eine Anforderung geworden.

Das ist der interessante Punkt.

Nicht weil die alte Entscheidung notwendigerweise falsch ist.

Sondern weil niemand mehr weiß, ob sie noch notwendig ist.

Verhalten ist kein Beweis für eine Anforderung

In bestehenden Organisationen beobachten wir ständig Verhalten.

Menschen benutzen bestimmte Arbeitsabläufe. Teams pflegen bestimmte Daten. Bediener führen bestimmte Schritte aus. Software enthält bestimmte Regeln.

Bei der Ermittlung von Anforderungen ist es verlockend, dieses beobachtete Verhalten direkt zu übernehmen:

So wird es gemacht → also muss es so gemacht werden.

Doch dieser Schluss ist nicht zulässig.

Das beobachtete Verhalten kann eine echte Anforderung widerspiegeln.

Es kann aber genauso gut das Ergebnis sein von:

einer alten technischen Einschränkung
einem früheren Workaround
einer inzwischen verschwundenen Schnittstelle
einer organisatorischen Gewohnheit
einer historischen Kundenanforderung
einer Entscheidung, deren Begründung verloren gegangen ist

Das Verhalten allein sagt uns nicht, welcher Fall vorliegt.

Die gefährliche Frage

Eine klassische Requirements-Frage lautet:

„Was muss das System tun?“

Bei einem bestehenden System reicht sie oft nicht.

Eine mindestens ebenso wichtige Frage ist:

„Warum muss es das tun?“

Und danach:

„Gilt dieser Grund noch?“

Das kleine Wort warum kann einen erheblichen Unterschied machen.

Denn wenn die Antwort lautet:

„Das war wegen System X.“

und System X seit acht Jahren nicht mehr existiert, haben wir möglicherweise keine Anforderung gefunden.

Wir haben ein Fossil gefunden.

Aber alte Regeln nicht einfach löschen

Auch die gegenteilige Reaktion wäre ein Fehler.

„Niemand kennt den Grund“ bedeutet nicht automatisch „wir brauchen es nicht“.

Organisationen besitzen viel implizites Wissen. Eine scheinbar überflüssige Regel kann eine wichtige Sicherheits-, Betriebs- oder Geschäftsbedingung schützen, deren Zusammenhang nur nicht mehr offensichtlich ist.

Die Aufgabe besteht deshalb nicht darin, alte Regeln aggressiv zu entfernen.

Die Aufgabe besteht darin, ihren Status wieder sichtbar zu machen.

Ist es eine aktuelle Anforderung?

Eine technische Einschränkung?

Eine Designentscheidung?

Eine Gewohnheit?

Ein Workaround?

Oder lediglich etwas, das überlebt hat?

Diese Unterscheidung ist wichtiger als sie klingt.

Anforderungen brauchen Herkunft

Eine Anforderung ohne nachvollziehbare Herkunft ist schwer zu beurteilen.

Wenn wir wissen, warum sie existiert, können wir sie diskutieren.

Wenn wir wissen, wer oder was sie benötigt, können wir ihre Gültigkeit überprüfen.

Wenn wir ihre Abhängigkeiten kennen, können wir beurteilen, was passiert, wenn sich die Umgebung verändert.

Fehlt all das, bleibt nur der Satz:

„Das System muss das können.“

Und nach einigen Jahren:

„Das haben wir schon immer so gemacht.“

Genau dort beginnt ein Teil der Requirements-Schulden, die sich in langlebigen Systemen ansammeln.

Ein kleiner Test für bestehende Anforderungen

Wenn du das nächste Mal auf eine alte, scheinbar selbstverständliche Anforderung stößt, versuche nicht zuerst, sie neu zu formulieren.

Frage stattdessen:

Welches Problem würde entstehen, wenn wir diese Anforderung heute nicht hätten?

Eine konkrete Antwort ist wertvoll.

Schweigen ist ebenfalls wertvoll.

Denn dann weißt du, dass hier noch etwas untersucht werden muss.

Dieser Fall ist Teil des RequiScribe Requirements Failure Field Guide – einer Sammlung kleiner, wiederkehrender Muster, durch die Anforderungen falsch verstanden, übernommen oder formalisiert werden.

Die deutsche Ausgabe des Field Guide:

https://requiscribe.es/de/publications/requirements-failure-field-guide/

RequiScribe untersucht Requirements Engineering aus einer einfachen Perspektive: Nicht nur was als Anforderung geschrieben wurde, sondern woher es kam, warum es existiert und was wir tatsächlich darüber wissen.

The solution arrived before the problem

Dieter Goetz — Thu, 24 Sep 2026 11:09:08 +0000

THE CASE
We need a faster coconut-cracking machine

Upper management decrees: "We want to sell more coconuts." Some other manager proposes: "Then we will definitely need a faster coconut-cracking machine !"

The proposal is concrete, costable and engineerable. What has not been established is whether cracking capacity is what prevents increased sales.

THE TRAP
Solutions make uncertainty disappear

A specific proposal feels like progress. Specificity, plausibility and authority can create the impression that Requirements Engineering has already been done.

THE FAILURE
The answer has occupied the place of the question

A proposed solution has been allowed to take the place of the problem and need it is supposed to address.

FOLLOW THE REASONING
Objective
→
Problem / Need
→
Requirement
→
Solution

THE DIAGNOSTIC
Take the machine away

Remove the proposed solution.

And then ask yourself: "Can the team still explain the desired outcome, the obstacle that currently prevents it and what actually needs to change?"

THE CONSEQUENCE
Doing the wrong thing very well

The solution can be specified, designed, verified and commissioned correctly while the original objective remains unmet.

THE RESPONSE
Keep the solution --- change its status

Does that mean all the work which has been done is in vain ? Not at all:

Keep it as a candidate. Reconstruct

objective → problem → need → requirements → candidate solution,

then assess the candidate against the established need.

QUICK TEST
Remove the proposed solution

Can the team still explain the problem and the need it is intended to satisfy?

Originally published as part of the RequiScribe Requirements Failure Field Guide, Season 01.

DEV Community: Dieter Goetz