Herzlich Willkommen zurück zu unserer Blog-Serie rund um unser Buch „Requirements-Engineering & -Management – Aus der Praxis von klassisch bis agil“. Im letzten Blogartikel wurden die Grundlagen für die Systemanalyse geschaffen, wie die Dokumentation von Geschäftsprozessen mit Hilfe der UML & weiteren Analysemitteln erfolgreich durchgeführt werden kann. Im heutigen Artikel widmen wir uns der modellbasierten Dokumentation von Systemanforderungen, also der Dokumentation von funktionalen Anforderungen an unser System mittels UML.
> Use-Case-Diagramm
Nachdem Sie die Dokumentation Ihrer Geschäftsprozesse abgeschlossen haben, steht für Sie nun die erste Architekturentscheidung an. Dabei müssen Sie sich folgende Frage stellen: „Welche Systeme übernehmen welchen Business-Use-Case?“ Aus dieser Frage heraus entstehen neue System-Use-Cases, welche den Business-Use-Cases zugeordnet werden müssen.
Definition System-Use-Case
Abbildung 1: Definition System-Use-Case
System-Use-Case-Diagramme können vom Benutzer mit wenig Vorkenntnissen gelesen werden und sind für jede Art von Anwender leicht verständlich. Es muss also kein großer Aufwand in das Erlernen neuer Notationselemente investiert werden, so dass Use-Case-Diagramme im Management und bei der Anforderungsanalyse optimal für eine erste Skizze der zu entwickelnden Funktionalität eingesetzt werden können. Leider können bei Use-Case-Diagrammen Redundanzen oder Inkonsistenzen nur schwer vermieden werden, weshalb das Prüfen und Abstimmen solcher Diagramme einen hohen Stellenwert hat und dementsprechend auch Zeit für diese Tätigkeit eingeplant werden muss. Auch können Use-Cases nur den funktionalen Anteil eines Systems abbilden. Der nicht-funktionale Anteil wird in diesem Diagramm nicht dargestellt und muss mit anderen Analysemitteln betrachtet und im späteren Verlauf dokumentiert werden.
Nach der erfolgreichen Zuteilung von System-Use-Cases zu Business-Use-Cases ist der erste Schritt der Dokumentation getan. Leider stellen System-Use-Cases nur eine grobe Übersicht dar, welche Funktionalität das zu betrachtende System bieten soll. Daher ist der nächste Schritt für Sie zu jedem System-Use-Case eine detailliertere Beschreibung, die sogenannte Use-Case-Beschreibung (auch Anwendungsfallbeschreibung oder Use-Case Spezifikation genannt), anzufertigen. Einen Vorschlag für eine Use-Case-Beschreibung finden Sie in Abbildung 2 „Use-Case-Beschreibung“.
Abbildung 2: Use-Case-Beschreibung
> Aktivitätsdiagramm
Nachdem Sie nun jeden Use-Case näher beschrieben haben, kann das erstellte Hauptszenario in ein Aktivitätsdiagramm überführt werden. Ein Aktivitätsdiagramm beschreibt hierbei die Abläufe im System detaillierter. Wir dokumentieren nun den inneren Ablauf – sprich: die einzelnen Prozessschritte – des eben betrachteten Use-Case. Ist Ihnen die verfeinerte Aktivität auf erster Ebene noch zu grobgranular, können Sie diese Aktivität wiederum durch Unteraktivitäten in weiteren Ebenen verfeinern. So können Sie von grober Funktionalität (Use-Cases) zu immer feineren Abläufen (Aktivitäten) gelangen.
Damit sind wir nun ans Ende unseres Artikels gelangt. Wenn Sie mehr Informationen zur modellbasierten Dokumentation von Systemanforderungen erfahren möchten, können Sie das gerne ausführlich in unserem Buch „Requirements-Engineering und -Management – Aus der Praxis von klassisch bis agil“ in Kapitel 9 nachlesen. Hierbei werden Sie weitere Diagrammarten wie zum Beispiel das Sequenzdiagramm, oder aber auch das Klassendiagramm kennenlernen.
Wir wünschen Ihnen außerdem noch viel Spaß bei der Bearbeitung der Quizfragen für Kapitel 9!
Ihre SOPHISTen
In verschiedenen Projekten haben wir die Systemanalyse über das Erstellen der System -Use-Cases durchgeführt. Es ist ein sehr guter Ansatz, um sich einem System in Rahmen der Anforderungsanalyse initial zu nähern.
Bei höheren Komplexitäten wird sehr schnell deutlich, dass die Darstellung eines Business-Use-Case durch mehrere Systems-Use-Cases, Unteraktivitäten und deren Verfeinerungen sehr schnell unübersichtlich wird, was unter anderem auch daran liegt, dass nicht mehr alle zusammenhängenden „Bilder“ z.B. an einem Bildschirm dargestellt werden können. Hier den Überblick zu behalten erfordert viel Erfahrung, womit der Vorteil des leichten Erlernens der Notationselemente wieder aufgehoben wird.
Gibt es übergreifende Anforderungen, wie z.B. beim Product Line Engineering, stößt diese Vorgehnsweise schnell an ihre Grenzen. Die Darstellungen enthalten zunehmend Redundanzen, das Requirement Management wird aufwendig und fehleranfällig. Die im Einzelnen übersichtlichen „Bilder“ werden in Summe unübersichtlich und können dem Anspruch der Transparenz nicht mehr gerecht werden. Nach meinen Erfahrungen sind hier textuelle Systemanforderungen unbedingt zu bevorzugen. Natürlich können hier „Bilder“ bzw. Modelle die textuellen Anforderungen unterstützen.
Mein Fazit:
Für einen ersten Überblick und für Systeme mit geringer Komplexität ist nach meiner Erfahrung die Vorgehensweise über System-Use-Cases und deren Verfeinerungen gut geeignet. Bei der Systemanalyse von komplexen Systemen ist textuellen Anforderungen unbedingt Vorrang einzuräumen.
Hallo Herr Fangmeier,
vielen Dank für die ausführliche Schilderung Ihrer Praxiserfahrung und das abschließende Fazit. Wir freuen uns sehr, dass Sie unseren Blog so aufmerksam verfolgen!
Viele Grüße und sonnige Grüße aus Nürnberg
Fabian Lingg