Management-Zusammenfassung dieses Beitrags:
Das System und der Systemkontext werden zu Beginn eines Vorhabens bestimmt, um abzugrenzen, welche Inhalte und Themen in der nachfolgenden Ermittlung von Anforderungen betrachtet werden sollen und welche nicht.
In diesem Beitrag wird der Scope / das System und der Systemkontext und deren Einsatz im → Requirements Engineering beschrieben.
Um zu bestimmen, welche Themen und Inhalte in einem Projekt oder einem Requirements-Engineering-→ Vorhaben betrachtet werden sollen, sollte unbedingt eine Bestimmung des Systems und Systemkontexts erfolgen. In diesem Beitrag wird eine Übersicht zum Thema “System und Systemkontext” oder auch “Scope Management” mit verschiedenen Blickwinkeln geliefert.
Das Thema System und Systemkontext wird in diesem Beitrag als ein Teilgebiet des → Requirements Engineerings verstanden.
1. Einleitung und Grundlagen
Anforderungen dienen zur Beschreibung eines Systems, welches durch einen Kontext und eine Umgebung entsprechende Grenzen besitzt. Nur für das System relevante Teile müssen detailliert erfasst und beschrieben werden.
Das → IREB (International Requirements Engineering Board) definiert den Systemkontext wie folgt /IREB21/:
“Der Systemkontext ist der Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen des zu entwickelnden Systems relevant ist.”
Das → IIBA verwendet den ähnlichen Begriff “Abgrenzungsmodell” und schreibt dazu /BBG17‑d/:
“Abgrenzungsmodell (scope model): Modell, mit dem die Grenzen eines Geschäftsbereichs oder einer Lösung bestimmt werden.”
Abbildung 1.1: System und Systemkontext
Die in Abbildung 1.1 verwendeten fünf Begriffe haben folgende Bedeutung:
- System: Dies ist der gestalt- oder veränderbare Teil der Realität
- Systemgrenze: Die Systemgrenze trennt den gestaltbaren und veränderbaren Teil der Realität („das System“) von den nicht veränderbaren Aspekten
- Systemkontext: Der Teil der Umgebung des Systems, der für die Definition und das Verständnis der Systemanforderungen relevant ist, selbst aber nicht gestalt- oder veränderbar ist, wird als Systemkontext bezeichnet
- Kontextgrenze: Die Kontextgrenze grenzt den relevanten vom irrelevanten Teil der Systemumgebung ab
- Umgebung: Für Anforderungen irrelevanter Teil der Systemumgebung
Vielfach werden der einfachen Darstellung noch Schnittstellen hinzufügt (gerichtete Pfeile oder Linien mit Abschlusspunkten in Abbildung 1.2), die dann im weiteren Verlauf einer Ausarbeitung benannt und konkretisiert werden können.
Abbildung 1.2: System und Systemkontext mit Schnittstellendarstellung
Nicht immer sind die Grenzen des Systems eindeutig zu bestimmen — es gibt Grauzonen, bei denen nicht (von vornherein) klar ist, ob sie zum System oder Systemkontext gehören. Diese Grauzonen sind in der nachfolgenden Abbildung 1.3 eingefügt.
Abbildung 1.3: System und Systemkontext mit Grauzonen
Es wird somit zwischen zwei Grauzonen unterschieden:
- Systemgrauzone: Dies ist der Bereich, bei dem nicht klar ist, ob die Elemente zum System oder zum Systemkontext gehören
- Kontextgrauzone: Dies ist der Bereich, bei dem nicht klar ist, ob die Elemente zum Systemkontext oder zur Umgebung gehören
Anmerkung:
Auf den Begriff “Systemumgebung” sollte zugunsten des Begriffs “Umgebung” verzichtet werden, um dies sprachlich besser unterscheiden zu können.
Es kann im Systemkontext-Diagramm der technische oder der organisatorische Aspekt im Vordergrund stehen (Abbildung 1.4). In der Praxis sollten dafür zwei Systemkontext-Diagramme erstellt werden.
Abbildung 1.4: Systemkontext: Unterscheidung Technik und Organisation
2. Die Bestimmung des Systems und des Systemkontexts
Zur Bestimmung des Systems und der Systemgrenzen können verschiedene Quellen herangezogen werden.
Dies sind beispielsweise:
- Altsysteme
- → Stakeholder(befragungen)
- Prozesse und → Geschäftsprozesse
- Ereignisse
- Dokumentationen
Generell sollte das System und der Systemkontext möglichst frühzeitig, d.h.vor der Ermittlung der Anforderungen, bestimmt werden. Dies ist aber nicht immer möglich, vielfach ergeben sich System und Systemkontext erst bei der Ausarbeitung oder der Umsetzung der Anforderungen. Eine (mögliche) zeitliche Einordnung der Bestimmung des Systems und des Systemkontexts ist in Abbildung 2.1 dargestellt.
Abbildung 2.1: System und Systemkontext bestimmen — zeitliche Einordnung
Nach /#microTOOL-Systemkontext-15/ beantwortet die Abgrenzung des Systemkontexts drei entscheidende Fragen:
- Was soll entwickelt werden?
- Was hat Einfluss auf die Entwicklung?
- Was kann vernachlässigt werden?
2.1 Schrittweises Vorgehen
Generell kann zunächst das System mit seinen Schnittstellen benannt werden, wobei an Schnittstellen immer Daten “übergeben werden”, d.h. in das System hinein- oder aus dem System herausgelangen. Die Schnittstellen werden — wie schon in Abbildung 1.2 — über gerichtete Pfeile symbolisiert.
Abbildung 2.2: System mit Schnittstellen
Typische Quellen für Schnittstellen sind “Nachbarsysteme” — diese können sein:
- Softwaresysteme
- Hardwaresysteme
- Geschäftsprozesse
- Sonstige Prozesse und Ereignisse
- Stakeholder / Personen
- Dokumente (z.B. mit rechtlichen Vorgaben)
Überträgt man diese potenziellen Quellen auf die einfache Darstellung, so ergibt sich folgendes Schnittstellendiagramm:
Abbildung 2.3: System mit möglichen Quellen für Schnittstellen (nach /IREB21/)
Die in Abbildung 2.3 verwendeten Elemente haben folgende Bedeutung:
Abbildung 2.4: Legende für Schnittstellen-Quellen (nach /IREB21/)
Nimmt man als Beispiel einen Bewegungsmelder mit seinen Schnittstellen, so kann daraus folgendes Systemkontextdiagramm resultieren:
Abbildung 2.5: Beispiel für ein einfaches Systemkontextdiagramm: Bewegungsmelder
An diesem einfachen Beispiel kann man sehr schnell erkennen, dass dieser Bewegungsmelder über einen integrierten Sensor verfügt, denn er wird nicht explizit im Systemkontext angegeben.
2.2 Prinzipien bei der Bestimmung des Systems und des Systemkontexts
Es sollten bei der Bestimmung des Systems und des Systemkontexts immer einige Prinzipien beachtet werden. Diese sind beispielsweise:
- Erkennen der Systemelemente
- → Minimieren der Schnittstellen
Wie viele Elemente (Nachbarsysteme und Schnittstellen) sollten bestimmt werden? In der Regel sollten etwa 5 bis 100 Elemente erfasst werden. Hruschka /Hruschka19/ schreibt dazu: “Das allergrößte, was wir jemals gezeichnet haben, war ein System mit 150 Nachbarsystemen und 400 Ein- und Ausgaben.”
In der Praxis kann die Bestimmung und Beschreibung des Systems und des Systemkontexts in einem → Workshop mit dem gesamten Team erfolgen. Dabei werden die Systemelemente auf einzelnen Zetteln notiert und gemeinsam den Kategorien 1. System, 2. Systemkontext und 3. Umgebung zugeordnet.
2.3 Zur Überprüfung des bestimmten Systems und des Systemkontexts
Ist das System und der Systemkontext bestimmt, so stellt sich die Frage, ob es “gut und richtig” ist — eine Überprüfung sollte diese Frage beantworten. In einem ersten Schritt sollte der Systemkontext mit der Beschreibung (Ziel, → Vision, → Mission) des Vorhabens oder — falls vorhanden — mit dem → Projektantrag / ‑vertrag abgeglichen werden. In einem zweiten Schritt können die Stakeholder (nochmals) befragt werden.
3. Die Darstellung des Systems und des Systemkontexts
Die Beschreibung kann textuell, über verschiedene grafische Formen oder spezielle Darstellungen erfolgen.
Dies sind beispielsweise:
- Ellipsen oder Kreise
- Rechtecke oder Quadrate
- Wolkenformen
- Kontextdiagramme aus der Strukturierten Analyse (SA) nach Tom DeMarco
- Use-Case-Diagramme
- Andere → UML-Diagramme
- Andere Formen der Darstellung
In Abbildung 3.1 sind drei einfache grafische Formen gegenübergestellt; diese sind gleichwertig.
Abbildung 3.1: System und Systemkontext in verschiedenen Darstellungsformen
3.1 Das Kontextdiagramm
Häufig wird ein Kontextdiagramm zur Beschreibung des Systems und Systemkontexts verwendet. Das Kontextdiagramm ist das Datenflussdiagramm aus der Strukturierten Analyse (SA) nach Tom DeMarco aus den 1970er Jahren /#Wiki-Kontextdiagramm/, welches aufgrund seiner Einfachheit zur Darstellung des Systems und des Systemkontexts häufig herangezogen wird.
Dabei wird das zentrale System als Kreis in den Mittelpunkt gestellt und die direkt umgebenden Nachbarsysteme (aus dem Systemkontext) als Rechtecke. Zwischen den diesen beiden Elementen werden beschriftete gerichtete Pfeile zur Visualisierung des Datenflusses eingesetzt (Abbildung 3.2).
Abbildung 3.2: Elemente eines Kontextdiagramms
“Spielregeln” für das Kontextdiagramm:
- Das System wird als Black-Box dargestellt
- Alle Nachbarsysteme werden benannt
- Alle Schnittstellen zu den Nachbarsystemen werden als gerichtete Pfeile eingetragen und benannt
Die Farben haben keine Bedeutung und dienen hier nur der Verdeutlichung.
In Abbildung 3.3 ist für ein Buchbestellsystem ein Kontextdiagramm angegeben.
Abbildung 3.3: Beispiel eines Kontextdiagramms nach /Hruschka19/
4. System, Gesamtsystem und Systemelement
Ein System, welches in einem RE-Vorhaben betrachtet wird, kann wiederum eingeordnet und untergliedert werden: Es kann übergeordnete Gesamtsysteme oder Systemelemente geben (Abbildung 4.1).
Abbildung 4.1: System, Gesamtsystem und Systemelement
5. Weitere Beispiele zur Verwendung des Systems und des Systemkontexts
In Abbildung 5.1 ist — als Beispiel für das System / den Systemkontext einer Dienstleistung — der Umfang einer Schulung für das Requirements Engineering angegeben.
Abbildung 5.1: Beispiel Systemkontext: Schulung “Requirements Engineering”
Anmerkung:
In Abbildung 5.1 sind die Inhalte meiner RE-Einführungsschulung dargestellt. Diese Schulung können Sie bei mir buchen.
6. Die Verwendung des Systems und des Systemkontexts
Generell sollte die Beschreibung des Systemkontexts im eigenen RE-Vorhaben weiterverwendet werden, denn alle dort gemachten Angaben müssen stimmen, ansonsten ist der Scope / Umfang nicht richtig erfasst.
6.1 Verwendung im Fachglossar
Alle im Systemkontext verwendeten Begriffe sollten im → Fachglossar aufgeführt werden. Daher bietet es sich an, das Fachglossar / → Glossar bei der Beschreibung des Systemkontexts heranzuziehen. Dabei gibt es folgende Möglichkeiten:
- Falls ein Fachglossar bereits vorliegt, so sollten “alle wesentlichen” Begriffe aus dem Glossar auch im Systemkontext verwendet werden
- Falls ein Fachglossar noch aufgebaut werden muss, so kann es bei der Erstellung des Systemkontexts initial befüllt werden
Sollten (wesentliche) Änderungen am Glossar vorgenommen werden, so sollte der Systemkontext / die Systemkontextbeschreibung überprüft und ggf. angepasst werden.
6.2 Satzschablonen
Durch die Beschreibung des Systems und des Systemkontexts wird festgelegt, was im RE-Vorhaben erfasst werden soll. Mit Hilfe von → Satzschablonen /Rupp20/ können dann Einzelanforderungen benannt werden. Hierzu wird der System- oder Subsystemname herangezogen und daraus eine Einzelanforderung abgeleitet (Abbildung 6.1).
Abbildung 6.1: Die → Satzschablone ohne Bedingung
Die Formulierung der einzelnen Anforderungen geschieht dann in separaten Schritten, wobei der erste Schritt immer die Benennung des betrachteten Teilsystems umfasst.
Diese sind:
- System benennen
- Rechtliche → Verbindlichkeit (auch: Verbindlichkeit oder Wichtigkeit) festlegen
- Funktionalität identifizieren
- Art der Funktionalität bestimmen
- Objekt identifizieren
6.3 Übergang zum Systems Engineering und zur Projektplanung
Wenn eine technische und eine organisatorische Systembeschreibung vorliegt, so kann damit (Abbildung 6.2) …
- die Systemmodellierung (beispielsweise mit der UML oder SysML) begonnen und
- und die erste Grobplanung für ein Projekt gestartet werden.
Abbildung 6.2: Systemkontext: Verwendung beim → Systems Engineering und bei der → Projektplanung
7. Stärken und Schwächen der Beschreibung von System und Systemkontext
Da das System und der Systemkontext in jedem RE-Vorhaben beschrieben werden muss, stellt sich die Frage nach “Stärken und Schwächen” nur indirekt. Generell sollten die Stakeholder anhand der Beschreibung von System und Systemkontext erkennen können, was gemacht werden soll.
8. Häufig gestellte Fragen und Antworten (FAQ) zum Thema “System und Systemkontext”
Einige Fragen zu dem System und Systemkontext werden häufig gestellt – diese werden hier wiedergegeben.
- F: Muss ich vor Beginn der Ermittlungstätigkeiten den Systemkontext bestimmen?
A: Ja. Dies ist sinnvoll. Leider ist häufig der Systemkontext zu einem frühen → Zeitpunkt nicht vollständig bestimmbar, sodass eventuell nachgebessert werden muss. - F: Welches Diagramm ist zur Darstellung des Systemkontexts am besten geeignet?
A: Im Zweifel dasjenige, das “von allen” verstanden wird. Ein Kontextdiagramm leistet dies im Allgemeinen. - F: Muss bei agiler Vorgehensweise (Agiles RE) der Systemkontext bestimmt werden?
A: Nein — nicht unbedingt, da durch die Kommunikation mit den Stakeholdern ohnehin nur das betrachtet wird, was “im Systemkontext” liegt. Meine Empfehlung ist jedoch, den Systemkontext sehr frühzeitig (“Sprint Null”) mit allen Teammitgliedern zu entwickeln, um so ein gemeinsames Verständnis für das “große Ganze” zu gewinnen.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
Das System und der Systemkontext wird (kurz) in der Präsentation zum Requirements Engineering beschrieben.
| Inhalt | Typ |
|---|---|
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 
|
In folgenden Büchern werden als Teilaspekt das System und der Systemkontext erläutert:
- /BBG15/ IIBA: A Guide to the → Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis, Marietta, Georgia 3rd Edition 2015, ISBN 978–1‑927584–02‑6
- /BBG17‑d/ IIBA: BABOK v3: Leitfaden zur Business-Analyse BABOK Guide 3.0, Dr. Götz Schmidt, Wettenberg 2017, ISBN 978–3‑945997–03‑1
- /Ebert19/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 6. Auflage 2019, ISBN 978–3‑86490–562‑9
- /Hruschka19/ Peter Hruschka: → Business Analysis und Requirements Engineering: Prozesse und Produkte nachhaltig verbessern, Hanser, München 2. Auflage 2019, ISBN 978–3‑446–45589‑4
- /IREB21/ siehe /Pohl21/
- /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-→ Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 5. Auflage 2021, ISBN 978–3‑86490–814‑9
- /Rupp20/ Chris Rupp: Requirements-Engineering und ‑Management. Das Handbuch für Anforderungen in jeder Situation, Hanser, München 7. Auflage 2020, ISBN 978–3‑446–45587‑0
Auf folgende Weblinks (zu dem System und Systemkontext) wird hier Bezug genommen:
- /#microTOOL-Systemkontext-15/ Fa. microTOOL: Der Systemkontext. Die Definition von System, Systemgrenzen und Randbedingungen
- /#V‑microTOOL-System-15/ Fa. microTOOL: Systemkontext und Systemkontextdiagramme: Video vom 16.02.2015 (deutsch, 4:33 Minuten)
- /#Sophist-Wissen-For-Free/ Fa. Sophist: Webseite mit einigen Broschüren und Postern rund um das RE
- /#Wiki-Kontextdiagramm/ Kontextdiagramm in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 08.05.2021 © Peterjohann Consulting, 2005–2025
