Requirements Engineering Methoden

Jeff Patton wrote an article about goal levels, that I described in my earlier article Abstraktionsgrad von Anforderungen. He refers to Alistair Cockburn for the description of levels.

What I find an interesting point in Jeff's article is that the same requirement may be on different levels, depending on the context.
He finds two examples, where buying coffee can be either on fish level when I'm ordering a breakfast - or on sea level when I need to get coffee. The other example is looking up an email address for a friend who asks for the address of another friend (sea level) or looking up the same address while sending an email message (fish level).

When designing an email client, you would have to figure out which of the two scenarios is the more likely one. For this one you should write the use case.
It does not make sense to repeat the same use case from the sea level on fish level, obviously.
Still the fish level use case should be a considered scenario when designing the software - otherwise you would lose the possibility to look up an email address without having to write an email message...
I guess, I would try to cope with this in the use case's trigger. Other ideas?

Vor einiger Zeit hatte ich eine interessante Diskussion mit einem Senior-Entwickler.
Muss ein Use-Case "Login" auf Anwenderzielebene aufgeführt werden?

Ich hatte in etwa folgende Use-Cases aufgestellt:


Der Kollege argumentierte, ein für ihn relevanter, weil den Aufwand stark beeinflussener Use-Case fehlt: Login

Auf der einen Seite verbietet es die "reine" Lehre, z. B. nach Alistair Cockburn (z. B. in diesem Artikel) oder gemäß dem Kaffeepausen-Test, Use-Cases auf Systemebene mit denen der Anwenderebene zu mischen.
Mein Entwickler will auf der anderen Seite die wichtigen Kostentreiber auf einen Blick erkennen können.

Heute schreibe ich pragmatisch einen Use-Case "Login", mische die Ebenen und behelfe mir mit der Ausreden, dass ich es bewusst tue.

Bessere Ideen?

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.

Ich habe mal wieder in meinem Lieblings-Use-Case-Buch von Alistair Cockburn, "Writing effective Use Cases" geschmökert und mich über seine Zeichnung der Abstraktionsebenen von Use-Cases gefreut (eine Rohfassung davon gibt es hier in einem lesenswerten Artikel über Use-Cases). Er unterscheidet 5 Abstraktionsebenen von Anforderungen (Use-Cases) und beantwortet die Frage, wie diese Ebenen zusammenhängen.
Tiefere Use-Cases beschreiben, wie ein Use-Case gelöst wird. Use-Cases darüber beantworten, warum der Use-Case benötigt wird.
Durch die Fragen "Wie?" und "Warum?" kann man also Anforderungen unter bzw. über einer gegebenen Anforderung ermitteln.

In den meisten Projekten nutze ich Use-Cases zur Analyse und Spezifikation.

Warum?
Weil sie einfach sind und leicht von Kunden verstanden werden.
Weil das Ziel des Anwenders beschrieben ist - sehr wichtig!
Weil sie funktionale Anforderungen in Applikationen sehr gut abbilden - was den Großteil meiner Projekte ausmacht.
Weil sie für die Analyse genauso funktionieren wie für die Konzeption.

Ich verwende Use-Cases, wie sie Alistair Cockburn beschreibt, siehe z. B. Cockburns Artikel "Use case fundamentals".

Die Szenarien sind einfach und logisch aufgebaut. Durch das Beschreiben des Ablaufs spare ich mir, in jedem Requirement den vollständigen Kontext zu beschreiben.
Eine Auswirkung ist, dass z. B. der ganze Use-Case getestet werden muss und Requirements nicht alleine gültig sind. Hat mir aber noch nie Schwierigkeiten bereitet - im Gegenteil: Der Übergang zur Testspezifikation wird einfacher, da diese sowieso ein Szenario beschreiben muss.

Das Use-Case-Schema gibt einige Formalismen vor, die sicherstellen, dass relevante Informationen auftauchen (insb. Ziel des Use-Cases). Die Formulierung gemäß "Wer macht was" stellt sicher, dass viele Formulierungsfehler nicht passieren können.
Ich kann mich also darauf konzentrieren, die funktionalen Anforderungen zu dokumentieren.

Scott Sehlhorst beschreibt in seinem Blog unter "Communicating Intent With Implementers" den Vorteil, dass die Entwickler das "Warum" einer Funktionalität kennen.
Mindestens genauso wichtig ist es für Frontend-Designer, die Ziele der Benutzer zu kennen und deren typische Arbeitsabläufe - Dinge, die ein Use-Case bereits gut beschreibt.