Kolumne

Req4Arcs: Scope ist nicht gleich Scope

Peter Hruschka, Gernot Starke

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.

Abb. 1: Scope und Kontext

Abb. 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).

Abb. 2: Projekt-Scope vs. Produkt-Scope

Abb. 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. Wir bevorzugen zu diesem Zweck Komponentendiagramme mit einer kurzen (tabellarischen) Erklärung der Funktionalitäten und Schnittstellen. Das erleichtert die Diskussion über alle notwendigen Änderungen und Anpassungen.

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 hohe Risiken.
Zur Festlegung der Grenze zwischen Scope und Kontext reicht anfangs die Betrachtung der ein- und ausgehenden Daten Ihres Systems. Die klassische Darstellungsweise dafür ist ein sogenanntes fachliches Kontextdiagramm [1], wie Sie es als Beispiel für einen Bordcomputer eines PKWs in Abbildung 3 sehen. Das System soll den Fahrer sowohl mit typischen Informationen wie Durchschnittsgeschwindigkeit, Treibstoffverbrauch, Außentemperatur etc. versorgen als auch Navigation ermöglichen, einen Tempomaten zur Verfügung stellen, Wartungsintervalle überwachen und den Fahrer über Radiosender und Telefonanrufe informieren.

Abb. 3: Kontextdiagramm mit Ein- und Ausgaben des Systems

Abb. 3: Kontextdiagramm mit Ein- und Ausgaben des Systems

Sie sollten in einem Kontextdiagramm alle Nachbarsysteme identifizieren und für jedes davon die Ein- und Ausgaben benennen. Eine Aufzählung von Funktionen (oder Features und Epics) genügt meist nicht, um den Scope des Produkts festzulegen!

Falls Sie übrigens Diagramme nicht mögen, so wird unter [1] eine ganze Menge an alternativen Notationen dafür vorgeschlagen, im einfachsten Fall eine Tabelle mit allen Nachbarsystemen und deren Schnittstellen. Wichtig ist, dass Sie erstens Ihr System klar identifiziert haben, zweitens alle Nachbarn kennen und drittens die komplette Ein- und Ausgabe auf fachlicher Ebene verstanden haben.

Entwicklung braucht (Schnittstellen-)Details

Als Ergebnis einer Anforderungsanalyse genügt es, Ein- und Ausgaben von und zu den Nachbarn zu erkennen. Diese Schnittstellen explizit identifiziert zu haben, bedeutet mehr als die halbe Miete.

Bei Entwurf und Entwicklung des Systems müssen Sie bei jeder dieser externen Schnittstellen alle notwendigen Details entweder hinterfragen oder entscheiden. Unter [2] finden sich dazu viele pragmatische Hinweise. Sie müssen zum Beispiel festlegen, wer der aktive Partner ist (Push oder Pull), wie die Handshakes oder Protokolle aussehen, die an der Schnittstelle einzuhalten sind, welche zeitlichen, technischen oder organisatorischen Randbedingungen einzuhalten sind etc.

Im arc42-Termplate haben wir Abschnitt 3 (Kontextabgrenzung) für diese wichtigen Informationen vorgesehen. Abschnitt 3.1 enthält das fachliche Kontextdiagramm. Falls nötig, können Sie in Abschnitt 3.2. noch das technische Kontextdiagramm aufnehmen, das die technischen Kanäle zeigt, über die fachliche Informationen fließen. In obigem Beispiel würde man für das Fahrerinterface vielleicht sowohl Spracheingabe als auch Tastatureingabe technisch zulassen. Viele der anderen Schnittstellen laufen vielleicht über den CAN-Bus. arc42-Abschnitt 3.2 enthält dann auch ein Mapping, welcher fachliche Input/Output über welchen technischen Kanal läuft.

Alternativ können Sie Details von Schnittstellen auch als technische oder querschnittliche Konzepte in Abschnitt 8 beschreiben – falls Sie beispielsweise viele Schnittstellen nach demselben Schema behandeln möchten.

Falls Sie auf die grafische Variante stehen: Die UML bietet Ihnen viele Möglichkeiten, Schnittstellen genauer festzulegen. Abbildung 5 zeigt zu obigem Beispiel jetzt die Verwendung von Ball- und Socket-Notation beziehungsweise die Einführung von Ports.

Wir Autoren vertreten diesbezüglich unterschiedliche Meinungen: Peter mag UML, Gernot eher die text- oder tabellenorientierte Beschreibung von Schnittstellen. Beides funktioniert…

Abb. 4: Notation für Schnittstellendetails

Abb. 4: Notation für Schnittstellendetails

Abbildung 4 zeigt noch eine Empfehlung: Wenn ein Produkt viele Schnittstellen aufweist, könnten Sie diese als Analyseergebnis bündeln. Die Abbildung zeigt nur zwei Sensoren (Temp- und Durchfluss). Stellen Sie sich aber vor, dass Sie mehrere Dutzend Sensoren als Schnittstellen haben. Dann lohnt es sich, anfänglich in der Analyse nur über ein Sensorinterface zu sprechen und dieses erst in der Entwicklung detailliert aufzuspalten. Ein weiteres Beispiel wären im Telekommunikationsbereich die Schnittstellen zu Roaming-Partnern. Dabei handelt es sich vielleicht um einige Hunderte, die teilweise ganz unterschiedliche Protokolle nutzen oder unterschiedliche Formate liefern. Trotzdem kann man sie anfangs zu einem „Roaming-Partner-Interface“ zusammenfassen. Wie gesagt: Schnittstelle erkannt, Gefahr halbwegs gebannt.

Damit sind Sie in den weitaus meisten Fällen mit Scope und Kontext fertig. Ein i-Tüpfelchen aber hätten wir noch für Sie.

Business- und Produkt-Scope

Gründliche Requirements Engineers unterscheiden zwischen Business-Scope und Produkt-Scope: Der Business-Scope ist der Bereich Ihres Unternehmens oder Ihrer Organisation, in dem Sie im Zuge Ihrer Software- oder Systementwicklung Entscheidungen treffen oder vorschlagen dürfen – also beispielsweise Ihr Fachbereich oder Ihre Abteilung. Normalerweise ist der Business-Scope um einiges größer als der Produkt-Scope, weil Sie vielleicht nicht alles, was in Ihren Entscheidungsbereich fällt, auch automatisieren wollen. Sie können also in Zusammenarbeit von Analytikern und Architekten festlegen, welche Teile von Geschäftsprozessen automatisiert und welche Schritte vielleicht noch längere Zeit manuell durchgeführt werden sollen.

Abb. 5: Business- und Produkt-Scope

Abb. 5: Business- und Produkt-Scope

Abbildung 5 zeigt eine solche Situation. User 1 und User 2a sowie IT-System 1 befinden sich außerhalb Ihres Business-Scope. Dort haben Sie keinen direkten Einfluss. User 2b und User 3 sowie IT-System 2 gehören in Ihren Business-Scope. Daher sollte es relativ leicht sein, diese bei der Neuentwicklung eines Produkts zu berücksichtigen. IT-System n gehört Ihnen nicht allein, sondern es sind auch andere Verantwortliche im Business-Kontext mit im Spiel.

Für User 2a können Sie zum Beispiel entscheiden, dass Anfragen zunächst an User 2b in Ihrer Abteilung gehen und dieser mit dem neuen Produkt diesen Request erfüllt. Später erhält User 2a vielleicht einen direkteren Zugriff zu dem neuen System.

Unsere Empfehlung ist es, in der Anforderungsanalyse die Scheuklappen grundsätzlich etwas weiter aufzumachen und an die Schnittstellen Ihres Business zu denken, statt an die möglicherweise eingeschränkten Schnittstellen eines Produkts.

Sie sehen schon: Scope und Kontextabgrenzung sind in vielen Fällen nicht trivial. Und wenn Sie diesen Input nicht von Requirements Engineering oder Business Analysts bekommen, dann ist das ein ganz wichtiger, früher Schritt bei Ihrer Architekturarbeit.

Fazit

Nehmen Sie die Festlegung von Scope und Kontext ernst. Im Entwicklungsteam müssen Sie manchmal nacharbeiten, weil die Anforderungsanalyse oder Ihre Product Owner Sie diesbezüglich im Stich gelassen haben.

Nutzen Sie bereits frühzeitig in Ihrem Projekt oder Vorhaben ein Kontextdiagramm als Kommunikationshilfsmittel, um Feedback Ihrer Stakeholder über die wichtigen Außenschnittstellen ihres Systems einzuholen – lange bevor Sie interne Entscheidungen treffen. Legen Sie besonderes Augenmerk auf volatile oder kritische Schnittstellen, die sich oft und ohne ihr Zutun ändern können.

In der nächsten Folge beschäftigen wir uns mit funktionalen Anforderungen. Bis dahin alles Gute, mit hoffentlich geklärtem Scope und Kontext.

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Req4Arcs: Scope ist nicht gleich Scope"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Suljo Čakišić
Gast
Hallo Herr Hruschka und Herr Starke, als erstes möchte ich mich für Ihr tolle Arbeit rund um den KnowHow Transfer bedanken. Nun zu meiner eigentlichen Frage. Ich habe ein Produkt welches ich nach arc42 dokumentiert habe. Unter Kapitel 3 habe ich den Systemkontext fachlich wie auch technisch erfasst und abgebildet. In der Mitte habe ich mein Produkt und links und rechts zwei Systeme die mit meinem zutun haben. Die Beziehungen habe ich im fachlichen Kontext benannt um diese in der Tabelle unter Kapitel 3.2 mit den technischen Kanälen zu mappen (Beziehung | Input | Output) Nun habe ich eine ergänzende… Read more »