Hält die SysML was sie verspricht?

Seifenblase oder Problemlöser

Nun kommen wir an den Punkt, bei dem wir uns die Frage stellen müssen, ob mit der SysML – insbesondere mit dem neu erfundenen Anforderungsdiagramm – das Problem von Brüchen in der Systementwicklung aus der Welt geschafft werden kann. Und vor allem, ob dieses Vorgehen in der Praxis auch anwendbar ist.

Anforderungen gibt es in unterschiedlichsten Abstraktionsgraden. Von sehr groben, abstrakten bis hin zu den sehr detaillierten und feingranularen Anforderungen. Ein Beispiel für eine sehr grobe Prosaanforderung oder ein Ziel wäre: R1: „Durch den Einsatz des neuen Systems sollen trotz Steigerung der Luftfahrtbewegungen um 20%, 10% der Personalkapazitäten eingespart werden können und die Sicherheit der Luftkontrolle um 10% erhöht werden.“ Eine detaillierte Prosa-Anforderung könnte dann die folgende sein: R2: „Das System soll einen Einsatzplan erstellen, in dem maximal 8 Mitarbeiter pro Woche verplant werden.“

Da das Spektrum, was alles eine Anforderung darstellt, sehr weit ist, sollte man sich genau überlegen, welche Darstellungsart man für welche Anforderungsart verwendet. Schließlich möchte man ja keinesfalls redundant (also in UML und textuell oder gar noch als Prototyp) beschreiben – sondern nur genau einmal in der optimalen Repräsentation. Tabelle 1 zeigt die Vor- und Nachteile der unterschiedlichen Repräsentationsarten Modell, Sprache und Prototyp:

Tabelle 1: Sprache, Notation und Prototypen im Vergleich
Notation Vorteile Nachteile
Natürliche
Sprache

– Kann jeder

– Für alle Projektphasen einsetzbar

– Bewältigt alle Arten von Anforderungen

– Kann singuläre Aspekte in jeder Detaillierungsstufe darstellen

– Kann lösungsfrei beschrieben werden

– Komplizierte Entscheidungssituationen sind nur schwer zu beschreiben

– Unhandlich bei Änderungen, wenn nicht singulär beschrieben

Modelle

– Für alle Projektphasen einsetzbar

– Zeigt den Zusammenhang zwischen den Anforderungen

– Änderungen sind leichter zu pflegen

– Geeignet, um komplexe Abhängigkeiten im Überblick darzustellen

– Notation muss häufig erst erlernt werden

– Höherer Aufwand bei der Einführung

– Ungeeignet für die Darstellung von Details

Proto-
typen

– Zeigen schnell Ergebnisse für grafische Repräsentationen

– Anforderungen sind leicht vorstellbar

– Nicht alle Anforderungen sind darstellbar

– Umfangreiche Prototypen sind sehr aufwändig

Anforderungen auf sehr grober Ebene

Auf sehr grober Ebene (z.B. für sehr generische Anforderungen und Ziele) eignen sich Prosaanforderungen am besten, denn die noch sehr lösungsneutralen Anforderungen besitzen keine Abläufe oder Strukturen, die unbedingt modelliert werden müssten. Das Anforderungsdiagramm der SysML macht hier wenig Sinn, da es hier auch nicht auf die Abhängigkeiten der Anforderungen untereinander ankommt. Bleiben Sie hier bei wenigen textuellen Anforderungen. Falls Sie im nächsten Schritt darstellen möchten, wie diese Anforderungen durch das System realisiert werden, so können Sie die groben Anforderungen in das Diagramm integrieren, das die erste grobe funktionale Darstellung ihres Systems übernimmt. Dies ist bei den meisten Projekten das Use-Case-Diagramm. Da hier aber meist ein Ziel/eine grobe Anforderung durch mehrere Use Cases realisiert wird und ein Use Case der Erreichung mehrere Ziele dient, bringt eine derartige Darstellung meist wenig Nutzen. Verwenden Sie diese Möglichkeit der SysML nur, wenn Sie sich sicher sind, dass Sie Ihre Stakeholder damit nicht mehr verwirren als informieren.

Anforderungen auf detaillierterer Ebene

Bei detaillierteren Anforderungen entwickelt die Modellierung Ihre wirkliche Stärke. Wenn z.B. das System mittels Use Cases modelliert wurde und die Abläufe innerhalb der Use Cases dargestellt werden sollen, hat eine Modellierung deutliche Vorteile gegenüber der reinen Prosadarstellung von Anforderungen. Natürliche Sprache ist eben nur sehr bedingt geeignet, komplexe Entscheidungssituationen darzustellen. Sätze verschlingen sich da gerne in undurchdringliche wenn-dann-sonst-Konstrukte. Ein Diagramm, wie z.B. ein Aktivitätsdiagramm oder ein Zustandsautomat, hat hier deutlich bessere Chancen, einen komplizierten Ablauf so darzustellen, dass er überblickt werden kann. Anforderungen, die sich auf Reihenfolgen, Abhängigkeiten etc. beziehen, sollten Sie nicht textuell, sondern am besten in Form eines UML- oder SysML-Diagramms darstellen. Hier eignen sich vor allem der Zustandsautomat oder das Aktivitätsdiagramm, aber nicht das Anforderungsdiagramm. Somit sollten Sie Anforderungen, die Abläufe beschreiben, am besten klassisch modellieren, wie auch schon in der UML.

Feingranulare Anforderungen

Irgendwann sind alle komplizierten Abläufe und Entscheidungen modelliert. Übrig bleiben feingranulare Anforderungen, die einzelne Aktivitäten näher beschreiben, z.B R2: „Bei der Erstellung des Einsatzplans soll das System dem Nutzer alle im Zeitraum verfügbaren Mitarbeiter mit ihren ausführlichen Profildaten zur Auswahl per Mausklick in Form einer Liste anbieten.“

Hier wurden bisher Prosaanforderungen verwendet. Die Möglichkeit, feingranulare Anforderungen grafisch in ein Aktivitätsdiagramm oder einen Zustandsautomaten hineinzumodellieren, klingt verführerisch. Dies führt in der Praxis aber meist zu völlig überladenen, nicht mehr durchschaubaren Diagrammen. Je Aktivität sind in realen Projekten meist noch zwei bis 20 Anforderungen zu schreiben, um diese im Detail auszugestalten. Da innerhalb eines Diagramms meist fünf bis 15 Aktivitäten zu finden sind, kämen wir da zu einem Diagramm mit bis zu 300 Elementen. Dass das sinnlos ist, offenbart sich vermutlich jedem, der sich das bildlich vorstellt.

Wichtig ist dennoch, dass die Anforderungen, die eine Aktivität oder einen Zustand näher verfeinern, direkt mit dieser verknüpft sind. Ob Sie das wie bisher lösen, indem sie die Requirements-ID der Prosaanforderung (die sich in Word oder einem RM-Tool befinden) in ihrem Modell verlinken oder referenzieren, oder ob sie die Anforderungen in ihrem SysML-Tool modellieren (somit auch textuell beschreiben), ist eigentlich egal. Dabei sollten Sie aber tunlichst dafür sorgen, dass die Anforderungen nicht grafisch in den Diagrammen auftauchen. Grundsätzlich lässt sich sagen, dass Anforderungen natürlich in Beziehung zueinander stehen – diese in Form eines Anforderungsdiagramms zu modellieren, erscheint uns sinnlos und unübersichtlich.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.