Benutzer-Werkzeuge
se:anforderungsdefinition
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:anforderungsdefinition [2009-01-30 15:23] stefan |
se:anforderungsdefinition [2009-02-12 13:47] stefan |
||
|---|---|---|---|
| Zeile 26: | Zeile 26: | ||
| Schätzung: 4 Punkte | Schätzung: 4 Punkte | ||
| Priorität: 8</code> | Priorität: 8</code> | ||
| + | |||
| + | **nach {[quellen:Goodliffe2008|S. 367]}** | ||
| + | * 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.) | ||
| ===== Probleme von umfangreichen Pflichtenheften ===== | ===== Probleme von umfangreichen Pflichtenheften ===== | ||
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
