Das Irrenhaus der Regulatorik: Widersprüche, Duplikate und ein Milliardengeschäft
Warum sich die ISO/IEC/IEEE-Normen im Systems Engineering selbst widersprechen – und warum das kein Zufall ist.
Wer im Systems Engineering arbeitet, kennt das Gefühl: Man kauft eine Norm für mehrere hundert Euro, liest sie durch, und stellt fest – das steht doch schon in der anderen Norm, die man letzten Monat gekauft hat. Nur anders formuliert. Und manchmal widersprüchlich.
Ich habe mir die sieben Kernnormen des Requirements Engineering vorgenommen – ISO/IEC/IEEE 29148, 15288, 12207, IEEE 830, IEEE 1362, ISO/IEC/IEEE 24748 und 24765 – und systematisch verglichen. Das Ergebnis ist ernüchternd.
Der Selbstwiderspruch: 29148 gegen 29148
Der offensichtlichste Widerspruch steckt nicht zwischen zwei Normen, sondern innerhalb einer einzigen.
Abschnitt 5.2.4 der ISO/IEC/IEEE 29148:2018 definiert, was ein wohlgeformtes Requirement ist. Die Aussage ist unmissverständlich: Ein Requirement muss verifizierbar sein, durch messbare Bedingungen qualifiziert und durch Randbedingungen begrenzt. Ohne Messgröße kein Requirement. Das ist eine harte, klare Ansage.
Dann blättert man weiter zu Abschnitt 5.2.8.2. Dort definiert dieselbe Norm Anforderungstypen. Funktionale Anforderungen werden beschrieben als Aussagen, die Funktionen oder Aufgaben des Systems beschreiben. Kein Wort von Messbarkeit. Kein Wort von Verifikationskriterium.
Das bedeutet: Nach 5.2.4 ist „Das System soll die aktuelle Temperatur anzeigen“ kein gültiges Requirement – es fehlt die Messgröße. Nach 5.2.8.2 ist es ein perfekt gültiges funktionales Requirement.
Und als hätten die Autoren selbst gemerkt, dass das nicht zusammenpasst, schließt 5.2.8.2 mit dem Satz: „There may be other ways to organize requirements types.“ Das ist keine Spezifikation mehr. Das ist eine Kapitulationserklärung.
Die Geschwister, die sich nicht einig sind
ISO/IEC/IEEE 15288 definiert 30 Prozesse für den System-Lebenszyklus. ISO/IEC/IEEE 12207 definiert Prozesse für den Software-Lebenszyklus. Beide haben die gleiche Struktur, die gleichen Prozessnamen, die gleichen Process Purposes und Outcomes.
Die Unterschiede liegen in den Activities und Tasks – weil die eine Norm auf Systeme und die andere auf Software fokussiert. Das klingt sinnvoll, bis man merkt: In der Praxis entwickelt heute kaum jemand ein System ohne Software. Und kaum jemand Software ohne ein umgebendes System.
Das Ergebnis: Organisationen müssen beide Normen kaufen und parallel anwenden. Oder eine wählen und hoffen, dass der Auditor die andere nicht verlangt. Zwei Normen, ein Zweck, doppelte Kosten.
Die toten Normen, die niemand beerdigt hat
IEEE 830 definierte SRS-Templates. IEEE 1362 definierte ConOps-Templates. Beide wurden 2011 durch die ISO/IEC/IEEE 29148 ersetzt. Formal zurückgezogen.
In der Praxis referenzieren bis heute Hunderte von Lastenheften, Ausschreibungen und Prozessbeschreibungen auf IEEE 830. Ganze Generationen von Ingenieuren haben mit 830 gelernt, was ein gutes Requirement ist. Die Terminologie lebt weiter – auch wenn sie mit 29148 teilweise inkompatibel ist.
29148 unterscheidet zum Beispiel zwischen ConOps (Concept of Operation) (nutzerzentriert) und OpsCon (systemzentriert). IEEE 1362 kannte diese Unterscheidung nicht. Wer also ein „ConOps nach 1362″ schreibt und dann gegen 29148 auditiert wird, hat ein Problem – ohne es zu wissen.
INCOSE, SOPHIST und die Babylonische Verwirrung
Es wird noch besser, wenn man die Methodenframeworks hinzunimmt.
INCOSE fordert im Systems Engineering Handbook für jedes Requirement eine Verifikationsmethode. Die EARS-Schablonen erzwingen explizit Bedingungen. Das passt zu 29148 §5.2.4.
SOPHIST bietet Satzschablonen an, die eine Messgröße ermöglichen – aber nicht erzwingen. Mal wird „mit einer Antwortzeit < 2s“ angehängt, mal nicht. Das passt zu 29148 §5.2.8.2.
User Stories im agilen Kontext? „Als Nutzer möchte ich X, damit Y.“ Keine Messgröße. Kein Verifikationskriterium. Nach 5.2.4 kein Requirement. Nach gängiger Praxis völlig akzeptabel.
Automotive SPICE fordert Traceability und Verifikation, sagt aber nichts Konkretes zur Messbarkeit einzelner Requirements. ISO 25010 (SQuaRE) definiert Metriken – aber nur für nicht-funktionale Qualitätsmerkmale.
Jeder Auditor, jeder Berater, jedes Tool interpretiert das anders. Der eine sagt „nicht konform“, der andere nickt ab. Und beide können ihre Position mit derselben Norm begründen.
Das Geschäftsmodell dahinter
Man muss kein Zyniker sein, um das Muster zu erkennen.
ISO/IEC/IEEE 29148:2018 kostet bei DIN Media (vormals Beuth Verlag) rund 200 Euro. ISO/IEC/IEEE 15288:2023 nochmal so viel. 12207, 24748, 24765, 15289 – jede einzeln zu kaufen. Für eine vollständige Normensammlung im Requirements Engineering kommt man schnell auf über 1.000 Euro. Pro Arbeitsplatz. Ohne die branchenspezifischen Derivate wie ASPICE (Kostenfrei) , ISO 26262 oder ISO 14971.
Die Normen referenzieren sich gegenseitig. Wer 29148 kauft, stellt fest, dass man 15288 und 12207 auch braucht. Wer 15288 kauft, wird auf 24748 verwiesen. Wer 24748 liest, braucht 24765 für das Vokabular.
Und alle paar Jahre gibt es eine Revision. Nicht weil die Gesetze der Physik sich geändert haben, sondern weil eine andere Norm revidiert wurde und die Querverweise aktualisiert werden müssen. Neue Ausgabe, neuer Preis. Die ISO verdient an jeder Revision – und an der Fragmentierung, die die Revisionen nötig macht.
Was eigentlich nötig wäre
Stellen wir uns vor, die ISO würde an ihre eigenen Normen die gleichen Qualitätskriterien anlegen, die sie für Requirements fordert.
Verifizierbar: Kann ein Ingenieur eindeutig feststellen, ob er die Norm korrekt anwendet? Bei den Widersprüchen zwischen 5.2.4 und 5.2.8.2: Nein.
Konsistent: Widersprechen sich die Aussagen innerhalb einer Norm oder zwischen Normen? Ja. Dokumentiert.
Eindeutig: Kann die Norm nur auf eine Art interpretiert werden? „There may be other ways“ ist das Gegenteil von Eindeutigkeit.
Redundanzfrei: Steht der gleiche Inhalt in mehreren Normen? 15288 und 12207 sind der Beweis.
Notwendig: Braucht man wirklich sieben separate Dokumente, um Requirements Engineering zu beschreiben? Oder würden zwei reichen – eines für Prozesse, eines für Inhalte?
Die Antwort kennt jeder, der diese Normen in der Praxis anwendet. Aber die ISO hat keinen Anreiz zur Konsolidierung. Jede Norm ist ein Produkt. Jede Revision ist ein neues Produkt. Jede Referenz auf eine andere Norm ist ein Upsell.
Fazit: Das System ist das Problem
Die ISO/IEC/IEEE-Normenlandschaft im Systems Engineering ist das Ergebnis von Jahrzehnten organischen Wachstums, von Komitees, die ihr Revier verteidigen, und von einem Geschäftsmodell, das Fragmentierung belohnt.
Die Harmonisierungsbemühungen seit 2008 waren ein Schritt in die richtige Richtung. 15288 und 12207 teilen jetzt Terminologie. 29148 hat 830 und 1362 abgelöst. 24765 stellt ein gemeinsames Vokabular bereit.
Aber es reicht nicht. Solange eine einzelne Norm sich selbst widerspricht, solange zwei Geschwisternormen für denselben Zweck koexistieren, und solange der Zugang zu diesen Normen Hunderte Euro kostet – solange bleibt die Normenwelt ein Irrenhaus.
Was wir brauchen, ist nicht noch eine Harmonisierungsnorm. Was wir brauchen, ist eine Entrümpelungsnorm. Eine Norm, die sagt: Requirements Engineering ist ein Prozess. Hier sind die Schritte. Hier sind die Dokumenttypen. Hier ist das Vokabular. Ein Dokument. Ein Preis. Keine Widersprüche. Keine Querverweise auf sechs andere käufliche Dokumente.
Aber das wird nicht passieren. Denn die Norm für Redundanzentfernung würde wahrscheinlich als eigenständiges Dokument veröffentlicht – für 180 Euro. Mit Querverweisen auf alle existierenden Normen.
Thomas Arends ist Geschäftsführer und Gründer von OTSM, einer integrierten SaaS-Plattform für Requirements Engineering, FMEA und Compliance Management.