Warum Lastenhefte unvollständig sind — und wie Vollständigkeit zählbar wird#
Einseiter zum Methodenpapier „Elementgrenze und Vollständigkeitsraster" (v0.3, 19.10.2026). Das Papier ist die Quelle; dieser Text ist die Kurzfassung für Leser ohne Methodentiefe.
Das Symptom#
Jede Entwicklungsabteilung kennt es: Die FMEA findet Schnittstellen, die im Lastenheft fehlen. Das Handbuch beschreibt Bedienfälle, die kein Requirement kennt. Transport, Reinigung, Werkstattbesuch tauchen erst auf, wenn etwas kaputtgeht. Nicht, weil die Ingenieure schlecht arbeiten — sondern weil keine Methode verlangt, Vollständigkeit an jedem Bauteil nachzuweisen.
Die Ursache#
Anforderungen werden über „das System" geschrieben, in der dritten Person. Niemand deklariert am einzelnen Bauteil, was hereinkommt, was hinausgeht, wer auf der anderen Seite steht, in welcher Lebensphase und in welchem Zustand. Gegen „die Welt" kann niemand Vollständigkeit prüfen. Gegen eine endliche Liste schon — und diese Liste existiert längst, verstreut über bekannte Methoden: die 4M der FMEA, die Lebensphasen der ISO 15288, die Störgrößen des P‑Diagramms, die Verträge des Contract‑Based Design. Nur im Lastenheft steht sie nicht.
Die Maßnahme#
Jedes Bauteil deklariert seine Grenze selbst: was es aufnimmt, was es zusagt, von wem, an wen, in welcher Lebensphase, in welchem Zustand — und wo nichts deklariert ist, zählt das System eine Lücke.
Konkret ändern sich vier Dinge:
- Die Gegenseite wird benannt: Mensch, fremdes technisches System (Stromnetz, Buspartner, der Topf auf dem Kochfeld), Umwelt, Material. Jede Kombination aus Bauteil, Gegenseite, Lebensphase und Zustand ist entweder deklariert, begründet nicht zutreffend — oder eine gezählte Lücke. Leer ist nie stilles Einverständnis.
- Anforderung, FMEA‑Zeile, Gefährdungsanalyse, Handbuchschritt und Testfall entstehen aus derselben Deklaration. Nichts davon wird ein zweites Mal gepflegt; eine Änderung ist überall gleichzeitig da.
- Bedienfälle und vorhersehbare Fehlanwendung werden erzeugt, nicht gesammelt: Die Handlung des Bedieners ist der Use Case, ihre Negation die Fehlanwendung — beides fällt aus dem Raster statt aus Workshops.
- Die Bilanz findet, woran keiner gedacht hat: Energie und Stoff, die hineingehen, müssen hinaus. Der Rest — Wärme, Lärm, Vibration — wird als undeklarierter Abgang sichtbar.
Der Prüfstein#
Die Maßnahme ist zugleich der Test der Ursache: Wenn die Ursache die fehlende Deklaration am Bauteil ist, dann beseitigt die Grenzdeklaration gegen das Raster die nachträglichen Vollständigkeitsfunde — messbar an drei Größen: (a) Anzahl der Lücken, die das Raster vor der FMEA findet, (b) Pflegeaufwand je Bauteil in Minuten, (c) Anteil der Deklarationen aus Standardvorlagen statt Handarbeit. Zeitrahmen: ein Pilot an einem Teilsystem, ein Quartal. Findet das Raster keine Lücken, die die FMEA nicht ohnehin gefunden hätte, oder explodiert der Pflegeaufwand, ist der Ansatz widerlegt — dann zurück in die Diagnose.
Wer handeln kann#
Der Eigentümer des Entwicklungsprozesses — Entwicklungsleitung bzw. Prozessverantwortung für Requirements und FMEA. Die Entscheidung ist klein: ein Pilot‑Teilsystem benennen, das Vokabular (Gegenseiten, Lebensphasen, Flussgrößen) einmal festlegen, die drei Messgrößen vor dem Start fixieren.
Der Preis des Unterlassens#
Die Vollständigkeit bleibt dort, wo sie heute ist: in der FMEA, im Feld und in der Reklamation. Jede dieser drei Stellen ist teurer als die Deklaration am Bauteil — die FMEA um Wochen, das Feld um Jahre.
Thomas Arends. Einseiter zum Methodenpapier Elementgrenze und Vollständigkeitsraster, 19.10.2026.