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.
Top comments (0)