Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:anforderungsdefinition

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung Beide Seiten der Revision
se:anforderungsdefinition [2009-02-12 13:47]
stefan
se:anforderungsdefinition [2010-05-03 10:47]
127.0.0.1 Externe Bearbeitung
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!
se/anforderungsdefinition.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)