Warum ist der Systemkontext so wichtig?
Systeme sind in einen Kontext eingebettet, und ohne dieses Verständnis lässt sich ein System nicht richtig spezifizieren. Der IREB-Lehrplan formuliert das als viertes Prinzip: Systeme lassen sich nicht isoliert verstehen. Der Kontext ist dabei der Teil der Umgebung eines Systems, der für das Verständnis des Systems und seiner Anforderungen relevant ist [1]. Wer den Kontext nicht klärt, übersieht Schnittstellen, Stakeholder und Annahmen, von denen das System abhängt.
In der Praxis zeigt sich das an typischen Streitfragen: Gehört die Anbindung an das Buchhaltungssystem zum Auftrag oder nicht? Wer liefert die Stammdaten der Mitarbeitenden? Muss das neue System auch die Ferienplanung abdecken, oder bleibt diese im bestehenden Werkzeug? Solche Fragen lassen sich zu Beginn in einer Stunde klären. Werden sie erst während der Umsetzung gestellt, führen sie zu Nachträgen, Verzögerungen und Konflikten.
Was bedeuten Systemgrenze, Kontextgrenze und Scope?
| Begriff | Bedeutung | Leitfrage |
|---|---|---|
| System | das, was entwickelt oder verändert wird | Was bauen oder verändern wir? |
| Systemgrenze | Grenze zwischen dem System und seinem Kontext | Was gehört zum System, was nicht? |
| Kontext | relevanter Teil der Umgebung zwischen Systemgrenze und Kontextgrenze | Wer und was wirkt auf das System ein oder wird von ihm beeinflusst? |
| Kontextgrenze | trennt den relevanten Kontext vom Rest der Welt | Was ist für unsere Anforderungen irrelevant? |
| Scope | alles, was bei der Entwicklung gestaltet werden kann | Worauf haben wir Einfluss? |
Der Lehrplan betont, dass die Systemgrenze anfangs oft unklar ist und sich mit der Zeit verschieben kann. Sie zu klären und die externen Schnittstellen zwischen dem System und den Kontextelementen festzulegen, ist eine originäre Aufgabe des Requirements Engineering. Gleichzeitig ist der Scope zu bestimmen, also die Menge dessen, was im Rahmen der Entwicklung gestaltet werden kann [1]. Systemgrenze und Scope fallen oft, aber nicht immer zusammen: Ein Projekt kann etwa einen Geschäftsprozess mitgestalten, der ausserhalb des Softwaresystems liegt.
Wie erstellt man ein Kontextdiagramm?
Ein Kontextmodell zeigt das System, die Akteure im Kontext, die mit dem System interagieren, und skizziert die Schnittstellen, etwa in Form ausgetauschter Informationen. Für Kontextdiagramme gibt es keine standardisierte Notation; verwendet werden Diagramme aus der strukturierten Analyse oder einfache Darstellungen aus Kästen und Linien. In UML bieten Use-Case-Diagramme eine Möglichkeit, das System mit seinen Use Cases und den Akteuren im Kontext zu modellieren [1].
- 1System in die Mitte setzen und eindeutig benennen.
- 2Akteure sammeln: Personengruppen, andere Systeme, Organisationen, Geräte, die mit dem System interagieren.
- 3Für jeden Akteur festhalten, welche Informationen in welche Richtung fliessen.
- 4Grenzfälle klären: Gehört ein Element zum System oder zum Kontext?
- 5Was ausdrücklich nicht dazugehört, separat notieren.
- 6Diagramm mit Stakeholdern validieren und als Teil der Spezifikation pflegen.
Beispiel: Kontext einer Zeiterfassungslösung
| Akteur oder System | Information an das System | Information vom System |
|---|---|---|
| Mitarbeitende | Zeiteinträge, Tätigkeiten, Abwesenheiten | eigene Übersichten, Erinnerungen |
| Projektleitende | Projekte, Budgets, Freigaben | Auswertungen pro Projekt, Warnungen bei Budgetüberschreitung |
| Personalsystem | Stammdaten der Mitarbeitenden, Pensen | keine |
| Buchhaltungssystem | Kundennummern, Kostenstellen | abgeschlossene Monatsdaten für die Rechnungsstellung |
| Lohnsystem | keine | geleistete Stunden pro Person für die Lohnabrechnung |
| Kunde | keine direkte Interaktion | Leistungsnachweise über die Projektleitenden |
Aus dieser Darstellung ergeben sich sofort wichtige Fragen: Welches System ist führend für die Stammdaten? In welchem Format und wie oft werden Daten an die Buchhaltung übertragen? Was passiert, wenn das Personalsystem nicht erreichbar ist? Jede Schnittstelle erzeugt Anforderungen, die ohne Kontextdiagramm leicht übersehen werden. Zugleich zeigt die Tabelle, dass der Kunde kein direkter Akteur ist; Anforderungen an ein Kundenportal gehören deshalb nicht in diesen Auftrag, sofern das nicht ausdrücklich gewünscht ist.
Wie wird die Abgrenzung dokumentiert?
Neben dem Kontextdiagramm hat sich eine einfache Liste bewährt, die festhält, was ausdrücklich zum System gehört und was nicht. Diese In-und-Out-Liste schafft Klarheit für Auftraggeber, Team und Lieferanten. Sie ist besonders wichtig bei Ausschreibungen und Festpreisverträgen, weil sie den Leistungsumfang begrenzt und spätere Diskussionen über Mehrleistungen vermeidet.
| Im Umfang | Nicht im Umfang |
|---|---|
| Erfassung von Arbeitszeiten auf Projekte und Tätigkeiten | Ferien- und Abwesenheitsplanung (bleibt im Personalsystem) |
| Auswertungen pro Projekt, Person und Monat | Rechnungsstellung (erfolgt im Buchhaltungssystem) |
| Export abgeschlossener Monate an Buchhaltung und Lohn | Kundenportal mit direktem Zugriff für Kunden |
| Mobile Erfassung über Browser | eigene App für Smartphones |
Die Liste wird gemeinsam mit dem Auftraggeber erarbeitet und Teil des Projektauftrags oder der Spezifikation. Änderungen am Umfang laufen danach über das Änderungsverfahren. Wie der Projektumfang klassisch gesteuert wird, beschreibt der Beitrag Scope-Management und Änderungskontrolle; wie er im Projektauftrag festgehalten wird, der Beitrag Projektauftrag schreiben.
Was sind Kontextannahmen?
Bei der Spezifikation eines Systems genügt es laut Lehrplan nicht, nur Anforderungen innerhalb der Systemgrenze zu betrachten. Zu berücksichtigen sind auch Änderungen im Kontext, die sich auf die Systemanforderungen auswirken können, Anforderungen der realen Welt, die für das System relevant sind, und Kontextannahmen, die gelten müssen, damit das System funktioniert und die Anforderungen der realen Welt erfüllt [1].
Ein Beispiel: Die Zeiterfassung liefert korrekte Lohndaten nur unter der Annahme, dass die Pensen im Personalsystem aktuell sind. Diese Annahme liegt ausserhalb des Systems, ist aber für den Erfolg entscheidend. Sie muss festgehalten, mit den Verantwortlichen abgestimmt und validiert werden. Das sechste IREB-Prinzip verlangt ausdrücklich zu prüfen, ob Kontextannahmen vernünftig sind. Wird eine Annahme verletzt, kann ein korrekt umgesetztes System trotzdem falsche Ergebnisse liefern.
Systemkontext in Normen und HERMES
Die Norm ISO/IEC/IEEE 29148 behandelt die Abgrenzung des Systems und seiner Schnittstellen als Teil der Anforderungsprozesse und der geforderten Informationsobjekte [2]. In HERMES-Projekten wird der Kontext in den Ergebnissen zu Stakeholderinteressen und Lösungsanforderungen sichtbar; eine klare Abgrenzung ist zudem Voraussetzung für Beschaffungen, bei denen der Leistungsumfang eindeutig beschrieben werden muss [3]. Eine Vorlage für Lösungsanforderungen bietet flenio.ch unter HERMES Lösungsanforderungen.
Typische Fehler bei der Abgrenzung
| Fehler | Folge | Gegenmittel |
|---|---|---|
| Kein Kontextdiagramm | Schnittstellen werden spät entdeckt | Kontextdiagramm zu Beginn erstellen und validieren |
| Keine In-und-Out-Liste | Streit über Leistungsumfang | ausdrücklich festhalten, was nicht dazugehört |
| Kontextannahmen nicht dokumentiert | System liefert falsche Ergebnisse trotz korrekter Umsetzung | Annahmen festhalten und mit Verantwortlichen abstimmen |
| Systemgrenze nicht nachgeführt | Dokumentation passt nicht mehr zum Projekt | Kontext bei Änderungen aktualisieren |
| Nur technische Systeme als Akteure | Personengruppen und Organisationen fehlen | alle Arten von Akteuren systematisch prüfen |
Kontext im Werkzeug festhalten
Kontextdiagramm, In-und-Out-Liste und Kontextannahmen gehören an einen zentralen Ort, auf den alle Beteiligten zugreifen. In Flenio lassen sich diese Inhalte als Dokumente im Projekt ablegen und mit Anforderungen und Meilensteinen verknüpfen. Wie aus dem geklärten Kontext Anforderungen erhoben werden, beschreibt der Beitrag Anforderungen erheben. Den Gesamtzusammenhang zeigt der Leitfaden Requirements Engineering.
So führen Sie einen Kontext-Workshop durch
Ein Kontext-Workshop dauert typischerweise zwei bis drei Stunden und bringt Auftraggeber, Fachbereich, Informatikbetrieb und gegebenenfalls Vertreter angrenzender Systeme zusammen. Zu Beginn wird das System benannt und sein Zweck in einem Satz festgehalten. Danach sammeln die Teilnehmenden auf Karten alle Personengruppen, Systeme und Organisationen, die mit dem System zu tun haben könnten. Für jeden Kandidaten wird entschieden, ob er zum System, zum Kontext oder ausserhalb der Kontextgrenze liegt. Grenzfälle werden ausdrücklich diskutiert und entschieden, statt sie offen zu lassen.
Anschliessend werden für jeden Akteur im Kontext die ausgetauschten Informationen beschrieben, jeweils mit Richtung und, soweit bekannt, Häufigkeit und Format. Am Ende stehen ein Kontextdiagramm, eine In-und-Out-Liste, eine Liste der Kontextannahmen und eine Liste offener Fragen mit Verantwortlichen. Diese Ergebnisse bilden den Rahmen für die weitere Erhebung: Jeder Akteur ist eine potenzielle Quelle für Anforderungen, jede Schnittstelle erzeugt funktionale Anforderungen und Qualitätsanforderungen, etwa an Verfügbarkeit oder Datenformate.
Aus den Schnittstellen entstehen oft die ersten Qualitätsanforderungen und Randbedingungen, etwa vorgeschriebene Formate oder Übertragungszeiten. Wie diese messbar formuliert werden, beschreibt der Beitrag Funktionale und nicht-funktionale Anforderungen. Wie Abläufe innerhalb der Systemgrenze beschrieben werden, zeigt der Beitrag Use Case vs. User Story.
Die Ergebnisse des Workshops sind kein Endpunkt. Mit jeder neuen Erkenntnis wird geprüft, ob sich der Kontext verändert hat: Kommt ein neues System hinzu, fällt ein Akteur weg, verschiebt sich die Grenze? Ein aktuelles Kontextdiagramm ist eines der wertvollsten Arbeitsprodukte im gesamten Requirements Engineering, weil es auf einer Seite zeigt, worüber alle anderen Anforderungen sprechen. Es lohnt sich, dieses Diagramm in jedem wichtigen Review kurz zu zeigen.