Systems Engineering Trends

Jede Woche Neuigkeiten aus der Welt des Systems Engineering

AnforderungenMethoden

Systemkontext: Bedeutung, Modellierung und praktische Anwendungen

Jedes Entwicklungsprojekt hat einen Systemkontext. Denn dieser ist der Teil der Umgebung eines Systems, der für die Entwicklung relevant ist. Daher sollten wir diesen auch explizit festhalten. Das kann mit oder ohne Modellierung geschehen. Was genau der Systemkontext ist und wie wir ihn modellieren können, darum geht es in diesem Artikel.

Nicht vergessen: Stimmt bis zum 15.01. ab, ob SE-Trends für Bildung, Umwelt oder Frieden spenden soll.

Der Systemkontext

Der Systemkontext ist ein Werkzeug, um mit den Stakeholdern zu kommunizieren. Daher wird dieser in der Regel für die Definition und das Verständnis der Anforderungen genutzt. Die Stakeholder sind dementsprechend Teil des Systemkontexts. In den Kontext gehören auch Fremdsysteme (einschließlich der Schnittstellen, mit denen sie angeschlossen werden), aber auch Gesetze und Normen.

Alles im Universum ist miteinander durch die Gesetze der Physik verknüpft. Das meiste ist jedoch für unser System irrelevant und daher nicht Teil des Systemkontextes. Allerdings sorgt eine immer stärkere Vernetzung dafür, dass der Kontext ebenfalls wächst, was starke Auswirkungen auf die Größe des Kontextes haben kann.

Wir können, wenn wir wollen, den Systemkontext noch weiter unterteilen. Zum Beispiel könnten wir außerhalb des Kontexts noch den Anwendungsbereich einführen, der aber nicht Teil des Kontextes sind.

Systemkontext mit UML modellieren

Ein Systemkontext muss nicht formal modelliert werden. Für einfache Systeme reichen die berühmten „Kästchen und Striche“. Allerdings ist es schon seit Jahrzehnten üblich den Kontext mit UML zu modellieren. Der Haken: eigentlich ist UML dafür gar nicht geeignet, denn es gibt offiziell gar kein Kontextdiagramm in UML. Daher sind UML-Kontextdiagramme eher Bilder, nicht formale Modelle. In der Praxis finden wir auch oft von UML „inspirierte“ Kontextdiagramme, die dann aber auch mit sprechenden Bildern arbeiten.

Der Aufwand einer formal halbwegs korrekten UML-Modellierung ist nur dann gerechtfertigt, wenn das Modell einen Mehrwert dem informellen Bild gegenüber hat. Ein Mehrwert ist Präzision. Dieser kann aber nur dann realisiert werden, wenn das Team die Notation gut versteht und dadurch Fehler in der Kommunikation vermieden werden. Ein anderer Mehrwert ist Automatisierung, also die maschinelle Weiterverarbeitung des Modells.

Systemkontext mit SysML

In SysML können wir den Kontext mit Blöcken modellieren. Grundsätzlich ist das Vorgehen ähnlich wie bei UML. Doch finden wir bei SysML oft auch methodische Unterstützung, die für eine echte Durchgängigkeit sorgen kann.

Schon vor über zehn Jahren hat Tim Weilkiens in seinem SysML-Buch (und auch in seinem Blog) beschrieben, wie wir den Systemkontext mit Blöcken beschreiben können (zu sehen in der Box rechts).

Durch die Weiterentwicklung der SysML ist die Notation allerdings schon wieder überholt. Bereits in dem Artikel empfiehlt Tim, das Actor-Symbol nicht mehr zu verwenden. Dieses Vorgehen begründet er ausführlich in dem Artikel The Death of the Actor.

Methoden, die auf der SysML aufsetzen, haben dieses Vorgehen größtenteils übernommen, wie die MagicGrid-Methode (MagicGrid® Book of Knowledge).

Nützlich, aber kein Modell: System Footprint Canvas

Gerade für das Brainstorming nützlich ist der System Footprint Canvas. Dabei handelt es sich um einen an den Business Model Canvas angelehnten Einseiter, der alle für den Systemkontext relevanten Informationen enthält, konkret:

  • Leistungsversprechen
  • Wichtigste Funktionen
  • Wichtigste Komponenten
  • Wichtigste Anwendungsfälle
  • Wichtigstes Produkt/Ergebnis
  • Wichtigste Stakeholder
  • Technische Rahmenbedingungen
  • Wichtigste Stakeholder-Einschränkungen
  • Schnittstellen

Im Gegensatz zum Business Model Canvas hat die Anordnung dieser Punkte auf dem Papier keine tiefere Bedeutung. Insofern können wir auch einfach diese Liste als Checkliste beim Erarbeiten des Systemkontexts nutzen.

Mindestens genauso wichtig ist das Vorgehen bei der Erstellung des Systemkontexts. Dazu kann ich das Vorgehen von Markus Unterauer in seinem Buch Workshops in Requirements Engineering empfehlen.

Fazit

Der Systemkontext ist ein einfaches, aber wichtiges Artefakt, das in keinem Entwicklungsprojekt fehlen sollte. Es kann nützlich sein, ein formales Kontextmodell zu erstellen. Das macht aber nur Sinn, wenn auch die Architektur formal modelliert werden soll. In dem Fall benötigen wir auch eine Methode. Und jede Methode, die was taugt, macht auch Vorgaben für die Kontextmodellierung.

Oft reicht für den Systemkontext auch ein einfaches Bild, wenn das Ziel ist, die Kommunikation der Stakeholder zu schärfen. Wichtig ist dann nur, dass alle Stakeholder die verwendete Notation auch verstehen.

Michael Jastram

Creator and Author of SE-Trends