© Excellent backgrounds/Shutterstock.com
Kolumne: Requirements4Arc

Kolumne: Requirements4Arc


In der vorigen Folge haben wir Ihnen drei Zutaten vorgestellt, die Sie als Architekt(in) von anderen auf jeden Fall einfordern sollten, bevor Sie mit Designentscheidungen loslegen: klare Ziele, die Kenntnis der Stakeholder und die Festlegung Ihres Scopes. Starten wir mit dem Scope.

Der Scope ist der Bereich, in dem Sie freie Entscheidungen treffen dürfen (Abb. 1). Im Kontext liegen die Schnittstellen zu Umsystemen oder Nutzergruppen. Änderungen daran müssen Sie mit den dafür Zuständigen verhandeln. Dinge im Kontext liegen also außerhalb Ihres direkten Einflussbereichs.

hruschka_starke_folge3_1.tif_fmt1.jpgAbb. 1: Scope und Kontext

Erfahrungsgemäß tun sich viele Projekte und/oder Teams schwer damit, diese einfache Abgrenzung präzise vorzunehmen: Was gehört in unseren Scope und mit wem müssen wir verhandeln? Deshalb wollen wir in diesem Teil unserer Kolumne genauer auf die Feinheiten der Scope-Festlegung eingehen.

Produkt-Scope und Projekt-Scope

Wenn man von Produkt oder System spricht, ist meist ein IT-Produkt oder ein IT-System gemeint. Sollte Ihre Aufgabe also darin bestehen, ein (einziges) neues IT-System zu schaffen, so sind Produkt-Scope und Projekt-Scope identisch. In der Praxis betreffen Projekte manchmal auch mehrere vorhandene IT-Systeme. Möglicherweise müssen Sie ein System neu entwickeln oder kräftig modifizieren und in diesem Rahmen auch notwendige Anpassungen anderer IT-Systeme mit erledigen (Abb. 2).

hruschka_starke_folge3_2.tif_fmt1.jpgAbb. 2: Projekt-Scope vs. Produkt-Scope

Wie Sie in Abbildung 2 erkennen, müssen Sie die Schnittstellen des neuen (oder zu modifizierenden) Systems zu den Benutzern und zu IT-System 2 festlegen. Außerdem gilt es, auch die Leistungen, Funktionalität und Schnittstellen innerhalb der IT-Systeme 1, 3 und 4 zu identifizieren, die angepasst werden müssen. Sollten Sie als Projektverantwortlicher keine Entscheidungsgewalt über die notwendigen Änderungen an den IT-Systemen 1, 3 und 4 haben, so ist Ihr Projekterfolg vom guten Willen dieser drei Nachbarsysteme abhängig: Sie brauchen dort Änderungen, dürfen diese aber nicht selbst ausführen oder anordnen, sondern müssen mit den Verantwortlichen dieser Systeme verhandeln.

Nutzen Sie für die Scope-Festlegung Ihres Projekts eine visuelle Gesamtübersicht (Kontextdiagramm) des neuen oder zu modifizierenden Systems, zusammen mit den Nachbarsystemen 1 bis 4.

Notationen für Scope und Kontext

Requirements-Analysten können Schnittstellen einfach vorgeben – in der Entwicklung bereiten diese den Entwicklungsteams möglicherweise viel Aufwand und beinhalten h...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang