Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- se:anforderungsdefinition [2009-01-30 15:23]
stefan
+++ se:anforderungsdefinition [2014-04-05 11:42] (aktuell)
@@ Zeile 4: / Zeile 4: @@
   * [[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.)
   * 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
   * 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
 Für jeden Tag können einem Fahrzeug Aufträge zugewiesen werden.
@@ Zeile 26: / Zeile 26: @@
 Schätzung: 4 Punkte
 Priorität: 8</code>
+**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.)
 ===== 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
   * veralten schnell und bedeuten hohen (meist nutzlosen) Aktualisierungsaufwand
@@ Zeile 34: / 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
-**nach {[quellen:Goodliffe2008|S. 242]}**
+**nach \cite[S. 242]{Goodliffe2006}**
   * 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

Stefans Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge