dot.tipp - Wie kann ich meinen Product Scope visualisieren? Mit Kontextanalyse

David Berger
28. August 2018

Vorhaben starten. Doch kennen alle Beteiligten den Umfang des Produkts? Dieser Blog zeigt, wie man den Product Scope visualisiert. Und zwar mit bewährten Techniken aus dem Requirements Engineering. 

Als Embedded Coach in der Domäne Effective Delivery unterstütze ich Kunden dabei, Projekte abzuschliessen. Sobald ich ein IT-Projekt betrete, will ich mich fachlich und technisch orientieren. Ich verlange ein sogenanntes Kontextmodell - schön klassisch nach IREB. Ein Kontextmodell repräsentiert den Produktumfang, statt in epischen Aufzählungslisten prägnant und kompakt als menschenlesbares Modell. Es abstrahiert Aspekte wie Stakeholder, Prozesse, Umsysteme des Systems. Die Tätigkeit der Erstellung eines Kontextmodells heisst Kontextanalyse.

Wo ist sie nur?

Leider überfordere ich damit Projekte. Manche haben kein Kontextmodell. Manche haben es in einer veralteten Architekturdokumentation in einem DMS verwaist. Andere wiederum behaupten, sie hätten kein Kontextmodell nötig, weil allen Beteiligten alles klar sei. 

Diesen Antworten misstraue ich. Ein Kontextmodell muss omnipräsent, allen zugänglich und stets aktuell sein. Jede Anforderung verweist auf das Kontextmodell - unabhängig des gewählten Vorgehensmodells. Das Kontextmodell ist schliesslich der grösste gemeinsame Nenner eines Vorhabens. 

Mehrwert des Kontextmodells

dotag_Blog_Inhalt_Kontextanalyse

Das Kontextmodell hat meines Erachtens folgende Mehrwerte, unabhängig wie sie formalisiert sind:

  • Orientierung im Projekt
  • Verkürzung der Komplexität 
  • Vermittlung des gemeinsamen Verständnisses

Ebenso wertschöpfend ist der gemeinsame Prozess des Kontextmodells. Das Kontextmodell soll nicht in einem Einzelbüro gefertigt, mit formalen Reviewarten nach IREB wie Inspektionen begutachtet werden. Vielmehr ist das gemeinsame Kontextmodellschaffen eine Art Erlebnis, das wir von der dot consulting AG auch für sogenannte Nordstern-Workshops bekräftigen. 

Orientierung im Projekt

Mithilfe des manifesten Kontextmodells kann jeder Mitarbeitende und/oder Interessierte sich rasch in einem Kontext orientieren. Das Kontextmodell bietet den fachlichen wie technischen Einstieg. Das Kontextmodell wächst mit dem Vorhaben; Grauzonen klären sich, Systemgrenzen verschieben sich. Das Kontextmodell kann auch als Input-Spezifikation in agilen Vorhaben gemäss IREB wiederverwendet werden, um dort rasch den Umfang beispielsweise eines Epics zu illustrieren. 

dotag_Blog_Inhalt_Kontextanalyse_mit_Epic_Schnitt-1

Verkürzung der Komplexität

Komplexität existiert. Die grosse Kunst des Requirements Engineerings im Effective Delivery ist es, Komplexität zu abstrahieren. Hierfür eignen sich Modelle. Modelle sind per Definition verkürzend, denn sie blicken aus einer spezifischen, aber dafür exakten Perspektive. 

Ein Kontextmodell ist die abstrakteste Form eines Analyse-Modells. Es beschreibt den Kontext auf der oberersten Ebene. Auf dieser Ebene sind gewiss nicht alle Details abgebildet, manche Aspekte im Kontext sind bewusst verkürzt oder zusammengefasst. 

Vermittlung des gemeinsamen Verständnisses

Nicht nur die Erarbeitung des Kontextmodells ist wertschöpfend im Sinne des gemeinsamen Verständnisses. Auch das Kontextmodell als Artefakt begünstigt das gemeinsame Verständnis in der Kommunikation. Das Kontextmodell ist das Medium der Wahl, um den Kontext zu erläutern. Das wiederholende Erklären schärft und bestätigt das Kontextmodell. 

Ohne manifestes Kontextmodell müsste man ohne Bildunterstützung diskutieren - oder man behilft sich löblicherweise mit spontanen Visualisierungen, die aber nicht systematisiert und wiederverwendbar sind. Wer ohne Bildunterstützung diskutiert, verliert schnell den Kontext und verirrt sich entweder in Details oder auf Aspekte, die nicht im Kontext sind. Daher erinnert ein visualisiertes Kontextmodell an den oftmals schwierig zu haltenden Kontext. 

Notationsformen des Kontextmodells

Die Notationsform des Kontextmodells ist unerheblich; die in diesem Blog aufgezählten Mehrwerte wie Orientierung, Verkürzung und Vermittlung erzielt man unabhängig der Notationsform. Je nach Kontext eignen sich aber unterschiedliche Formen. 

Notationsform Vorteile Nachteile
UML Use Case Diagramm Einfache und schnell erlernbare Notation Nicht alle Aspekte können abgebildet werden (vor allem Architektur-Überlegungen)
UML Komponenten Diagramm Einfache Notation Vermittelt einen zu starken technischen Fokus, Benutzer-Interaktionen können gemäss strengem Syntax nicht abgebildet werden
Datenfluss Diagramm Einfache und populäre Notation Vermittelt einen zu starken technischen Fokus, veraltete und nicht immer eindeutige Notation
"Freestyle" / Visual Facilitation Keine Notation, so viele Informationen wie nötig können abgebildet werden (pragmatisch), fachliche wie technische Aspekte können gleichwertig visualisiert werden, keine Syntax-Diskussionen Keine formalisierte Spezifikation möglich, zwingt zu "Handarbeit"

 

Die grosse Eleganz der Freestyle-Notation ist, dass man nicht mit UML-Fetischisten über eine fehlerhafte Syntax diskutieren muss. Denn sobald man UML praktiziert, provoziert das automatische Notationsdiskussionen, denn UML ist sehr formalisiert. Hier kann die Freestyle-Notation die Diskussion entschärfen.  

Die gemeinsame Kontextanalyse am Kick-Off

Das Vorhaben startet. Eine weitere Teambildungsmassnahme ist die gemeinsame Kontextanalyse am Workshop, die zu einem abgestimmten Kontextmodell führt. Mit Papier und Stift dürfen die Teilnehmenden den Kontext interpretieren und somit schärfen.

Es geht nicht darum, auf der Granularitätsstufe Kontextmodell alle offenen Fragen zu klären - sondern darum, einen Überblick und ein Verständnis über den Produktumfang zu erlangen. Damit kann man sogleich die Teilnehmenden des Kick-Off Workshops "aktivieren" statt sie mit langatmigen PowerPoints zu beüben. 

Ist dein Kontext klar?

Wenn du diese Frage nicht zweifelsfrei beantworten kannst, raten wir dir, eine Kontextanalyse zu starten, auch wenn dein Projekt (vermeintlich) weit fortgeschritten ist. Für eine seriöse Kontextanalyse mit dem Artefakt des Kontextmodells gibt's keinen schlechten Zeitpunkt - besser spät als nie. 

In unserem IREB Certified Professional Requirements Engineering (CPRE) Foundation Level (FL) Kurs erlernst du die wichtigsten Notationsformen und kannst damit üben. 

Requirements Engineering lernen

Keine Kommentare bis jetzt

Lass uns wissen, was du darüber denkst.

Vielleicht gefallen dir auch

diese Artikel Effective Delivery

Newsletter Anmeldung