Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
se:anforderungsdefinition [2009-02-12 13:47] stefan |
se:anforderungsdefinition [2014-04-05 11:42] (aktuell) |
||
---|---|---|---|
Zeile 4: | Zeile 4: | ||
* [[softwarequalitaet#anforderungsermittlung|Anforderungsermittlung laut Hopf]] | * [[softwarequalitaet#anforderungsermittlung|Anforderungsermittlung laut Hopf]] | ||
- | **nach {[quellen:Bleek2008|S. 35ff., S.58f.]}** | + | **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.) | * 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 | * 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 | ||
Zeile 20: | Zeile 20: | ||
* 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 | * 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) | * Storys können gut auf Karteikarten oder Postits untergebracht werden (was auch gleichzeitig deren Länge einschränkt) | ||
- | **Beispiel aus {[quellen:Bleek2008|S. 37]}** | + | **Beispiel aus \cite[S. 37]{Bleek2008}** |
<code>Story 142 | <code>Story 142 | ||
Für jeden Tag können einem Fahrzeug Aufträge zugewiesen werden. | Für jeden Tag können einem Fahrzeug Aufträge zugewiesen werden. | ||
Zeile 27: | Zeile 27: | ||
Priorität: 8</code> | Priorität: 8</code> | ||
- | **nach {[quellen:Goodliffe2008|S. 367]}** | + | **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 | * 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 | * Entwickler sollten nicht anfangen zu programmieren, bevor eine adequate Spezifikation vorliegt, der die Kunden zustimmen | ||
Zeile 45: | Zeile 45: | ||
===== Probleme von umfangreichen Pflichtenheften ===== | ===== Probleme von umfangreichen Pflichtenheften ===== | ||
- | **nach {[quellen:Bleek2008|S. 57f.]}** | + | **nach \cite[S. 57f.]{Bleek2008}** |
* der Kunde kann viele seine Anforderungen gar nicht im Voraus kennen | * der Kunde kann viele seine Anforderungen gar nicht im Voraus kennen | ||
* veralten schnell und bedeuten hohen (meist nutzlosen) Aktualisierungsaufwand | * veralten schnell und bedeuten hohen (meist nutzlosen) Aktualisierungsaufwand | ||
Zeile 51: | Zeile 51: | ||
* 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 | * 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 {[quellen:Goodliffe2008|S. 242]}** | + | **nach \cite[S. 242]{Goodliffe2006}** |
* auch die umfangreichste Spezifikation hat Lücken, sonst wäre sie ja Programmcode! | * auch die umfangreichste Spezifikation hat Lücken, sonst wäre sie ja Programmcode! | ||
+ | |||
+ | ===== Anforderungsdefinition durch Beispielfälle ===== | ||
+ | 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 |