Samstag, 18. Mai 2013

Welche Arten von Kontextobjekten gibt es?


These: Systemkontextanalyse öffnet die Augen für optimale Software

Im Systemkontext befinden sich mehr oder weniger interessante Kontextobjekte. Kontextobjekte sind abzugrenzende Einheiten, bei denen es sich lohnt, sie als Ganzes zu beschreiben. Es macht Sinn, Kontextobjekte zu klassifizieren, um für gleichartige Kontextobjekte standardisierte Beschreibungswege zu finden. Diese Klassen von Kontextobjekten werden auch als Kontextaspekte bezeichnet. Pohl [S65, POHL08] findet drei Kontextaspekttypen.


  1. Anforderungsquellen – Sie bilden die direkte Grundlage der Systemanforderungen.
  2. Betrachtungsgegenstände – Sie sind wichtig für das Verstehen der Zusammenhänge. Anforderungsquellen bilden eine Teilmenge der Betrachtungsgegenstände.
  3. Eigenschaften und Beziehungen der Betrachtungsgegenstände.
Jedes Kontextobjekt wird somit immer als Betrachtungsgegenstand erfasst. Die besondere Kennzeichnung als Anforderungsquelle kann zu einem späteren Zeitpunkt erfolgen, und sie bildet keine unwiderrufliche Entscheidung. Bei den Übergängen vom IST-Zustand zu den SOLL-Zuständen muss spätestens im System-SOLL-Zustand die Kennzeichnung als Anforderungsquelle erfolgen, um die Beziehungen zwischen Anforderungen und Kontextobjekt zu modellieren.

Die Kontextobjekte sollten nicht isoliert betrachtet werden. Zwischen ihnen existieren vielfältige Beziehungen, deren Darstellungen ein wesentlicher Bestandteil der Systemkontexterfassung bilden.


Im Folgenden versuche ich eine Aufzählung geeigneter Kontextaspekte. Nicht jeder Kontextaspekt muss in einem abzubildenden Systemkontext enthalten sein.
  1. Stakeholder: „Ein Stakeholder ist eine Person oder Organisation, die ein potentielles Interesse an dem zukünftigen System hat und somit in der Regel auch Anforderungen an das System stellt. Eine Person kann dabei die Interessen von mehreren Personen oder Organisationen vertreten, d.h. mehrere Rollen einnehmen“ [S.65, POHL08]
  2. Dokumente: Dokumente sind schriftlich fixierte Medien wie Handbücher, Gesetzestexte, Standards, Richtlinien, Quellcode, Systembeschreibungen und Anforderungsbeschreibungen.
  3. Systeme: Systeme sind Softwareprogramme und/oder Hardware wie Altsysteme, Konkurrenzsysteme, aber auch Systeme, an die weitergeleitet wird oder mit denen zusammengearbeitet wird.
  4. Prozesse: Ein Prozess ist eine Aktivität zur Verarbeitung von Eingangsdaten. Die Beschreibung des Algorithmus dieser Verarbeitung bildet die Abbildung des Prozesses.
  5. Domänenmodell: Das Domänenmodell ist das Fachmodell. Es zeigt alle zu betrachtenden Daten und deren Beziehungen. Außerdem werden alle Fachbegriffe definiert.
  6. Strategien: Eine Strategie bildet einen Plan des Vorgehens. Oft sind Strategien in Dokumenten erfasst. Dennoch lohnt sich die gesonderte Erfassung, weil Strategien die Grundlage der Entwicklung des zu betrachtenden Gegenstandes bilden. Es gibt z.B. Geschäftsstrategien, Sicherheitsstrategien oder auch IT-Strategien.
  7. Geschäftsregeln: Geschäftsregeln sind Bedingungen und damit in Zusammenhang stehende Aktivitäten. Somit stehen Geschäftsregeln und Prozesse in einem engen Zusammenhang.
  8. Prozesslandschaften: Prozesslandschaften bilden eine klassifizierende und geordnete Darstellung von Prozessen in Bezug auf eine bestimmte Einheit, wie z.B. einen Betrieb.
  9. Aufbauorganisationen: Aufbauorganisationen stellen das Ordnungsprinzip einer Organisation dar. Somit stehen Stakeholder und Aufbauorganisationen in einem engen Zusammenhang.
  10. IT-Landschaften: IT-Landschaften stellen das Zusammenwirken von Soft- und Hardwaresystemen dar.
Es ist vorstellbar, das es viele weitere Kontextaspekte gibt. Diese sollten ergänzt werden und mit der Zeit in das Gesamtsystem eingebaut werden. Für den Anfang einer strukturierten Erfassung des Systemkontextes sind sie jedoch vollkommen ausreichend.



In den folgenden Posts möchte ich verschiedene Modellierungsmöglichkeiten diskutieren, mit denen die einzelnen Kontextaspekte geeignet und intuitiv dargestellt werden können.

  • [POHL08] Klaus Pohl: „Requirements Engineering“, 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen