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

Gottfried Wilhelm
Leibniz Universität Hannover
Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik
Fachgebiet Software Engineering
Ein kontrolliertes Experiment über die Auswirkung von
Feedback-Werkzeugen auf die Anforderungserhebung
Diplomarbeit
im Studiengang Mathematik mit Studienrichtung Informatik
von
Melanie Hennemann
Prüfer: Prof. Dr. Kurt Schneider
Zweitprüfer: Prof. Dr. Ludwig Baringhaus
Betreuer: M. Sc. Kai Stapel
Hannover, 9. Mai 2010

Erklärung
Hiermit versichere ich, die vorliegende Diplomarbeit selbstständig und ohne
fremde Hilfe verfasst und keine anderen als die angegebenen Quellen und
Hilfsmittel verwendet zu haben. Die Arbeit hat in gleicher oder ähnlicher Form
noch keinem anderen Prüfungsamt vorgelegen.
Hannover, den 10. Mai 2010 ___________________
Melanie Hennemann
| 2

Danksagung
An dieser Stelle möchte ich mich bei allen Personen herzlich bedanken, die
mich bei der Erstellung dieser Arbeit unterstützt haben.
Besonderer Dank gilt Prof. Dr. Kurt Schneider für die Vergabe und Betreuung
meiner Diplomarbeit. Ich danke auch Prof. Dr. Ludwig Baringhaus für die
Geduld und Hilfestellung bei der Beantwortung von mathematischen Fragen.
Bei M. Sc. Kai Stapel möchte ich mich für die hervorragende Unterstützung
über den ganzen Zeitraum meiner Diplomarbeit bedanken.
| 3

Inhaltsverzeichnis
1 Einleitung ................................................................................................................................6
1.1 Motivation ........................................................................................................................6
1.2 Ziele dieser Arbeit ............................................................................................................6
1.3 Aufgabenstellung..............................................................................................................6
1.4 Vorgehensweise und Gliederung......................................................................................7
2 Grundlagen ..............................................................................................................................8
2.1 Softwaretechnische Grundlagen.......................................................................................8
2.1.1 Die Anforderungserhebung in der Softwareentwicklung..........................................8
2.1.2 Beschreibung der Werkzeuge..................................................................................10
2.1.3 Die GQM-Methode .................................................................................................14
2.2 Statistische Grundlagen..................................................................................................15
2.2.1 Grundbegriffe ..........................................................................................................15
2.2.2 Statistische Tests .....................................................................................................18
2.2.3 Bestimmung der Stichprobengröße .........................................................................20
2.2.4 Zufällige Auswahl, Randomisation.........................................................................22
2.2.5 Messfehler und Ausreißer........................................................................................23
2.2.6 Korrelation von Merkmalen ....................................................................................24
2.2.7 Skalenniveau............................................................................................................25
2.3 Allgemeine Grundlagen..................................................................................................25
2.3.1 Das Experiment .......................................................................................................25
2.3.2 Exkurs: Experimentdesign.......................................................................................26
2.3.3 Fragebögen als Hilfsmittel zur Datenerhebung.......................................................27
3 Vorbereitung des Experiments mit der GQM-Methode........................................................28
3.1 Vorstudie ........................................................................................................................28
3.1.1 Herausarbeitung der Hypothesen ............................................................................28
3.1.2 Einschränkungen auf das Experiment .....................................................................36
3.2 Ziele und GQM-Modell..................................................................................................38
3.2.1 Konkretisierung der Ziele und Hypothesen mit Hilfe von Abstraction Sheets .......38
3.2.2 GQM-Modell - Ziele, Fragen, Metriken..................................................................42
3.3 Mögliche Einflüsse auf die Gültigkeit der Ergebnisse (Störvariablen)..........................44
3.4 Sonstige Vorbereitungen ................................................................................................46
| 4

3.4.1 Probandensuche.......................................................................................................46
3.4.2 Software und Technik..............................................................................................46
3.5 Messplan.........................................................................................................................46
3.5.1 Schritte vor der Messung.........................................................................................46
3.5.2 Schritte während der Messung ................................................................................53
3.6 Vorgehensweise im Experiment – Prüflisten, Softwarebeispiel, Drehbuch...................53
4 Durchführung des Experiments.............................................................................................57
4.1 Probanden.......................................................................................................................57
4.2 Zusammenfassung des Experimentablaufs.....................................................................60
4.3 Was hat geklappt und wo kann verbessert werden.........................................................60
5 Datensammlung und Validierung..........................................................................................62
5.1 Messergebnisse aus dem universitären Umfeld .............................................................62
5.1.1 Messergebnisse zu den GQM-Zielen ......................................................................62
5.1.2 Messergebnisse außerhalb von GQM......................................................................74
6 Analyse und Interpretation ....................................................................................................77
6.1 Analyse und Interpretation der Ergebnisse aus dem universitären Umfeld ...................77
6.2 Ergebnisaufbereitung durch Bewertung der Gültigkeit..................................................80
6.2.1 Bewertung der Schlussfolgerungen.........................................................................80
6.2.2 Bewertung des Konstrukts.......................................................................................81
6.2.3 Bewertung der internen Validität ............................................................................82
6.2.4 Externe Validität......................................................................................................84
6.3 Ergebnisse aus dem industriellen Umfeld ......................................................................84
6.4 Fazit und Ausblick..........................................................................................................90
7 Anhang ..................................................................................................................................92
Quantile der Normalverteilung.............................................................................................92
Quantile der t-Verteilung......................................................................................................92
Kritische Werte des Grubbs-Tests........................................................................................93
Abbildungsverzeichnis .............................................................................................................94
Tabellenverzeichnis..................................................................................................................95
Quellenverzeichnis ...................................................................................................................96
| 5

1 Einleitung | 6
1 Einleitung
1.1 Motivation
Im Software Engineering und insbesondere bei der Anforderungserhebung werden häufig
spezialisierte Werkzeuge eingesetzt, um die Beteiligten dabei zu unterstützen, die
Anforderungen an das zu entwickelnde System früher, vollständiger und korrekter zu
formulieren. In der Anforderungserhebung wird mit dem Austausch von Wissen und
Informationen zwischen den Beteiligten der Grundstein für den weiteren Verlauf des
Softwareprojektes gelegt. Ob die Erwartungen des Kunden erfüllt werden können, hängt also
ganz entschieden davon ab, ob die Anforderungen an das System genau den Vorstellungen
des Kunden entsprechen. Abweichungen können schwerwiegende Folgen für das ganze
Softwareprojekt haben. Die Umsetzung später erhobener Anforderungen oder die Änderung
von Anforderungen können kostenintensiv werden oder das Softwareprojekt soweit
hinauszögern, dass der Kunde das Interesse an dem Produkt verliert. Der Einsatz eines den
Anforderungsprozess unterstützenden Werkzeugs verspricht dem vorzubeugen, indem dem
Entwickler strukturierte Vorgehensweisen und Hinweise zur Verfügung gestellt werden, mit
denen er systematisch durch den Anforderungserhebungsprozess geleitet wird. Um
abschätzen zu können, ob diese Werkzeuge tatsächlich einen entsprechend nützlichen Effekt
bewirken oder ob die gleichen Ergebnisse auch ohne den Einsatz eines solchen Werkzeugs
hätten erzielt werden können, gilt es, in dieser Arbeit an einem konkreten Beispiel zu zeigen.
1.2 Ziele dieser Arbeit
Das übergeordnete Ziel dieser Arbeit soll sein, die Wirkung eines den Anforderungsprozess
unterstützenden Werkzeugs mit Hilfe eines empirischen Experiments zu untersuchen. Dabei
sollen Erkenntnisse darüber gewonnen werden, ob die gleichen oder vielleicht sogar bessere
Ergebnisse auch ohne das Werkzeug hätten erzielt werden können. Konkret soll das
Werkzeug Fast Feedback evaluiert werden, das die Einsparung von Terminen zwischen
Entwickler und Kunde aber trotzdem auch die Erhebung von mehr Anforderungen in einem
gleichen Zeitraum verspricht. Dabei soll ein Eindruck davon vermittelt werden, bei welchen
Kriterien der Anforderungserhebung Unterstützung in Form des Werkzeugs Fast Feedback
hilfreich ist und in welchen eher nicht. Dazu ist es natürlich sinnvoll, in den Grundlagen zu
dieser Arbeit genau aufzuzeigen, welche Umstände in der Anforderungserhebung zu welchen
Folgen im Projektverlauf führen könnten, die Verbesserungsaussichten durch Fast Feedback
darzustellen und daraus die genauen Hypothesen zu entwickeln.
1.3 Aufgabenstellung
Es stehen zwei konkrete Werkzeuge zur Durchführung der Arbeit zur Verfügung. Dabei
handelt es sich um „Fast Feedback“ und „Vision Catcher“.
Zu mindestens einem Werkzeug soll ein empirisches Experiment systematisch vorbereitet,
durchgeführt und ausgewertet werden. Dazu gehören:
• die Formulierung von fokussierten Fragestellungen und Hypothesen,

1 Einleitung | 7
• die Planung des Experiments unter der Berücksichtigung statistischer Rahmenbedingungen
für aussagekräftige Auswertungen,
• die Bestimmung geeigneter Probanden und die Mitwirkung bei deren Anwerbung und
Einweisung in das Experiment,
• die Durchführung und systematische Beobachtung der eigentlichen Experimente,
• die Auswertung der Resultate mit Hilfe der mathematischen Werkzeuge aus der Statistik,
• das Angeben von Gültigkeitskriterien und deren Interpretation in Bezug auf die
Hypothesen, Forschungsfragen und gegebenenfalls ungeplanten Beobachtungen.
Um statistisch signifikante Aussagen treffen zu können, sind in der Regel relativ große
Probandenzahlen erforderlich, die nur schwer erreicht werden können. Daher ist es sinnvoll,
zunächst einen Richtwert für den Umfang der Stichprobe mit Hilfsmitteln der Mathematik zu
ermitteln. Zudem gibt es zahlreiche Fallstricke und Fehlerquellen, die einer belastbaren
Interpretation der Beobachtungen im Wege stehen könnten. Diese können durch eine korrekte
Anwendung der Statistik im Rahmen der Möglichkeiten eingeschränkt werden.
Neben der eigentlichen Evaluierung von ein oder zwei Werkzeugen ist die Dokumentation der
Vorgehensweise eine wesentliche Leistung dieser Diplomarbeit. Insbesondere soll die
Planung auch Erfahrungen gegenübergestellt werden, die im Verlauf der Evaluierung
gemacht werden.
1.4 Vorgehensweise und Gliederung
Zunächst muss entschieden werden, mit der Evaluierung welchen Werkzeugs im Rahmen
dieser Arbeit begonnen wird. Dazu wird im zweiten Kapitel dieser Arbeit auf die
Anforderungserhebung in der Softwareentwicklung eingegangen und darauf basierend die
Wahl des zu evaluierenden Werkzeugs begründet. Das gewählte Werkzeug wird dann
ausführlich und zielorientiert vorgestellt. Im Anschluss daran werden die Grundlagen für die
Durchführung eines Experiments geliefert. Sie stammen sowohl aus dem Bereich der
Informatik als auch aus dem Bereich der Mathematik.
Im dritten Kapitel geht es dann um die Vorbereitung des Experiments. Es werden
Einschränkungen angegeben, die in Bezug auf das durchzuführende Experiment zu machen
sind. Außerdem enthält die Vorbereitung des Experiments die Ausarbeitung der Hypothesen,
die systematische Herleitung aller Entscheidungen bzgl. der Experimentdurchführung, eine
Übersicht möglicher Einflüsse auf die Ergebnisse und Hinweise zur Durchführung der
Auswertung.
Im Anschluss wird im vierten Kapitel die Durchführung des Experiments genau dokumentiert
und die Ergebnisse werden übersichtlich dargestellt, bevor sie im fünften Kapitel analysiert
und interpretiert werden. Die Interpretation enthält die Beurteilung anhand von
Gültigkeitskriterien. Das Kapitel schließt ab mit einem Fazit, in dem auch mögliche
Verbesserungsvorschläge für zukünftige Experimente dieser Art gegeben werden, und
Aussichten auf möglicherweise weiterführende Projekte.

2 Grundlagen | 8
2 Grundlagen
2.1 Softwaretechnische Grundlagen
2.1.1 Die Anforderungserhebung in der Softwareentwicklung
In der konventionellen Softwareentwicklung, nach der sich viele Entwicklungsfirmen richten,
werden die verschiedenen Projektphasen nach einer festen Abfolge durchlaufen. Als Beispiel
sei hier das Wasserfallmodell genannt, bei dem die Projektphasen in der vorgegebenen
Reihenfolge durchlaufen werden sollen und die Ergebnisse jeder Phase als Grundlage für die
darauffolgende Phase dienen (vgl. Abb.1).
Abbildung 1: Wasserfallmodell [Schn05] nach [Roy70]
Dabei steht die Anforderungserhebungsphase vorne im Entwicklungsprozess und legt so den
Grundstein für die weitere Entwicklerarbeit. „Die für das Projekt ermittelten Anforderungen
werden in einer Anforderungsspezifikation festgeschrieben. Diese dient als Referenzdokument
für die folgenden Entwicklungsphasen.“ [Poh08, S.31] Die Anforderungen an die zu
entwickelnde Software sollten weitestgehend im Voraus und möglichst korrekt festgelegt
werden. Nachträgliche Änderungen oder Ergänzungen der Anforderungen sind in der
konventionellen Softwareentwicklung in der Regel nicht vorgesehen. Sie würden einen
erneuten Durchlauf aller auf die Anforderungserhebung folgenden Phasen bedeuten und damit
zusätzliche Kosten und einen deutlich höheren Zeitaufwand erzeugen. Im Wesentlichen liefe
das darauf hinaus, dass die Wünsche des Kunden oder auch anderer Stakeholder nicht
zufriedenstellend umgesetzt würden. Deshalb ist es umso wichtiger, dass die erhobenen
Anforderungen von vornherein möglichst genau den Vorstellungen des Kunden entsprechen
und möglichst fehlerfrei dokumentiert werden. Da aber, wie im Beispiel des
Wasserfallmodells, in der konventionellen Softwareentwicklung in den ersten drei
Projektphasen auch keine Erstellung von Prototypen vorgesehen ist, ist es schwierig, die
(insbesondere die Bedienoberfläche betreffenden) Anforderungen an das System mit dem
Kunden abzustimmen und die erreichte Qualität der dokumentierten Anforderungen
(beispielsweise ihre Korrektheit) zu überprüfen. Unterstützung in Form eines Werkzeugs
wäre also in der konventionellen Softwareentwicklung insofern sinnvoll, als dass

2 Grundlagen | 9
Anforderungen spezifizierter erhoben und ihre Qualität durch die Erstellung früherer
Prototypen abgesichert werden könnten.
„Verschiedene Studien der Standish Group nennen unzureichendes Requirements
Engineering als eine der wichtigsten Ursachen für das Scheitern von Projekten“ [Poh08, S.8]
Dabei stehen als Ursache die mangelnde Einbeziehung der Benutzer, unvollständige
Anforderungen und Änderungen von Anforderungen an vorderster Stelle. [Poh08, S.9] In der
Anforderungserhebung sollen aus Kundenbedürfnissen Anforderungen an die Software
abgeleitet werden. Wenn die Anforderungen nicht richtig erhoben werden, kann das
Folgefehler im Entwurf und in der Implementierung nach sich ziehen, die letztendlich zu
höheren Kosten und der Unzufriedenheit des Kunden führen können. Eine Anforderung an
die Software beschreibt dabei eine gewünschte funktionale oder qualitätsbezogene
Eigenschaft der Software aus Kundensicht. Die Aufgabe des Entwicklers ist es, den Kunden
von Anfang an konsequent in die Entwicklung einzubeziehen und ihm zu helfen, seine
Wünsche klarzumachen, und Fehlern durch systematisches und sorgfältiges Vorgehen
vorzubeugen. Die Verfahrensweise in der Anforderungserhebung ist ausschlaggebend für den
Projekterfolg.
Ohne Einsatz eines Werkzeugs ist der Anforderungsingenieur frei, verschiedene
Anforderungserhebungsmethoden wie zum Beispiel das Erstellen von Use Cases zu
verwenden. Oft wird aber eher nach dem Prinzip „einfach mal anfangen“ gearbeitet. Doch
genau dieses inkonsequente Vorgehen führt zu fehlerhaften Anforderungen, aus denen
wiederum resultiert, dass die Software am Ende zum Beispiel fehlerhaft ist oder insgesamt zu
spät fertig wird. Werkzeuge zur Unterstützung der Anforderungserhebung basieren oft auf
schon bekannten Methoden und automatisieren das entsprechende gezielte Vorgehen der
Methode. Im Prinzip ist aber der Anforderungsingenieur bei der Entscheidung, ob ein Einsatz
eines zur Unterstützung der Anforderungserhebung entwickeltem Werkzeug in seinem
konkreten Projekt sinnvoll ist, auf Erfahrungsberichte angewiesen. Das macht es umso
interessanter, ein entsprechendes Experiment durchzuführen und anhand dessen eine Aussage
darüber zu treffen, in welchen Fällen und in welchem Maße die Verwendung eines
Werkzeugs nützlich sein kann.
In der Softwareentwicklung nimmt die Anforderungserhebung meist mehrere Termine in
Anspruch. Im ersten Termin stellt der Kunde vor, um was für eine zu entwickelnde Software
es sich handelt. Der Anforderungsingenieur fragt erste Anforderungen an die Software ab und
notiert sie sich grob. Meistens muss sich der Anforderungsingenieur im Anschluss an das
erste Kundengespräch erst noch intensiver in den Kontext der zu entwickelnden Software
einarbeiten, bevor er dann mit den ersten Plänen zur Umsetzung in das zweite
Kundengespräch gehen kann. Im zweiten Kundengespräch stellt der Anforderungsingenieur
seine Ideen vor und der Kunde gibt sein Feedback ab. Aus diesem Austausch von Ideen und
Rückmeldungen entstehen dann meist noch neue Anforderungen, die sich der
Anforderungsingenieur zur erneuten Bearbeitung wieder notiert. Nach dem zweiten Gespräch
nimmt der Anforderungsingenieur gegebenenfalls die vom Kunden gewünschten Änderungen
seiner Pläne vor und lässt auch die neu erhobenen Anforderungen noch einfließen. In einem
dritten Gespräch werden die dokumentierten Ergebnisse erneut besprochen und validiert. Je
nach dem, wie genau der Anforderungsingenieur den Kunden versteht bzw. seine Wünsche
umzusetzen weiß, können auch noch weitere Termine notwendig sein. Da sowohl der
Anforderungsingenieur als auch gerade der Kunde mit großer Wahrscheinlichkeit noch andere
berufliche Termine wahrzunehmen haben, kann zwischen den Kundengesprächen auch schon
mal eine etwas längere Zeit verstreichen. Die wenigen Termine, die für die

2 Grundlagen | 10
Anforderungserhebung vorgesehen sind, können so letztendlich doch mehrere Wochen
Projektzeit in Anspruch nehmen.
Zusammengefasst besteht also ein Interesse daran, die folgenden Aspekte der
Anforderungserhebung zu verbessern:
1. Vermeidung von Fehlern bei der Dokumentation von Anforderungen, um späte und damit
teure Änderungen zu vermeiden und um die Kundenwünsche bestmöglich umsetzen zu
können.
2. Reduzierung der Termine bis zur Vervollständigung der Anforderungserhebung, um die
Anforderungserhebungsphase zu verkürzen.
2.1.2 Beschreibung der Werkzeuge
In diesem Kapitel soll es darum gehen, aus den zwei zur Verfügung stehenden Werkzeugen
Vision Catcher und Fast Feedback das in Bezug auf die zwei oben genannten Aspekte
zweckdienlichere auszuwählen. Um die Wahl tiefer gehend begründen zu können, folgt hier
eine Beschreibung der Funktionsweisen beider Werkzeuge.
2.1.2.1 Vision Catcher
Der Vision Catcher wurde im Rahmen der Masterarbeit von Ingo Kitzmann entwickelt (vgl.
[Kit09]). Mit dem Vision Catcher können Entwickler und Kunde gemeinsam Szenarien
erstellen und linear ablaufen lassen. Ziel ist es, vom Kunden unmittelbar Rückmeldung zu den
Szenarien zu bekommen und sich diese bestätigen zu lassen. Dafür werden die Bilder der
einzelnen Schritte chronologisch miteinander verbunden. Es können verschiedene Versionen
eines Schrittes erfasst werden. Dazu werden einem Schritt mehrere Artefakte zugeordnet, von
denen nur das als „aktiv“ markierte Artefakt beim Abspielen des Films gezeigt wird. Alle
Artefakte werden in einer Bibliothek angelegt, so dass sie auch für folgende Projekte wieder
zur Verfügung stehen. Die Zuordnung von Schlagwörtern erleichtert dabei die Suche nach
Artefakten. Als Artefakte werden Video-, Bild- und Audiodateien unterstützt. Zusätzlich
können Skizzen direkt in Vision Catcher angefertigt werden.
Werden bei der Dokumentation von Anforderungen in Form von Szenarien verschiedene
Versionen eines Schrittes erfasst und unterschiedliche Medien miteinander verknüpft, können
dem Kunden ebenso viele verschiedene Möglichkeiten der Umsetzung und genauso andere
Sichten auf die Anforderungen aufgezeigt werden. So entstehen oft noch während des
Anforderungsinterviews weitere oder sogar innovative Anforderungen, die sonst vielleicht
erst in der Entwicklungsphase oder gar nicht ermittelt worden wären.
Die Anforderungen des Kunden, die nicht das aktuelle Szenario betreffen, können ebenfalls
mit dem Vision Catcher dokumentiert werden. Dafür steht ein Protokollant in Form eines
Audiomitschnitts bereit, der jeweils die letzten zehn Minuten des Gespräches in einem Puffer
zwischenspeichert. Der Anforderungsingenieur kann jeweils entscheiden, ob gespeichert oder
verworfen werden soll. Die Audioaufzeichnung kann dann im Anschluss an das Gespräch
ausgewertet werden. Des Weiteren können Anforderungen, die unerwünschte Zustände
beschreiben, festgehalten werden, indem sie nicht einfach nur durch die stattdessen
gewünschten sondern durch selbstbeschreibende Szenarien dargestellt und anschließend als

2 Grundlagen | 11
unerwünscht gekennzeichnet werden können. So gehen keine wichtigen Informationen des
Kunden verloren.
Da mit diesem Werkzeug zwei Personen zusammen an Szenarien und Skizzen arbeiten
können, verspricht seine Verwendung eine sehr effektive Kommunikation. Die
„Kommunikationstheorie (z.B. [Coc02]) zeigt [nämlich], dass mit der Reichhaltigkeit des
Mediums die Effektivität der Kommunikation zunimmt“ [Kit09] und der Vision Catcher ist in
dieser Theorie in der Nähe von „2 People at White Board“, das heißt im Bereich einer sehr
effektiven Art der Kommunikation einzuordnen (vgl. Abb.2).
2.1.2.2 Fast Feedback
Abbildung 2: Effektivität verschiedener Kommunikationsformen [Coc02]
Fast Feedback ist eine Software, die auf Use Cases basiert und helfen soll, die Anforderungen
an die zu entwickelnde Software systematisch zu ermitteln. Mit Use Cases können die
Beschreibungen für die wichtigsten oder sogar alle möglichen Szenarios, die bei der
Benutzung der Software denkbar sind, zusammengefasst werden. Ein Use Case sollte
genügend Informationen über das Ziel der zu beschreibenden Handlung, die
Rahmenbedingungen, die einzelnen Schritte des Szenarios und mögliche
Fallunterscheidungen oder Problemfälle enthalten. Zusätzlich können in Fast Feedback aber
auch weitere Angaben zum Beispiel darüber gemacht, welche Technologie für die Umsetzung
des betreffenden Use Cases erforderlich ist. Je nach Granularität der Use Cases wird so ein
Überblick über das System gegeben, die Wechselbeziehung zwischen Benutzer und Software
dargestellt oder jeder Ablauf im Detail beschrieben. Use Cases eignen sich sehr gut für die
Anforderungserhebung, da sie relativ einfach zu schreiben und mit dem Kunden abzustimmen
sind. In Abb.3 ist die Oberfläche von Fast Feedback dargestellt. Die linke Hälfte zeigt den
Use Case „Geld abheben“ und die rechte Seite ein Mock-up zum vierten Use Case Schritt.

2 Grundlagen | 12
Abbildung 3: Fast Feedback mit Use Case und Mock Up zum Beispiel "Geldautomat"
Use Cases können dafür eingesetzt werden, funktionale Anforderungen und Prozesse der zu
entwickelnden Software zu beschreiben. Allerdings sagen Use Cases erstmal nichts über
nicht-funktionale Anforderungen aus. In Fast Feedback können die Use Cases nun durch
beliebig viele Mock-ups ergänzt werden. Mock-ups bestehen aus Skizzen der zu
entwickelnden Bedienoberfläche und stellen erste Versuche eines Demonstrations-Prototyps 1
dar. Mit Hilfe der Mock-ups können auch nicht-funktionale Anforderungen mit dem Kunden
abgestimmt und dokumentiert werden. Zum Beispiel lässt sich mit ihnen problemlos die
grobe Struktur der Bedienelemente darstellen. Zur Unterscheidung von funktionalen und
nicht-funktionalen Anforderungen vgl. auch Kapitel 3.1.1.2.
Natürlich ließen sich Use Cases in Verbindung mit Mock-ups auch ohne das Werkzeug Fast
Feedback in der Anforderungserhebung anwenden. Aber Fast Feedback bietet darüber hinaus
die Möglichkeit, die Mock-ups den entsprechenden Schritten der Use Cases zuzuweisen. In
der Abb.2 wurde im Beispiel „Geldautomat“ Mock-up 3 dem vierten Schritt des Use Cases
„Geld abheben“ zugeordnet. Werden dann noch die Use Cases in der richtigen Reihenfolge
miteinander verknüpft, lassen sich die Mock-ups anhand der Use Cases zeitlich geordnet
wiedergeben. Das gibt dem Anforderungsingenieur die Möglichkeit, dem Kunden sehr präzise
einen Eindruck davon zu vermitteln, wie die Software aufgebaut sein bzw. wie der Ablauf
einer konkreten zielorientierten Handlung mit der Software aussehen könnte.
Fast Feedback vereint also zunächst einmal die beiden bekannten Methoden der Use Cases
und Mock-ups miteinander und stellt zusätzliche Funktionen zur Verfügung, mit denen die
Methoden verknüpft werden können. Fast Feedback bindet den Anforderungsingenieur an die
Methoden und fördert dadurch ein systematisches zielgerichtetes Vorgehen. Die
1 Demonstrations-Prototyp: Die Maskenfolge und der Bildschirmaufbau werden dargestellt, die suggerierte
Funktion dahinter aber nicht. Diese Art Prototyp findet Verwendung, wenn das Aussehen der Software nach
außen relevant ist. [Schn09, S.178]

2 Grundlagen | 13
Anforderungen werden anhand von konkreten die zu entwickelnde Software betreffenden
Szenarios erhoben. Dabei können alle denkbaren Szenarios und die zugehörigen
Anforderungen durchgedacht werden. Durch die oben beschriebenen und die beiden
wesentlichen Methoden Use Cases und Mock-ups ergänzenden Funktionen können der
Anforderungsingenieur und der Kunde kontinuierlich bereits Vereinbartes immer wieder
prüfen und so zum Beispiel fehlerhafte Anforderungen aufdecken.
Die Art der Kommunikation wie sie bei der Verwendung von Fast Feedback entsteht ist wie
die des Vision Catchers in einem sehr effektivem Bereich, das heißt in der Nähe von „2
People at White Board“, anzuordnen (vgl. Abb.2).
Eine ausführliche Beschreibung des Werkzeugs bietet auch „Generating Fast Feedback in
Requirements Elicitation“ [Schn07b].
2.1.2.3 Zusammenfassung und Entscheidung
Die vorgestellten Werkzeuge scheinen im Hinblick darauf, die Aspekte „Vermeidung von
Fehlern bei der Dokumentation von Anforderungen“ und „Reduzierung der Interviewtermine
bis zur Vervollständigung der Anforderungserhebung“ zu überprüfen, beide eine
entsprechende Verbesserung erwarten zu lassen. Sie bieten dem Anforderungsingenieur die
Möglichkeit, die Anforderungen des Kunden erst gemeinsam mit ihm zu erarbeiten, sie dann
zu dokumentieren und anschließend auch schon zu validieren. Der Vision Catcher gibt dafür
die Möglichkeit, Szenarien verschiedener Medienarten zu modellieren, und Fast Feedback
bietet das Erstellen und Verknüpfen von Use Cases und Mock-ups. Alle diese Funktionen
laufen letztendlich darauf hinaus, mit Hilfe von anschaulichem Material schon früh ein
Feedback vom Kunden zu erhalten. Einerseits können nämlich so Anforderungen anhand von
Demonstrations-Prototypen diskutiert und dadurch Fehler vermieden werden und andererseits
können in kürzerer Zeit die gleiche Menge an Anforderungen erhoben und somit die Anzahl
der Termine für Anforderungsinterviews reduziert werden. Die Art der Kommunikation ist
mit beiden Werkzeugen sehr effektiv.
Obwohl die beiden Werkzeuge sich so ähnlich sind, sollen im Rahmen dieser Arbeit nur die
Auswirkungen der Verwendung von Fast Feedback untersucht werden. Ausschlaggebend für
die Entscheidung ist die für den Einsatz des jeweiligen Werkzeugs notwendige Vorbereitung.
Der Unterschied zwischen den beiden Werkzeugen liegt nämlich im Umfang der
Vorbereitung. Beim Vision Catcher muss zum Füllen der Bibliothek zunächst einmal ein
relativ großer Aufwand betrieben werden. Der Anforderungsingenieur muss sich einen
Überblick über das gewünschte System verschaffen, Fotos und/oder Videos dem vom Kunden
geforderten System entsprechend erstellen und sie in die Bibliothek einpflegen. Aber auch
dann kann der Anforderungsingenieur im Vorfeld nicht sicher sein, alle für den Aufbau der
Szenarien notwendigen Artefakte berücksichtigt zu haben. Mit großer Wahrscheinlichkeit
müssen dann doch weitere Interviews zur Validierung der Anforderungen und zur Vorstellung
des Demonstrations-Prototyps einkalkuliert werden und die erwartete Einsparung an
Interviews kommt doch nicht zustande. Dagegen kann man Fast Feedback sofort ohne
vorheriges Einpflegen von Daten im Anforderungsinterview verwenden. Natürlich muss der
Anforderungsingenieur über ausreichend Kenntnis im Bereich Use Cases und Mock-ups
verfügen, allerdings sind sie auch ohne die Verwendung von Werkzeugen gebräuchliche
Methoden in der Anforderungserhebung, so dass sie in der Regel schon zum Handwerkszeug
eines Anforderungsingenieurs gehören. Durch den Aufbau von Fast Feedback wird der
Anforderungsingenieur zudem auch immer wieder an die Strukturen von Use Cases und

2 Grundlagen | 14
Mock-ups erinnert. Insgesamt lässt also Fast Feedback größere Effekte in Bezug die
Verbesserung der Anforderungserhebung erwarten und soll deshalb evaluiert werden.
2.1.3 Die GQM-Methode
Im Folgenden sei die Vorgehensweise mit der GQM-Methode beschrieben, mit welcher das
Experiment systematisch vorbereitet wurde.
GQM steht für Goal-Question-Metric. Diese Methode dient dazu, systematisch aus Zielen
geeignete Metriken zu bestimmen. „Die Grundidee von GQM ist […]: Man soll nicht das
messen, was leicht zu messen ist, sondern das, was man braucht, um seine Verbesserungsziele
zu erreichen“ [Schn07a, S.69].
Dazu definiert man zuerst die eigenen Ziele (Goal), zu denen man dann „Fragen [(Question)]
formuliert und Metriken [(Metric)] sucht oder definiert, mit denen man die Fragen
beantworten kann“ [Schn07a, S.69]. Aus dem entstandenen Ziel- bzw. GQM-Baum wird ein
Messplan entwickelt, der genau vorgibt, wer wie welche Messungen durchführt. Darauf folgt
die eigentliche Messung, nach der man dann die Ergebnisse „rückwärts einsetzt und so von
den Metriken bis zu den Zielen verfolgt“ [Schn07a, S.70]. Das Resultat sind Antworten auf
die vor der Messung gestellten Fragen.
Bei der folgenden Durchführung des Experiments wird wie in Abb.3 dargestellt vorgegangen.
Abbildung 3: Basilis Goal-Question-Paradigm zur iterativen Verbesserung [Schn07a, S.70]
In einer Vorstudie sollen die Hypothesen mit Hilfe von Abstraction Sheets entwickelt und
mögliche Einflüsse überdacht werden. Aus den Hypothesen sollen dann die konkreten Ziele
formuliert, zu den Zielen Fragen gestellt und letztendlich Metriken entwickelt werden, mit
denen dann der Messplan aufgestellt werden kann. Die Daten des Experiments können dann
gesammelt und validiert werden, um sie anschließend zu analysieren und die Ergebnisse zu
interpretieren. Am Ende soll die Gültigkeit der Ergebnisse unter Einbeziehen der möglichen
Einflüsse diskutiert werden.

€
€
2 Grundlagen | 15
2.2 Statistische Grundlagen
Statistische Verfahren werden in Experimenten dazu verwendet, um beispielsweise den Wert
unbekannter quantitativer Größen zu schätzen oder um eine Aussage auf Gültigkeit hin zu
überprüfen. Die für diese Arbeit relevanten Verfahren werden in diesem Kapitel vorgestellt.
2.2.1 Grundbegriffe
„Die Statistik befasst sich mit Daten, die bei wiederholter Beobachtung oder Messung
festgestellt werden. Kennzeichnend für diese Daten sind zufällige (regellose) Schwankungen
bei wiederholter Beobachtung oder Messung und stabile Häufigkeiten (Häufigkeitsverteilung)
der Meß- oder Beobachtungswerte (Merkmalwerte) in hinreichend großen Gesamtheiten. Es
wird angenommen, dass die in der Stichprobe beobachteten Daten zufällig und unabhängig
aus der Grundgesamtheit entnommen sind.“ [Schn98, S.2] Die Daten können durch
Messungen, aber auch durch Befragung von Personen erhoben werden; die Größen, auf die
sich Fragen oder Messungen beziehen, heißen Merkmale. Die Grundgesamtheit bezeichnet
die Menge aller statistischen Objekte mit den gleichen Identifikationseigenschaften, über die
in einem Experiment mit Hilfe einer Stichprobe eine Aussage getroffen werden soll. Eine
Stichprobe erhält man durch Ziehen einer Teilmenge aus der Grundgesamtheit.
Im Folgenden sollen die wichtigsten Grundbegriffe für solche Zufallsexperimente erklärt
werden, die nur endlich viele oder abzählbar viele mögliche Experimentergebnisse haben, das
heißt die in einem sogenannten diskreten Wahrscheinlichkeitsraum liegen. Sei Ω ein
Ergebnisraum, wobei alle denkbaren Ereignisse des zugehörigen Zufallsexperiments
Teilmengen dieses Raumes sind. Beschreibe A ⊂ Ω ein Ereignis und {w} mit w ∈Ω ein
Elementarereignis. Sei ( Ω,A)
ein Ereignisraum. Dann heißt eine endliche Funktion X : Ω →
€
, die jedem Ergebnis w ∈Ω eine reelle Zahl X( w)
zuordnet, so dass für die mit dieser
Funktion beschriebenen Ereignisse € Wahrscheinlichkeiten nennbar € sind, reellwertige
Zufallsvariable, falls
€
€
€
€
X −1( Β)
= { w ∈Ω | X( w)
∈Β}
∈ A, ∀Β∈ B,
das heißt falls die Umkehrfunktion von X auf allen borelschen Mengen
€
2 von in A ist. Diese
X
Bedingung wird auch ( B,A)-Messbarkeit
von X genannt mit (Ω,A) ⎯⎯ ⎯⎯ → ( , B). In vielen
Fällen interessiert nämlich nicht w selbst, sondern eine durch w bestimmte Größe X( w),
was
in Beispiel 1 verdeutlicht werden soll.
€
€
€
€
€
€
Es werde zweimal gewürfelt. Der Ergebnisraum ist dann Ω = { ( i, j)
: i, j =1,...,6}.
Nun
interessiert nicht nur eine der beiden gewürfelten Augenzahlen, sondern die Summe der
Augenzahlen beider Würfe X( w)
= X( ( i, j)
) = i + j. Man möchte dem Ereignis X ∈ Α mit
Α ∈ , dass die Summe der Augenzahlen gleich 12 € ist, eine Wahrscheinlichkeit zuordnen.
Dabei muss { w | X( w)
∈ Α}
∈ A sein.
€
€
Beispiel 1: Zufallsexperiment „Würfeln“
€
2 Zur Definition einer borelschen Menge sei verwiesen auf [Kre00, S.130].

€
€
€
€
€
2 Grundlagen | 16
Die Ergebnisse eines Zufallsexperiments können wie beim „Würfeln“ selbst schon Zahlen
sein, aber natürlich kann es sich bei den Ergebnissen beispielsweise auch um Ausprägungen
qualitativer Merkmale handeln. [Har+05, S.103]
Die Verteilung einer Zufallsvariable gibt an, „wie wahrscheinlich die einzelnen Werte von
X sind“ [Kre00, S.42]. Ist eine Zufallsvariable X reellwertig, so lässt sich ihre Verteilung
eindeutig durch die Verteilungsfunktion F( X)
= P( X ≤ x)
mit x ∈ beschreiben, wobei
P( X ≤ x)
ausdrückt, mit welcher Wahrscheinlichkeit die Zufallsvariable X einen Wert kleiner
oder gleich x annimmt. Als Beispiel für die Verteilung einer Zufallsvariable sei hier die
Normalverteilung genannt. Deren Eigenschaften sollen
€
€ etwas später in diesem Kapitel noch
genauer beschrieben werden, da es im durchzuführenden Experiment um die Anzahl von
Fehlern und die Anzahl von Anforderungen gehen soll und deshalb zur Anwendung von
statistischen Tests eventuell einige Annahmen zur Normalverteilung erforderlich sein
könnten. Zunächst werden aber noch weitere Grundbegriffe erläutert.
Betrachtet man eine reellwertige Zufallsvariable X mit diskreter Verteilung und den Werten
x1 ,x 2 ,...,x n , das heißt man führt das Zufallsexperiment n-mal durch, dann will man
gegebenenfalls wissen, welchen Wert man für X im Mittel erhält. Der Mittelwert x ist
definiert durch
€
.
€
Wenn man einen „mittleren Wert“ für die Zufallsvariable X angeben will, ist es auch sinnvoll,
die Werte x1, x2,..., xn mit den entsprechenden Wahrscheinlichkeiten p1,..., pn zu gewichten.
Die Berücksichtigung dieser Gewichtung findet man im Erwartungswert µ mit
n
∑
µ € = xi pi i=1
wieder. Der Erwartungswert ist eine Maßzahl für den Schwerpunkt einer Verteilung. [Kre00,
S.52] Die Varianz ist ein Maß für die Abweichung der Zufallsvariable X von ihrem
Erwartungswert, sie ist also ein Streuungsmaß. Für die Varianz gilt
n
σ 2 = (x i − µ) 2 ∑ pi .
i=1
Die Quadratwurzel der Varianz heißt Standardabweichung und wird mit bezeichnet.
Bezieht man die Begriffe Varianz und Standardabweichung auf empirische Daten, so spricht
man von der empirischen Varianz bzw. der empirischen Standardabweichung s. Die
empirische Varianz stellt für die Varianz einer Zufallsvariable eine Schätzfunktion 3 aus
Werten dar, die bei einer Stichprobe gemessen wurden. Die empirische Varianz ist gerade
3 Eine Schätzfunktion ordnet der Zufallsstichprobe einen Wert zu. Dabei ist natürlich ein Wert, der
möglichst nahe oder gleich dem wahren Wert ist, gewünscht, allerdings kann der Wert auch weit daneben liegen.
€
€
€

€
€
2 Grundlagen | 17
mit Mittelwert von
x 1 ,x 2 ,..,x n .
Die empirische Standardabweichung ist wiederum die Wurzel der empirischen Varianz. Sie
hat im Gegensatz zur Varianz den Vorteil, dass € die Handhabung von Maßeinheiten einfacher
ist.
Als Kenngrößen von Verteilungen werden sogenannte Quantile benutzt. Für jedes beliebige p
mit nennt man das p-Quantil, wenn für die Verteilungsfunktion gilt
(vgl. Tab. „Quantile der Normalverteilung“). Dabei wird das 0,25-Quantil als das untere
Quartil, das 0,75-Quantil als das obere Quartil und das 0,5-Quantil als Median bezeichnet.
Der Median halbiert die Verteilung. Gegenüber dem Mittelwert hat der Median den Vorteil,
robuster gegenüber Ausreißern zu sein. [WikiM]
Nun seien noch einige Hinweise zu den Eigenschaften der Normalverteilung gegeben. Eine
Zufallsvariable X mit der Wahrscheinlichkeitsdichtefunktion 4
f : → >0 , x f ( x),
1
f ( x)
= ⋅ e
σ 2π
− 1
⎛⎛
2
⎛⎛ x −µ ⎞⎞ ⎞⎞
⎜⎜
⎜⎜ ⎜⎜ ⎟⎟ ⎟⎟
⎝⎝ 2⎝⎝
σ ⎠⎠ ⎟⎟
⎠⎠
heißt mit Erwartungswert und Standardabweichung σ normalverteilt. Das Bild der
Dichtefunktion ist die bekannte Glockenkurve (vgl. Abb.4).
1
F( x)
=
σ 2π
1 ⎛⎛ t −µ ⎞⎞ 2
x
⋅⎜⎜ ⎟⎟
2 ⎝⎝ σ ⎠⎠
⋅ e−
∫ dt
−∞
heißt die Verteilungsfunktion der Normalverteilung.
Abbildung 4: Verteilungs- und Dichtefunktion der Normalverteilung [UniM]
Grundsätzlich sollte eine Annahme über eine Verteilung immer mit einem entsprechenden
Test überprüft werden. Ein Beispiel für einen Test zur Prüfung auf Normalverteilung ist der
Kolmogoroff-Smirnov-Anpassungstest, deren genaue Beschreibung aber im Rahmen dieser
Arbeit etwas zu weit führen würde. Die entsprechenden Berechnungen können beispielsweise
mit dem Statistikprogramm „R“ durchgeführt werden, so dass die Ergebnisse für die in dieser
Arbeit getroffenen Annahmen zur Normalverteilung zur Verfügung stehen und so auch ohne
4 „Durch die Angabe einer Dichte, die in vielen Fällen als Ableitung der Verteilungsfunktion bestimmt werden
kann, ist eine Wahrscheinlichkeitsdichte eindeutig bestimmt.“[Har+05, S.106]
€
€
€
€
€

€
€
€
2 Grundlagen | 18
konkretere Beschreibung des Tests zur Diskussion der Gültigkeit der Experimentergebnisse
herangezogen werden können.
2.2.2 Statistische Tests
Mit einem statistischen Test (auch Hypothesen- oder Signifikanztest genannt) können
Hypothesen entweder widerlegt oder gestützt werden. Beispielsweise möchte man wissen, ob
ein Parameter größer oder kleiner als ein bestimmter Wert ist. Bei solchen Fragestellungen
können statistische Tests natürlich nicht immer die richtige Entscheidung liefern, da die
Messdaten eines zufälligen Experiments die Ausgangspunkte für die aufgestellten
Hypothesen sind, aber sie können der Entscheidung eine Richtung weisen.
Beim Aufstellen von testbaren Hypothesen unterscheidet man zwischen der Null- und
Alternativhypothese ( und ). Die Nullhypothese enthält in der Regel die Aussage über
den Zusammenhang, der nicht erwartet wird. Diese Annahme soll verworfen werden, so dass
die Alternativhypothese bestärkt wird. Die Aufgabe zwischen der Null- und der
Alternativhypothese eine Entscheidung zu treffen, wird als Testproblem bezeichnet. Dabei
können zwei Arten von Fehlern entstehen. Entscheidet man sich für H1 , obwohl H0 zutrifft,
so bezeichnet man diesen Fehler als Fehler 1. Art bzw. -Fehler. Umgekehrt heißt die
Fehlentscheidung, bei der man sich für entscheidet, obwohl vorliegt, Fehler 2. Art
bzw. -Fehler (vgl. Tab.1). Dabei kann man allerdings nicht feststellen, ob man einen Fehler
€ €
gemacht hat, sondern nur, von welcher Art der Fehler ist.
Es liegt vor
Entscheidung für
H1 - Fehler 2. Art ( -Fehler)
H1 Fehler 1. Art ( -Fehler)
€
-
Tabelle 1: Fehlerarten beim Testen [Har+05, S.133]
Nun soll gezeigt werden, wie so ein Test aussieht. Möchte man testen, ob ein Parameter p
größer € bzw. kleiner als ein Wert p0 ist, so stellt man Hypothesen der Art H0 : p ≤ p0 gegen
H1 : p > p0 bzw. gegen H1 : p < p0 auf. Eine solche Hypothese nennt man
einseitige Hypothese. Die einseitige Hypothese legt die Richtung des möglichen
Unterschieds fest. Das zur einseitigen Hypothese gehörige Testproblem heißt einseitiges
€
€
Testproblem. Die zweiseitige Hypothese gegen H1 : p ≠ p0 sagt nur etwas
€
darüber aus, ob es einen Unterschied zwischen dem Parameter p und dem Wert p0 gibt, ohne
dabei eine Richtung vorzugeben. Man spricht von einem zweiseitigen Testproblem.
€
Betrachtet man ausschließlich eine Stichprobe mit einer Zufallsvariablen X einer
normalverteilten Grundgesamtheit, die der Stichprobe die Werte
€
x1 ,..., xn zuordnet, mit
unbekannten Erwartungswert µ ∈ und unbekannter Varianz σ
€
€
€
€
2 > 0 zu gegebenem µ 0 ∈ .
Dann lässt sich der einseitige Einstichproben-t-Test mit n-1 Freiheitsgraden zu einem
gewählten Signifikanzniveau α ∈(0,1) anwenden. Dabei testet man die Nullhypothese
H0 : µ ≤ µ 0 gegen die Alternativhypothese H1 : µ > µ 0 . Dafür wird mit dem Mittelwert und
€
der Standardabweichung s der Stichprobe x1,..., xn die sogenannte Prüfgröße
t = n x − µ 0
s
€
€
€

€
€
€
€
€
€
€
€
2 Grundlagen | 19
ermittelt.
H0 wird zum angegebenen Signifikanzniveau α verworfen, falls
t > t( n −1;1−α)
,
€
€
wobei tn,γ das Quantil der t-Verteilung ist (vgl. Tab. „Quantile der t-Verteilung“). Analog
kann die Nullhypothese H0 : µ ≥ µ 0 kann gegen die Alternativhypothese H1 : µ < µ 0 getestet
werden. Beim zweiseitigen Einstichproben-t-Test wird die Nullhypothese H0 : µ = µ 0 gegen
die Alternativhypothese H1 : µ ≠ µ 0 getestet und H0 verworfen, falls
€
€
€
t > t⎛⎛ α ⎞⎞ .
⎜⎜ n −1;1− ⎟⎟
€
⎝⎝ 2⎠⎠
€
€
€
Mit dem Zweistichproben-t-Test mit n+m-2 Freiheitsgraden betrachtet man zwei
unabhängige Stichproben mit der Zufallsvariable X, die der ersten Stichprobe die Werte
x1 ,...,x n zuordnet, und der Zufallsvariable Y, die der zweiten Stichprobe die Werte y1 ,..., yn zuordnet. X und Y seien Zufallsvariablen jeweils einer normalverteilten Grundgesamtheit.
Seien µ x,µ y ∈ unbekannte Parameter. Gewählt sei ein Signifikanzniveau α ∈(0,1). Mit den
2 2
Mittelwerten , und den Stichprobenvarianzen sx,sy > 0 der beiden Stichproben € wird die
gewichtete Varianz
€
berechnet. Für die Prüfgröße t ergibt sich dann
t =
n⋅ m
n + m
x − y
⋅ .
s
€
Beim einseitigen Zweistichproben-t-Test wird die Nullhypothese H0 : µ ≤ µ 0 gegen
H1 : µ > µ 0 getestet. Die Nullhypothese wird dann zum angegebenen Signifikanzniveau
verworfen, falls
t > t (n +m −2;1−α ).
Die Nullhypothese H0 : µ ≥ µ 0 kann wiederum analog gegen die Alternativhypothese
H1 : µ < µ 0 getestet werden. Beim zweiseitigen Zweistichproben-t-Test wird die
Nullhypothese H0 : µ = µ 0 gegen die Alternativhypothese H1 : µ ≠ µ 0 getestet und H0 verworfen, falls
€
t > t α
(n € +m −2;1−
2 )
.
Wird eine Nullhypothese abgelehnt, so spricht das für einen signifikanten Unterschied
zwischen den Ausprägungen der betrachteten Stichprobenmerkmale.
Sowohl der Einstichproben- als auch der Zweistichproben-t-Test basieren auf der empirischen
Standardabweichung der Stichprobe(n). Ihr Vorteil für das durchzuführende Experiment liegt
€
€
€

2 Grundlagen | 20
also darin, dass die Standardabweichung der Grundgesamtheit nicht bekannt sein muss, wie es
beispielsweise bei dem Gauß-Test (einem weiteren statistischem Test) der Fall ist.
Anstatt einen unbekannten Parameter durch einen einzigen Wert zu schätzen, möchte man
manchmal einen möglichst kleinen Bereich angeben, in dem der gesuchte Parameter mit einer
vorher festgelegten Wahrscheinlichkeit zu finden ist. Die Informationen über den
unbekannten Parameter erhält man durch ein Zufallsexperiment und der Bereich, der den
Parameter überdecken soll, wird zufällig ausgewählt, so dass es im Allgemeinen unmöglich
ist, ein Verfahren anzugeben, das immer so einen kleinen Bereich liefert. Man berücksichtigt
also die Irrtumswahrscheinlichkeit α ∈( 0,1),
dass der gesuchte Parameter nicht in dem
Bereich liegt, und erhält mit einer Wahrscheinlichkeit von einen Bereich, in dem der
unbekannte Parameter liegt. Dieser Bereich heißt Konfidenzintervall oder Vertrauensbereich
zum Niveau 1 − α .
€
2.2.3 € Bestimmung der Stichprobengröße
Die sogenannte Güteanalyse ist ein Verfahren, mit dem man im Vorfeld eines Experiments
eine Richtlinie erhält, welche Stichprobengröße erforderlich ist, um zu den gestellten Fragen
aussagekräftige Antworten zu bekommen. Dieses Verfahren soll hier zum Einsatz kommen,
da zu vermuten ist, dass für aussagekräftige Antworten eine sicher ausreichend große
Probandenzahl nur schwer erreicht werden kann. Eine zu kleine Stichprobengröße hat eine
große Ungenauigkeit das heißt ein zu großes Konfidenzintervall zur Folge, ist deshalb
unzuverlässig und liefert sehr wahrscheinlich unbrauchbare Ergebnisse. Eine zu große
Stichprobengröße dagegen verursacht Kosten, die in vielen Fällen nicht getragen werden
können, und bedeutet einen wesentlich größeren Zeitaufwand. Es gibt je nach dem, wie die
zugrundeliegende Grundgesamtheit verteilt ist, verschiedene Möglichkeiten, den
Stichprobenumfang abzuschätzen. In diesem Kapitel soll jeweils eine Möglichkeit für eine
zugrundeliegende normalverteilte und eine binomialverteilte Grundgesamtheit vorgestellt
werden. Auf normalverteilte Grundgesamtheiten wurde in Bezug auf das in dieser Arbeit
durchzuführende Experiment in Kapitel 2.2.1 schon genauer eingegangen. Die Abschätzung
des Stichprobenumfangs für eine binomialverteilte Grundgesamtheit soll hier, ohne dass
näher auf die Eigenschaften einer Binomialverteilung eingegangen wurde, aufgeführt
werden, da Annahmen zur Binomialverteilung ähnlich wie die zur Normalverteilung gängig
im Bereich der Softwareentwicklung sind. Die konkreten Berechnungen zu dem Experiment
in dieser Arbeit werden in Kapitel 3.5.1.1 in den vor der Messung notwendigen Schritten
dokumentiert.
Die Güte meint die Wahrscheinlichkeit, mit der ein statistischer Test für die
Alternativhypothese entscheidet. Die Güte ist gerade , wobei β den Fehler 2. Art
beschreibt, und wird unter anderem durch den Stichprobenumfang beeinflusst. Je größer der
Stichprobenumfang ist, desto höher ist in der Regel die Güte. Je kleiner der nachzuweisende
Effekt im Experiment ist, desto kleiner ist erwartungsgemäß die Güte. Ist der nachzuweisende
Effekt also tatsächlich klein, so wird wahrscheinlich ein € größerer Stichprobenumfang
erforderlich sein, um die Aussagekraft der getesteten Hypothese einschätzen zu können.
Allerdings lassen sich diese Einflüsse auf die Güte nicht verallgemeinern.

€
€
€
€
€
2 Grundlagen | 21
2.2.3.1 Bestimmung des Stichprobenumfangs über den Erwartungswert einer
Normalverteilung
Betrachtet man eine Stichprobe mit unabhängigen Zufallsvariablen x1 ,...,x n = X einer
normalverteilten Grundgesamtheit, dann ermittelt man den Stichprobenumfang n beim Testen
von Hypothesen über den unbekannten Parameter µ ∈ mit bekannter Varianz σ
€
2 > 0 nach
[Pfla+01] folgendermaßen:
Liegt ein einseitiges Testproblem zugrunde, das heißt man testet die Nullhypothese
€
€
H0 : µ ≤ µ 0 gegen die Alternativhypothese H1 : µ > µ 0 zum gewählten Signifikanzniveau
α ∈( 0,1)
und gibt an der Stelle eine Wahrscheinlichkeit β ∈( 0,1)
für den Fehler 2.
Art vor, so muss der Stichprobenumfang, um beide Fehler einhalten zu können,
€
sein. uγ beschreibt hier das Quantil der Normalverteilung (vgl. Tab. „Quantile der
Normalverteilung“).
Analog bestimmt man auch n, wenn die Nullhypothese H0 : µ ≥ µ 0 gegen die
Alternativhypothese H1 : µ < µ 0 zum gewählten Signifikanzniveau α ∈( 0,1)
und bei
vorgegebener Wahrscheinlichkeit β ∈ 0,1
€
Im zweiseitigen
€
Testproblem H0 : µ = µ 0 gegen H1 : µ ≠ µ 0 zum gewählten Signifikanzniveau
€
α ∈( 0,1)
ergibt sich bei vorgegebener Wahrscheinlichkeit β ∈( 0,1)
für den Fehler 2. Art an
€
einer Stelle eine Stichprobengröße von
€
.
€
( ) für den Fehler 2. Art getestet werden soll.
€
Man muss also mindestens eine Stichprobe der Größe n ziehen, um sicherzustellen, sich
entweder höchstens mit der Wahrscheinlichkeit α irrtümlich für die Alternative
entschieden zu haben, obwohl vorliegt, oder sich höchstens mit der Wahrscheinlichkeit β
irrtümlich für die Hypothese entschieden hat, obwohl vorliegt.
µ 1 ist stets so zu wählen, dass die Abweichung zwischen µ 0 und µ 1 nicht von praktischem
Interesse ist. [Har+05, S.182]
Sowohl für den einseitigen als auch für den zweiseitigen Test ist die Varianz der
€ €
Grundgesamtheit als bekannt vorausgesetzt. Für σ 2 kann aber beispielsweise auch ein
Erfahrungswert aus früheren Messungen verwendet werden.
2.2.3.2 Bestimmung der Stichprobengröße € über den Parameter p einer
Binomialverteilung
€

€
2 Grundlagen | 22
Betrachtet man eine Stichprobe mit unabhängigen Zufallsvariablen x1 ,...,x n = X einer
binomialverteilten Grundgesamtheit, dann ist die Stichprobengröße n beim Testen von
Hypothesen über den Parameter p einer Binomialverteilung bei vorgegebenen Fehlern 1. und
2. Art wird nach [Har+05, S.206] wie folgt bestimmt:
€
Formuliert man ein einseitiges Testproblem und testet die Nullhypothese H0 : p ≤ p0 gegen
die Alternativhypothese H1 : p > p0 zum gewählten Signifikanzniveau α ∈( 0,1)
und sichert
dabei einen Fehler 2. Art β ∈( 0,1)
an einer Stelle p1 > p0 ab, so muss man, um die
Fehlerwahrscheinlichkeiten α und β nicht zu überschreiten, als Stichprobenumfang
€
€
€
€
€
wählen. Die gleiche Formel zur Bestimmung des Stichprobenumfangs n gilt für das einseitige
Testproblem, bei dem die Nullhypothese H0 : p ≥ p0 gegen die Alternativehypothese
H1 : p < p0 bei vorgegebenem Fehler β an einer Stelle p1 < p0 . Im zweiseitigen Testproblem
wird die Nullhypothese H0 : p = p0 gegen die Alternativhypothese H1 : p ≠ p0 zum gewählten
Signifikanzniveau α ∈( 0,1)
bestimmt
€
man den Stichprobenumfang n aus
€
€
€
€
,
€
wenn man an einer Stelle
p 1 ≠ p 0 einen Fehler 2. Art mit
2.2.4 Zufällige Auswahl, Randomisation
€
€
β ∈( 0,1)
vorgibt.
Es ist ausgeschlossen, alle möglichen Einflüsse, die sich auf die Gültigkeit der Ergebnisse
auswirken könnten, zu bestimmen und zu berücksichtigen. Sie sollten aber weitestgehend
abgeschwächt werden. Insbesondere bei der Auswahl der Stichprobe, die als Grundlage für
das Experiment dient, sollten die Folgen von Störgrößen so gering wie möglich gehalten
werden. Die Größe systematischer Fehler lässt sich allein aus den Messwerten nicht ermitteln,
da der Fehler immer die gleiche Größe hat. Um also systematische Fehler bei der Auswahl
der Stichprobe wie zum Beispiel den Experimentleitereffekt 5 einzugrenzen bzw. zu
vermeiden, sollen im durchzuführenden Experiment die Probanden zufällig den
Experimentgruppen zugeordnet werden. Dabei ist der systematische Fehler gerade derjenige,
der immer wieder die gleiche Struktur aufweist. Sucht der Experimentleiter beispielsweise
ein Objekt der Stichprobe (hier ein Teilnehmer des Experiments) unbewusst nach einem
bestimmten Merkmal aus, so wird er diesen Fehler, der starke Effekte in den Ergebnissen
hervorrufen kann, bei jeder Auswahl des nächsten Objekts wiederholen.
Für eine zufällige Auswahl werden zunächst alle Probanden durchnummeriert. Dann wird für
jede Experimentgruppe die vorgesehene Anzahl von Probanden durch zufälliges Ziehen ihrer
Nummern ausgewählt. „Diese Vorgehensweise nennt man auch Randomisation“ [Har+05,
S.141] Eine zufällige Auswahl von Nummer kann beispielsweise mit dem Statistikprogramm
„R“ oder mit dem Tabellenkalkulationsprogramm „Excel“ simuliert werden.
5 Der Experimentleitereffekt bedeutet, dass der Experimentleiter (unbewusst) auf das Versuchsergebnis einwirkt.

2 Grundlagen | 23
2.2.5 Messfehler und Ausreißer
Ziel eines Experiments ist es, von einer Stichprobe Schlüsse auf die Grundgesamtheit zu
ziehen. Sobald die Daten der Stichprobe erhoben wurden, sollte man sie auf statistische
Fehler und Ausreißer prüfen, die das verallgemeinerte Ergebnis verfälschen könnten.
2.2.5.1 Statistische Fehler
„Nimmt man irgendwelche Messungen vor, [...], so sind diese niemals exakt; das bemerkt
man, wenn Messungen wiederholt werden oder wenn verschiedene Personen das Gleiche
messen. Es treten dann Schwankungen oder Ungenauigkeiten in den erhaltenen Messwerten
auf.“ [Har+05, S.320] Statistische Fehler beeinflussen die Ergebnisse auf verschiedene Arten,
sind zufällig und unberechenbar. Sie resultieren oft aus einer Reihe an Elementarfehlern. Das
Ausmaß eines statistischen Fehlers lässt sich aber bewerten, wenn beispielsweise Messungen
wiederholt werden und Ergebnisse mehrfach zur Beurteilung vorliegen.
Im konkret durchzuführenden Experiment sollen zur Datenerhebung notwendige Definitionen
und Klassifizierungen teilweise von zwei verschiedenen Personen angewendet werden, das
heißt die Messung soll (zumindest teilweise) wiederholt werden, so dass ein Teil der
Ergebnisse mehrfach vorliegt. Dabei kann eine gewisse Toleranz von Abweichungen
eingeräumt werden. Bei deren Überschreitung sollte die Herleitung der Ergebnisse genau
hinterfragt werden. Beispielsweise können die Metriken, die zu den Ergebnissen geführt
haben, auf Präzision geprüft werden. Metriken können ungenau werden, wenn sie auf
Definitionen und Klassifizierungen basieren.
2.2.5.2 Ausreißer
Oft sind einige Messwerte sehr weit von allen anderen entfernt. Das kann das Ergebnis eines
Experiments stark beeinflussen. Solche „Ausreißer“ können aber beispielsweise durch
Unregelmäßigkeiten im Experiment entstanden sein. Ein Ausreißer-Test kann gegebenenfalls
eine Entscheidungshilfe geben, ob es besser ist, den Ausreißer bei den weiteren Berechnungen
nicht zu berücksichtigen. Zur Anwendung eines Tests müssen zunächst die zu testenden
Datenpunkte ihrer Größe nach geordnet werden. Der Grubbs-Test, der hier als Beispiel für
einen Ausreißertest angegeben werden soll, geht von der Annahme aus, dass die
Zufallsvariablen normalverteilt sind und testet, ob ein potentieller Ausreißer tatsächlich einer
ist, indem überprüft wird, ob er aus der Normalverteilung stammt. Geprüft werden in der
Regel der kleinste und der größte Wert einer Menge von Zufallsvariablen.
Nach [Har+05, S.345] wird bei dem Ausreißer-Test von Grubbs für die Meßreihe mit den
Zufallsvariablen x (1) ,...,x (n ) , wobei x (1) der kleinste und x (n ) der größte Wert der Menge von
Zufallsvariablen ist, die Nullhypothese H0 : (x (1) ist kein Ausreißer) gegen die
Alternativhypothese H1 : (x (1) ist ein Ausreißer) zum Signifikanzniveau α ∈( 0,1)
getestet. H0 wird verworfen, € falls €
€
€
€ .
€
€

€
€
€
2 Grundlagen | 24
Dabei bezeichnet den Mittelwert, s die Standardabweichung und n die Anzahl der
Zufallsvariablen. Der Wert für lässt sich dann aus der Tabelle für kritische Werte 6
des Grubbs-Tests ablesen (vgl. Tab. „Kritische Werte des Grubbs-Test“). Wird die
Nullhypothese H0 : (x (n) ist kein Ausreißer) gegen die Alternativhypothese H1 : (x (n) ist ein
Ausreißer) wird zum Signifikanzniveau α ∈ 0,1 H0 wird verworfen, falls
€
.
€
2.2.6 Korrelation von Merkmalen
( ) getestet.
In der Analyse von in Experimenten erhobenen Daten möchte man oft Abhängigkeiten
verschiedener Merkmale finden bzw. auch belegen, um qualitative Aussagen über deren
Beziehung untereinander machen zu können. Die Korrelation von Merkmalen misst den
Stärkegrad einer Abhängigkeit verschiedener Merkmale. Wenn eine Korrelation vorliegt,
bedeutet das jedoch nicht zwingend, dass das eine Merkmal das andere kausal beeinflusst.
Möglich ist auch, dass beide Merkmale von einer dritten Größe abhängen oder gar keine
Abhängigkeit im Sinne eines kausalen Zusammenhangs besteht.
Seien X mit den Werten x1,...,x n und Y mit den Werten y1,..., yn Zufallsvariablen einer
normalverteilten Grundgesamtheit mit jeweils positiver Varianz, wobei die Werte für X und Y
paarweise erhoben wurden. Will man die Korrelation anhand einer Stichprobe vom Umfang n
aus dieser normalverteilten Grundgesamtheit, dann kann die Korrelation zwischen ihnen mit
dem sogenannten
€
Pearsonschen Korrelationskoeffizienten
€
ρXY ∈ −1,+1
ρ XY =
n
n
∑
i=1
( xi − x ) yi − y
( )
( xi − x ) 2
∑ ⋅ ∑ yi − y
i=1
n
i=1
( ) 2
€
€
€
[ ] mit
abgeschätzt werden. [Har+05, S.546] Dabei bezeichnet x den Mittelwert von x1,..., xn und y
den Mittelwert von y1,...,y n . Der Wert ρXY = +1 ( ρXY = −1) gibt dabei an, dass ein vollständig
positiver (negativer) linearer Zusammenhang vorliegt. Bei einem Korrelationskoeffizienten
von Null hängen die auf Korrelation geprüften
€
Merkmale nicht linear voneinander ab. Mit
€
Hilfe der Korrelation kann man testen, ob die Zufallsvariablen X und Y wie oben
€
definiert
unabhängig
€
sind. Dazu formuliert
€
man
€
zu den gegebenen Zufallsvariablen das zweiseitige
Testproblem, bei dem man die Nullhypothese H0 : ρ = 0 gegen die Alternativhypothese
H1 : ρ ≠ 0 zum gewähltem Signifikanzniveau α ∈( 0,1)
mit dem zweiseitigen
Zweistichproben-t-Test testet. Die Nullhypothese wird verworfen, falls gilt
t > t n −2;1− α
2
€
mit
t = ρXY ⋅ n − 2
2
1− ρXY ,
€
6 Diese bezeichnen allgemein den kritischen Wert einer t-Verteilung mit m Freiheitsgraden zum Niveau β.
€

2 Grundlagen | 25
wobei das Quantil der t-Verteilung ist (vgl. Tab. „Quantile der t-Verteilung“).
2.2.7 Skalenniveau
„Um die Ausprägung eines Merkmals messen oder erfragen zu können, muss man natürlich
zunächst eine Skala [...] festlegen, die alle möglichen Ausprägungen eines Merkmals
beinhaltet.“ [Har+05, S.16] Zur Klassifizierung von Merkmalen lassen sich beispielsweise
verschiedene Stufen der Skalierbarkeit, sogenannte Skalenniveaus verwenden. Das
Skalenniveau definiert die mathematischen Operationen, die auf dem skalierten Merkmal
zulässig sind (vgl. Tab.2). Ist ein Merkmal auf einem Niveau skalierbar, so ist es ebenfalls auf
allen darunter liegenden Niveaus skalierbar. Dies gilt allerdings nicht für die Umkehrung. Das
niedrigste Skalenniveau ist die Nominalskala. Ihre Werte „unterliegen keiner Rangfolge und
sind nicht vergleichbar“ [Har+05, S.16] Darüber steht die Ordinalskala, deren Werte einer
Rangfolge unterliegen und sich daher „in ihrer Intensität unterscheiden und nach der Stärke
der Intensität ordnen lassen.“ [Har+05, S. 17] Ein Beispiel für die Ordinalskala ist die
Skalierung mit Hilfe von Schulnoten. Das höchste Skalenniveau ist die metrische Skala. Die
Abstände zwischen ihren Werten sind interpretierbar. In der metrischen Skala werden die
Intervall- und Verhältnisskala zusammengefasst. Sie unterscheiden sich je nach dem, ob ein
absoluter Nullpunkt existiert (Verhältnisskala) oder nicht (Intervallskala).
Skalenniveau
Gleichheit
der Werte
(=,≠)
mögliche mathematische Operationen
Ordnung
der Werte
()
Verhältnisse
von
Wertdifferenzen
(+,-)
Verhältnisse
von Werten
( )
Beispiel
Nominalskala ja nein nein nein Farbe
Ordinalskala ja ja nein nein Schulnote
metrische Intervallskala ja ja ja nein Zeit
Skala Verhältnisskala ja ja ja ja Alter
Tabelle 2: Skalenniveaus
Die Skalierung zu dem in dieser Arbeit durchzuführenden Experiment wird in Kapitel 3.2.2
vorgenommen. Sind die Ausprägungen der beobachteten Merkmale metrisch skaliert, so sind
Methoden wie zum Beispiel die Korrelationsrechnung problemlos anwendbar.
2.3 Allgemeine Grundlagen
2.3.1 Das Experiment
Der Vollständigkeit halber soll in diesem Kapitel der schon vorweg mehrfach genannte
Begriff Experiment definiert werden, um auf dieser Grundlage etwas über Variablen und
Experimentdesign sagen zu können. Ein Experiment ist eine Untersuchung und eine
Methode zur Datenerhebung, bei der gezielt vorher formulierte Hypothesen auf ihre
Gültigkeit geprüft werden sollen. Man erhofft sich Hinweise darüber, ob die formulierten
Hypothesen eher anzuzweifeln oder zu bekräftigen sind. Im Gegensatz zu einer reinen
Beobachtung werden in einem Experiment bestimmte Rahmenbedingungen im Vorfeld
bewusst festgelegt werden. Außerdem spielt in der Regel zusätzlich zu dem zu
untersuchenden Objekt und dem Beobachter auch noch eine vorher gewählte Methode zur
Experimentplanung (hier die GQM-Methode) eine Rolle.

2 Grundlagen | 26
Die wesentlichen Elemente eines Experiments sind die Variablen. Man unterscheidet
zwischen abhängigen, unabhängigen und Störvariablen. Die unabhängigen Variablen
werden bewusst beeinflusst, um eine mögliche Veränderung messen zu können. Sie wirken
auf die abhängigen Variablen ein. Ihre Auswirkung wiederum sollen gerade durch das
Experiment geprüft werden. Als Störvariablen bezeichnet man schließlich Elemente
innerhalb des Versuchsaufbaus, die ebenfalls auf die abhängigen Variablen einwirken und so
die Gültigkeit der Ergebnisse beeinflussen und die Aussagekraft des Experiments mindern.
2.3.2 Exkurs: Experimentdesign
Im klinischen Umfeld werden oft Experimente durchgeführt, um beispielsweise die
unterschiedlichen Wirkungsweisen von zwei Medikamenten beim Menschen zu vergleichen.
Beim sogenannten Parallelgruppen-Design wird jeder Experimentteilnehmer per
Zufallsziehung nur einer der beiden Experimentgruppen zugeteilt, das heißt an jedem
Experimentteilnehmer wird nur eines der beiden Medikamente getestet. Häufig wird aber das
Cross-Over-Design angewendet. Im Gegensatz zum Parallelgruppen-Design werden dabei
die Experimentteilnehmer nacheinander beiden Experimentgruppe zugeordnet, das heißt an
jedem Experimentteilnehmer wird erst das eine und dann das andere Medikament getestet.
Ausschließlich die Reihenfolge wird dann noch mit Hilfe einer Zufallsziehung bestimmt. Im
Vorfeld der Planung des in dieser Arbeit durchzuführenden Experiments stellte sich die
Frage, ob die Anwendung dieses Experimentdesigns die doppelte Menge an Datenpunkten
liefern bzw. die Größe der für ein aussagekräftiges Ergebnis notwendigen Stichprobe
verringern könnte, weshalb die Designmethode hier kurz erläutert und ihr Nutzen für dieses
Experiment abgeschätzt werden soll.
Ein Experiment, das die verschiedenen Wirkungsweisen von Medikamenten untersuchen ist
ähnlich dem in dieser Arbeit durchgeführten Experiment, in dem die Wirkungsweisen von
Werkzeugen in der Anforderungserhebung verglichen werden sollen. Nach [Schu+08, S.306]
kann dieses Experimentdesign in klinischen Experimenten im geeigneten Fall den Aufwand
gegenüber dem Parallelgruppendesign deutlich reduzieren, weil jeder Experimentteilnehmer
seine eigene Kontrolle ist. Weniger Aufwand meint insbesondere, dass man mit einer
geringeren Stichprobengröße auskommt. Die Idee davon, dass die Anwendung des Cross-
Over-Designs die notwendige Stichprobengröße verringern könnte, begründet sich darin, dass
die Variabilität innerhalb der einzelnen Experimentteilnehmer oft geringer ist als die zwischen
Experimentteilnehmern. Die Frage ist, unter welchen Voraussetzungen das der Fall ist, das
heißt welcher Fall für das Cross-Over-Design als geeignet betrachtet werden kann. Dieser
mögliche positive Effekt einer geringeren Stichprobengröße kann nämlich nur dann eintreten,
wenn von dem ersten Experiment keine sogenannten Überhangeffekte mit in das
nachfolgende Experiment getragen werden. So ein Überhangeffekt kann beispielsweise
entstehen, wenn das im ersten Experiment verabreichte Medikament die Wirkung des zweiten
beeinflusst. Nur durch Vermeidung von Überhangeffekten kann die Vergleichbarkeit der
Experimentgruppen geleistet werden. Wirken starke Überhangeffekte auf das zweite
Experiment ein, die man im Vorfeld vielleicht nicht berücksichtigt hat, können nur noch die
Ergebnisse der ersten Experimentgruppe für ein Parallelgruppen-Design verwendet werden,
für das dann aber oft die gewählte Stichprobengröße nicht mehr ausreicht. In klinischen
Experimenten, in denen die Wirkungsweisen verschiedener Medikamente verglichen werden
soll, kann zur Vermeidung von Überhangeffekte ein gewisser Zeitraum ohne
Medikamentenverabreichung zwischen den Experimenten eingeplant werden (Wash-Out
Periode).

2 Grundlagen | 27
Um eine Entscheidung darüber zu treffen, ob der Einsatz des Cross-Over-Designs für
Experimente in der Softwareentwicklung und speziell für das in dieser Arbeit
durchzuführende Experiment Sinn macht, muss also geprüft werden, ob Überhangeffekte
vermieden werden können. Ob es grundsätzlich Situationen in der Softwareentwicklung gibt,
in denen die Anwendung des Cross-Over-Designs den gewünschten Effekt der geringeren
Stichprobengröße bringen würde, lässt sich allerdings nur schwer beurteilen, da das Umfeld,
in dem Experimente in der Softwareentwicklung angewendet werden, wahrscheinlich nicht
vollständig überblickt werden kann. Für diesen gesonderten Fall der Wirkungsweisen von
Werkzeugen in der Anforderungserhebung kann aber gesagt werden, dass es unmöglich ist,
den Überhangeffekt, dass der Anforderungsingenieur das im ersten Experiment Gelernte im
zweiten Experiment benutzt, vollkommen auszuschließen. Der Überhangeffekt würde eine
weitere Störvariable im Experiment bedeuten. Es werden allerdings schon dadurch einige
Einflüsse auf die Gültigkeit der Ergebnisse erwartet, dass in einem Anforderungsinterview
durch die Beteiligung von Menschen kaum alle unabhängigen Variablen identifiziert und
festgehalten werden können. Deshalb soll hier keine weitere notwendige Einschränkung der
Ergebnisse durch nicht kontrollierbare Abhängigkeiten in Kauf genommen und auf die
Anwendung des Cross-Over-Designs verzichtet werden.
2.3.3 Fragebögen als Hilfsmittel zur Datenerhebung
Bei Fragen an die Probanden kann zwischen offenen und geschlossenen Fragen unterschieden
werden. Eine offene Frage muss von dem Befragten mit einem freien Fließtext beantwortet
werden. Die Auswertung ist bei dieser Art von Fragen besonders schwierig, weil sie schwer
miteinander verglichen oder gar zu einer Gruppe von Antworten zusammengefasst werden
können. Diese Problematik kann zu Ungenauigkeiten führen, die möglichst vermieden werden
sollten. Besser sind da geschlossene Fragen, die dem Befragten eine Menge von Antworten
vorgeben. Bei geschlossenen Fragen ist nach [Har+05, S.309] darauf zu achten, dass ihre
Antworten überschaubar, erschöpfend und gut gegeneinander abgegrenzt sind.
Mehrdeutigkeiten und subjektive Standpunkte des Fragebogenentwicklers müssen
ausgeschlossen werden. Antwortmöglichkeiten der Form „weiß nicht“ oder „keine Angabe“
sollte man nicht geben, da sie für den Befragten ein „Freifahrtsschein“ sind, über die
eigentliche Antwort gar nicht erst nachzudenken. Außerdem muss ein Fragebogen den
Eindruck einer wirklichen Gesprächssituation erwecken. Dazu sollte er möglichst von
mehreren über die Rahmenbedingungen informierten Personen erarbeitet oder geprüft
werden. Vor der eigentlichen Befragung sollte getestet werden, ob der Fragebogen
zielgerichtet aufgebaut wurde.

3 Vorbereitung des Experiments mit der GQM-Methode | 28
3 Vorbereitung des Experiments mit der GQM-Methode
3.1 Vorstudie
In der Vorstudie soll herausgearbeitet werden, worum es bei der Messung genau gehen soll.
Klar ist, dass die Ergebnisse zwei unabhängiger Stichproben miteinander verglichen werden
sollen. Dabei soll nur die eine Gruppe das Werkzeug Fast Feedback benutzen. Sie wird im
Folgenden als Experimentgruppe bezeichnet. Die andere Gruppe soll als Hilfsmittel
ausschließlich ein leeres Blatt Papier zur Verfügung gestellt bekommen. Dieses wird ihnen
aus drei Gründen elektronisch in Form eines leeren Word-Dokuments bereitgestellt. Das hat
erstens den Grund, dass die Probanden der verschiedenen Gruppen das jeweilige Werkzeug
möglichst alle unter den gleichen Rahmenbedingungen benutzen sollen und ein Unterschied
in der Art der Textverarbeitung (Papier gegen PC) eine Störvariable bedeuten könnte.
Zweitens sind handschriftliche Dokumente grundsätzlich schwierig auszuwerten. Drittens
wurde Word als Textverarbeitungsprogramm ausgewählt, weil davon auszugehen ist, dass die
Probanden aufgrund des Bekanntheitsgrades von Word ausreichend mit den zugehörigen
Funktionen vertraut sind und keine Einarbeitungszeit benötigen. Das von der zweiten Gruppe
verwendete Werkzeug ist also Word und die Gruppe soll im Folgenden als Kontrollgruppe
bezeichnet werden. Zur weiteren Erarbeitung dessen, worum es in der Messung nun genau
gehen soll, werden in diesem Kapitel zunächst die Hypothesen aus den Grundlagen
herausgearbeitet, dann wird das Experiment sinnvoll eingeschränkt und anschließend mit der
GQM-Methode vorbereitet. So ist eine präzise Planung und korrekte Erstellung des
Messplans möglich.
3.1.1 Herausarbeitung der Hypothesen
3.1.1.1 Hypothese 1 – Fehler in der Anforderungserhebung
„Die Wichtigkeit des Requirements Engineering wird vielfach unterschätzt.“ [Poh08, S.10] In
der Anforderungserhebungsphase werden die Anforderungen in der Regel zunächst nur vage
formuliert. Verschiedene Stakeholder haben wahrscheinlich sogar unklare und
widersprüchliche Ansichten zur gewünschten Software. Dazu kommt, dass sich der
Anforderungsingenieur erst in den Kontext der zu entwickelnden Software einarbeiten muss.
Werden die Anforderungen dann im nächsten Schritt dokumentiert, so kommt es nicht selten
dazu, dass sich Missverständnisse, Widersprüche, Inkonsistenzen und ähnlich fehlerhaft
dokumentierte Anforderungen in den Dokumenten verfestigen. „Beispielsweise werden
Anforderungen übersehen oder missverständlich und unvollständig spezifiziert.“ [Poh08,
S.10] Diese Fehler können ernste und kostenintensive Probleme zur Folge haben. [Schn08]
Natürlich können sich auch Tippfehler und problematische Satzstrukturen einschleichen, um
die es aber im Rahmen dieses Experiments nicht gehen soll, da die zu untersuchende Software
nicht darauf ausgelegt ist, solche Fehler zu finden. Vielmehr verspricht eine die
Anforderungserhebung unterstützende Software wie Fast Feedback dadurch Verbesserung,
dass früher im Prozess ein Demonstrations-Prototyp mit Hilfe von Mock-ups skizziert werden
kann, der dem Kunden die Möglichkeit zu einem schnellen Feedback gibt. Die
Dokumentation und die Validierung fließen so in die Anforderungserhebung mit ein. Ein Ziel
der Verwendung von Fast Feedback soll also sein, möglichst viele fehlerhaft dokumentierten
Anforderungen zu erkennen und das am besten zu einem frühen Zeitpunkt, damit hohe

3 Vorbereitung des Experiments mit der GQM-Methode | 29
Folgekosten für eventuelle nachträgliche Änderungen der Software vermieden werden
können.
Um eine konkrete Hypothese in Bezug auf die Erkennung fehlerhaft dokumentierter
Anforderungen in der frühen Phase der Anforderungserhebung aufstellen zu können, ist es
notwendig, genau zu definieren, in welchen Fällen die Anforderungen als fehlerhaft
dokumentiert bezeichnet und wie sie klassifiziert werden können.
Definition fehlerhaft dokumentierter Anforderungen:
Fehler, die durch die Verwendung von Fast Feedback früher und häufiger gefunden werden
sollen, sind erstens Missverständnisse zwischen dem Anforderungsingenieur und dem
Kunden. Im Falle eines solchen Fehlers unterscheidet sich das, was einer der beiden
gemeint und was der andere verstanden hat maßgeblich voneinander. Dem liegt eine falsche
Interpretation einer Aussage zugrunde. Zweitens sollen mit Fast Feedback früher und
häufiger Widersprüche in den Anforderungen des Kunden an die Software aufgedeckt
werden können. Solche Widersprüche entstehen dann, wenn der Kunde dem
Anforderungsingenieur unbewusst gegensätzliche Informationen zur gewünschten Software
liefert, von denen nur eine verwirklicht werden kann. Drittens sollen mit Hilfe von Fast
Feedback Unvollständigkeiten identifiziert werden. Unvollständigkeiten entstehen dann,
wenn vom Kunden (gegebenenfalls auch versteckt) genannte Anforderungen oder Teile von
Anforderungen, ohne die eine Software nicht funktionieren oder nicht den Vorstellungen
des Kunden entsprechen würde, versehentlich nicht dokumentiert wird. Geschieht dies aber
nicht unabsichtlich sondern absichtlich, das heißt der Anforderungsingenieur hält den
betreffenden Aspekt nicht für wesentlich und interpretiert damit die Aussage des Kunden
falsch, handelt es sich allerdings nicht um eine Unvollständigkeit, sondern um ein
Missverständnis wie oben beschrieben. Viertens sollen gerade Inkonsistenzen zwischen
Oberfläche und Ablauf aufgespürt werden. Solche Inkonsistenzen entstehen zum Beispiel
beim Erstellen von Mock-ups zu verschiedenen Use Cases. Wenn beim Erstellen des
zweiten Use Cases das Mock-up des ersten Use Cases vielleicht nicht mehr so gut in
Erinnerung ist, kann der Aufbau der Oberflächen voneinander abweichen, obwohl der
Ablauf eigentlich identisch ist. Inkonsistente Bezeichnungen können wiederum
Missverständnisse hervorrufen, die sich erst durch Fehler im Entwurf zeigen.
Definition 1: Fehlerhaft dokumentierte Anforderungen
Die in der Definition 1 genannten Arten von fehlerhaft dokumentierten Anforderungen sollen
nun anhand von Beispielen verdeutlicht werden (vgl. Beispiel 1).
Arten von Fehlern Beispiele zum Szenario „Bibliotheksverwaltung“
Missverständnis
Der Anforderungsingenieur dokumentiert die Anforderung: „Nach
der Suche nach einem Buch soll das System den Benutzer nach der
als nächstes gewünschten Aktion („weiteres Buch suchen“ oder
„ausloggen“) fragen.“ Im weiteren Gespräch zwischen
Anforderungsingenieur und Kunde stellt sich heraus, dass der
Anforderungsingenieur mit „Suche“ schon den vollständigen
Ausleihvorgang gemeint hat, während der Kunde dachte, es ginge
ausschließlich um die Buchsuche mit Hilfe einer Suchfunktion.

3 Vorbereitung des Experiments mit der GQM-Methode | 30
Widerspruch
Unvollständigkeit
Inkonsistenz
Der Anforderungsingenieur und der Kunde sprechen über den
Ausleihvorgang. Der Anforderungsingenieur dokumentiert die
Anforderung: „Der Zugriff soll nur über den Terminal möglich sein,
der in der Bibliothek zur Verfügung steht.“ Im weiteren
Gesprächsverlauf wird die Anforderung „Der Zugang zur Verwaltung
soll auch über andere Rechner zum Beispiel vom eigenen Büro aus
möglich sein.“ dokumentiert. Da der Anforderungsingenieur zur
ersten Anforderung nicht notiert hat, dass es dabei um den
Ausleihvorgang ging, stehen nun die beiden Anforderungen im
Widerspruch zueinander.
Der Anforderungsingenieur und der Kunde sprechen die Schritte und
Funktionen von der Buchsuche bis zum Abschluss des
Ausleihvorgangs durch. Später stellt sich heraus, dass dabei nur der
Erfolgsfall das heißt der Fall, dass der Benutzer ein gefundenes Buch
auch wirklich ausleihen möchte, berücksichtigt wurde. Es fehlt bis zu
dem Zeitpunkt, zu dem der Fehler erkannt wurde, eine Funktion im
Bereich der Suchergebnisliste, die der Benutzer auswählen kann,
wenn er das gefundene Buch nicht ausleihen möchte. Der
Ausleihvorgang war unvollständig.
Beim Skizzieren der Softwareoberfläche benennt der
Anforderungsingenieur die Schaltfläche zum starten der Suchfunktion
an einigen Stellen als „Buch suchen“ und an anderen wiederum als
„Buch finden“. Der Anforderungsingenieur und der Kunde wissen
zwar, was gemeint ist (es liegt also kein Missverständnis vor), aber
die Bezeichnungen sind inkonsistent.
Beispiel 2: Fehlerhaft dokumentierte Anforderungen
Mit Sicherheit gibt es weitere Arten von Fehlern wie zum Beispiel Widersprüche, die auf
Interessengegensätzen beruhen, die aber in diesem Experiment aufgrund der Übersichtlichkeit
des Systems nicht erwartet werden. Aus diesem Grund seien hier nur die oben genannten vier
Unterscheidungen von Fehlern explizit zu klassifizieren. Alle übrigen Klassen werden in einer
Klasse „sonstige Fehler“ zusammengefasst und bei der hier durchgeführten Untersuchung
nicht berücksichtigt. Zur grundsätzlichen Definition von Anforderungen wird mit der
Erarbeitung von Hypothese 2 Stellung genommen.
Damit ergibt sich die folgende erste Hypothese:
Durch die Verwendung von Fast Feedback in der Anforderungserhebung können Fehler in
den Anforderungen schon im ersten Anforderungsinterview aufgedeckt werden.
Hypothese 1: Fehler in der Anforderungserhebung

3 Vorbereitung des Experiments mit der GQM-Methode | 31
3.1.1.2 Hypothese 2 – Anzahl der Anforderungen
Bis die Anforderungserhebung inklusive der Validierung abgeschlossen ist, können
normalerweise einige Wochen und mehrere Termine zwischen Anforderungsingenieur und
Kunde vergehen. Das Feedback des Kunden muss oft in einer zweiten oder sogar dritten Serie
von Interviews gesammelt werden, bevor die gesammelten Informationen und erste Pläne der
Entwickler validiert werden können. Das kann den Fortschritt der Anforderungserhebung und
damit auch den Fortschritt des ganzen Projektes erheblich verzögern. Bis zur möglichen
Übergabe haben die Auftraggeber vielleicht das Interesse an dem Produkt verloren oder das
Produkt ist bereits veraltet. Allerdings darf auf die Validierung und damit auf das Feedback
des Kunden auch nicht verzichtet werden, da das konsequente Einbeziehen des Kunden
gerade in die frühe Entwicklungsphase ausschlaggebend für den Projekterfolg ist. Das zweite
Ziel der Verwendung von Fast Feedback soll also sein, dass Fast Feedback zur
Beschleunigung der Anforderungserhebungsphase dadurch beiträgt, dass die Validierung
schon gleich im ersten Interview parallel zur Befragung abläuft und damit bis zum Abschluss
der Validierung vermutlich weniger Termine mit dem Kunden notwendig sind. [Schn07b] Es
kann also angenommen werden, dass mehr Anforderungen pro Zeiteinheit erhoben werden,
da der Kunde durch die Erstellung von Mock-ups schon früh die Möglichkeit zum Feedback
bekommt. Das führt dazu, dass der Kunde selbst genauere Vorstellungen von der
gewünschten Software bekommt, was wiederum dazu führt dass der Kunde seine Wünsche
auch konkreter in Form von Anforderungen formulieren kann. Außerdem wird die
Validierung im Entwicklungsprozess vorgezogen, so dass der Anforderungsingenieur früher
zum Endergebnis der Anforderungserhebungsphase gelangt.
Um die Hypothese klar zu formulieren, soll im Folgenden konkret definiert werden, um was
für Anforderungen es sich bei der oben beschriebenen Annahme handelt.
Eine Anforderung in der Softwareentwicklung ist ein natürlichsprachiger Satz mit einer
Aussage über eine zu erfüllende Beschaffenheit einer Software. Bevor Anforderungen
klassifiziert werden können, muss der beschreibende Satz so weit wie möglich zerlegt
werden. In einigen dokumentierten Anforderungen verstecken sich oft eigentlich zwei oder
mehr Anforderungen. Die Anforderungen müssen so geteilt werden, dass sie auch einzeln
noch ihren Sinn behalten, das heißt oft kann eine Anforderung bei einem „und“ oder „oder“
geteilt werden, da die entsprechenden Satzteile eigentlich zwei unabhängige Funktionen
beschreiben, manchmal würde diese Trennung aber die Aussage ändern/verfälschen. Es sind
aber auch manchmal Trennungen möglich, ohne dass ein „und“ oder „oder“ den Satz trennt.
Grundsätzlich soll beim Trennen nach der Regel verfahren werden, dass ein Satz immer dann
getrennt wird, wenn seine Einzelteile noch dieselbe Aussage beschreiben wie die ursprünglich
dokumentierte Anforderung. Die einzige Ausnahme sollen Aufzählungen sein, deren
Elemente offensichtlich zusammenhängen, weil sie beispielsweise alle ein und dasselbe
Formular oder die gleiche Eingabe betreffen. Sie zählen als eine Anforderung und werden
nicht getrennt. Die Regeln zum Zerlegen von Anforderungen sollen an einigen Beispielen
erläutert werden (vgl. Beispiel 2).
„Im Anschluss soll der Administrator die Möglichkeit haben, ein weiteres Buch einzutragen
oder zur Startseite zurückzukehren.“
Daraus lassen sich zwei in sich logische Anforderungen machen:
„Im Anschluss soll der Administrator die Möglichkeit haben, ein weiteres Buch

3 Vorbereitung des Experiments mit der GQM-Methode | 32
einzutragen.“ und „Im Anschluss soll der Administrator die Möglichkeit haben, zur
Startseite zurückzukehren.“
„Nach dem Log-In sollen folgende Aktionen zur Verfügung gestellt werden: „Buch suchen“
und „Schnellausleihe“.“
Auch hier kann man sinnvoll trennen:
„Nach dem Log-In soll die folgende Aktion zur Verfügung gestellt werden: „Buch
suchen“.“ und „Nach dem Log-In soll die folgende Aktion zur Verfügung gestellt werden:
„Schnellausleihe“.“
Aber die folgende Anforderung lässt sich nicht mehr so trennen, dass die entstehenden
Teilstücke noch Sinn ergeben.
„Die Log-In Daten sollen aus Benutzernamen und Passwort bestehen.“
Die Log-In Daten können nämlich nicht nur aus einem Benutzernamen oder nur aus einem
Passwort bestehen, was aber nach einer Trennung ausgesagt würde.
Bei einer Aufzählung, bei der sich alle Elemente auf ein und dieselbe Eingabe beziehen, soll
die Anforderung auch nicht mehr getrennt werden.
„Die Standortanzeige besteht aus Angaben zu Regal, Fach und Platz.“
Eine Standortanzeige braucht immer alle drei Variablen (Regal, Fach und Platz).
Beispiel 3: Zerlegen von Anforderungen
Zunächst sollen also alle vom Anforderungsingenieur dokumentierten Anforderungen in einer
Tabelle notiert und dann in die kleinstmöglichen Einzelteile zerlegt werden. Auf alle
Anforderungen soll dann die Klassifikationen für funktionale bzw. nicht-funktionale
Anforderungen angewendet werden.
Damit die Klassifikation von jedem gleich durchgeführt werden kann, müssen die genannten
Klassen von Anforderungen nun genau definiert werden. Im Anschluss an die jeweilige
Definition soll der Bezug zum Anforderungsinterview dargestellt und eine Einschätzung
darüber abgegeben werden, ob die beschriebene Klasse von Anforderungen unter der
Verwendung von Fast Feedback eher ein geringeres oder vermehrtes Aufkommen der eben
dieser Anforderungsklasse erwarten lässt. Abschließend soll daraus die Hypothese formuliert
werden.
Anforderungen, die „vom System selbstständig ausgeführt werden sollen, Interaktionen des
Systems (Eingaben, Ausgaben) mit menschlichen Nutzern und Anforderungen zu
allgemeinen, funktionalen Vereinbarungen und Einschränkungen“ [Rup06] sind, sind
funktional. Diese Anforderungen legen also fest, wie sich die Software verhalten soll.

3 Vorbereitung des Experiments mit der GQM-Methode | 33
Nicht-funktionale Anforderungen „sollen alle jene Merkmale der Software darstellen, die
zum Gelingen der Interaktion zwischen Anwender und System maßgeblich beitragen, aber
mit der direkten Eingabe-Verarbeitung-Ausgabe-Kette von Daten nichts zu tun haben“
[Zus+04, S.225]. Sie sagen etwas darüber aus, welche Eigenschaften die Software haben
soll und werden deshalb auch als Qualitätsanforderungen bezeichnet. Nicht-funktionale
Anforderungen lassen sich in verschiedene Typen unterteilen. Einige gängige Typen sind
Benutzbarkeit, Zuverlässigkeit, Effizienz und Wartbarkeit. Aber auch technische
Anforderungen gehören zu den nicht-funktionalen Anforderungen.
Definition 2: Funktionale und nicht-funktionale Anforderungen
Es ist möglich, dass unter der Verwendung von Fast Feedback deutlich mehr nichtfunktionale
Anforderungen erhoben werden als ohne die Verwendung von Fast Feedback, da
durch das Skizzieren von Mock-ups wahrscheinlich mehr darüber gesprochen wird, wie die
Oberfläche konkret aussehen, das heißt welche Eigenschaften sie haben soll. Gerade die
Eigenschaften der Oberfläche entscheiden oftmals darüber, ob die Software ein gewisses Maß
an Benutzbarkeit aufweisen kann, weil sie dem Benutzer eine intuitive Bedienung
ermöglichen können, durch die das problemlose Einleiten der Eingabe-Verarbeitung-
Ausgabe-Kette erfolgen kann. Neben den Qualitätsanforderungen wird aber vermutlich auch
die Anzahl funktionaler Anforderungen unter der Verwendung von Fast Feedback durch die
frühzeitig mögliche Validierung höher sein. Die frühzeitige Validierung spielt dabei natürlich
sowohl bei den funktionalen als auch bei den nicht-funktionalen Anforderungen eine Rolle, so
dass der durch die Verwendung von Fast Feedback hervorgerufene Aspekt bei den nichtfunktionalen
Anforderungen wahrscheinlich deutlicher erkennbar sein wird als bei den
funktionalen Anforderungen.
Nun kommt es aber auch darauf an, ob die Anforderungen nur besprochen oder auch
tatsächlich dokumentiert wurden. Nicht-dokumentierte Anforderungen können schnell
verloren gehen und werden bei der Umsetzung der Anforderungen oft gar nicht mehr
berücksichtigt. Im folgenden Experiment soll deshalb zwischen dokumentierten und nichtdokumentierten
Anforderungen unterschieden werden.
Die Dokumentation bezeichnet die Nutzbarmachung von Informationen zur weiteren
Verwendung. Die Aufzeichnungen können als (Entscheidungs-) Grundlage für die weiteren
Arbeiten dienen.
Anforderungen können auf verschiedene Weisen (Text, Bild, Ton, Video) dokumentiert
werden. Zwei Arten der Dokumentation sind in der Anforderungserhebung üblich - erstens
die Dokumentation in Form von Text und zweitens die in Form von Mock-ups.
Definition 3: Dokumentierte- und nicht-dokumentierte Anforderungen
Interessant ist die Frage, ob, wenn bei der Verwendung von Fast Feedback wirklich mehr
Anforderungen erhoben wurden, das tatsächlich eben solche Anforderungen sind, die mit
Hilfe von Mock-ups festgehalten wurden. Denn das leichte Skizzieren von Mock-ups ist ein
wesentlicher Aspekt von Fast Feedback.
Der tatsächlich interessante Effekt, der unter der Verwendung von Fast Feedback in Bezug
auf die Anzahl der Anforderungen sichtbar werden soll, dürfte der sein, der sich auf

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

3 Vorbereitung des Experiments mit der GQM-Methode | 35
verschiedenen Gründen ohnehin schon zum Werkzeug der Kontrollgruppe bestimmt. Zudem
ist bei einem derart verbreiteten Textverarbeitungsprogramm anzunehmen, dass die
Benutzbarkeit zumindest in sofern ausreichend ist, als dass sich der Anwender bei der
Benutzung nicht in einem unzumutbaren Maß gestört fühlt.
Die erste Frage ist, ob der Anforderungsingenieur das Werkzeug ausreichend versteht, um die
Vorteile und Möglichkeiten des Werkzeugs auszunutzen. Ein Unterschied zwischen der
Lösung eines Problems mit der Benutzung von Fast Feedback und der Lösung des gleichen
Problems ohne Fast Feedback (hier mit Word) kann sich nur zeigen, wenn Fast Feedback
ähnlich gut „verstanden“ wurde. Was es nun bedeutet, ein Werkzeug „verstanden“ zu haben,
soll zur klaren Formulierung der Hypothese nun definiert werden.
Die folgenden zwei Aspekte definieren „Werkzeug verstehen“:
1. Erstens sollte vorausgesetzt werden, dass das Werkzeug auch über die ganze
Anforderungserhebungszeit hin genutzt wird. Dabei kann dem Anforderungsingenieur
zwar ein Zeitraum von fünf Minuten eingeräumt werden, in dem er sich zum Beispiel
erst einmal durch Fragen einen groben Überblick über das System verschafft, bevor er
mit der Dokumentation der Anforderungen beginnt. Aber spätestens nach fünf Minuten
Gesprächszeit sollte das Werkzeug dann zum Einsatz kommen, um die Experimente
untereinander vergleichbar zu halten, ohne dass die tatsächliche Zeit, in der das
Werkzeug benutzt wird, zu stark von der gesamten Anforderungserhebungszeit
abweicht. Dadurch würde eine ungewollte Variable in das Experiment eingebracht. Im
Einzelfall müsste dann entschieden werden, ob der entsprechende Datenpunkt bei der
Auswertung nicht mehr berücksichtigt wird. Dies könnte zum Beispiel dann der Fall
sein, wenn sich der Datenpunkt als „Ausreißer“ darstellt (vgl. hierzu Kapitel 2.2.5.2)
2. Für den zweiten Aspekt müssen die beiden Werkzeuge Fast Feedback und Word
unabhängig voneinander betrachtet werden. Es kann davon gesprochen werden, dass das
Werkzeug verstanden wurde, wenn mindestens 40% der vorher definierten
Grundfunktionen der zu entwickelnden Software (zumindest ansatzweise) dokumentiert
wurden. Bei Fast Feedback wird diese Dokumentation in Form von Use Cases, Use
Case Schritten oder Mock-ups umgesetzt, bei Word sollten entsprechende Stichworte im
Text oder in Mock-ups festgehalten werden. Außerdem müssen die Features des
jeweiligen Werkzeugs ausreichend genutzt werden. Dies ist bei Fast Feedback mit der
Erfüllung der folgenden zwei Bedingungen der Fall: Erstens muss mindestens ein
Mock-up pro Use Case erstellt werden und zweitens muss jedes Mock-up eine
Verknüpfung zu einem Use Case Schritt haben. Auch Word verfügt eine Funktion zum
Malen von Bildern, die zum Erstellen von Mock-ups verwendet werden kann. Die
Bedingung sollte hier sein, dass mindestens ein Mock-up im ganzen Dokument erstellt
wurde.
Definition 4: „Werkzeug verstehen“
Zu den Features von Fast Feedback gehören aber natürlich nicht nur das Erstellen von Mockups
und deren Zuweisung zu den entsprechenden Use Case Schritten sondern auch das
Verknüpfen von Use Case Schritten untereinander und das Abspielen einer Demo bestehend
aus den Mock-ups in chronologischer Reihenfolge. Allerdings ist mit der verkürzten
Anforderungserhebungsdauer nicht zu erwarten, dass die Möglichkeiten, Use Case Schritte
untereinander zu verknüpfen und eine Demo abzuspielen, in vollem Umfang genutzt werden

3 Vorbereitung des Experiments mit der GQM-Methode | 36
können. Deshalb seien hier nur das Erstellen von Mock-ups und deren Zuweisung zu den
entsprechenden Use Case Schritten die Indikatoren für die ausreichende Nutzung der
Features.
Die zweite Frage ist, ob der Anforderungsingenieur mit den Möglichkeiten der Software
zufrieden ist. So sollen mit Hilfe eines Fragebogens die Eindrücke des
Anforderungsingenieurs bzgl. des Werkzeugs Fast Feedback abgefragt werden.
So kommt man zur dritten Hypothese:
Die Benutzbarkeit von Fast Feedback ist gut, da das Werkzeug mindestens genauso
verständlich ist wie Word und sich der Anforderungsingenieur unterstützt fühlt.
3.1.2 Einschränkungen auf das Experiment
Hypothese 3: Benutzbarkeit von Fast Feedback
Dieses Kapitel zeigt Einschränkungen auf, die in Bezug auf das durchzuführende Experiment
unter anderem auch deshalb gemacht werden müssen, um negative Auswirkungen auf die
Gültigkeit der Ergebnisse gering zu halten. Auf genau diese Einflüsse wird dann in der
Analyse und Interpretation der Ergebnisse eingegangen.
3.1.2.1 Einschränkungen bzgl. der Rahmenbedingungen
1. Software lässt sich anhand von Kriterien in verschiedene Arten unterteilen. Nimmt man
die Aufteilung nach der Beziehung der Software zum Anwender vor, so gibt es auf der
einen Seite die Software, die für den Anwender direkt sichtbar und bedienbar ist
(Anwendersoftware) und auf der anderen Seite die Software, die für den Anwender nicht
direkt sichtbar ist (Systemsoftware). Häufig will ein Kunde eine Anwendersoftware, das
heißt eine Software mit einer Oberfläche, entwickeln lassen. Gerade die
Anwendersoftware ist die Software, deren Entwicklung durch die Verwendung des
Werkzeugs Fast Feedback in der Anforderungserhebung unterstützt werden kann. Denn
zur Darstellung dieser Oberfläche verwendet man die Mock-ups. Wenn keine Oberfläche
benötigt würde, gäbe es mit den Mock-ups kaum etwas darzustellen. Die Funktionen von
Fast Feedback könnten nicht im vollem Umfang genutzt werden, es wären nicht die
entsprechenden Effekte zu erwarten und der Einsatz von Fast Feedback würde keinen
Sinn machen. Aus diesem Grund bezieht sich das folgende Experiment einzig und allein
auf Software, die eine Oberfläche benötigt.
2. Ein reales Kundengespräch dauert in der Regel um die neunzig Minuten. Es ist
unwahrscheinlich, dass sich ausreichend Studenten als Probanden finden, wenn sie der
realistischen Kundengesprächsdauer entsprechend viel Zeit investieren müssen. Die
Simulation der Anforderungserhebungen soll in diesem Experiment deshalb einen zeitlich
eingeschränkten Rahmen von dreißig Minuten bekommen. Außerdem sollte die Software,
zu der im Experiment Anforderungserhebungen simuliert werden sollen, eine
überschaubare Menge an Funktionen haben, um in der gekürzten Kundengesprächszeit
zumindest die wesentlichen Funktionen der Software durchsprechen zu können. Die Wahl
des zeitlichen Rahmens pro Anforderungserhebung und die Wahl des

3 Vorbereitung des Experiments mit der GQM-Methode | 37
Softwarebeispiels, zu dem Anforderungserhebungen simuliert werden sollen, wurde mit
Hilfe eines Probedurchlaufes getroffen. In diesem wurde zunächst eine Gesprächsdauer
von zwanzig Minuten zur Erhebung der Anforderungen zum SE-Bibliothekbeispiel (zur
genauen Beschreibung des SE-Bibliothekbeispiels vgl. Kapitel 3.6) vereinbart. Obwohl
das SE-Bibliothekbeispiel aufgrund seiner Übersichtlichkeit geeignet schien, zeigte sich,
dass die Zeit nicht ganz ausreicht, um alle Funktionen des Werkzeugs nutzen und um alle
wesentlichen Funktionen der zu entwickelnden Software in Form von Use Cases
aufnehmen zu können. Unter der Berücksichtigung der Menge der wesentlichen Szenarien
der Software, zu der beispielhaft Anforderungen erhoben werden sollen, wurde die
Gesprächsdauer auf dreißig Minuten festgelegt. Ob in diesem Zeitrahmen der Anspruch
an eine optimale Ausnutzung der mit dem Werkzeug gebotenen Möglichkeiten erfüllt
werden kann, hängt natürlich aber auch von den folgenden Faktoren ab: Wissensstand des
Probanden bzgl. Anforderungserhebung, Use Cases etc., Auffassungsgabe des Probanden
bzgl. der Benutzung von Fast Feedback. Diesen Einflüssen kann aber mit einer geeigneten
Auswahl der Probanden entgegengewirkt werden.
3.1.2.2 Einschränkungen bzgl. der Probanden und der Experiment- und Kontrollgruppe
1. Natürlich kann ein erfahrener Anforderungsingenieur von vorn herein bessere Ergebnisse
erzielen, als ein Einsteiger. In diesem Experiment sollte man für eine hohe Gültigkeit der
Ergebnisse, einen annährend einheitlichen oder zumindest einen möglichst ähnlichen
Wissensstand der Probanden annehmen können. Deshalb sollen die Teilnehmer zunächst
ausschließlich aus dem universitären Umfeld und insbesondere aus dem Fachbereich
Informatik stammen. Dabei kann es sich sowohl um Informatikstudenten als auch um
Mitarbeiter des Instituts handeln. Vorraussetzung für die Teilnahme am Experiment
ist, schon etwas über Anforderungserhebungen in einer der vom Fachgebiet Software
Engineering angebotenen Vorlesungen gehört zu haben. Vorkenntnisse und Erfahrungen
der Probanden sollen im Anschluss an das Experiment abgefragt werden, um einschätzen
zu können, ob die Ergebnisse miteinander vergleichbar sind oder die Voraussetzungen der
Probanden zusätzlich zum Werkzeug Fast Feedback eine weitere Variable darstellen, die
bei der Auswertung der Ergebnisse berücksichtigt werden muss. Um aber auch einen
Bezug zur realen Softwareentwicklung außerhalb eines universitären Umfelds
herzustellen zu können, kann das Experiment, sofern dazu eine Möglichkeit besteht,
zusätzlich auch in einer echten Softwarefirma durchgeführt werden. Man könnte dann
annehmen, dass die Mitarbeiter der Entwicklungsabteilung dann wiederum einen
ähnlichen Wissensstand vorzuweisen haben.
2. Da das zu evaluierende Werkzeug Fast Feedback auf Use Cases und Mock-ups basiert,
wäre es denkbar, den Probanden der Kontrollgruppe als Hilfsmittel ebenfalls Use Cases
und Mock-ups benutzen zu lassen - mit dem Unterschied, dass sie dafür außer einem
leeren Dokument nichts zur Verfügung gestellt bekämen. Da diese Methoden aber die
wesentlichen Bestandteile von Fast Feedback sind, scheint es doch realitätsnaher und vor
allen Dingen interessanter zu sein, die Experimentgruppe mit einer Kontrollgruppe zu
vergleichen, die keine Hilfestellungen bzgl. zu verwendenden Anforderungserhebungsmethoden,
sondern als Hilfsmittel nur ein leeres Dokument zur Verfügung gestellt
bekommt. Zwar lässt die letztere Vorgehensweise befürchten, dass am Ende die
sichtbaren Effekte vielleicht hauptsächlich auf die Verwendung der Methoden Use Cases
und Mock-ups zurückzuführen ist, allerdings würden weitere Effekte natürlich auch
darüber hinaus deutlich werden können. Die Frage ist, ob der Umstand, dass die
Kontrollgruppe keine Use Cases oder Mock-ups verwenden muss, eine neue Variable im

3 Vorbereitung des Experiments mit der GQM-Methode | 38
Experiment darstellt oder ob sie unter die Variable Fast Feedback fällt. Da in der Realität
vermutlich eher nach dem Prinzip „einfach mal anfangen“ vorgegangen wird, ohne dass
tatsächlich auch bestimmte Methoden vorgegeben oder selbstständig genutzt werden,
scheint es doch sinnvoll, die Kontrollgruppe das Experiment realitätsnah ohne konkrete
Vorgaben zu durchführen und sie selber entscheiden zu lassen, ob sie eine bestimmte
Methode verwenden wollen oder nicht.
3.2 Ziele und GQM-Modell
3.2.1 Konkretisierung der Ziele und Hypothesen mit Hilfe von Abstraction Sheets
Aus den erarbeiteten Hypothesen lassen sich die folgenden Ziele bzgl. Fast Feedback ableiten,
die es gilt, im durchzuführenden Experiment zu überprüfen:
1. Erkennung fehlerhaft dokumentierter Anforderungen
2. Dauer der Anforderungserhebung senken
3. Benutzbarkeit von Fast Feedback feststellen.
Zu diesen Zielen sollen nun mit Hilfe von Abstraction Sheets zugehörige wichtige
Informationen wie Qualitäts- und Einflussfaktoren und Ausgangs- und Eingangshypothesen
zugeordnet werden.
Ziel: Erkennung fehlerhaft dokumentierter Anforderungen
Ziel: Zweck: Qualitätsaspekt: Beobachtungsgegenstand: Perspektive:
1.1 Erkenne fehlerhaft Anforderungserhebung Anforderungsingenieur/
dokumentierte
Anforderungen
Projektmanager
Qualitätsfaktoren:
Einflussfaktoren:
• Anzahl der erkannten Fehler
o Unvollständigkeiten
o Missverständnisse
o Widersprüche
o Inkonsistenzen
• Zeitpunkt des Erkennens
(hier nicht berücksichtigt, Begründung
folgt im nächsten Absatz)
Ausgangshypothesen:
• Im ersten Interview wird kein(e) bis
ein(e)
o Unvollständigkeit
o Missverständnis
o Widerspruch
o Inkonsistenz erkannt.
• Verwendung von Fast Feedback
Einflusshypothesen:
Tabelle 3: Abstraction Sheet zu Hypothese 1
• Unter der Verwendung von Fast
Feedback werden mehr Fehler schon im
ersten Interview erkannt.

3 Vorbereitung des Experiments mit der GQM-Methode | 39
Ein Experiment, das sich für jeden Probanden über mehrere Termine erstreckt, ist in einem
universitären Umfeld schwer umsetzbar. Es wird aber vermutet, dass Fehler, die ohne die
Verwendung von Fast Feedback entstehen, frühestens im zweiten Kundengespräch
aufgedeckt werden. Die Durchführung mehrerer Termine zur Anforderungserhebung wäre
deshalb grundlegend, um Messungen bzgl. des Erkennungszeitpunktes durchzuführen. Aus
diesem Grund wird im Rahmen dieses Experiments auf die weitere Untersuchung des
Qualitätsfaktors „Zeitpunkt des Erkennens“ verzichtet.
Der Qualitätsfaktor „Anzahl der erkannten Fehler“ soll im Hinblick auf den Einflussfaktor
„Verwendung von Fast Feedback“ aber genau untersucht werden. Dazu ergibt sich das
zweiseitige Testproblem mit der folgenden Null- bzw. Alternativhypothese:
Alternativhypothese H1,1 zu Ziel 1.1:
Im ersten Interview gibt es einen Unterschied beim Erkennen von Fehlern zwischen der
Anforderungserhebung mit und der ohne der Verwendung von Fast Feedback.
Nullhypothese H0,1 zu Ziel 1.1:
Im ersten Interview gibt es keinen Unterschied beim Erkennen von Fehlern zwischen der
Anforderungserhebung mit und der ohne der Verwendung von Fast Feedback.
Allerdings gilt es in der Analyse der Ergebnisse zu berücksichtigen, dass natürlich keine
Fehler erkannt werden können, wenn erst gar keine gemacht werden. Es muss diskutiert
werden, was das für die Interpretation der Ergebnisse bedeutet.

3 Vorbereitung des Experiments mit der GQM-Methode | 40
Ziel: Dauer der Anforderungserhebungsphase senken
Ziel: Zweck: Qualitätsaspekt: Beobachtungsgegenstand: Perspektive:
1.2 Erhöhe Anzahl der Anforderungserhebung Anforderungsingenieur/
Anforderungen
pro Zeiteinheit
Projektmanager
Qualitätsfaktoren:
Einflussfaktoren:
• Anzahl dokumentierter Anforderungen
pro Zeiteinheit
• Anteil dokumentierter nicht-funktionaler
Anforderungen pro Zeiteinheit
Ausgangshypothesen:
• In einem 30-minütigen Kundengespräch
werden 30 Anforderungen 7 wie oben
definiert erhoben.
• Ein Drittel der in dem 30-minütigen
Kundengespräch erhobenen
Anforderungen sind nicht-funktionale
Anforderungen wie oben definiert.
[Hen08]
• Verwendung von Fast Feedback
Einflusshypothesen:
Tabelle 4: Abstraction Sheet zu Hypothese 2
• Unter der Verwendung von Fast
Feedback werden in einem 30-minütigen
Kundengespräch 30% mehr
Anforderungen wie definiert erhoben.
• Unter der Verwendung von Fast
Feedback sind unter der Annahme, dass
zwei Drittel der hinzugekommenen
Anforderungen nicht-funktional sind,
40% der in dem 30-minütigen
Kundengespräch erhobenen
Anforderungen nicht-funktional nach
obiger Definition.
Da Fast Feedback durch seine Mock-up Funktion sehr gut zur Darstellung nicht-funktionaler
Anforderungen geeignet ist, kann vermutet werden, dass die unter der Verwendung von Fast
Feedback mehr erhobenen Anforderungen zum größten Teil nicht-funktionale sind. Diese
Vermutung wurde bereits im Abstraction Sheet berücksichtigt und soll sich auch in der Null-
bzw. Alternativhypothesen widerspiegeln:
Alternativhypothese H1,2a zu Ziel 1.2:
Es besteht ein Unterschied in der Anzahl der dokumentierten Anforderungen zwischen der
Anforderungserhebung mit und der ohne die Verwendung von Fast Feedback.
Nullhypothese H0,2a zu Ziel 1.2:
Es besteht kein Unterschied in der Anzahl der dokumentierten Anforderungen zwischen der
Anforderungserhebung mit und der ohne die Verwendung von Fast Feedback.
7 Die Annahme, dass durchschnittlich eine Anforderung pro Minute (Zerlegung wie oben definiert
vorausgesetzt) erhoben wird, basiert auf Erfahrungswerten, die bei der Beobachtung von Kundengesprächen
gesammelt wurden.

3 Vorbereitung des Experiments mit der GQM-Methode | 41
Alternativhypothese H1,2b zu Ziel 1.2:
Es lässt sich ein Unterschied zwischen dem Anteil nicht-funktionaler dokumentierter
Anforderungen mit und ohne Verwendung von Fast Feedback feststellen.
Nullhypothese H0,2b zu Ziel 1.2:
Es lässt sich kein Unterschied zwischen dem Anteil nicht-funktionaler dokumentierter
Anforderungen mit und ohne Verwendung von Fast Feedback feststellen.
Ziel: Benutzbarkeit von Fast Feedback feststellen
Ziel: Zweck: Qualitätsaspekt: Beobachtungsgegenstand: Perspektive:
1.3 Untersuche Benutzbarkeit Werkzeuge
Anforderungs-
(Fast Feedback und Word) ingenieur
Qualitätsfaktoren:
Einflussfaktoren:
• Verständlichkeit des Werkzeugs (vgl. Def.
„Werkzeug verstehen“)
⇒ Grundfunktionen werden zu mind. 40%
dokumentiert
⇒ Features werden genutzt
• Beurteilung des Anforderungsingenieurs
⇒ zur Bedienung,
⇒ zum zweckdienlichen Aufbau und
⇒ zum Gefallen insgesamt
mit der Schulnote „ausreichend“ oder
besser.
Ausgangshypothesen:
• Word ist verständlich nach Def.
• Anforderungsingenieur fühlt sich von
Word unterstützt, da Beurteilung von Word
in der Anforderungserhebung
⇒ zur Bedienung „gut“,
⇒ zum zweckdienlichen Aufbau
„ausreichend“ und
⇒ zum Gefallen insgesamt „befriedigend“
ausfällt.
Tabelle 5: Abstraction Sheet zu Hypothese 3
• Verwendung des Werkzeugs Fast
Feedback oder Word
Einflusshypothesen:
• Fast Feedback ist verständlich nach
Def.
• Anforderungsingenieur fühlt sich von
Fast Feedback mehr unterstützt, da
Beurteilung zu Fast Feedback
⇒ zur Bedienung mindestens auch
„gut“,
⇒ zum zweckdienlichen Aufbau „gut“
und
⇒ zum Gefallen insgesamt „gut“
ausfällt.

3 Vorbereitung des Experiments mit der GQM-Methode | 42
Alternativhypothese H1,3a zu Ziel 1.3:
Die Benutzbarkeit von Fast Feedback ist gut, da das Werkzeug mindestens genauso
verständlich ist wie Word.
Nullhypothese H0,3a zu Ziel 1.3:
Die Benutzbarkeit von Fast Feedback ist schlecht, da das Werkzeug Fast Feedback weniger
verständlich ist als Word.
Alternativhypothese H1,3b zu Ziel 1.3:
Die Benutzbarkeit von Fast Feedback ist gut, da sich der Anforderungsingenieur bei der
Verwendung von Fast Feedback mehr unterstützt fühlt als bei der Verwendung von Word.
Nullhypothese H0,3b zu Ziel 1.3:
Die Benutzbarkeit von Fast Feedback ist schlecht, da der Anforderungsingenieur sich bei
der Verwendung von Fast Feedback genauso oder weniger unterstützt fühlt als bei der
Verwendung von Word.
3.2.2 GQM-Modell - Ziele, Fragen, Metriken
Mit Hilfe der Abstraction Sheets konnten die Hypothesen und damit die Ziele deutlich
herausgearbeitet werden und sind nun konkret genug, um über Fragen zu Metriken zu
kommen. In der folgenden Tab.6 wurden die Ziele, Fragen und Metriken übersichtlich in
einer einem GQM-Modell zusammengefasst.

3 Vorbereitung des Experiments mit der GQM-Methode | 43
Ziele
(Ebene 1)
Ziele
(Ebene 2)
Fragen
Metriken
Skalenniveaus
G1.1 Verbessere die
Erkennung fehlerhaft
dokumentierter
Anforderungen
in der
Anforderungserhebung
aus der
Perspektive des
Anforderungsingenieurs/
Projektmanagers.
Q1.1 Werden unter der
Verwendung von Fast
Feedback mehr
fehlerhaft
dokumentierte
Anforderungen im
ersten Kundengespräch
erkannt?
M1.1 Miss die Anzahl
der erkannten
fehlerhaft
dokumentierten
Anforderung laut
Definition pro
Kundengespräch
(Gesprächsdauer 30
Minuten).
Verhältnisskala
G1 Untersuche die Zweckdienlichkeit von Fast Feedback
G1.2 Erhöhe die
Anzahl der Anforderungen pro
Zeiteinheit in der
Anforderungserhebung aus der
Perspektive des Anforderungsingenieurs/
Projektmanagers.
Q1.2.1 Werden
unter der
Verwendung
von Fast
Feedback mehr
Anforderungen
schon im
ersten Kundengespräch
dokumentiert?
M1.2.1 Miss
die Menge
aller dokumentierten
Anforderungen
laut Definition.
Verhältnisskala
Q1.2.2 Werden
unter der
Verwendung
von Fast
Feedback im
Verhältnis zur
Gesamtmenge
erhobener
Anforderungen
mehr nichtfunktionale
dokumentiert?
M1.2.2 Miss
die Menge
aller dokumentierten
Anforderungen
laut Definition
und berechne
das Verhältnis
der nicht-fkt.
Anforderungen
gemessen an
der
Gesamtmenge
der dokumentierten
Anforderungen
Verhältnisskala
Tabelle 6: GQM-Modell
G1.3 Untersuche die
Benutzbarkeit
von Werkzeugen in der
Anforderungserhebung aus der
Perspektive des
Anforderungsingenieurs/
Projektmanagers.
Q1.3.1 Hat der
Anforderungsingenieur
das
Werkzeug
verstanden?
M1.3.1
Überprüfe im
Anschluss an
die Erhebung
das
Verständnis
des
Anforderungsingenieurs
für
das jeweilige
Werkzeug
anhand der
Definition
„Werkzeug
verstanden“.
Nominalskala
Q1.3.2 Fühlt
sich der
Anforderungsingenieur
von
Fast Feedback
unterstützt?
M1.3.2
Befrage den
Anforderungsingenieur
im
Anschluss an
die Erhebung
zur
Benutzbarkeit
des jeweilige
Werkzeugs in
der
Anforderungserhebung
mit Hilfe eines
Fragebogens.
Ordinalskala

3 Vorbereitung des Experiments mit der GQM-Methode | 44
3.3 Mögliche Einflüsse auf die Gültigkeit der Ergebnisse (Störvariablen)
Gerade in der Softwareentwicklung sind Experimente und empirische Untersuchungen häufig
schwierig. Wenn Menschen miteinander kommunizieren, können immer viele Faktoren, wie
zum Beispiel das Vorwissen des Kunden, Einfluss auf die Ergebnisse des Gesprächs nehmen.
Auch in der Anforderungserhebung sind natürlich einige Variablen zu finden, die
möglicherweise Einfluss auf die Ergebnisse des Experiments haben könnten. Auf der einen
Seite sind da die unabhängigen Variablen, von denen einige bewusst festgehalten und andere
eingestellt werden. Die festgehaltenen unabhängigen Variablen im durchzuführenden
Experiment sind beispielsweise der gleichbleibende Kunde und im gewissen Maße auch sein
Verhalten (Drehbuch) und die Erfahrung der Probanden. Die bewusst regulierte unabhängige
Variable soll das Werkzeug sein. Diese unabhängige Variable wird gezielt reguliert, um im
Experiment die Auswirkungen auf die abhängigen Variablen beobachten zu können. Zu den
abhängigen Variablen gehören die Anzahl der Anforderungen und die Anzahl der Fehler in
der Anforderungserhebung. Zur Überprüfung der oben genannten Hypothesen ist es
unbedingt erforderlich, dass möglichst alle Störvariablen vermieden bzw. zumindest
bestmöglich eingegrenzt werden, um sicherzustellen, dass die einzige unabhängige Variable,
die sich in dem Experiment auf die abhängigen Variablen auswirkt, das Werkzeug selbst ist.
Es stellt sich zum Beispiel die Frage, wie die einzelnen Rollen im Experiment zu besetzen
sind, damit das Werkzeug die einzige regulierbare unabhängige Variable bleibt. So kann
nämlich der Kunde mit seinen Antworten und Entscheidungen im Anforderungsinterview
ganz entschieden Einfluss auf das Ergebnis nehmen. Um zu gewährleisten, dass der Einfluss
auf das Gespräch in allen Anforderungsinterviews der gleiche ist, soll die Rolle des Kunden
in allen Interviews mit der gleichen Person besetzt werden, die sich dann an eine Art
Drehbuch bzw. an bestimmte Regeln hält, die Ihre Aussagen und Reaktionen betreffen. Das
Drehbuch soll bewirken, dass der Kunde keinem Lernprozess unterliegt, in dem er
Erfahrungen aus frühen Interviews in spätere einbringt. Der Kunde soll so jedes der
Anforderungserhebungsgespräche führen können, als wäre es das erste. Unterschiedliche
Personen in dieser Rolle wären zwar realistischer und würden nicht Gefahr laufen, in frühen
Interviews Gelerntes später anzuwenden, da sie nur ein Interview durchführen würden. Sie
würden aber wahrscheinlich trotz Drehbuch unterschiedlich (re-)agieren, weil auch ein
Drehbuch unterschiedliche Interpretationen zulässt. Letztendlich würde man nicht mehr sehen
können, ob unterschiedliche Ergebnisse durch die Variable Werkzeuge oder die Variable
Kunde entstanden sind. Um dem entgegenzuwirken, dass der Kunde mit jedem
durchgeführten Interview im Rahmen des Experiments dazulernt, könnte man die ersten
Interviewergebnisse verwerfen. Damit würde man die Experimente, in denen die Person in
der Rolle des Kunden bzgl. dem von ihr gewünschten System noch hinzulernen würde, aus
der Wertung nehmen. Die fehlende Variabilität des Kunden in dem in dieser Arbeit
durchgeführten Experiment soll dann in der Bewertung der Gültigkeit der Ergebnisse noch
mal aufgegriffen werden.
In der Realität kennen sich die Kunden in der Regel selbst nicht mit dem Entwickeln von
Software aus. Da man aber keine Kenntnisse bzgl. Softwareentwicklung voraussetzen kann,
sollen die Ausnahmekunden, die Vorkenntnisse mitbringen, in diesem Experiment nicht
berücksichtigt werden. Die Person, die den Kunden in diesem Experiment darstellt, spielt also
einen Kunden ohne Softwareentwicklungshintergrund. Damit werden mögliche Einflüsse
durch unterschiedlich gute Vorkenntnisse im Bereich Softwareentwicklung von vornherein
bestmöglich eingegrenzt.

3 Vorbereitung des Experiments mit der GQM-Methode | 45
Die Experimentleiterin wird auch die Rolle der Kundin in jedem Anforderungsinterview
einnehmen. Diese Rollenverteilung stellt sicher, dass die Voraussetzungen für jedes
Anforderungsinterview die gleichen sind und das Werkzeug die einzige regulierbare
unabhängige Variable im Experiment bleibt. Auf mögliche Konflikte, die dadurch entstehen
können, dass die Experimentleiterin und die Kundin ein und dieselbe Person sind, wird in der
Interpretation der Ergebnisse eingegangen.
Die Rolle des Anforderungsingenieurs muss selbstverständlich mit wechselnden Personen
besetzt werden, da die Effekte des Werkzeugs ja unabhängig von der (Re-)Aktion des
Anforderungsingenieurs sichtbar werden sollen. Allerdings sollte auch der
Anforderungsingenieur gewisse Vorraussetzungen in das Experiment mitbringen, da auch
seine Vorkenntnisse und Erfahrungen bzgl. Anforderungserhebungen Einfluss auf die
Ergebnisse der Messung haben können. Um dem vorzubeugen, müssen die
Experimentteilnehmer, die für die Rolle des Anforderungsingenieurs ausgewählt werden
möglichst ähnliche Vorkenntnisse haben. Die Suche nach geeigneten Teilnehmern sollte sich
also an Informatikstudenten richten, die bereits Vorlesungen im Bereich des Software
Engineering gehört hatten und damit zumindest theoretisch über den Ablauf einer
Anforderungserhebung und über den Aufbau von Use Cases Bescheid wussten. Allein mit der
Absolvierung eines im Studienplan eines Informatikers ohnehin vorgesehen
Softwareprojektes hat der Student schon eine zumindest einmalige Erfahrung mit einer
Anforderungserhebung gemacht. Damit die Voraussetzungen noch mehr übereinstimmen, soll
jeder Proband eine einheitliche Einführung zu Beginn des Interviews und auch während des
Interviews jederzeit die Möglichkeit für technische Fragen bekommen.
Die spätere Auszählung und Klassifizierung der Anforderungen soll durch die
Experimentleiterin durchgeführt werden. Trotz einer genauen Definition, wie Anforderungen
zu zählen und zu klassifizieren sind, kann es vor allen Dingen in Grenzfällen Einflüsse durch
die subjektive Einschätzung der Experimentleiterin geben. Dieses Problem kann
beispielsweise durch eine zu ungenaue Definition hervorgerufen werden. Um die Definition
zu prüfen und subjektive Einflüsse der Experimentleiterin auszuschließen, kann ein Teil der
Auszählung und Klassifizierung von einer zweiten Person wiederholt werden. Damit kann
kontrolliert werden, ob ein Experimentleitereffekt, indem Anforderungen subjektiv
klassifiziert werden, eingetreten ist. Zur Kontrollzählung steht ein Mitarbeiter des
Fachgebietes Software Engineering zur Verfügung, der ausreichend über die vorgesehene Art
und Weise der Klassifikation in Kenntnis gesetzt werden muss.
Einflüsse sind auch durch die Form der Dokumentation der Anforderungen in den
verschiedenen Gruppen (mit bzw. ohne Fast Feedback) möglich. So sollten die Teilnehmer
beider Gruppen eine möglichst identische Form der Dokumentation vorgeschrieben
bekommen, um keine zusätzliche Variable im Experiment zuzulassen. Alle Teilnehmer sollen
Ihre Notizen elektronisch vornehmen. Das erleichtert die Auswertung und schafft gleiche
Voraussetzungen für alle Probanden. Fast Feedback muss wegen der Möglichkeit zur
Skizzierung von Mock-ups auf einem Tablet PC ausgeführt werden. Dazu stehen die
automatische Schrifterkennung oder eine Tastatur zur Verfügung und ein Stift zum Klicken
und Zeichnen. Die Kontrollgruppe soll also die gleichen Voraussetzungen erhalten und
bekommt deshalb ebenfalls den Tablet PC zur Verfügung gestellt, allerdings nicht mit dem zu
evaluierenden Werkzeug Fast Feedback, sondern mit einem leeren Word-Dokument, auf dem
ebenfalls geschrieben und gezeichnet werden darf. So wird die Struktur des Werkzeugs bei
dem Experiment in den Vordergrund gerückt und nicht zum Beispiel ungewollt die
automatische Schrifterkennung evaluiert.

3 Vorbereitung des Experiments mit der GQM-Methode | 46
Insgesamt gesehen soll es möglichst nur die eine unabhängige Variable „Werkzeug“
geben. Jede weitere regulierbare Variable im Experiment kann zur Störvariablen werden und
die Ergebnisse beeinflussen. Diese Einflüsse müssen bei der Vorbereitung und der
Vorgehensweise berücksichtigt und gegebenenfalls bei der Analyse und Interpretation der
Ergebnisse diskutiert werden.
3.4 Sonstige Vorbereitungen
3.4.1 Probandensuche
Die Probandensuche fand im universitären Umfeld statt. Um den Studenten oder
Institutsmitarbeitern einen Anreiz zur Teilnahme zu geben, wurde das Experiment als
Wettbewerb beworben. Die Studenten sollten als zusätzliche Motivation die Möglichkeit
bekommen, gegeneinander anzutreten, indem sie ihr theoretisches Wissen praktisch
anwenden. Die Probanden wurden gezielt in Vorlesungen und unter den Hilfswissenschaftlern
des Fachgebietes Software Engineering gesucht. Der Wettbewerb wurde darüber hinaus mit
Hilfe von Aushängen und Foreneinträge bekannt gemacht.
3.4.2 Software und Technik
Während der Experimentdurchführung sollen von der Experimentleiterin aufgrund ihrer
Doppelrolle keine Formulare oder ähnliches ausgefüllt werden. Die Rolle als Kundin erfordert
seine volle Aufmerksamkeit. Ohne die Protokollierung des Anforderungsinterviews würde
damit jegliche Auswertungsgrundlage fehlen. Um das Anforderungsinterview wirklich genau
protokollieren zu können, müssen sowohl der Ton als auch die Bildschirmaktivitäten
aufgezeichnet werden. Zur bestmöglichen Ton- und Bildschirmaufnahme müssen die dafür
notwendige Software (z.B. Camtasia) und Technik (Mikrofon) zur Verfügung stehen. Beides
muss vor der Durchführung der Experimente ausgiebig getestet werden. In einem ruhigen
Raum muss die Tonaufzeichnung ausprobiert und die bestmögliche Lautstärkeeinstellung
gefunden werden. Es sollte großen Wert darauf gelegt werden, dass die Aufzeichnung optimal
und störungsfrei ist, um eine korrekte Auswertung der Ergebnisse gewährleisten zu können.
Ein zusätzlicher Bildschirm sollte eingerichtet werden, um es sowohl dem
Anforderungsingenieur (und Proband) als auch der Kundin (und Experimentleiterin) leichter
zu machen, dem jeweils anderen etwas zu zeigen.
Des Weiteren muss sichergestellt werden, dass der Tablet PC zur Durchführung des
Experiments und insbesondere zur Ton- und Bildschirmaufnahme über ausreichende
Speicherkapazitäten verfügt. Gegebenenfalls sollte zusätzlich ein externes Speichermedium
bereitgestellt werden.
3.5 Messplan
3.5.1 Schritte vor der Messung
Zunächst muss klar werden, wie viele Probanden für die Rolle der Anforderungsingenieurs
benötigt werden und welcher Gruppe jeder Proband zugeteilt wird. Dazu folgen in diesem

3 Vorbereitung des Experiments mit der GQM-Methode | 47
Kapitel die konkreten Berechnungen des Stichprobenumfangs und die Zuteilungen zu den
Gruppen mit Hilfe von Zufallsziehungen.
3.5.1.1 Bestimmung des Stichprobenumfangs
Die Bestimmungen des Stichprobenumfangs basieren auf einigen Annahmen (z.B. zur
Verteilung der Zufallsvariable und zum Erwartungswert) und können deshalb nur als
Richtwert gelten. Mit Hilfe von statistischen Tests kann dann im Nachhinein festgestellt
werden, ob der Stichprobenumfang tatsächlich ausgereicht hat.
Die Berechnungen sollen im Vorfeld nur zu den GQM-Zielen 1.1 und 1.2 durchgeführt
werden, da Ziel 1.3 nur zur Einschätzung der Gültigkeit der Ergebnisse der ersten beiden
Ziele verfolgt wird und damit die Wahl des Stichprobenumfangs im wesentlichen aus den
Berechnungen zu den ersten beiden Zielen basieren sollte.
Das Ergebnis der Berechnungen bezieht sich dabei immer auf die Experimentgruppe.
Optimalerweise sollte der gleiche Stichprobenumfang auch für die Kontrollgruppe gewählt
werden. Geplant ist nämlich, die Ergebnisse mit Hilfe eines Ein- oder Zweistichproben t-Tests
zu prüfen, wobei die Freiheitsgrade den Wert für das Quantil der t-Verteilung beeinflussen.
Wird der Stichprobenumfang für beide Gruppen identisch gewählt, werden die n+m-2
Freiheitsgrade maximal und der Wert für das Quantil der t-Verteilung und somit die Grenze
zur Signifikanz der Ergebnisse geringer. Der geringere Stichprobenumfang einer Gruppe
könnte also bewirken, dass der Stichprobenumfang insgesamt nicht ausreicht, um eine
Signifikanz der Ergebnisse feststellen zu können.
Alternativhypothese H1,1 zu Ziel 1.1:
Im ersten Interview gibt es einen Unterschied beim Erkennen von Fehlern zwischen der
Anforderungserhebung mit und der ohne der Verwendung von Fast Feedback.
Nullhypothese H0,1 zu Ziel 1.1:
Im ersten Interview gibt es keinen Unterschied beim Erkennen von Fehlern zwischen der
Anforderungserhebung mit und der ohne der Verwendung von Fast Feedback.
Aus Erfahrung nimmt man an, dass im ersten Anforderungsinterview ohne die Verwendung
von Fast Feedback null bis ein Fehler erkannt werden. Dagegen wird vermutet, dass mit dem
Einsatz von Fast Feedback mehr (also mindestens zwei) Fehler im ersten
Anforderungsinterview erkannt werden. Sei Y die Zufallsvariable, die jeder
Anforderungserhebung der Experimentgruppe eine Anzahl von Fehlern zuordnet. Es wird
weiter angenommen, dass die Zufallsvariable Y normalverteilt ist, was nach Durchführung des
Experiments aber noch zu prüfen wäre. Die Berechnung des Stichprobenumfangs erfolgt über
den Erwartungswert einer normalverteilten Grundgesamtheit (vgl. Kapitel 2.2.3.1). Die
Abweichungen von dem Sollwert sind dabei sowohl nach unten als auch nach oben
unerwünscht bzw. bedeutend, so dass hier eigentlich ein zweiseitiges Testproblem vorliegt.
Für die Bestimmung des Stichprobenumfangs soll aber die Anwendung des einseitigen

€
€
€
3 Vorbereitung des Experiments mit der GQM-Methode | 48
Testproblems genügen. Da in der Experimentgruppe für die Anzahl der Fehler ein Wert
größer als µ 0 = 2 erwartet wird, formuliert man das Testproblem wie folgt.
Sei Y Zufallsvariable wie oben definiert. Testet man die Nullhypothese H0,1 : µ ≤ µ 0 mit dem
Erwartungswert µ 0 = 2 , dem unbekanntem Parameter µ ∈ und der geschätzten Varianz
€
σ
€
€
€
2 = 2,25 gegen die entsprechende Alternativhypothese H1,1 : µ > µ 0 zum gewählten
Signifikanzniveau und gibt an der Stelle µ 1 = 3,5 eine Wahrscheinlichkeit
für den Fehler 2. Art vor, so muss die Stichprobengröße, um beide Fehler
einhalten zu können,
€
€
n ≥ u0,975 + u 2
⎛⎛ ( 0,95)⋅
1,5 ⎞⎞
⎜⎜
⎜⎜
⎟⎟
⎝⎝ 3,5 − 2 ⎟⎟ =
⎠⎠
1,96 +1,645
2
⎛⎛ ( )⋅ 1,5 ⎞⎞
⎜⎜
⎟⎟ =
⎝⎝ 1,5 ⎠⎠
5,408
2
⎛⎛ ⎞⎞
⎜⎜ ⎟⎟ =12,998
⎝⎝ 1,5 ⎠⎠
sein. Als Richtwert sollte zu dieser Hypothese also mindestens eine Stichprobe vom Umfang
n=13 für die Experimentgruppe und optimalerweise auch für die Kontrollgruppe gezogen
werden. Man stellt mit dem oben aufgestellten Testproblem sicher, dass man sich höchstens
mit der Wahrscheinlichkeit fälschlicherweise für die Alternative H1,1 entscheidet,
obwohl H0,1 vorliegt, und dass man sich höchstens mit der Wahrscheinlichkeit
fälschlicherweise für H0,1 entscheidet , falls in Wirklichkeit der Parameter µ größer als
µ 1 = 3,5 ist.
€
€
€
€
Alternativhypothese H1,2a zu Ziel 1.2:
Es besteht ein Unterschied in der Anzahl der Anforderungen zwischen der
Anforderungserhebung mit bzw. ohne die Verwendung von Fast Feedback.
Nullhypothese H0,2a zu Ziel 1.2:
Es besteht kein Unterschied in der Anzahl der Anforderungen zwischen der
Anforderungserhebung mit bzw. ohne die Verwendung von Fast Feedback.
Man nimmt (aus Erfahrung) an, dass ohne die Verwendung von Fast Feedback in einem
dreißigminütigen Anforderungsinterview dreißig Anforderungen dokumentiert werden.
Dagegen wird vermutet, dass mit dem Einsatz von Fast Feedback dreißig Prozent mehr
Anforderungen erhoben werden. Es wird weiter angenommen, dass die Zufallsvariable Y, die
jeder Anforderungserhebung der Experimentgruppe eine Anzahl von dokumentierten
Anforderungen zuordnet, normalverteilt ist, was nach Durchführung des Experiments wieder
zu überprüfen wäre. Die Berechnung des Stichprobenumfangs erfolgt wieder über den
unbekannten Erwartungswert einer normalverteilten Grundgesamtheit. Die Abweichungen
von dem Sollwert sind dabei sowohl nach unten als auch nach oben unerwünscht bzw.
bedeutend, so dass hier eigentlich wieder ein zweiseitiges Testproblem vorliegt. Für die
Bestimmung des Stichprobenumfangs soll aber wiederum die Anwendung des einseitigen
Testproblems genügen. Da in der Experimentgruppe für die Anzahl der dokumentierten
Anforderungen ein Wert größer als µ 0 = 39 erwartet wird, formuliert man das Testproblem
wie folgt.
€

€
€
€
3 Vorbereitung des Experiments mit der GQM-Methode | 49
Sei Y Zufallsvariable wie oben definiert. Testet man die Nullhypothese H0,2a : µ ≤ µ 0 mit dem
Erwartungswert µ 0 = 39 , dem unbekanntem Parameter µ ∈ und der geschätzten Varianz
σ
€
€
€
2 = 56,25 gegen die entsprechende Alternativhypothese H1,1 : µ > µ 0 zum gewählten
Signifikanzniveau und gibt an der Stelle µ 1 = 46 eine Wahrscheinlichkeit
für den Fehler 2. Art vor, so muss die Stichprobengröße, um beide Fehler
einhalten zu können,
€
€
n ≥ u0,975 + u 2
⎛⎛ ( 0,95)⋅
7,5⎞⎞
⎜⎜
⎜⎜
⎟⎟
⎝⎝ 46 − 39 ⎟⎟ =
⎠⎠
1,96 +1,645
2
⎛⎛ ( )⋅ 7,5 ⎞⎞
⎜⎜
⎟⎟ =
⎝⎝ 7 ⎠⎠
27,038
2
⎛⎛ ⎞⎞
⎜⎜ ⎟⎟ =14,92
⎝⎝ 7 ⎠⎠
sein. Als Richtwert sollte zu dieser Hypothese also mindestens eine Stichprobe vom Umfang
n=15 für die Experimentgruppe und optimalerweise auch für die Kontrollgruppe gezogen
werden. Man stellt mit dem oben aufgestellten Testproblem sicher, dass man sich höchstens
mit der Wahrscheinlichkeit fälschlicherweise für die Alternative H1,1 entscheidet,
obwohl H0,1 vorliegt, und dass man sich höchstens mit der Wahrscheinlichkeit
fälschlicherweise für H0,1 entscheidet , falls in Wirklichkeit der Parameter µ größer als
µ 1 = 46 ist.
€
€
€
€
Alternativhypothese H1,2b zu Ziel 1.2:
Es lässt sich ein Unterschied zwischen dem Anteil nicht-funktionaler dokumentierter
Anforderungen mit und ohne Verwendung von Fast Feedback feststellen.
Nullhypothese H0,2b zu Ziel 1.2:
Es lässt sich kein Unterschied zwischen dem Anteil nicht-funktionaler dokumentierter
Anforderungen mit und ohne Verwendung von Fast Feedback feststellen.
Man nimmt an, dass ohne die Verwendung von Fast Feedback in einem dreißigminütigen
Anforderungsinterview ein Drittel der dokumentierten Anforderungen nicht-funktional sind.
Dagegen wird vermutet, dass mit dem Einsatz von Fast Feedback vierzig Prozent der
dokumentierten Anforderungen nicht-funktional sind. Es wird erneut angenommen, dass die
Zufallsvariable Y, die jeder Anforderungserhebung der Experimentgruppe Anzahl nichtfunktionaler
dokumentierter Anforderungen zuordnet, normalverteilt ist, was nach
Durchführung des Experiments auch wieder zu prüfen wäre. Die Berechnung des
Stichprobenumfangs erfolgt wieder über den Erwartungswert einer normalverteilten
Grundgesamtheit. Die Abweichungen von dem Sollwert sind dabei wie zuvor sowohl nach
unten als auch nach oben unerwünscht bzw. bedeutend, so dass hier eigentlich wieder ein
zweiseitiges Testproblem vorliegt. Für die Bestimmung des Stichprobenumfangs soll aber
wiederum die Anwendung des einseitigen Testproblems genügen. Da in der
Experimentgruppe für die Anzahl der dokumentierten nicht-funktionalen Anforderungen ein
Wert größer als µ 0 =15,6 (40% von 39 dokumentierten Anforderungen) erwartet wird,
formuliert man das Testproblem wie folgt.
€

€
€
€
3 Vorbereitung des Experiments mit der GQM-Methode | 50
Sei Y Zufallsvariable wie oben definiert. Testet man die Nullhypothese H0,2b : µ ≤ µ 0 mit dem
Erwartungswert µ 0 =15,6 , dem unbekanntem Parameter µ ∈ und der geschätzten Varianz
σ
€
€
€
2 = 20,25 gegen die entsprechende Alternativhypothese H1,1 : µ > µ 0 zum gewählten
Signifikanzniveau und gibt an der Stelle µ 1 = 20 eine Wahrscheinlichkeit
für den Fehler 2. Art vor, so muss die Stichprobengröße, um beide Fehler
einhalten zu können,
€
€
n ≥ u0,975 + u 2
⎛⎛ ( 0,95)⋅
4,5⎞⎞
⎜⎜
⎜⎜
⎟⎟
⎝⎝ 20 −15,6 ⎟⎟ =
⎠⎠
1,96 +1,645
2
⎛⎛ ( )⋅ 4,5⎞⎞
⎜⎜
⎟⎟ =
⎝⎝ 4,4 ⎠⎠
16,223
2
⎛⎛ ⎞⎞
⎜⎜ ⎟⎟ =13,594
⎝⎝ 4,4 ⎠⎠
sein. Als Richtwert sollte zu dieser Hypothese also mindestens eine Stichprobe vom Umfang
n=14 für die Experimentgruppe und optimalerweise auch für die Kontrollgruppe gezogen
werden. Man stellt mit dem oben aufgestellten Testproblem sicher, dass man sich höchstens
mit der Wahrscheinlichkeit fälschlicherweise für die Alternative H1,1 entscheidet,
obwohl H0,1 vorliegt, und dass man sich höchstens mit der Wahrscheinlichkeit
fälschlicherweise für H0,1 entscheidet , falls in Wirklichkeit der Parameter µ größer als
µ 1 = 20 ist.
€
€
3.5.1.2 Zuteilung € mit Hilfe einer Zufallsziehung
€
Die Probanden sollen durch die von der Experimentleiterin durchgeführte Zufallsziehung den
beiden verschiedenen Gruppen zugeordnet werden. Die Zufallsziehung verhindert eine
subjektive Beeinflussung bei der Zuteilung der Probanden durch die Experimentleiterin, die
möglicherweise eine bestimmte Bedingung mit ganz bestimmten Probanden favorisiert und
dadurch (unbewusst) einen Experimentleitereffekt produziert. Durchgeführt werden muss eine
Zufallsziehung ohne Zurücklegen, da jeder Proband nur einmal einer Gruppe zugeordnet
werden kann. Dafür ist es vorteilhaft, wenn im Vorfeld genau festgelegt wird, wie viele
Probanden es (maximal) geben wird (vgl. Kapitel 3.5.1.1). Werden letztendlich weniger
Probanden gefunden und werden vielleicht sogar unterschiedlich viele Probanden jeder
Gruppe zugeordnet, so stellt das grundsätzlich erstmal kein Problem dar, wobei beachtet
werden sollte, dass sich ein zu großer Unterschied in der Größe der Gruppen auf die
Gültigkeit der Ergebnisse auswirken könnte. Kommen umgekehrt nachträglich noch weitere
Probanden hinzu, so können diese mit Hilfe einer weiteren Zufallsziehung ganz einfach den
beiden schon bestehenden Gruppen zugeordnet werden. Da die geplanten Experimente
zeitlich unabhängig voneinander durchgeführt werden können, ist es durchaus möglich, dass
später noch Probanden hinzugefügt werden.
Die Zufallsziehung wird zunächst auf einen Stichprobenumfang von dreißig Probanden
ausgelegt. Sie wird mit Hilfe von Excel simuliert (vgl. Hinweis in Abb.7). Dabei wird die
erste Hälfte aller gezogenen Nummern der Experimentgruppe zugewiesen. Die zweite Hälfte
wird der Kontrollgruppe zugeteilt. Betrachtet man das Beispiel in Abb.5, so würde das
bedeuten, dass der erste Proband der Kontrollgruppe, der zweite der Experimentgruppe usw.
zugeteilt würde.

3 Vorbereitung des Experiments mit der GQM-Methode | 51
Aus einem String mit allen Möglichkeiten zu ziehender Zahlen wird sukzessive eine
zufällige Möglichkeit herausgeschnitten. In Abb.3 können die Zahlen von 1 bis 30 gezogen
werden; der String befindet sich in Zelle B1. Spalte A ermittelt die Position Z des
Herausschneidevorgangs, Spalte B das Ergebnis des Herausschneidens. Das Ergebnis steht
für den nächsten Herausschneidevorgang zur Verfügung. Eine schon gezogene Zahl kann
dann nicht wieder gezogen werden. In Spalte C steht jeweils die gezogene Zahl. Da die
Formeln in Excel immer wieder neu berechnet werden, muss das Ergebnis einer Ziehung
eingefroren werden, indem die Werte in eine neue Spalte kopiert werden.
Abbildung 5: Hinweis und Beispiel zur Simulation einer Zufallsziehung ohne Zurücklegen mit Excel
3.5.1.3 Erstellen des Fragebogens
Der Fragebogen soll zur besseren Auswertung nur geschlossene Fragen enthalten. Ziel des
Fragebogens soll es sein, etwas über die Benutzbarkeit des jeweiligen Werkzeugs zu erfahren.
Es müssen also zu jedem der beiden Werkzeuge ein anderer Fragebogen erstellt werden,
wobei aber die Fragen, die zur Beantwortung der in G1.3 gestellten Fragen dienen sollen, für
eine Vergleichbarkeit auf beiden Fragebögen identisch sein müssen. Zusätzlich zu den in
Kapitel 2.3.3 zu berücksichtigenden Qualitätsanforderungen sollte der Fragebogen auch
einige Daten des Probanden (Studiengang, Semester) erfassen. Diese Informationen können
zur Einschätzung der Gültigkeit der Ergebnisse verwendet werden, da ein ähnliches
Vorwissen der Probanden gefordert war.

3 Vorbereitung des Experiments mit der GQM-Methode | 52
Abbildung 6: Fragebogen für die Kontrollgruppe
Abbildung 7: Fragebogen für die Experimentgruppe

3 Vorbereitung des Experiments mit der GQM-Methode | 53
3.5.2 Schritte während der Messung
Die Messung zu den Zielen 1 und 2 erfolgt durch die Ton- und Bildschirmaufnahmen mit
Camtasia. Für die korrekte Aufnahme hat die Experimentleiterin und zugleich Kundin
während jedem Anforderungsinterview Sorge zu tragen. Sie startet die Aufnahme vor
Gesprächsbeginn und beendet und speichert sie nach Ablauf der dreißig Minuten
Gesprächszeit.
Die eigentliche Datenerhebung zu den in der Vorbereitung definierten Zielen findet jeweils
im Anschluss an das Experiment statt. Dabei werden die Kundengespräche anhand der Ton-
und Bildschirmaufnahmen von der Experimentleiterin analysiert, indem jede dokumentierte
Anforderung in einer Tabelle notiert wird. Außerdem bekommt jede Anforderung ein
Vermerk, ob sie in Form von Text oder in Form eines Mock-ups dokumentiert wurde. Des
Weiteren werden bei der Analyse der Ton- und Bildschirmaufnahmen die fehlerhaft
dokumentierten Anforderungen gesondert kenntlich gemacht.
Abbildung 8: Auswertungstabelle für Anforderungen
Die Messung zu dem Ziel 3 findet in Form des für jede Gruppe entwickelten Fragebogens
statt, der jeweils im Anschluss an das Experiment vom Proband ausgefüllt werden muss. Die
Experimentleiterin händigt dem Proband den Fragebogen aus, steht dem Proband beim
Ausfüllen für Rückfragen zur Verfügung und sammelt den Fragebogen anschließend wieder
ein.
3.6 Vorgehensweise im Experiment – Prüflisten, Softwarebeispiel, Drehbuch
Zunächst braucht jeder Proband eine Einführung in die Experimentszenerie und die zu
verwendenden Hilfsmittel. Um gleiche Voraussetzungen für alle Probanden zu schaffen und
Störvariablen im Experiment zu vermeiden, muss die Einführung einheitlich sein. Anhand
einer Prüfliste für die Experimentleiterin sollen dem Proband einheitliche Informationen
gegeben werden.

3 Vorbereitung des Experiments mit der GQM-Methode | 54
Prüfliste 1
Wir werden eine Anforderungserhebung durchführen.
Dabei spielen Sie den Anforderungsingenieur/ die Anforderungsingenieurin und ich
die Kundin.
Zur Erhebung von Anforderungen haben Sie dreißig Minuten Zeit.
Die Anforderungserhebung muss nach den dreißig Minuten nicht abgeschlossen sein.
Nach dreißig Minuten beende ich das Experiment unabhängig davon, wie viele
Anforderungen Sie erhoben haben.
Beachten Sie bitte, dass ich die Rolle einer Kundin ohne Informatikhintergrund
einnehmen werde.
Zur Anforderungserhebung sollen Sie den Tablet PC und das Werkzeug Fast
Feedback/ Word verwenden.
Dabei steht es Ihnen frei, die automatische Schrifterkennung oder die Tastatur zu
benutzen. Kurze Demonstration zur Benutzung der Schrifterkennung.
Hier mit Prüfliste zum jeweiligen Werkzeug (2a oder 2b) fortfahren!
Es wird eine Ton- und Bildschirmaufnahme von dem Anforderungsinterview
gemacht. Sind Sie damit einverstanden?
Technische Fragen dürfen Sie bei Schwierigkeiten auch noch während der
Anforderungserhebung stellen.
Prüfliste 2a
Die Aufnahme starte ich jetzt und damit beginnen die dreißig Minuten.
Prüfliste 1: Allgemeine Hinweise
Sie können in diesem Word-Dokument notieren und skizzieren, was Sie wollen.
An dieser Stelle kurze Demonstration zur Erstellung von Skizzen in Word.
Hier mit Prüfliste 1 fortfahren.
Prüfliste 2a: Hinweise zum Werkzeug Word

3 Vorbereitung des Experiments mit der GQM-Methode | 55
Prüfliste 2b
Demonstration zur Verwendung von Fast Feedback anhand des Use Case „Geld am
Automat abheben“
Erstellen von Use Cases
Erstellen von Verknüpfungen zwischen Use Cases
Erstellen von Mock-ups
Erstellen von Verknüpfungen zwischen Mock-ups und Use Case-Schritten
Abspielen der Mock-ups (Demonstrations-Prototypen in chronologischer
Abfolge)
Hier mit Prüfliste 1 fortfahren.
Prüfliste 2b: Hinweise zum Werkzeug Fast Feedback
Sobald die dreißig Minuten Anforderungserhebungszeit mit der Stoppuhr gestartet wurden,
soll die Kundin mit einigen einleitenden Sätzen eine kurze Beschreibung zu der gewünschten
Software geben. Auch hier soll sich an eine Prüfliste gehalten werden. Die Anforderungen
sollen zu dem Softwarebeispiel „SE-Bibliothek“ erhoben werden.
Prüfliste 3
„Ich wünsche mir eine elektronische Verwaltung für die Fachbibliothek des
Fachgebietes Software Engineering.“
„Derzeit werden die Ausleihvorgänge auf Papier dokumentiert.“
„Die Bibliothek enthält zwei Regale mit Büchern.“
Für die Ausleihvorgänge wird ein Terminal (regulärer PC) in der Bibliothek zur
Verfügung gestellt.
Prüfliste 3: Softwarebeispiel „SE-Bibliothek“
Die Kundin braucht außerdem ein Drehbuch, an das sie sich während der dreißig Minuten
Gesprächszeit halten kann. Das Drehbuch soll der Kundin helfen, in jedem
Anforderungsinterview nach den gleichen Regeln zu reagieren, um mögliche Einflüsse durch
Lernprozesse der Kundin zu vermeiden. Das Drehbuch enthält die Regeln, an die sich die
Kundin beim Reagieren auf Fragen des Anforderungsingenieurs halten muss. Da jeder Kunde
schon einige Ideen in ein Anforderungsinterview mitbringt, sollen auch hier einige typische
Anforderungen vorgegeben werden, die aber von der Kundin nur auf Nachfragen des
Anforderungsingenieurs erzählt werden. Auch diese Antworten finden sich im Drehbuch
wieder.

3 Vorbereitung des Experiments mit der GQM-Methode | 56
Drehbuch
1. Grundsätzlich nur auf Fragen antworten und nicht von selbst erzählen. Ausnahme: es
wird ein Fehler entdeckt.
2. Bei speziellen Informatikfragen oder bei Fragen, zu denen keine Anforderungen
vordefiniert wurden: Empfehlung vom Anforderungsingenieur einholen und entweder
zustimmen oder bei verschiedenen Auswahlmöglichkeiten für die erste entscheiden.
3. Anforderungen, die auf Nachfrage des Anforderungsingenieurs gegeben werden:
a. Benutzer- und Bücherdaten sollen per Formular eingetragen werden können.
b. Die Benutzung des Terminals soll nur mit Zugangsdaten möglich sein.
c. Zugangsdaten sollen automatisch verschickt werden.
d. Derzeit brauchen keine Leihfristen berücksichtigt werden.
e. Es soll für Benutzer die Möglichkeit geben, Bücher vorzumerken.
f. Zum Ausleihen soll es eine Suchfunktion nach Stichworten geben.
g. Es soll auch eine Bestandsliste einsehbar sein.
h. Jedes Buch soll einen Standort zugewiesen bekommen können.
Tabelle 7: Drehbuch
Zur Auswertung von Ziel 3 ist nun noch notwendig die Grundfunktionen des Beispiels SE-
Bibliothek zu definieren. Sie sollen ebenfalls in einer Prüfliste zur Verfügung stehen, um sie
bei der Auswertung mit den Messdaten vergleichen zu können.
Prüfliste 4
Buch ausleihen
Buch zurückbringen
Buch suchen
Authentifizierung/ Log-In
Verwaltertätigkeit
Prüfliste 4: Grundfunktionen „SE-Bibliothek"

4 Durchführung des Experiments | 57
4 Durchführung des Experiments
4.1 Probanden
In diesem Kapitel soll ein Eindruck davon vermittelt werden, wie viele Probanden
letztendlich gefunden wurden und was für Eigenschaften sie haben.
Die Suche nach geeigneten Probanden gestaltete sich grundsätzlich schwierig. Den Studenten
fehlte gerade in ihrer Prüfungszeit die Motivation zur Teilnahme an freiwilligen Projekten.
Der im Vorfeld geplante Wettbewerb gab den Studenten aber tatsächlich den Reiz, Wissen
auch mal praktisch anzuwenden, so dass sich letztendlich doch zumindest annährend so viele
Probanden gefunden haben, wie in den Berechnungen zum Stichprobenumfang als Richtwert
ermittelt wurde.
Aus dem universitären Umfeld haben sich insgesamt sechzehn Probanden gefunden, von
denen mittels Zufallsziehung neun der Experimentgruppe und sieben der Kontrollgruppe
zugeordnet wurden. Die Probanden hatten die folgenden Eigenschaften:
• Die 16 Probanden teilen sich auf in 4 Frauen (25%) und 12 Männer (75%).
• 12 von Ihnen (75%) sind Informatikstudenten, 3 (19%) sind Studenten der Mathematik
mit der Studienrichtung Informatik und ein Proband (6%) hat sein Studium zum M.Sc.
in Informatik bereits vollendet.
• Die meisten von ihnen (56%) haben zuvor 2 Vorlesungen am Fachgebiet Software
Engineering gehört, bei denen davon ausgegangen werden kann, dass über das Thema
Anforderungserhebung gesprochen wurde.
Abbildung 9: Theoretische Erfahrung der Probanden (Vorlesungen)
• Insbesondere haben 11 von Ihnen (69%) bereits mindestens ein Softwareprojekt
mitgemacht und bestanden, wobei Anforderungserhebungen entsprechend durchgeführt
werden mussten.

4 Durchführung des Experiments | 58
Abbildung 10: Praktische Erfahrung der Probanden (Projekte)
• Sogar 14 von Ihnen (88%) gaben an, bereits Erfahrungen als Anforderungsingenieur
gemacht zu haben.
•
Abbildung 11: Praktische Erfahrung der Probanden (Anforderungserhebungen)
• 2 Probanden (13%) hatten sich bereits im Vorfeld in einem Softwareprojekt mit dem
Softwarebeispiel „SE-Bibliothek“ befasst.
• Nur 5 Probanden (31%) gaben an, schon mit einem Tablet-PC gearbeitet zu haben.
Abbildung 12: Praktische Erfahrung der Probanden (Tablet-PC)

4 Durchführung des Experiments | 59
• 6 Probanden (38%) haben die Anforderungserhebung mit der automatischen
Schrifterkennung begonnen, 2 davon hatten bereits Erfahrung mit dem Tablet-PC,
haben aber genauso wie noch 2 weitere der 6 Probanden zur Tastatur gewechselt.
Abbildung 13: Praktische Erfahrung der Probanden (automatische Schrifterkennung)
Außerdem gab es die Möglichkeit, das Experiment in einer realen Firma, das heißt in einem
industriellen Umfeld, durchzuführen. Die Firma ließ das Experiment an zehn ihrer Mitarbeiter
aus der Abteilung für Softwareentwicklung durchführen. Mittels Zufallsziehung wurden von
ihnen sechs der Experimentgruppe und vier der Kontrollgruppe zugeordnet. Die Probanden
hatten die folgenden Eigenschaften:
• Die 10 Probanden teilen sich auf in 1 Frau (10%) und 9 Männer (90%).
• 2 Probanden (20%) sind noch Informatikstudenten, 1 Student (10%) kannte bereits das
Beispiel „SE-Bibliothek“.
• 4 Probanden (40%) gaben an, noch keine Erfahrung mit einem Tablet-PC gemacht zu
haben. 2 Probanden (20%) hatten einmalig Erfahrung gesammelt und 3 Probanden
(30%) mehr als einmal, aber selten.
Abbildung 14: Praktische Erfahrung der Probanden (Tablet-PC) (Industrie)
• Nur einer der Probanden (10%) hat zunächst die automatische Schrifterkennung
ausprobiert, später dann aber zur Tastatur gewechselt. Alle anderen Probanden (90%)
haben von Anfang an die Tastatur verwendet.
• Die 6 der Experimentgruppe zugeteilten Probanden haben alle bereits mehrmalige
Erfahrung mit Use Cases gesammelt.

4 Durchführung des Experiments | 60
Die Auswertung zu diesem Teil des Experiments wird in dem Kapitel 6.3 gesondert
vorgestellt, um anhand dieser Ergebnisse die Übertragbarkeit der im universitären Umfeld
gewonnenen Erkenntnisse in ein industrielles Umfeld beurteilen zu können.
4.2 Zusammenfassung des Experimentablaufs
Jedes Experiment fand in einem separaten Raum statt, in dem keine Störungen möglich
waren, und begann jedes Mal mit der Vorbereitung der notwendigen Software und Technik.
Es wurde zur Durchführung ein Tablet-PC mit der folgenden Software benutzt: Word, Fast
Feedback, Camtasia. Für jeden Proband wurde je nachdem, in welcher Gruppe er war, ein
leeres Word- oder Fast-Feedback-Dokument vorbereitet. Außerdem wurde ein zusätzlicher
Bildschirm an den Tablet-PC angeschlossen.
Unabhängig davon, welcher Gruppe der jeweilige Proband angehört, bekam er die
entsprechende Einführung in das Experiment und die zu verwendenden Hilfsmittel mit Hilfe
der Prüflisten 1 und 2a/2b (vgl. Kapitel 3.6). Wie geplant waren bei jedem Experiment nur der
Proband und die Experimentleiterin/Kundin anwesend. Mit dem Start der Ton- und
Bildschirmaufzeichnung begann die Experimentzeit, die mit Hilfe einer Uhr gestoppt wurde.
Das Anforderungsinterview wurde dann mit den in Prüfliste 3 festgelegten Sätzen eingeleitet.
Ab dem Zeitpunkt war der Proband dann auf sich gestellt, durfte aber bei Schwierigkeiten mit
der Technik Zwischenfragen stellen. Die Anforderungserhebungszeit wurde für die
technischen Fragen gestoppt und die für die Anforderungserhebung „verlorene“ Zeit
sozusagen hinten angehängt, so dass am Ende tatsächlich dreißig Minuten reine
Anforderungserhebungszeit absolviert wurde. Nach Ablauf der dreißig Minuten
Experimentzeit wurde das Gespräch beendet. Die Aufnahme wurde angehalten und genauso
wie auch das Word- oder Fast-Feedback-Dokument doppelt (auf internem und externem
Speichermedium) abgespeichert. Der Proband bekam den für die entsprechende Gruppe
vorbereiteten Fragebogen, auch hier waren Rückfragen erlaubt. Mit der Abgabe des
Fragebogens war das Experiment beendet.
4.3 Was hat geklappt und wo kann verbessert werden
Zusammenfassend lässt sich sagen, dass die Experimente weitestgehend nach Plan verlaufen
sind. Es gab nur zu einer Unregelmäßigkeit, die hier aufgeführt werden und noch zusätzlich
zu den schon in der Planung des Experiments angesprochenen Einschränkungen und
Einflüssen in die spätere Bewertung der Ergebnisse einfließen soll.
Die Unregelmäßigkeit entstand dadurch, dass dem Probanden freigestellt wurde, die Tastatur
oder die automatische Schrifterkennung des Tablet-PC zu benutzen. Sechs Probanden wollten
die Schrifterkennung ausprobieren, kamen dann aber teilweise doch nicht gut mit ihr zurecht.
Vier wechselten dann rechtzeitig über zur Tastatur, aber die anderen zwei versuchten es
weiter und verloren dadurch kostbare Anforderungserhebungszeit. Diese Störvariable muss in
der Bewertung der Ergebnisse berücksichtigt werden. Natürlich wäre es der
Experimentleiterin möglich gewesen, einzugreifen, aber da dem Proband die Art des
Schreibens explizit freigestellt wurde, hätte es ihn verunsichern können, unterbrochen und
doch in seiner eigenen Entscheidung korrigiert zu werden, weshalb letztendlich nicht
eingeschritten wurde. Für zukünftige Experimente sollte gelten, dass alle bekannten
unabhängigen Variablen festgehalten werden, auch wenn sie einem im Vorfeld unwesentlich
erscheinen. Diese Regel muss gerade dann beachtet werden, wenn Menschen am

4 Durchführung des Experiments | 61
Experimentaufbau beteiligt sind. Hier waren es wahrscheinlich der Reiz, etwas Neues
auszuprobieren, und der Ehrgeiz, die Herausforderung „Schrifterkennung“ auch zu
bewältigen, die den Probanden verleitet haben, die automatische Schrifterkennung trotz
Zeiteinbußen und ohne Vorerfahrung zu verwenden.

€
€
€
5 Datensammlung und Validierung | 62
5 Datensammlung und Validierung
5.1 Messergebnisse aus dem universitären Umfeld
5.1.1 Messergebnisse zu den GQM-Zielen
In der Datensammlung sollen alle Messdaten dargestellt werden, die Antworten zu den mit
der GQM-Methode erarbeiteten Zielen liefern können. Dabei wird konkret auf die Ziele der
zweiten Ebene eingegangen. Das übergeordnete Ziel der ersten Ebene soll dann im Anschluss
an die Analyse der Ergebnisse in einem Fazit wieder aufgegriffen werden.
Vorweg ist festzustellen, dass ein Proband die Bedingung, spätestens nach fünf Minuten
Anforderungserhebungszeit mit der Verwendung des Werkzeugs zu beginnen, nicht erfüllt
hat. Stellt sich der Proband als Ausreißer nach Grubbs (vgl. Kapitel 2.2.5.2) dar, so muss
überlegt werden, ihn beim Zusammentragen der Ergebnisse nicht zu berücksichtigen.
Zumindest sollte in dem Fall aber geprüft werden, in wie weit die Ergebnisse des besagten
Probanden das Gesamtergebnis beeinflussen könnten. Sei X Zufallsvariable einer
normalverteilten Grundgesamtheit mit den Werten x1,...,x 9 , die jeder Anforderungserhebung
der Experimentgruppe eine Anzahl von Fehlern zuordnet, wobei x1 der kleinste Wert ist. Prüft
man mit dem Ausreißer-Test von Grubbs die Hypothese H0 : (x1 ist kein Ausreißer) zum
Signifikanzniveau α = 0,05 gegen die Alternativhypothese H
€
1 : (x1 ist ein Ausreißer) bezogen
auf die Anzahl der entdeckten Fehler, so ist mit dem Mittelwert x =1,429, der Anzahl der
€
Fehler des zu untersuchenden Probanden x1 =1, der Standardabweichung s =1,225 und dem
€
Stichprobenumfang n = 9
€
€
1,429 −1
T1 = €
1,225
€
= 0,35 < 2,11 = T9;0,95. Die Nullhypothese kann zum gewählten Signifikanzniveau α nicht verworfen werden. In
Bezug auf die Menge der erkannten Fehler ist der Proband kein Ausreißer nach Grubbs.
Basierend auf der Einschätzung durch den Test von Grubbs wird deshalb entschieden, bei den
Ergebnissen zu G1.1 keine Einschränkungen zu machen und den Datenpunkt des Probanden
€
zu der Stichprobe zu zählen. Prüft man unter den oben genannten Voraussetzungen die
gleiche Hypothese bezogen auf die Menge der dokumentierten Anforderungen, so erhält man
mit dem Mittelwert x = 23,571, der Anzahl der dokumentierten Anforderungen des zu
prüfenden Probanden x1 = 9, der Standardabweichung s = 8,307 und dem Stichprobenumfang
n = 9
23,571−
€
9
T1 = € =1,754 < 2,11 = T
8,307
9;0,95.
€
Auch hier kann die Nullhypothese, der Proband sei kein Ausreißer, nicht verworfen werden
und der Datenpunkt des geprüften Probanden wird deshalb auch beim Zusammentragen der
Ergebnisse zu G1.2 nicht gesondert betrachtet. Gegebenenfalls stellt sich bei der Analyse zu
G1.3 heraus, dass der Proband das Werkzeug nicht verstanden hat bzw. dass das Werkzeug
Fast Feedback im Allgemeinen nicht besonders gut verständlich im Sinne der in der Planung
des Experiments aufgestellten Definition ist. In dem Fall müsste die Gültigkeit der Ergebnisse
ohnehin eingeschränkt werden. Nun werden aber die Ergebnisse zu den drei Zielen der
€
€

5 Datensammlung und Validierung | 63
zweiten GQM-Ebene dargestellt, ohne dass ein Datenpunkt der Stichprobe entfernt wird.
Dabei ist es sinnvoll, zuerst die Ergebnisse zu Ziel G1.3 zu untersuchen, da die Benutzbarkeit
Einfluss auf die Ziele G1.1 und G1.2 haben könnte.
G1.3 Untersuche die Benutzbarkeit von Werkzeugen (Fast Feedback, Word) in der
Anforderungserhebung aus der Perspektive des Anforderungsingenieurs/Projektmanagers.
Als erstes soll dargestellt werden, in welchem Umfang die sogenannten Features von Fast
Feedback und Word, wie sie in Kapitel 3.1.1.3 definiert wurden, in den
Anforderungsinterviews genutzt wurden.
Mit der Verwendung von Word wurden kaum weniger Mock-ups erstellt als mit dem Einsatz
von Fast Feedback. Verknüpfungen zwischen Use Cases und das Vorzeigen des
Demonstrations-Prototyps fallen, wenn man den Mittelwert über alle Probanden der
Experimentgruppe betrachtet, kaum ins Gewicht (vgl. Abb.15).
Abbildung 15: Häufigkeit, mit der Features durchschnittlich benutzt wurden
Schaut man sich die Stichproben getrennt voneinander an, so stellt man fest, dass ein Proband
der Experimentgruppe (vgl. Proband 9 in Abb.16) nicht über das Erstellen von Use Cases
hinaus gekommen ist und ein weiterer (vgl. Proband 2 in Abb.16) sich auf Use Cases mit der
Erstellung eines Mock-ups beschränkt hat. Wie zu Beginn dieses Kapitels gesagt, gab es nur
einen Probanden (vgl. Proband 4 in Abb.16), der sich mehr als fünf Minuten Zeit gelassen
hat, ehe er Fast Feedback eingesetzt hat. Dieser hat aber trotzdem mehr Features genutzt als
die beiden oben genannten, die vergleichsweise wenig Features benutzt haben.

5 Datensammlung und Validierung | 64
Abbildung 16: Anzahl der eingesetzten Features pro Proband der Experimentgruppe
Geht man nun davon aus, dass die Features bei Fast Feedback nacheinander in der
Reihenfolge Use Cases (A), Mock-ups (B), Verknüpfungen zwischen Use Case Schritten (C)
und Mock-ups, Verknüpfungen zwischen Use Cases (D) und Abspielen des Demonstrations-
Prototyps (E) eingesetzt werden, weil das eine ohne das andere eher wenig Sinn macht, so ist
es noch interessant, die Ergebnisse in Abb.17 zu betrachten. Für jede Betrachtung einer
Kombination von Features wurden wieder alle neun Probanden einbezogen, so dass, wenn ein
bestimmter Proband in einer der Kombinationen von Features auftritt, er auch in allen
darunter liegenden Kombinationen zu finden ist. Dabei stellt man fest, dass nur ein Proband,
alle zur Verfügung stehenden Features des Werkzeugs Fast Feedback nutzte, wogegen
zumindest noch die Use Cases von allen Probanden eingesetzt wurden, wenn auch nicht von
allen Probanden in gleichem Maße.
Abbildung 17: Häufigkeit eingesetzter Features mit eingeschränkten Kombinationsmöglichkeiten
Betrachtet man nicht nur die oben festgelegten sondern alle Kombinationen von Features und
teilt jeden Probanden nur einer Kombination zu, so erkennt man, dass die 56% der Probanden
insgesamt vier Features genutzt haben (vgl. Abb.18).

5 Datensammlung und Validierung | 65
Abbildung 18: Häufigkeit eingesetzter Features mit allen Kombinationsmöglichkeiten
Die Probanden der Kontrollgruppe konnten ebenfalls ein Feature, nämlich das Erstellen von
Mock-ups einsetzen. Darauf verzichtete nur ein einziger Proband. Alle anderen erstellten
mindestens ein, aber sogar bis zu sieben Mock-ups (vgl. Abb.19). Vergleicht man die
Verteilung der Zufallsvariablen der Kontroll- mit der Experimentgruppe, so stellt man sogar
fest, dass der Median über die Werte der Kontrollgruppe sogar über dem der
Experimentgruppe liegt, dafür aber das obere Quartil tiefer liegt (vgl. Abb.20).
Abbildung 19: Mock-ups pro Proband der Kontrollgruppe

5 Datensammlung und Validierung | 66
Abbildung 20: Boxplot zur Anzahl von Mock-ups
Nun soll gezeigt werden, wie die Probanden Word und Fast Feedback als Werkzeug in der
Anforderungserhebung mit Hilfe von Schulnoten (vgl. Tab.8) beurteilt haben. Beide
Werkzeuge wurden, wenn man den Mittelwert über die Beurteilung aller Probanden
betrachtet, unter allen drei untersuchten Aspekten (Bedienung, Aufbau und Beurteilung
insgesamt) mit der Schulnote „2“ bewertet (vgl. Tab.9). Auch hier soll vergleichend der
jeweilige Median betrachtet werden. So erhält man für den Aufbau des Werkzeugs Word nur
noch die Schulnote „3“ (vgl. Tab.10). In beiden Tabellen wurden die auf volle Noten
gerundeten und die auf eine Dezimalstelle genau berechneten Werte dargestellt.
Bezeichnung Notenskala
sehr gut 1
gut 2
befriedigend 3
ausreichend 4
mangelhaft 5
schlecht 6
Tabelle 8: Ordinalskala für Schulnoten
Werkzeug
Beurteilung
Word Fast Feedback
Bedienung 2 (2,1) 2 (2,1)
Aufbau 2 (2,3) 2 (2,0)
insgesamt 2 (2,1) 2 (2,1)
Tabelle 9: Beurteilung der Werkzeuge in Schulnoten per Mittelwert
Werkzeug
Beurteilung
Word Fast Feedback
Bedienung 2 (2,0) 2 (2,0)
Aufbau 3 (2,5) 2 (2,0)
insgesamt 2 (2,0) 2 (2,0)
Tabelle 10: Beurteilung der Werkzeuge in Schulnoten per Median

5 Datensammlung und Validierung | 67
Bei der Beurteilung per Median lässt sich feststellen, dass der Unterschied zwischen dem
Aufbau von Word und dem von Fast Feedback etwas deutlicher ist als der, der mit Hilfe des
Mittelwerts ermittelt wurde. Bei der Beurteilung der Bedienung und der Beurteilung
insgesamt ist kein Unterschied festzustellen. Zur Veranschaulichung soll die Verteilung der
Beurteilungen nun grafisch in einem Boxplot-Diagramm dargestellt werden. Dargestellt
werden der Median, das obere Quartil, das Maximum, das Minimum und das untere Quartil
der Werte.
Abbildung 21: Boxplots zur Beurteilung der Werkzeuge mit Schulnoten
Der aus den Betrachtungen des Mittelwerts bzw. des Medians entstandene Eindruck, dass Fast
Feedback im Vergleich zu Word etwas besser abgeschnitten hat, lässt sich nach einem Blick
auf die Boxplot-Diagramme bestätigen. In allen drei Bereichen (Bedienung, Aufbau und
Beurteilung insgesamt) liegen die Werte zu Fast Feedback in einem besseren
Schulnotenbereich als die zu Word, wobei die oberen Quartil bei der Bedienung und der
Beurteilung insgesamt bei Fast Feedback allerdings deutlich höher liegen als bei Word.
In Prüfliste 4 (vgl. Kapitel 3.6) wurden Grundfunktionen zum Softwarebeispiel „SE-
Bibliothek“ definiert. Alle Probanden, sowohl die aus der Experiment- als auch die aus der
Kontrollgruppe, haben die Bedingung, dass zumindest 40% der Grundfunktionen (das heißt
zwei von fünf) in der Dokumentation der Anforderungen berücksichtigt werden, erfüllt.

5 Datensammlung und Validierung | 68
Abbildung 22: Häufigkeit, mit der Probanden eine bestimmte Anzahl Grundfunktionen dokumentierten
Der Median bzgl. der Anzahl der dokumentierten Anforderungen liegt bei den Probanden der
Experimentgruppe etwas höher als bei den Probanden der Kontrollgruppe. Dafür liegt
allerdings auch das untere Quartil der Werte aus der Experimentgruppe in einem niedrigeren
Bereich als bei denen aus der Kontrollgruppe.
Abbildung 23: Boxplot zur Anzahl dokumentierter Grundfunktionen
Zusammenfassend soll hier gesagt sein, dass das Werkzeug Fast Feedback bei einem Blick
auf die dargestellten Ergebnisse ähnlich verständlich scheint wie Word. Damit kann zwar ein
möglicher Einfluss auf die Ziele 1.1 und 1.2 nicht ausgeschlossen werden, aber es ist
anzunehmen, dass der Einfluss eher gering ist und die Ziele 1.1 und 1.2 erstmal unabhängig
von der Benutzbarkeit des Werkzeugs untersucht werden können. Eine umfangreichere
Auswertung der Ergebnisse zu G1.3 folgt noch im Kapitel zur Analyse und Interpretation.
G1.1 Verbessere die Erkennung fehlerhaft dokumentierter Anforderungen in der
Anforderungserhebung aus der Perspektive des Anforderungsingenieurs/Projektmanagers
In der Experimentgruppe wurden, wie in der Hypothese angenommen, mehr Fehler erkannt.
Während 44% der Probanden der Experimentgruppe mehr als einen Fehler erkannt haben,
haben nur 14% Probanden der Kontrollgruppe mehr als einen Fehler erkannt (vgl. auch die
absoluten Werte in Abb.15). Insbesondere hat es aus der Kontrollgruppe kein Proband
geschafft, mehr als zwei Fehler in der vorgegebenen Anforderungserhebungszeit zu erkennen
(vgl. Abb.16).

5 Datensammlung und Validierung | 69
Abbildung 24: Häufigkeit, mit der die Probanden Fehler erkannt haben oder nicht
Abbildung 25: Häufigkeit, mit der eine bestimmte Anzahl von Fehlern erkannt wurde
Vergleicht man die Ergebnisse mit der Bildung des Medians für jede Gruppe, so kommt man
bei der Experimentgruppe auf einen Fehler und bei der Kontrollgruppe auf null Fehler. Zur
Veranschaulichung der Verteilung der erhobenen Daten zur Anzahl von erkannten Fehlern
sollen wieder der Median, das obere Quartil, das Maximum, das Minimum und das untere
Quartil der Werte in einem Boxplot-Diagramm dargestellt werden (vgl. Abb.17). Die Werte,
auf denen das Boxplot-Diagramm basiert, wurden in Tab.11 zusammengefasst.
Median oberes Maximum Minimum unteres
Quartil
Quartil
Experimentgruppe 1 2 3 0 0
Kontrollgruppe 0 0,5 2 0 0
Tabelle 11: Werte für das Boxplot-Diagramm

€
€
5 Datensammlung und Validierung | 70
Abbildung 26: Boxplots zur Anzahl erkannter Fehler
Die Hypothese, dass im ersten Anforderungsinterview mit der Verwendung von Fast
Feedback mehr Fehler erkannt werden, kann zwar bestätigt werden, nur muss jetzt geprüft
werden, ob der Unterschied signifikant ist. Dazu folgen jetzt die entsprechenden
Berechnungen, wobei der zweiseitige Zweistichproben-t-Test für zwei unabhängige
Stichproben angewendet wird (vgl. Kapitel 2.2.1). Zur Erinnerung hier die für einen
zweiseitigen Test aufgestellte Alternativ- und Nullhypothese:
Alternativhypothese H1,1 zu Ziel 1.1:
Im ersten Interview gibt es einen Unterschied beim Erkennen von Fehlern zwischen der
Anforderungserhebung mit und der ohne der Verwendung von Fast Feedback.
Nullhypothese H0,1 zu Ziel 1.1:
Im ersten Interview gibt es keinen Unterschied beim Erkennen von Fehlern zwischen der
Anforderungserhebung mit und der ohne der Verwendung von Fast Feedback.
Sei X die Zufallsvariable mit Werten , die jeder Anforderungserhebung der
Kontrollgruppe eine Anzahl von Fehlern zuordnet, und Y die Zufallsvariable mit Werten
, die jeder Anforderungserhebung der Experimentgruppe eine Anzahl von Fehlern
zuordnet. Es wird weiter angenommen, dass die Zufallsvariablen X und Y normalverteilt sind.
Sind µ x,µ y ∈ unbekannte Erwartungswerte. Die Nullhypothese soll gegen die
Alternativhypothese getestet werden. Die Mittelwerte sind und
dann
. Die Stichprobenvarianzen sind
s €
2 ( 7 −1)⋅
0,62 + ( 9 −1)⋅
1,5
= =1,123.
7 + 9 − 2
2
sx = 0,62 und
€
2
sy =1,5. Die gewichtete Varianz ist

€
€
€
€
5 Datensammlung und Validierung | 71
Für die Prüfgröße t ergibt sich dann
t =
7⋅ 9 0,43 −1,43
⋅ =1,984⋅ ( −0,943)
= −1,871.
7 + 9 1,06
kann zum Signifikanzniveau nicht verworfen werden, da der Wert für
t kleiner ist als das 0,975-Quantil der t-Verteilung mit Freiheitsgraden:
t =1,871 < 2,145 = t( 14; 0,975).
Gibt es tatsächlich einen signifikanten Unterschied zwischen der Erkennung fehlerhaft
dokumentierter Anforderungen mit und der ohne Fast Feedback, so reicht der hier getestete
Stichprobenumfang nicht aus, um ihn zu belegen. Der im Vorfeld des Experiments geschätzte
Stichprobenumfang von n=13 Probanden pro Gruppe liegt über dem tatsächlichen
Stichprobenumfang (Experimentgruppe n=9, Kontrollgruppe n=7). Zusätzlich ist der Effekt
zwischen den beiden Gruppen einen halben Punkt kleiner ausgefallen als er bei den
Berechnungen zum Stichprobenumfang geschätzt wurde. Je kleiner der Effekt, desto größer
muss wiederum der Stichprobenumfang sein, um die Signifikanz eines Unterschieds zeigen zu
können.
Testet man wegen des schwächeren Effekts alternativ die einseitige Hypothese
gegen , so kann die Nullhypothese H0,1 zum vorgegebenen Signifikanzniveau
nicht verworfen werden, da
t = −1,871

5 Datensammlung und Validierung | 72
Abbildung 27: Mittelwerte über die Anzahl dokumentierter Anforderungen je Gruppe
Der Anteil der nicht-funktionalen Anforderungen gemessen an der Gesamtmenge
dokumentierter Anforderungen ist bei der Experimentgruppe (36,0%) kaum höher als bei der
Kontrollgruppe (35,4%) (vgl. Abb.19). Auf den ersten Blick scheint das Werkzeug Fast
Feedback also keine Auswirkungen auf das Verhältnis funktionaler zu nicht-funktionaler zu
haben.
Abbildung 28: Verhältnis funktionaler zu nicht-funktionaler Anforderungen
Sowohl zu dem Ziel, mit Fast Feedback mehr Anforderungen dokumentieren zu können, als
auch zu dem, das Verhältnis funktionaler zu nicht-funktionaler Anforderungen zugunsten der
nicht-funktionalen mit Hilfe von Fast Feedback verändern zu können, stellt sich nun wieder
die Frage nach der Signifikanz der Ergebnisse. Auch hier folgen deshalb die entsprechenden
Berechnungen mit Hilfe des zweiseitigen Zweistichproben-t-Tests für zwei unabhängige
Stichproben.
Alternativhypothese H1,2a zu Ziel 1.2:
Es besteht ein Unterschied in der Anzahl der dokumentierten Anforderungen zwischen der
Anforderungserhebung mit und der ohne die Verwendung von Fast Feedback.

€
€
€
€
5 Datensammlung und Validierung | 73
Nullhypothese H0,2a zu Ziel 1.2:
Es besteht kein Unterschied in der Anzahl der dokumentierten Anforderungen zwischen der
Anforderungserhebung mit und der ohne die Verwendung von Fast Feedback.
Sei X die Zufallsvariable mit Werten , die jeder Anforderungserhebung der
Kontrollgruppe eine Anzahl von dokumentierten Anforderungen zuordnet, und Y die
Zufallsvariable mit Werten , die jeder Anforderungserhebung der Experimentgruppe
eine Anzahl von dokumentierten Anforderungen zuordnet. Es wird weiter angenommen, dass
die Zufallsvariablen X und Y normalverteilt sind. Seien µ x ,µ y ∈ unbekannte
Erwartungswerte. Die Nullhypothese H0,2a : µ = µ 0 soll gegen die Alternativhypothese
H1,2a : µ ≠ µ 0 getestet werden. Die Mittelwerte sind und . Die
2 2
Stichprobenvarianzen sind sx = 35,48 und sy = 69,0. Die gewichtete € Varianz ist dann
€
s
€
€
2 ( 7 −1)⋅
35,48 + ( 9 −1)⋅
69
= = 54,63.
7 + 9 − 2
Für die Prüfgröße t ergibt sich dann
t =
7⋅ 9 33,86 − 22,57
⋅ =1,984⋅ 1,528 = 3,032.
7 + 9 7,391
kann zum Signifikanzniveau verworfen werden, da der Wert für
größer ist als das 0,975-Quantil der t-Verteilung mit Freiheitsgraden:
t = 3,032 > 2,145 = t( 14; 0,975).
Es gibt tatsächlich einen signifikanten Unterschied zwischen der Anzahl dokumentierter
Anforderungen mit und der ohne Fast Feedback. Allerdings spricht dieser signifikante
Unterschied aufgrund der Ergebnisse dafür, dass in der Kontrollgruppe mit Word mehr
Anforderungen dokumentiert wurden als in der Experimentgruppe, die mit Fast Feedback
gearbeitet hat. Die zugrundeliegende Hypothese, dass der Anforderungsingenieur mit Fast
Feedback mehr Informationen in Form von dokumentierten Anforderungen erhält, kann durch
die vorliegenden Ergebnisse nicht unterstützt werden.
Alternativhypothese H1,2b zu Ziel 1.2:
Es lässt sich ein Unterschied zwischen dem Anteil nicht-funktionaler dokumentierter
Anforderungen mit und ohne Verwendung von Fast Feedback feststellen.
€
t

€
€
€
€
€
€
€
5 Datensammlung und Validierung | 74
Nullhypothese H0,2b zu Ziel 1.2:
Es lässt sich kein Unterschied zwischen dem Anteil nicht-funktionaler dokumentierter
Anforderungen mit und ohne Verwendung von Fast Feedback feststellen.
Auf den ersten Blick lässt sich kein wesentlicher Unterschied zwischen dem Anteil nichtfunktionaler
Anforderungen mit und ohne Fast Feedback feststellen, was hier wieder mit
Hilfe eines zweiseitigen Zweistichproben-t-Tests zu prüfen ist. Sei X die Zufallsvariable mit
Werten , die jeder Anforderungserhebung der Kontrollgruppe eine Zahl zuordnet, die
den Anteil der nicht-funktionalen dokumentierten Anforderungen gemessen an allen
dokumentierten Anforderungen beschreibt, und Y die Zufallsvariable mit Werten , die
jeder Anforderungserhebung der Experimentgruppe eine Zahl zuordnet, die den Anteil der
nicht-funktionalen dokumentierten Anforderungen gemessen an allen dokumentierten
Anforderungen beschreibt. Es wird weiter angenommen, dass die Zufallsvariablen X und Y
normalverteilt sind. Seien µ x ,µ y ∈ unbekannte Erwartungswerte. Die Nullhypothese
H0,2b : µ = µ 0 soll gegen die Alternativhypothese H1,2b : µ ≠ µ 0 getestet werden. Die
2
Mittelwerte sind x = 36,47 und y = 32,21. Die Stichprobenvarianzen sind sx = 92,16 und
2
sy = 234,74 . Die gewichtete € Varianz ist dann
€
s
€
€
€
2 ( 7 −1)⋅
92,16 + ( 9 −1)⋅
234,74
= =173,634 .
7 + 9 − 2
Für die Prüfgröße t ergibt sich dann
t =
7⋅ 9 36,47 − 32,21
⋅ =1,984⋅ 0,323 = 0,641.
7 + 9 13,177
H0,2b : µ = µ 0 kann zum Signifikanzniveau nicht verworfen werden, da der Wert für
t kleiner ist als das 0,975-Quantil der t-Verteilung mit Freiheitsgraden:
t = 0,641 < 2,145 = t( 14; 0,975).
Gibt es tatsächlich einen signifikanten Unterschied zwischen der Erkennung fehlerhaft
dokumentierter Anforderungen mit und der ohne Fast Feedback, so reicht der hier getestete
Stichprobenumfang nicht aus, um ihn zu belegen. Der im Vorfeld des Experiments geschätzte
Stichprobenumfang von n=14 Probanden pro Gruppe liegt über dem tatsächlichen
Stichprobenumfang (Experimentgruppe n=9, Kontrollgruppe n=7). Allerdings hat man schon
nach einem ersten Blick auf die Ergebnisse der einzelnen Stichprobenwerte feststellen
müssen, dass kein wesentlicher Unterschied erkennbar ist. Deshalb wird möglicherweise auch
ein größerer Stichprobenumfang kein anderes Ergebnis liefern.
5.1.2 Messergebnisse außerhalb von GQM
Einige für die Bewertung der Ergebnisse möglicherweise interessante Messdaten, die als
Nebenprodukt zur eigentlich geplanten Messung entstanden sind, sollen nicht vorenthalten
werden.

€
€
€
5 Datensammlung und Validierung | 75
Zur Selbsteinschätzung der Probanden
Zusätzlich zu dem Nutzen von Fast Feedback in der Anforderungserhebung sollten die
Probanden auch selbst einschätzen, ob sie mehr oder weniger Anforderungen mit der
Verwendung von Fast Feedback erhalten haben. Die Frage ist also, ob die Einschätzung des
Probanden mit dem wahren Wert übereinstimmt. Dazu soll der für die Anforderungserhebung
mit Word geschätzte und auf Erfahrungen basierende Wert von dreißig Anforderungen (in
dreißig Minuten) als Richtwert dienen. Nur ein Proband hat knapp mehr als dreißig
Anforderungen mit der Verwendung von Fast Feedback dokumentiert. Sein Wert lag drei
Punkte über dem definierten Richtwert. Der Proband selbst hat nicht vermutet, mehr
Anforderungen erhoben zu haben. Die übrigen Probanden der Experimentgruppe vermuteten
je zur Hälfte, dass sie mehr bzw. gleich viel oder weniger Anforderungen bekommen haben.
Dabei lag der bzgl. der Anforderungsanzahl stärkste Proband noch drei Punkte hinter dem
Erwartungswert, der schwächste sogar acht Punkte. Es schätzten sich fünf der neun
Probanden falsch ein.
Abhängigkeiten verschiedener Merkmale
Um besser einschätzen zu können, welchen Einfluss die Erfahrung, die jeder Proband in der
Rolle des Anforderungsingenieurs mit in das Experiment bringt, auf die Ergebnisse haben
könnte, kann es hilfreich sein, die mögliche lineare Abhängigkeit des Merkmals „Erfahrung
der Probanden“ zu einem anderen Merkmal („Anzahl dokumentierter Anforderungen“ oder
„Anzahl der erkannten Fehler“) zu betrachten.
Zunächst betrachten wir die mögliche lineare Abhängigkeit zwischen der Erfahrung des
Anforderungsingenieurs und der Anzahl der dokumentierten Anforderungen. Mittels
Fragebogen wurden die Probanden zu ihren Erfahrungen mit Anforderungsinterviews befragt.
Ihnen standen drei Antwortmöglichkeiten zur Auswahl: keine, einmalige und mehrmalige
Erfahrung. Mit Hilfe einer definierten Bewertungsskala (vgl. Tab.12) für die drei
Antwortmöglichkeiten soll geprüft werden, ob die Erfahrung des Probanden mit der Anzahl
der dokumentierten Anforderungen korreliert.
Antwortmöglichkeit Bewertung in
Punkten
keine Erfahrung 0
einmalige Erfahrung 1
mehrmalige Erfahrung 2
Tabelle 12: Bewertungsskala zur Erfahrung der Probanden
Sei X mit den Werten x1 ,...,x n Zufallsvariable der zugrundeliegenden normalverteilten
Grundgesamtheit, die jedem Proband eine Erfahrungsbewertung in Punkten (vgl. Tab.12)
zuordnet, und Y mit den Werten y1 ,..., yn Zufallsvariable der normalverteilten
Grundgesamtheit, die jedem Proband eine Anzahl von dokumentierten Anforderungen
€
zuordnet, wobei die Werte der Zufallsvariablen paarweise erhoben wurden. Sei die Varianz
von X und Y positiv. Dann schätzt man die Korrelation anhand der Stichprobe vom Umfang
n =16 aus dieser normalverteilten € Grundgesamtheit mit dem Pearsonschen
Korrelationskoeffizienten (vgl. Kapitel 2.2.6) und erhält für ρXY ∈[ −1,+1]
mit x Mittelwert
von x1,...,x n und y Mittelwert von y1,..., yn einen Wert für den Korrelationskoeffizienten von
ρXY = 0,053. Der Wert liegt so nahe bei Null, dass man mit hoher Wahrscheinlichkeit davon
€
€
€
€

€
5 Datensammlung und Validierung | 76
ausgehen kann, dass die beiden Merkmale zumindest in linearer Weise nicht voneinander
abhängen.
Überprüft man die mögliche lineare Abhängigkeit zwischen der Anzahl erkannter Fehler und
der Erfahrung des Probanden, wobei nun X mit den Werten x1 ,..., xn wieder die
Zufallsvariable der zugrundeliegenden normalverteilten Grundgesamtheit sei, die jedem
Proband eine Erfahrungsbewertung in Punkten zuordnet, und Y mit den Werten y1 ,..., yn die
Zufallsvariable der normalverteilten Grundgesamtheit sei, die jedem Proband eine Anzahl von
€
erkannten Fehlern zuordnet, wobei die Werte der Zufallsvariablen paarweise erhoben wurden.
Ihre Varianz sei jeweils positiv. So erhält man für die Korrelation einen
Korrelationskoeffizienten von ρ
€
XY = 0,444. Es besteht also auf den ersten Blick ein in etwa
mittlerer linearer Zusammenhang zwischen den beiden Merkmalen. Nun prüft man die
Signifikanz dieses Wertes mit Hilfe des zweiseitigen Zweistichproben-t-Tests zu einem
gewählten Signifikanzniveau α ∈( 0,1).
Dazu formuliert man zu den oben gegebenen
€
Zufallsvariablen das zweiseitige Testproblem, bei dem man die Nullhypothese H0 : ρ = 0
gegen die Alternativhypothese H1 : ρ ≠ 0 zum gewähltem Signifikanzniveau α = 0,05 testet.
Die Nullhypothese wird nicht verworfen, da gilt
€
€
0,444⋅ 14 1,661
t < 2,145 = t €
€
14; 0,975 mit t = =
2
1 − 0,444 0,896 =1,854.
Der errechnete Korrelationskoeffizient ist damit zum gewählten Signifikanzniveau α nicht
signifikant von Null verschieden. Der möglicherweise bestehende lineare Zusammenhang der
beiden betrachteten € Merkmale kann mit dem Test nicht gestützt werden.
€

6 Analyse und Interpretation | 77
6 Analyse und Interpretation
6.1 Analyse und Interpretation der Ergebnisse aus dem universitären Umfeld
In diesem Kapitel sollen die Ergebnisse aus dem universitären Umfeld bzgl. der mit GQM
konkretisierten Hypothesen analysiert und interpretiert werden. Dazu werden jeweils noch
einmal das Ziel und die aufgestellte Hypothese genannt.
G1.1 Verbessere die Erkennung fehlerhaft dokumentierter Anforderungen in der
Anforderungserhebung aus der Perspektive des Anforderungsingenieurs/Projektmanagers
Zu der Hypothese, der Anforderungsingenieur würde mit der Verwendung von Fast Feedback
mehr Missverständnisse, Widersprüche, Unvollständigkeiten und Inkonsistenzen schon im
ersten Anforderungsinterview mit dem Kunden aufdecken können, lässt sich nach
Betrachtung der Messergebnisse sagen, dass zwar ein Unterschied zugunsten von Fast
Feedback festgestellt werden konnte, dieser aber geringer ausgefallen ist als erwartet. Der
zuvor abgeschätzte Stichprobenumfang konnte nicht erreicht werden. Er reicht deshalb nicht
aus, um einen statistisch signifikanten Unterschied festzustellen. Führt man die Berechnungen
zum benötigten Stichprobenumfang mit dem neuen Wert für den erwarteten Effekt durch, so
kommt man auf einen entsprechend höheren benötigten Stichprobenumfang von etwa dreißig
Probanden allein für die Experimentgruppe. Zusammenfassend kann man also sagen, dass der
Effekt beim Erkennen von Fehlern zwischen der Anforderungserhebung mit Word und der
mit Fast Feedback so gering ausfällt, dass ein kleiner Stichprobenumfang noch nicht
ausreicht, um eine mögliche Signifikanz des Ergebnisses zeigen zu können.
Nun soll diskutiert werden, wie der geringere Effekt entstanden sein könnte. Zum einen spielt
sicherlich die im Experiment eingeschränkte Anforderungserhebungszeit eine Rolle. Das
Erkennen von Fehlern wurde gerade für den Zeitpunkt im Anforderungsinterview erwartet, zu
dem der Demonstrations-Prototyp mit Hilfe der hintereinander gereihten Mock-ups gezeigt
wird. Allerdings konnten sich innerhalb der vorgegebenen dreißig Minuten nur zwei der
Probanden überhaupt bis zu diesem Teil der Anforderungserhebung mit Fast Feedback
vorarbeiten, so dass man davon ausgehen muss, dass das vollständige Potenzial, das Fast
Feedback zur Erkennung von Fehlern mitbringt, nicht in vollem Umfang ausgenutzt werden
konnte. Zum anderen könnte die Ursache aber auch sein, dass die Benutzbarkeit des
Werkzeugs Fast Feedback höher eingeschätzt wurde, als sie tatsächlich ist. Das Maß der
Benutzbarkeit von Fast Feedback kann sich, genauso wie der vorgegebene Zeitrahmen auch,
darauf auswirken, wie gut oder schlecht die Vorteile des Werkzeugs ausgenutzt werden
können. Da die Benutzbarkeit des Werkzeugs Fast Feedback von den Probanden eher für gut
beurteilt wurde, wird möglicherweise der enge Zeitrahmen, der für jede
Anforderungserhebung gesteckt wurde, auschlaggebend Einfluss auf den Effekt genommen
haben.
Das Ergebnis kann für die Stichprobe zugunsten des Werkzeugs Fast Feedback interpretiert
werden. Auf die Grundgesamtheit kann man aber nicht schließen, da keine Signifikanz der
Ergebnisse gezeigt werden konnte. Bei richtiger Ausnutzung der Vorteile von Fast Feedback
würde man aber wahrscheinlich einen deutlicheren Effekt zwischen den Auswirkungen der
Werkzeuge erwarten können. Für eine abschließende Bewertung sollte auf jeden Fall die

6 Analyse und Interpretation | 78
Anforderungserhebungszeit, die Benutzbarkeit von Fast Feedback und in dem Zuge auch die
Vorbereitung der Probanden auf den Umgang mit dem Werkzeug berücksichtigt werden.
G1.2.1 Erhöhe die Anzahl der Anforderungen pro Zeiteinheit in der Anforderungserhebung
aus der Perspektive des Anforderungsingenieurs/Projektmanagers.
Es konnte ein Unterschied in der Anzahl der dokumentierten Anforderungen zwischen der
Experiment- und der Kontrollgruppe festgestellt werden. Allerdings fiel das Ergebnis nicht in
die erwartete Richtung aus. Man kann die ursprüngliche Hypothese, dass der
Anforderungsingenieur mit der Verwendung von Fast Feedback mehr Informationen in Form
von Anforderungen erhält nicht bestätigen. Stattdessen lässt sich behaupten, dass mit Fast
Feedback weniger Anforderungen dokumentiert wurden, und man muss sich fragen, was der
Grund dafür sein könnte. Auch hier spielen sicherlich wieder die Aspekte
Anforderungserhebungszeit und Benutzbarkeit von Fast Feedback eine Rolle. Während sich
die Probanden mit Fast Feedback innerhalb ihrer Anforderungserhebungszeit noch in das
Werkzeug einarbeiten mussten, waren die Probanden der Kontrollgruppe mit Ihrem Werkzeug
Word schon vertraut. Die Beurteilung der Benutzbarkeit von Fast Feedback ist zwar „gut“ im
Sinne von Schulnoten ausgefallen, aber mit einer „sehr guten“ Beurteilung hätte dieser
Nachteil noch geringer ausgefallen können. Möglicherweise wurde dadurch der durch die
notwendige Einarbeitungszeit entstandene Nachteil etwas verstärkt. Ein weiterer Grund dafür,
dass die Probanden der Kontrollgruppe mehr Anforderungen dokumentiert haben, könnte
sein, dass die festgelegte Use Case Struktur die Probanden eingeschränkt hat. Tatsächlich hat
sich in kurzen Nachgesprächen gezeigt, dass es für einige Probanden schwierig war, in Fast
Feedback für alle Anforderungen das passende Feld zum Eintragen zu finden. Dieses Problem
könnte wiederum für die Notenabzüge in der Bewertung der Benutzbarkeit von Fast Feedback
verantwortlich sein. Es ist auch möglich, dass einige Abzüge in der Schulnote dadurch
entstanden sind, dass sich einige Probanden bei der Benutzung von Fast Feedback zur
Dokumentation von Anforderungen zu eingeschränkt gefühlt haben. Auch deshalb sollte das
Ergebnis zu G1.3 unbedingt in das Fazit einfließen.
G1.2.2 Erhöhe den Anteil der nicht-funktionalen dokumentierten Anforderungen pro
Zeiteinheit in der Anforderungserhebung aus der Perspektive des
Anforderungsingenieurs/Projektmanagers.
Die Gesamtanzahl der dokumentierten Anforderungen bei den Probanden der Kontrollgruppe
lag bei der Betrachtung des Mittelwerts je Gruppe höher als bei der Experimentgruppe. Bei
denselben Probanden konnte jedoch bei Betrachtung des Mittelwerts über den Anteil nichtfunktionaler
Anforderungen kein Unterschied festgestellt werden. Das entspricht den
Erwartungen, die darauf gestützt waren, dass die Möglichkeit besteht, mit Fast Feedback
einen Demonstrations-Prototyp erstellen zu können. Bei der Darstellung der Ergebnisse
konnte man sehen, dass zwar acht von neun Probanden der Experimentgruppe Mock-ups
erstellt haben, allerdings wurde auch dieses Feature teilweise in einem nur sehr geringem
Maße verwendet, woran wieder die knapp angelegte Anforderungserhebungszeit ihren Anteil
haben mag. Man könnte sich aber auch vorstellen, dass den Kunden im ersten Gespräch
vielleicht noch gar nicht wichtig ist, wie die Oberfläche der gewünschten Software genau
aussehen soll. Es ist vielleicht interessanter, doch erstmal über konkrete Funktionen zu
sprechen, als z.B. darüber, wo genau welches Eingabefeld platziert werden soll. Es wäre
sicherlich auch hier interessant, die Auswirkungen über eine längere

6 Analyse und Interpretation | 79
Anforderungserhebungszeit oder sogar über zwei Anforderungsinterviews hinweg zu
betrachten.
G1.3 Untersuche die Benutzbarkeit von Werkzeugen (Word und Fast Feedback) in der
Anforderungserhebung aus der Perspektive des Anforderungsingenieurs/Projektmanagers.
Geprüft werden sollte die Hypothese, dass die Benutzbarkeit von Fast Feedback mindestens
so gut ist, wie die von Word.
Die dazu zunächst aufgestellte Vermutung, dass Fast Feedback im Hinblick auf die
Durchführung einer Anforderungserhebung mindestens genauso verständlich ist wie Word,
kann bestätigt werden. Die Definition „Werkzeug verstanden“ enthielt als erste Bedingung die
Voraussetzung, dass die Probanden beider Gruppen maximal fünf Minuten verstreichen
lassen, ehe sie das jeweilige Werkzeug zum Einsatz bringen. Nur ein Proband der
Experimentgruppe ließ sich mehr (nämlich gut zehn Minuten) Zeit, ehe er Anforderungen mit
Hilfe des Werkzeugs (Fast Feedback) dokumentierte. Allerdings stellen seine Ergebnisse
nicht die eines statistischen Ausreißers dar, so dass man dem Probanden zugestehen kann,
einfach mit einer anderen Zeiteinteilung innerhalb des vorgegebenen Zeitrahmens
vorgegangen zu sein. Die zweite Bedingung, dass die vorher definierten Grundfunktionen mit
Hilfe dokumentierter Anforderungen zu mindestens 40% berücksichtigt wurden, wurde
ebenfalls von den Probanden beider Gruppen erfüllt. Die Features der Werkzeuge wurden
allerdings nicht von allen Probanden gleichermaßen eingesetzt. Nimmt man zum Vergleich
unter den Gruppen die Anzahl der erstellten Mock-ups, so erkennt man bei den Probanden der
Experimentgruppe eine stärkere Variation als bei den Probanden der Kontrollgruppe. Das
könnte beispielsweise daran liegen, dass einige Probanden der Experimentgruppe sich
schneller in das für sie neue Werkzeug Fast Feedback einarbeiten konnten als die anderen und
der Umgang mit Word im allgemeinen schon vertraut ist. Damit stellt auch wieder die
kalkulierte Anforderungserhebungszeit einen Einfluss dar. Mit einem größeren Zeitrahmen
hätte die Probanden der Experimentgruppe vielleicht alle eine Möglichkeit zur Einarbeitung
gehabt. Letztlich kann man also sagen, dass Fast Feedback zumindest so verständlich ist wie
Word, aber durch seinen Unbekanntheitsfaktor eine längere Einarbeitungszeit bezüglich der
Verwendung in einer Anforderungserhebung erfordert.
Des Weiteren sollte geprüft werden, ob sich der Anforderungsingenieur durch das jeweilige
Werkzeug in seiner Anforderungserhebung unterstützt fühlt das heißt wie er den Einsatz des
Werkzeugs im Rahmen einer Anforderungserhebung beurteilt. Die Bedienung betreffend
wurde bei beiden Werkzeugen die Schulnote „2“ erwartet und genauso wurden die
Werkzeuge im Rahmen der Befragung auch beurteilt, wobei die Tendenz bei Fast Feedback
etwas besser ist wie ein Blick auf die Verteilungen der Zufallsvariablen gezeigt hat. Der
Aufbau der Werkzeuge bezogen auf die Verwendung in einem Anforderungsinterview wurde
im Vorfeld des Experiments bei Fast Feedback besser (Schulnote „2“) als bei Word
(Schulnote „4“) eingeschätzt. Der Unterschied stellt sich nun nicht ganz so deutlich dar,
dennoch kann hier ein kleiner Vorteil für Fast Feedback verzeichnet werden. Betrachtet man
die Beurteilung des Werkzeugs insgesamt, so kann zwischen den Werkzeugen wiederum kein
wesentlicher Unterschied mehr festgestellt werden. Die Spanne zwischen der besten und der
schlechtesten Beurteilung ist bei Fast Feedback wieder größer. Es lässt sich sagen, dass Fast
Feedback zumindest nicht schlechter abgeschnitten hat als Word. Die Beurteilung der
Werkzeuge bestätigt vielmehr die Theorie, dass einige Probanden mit der kurzen
Einarbeitungszeit zurechtgekommen sind und andere nicht. Letztere sind wahrscheinlich
genau die Probanden, die die Benutzbarkeit weniger gut eingeschätzt haben.

6 Analyse und Interpretation | 80
Insgesamt wurde das Werkzeug Fast Feedback ähnlich gut verstanden wie Word und die
Probanden fühlten sich größtenteilt unterstützt.
6.2 Ergebnisaufbereitung durch Bewertung der Gültigkeit
Das hier zugrundeliegende Experiment soll in Anlehnung an die Aufteilung der
Validitätsarten nach [Woh+99] bewertet werden. Demnach gibt es die folgenden vier
Validitätsarten in der Experimentplanung: „conclusion validity“, „internal validity“, „external
validity“ und „construct validity“. Sie sollen hier zunächst kurz mit Hilfe von repräsentativen
Fragen beschrieben werden und dann als Grundlage für die abschließende Bewertung dienen.
1. „Conclusion validity“ (Gültigkeit der Schlussfolgerungen):
Besteht ein statistisch nachweisbarer Zusammenhang zwischen der unabhängigen und der
abhängigen Variable? Ist der Unterschied signifikant?
2. „Construct validity“ (Gültigkeit der Konstrukte):
Sind die unabhängige und die abhängige Variable in zuverlässiger Weise messbar
gemacht worden? Entspricht das im Experiment aufgestellte Konstrukt von unabhängiger
und abhängiger Variable tatsächlich dem theoretisch zugrundeliegenden Konstrukt?
3. „Internal validity“ (interne Gültigkeit):
Lässt sich die Variation der abhängigen Variable auf die Variation in der unabhängigen
Variable zurückführen? Gibt es Störvariablen, die für die Variation der abhängigen
Variablen verantwortlich sein können?
4. „External validity“ (externe Gültigkeit):
Lässt sich das Ergebnis generalisieren (z.B. auf anderes Umfeld, andere Werkzeuge)?
6.2.1 Bewertung der Schlussfolgerungen
Keinem Ergebnis konnte eine statistische Signifikanz nachgewiesen werden. Der Effekt, der
sich zu der Hypothese über die Erkennung von Fehlern zeigt, ist nicht groß genug, um eine
Signifikanz schon mit einem kleinen Stichprobenumfang zu zeigen. Die Ergebnisse zu der
Hypothese über die Anzahl von dokumentierten Anforderungen und das Verhältnis ihrer
Klassen zeigen genau das Gegenteil von dem, was erwartet wurde, aber auch hier bleibt die
Prüfung auf Signifikanz ohne Erfolg. Letztendlich muss für ein signifikantes Resultat und
eine höhere Gültigkeit der Ergebnisse der Stichprobenumfang vergrößert werden. Dies gilt
zumindest dann, wenn die bisher gegebenen Experimentbedingungen erhalten bleiben. Eine
andere Möglichkeit, die statistische Signifikanz nachzuweisen, ist, alles daran zu setzen,
potenzielle Störvariablen zu vermeiden, um den durch die Störvariablen möglicherweise
„versteckten“ Effekt sichtbarer zu machen. Dazu können die aus diesem Experiment
gewonnenen Erfahrungen nützlich sein. Um was für Störvariablen es sich dabei handelt, soll
im Kapitel über die interne Validität zusammengefasst werden.

6 Analyse und Interpretation | 81
6.2.2 Bewertung des Konstrukts
Beurteilt man nun den Einfluss der Metriken auf die Ergebnisse, so entdeckt man auch dort
eine Auffälligkeit. Man muss bei der Hypothese, wie sie aufgestellt wurde, davon ausgehen,
dass auch tatsächlich Fehler gemacht werden, denn ansonsten könnte der
Anforderungsingenieur mit Hilfe des jeweiligen Werkzeugs auch keine finden. Wie
wahrscheinlich ist es also, dass keine Fehler gemacht werden? In einer
Anforderungserhebung, wie in diesem Experiment, durchgeführt sind zwei Menschen
beteiligt. Menschen machen Fehler und je komplexer der Kontext desto mehr Fehler werden
gemacht. Die Entwicklung von Software an sich ist immer komplex, auch wenn an
überschaubaren Szenarien gearbeitet wird. Die Möglichkeiten der Umsetzung sind vielfältig
und die entsprechenden Anforderungen an die Software können ebenso vielfältig
dokumentiert werden. Jeder Mensch bringt zudem andere Kenntnisse und seine eigene
Persönlichkeit mit in das Gespräch zwischen Anforderungsingenieur und Kunde. Es ist also
höchst unwahrscheinlich, dass keine Fehler gemacht werden, wie auch in den Ergebnissen zu
der Hypothese über die Erkennung von Fehlern sichtbar wird. Hier liegt kein großes Risiko
für die Gültigkeit der Ergebnisse vor. Allenfalls könnte man, um sicher zu gehen, wiederum
einen größeren Stichprobenumfang wählen.
Das Konstrukt des Experiments entspricht dennoch nicht ganz dem theoretischen Konstrukt
einer Anforderungserhebung. Im Experiment wurde die Variabilität des Kunden nicht
berücksichtigt, um den möglichen Effekt des Werkzeugs deutlicher erkennen zu können. Nun
muss man sich fragen, was die fehlende Variabilität des Kunden für Auswirkungen auf die
Ergebnisse haben könnte. Viele Kunden kennen sich im Bereich der Softwareentwicklung
selbst nicht aus. Er lässt sich deshalb bei der Umsetzung seiner Wünsche von dem
Anforderungsingenieur beraten. Der Anforderungsingenieur nimmt Einfluss auf die
Gesprächsentwicklung und die vom Kunden zu treffenden Entscheidungen bzgl. der von ihm
gewünschten Software. In umgekehrter Richtung ist ein Einfluss dieser Stärke eher nicht
gegeben. Der Kunde beschreibt dem Anforderungsingenieur, wie er sich die zu entwickelnde
Software vorstellt. Das hat aber wahrscheinlich kaum Auswirkungen darauf, was der
Anforderungsingenieur von den Informationen des Kunden für wichtig hält und welche er in
Form von Anforderungen, Use Cases oder Mock-ups dokumentiert. Der Kunde ist zwar auch
gefragt, was das Aufdecken von Fehlern angeht, nur ist er auch dabei wieder mehr auf den
Anforderungsingenieur angewiesen als umgekehrt. Der Anforderungsingenieur muss dem
Kunden erstmal dokumentierte Anforderungen zeigen, damit er als Kunde überhaupt Fehler
aufdecken kann, und das ist oft schon nicht gegeben. In diesem Experiment die Variabilität
des Kunden nicht zu berücksichtigen, war in sofern die richtige Entscheidung, als dass der
Einfluss des Anforderungsingenieurs auf den Kunden letztendlich stärker einzuschätzen ist als
umgekehrt, die Ergebnisse wahrscheinlich nur gering durch diese Entscheidung beeinflusst
werden und es wichtiger war, den Effekt des Werkzeugs nicht durch Störvariablen zu
bedecken.
In dieser Arbeit wurde mehrfach die Annahme gemacht, dass eine Zufallsvariable
normalverteilt ist. Für eine „Anzahl“ ist eine Annahme auf Normalverteilung streng
mathematisch gesehen eigentlich nicht üblich, für Anwender (hier aus dem Bereich der
Softwareentwicklung) aber trotzdem machbar. Die Annahmen auf Normalverteilung in dieser
Arbeit wurden mit Hilfe des Kolmogoroff-Smirnov-Anpassungstests in „R“
(Statistikprogramm) abgeschätzt. Es konnten keine wesentlichen Abweichungen von der
Normalverteilung festgestellt werden, so dass hier vermutlich nur ein geringes Risiko für die

6 Analyse und Interpretation | 82
Gültigkeit der Ergebnisse besteht. Trotzdem gibt es sicherlich andere Möglichkeiten als die,
eine „Anzahl“ als normalverteilt anzunehmen, die aber nicht Teil dieser Arbeit sein sollen.
6.2.3 Bewertung der internen Validität
In dieser Arbeit war es ein Anliegen, möglichst nur die eine unabhängige Variable
„Werkzeug“ zuzulassen. Alle anderen unabhängigen Variablen könnten sich als Störvariablen
herausstellen und die Gültigkeit der Ergebnisse negativ beeinflussen. Es soll nun aufgezeigt
werden, in wie weit es geglückt ist, den Einfluss von Störvariablen zu minimieren.
Als erstes soll die Doppelrolle Experimentleiterin/Kundin betrachtet werden. Die Kundin
hatte (die Ziele der Experimentleiterin im Hinterkopf) die Möglichkeit, mit ihren Antworten
und (Re-)Aktionen das Gespräch in einem gewissen Maße zu lenken. Diesem Rollenkonflikt
wurde entgegengewirkt, indem für die Kundin ein Drehbuch und somit bestimmte
Verhaltensregeln im Vorfeld des Experiments erstellt wurden. Letztendlich hat das Drehbuch
seinen Nutzen zufriedenstellend erfüllt, so dass die Doppelrolle an sich kein Risiko für die
Gültigkeit der Ergebnisse darstellt.
Schaut man aber separat auf die Rolle der Kundin, so kann man schon sagen, dass die ersten
Experimente trotz Drehbuch noch einer gewissen Unsicherheit unterlagen. Die Kundin hat
sich zwar an definierte Richtlinien halten können, allerdings gehört auch grundsätzlichen zum
Simulieren von Szenarien etwas Übung. Es entstand also in den ersten Experimenten ein
Lerneffekt bei der Kundin, das heißt sie übte sich sozusagen in ihrer Rolle. Um dem Einfluss
dieser Störvariablen entgegenzuwirken sollten gegebenenfalls die ersten (beispielsweise vier)
Experimente verworfen werden. Dies war hier aufgrund des ohnehin schon sehr geringen
Stichprobenumfangs nicht möglich. Dennoch sind die Auswirkungen eines Lerneffekts
überschaubar. Die Antworten der Kundin auf Fragen des Anforderungsingenieurs wurden
innerhalb der ersten Experimente bezogen auf die gewünschte Software (Beispiel „SE-
Bibliothek“) etwas gezielter und die Kundin bekam auch ein besseres Gefühl dafür, welche
Fragen sie als Kundin, die in ihrer Rolle nicht aus dem Fachbereich der Informatik stammt,
beantworten kann und welche so fachspezifisch sind, dass sie, wie im Drehbuch definiert,
Rückfragen an den Anforderungsingenieur stellt. Es handelt sich also bei dem möglichen
Lerneffekt der Kundin um ein eher kleines Risiko für die Ergebnisse dieser Arbeit.
Für die Rolle der Experimentleiterin bestand die Gefahr, die Klassifizierung so
durchzuführen, dass die Wiederholbarkeit des Experiments nicht gegeben sein könnte. Die
Art der Klassifizierung wurde aber im Vorfeld wieder genau festgelegt, um mögliche
Abweichungen zwischen den von unterschiedlichen Personen durchgeführten
Klassifizierungen zu vermeiden. Um die Robustheit der entsprechenden Definitionen
gegenüber anderen klassifizierenden Personen und damit die Wiederholbarkeit des
Experiments zu prüfen, wurde aus jeder Gruppe eine Anforderungserhebung zufällig
herausgesucht und noch von einer zweiten Person ausgewertet. Die Auswertung beinhaltete
wieder das Herausschreiben der Anforderungen anhand der vorhandenen Ton- und
Bildschirmaufzeichnungen, das Aufteilen und das Klassifizieren der Anforderungen. Die
Ergebnisse der Erstauswertung und der Kontrollauswertung liegen dabei nah beieinander. Nur
bei der Klassifizierung in funktionale und nicht-funktionale Anforderungen zeigen sich
auffällige Unterschiede (vgl. Abb.29).

6 Analyse und Interpretation | 83
Abbildung 29: Prüfung der Anforderungs-Definitionen auf Robustheit
Die entsprechenden Definitionen für funktionale und nicht-funktionale Anforderungen
entstammen im Gegensatz zu den anderen Anforderungs-Definitionen, die erst im Rahmen
dieser Arbeit aufgestellt wurden, der Literatur. Vermutlich hätten sie im Rahmen dieser
Arbeit noch etwas spezifischer formuliert werden müssen, da Klassifizierung in funktional
oder nicht-funktional in der Softwareentwicklung ohnehin schon als schwierig und nicht
immer eindeutig gilt. Da die Abweichung bei der Anzahl der nicht-funktionalen
Anforderungen zwischen den Erfassern bei beiden Proben ähnlich ausfällt, kann man
vermuten, dass der Kontrollerfasser, hätte er alle Anforderungserhebungen ausgewertet, zu
einem vergleichbaren Ergebnis gekommen wäre wie die Erfasserin der in dieser Arbeit
vorgestellten Ergebnisse. Vergleichbare Ergebnisse können deshalb angenommen werden,
weil gleichmäßige Abweichungen bei der Auswertung jedes Probanden am betrachteten
Verhältnis von funktionalen zu nicht-funktionalen Anforderungen nichts geändert hätten.
Nun soll auch noch die Rolle des Anforderungsingenieurs beleuchtet werden. Die Probanden
dieses Experiments bringen ganz ähnliche Voraussetzungen mit, denn darauf wurde bei der
Auswahl geachtet. Alle stammen aus dem universitären Umfeld und haben insbesondere
einen durch ihren Studiengang bedingten Bezug zum Fachbereich Software Engineering.
Nichts desto trotz gibt es Voraussetzungen, die sich nur schwer kontrollieren lassen. Dazu
gehört beispielsweise, wie schnell sich ein Proband in das ungewohnte Experimentumfeld und
natürlich in das unbekannte Werkzeug Fast Feedback einarbeiten kann. Das wiederum hängt
entschieden davon ab, wie die Benutzbarkeit des Werkzeugs zu beurteilen ist. In diesem
Experiment hat das Werkzeug ausreichend gut abgeschnitten, um den Einfluss auf die
anderen Ziele als gering einstufen zu können. Allerdings basieren die Erkenntnisse zu der
Benutzbarkeit des Werkzeugs auf persönlichen Erfahrungen und Einschätzungen weniger
Probanden, weshalb ein Einfluss auch nicht völlig ausgeschlossen werden kann.
Blickt man nun von den an dem Experiment beteiligten Personen rüber zu dem Gerüst des
Experiments, so war es rückblickend gut für die Gültigkeit der Ergebnisse, dass die Art der
Hilfsmittel in beiden Gruppen so identisch wie möglich gehalten wurden. Beide Gruppen
hatten die gleiche Technik, nämlich den Tablet-PC zur Verfügung. Jeder Proband
dokumentierte die erhobenen Anforderungen in elektronischer Form. Allerdings hätte die
Tastatur zum Schreiben nicht als Alternative zur automatischen Schrifterkennung freigestellt,
sondern zur einzigen Möglichkeit erklärt werden sollen. Hier wurde nicht berücksichtigt, dass
sich die Probanden der Experimentgruppe gegebenenfalls in zweifacher Weise einarbeiten
müssen – in die automatische Schrifterkennung und Fast Feedback. Da sich allerdings nicht
viele Probanden ausschließlich an der automatischen Schrifterkennung versucht haben, bleibt
der Einfluss auf die Gültigkeit der Ergebnisse, wenn auch vorhanden, gering.

6 Analyse und Interpretation | 84
6.2.4 Externe Validität
Bei Beurteilung der externen Validität stellt sich einerseits die Frage, ob sich die in dieser
Arbeit beobachteten Auswirkungen von Fast Feedback in der Anforderungserhebung auf
andere Werkzeuge übertragen lassen, und andererseits, ob sich das universitäre Umfeld auf
ein reales übertragen lässt.
Werkzeuge zur Verbesserung der Anforderungserhebung haben alle unterschiedliche
Eigenschaften und Ziele, aber sie lassen sich in Kategorien einteilen. Fast Feedback soll
vorrangig die Validierung zu einem frühen Zeitpunkt der Anforderungserhebung möglich
machen, indem die Fehlererkennung erleichtert wird. Außerdem soll das Werkzeug dem
Anforderungsingenieur helfen, mehr Informationen dadurch zu bekommen, dass es dem
Kunden möglich gemacht wird, genauere Vorstellungen zu dem gewünschten Produkt zu
entwickeln. Das sind ganz typische Ziele für die Verbesserung von Anforderungserhebungen.
Deshalb gibt es dort ein breites Spektrum an erfolgversprechenden Werkzeugen. Der in
Kapitel 2.1.2.1 vorgestellte Vision Catcher gehört beispielsweise auch dazu. Diese
Werkzeuge zielen auf eine ähnliche Art der Verbesserung ab und gehören deshalb einer
Kategorie an. Das Prinzip dieser Werkzeuge ist dann meist auch ganz ähnlich. Fast Feedback
und Vision Catcher arbeiten etwa beide mit einem Demonstrationsprototyp, wenn dieser auch
anders umgesetzt wurde. Die Erkenntnisse dieser Arbeit lassen sich gewiss auf Werkzeuge
der gleichen Kategorie übertragen. Wenn der Demonstrationsprototyp, wie auch immer er
umgesetzt wurde, in Fast Feedback die Anforderungserhebung verbessert, dann wird es mit
großer Wahrscheinlichkeit auch der im Vision Catcher - natürlich immer eine ausreichend
hohe Benutzbarkeit vorausgesetzt. Allerdings sagen die Ergebnisse dieser Arbeit nichts über
Werkzeuge aus, die eine Anforderungserhebung unter ganz anderen Aspekten verbessern
sollen das heißt die einer anderen Kategorie angehören.
Ob sich die Ergebnisse aus dem universitären auch in ein reales Umfeld übertragen lassen, hat
ganz explizit das Experiment im industriellen Umfeld gezeigt. Dies soll nun vor dem
abschließenden Fazit noch im nächsten Kapitel vorgestellt werden. Dort wird dann auch
abschließend Stellung zur Übertragbarkeit der Ergebnisse in ein industrielles Umfeld
genommen.
6.3 Ergebnisse aus dem industriellen Umfeld
Vorweg sei gesagt, dass der Umfang der aus dem industriellen Umfeld gezogenen Stichprobe
mit einer Anzahl von sechs Probanden für die Experiment- und vier Probanden für die
Kontrollgruppe sehr gering ist. Deshalb soll mit den hier vorgestellten Ergebnissen zunächst
lediglich eine Einschätzung darüber abgegeben werden, ob die zuvor aus dem universitären
Umfeld eventuell auf ein industrielles Umfeld übertragbar sind. Fällt die Einschätzung so aus,
dass eine Übertragbarkeit denkbar ist, so kann dann noch entschieden werden, ob es Sinn
macht, die Stichproben aus den beiden verschiedenen Bereichen zu einer Stichprobe
zusammenzufügen und auf diese Stichprobe wieder die statistischen Tests zur Prüfung der
Signifikanz der Ergebnisse anzuwenden.
Zunächst soll die Frage nach einer verbesserten Fehlererkennung mit der Verwendung Fast
Feedback betrachtet werden. Die Ergebnisse der im industriellen Umfeld durchgeführten
Anforderungserhebungen weisen einen Unterschied zu den Ergebnissen der im universitären
Umfeld durchgeführten Anforderungserhebungen auf. Im industriellen Umfeld hat nur ein
Proband der Experimentgruppe einen Fehler erkannt, die übrigen Probanden dieser Gruppe

6 Analyse und Interpretation | 85
haben keinen Fehler erkannt. Ein Proband der Kontrollgruppe hat zwei Fehler erkannt und
alle anderen Probanden dieser Gruppe haben wiederum keinen Fehler aufgedeckt (vgl.
Abb.30).
Abbildung 30: Häufigkeit, mit der eine bestimmte Anzahl von Fehlern erkannt wurde (Industrie)
Vergleicht man die Ergebnisse aus dem universitären und dem industriellen Umfeld
miteinander, so stellt man fest, dass im universitären Umfeld die Experimentgruppe 80% der
von dieser Stichprobe insgesamt erkannten Fehler aufgedeckt hat, die Experimentgruppe aus
dem industriellen Umfeld aber nur 33% (vgl. Abb.31). Das heißt, im universitären Umfeld hat
die Experimentgruppe die meisten Fehler erkannt, aber im industriellen Umfeld war es die
Kontrollgruppe.
Abbildung 31: Verhältnis zwischen den Gruppen eines Umfelds bzgl. der Anzahl der erkannten Fehler
Natürlich muss man berücksichtigen, dass die 33% der Experimentgruppe aus dem
industriellen Umfeld aus einer Gesamtanzahl von nur drei erkannten Fehlern resultieren, aber
dennoch ist hier einfach nicht die gleiche Tendenz bzgl. einer möglichen Verbesserung der
Fehlererkennung durch Fast Feedback erkennbar. Aus diesem Grund wird bei dieser
Fragestellung davon abgesehen, die Stichproben der unterschiedlichen Bereiche zu einer
Stichprobe zusammenzufügen.
Nun soll die Anzahl der dokumentierten Anforderungen der Stichprobe aus dem industriellen
Umfeld untersucht werden. Wieder wird der Mittelwert über die jeweilige Art der
Anforderungen betrachtet. Die Probanden der Kontrollgruppe haben mehr Anforderungen in

6 Analyse und Interpretation | 86
Text und auch mehr insgesamt dokumentiert (vgl. Abb.32). Dabei haben sie aber auch nicht
wesentlich weniger Anforderungen in Mock-ups dokumentiert als die Experimentgruppe.
Man würde auf den ersten Blick sogar sagen, dass beide Gruppen sehr wenige Anforderungen
in Mock-ups dokumentiert haben.
Abbildung 32: Mittelwerte über die Anzahl dokumentierter Anforderungen je Gruppe (Industrie)
Gemessen an der Gesamtanzahl der dokumentierten Anforderungen sieht es aber etwas anders
aus. Die Experimentgruppe hat 27% der Anforderungen in Mock-ups dokumentiert, die
Kontrollgruppe dagegen nur 4%. Dabei wurden die doppelt dokumentierten Anforderungen
der Experimentgruppe nicht berücksichtigt. Das ist der einzige wesentliche Unterschied, der
sich im Vergleich zu den Ergebnissen der Stichprobe aus dem universitären Umfeld zeigt. Bei
einem Vergleich der beiden Stichproben aus den unterschiedlichen Bereichen Universität und
Industrie zeigt sich bezogen auf die in Text und insgesamt dokumentierten Anforderungen
sonst ein ganz ähnliches Bild (vgl. Abb.33).
Abbildung 33: Anzahl der dokumentierten Anforderungen je Stichprobe und Gruppe
Bezogen auf die Fragestellung, ob mit Fast Feedback mehr Anforderungen dokumentiert
werden, könnte man sicherlich überlegen, die beiden Stichproben aus den unterschiedlichen

€
€
€
€
6 Analyse und Interpretation | 87
Bereichen zu einer Stichprobe zusammenzufassen und die Gültigkeit der Aussage durch
Anwenden eines statistischen Tests erneut abschätzen.
Sei X die Zufallsvariable mit Werten x1 ,..., x11 , die jeder Anforderungserhebung der
Kontrollgruppe (jetzt Universität und Industrie) eine Anzahl von dokumentierten
Anforderungen zuordnet, und Y die Zufallsvariable mit Werten y1 ,...,y15 , die jeder
Anforderungserhebung der Experimentgruppe (jetzt Universität und Industrie) eine Anzahl
€
von dokumentierten Anforderungen zuordnet. Es wird weiter angenommen, dass die
Zufallsvariablen X und Y normalverteilt sind. Seien µ x ,µ y ∈ unbekannte Erwartungswerte.
€
Die Nullhypothese H0,2a : µ = µ 0 soll gegen die Alternativhypothese H1,2a : µ ≠ µ 0 getestet
werden. Die Mittelwerte sind x = 30,18 und y =16,53. Die Stichprobenvarianzen sind
2 2
sx = 73,16 und sy = 78,98. Die gewichtete € Varianz ist dann
€
s
€
€
€
€
2 = 11−1 ( )⋅ 73,16 + ( 15 −1)⋅
78,98
= 76,56.
11+15 − 2
Für die Prüfgröße t ergibt sich dann
t =
11⋅ 15 30,18 −16,53
⋅ = 2,519⋅ 1,56 = 3,930.
11+15 8,750
kann zum Signifikanzniveau verworfen werden, da der Wert für
größer ist als das 0,975-Quantil der t-Verteilung mit 11+15 − 2 = 24 Freiheitsgraden:
t = 3,930 > 2,064 = t( 24; 0,975).
€
€
Legt man die Kontroll- und Experimentgruppe der Stichproben aus den verschiedenen
Bereichen Universität und Industrie jeweils zusammen und testet, ob es bzgl. der insgesamt
(in Text und in Mock-ups) dokumentierten Anforderungen einen Unterschied zwischen den
Gruppen gibt, dann kann man durch die Anwendung des zweiseitigen Zweistichproben-t-
Tests die Hypothese, dass es einen Unterschied gibt, stützen. Es ist anzunehmen, dass man
mit Word mehr Anforderungen dokumentiert als mit Fast Feedback.
Schaut man nun auf das Verhältnis von funktionalen zu nicht-funktionalen dokumentierten
Anforderungen innerhalb der Ergebnisse aus der Industrie und vergleicht sie mit denen aus
dem universitären Umfeld, dann zeigen sich auch dabei ganz ähnliche Ergebnisse.
Abbildung 34: Verhältnis funktionaler zu nicht-funktionaler Anforderungen (Industrie)
t

6 Analyse und Interpretation | 88
Auch hier wäre die erneute Anwendung eines statischen Tests auf die zusammengefasste
Stichprobe sicherlich möglich und sinnvoll. Da allerdings kein Unterschied zwischen den
Ergebnissen der beiden Gruppen zu erwarten ist, den man mit einem statistischen Test
unterstreichen wollen würde, soll hier auf die Anwendung verzichtet werden.
Zuletzt sollen die Ergebnisse zu der Frage der Benutzbarkeit von Fast Feedback
zusammengetragen werden. Wieder kann man erkennen, dass nicht alle Features genutzt
wurden. Nur ein Proband der Experimentgruppe hat überhaupt Use Cases untereinander
verknüpft. Seine (zwei) Verknüpfungen fallen bei Betrachtung des Mittelwerts über alle sechs
Probanden dieser Gruppe aber nicht ins Gewicht, so dass hier durchschnittlich null Use Cases
miteinander verknüpft wurden. Tatsächlich hat aus dieser Experimentgruppe kein Proband
einen Demonstrations-Prototyp gezeigt (vgl. Abb.35).
Abbildung 35: Häufigkeit, mit der Features durchschnittlich eingesetzt wurden (Industrie)
Es soll nun gezeigt werden, wie die Probanden aus dem industriellen Umfeld Word und Fast
Feedback als Werkzeug in der Anforderungserhebung mit Hilfe von Schulnoten (vgl. Tab.8)
bewertet haben. Die Beurteilung für Fast Feedback ist ganz ähnlich der, die sich schon bei der
Betrachtung der Ergebnisse aus dem universitären Umfeld gezeigt hat (vgl. Tab.9/10 und Tab.
13/14). Die Bedienung von Word schneidet bei den Probanden aus der Industrie zwar besser
ab, der Aufbau von Word und Word insgesamt schneiden für den Einsatz in einer
Anforderungserhebung jedoch schlechter ab als bei den Probanden der Universität. In beiden
Tabellen wurden sowohl die auf volle Noten gerundeten als auch die auf eine Dezimalstelle
genau berechneten Werte dargestellt.
Werkzeug
Beurteilung
Word Fast Feedback
Bedienung 2 (1,8) 2 (2,3)
Aufbau 3 (3,0) 2 (2,0)
insgesamt 3 (3,0) 2 (2,0)
Tabelle 13: Bewertung der Werkzeuge in Schulnoten per Mittelwert (Industrie)

6 Analyse und Interpretation | 89
Werkzeug
Beurteilung
Word Fast Feedback
Bedienung 1 (1,0) 2 (2,0)
Aufbau 3 (2,5) 2 (2,0)
insgesamt 3 (2,5) 2 (2,0)
Tabelle 14: Bewertung der Werkzeuge in Schulnoten per Median (Industrie)
Letztendlich kann man sagen, dass die Bedienung von Fast Feedback im Hinblick auf den
Einsatz des Werkzeugs in einer Anforderungserhebung zwar schlechter scheint als die von
Word, das Werkzeug aber trotzdem in allen Bereichen für „gut“ im Sinne einer Schulnote
beurteilt wurde.
Der Vergleich der Anforderungserhebungen aus den Bereichen der Industrie und der
Universität zeigt, dass es Unterschiede bzgl. der Anzahl erkannten Fehler gibt. Dass in der
Industrie weniger Fehler erkannt werden, kann eventuell damit zusammenhängen, dass die
Anforderungsingenieure der Industrie durch ihre Berufserfahrung weniger Fehler machen.
Fehler die nicht gemacht werden, können auch nicht erkannt werden. Dieses mögliche
Problem wurde ja schon in Kapitel 6.2 bei der Bewertung der Metriken diskutiert. Bei der
Stichprobe aus dem universitären Umfeld schien das kein Problem zu sein, aber eventuell ist
es das in der Industrie. Diese Frage kann hier nicht abschließend geklärt werden.
Naheliegender ist aber, dass ganz einfach der Umfang der Stichprobe aus der Industrie zu
klein ist. Obwohl der Umfang der Stichprobe aus dem universitären etwas größer ist, reicht
der schon nicht aus, um eine Signifikanz der zugehörigen Ergebnisse zeigen zu können. Da
die beiden Stichproben aber auch unterschiedliche Tendenzen bzgl. Ihrer Ergebnisse
aufweisen, können sie auch nicht zusammengelegt werden. Vergleicht man die
Anforderungserhebungen aus den Bereichen der Industrie und der Universität bzgl. der
Anzahl der dokumentierten Anforderungen, so stellt man fest, dass die Ergebnisse ähnlich
sind. Das Zusammenlegen der Stichproben und die erneute Anwendung des zweiseitigen
Zweistichproben-t-Tests auf die zusammengelegt Stichprobe zeigte, dass mit Word mehr
Anforderungen dokumentiert wurden. Das spricht dafür, dass die eingeschränkte
Anforderungserhebungszeit sich auch hier ausgewirkt hat. Kostbare Zeit zum Dokumentieren
von Anforderungen ging wahrscheinlich dadurch verloren, dass die Probanden sich in das
Werkzeug Fast Feedback erst einarbeiten mussten. Dass die Bewertung für Fast Feedback
trotzdem gut ausgefallen ist, kann darin begründet liegen, dass das Problem, sich in das
Werkzeug einarbeiten zu müssen, bei einer Anwendung des Werkzeugs außerhalb dieses
Experiments nicht bestehen würde. Natürlich würde sich jeder Anforderungsingenieur schon
im Vorfeld einer Anforderungserhebung ausreichend mit den Funktionen des Werkzeugs
vertraut machen. Niemand würde unvorbereitet das Werkzeug anwenden.
Mit den Ergebnissen aus dem industriellen Umfeld lässt sich den Ergebnissen aus dem
universitären Umfeld schon eine gewisse Übertragbarkeit zusprechen. Diese Aussage muss
gegebenenfalls deshalb eingeschränkt werden, weil die Erfahrung des
Anforderungsingenieurs Einfluss auf die Qualität einer Anforderungserhebung haben kann
und dabei ist es wahrscheinlich unerheblich, ob diese mit oder ohne die Hilfe eines
Werkzeugs durchgeführt wurde. Die Erfahrung im Bereich Anforderungserhebung, die jeder
Proband mitbringt, kann als Störvariable ausschlaggebend dafür sein, dass der Effekt des
Werkzeugs überdeckt wird.

6 Analyse und Interpretation | 90
6.4 Fazit und Ausblick
In diesem Kapitel soll abschließend zusammengefasst werden, wie die Zweckdienlichkeit von
Fast Feedback mit den Ergebnissen des durchgeführten Experiments einzuschätzen ist, was
für Erkenntnisse über das Evaluieren von Werkzeugen gewonnen werden konnten und was
für Fragestellungen sich aus dem in dieser Arbeit durchgeführten Experiment für zukünftige
Projekte ergeben haben.
Das Werkzeug Fast Feedback hat den übergeordneten Zweck, als Anforderungsingenieur
schon im ersten Kundengespräch möglichst viele korrekte Informationen vom Kunden in
Form von dokumentierten Anforderungen zu bekommen. Eine Tendenz, dass das Werkzeug
Fast Feedback genau die dafür erforderlichen Eigenschaften mitbringt, lässt sich nach
Betrachtung der Ergebnisse zwar durchaus erkennen, allerdings konnten die gewonnen
Erkenntnisse nicht alle mit den Hilfsmitteln der Mathematik bestärkt werden. Die Funktionen
von Fast Feedback sind zwar insofern zweckmäßig, als dass das Werkzeug den
Anforderungsingenieur bei der Verbesserung der Fehlererkennung wie erwartet unterstützen
kann, um späte und teure Änderungen der zu entwickelnden Software zu vermeiden, aber ein
signifikanter Unterschied zu dem in der Anforderungserhebung und darüber hinaus weit
verbreiteten aber unspezialisierten Werkzeug Word konnte nicht festgestellt werden. Eine
Verbesserung bei der Dokumentation von Anforderungen zur Reduzierung der Termine bis
zur Vervollständigung der Anforderungserhebung, um die Anforderungserhebungsphase
insgesamt zu verkürzen, konnte mit der Verwendung von Fast Feedback gar nicht festgestellt
werden. Es ist anzunehmen, dass einige Unregelmäßigkeiten im Experimentaufbau dazu
geführt haben, dass die Vorteile von Fast Feedback nicht in ihrem ganzen Umfang
ausgeschöpft werden konnten. Außerdem wird vermutet, dass der Effekt, der durch den
Einsatz von Fast Feedback in der Anforderungserhebung erwartet wurde, durch einige geringe
Einflüsse, die sich aber in der Summe doch bemerkbar gemacht haben, teilweise überdeckt
wurde.
Mit dem durchgeführten Experiment sind einige Aspekte klar geworden, die beim
grundsätzlichen Evaluieren von Werkzeugen zur Unterstützung der Anforderungserhebung
berücksichtigt werden sollten. Da verschiedene Personen an einer Anforderungserhebung
beteiligt sind, die alle ihre persönlichen (Re-)Aktionseigenschaften mit sich bringen, ist es
schwierig, alle Einflüsse zu kontrollieren, um den möglichen Effekt des Werkzeugs auch
tatsächlich erkennen zu können. Aber gerade die Einflüsse, die nicht direkt etwas mit den der
(Re-)Aktion der beteiligten Personen zu tun haben, lassen sich doch relativ gut einschränken.
Da wäre zunächst die Technik zu erwähnen, die, wenn die Probanden mit ihr nicht alle
gleichermaßen vertraut sind, immer zum Hindernis werden kann. In diesem Experiment war
das die automatische Schrifterkennung. Solche Einflüsse können eingeschränkt werden, in
dem dafür gesorgt wird, dass alle Probanden die gleichen Vorraussetzungen bekommen. Sie
sollen nicht eine Technikvariante frei wählen können, um mögliche persönliche Ziele des
Probanden (wie z.B. „Das will ich mal ausprobieren.“) nicht zu provozieren. Gegebenenfalls
muss es auch bei der einen Technikvariante dann noch eine kurze Einführung geben, da man
nicht davon ausgehen kann, dass alle Probanden ähnliche Vorkenntnisse mitbringen. Auch die
Bedienung des zu evaluierenden Werkzeugs sollte mit den Probanden geübt werden. Es ist
unrealistisch, jemanden eine Anforderungserhebung mit einem Werkzeug durchführen zu
lassen, mit dem er nicht vertraut ist. Auch eine mehrjährige Berufserfahrung kann nicht
ausreichen, um ohne Übung alle Vorteile eines Werkzeugs ausnutzen zu können. Ohne
Einarbeitungszeit bliebe wahrscheinlich nur die Möglichkeit, jedem Probanden mehr
Anforderungserhebungszeit zur Verfügung zu stellen, was aber natürlich schnell den Rahmen
eines solchen Experiments sprengen kann. Des Weiteren ist es ratsam, die Benutzbarkeit eines

6 Analyse und Interpretation | 91
Werkzeugs vor dem eigentlich Experiment zu untersuchen. Denn stellt sich das Werkzeug als
ungenügend benutzbar heraus, dann kann das starke Auswirkungen auf die Ergebnisse haben
und der Aufwand, der zur Beantwortung anderer Untersuchungsziele betrieben wurde, könnte
nutzlos gewesen sein. Eine unzureichende Benutzbarkeit verursacht zudem Verunsicherung
bei den Probanden während der durchzuführenden Anforderungserhebung. Das wiederum
kann sich in den Ergebnisse des einzelnen Probanden widerspiegeln. Gerade bei Werkzeugen
mit aufeinander aufbauenden Funktionen sollte für jede Anforderungserhebung ausreichend
Experimentzeit eingeplant werden, um sicher zu gehen, dass auch alle Features, die zur
Zweckerfüllung des Werkzeugs wesentlich sind, vom Probanden verwendet werden können.
Dann sind noch einige Aspekte zusammenzutragen, die wieder die Rollen im Experiment
betreffen. Es ist möglich, ein und dieselbe Person mit zwei Rollen im Experiment zu
besetzten. Ein Drehbuch kann hier helfen. Wenn der Experimentleiter noch eine zweite Rolle
übernimmt, ist aber zu beachten, dass die Auswertung erst erfolgt, wenn alle Experimente
durchgeführt wurden. Das soll einen möglichen Experimentleitereffekt gering halten oder
sogar vermeiden. Sofern die Rolle des Kunden von nur einer Person übernommen wird,
sollten die ersten Experimente, sofern der Stichprobenumfang dafür ausreicht, verworfen
werden. Die in dieser Arbeit gewonnenen Erfahrungen haben gezeigt, dass die
Softwarewünsche des Kunden in den ersten drei bis vier Experimenten noch „reifen“
(Lerneffekt). Eine andere Möglichkeit ist natürlich, auch Rolle des Kunden variabel zu
machen. Dabei besteht aber in jedem Fall die Gefahr, dass dem Kunden zuzuordnende
Effekte dem Werkzeug zugesprochen werden. Wenn man aber alle anderen Einflüsse auf den
Effekt bestmöglich eingeschränkt hat, kann man natürlich überlegen, ob es nicht sinnvoller
ist, den Experimentaufbau realistisch mit variablen Kunden zu gestalten als auch noch den
„letzten“ Einfluss einzugrenzen. Solche Vorraussetzung wird es für den Einsatz des
Werkzeugs in der Realität nie geben. Die abschließende Lösung könnte ein deutlich höherer
Stichprobenumfang sein als er in dem Experiment dieser Arbeit zur Verfügung stand, aber
natürlich ist das schwierig umzusetzen.
Letztendlich haben sich die Fragen in dieser Arbeit immer wieder mit den verschiedenen
Rollen in einer Anforderungserhebung befasst. Insbesondere ergab sich nach der Betrachtung
der Ergebnisse aus dem industriellen Umfeld die Frage, welchen Einfluss die Erfahrung der
Probanden das heißt welchen Einfluss die Erfahrung des Anforderungsingenieurs im Bereich
Anforderungserhebung/Softwareentwicklung hat. An dieser Stelle könnte ein weiterführendes
Experiment ansetzen.

€
€
7 Anhang | 92
7 Anhang
Quantile der Normalverteilung
γ uγ 0,8 0,84162
0,9 1,28155
0,95
€
0,975
1,64485
1,95996
0,98 2,05375
0,99 2,32635
0,995 2,57583
0,9975 2,80703
0,998 2,87816
0,999 3,09023
0,9995 3,29053
Tabelle 15: γ -Quantil uγ der Normalverteilung
Quantile der t-Verteilung
€ €
γ 0,975 0,950
n
11 2,201 1,796
12 2,179 1,782
13 2,160 1,771
14 2,145 1,761
15 2,131 1,753
16 1,120 1,746
17 2,110 1,740
18 2,101 1,734
19 2,093 1,729
20 2,086 1,725
21 2,080 1,721
22 2,074 1,717
23 2,069 1,714
24 2,064 1,711
25 2,060 1,708
26 2,056 1,706
27 2,052 1,703
28 2,048 1,701
29 2,045 1,699
30 2,042 1,697
Tabelle 16: Auszug der Quantile
€
t n;γ der t-Verteilung

7 Anhang | 93
Kritische Werte des Grubbs-Tests
T n;0,95
T n;0,99
n
3 1,15 1,16
4 1,46 1,49
€
5
6
1,67
€
1,82
1,75
1,94
7 1,94 2,10
8 2,03 2,22
9 2,11 2,32
10 2,18 2,41
12 2,29 2,55
15 2,41 2,71
20 2,56 2,88
30 2,75 3,10
40 2,87 3,24
50 2,96 3,34
100 3,21 3,60
Tabelle 17: Auszug der kritischen Werte
€
T n;γ des Grubbs-Tests [Har+05, S.345]

Abbildungsverzeichnis | 94
Abbildungsverzeichnis
Abbildung 1: Wasserfallmodell [Schn05] nach [Roy70] ...........................................................8
Abbildung 2: Effektivität verschiedener Kommunikationsformen [Coc02] ............................11
Abbildung 3: Fast Feedback mit Use Case und Mock Up zum Beispiel "Geldautomat" ........12
Abbildung 4: Verteilungs- und Dichtefunktion der Normalverteilung [UniM].......................17
Abbildung 5: Hinweis und Beispiel zur Simulation einer Zufallsziehung ohne Zurücklegen
mit Excel...........................................................................................................................51
Abbildung 6: Fragebogen für die Kontrollgruppe....................................................................52
Abbildung 7: Fragebogen für die Experimentgruppe...............................................................52
Abbildung 8: Auswertungstabelle für Anforderungen .............................................................53
Abbildung 9: Theoretische Erfahrung der Probanden (Vorlesungen)......................................57
Abbildung 10: Praktische Erfahrung der Probanden (Projekte)...............................................58
Abbildung 11: Praktische Erfahrung der Probanden (Anforderungserhebungen) ...................58
Abbildung 12: Praktische Erfahrung der Probanden (Tablet-PC)............................................58
Abbildung 13: Praktische Erfahrung der Probanden (automatische Schrifterkennung) ..........59
Abbildung 14: Praktische Erfahrung der Probanden (Tablet-PC) (Industrie)..........................59
Abbildung 15: Häufigkeit, mit der Features durchschnittlich benutzt wurden ........................63
Abbildung 16: Anzahl der eingesetzten Features pro Proband der Experimentgruppe ...........64
Abbildung 17: Häufigkeit eingesetzter Features mit eingeschränkten
Kombinationsmöglichkeiten.............................................................................................64
Abbildung 18: Häufigkeit eingesetzter Features mit allen Kombinationsmöglichkeiten ........65
Abbildung 19: Mock-ups pro Proband der Kontrollgruppe .....................................................65
Abbildung 20: Boxplot zur Anzahl von Mock-ups ..................................................................66
Abbildung 21: Boxplots zur Beurteilung der Werkzeuge mit Schulnoten...............................67
Abbildung 22: Häufigkeit, mit der Probanden eine bestimmte Anzahl Grundfunktionen
dokumentierten.................................................................................................................68
Abbildung 23: Boxplot zur Anzahl dokumentierter Grundfunktionen ....................................68
Abbildung 24: Häufigkeit, mit der die Probanden Fehler erkannt haben oder nicht ...............69
Abbildung 25: Häufigkeit, mit der eine bestimmte Anzahl von Fehlern erkannt wurde .........69
Abbildung 26: Boxplots zur Anzahl erkannter Fehler .............................................................70
Abbildung 27: Mittelwerte über die Anzahl dokumentierter Anforderungen je Gruppe.........72
Abbildung 28: Verhältnis funktionaler zu nicht-funktionaler Anforderungen.........................72
Abbildung 29: Prüfung der Anforderungs-Definitionen auf Robustheit..................................83
Abbildung 30: Häufigkeit, mit der eine bestimmte Anzahl von Fehlern erkannt wurde
(Industrie) .........................................................................................................................85
Abbildung 31: Verhältnis zwischen den Gruppen eines Umfelds bzgl. der Anzahl der
erkannten Fehler ...............................................................................................................85
Abbildung 32: Mittelwerte über die Anzahl dokumentierter Anforderungen je Gruppe
(Industrie) .........................................................................................................................86
Abbildung 33: Anzahl der dokumentierten Anforderungen je Stichprobe und Gruppe ..........86
Abbildung 34: Verhältnis funktionaler zu nicht-funktionaler Anforderungen (Industrie).......87
Abbildung 35: Häufigkeit, mit der Features durchschnittlich eingesetzt wurden (Industrie) ..88

Tabellenverzeichnis | 95
Tabellenverzeichnis
Tabelle 1: Fehlerarten beim Testen [Har+05, S.133]...............................................................18
Tabelle 2: Skalenniveaus..........................................................................................................25
Tabelle 3: Abstraction Sheet zu Hypothese 1...........................................................................38
Tabelle 4: Abstraction Sheet zu Hypothese 2...........................................................................40
Tabelle 5: Abstraction Sheet zu Hypothese 3...........................................................................41
Tabelle 6: GQM-Modell...........................................................................................................43
Tabelle 7: Drehbuch .................................................................................................................56
Tabelle 8: Ordinalskala für Schulnoten....................................................................................66
Tabelle 9: Beurteilung der Werkzeuge in Schulnoten per Mittelwert......................................66
Tabelle 10: Beurteilung der Werkzeuge in Schulnoten per Median ........................................66
Tabelle 11: Werte für das Boxplot-Diagramm.........................................................................69
Tabelle 12: Bewertungsskala zur Erfahrung der Probanden ....................................................75
Tabelle 13: Bewertung der Werkzeuge in Schulnoten per Mittelwert (Industrie) ...................88
Tabelle 14: Bewertung der Werkzeuge in Schulnoten per Median (Industrie)........................89
Tabelle 15: γ -Quantil uγ der Normalverteilung.......................................................................92
Tabelle 16: Auszug der Quantile tn;γ der t-Verteilung .............................................................92
Tabelle 17: Auszug der kritischen Werte Tn;γ des Grubbs-Tests [Har+05, S.345] ..................93
€
€
€
€

Quellenverzeichnis | 96
Quellenverzeichnis
[Bou08] Christian El Boustani (2008), Bachelorarbeit: Quantitative und qualitative
Messung von Software-Anforderungen
[Coc02] Alistair Cockburn (2002), Agile software development, 4. Auflage, Addison-
Wesley
[Har+05] Joachim Hartung, Bärbel Elpelt und Karl-Heinz Klösener (2005), Statistik,
Oldenbourg
[Hen08] Melanie Hennemann (2008), Studienarbeit: Quantitativer und qualitativer
Vergleich von Anforderungen bei agilen und konventionellen
Softwareprojekten
[Kit09] Ingo Kitzmann (2009), Masterarbeit: Konzept und Implementierung eines
Werkzeugs für multimediale Anforderungserhebung- und validierung
[Kre00] Ulrich Krengel (2000), Einführung in die Wahrscheinlichkeitstheorie und
Statistik, 5. Auflage, Vieweg
[Pfla+01] Peter Pflaumer, Barbara Heine und Joachim Hartung (2001), Statistik für
Wirtschafts- und Sozialwissenschaften, Induktive Statistik, Oldenbourg
[Poh08] Klaus Pohl (2008), Requirements Engineering – Grundlagen, Prinzipien,
Techniken, dpunkt Verlag
[Rup06] Chris Rupp (2007), Requirements-Engineering und Management, 4. Auflage,
Hanser
[Roy70] Dr. Winston W. Royce (1970), Managing the Development of Large Software
Systems Proceedings of IEEE WESCON
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf,
letzter Zugriff: 02.05.2010
[Schn98] Berthold Schneider (1998), Bestimmung des Stichprobenumfangs bei
biomedizinischen Experimenten
[Schn05] Prof. Dr. Kurt Schneider (2005), Vorlesung: Softwaretechnik WS 2005/2006
[Schn07a] Prof. Dr. Kurt Schneider (2007), Abenteuer Software Qualität, dpunkt Verlag
[Schn07b] Prof. Dr. Kurt Schneider (2007), Generating Fast Feedback in Requirements
Elicitation
[Schn08] Prof. Dr. Kurt Schneider (2008), Improving Feedback on Requirements
through Heuristics
[Schn09] Prof. Dr. Kurt Schneider (2009), Vorlesung: Software-Anforderungen und
Entwurf SS 2009
[Schu+08] Martin Schumacher und Gabriele Schulgen-Kristiansen (2008), Methodik
klinischer Studien: Methodische Grundlagen der Planung, Durchführung und
Auswertung, 3. Auflage, Springer
[UniM] Uni Münster, Übungen zur medizinischen Biometrie
http://campus.unimuenster.de/fileadmin/einrichtung/imib/lehre/skripte/biomathe/bio/script7.html
, letzter Zugriff: 02.05.2010
[WikiM] Wikipedia, Median, http://de.wikipedia.org/wiki/Median, letzter Zugriff
02.05.2010
[Woh+99] Claes Wohlin, Per Runeson, Martin Höst, Anneliese von Mayrhauser, Björn
Regnell, Anders Wesslén, Magnus C. Ohlsson (1999), Experimentation in
Software Engineering: An Introduction, 1. Auflage, Springer
[Zus+04] Wolfgang Zuser, Thomas Grechenig und Monika Köhle (2004), Software
Engineering mit UML und dem Unified Process, Pearson Studium