Requirements Engineering Methoden

Ausgelöst von einem Nebensatz in Scott Sehlhorsts (interessante) Artikel-Reihe über Use-Case-Estimation denke ich darüber nach, wie viel Design in meinen Use-Cases steckt.

Der Nebensatz im Artikel bezog sich auf einen Use-Case-Schritt, in dem der Benutzer weiter klickt, und das System die nächste Seite anzeigt. Scott Sehlhorst ist sich mit Alistair Cockburn einig, dass GUI im Use-Case nichts verloren hat.
Ich habe bisher bereits versucht, die Ausprägung der GUI nicht im Use-Case zu beschreiben. Dass der Benutzer "klickt" schließt z. B. aus, dass es ein Tastenkürzel gibt... Wörtliche Bezeichnung von Buttons wie "weiter" sind ebenfalls gefährlich, weil das Wording erst weit nach der Use-Case-Erstellung bestimmt wird - und hier schon im Use-Case vorgegeben wird.

In meinen Use-Cases habe ich die Funktion beschrieben, welche dem Benutzer zur Verfügung steht. Z. B. auch den Seitenwechsel einer Suchergebnisliste. Z. B.:
7. Das System zeigt die Suchergebnisliste an (okok, Ergebnisliste ist hier nicht definiert ;-)
8. Der Benutzer wählt die Anzahl der angezeigten Einträge:

• 10 (default)
• 25
• 50

9. Das System zeigt die entsprechende Zahl von Ergebnissen an.
10. Der Benutzer wechselt auf die nächste Seite.
11. ...

Diese Funktionen sind Anforderungen an die GUI! Insbesondere werden diese Anforderungen im Wireframe beschrieben (siehe Artikel "Wireframes und Use-Cases").

Ein Wireframe beschreibt zwar nur das Vorhandensein eines Dropdowns mit den Einträgen 10 (default), 25 und 50. Anstatt diese Information jedoch in Wireframe und Use-Case redundant zu dokumentieren, würde ich den Wireframe um eine Notiz ergänzen, in welcher der funktionale Zusammenhang des Dropdowns beschrieben ist.