Das Framework für die digitale Transformation von objectiF RPM – Teil 5: Lösungsanforderungen

Unsere Reise zur digitalen Transformation mit objectiF RPM ist noch voll im Gange. Das Projekt Northern Country Stores hat die Strategieanalyse und Lösungsabgrenzung mit einem ersten Entwurf für die Lösungsarchitektur abgeschlossen.

Heute geht es weiter mit dem Requirements Engineering, also der Definition von konkreten, umsetzbaren Lösungsanforderungen. Parallel dazu entwickeln wir die Systemarchitektur detaillierter, weil wir uns am Twin Peaks Model orientieren. Hier noch einmal alle Teile der Blog-Reihe im Überblick:

1. Überblick
2. Strategieanalyse
3. Ableitung und Priorisierung von Geschäftsanforderungen
4. Lösungsabgrenzung
5. Anforderungsdefinition an die Lösung und Entwicklung der Systemarchitektur
6. Planung des Projekts

Anforderungen definieren

Das Projekt Northern Country Stores hat konkrete Anforderungen basierend auf seinen vorherigen Arbeitsergebnissen entwickelt. Die Anforderungen hat es zum einen rein textlich dokumentiert und zum anderen mit Hilfe eines Anforderungsdiagramms. In der folgenden Grafik zeige ich nur einen Ausschnitt davon, da es sehr umfangreich ist.

Anforderungen im Projekt Northern Country Stores: Als Liste und als Diagramm

Im Anforderungsdiagramm können Sie direkt erkennen, wie das Projekt ebenfalls Testfälle abgeleitet und mit einer Anforderung verbunden hat. Wenn Sie sich die Anforderungen genauer anschauen, stellen Sie unterschiedliche Typen fest. Ganz oben im Diagramm befindet sich z.B. ein Feature Requirement, also eine Anforderung auf hohem Niveau. Schweifen Sie mit dem Blick weiter über das Diagramm, so sehen Sie außerdem Epics und User Stories. Diese unterschiedlichen Typen verraten Ihnen, wie umfangreich die Umsetzung der Anforderung ist. Ein Epic lässt sich z.B. innerhalb eines Releases umsetzen, eine User Story kann dagegen in Sprints eingeplant und damit binnen ein oder zwei Wochen umgesetzt werden.

Die User Story Identifikation des Kunden per QR-Code hat einen geschätzten Aufwand von fünf Personentagen und ist bereits mit einer Systemkomponente verbunden, durch die sie erfüllt wird.

Beispiel einer User Story im Projekt Northern Country Stores

Wir haben also damit auch bereits einen ersten Eindruck von der weiterentwickelten Systemarchitektur gewonnen und wie diese mit Anforderungen verbunden werden kann, um die Traceability sicherzustellen.

Wie sieht die ausgearbeitete Architektur aus?

Systemarchitektur entwickeln

Wie anfangs erwähnt, folgen wir bei der Entwicklung der Anforderungen und der Systemarchitektur dem Twin Peaks Model. Das bedeutet: Die Arbeitsergebnisse aus beiden Fachbereichen werden parallel und iterativ entwickelt. So wurden aus einem ersten Entwurf in Form eines Blockdiagramms fünf Blockdiagramme. Sie finden diese in der Themenleiste unter Systemarchitektur.

Die in der Strategieanalyse skizzierte Lösungsarchitektur hat sich weiterentwickelt und ist detaillierter geworden. Als Ergebnis besteht die Lösung aus einem Shop, einer mobilen App, einem Service zur Analyse der Videodateien und einem Service für die Anwendung. Anders ausgedrückt besteht das Lösungssystem aus 4 Komponenten:

• Shop
• MobileApp
• VideoRecognitionService
• ApplicationService

Das System und seine Komponenten im Überblick

Zum besseren Verständnis wurden für die Komponente Shop die Struktur und der Informationsfluss zwischen diesen Komponenten in separaten Blockdiagrammen modelliert.

Aufbau und Informationsflow in der Komponente Shop

Anhand der satisfy-Beziehung innerhalb der Blockdiagramme erkennen Sie, welche Services welche Anforderungen erfüllen.

Ergebnisse als Dokument zusammenstellen

Sie können sowohl die Ergebnisse des Requirements Engineering als auch die der Entwicklung der Systemarchitektur als Dokument festhalten und als MS Word- oder PDF-Datei weitergeben.

Im Beispiel Northern Country Stores gibt es z.B. das Dokument Anforderungsdefinition Lösung, die Arbeitsergebnisse sind jedoch noch nicht integriert. Um diesen letzten Schritt zu tun, brauchen Sie nur einen Rechtsklick auf das Dokument machen und Inhalt generieren und öffnen wählen. Jetzt enthält das Dokument die erstellten Anforderungen.

Fazit

Der vorletzte Schritt im Workflow zur digitalen Transformation ist geschafft: Die Anforderungen an die Lösung und die Systemarchitektur wurden parallel zueinander entwickelt. Etwas fehlt aber noch. Das etwas, das uns eine klare Struktur verschafft, um all diese Arbeitsergebnisse zu erzeugen – und uns Möglichkeiten zur Überwachung der Entwicklung bereitstellt. Schließlich sind eine Menge Leute an diesem Projekt der digitalen Transformation beteiligt. Und sie arbeiten womöglich an unterschiedlichen Standorten, sodass die Aufgaben effizient koordiniert werden müssen. Das ist ein Thema der Projektplanung und Steuerung, die der nächste Teil behandeln wird. Also bleiben Sie gespannt auf den 6. und damit letzten Teil der Blog-Reihe.

Ein kostenloses Trial von objectiF RPM können Sie sich hier herunterladen.