Benutzer-Werkzeuge
se:anforderungsdefinition
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:anforderungsdefinition [2008-12-27 20:22] stefan |
se:anforderungsdefinition [2009-01-30 15:23] stefan |
||
|---|---|---|---|
| Zeile 4: | Zeile 4: | ||
| * [[softwarequalitaet#anforderungsermittlung|Anforderungsermittlung laut Hopf]] | * [[softwarequalitaet#anforderungsermittlung|Anforderungsermittlung laut Hopf]] | ||
| - | **nach {[quellen:Bleek2008|S. 35ff.]}** | + | **nach {[quellen:Bleek2008|S. 35ff., S.58f.]}** |
| * 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 | ||
| * grundsätzliche Haltung: so wenig wie möglich aufschreiben -> mehr Arbeitszeit für Entwicklung | * 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ätzverfahren|Aufwandsschätzung]] durch die Entwickler möglich ist, um die Iterationen zu planen | * Anforderungen müssen aber mindestens so genau aufgenommen werden, dass eine [[aufwandsschätzverfahren|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 | * 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 | ||
| Zeile 23: | Zeile 28: | ||
| ===== Probleme von umfangreichen Pflichtenheften ===== | ===== Probleme von umfangreichen Pflichtenheften ===== | ||
| + | **nach {[quellen:Bleek2008|S. 57f.]}** | ||
| * 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 | ||
| * 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 | * 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 | * 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]}** | ||
| + | * auch die umfangreichste Spezifikation hat Lücken, sonst wäre sie ja Programmcode! | ||
se/anforderungsdefinition.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
