Kontextabgrenzung – Grenzen abstecken – Teil 1

Kennen Sie die Situation? Sie haben sich entschieden ein System zu entwickeln und nun müssen Sie erst einmal einige Entscheidungen treffen:

  • Was gehört eigentlich zum System dazu und muss spezifiziert werden?
  • Welche äußeren Aspekte haben Einfluss auf das System bzw. welche Einschränkungen sind zu beachten?
  • Und was hat keinen Einfluss auf das System?

Um diese Fragen zu beantworten, führt man eine Kontextabgrenzung durch, welche das System und die Systemgrenze definiert, festlegt was der Systemkontext beinhaltet, und die irrelevante Umgebung abgegrenzt. Doch was versteht man überhaupt unter diesen Begriffen?

Um eine Kontextabgrenzung korrekt durchzuführen muss man erst einmal wissen, welche Bereiche man beachten muss. Das System ist das zu entwickelnde Ergebnis unserer Bemühungen. Die Systemgrenze trennt das geplante System von seiner Umgebung – dem Systemkontext. Der Systemkontext ist der Teil der Umgebung eines Systems, der das System beeinflusst und der bei der Erhebung der Anforderungen an das System relevant ist. Das System kann aber den Systemkontext selbst nicht beeinflussen. Es muss sich daran anpassen. Mögliche Aspekte im Systemkontext können Personen (z. B. Stakeholder), Systeme (z. B. andere technische Systeme, mit denen das System kommunizieren muss), Prozesse (z. B. Geschäftsprozesse) oder Dokumente (z. B. Gesetze) sein. Die Kontextgrenze trennt den Systemkontext von der irrelevanten Umgebung ab. Die irrelevante Umgebung hat keinen Einfluss auf das geplante System und somit auch nicht auf die Anforderungen.

Die folgende Abbildung zeigt skizzenhaft die verschiedenen Bereiche: das System, die Systemgrenze, den Systemkontext, die Kontextgrenze und die irrelevante Umgebung.

Abbildung 1: Bereiche der Kontextabgrenzung

Grauzonen

Es können natürlich nicht immer zu Beginn alle Aspekte einem der drei Bereiche zugeordnet werden. Aufgrund von ausstehenden Management-Entscheidungen, fehlenden Informationen oder bisher unberücksichtigt gebliebenen Aspekten ist man sich nicht immer sicher, ob etwas zum System gehört oder nicht, oder ob es das System beeinflusst oder nicht: dies sind dann die sogenannten Grauzonen.

Obwohl Grauzonen während der Analyse hingenommen werden müssen, ist es wichtig, sie im Laufe des Projektes aufzulösen. Früher oder später muss eine Entscheidung getroffen werden, ob die Elemente der Grauzonen innerhalb oder außerhalb der System- bzw. Kontextgrenze liegen.

Schnittstellen

Haben Sie eine vollständige Kontextabgrenzung durchgeführt und eine vollständige Beschreibung des Systems und seiner Umgebung, können Sie einen großen Vorteil dieser Herangehensweise erkennen. Die zu implementierenden Schnittstellen des Systems werden Ihnen auf dem Silbertablett geliefert. Sie fragen sich wieso? Das zu entwickelnde System kann nur dann mit den Personen oder Systemen im Systemkontext kommunizieren, wenn es auch über entsprechende Schnittstellen verfügt. Unser System muss also allen Systemen, die im Systemkontext liegen Schnittstellen zur Verfügung stellen. Zusätzlich können wir an dieser Stelle festlegen, welche Daten über die Schnittstellen fließen und ob diese in das System oder zu anderen Systemen fließen.

Ausblick

Wenn Sie eine vollständige Kontextabgrenzung durchgeführt haben, müssen Sie das Ganze aber auch dokumentieren. Es reicht nicht, dieses Wissen über den Systemkontext nur im eigenen Kopf zu haben, es muss auch festgehalten und anderen Projektbeteiligten zugänglich gemacht werden.

Wie man das Ganze dokumentieren kann, werden wir Ihnen in den beiden folgenden Teilen dieser Blogserie vorstellen.

Wenn Sie noch Anmerkungen oder Fragen haben oder uns einige Erfahrungen zu diesem Thema mitteilen möchten, schreiben Sie einen Kommentar oder senden Sie uns eine Mail an heureka@sophist.de.

Wir freuen uns über Anregungen, neue Sichtweisen und wissenshungrige Blogleser!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.


9 + = zehn