Wenn das Modell richtig ist, aber in der Praxis keinen Mehrwert bringt — dann ist es abzulehnen.

RFLP: Die saubere Trennung, die niemand lebt

Der RFLP-Ansatz — Requirements, Functional, Logical, Physical — ist das derzeit prominenteste Denkmodell im Systems Engineering. Entstanden im Rahmen des SPES-2020-Forschungsprojekts an der TU München, propagiert von Trainingsanbietern und Beratungshäusern, eingebettet in teure Modellierungstools.

Die Idee: Man betrachtet ein System aus vier getrennten Perspektiven.

1. Requirements: Was muss das System leisten? (Kundenanforderungen)
2. Functional: Welche Funktionen setzen diese Anforderungen um?
3. Logical: Welche logischen Komponenten realisieren die Funktionen?
4. Physical: Welche physischen Bauteile setzen die logische Architektur um?

Jeder Viewpoint hat eigene Diagramme, eigene Sichten, eigene Modellierungskonventionen. Die Trennung soll helfen, Komplexität zu beherrschen.

Das klingt sauber. Und theoretisch ist es das auch.

Wo die Theorie an der Realität zerschellt

Was passiert, wenn ein mittelständisches Unternehmen versucht, RFLP umzusetzen?

Erstens: Vier Sichten bedeuten vierfachen Pflegeaufwand. Jede Änderung an einer Anforderung muss durch alle vier Viewpoints propagiert werden. Die Kundenanforderung ändert sich → die Funktion muss angepasst werden → die logische Zuordnung stimmt nicht mehr → die physische Realisierung muss geprüft werden. In der Theorie ein nachvollziehbarer Prozess. In der Praxis ein Dokumentations-Marathon, der den Ingenieur vom eigentlichen Entwickeln abhält.

Zweitens: Die Trennung ist künstlich. In der realen Entwicklung denkt kein Ingenieur in vier getrennten Schubladen. Wenn jemand eine Anforderung zerlegt, entstehen gleichzeitig Vorstellungen über Funktionen und mögliche Realisierungen. Das ist keine Schwäche — das ist der natürliche Entwicklungsweg. RFLP zwingt diesen organischen Prozess in eine sequenzielle Struktur, die der menschlichen Denkweise widerspricht.

Drittens: Selbst die Methodenexperten stolpern. SOPHIST, einer der renommiertesten Anbieter für Requirements Engineering in Deutschland, hat im Rahmen ihres eigenen Innovationsprojekts „Architektur im SE" festgestellt, dass ihnen die vier RFLP-Viewpoints nicht ausreichten. Sie mussten zusätzliche Perspektiven einführen — unter anderem für Stakeholder und Organisation. Und die Trennung von Anforderungen und Funktionen „stieß bei ihnen selbst zunächst auf Verwirrung". Wenn die Experten bei der Anwendung ihrer eigenen Methode Verwirrung erleben, was bedeutet das für den Praktiker?

Die Zahlen sprechen für sich: RFLP in der Praxis

Wer glaubt, das sei ein akademisches Problem, dem sei eine aktuelle Branchenumfrage empfohlen. INVENSITY hat 2026 sieben etablierte Unternehmen der deutschen Verteidigungsindustrie zu ihrem Systems-Engineering-Reifegrad befragt — Experteninterviews mit den SE-Bereichsverantwortlichen, keine anonymen Online-Fragebögen.

Die Ergebnisse sind ernüchternd:

• 57% der Befragten nutzen RFLP — aber „works somehow". 43% nutzen es gar nicht. Formale, konsequente Anwendung? Fehlanzeige. RFLP lebt in den Köpfen, nicht in den Tools. Die Befragten selbst beschreiben es so: „RFLP eher im Kopf als sauber im Tool abgebildet." Flexibilität und Geschwindigkeit werden wichtiger eingeschätzt als formale Methodik — oder in den Worten der Umfrage: „Time over Quality."
• Vier von sieben Unternehmen nutzen keine Modellierungssprache. Vereinzelt kommt Visio oder Draw.io zum Einsatz. Die Tool-Landschaft ist heterogen und kaum standardisiert. Unterschiedliche Methoden innerhalb desselben Projekts sind keine Ausnahme, sondern Alltag.
• Die größten Pain Points? Tool-Brüche, unklare Requirements und hoher Prozessaufwand. Nicht etwa fehlende Methodik — sondern zu viel davon, zu schlecht integriert. Die Schwierigkeiten liegen, so die Studie, „weniger im Scope oder der Architektur, sondern vor allem in Organisation und Kommunikation."
• Und der vielleicht bezeichnendste Befund:
  Dort, wo Modularität bereits funktioniert, sehen die Befragten keinen zusätzlichen Nutzen in formaler MBSE/RFLP-Modellierung. Das heißt übersetzt:
• • Wer seine Entwicklung im Griff hat, braucht kein formales RFLP.
  • Und wer sie nicht im Griff hat, wird sie durch formales RFLP auch nicht in den Griff bekommen — weil die Probleme woanders liegen.

Die Studie bestätigt gleichzeitig, dass Systems Engineering an sich wirkt: Projekte mit gutem SE performen nachweislich besser. Aber „gutes SE" und „formales RFLP mit vier getrennten Viewpoints in einem teuren Tool" sind offensichtlich nicht dasselbe.

Das EVA-Prinzip: Die Methodik existiert bereits — implizit

Interessant ist, dass die logische Sicht des RFLP-Ansatzes bei genauerer Betrachtung auf etwas hinausläuft, das Informatiker seit Jahrzehnten kennen: das EVA-Prinzip (Eingabe → Verarbeitung → Ausgabe) bzw. die Von-Neumann-Architektur.
Ein „logisches Eingabewerk" ist nichts anderes als die Abstraktion eines physischen Bauteils — ob Touchscreen, Tastatur oder Mikrofon.

Die Erkenntnis: Die RFLP-Sichten sind keine unabhängigen Entitäten. Sie sind Eigenschaften desselben Elements auf unterschiedlichen Abstraktionsniveaus. Die logische Sicht ist nicht etwas anderes als die physische — sie ist die physische Sicht, bevor die Technologieentscheidung gefallen ist.

Warum also vier getrennte Modelle pflegen, wenn alles an einem Element hängt?

Der natürliche Entwicklungsweg

Beobachten Sie einen Ingenieur bei der Arbeit — nicht in einem MBSE-Training, sondern an seinem Schreibtisch mit einer echten Aufgabe:

1. Er bekommt eine Kundenanforderung: „Das System soll Temperatur messen."
2. Er zerlegt sie: „Dafür brauche ich eine Funktion ‚Temperaturerfassung'."
3. Er denkt weiter: „Die Funktion braucht einen Sensor (logisch) — welcher genau, weiß ich noch nicht."
4. Später entscheidet er: „Wir nehmen den PT100 (physisch), weil der für unseren Temperaturbereich passt."

Was ist passiert? R, F, L und P sind nicht in vier getrennten Workshops entstanden. Sie sind iterativ aus derselben Arbeit heraus gewachsen. Die Anforderung wurde zerlegt, und bei jeder Zerlegung hat sich die nächste Sicht automatisch ergeben.

Das ist kein Zufall. Das ist der Weg, wie Ingenieure seit Jahrhunderten arbeiten. Methoden, die diesen Weg ignorieren, werden nicht angenommen — egal wie korrekt sie theoretisch sind.

Methoden verheiraten statt Sichten trennen

OTSM verfolgt einen grundlegend anderen Ansatz. Nicht gegen RFLP — sondern über RFLP hinaus.

Das Prinzip heißt „Work Once, Use Many": Der Ingenieur arbeitet an einem einzigen, vereinheitlichten Element. Dieses Element hat Eigenschaften — darunter auch solche, die den RFLP-Viewpoints entsprechen. Aber er muss sie nicht in vier getrennten Modellen pflegen.

Konkrete Umsetzung:

Anforderungen zerlegen → Funktionen entstehen automatisch als Unterstruktur

Funktionen zuordnen → Logische Architektur wächst mit, nicht in einem separaten Tool

Technologieentscheidungen treffen → Physische Sicht wird Eigenschaft des Elements

Traceability → R↔F↔L↔P-Verlinkung entsteht beim Arbeiten, nicht durch nachträgliches Mapping

FMEA, Compliance, Impact Analysis — alles verknüpft sich automatisch, weil die Daten an einem Ort leben. Der Ingenieur entwickelt sein Produkt. Die Dokumentation entsteht als Nebenprodukt der Arbeit, nicht als separate Aufgabe.

Und damit adressiert OTSM exakt die Pain Points, die die INVENSITY-Umfrage aufdeckt:

Tool-Brüche? Ein System, eine Datenbasis. Keine Übergabe zwischen Requirements-Tool, Architektur-Tool, FMEA-Tool und Testmanagement. Kein Export-Import-Zyklus, bei dem Informationen verloren gehen.

Unklare Requirements? Anforderungen sind keine isolierten Textblöcke, sondern verknüpfte Elemente mit Kontext — wer braucht sie, welche Funktion setzt sie um, welches Bauteil realisiert sie. Unklarheit entsteht durch fehlenden Kontext. OTSM liefert den Kontext automatisch.

Hoher Prozessaufwand? Wenn der Prozess darin besteht, vier Sichten manuell konsistent zu halten, ist hoher Aufwand unvermeidbar. Wenn die Sichten automatisch aus der Arbeit entstehen, verschwindet dieser Aufwand.

Heterogene Tool-Landschaft? OTSM ist keine weitere Option, die neben Confluence, JIRA, DOORS und Cameo existiert. Es ersetzt die Notwendigkeit, fünf Tools zu integrieren, durch ein System, das von Anforderung bis FMEA durchgängig denkt.

Praxis schlägt Theorie

Kein Mittelständler wird scheitern, weil er seine logische Sicht nicht sauber von der physischen getrennt hat. Aber viele scheitern, weil sie so viel Zeit in Methodik investieren, dass keine Zeit mehr fürs eigentliche Engineering bleibt.

Die große Ironie der SE-Methodenwelt: Die Methoden, die entwickelt wurden, um Komplexität zu beherrschen, haben selbst eine Komplexität erzeugt, die beherrscht werden muss. Trainings für die Methode, Tools für die Methode, Berater für die Methode — und am Ende fragt sich der Ingenieur, wann er eigentlich entwickeln soll.

RFLP ist nicht falsch. Es ist ein valides Denkmodell. Aber ein Denkmodell, das den Ingenieur zwingt, seinen natürlichen Arbeitsfluss zu unterbrechen, um vier getrennte Sichten zu pflegen, hat in der Praxis verloren — egal wie elegant es auf einer Powerpoint-Folie aussieht.

Methoden sind Werkzeuge, keine Religion

Der Respekt vor SOPHIST, SPES 2020 und der akademischen Arbeit hinter RFLP ist echt. Die Erkenntnisse sind wertvoll. Aber die Art, wie diese Erkenntnisse in die Praxis überführt werden — als getrennte Viewpoints, die in teuren Modellierungstools gepflegt werden müssen — folgt nicht dem Weg, den Ingenieure tatsächlich gehen.

Die bessere Frage ist nicht: „Wie implementiere ich RFLP?" Sondern: „Wie sorge ich dafür, dass R, F, L und P automatisch aus meiner täglichen Arbeit entstehen?"

Das ist der Ansatz, den OTSM verfolgt. Nicht weil RFLP falsch ist. Sondern weil Praxis immer Theorie schlägt — und weil der Ingenieur Produkte entwickeln soll, nicht Modelle pflegen.

OTSM — Organisation, Technologie und Service Management. Für Unternehmen, die etwas verändern wollen.