Auf der Basis des Bedarfs wird der Scope definiert, d.h. die Eingrenzung der fachlichen wie auch technischen Untersuchung des Projekts. Dazu gehört auch die Definition der Dinge, welche explizit nicht im Projekt berücksichtigt werden und „Out of Scope“ sind.

Systeme sind immer in einen Kontext eingebettet. Ohne diesen Kontext zu verstehen, ist es unmöglich, ein System richtig zu spezifizieren. Der Kontext (im RE*) ist der Teil der Systemumgebung, der für das Verständnis des Systems und seiner Anforderungen relevant ist. Der Kontext eines Systems wird durch die Systemgrenze und die Kontextgrenze abgegrenzt. Die Kontextgrenze ist die Grenze zwischen dem Kontext eines Systems und denjenigen Teilen der Anwendungsdomäne, die für das System und seine Anforderungen nicht relevant sind. Die Systemgrenze ist die Grenze zwischen einem System und seinem umgebenden Kontext. Der Scope ist die Bandbreite der Dinge, die bei der Entwicklung eines Systems geformt und gestaltet werden können. Manchmal stimmen die Systemgrenzen und sein Scope jedoch nicht überein. Es reicht nicht aus, nur die Anforderungen innerhalb der Systemgrenze zu berücksichtigen.

*Requirements Engineering (=Anforderungsmanagement)

Aspekte im Systemkontext, die zum Untersuchungsumfang (Scope) gehören können:

Anforderungsfabrik Aspekte im Sysmkontext
  • Dokumente (z. B. Gesetze, Vorgaben, Unternehmensstandards)
  • Personen (Stakeholder)
  • Partner-Systeme (andere Systeme oder Systemkomponenten, die eine Schnittstelle zum System besitzen)
  • Prozesse (Geschäftsprozesse oder technische Prozesse, die Auswirkungen auf das System haben)
  • Ereignisse (technische oder physikalische Ereignisse, die das System beeinflussen)
Anforderungsfabrik Aspekte im Sysmkontext

Empfehlung

Grenzen Sie anfänglich den Untersuchungsumfangs (ggf. mit Projekt-/Teilprojektleiter, ergänzt um relevante Stakeholder) ab. Der Fokus sollte dabei auf der Definition von Inhalt und Umfang des Projekts sowie klarer Abgrenzung liegen. Wichtig ist es zu beachten nicht direkt mit der Entwicklung des Systems zu beginnen. Die Chance, dass Kommunikationsprobleme zwischen den beteiligten Parteien entstehen, ist ohne klar definiertem Scope sehr wahrscheinlich. Oft besteht jedoch die Annahme, dass die Anforderungen selbstverständlich sind. Daher sollte man den Auftraggeber intensiv einbeziehen, viel kommunizieren und gemeinsam Entscheidungen treffen. Risiken müssen dabei unbedingt angesprochen und reflektiert werden. Bei entsprechenden Risiken, die mit hoher Wahrscheinlichkeit und Tragweite eintreten, muss der Scope ggf. anpasst werden.

Werkzeuge

Erstellen Sie von Anfang an einen Projektsteckbrief, der die wesentlichen Aspekte des Projekts übersichtlich darstellt. Einen generellen Überblick erhalten Sie durch eine Übersicht aller angrenzenden Systeme mithilfe eines Kontextdiagramms. Use Case-Diagramme können zur vereinfachten Darstellung genutzt werden. Weiter wären Prozess-, Daten- und Applikationsframeworks der Branche zu nennen. Standard-Bürosoftware (Word, PowerPoint, ggf. Visio) sind einfache Tools, die man auch dafür nutzen kann.

Ergebnis

Ziel dieser Aktivitätsgruppe ist es, dass ein möglichst klar abgegrenzter Scope (inkl. System und Systemkontext) definiert ist

Hinweis

Man muss sich stets bewusst sein, dass auf Projekt-/Programmebene sich der Scope mit der Zeit ändern kann. Auf Teilprojekt-/Arbeitsebene wird sich der Scope konkretisieren und verkleinern.

Sie brauchen Hilfe? Lassen Sie sich von uns unverbindlich beraten.