Use-Cases bilden einen guten Einstieg in die Systemanalyse. Sie ermöglichen es, vor jeglichen Detaildiskusionen einen Überblick über die gewünschten Funktionalitäten eines Systems zu erhalten. Als Darstellungsmittel für die Use-Cases verwendet man die Notationselemente eines Use-Case Diagramms der Unified Modeling Language UML

Da das Use-Case Diagramm nicht sonderlich kompliziert ist, stellt das Modellieren der Use-Cases auch keine wirklich große Kunst dar. Anders sieht es beim Identifizieren der einzelnen Use-Cases aus. Welche Funktionalitäten hat das System und wie detailliert müssen die Use-Cases sein, die diese Funktionalitäten beschreiben? Diese und viele weitere Fragen tun sich beim Suchen der richtigen Use-Cases auf.

Deshalb möchten wir Ihnen an dieser Stelle ein paar Tipps zum Schneiden von Use-Cases liefern:

1.    Ebene der Betrachtung
Gemeint ist hier Geschäftsprozess- versus Systemebene. Wenn man diese Ebenen nicht scharf voneinander trennt, führt das zu einer Vermischung von Uses-Cases dieser beiden Ebenen in einem Diagramm. Falls die Intention besteht, ein Use-Case Diagramm zu einer Software zu erstellen, nehmen wir als Beispiel einen Kalender, dann ist der Use-Case „Termin vereinbaren“ an dieser Stelle falsch adressiert. Beim vereinbaren eines Termins wird eine Kommunikation zwischen mehreren Personen stattfinden, was für den Kalender irrelevant ist. Vielmehr muss man sich fragen, welches Ergebnis wir uns vom Gebrauch des Kalenders erhoffen, z.B. einen Termin zu dokumentieren. In diesem Fall wäre  wohl eher „Termin anlegen“ ein Use-Case für unseren Betrachtungsgegenstand.

2.    Auf das Ergebnis achten
Das Ergebnis, welches man mit einem Use-Case erreichen möchte ist essenziell. Jeder Use-Case sollte einen Grund haben, der seine Existenz rechtfertigt. Dieser Grund resultiert aus dem Ergebnis, welches durch den Use-Case im Erfolgsfall erlangt wird. Dass im Falle eines Misserfolgs das Ergebnis des Use-Case anders aussehen kann, wird dabei nicht betrachtet. Wichtig  ist allerdings, dass das Ergebnis immer von einem Akteur gewünscht wird, also ein konkreter Bedarf an einem Ergebnis besteht. Unterschiedliche Ergebnisse deuten auf verschiedene Use-Cases und gleiche Ergebnisse auf ein und denselben Use-Case hin.

3.    Mut zur Lücke
Das Identifizieren der Use-Cases geschieht zumeist zu Beginn der Systemanalyse. Folglich können wir noch nicht alles wissen und so passiert es, dass nicht alle Use-Cases auf Anhieb gefunden werden. Das ist eine Unschärfe, mit der man zu Beginn erst einmal leben muss. Im Laufe der Analyse wird sich das Bild der Use-Cases dann jedoch vervollständigen.

4.    Die beteiligten Akteure
Auch die Frage, welcher Akteur an einem Use-Case beteiligt ist, hilft beim Identifizieren von Use-Cases. Für System-Use-Cases gilt die Regel, dass am Durchlaufen eines Use-Case nur ein menschlicher Akteur beteiligt ist. Es mag Ausnahmen zu dieser Regel geben, aber die Wahrscheinlichkeit, dass man sich bei mehreren beteiligten menschlichen Akteuren auf der Geschäftsprozessebene befindet, ist ziemlich hoch.

5.    Kein Verwalten
Bei der Benennung der Use-Cases sollten unklare und aussageschwache Verben vermieden werden. Ein typischer Vertreter ist das Verb „verwalten“. Häufig werden Use-Case, die mit solchen Verben versehen werden, als Sammelbecken für sämtliche Funktionalitäten verwendet, über die man noch nicht so genau Bescheid weiß. Das gilt es tunlichst zu vermeiden, denn die weiteren Detailbetrachtungen solcher Use-Cases gestalten sich als extrem schwierig. Demnach muss man sich die Frage stellen, was  denn beim Verwalten im Einzelnen getan wird. Das Ergebnis dieser Überlegungen spiegelt im Allgemeinen die wirklichen Use-Cases wider.

Prinzipiell ist das Auffinden der richtigen Use-Cases vor allem ein kreativer Prozess. Demnach sollte man den Mut haben, mit einem bestehenden Stand einer Use-Case-Modellierung weiter zu arbeiten, auch wenn die Vermutung besteht, dass diese nicht hundert prozentig korrekt sind. Sobald es in die Detailbetrachtung der einzelnen Use-Cases geht, wird sich deren Sinnhaftigkeit herausstellen. Dass es dann zu Nachbesserungen kommt ist normal.

Wir wünschen viel Erfolg beim Einsatz von Use-Cases in der Systementwicklung.