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

nach \cite[S. 35ff., S.58f.]{Bleek2008}

• 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.)
• Entwickler müssen vor/bei der konkreten Implementierung im Kontakt mit dem Kunden die aktuellen Details klären → möglichst wenig Zeitverlust zwischen Definition der Details und Implementierung
• grundsätzliche Haltung: so wenig wie möglich aufschreiben → mehr Arbeitszeit für Entwicklung
• nur der Kunde kann die Details definieren, die Entwickler können implementieren aber kennen sich nicht (zwangsläufig) in der fachlichen Domäne aus
• optimal: Vertreter des Kunden oder der Kunde selbst ist bei der Entwicklung vor Ort und steht als direkter Ansprechpartner zur Verfügung (andersherum geht es auch: die Entwickler richten ihren Arbeitsplatz beim Kunden ein)
• die Dokumentation der geklärten Details erfolgt am Besten in Form von Tests und nicht in Dokumenten, dies hat auch gleich einen erheblichen Mehrwert für die Entwicklung und Qualitätssicherung
• kleinere Details, dür die kein Test benötigt wird, können im Quelltext selbst dokumentiert werden (warum wurde genau diese Art der Implementierung gewählt?)
• 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 \cite[S. 37]{Bleek2008}

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

nach \cite[S. 367]{Goodliffe2006}

• Anforderungen an Software müssen möglichst früh erfasst werden, um die Erwartungen auf allen Seiten einzugrenzen, "Feature Creep" zu vermeiden und die Angst der Entwickler zu verringern
• Entwickler sollten nicht anfangen zu programmieren, bevor eine adequate Spezifikation vorliegt, der die Kunden zustimmen
• Design Spezifikationen veralten sehr schnell (Problem der Synchronisation mit dem Code) und sollten daher nicht erstellt werden. Vielmehr sollte der Code sich selbst dokumentieren → API-Doku
• lange Anforderungsdefinitionsphasen sind verschwendete Zeit für die Entwickler, aber ohne Spezifikation sollte man nicht entwickeln → Anforderungen als User Storys erfassen
• Informationen in einer Spezifikation müssen sein:
  • Correct: korrekt und unmissverständlich
  • Comprehensible: jeder Leser muss sie verstehen können, klar definierte Worte verwenden (should, must, may etc.)
  • Complete: nicht alle Informationen müssen drin stehen (→ Referenzen auf andere Dokumente) und das Level der Abstraktion sollte weit über dem des Codes liegen
  • Verifiable: aus der Spezifikation sollten direkt Tests ableitbar sein
  • Modifiable: keine PDF-Dateien usw. da Änderungen meist sehr wahrscheinlich sind
  • Self-describing: drin sein sollten Titelseite, Einleitung, Begriffserklärungen, Referenzen, History
  • Traceable: auch Spezifikationen sollten versioniert werden
• "What is written without effort is in general read without pleasure." [Samuel Johnson]
• "Niemand wird meine Spezifikation je lesen" denken sich viele Entwickler und schreiben keine! Aber wichtiger als das Lesen ist der Prozess, der beim Schreiben im Kopf des Entwicklers vorgeht. Er muss sich nämlich intensiv mit seinem Thema auseinandersetzen, was zu besseren Ergebnissen führt.
• Die Zeit, die man meint einsparen zu können, indem man auf eine Spezifikation verzichtet, wird deutlich von der Zeit übertroffen werden, die man ohne Spezifikation für die Abstimmung von Anforderungen etc. aufbringen muss (→ deutlich ineffektivere Kommunikation, die gleichen Dinge müssen mehrmals erklärt werden etc.)

nach \cite[S. 57f.]{Bleek2008}

• der Kunde kann viele seine Anforderungen gar nicht im Voraus kennen
• veralten schnell und bedeuten hohen (meist nutzlosen) Aktualisierungsaufwand
• bedeuten grundsätzlich einen hohen Erfassungsaufwand, der nicht für die eigentliche Entwicklung verwendet werden kann → Zeitverlust und Kosten für den Kunden ohne sichtbaren Nutzen
• man kann Anforderungen nie gut genug beschreiben, es werden je nach Einschätzung der Kenntnisse des Gegenübers entweder zu viele Details festgehalten oder gar wichtige weggelassen

nach \cite[S. 242]{Goodliffe2006}

• auch die umfangreichste Spezifikation hat Lücken, sonst wäre sie ja Programmcode!

Anforderungen in Form von Beispielfällen zu definieren anstatt in Fließtext hat laut \cite{Rainsberger2007} Vorteile:

• komplexe Regeln sind schwer in Fließtext zu beschreiben und durch den Entwickler zu verstehen
• (scheinbar) einfache Regeln werden durch den Entwickler häufig falsch interpretiert, weil offensichtliche Wörter anders verstanden werden (z.B. Monat → Kalendermonat oder 30-tägiger Monat)
• Beispielfälle (insb. mit Grenzwerten) definieren eindeutig die erwarteten Ergebnisse bei gegebenen Eingangsparametern und lassen keinen Spielraum für (Fehl-)Interpretationen
• Beispielfälle (z.B. in Form von Excel-Tabellen) können direkt in (Unit-)Testfälle übersetzt werden