1 Einleitung

USE Cases können eine gemeinsame Sprache für Entwickler, Endanwender und Fachleuten für den Anwendungsbereiche zur Beschreibung eines Systems sein. Sie sind eine Möglichkeit, das Verhalten eines Systems zu beschreiben und schaffen damit eine Basis für die Requirements und auch abschließende Tests am Ende der Entwicklung. Die Use Cases ergeben aber noch keine vollständige Sammlung der Requirements sondern decken ca. 30% ab.

Use Cases beschreiben nicht die Implementierung. Sie geben das Verhalten des Systems an. Ein Use Case beschreibt eine Folge von Aktionen inklusive von Varianten wie z.B. Fehlerbehandlung, die zu einem nützlichen Ergebnis für einen Benutzer führt.

Use Cases sollte man nicht allein sondern in einer Gruppe erstellen, um damit verschiedenen Sichtweisen und Ideen kombinieren zu können. Wichtig ist es dabei, den richtigen Level (sea level) zu finden. Zu tief unter der Oberfläche verlieren sich die Use Cases in Details, zu hoch in den Wolken bleiben die Use Cases zu oberflächlich. Mit der Frage "warum" kann man den Level heben, mit der Frage "wie" senken. Anschaulich kann man die als Bild mit der Meeresoberfläche (sea level), den Wolken und unter der Oberfläche dem Meeresgrund malen.

Nach der Vorstellung der durch die UML definierten Diagramme bzw. Notationen für Use Cases folgen eine Reihe von Regeln zur Erstellung von Use Cases. Damit soll erreicht werden, daß die Use Cases kurz, prägnant und möglichst exakt die Requirements beschreiben.

English version not yet available.