Samstag, 12. August 2006
Thema: Use-Cases
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.
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.
... kommentieren