Das „R“ im RFLP-Ansatz von SPES2020

Im letzten Blogbeitrag haben wir Ihnen unsere Interpretation des RFLP-Ansatzes vorgestellt. In dem RFLP-Ansatz spielen die RFLP-Viewpoints eine große Rolle und deswegen möchten wir Ihnen die RFLP-Viewpoints und ihre Inhalte in diesem und in den folgenden Blogbeiträgen präsentieren.

Ziel und Zweck

Der Requirements Viewpoint beinhaltet alle Anforderungen an den Betrachtungsgegenstand über unterschiedliche Abstraktionsebenen hinweg. Er beschreibt, was das betrachtete System leisten muss und fungiert als Ausgangspunkt für die Nachverfolgbarkeit der Inhalte in anderen Viewpoints.

Diesen Viewpoint sollten Sie in jedem Fall beachten, auch wenn Sie sich dazu entscheiden, nicht alle Viewpoints aus dem RFLP-Ansatz zu verwenden. Dieser Viewpoint ist die Basis für alle anderen Viewpoints. Am Ende ist jedes Architekturelement (vielleicht über mehrere Stationen) auf eine Anforderung zurückzuführen.

Bei diesem Viewpoint sollten noch keine funktionalen, logischen oder technischen Realisierungsmöglichkeiten eine Rolle spielen.

Inhalte

Der Requirements Viewpoint sollte mindestens folgende Inhalte enthalten:

• Use-Cases / Funktionen
• Textuelle Anforderungen für nicht-funktionale Aspekte wie Eigenschaften des betrachteten Systems

Funktionen bzw. der Use-Case-Ansatz zur Beschreibung von Funktionen sind ein Muss in jeder Systementwicklung, weil sie die kundenwahrnehmbaren Anforderungen mit fachlichem Wert für einen Akteur, der mit dem System agiert, darstellen. Funktionen werden u. a. durch Ablaufdiagramme näher spezifiziert.

Zudem sollten sie auch nicht-funktionale Anforderungen des betrachteten Systems abbilden, denn diese wirken sich auf die Realisierung des betrachteten Systems aus.

Optionale Sichten sind:

• Zustände in Zustandsdiagrammen
• Szenarien in Sequenzdiagrammen
• Informationsmodell/Glossar u. a. in Klassendiagrammen

Eine Sicht auf die Zustände der Objekte des Systems ist gerade dann zu empfehlen, wenn die Objekte des betrachteten Systems häufigen Zustandswechseln unterlegen sind.

Weiterhin hat es sich als positiv erwiesen, Sichten für ein Informationsmodell/Glossar und Ziele zu erzeugen, um den abzubildenden Ausschnitt der Realität mit nützlichen Informationen zu versehen.

Diagramme und Notationselemente

Für die Sicht der Use-Cases / Funktionen benötigen Sie das Use-Case-Diagramm der UML. Dieses stellt die Interaktion der Akteure mit den Funktionen des betrachteten Systems dar. Akteure interagieren mit dem System (z.B. Personen und externe Systeme. Notationselemente, die Sie zur Modellierung von Use-Cases / Funktionen benötigen sind:

• Use-Case
• Akteur
• Systemgrenze
• Assoziation

Akteure befinden sich außerhalb der Systemgrenze, da sie nicht Teil des Systems sind. Die Interaktion der Akteure mit Use-Cases / Funktionen des Systems stellt die Assoziation dar.

Die Abläufe der Use-Cases / Funktionen modellieren Sie mit dem Aktivitätsdiagrammen der UML und SysML. Eine Aktivität repräsentiert ein Use-Case / eine Funktion. Folgende Notationselemente benötigen Sie für die Modellierung eines Aktivitätsdiagramms:

• Aktion
• Informationsfluss
• Objekt
• Objektfluss
• Verzweigung
• Zusammenführung
• Parallelisierung
• Synchronisation

Die Sicht der übergreifenden nicht-funktionalen Anforderungen können Sie durch das Anforderungsdiagramm der SysML modellieren. Weiterhin können Sie übergreifende nicht-funktionale Anforderungen mit Klassen aus dem Klassendiagramm und in tabellarischer Form, darstellen.

Wenn Sie wissen möchten, wie Sie die Anforderungen Ihres Systems modellbasiert darstellen können, finden Sie weitere Informationen zu dem Requirements Viewpoint in unserem Systems-Engineering-Training. Für weitere Fragen, Buchung eines Trainings oder Unterstützung in Ihrem Projekt wenden Sie sich bitte an unseren Vertrieb unter der Telefonnummer 0911-40900-0 oder per E-Mail an vertrieb@sophist.de.

Im nächsten Blogbeitrag stellen wir Ihnen den Functional Viewpoint vor. Dort erfahren Sie, wie die Anforderungen aus Sicht des Stakeholders in Funktionen des Systems abgebildet werden können.

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 4: RFLP: Functional Viewpoint

Teil 5: RFLP: Logical Viewpoint

Teil 6: RFLP: Physical Viewpoint

Teil 7: Erkenntnisse aus Innovationsprojekt „Architektur im SE“