Wie werden Spezifikationen gelesen? Eine empirische ... · presentation on paper. The goal of the...
Transcript of Wie werden Spezifikationen gelesen? Eine empirische ... · presentation on paper. The goal of the...
Gottfried Wilhelm
Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik Fachgebiet Software Engineering
Wie werden Spezifikationen gelesen?
Eine empirische Untersuchung mit Eye Tracking
Bachelorarbeit
im Studiengang Informatik
von
Maike Ahrens
Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Joel Greenyer
Betreuer: Stephan Kiesling
Hannover, 28.08.2015
iii
Erklärung der Selbstständigkeit
Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbständig und ohne fremde Hilfe verfasst und keine anderen als die in der Arbeit ange-gebenen Quellen und Hilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form noch keinem anderen Prüfungsamt vorgelegen. Hannover, den 28.08.2015 i Vorname Nachname
iv
v
Zusammenfassung
Anforderungsspezifikationen werden von vielen an der Entwicklung beteiligten Nut-
zern mit unterschiedlichen Informationsbedarfen gelesen. Das Auffinden der jeweils
relevanten Informationen bindet für sie dabei viel Arbeitszeit und Ressourcen. Um
diesen Aufwand zu reduzieren wurde im Rahmen dieser Arbeit eine Eye Tracking
Studie durchgeführt, die analysiert, für welche Rolle des Lesers welche Spezifikati-
onsabschnitte relevant und welche unwichtig sind, sowie welche der beiden
Darstellungsformen ausgedruckt oder am Bildschirm geeigneter ist. Das Ziel dabei
war es, mit Hilfe rollenabhängiger Sichten auf Anforderungsdokumente nur die für
den Nutzer wichtigen Abschnitte anzuzeigen, wodurch eine Effizienzsteigerung bei
dem Lesen von Spezifikationen erreicht werden kann. Gleichzeitig bringt dies eine
Effektivitätssteigerung für die Anforderungsingenieure beim Erstellen der Dokumente
mit sich.
Die Studie konnte signifikante Unterschiede bei der Bewertung der Spezifikationsab-
schnitte, sowie zwischen den Rollen nachweisen. Bei der Darstellungsform konnte
hingegen kein Effekt verzeichnet werden.
vi
vii
Abstract
Requirements Specifications are read by several different users involved in the
development process. Each user has different information needs which are all
addressed by the same documents. This leads to a lot of time and ressources needed
to find the relevant information in the text. To reduce this effort, an eye tracking study
was conducted to investigate which artefacts are relevant for which role of the reader.
Furthermore it was analyzed if a presentation on screen is more appropriate than the
presentation on paper. The goal of the study was to show nothing but the important
information to the user, with the help of view-based specifications depending on the
user’s role. This results in a more efficient way of reading requirements documents
and even an increased effectivity writing the specification by the requirements
engineer.
The study could show significant differences in the ratings of the specification’s
artefacts and between the different roles. Concerning the presentation medium no
effect could be proved.
viii
ix
Inhaltsverzeichnis
1 Einleitung ............................................................................................................................. 1
1.1 Motivation ..................................................................................................................... 1 1.2 Zielsetzung .................................................................................................................... 1 1.3 Struktur der Arbeit ........................................................................................................ 2
2 Grundlagen ........................................................................................................................... 2
2.1 Eye Tracking .................................................................................................................. 3 2.1.1 Allgemeines zu Eye Tracking .................................................................................. 3
2.1.2 Grundlagen der visuellen Wahrnehmung .............................................................. 3
2.1.3 Funktionsweise von Eye Trackern .......................................................................... 4
2.1.4 Möglichkeiten und Grenzen von Eye Tracking ....................................................... 4
2.1.5 Eye Tracker ............................................................................................................. 5
2.1.6 Analyse der Eye Tracking Daten ............................................................................. 6
2.2 Vorgehensweise bei der Studie ..................................................................................... 6 2.2.1 GQM-Paradigma..................................................................................................... 6
2.2.2 Testen der Hypothesen .......................................................................................... 7
2.2.3 Sicherstellen der Validität ...................................................................................... 8
3 Verwandte Arbeiten ........................................................................................................... 10
3.1 Rechercheansatz und -ergebnisse .............................................................................. 10 3.2 Ähnliche Studien über sichtenbasierte Spezifikationen ............................................. 10
3.2.1 Eye Tracking Studie .............................................................................................. 11
3.2.2 Software Engineering Projekt Studie ................................................................... 12
3.2.3 Tutorial Studie ...................................................................................................... 13
3.3 Ähnliche Studien zum Vergleich der Darstellungsform .............................................. 13
4 Planung der Studie ............................................................................................................. 15
4.1 Ziele ............................................................................................................................. 15 4.1.1 Verbesserungsziele .............................................................................................. 15
4.1.2 Erreichung der Verbesserungsziele ...................................................................... 15
4.1.3 Betrachtete Darstellungsmedien ......................................................................... 16
4.1.4 Betrachtete Rollen ............................................................................................... 16
4.1.5 Von der Betrachtung ausgeschlossene Rollen ..................................................... 17
4.1.6 Messziel ................................................................................................................ 17
4.2 Fragen.......................................................................................................................... 18 4.3 Metriken ...................................................................................................................... 19
4.3.1 Beschreibung der Zwischenmetriken ................................................................... 20
5 Vorbereitung der Studie ..................................................................................................... 21
5.1 Auswahl der Untersuchungsobjekte ........................................................................... 21 5.2 Kontextbeschreibung .................................................................................................. 22
5.2.1 Testpersonen (Stichprobe) ................................................................................... 22
5.2.2 Untersuchungsumgebung .................................................................................... 23
5.3 Datenquellen und Messmethoden ............................................................................. 23 5.3.1 Fragebögen .......................................................................................................... 23
5.3.2 Experiment in der Eye Tracking Software ............................................................ 24
5.4 Design der Studie ........................................................................................................ 24 5.4.1 Randomisierung ................................................................................................... 24
5.4.2 Blocking ................................................................................................................ 24
5.4.3 Balancing .............................................................................................................. 25
x
5.5 Zuordnung der Untersuchungssubjekte und -objekte ................................................ 25 5.6 Beschreibung des Ablaufs ........................................................................................... 26
6 Durchführung der Studie .................................................................................................... 28
6.1 Beobachtungen während der Studie .......................................................................... 28 6.2 Änderungen im Ablauf ................................................................................................ 28
7 Analyse und Interpretation ................................................................................................ 30
7.1 Verarbeitung der Rohdaten ........................................................................................ 30 7.2 Validierung der Messdaten ......................................................................................... 30 7.3 Formale Prüfung der Hypothesen auf Signifikanz ....................................................... 31
7.3.1 F1: Darstellungsform ............................................................................................ 31
7.3.2 F2: Auswahl der Abschnitte.................................................................................. 34
7.3.3 F3: Unterschiede zwischen den Rollen ................................................................ 38
8 Reflektion zu Studien mit Eye Tracking .............................................................................. 39
8.1 Vorbereitung der Aufnahmen ..................................................................................... 39 8.1.1 Eye Tracking Glasses ............................................................................................. 39
8.1.2 Externer Eye Tracker ............................................................................................ 39
8.2 Durchführung der Aufnahmen .................................................................................... 40 8.2.1 Eye Tracking Glasses ............................................................................................. 40
8.2.2 Externer Eye Tracker ............................................................................................ 40
8.3 Analyse der Daten und Auswertungsmöglichkeiten ................................................... 40 8.3.1 Eye Tracking Glasses ............................................................................................. 40
8.3.2 Externer Eye Tracker ............................................................................................ 41
8.4 Fazit zur Durchführung von Studien mit Eye Tracking ................................................ 41
9 Auswertung und Schlussfolgerung ..................................................................................... 42
9.1 Ergebnisse der Studie .................................................................................................. 42 9.1.1 Effekt der Darstellungsform ................................................................................. 42
9.1.2 Relevanz der Abschnitte ....................................................................................... 43
9.1.3 Unterschiede zwischen den Rollen ...................................................................... 44
9.2 Vergleich mit einschlägigen Studien ........................................................................... 45 9.2.1 Effekt der Darstellungsform ................................................................................. 45
9.2.2 Relevanz der Abschnitte ....................................................................................... 45
9.3 Schlussfolgerung ......................................................................................................... 46
10 Einschränkungen der Validität ......................................................................................... 48
10.1 Validität der Schlussfolgerung ................................................................................... 48 10.2 Interne Validität ........................................................................................................ 48 10.3 Validität der Konstruktion ......................................................................................... 49 10.4 Externe Validität ........................................................................................................ 49
11 Abschließende Betrachtung ............................................................................................. 50
11.1 Zusammenfassung ..................................................................................................... 50 11.2 Ausblick ..................................................................................................................... 50
Literaturverzeichnis ............................................................................................................... 51
A. Anhang .............................................................................................................................. 53
A.1 Einführungen für die Teilnehmer ................................................................................ 54 A.2 Fragebögen ................................................................................................................. 58 A.3 Ergebnisdaten der Studie ............................................................................................ 68
1
1 Einleitung
1.1 Motivation
Spezifikationen spielen eine große Rolle im Softwareentwicklungsprozess, da sie die
Basis und Zielvorgabe bilden, auf dessen Grundlage weitergearbeitet wird. Nur was
klar und ausreichend beschrieben ist, kann auch richtig entwickelt werden (Ebert12).
Eine solche Beschreibung kann schnell sehr umfangreich werden und so ausführlich,
dass relevante Aspekte unter Umständen aus dem Blickfeld geraten (Gross12a). Das
Verfassen und Lesen dieser teils sehr langen Dokumente bindet daher viel Arbeits-
zeit und Ressourcen.
Hinzu kommt die Problematik, dass die Spezifikation aufgrund ihrer zentralen Rolle
eine wichtige Informations- und Kommunikationsquelle für sehr viele an der Entwick-
lung beteiligte Personen mit jeweils unterschiedlichem Informationsbedarf darstellt
(Gross12b). Für einen Usability Experten sind Benutzerbeschreibungen und Anwen-
dungsgebiete beispielsweise besonders relevant. Angaben zum Altsystem hingegen
sind weniger von Interesse. Andere Rollen, wie Projektleiter oder Kunden haben wie-
derum andere Anforderungen an die Spezifikation (Brau11).
Daraus ergibt sich für jeden die Schwierigkeit in der großen Menge an Artefakten,
die eine Spezifikation umfasst, die für die jeweilige Rolle relevanten Informationen
herauszufiltern. Aufgrund der Arbeit, die eine solche Informationssuche mit sich
bringt, besteht die Gefahr, dass die Spezifikationsdokumente dadurch in den Hinter-
grund rücken und somit wichtige ermittelte Systemanforderungen vernachlässigt
werden (Gross12a).
Da das Verfassen und Lesen von Spezifikationen sehr viel Zeit erfordert, wäre es
dementsprechend wünschenswert, wenn man diesen Aufwand möglichst reduzieren
und dessen Nutzen optimieren könnte.
1.2 Zielsetzung
Ziel dieser Arbeit ist es, den Schreib- und Leseprozess von Spezifikationen effizienter
und effektiver zu gestalten, wobei zwei Ansätze verfolgt werden. Zum einen werden
Tipps für eine sichtenbasierte Spezifikation entwickelt, die es möglich machen, ab-
hängig von der Rolle des Lesers das Dokument anzupassen, indem irrelevante
Abschnitte ausgeblendet und wichtige dagegen in den Vordergrund gesetzt werden.
Dazu ist es zunächst einmal nötig, herauszufinden, um welche Abschnitte es sich im
Einzelnen handelt, das heißt, welche Rolle welchen Informationsbedarf hat und wel-
che Darstellung bevorzugt wird. Dies erfolgt im Rahmen einer Eye Tracking Studie,
in der der Leseprozess verschiedener Benutzer mit unterschiedlichen Spezifikatio-
nen untersucht wird, wobei sich bei den Rollen der Leser auf die des UI-Designers,
des Softwarearchitekten, des Testers und des Entwicklers beschränkt wird. Das Au-
genmerk liegt dabei weniger auf dem konkreten Inhalt einzelner Abschnitte, sondern
vielmehr auf deren Reihenfolge und Relevanz für den Leser.
Darüber hinaus wird das Lesen von Spezifikationen auf dem Papier und am Bild-
schirm verglichen mit dem Ziel, herauszufinden, welche der beiden
Darstellungsformen geeigneter ist. Hierfür werden die Spezifikationsdokumente der
Studie den Teilnehmern entweder ausgedruckt oder in Papierform ausgehändigt.
1 Einleitung
2
1.3 Struktur der Arbeit
Zu Beginn der Arbeit werden zunächst notwendige Konzepte und Begrifflichkeiten im
Grundlagenteil erklärt. Anschließend folgt eine Beschreibung der Erkenntnisse, die
bisherige Arbeiten zu dem behandelten Thema bereits erlangen konnten. Auf dessen
Basis wurden die Ziele der durchgeführten Studie, sowie dessen Aufbau, untersuchte
Fragestellungen und betrachtete Metriken definiert. Im Anschluss daran ist die ge-
samte Umgebung der Studie beschrieben. Diese umfasst Aspekte wie die
verwendeten Untersuchungsobjekte und Messmethoden. Daraufhin ist der Ablauf
der Studie detailliert aufgeführt und es werden die resultierenden Daten analysiert,
interpretiert und die Ergebnisse auf statistische Aussagekraft überprüft. Schlussend-
lich werden die Resultate auf die Erreichung der Zielsetzung der Arbeit hin bewertet,
ihre Validität diskutiert und mögliche Schlussfolgerungen gezogen. Die erlangten Er-
kenntnisse werden zuletzt noch zusammengefasst und ein Ausblick über weitere
Möglichkeiten gegeben
3
2 Grundlagen
2.1 Eye Tracking
Die Studie, die im Rahmen dieser Arbeit durchgeführt wurde, nutzt die Methode des
Eye Tracking. Ein Überblick darüber, worum es sich dabei genau handelt und wel-
chen Nutzen man daraus ziehen kann, gibt dieses Kapitel.
2.1.1 Allgemeines zu Eye Tracking
Eye Tracking ist eine Methode zur Aufzeichnung von Blickbewegungen. Die Geräte,
die diese Aufzeichnung vornehmen, werden entsprechend Eye Tracker genannt. Mit
deren Hilfe ist es möglich zu detektieren, wo die Versuchsperson zu einem bestimm-
ten Zeitpunkt hinschaut, wie lange sie dort hinsieht und welchem Blickpfad die Augen
folgen. Damit hilft Eye Tracking Forschern dabei visuelle Aufmerksamkeit zu verste-
hen und einen Nutzen aus diesem Wissen zu ziehen (Schall14).
2.1.2 Grundlagen der visuellen Wahrnehmung
Um die Funktionsweise von Eye Trackern zu verstehen, ist es zunächst einmal nötig,
ein paar Grundlagen darüber zu kennen, wie Menschen visuelle Informationen auf-
nehmen. Dazu sind die beiden Grundbegriffe Fixationen und Sakkaden von
Relevanz. Bei Fixationen handelt es sich um eine Pause der Blickbewegung. Das
heißt, zu diesem Zeitpunkt verweilt das Auge auf einem bestimmten Bereich des
Blickfelds. Währenddessen kann das Auge visuelle Informationen aufnehmen. Sak-
kaden hingegen sind die Blicksprünge von einer Fixation zur nächsten (Schall14).
Während dieser Phase werden nur bereits wahrgenommene visuelle Informationen
verarbeitet, jedoch keine neuen aufgenommen (Schmidts07).
Mithilfe von Fixationen und Sakkaden ist es dem Gehirn möglich ein komplettes Bild
der wahrgenommenen Szene zusammenzusetzen. Die einzelnen Fixationen haben
typischerweise eine Dauer von 100 bis 600 Millisekunden und finden im fovealen
Blickfeld statt. Das ist der Bereich, in dem das Auge scharf und detailliert sieht. Die
dort aufgenommen visuellen Reize bilden jedoch nur knapp die Hälfte der insgesamt
wahrgenommenen visuellen Informationen. Der Rest befindet sich im parafovealen
und peripheren Bereich. Diese befinden sich um das fokussierte foveale Blickfeld
herum. Dort befindliche Objekte können nur grob wahrgenommen werden und man
erhält nur einen Eindruck ihrer generellen Form und Farbe. Meist ziehen sie nur in
Bewegung die Aufmerksamkeit auf sich.
Das Gehirn ist jedoch sehr gut in der Lage aus diesen grob aufgelösten Wahrneh-
mungen, die genaue Beschaffenheit der einzelnen Objekte zu erahnen und somit ein
scheinbar komplettes Bild eines Geschehens zu erzeugen (Schall14). Aus diesem
Grund ist es Menschen unter anderem möglich den Inhalt eines Textes zu erfassen,
ohne beim Lesen jeden oder jeden zweiten Buchstaben fokussieren zu müssen, da
aus der groben Form eines Wortes, sowie einzelnen Buchstaben bereits das Ge-
samtwort „erraten“ werden kann. Abbildung 2.2 stellt dar, wie ein solcher
Leseprozess aussehen kann. Die einzelnen Kreise repräsentieren Fixationen. Ihre
Größe ist dabei abhängig von der Dauer der Fixation. Je länger sie angedauert hat,
desto ist der jeweilige Kreis. Die Verbindungslinien zwischen den Kreisen stehen für
die Sakkaden, die den Blicksprung von einer Fixation zur nächsten darstellen.
2 Grundlagen
4
Abbildung 2.1: Beispieltext mit Fixationen und Sakkaden (Wiki15)
2.1.3 Funktionsweise von Eye Trackern
Während frühere Eye Tracker noch den gesamten Kopf und teilweise sogar die Au-
genlider fixieren mussten, sind die heutigen Geräte deutlich komfortabler für die
Versuchsperson. Der Großteil der neuen Eye Tracker nutzt die Methode der Horn-
hautreflexion, um die Position der Pupille während der Bewegung erkennen und
verfolgen zu können. Diese Methode umfasst eine Lichtquelle mit Infrarotlicht, die auf
das Auge gerichtet wird und dessen Reflexion auf der Hornhaut von einer hochauf-
lösenden Kamera aufgenommen wird (Schall14). Da am Ort der Pupille kein Licht
reflektiert wird, kann anschließend mittels spezieller Bildverarbeitungsalgorithmen
die Pupillenposition bestimmt werden (Schall14, Schmidts07). Um diese Position auf
das gesehene Bild der Versuchsperson abzubilden, wird anschließend noch eine Ka-
librierung benötigt. Bei dieser wird die Versuchsperson dazu aufgefordert einen
bestimmte Punkt oder mehrere Punkte hintereinander zu betrachten. Diese Informa-
tion nutzt dann der Eye Tracker, um den Zusammenhang zwischen Blickpunkten und
Aufnahmebild herzustellen.
2.1.4 Möglichkeiten und Grenzen von Eye Tracking
Untersuchungen mit Eye Tracking geben Aufschluss darüber, wo eine Person zu ei-
nem bestimmten Zeitpunkt hinsieht und bieten so die Möglichkeit das Blickverhalten
von Menschen genauestens zu analysieren. Damit lässt sich untersuchen, wo das
Zentrum der Aufmerksamkeit während bestimmter Ereignisse liegt. Des Weiteren
kann über die Dauer von Fixationen ausgesagt werden, wie lange ein bestimmter
Bereich fokussiert wurde. Die Auswertungsmöglichkeiten gehen sogar so weit, dass
man einen Anhaltspunkt darüber geben kann, ob eine Person nervös oder aufgeregt
ist, da dann das Blickverhalten sprunghafter und die Fixationen kürzer werden
(Schmidts07).
Entsprechend große Anwendung finden Eye Tracking Studien in Marktforschungs-
analysen, um die Wirksamkeit von Werbekampagnen zu testen. Ebenfalls ein großes
Anwendungsgebiet sind Studien über Benutzeroberflächen. Mittels Eye Tracking
kann ausgesagt werden, welche Elemente zu welchem Zeitpunkt, wie lange und in
welcher Reihenfolge dem Nutzer ins Auge springen. Damit lässt sich herausfinden,
wie anwenderfreundlich und bedienbar beispielsweise eine Webseite ist. Weitere An-
wendungsgebiete sind die Medizin oder auch immer mehr die Mensch-Computer-
2 Grundlagen
5
Interaktion, wo Eye Tracking zur Steuerung von Computern eingesetzt wird
(Schall14).
Jedoch ist bei der Auswertung der Eye Tracking Daten Vorsicht geboten, damit keine
falschen Schlüsse gezogen werden. Wie in Kapitel 2.1.1 bereits beschrieben, nimmt
der Mensch auch sehr viele Information über den peripheren Sehbereich auf. Wenn
bei einer Usability-Studie beispielsweise ein Webseitenelement nicht über eine Fixa-
tion direkt betrachtet wurde, heißt das nicht zwangsläufig, dass der Nutzer es nicht
wahrgenommen hat. Andersherum bedeutet eine Fixation auf einem Objekt nicht ge-
zwungenermaßen, dass die Person die visuellen Informationen auch wirklich
aufgenommen und verarbeitet hat. Dies ist insbesondere dann der Fall, wenn kogni-
tiv anspruchsvolle Aufgaben untersucht werden. Der Eye Tracker kann zudem nur
Aussagen über den Verlauf des Blickverhaltens machen, nicht jedoch über die
Gründe dafür, wie z.B. warum ein Nutzer einen Text besonders intensiv liest oder ein
Bild sehr lange betrachtet. Dafür sollten weitere Untersuchungsmethoden, wie Fra-
gebögen oder lautes Denken hinzugezogen werden (Schall14).
2.1.5 Eye Tracker
Eye Tracker werden in die beiden Kategorien externe und mobile Systeme unterteilt.
Externe Eye Tracker sind dabei die Geräte, die nicht an der Versuchsperson, son-
dern am Bildschirm befestigt werden oder sogar in ihn integriert sind. Diese zeichnen
dann parallel zu den Blickbewegungen das Bild des Monitors auf. Dabei kann es sich
beispielsweise um Bilder, Videos, Textdokumente oder Webseiten handeln. Das Ge-
rät, dass in der Studie dieser Arbeit verwendet wird, stammt von dem Unternehmen
SensoMotoric Instruments (SMI) und es handelt sich dabei um das Modell Red-m.
Es wird auf der Abbildung 2.4 gezeigt und lässt sich entweder an einen Monitor an-
bringen oder auf einen Laptop stellen (SMI15).
Abbildung 2.2: externer Eye Tracker Red-m von SMI (SMI15)
Im Gegensatz zu externen Eye Trackern werden mobile Systeme von der Versuchs-
person getragen. Ein Beispiel für ein solches auch head-mounted Eye Tracker
genanntes Gerät sind die Eye Tracking Glasses 1 Wireless von SensoMotoric Instru-
ments, die in der Studie dieser Arbeit verwendet wurden. Diese Brille wird auf
Abbildung 2.5 gezeigt. Sie kann entweder an eine mitgelieferte Aufnahmeeinheit (Re-
cording Unit), die aus einem Smartphone und einem zusätzlichen Akku für die Eye
Tracking Glasses besteht, angeschlossen werden oder direkt an einen Laptop
(SMI15).
2 Grundlagen
6
Abbildung 2.3: Eye Tracking Glasses 1 Wireless von SMI (SMI15)
2.1.6 Analyse der Eye Tracking Daten
Zu jedem Eye Tracker gehört eine passende Analysesoftware, die die Quantifizie-
rung, sowie Visualisierung der Daten ermöglicht. Dazu werden verschiedene
Möglichkeiten, wie beispielsweise der Gaze Plot, der auch in Abbildung 2.1 zu sehen
ist oder Heat Maps, in denen die Dauer der Fixationen in einem bestimmten Bereich
durch Verläufe von warmen zu kalten Farben dargestellt wird (Schall14). Eine Option,
um konkrete Blickwerte in Form von Zeiten in Millisekunden zu erhalten, ist darüber
hinaus das Definieren sogenannter „Areas of Interest“ (AOIs). Diese können entwe-
der in geometrischen oder handgezeichneten Formen auf Screenshots des
Kamerabildes des Eye Trackers gezogen werden oder auf selbst erstellte Referenz-
bilder. Anschließend berechnet die Analysesoftware Werte wie die durchschnittliche
Dauer einer Fixation auf diesem Bereich, die Blickdauer insgesamt oder die Anzahl
an Sakkaden (Schall14).
2.2 Vorgehensweise bei der Studie
2.2.1 GQM-Paradigma
Die im Rahmen der Arbeit durchgeführte Studie wurde nach dem GQM-Paradigma
geplant. GQM steht dabei für Goal, Question, Metric und beschreibt eine systemati-
sche Vorgehensweise zur Erstellung von Qualitätsmodellen. Dieser Ansatz gibt vor,
dass zu Beginn der Arbeit zunächst Ziele definiert werden, die mit der Studie erreicht
werden sollen. Diese lassen sich in die beiden Kategorien „Verbesserungsziel“ und
„Messziel“ unterteilen. Verbesserungsziele (Goals) beschreiben, welchen Prozess
oder Sachverhalt die Ergebnisse verbessern sollen, also welches übergeordnete Ziel
die Studie hat. Die Messziele hingegen verfeinern dieses Ziel, indem sie das konkrete
Objekt der Messung vorgeben. Dieses kann beispielsweise ein bestimmter Prozess
oder ein Produkt sein. Anschließend werden auf Basis des Messziels Fragen (Ques-
tions) aufgestellt, die das Messziel näher spezifizieren und angeben welche
Fragestellungen von den Messungen untersucht werden. Zu jeder Frage werden an-
schließend eine oder mehrere Metriken (Metrics) definiert, welche die Beantwortung
der Fragen ermöglichen, sowie Hypothesen über die erwartete Antwort festgelegt
(Solingen99). Abbildung 2.1 beschreibt das Vorgehen des GQM-Ansatzes noch ein-
mal anschaulich. Dort lässt sich auch der entsprechende Ablauf bei der Auswertung
entnehmen. Im Anschluss an die Definition der Ziele, Fragen und Metriken folgt dem-
nach die Datenerfassung, dessen Messdaten mit den Metriken validiert werden, um
sicherzustellen, dass die gewünschten Daten auf die richtige Weise erhoben wurden.
Ist dieser Schritt erfolgt, können die Messaufzeichnungen in Bezug auf die zuvor de-
finierten Hypothesen, Fragen und Messzielen analysiert werden. Daraufhin können
2 Grundlagen
7
die erlangten Erkenntnisse zu der ursprünglich angestrebten Verbesserung führen
(Freimut02).
Abbildung 2.4: Übersicht zum Vorgehen mit GQM (Freimut02)
2.2.2 Testen der Hypothesen
Vor der Durchführung der Studie werden zunächst die erwarteten Ergebnisse in Form
von Hypothesen festgehalten. Diese können auf vorherigen Untersuchungen oder
logischen Überlegungen beruhen. Die meisten Hypothesen lassen sich jedoch nur
indirekt prüfen, da meist schon ein Gegenbeispiel genügt, um sie zu widerlegen. Da-
her wird häufig zum Beweisen einer Hypothese die Gegenhypothese, auch
Nullhypothese H0 formuliert und diese geprüft. Wenn man beispielsweise zeigen
möchte, dass der Mittelwert 𝜇1 einer gemessenen Variable größer ist als ein anderer
Mittelwert 𝜇2, wäre die entsprechende Nullhypothese 𝜇1 ≤ 𝜇2. Das hat den Vorteil,
dass wenn die Gegenhypothese abgelehnt werden kann, automatisch die ursprüng-
liche Hypothese, auch Arbeitshypothese HA genannt, als wahr belegt wird.
Hypothesen können entweder einseitig oder zweiseitig aufgestellt werden (Sachs93).
Ein Beispiel für eine einseitige Fragestellung ist wie oben 𝜇1 > 𝜇2, wobei das Inter-
vall für den jeweiligen Mittelwert nur zu einer Seite offen ist. Bei zweiseitigen
Fragestellen, wie z.B. 𝜇1 ≠ 𝜇2, müssen die Mittelwerte nur unterschiedlich sein. Die
Art des Unterschieds ist dabei nicht vorgegeben. Der zweite Mittelwert kann entwe-
der größer oder kleiner sein, wodurch das Intervall zu zwei Seiten offen ist (Sachs93).
Zur Prüfung von Hypothesen werden statistische Tests verwendet, die einen gemes-
senen Trend, wie den Unterschied zweier Mittelwerte auf Signifikanz testen. Ein
statistisch signifikantes Ergebnis ist dabei ein Ergebnis, bei dem die Wahrscheinlich-
keit, dass der betrachtete Effekt zufällig auftritt, sehr gering ist. Diese
Wahrscheinlichkeit für ein zufälliges Auftreten, also ein irrtümliches Ablehnen der
Nullhypothese, wird mit 𝛼 bezeichnet und auch Fehler 1. Art genannt. Dem gegen-
über steht der Fehler 2. Art mit der Wahrscheinlichkeit 𝛽, dass die Nullhypothese
nicht abgelehnt wird, obwohl sie falsch ist. Anders gesagt ist 𝛽 die Wahrscheinlich-
keit, dass ein vorhandener Effekt nicht erkannt wird (Sachs93). Dabei gilt: je kleiner
𝛼, desto größer ist 𝛽. Je nachdem wie gravierend ein entsprechender Irrtum ist, dass
die Nullhypothese fälschlicherweise abgelehnt oder beibehalten wird, werden die je-
weiligen 𝛼- und 𝛽-Werte gewählt. Bei der Untersuchung, ob ein neues Medikament
die gleiche Wirkung zeigt wie das auf dem Markt bestehende, würde beispielsweise
2 Grundlagen
8
𝛼 besonders klein und 𝛽 dafür größer wählen, da eine irrtümliche Annahme über die
gleiche Wirkung also ein Ablehnen der Nullhypothese verheerende Folgen hätte. Üb-
licherweise wird für 𝛼 der Wert 0,05 gewählt. Das heißt, dass die Wahrscheinlichkeit
eines Irrtums bei Ablehnen der Nullhypothese 5% beträgt. In diesem Fall wird auch
von 5%-Signifikanzniveau gesprochen (Sachs93).
2.2.3 Sicherstellen der Validität
Das Durchführen einer Studie ist nur dann sinnvoll, wenn die Resultate auch an-
wendbar sind. Das heißt, wenn die Studie in sich valide und die dort untersuchten
Sachverhalte auf die gewünschte Umgebung übertragen werden können. Dazu prüft
man, ob die Untersuchungen durch sogenannte Einschränkungen der Validität ge-
fährdet werden. Um die verschiedenen Arten von Validität zu verstehen, ist zunächst
ein gewisses Verständnis für das Durchführen von Studien erforderlich. Eine Über-
sicht darüber gibt Abbildung 2.4. Studien können entweder off-line in einer definierten
Untersuchungsumgebung stattfinden oder on-line, beispielsweise in einem echten
Projekt innerhalb eines Unternehmens (Wohlin00). In beiden Fällen liegt den Be-
obachtungen eine gewisse Theorie zugrunde. Die Studie wird durchgeführt, um eine
bestimmte Ursache-Wirkung-Korrelation zu erforschen. Die Ursache wird dabei
durch bestimmte, in der Studie fest gesetzte Faktoren abgebildet. Der Effekt dieser
Faktoren wird anschließend im Ergebnis gemessen. Diese Eingabe-Ergebnis-Korre-
lation im Experiment entspricht dann der Ursache-Wirkung-Korrelation (Wohlin00).
Die verschiedenen Arten von Validität zielen auf verschiedene Zusammenhänge in
diesem Konstrukt ab. Wie gut die Abbildung der beiden Korrelationen ist beurteilt
dabei die Validität der Konstruktion. Das heißt, dabei stellt man sich die Frage, wie
gut die betrachteten Faktoren die zu untersuchende Wirkung und das gemessene
Ergebnis die entsprechende Wirkung darstellen. Einen negativen Einfluss auf diese
Art der Validität kann es zum Beispiel geben, wenn man in einer Studie die gemach-
ten Fehler in Programmcode untersucht und die Teilnehmer sich dessen bewusst
sind. In dem Fall würden sie besonders darauf Acht geben und somit versuchen die
Fehlerzahl zu reduzieren (Wohlin00).
Bezüglich des Feststellens einer Korrelation zwischen Eingabe und Ergebnis gibt es
zwei verschiedene Validitäten, die sich damit auseinander setzen. Zum einen ist das
die interne Validität, die sich damit beschäftigt, ob die beobachteten Faktoren über-
haupt die Ursache für den gemessenen Effekt sind und nicht ein anderer, nicht
berücksichtigter Faktor diesen bewirkt hat. Ein Beispiel für eine beeinträchtigte in-
terne Validität ist, wenn die Teilnehmer während der Studie durch äußere nicht
betrachtete Einflüsse abgelenkt werden und diese die Ergebnisse beeinflussen, man
jedoch fälschlicherweise annimmt, dass die festgelegten Faktoren der Studie diese
verursacht haben. Die zweite Validität, die sich mit der Beziehung zwischen Eingabe
und Ergebnis beschäftigt ist die Validität der Schlussfolgerung, auch statistische Va-
lidität genannt. Diese umfasst Faktoren, die beispielsweise durch den gewählten
Signifikanztest oder eine zu geringe Stichprobengröße entstehen können. Der beo-
bachtete Effekt könnte beispielsweise irrtümlich gefunden worden sein, wenn die
Voraussetzungen für den verwendeten Test nicht gegeben sind (Wohlin00).
Die letzte Kategorie der Validität ist die externe Validität. Diese thematisiert die Ver-
allgemeinerungsmöglichkeiten der Studienergebnisse auf andere Sachverhalte und
wird durch die Wahl der Untersuchungsobjekte, -subjekte und der Umgebung beein-
flusst. Erkenntnisse lassen sich beispielsweise schlecht generalisieren, wenn eine
sehr spezielle Gruppe an Teilnehmern gewählt wurde, die nicht repräsentativ für die
betrachtete Grundgesamtheit sind (Wohlin00). Ein Beispiel hierfür wäre, wenn man
2 Grundlagen
9
das Durchschnittsalter von Studenten bestimmen möchte und dafür Studenten in ei-
ner Erstsemesterveranstaltung befragt.
Einer schlechten Validität der Ergebnisse entgegen wirken die drei Experimentprin-
zipien Randomisierung, Blocking und Balancing. Die Randomisierung, also das
zufällige Wählen von Probanden, Reihenfolgen und weiteren Faktoren, die ebenfalls
einen Einfluss auf die Beobachtungen haben können, wirkt dabei einer schlechten
internen Validität entgegen. Das Blockingverfahren kann angewendet werden, wenn
nicht gewünschte Einflussfaktoren bekannt sind, z.B. wenn die Teilnehmer einen un-
terschiedlichen Erfahrungsstand haben. In dem Fall werden die Probanden dann in
zwei von der Erfahrung abhängige Gruppen aufgeteilt und anschließend wird der Ef-
fekt der untersuchten Faktoren nur innerhalb dieser Gruppen analysiert und
verglichen. Somit hat der ungewünschte Faktor jeweils den gleichen Wert und keinen
Einfluss auf die Erkenntnisse innerhalb der Gruppen. Das letzte Prinzip der Ausge-
glichenheit bzw. Balancing gibt vor, dass Vergleiche jeweils auf gleich großen
Stichprobengrößen und Anzahlen an Untersuchungsobjekten stattfinden sollten, um
eine möglichst gute statistische Testbarkeit und somit eine gute Validität der Schluss-
folgerung zu erhalten (Wohlin00).
Abbildung 2.5: Experimentprinzipien (aus (Wohlin00) ins Deutsche übertragen)
10
3 Verwandte Arbeiten
3.1 Rechercheansatz und -ergebnisse
Zu Beginn der Arbeit wurde zunächst nach bestehendem Material recherchiert. Dazu
wurde vor allem Google Scholar verwendet. Zu jeder Suchanfrage wurden die ersten
zwei bis drei Ergebnisseiten durchgesehen, je nachdem wie vielversprechend der
sich ergebende Eindruck war.
Anfangs wurde nach Quellen gesucht, die ebenfalls den Ansatz von rollenabhängi-
gen Spezifikationen behandelten. Jedoch führten erste einfache Suchanfragen,
bestehend aus Wörtern wie „Anforderungsmanagement“, „Spezifikationen“, „Soft-
ware Engineering“, „Probleme“ und „Problemansatz“, „Lesbarkeit“, „Risiken“,
„Verbesserung“ und „Verbesserungsansatz“, „Kriterien“ oder „Studie“ zu keinen Er-
gebnissen, die in die Richtung des Ziels der geplanten Studie gingen.
Es wurden viele Verbesserungsansätze für Spezifikationen gefunden. Einige dieser
betrafen dabei den Aufbau des Dokuments, wie verschiedene Standards, beispiels-
weise von dem Institute of Electrical and Electronics Engineers (IEEE) (IEEE98a,
IEEE98b) oder Templates und Frameworks, wie z.B. das Volere Template
(Robertson06) oder das TORE-Framework (Task-oriented Requirements Enginee-
ring) (Adam09). Diese sind jedoch meist sehr allgemein formuliert und adressierten
keine rollenspezifischen Bedürfnisse. Andere beinhalteten jedoch bereits die Idee
von Perspektiven auf Anforderungsdokumente, wie das perspective-based reading.
Dabei handelt es sich um eine Methode zur Inspektion von Spezifikationen zum effi-
zienten und möglichst vollständigem Auffinden von Fehlern in
Anforderungsspezifikationen (Wohlin00). Sie repräsentieren somit einen Ansatz, der
auf bereits erstellten Dokumenten aufbaut und nicht den Prozess des Erstellens und
Nutzens betrifft, wie es sichtenbasierte Spezifikationen tun (Gross12b).
Schließlich wurden mithilfe der Google Suchanfrage „Spezifikation abhängig vom Le-
ser“ bereits im ersten Ergebnis die Studien des Fraunhofer Instituts für
Experimentelles Software Engineering (IESE) entdeckt, die genau den Ansatz der
sichtenbasierten Anforderungsspezifikation behandeln (Gross12a). Diese sind im
nächsten Teilkapitel (3.2) noch näher beschrieben. Über diesen Beitrag wurden an-
schließend zwei Verfahren zum Auffinden weiterer einschlägiger Quellen verwendet.
Zum einen wurde nach den in passender Literatur aufgeführten Schlüsselwörtern,
wie beispielsweise „view-based requirements specification“ oder „perspective-based
requirements specification“ gesucht, um ähnliche Paper oder Bücher zu finden. Zum
anderen wurden nach dem Schneeballprinzip die Literaturangaben geeigneter Su-
chergebnisse auf verwendbare Informationen durchgesehen. Hat man hierbei einen
passenden Treffer gefunden, wurden wiederum dessen Quellen betrachtet und so
weiter. Es wurde jedoch über die Studien des IESE hinaus keine weitere Literatur
gefunden, die sich explizit mit der Entwicklung sichtenbasierter Spezifikationen und
der dazu erforderlichen empirischen Datenerhebung befasst.
3.2 Ähnliche Studien über sichtenbasierte Spezifikationen
Die Planung und der Aufbau der in dieser Arbeit durchgeführten Studie baut auf drei
Studien auf, die das bereits erwähnte Fraunhofer Institut für Experimentelles Soft-
ware Engineering (IESE) im Rahmen eines Dissertationsverfahrens durchgeführt
hat. Sie haben damit den gleichen Ansatz der „sichtenbasierten Anforderungsspezi-
fikation“ erforscht. Die Zielsetzung ihrer Arbeit war es, ebenfalls mithilfe empirischer
3 Verwandte Arbeiten
11
Studien und Literaturrecherchen fundiertes Wissen über die individuellen Informati-
onsbedürfnisse der Rollen zu erhalten, die Spezifikationen nutzen. Dieses Wissen
sollte anschließend dazu verwendet werden, Sichten auf Anforderungsspezifikatio-
nen zu generieren, welche die jeweiligen Ansprüche an das Dokument erfüllen
(Gross12a). Auf Basis dieser Zielsetzung haben sie sich die folgenden in Tabelle 3.1
aufgeführten zwei Forschungsziele mit dazugehörigen Fragen überlegt, dessen Be-
antwortung Daten für die Entwicklung von rollenabhängigen Sichten auf
Spezifikationsdokumente liefern sollen. Die drei durchgeführten Studien untersuchen
jeweils nur FZ1 (Gross12b).
Forschungsziel FZ1: Untersuchung der Informationsbedarfe von Entwickler-rollen bezüglich der Nutzung von Softwareanforderungs- spezifikationen (SAS)
Frage F1_1: Was sind typische Artefakttypen, die in SAS aus Sicht von Entwicklerrollen zur Bearbeitung ihrer Aufgaben enthalten sein sollten?
Frage F1_2: Wie detailliert sollten Artefakte eines bestimmten Typs spezifiziert werden?
Frage F1_3: Welche Notation sollte zur Spezifikation bestimmter Artefakttypen genutzt werden?
Forschungsziel FZ2: Untersuchen, ob es Unterschiede zwischen den Informa- tionsbedarfen aus Sicht unterschiedlicher Entwicklerrol-len gibt
Frage F2_1: Gibt es einen Unterschied zwischen den Informations- bedarfen verschiedener Rollen?
Frage F2_2: Gibt es sogar einen Unterschied zwischen Personen mit der gleichen Rolle?
Frage F2_3: Was sind Faktoren, die den Informationsbedarf von Entwicklungsingenieuren der gleichen Rolle beeinflus-sen?
Tabelle 3.1: Forschungsfragen des Fraunhofer IESE (übersetzt aus (Gross12b))
3.2.1 Eye Tracking Studie
Die erste Studie des IESE bezog sich auf die Fragestellungen F1_1 und F1_3. An ihr
nahmen zwei Architekturexperten und zwei Usabilityexperten teil. Ihre Aufgabe war
es eine in einem echten Softwareprojekt mithilfe des TORE Frameworks (Adam09)
erstellte Anforderungsspezifikation zu sichten und durch „lautes Denken“ die Rele-
vanz der enthaltenen Informationen für die Erstellung einer Architektur bzw. eines UI
Designs zu bewerten (Gross12a). Die verwendete Spezifikation umfasste 133 Seiten
mit Domänenanforderungen, 140 Seiten Systemanforderungen und weitere 82 Sei-
ten Anhang mit Zusatzmaterial und war daher in drei Dokumente aufgeteilt
(Gross12b).
Mithilfe eines mobilen Eye Trackers wurden das Blickverhalten der Versuchsteilneh-
mer aufgezeichnet, sodass beobachtet werden konnte, welche Stellen im Dokument
besondere Aufmerksamkeit erlangten. Zusätzlich wurde der Ablauf mit einer exter-
nen Kamera gefilmt und es waren jeweils ein bis drei Beobachter anwesend, die den
Umgang mit der Spezifikation protokollierten. Neben dem „lauten Denken“ zur Be-
stimmung der Relevanz der insgesamt 35 Artefakte wurde ein Fragebogen im
Nachgang an die Dokumentanalyse verwendet, indem die einzelnen Artefakttypen
mit einer Gewichtung von „Sehr wichtig“ bis „Unwichtig“ bewertet (Brau11) und zu-
sätzlich Kommentare abgegeben werden sollten, warum einzelne Teile als relevant
3 Verwandte Arbeiten
12
erachtet werden, ob eventuell Informationen fehlen und ob die gewählten Notationen
nützlich sind (Gross12b). Ein Bild der Studie zeigt die Abbildung 3.1.
Abbildung 3.1: Eye Tracking Studie des Fraunhofer IESE (Gross12c)
Als Ergebnis konnte festgestellt werden, dass aus Sicht des Architekten alle Artefakt-
typen wichtig oder sehr wichtig sind. Aus Sicht des UI-Designers sind dagegen nicht
alle Artefakte relevant. Demzufolge stechen besonders Stakeholder, Prozess- und
Interaktionsbeschreibungen als sehr wichtig hervor (Gross12a).
Als Fazit der Studie konnte festgehalten werden, dass zwar einige Schlüsse auf die
Informationsbedarfe der beiden Rollen Architekt und UI-Designer gezogen werden
konnten, die Stichprobe jedoch zu klein ist, um valide Ergebnisse zu erhalten und
daher weitere Studien notwendig sind. Zudem wurde ebenfalls in Bezug auf zukünf-
tige Studien der Hinweis gegeben, dass eine weitere Schwäche der Studie darin lag,
dass sich die Probanden die Situation der Analyse der Spezifikation vorstellen muss-
ten. Daher wird empfohlen den Teilnehmern tatsächlich den Auftrag zu geben,
beispielsweise eine Architektur zu designen. Des Weiteren hat man bei der Auswer-
tung der Daten festgestellt, dass die Informationen, die man aus dem „lauten
Denken“ ziehen konnte, die Methode des Eye Tracking praktisch überflüssig ge-
macht haben, da sie eine ähnliche Präzision boten (Gross12b).
3.2.2 Software Engineering Projekt Studie
Die zweite Studie untersuchte ebenfalls die Frage F1_1 in Bezug auf die Rolle Archi-
tekt. Sie fand im Rahmen eines Softwareentwicklungsprojektes an der Universität
Kaiserslautern statt. Dort hatten 13 Studenten in Teams von vier bis fünf Personen
die Aufgabe den kompletten Entwicklungsprozess über Anforderungserhebung, Er-
stellen der Spezifikation bis hin zur Fertigstellung des Softwareprodukts für ein
Accountmanagementsystem zu durchlaufen (Gross12b). Bei den Teilnehmern han-
delte es sich um neun Bachelor Informatikstudenten und vier Diplom
Wirtschaftsingenieure mit Spezialisierung auf Informatik. Jeder von ihnen hatte be-
reits zuvor einen Kurs zur Vorstellung von wesentlichen Software Engineering
Methoden besucht, in der auch das TORE-Framework (Adam09), mit dem die Spe-
zifikation erstellt wurde, vorgestellt wurde (Gross12b).
Im Anschluss an das dreimonatige Projekt bewerteten die Studenten die in der An-
forderungsspezifikation dokumentierten Informationen in einem Fragebogen mit
einer Relevanz. Die Skala stimmte dabei mit der aus der vorherigen Eye Tracking
Studie überein und umfasste vier Stufen von „Sehr wichtig“ bis „Unwichtig“
(Gross12a). Auch der Rest des Fragebogens, welcher Fragen zu fehlenden Informa-
tionen und nach Gründen für die Einschätzung umfasste, entsprach dem der Eye
Tracking Studie.
3 Verwandte Arbeiten
13
In der anschließenden Auswertung konnte man einen Unterschied zu der Bewertung
der Architektur- und Usabilityexperten in der ersten Studie feststellen. Als besonders
wichtig wurden Interaktionsbeschreibungen, Systemfunktionalitäten, Qualitäts- und
technische Anforderungen, sowie Stakeholder und Ziele bewertet. Als weniger wich-
tig erachteten die Studenten Datenanforderungen, sowie Beschreibungen von
Aufgaben und Arbeitsweisen. Der Teil über die bisherige Arbeitsweise (as-is work-
flow) wurde als absolut unwichtig beurteilt. Als Erklärung dafür diente, dass die
Studenten bei dem gesamten Entwicklungsprozess dabei waren und einen aktiven
Teil der Anforderungserhebung und dem Erstellen der Spezifikation darstellten. Das
kann einen großen Einfluss auf ihre Einschätzung gehabt haben. Außerdem konnte
eine starke Varianz der Bewertungen zwischen den Studenten beobachtet werden
(Gross12b).
3.2.3 Tutorial Studie
Die dritte und letzte durchgeführte Studie des IESE behandelt F1_1, F1_2 und F1_3 aus
der Perspektive von Usabilityexperten. Dazu sollten zehn Teilnehmer eines Tutorials
über aufgabenorientiertes Requirements Engineering basierend auf dem TORE-
Framework (Adam09) nach dessen Ende in einem Fragebogen die vorgestellten Ar-
tefakt-typen mit einer Relevanz bewerten (Gross12a). Die Art der Bewertung mittels
Stufen von „Sehr wichtig“ bis „Unwichtig“ stimmt dabei mit der Skala der vorherigen
beiden Studien überein, um Vergleichbarkeit sicherzustellen. Auch nach Gründen
der Bewertung und der Eignung der Notation wurde genauso wie in den bisherigen
Fragebögen gefragt. Zusätzlich wurden jedoch, im Hinblick auf Forschungsfrage F1_2,
die Punkte, die der Artefakttyp enthielt, aufgeführt und der Proband sollte angeben,
welche er für wichtig erachtet (Gross12b). Damit sollte eine Aussage darüber getrof-
fen werden, wie detailliert die Abschnitte ausfallen sollten.
Die Ergebnisse der Studie ergaben ebenfalls Unterschiede zu den Bewertungen der
UI-Experten aus der Eye Tracking Studie, sowie Varianzen innerhalb der Teilneh-
mergruppe (Gross12a). Demnach wurden alle Artefakttypen als wichtig oder sehr
wichtig eingestuft. Die einzige Ausnahme bilden die Interaktions- und Domänenda-
ten, die als eher unwichtig bewertet wurden (Gross12b). Dies ließ sich durch die
angegebenen Kommentare erklären, die aussagten, dass aus Sicht der Teilnehmer
relevante Daten eher zusammen mit Interaktionsbeschreibungen (wie beispielsweise
Use Case-Beschreibungen) spezifiziert werden sollten. Weitere Ergebnisse, die
ebenfalls die Frage F1_3 adressieren, sagen aus, dass von den untersuchten Usabi-
lityexperten visuelle Repräsentationen im Vergleich zu textuellen Beschreibungen
generell bevorzugt werden. Jedoch konnte auch bei dieser Studie eine mögliche Ge-
fährdung der Resultate identifiziert werden, da die Teilnehmer erneut keine echte
Aufgabe umzusetzen hatten, sondern sich lediglich in die Situation hineinversetzen
mussten. Dennoch werden Studien dieser Art als geeignetes Mittel der Datenerhe-
bung eingeschätzt. Als zusammenfassende Schlussfolgerung hat das Fraunhofer
IESE festgehalten, dass die bisherigen Studien noch nicht ausreichten, um valide
Schlüsse ziehen zu können, die beobachteten Tendenzen jedoch vielversprechend
und weitere aufbauende Studien daher durchaus lohnenswert seien (Gross12b).
3.3 Ähnliche Studien zum Vergleich der Darstellungsform
Über die soeben aufgeführten Studien hinaus, stützt sich die durchgeführte Studie
außerdem auf die Ergebnisse einiger Studien, die ebenfalls die beiden Darstellungs-
formen Papier und Bildschirm miteinander verglichen haben (Dillon02). Diese
wurden zwar nicht im Kontext von Anforderungsspezifikationen durchgeführt, können
dennoch als Vergleichsmöglichkeit für die Resultate dienen.
3 Verwandte Arbeiten
14
Der Autor Andrew Dillon hat in seinem Buch „Reading from paper versus screens: a
critical review of empirical literature“ einige bis zu dem Zeitpunkt durchgeführte Stu-
dienergebnisse verglichen und hinterfragt (Dillon92). Dabei hat er mögliche zu
messende Merkmale zum Vergleich von den beiden Darstellungsmedien Papier und
Bildschirm in Ergebnis- und Prozessmerkmale („outcome vs. process measures“ (Dil-
lon92)) unterteilt. Ergebnismerkmale beziehen sich dabei auf das was ein Leser von
dem Text erhält. Das können Metriken wie aufgenommene Informationen, Wieder-
gabefähigkeit oder benötigte Lesezeit. Prozessmerkmale hingegen konzentrieren
sich darauf, wie der Leser den Text verwendet, beispielsweise das Blickverhalten
währenddessen oder wie Veränderungen durch Notizen oder ähnliches vorgenom-
men werden. Die Literatur und Forschung beschäftigt sich dabei hauptsächlich mit
Ergebnismerkmalen, da diese auf ein größeres Interesse stoßen und diesbezüglich
mehr Hypothesen aufgestellt werden (Dillon92).
In diesem Abschnitt werden einige betrachtete Metriken und die diesbezüglichen Er-
kenntnisse zusammengefasst. Dabei liegt das Hauptaugenmerk auf den Messungen,
die auch in der Studie, die im Rahmen dieser Arbeit durchgeführt wurde, betrachtet
wurden. Zu den thematisierten Ergebnismerkmalen gehört zum einen die Lesege-
schwindigkeit. Diese ist die mit Abstand am meisten untersuchte Metrik. Das
häufigste Ergebnis dabei war, dass das Lesen am Bildschirm signifikant langsamer
ist als das Lesen auf Papier. Studien belegen hierbei einen Performanzverlust von
20% bis 30% bei dem Lesen am Monitor. Den Untersuchungen liegen jedoch jeweils
unterschiedliche Berechnungen und Experimentdesigns zugrunde. Daher ist nicht
klar, ob immer die gleichen Gründe zu diesem Geschwindigkeitsverlust geführt ha-
ben. Andere Studien konnten wiederum keinen signifikanten Unterschied zwischen
den beiden Darstellungsmedien bei der Lesegeschwindigkeit feststellen. Es wird da-
her vermutet, dass der gefundene Unterschied womöglich von der Größe, Qualität
und dem Typ des Monitors abhängig ist (Dillon92).
Ein weiteres Kriterium in Bezug auf den Vergleich von der Darstellung auf Papier und
Bildschirm ist Genauigkeit, wie beispielsweise bei dem Finden von Informationen in
einem Text, der Wiedergabe bestimmter Sektionen oder dem Auffinden von Recht-
schreib- und Grammatikfehlern. Einschlägige Studien hierzu haben zum Beispiel
Buchstaben von Wörtern in einem Text vertauscht, hinzugefügt oder weggelassen
und die Leser sollten diese auffinden. Dabei wurden jedoch keine signifikanten Er-
gebnisse gefunden. Anders sieht es da bei Untersuchungen der Wiedergabefähigkeit
aus oder generell bei Aufgaben mit einem höheren visuellen und kognitiven An-
spruch. Bei diesen konnte ein Performanzdefizit beim Lesen am Monitor
nachgewiesen werden (Dillon92).
Eine andere untersuchte Metrik ist außerdem die Präferenz des Lesers, welche Dar-
stellungsform bevorzugt wird. Erste Studien haben dazu unterschiedliche Ergebnisse
erhalten. Je aktueller die Untersuchungen jedoch sind, umso eindeutiger geht die
Tendenz zu der Bevorzugung der digitalen Darstellung. Das wird sich dadurch er-
klärt, dass sich die Bildqualität neuerer Monitore über die Jahre deutlich verbessert
hat. Darüber hinaus ebenfalls ein im Zuge der Verbreitung digitaler Medien häufig
diskutierter Punkt ist eine höhere Neigung zu Müdigkeit bei dem Lesen am Bild-
schirm. Aber auch die Verständlichkeit des Textes ist eine weitere betrachtete Metrik.
Diesen Ergebnismerkmalen gegenüber stehen die Prozessmerkmale. Diese werden
hier nicht weiter behandelt, da sie für die durchgeführte Studie keine Bedeutung ha-
ben. Beispiele sind das Untersuchen der Blickbewegungen oder der Navigation des
Lesers im Text (Dillon92).
15
4 Planung der Studie
Die Zielsetzung dieser Arbeit ist es, Spezifikationen effektiver erstellen und effizienter
nutzen zu können. Eine Übersicht, wie dieses Ziel erreicht werden kann, gibt Abbil-
dung 4.1. Darin wird dargestellt, dass um die Voraussetzung für eine sichtenbasierte
Anforderungsspezifikation bzw. ein entsprechendes Tool zu schaffen, zunächst die
Informationsbedarfe der einzelnen Rollen untersucht werden müssen, um festzustel-
len welche Abschnitte für wen relevant sind. Die dafür nötigen Daten werden
innerhalb einer Studie erhoben, deren Planungsschritte in diesem Kapitel ausführlich
dokumentiert sind. Darüber hinaus wird innerhalb der Studie eruiert, welchen Effekt
die Darstellung ausgedruckt auf Papier oder am Bildschirm auf den Leseprozess hat.
Grundlage dieser Studie sind im Wesentlichen die vom Fraunhofer IESE durchge-
führten Studien, insbesondere die Eye Tracking Studie. Bei der Planung wurden
daher die dort festgestellten Schwächen berücksichtigt.
Abbildung 4.1: Zielsetzung und Motivation der Studie (angelehnt an (Gross11))
4.1 Ziele
4.1.1 Verbesserungsziele
Die folgenden Verbesserungsziele werden von der Studie untersucht.
VZ1: Effizienzsteigerung bei der Nutzung (dem Lesen) von Anforderungsspezifika-tionen im Kontext von Softwareprojekten, abhängig vom Darstellungsmedium und der Rolle des Lesers.
VZ2: Effektivitätssteigerung bei der Erstellung von Spezifikationen im Kontext von Softwareprojekten aus der Perspektive von Anforderungsingenieuren.
4.1.2 Erreichung der Verbesserungsziele
Die beschriebene Effizienzsteigerung soll durch eine auf den Informationsbedarf des
Nutzers hin optimierte Umstrukturierung des Spezifikationsdokuments erreicht wer-
den. Dabei wird die Effizienz anhand der benötigten Zeit zum Auffinden relevanter
Informationen im Dokument bewertet. Durch die Entwicklung solcher sichtenbasier-
ten Spezifikationen wird versucht Zeit und Ressourcen, also Kosten zu sparen, indem
Sichtenbasierte Anforderungsspezifikationen
Informationsbedarfe empirisch erheben
(UI-Designer, Softwarearchitekt, Tester, Entwickler)
Sichten auf Anforderungsdokumente
(z.B. toolbasiert)
Effizientere/ effektivere Nutzung sowie Erstellung
4 Planung der Studie
16
der Leseaufwand für am Projekt beteiligte Personen reduziert wird. Zusätzlich wird
die Konformität des fertigen Softwareprodukts mit den Anforderungen erhöht, da
wichtige Aspekte schneller zugreifbar sind (Gross12b).
Im gleichen Zug wird so eine Effektivitätssteigerung für die Anforderungsingenieure
erreicht, da die Spezifikation so einen eindeutig identifizierbaren Adressaten hat, auf
den die enthaltenen Informationen abgestimmt werden können. Die Herausforderung
allen Ansprüchen der Nutzer gleichzeitig gerecht werden zu müssen, fällt daher wei-
testgehend weg. Dadurch wird die Gefahr vermieden, für alle Rollen irrelevante
Aspekte mit aufzunehmen. Darüber hinaus, wird so Zeit im Projekt gespart, da der
Softwarearchitekt beispielsweise bereits mit dem Entwurf eines Entwicklungskon-
zepts beginnen kann, bevor manche Abschnitte, die beispielsweise nur die Rolle des
Testers benötigt, fertig gestellt sind (Gross12b).
Über den Vergleich der Darstellungsmedien kann zusätzlich festgestellt werden, ob
Spezifikationen am Bildschirm oder ausgedruckt unterschiedlich effizient gelesen
werden. In den geplanten Messungen soll es jedoch zunächst darum gehen, den
konkreten Informationsbedarf und die individuellen Anforderungen der verschiede-
nen Rollen, die die Spezifikation nutzen, zu ermitteln, um schließlich das Grundgerüst
für sichtenbasierte Anforderungsspezifikationen bieten zu können.
4.1.3 Betrachtete Darstellungsmedien
Bei der Darstellung werden dabei Papier und Bildschirm berücksichtigt. Das heißt,
es werden einmal am Bildschirm gelesene Spezifikationen und einmal ausgedruckte
Versionen untersucht.
4.1.4 Betrachtete Rollen
Bei der Rolle des Lesers kann es sich entweder um UI-Designer, Softwarearchitek-
ten, Tester oder Entwickler im Allgemeinen handeln. Die Rollen UI-Designer,
Softwarearchitekt und Tester sind dabei in ihrem Aufgabenfeld disjunkt. Die Tätigkeit
des Entwicklers hingegen umfasst die Zuständigkeiten aller drei Rollen. Dies bein-
haltet das Erstellen erster Entwürfe, über deren Umsetzung bis hin zum Herleiten
von Testfällen und deren Ausführung zur Sicherstellung der Anforderungen, sämtli-
che Aufgaben, die zum Entwickeln des Systems notwendig sind.
Für die Rollen Softwarearchitekt, UI-Designer und Tester werden diese Aufgaben
klar aufgeteilt. Der Softwarearchitekt in diesem Sinne ist dabei für die Implementie-
rung sämtlicher Funktionen, die das System bieten soll, also insbesondere der
funktionalen Anforderungen, zuständig. Außerdem fallen das Verwalten von invol-
vierten Daten, sowie das Bereitstellen von Schnittstellen an bestehende
Randsysteme in ihren Aufgabenbereich (Eckstein09). Bei UI-Designern hingegen
handelt es sich um Personen, die sich mit der Gestaltung von Benutzeroberflächen
auskennen und entsprechend nur für dessen Entwicklung zuständig sind (Eck-
stein09). Das heißt, ihre Aufgabe ist es, zunächst Entwürfe zu erstellen und diese zu
implementieren. Sie sind verantwortlich für die Bedienbarkeit des fertigen Produkts,
dessen Verständlichkeit und intuitive Verwendbarkeit. Nicht-funktionale Anforderun-
gen müssen somit sowohl von Softwarearchitekten, als auch von UI-Designern
beachtet und sichergestellt werden.
Der Tester muss zum einen zu Beginn die Akzeptanzkriterien der Software definie-
ren, die er in Form von Abnahmetestfällen festhält. Zum anderen überprüft er
abschließend nach der Implementierung der Komponenten, deren Richtigkeit, also
die Erfüllung der Systemanforderungen, indem er zu diesem Zweck die entsprechen-
den Testfälle ausführt (Eckstein09). Diese Aufgabe hat besondere Priorität, da nur
so die gewünschte Funktionsweise gewährleistet werden kann.
4 Planung der Studie
17
In der Praxis werden Rollen unter Umständen auch durch mehrere Personen ausge-
füllt oder eine Person übernimmt mehrere Rollen (Eckstein09). In dieser Studie hat
jedoch jede Person genau eine Rolle und innerhalb eines Durchlaufs mit einem Teil-
nehmer wird diese Rolle auch nur durch eine Person repräsentiert. Dies dient der
Vereinfachung und Sicherung der Auswertung.
4.1.5 Von der Betrachtung ausgeschlossene Rollen
Ebenfalls maßgeblich am Projekt beteiligt und Stakeholder der Spezifikation sind na-
türlich auch weitere Rollen wie Kunden und die Projektleitung. Der Vollständigkeit
halber werden sie daher ebenfalls beschrieben.
Bei dem Kunden handelt es sich in der klassischen Kundensituation um ein Unter-
nehmen, das eine bestimmte Softwarelösung wünscht. Im Falle von
Produktentwicklungen kann auch der Markt die Rolle des Kunden einnehmen (Vers-
teegen03). Der Kunde wird entweder direkt vom Auftraggeber oder eine hierarchisch
tiefer gestellte Person des Fachgebiets vertreten (Günter13). Er tritt dabei als Ver-
tragspartner auf, dessen Grundlage die Spezifikation ist. In dieser müssen alle
gewünschten Funktionalitäten und Eigenschaften enthalten sein, da sich im Zwei-
felsfall darauf berufen werden kann. Der Kunde hat eine wesentliche Rolle im Projekt,
da er die Schnittstelle zwischen der Businesswelt, in der das Produkt Anwendung
findet und der Entwicklerseite bildet. Sämtliche Anforderungen werden mit seiner
Hilfe ermittelt. Unter Umständen liefert er sogar direkt Use Cases oder Testfälle
(Günter13).
Die Rolle des Projektleiters hat umfassend beschrieben die Aufgabe für das Team
eine Umgebung zu schaffen, in der jeder seiner Tätigkeit nachgehen und in Ruhe
arbeiten kann. Dazu kümmert er sich um organisatorische Angelegenheiten, wie die
Etablierung und Gewährleistung der Unterstützung des Projekts innerhalb des Soft-
wareunternehmens und ist zudem im Falle von Konfliktsituationen der verständige
Ansprechpartner für die Teammitglieder (Eckstein09). Darüber hinaus hat er die Ge-
samtverantwortung für das Projekt und wird in alle wichtigen Entscheidungen
integriert (Versteegen03). Oft ist er auch für die Organisation von Einstellungen neuer
geeigneter Mitarbeiter zuständig (Eckstein09).
Da die Tätigkeitsfelder dieser Rollen jedoch sehr umfassend sind und aufgrund des
Mangels an geeigneten Probanden, kann der Informationsbedarf dieser Rollen nur
sehr schwer in einem off-line Experiment, also einer Studie in nicht-industriellem
Rahmen, untersucht werden. Andernfalls wäre die Validität der Daten und somit der
Resultate gefährdet, wenn bestimmte Rollenaspekte unberücksichtigt oder Proban-
den zu sehr aus ihrem gewohnten Arbeitsumfeld entfremdet würden. Daher wurde
sich in dieser Studie lediglich die Rollen beschränkt, die die direkte Entwicklung des
Systems betreffen, um so Aussagen darüber treffen zu können, welche Abschnitte
der Spezifikation für diese Gruppen eine hohe Priorität haben oder irrelevant sind.
4.1.6 Messziel
Um die Verbesserungsziele der Studie erreichen zu können, muss zunächst der In-
formationsbedarf der betrachteten Rollen untersucht werden. Das primäre Ziel der
Messung ist somit die:
MZ1: Untersuchung des Informationsbedarfs der Nutzer von Spezifikationen unter Berücksichtigung dessen Rolle und dem verwendeten Darstellungsmedium.
Dieses deckt sich mit dem Forschungsziel FZ1 des Fraunhofer IESE, was die Ver-
gleichsmöglichkeiten der Resultate ermöglicht (Gross12b).
4 Planung der Studie
18
4.2 Fragen
Ausgehend von den Verbesserungs- und Messzielen wurden Fragen erarbeitet, des-
sen Betrachtung das Erreichen der Ziele ermöglicht. Im Anschluss wurden dazu
Metriken definiert, dessen Erfassung zur Beantwortung der Fragestellungen beitra-
gen. Alle Ziele, Fragen und Metriken, sowie dessen Zusammenhänge sind in
Abbildung 4.2 dargestellt. In dieser Studie wurde die Metrikebene des GQM-Para-
digmas in zwei Ebenen aufgespalten, um den Zusammenhang zwischen Metrik und
Fragestellung erkennbarer zu machen. Zu allen Metriken findet sich zudem eine aus-
führliche Beschreibung in Kapitel 4.3.
Abbildung 4.2: Übersicht über Ziele, Fragen und Metriken
Zwischen-
metriken
Verbesserungs-
ziele
Effizienzsteigerung bei der Nut-
zung von Spezifikationen im
Kontext von Softwareprojekten aus der Perspektive von UI-De-
signern, Architekten und
Testern
Effektivitätssteigerung bei der
Erstellung von Spezifikationen
im Kontext von Softwarepro-
jekten aus der Perspektive von
Anforderungsingenieuren
F1: Welche Dar-
stellungsform
(ausgedruckt oder
am Bildschirm) ist
geeigneter?
F2: Welche Ab-
schnitte sind
besonders wichtig/
unwichtig? (rollen-
abhängig)
Wiedergabe-
fähigkeit
Vorliebe
des Le-
sers
Geschwin-
digkeit Intensität
des Lesens
einzelner
Abschnitte
Frage-
bogen Lesezeiten
für AOIs auf
Abschnitten
Länge der
Spezifikations-
abschnitte in
Zentimetern
Gesamt-
lesezeit
Relevanz
F3: Gibt es Un-
terschiede
innerhalb der
Rollen? (rollen-
abhängig)
Untersuchung des Informationsbedarfs
der Nutzer von Spezifikationen unter
Berücksichtigung dessen Rolle und
dem Darstellungsmedium
Messziele
Fragen
Metriken
4 Planung der Studie
19
Zu jeder Frage werden im Anschluss überblicksartig die verwendeten Untersu-
chungsobjekte, zugehörige Metriken und zu erwartende Hypothesen aufgelistet.
F1: Darstellungsform
Frage Welche Darstellungsform (ausgedruckt oder am Bildschirm)
ist geeigneter?
Objekt Spezifikation ausgedruckt, Spezifikation am Bildschirm
Zwischenmetrik Vorliebe des Lesers, Wiedergabefähigkeit, Geschwindigkeit
Hypothese HA1_1: Die ausgedruckte Darstellung wird bevorzugt.
HA1_2: Die Wiedergabefähigkeit unterscheidet sich abhängig
von der Darstellungsart.
HA1_3: Die ausgedruckten Spezifikationen werden schneller
gelesen als die am Bildschirm gelesenen Spezifikationen.
F2: Auswahl der Abschnitte
Frage Welche Abschnitte sind für welche Rolle besonders relevant?
Welche sind weniger relevant?
Objekt Spezifikationen
Zwischenmetrik Priorisierung des Lesers, Intensität des Lesens einzelner Ab-
schnitte
Hypothese HA2_1: Die Abschnitte werden unterschiedlich bewertet.
F3: Unterschiede zwischen den Rollen
Frage Gibt es Unterschiede zwischen den Informationsbedarfen ein-
zelner Rollen?
Objekt Spezifikationen
Zwischenmetrik Priorisierung des Lesers
Hypothese HA3_1: Bei mindestens zwei Rollen unterscheiden sich die Mit-
telwerte der Relevanzbewertung.
HA3_2: Wichtig bewertete Abschnitte werden intensiver gele-
sen als unwichtig bewertete und umgekehrt.
4.3 Metriken
Die Metriken, die zur Beantwortung der zuvor aufgestellten Fragen nötig sind, werden
hier genau beschrieben. Die Metrik-Ebene des GQM-Paradigmas wurde, wie bereits
zuvor beschrieben, in die beiden Unterebenen Zwischenmetrik und Metrik aufgeteilt.
Zu jeder hier definierten Zwischenmetrik ist festgehalten, welche konkreten Metriken
zum Messen notwendig sind, wie diese ausgeführt werden und um welchen Skalen-
typ es sich handelt.
4 Planung der Studie
20
4.3.1 Beschreibung der Zwischenmetriken
M1: Präferenz des Lesers
Um festzustellen, welche Darstellungsform der Leser präferiert, wird ein Fragebogen
konzipiert, der dem Probanden vor dem Lesen der Spezifikation übergeben wird und
in dem dieser seine Vorliebe festhält (siehe A.2.1). Dort wählt er entweder ausge-
druckt oder am Bildschirm. Aufgrund der beiden voneinander unabhängigen
Antwortmöglichkeiten ohne implizierte Rangordnung, handelt es sich hierbei um eine
Nominalskala.
M2: Wiedergabefähigkeit
Unter Wiedergabefähigkeit wird hier die Fähigkeit verstanden, nach dem Lesen des
Dokuments darin befindliche Inhalte wiedergeben zu können. Dies erfolgt ebenfalls
in einem Fragebogen nach dem Lesen der Spezifikation. Dazu werden insgesamt
sechs Fragen zum Inhalt gestellt. Zu jeder Frage gibt es drei Antwortmöglichkeiten,
von denen jeweils genau eine richtig ist. Anschließend wird die Anzahl an richtigen
Antworten bestimmt, wobei es auch als falsch gewertet wird, wenn eine Frage nicht
beantwortet oder mehr als eine Antwort abgegeben wird. Bei den Fragen handelt es
sich jeweils um Nominalskalen, bei der Anzahl an richtigen Antworten, die daraus
ermittelt wird, um eine Verhältnisskala.
M3: Priorisierung des Lesers
Die Feststellung der Priorisierung des Lesers wird ebenso in demselben Fragebogen
gemessen. Dazu werden alle Abschnitte der gelesenen Spezifikation aufgelistet und
sind vom Probanden subjektiv mit sehr wichtig, wichtig, weniger wichtig oder unwich-
tig zu bewerten. In einer vorherigen Einleitung (siehe A.1) wird darauf hingewiesen,
dass es dabei nicht um die allgemeine Relevanz im Projekt geht, sondern nur darum,
ob der jeweilige Abschnitt wichtig ist, um die Tätigkeiten der Rolle des Teilnehmers
ausführen zu können. Dabei handelt sich um dieselbe Ordinalskala, die auch bei der
Studie des Fraunhofer IESE verwendet wurde, um die Ergebnisse später vergleichen
zu können (Gross12b).
M4: Geschwindigkeit
Die Geschwindigkeit mit der der Leser das Dokument liest wird in cm/s (Zentimeter
pro Sekunde) gemessen. Dazu wird zum einen die Länge der einzelnen Abschnitte
in Zentimetern bestimmt und zum anderen die jeweilige Lesedauer in Sekunden ge-
messen. Die Geschwindigkeit wird daraus indirekt errechnet, indem die Summe der
Abschnittslängen durch die Summe der Lesezeiten dividiert wird. Dabei sei darauf
hingewiesen, dass damit nicht die tatsächliche Lesegeschwindigkeit gemessen wird,
da nicht davon ausgegangen werden kann, dass jede Zeile gelesen wird. Es handelt
sich lediglich um einen Vergleichswert, wie viel Zeit Nutzer von Spezifikationen zum
Lesen benötigen, abhängig von der Darstellungsart. Bei der Messskala handelt es
sich hierbei um eine Verhältnisskala (ratio scale).
M5: Intensität des Lesens einzelner Abschnitte
Mit dieser Metrik wird gemessen wie intensiv die einzelnen Abschnitte gelesen wer-
den. Dazu wird auf jedem Abschnitt der Spezifikation mithilfe der EyeTracking
Analysesoftware ein Area of Interest (AOI) definiert und so die Lesezeiten für alle
Abschnitte miteinander verglichen. Um daraus zu ermitteln, wie intensiv der jeweilige
Teil gelesen wurde, werden die Werte für die Lesedauer anschließend mit den Län-
gen der Abschnitte relativiert. So erhält man die entsprechenden Leseintensitäten in
der Einheit s/cm (Sekunden pro Zentimeter). Die Messung der Lesezeiten und Ab-
schnittslängen erfolgt auf einer Verhältnisskala (ratio scale).
21
5 Vorbereitung der Studie
In diesem Kapitel werden die verwendeten Untersuchungsobjekte, Messverfahren
und -instrumente, sowie das konkrete Design der Studie beschrieben.
5.1 Auswahl der Untersuchungsobjekte
Bei den Untersuchungsobjekten der Messung handelt es sich um die jeweiligen Spe-
zifikationen, dessen Verwendung mithilfe des EyeTrackers Red-m, sowie den
EyeTracking Glasses untersucht wird. In dieser Studie werden zwei Spezifikationen
verwendet, die beide dem Spezifikationstemplate für Softwareprojekte des Fachge-
biets Software Engineering der Leibniz Universität Hannover folgen. Einen Überblick
darüber gibt Abbildung 5.1.
Für die Studie wurden die Spezifikationen jedoch insofern abgeändert, dass zum ei-
nen im Dokument vorkommende Namen entfernt oder anonymisiert wurden und
zusätzlich die Abschnitte „Entwurf der grafischen Benutzeroberfläche“ bzw.
„MockUps“ und „Abnahmetestfälle“ entfernt wurden, da die Probanden mit den Rol-
len UI-Designer, Tester und Entwickler andernfalls in Ihrer Aufgabe beeinflusst
würden.
Abbildung 5.1 macht außerdem deutlich, dass die Spezifikationen, die nach diesem
Template erstellt werden, eine Zusammenführung von Lasten- und Pflichtenheft sind.
In ihnen werden sowohl die Wünsche und Prioritäten des Kunden, aber auch kon-
krete Umsetzungsansätze der Entwickler genannt. Das hilft dabei im Nachhinein bei
der Auswertung Abschnitte beider Kategorien bewerten zu können und sich nicht auf
Lasten- oder Pflichtenheft beschränken zu müssen.
Bei der Auswahl der Spezifikationen wurde darauf geachtet, dass sie den Teilneh-
mern der Studie noch nicht bekannt waren, um Einflüsse durch Vorwissen, wie sie in
der zweiten Studie des IESE vorkamen (Gross12b), zu vermeiden.
Die erste Spezifikation enthält eine Beschreibung der Anwendung „Set!“. Set ist ein
Kartenspiel bei dem es darum geht bestimmte Muster in den für alle Mitspieler sicht-
bar ausgelegten Karten zu finden. Dieses Spiel soll in dem Projekt als
Desktopanwendung mit einem Einzelspielermodus und einem Mehrspielermodus
umgesetzt werden. Im Mehrspielermodus können bis zu sechs Spieler über eine Ser-
ververbindung an einem gemeinsamen Spiel teilnehmen. Die Anwendung soll in der
Programmiersprache Java entwickelt werden.
Bei der zweiten Spezifikation handelt es sich um die Beschreibung einer Überset-
zungsanwendung. Diese Webanwendung mit dem Namen „Translate“ soll Nutzer bei
dem Schreiben wissenschaftlicher Arbeiten bzw. dem Verstehen fremdsprachiger
Veröffentlichungen unterstützen, indem es zu einem Wort verschiedene Überset-
zungsmöglichkeiten, sowie Synonyme ausgibt. Die Übersetzung erfolgt vom
Deutschen ins Englische oder anders herum. Alle Ergebnisse werden dabei gegebe-
nen Übersetzungswebseiten, wie z.B. dict.leo.org oder translate.google.de,
entnommen. Dem Nutzer ist es zudem möglich weitere Onlinewörterbücher hinzuzu-
fügen und sie mit einer Gewichtung zu bewerten. Beide Spezifikationen kamen
einmal in digitaler und einmal in ausgedruckter Form zum Einsatz. Ausgedruckt wur-
den sie einseitig auf weißem Papier in Schriftgröße zwölf der Schriftart Times New
Roman. In digitaler Form wurden sie ganzseitig auf einem etwa 22“ großen Monitor
mit hoher Auflösung angezeigt.
5 Vorbereitung der Studie
22
Abbildung 5.1: SE-Template Spezifikationen (Schneider15)
5.2 Kontextbeschreibung
Die Studie wird im Rahmen eines off-line Quasi-Experiments durchgeführt. Das
heißt, die Studie findet nicht im Umfeld eines echten Projekts in einem Unternehmen
statt, sondern in einer definierten Forschungsumgebung. Das bringt jedoch den Vor-
teil guter Replikations- und Vergleichsmöglichkeiten mit sich, da der Kontext somit
klar spezifiziert ist und wieder herbeigeführt werden kann. Damit unterscheidet es
sich von einem echten Projekt, das nach Abschluss nicht wiederholt werden kann
(Wohlin00).
Ein Quasi-Experiment ist es deshalb, da die Auswahl der Teilnehmer nicht mit der
für ein echtes Experiment erforderlichen Zufälligkeit erfolgt (Wohlin00). Das ergibt
sich daraus, dass nicht eine zufällige Stichprobe der betrachteten Personengruppe
ausgewählt wurde, sondern die Teilnehmer sich auf freiwilliger Basis für die Studie
melden konnten.
5.2.1 Testpersonen (Stichprobe)
Bei acht der elf betrachteten Versuchsteilnehmer handelt es sich um Informatikstu-
denten der Leibniz Universität Hannover. Eine Hälfte von ihnen ist im zweiten oder
vierten Mastersemester, die andere Hälfte im sechsten oder achten Semester im Ba-
chelorstudium. Alle Teilnehmer sind zwischen 21 und 40 Jahre alt und haben gute
bis sehr gute Deutschkenntnisse. Das heißt, es sollte bei keinem Probanden zu
sprachlichen Verständnisproblemen der Spezifikationen gekommen sein. Zudem ha-
ben alle Testpersonen vorher schon einmal nach einer Spezifikation entwickelt oder
Spezifikationstemplate
Softwareprojekt, Leibniz Universität Hannover
1 Mission des Projekts
1.1 Erläuterungen des zu lösenden Problems
1.2 Wünsche und Prioritäten des Kunden
1.3 Domänenbeschreibung
1.4 Maßnahmen zur Anforderungsanalyse
2 Rahmenbedingungen und Umfeld
2.1 Einschränkungen und Vorgaben
2.2 Anwender
2.3 Schnittstellen und angrenzende Systeme
3 Funktionale Anforderungen
3.1 Use Case-Diagramme
3.2 Use Case-Beschreibungen
3.3 Technische Anforderungen
4 Qualitätsanforderungen
4.1 Qualitätsziele des Projekts
4.2 Qualitäts-Prioritäten des Kunden
4.3 Wie Qualitätsziele erreicht werden sollen
5 Probleme und Risiken
6 Optionen zur Aufwandsreduktion
6.1 Mögliche Abstriche
6.2 Inkrementelle Arbeit
7 MockUps
8 Glossar
9 Abnahme-Testfälle
5 Vorbereitung der Studie
23
sind zumindest in der Lehrveranstaltung „Software-Projekt“ damit in Berührung ge-
kommen.
Bei den drei Probanden, die keine Informatikstudenten (mehr) sind, handelt es sich
um erfahrene Entwickler. Einer von ihnen arbeitet als Produktmanager und Entwick-
ler in einem Startup. Der zweite ist in einem Unternehmen mit etwa 70 Mitarbeitern
als Softwareentwickler tätig, fungiert außerdem als Teamleiter berichtend für die
übergeordnete Ebene. Darüber hinaus hat er hin und wieder auch Kontakt mit den
Kunden. Der dritte und letzte erfahrene Versuchsteilnehmer arbeitet als Integrations-
architekt. In seinen Aufgabenbereich fallen Schnittstellen von Software, sowie das
Erstellen und „Reviewen“ von Spezifikationen und teilweise Programmiertätigkeiten.
5.2.2 Untersuchungsumgebung
Die Studie fand in einem geschlossenen Raum in der Leibniz Universität Hannover
statt. Die Umgebung war für die Teilnehmer ruhig und störungsfrei, sodass sie sich
voll und ganz auf die Inhalte der Studie konzentrieren konnten. Der Termin wurde für
jeden individuell festgelegt und lag zwischen 10:00 Uhr und 15:40 Uhr, im Zeitraum
von knapp drei Wochen. Außer Tageslicht wurden keine weiteren Lichtquellen ver-
wendet und um eine geeignete Messumgebung für das Eye Tracking zu schaffen
wurde direktes Sonnenlicht ggf. abgedämmt.
5.3 Datenquellen und Messmethoden
Sämtliche während der Studie erfasste Daten werden über Fragebögen, die entwe-
der auf Papier oder am Bildschirm beantwortet werden, den Eye Tracker Red-m für
die am Monitor gelesenen Spezifikationen und die Eye Tracking Glasses für die aus-
gedruckten Exemplare gesammelt. Die Datenerfassung erfolgt dabei komplett
anonym. Das heißt, die Angaben von jedem Teilnehmer werden mit einer Teilneh-
mer-ID, die fortlaufend von 001 bis 013 den Probanden zugeteilt wird, versehen und
so können die Daten der Fragebögen und die Aufnahmen der EyeTracker einander
zugeordnet werden.
5.3.1 Fragebögen
Der erste Fragebogen (siehe A.2.1), der vor dem Lesen der Spezifikation ausgehän-
digt wird, enthält Fragen zu dem Hintergrund der Teilnehmer. Dazu gehören das
Alter, der Erfahrungsstand und welche Darstellungsform bevorzugt wird, sowie im
Fall von Studenten der Studiengang und das Semester. Der zweite Fragebogen
(siehe A.2.2 und A.2.3) dagegen beinhaltet zunächst die sechs inhaltlichen Fragen,
die die Wiedergabefähigkeit feststellen sollen und anschließend sind die Abschnitte
der Spezifikation aufgelistet, zu denen der Teilnehmer jeweils eine Relevanzein-
schätzung von Sehr wichtig, über Wichtig und Weniger wichtig bis hin zu Unwichtig
abgeben kann. Diese Skala entspricht exakt der in den Studien des Fraunhofer IESE
(Gross12b) verwendeten Ordinalskala.
Die inhaltlichen Fragen wurden so konzipiert, dass zu beiden Spezifikationen eine
Frage zu dem Abschnitt „Mission des Projekts“, ein bis zwei Fragen zu den Abschnit-
ten „Rahmenbedingungen und Umfeld“, sowie „Funktionale Anforderungen“
enthalten sind und dazu noch jeweils eine Frage zu den Kapiteln „Qualitätsanforde-
rungen“ und „Probleme und Risiken“. So wird sichergestellt, dass mindestens eine
Frage einen Abschnitt betrifft, der für die Rolle des Probanden relevant ist. Dies ist
zwar für die Auswertung irrelevant, da die Ergebnisse der Fragen nur rollenübergrei-
fend verglichen werden, verunsichert die Probanden jedoch nicht so sehr.
Beide Fragebögen sind während der Studie zweimal zu beantworten – einmal aus-
gedruckt bei dem Durchlauf mit den Eye Tracking Glasses und einmal am PC bei
5 Vorbereitung der Studie
24
dem Durchlauf mit dem externen Eye Tracker. Die Reihenfolge variiert dabei zufällig
von Teilnehmer zu Teilnehmer. Im Falle des externen Eye Trackers werden die Fra-
gen jeweils bildschirmfüllend mit schwarzer Schrift auf hellgrauem Hintergrund
angezeigt. Dabei ist es nicht möglich, keine oder mehr als eine Antwort pro Frage
anzugeben.
5.3.2 Experiment in der Eye Tracking Software
Um Daten mithilfe des externen Eye Trackers am Monitor aufnehmen zu können,
muss dazu vorab ein Experiment erstellt und darin einzelne Stimuli, wie beispiels-
weise Fragen, Web- oder PDF-Seiten, definiert werden. Obwohl nur während dem
Lesen der Spezifikation Daten aufgenommen werden, wurden auch die Fragen des
ersten und zweiten Fragebogens für den Durchlauf mit der digitalen Spezifikation in
die Software integriert, um die Eingewöhnungsphase mit dem Eye Tracker auszu-
gleichen, da der Proband dann bereits einige Zeit am Bildschirm verbracht hat, wenn
mit der Aufnahme begonnen wird. Des Weiteren lassen sich die Daten in der Analyse
auf diese Weise nach den Antworten der Probanden filtern.
Das Experiment, dass für diese Studie erstellt wurde, besteht zunächst aus den zwölf
allgemeinen Fragen, gefolgt von einigen einführenden Worten und der Spezifikation.
Die beiden verwendeten Spezifikationen lassen sich aufgrund ihrer Länge nur als
PDF-Stimulus einbinden. Das bedeutet, dass die Spezifikation als PDF-Dokument
jeweils seitenweise, bildschirmfüllend angezeigt wird und der Proband die Möglich-
keit hat mithilfe der linken und rechten Pfeiltaste zu navigieren. Gewohnte
Interaktionen wie Zoomen, Scrollen innerhalb von Seiten oder die Suchfunktion, sind
hierbei nicht möglich. Nachdem der Teilnehmer die Spezifikation gelesen hat, gelangt
er zu den sechs inhaltlichen Fragen und wird anschließend durch die Überschriften
der einzelnen Spezifikationsabschnitte geleitet, bei denen er jeweils eine Relevanz
zwischen Sehr wichtig und Unwichtig auszuwählen hat.
5.4 Design der Studie
Da nun das Umfeld, sowie die Untersuchungssubjekte und -objekte beschrieben
sind, kann anschließend der Ablauf der Studie geplant werden. Jedem Probanden
wurden in der Studie beide ausgewählten Spezifikationen nacheinander zum Lesen
zur Verfügung gestellt. Davon ist jeweils eine in digitaler Form am Bildschirm und
eine in ausgedruckter Fassung auf Papier. Bei der Verteilung wurden die generellen
Designprinzipien Randomisierung, Blocking und Balancing berücksichtigt
(Wohlin00).
5.4.1 Randomisierung
Jeder Teilnehmer der Studie erhält eine Spezifikation ausgedruckt und eine zum Le-
sen am Bildschirm. Die Reihenfolge, welche der beiden Darstellungsarten zuerst
verwendet wird erfolgt zufällig. Auch die Auswahl der ersten Spezifikation und die
Zuordnung zu einer der Rollen geschieht zufällig, sodass das Prinzip der Randomi-
sierung eingehalten wird.
5.4.2 Blocking
Eine angepasste Version des Blocking-Ansatzes wird in diesem Fall insofern ange-
wandt, dass Unterschiede zwischen den Spezifikationen, die womöglich das
Ergebnis beeinflussen könnten, ausgeblendet werden, indem jede Spezifikation bei
jeder Rolle gleich oft untersucht wird. Das heißt, für jede Rolle werden die gleichen
Spezifikationen betrachtet, sodass eventuelle spezifikationsabhängige Faktoren bei
allen Gruppen gleich sind.
5 Vorbereitung der Studie
25
5.4.3 Balancing
Bei dem Design der Studie handelt es sich zudem um ein ausgeglichenes (balanced)
Design. Dies wurde erreicht, indem folgende Grundsätze eingehalten wurden.
1. Für jede Rolle und jede Spezifikation werden gleich viele Datensätze von der
gleichen Anzahl Probanden aufgenommen.
2. Jeder Teilnehmer nimmt genau eine Rolle ein und bekommt die gleiche An-
zahl Spezifikationen zum Lesen.
3. Den beiden Darstellungsarten ausgedruckt und am Bildschirm werden jeweils
gleich viele Teilnehmer, sowie Spezifikationen zugeordnet.
4. Jede Spezifikation wird gleich oft in ausgedruckter und digitaler Form unter-
sucht.
Die einzige Abweichung von diesem Designprinzip liegt bei den Aufnahmen der er-
fahrenen Entwickler vor, da hierbei drei Teilnehmer untersucht wurden und nicht nur
zwei, wie es bei den anderen Rollen der Fall war. Einer der Teilnehmer hat zudem,
da er es nicht anders einrichten konnte, nur die Hälfte der Studie absolviert. Das
heißt, er hat nur eine Spezifikation gelesen und die entsprechenden Fragebögen be-
antwortet und nimmt daher eine Sonderrolle ein. Diese Abweichung hat jedoch keine
weitreichenden Konsequenzen und wurde bei den entsprechenden Tests in der Aus-
wertung berücksichtigt, in dem in Einzelfällen die Daten dieser Versuchsperson nicht
mitberücksichtigt wurden.
5.5 Zuordnung der Untersuchungssubjekte und -objekte
Entsprechend der eben beschriebenen Designprinzipien wurde den Teilnehmern zu-
fällig eine Rolle und eine Reihenfolge der Spezifikation und Darstellungsart zugeteilt,
so dass am Ende alle Kombinationen gleichmäßig besetzt sind.
In Tabelle 5.1 ist diese Zuordnung dargestellt. In der ersten Spalte steht dabei die ID
des Teilnehmers, die den Probanden in chronologischer Reihenfolge zugeteilt wurde.
Das heißt, je höher die ID des Teilnehmers, desto später fand der entsprechende
Durchlauf der Studie statt. In den Spalten zwei bis fünf sind die Spezifikationen an-
gegeben. Die beiden verwendeten Spezifikationen „Set“ und „Translate“ erscheinen
jeweils einmal in ausgedruckter Form mit der Kennung „_a“ oder in digitaler Form am
Bildschirm mit der Kennung „_d“. Die in den Feldern angegebene Nummer impliziert
die Reihenfolge, in der die Spezifikationen den Probanden gegeben werden. Ab-
schließend ist in der letzten Spalte die zugeteilte Rolle vermerkt. Jede der vier
möglichen Rollen wurde dabei genau zweimal besetzt, um für jede Rolle einen Ver-
gleichswert zu haben. Die Anzahl an Teilnehmern wurde auf elf beschränkt, da die
Vor- und Nachbereitung und die Durchführung eines Durchlaufs, sowie die Analyse
der Aufnahmedaten der Eye Tracking Glasses sehr zeitaufwändig ist und sonst den
Rahmen der Studie überschreiten würde.
5 Vorbereitung der Studie
26
Tabelle 5.1: Übersicht über die Zuordnung der Probanden
5.6 Beschreibung des Ablaufs
Der Fortgang der Studie ist für jeden Teilnehmer genau gleich, abgesehen von der
Reihenfolge der ausgewählten Darstellungsmedien Papier und Monitor und der Rei-
henfolge der beiden Spezifikationen „Set“ und „Translate“. Alle Probanden werden
dabei von der gleichen Person betreut, um Fragen stellen zu können und durch das
Experiment begleitet zu werden. Eben diese Person ist auch dafür zuständig, Auffäl-
ligkeiten zu dokumentierten, die unter Umständen bei der Durchführung der Studie
auftreten könnten.
Zu Beginn der Studie wird der Proband gebeten sich zu setzen und bekommt zu-
nächst den allgemeinen Ablauf der Studie erklärt, um sich darauf einstellen zu
können. Anschließend liest er die Einführung (siehe A.1). In dieser sind weitere all-
gemeine Informationen zur Studie gegeben. Darüber hinaus erfährt der Teilnehmer
hier die Aufgabe, die er während der Studie zu bearbeiten hat. Diese umfasst die
ersten Tätigkeiten, die die zugewiesene Rolle umfasst (siehe 4.1.4). Es wurde gro-
ßen Wert darauf gelegt, dass die Teilnehmer sich nicht nur ihre Tätigkeit vorstellen,
sondern tatsächlich einen UI- oder Architekturentwurf konzipieren sollen, um Ein-
flüsse durch diese Abweichung von den realen Umständen zu umgehen (Gross12b).
Darüber hinaus sollen die Teilnehmer sich nur auf ihre Rolle und Aufgabe konzent-
rieren und nicht versuchen die Studienergebnisse in eine bestimmte Richtung zu
lenken. Daher wird ihnen nicht mitgeteilt, was das Ziel der Studie und die jeweilige
Hypothese ist, um solche Beeinflussungen zu vermeiden. Außerdem werden sie da-
rauf hingewiesen, dass die Studie anonym erfolgt und es kein Test ihrer Fähigkeiten
darstellt.
Nachdem der Teilnehmer die Einführung gelesen hat, hängt der weitere Verlauf da-
von ab, ob mit der ausgedruckten oder der am Bildschirm gelesenen Spezifikation
Teilnehmer Spezifikationen Rolle
Set_a Set_d Translate_a Translate_d
002 1. 2. Softwarearchi-tekt
003 2. 1. Tester
004 2. 1. Softwarearchi-tekt
005 2. 1. UI-Designer
006 1. 2. Tester
007 1. 2. Entwickler (Student)
008 1. 2. Entwickler (Student)
010 2. 1. UI-Designer
011 1. 2. Entwickler (mit Erfahrung)
012 1. 2. Entwickler (mit Erfahrung)
013 2. 1. Entwickler (mit Erfahrung)
5 Vorbereitung der Studie
27
begonnen wird. Im Fall der ausgedruckten Spezifikation beantwortet der Proband
nun den ersten Fragebogen (siehe A.2.1) und anschließend wird er gebeten die Eye
Tracking Brille aufzusetzen. Nachdem geprüft wurde, dass diese richtig sitzt und die
Software für die Kalibrierung bereit ist, wird diese durchgeführt und es kann mit der
Aufnahme begonnen werden. Zu diesem Zeitpunkt wird der Teilnehmer darauf hin-
gewiesen, dass ihm nun die Spezifikation ausgeteilt wird und er ab dann 20 Minuten
Zeit zum Lesen der Spezifikation und zum Bearbeiten seiner Aufgabe hat. Es wird
betont, dass die Bearbeitung auch schrittweise erfolgen kann und das Lesen der
Spezifikation für Notizen oder erste Skizzen unterbrochen werden darf. Die Vorgabe
ist lediglich nach 20 Minuten die Aufgabe zu beenden.
Anschließend, sobald der Teilnehmer dies bestätigt hat, erhält er die Spezifikation
und die Aufnahme der Brille, sowie die Zeit wird gestartet. In 5 Minuten Abständen,
sowie eine Minute vor Ablauf der Bearbeitungszeit wird dem Probanden der aktuelle
Zeitstand mitgeteilt. Die Zeit wird mit einer Stoppuhr gemessen und nach dessen
Ablauf wird die Aufnahme des Eye Trackers gestoppt und der Proband darf die Brille
wieder absetzen. Abschließend wird ihm noch der zweite Fragebogen ausgeteilt. Das
Bild in Abbildung 5.2 zeigt wie die Versuchsumgebung für die Teilnehmer bei dem
Lesen der ausgedruckten Spezifikation aussah.
Wird mit der am Bildschirm gelesenen Spezifikation begonnen, erfolgt die gesamte
Befragung für diese Spezifikation in dem zuvor erstellten Experiment in der Eye Tra-
cking Software Experiment Center. Um mit diesem beginnen zu können, wird vorerst
überprüft, ob der Teilnehmer den richtigen Abstand und Winkel zu dem Bildschirm
und dem Eye Tracker hat. Nachdem dieser ggf. nachjustiert wurde, kann die Auf-
nahme gestartet werden. Diese beginnt vorerst mit einer 5-Punkt Kalibrierung.
Anschließend wird der Proband Schritt für Schritt durch die Studie geführt. Das Ex-
periment besteht dabei zunächst aus einem Fragenteil, der dem ersten Fragebogen
entspricht. Daraufhin wird eine kurze Infomeldung angezeigt, die den Probanden auf
die Spezifikation im Anschluss, sowie das Zeitlimit hinweist. Der Ablauf während der
Bearbeitung erfolgt analog zu der ausgedruckten Spezifikation. Ist die Zeit abgelau-
fen, wird der PDF-Stimulus mit der Spezifikation vom Versuchsbetreuer abgebrochen
und der zweite Fragenteil beginnt.
Bevor jeweils mit der zweiten Hälfte begonnen wird, hat der Versuchsteilnehmer die
Möglichkeit eine kurze Pause einzulegen. Anschließend erfolgt der Durchlauf mit der
Spezifikation der jeweils anderen Darstellungsform. Änderungen im Ablauf, abhängig
davon, ob die Spezifikation dem Teilnehmer als erstes oder zweites zur Verfügung
gestellt wird, gibt es dabei nicht.
Abbildung 5.2: Untersuchungsumgebung bei ausgedruckten Spezifikationen
28
6 Durchführung der Studie
Die Studie konnte weitestgehend entsprechend des vorgesehen Ablaufs durchge-
führt werden. Die einzigen notwendigen Abweichungen von der ursprünglichen
Planung sind hier festgehalten.
6.1 Beobachtungen während der Studie
Während der konnte beobachtet werden, dass die Teilnehmer unterschiedlich mit
dem Dokument umgegangen sind. Einige Probanden haben die Spezifikation kom-
plett von vorne nach hinten durchgelesen, wohingegen andere sich jeweils
bestimmte Seiten an den Rand gelegt haben. Zu diesen Abschnitten gehörten die
Teile „Erläuterung des zu lösenden Problems“, „Wünsche und Prioritäten des Kun-
den“, sowie das Use Case-Diagramm.
Zudem konnte festgestellt werden, dass aufgrund des Zeitlimits von 20 Minuten nicht
alle Teilnehmer ihre Aufgabe haben beenden können. Besonders die Entwickler
standen unter starkem Zeitdruck. Diese Zeitknappheit haben die Versuchspersonen
jedoch unterschiedlich gehandhabt. Ein Teil der Probanden hat sich die Zeit eingeteilt
und alle Aufgabenteile gleichermaßen bearbeitet, wobei der andere Teil manche As-
pekte komplett weggelassen, die restlichen dafür vollständig und ausführlicher
bearbeitet hat.
6.2 Änderungen im Ablauf
Die folgenden Änderungen im Ablauf der Studie mussten aufgrund von Beobachtun-
gen während der Studie durchgeführt werden. Die daraus resultierenden
Konsequenzen für die Metriken und die Auswertung sind in Abschnitt 7.3 erläutert.
Änderung 1: Setzen eines Zeitlimits
Zunächst war den Teilnehmern kein Zeitlimit für die Bearbeitung der Aufgabe und
das Lesen der Spezifikationen gesetzt. Das heißt, es lag in ihrem Ermessen zu be-
urteilen, wann sie fertig sind. Der erste Teilnehmer hat infolgedessen jedoch zwei
Stunden für den gesamten Durchlauf der Studie benötigt. Dies umfasst ca. 1:10h für
das Beantworten der beiden Fragebögen und das Lesen und Bearbeiten der ersten
Spezifikation mit den Eye Tracking Glasses, sowie nochmals ca. 50 Minuten für den
gleichen Ablauf bei der zweiten Spezifikation mit dem externen Eye Tracker. Der
Zeitunterschied zwischen den beiden Abläufen ergibt sich daraus, dass die Kalibrie-
rung der Brille länger dauert als für den externen Eye Tracker und es außerdem zu
Verbindungsproblemen bei der Eye Tracking Brille kam, weshalb das Aufnahmepro-
gramm mehrfach neu gestartet werden musste. Der Proband wurde dadurch in
seiner Aufgabe nicht beeinträchtigt.
Da bei einer so langen Dauer allerdings Faktoren wie Müdigkeit, mangelndes Durch-
haltevermögen und Konzentrationsabnahme die Ergebnisse vermehrt
beeinträchtigen und die Bereitschaft von Studenten an Studien teilzunehmen sinkt je
Länger diese dauert, wurde daraufhin für alle Teilnehmer mit der ID 002 oder höher
ein Zeitlimit von 20min pro Spezifikation gesetzt. Das heißt, von dem Zeitpunkt an
hatten die Probanden genau 20 Minuten Zeit um die Spezifikation zu lesen und ihre
rollenspezifische Aufgabe zu bearbeiten.
6 Durchführung der Studie
29
Änderung 2: Wiederholung von Durchläufen
Des Weiteren wurden die folgenden zwei Durchläufe aus Tabelle 7.1 nochmals wie-
derholt und aus der Menge an auszuwertenden Daten entfernt, da die
Vergleichsmöglichkeit der Daten bzw. deren Validität gefährdet war.
Teilnehmer Spezifikationen Rolle
Set_a Set_d Translate_a Translate_d
001 2. 1. UI-Designer
009 2. 1. UI-Designer
Tabelle 7.1: Wiederholung von Durchläufen
Zum einen handelt es sich dabei um den Teilnehmer mit der ID 001, da diesem wie
zuvor beschrieben noch kein Zeitlimit gesetzt war und die Rahmenbedingungen der
Studie sich für ihn somit von den anderen Teilnehmern unterschieden haben. Da die
aufgenommenen Daten aus diesem Durchlauf daher nicht mit den anderen Teilneh-
mern vergleichbar sind, wurden die Einstellungen für Teilnehmer 001 nochmals mit
einem weiteren Probanden wiederholt. Das heißt, die Zuordnungstabelle wurde um
die Zeile mit der ID 009 ergänzt. Die Spezifikationen, deren Reihenfolge und Darstel-
lung entsprechen dabei genau denen von Teilnehmer 001.
Des Weiteren wurde anschließend bei dem Durchlauf des Teilnehmers mit der ID
009 festgestellt, dass dieser die Aufgabe nicht richtig verstanden hat, da er sich wäh-
rend den 20 Minuten lediglich Notizen zu seiner Aufgabe gemacht, diese jedoch nicht
vollständig bearbeitet hat. Zudem hat er im Nachhinein reflektiert, dass er sich immer
wieder daran erinnern musste, was seine Rolle ist und er die Spezifikation meist we-
niger als Informationsquelle für seine Aufgabe, sondern mehr aus Interesse gelesen
hat. Darüber hinaus, handelte es sich bei dem Probanden um einen Brillenträger und
am Bildschirm wäre das Lesen für ihn zu anstrengend geworden, weshalb er dafür
seine Brille aufbehalten hat. Das hatte jedoch zur Folge, dass der aufgenommene
Blickpunkt des Eye Trackers durch Reflexionen der Brille oder wenn der Brillenrah-
men die Kamera verdeckt, sehr instabil war und viele Sprünge beinhaltete. Deshalb
wurde der Durchgang ein weiteres Mal wiederholt. Der entsprechende Teilnehmer
trägt die ID 010. Beide Teilnehmer wurden in die Zuordnungstabelle eingefügt.
30
7 Analyse und Interpretation
In diesem Kapitel folgt eine formale Analyse der Daten. Diese umfasst die Beschrei-
bung sämtlicher Maßnahmen, die nötigt sind, um die Rohdaten der Messung in die
gewünschten Metriken zu überführen, deren Prüfung auf Validität, sowie die formalen
Tests der in Kapitel 4.2 aufgestellten Hypothesen.
7.1 Verarbeitung der Rohdaten
Bevor das Ergebnis der Metriken analysiert werden konnte, mussten die Aufnahme-
daten zunächst in die gewünschte auswertbare Form gebracht werden. Dazu wurden
die Ergebnisse der Fragebögen in Exceltabellen übertragen und die Anzahl an rich-
tigen Antworten bei den inhaltlichen Fragen, die Anzahl an Stimmen für die jeweiligen
Darstellungsformen und die durchschnittlichen Bewertungen der Relevanz der Spe-
zifikationsabschnitte abhängig von der Rolle des Lesers bestimmt.
Um die Lesezeiten für einzelne Abschnitte zu erhalten, wurden für die Daten des
externen EyeTracker AOIs auf den einzelnen Abschnitte definiert. Dazu wurden über
die jeweiligen Absätze, einschließlich der zugehörigen Überschrift und einem zusätz-
lichen Rand zum Ausgleich eventueller Ungenauigkeiten des Eye Trackers ein
rechteckiger AOI gezogen. Anschließend konnte für jeden Teilnehmer die entspre-
chende Lesedauer abgelesen und in die passende Tabelle übertragen werden.
Für die Auswertung der Daten der Eye Tracking Glasses musste noch ein zusätzli-
cher Zwischenschritt erfolgen, da die Aufnahme zunächst nur als Video vorlag, auf
dem jeweils der Blickpunkt des Teilnehmers abgetragen ist. Das Zusammenfügen
von Blickpunkt und Bild der Kamera musste jedoch manuell erfolgen, indem jeder
Blickpunkt einem Punkt auf dem Referenzbild zugewiesen wurde. Das Referenzbild
beinhaltet für diese Studie eine Auflistung aller Teilkapitel, die in den beiden verwen-
deten Spezifikationen enthalten sind. Für jede Fixation der Probanden wurde
ausgewählt zu welchem der Abschnitte auf dem Bild es gehört. Bei Zeitpunkten, zu
denen der Leser seinen Blick nicht auf die Spezifikation gerichtet hat, wurde auf einen
Bereich des Referenzbilds geklickt, der zu keinem Teil der Spezifikation gehört. An-
schließend wurden auf den farbig markierten Abschnitten der Referenz ebenfalls
AOIs definiert, sodass die entsprechenden Lesezeiten abgelesen und festgehalten
werden konnten.
7.2 Validierung der Messdaten
Nachdem sämtliche Daten in auswertbarer Form vorlagen, konnte die Validität der
Messdaten geprüft werden. Dazu wurde zunächst kontrolliert, ob alle Fragebögen
korrekt ausgefüllt waren. Beispielsweise würde es darauf hinweisen, dass ein Teil-
nehmer den Fragebogen nicht richtig verstanden hat oder nicht ernsthaft genug an
der Studie teilgenommen hat, wenn er bei den inhaltlichen Fragen mehrere Antwort-
möglichkeiten angekreuzt hätte, obwohl darauf hingewiesen wurde, dass jeweils nur
eine Antwort korrekt ist. Bei den erhobenen Daten konnten solche Vorkommnisse
jedoch nicht beobachtet werden. Anschließend wurden die Daten auf Ausreißer ge-
prüft. Dies erfolgte über eine graphische Darstellung der Stichprobendaten, um sich
einen Überblick über deren Verlauf verschaffen zu können. Anschließend wurde fest-
gestellt, ob einzelne Datenpunkte sehr weit von dem Rest entfernt lagen. Ein Beispiel
einer solchen graphischen Darstellung zeigt Abbildung 8.1. Darin ist der Verlauf der
Lesezeiten der Spezifikation „Set“ in der Darstellung am Bildschirm gezeigt. Auf der
x-Achse sind die einzelnen Kapitel der Spezifikation aufgetragen. Die beiden ersten
7 Analyse und Interpretation
31
Intervalle tragen keine Beschriftung, da es sich dabei um das Deckblatt und das In-
haltsverzeichnis handelt. Auf der y-Achse sind die dazugehörigen Lesezeiten in
Millisekunden abgebildet. In dem Diagramm kann man sehr gut erkennen, dass sich
der Verlauf der Teilnehmerdaten stark ähnelt. Das weist auf einen Zusammenhang
der Daten hin, da es dafür spricht, dass es sich nicht um zufällige Beobachtungen
handelt.
Abbildung 8.1: Übersicht der Lesezeiten der Spezifikation Set_d
7.3 Formale Prüfung der Hypothesen auf Signifikanz
Da die Validität der Daten sichergestellt wurde, konnten im Anschluss die in Kapitel
4.2 aufgestellten Hypothesen, die zur Beantwortung der betrachteten Fragen dienen
sollen, auf Richtigkeit geprüft werden. Dazu wurden die jeweilig definierten Aussagen
mittels statistischer Tests auf Signifikanz untersucht. Die Betrachtungen wurden da-
bei nach der zugehörigen Fragestellung gruppiert.
7.3.1 F1: Darstellungsform
Zur Beantwortung der Frage, ob die ausgedruckte oder digitale Darstellung geeigne-
ter ist, wurden drei Zwischenmetriken verwendet. Zum einen wurden die Vorliebe des
Lesers und die Wiedergabefähigkeit abhängig von dem Darstellungsmedium Papier
oder Bildschirm bestimmt. Als weiteres Kriterium wurde die Lesegeschwindigkeit be-
trachtet.
M1: Präferenz des Lesers
Um herauszufinden, ob ausgedruckte oder am Bildschirm angezeigte Spezifikatio-
nen vom Nutzer bevorzugt werden, wurde im ersten Fragebogen nach der
favorisierten Darstellungsform gefragt. Die dazu aufgestellte Hypothese HA2_1 wird
über den Vergleich der Häufigkeit der beiden möglichen Antworten geprüft. Dazu
wurden die Tafeln der F-Verteilung verwendet (Sachs93).
Die dafür betrachteten Merkmale der Grundgesamtheit sind:
a1: Anteil an Personen, die die ausgedruckte Darstellung bevorzugen
d1: Anteil an Personen, die die digitale Darstellung bevorzugen
7 Analyse und Interpretation
32
Die entsprechenden Metriken für die Stichprobe werden wie folgt symbolisiert:
xa1: Anzahl an Personen, die die ausgedruckte Darstellung bevorzugen
xd1: Anzahl an Personen, die die digitale Darstellung bevorzugen
Entgegen der Arbeitshypothese HA2_1 wird zur Überprüfung die Nullhypothese formu-
liert.
H02_1: a1 ≤ d1, das heißt, es bevorzugen mindestens so viele Personen die digitale
Darstellung, wie die ausgedruckte Form
Die ermittelten Häufigkeiten der Stichprobe sind xa1 = 7 und xd1 = 4. Um herauszufin-
den, ob die Nullhypothese auf dem 5%-Niveau abgelehnt werden kann, wird der
entsprechende �̂�-Wert berechnet und mit dem Grenzwert aus der zugehörigen Ta-
belle (Sachs93) verglichen.
�̂� ≥ 𝐹𝑣1;𝑣2;0,05
wobei �̂� = xa1
xd1+1 und 𝑣1 = 2(xd1 + 1), 𝑣2 = 2 ∗ xa1
𝑣1 = 2(4 + 1) = 10, 𝑣2 = 2 ∗ 7 = 14
�̂� = 7
4 + 1= 1,4 ≱ 𝐹10;14;0,05 = 2,6
Da der �̂�-Wert der Stichprobe nicht mindestens so groß wie der 𝐹𝑣1;𝑣2;0,05-Wert der
Tabelle ist, muss die Nullhypothese beibehalten werden. Das heißt, die Anzahl an
Personen, die die ausgedruckte Darstellung bevorzugen ist nicht signifikant höher
als die Anzahl an Personen, die die Darstellung am Bildschirm präferieren.
Bei den Werten ist jedoch aufgefallen, dass insbesondere die erfahrenen Entwickler
fast ausschließlich für die digitale Variante gestimmt haben. Den Kommentaren dazu
nach zu urteilen liegt das daran, dass sie größtenteils bereits Erfahrung mit Tools
zum Anzeigen von Spezifikationen haben und aufgrund dessen Funktionalität die
Variante am Bildschirm gewählt haben. Daher lässt sich vermuten, dass die ausge-
druckte Variante beim Vergleich mit lediglich am Bildschirm angezeigten PDF-
Spezifikationen ohne erweitere Funktionalität, bevorzugt wird. Diese Vermutung lässt
sich jedoch mit den gegebenen Daten nicht überprüfen.
M2: Wiedergabefähigkeit
Für die Wiedergabefähigkeit wird analog vorgegangen, da der gleiche statistische
Test verwendet werden kann. Dazu wird die Anzahl an richtigen Antworten auf die
gestellten inhaltlichen Fragen für die ausgedruckten und am Bildschirm gezeigten
Spezifikationen miteinander verglichen. Das heißt, es handelt sich erneut um ein Ver-
gleich zweier Häufigkeiten und es werden die Tafeln der F-Verteilung zur
Überprüfung der Arbeitshypothese angewendet (Sachs93).
Die für diese Fragestellung betrachteten Merkmale der Grundgesamtheit sind:
a2: Anteil an richtigen Antworten bei ausgedruckten Spezifikationen
d2: Anteil an richtigen Antworten bei Spezifikationen am Bildschirm
Die entsprechenden Metriken für die Stichprobe werden wie folgt symbolisiert.
xa2: Anzahl an richtigen Antworten der sechs gestellten inhaltlichen Fragen der Personen der Stichprobe bei ausgedruckten Spezifikationen
xd2: Anzahl an richtigen Antworten der sechs gestellten inhaltlichen Fragen der Personen der Stichprobe bei am Bildschirm gezeigten Spezifikationen
7 Analyse und Interpretation
33
Der Arbeitshypothese HA2_2 entgegen wird zur Überprüfung die Nullhypothese formu-
liert.
H02_1: a2 ≠ d2, das heißt, es gibt einen Unterschied in der Wiedergabefähigkeit
abhängig von der Darstellungsart (ausgedruckt oder am Bildschirm)
Die gemessenen Häufigkeiten an richtigen Antworten sind xa1 = 37 und xd2 = 40. Um
zu testen, ob die Nullhypothese auf dem 5%-Niveau abgelehnt werden kann, wird
der entsprechende �̂�-Wert berechnet und mit dem Grenzwert aus der zugehörigen
Tabelle (Sachs93) verglichen.
�̂� ≥ 𝐹𝑣1;𝑣2;0,05
wobei �̂� = xa2
xd2+1 und 𝑣1 = 2(xd2 + 1), 𝑣2 = 2 ∗ xa2
𝑣1 = 2(37 + 1) = 76, 𝑣2 = 2 ∗ 40 = 80
�̂� = 40
37 + 1= 1,05 ≱ 𝐹76;80;0,05 = 1,53
Da der �̂�-Wert der Stichprobe nicht mindestens so groß wie der 𝐹𝑣1;𝑣2;0,05-Wert der
Tabelle ist, muss die Nullhypothese beibehalten werden. Das heißt, es gibt keinen
signifikanten Unterschied zwischen der Wiedergabefähigkeit der Teilnehmer abhän-
gig vom Darstellungsmedium. Auch im Fall einer einseitigen Fragestellung (a2 < d2)
würde der ermittelte �̂�-Wert der Stichprobe nicht für ein signifikantes Ergebnis auf
dem 5%-Niveau ausreichen.
M4: Geschwindigkeit
Um die Arbeitshypothese HA2_3 testen zu können, muss zunächst einmal die Lese-
geschwindigkeit der einzelnen Teilnehmer berechnet werden. Dies wird nach der
folgenden Formel berechnet.
Geschwindigkeit = Summe der Länge der Spezifikationsabschnitte
Summe der Lesezeiten der Spezifikationsabschnitte [
𝑐𝑚
𝑠]
Die errechneten Geschwindigkeiten können Tabelle 8.1 entnommen werden. Die
Werte sind jeweils auf drei Nachkommastellen gerundet. Da die Länge der Spezifi-
kation aufgrund des Zeitlimits höchstwahrscheinlich einen Einfluss auf die
Lesegeschwindigkeit hat, wird an dieser Stelle das Blocking-Prinzip angewandt. Da
die Translate-Spezifikation acht Seiten mehr umfasst als die Set-Spezifikation, wer-
den die Teilnehmer bei ihr vermutlich mit einer anderen Geschwindigkeit gelesen
haben. Um die resultierende erhöhte Varianz innerhalb der Messgruppen auszuglei-
chen, werden die Mittelwerte der Geschwindigkeiten daher getrennt für die beiden
Spezifikationen verglichen. Zum Test der Arbeitshypothese wird dazu ein Verfahren
von McDonald und Thompson verwendet, das auf den sogenannten Rangsummen
basiert. Dabei wird vorausgesetzt, dass die Daten den gleichen Verteilungstyp und
unter der Nullhypothese gleiche Parameter aufweisen (Sachs93). Das ist in diesem
Fall gegeben, da die Messwerte von den gleichen Teilnehmern unter gleichen Ver-
suchsbedingungen aufgenommen wurden. Die Daten von Teilnehmer 011 wurden
an dieser Stelle nicht mit ausgewertet, da dort nur Daten für die Spezifikation am
Bildschirm vorliegen und der Test nur für gleich große Messgruppen funktioniert
(Sachs93).
Zunächst wird wieder die Nullhypothese definiert. Diese ist in diesem Fall in zwei
Nullhypothesen aufgeteilt, da der Test je einmal für die beiden Spezifikationen durch-
geführt wird.
7 Analyse und Interpretation
34
H02_31: Die am Bildschirm gelesenen Set-Spezifikationen werden genauso schnell oder langsamer gelesen als die ausgedruckten Spezifikationen.
H02_31: Die am Bildschirm gelesenen Translate-Spezifikationen werden genauso schnell oder langsamer gelesen als die ausgedruckten Spezifikationen.
Anschließend wird den Messwerten ein Rang zugewiesen. Der kleinste Wert be-
kommt dabei den Rang 1, der zweitkleinste den Rang 2 und so wird für die gesamten
Daten verfahren. Danach wird die Rangsumme berechnet. Beide Werte lassen sich
der Tabelle 8.1 entnehmen. Die Ränge entsprechen den eingeklammerten Zahlen
hinter den Geschwindigkeiten. Die Rangsumme befindet sich in der untersten Zeile.
Set-Spezifikation Translate-Spezifikation
ausgedruckt am Bildschirm ausgedruckt am Bildschirm
1,070 (9) 0,707 (1) 0,518 (4) 0,908 (10)
0,797 (2) 0,920 (5) 0,614 (5) 0,493 (3)
0,992 (6) 0,998 (8) 0,730 (6) 0,458 (1)
0,863 (4) 0,987 (7) 0,490 (2) 0,821 (7) 0,827 (3) 1,305 (10) 0,843 (9) 0,842 (8)
∑ 24 31 26 29
Tabelle 8.1: Geschwindigkeiten und Rangsummenvergleich der Spezifikationen
Der entsprechenden Tabelle aus der Literatur (Sachs93) lässt sich entnehmen, dass
bei fünf Messwerten und zwei Gruppen, die Rangsumme 37 betragen müsste, damit
die jeweilige Nullhypothese auf dem 5%-Niveau abgelehnt werden könnte. Die Rang-
summen der Stichprobe erreichen diesen Grenzwert nicht, daher muss die
Nullhypothese beibehalten werden. Demnach ist die Lesegeschwindigkeit bei am
Bildschirm gelesenen Spezifikation in dieser Studie nicht signifikant höher als bei
ausgedruckten Versionen.
7.3.2 F2: Auswahl der Abschnitte
Um herauszufinden welche Abschnitte besonders wichtig bzw. unwichtig für die je-
weiligen Rollen sind und somit die wichtigen Abschnitte für die Rollen auswählen zu
können, werden die beiden Metriken Bewertung und Lesezeiten betrachtet.
M3: Priorisierung des Lesers
Für diese Metrik wurde der Chi-Quadrat-Test verwendet, mit dem es möglich ist die
Vereinbarkeit mehrerer Zählungen zu überprüfen (Sachs93). Das heißt, es wird ge-
testet, ob es einen signifikanten Unterschied zwischen den Bewertungen für einen
Abschnitt bei einer Rolle gibt. Dazu wird zunächst die Nullhypothese aufgestellt, die
für jeden Abschnitt bei jeder Rolle zu überprüfen ist.
H03_1: Alle Bewertungsschritte werden gleich häufig gewählt.
7 Analyse und Interpretation
35
Mithilfe der 𝜒2-Prüfgröße lassen sich die Häufigkeiten der jeweiligen Bewertung von
„Sehr wichtig“ bis „Unwichtig“ miteinander vergleichen (Sachs93). Die Nullhypothese
wird dabei auf dem 5%-Niveau abgelehnt, sobald folgende Bedingung erfüllt ist.
𝜒2̂ = ∑ (𝑥𝑖 − �̅�)24
𝑖=1
�̅� > 𝜒2
𝑣;0,05
mit �̅�: der Mittelwert der Häufigkeiten der Bewertungsschritte,
v: Anzahl an Bewertungsschritten - 1 = 4 – 1 = 3
und 𝑥𝑖: Häufigkeit der i-ten Bewertung
Der zu überschreitende Grenzwert 𝜒23;0,05, der für alle Abschnitte und Rollen gleich
ist, da es in jedem Fall vier Bewertungsschritte gab, ist dabei 7,815 (Sachs93). Bei
der Errechnung der 𝜒2-Größe ergibt sich, dass die Nullhypothese nur abgelehnt wer-
den kann, wenn alle Teilnehmer einer Rolle die gleiche Bewertung abgegeben
haben. Die einzige Ausnahme bilden die Entwickler, da man dort nicht nur jeweils
zwei Teilnehmer mit jeweils zwei Bewertungen zur Verfügung hat, sondern vier Teil-
nehmer mit insgesamt acht Bewertungen. Der erfahrene Entwickler mit der
Teilnehmer-ID 011 blieb an dieser Stelle erneut unberücksichtigt, damit gleich viele
Messwerte für beide Spezifikationen betrachtet werden und so eventuelle Projektab-
hängigkeiten nicht ins Gewicht fallen. Außerdem können die Ergebnisse dieser
Metrik besser mit den Lesegeschwindigkeiten verglichen werden, da so die gleichen
Daten betrachtet wurden.
Außer für die Teilnehmergruppe der Entwickler ist daher lediglich zu prüfen, für wel-
che Abschnitte identische Bewertungen einer Rolle vorliegen. Das ist für die
nachfolgenden Abschnitte und Rollen der Fall.
UI-Designer: Qualitätsziele des Projekts (wichtig), MockUps (sehr wichtig)
Softwarearchitekt: Erläuterung des zu lösenden Problems (sehr wichtig)
Tester: Use-Case Beschreibungen (sehr wichtig), Inkrementelle Arbeit (un-
wichtig)
Für diese Rollen und Abschnitte wird die Nullhypothese auf dem 5%-Niveau abge-
lehnt. Das heißt, die Bewertungseinschätzungen sind bei diesen Artefakten
statistisch signifikant.
Für die Rolle des Entwicklers wurden die entsprechenden 𝜒2-Werte nicht berechnet,
da sie in dem Fall nur ausgesagt hätten, dass es signifikante Unterschiede zwischen
den Häufigkeiten gibt, jedoch nicht, welche Bewertung dominiert. Daher wurden die
Bewertungen in diesem Fall anders verglichen. Um aussagen zu können, ob ein Ab-
schnitt wichtig oder unwichtig bewertet worden ist, wurden die Anzahl an „Sehr
wichtig“- und „Wichtig“-Bewertungen, sowie an „Weniger wichtig“- und „Unwichtig“
Bewertungen jeweils zusammengezählt und mittels dem Test für den Vergleich
zweier Häufigkeiten verglichen. Das heißt, es wurden erneut die Tafeln der F-Vertei-
lung verwendet. Die resultierende Vereinfachung der Fragestellung von vier auf zwei
mögliche Antworten, stellt hierbei keinen Verlust dar, da bei der Auswertung sowieso
eindeutig über die Wichtigkeit der Abschnitte entschieden werden muss. Diese Ver-
gleichsvariante konnte bei den anderen drei Rollen nicht verwendet werden, da dort
die Teilnehmeranzahl pro Rolle nicht ausreicht, um signifikante Ergebnisse zu erhal-
ten.
Die entsprechende Nullhypothese für die Entwicklerrolle hierbei lautet somit wie folgt.
H03_2: Der Abschnitt wird gleich oft mit „Sehr wichtig“ oder „Unwichtig“ bewertet, wie mit „Weniger wichtig“ und „Unwichtig“.
7 Analyse und Interpretation
36
Für den Test wird außerdem folgende Notation verwendet.
x1: größere Anzahl der „(Sehr) wichtig“- bzw. „Weniger wichtig“- und „Unwichtig“-Bewertungen
x2: kleinere Anzahl der „(Sehr) wichtig“- bzw. „Weniger wichtig“- und „Unwichtig“-Bewertungen
Mithilfe dieser Größen wird anschließend mit den entsprechenden Formeln
(Sachs93) der �̂�-Wert berechnet und mit den zugehörigen Tabellen verglichen, um
festzustellen, ob das gewünschte Signifikanzniveau erreicht werden kann.
�̂� = x1
x2+1 und 𝑣1 = 2(x2 + 1), 𝑣2 = 2 ∗ x1
Dabei konnte man feststellen, dass für die Rolle Entwickler die folgenden Abschnitte
und jeweils angegebene Bewertung die Nullhypothese auf dem 5%-Niveau abge-
lehnt werden konnte.
Erläuterungen des zu lösenden Problems (Wichtig)
Wünsche und Prioritäten des Kunden (Wichtig)
Maßnahmen zur Anforderungsanalyse (Unwichtig)
Einschränkungen und Vorgaben (Wichtig)
Use Case-Beschreibungen (Wichtig)
Technische Anforderungen (Wichtig)
Inkrementelle Arbeit (Wichtig)
MockUps (Wichtig)
Glossar (Unwichtig)
Bei dieser Untersuchung handelte es sich um eine zweiseitige Fragestellung. Da die
zu erreichenden �̂�-Werte für die einseitige Fragestellung unter denen der zweiseiti-
gen liegen, kann somit für jedes Ergebnis auch signifikant festgestellt werden, dass
die Werte nicht nur ungleich, sondern sogar echt größer sind.
M5: Intensität des Lesens einzelner Abschnitte
Die gemessenen Lesezeiten, die Rückschlüsse auf die Intensität des Lesens der ein-
zelnen Abschnitte geben, dienen lediglich als Vergleichsmöglichkeit für die
Bewertungen der Teilnehmer. Wenn ein Teilnehmer einen Abschnitt beispielsweise
nur überflogen hat, diesen jedoch als sehr wichtig für seine Rolle bewertet hat, weist
das auf eine geringe Aussagekraft der Bewertung hin.
Mit dieser Metrik kann darüber hinaus festgestellt werden, ob als unwichtig bewertete
Abschnitte auch weniger intensiv gelesen werden. Es kann so also untersucht wer-
den, ob es einen Zusammenhang zwischen Bewertung und Lesezeit gibt.
Über die einzelnen Leseintensitäten alleine kann jedoch keine signifikante Aussage
getroffen werden, ob diese für ein sehr intensives oder weniger intensives Lesen
stehen, da es keinen konkreten Vergleichswert gibt. Das hat den Grund, dass das
Lesen von Spezifikationen einen sehr speziellen Anwendungsfall darstellt, da zum
einen Abbildungen, Tabellen und Aufzählungen enthalten sind und zum anderen die
Absätze nicht nur zur reinen Informationsaufnahme gelesen werden, sondern neben-
bei Aufgaben bearbeitet werden. Die gemessenen Daten der Stichprobe können
jedoch als Referenz genommen werden, um für einzelne Intensitäten beurteilen zu
können, ob diese vergleichsweise hoch oder niedrig sind. Damit hat man zwar eine
Abhängigkeit von der Messausprägung, besitzt jedoch Vergleichswerte, die unter
7 Analyse und Interpretation
37
den gleichen Umständen, also auch beim Lesen derselben Spezifikationen aufge-
nommen wurden.
Um die Intensität des Lesens der einzelnen Abschnitte beurteilen zu können, müssen
die gemessenen Lesezeiten zunächst mit deren Länge relativiert werden. Dies ist
notwendig, da ein kurzer Abschnitt bei gleicher Wichtigkeit und Komplexität stets ten-
denziell kürzere Lesezeiten erhalten wird als ein längerer Abschnitt. Dazu wird
folgende Formel verwendet.
Leseintensität = Lesedauer des Abschnitts
Länge des Abschnitts [
𝑠
𝑐𝑚]
Um diese Daten anschließend mit den Bewertungen der Teilnehmer vergleichen zu
können, werden sie anschließend auf die gleiche Skala von 1 (Sehr wichtig) bis 4
(Unwichtig) transformiert. Hierbei werden große Werte jedoch auf einen kleinen Wert
abgebildet, da eine hohe Leseintensität auf eine hohe Wichtigkeit des Abschnitts hin-
deutet und anders herum. Dies erfolgt mit der folgenden Formel.
𝑖𝑠(𝑥) = 5 − (𝑃(𝑥)
|𝑋|∗ 3 + 1)
wobei 𝑖𝑠(𝑥): skalierte Intensität der Leseintensität x in s
cm
𝑃(𝑥): die Position von x in der aufsteigend sortierten Liste aller
Leseintensitäten
|𝑋|: die Anzahl an Elementen in der Liste aller Leseintensitäten
Diese Transformierung kehrt Beziehungen wie „größer als“, „gleich“ oder „kleiner als“
lediglich genau um. Absolute Aussagen wie „doppelt „doppelt so groß wie“ oder
„kleinster Abstand zum nächsten Wert“ bleiben jedoch nicht erhalten (Wohlin00).
Da sich Daten, insbesondere bei der hier bestehenden Stichprobengröße, nicht so
einfach auf Gleichheit testen lassen, wird jeweils verglichen, ob der Unterschied zwi-
schen den Mittelwerten der Bewertungen für die einzelnen Abschnitte und Rollen
maximal um 1,0 abweicht. Andernfalls, wird dies als Hinweis erachtet, dass Bewer-
tung und Leseintensität nicht zueinander passen und die konkreten Datenpunkte
näher betrachtet werden müssen, um evtl. Gründe für die Abweichung finden zu kön-
nen. Nicht beachtet werden dabei Abweichungen bei den Abschnitten „MockUps“,
sowie „Abnahmetestfälle“, da diese wie in Abschnitt 5.1 beschrieben aus den Spezi-
fikationen entfernt wurden und daher natürlich nicht intensiv gelesen werden
konnten.
Bei der derartigen Analyse der Daten konnten folgende Abweichungen zwischen Be-
wertung und skalierter Leseintensität gefunden werden. Der erste Wert in den
Klammern gibt dabei die durchschnittliche Bewertung, der zweite die transformierte
Leseintensität an.
UI-Designer: Domänenbeschreibung (2,0 – 3,08), Use Case-Beschreibungen
(1,25 – 2,58), Probleme und Risiken (2,75 – 3,94), Inkrementelle Arbeit (2,5
– 3,87)
Softwarearchitekt: Qualitätsziele des Projekts (1,75 – 3,18), Qualitätsprioritä-
ten des Kunden (1,75 – 3,24), Wie Qualitätsziele erreicht werden sollen (1,75
– 2,77)
Tester: Domänenbeschreibung (2,5 – 1,38), Einschränkungen und Vorgaben
(2,5 – 1,28), Use Case-Beschreibungen (1,0 – 2,29), Mögliche Abstriche
(3,25 – 2,2)
7 Analyse und Interpretation
38
Entwickler: Use Case-Beschreibungen (1,38 – 2,64), Inkrementelle Arbeit
(2,13 – 3,35)
Die vergleichsweise geringen Abweichungen beim Abschnitt „Domänenbeschreibun-
gen“ können dadurch erklärt werden, dass dieser Abschnitt nur 3,1cm bzw. 2,2cm
umfasst und die Messung des Eye Trackers bei so kurzen Abschnitten relativ unge-
nau ist. Außerdem ist die Wahrscheinlichkeit, dass ein „leerer Blick“, also ein
Anschauen eines Punktes ohne Verarbeitung der aufgenommenen visuellen Infor-
mationen auf so einen kurzen Abschnitt trifft, relativ gering. Die Abweichungen
werden daher nicht als maßgeblich erachtet. Ebenso verhält es sich bei den Ab-
schnitten „Einschränkungen und Vorgaben“, „Mögliche Abstriche“ und „Inkrementelle
Arbeit“.
Die Unterschiede bei dem Abschnitt „Use Case-Beschreibungen“ können dadurch
erklärt werden, dass sich dieser über mehrere Seiten erstreckt und viele Teilnehmer
zurückgemeldet haben, allein aus Zeitgründen nicht alle Use Cases gelesen zu ha-
ben. Daher können einzelne Seiten jeweils schon intensiv gelesen worden sein,
verteilt auf den gesamten Abschnitt erscheint die gemessene Leseintensität dennoch
gering.
Die letzte, ebenfalls vergleichsweise geringe Abweichung beim Abschnitt „Probleme
und Risiken“ könnten zum einen daran liegen, dass dieser Abschnitt Stichpunkte und
ein Diagramm enthielt, also Daten, die schneller erfassbar sind. Allerdings wurde bei
diesen Daten tatsächlich festgestellt, dass ein Teilnehmer diesen Abschnitten mit
„Weniger wichtig“ bewertet hat, ohne ihn gelesen zu haben. Diese Bewertung ist da-
her als wenig aussagekräftig zu betrachten. Entfernt man die Bewertung und
Leseintensität dieses Teilnehmers und berechnet die Werte erneut, ergibt sich eine
Differenz von unter eins und wird daher als nicht maßgeblich betrachtet.
7.3.3 F3: Unterschiede zwischen den Rollen
Bei dieser Fragestellung wird anhand der Metriken Bewertung (M5) und Leseinten-
sität (M7) untersucht, ob es signifikante Unterschiede zwischen den Rollen gibt.
Damit wird festgestellt, ob eine Definition von unterschiedlichen Sichten auf Anforde-
rungsdokumente für die betrachteten Rollen überhaupt Sinn ergibt.
M3: Priorisierung des Lesers
Die Bewertungen der Teilnehmer wurden mit der sogenannten Welch-Statistik zum
Vergleich mehrerer Mittelwerte auf Unterschiede untersucht. Die Vereinbarkeit mit
der vorausgesetzten Normalverteilung wurde zuvor mit der Mittelwert-Kontrollkarte
(Sachs93) geprüft.
Die Nullhypothese in diesem Fall ist:
H04_1: Die Mittelwerte der Bewertungen sind alle gleich.
Anschließend prüft man mithilfe des �̂�-Wertes der Welch-Statistik, ob dieser den not-
wendigen 𝐹𝑣1;𝑣2;0,05 (Sachs93) übersteigt, wobei in diesem Fall v1 = 3 und v2 liegt je
nach Abschnitt zwischen sechs und acht. Dabei konnte festgestellt werden, dass die
Nullhypothese für folgende Abschnitte auf dem 5%-Niveau abgelehnt werden kann.
Schnittstellen und angrenzende Systeme
Inkrementelle Arbeit
MockUps
Die geringe Anzahl an signifikanten Unterschieden ist dabei jedoch auf die Größe
der Stichprobe zurückzuführen.
39
8 Reflektion zu Studien mit Eye Tracking
Nachdem die Planung, Vorbereitung und Durchführung der Studie, sowie die Ana-
lyse der Ergebnisdaten abgeschlossen ist, kann nun die jeweilige Arbeit mit dem Eye
Tracker reflektiert werden. Diese Reflektion umfasst, an welchen Stellen die Software
des Eye Trackers Vorteile bietet und welche Teile sehr viel Arbeit umfassen.
8.1 Vorbereitung der Aufnahmen
Bevor mit den Eye Tracking Aufnahmen begonnen werden kann, müssen je nach
Gerät bestimmte Vorbereitungen vorgenommen werden. Diese sind unterschiedlich
umfangreich und aufwändig. Generell gilt bei den Geräten und der Software von SMI:
Je mehr Arbeit man bei der Vorbereitung der Experimente hat, desto weniger Auf-
wand hat man bei der Analyse der Daten.
8.1.1 Eye Tracking Glasses
Bei den Eye Tracking Glasses hat man zwei Möglichkeiten, wie die Aufnahmen der
Daten durchgeführt werden sollen. Entweder nutzt man die Option des „Quick Runs“
oder man erstellt ein neues Experiment in dem Programm IView ETG. Im „Quick Run“
werden die Standardoptionen für die Kalibrierung verwendet. Beispielsweise ist fest-
gelegt, wie viele Kalibrierungspunkte aufgenommen werden sollen. Diese ist
standardmäßig auf 1-Punkt-Kalibrierung gesetzt. Bei dem Erstellen eines neuen Ex-
periments kann man diese Einstellungen für alle Aufnahmen gemeinsam festlegen
und zusätzlich noch Eigenschaften („Properties“) erstellen, die dann für jeden Teil-
nehmer individuell mit Werten belegt werden können. Anschließend kann sofort das
Experiment gestartet und mit der Aufnahme begonnen werden.
8.1.2 Externer Eye Tracker
Bei dem externen Eye Tracker sind die Vorbereitungen deutlich umfangreicher, da
zunächst der gesamte Ablauf des Experiments vorgegeben werden muss. Je nach-
dem, wie viele Abschnitte dieses umfasst, ist die Vorarbeit dementsprechend
zeitaufwändig. In jedem Fall wird zu Beginn ein Experiment erstellt, in das man ver-
schiedene Stimuli, wie z.B. Bilder, Text, Fragen, PDF-Dokumente oder Webseiten
einfügen kann. Jeder Stimulus hat dabei je nach Art unterschiedliche Editierungs-
möglichkeiten. Bei einer Frage lässt sich beispielsweise ein freier Text oder
vorgegebene Optionen als Antwort angeben und ob es als Teilnehmer möglich sein
soll, mehrere Antwortoptionen auszuwählen. Im Fall der Studie dieser Arbeit hat das
Erstellen der beiden benötigten Experimente für die Set- und Translate-Spezifikation
ca. 3 Stunden in Anspruch genommen, da trotz teils gleicher Antworten der Fragen
keine Antwortoptionen bei einer Frage kopiert und in eine andere eingefügt werden
können. Zudem ist es empfehlenswert, für jede Frage eine sogenannte „Property“ zu
definieren, um die Ergebnisdaten anschließend besser zuordnen zu können.
Wenn der gesamte Ablauf des Experiments auf diese Weise vorgegeben ist, kann
ausgewählt werden, während welcher Stimuli der Eye Tracker Blickdaten aufnehmen
soll. Dazu ist jeweils ein Kreuz zu setzen.
Sobald das Experiment vollständig eingestellt ist, gibt es auch hier die Möglichkeit
des „Quick Runs“. Dieser dient jedoch lediglich der Vorabansicht des Experiments
und es werden dabei keine Daten aufgenommen. Über „Record“ lässt sich die Auf-
nahme starten, wobei jedem Teilnehmer ein individueller Name gegeben werden
kann, über den die Daten letztendlich zu finden sind.
8 Reflektion zu Studien mit Eye Tracking
40
8.2 Durchführung der Aufnahmen
Die Durchführung der Aufnahmen ist bei beiden Eye Trackern ähnlich einfach und
umfasst wenig Aufwand von der Begleitperson der Studie.
8.2.1 Eye Tracking Glasses
Bei den Eye Tracking Glasses besteht die einzige Aufgabe (sofern die Studie nicht
weitere vorsieht) während der Aufnahme darin, aufzupassen, dass die Brille den
Blickpunkt des Probanden erkennt, dieser somit halbwegs mittig durch die Brille und
nicht an ihr vorbei schaut. Zudem wurden immer wieder Verbindungsprobleme mit
der Brille beobachtet. Das heißt, teilweise hat der an die Eye Tracking Glasses an-
geschlossene Rechner die Verbindung zu dieser verloren und die Aufnahme, das
Programm oder sogar der ganze Rechner mussten neu gestartet werden. Das führte
dazu, dass die Aufnahmedaten anschließend nicht mehr in einem Stück, sondern
aufgeteilt vorliegen. Es kommt jedoch nicht zum Verlust der Daten.
8.2.2 Externer Eye Tracker
Bei dem externen Eye Tracker muss darauf geachtet werden, dass der Proband sich
nicht aus dem Aufnahmefeld des Eye Trackers bewegt, den Kopf nicht zu schräg legt
oder seine Arme zwischen Eye Tracker und Augen bring, was dazu führt, dass kein
Blickpunkt erkannt werden kann. Zudem sei darauf hingewiesen, dass sobald der
Teilnehmer zu einer neuen Frage navigiert, nicht mehr zum vorherigen Stimulus zu-
rückgekehrt werden kann, da die Software die Antwort der Frage verlangt.
8.3 Analyse der Daten und Auswertungsmöglichkeiten
Die Datenanalyse ist der Schritt, bei dem sich der Zeitaufwand bei beiden Eye Tra-
ckern am meisten unterscheidet, da diese bei den Eye Tracking Glasses aufwändiger
ist.
8.3.1 Eye Tracking Glasses
Zunächst liegen die Daten der Eye Tracking Glasses nach der Aufnahme nur in der
Software als Video vor, auf dem jeweils der Blickpunkt des Probanden abgetragen
ist. Mit diesem lassen sich jedoch Auswertungsmöglichkeiten, wie Areas of Interest,
Gaze Plot oder Heat Maps nicht nutzen, da es keine statische Referenz gibt. Bevor
man quantitative Messwerte aus den Aufnahmedaten erhält, muss jeder Blickpunkt
somit auf ein oder mehrere sogenannte Referenzbilder abgebildet werden. Als eine
solche Referenz lässt sich entweder ein eigenes Bild in die Analysesoftware laden
oder ein Screenshot des Videos nehmen.
Der Abbildungsprozess wird in Abbildung 8.1 dargestellt. Dort ist auf der linken Seite
das Referenzbild zu sehen und dem gegenüber die Aufnahmedaten der Brillenka-
mera, wo jeweils der aktuelle Blickpunkt zu dem Zeitpunkt angezeigt wird. Nun lässt
sich auf der linken Seite im Bild auswählen, zu welchem Abschnitt der Spezifikation
der Punkt gehört. Um Zeit zu sparen und weil eine genauere Auswertung für diese
Studie nicht notwendig war, wurden die Blickpunkte hier nur in Kategorien (die ein-
zelnen Teilkapitel der Spezifikation) eingeteilt und nicht punktgenau ausgewertet.
Das hat zur Folge, dass die genaue Lage der Punkte zwar keine Aussagekraft mehr
hat, man jedoch die Auswertungsmöglichkeit der Areas of Interest nutzen kann. Dazu
definiert man einen rechteckigen AOI-Bereich für jede Kategorie und kann sich an-
schließend genau ausgewertete Daten, wie die jeweilige Blickdauer oder die
durchschnittliche Anzahl an Fixationen anzeigen lassen. Auch andere Auswertungs-
möglichkeiten, wie z.B. Heat Maps lassen sich nun nutzen.
8 Reflektion zu Studien mit Eye Tracking
41
Abbildung 8.1: Abbilden der Blickpunkte auf ein statisches Referenzbild
Für die Studie, die im Rahmen dieser Arbeit durchgeführt wurde, hat die Analyse der
Daten auf diese Weise im Durchschnitt etwa 50 Minuten pro Teilnehmer in Anspruch
genommen, also das zwei- bis dreifache der Videozeit, die 20 Minuten betrug. Die
benötigte Zeit hängt jedoch stark von der Präzision der gewünschten Auswertung ab.
Je kleiner die betrachteten Bereiche und je öfter aufgrund der gestellten Aufgabe
zwisschen ihnen gewechselt wird, desto größer der Aufwand. Des Weiteren spielt
auch ein individueller Faktor des Probanden eine Rolle, da es Menschen gibt, die ein
deutlich sprunghafteres Blickverhalten haben als andere und dessen Blickdaten da-
her aufwändiger zu analysieren sind.
8.3.2 Externer Eye Tracker
Im Gegenzug zu den Eye Tracking Glasses liefert der externe Eye Tracker für den
Monitor bereits sofort sämtliche Auswertungsmöglichkeiten und benötigt kein stati-
sches Referenzbild, da er dieses mit dem Monitor bereits gegeben hat. Die einzige
zeitaufwendige Aufgabe, die sich ergab, lag darin die Blickdaten der definierten AOIs
für jeden Teilnehmer in eine Exceltabelle zu übertragen, da die Analysesoftware da-
für keine geeignete Exportfunktion bietet. Bei den Daten dieser Studie kam hinzu,
dass die Software für jedes Mal, wenn der Proband eine PDF-Seite ein weiteres Mal
aufgerufen hat, ein neuer Datensatz erstellt wurde. Das heißt, für eine PDF-Seite
waren zum Beispiel für einen Probanden bis zu acht einzelne Elemente angezeigt.
Da eine Auswahl aller dazu führt, dass der Durchschnitt und nicht die Summe der
Blickdaten ermittelt wird, musste somit manuell jeder Datensatz durchgegangen und
anschließend alle Werte summiert werden. Dieser Prozess benötigte daher ohne die
Definition der AOIs etwa vier Stunden.
8.4 Fazit zur Durchführung von Studien mit Eye Tracking
Insgesamt lässt sich sagen, dass Eye Tracking eine sehr mächtige Methode darstellt,
da sie sehr genaue Aussagen darüber liefert, wie lange welcher untersuchte Bereich
betrachtet wird. Mithilfe dieser Daten lassen sich beispielsweise Lesegeschwindig-
keiten ermitteln oder Prioritätslisten von Elementen bestimmen. Um die
Ergebnisdaten zu erhalten, ist jedoch einiges an Zeit und Aufwand nötig. Daher sollte
abhängig vom zu untersuchenden Sachverhalt jeweils genau überlegt werden, ob
der entstehende Nutzen den nötigen Aufwand rechtfertigt oder ob andere Messme-
thoden ausreichend oder geeigneter sind.
42
9 Auswertung und Schlussfolgerung
In diesem Kapitel wird beschrieben, welche Schlüsse sich aus den Ergebnissen der
Studie ziehen ließen. Dazu wurden zunächst die Resultate zusammengefasst, je-
weils mit einem Hinweis auf die Signifikanz des Untersuchungsbefunds.
Anschließend konnten die ermittelten Erkenntnisse mit denen einschlägiger Literatur
verglichen werden. Daraufhin wurde eruiert welche Schlüsse aus den Ergebnissen
gezogen werden konnten, um die ursprünglich definierten Verbesserungsziele der
Studie zu erreichen.
9.1 Ergebnisse der Studie
Bei den Studienergebnisse wurden sowohl sich als signifikant herausgestellte Resul-
tate, sowie bei gegebener Stichprobengröße nicht ausreichend große Unterschiede
zusammengefasst. Bei jeder Erkenntnis ist daher das Signifikanzniveau angegeben.
9.1.1 Effekt der Darstellungsform
Bei der Darstellungsform wurden die Kriterien Vorliebe des Lesers, Wiedergabefä-
higkeit und Geschwindigkeit berücksichtigt. Bei der Vorliebe des Lesers haben vier
von elf Personen für die digitale Variante und sieben von elf Personen für die ausge-
druckte Version gestimmt. Dieser Unterschied reicht jedoch noch nicht für eine
Bestätigung der Hypothese auf dem 5%-Niveau, dass ausgedruckte Spezifikationen
bevorzugt werden. Ebenso verhält es sich bei der Wiedergabefähigkeit, die mittels
inhaltlicher Fragen nach dem Lesen der Spezifikation gemessen wurden. Dabei gab
es bei gleicher Fragenanzahl bei den ausgedruckten Spezifikationen 37 richtige Ant-
worten und bei den am Bildschirm gezeigten 40. Die Geschwindigkeit wurde in s/cm
gemessen und Mittels dem Vergleich mehrerer Mittelwerte auf einen signifikanten
Unterschied auf dem 5%-Niveau getestet. Dieser konnte jedoch nicht festgestellt
werden. Eine Übersicht über die Lesegeschwindigkeiten der Teilnehmer geben die
Balkendiagramme in Abbildung 9.1. Dort sind auf der x-Achse die einzelnen Ge-
schwindigkeiten der Größe nach geordnet paarweise gegenübergestellt. Die Länge
der Balken gibt auf der y-Achse die jeweilige Gesamtgeschwindigkeit für das Doku-
ment an. Anhand der Daten lässt sich der Trend erkennen, dass am Bildschirm
angezeigte Spezifikationen tendenziell schneller gelesen werden, es lässt sich je-
doch nicht nachweisen, dass diese Unterschiede nicht zufällig sind.
Abbildung 9.1: Geschwindigkeitsübersichten der Spezifikationen
0,00
0,20
0,40
0,60
0,80
1,00
1 2 3 4 5Ges
chw
ind
igke
it [
cm/s
]
Wertepaare nach Größe sortiert
Geschwindigkeit: Translate
ausgedruckt am Bildschirm
0,00
0,20
0,40
0,60
0,80
1,00
1,20
1,40
1 2 3 4 5Ges
chw
ind
igke
it [
cm/s
]
Wertepaare nach Größe sortiert
Geschwindigkeit: Set
ausgedruckt am Bildschirm
9 Auswertung und Schlussfolgerung
43
9.1.2 Relevanz der Abschnitte
Für die Beurteilung der Wichtigkeit der Abschnitte für die Tätigkeiten der einzelnen
Rollen wurden die Relevanzeinschätzungen der Studienteilnehmer zunächst unter-
sucht und anschließend die erkennbaren Trends mit den Leseintensitäten der
Abschnitte verglichen. Bei der Betrachtung der Bewertungen der Wichtigkeit der Ab-
schnitte ergaben sich die in Abbildung 9.2 dargestellten Werte. In der linken Spalte
sind die einzelnen Abschnitte der Spezifikation dargestellt. In den vier Spalten dane-
ben ist die jeweilige durchschnittliche Bewertung der Teilnehmer mit der
entsprechenden Rolle enthalten. Die Werte, die auf dem 5%-Niveau erfolgreich auf
statistische Signifikanz getestet wurden, sind mit einem Stern markiert. Die geringe
Anzahl an signifikanten Ergebnissen lässt sich dabei auf die geringe Probandenzahl
der einzelnen Rollen zurückführen. Die grün und türkis markierten Felder in der Ta-
belle stehen für (sehr) wichtige Abschnitte, die blau und rot markierten für weniger
wichtige und unwichtige Teile und die gelb eingefärbten stehen genau zwischen
wichtig und weniger wichtig. Es kann beobachtet werden, dass einige Abschnitte
deutlich als unwichtig bewertet wurden, wie zum Beispiel die Abschnitte „Maßnah-
men zur Anforderungsanalyse“ und „Glossar“. Zum Glossar ist jedoch anzumerken,
dass die Domäne der Spezifikationen keine komplizierten Begrifflichkeiten umfasste,
sodass diese ohne große Erklärungen für die Teilnehmer verständlich waren. Dies
deckt sich auch mit den Kommentaren in den Fragebögen. Als besonders wichtig
bewertet wurden insbesondere die Abschnitte „Erläuterung des zu lösenden Prob-
lems“ und „Wünsche und Prioritäten des Kunden“, die allgemeine Informationen zu
dem Projekt umfassen. Diese klare Tendenz zeigt sich auch in den Lesezeiten der
Abschnitte, da diese mit Abstand am intensivsten gelesen wurden. Die Bewertungen
aller anderen Abschnitte wurden ebenfalls mit den Leseintensitäten verglichen, wo-
bei keine auffälligen Unterschiede gefunden werden konnten, was die Aussagekraft
der Bewertungen bestätigt.
9 Auswertung und Schlussfolgerung
44
Bewertung der Rollen
Spezifikations- abschnitt
UI-Designer Software- architekt
Tester Entwickler
gesamt
1.1 Erläuterung des zu lösenden Problems
1,50 1,00 (*) 1,50 1,50 (*)
1.2 Wünsche und Prioritäten des Kunden
1,50 1,50 1,75 1,50 (*)
1.3 Domänenbeschreibung 2,00 2,00 2,50 2,50 1.4 Maßnahmen zur Anforderungsanalyse
2,75 3,50 3,75 3,63 (*)
2.1 Einschränkungen und Vorgaben
1,75 2,25 2,50 1,75 (*)
2.2 Anwender 1,75 2,75 2,00 1,88 2.3 Schnittstellen und angrenzende Systeme
2,75 1,50 3,50 1,88
3.1 Use Case-Diagramm 2,00 2,00 1,50 2,38 3.2 Use Case-Beschreibungen 1,25 2,75 1,00 (*) 1,38 (*)
3.3 Technische Anforderungen 2,75 2,25 2,50 1,88 (*) 4.1 Qualitätsziele des Projekts 2,00 (*) 1,75 1,50 2,38
4.2 Qualitätsprioritäten des Kunden
1,75 1,75 1,50 2,25
4.3 Wie Qualitätsziele erreicht werden sollen
2,50 1,75 2,50 2,38
5 Probleme und Risiken 2,75 3,50 3,75 2,75 6.1 Mögliche Abstriche 2,25 2,25 3,25 2,50
6.2 Inkrementelle Arbeit 2,50 2,00 4,00 (*) 2,13 (*) 7 MockUps 1,00 (*) 3,75 2,50 1,38 (*) 8 Glossar 3,00 3,00 3,25 3,50 (*)
9 Abnahmetestfälle 3,00 2,50 3,00 2,38
1 = "sehr wichtig", 2 = "wichtig", 3 = "weniger wichtig", 4 = "unwichtig" (*) = statistisch signifikant auf dem 5%-Niveau
Abbildung 9.2: Durchschnittliche Bewertungen der Rollen
9.1.3 Unterschiede zwischen den Rollen
Um festzustellen, wo es Unterschiede zwischen den Informationsbedarfen der Rollen
gibt und wo es somit nötig ist, unterschiedliche Spezifikationssichten zu definieren,
wurden die Bewertungen der verschiedenen Rollen miteinander verglichen und auf
signifikante Differenzen geprüft. Diese konnten vor allem wegen der kleinen Stich-
probengröße nur bei den Abschnitten „Schnittstellen und angrenzende Systeme“,
„Inkrementelle Arbeit“ und „MockUps“ gefunden werden. Das Signifikanzniveau ist
dabei erneut 5%.
Die Daten weisen darüber hinaus insgesamt darauf hin, dass sich insbesondere die
Daten des Testers besonders von den anderen abheben. Dieser Trend zeigt sich
auch in Abbildung 9.2. Die Unterschiede zwischen UI-Designern, Softwarearchitek-
ten und Entwicklern sind dagegen vergleichsweise gering. Bis auf den Abschnitt
„MockUps“, der nur für UI-Designer und Entwickler eine hohe Relevanz hat, weichen
die Werte kaum voneinander ab. Daraus lässt sich schließen, dass es sinnvoll ist, für
die Rolle des Testers eine eigene Sicht auf die Anforderungsdokumente zu generie-
ren.
9 Auswertung und Schlussfolgerung
45
9.2 Vergleich mit einschlägigen Studien
Die Ergebnisse der Studie wurden nach deren Ermittlung und Überprüfung mit ähn-
lichen Studien verglichen, um zu untersuchen, ob diese übereinstimmen und wo sich
Unterschiede aufzeigen lassen.
9.2.1 Effekt der Darstellungsform
Die Studien, die in einschlägiger Literatur zum Vergleich der Darstellungsformen Pa-
pier und Bildschirm aufgeführt werden, haben ebenfalls die Metriken
Geschwindigkeit, Wiedergabefähigkeit und Präferenz untersucht. Dabei konnte bei
der Lesegeschwindigkeit am Bildschirm ein signifikanter Performanzverlust von bis
zu 30% verzeichnet werden (Dillon92). Die Daten dieser Studie können dieses Ver-
hältnis jedoch nicht bestätigen. Nicht nur, dass kein signifikanter Unterschied
zwischen der Geschwindigkeit am Bildschirm und auf Papier festgestellt werden
konnte, die Durchschnittsgeschwindigkeiten der digitalen Spezifikation lagen zudem
über denen der ausgedruckten Versionen. Bei der Wiedergabefähigkeit hingegen
stimmen die Ergebnisse der bisher durchgeführten Studien, dass Informationen am
Bildschirm schlechter erinnert werden (Dillon92), mit dem Trend der in diesem Rah-
men durchgeführten Studie überein. Dieser Unterschied konnte wiederum nicht als
signifikant nachgewiesen werden und ist daher vorsichtig zu betrachten. Bei der Prä-
ferenz des Lesers widersprechen die Untersuchungsbefunde der vergangenen
Studien aus der Literatur erneut der Tendenz der ermittelten Daten dieser Studie.
Einschlägige Studien konnten vorwiegend eine Präferenz für die Darstellung am Bild-
schirm feststellen (Dillon92). Die Teilnehmer der Studie haben hingegen mehrheitlich
für die ausgedruckte Fassung gestimmt, die jedoch nicht als signifikant nachgewie-
sen werden konnte.
Die einheitliche Diskrepanz zwischen Literatur und Studienergebnisse kann dadurch
erklärt werden, dass die Nutzungsszenarien stark voneinander abweichen und das
Lesen von Spezifikationen einen anderen Anwendungsfall der Darstellungsformen
Papier und Bildschirm darstellt. Mit dem Vergleich der Ergebnisse konnte somit fest-
gestellt werden, dass diese darauf hindeuten, dass sich das Lesen von
Spezifikationen nicht mit dem Lesen herkömmlicher Texte vergleichen lässt. Auf-
grund der fehlenden statistischen Signifikanz dieser Erkenntnisse, sind jedoch
weitere Untersuchungen zur Sicherung nötig.
9.2.2 Relevanz der Abschnitte
Die Studien des Fraunhofer Instituts für Experimentelles Software Engineering be-
handelten ebenfalls den Ansatz für verschiedene Rollen eine eigene Sicht auf
Anforderungsdokumente zu generieren. Die verwendeten Spezifikation wurden je-
doch mit dem TORE-Framework (Adam09) erstellt und damit nicht nach dem
Template der Spezifikationen dieser Studie. Darüber hinaus wurden dort nur die Rol-
len Usabilityexperte und Softwarearchitekt untersucht (Gross12b). Die
Vergleichsmöglichkeiten sind daher relativ beschränkt. Da in den Fragebögen zur
Relevanzeinschätzung jedoch die gleiche Skala verwendet wurde, lassen sich die
übereinstimmenden Abschnitte sehr gut vergleichen. Die entsprechenden durch-
schnittlichen Bewertungen der vergleichbaren Artefakte sind in Abbildung 10.3
gezeigt. Die Farben und Bewertungen wurden dabei genauso abgebildet, wie in Ab-
bildung 10.2. Das heißt, 1 steht für „Sehr wichtig“, 2 für „Wichtig“, 3 für „Weniger
wichtig“ und 4 für „Unwichtig“ (Gross12b). In der Tabelle lässt sich erkennen, dass
sich die Bewertungen der UI-Designer stark ähneln. Auch die Einschätzungen der
Architekt sind weitestgehend identisch. Die einzige Ausnahme bilden die Abschnitte
„Anwender“ und „Technische Anforderungen“. Das lässt sich damit erklären, dass
9 Auswertung und Schlussfolgerung
46
diese Abschnitte in den Spezifikationen dieser Studie eher kurz ausfielen und daher
vermutlich schlechter bewertet wurden, da sie weniger Informationen boten. Somit
können keine gravierenden Differenzen festgestellt werden, was für die Vereinbarkeit
der beiden Ergebnisse spricht. Auf statistische Signifikanz lassen sich die einzelnen
Differenzen nicht testen, da die konkreten Bewertungen der Teilnehmer der Fraun-
hofer IESE Studien nicht bekannt sind. Für alle Differenzen zusammen ergibt der t-
Test für paarweise angeordnete Messwerte jedoch keinen statistisch signifikanten
Unterschied auf dem 5%-Niveau.
Abbildung 9.3: Vergleich mit Fraunhofer IESE Studie (Gross12b)
9.3 Schlussfolgerung
Anhand der untersuchten Unterschiede zwischen den Informationsbedarfen lässt
sich statistisch geprüft feststellen, dass es sinnvoll ist, für die Rollen Tester, Soft-
warearchitekt und UI-Designer bzw. Tester und Entwickler gesonderte Sichten auf
Anforderungsdokumente zu generieren. Dafür sollten für die Rolle des UI-Designers
auf jeden Fall die Abschnitte „Qualitätsziele des Projekts“ und MockUps enthalten
sein. Für die Rolle des Softwarearchitekten darf der Abschnitt „Erläuterung des zu
lösenden Problems“ nicht fehlen, sowie für den Tester die Use Case-Beschreibun-
gen. Informationen über die inkrementelle Vorgehensweise werden von der Rolle des
Testers hingegen nicht benötigt. Für Entwickler im Allgemeinen bilden die Abschnitte
„Erläuterung des zu lösenden Problems“, „Wünsche und Prioritäten des Kunden“,
„Einschränkungen und Vorgaben“, „Use Case-Beschreibungen“, „Technische Anfor-
derungen“, „Inkrementelle Arbeit“ und „MockUps“ eine wichtige
Informationsgrundlage. Auf die Sektion „Maßnahmen zur Anforderungsanalyse“
kann hingegen verzichtet werden. Bei dem Glossar muss außerdem berücksichtigt
werden, ob es sich bei dem Projekt um eine für Entwickler eher unbekannt Domäne
handelt. Andernfalls spielt dieser Abschnitt ebenfalls eine eher unwichtige Rolle. Für
alle anderen als wichtig oder unwichtig bewertete Artefakte, deren Relevanzeinschät-
zung nicht ausreichte, um statistisch signifikante Aussagen treffen zu können, sind
weitere Studien nötig, um empirisch fundiert deren Wichtigkeit für die einzelnen Rol-
len beurteilen zu können.
Abschnitt nach TORE
Abschnitt nach SWP-Template
Bewertungen nach TORE Bewertungen dieser Studie
AS AE UE UT UI-
Designer Software- architekt
Descriptions of Stakeholders
Anwender 2,46 2 1 1,78 1,75 2,75
Descriptions of Stakeholder Goals
Erläuterung des zu lösenden Problems
2,31 1 2 1,5 1,5 1
Descriptons of Domain Data
Domänen- beschreibung
2,69 1,5 2 2,78 2 2
Descriptions of Quality Attributes/ NFRs
Qualitätsziele des Projekts bzw. Quali-tätsziele des Kunden
1,58 1,5 2 - 1,875 1,75
Descriptions of Technical Constraints
Technische Anforderungen
1,77 1 2,5 - 2,75 2,25
AS: Architekten der SE-Projekt Studie, AE: Architekten der Eye Tracking Studie, UE: Usability- experten der Eye Tracking Studie, UT: Usability der Tutorial Studie, NFRs: nichtfunktionale Funktionsanforderungen
9 Auswertung und Schlussfolgerung
47
Um eventuelle Varianzen innerhalb der Rollen auszugleichen ist es darüber hinaus
sinnvoll, dass das entsprechende Tool, das rollenabhängige Sichten auf Anforde-
rungsspezifikationen zur Verfügung stellt, auch die Möglichkeit bietet herausgefilterte
Abschnitte dennoch aufrufen zu könne, sollte dies gewünscht sein. Der Vergleich
der beiden Darstellungsmedien Papier und Bildschirm deutet zudem daraufhin, dass
ein solches technisch unterstütztes Tool keine Nachteile in Bezug auf die betrachte-
ten Kriterien Präferenz der Leser, Lesegeschwindigkeit, sowie Wiedergabefähigkeit
hätte, da dort auf dem 5%-Niveau keine signifikanten Effekte nachgewiesen werden
konnten.
48
10 Einschränkungen der Validität
Eine wichtige Frage bei dem Durchführen einer Studie ist die Validität der Ergeb-
nisse. Diese sollte man schon in der Vorbereitungsphase berücksichtigen, um das
Design der Studie bereits mit Absicht auf ein möglichst hohes Maß an Validität planen
zu können (Wohlin00). Ein angemessenes Maß an Validität bedeutet, dass die Re-
sultate der Studie für die betrachtete Personengruppe geeignet sein sollten. Die vier
Kategorien von möglichen Einschränkungen der Validität werden in diesem Abschnitt
diskutiert.
10.1 Validität der Schlussfolgerung
Die Validität der Schlussfolgerung bezieht sich darauf, dass erlangte Erkenntnisse
statistisch richtig ausgewertet sein sollten (Wohlin00). Dies ist sichergestellt, da für
jeden verwendeten Signifikanztest die Voraussetzungen geprüft und stets das glei-
che Signifikanzniveau von 5% verwendet wurde. Auch Einschränkungen, wie
maximal zulässige oder minimal notwendige Stichprobengrenzen wurden berück-
sichtigt.
10.2 Interne Validität
Mögliche Faktoren, die die interne Validität negativ beeinflussen könnten, wurden
bereits in der Planungsphase ausgeschlossen. Dazu gehört beispielsweise die Tat-
sache, dass die verschiedenen Teilnehmer die einzelnen Fragen je nach Rolle
besser oder schlechter beantworten können, da die einzelnen Abschnitte für ihre Tä-
tigkeiten unterschiedlich relevant und daher auch unterschiedlich intensiv gelesen
werden. Dies spielt für die Auswertung jedoch keine Rolle, da am Ende die Werte
insgesamt für die beiden Darstellungsformen „ausgedruckt“ und „am Bildschirm“ ver-
glichen werden und jede Rolle dabei jeweils gleich häufig vertreten ist. Ebenso
verhält es sich mit Einflüssen, die sich durch die Reihenfolge der Spezifikation oder
Darstellungsform ergeben könnten, da diese zum einen zufällig ausgewählt wurde
und zum anderen jede Spezifikation, Darstellungsform und Kombination von beiden
gleich häufig als erstes und zweites zum Einsatz kam. Durch diese Maßnahmen wur-
den gleichzeitig auch ungewollte Lerneffekte im Verlauf der Studie ausgeglichen, da
diese bei allen betrachteten Metriken gleichermaßen vertreten sind. Des Weiteren
könnte die unterschiedliche Darstellungsform der Umfragebögen die Teilnehmer in
ihren Antworten beeinflussen, da z.B. auf den ausgedruckten Fragebögen mehrere
Fragen auf einer Seite und am Bildschirm jede Frage separat abgebildet wurde.
Diese Einflüsse wurden jedoch dadurch abgefangen, dass jeder Teilnehmer die Fra-
gebögen einmal auf Papier und einmal am Bildschirm ausgefüllt haben und die
Antworten anschließend miteinander abgeglichen wurden. Der letzte Faktor, der die
Studienergebnisse und somit die interne Validität hätte beeinflussen können, sind die
unterschiedlichen Längen der Spezifikationen. Diese spielen durch das gesetzte
Zeitlimit eine Rolle bei dem Geschwindigkeitsvergleich der beiden Darstellungsme-
dien. Das wurde jedoch umgangen, indem mittels Blockingverfahren die
verwendeten Spezifikationen getrennt analysiert wurden. Somit verfügt die Studie
über eine hohe interne Validität.
10 Einschränkungen der Validität
49
10.3 Validität der Konstruktion
Die Validität der Konstruktion wurde dadurch sichergestellt, dass die betrachteten
Rollen einen Ausschnitt aus denen realer Softwareprojekte darstellen und die Teil-
nehmer darüber hinaus echte Aufgaben zu bearbeiten hatten und sich daher nicht
nur in fiktive Szenarien hinein versetzen mussten. Die betrachteten Metriken wurden
zudem bestehender Literatur und bereits durchgeführten Untersuchungen entnom-
men und sind somit nicht zufällig gewählt, was zu künstlich herbeigeführten Effekten
hätte führen können.
10.4 Externe Validität
Die externe Validität beschreibt inwiefern die Resultate der Studie auf andere reale
Softwareprojekte übertragen werden können. Da an der Studie ausschließlich Infor-
matiker teilgenommen haben, die bereits erste Erfahrungen in der Entwicklung von
Softwareprodukten haben, lassen sich die Ergebnisse auf jeden Fall auf akademi-
sche Umgebungen, sowie Entwickler mit geringer Berufserfahrung übertragen. Da
zusätzliche erfahrene Entwickler hinzugezogen wurden und bei dem Vergleich ihrer
Messdaten mit denen der studentischen Entwickler kein signifikanter Unterschied auf
dem 5%-Niveau festgestellt werden konnte, sind die Erkenntnisse auch erfahrenere
Personen in Entwicklerrollen verallgemeinerbar.
Einzige Einschränkungen müssen bei der Art der Spezifikation gemacht werden, da
die Untersuchungsbefunde sich auf das Template der verwendeten Spezifikationen
beziehen und nichts über einen anderen Aufbau ausgesagt werden kann. Durch den
Vergleich mit den Studien des Fraunhofer IESE konnte jedoch festgestellt werden,
dass sich die Ergebnisse auch für längere Spezifikationen anwenden lassen.
50
11 Abschließende Betrachtung
11.1 Zusammenfassung
Die vorliegende Arbeit hat auf Basis der Erkenntnisse bisheriger Untersuchungen,
die die Abhängigkeit von der Relevanz von Spezifikationsabschnitten und der Rolle
des Lesers gezeigt haben, eine Eye Tracking Studie entworfen und durchgeführt.
Diese hat den Informationsbedarf von verschiedenen Entwicklerrollen analysiert. Da-
bei wurde untersucht, ob es Unterschiede in der Wichtigkeit der Abschnitte von
Spezifikationen, sowie Unterschiede zwischen den Informationsbedarfen der Rollen
gibt. Mithilfe dieser Ergebnisse konnte gezeigt werden, dass die in Anforderungsspe-
zifikationen enthaltenen Informationen für die Rollen UI-Designer, Softwarearchitekt,
Tester und Entwickler unterschiedlich relevant sind und es zu dem signifikante Un-
terschiede zwischen den Informationsbedarfen der einzelnen Rollen gibt. Diese
Ergebnisse stimmen mit denen einschlägiger Studien aus der Literatur überein.
Auf dieser Grundlage konnte gefolgert werden, dass die Generierung von rollenab-
hängigen Sichten auf Anforderungsdokumente, in denen nur noch für die jeweilige
Rolle wichtige Abschnitte gezeigt werden, eine erhebliche Effizienzsteigerung bei
dem Lesen von Spezifikationen bringen könnte. Der Grund liegt darin, dass das Her-
ausfiltern unwichtiger Sektionen wegfiele. Zudem ließe sich das Erstellen der
Dokumente teils aufteilen, da beispielsweise der Softwarearchitekt bereits mit seiner
Arbeit beginnen könnte bevor die für den UI-Designer notwendigen Teile fertig ge-
stellt sind. Das würde dazu beitragen, Fristen besser einhalten zu können.
Des Weiteren wurde im Zuge der durchgeführten Studie mittels Eye Tracking und
Fragebögen eruiert, ob die Darstellung der Spezifikation auf Papier oder am Monitor,
einen Effekt auf die Lesegeschwindigkeit, sowie die Wiedergabefähigkeit der Textin-
halte hat. Dabei konnte kein signifikanter Unterschied festgestellt werden. Auch in
der Präferenz der Leser konnte keine aussagekräftige Tendenz erkannt werden.
11.2 Ausblick
Aufgrund der kleinen Stichprobengröße konnte nicht für alle Unterschiede in den Be-
wertungen der Abschnitte die Signifikanz der Ergebnisse nachgewiesen werden.
Hierfür sind weitere Untersuchungen nötig. Dazu ist es zu empfehlen auch Anforde-
rungsspezifikationen größerer Projekt, sowie andere Templates und Frameworks zu
betrachten, um möglichst umfassende Kenntnisse über den Zusammenhang zwi-
schen den einzelnen Rollen und ihrem Informationsbedarf zu erhalten.
Darüber hinaus bietet der Ansatz noch Potenzial bei der Berücksichtigung weiterer
Rollen, wie Projektleitern oder Qualitätsbeauftragten, da dort ebenfalls ein Unter-
schied zu den Rollen der direkt an der Entwicklung beteiligten Rollen vermutet wird.
Diese benötigen jedoch aufgrund der umfassenden Tätigkeiten größere Stichpro-
ben, um valide Ergebnisse zu erhalten.
Sobald genügend empirische Daten erhoben wurden, müssen diese anschließend in
einem entsprechenden Tool umgesetzt werden, um die angestrebte Effizienz- und
Effektivitätssteigerung auch tatsächlich erreichen zu können. Durch die Umsetzung
dieser sichtenbasierten Anforderungsdokumente wird ein großes Potenzial zur Kos-
ten- und Zeitersparnis gesehen.
51
Literaturverzeichnis
(Adam09) Sebastian Adam, Joerg Doerr, Michael Eisenbarth, Anne Gross: Using
Task-oriented Requirements Engineering in Different Domains – Experience of Ap-
plication in Research and Industry, In: Proceedings of the 2009 17th IEEE
International Requirements Engineering Conference, RE (RE '09). IEEE Computer
Society, Washington, DC, USA, S. 267-272, 2009
(Adam14) Dr. Sebastian Adam, Norman Riegel, Dr. Joerg Doerr: TORE - A Frame-
work for Systematic Requirements Development in Information Systems, In:
Requirements Engineering Magazine, Ausgabe 04/2014
(Brau11) Henning Brau, Andreas Lehmann, Kostanija Petrovic, Matthias C. Schro-
eder: Usability Professionals 2011 - Tagungsband, S.24-29. German UPA e.V.
(Dillon92) Andrew Dillon: Reading from paper versus screens: a critical review of the
empirical literature, In: Ergonomics, 1992, Ausgabe 35, Nr. 10, S.1297-1326
(Ebert12) Christof Ebert: Systematisches Requirements Engineering, In dpunkt.ver-
lag, 2012, 4. überarbeitete Auflage
(Eckstein09) Jutta Eckstein: Agile Softwareentwicklung mit verteilten Teams, In:
dpunkt.verlag Heidelberg, 2009
(Freimut02) Bernd Freimut, Jochen Hiller, Ralf Kalmar, Teade Punter: Messpro-
gramm zur Minimierung der Fehlerrate in der Produktion des Produkts Top-Logic von
Bauer & Partner, In: IESE-Report Nr. 098.02/D, Version 1.0, 18.12.2002
(Gross12a) Anne Gross: Anforderungen an die Anforderungsspezifikation aus Sicht
von Architekten und Usability Experten, In Softwaretechnik-Trends, November 2012,
Ausgabe 32, Heft 4, S.7-8. Köllen Druck & Verlag GmbH
(Gross11) Anne Gross: Anforderungen an die Anforderungsspezifikation aus Sicht
von Architekten und Usability Experten, Fraunhofer IESE, Präsentation auf dem GI
Fachgruppentreffen RE, 24./25.11.2011, Hamburg
(Gross12b) Anne Gross, Joerg Doerr: What You Need Is What You Get! The Vision
of View-Based Requirements Specifications, IEEE RE 2012, Chicago, Illinois, USA,
S. 171-180
(Gross12c) Anne Gross, Joerg Doerr: What do Software Architects Expect from Re-
quirements Specifications, In: IEEE TwinPeaks 2012, Chiacgo, Illinois, USA, 2012
(Gross12d) Anne Gross, Steffen Hess: Was erwarten Usability Experten von Anfor-
derungsdokumenten?, In: I-com Zeitschrift für interaktive und kooperative Medien,
Ausgabe 11, Heft 2, Seiten 50-54. Oldenbourg Wissenschaftsverlag, August 2012
(Günter13) Matthias Günter: Die Kundenrolle in IT-Projekten, In: BoD – Books on
Demand, 2013
(IEEE98a) IEEE: IEEE Guide for InformationTechnology – System Definition – Con-
cept of Operations (ConOps) Document, In: IEEE Standard 1362-1998, 1998
Literaturverzeichnis
52
(IEEE98b) IEEE: IEEE Recommended practice for Software Requirements Specifi-
cations, In: IEEE Standard 830-1998, 1998
(Lemke14) Michael Lemke: Sind wir wirklich reif für E-only? Nutzerbedarf und Lese-
verhalten als Kriterien einer monographischen Erwerbungspolitik an
wissenschaftlichen Bibliotheken, In: Perspektive Bibliothek, Band 3, Nr. 2, 2014, S.7-
43
(Lemken99) Birgit Lemken: Ebook - the Missing Link between Paper and Screen, In:
Designing Electronic Books Workshop, CHI 1999 Conference, Pittsburgh, PA
(Robertson06) S. Robertson and J. Robertson: Volere Requirements Specification
Template, In: Mastering the Requirements Process, Affison-Wesley, 2006
(Sachs93) Lothar Sachs: Statistische Methoden: Planung und Auswertung, In: Sprin-
ger-Verlag, Berlin, 1993
(Schall14) Andrew Schall, Jennifer Romano Bergstorm: Eye Tracking in User Expe-
rience Design, In: Elsevier, Morgan Kaufmann, 2014
(Schmidts07) Hermann Schmidts: Usability-Evaluation: Eine Studie zur Identifizie-
rung von Nutzungsproblemen mittels Eye-Tracking-Parametern, Kapitel 3 und 4, In:
VDM Verlag Dr. Müller, Saarbrücken, 2007
(Schneider15) Kurt Schneider: Vorlesung: Requirements Engineering, In: Leibniz
Universität Hannover, Sommersemester 2015
(SMI15) SMI Webseite, http://www.smivision.com/en/gaze-and-eye-tracking-systems/pro-
ducts/redm.html (letzter Zugriff: 13.08.15)
(Solingen99) Rini van Solingen, Egon Berghout: The Goal/Question/Metric Methode:
a practical guide for quality improvement of software development, In: McGraw-Hill,
London, 1999
(Versteegen03) Gerhard Versteegen (Hrsg.), Alexander Heßeler, Colin Hood, Chris-
tian Missling, Renate Stücka: Anforderungsmanagement, In: Springer-Verlag, Berlin,
2003
(Wohlin00) Claes Wohlin, Per Runeson, Martin Höst, Magnus C. Ohlsson, Björn Reg-
nell, Anders Wesslen: Experimentation in Software Engineering: An Introduction, In:
Kluwer Academic Publishers, Boston/Dordrecht/London, 2000
(Wiki15) Abbildung 2.2: https://upload.wikimedia.org/wikipedia/commons/e/ef/Rea-
ding_Fixations_Saccades.jpg (letzter Zugriff: 13.08.15)
53
A. Anhang
A. Anhang
54
A.1 Einführungen für die Teilnehmer
A.1.1 Einführung für die Rolle UI-Designer
Herzlich Willkommen zu der Studie
„Lesen von Spezifikationen“!
In dieser Studie werden Ihnen zwei Spezifikationen zum Lesen gegeben. Sie ha-
ben dabei die Rolle des UI-Designers und sollen für das im Dokument
beschriebene System die Benutzeroberfläche entwerfen. Dazu ist Ihre Aufgabe im
Rahmen dieser Studie zunächst einige MockUps (erste Entwürfe) für diese zu er-
stellen. Anschließend werden Ihnen einige Fragen zum Inhalt des Dokuments
gestellt, sowie nach Ihrer subjektiven Bewertung der Relevanz der darin enthalte-
nen Abschnitte.
Vorher werden Sie jedoch noch darum gebeten, einige Fragen zu Ihrem Hinter-
grund zu beantworten. Dies dient lediglich dazu, die Teilnehmer der Studie
charakterisieren zu können. Es geht nicht darum, Ihre Fähigkeiten zu bewerten.
Alle Antworten werden anonym behandelt. Es wird nicht möglich sein, Ihre Anga-
ben auf Ihre Person zurückzuführen. Zu jeder Frage werden Ihnen einige
Antwortmöglichkeiten vorgegeben. Bitte geben Sie die für Sie zutreffende Antwort
an.
Vielen Dank für Ihre Teilnahme!
A. Anhang
55
A.1.2 Einführung für die Rolle Softwarearchitekt
Herzlich Willkommen zu der Studie
„Lesen von Spezifikationen“!
In dieser Studie werden Ihnen zwei Spezifikationen zum Lesen gegeben. Sie ha-
ben dabei die Rolle des Entwicklers von einzelnen Komponenten und
Schnittstellen. Das heißt, Ihre Tätigkeit umfasst das Entwickeln aller Funktionali-
täten, die im Hintergrund laufen, sowie das Anbieten von Schnittstellen für
angrenzende Systeme und die Benutzeroberfläche. Die Oberfläche und alle grafi-
schen Elemente fallen nicht in Ihre Zuständigkeit.
Ihre Aufgabe im Rahmen dieser Studie ist es zunächst erste Entwürfe in Form
von Klassendiagrammen und Skizzen für die einzelnen Komponenten zu erstel-
len. Anschließend werden Ihnen einige Fragen zum Inhalt des Dokuments
gestellt, sowie nach Ihrer subjektiven Bewertung der Relevanz der darin enthalte-
nen Abschnitte.
Vorher werden Sie jedoch noch darum gebeten, einige Fragen zu Ihrem Hinter-
grund zu beantworten. Dies dient lediglich dazu, die Teilnehmer der Studie
charakterisieren zu können. Es geht nicht darum, Ihre Fähigkeiten zu bewerten.
Alle Antworten werden anonym behandelt. Es wird nicht möglich sein, Ihre Anga-
ben auf Ihre Person zurückzuführen. Zu jeder Frage werden Ihnen einige
Antwortmöglichkeiten vorgegeben. Bitte geben Sie die für Sie zutreffende Ant-
wort an.
Vielen Dank für Ihre Teilnahme!
A. Anhang
56
A.1.3 Einführung für die Rolle Tester
Herzlich Willkommen zu der Studie
„Lesen von Spezifikationen“!
In dieser Studie werden Ihnen zwei Spezifikationen zum Lesen gegeben. Sie ha-
ben dabei die Rolle des Testers und sollen für das im Dokument angegebene
System Testfälle ableiten, die die beschriebenen Anforderungen sicherstellen.
Dazu ist Ihre Aufgabe im Rahmen dieser Studie einige Testfälle (Setup, Eingabe,
Sollwert) zu entwickeln. Anschließend werden Ihnen einige Fragen zum Inhalt
des Dokuments gestellt, sowie nach Ihrer subjektiven Bewertung der Relevanz
der darin enthaltenen Abschnitte.
Vorher werden Sie jedoch noch darum gebeten, einige Fragen zu Ihrem Hinter-
grund zu beantworten. Dies dient lediglich dazu, die Teilnehmer der Studie
charakterisieren zu können. Es geht nicht darum, Ihre Fähigkeiten zu bewerten.
Alle Antworten werden anonym behandelt. Es wird nicht möglich sein, Ihre Anga-
ben auf Ihre Person zurückzuführen. Zu jeder Frage werden Ihnen einige
Antwortmöglichkeiten vorgegeben. Bitte geben Sie die für Sie zutreffende Ant-
wort an.
Vielen Dank für Ihre Teilnahme!
A. Anhang
57
A.1.4 Einführung für die Rolle Entwickler
Herzlich Willkommen zu der Studie
„Lesen von Spezifikationen“!
In dieser Studie werden Ihnen zwei Spezifikationen zum Lesen gegeben. Sie ha-
ben dabei die Rolle des Entwicklers und sollen das System entsprechend den
Anforderungen im Dokument implementieren. Dazu ist Ihre Aufgabe im Rahmen
dieser Studie zunächst MockUps (erste Entwürfe) für die Benutzeroberfläche, so-
wie Klassendiagramme für die wesentlichen Komponenten zu erstellen und
Testfälle (Setup, Eingabe, Sollausgabe) abzuleiten, die die gewünschte Funktio-
nalität prüfen. Anschließend werden Ihnen einige Fragen zum Inhalt des
Dokuments gestellt, sowie nach Ihrer subjektiven Bewertung der Relevanz der
darin enthaltenen Abschnitte.
Vorher werden Sie jedoch noch darum gebeten, einige Fragen zu Ihrem Hinter-
grund zu beantworten. Dies dient lediglich dazu, die Teilnehmer der Studie
charakterisieren zu können. Es geht nicht darum, Ihre Fähigkeiten zu bewerten.
Alle Antworten werden anonym behandelt. Es wird nicht möglich sein, Ihre Anga-
ben auf Ihre Person zurückzuführen. Zu jeder Frage werden Ihnen einige
Antwortmöglichkeiten vorgegeben. Bitte geben Sie die für Sie zutreffende Ant-
wort an.
Vielen Dank für Ihre Teilnahme!
A. Anhang
58
A.2 Fragebögen
A.2.1 Erster Fragebogen
Frage Antwortmöglichkeiten
1.1 Was ist Ihr Studien-
gang?
O Informatik
O Technische Informatik
O Informatik als Nebenfach
O Ich bin kein Student (mehr).
1.2 Was ist Ihr aktuelles
Studienziel?
O Bachelor
O Master
O Diplom
O Ich bin kein Student (mehr).
1.3 In welchem Semester
sind Sie?
O 1 O 4 O 7
O 2 O 5 O ≥ 8
O 3 O 6 O kein Student
1.4 Wie alt sind Sie? O ≤ 20 O 26-30 O 41-50
O 21-25 O 31-40 O > 50
1.5 Wie gut sind Ihre
Deutschkenntnisse?
O Sehr gut
O Gut
O Weniger gut
O Schlecht
1.6 Über wie viel Berufser-
fahrung im Bereich
Softwareentwicklung verfü-
gen Sie?
O Sehr viel (mind. 1 Jahr Vollzeit oder vergleichbar)
O Viel (mind. 1 Jahr Teilzeit-/ Hiwi-Job)
O Wenig (Hiwi-Job < 1 Jahr, kleiner Nebenjob oder
vergleichbar)
O Keine
1.7 Haben Sie schon ein-
mal nach einer
Spezifikation entwickelt?
O ja
O nein
1.8 Haben Sie bereits an
der Lehrveranstaltung
„Software-Projekt“ teilge-
nommen?
O ja
O nein
1.9 Haben Sie schon ein-
mal Klassendiagramme
erstellt?
O ja
O nein
A. Anhang
59
Frage Antwortmöglichkeiten
1.10 Wie gut kennen Sie
sich mit der Entwicklung
grafischer Benutzeroberflä-
chen (GUIs) aus?
O Sehr gut
O Gut
O Weniger gut
O Schlecht
1.11 Haben Sie schon ein-
mal Testfälle erstellt?
O ja
O nein
1.12 Welche Darstellungs-
form von Spezifikationen
bevorzugen Sie (unabhän-
gig von den Spezifikationen
dieser Studie)?
O ausgedruckt
O am Bildschirm
A. Anhang
60
A.2.2 Zweiter Fragebogen für die Spezifikation Set
Fragebogen II: SET
Sie haben es fast geschafft!
Schlussendlich werden Sie nun noch gebeten einige Fragen zu beantworten – zu-
nächst einige Fragen bezüglich des Inhalts der soeben gelesenen Spezifikation,
anschließend folgt Ihre Bewertung der Relevanz der einzelnen Abschnitte. Bei den
inhaltlichen Fragen werden jeweils drei Antwortmöglichkeiten vorgegeben, von de-
nen genau eine richtig ist. Wird keine oder mehr als eine Antwort angekreuzt, so wird
die Frage als falsch beantwortet gewertet.
Frage Antwortmöglichkeiten
2.1 Was passiert, wenn bei
den drei Karten, die der
Spieler im Einzelmodus an-
geklickt hat, kein Set
vorliegt?
(Mission des Projekts)
O Der Spieler muss drei Karten abgeben, sofern dies
möglich
ist.
O Dem Spieler werden drei Punkte abgezogen.
O Dem Spieler werden drei Punkte abgezogen und
er muss
drei Karten abgeben, sofern dies möglich ist.
2.2 Wer soll die Anwen-
dung nutzen?
(Rahmenbedingungen und
Umfeld)
O Die Anwendung soll hauptsächlich von jungen Nut-
zern
Verwendung finden. Dabei können keine technischen
Vorkenntnisse vorausgesetzt werden.
O Die Anwendung soll uneingeschränkt für jeden
nutzbar sein.
Entweder in Pausen zwischendurch oder im Rahmen
von
Spieleabenden.
O Die Anwendung ist hauptsächlich an ältere Nutzer
gerichtet,
da der intellektuelle Anspruch für Kinder zu hoch ist.
2.3 Was passiert beim Än-
dern des Spielernamens,
wenn ein Fehler vorliegt?
(Funktionale Anforderun-
gen)
O Dem Spieler wird ein vom System generierter
Name
zugewiesen.
O Wenn der Spielername 0 oder mehr als 20 Zeichen
umfasst,
wird eine Fehlermeldung ausgegeben.
O Der Spieler wird aufgefordert seinen Namen erneut
einzugeben.
A. Anhang
61
Frage Antwortmöglichkeiten
2.4 Können im Mehrspie-
lermodus mehrere Spieler
gleichzeitig ein Set markie-
ren?
(Funktionale Anforderun-
gen)
O Nein, jeder Spieler muss anzeigen, dass er ein Set
markieren
möchte. Dann ist diese Möglichkeit für alle anderen
Mitspieler gesperrt.
O Ja. Derjenige, der zuerst ein Set vollständig mar-
kiert hat,
bekommt die Punkte. Die Markierung des anderen
Spielers
wird wieder zurückgesetzt.
O Es gibt eine Einstellungsmöglichkeit, ob dies mög-
lich sein
soll oder nicht. In der Standardeinstellung ist es nicht
möglich.
2.5 Was sind die wichtigs-
ten Qualitätsaspekte für
den Kunden?
(Qualitätsanforderungen)
O Korrektheit, Usability, Portabilität, Wartbarkeit und
Zuverlässigkeit
O Zuverlässigkeit, Portabilität, Wiederverwendbarkeit,
Korrektheit und Flexibilität
O Usability, Zuverlässigkeit, Korrektheit, Integrität
und
Wartbarkeit
2.6 WENN die für den
Mehrspielermodus notwen-
dige Netzwerkverbindung
zwischen Server und Client
nicht hergestellt werden
kann oder nicht funktio-
niert, DANN …
(Probleme und Risiken)
O … wird es nicht möglich sein ein Spiel im Mehr-
spielermodus
zu spielen.
O … wird alternativ ein Mehrspielermodus an einem
PC
umgesetzt.
O … muss erneute Rücksprache mit dem Kunden ge-
halten
werden.
A. Anhang
62
Nun werden Sie noch gebeten, die Abschnitte der Spezifikation, die Sie soeben ge-
lesen haben mit einer Relevanz von Sehr wichtig bis Unwichtig zu bewerten. Als wie
wichtig ordnen Sie persönlich die in dem Abschnitt gegebenen Informationen für Ihre
Rolle ein?
Damit ist nicht die Relevanz allgemein im Projekt gemeint, sondern nur, ob Sie diese
Inhalte für die Ausführung der gesamten Tätigkeiten, die Ihre Rolle umfasst, benöti-
gen.
Für diese Fragen gibt es natürlich keine falschen Antworten.
Abschnitt
1 Mission des Projekts
Unterabschnitt Priorität
1.1 Erläuterung des zu lösenden Prob-
lems
O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
1.2 Wünsche und Prioritäten des Kun-
den
O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
1.3 Domänenbeschreibung O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
1.4 Maßnahmen zur Anforderungsana-
lyse
O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
2 Rahmenbedingungen und Umfeld
Unterabschnitt Priorität
2.1 Einschränkungen und Vorgaben O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
A. Anhang
63
Abschnitt
2.2 Anwender O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
2.3 Schnittstellen und angrenzende
Systeme
O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
3 Funktionale Anforderungen
Unterabschnitt Priorität
3.1 Use Case-Diagramm O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
3.2 Use Case-Beschreibungen O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
3.3 Technische Anforderungen O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
4 Qualitätsanforderungen
Unterabschnitt Priorität
4.1 Qualitätsziele des Projekts O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
4.2 Qualitätsprioritäten des Kunden O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
A. Anhang
64
Abschnitt
4.3 Wie Qualitätsziele erreicht werden
sollen
O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
Abschnitt Priorität
5 Probleme und Risiken O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
6 Optionen zur Aufwandsreduktion
Unterabschnitt Priorität
6.1 Mögliche Abstriche O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
6.2 Inkrementelle Arbeit O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
Abschnitt Priorität
7 Entwurf der grafischen Benutzerober-
fläche/ (GUI-)MockUps
O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
8 Glossar O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
9 Abnahmetestfälle O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
A. Anhang
65
Abschnitt
Kommentar
An dieser Stelle haben Sie die Möglich-
keit noch einen Kommentar
hinzuzufügen. Dieser kann beispiels-
weise Gründe für Ihre Bewertung
enthalten, welche Informationen Sie in
der Spezifikation für Ihre Rolle beson-
ders wichtig/ unwichtig fanden oder ob
Sie sich vielleicht noch weitere Anga-
ben, die nicht enthalten waren,
gewünscht hätten.
A. Anhang
66
A.2.3 Inhaltliche Fragen des zweiten Fragebogens der Spezifika-
tion Translate
Frage Antwortmöglichkeiten
2.1 Welche Sprachen soll
die Anwendung verarbeiten
können?
(Mission des Projekts)
O Englisch und Deutsch
O Es sollen weitere Sprachen hinzufügbar sein. Stan-
dard sind Englisch und Deutsch.
O Englisch, Deutsch, Spanisch und Französisch
2.2 Wer soll die Anwen-
dung nutzen?
(Rahmenbedingungen und
Umfeld)
O Die Anwendung soll Studenten Im Übungsbetrieb
von
Vorlesungen zur Verfügung stehen.
O Die Anwendung ist hauptsächlich an Studenten,
sowie Mitarbeiter der Universität zum Verfassen von
wissenschaftlichen Arbeiten gerichtet.
O Die Anwendung soll innerhalb von Unternehmen
die globale Kommunikation erleichtern. Aber auch
Studenten sollen das Tool nutzen können.
2.3 Auf welchen Webbrow-
sern soll die Anwendung
laufen?
(Rahmenbedingungen und
Umfeld)
O Chrome, Firefox, Safari, Internet Explorer ab Ver-
sion 10
O Chrome, Firefox, Safari, Opera
O Chrome ist der empfohlene Browser, auf dem die
Anwendung zur Abnahme laufen soll.
2.4 Welchen Spezialfall
gibt es bei der Angabe von
Gewichtungen?
(Funktionale Anforderun-
gen)
O Wenn gespeichert wird, obwohl keine Werte geän-
dert
wurden, erscheint eine entsprechende Meldung.
O Wenn keine ganzzahligen Werte eingegeben wer-
den,
erscheint eine Fehlermeldung.
O Wenn der Benutzer clientseitige Profilspeicherung
blockiert, behält die Anwendung die ursprüngliche
Gewichtung bei.
2.5 Wie werden die Quali-
tätsaspekte vom Kunden
priorisiert (Auflistung in ab-
steigender Reihenfolge)?
(Qualitätsanforderungen)
O Bedienbarkeit, Zuverlässigkeit, Korrektheit, Integri-
tät,
Wartbarkeit, Effizienz
O Bedienbarkeit, Integrität, Portabilität, Wartbarkeit,
Effizient, Korrektheit
O Korrektheit, Effizienz, Bedienbarkeit, Integrität,
Wartbarkeit, Portabilität
A. Anhang
67
Frage Antwortmöglichkeiten
2.6 Wie ist der Erfahrungs-
stand im Team bezüglich
des Play!-Frameworks?
(Probleme und Risiken)
O Die meisten Mitglieder haben schon einmal damit
gearbeitet.
O Die meisten Mitglieder haben keine Erfahrung da-
mit.
O Keins der Mitglieder hat bereits damit Erfahrung.
A. Anhang
68
A.3 Ergebnisdaten der Studie
A.3.1 Erster Fragebogen
A. Anhang
69
A.3.2 Zweiter Fragebogen
Frage Frage
2.1 Frage
2.2 Frage
2.3 Frage
2.4 Frage
2.5 Frage
2.6
Rolle Set_a
Set_d
Trans-late_a
Trans-late_d
Teil-neh-mer
Kompo-nenten
1. 002 3 2 3 1 3 3
2. 002 2 3 1 2 2 2
Tester 1. 003 1 2 1 3 3 2
2. 003 3 2 x 1 3 1
Kompo-nenten
1. 004 1 2 1 3 3 3
2. 004 2 2 3 1 3 1
UI-De-signer
1. 005 1 2 1 2 3 2
2. 005 1 2 3 3 3 1
Tester 1. 006 3 2 3 2 3 1
2. 006 1 2 x 3 3 2
Entwick-ler
1. 007 2 2 3 1 2 1
2. 007 1 2 2 3 3 3
Entwick-ler
1. 008 3 2 3 3 3 2
2. 008 2 2 1 3 3 1
UI-De-signer
1. 010 1 2 1 x x 2
2. 010 3 2 3 2 3 1
Entwick-ler 1. 011 3 2 3 1 3 1
Entwick-ler
1. 012 3 2 3 1 3 3
2. 012 1 2 1 2 3 2
Entwick-ler
1. 013 2 3 x x x x
2. 013 2 2 1 2 3 1
A. Anhang
70
A.3.3 Relevanzeinschätzungen der Teilnehmer
Abschnitte Teilneh-mer
1.1
1.2
1.3
1.4
2.1
2.2
2.3
3.1
3.2
3.3
4.1
4.2
4.3 5
6.1
6.2 7 8 9
002 1 2 2 3 1 2 1 3 4 3 2 2 2 4 2 2 4 4 4
002 1 1 3 4 2 2 3 3 4 2 2 1 2 4 3 2 4 4 4
003 2 3 2 4 2 1 3 1 1 1 1 1 1 3 4 4 1 2 4
003 1 2 2 4 2 3 3 2 1 2 3 3 3 4 4 4 2 3 1
004 1 1 2 3 3 4 1 1 2 2 1 2 1 3 2 3 3 2 1
004 1 2 1 4 3 3 1 1 1 2 2 2 2 3 2 1 4 2 1
005 1 1 1 2 1 1 3 3 1 3 2 1 2 2 2 2 1 1 2
005 1 2 2 2 2 1 3 3 1 3 2 2 3 3 3 3 1 3 2
006 1 1 3 3 3 2 4 1 1 3 1 1 3 4 2 4 3 4 3
006 2 1 3 4 3 2 4 2 1 4 1 1 3 4 3 4 4 4 4
007 2 1 3 4 2 1 2 3 1 2 3 3 2 4 2 2 1 4 1
007 1 2 3 4 1 2 3 2 1 2 3 3 3 3 2 2 1 4 1
008 2 1 2 3 2 3 1 1 1 3 3 1 2 2 3 2 1 4 2
008 2 1 2 4 2 3 1 2 2 1 1 1 3 1 3 2 2 4 3
010 2 2 2 4 2 2 3 1 2 2 2 2 2 3 2 2 1 4 4
010 2 1 3 3 2 3 2 1 1 3 2 2 3 3 2 3 1 4 4
011 1 3 3 4 3 3 3 2 1 3 2 2 2 3 2 3 1 4 1
012 1 2 3 4 2 2 3 4 2 2 3 3 2 3 2 3 2 3 3
012 1 1 2 4 2 2 2 4 2 2 3 3 3 3 2 2 2 3 3
013 2 2 3 3 1 1 1 1 1 1 1 2 2 3 3 2 1 3 3
013 1 2 2 3 2 1 2 2 1 2 2 2 2 3 3 2 1 3 3
A. Anhang
71
A.3.4 Lesezeiten der Abschnitte
Lesezei-ten [ms]
1.1 1.2 1.3
1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9
Teilneh-mer
002 7 21 249 88 4 9 29 3 11 26 12 0 2 1 1 2 1 0 0 2 0
002 17 10 41 204 1 6 8 4 15 10 1 0 4 2 12 3 0 0 0 3 0
003 5 14 144 111 14 4 57 14 9 18 87 7 59 51 6 17 6 2 1 3 0
003 20 31 57 120 11 23 30 26 14 8 190 0 17 6 43 16 5 1 0 6 4
004 10 9 145 56 11 2 22 26 32 54 213 0 19 15 13 29 21 15 1 17 2
004 24 25 26 140 16 22 5 6 30 107 134 9 8 1 4 9 1 22 0 5 1
005 6 3 168 45 3 11 16 4 3 6 163 1 22 37 5 9 3 2 0 1 0
005 21 24 47 192 1 2 6 15 9 2 264 2 52 6 13 4 1 0 0 13 1
006 7 4 127 41 7 8 30 14 14 22 273 0 0 0 0 0 0 0 0 0 0
006 0 6 23 62 6 10 8 7 24 16 230 3 72 6 11 13 2 2 0 3 0
007 9 7 112 40 1 5 48 7 9 18 236 1 4 2 0 0 0 0 1 4 0
007 3 4 20 24 7 2 4 10 21 26 240 7 28 3 7 11 2 0 0 3 0
008 8 2 237 62 1 6 22 10 3 21 155 8 13 5 5 5 14 0 4 2 0
008 4 1 7 6 2 4 11 6 14 58 226 6 6 1 3 17 2 0 0 1 0
010 3 1 174 60 0 3 2 1 0 5 261 0 0 0 0 0 0 0 0 0 0
010 10 13 62 306 1 32 20 28 32 81 29 0 2 1 1 6 1 0 4 2 1
012 11 10 274 26 5 6 34 5 7 20 128 6 15 17 8 14 13 5 1 4 0
012 8 3 34 127 8 16 14 12 15 17 24 6 25 4 16 18 8 8 0 4 1
013 0 1 97 73 1 2 14 6 2 17 119 1 33 7 1 2 1 0 2 4 2
013 16 8 23 128 1 3 2 0 1 65 109 1 2 0 0 4 2 0 0 2 1
011 12 2 86 64 5 2 19 6 6 17 353 6 23 8 8 14 13 0 4 4 5
A. Anhang
72
A.3.5 Übersicht über Leseintensitäten
0,000
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
10,000
1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9
Lese
zeit
/ Lä
nge
[s/
cm]
Abschnitt
relativer Durchschnitt der Lesezeiten: ausgedruckt
0,000
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
10,000
1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9
Lese
zeit
/ Lä
nge
[s/
cm]
Abschnitt
relativer Durchschnitt der Lesezeiten: am Bildschirm
0,000
1,000
2,000
3,000
4,000
5,000
6,000
7,000
1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9
Lese
zeit
/ Lä
nge
[s/
cm]
Abschnitt
relativer Durchschnitt der Lesezeiten: Set
A. Anhang
73
A.3.6 Übersicht über die Lesegeschwindigkeiten
0,000
2,000
4,000
6,000
8,000
10,000
12,000
14,000
16,000
18,000
20,000
1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9
Lese
zeit
/ Lä
nge
[s/
cm]
Abschnitt
relativer Durchschnitt der Lesezeiten: Translate
0
1
2
3
4
5
6
7
1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9
Ges
chw
ind
igke
it [
cm/s
]
Abschnitt
Geschwindigkeit: ausgedruckt
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9
Ges
chw
ind
igke
it [
cm/s
]
Abschnitt
Geschwindigkeit: am Bildschirm
A. Anhang
74
A.3.7 Übersicht über die durchschnittlichen Bewertungen
Bewertung der Rollen (1=sehr wichtig, 2=wichtig, 3=weniger wich-tig, 4=unwichtig)
Spezifikations- abschnitt
UI-Desig-ner
Software- architekt
Tes-ter
Entwickler Student
Entwickler erfahren
Entwickler gesamt
1.1 Erläuterung des zu lösenden Problems
1,50 1,00 1,50 1,75 1,25 1,50
1.2 Wünsche und Prio-ritäten des Kunden
1,50 1,50 1,75 1,25 1,75 1,50
1.3 Domänenbeschrei-bung
2,00 2,00 2,50 2,50 2,50 2,50
1.4 Maßnahmen zur Anforderungsanalyse
2,75 3,50 3,75 3,75 3,50 3,63
2.1 Einschränkungen und Vorgaben
1,75 2,25 2,50 1,75 1,75 1,75
2.2 Anwender 1,75 2,75 2,00 2,25 1,50 1,88
2.3 Schnittstellen und angrenzende Systeme
2,75 1,50 3,50 1,75 2,00 1,88
3.1 Use Case-Dia-gramm
2,00 2,00 1,50 2,00 2,75 2,38
3.2 Use Case-Beschrei-bungen
1,25 2,75 1,00 1,25 1,50 1,38
3.3 Technische Anfor-derungen
2,75 2,25 2,50 2,00 1,75 1,88
4.1 Qualitätsziele des Projekts
2,00 1,75 1,50 2,50 2,25 2,38
4.2 Qualitätsprioritäten des Kunden
1,75 1,75 1,50 2,00 2,50 2,25
4.3 Wie Qualitätsziele erreicht werden sollen
2,50 1,75 2,50 2,50 2,25 2,38
5 Probleme und Risi-ken
2,75 3,50 3,75 2,50 3,00 2,75
6.1 Mögliche Abstriche 2,25 2,25 3,25 2,50 2,50 2,50
6.2 Inkrementelle Ar-beit
2,50 2,00 4,00 2,00 2,25 2,13
7 MockUps 1,00 3,75 2,50 1,25 1,50 1,38
8 Glossar 3,00 3,00 3,25 4,00 3,00 3,50
9 Abnahmetestfälle 3,00 2,50 3,00 1,75 3,00 2,38
A. Anhang
75
A.3.8 Übersicht über die relativierten durchschnittlichen Lesezei-
ten der Abschnitte
Lesezeiten der Rollen, umskaliert auf 4 bis 1 (1=sehr intensiv gele-sen)
Spezifikations- abschnitt
UI-Desig-ner
Software- architekt
Tes-ter
Entwickler Student
Entwickler erfahren
Entwickler gesamt
1.1 Erläuterung des zu lösenden Problems
4,19 1,13 1,25 1,32 1,22 1,27
1.2 Wünsche und Prio-ritäten des Kunden
1,03 1,06 1,19 1,63 1,16 1,39
1.3 Domänenbeschrei-bung
3,08 1,44 1,38 2,26 2,14 2,20
1.4 Maßnahmen zur Anforderungsanalyse
2,89 2,99 2,93 3,72 3,34 3,53
2.1 Einschränkungen und Vorgaben
1,73 1,92 1,28 1,57 1,85 1,71
2.2 Anwender 1,66 1,98 1,47 2,11 2,52 2,31
2.3 Schnittstellen und angrenzende Systeme
1,88 1,35 1,51 1,82 2,55 2,18
3.1 Use Case-Dia-gramm
2,01 1,41 2,45 1,69 1,79 1,74
3.2 Use Case-Beschrei-bungen
2,58 3,15 2,29 2,17 3,12 2,64
3.3 Technische Anfor-derungen
3,62 2,64 2,23 1,54 2,07 1,81
4.1 Qualitätsziele des Projekts
2,48 3,18 1,76 2,80 2,36 2,58
4.2 Qualitätsprioritäten des Kunden
2,45 3,24 2,04 3,37 2,83 3,10
4.3 Wie Qualitätsziele erreicht werden sollen
3,31 2,77 2,33 3,40 2,96 3,18
5 Probleme und Risiken 3,94 3,53 3,43 3,75 3,62 3,68
6.1 Mögliche Abstriche 3,53 2,61 2,20 2,45 1,95 2,20
6.2 Inkrementelle Ar-beit
3,87 1,60 3,46 4,00 2,71 3,35
7 MockUps 2,74 3,84 3,65 2,67 3,24 2,96
8 Glossar 3,72 3,31 3,81 3,94 3,78 3,86
9 Abnahmetestfälle 3,56 3,08 2,86 4,00 3,08 3,54