Writing Use Cases: Avoid IF THEN in use case steps

Checking conditions within a use case step blows out the success scenario. The use case is hard to understand. Instead relocate conditions and their actions to exceptions or alternate flows. When it comes to use cases I often read success scenarios describing lots of conditions. The use case goes like this: Success scenario Step 4: The system does <A>. But in case the actor has selected <option 1> in step 3 then the system checks if <option 2> is selected too. If that is the

Use Cases Teil 1: Nutzerziele und fliegende Fische

Use Cases gehören zum Alltag der IT. Kein größeres Projekt kommt ohne sie aus. Die ganze Welt schreibt Use Cases. Wirklich? Dass ich diesen Artikel schreibe, mag erkennen lassen, dass ich da meine Zweifel habe. Meine These: Viele sogenannte Use Cases sind gar keine. Ich möchte im Folgenden darstellen, wie ich dazu komme. Da das Thema umfangreich ist, teile ich die Betrachtung in zwei Artikel auf: Differenzierung zwischen Nutzerziel und Unterfunktion. Wie beschreibe ich ein Nu

Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem

Im ersten Teil über Use Cases habe ich dargestellt, dass die richtige Differenzierung zwischen Nutzerzielen und Unterfunktionen nicht ganz leicht aber überaus wichtig ist (Use Cases Teil 1: Nutzerziele und fliegende Fische). Erhebt man Unterfunktionen zu vermeintlichen Nutzerzielen, verlieren wir nicht nur den Überblick, das Projektmanagement kann sogar in große Schwierigkeiten geraten. Da uns dies (hoffentlich) nicht mehr vorkommt, stellt sich nun die Frage, wie man denn Nut

Ohne UML in die Word-Falle

Über das Management in der UML-Falle habe ich bereits geschrieben. In dem Artikel habe ich darzustellen versucht, dass es eine große Gefahr birgt, wenn man sich in großen Projekten im Rahmen einer Spezifikation auf die Erstellung von UML-Diagrammen beschränkt und auf detaillierte textliche Erklärungen verzichtet. Man hat zwar schöne Fachklassen- und Use Case Diagramme, die gute Übersichten liefern. Die fachlichen Details – und die sind spätestens für die Entwickler unver

Management in der UML-Falle

Der Titel ist provokant. Das ist mir bewusst. Ich möchte zeigen, dass der unreflektierte Glaube in UML-Modelle zu einem echten Problem im Projekt führen kann. Und das droht besonders bei einem zeitlich engen Projektplan. Also genau dann, wenn man geneigt ist, es bei UML-Diagrammen zu belassen. Der Werkzeugkasten UML Die Unified Modelling Language –kurz UML- ist an sich gar nicht schlecht. Ganz im Gegenteil. Sie fasst verschiedene grafische Werkzeuge und Notationen für die Spe

Storyboards: Eine Erfolgsgeschichte

Was sind Storyboards? Storyboards sind Geschichtenbretter – jedenfalls wörtlich übersetzt. Ok, wir malen die nicht auf Holz. Storyboards beschreiben die Umsetzung eines fachlichen Anwendungsfalls in eine konkrete Software-Benutzeroberfläche. Beschreibt ein Anwendungsfall (Use Case) die rein fachlichen Abläufe (z.B. Anlegen eines Kontos), so beschreibt das entsprechende Storyboard, wie das in der Software-Oberfläche vor sich geht. Herkunft Storyboards verbindet man eher mit de