Es gibt einen Satz, der in jedem zweiten Lastenheft steht und in keiner Prüfung auffällt:
Die Baugruppe muss die erforderliche Festigkeit “gewährleisten”.
Grammatisch korrekt, fachlich plausibel und vollständig unbrauchbar. Vier Fragen bleiben offen:
- welche Kraft,
- zwischen welchen Elementen,
- wie viel Kraft,
- geprüft womit.
Alles Nachgelagerte — technische Auslegung, Test, Zulassung, Fehleranalyse — baut auf diesem Satz auf.
Die übliche Erklärung um das Problem zu lösen lautet: mangelnde Sorgfalt. Man müsse Ingenieure besser schulen, Reviews härter fahren, Checklisten einführen.
Diese obige Erklärung ist falsifizierbar, und sie ist widerlegt!
Seit dreißig Jahren wird geschult, reviewt und Checklisten geführt. Aber der Satz steht immer noch da.
Die These welche ich hier aufstelle: Anforderungsqualität ist kein Disziplinproblem, sondern ein Strukturproblem. Solange eine Anforderung als Fließtext erfasst wird, ist ihre Qualität eine Frage der Tagesformem (ich habe gesehen wie ein Unternehmen daraus versucht hat Ki zu trainiren). Wird die Anforderung als Datensatz erfasst und der Satz daraus erzeugt, ist sie eine Frage der Feldbelegung. Genau das macht die Anforderung prüfbar, während man tippt.
Was etablierte Methoden lösen#
Die Vorstellung, man müsse Anforderungen frei formulieren können, ist in der der industriellen Praxis schon längst aufgegeben. Drei Ansätze haben sich durchgesetzt und sind der Ausgangspunkt meiner Betrachtung, nicht mein Gegner:
EARS (Easy Approach to Requirements Syntax) unterscheidet fünf Satztypen nach ihrer Auslösebedingung — dauerhaft geltend, zustandsgebunden, ereignisgetrieben, unerwünschtes Verhalten, optionales Merkmal. Der Gewinn: Der Unterschied zwischen „solange" und „wenn" wird sichtbar und ist nicht mehr Auslegungssache. Die Möglichkeit zur deterministischen Erfassung von unerwünschtem Verhalten habe ich unter Erlaubter Raum beschrieben. Die SOPHIST-MASTER-Schablone zerlegt den die Anforderung in Bedingung, System, rechtliche Verbindlichkeit, Prozesswort und Objekt. Der Gewinn: Die Verbindlichkeit — muss, sollte, wird — ist ein eigenes Feld statt einer möglichen Nuance im Text.
Der INCOSE Guide for Writing Requirements benennt Eigenschaften, die eine gute Anforderung haben muss: eindeutig, einzeln, vollständig, verifizierbar, umsetzbar.
Zusammen decken die drei ab, was ein Satz aussagen muss. Was diese Mthoden nicht abdecken, ist, was die Anforderung tragen muss.
Die Lücke: Ein Objektfeld zu wenig#
Nehmen wir einen Satz, der nach allen drei Mustern korrekt ist:
Solange Normalbetrieb gilt, MUSS das Verbindungselement die Querkraft leiten.
Check:
- a) Bedingung vorhanden
- b) System vorhanden
- c) Verbindlichkeit vorhanden
- d) Prozesswort vorhanden
- e) Objekt vorhanden.
Ein Review nach INCOSE-Kriterien findet nichts zu beanstanden. –> Pass!
Die Anforderung ist trotzdem unvollständig, und zwar an einer Stelle, die keines der Muster abfragt: Von wo nach wo?
Ein Fluss hat eine Richtung. „Leitet Querkraft" ohne Quelle und Senke sagt nicht, welchen Weg die Kraft nimmt, welche Nachbarelemente betroffen sind, wo die Gegenkraft entsteht und welche Schnittstellen berührt werden.
Die Information geht nicht verloren, weil jemand nachlässig war. Sie geht verloren, weil es kein Feld dafür gibt.
Die Erweiterung ist minimal: Aus einem Objektfeld werden drei.
[Zustand] · [Bedingung] · [Verbindlichkeit] · [Träger] ·
[Wirkverb] · [Fluss] · von [Quelle] nach [Senke]Nicht jedes Verb braucht alle drei. Es gibt drei Muster, und das Verb bestimmt, welches gilt:
| Muster | Form | Beispiel |
|---|---|---|
| Fluss | von … nach … | leitet Energie von A nach B |
| Lage | … relativ zu … | hält A relativ zu B in Lage |
| Sperre | … an … | sperrt Medium an der Trennstelle |
Wer das Verb wählt, bekommt automatisch die passenden Felder. Ein Entscheidungsschritt weniger, nicht mehr.
Warum Messfähigkeit zwingend an der Struktur hängt#
Die ISO/IEC/IEEE 29148 führt Verifizierbarkeit einer Anforderung als eine Eigenschaft, die jede Anforderung besitzen muss. Sie schreibt dabei nicht vor, dass jeder Nachweis quantitativ zu führen ist — Inspektion und Demonstration sind gleichrangige Nachweisarten neben Test und Analyse.
Genau diese Doppelung wird in der Praxis zum Einfallstor. Wer keine Zahl nennen kann, beruft sich auf die qualitative Nachweisart und schreibt weiter „gewährleistet". Formal ist die Anforderung dann verifizierbar. Real ist sie es nicht, weil niemand sagen kann, wann sie verletzt wäre.
Die Auflösung liegt nicht in einer strengeren Auslegung der Norm, sondern in der Feldstruktur. Merkmal, Operator, Wert und Einheit sind eigene Felder. Wer sie nicht füllen kann, sieht das sofort — und muss sich entscheiden: nachschärfen oder als offen markieren. Beides ist ehrlich. Der unscharfe Satz, der als scharf durchgeht, ist es nicht.
Eine Funktion trägt dabei regelmäßig mehrere Merkmale. Das ist kein Sonderfall, sondern der Normalfall:
Der Wandler wandelt mechanische in elektrische Energie für den Abgang.
· Spannung = 400 V · Frequenz = 400 Hz · Dauerstrom ≥ 30 A · Stromart = Wechselstrom
Vier Merkmale, eine Funktion. Wer daraus vier Anforderungen macht, zerreißt den Zusammenhang; wer sie in einen Fließtextsatz presst, macht ihn unprüfbar. Die n:1-Beziehung zwischen Merkmal und Funktion ist die strukturell richtige Antwort — und sie fällt im Datensatz von selbst an, während sie im Fließtext eine Konvention wäre, an die sich niemand hält.
Der eigentliche Grund warum man so was machen sollte: Kontrolle über Design und Prozess#
Warum die Formulierungsgenauigkeit nicht Selbstzweck ist, zeigt sich in der Fehleranalyse. Zwei Definitionen, die den Anspruch benennen:
Kontrolle über das Design heißt, ein Design so weit in die Funktionen und Merkmale jedes einzelnen Bestandteils zu zerlegen, dass sichergestellt ist, dass die gewünschte Einzel- und Gesamtfunktionalität erreicht wird.
Kontrolle über den Prozess heißt, einen Prozess innerhalb seiner Eingriffsgrenzen so weit in einzelne Schritte zu zerlegen, dass die Einflussfaktoren — Mensch, Maschine, Material, Mitwelt — mit ihrer Auswirkung betrachtet werden können, sodass sichergestellt ist, dass das Produkt gemäß Designvorgaben entsteht.
In beiden Fällen ist die Zerlegung der Kern, und beide Male ist die Funktion die Zerlegungseinheit. Eine FMEA, deren Funktionsspalte anders formuliert ist als das Lastenheft, ist keine Analyse desselben Systems — sie ist eine zweite, unabhängige Beschreibung, die mit etwas Glück ähnlich klingt.
Der Unterschied ist an den erzeugten Fehlern ablesbar:
| Funktionssatz | erzeugter Fehlermodus | brauchbar? |
|---|---|---|
| gewährleistet Festigkeit | Festigkeit nicht gewährleistet | nein — keine Ursachenkette |
| leitet Querkraft von A nach B | leitet nicht · leitet teilweise · leitet nicht von A nach B | ja — Ursachen sitzen an A und B |
Der zweite Fall erzeugt Fehlermodi mit klarer Zuordnung. Die Ursachen liegen an den beiden benannten Schnittstellen — genau die Information, die das dritte Feld liefert und die im ersten Fall fehlt.
Das ist ein zusätzlicher Gewinn der zusätzlichen Felder: Die FMEA-Zeilen werden abgeleitet.
Ein Datensatz, drei Sichten#
Damit ist die eigentliche Struktur benannt. Was heute drei getrennt gepflegte Artefakte sind, ist eine Datenbasis mit drei Projektionen:
Die mittlere Projektion verdient einen eigenen Blick. Modellbasiertes Systems Engineering — ob mit SysML, mit OML oder mit einem hauseigenen Metamodell — verlangt genau die Angaben, die der erweiterte Datensatz bereits enthält: einen Block (Träger), einen gerichteten Fluss (Fluss, Quelle, Senke), einen Zustand und dimensionierte Eigenschaften (Merkmal, Wert, Einheit).
Das übliche Vorgehen ist, Anforderungen zu schreiben und das Modell anschließend daraus nachzubauen. Beides driftet ab dem ersten Änderungsstand auseinander, und die Pflege des Gleichlaufs kostet mehr als die Modellierung selbst. Bei feldbasierter Erfassung entfällt der Nachbau: Der Block ist der Trägerslot, die Schnittstelle ist das Quelle-Senke-Paar. Es gibt nichts zu synchronisieren, weil es nur eine Quelle gibt.
Warum das nicht mehr Aufwand ist, sondern weniger#
Der Einwand liegt nahe: Zwölf Felder auszufüllen dauert länger, als einen Satz zu schreiben. Für den einzelnen Satz stimmt das. Für den Schreibvorgang des Anforderungsmanagements und der Modellierung stimmt es nicht.
Auswählen ist schneller als formulieren. Wer aus einer Liste von dreißig Verben wählt, entscheidet einmal. Wer frei formuliert, entscheidet über Wortwahl, Satzbau, Verbindlichkeit und Detailtiefe gleichzeitig — und wird im Review über jede dieser Entscheidungen erneut sprechen.
Der Review-Zyklus für Formulierung entfällt. Nicht weil besser formuliert wird, sondern weil es für die Fromulierng nichts zu reviewen gibt. Die inhaltliche Prüfung — ob der Wert richtig ist, ob die Senke stimmt, bleibt. Das ist die Diskussion, die man führen will.
Die Folgeartefakte fallen ab. FMEA-Funktionsspalte, Fehlermodi, Schnittstellenliste, Testfallgerüst, Verifikationsmatrix: alles Projektionen derselben Felder. Der Aufwand, der bei der Erfassung entsteht, wird an drei Stellen wieder eingespart.
Damit löst sich auch das Problem, an dem Anforderungsqualität üblicherweise scheitert. Einen normkonformen Satz zu formulieren kostet den Schreibenden Zeit; der Nutzen fällt zwei Rollen weiter an, bei Test und Audit.
Historisch trägt genau eine Strategie: Konformität zum Nebenprodukt machen. Niemand schreibt heute normkonformen Maschinencode von Hand. Nicht weil Programmierer diszipliniert wurden, sondern weil ein Übersetzer den Weg dorthin billiger gemacht hat. Wer Felder füllt, wird nicht standardkonform, weil er soll, sondern weil der Weg zum Ergebnis durch die Struktur führt.
Die Tyrannei der dominanten Zerlegung#
Es gibt einen Grund, warum Anforderung, Modell und FMEA heute auseinanderlaufen, und er ist älter als jedes dieser Werkzeuge.
Tarr, Ossher, Harrison und Sutton haben 1999 für die Softwarearchitektur beschrieben, was sie die tyranny of the dominant decomposition nannten: Jedes System lässt sich nach mehreren Kriterien zerlegen — nach Bauteilen, nach Funktionen, nach Sicherheitsrelevanz, nach Zuständigkeit. Ein Artefakt wird aber typischerweise nur in einer Zerlegung ersellt. Alle anderen Sichten müssen sich verbiegen oder werden zweitrangig.
Im Engineering ist die dominante Zerlegung fast immer die Stückliste. Sie bestimmt die Dokumentenstruktur, die Verantwortlichkeiten und die Freigabewege. Die FMEA braucht die funktionale Zerlegung, die Sicherheitsanalyse eine nach Wirkketten, der Test eine nach prüfbaren Eigenschaften. Jede dieser Sichten baut sich deshalb eine eigene Beschreibung — und ab diesem Moment gibt es keine gemeinsame Wahrheit mehr, sondern nur noch Abgleichaufwand.
Der Ausweg ist nicht, sich auf eine Zerlegung zu einigen. Es ist, keine zu bevorzugen: Die Felder tragen die Information, die Zerlegung ist eine Abfrage. Nach Träger gruppiert entsteht die Stücklistensicht, nach Fluss gruppiert die Wirkkettensicht, nach Merkmal gruppiert die Prüfsicht. Kein Artefakt ist mehr das Original, alle sind Projektionen.
Was das nicht leistet#
Zwei Grenzen, ohne die die Argumentation nicht trägt.
Die Felder erzeugen keine Anforderungen. Sie sorgen dafür, dass eine gefundene Anforderung vollständig aufgeschrieben wird. Ob sie überhaupt gefunden wurde, ist eine andere Frage — und sie hängt an der Vollständigkeitsprüfung der jeweiligen Ebene, nicht an der Schablone. Auf Systemebene gibt es dafür Flussbilanz und Umfeldanalyse; erst auf Bauteilebene wird Vollständigkeit beweisbar.
Vorgegebene Lösungen verschwinden nicht. Kunden geben regelmäßig Lösungen vor — wegen Normen, Bestandsanschlüssen, Ersatzteilversorgung oder Rahmenverträgen. Das ist legitim und oft zwingend. Entscheidend ist nur, dass eine vorgegebene Lösung als Randbedingung geführt wird, nicht als Funktion. Randbedingungen erzeugen keine Fehlermodi; sie werden bei der Freigabe geprüft. Wer sie als Funktion führt, bekommt Fehler wie „Bauteil X nicht vorhanden" — das ist kein Fehler, sondern eine falsch gebaute Konstruktion.
Der Einwand, der ernst zu nehmen ist#
Die stärkste Gegenposition lautet: Ein geschlossenes Vokabular verarmt die Sprache. Es gibt Sachverhalte, für die kein Feld vorgesehen ist, und dann wird gebogen, bis es passt — mit dem Ergebnis, dass die Struktur zwar vollständig ist, aber das Falsche enthält.
Der Einwand trifft zu, und er hat eine Konsequenz: Es muss genau ein Freitextfeld geben. Nicht null. Die Begründung — warum es diese Anforderung gibt, welche Norm sie fordert, welcher Zielkonflikt dahinter steht — bleibt menschlich und gehört prominent platziert. Sie ist nur nicht Teil des normativen Satzes.
Das ist keine Aufweichung, sondern die Bedingung dafür, dass die Härte im Satz durchgehalten wird. Wer nur noch Auswahlfelder bedient, erlebt das Werkzeug als Entmündigung und umgeht es. Wer seine Nuance irgendwo unterbringen kann, presst sie nicht in den Trägerslot.
Ein Nachsatz zur Normenlage#
Wer diesen Gedankengang zu Ende geht, stößt auf eine unbequeme Beobachtung. Anforderungsnormen, Sicherheitsnormen, Prozessreifemodelle, Analysemethodiken — überschneiden sich zu erheblichen Teilen. Sie beschreiben dieselben Sachverhalte in unterschiedlichem Vokabular, mit unterschiedlicher Gliederung und gelegentlich mit wiedersprüchlichen Festlegungen.
Das ist historisch erklärbar: Jede Norm entstand in ihrer Domäne, für ihre Branche, mit ihrem Gremium. Es ist auch nicht durchweg schädlich — eine Automobilnorm darf Dinge festlegen, die in der Medizintechnik unsinnig wären.
Schädlich wird es dort, wo ein Unternehmen mehrere davon gleichzeitig erfüllen muss und für jede ein eigenes Artefakt pflegt. Dann wird derselbe Sachverhalt drei- bis fünffach beschrieben, und die Abweichungen zwischen den Beschreibungen sind reine Fehlerquelle — sie tragen keine Information.
Die Feldstruktur ist auch darauf eine Antwort: Wenn die Information einmal liegt, ist Normkonformität eine Frage der Projektion, nicht der Mehrfachpflege. Welche Norm welche Felder in welcher Anordnung sehen will, ist ein Ausgabeformat.
Ob sich die Regelwerke selbst je konsolidieren, ist eine andere Frage. Man kann darauf warten. Man kann auch die Datenbasis so bauen, dass es keine Rolle mehr spielt.
Wo ich stehe#
Was hier beschrieben ist, baue ich als Werkzeug — unter dem Namen OTSM. Die Feldstruktur, die Projektionen, der Lückenbericht, die Ableitung der FMEA-Zeilen: das läuft.
Fertig ist es nicht. Es wird auch in zwanzig Jahren nicht fertig sein, und ich halte das für den Normalzustand, nicht für ein Eingeständnis. Ein Werkzeug, das Methodik trägt, ist so lange unfertig, wie die Methodik weiterdenkt. Was ich sagen kann: Es geht. Nicht in jeder Ecke, aber in genug Ecken, dass man daran arbeiten kann.
Die Reihe zu dieser Methode:
| Teil | Inhalt |
|---|---|
| Anforderungen als Datensatz | dieser Artikel — Kunde und System, domänenneutral |
| Mechanik | Berührstellen als Vollständigkeitsanker |
| Hardware | Anschlüsse und Feldkopplung |
| Software | Schnittstellen und geteilter Zustand |
Wenn Sie das prüfen wollen#
Ich spiele mit offenen Karten, deshalb der Ablauf ohne Umweg:
Sagen Sie mir Ihre Branche. Nicht Ihr Problem — noch nicht. Die Branche entscheidet, welche Regelwerke gelten, welche Nachweise verlangt werden und wo die Zerlegung üblicherweise dominiert. Das kann ich vorbereiten.
Im Gespräch sagen Sie mir Ihr Problem. Dann passiert eines von zwei Dingen:
Entweder ich zeige Ihnen die Lösung. Das dauert in der Regel keine fünfzehn Minuten, und Sie sehen sie an Ihrem eigenen Fall, nicht an einem Niet oder einem Notstromaggregat. Danach wissen Sie, ob Sie mehr davon wollen.
Oder ich kann es nicht. Dann sage ich Ihnen das — in denselben fünfzehn Minuten, mit der Begründung, woran es liegt. Das ist kein schlechteres Ergebnis; es ist nur ein schnelleres.
Was ich nicht mache: Ihnen zusagen, dass die Methode Ihren Fall trägt, bevor ich ihn gesehen habe. Eine Methode, die angeblich alles kann, hat keine Grenzen benannt — und was keine Grenzen hat, ist nicht prüfbar. Die Grenzen dieser hier stehen im Abschnitt „Was das nicht leistet". Wenn Sie einen Fall haben, an dem sie zerbricht, will ich ihn hören. Das ist kein Höflichkeit, das ist der einzige Weg, wie so etwas besser wird.