Use Cases

Also nach Durchsicht der Anforderungen und Use Cases in den Gruppen 1, 4 und 5 lassen sich folgende wiederkehrende Probleme identifizieren (ich habe in den Kommentaren auch teilweise auf diese Punkte verwiesen):

1. Überladung: Die Diagramme sind oft überladen und werden somit unleserlich. Es wird anscheinend versucht alle Use Cases des Systems in ein Diagramm zu packen. Das ist nicht immer zielführend. Lösung: Diagramm auftrennen in mehrere Diagramme, die jeweils einen konkreten Ausschnitt (z.B. Benutzerverwaltung) zeigen.

2. Formulierung: Use Cases sind oft unklar formuliert. Z.B. "Suchen" klingt gut, aber es bleibt offen was gesucht wird. Lösung: Es hilft bei Use Case Benennung sich nach dem Schema Nomen+Verb zu halten, z.b. "Mitarbeiter suchen", "Forumseintrag erstellen", etc.

3. System Case: Es kommen Use Cases vor, die eher Systemverhalten repräsentieren (z.B. "Bestätigung erhalten"). Diese sind meist Systemaktionen, die durch einen anderen Use Case ausgelöst werden. Lösung: diese nicht als Use Cases modellieren. Es sollte aus der Beschreibugn bzw den Anforderungen dann erkennbar sein, dass das System eine Bestätigung verschickt. Konzentrieren Sie sich auf Interaktionen, die der Benutzer auslöst und wo der Benutzer aktiv mit dem System arbeitet um seine Ziele zu erreichen.

4. CRUD Use Cases: Oft sind Use Cases zu abstrakt, es ist keine konkrete Handlung dabei zu identifizieren, z.B. "Benutzer verwalten" (deshalb CRUD, weil Create, Retrieve, Update, Delete in einem Use Case vereint sind). Das ist kein Use Cases, bestenfalls noch ein abstrakter Use Case, der duch "Benutzer anlegen", "BEnutzerdaten ändern", etc. konkretisiert werden sollte. Auch ist es nicht sinnvoll, mehrere Use Cases in einen Use Case zusammenzufassen wie "Benutzer anlegen/ändern/löschen". In einem richtigen Use Case Dokument gibt es zu jedem Use Case eine strukturierte Beschreibung, das wäre in so einem Fall nicht möglich.

5. Zu Ablauforientiert: Oft wird zu viel Ablauflogik in die Use Cases durch übermäßiges Verwenden von «include» und «extend» eingebaut. Use Case Diagramme sind aber statische Diagramme ohne jegliche Ablaufinformation. Lösung: Beziehungen zwischen Use Cases nur wenn logisch und strukturell relevant, nicht versuchen alle Use Cases miteinander zu verknüpfen.

6. Keine Systemgrenze: Es ist die Systemgrenze unklar und/oder es fehlt die Benennung des Systems. Lösung: Rechteck um die Use Cases (im Zentrum) machen, bennenen, Use Cases innerhalb, Akteure links und/oder rechts ausserhalb. Das ist vor allem wichtig, wenn es mehrere Diagramme gibt.

Grundsätzlich war die Qualität der P2 Abgaben ganz gut, mit Ausschlägen nach oben aber auch einige nach unten. Je weniger schwerwiegend Sie die oben genannten Probleme ihren Use Cases anhängen können, desto besser :-) Die Anforderungen waren auch sehr unterschiedlich. Teilweise war kaum/nicht erkennbar wie diese erhoben wurden oder viel zu abstrakt formuliert, teilweise sehr klar und strukturiert.