Im letzten Blogbeitrag haben wir Ihnen den Physical Viewpoint vorgestellt. In diesem und letzten Blogbeitrag der Blogreihe möchten wir unser Innovationsprojekt mit Ihnen Revue passieren lassen. Welche Erwartungen hatten wir? Was waren die Ziele und wurden diese erreicht? Vor welchen Herausforderungen standen wir und welche Lösungen haben wir gefunden? Welche Unterschiede gibt es zwischen dem bisherigen SOPHISTischen Ansatz und dem RFLP-Ansatz?
Unser Ziel war es, ein Modelltemplate zur Dokumentation von Anforderungen und Architektur zu erstellen, welches wir in unser Systems Engineering Training mit einbinden können, um das Training noch praxisorientierter zu gestalten. Damit wollten wir dem realen Charakter eines Modells entsprechen, welches eben nicht die Sammlung von Diagrammen darstellt, sondern verschieden vielseitig verknüpfte Modellelemente in einem wohlstrukturierten Modellbaum.
Wir haben schon in einigen Projekten Modelle zur Dokumentation von Anforderungen und Architektur erstellt, jedoch den RFLP-Ansatz nicht flächendeckend in die Modelle miteinfließen lassen. Dieses Template sollte nicht nur die Erfahrungen aus einigen Projekten widerspiegeln, es sollte auch den aktuellen Stand der Forschung beinhalten. Der RFLP-Ansatz (explizite Trennung von Anforderungen, Funktionen, logischer und physikalischer Architektur) stellt den aktuellen Stand der Forschung dar und wird gegenwertig weiterentwickelt. Was der RFLP-Ansatz ist und welche Vorteile er hat, können Sie in diesem Beitrag nachlesen.
Zur Erreichung unseres Ziels haben wir Business Cases formuliert, Anforderungen an ein Modelltemplate von unseren Beratern (beispielsweise durch Interviews) ermittelt und konsolidiert, bisherige SE-Modelle recherchiert und miteinander verglichen und den RFLP-Ansatz studiert. Diese Aktivitäten haben zur Auswahl der Sichten, der Modellierungssprachen, der Diagrammtypen und der Notationselemente geführt, welche für uns in ein Modelltemplate zur modellbasierten Dokumentation von Anforderungen und Architektur gehören.
Während des Studiums des RFLP-Ansatzes fiel uns die Trennung zwischen Anforderungen und Funktionen auf. Bisher haben wir SOPHISTen die Funktionen während der Anforderungsanalyse mitbetrachtet und modelliert, sodass man daraus Anforderungen an die Architektur ableiten konnte. Dies ist in dem RFLP-Ansatz explizit nicht der Fall. Deshalb stieß die Trennung von Anforderungen und Funktionen unsererseits auf Verwirrung. Die Trennung ist jedoch bei näherer Betrachtung sehr sinnvoll und wurde von uns aus folgenden Gründen übernommen:
Funktionen sind im Gegensatz zu Anforderungen schon ein Schritt hin zur Realisierung, während Anforderungen nur den Lösungsraum darstellen. Es muss also nicht zwingend so sein, dass die Funktionen genau den Anforderungen entsprechen. Der Funktionsentwickler hat den Freiheitsgrad zu entscheiden, ob die Ziele des Systems mit den gestellten Anforderungen zu erreichen sind und ob es nicht Sinn macht, die Funktionen etwas anders zu schneiden als von den Anforderungen vorgeschlagen, um die Ziele, welche mit dem betrachteten System erreicht werden sollen, zu erreichen.
Der Functional View ergänzt die Anforderungen mit Details, die aus Perspektive der Funktion nötig sind und konsolidiert die Anforderungen, um beispielsweise eine Wiederverwendung der Funktionen zu ermöglichen. Der Functional View stellt im Gegensatz zum Requirements View eine andere Perspektive dar, die sich auch innerhalb der Organisationsstruktur wiederfinden kann. Der Anforderungsentwickler kann sich nun rein auf seine Anforderungen konzentrieren, während der Funktionsentwickler sich darüber Gedanken macht, wie er aus den Anforderungen konsistente und wiederverwendbare Funktionen erstellt.
Durch den Vergleich von SE-Modelltemplate und durch unsere gestellten Anforderungen an das SE-Modelltemplate stellten wir fest, dass uns die Perspektiven des RFLP-Viewpoints nicht ausreichten und wir Inhalte der RFLP-Viewpoints eher als eigene Perspektive herausstellen wollen. Ein Beispiel dafür sind Stakeholder, weil diese durchaus Auswirkungen auf mehrere Perspektiven des betrachteten Systems haben können.
Zudem haben wir die Organisationsperspektive hinzugefügt, welche die Verantwortlichkeiten für die einzelnen Perspektiven zeigt, um Kommunikationsprobleme zwischen den Abteilungen, welche bestimmte Perspektiven verantworten, zu vermeiden.
Weiterhin haben wir uns die Frage gestellt, ob wir die Struktur des Modells nach Abstraktionsebenen oder nach den Perspektiven abbilden wollen. Wir haben uns dann für die Struktur nach den Perspektiven entschieden, weil die Abstraktionsebenen domänenabhängig sind und die Flexibilität des Modelltemplates eine Anforderung an das Modelltemplate war.
In diesem Modelltemplate finden Sie nicht nur das Modelltemplate mit Modellierungsrichtlinien als Hilfe zur Modellierung, Sie finden auch ein Beispiel eines Smart Home Systems. Dieses Beispiel zeigt vollumfänglich und durchgängig auf, was das Modelltemplate zu leisten im Stande ist und wie es in der Praxis umgesetzt werden kann. Das Beispiel ist Teil des Systems Engineering Trainings und wird dort ausführlich besprochen.
In Zukunft wollen wir die Dokumentation von Schnittstellen und Designentscheidungen noch detaillierter beleuchten und unseren Systems Engineering Ansatz weiter verbessern.
Sie haben schon Erfahrung mit dem RFLP-Ansatz gemacht? Teilen Sie uns Ihre Erfahrungen zum RFLP-Ansatz gerne mit! Wir sind an einem Austausch sehr interessiert! Hinterlassen Sie einfach einen Kommentar oder schreiben Sie uns eine E-Mail an vertrieb@sophist.de.
Fazit: der RFLP-Ansatz hat unser Systems Engineering nochmal erweitert und dieses Wissen und das Modelltemplate geben wir im Rahmen des Systems Engineering Trainings weiter. In diesem Training erlernen Sie Theorie und Praxis des System Engineerings. Sie erwerben Know-How in den Bereichen der Systemanalyse und Systemarchitektur und wie Sie diese natürlichsprachlich und modellbasiert dokumentieren.
Weiterführende Informationen zu unserem SE-Training finden Sie hier. (Link auf SE-Training) Gerne steht Ihnen auch unser Vertrieb per E-Mail vertrieb@sophist.de oder telefonisch unter der Rufnummer 0911 – 40 9000 für Ihre Fragen rund um das Training zur Verfügung.
Bis zum nächsten Mal.
Viele Grüße!
Ihre SOPHISTen
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 4: RFLP: Functional Viewpoint
„Funktionen sind im Gegensatz zu Anforderungen schon ein Schritt hin zur Realisierung, während Anforderungen nur den Lösungsraum darstellen“
-> während Anforderungen nur den Problemraum darstellen?
Hallo Mark,
vielen Dank für deinen Kommentar. Aufgrund der Urlaubssituation beantworte ich den Kommentar erst jetzt.
Aus unserer Sicht stellen Anforderungen nicht den Problemraum dar, sondern was benötigt wird, um das Problem zu lösen.
Diese Ansicht deckt sich auch mit dem Prinzip „Problem – Anforderung – Lösung“ aus dem CPRE FL Handbuch.
Hier der Link zum Handbuch: https://www.ireb.org/content/downloads/3-cpre-foundation-level-handbook/cpre_foundationlevel_handbook_de_v1.0.pdf
Beispiel:
Du möchtest von A nach B kommen. Problem: Du hast keinen Gegenstand, der dich dort hin bringt.
Hier beschreibst du nur das Problem. Darauffolgend lassen sich Anforderungen an den Gegenstand
und der Gegenstand selbst ermitteln. Annahme: Du hast dich für ein Auto entschieden, weil du selbst steuern willst.
Eine Anforderung könnte also lauten:
Das Auto muss dem Benutzer die Möglichkeit bieten zu seinem gewünschten Ziel zu fahren.
Hier beschreibst du was der gewünschte Betrachtungsgegenstand können muss, um dein Problem zu lösen.
Daraus ergibt sich, dass das Auto ein Funktion „fahren“ umsetzen muss, um die Anforderung zu erfüllen.
Die Funktion „fahren“ wird im Functional Viewpoint beschrieben.
Viele Grüße,
Tim