Ein kontrolliertes Experiment über die Auswirkung von Feedback ...

3 Vorbereitung des Experiments mit der GQM-Methode | 34
dokumentierte Anforderungen bezieht, denn das Dokumentieren von Informationen im
Anforderungserhebungsprozess ist aus vielen Gründen unerlässlich. Seine wesentlichen
Vorteile sind unter anderem Persistenz, eine gemeinsame Informationsbasis und eine
Förderung der Kommunikation und der Objektivität [Poh08, S.217].
Umgekehrt könnten sich Anforderungen in den Notizen des Anforderungsingenieurs
verstecken, über die vielleicht gar nicht gesprochen wurde. Wenn weder der
Anforderungsingenieur noch der Kunde über etwas, dass in einer nachträglichen Durchsicht
der Notizen des Anforderungsingenieurs vielleicht als Anforderung erkennbar ist, kein Wort
gesprochen haben, so soll es hier nicht als dokumentierte Anforderung gelten. Sobald auch
nur einer der beiden etwas darüber gesprochen hat, soll es als dokumentierte Anforderung
gelten. So kann es beispielsweise sein, dass der Kunde beim Skizzieren bestimmte Details der
Oberfläche benennt, ohne dass der Kunde etwas dazu sagt. Es ist dann aber anzunehmen, dass
der Kunde einen Einwand gebracht hätte, wäre er mit der Struktur der Oberfläche so nicht
einverstanden gewesen. Das Schweigen des Kunden wird also als stille Zustimmung gewertet
und die Anforderung wird als solche gewertet.
Es stellt sich die Frage, ob bei der Auszählung der Anforderungen zwischen vom Kunden
angenommenen und abgelehnten Anforderungen unterschieden werden muss. Abgelehnte
Anforderungen stellen jedoch im Umkehrschluss eine angenommene Anforderung da. Wird
der Kunde beispielsweise gefragt, ob die Software eine Onlinefunktion haben soll, und der
Kunde lehnt das ab, dann ergibt sich daraus die Anforderung, dass die Software keine
Onlinefunktion haben soll. Zwischen angenommenen und abgelehnten Anforderungen muss
also nicht unterschieden werden, da abgelehnte Anforderungen Informationen darüber
enthalten, welche Funktion oder Art von Oberfläche die zu entwickelnde Software gerade
nicht haben soll, und stellt somit doch wieder eine angenommene Anforderung dar.
Aus diesen Einschätzungen leitet sich die zweite Hypothese ab:
Der Anforderungsingenieur/ Projektmanager bekommt durch die Verwendung von Fast
Feedback in der Anforderungserhebung mehr Informationen in Form von dokumentierten
Anforderungen als ohne die Verwendung von Fast Feedback, wobei der Anteil der nichtfunktionalen
Anforderungen (gemessen an der Gesamtmenge von dokumentierten
Anforderungen) mehr zunimmt als der Anteil der funktionalen Anforderungen.
Hypothese 2: Anzahl der Anforderungen
3.1.1.3 Hypothese 3 – Benutzbarkeit von Fast Feedback
Die Verwendung von Fast Feedback soll den Anforderungsingenieur bei der
Anforderungserhebung unterstützen. Dazu muss Fast Feedback als Werkzeug ein gewisses
Maß an Benutzbarkeit aufweisen. Würde sich der Anforderungsingenieur durch die
Verwendung von Fast Feedback mehr blockiert oder gestört als unterstützt fühlen, so könnte
das auch die vom Einsatz des Werkzeugs erwarteten Effekte zunichte machen und den
gesamten Anforderungserhebungsprozess negativ beeinflussen. Deshalb muss für die
Bewertung des Einsatzes eines solchen Werkzeuges auf jeden Fall die Benutzbarkeit
untersucht werden. Für den Fall einer schlechten Benutzbarkeit hätte das Einfluss auf die
Gültigkeit der Ergebnisse aus Hypothesen 1 und 2. Um einen Vergleichspunkt zu haben, soll
die Benutzbarkeit von Fast Feedback mit der von Word verglichen werden. Word wurde aus