Die Transformation vom Problemraum, repräsentiert durch die Anforderungen an ein System, in den Lösungsraum, repräsentiert durch die Architektur des Systems, ist eine zentrale Herausforderung in der Systementwicklung. Dieser Prozess erfordert eine sorgfältige Analyse und Planung, um sicherzustellen, dass das entwickelte System die (an es) gestellten Anforderungen erfüllt.
Dies beinhaltet die Entscheidung über die Struktur des Systems, einschließlich der Komponenten, aus denen es besteht, und wie diese Komponenten miteinander interagieren. Darüber hinaus muss das Verhalten des Systems definiert werden, d. h., wie es auf Eingaben reagiert und welche Ausgaben es produziert.
Die Verbindung zwischen dem Problem- und dem Lösungsraum wird durch den Entwicklungsprozess hergestellt. Dies beinhaltet die Umsetzung der Anforderungen in eine tragfähige Architektur.

Hierzu haben sich im Laufe der Jahre verschiedene Ansätze und Methoden zur Bewältigung dieser Komplexität im Systems Engineering entwickelt.

Das Prinzip, dem die meisten dieser Methoden folgen ist wohl der RFLP -Ansatz. Dieser steht als Akronym für die verschiedenen Sichten auf ein System: Anforderungssicht (Requirements), Funktionale Sicht, Logische Sicht und Physische Sicht.
Dieser Ansatz ermöglicht eine klare Trennung zwischen verschiedenen Aspekten in der Systementwicklung und hilft dabei, die Komplexität zu beherrschen und den Überblick über das System zu behalten.

Anforderungssicht

Zunächst ist es wichtig zu betrachten, welche Anforderungen das System erfüllen muss. Die Anforderungssicht fungiert als Basis für die weiteren Sichten des Ansatzes. Sie kann auf unterschiedliche Weise dargestellt werden, beispielsweise textuell oder in Form von Systems Modelling Language (SysML) Diagramme, wie bspw. mit Anwendungsfall- (UC) oder Anforderungsdiagrammen.

Betrachtet man exemplarisch ein Rechnersystem, könnten Anforderungen an das System lauten, dass es Daten in einer definierten Art und Weise verarbeiten können muss.

Funktionale Sicht

Ausgehend von den Anforderungen und potenziellen Anwendungsfällen gilt es, die Funktionen und Teilfunktionen des Systems zu betrachten. Die zentrale Frage hierbei lautet: „Welche Funktionen und ggf. Teilfunktionen muss das System konkret bieten, um die Anwendungsfälle und Anforderungen erfüllen zu können?“ Nicht zu vernachlässigen sind hierbei auch die Interaktionen und Abhängigkeiten zwischen den Funktionen und Teilfunktionen untereinander.

Betrachtet man die beispielhafte Anforderung an das Rechnersystem, muss dieses mitunter in der Lage sein, die Funktionen „Dateneingabe“, „Eingabedaten zwischenspeichern“, „Eingabedaten verarbeiten“ und „Datenausgabe“ zu realisieren.

Logische Sicht

Um die Funktionen erfüllen zu können, benötigt es Elemente, die diese Funktionen letztendlich auch umsetzen. Bevor man jedoch konkret definiert, wie die Funktionen technisch realisiert werden sollen, gilt es, dies durch die logische Sicht in abstrakter Form darzustellen.
Dies unterstützt zum einen, ein besseres Verständnis für das System zu erlangen und zum anderen, eine stabile Basis für Systeme mit technischer Varianz zu schaffen, d. h. Systeme, die dasselbe Funktionsprinzip teilen, sich aber in deren Realisierung unterscheiden.

Auch für die logische Sicht eignen sich die Diagrammarten der SysML, wie das BDD oder das IBD. Modellierungstools bieten die Möglichkeit, die zu erfüllenden Funktionen eindeutig mit den identifizierten, logischen Elementen zu verknüpfen. Somit lässt sich bspw. auch in einem ACT darstellen, welche Aktion von welchem Element des Systems ausgeführt werden soll. Ferner ist es die logische Architektursicht, in der die nicht funktionalen Anforderung zum Tragen kommen, die an das System gestellt werden.

Beispielsweise wird für die Funktion „Dateneingabe“ in der logischen Sicht abstrahiert ein „Eingabewerk“ benötigt. Wie dieses „Eingabewerk“ technisch realisiert werden soll, hängt von weiteren Aspekten ab, die definiert sind. Würde man nun die logische Architektursicht für das Rechnersystem weiter ausführen, ähnelt das stark der Von-Neumann-Referenzarchitektur. Diese stellt ein Konzept zur Gestaltung eines universellen Rechners dar. [1]

Physische Sicht

In der physischen Architektursicht gilt es, letztendlich die Festlegung zu treffen, wie die logischen Elemente physisch umgesetzt werden sollen. Das heißt, erst in dieser Sicht ist definiert, welches „Eingabewerk“ tatsächlich zum Einsatz kommen soll.
Dies kann von mehreren abhängen, wie bspw. und nicht abschließend: Wie sieht es mit Aspekten der Robustheit gegen äußere Einflüsse aus? Soll das „Eingabewerk“ gleichzeitig als „Ausgabewerk“ fungieren können? Sind Kosten ein wesentlicher Faktor? Welche Sicherheitsrelevanz besteht?
Aus diesen weiteren Anforderungen an das System kann sich für das gewählte Beispiel des „Eingabewerks“ ergeben, dass ein Touchscreen, eine QWERTZ-Tastatur, andere Tastaturtypen oder ein Mikrofon verwendet werden soll.

Wie bei der logischen Sicht können auch für diese Sicht dieselben Diagrammarten der SysML verwendet werden. Auch hier ist im Modellierungstool eine Allokation der physischen zu den logischen Elementen zu empfehlen, um die Komplexität des Systems zu beherrschen.

Fazit

Der RFLP-Ansatz ist ein effektives Werkzeug im Systems Engineering, das hilft, die Komplexität von Systemen zu beherrschen und den Überblick zu behalten. Durch die klare Trennung zwischen Anforderungs-, Funktions-, Logischer und Physischer Sicht in den verschiedenen Abstraktionsebenen, ermöglicht der RFLP-Ansatz eine strukturierte und systematische Herangehensweise an die Systemarchitektur.
Er unterstützt die Entwicklung von Systemen, die sowohl funktional als auch sind und trägt dazu bei, dass die Systeme den gestellten Anforderungen gerecht werden. Darüber hinaus fördert der RFLP-Ansatz das Verständnis für das System , da es in jeder Sicht für sich in einer über die Ebenen hinweg verknüpften Darstellung betrachtet werden kann.
Insgesamt ist der RFLP-Ansatz ein unverzichtbares Instrument für Ingenieure und Designer im Bereich des Systems Engineering.

[1] https://tams.informatik.uni-hamburg.de/applets/baukasten/DA/VNR_Einleitung.html