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.
Management-Zusammenfassung zu diesem Beitrag:
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.
Das Thema System und Systemkontext ist ein Teilgebiet des Requirements Engineerings (RE), welches
hier beschrieben wird.
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 /IREB15/:
“Der Systemkontext ist der Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen des Systems verantwortlich ist.”
Abbildung 1.1: System und Systemkontext
Die 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
Statt System wird häufig auch der Begriff Scope (of Product) oder Produktumfang verwendet, statt Systemkontext findet man auch Scope of Work oder Arbeitsbereichsumfang.
Vielfach werden der einfachen Darstellung noch Schnittstellen hinzufügt (Abbildung 1.2), die dann im weiteren Verlauf benannt werden.
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 vorneherein) klar ist, ob sie zum System oder Systemkontext gehören. Diese Grauzonen sind in der nachfolgenden Abbildung eingefügt.
Abbildung 1.3: System und Systemkontext mit Grauzonen
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 heraus gelangen.
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
- Personen / Stakeholder
- Dokumente (z.B. mit rechtlichen Vorgaben)
Trägt man diese Quellen auf die einfache Darstellung, so ergibt sich folgendes Schnittstellendiagramm:
Abbildung 2.3: System mit möglichen Quellen für Schnittstellen (nach /IREB15/)
Trägt man diese Quellen in die einfache Darstellung ein, so ergibt sich folgendes Schnittstellendiagramm:
Abbildung 2.4: Beispiel für ein einfaches Systemkontextdiagramm: Bewegungsmelder
An diesem einfachen Beispiel kann bereits 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
- Minimierung der Schnittstellen
Wieviele 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.”
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 gegen die Beschreibung des Vorhabens oder — falls vorhanden — gegen den 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 Systemkontextes 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 (siehe Abbildung 3.2).
Abbildung 3.2: Elemente eines Kontextdiagramms
“Spielregeln” für das Kontextdiagramm:
- Das System wird als Blackbox 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. Die Verwendung des Systems und des Systemkontexts
Durch die Beschreibung des Systems und des Systemkontextes wird festgelegt, was zum im RE-Vorhaben erfasst werden soll. Mithilfe von Satzschablonen /Rupp14/ können dann Einzelanforderungen benannt werden.
Abbildung 4.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
5. 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.
6. Häufige Fragen und Antworten 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. - F: Welches Diagramm ist zur Darstellung des Systemkontexts am besten geeignet?
A: Im Zweifel dasjenige, das “von allen” verstanden wird. - 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.
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. Eine separate Ausarbeitung im pdf-Format ist auf Anfrage verfügbar.
| Inhalt | Version | Stand | Seiten | Größe | Typ |
|---|---|---|---|---|---|
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 0.96 | 03/2017 | 248 | 1,3 MB |  (pdf) |
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
- /IREB15/ siehe /Pohl15a/
- /Pohl15a/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering – Foundation Level, dpunkt, Heidelberg 4. Auflage 2015, ISBN 978–3‑89864–771‑7
- /Pohl15b/ Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam – Foundation Level – IREB compliant, Rocky Nook, Santa Barbara, California 2nd Edition 2015, ISBN 978–1‑937538–77‑4
- /Rupp14/ Chris Rupp: Requirements-Engineering und ‑Management. Aus der Praxis von klassisch bis agil, Hanser, München 6. Auflage 2014, ISBN 978–3‑446–43893‑4
Auf folgende Weblinks (zu dem System und Systemkontext) wird hier Bezug genommen:
- /#IREB-CPRE-FL-17/ Lehrplan zum CPRE Foundation Level, deutsche Version 2.2.1 vom 24.07.2017
- /#IREB-CPRE-FL-E-17/ Lehrplan zum CPRE Foundation Level, englische Version 2.2.2 vom 23.07.2017
- /Rupp-Wissen-For-Free/ Chris Rupp (Fa. Sophist): Webseite mit einigen Broschüren und Postern rund um das RE
- /#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)
- /#Wiki-Kontextdiagramm/ Kontextdiagramm in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (generell)
/*/ Verweis auf eine Website, die als Buch-Ergänzung dient
/#/ Verweis auf einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 28.10.2019 © Peterjohann Consulting, 2005–2020