11 Erinnerungen für jeden Use Case

• Ein Use Case ist eine Kurzgeschichte
   
• Mache die Use Cases einfach lesbar
   
  • Halte dich kurz und bringe es auf den Punkt
     
  • Starte von oben und erzeuge eine stimmige Geschichte
     
  • Oben befindet sich ein strategischer (summary) Use Case
     
  • Die User Goal und Subfunction Use Cases verzweigen von hier
     
  • wähle die Namen mit kurzen Verben, die das Ziel des Use Cases ausdrücken
     
  • starte vom Trigger und fahre fort bis das Ziel erreicht oder aufgegeben ist und das System seine Buchführung mit Rücksicht auf die Transaktion getan hat
     
• Mache die Use Cases einfach lesbar
   
  • Schreibe volle Sätze mit aktiven Verben, die das Unterziel, das erreicht werden soll, ausdrücken
     
  • Stelle sicher, daß der Aktor und seine Absicht in jedem Schritt sichtbar werden
     
  • Stelle sicher, daß die Fehlerbedingungen gut erkennbar und die recovery Actions gut lesbar sind. Stelle sicher, daß gut erkennbar ist, was als nächstes passiert, auch ohne die Nummer der Schritte
     
  • Füge alternatives Verhalten in die Extensions ein und nicht als if statements in den Hauptablauf
     
  • Erzeuge Extension Use Cases nur unter sehr ausgewählten Bedingungen
     
• Nutze die "Ein Satz Form"
   
  • Ein Satz in der Gegenwart
     
  • mit einem aktiven Verb in der aktiven Form
     
  • einen Aktor beshreibend, der erfolgreich ein Ziel erreicht und den Prozeß vorantreibt
     
• "Include" Sub Use Cases
   
  • Benutze Sub Use Cases um untergeordnete Ziele zu erreichen
     
    • System überprüft Autorisierung des Callers
       
  • unterstreiche den Sub Use Case
     
  • bevorzuge die <<include>> Beziehung vor <<extends>> und <<specializes>>
     
• Wer hat den Ball
   
  • Nutze nicht die Passivform aus der Sicht des Systems
     
    • nicht "Software wird heruntergeladen" sondern "System lädt Software vom Server"
       
  • Schreibe aus der Vogelperspektive
     
  • Das erste oder zweite Wort des Satzes sollte der Aktor sein
     
  • Was immer auch passiert, stelle sicher, daß klar ist, wer den Ball hat
     
• Wähle das Level richtig
   
  • Stelle sicher, daß der Use Case mit dem richtigen Goal Level beschrieben ist (Summary, User Goal, Subfunction)
     
  • Überprüfe die Use Cases, damit immer klar ist, wo der "Sea Level" ist. Führe die Tests für den "Sea Level" durch
     
    • Er wird durch eine Person (oder ein System), an einem Ort, zu einer Zeit (zwischen 2 und 20 Minuten) ausgeführt
       
    • Der Aktor kann glücklich gehen, wenn der Use Case beendet ist
       
    • Der Aktor (wenn es ein Angestellter ist) kann nach einer Lohnerhöhung fragen, wenn er viele davon ausgeführt hat
       
• Wähle das Level richtig
   
  • Ein Use Case hat zwischen 3 und 9 Schritte. Wenn mehr als 9 Schritte vorhanden sind fasse die Schritte zusammen. Achte auf folgende Merkmale
     
    • Hat der gleiche aktor für mehrere Schritte hintereinander den Ball?
       
    • Werden die Bewegungen des Users beschrieben und nicht seine Absichten? Dies ist typisch für Bedienoberflächen
       
    • Wenn zwei Aktoren sehr viel miteinander kommunizieren, versuchen sie nicht ein höheres Ziel zu erreichen?
       
  • Frage warum der Aktor diese Aktion ausführt. Die Antwort die du erhältst ist das nächst höhere Ziel
     
• Halte die Benutzeroberfläche heraus
   
  • Stelle sicher, daß die Schritte die Du beschrieben hast die wahre Absicht des Aktors wiederspiegeln und nicht die Bewegungen des Aktors beim manipulieren der Oberfläche
     
  • Dies gilt nur wenn funktionale Requiments beschrieben werden, man kann Use Cases auch benutzen um die Benutzeroberflächen zu dokumentieren
     
• Jeder Use Case hat zwei Enden: Erfolg und Mißerfolg
   
  • Beachte, daß auch ein Sub Use Case mit Erfolg oder Mißerfolg enden kann
     
  • Taucht der Fehler im Hauptablauf auf, so wird er in den Extensions bhandlet. In der Extension werden Erfolg und Fehlerbehandlung in der gleichen Extension beschrieben
     
• Stakeholder brauchen Garantien
   
  • Ein Use Case beschreibt nicht nur die Interaktionen zwischen dem Primary Actor und dem System. Ein Use Case beschreibt wie das System die Interessen aller Stakeholder schützt, mit dem Primary Actor als treibende Kraft
     
  • Mögliche Stakeholder sind
     
    • der Primary Actor
       
    • der Firmenbesitzer
       
    • gesetzliche Behörden
       
    • der Testingenieur
       
    • der Serviceingenieur
       
• Stakeholder brauchen Garantien
   
  • Das Interesse des Primary Actors wird im Use Case Namen festgehalten. Normalerweise erhält er etwas
     
  • Das Firmeninteresse besteht meistens darin, daß der Primary Actor nicht etwas umsonst erhält, für die Leistung bezahlen muß oder keinen Schaden anrichten kann
     
  • Das Interesse des Gesetzgebers ist meist, daß die Firma zeigen kann, daß sie die Regeln einhält und daß die Transaktionen protokolliert werden
     
  • Eines der typischen Interesse von Stakeholdern ist die Behandlung von Fehlern und das Recovery bei Fehlern innerhalb einer Transaktion
     
• Vorbedingungen
   
  • Die Vorbedingungen eines Use Cases definieren die gültigen Randbedingungen unter denen der Use Case ablaufen kann
     
  • Die Vorbedingungen müssen erwähnt werden, da sie im Use Case nicht mehr abgeprüft werden
     
  • Es gibt zwei gebräuchliche Situationen für solche Vorbedingungen
     
    • Der User ist eingelogged und seine Autorisierung verifiziert
       
    • Ein zweiter Use Case verläßt sich darauf, daß in einem ersten Use Case Randbedingungen geschaffen wurden, auf die sich der zweite Use Case verlassen kann
       
  • Immer wenn man eine Vorbedingung findet, kann man davon ausgehen, daß es einen Use Case auf höherem Level gibt, in dem die Vorbedingung gesichert wurde
     

English version not yet available.