• Anforderungsdefinition laut Robra
• Prozess der Anforderungsdefinition laut Hopf
• Anforderungsermittlung laut Hopf

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