**Dies ist eine alte Version des Dokuments!**
Anforderungsdefinition/-ermittlung
nach {[quellen:Bleek2008|S. 35ff.]}
bei agiler Entwicklung sollen möglichst wenig Dokumente erzeugt werden, da diese erfahrungsgemäß schnell an Aktualität verlieren und die Entwicklung nicht mehr unterstützen bzw. sogar behindern (→ falsche/überholte Anforderungen etc.)
grundsätzliche Haltung: so wenig wie möglich aufschreiben → mehr Arbeitszeit für Entwicklung
Anforderungen müssen aber mindestens so genau aufgenommen werden, dass eine
Aufwandsschätzung durch die Entwickler möglich ist, um die Iterationen zu planen
die Entwickler lernen mehr über die Prozesse der Anwender während sie auf Basis der groben Anforderungen und ständiges Nachfragen oder Beobachten entwickeln, als wenn sie lange und meist missverständliche Dokumente lesen müssen
Anforderungen sollten als (User-)Storys erfasst werden, die textuell jeweils eine Anforderung gerade so präzise beschreiben, dass ein Aufwand dafür geschätzt werden kann
die Storys werden vom Kunden aufgeschrieben z.B. nach Feature Driven Development in der Form <Aktion> <Ergebnis> <Objekt>
Achtung: Aktionen wie "Verwalten" reichen nicht aus, da völlig unterschiedliche Dinge darunter verstanden werden können
auch (für den Kunden) selbstverständliche Dinge (z.B. Drucken von Daten etc.) müssen als Story vorliegen, damit nichts verloren geht
in XP wird die Story als Versprechen verstanden, dass der Entwickler sich beim Implementieren der Story noch einmal intensiv mit dem Kunden darüber unterhält und die Details klärt
Storys können gut auf Karteikarten oder Postits untergebracht werden (was auch gleichzeitig deren Länge einschränkt)
Beispiel aus {[quellen:Bleek2008|S. 37]}
Story 142
Für jeden Tag können einem Fahrzeug Aufträge zugewiesen werden.
Autor/Ansprechpartner: Stefan Macke
Schätzung: 4 Punkte
Priorität: 8