Das „F“ im RFLP-Ansatz von SPES2020
Im letzten Blogbeitrag haben wir Ihnen den Requirements Viewpoint vorgestellt. Heute zeigen wir Ihnen, wie Sie die Anforderungen aus Sicht der Stakeholder mit Hilfe des Functional Viewpoints in Systemfunktionen überführen können.
Ziel und Zweck
Der Functional Viewpoint ergänzt die Use-Cases / Funktionen und deren Abläufe aus dem Requirements Viewpoint um Details zur funktionalen Realisierung des betrachteten Systems. Außerdem können verschiedene Anforderungen in Systemfunktionen zusammengefasst oder architektonisch anders aufgeteilt werden. Es wird im RFLP-Ansatz strikt zwischen Anforderungen und Anteilen zur konkreten Realisierung dieser Anforderungen getrennt. Diese Trennung ist ein Prinzip des RFLP-Ansatzes.
Zudem dient der Functional Viewpoint zur Konsolidierung von funktionalen Anforderungen. Die Einordnung von funktionalen Anforderungen in eine Struktur kann sich ändern, weil die Perspektive, aus der man auf die Anforderungen schaut, eine andere ist. Es ist auch möglich, dass Anforderungen aus dem Requirements Viewpoint in dem Functional Viewpoint obsolet werden oder im Functional Viewpoint Anforderungen hinzukommen, die es im Requirements Viewpoint nicht gibt.
Weiterhin separiert der Functional Viewpoint funktionale Anforderungen von Anforderungen, die sich erst durch die Auswahl von Elementen ergeben, welche die Anforderungen realisieren. In dem Functional Viewpoint geht es einzig und allein um die Funktionen und nicht um Aspekte, die sich durch logische oder physikalische Bauteile ergeben, die jene Funktionen letztendlich umsetzen.
Inhalte, Diagramme und Notationselemente
Im Functional Viewpoint stellen Sie in einer Sicht eine Übersicht der Funktionen des betrachteten Systems dar. Für die Modellierung der Übersicht der Funktionen können Sie das Blockdefinitionsdiagramm der SysML oder das Komponentendiagramm der UML nutzen. In der nächsten Sicht stellen Sie die Hierarchie der Funktionen (Funktionsdekomposition) dar. Sowohl mit dem Blockdefinitionsdiagramm als auch mit dem Komponentendiagramm können Sie eine Funktionsübersicht und eine Funktionsdekomposition abbilden. Als Notationselemente verwenden Sie Blöcke im Blockdefinitionsdiagramm und Komponenten im Komponentendiagramm, um eine Funktionsübersicht zu generieren. Verwenden Sie Blöcke und Aggregationen im Blockdefinitionsdiagramm und Komponenten und Aggregationen im Komponentendiagramm, um eine Funktionsdekomposition zu erzeugen.
Detaillierte Abläufe der Funktionen modellieren Sie in einer weiteren Sicht. Hierfür nutzen das Aktivitätsdiagramm der UML oder SysML. Im letzten Blogbeitrag haben wir Ihnen schon die Notationselemente des Aktivitätsdiagramms vorgestellt. Zusätzlich eignen sich Ein- und Ausgangsaktionen und Ein- und Ausgangsparameter. Es ist wichtig, dass hier ein Entwicklungsschritt in der funktionalen Entwicklung des betrachteten Systems zu erkennen ist, ohne logische und technische Elemente zu adressieren. Ein Beispiel ist die Statusbehandlung von Systemobjekten. Kann diese in der Anforderungssicht noch rudimentär behandelt werden, legen Sie in der Funktionssicht das Verhalten der Statusbehandlung fest. Damit findet eine Konsolidierung der funktionalen Anforderungen statt, um die Statusbehandlung funktional mit allen nötigen Details zu realisieren.
In der letzten Sicht stellen Sie die Informationen dar, die zwischen den Funktionen ausgetauscht werden. Dazu verwenden Sie das interne Blockdefinitionsdiagramm der SysML oder das Kompositionsdiagramm der UML. Als Notationselemente verwenden Sie Blöcke (Komponenten), Schnittstellen, Ein- und ausgehende Schnittstellen, Ports und Informationsflüsse.
Haben Sie schon Erfahrung mit dem Functional Viewpoint gemacht oder haben Sie Anmerkungen? Hinterlassen Sie uns gerne einen Kommentar. Oder schreiben Sie uns Ihre Frage per Email an vertrieb@sophist.de.
Nachdem Sie nun die Funktionen Ihres Systems im Detail definiert haben, stellt sich die Frage welche Architekturelemente sollen denn welche Funktionsteile ausführen? Wie können nun Logische Systeme gebildet werden, damit eine widerstandfähige Architektur entsteht? Das stellen wir Ihnen im nächsten Blogbeitrag vor. Bleiben Sie also gespannt.
Viele Grüße!
Lesen Sie die weiteren Beiträge aus dieser Serie:
Teil 1: Architektur im SE: Anforderungs- und Architekturmodelle strukturiert aufbauen
Teil 2: RFLP: Gelebte Trennung zwischen Aspekten im Systems Engineering
Teil 3: RFLP: Requirements Viewpoint
Teil 5: RFLP: Logical Viewpoint
Teil 6: RFLP: Physical Viewpoint
Teil 7: Erkenntnisse aus Innovationsprojekt „Architektur im SE“