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
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 angegebenen 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
iii
iv
Zusammenfassung
Anforderungsspezifikationen werden von vielen an der Entwicklung beteiligten Nutzern 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 Spezifikationsabschnitte 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 Spezifikationsabschnitte, sowie zwischen den Rollen nachweisen. Bei der Darstellungsform konnte
hingegen kein Effekt verzeichnet werden.
v
vi
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.
vii
viii
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
ix
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
x
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 Arbeitszeit und Ressourcen.
Hinzu kommt die Problematik, dass die Spezifikation aufgrund ihrer zentralen Rolle
eine wichtige Informations- und Kommunikationsquelle für sehr viele an der Entwicklung beteiligte Personen mit jeweils unterschiedlichem Informationsbedarf darstellt
(Gross12b). Für einen Usability Experten sind Benutzerbeschreibungen und Anwendungsgebiete beispielsweise besonders relevant. Angaben zum Altsystem hingegen
sind weniger von Interesse. Andere Rollen, wie Projektleiter oder Kunden haben wiederum 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 Hintergrund 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, abhä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 welche Darstellung bevorzugt wird. Dies erfolgt im Rahmen einer Eye Tracking Studie,
in der der Leseprozess verschiedener Benutzer mit unterschiedlichen Spezifikationen 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 Augenmerk 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 Bildschirm 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
1 Einleitung
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 gesamte 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. Schlussendlich werden die Resultate auf die Erreichung der Zielsetzung der Arbeit hin bewertet,
ihre Validität diskutiert und mögliche Schlussfolgerungen gezogen. Die erlangten Erkenntnisse werden zuletzt noch zusammengefasst und ein Ausblick über weitere
Möglichkeiten gegeben
2
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 welchen 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 bestimmten Zeitpunkt hinschaut, wie lange sie dort hinsieht und welchem Blickpfad die Augen
folgen. Damit hilft Eye Tracking Forschern dabei visuelle Aufmerksamkeit zu verstehen 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 aufnehmen. 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. Sakkaden 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 Wahrnehmungen, 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 Gesamtwort „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.
3
2 Grundlagen
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 Augenlider fixieren mussten, sind die heutigen Geräte deutlich komfortabler für die
Versuchsperson. Der Großteil der neuen Eye Tracker nutzt die Methode der Hornhautreflexion, 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 hochauflö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 Kalibrierung benötigt. Bei dieser wird die Versuchsperson dazu aufgefordert einen
bestimmte Punkt oder mehrere Punkte hintereinander zu betrachten. Diese Information 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 einem 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 Marktforschungsanalysen, 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 Anwendungsgebiete sind die Medizin oder auch immer mehr die Mensch-Computer4
2 Grundlagen
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 Fixation direkt betrachtet wurde, heißt das nicht zwangsläufig, dass der Nutzer es nicht
wahrgenommen hat. Andersherum bedeutet eine Fixation auf einem Objekt nicht gezwungenermaßen, dass die Person die visuellen Informationen auch wirklich
aufgenommen und verarbeitet hat. Dies ist insbesondere dann der Fall, wenn kognitiv 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 Fragebö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, sondern 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 Gerä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 anbringen 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 Versuchsperson getragen. Ein Beispiel für ein solches auch head-mounted Eye Tracker
genanntes Gerät sind die Eye Tracking Glasses 1 Wireless von SensoMotoric Instruments, die in der Studie dieser Arbeit verwendet wurden. Diese Brille wird auf
Abbildung 2.5 gezeigt. Sie kann entweder an eine mitgelieferte Aufnahmeeinheit (Recording 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).
5
2 Grundlagen
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 Quantifizierung, 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 entweder in geometrischen oder handgezeichneten Formen auf Screenshots des
Kamerabildes des Eye Trackers gezogen werden oder auf selbst erstellte Referenzbilder. 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 systematische 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 (Questions) aufgestellt, die das Messziel näher spezifizieren und angeben welche
Fragestellungen von den Messungen untersucht werden. Zu jeder Frage werden anschließ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 einmal anschaulich. Dort lässt sich auch der entsprechende Ablauf bei der Auswertung
entnehmen. Im Anschluss an die Definition der Ziele, Fragen und Metriken folgt demnach 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 definierten Hypothesen, Fragen und Messzielen analysiert werden. Daraufhin können
6
2 Grundlagen
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. Daher 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üngliche 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 Intervall 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 entweder 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 gemessenen Trend, wie den Unterschied zweier Mittelwerte auf Signifikanz testen. Ein
statistisch signifikantes Ergebnis ist dabei ein Ergebnis, bei dem die Wahrscheinlichkeit, 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 Wahrscheinlichkeit, 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 jeweiligen 𝛼- und 𝛽-Werte gewählt. Bei der Untersuchung, ob ein neues Medikament
die gleiche Wirkung zeigt wie das auf dem Markt bestehende, würde beispielsweise
7
2 Grundlagen
𝛼 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. Üblicherweise 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 anwendbar 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 gefä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 Übersicht 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 Beobachtungen 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-Korrelation 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 gemachten 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 überhaupt 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 interne 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 Validität genannt. Diese umfasst Faktoren, die beispielsweise durch den gewählten
Signifikanztest oder eine zu geringe Stichprobengröße entstehen können. Der beobachtete 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 Verallgemeinerungsmöglichkeiten der Studienergebnisse auf andere Sachverhalte und
wird durch die Wahl der Untersuchungsobjekte, -subjekte und der Umgebung beeinflusst. 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
8
2 Grundlagen
das Durchschnittsalter von Studenten bestimmen möchte und dafür Studenten in einer Erstsemesterveranstaltung befragt.
Einer schlechten Validität der Ergebnisse entgegen wirken die drei Experimentprinzipien 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 unterschiedlichen Erfahrungsstand haben. In dem Fall werden die Probanden dann in
zwei von der Erfahrung abhängige Gruppen aufgeteilt und anschließend wird der Effekt 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 Ausgeglichenheit 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 Schlussfolgerung zu erhalten (Wohlin00).
Abbildung 2.5: Experimentprinzipien (aus (Wohlin00) ins Deutsche übertragen)
9
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ängigen Spezifikationen behandelten. Jedoch führten erste einfache Suchanfragen,
bestehend aus Wörtern wie „Anforderungsmanagement“, „Spezifikationen“, „Software Engineering“, „Probleme“ und „Problemansatz“, „Lesbarkeit“, „Risiken“,
„Verbesserung“ und „Verbesserungsansatz“, „Kriterien“ oder „Studie“ zu keinen Ergebnissen, 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, beispielsweise 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 Engineering) (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 effizienten
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 Leser“ 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 anschließ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 Suchergebnisse 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 Software Engineering (IESE) im Rahmen eines Dissertationsverfahrens durchgeführt
hat. Sie haben damit den gleichen Ansatz der „sichtenbasierten Anforderungsspezifikation“ erforscht. Die Zielsetzung ihrer Arbeit war es, ebenfalls mithilfe empirischer
10
3 Verwandte Arbeiten
Studien und Literaturrecherchen fundiertes Wissen über die individuellen Informationsbedürfnisse der Rollen zu erhalten, die Spezifikationen nutzen. Dieses Wissen
sollte anschließend dazu verwendet werden, Sichten auf Anforderungsspezifikationen 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 Beantwortung 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:
Frage F1_1:
Untersuchung der Informationsbedarfe von Entwicklerrollen bezüglich der Nutzung von Softwareanforderungsspezifikationen (SAS)
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 Informationsbedarfen aus Sicht unterschiedlicher Entwicklerrollen gibt
Frage F2_1:
Gibt es einen Unterschied zwischen den Informationsbedarfen verschiedener Rollen?
Gibt es sogar einen Unterschied zwischen Personen mit
der gleichen Rolle?
Was sind Faktoren, die den Informationsbedarf von
Frage F2_3:
Entwicklungsingenieuren der gleichen Rolle beeinflussen?
Tabelle 3.1: Forschungsfragen des Fraunhofer IESE (übersetzt aus (Gross12b))
Frage F2_2:
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 Relevanz 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 Seiten Anhang mit Zusatzmaterial und war daher in drei Dokumente aufgeteilt
(Gross12b).
Mithilfe eines mobilen Eye Trackers wurden das Blickverhalten der Versuchsteilnehmer aufgezeichnet, sodass beobachtet werden konnte, welche Stellen im Dokument
besondere Aufmerksamkeit erlangten. Zusätzlich wurde der Ablauf mit einer externen Kamera gefilmt und es waren jeweils ein bis drei Beobachter anwesend, die den
Umgang mit der Spezifikation protokollierten. Neben dem „lauten Denken“ zur Bestimmung 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 zusätzlich Kommentare abgegeben werden sollten, warum einzelne Teile als relevant
11
3 Verwandte Arbeiten
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 Artefakttypen 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ünftige Studien der Hinweis gegeben, dass eine weitere Schwäche der Studie darin lag,
dass sich die Probanden die Situation der Analyse der Spezifikation vorstellen mussten. Daher wird empfohlen den Teilnehmern tatsächlich den Auftrag zu geben,
beispielsweise eine Architektur zu designen. Des Weiteren hat man bei der Auswertung der Daten festgestellt, dass die Informationen, die man aus dem „lauten
Denken“ ziehen konnte, die Methode des Eye Tracking praktisch überflüssig gemacht 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 Architekt. 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, Erstellen der Spezifikation bis hin zur Fertigstellung des Softwareprodukts für ein
Accountmanagementsystem zu durchlaufen (Gross12b). Bei den Teilnehmern handelte es sich um neun Bachelor Informatikstudenten und vier Diplom
Wirtschaftsingenieure mit Spezialisierung auf Informatik. Jeder von ihnen hatte bereits zuvor einen Kurs zur Vorstellung von wesentlichen Software Engineering
Methoden besucht, in der auch das TORE-Framework (Adam09), mit dem die Spezifikation erstellt wurde, vorgestellt wurde (Gross12b).
Im Anschluss an das dreimonatige Projekt bewerteten die Studenten die in der Anforderungsspezifikation 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 Informationen und nach Gründen für die Einschätzung umfasste, entsprach dem der Eye
Tracking Studie.
12
3 Verwandte Arbeiten
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 wichtig erachteten die Studenten Datenanforderungen, sowie Beschreibungen von
Aufgaben und Arbeitsweisen. Der Teil über die bisherige Arbeitsweise (as-is workflow) 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 TOREFramework (Adam09) nach dessen Ende in einem Fragebogen die vorgestellten Artefakt-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 getroffen 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 Teilnehmergruppe (Gross12a). Demnach wurden alle Artefakttypen als wichtig oder sehr
wichtig eingestuft. Die einzige Ausnahme bilden die Interaktions- und Domänendaten, 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 Usabilityexperten visuelle Repräsentationen im Vergleich zu textuellen Beschreibungen
generell bevorzugt werden. Jedoch konnte auch bei dieser Studie eine mögliche Gefä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 Datenerhebung 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 Darstellungsformen 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.
13
3 Verwandte Arbeiten
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 Studienergebnisse 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“ (Dillon92)) unterteilt. Ergebnismerkmale beziehen sich dabei auf das was ein Leser von
dem Text erhält. Das können Metriken wie aufgenommene Informationen, Wiedergabefä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 vorgenommen 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 Erkenntnisse 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 Lesegeschwindigkeit. 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 haben. Andere Studien konnten wiederum keinen signifikanten Unterschied zwischen
den beiden Darstellungsmedien bei der Lesegeschwindigkeit feststellen. Es wird daher 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 Rechtschreib- 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 Ergebnisse gefunden. Anders sieht es da bei Untersuchungen der Wiedergabefähigkeit
aus oder generell bei Aufgaben mit einem höheren visuellen und kognitiven Anspruch. 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 Darstellungsform 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 erklä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 Bildschirm. 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 haben. Beispiele sind das Untersuchen der Blickbewegungen oder der Navigation des
Lesers im Text (Dillon92).
14
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 Abbildung 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 festzustellen 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 durchgeführten Studien, insbesondere die Eye Tracking Studie. Bei der Planung wurden
daher die dort festgestellten Schwächen berücksichtigt.
Sichtenbasierte Anforderungsspezifikationen
Informationsbedarfe empirisch erheben
(UI-Designer, Softwarearchitekt, Tester, Entwickler)
Sichten auf Anforderungsdokumente
(z.B. toolbasiert)
Effizientere/ effektivere Nutzung sowie Erstellung
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 Anforderungsspezifikationen 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 werden. Dabei wird die Effizienz anhand der benötigten Zeit zum Auffinden relevanter
Informationen im Dokument bewertet. Durch die Entwicklung solcher sichtenbasierten Spezifikationen wird versucht Zeit und Ressourcen, also Kosten zu sparen, indem
15
4 Planung der Studie
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 weitestgehend 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 Entwicklungskonzepts 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 verschiedenen 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, Softwarearchitekten, 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 beinhaltet das Erstellen erster Entwürfe, über deren Umsetzung bis hin zum Herleiten
von Testfällen und deren Ausführung zur Sicherstellung der Anforderungen, sämtliche 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 Implementierung sämtlicher Funktionen, die das System bieten soll, also insbesondere der
funktionalen Anforderungen, zuständig. Außerdem fallen das Verwalten von involvierten 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 (Eckstein09). 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 Anforderungen 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 definieren, 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 entsprechenden Testfälle ausführt (Eckstein09). Diese Aufgabe hat besondere Priorität, da nur
so die gewünschte Funktionsweise gewährleistet werden kann.
16
4 Planung der Studie
In der Praxis werden Rollen unter Umständen auch durch mehrere Personen ausgefüllt oder eine Person übernimmt mehrere Rollen (Eckstein09). In dieser Studie hat
jedoch jede Person genau eine Rolle und innerhalb eines Durchlaufs mit einem Teilnehmer 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 natü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 Unternehmen, das eine bestimmte Softwarelösung wünscht. Im Falle von
Produktentwicklungen kann auch der Markt die Rolle des Kunden einnehmen (Versteegen03). Der Kunde wird entweder direkt vom Auftraggeber oder eine hierarchisch
tiefer gestellte Person des Fachgebiets vertreten (Günter13). Er tritt dabei als Vertragspartner auf, dessen Grundlage die Spezifikation ist. In dieser müssen alle
gewünschten Funktionalitäten und Eigenschaften enthalten sein, da sich im Zweifelsfall 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 Softwareunternehmens und ist zudem im Falle von Konfliktsituationen der verständige
Ansprechpartner für die Teammitglieder (Eckstein09). Darüber hinaus hat er die Gesamtverantwortung 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 Probanden 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 Informationsbedarf 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 Vergleichsmöglichkeiten der Resultate ermöglicht (Gross12b).
17
4 Planung der Studie
4.2 Fragen
Ausgehend von den Verbesserungs- und Messzielen wurden Fragen erarbeitet, dessen Betrachtung das Erreichen der Ziele ermöglicht. Im Anschluss wurden dazu
Metriken definiert, dessen Erfassung zur Beantwortung der Fragestellungen beitragen. Alle Ziele, Fragen und Metriken, sowie dessen Zusammenhänge sind in
Abbildung 4.2 dargestellt. In dieser Studie wurde die Metrikebene des GQM-Paradigmas in zwei Ebenen aufgespalten, um den Zusammenhang zwischen Metrik und
Fragestellung erkennbarer zu machen. Zu allen Metriken findet sich zudem eine ausführliche Beschreibung in Kapitel 4.3.
Verbesserungsziele
Effizienzsteigerung bei der Nutzung von Spezifikationen im
Kontext von Softwareprojekten
aus der Perspektive von UI-Designern, Architekten und
Testern
Untersuchung des Informationsbedarfs
der Nutzer von Spezifikationen unter
Berücksichtigung dessen Rolle und
dem Darstellungsmedium
Messziele
Fragen
Zwischenmetriken
Metriken
Effektivitätssteigerung bei der
Erstellung von Spezifikationen
im Kontext von Softwareprojekten aus der Perspektive von
Anforderungsingenieuren
F1: Welche Darstellungsform
(ausgedruckt oder
am Bildschirm) ist
geeigneter?
Vorliebe
des Lesers
Fragebogen
F3: Gibt es Unterschiede
innerhalb der
Rollen? (rollenabhängig)
F2: Welche Abschnitte sind
besonders wichtig/
unwichtig? (rollenabhängig)
Wiedergabefähigkeit
Gesamtlesezeit
Geschwindigkeit
Länge der
Spezifikationsabschnitte in
Zentimetern
Abbildung 4.2: Übersicht über Ziele, Fragen und Metriken
18
Relevanz
Intensität
des Lesens
einzelner
Abschnitte
Lesezeiten
für AOIs auf
Abschnitten
4 Planung der Studie
Zu jeder Frage werden im Anschluss überblicksartig die verwendeten Untersuchungsobjekte, 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 Abschnitte
Hypothese
HA2_1: Die Abschnitte werden unterschiedlich bewertet.
F3: Unterschiede zwischen den Rollen
Frage
Gibt es Unterschiede zwischen den Informationsbedarfen einzelner Rollen?
Objekt
Spezifikationen
Zwischenmetrik
Priorisierung des Lesers
Hypothese
HA3_1: Bei mindestens zwei Rollen unterscheiden sich die Mittelwerte der Relevanzbewertung.
HA3_2: Wichtig bewertete Abschnitte werden intensiver gelesen 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 Skalentyp es sich handelt.
19
4 Planung der Studie
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 ausgedruckt 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 unwichtig 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 gemessen. 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 werden. 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ängen der Abschnitte relativiert. So erhält man die entsprechenden Leseintensitäten in
der Einheit s/cm (Sekunden pro Zentimeter). Die Messung der Lesezeiten und Abschnittslängen erfolgt auf einer Verhältnisskala (ratio scale).
20
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 Spezifikationen, 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 Fachgebiets 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 einen 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 Rollen 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 konkrete 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 Teilnehmern 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 sichtbar 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 Serververbindung 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 Übersetzungsanwendung. 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 Übersetzungsmöglichkeiten, sowie Synonyme ausgibt. Die Übersetzung erfolgt vom
Deutschen ins Englische oder anders herum. Alle Ergebnisse werden dabei gegebenen Übersetzungswebseiten, wie z.B. dict.leo.org oder translate.google.de,
entnommen. Dem Nutzer ist es zudem möglich weitere Onlinewörterbücher hinzuzufügen und sie mit einer Gewichtung zu bewerten. Beide Spezifikationen kamen
einmal in digitaler und einmal in ausgedruckter Form zum Einsatz. Ausgedruckt wurden 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.
21
5 Vorbereitung der Studie
Spezifikationstemplate
Softwareprojekt, Leibniz Universität Hannover
1
2
3
4
5
6
7
8
9
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
Rahmenbedingungen und Umfeld
2.1 Einschränkungen und Vorgaben
2.2 Anwender
2.3 Schnittstellen und angrenzende Systeme
Funktionale Anforderungen
3.1 Use Case-Diagramme
3.2 Use Case-Beschreibungen
3.3 Technische Anforderungen
Qualitätsanforderungen
4.1 Qualitätsziele des Projekts
4.2 Qualitäts-Prioritäten des Kunden
4.3 Wie Qualitätsziele erreicht werden sollen
Probleme und Risiken
Optionen zur Aufwandsreduktion
6.1 Mögliche Abstriche
6.2 Inkrementelle Arbeit
MockUps
Glossar
Abnahme-Testfälle
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 Vorteil 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 Informatikstudenten 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 Bachelorstudium. 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 haben alle Testpersonen vorher schon einmal nach einer Spezifikation entwickelt oder
22
5 Vorbereitung der Studie
sind zumindest in der Lehrveranstaltung „Software-Projekt“ damit in Berührung gekommen.
Bei den drei Probanden, die keine Informatikstudenten (mehr) sind, handelt es sich
um erfahrene Entwickler. Einer von ihnen arbeitet als Produktmanager und Entwickler 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 Integrationsarchitekt. 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 verwendet 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 entweder 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 ausgedruckten Exemplare gesammelt. Die Datenerfassung erfolgt dabei komplett
anonym. Das heißt, die Angaben von jedem Teilnehmer werden mit einer Teilnehmer-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ändigt 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 Relevanzeinschä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 Abschnitten „Rahmenbedingungen und Umfeld“, sowie „Funktionale Anforderungen“
enthalten sind und dazu noch jeweils eine Frage zu den Kapiteln „Qualitätsanforderungen“ 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übergreifend verglichen werden, verunsichert die Probanden jedoch nicht so sehr.
Beide Fragebögen sind während der Studie zweimal zu beantworten – einmal ausgedruckt bei dem Durchlauf mit den Eye Tracking Glasses und einmal am PC bei
23
5 Vorbereitung der Studie
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 Fragen 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 beispielsweise 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 auszugleichen, 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öglichkeit 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 Lesen 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 Randomisierung eingehalten wird.
5.4.2 Blocking
Eine angepasste Version des Blocking-Ansatzes wird in diesem Fall insofern angewandt, 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.
24
5 Vorbereitung der Studie
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 Anzahl 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 untersucht.
Die einzige Abweichung von diesem Designprinzip liegt bei den Aufnahmen der erfahrenen 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 beantwortet und nimmt daher eine Sonderrolle ein. Diese Abweichung hat jedoch keine
weitreichenden Konsequenzen und wurde bei den entsprechenden Tests in der Auswertung 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 zufä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 angegeben. 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. Abschließ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 Vergleichswert 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.
25
5 Vorbereitung der Studie
Teilnehmer
Spezifikationen
Set_a
Set_d
Translate_a
Rolle
Translate_d
002
1.
2.
Softwarearchitekt
003
2.
1.
Tester
004
005
2.
1.
2.
Softwarearchitekt
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
013
1.
2.
2.
1.
Entwickler (mit
Erfahrung)
Entwickler (mit
Erfahrung)
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 Reihenfolge 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älligkeiten 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 zunä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 allgemeine 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 Einflü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 konzentrieren 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 darauf 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 davon ab, ob mit der ausgedruckten oder der am Bildschirm gelesenen Spezifikation
26
5 Vorbereitung der Studie
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 hingewiesen, 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 Tracking 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 Aufnahme 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 Experiment 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 abgelaufen, 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
27
6 Durchführung der Studie
Die Studie konnte weitestgehend entsprechend des vorgesehen Ablaufs durchgefü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 komplett 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 Kunden“, 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 Aspekte 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 Beobachtungen 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 beurteilen, 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 Kalibrierung 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 Aufnahmeprogramm 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 Durchhaltevermö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.
28
6 Durchführung der Studie
Änderung 2: Wiederholung von Durchläufen
Des Weiteren wurden die folgenden zwei Durchläufe aus Tabelle 7.1 nochmals wiederholt und aus der Menge an auszuwertenden Daten entfernt, da die
Vergleichsmöglichkeit der Daten bzw. deren Validität gefährdet war.
Teilnehmer
Spezifikationen
Set_a
Rolle
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 Teilnehmern 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 Darstellung 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ährend 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 weniger 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 Brillenrahmen 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.
29
7 Analyse und Interpretation
In diesem Kapitel folgt eine formale Analyse der Daten. Diese umfasst die Beschreibung 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 Aufnahmedaten zunächst in die gewünschte auswertbare Form gebracht werden. Dazu wurden
die Ergebnisse der Fragebögen in Exceltabellen übertragen und die Anzahl an richtigen Antworten bei den inhaltlichen Fragen, die Anzahl an Stimmen für die jeweiligen
Darstellungsformen und die durchschnittlichen Bewertungen der Relevanz der Spezifikationsabschnitte 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ätzlichen Rand zum Ausgleich eventueller Ungenauigkeiten des Eye Trackers ein
rechteckiger AOI gezogen. Anschließend konnte für jeden Teilnehmer die entsprechende Lesedauer abgelesen und in die passende Tabelle übertragen werden.
Für die Auswertung der Daten der Eye Tracking Glasses musste noch ein zusätzlicher 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 verwendeten 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. Anschließ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 Teilnehmer den Fragebogen nicht richtig verstanden hat oder nicht ernsthaft genug an
der Studie teilgenommen hat, wenn er bei den inhaltlichen Fragen mehrere Antwortmö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 geprüft. Dies erfolgte über eine graphische Darstellung der Stichprobendaten, um sich
einen Überblick über deren Verlauf verschaffen zu können. Anschließend wurde festgestellt, 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
30
7 Analyse und Interpretation
Intervalle tragen keine Beschriftung, da es sich dabei um das Deckblatt und das Inhaltsverzeichnis 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 dabei nach der zugehörigen Fragestellung gruppiert.
7.3.1 F1: Darstellungsform
Zur Beantwortung der Frage, ob die ausgedruckte oder digitale Darstellung geeigneter 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 betrachtet.
M1: Präferenz des Lesers
Um herauszufinden, ob ausgedruckte oder am Bildschirm angezeigte Spezifikationen 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
31
7 Analyse und Interpretation
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 formuliert.
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 herauszufinden, 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.
wobei 𝐹̂ =
xa1
xd1 +1
𝐹̂ ≥ 𝐹𝑣1 ;𝑣2;0,05
und 𝑣1 = 2(xd1 + 1), 𝑣2 = 2 ∗ xa1
𝑣1 = 2(4 + 1) = 10, 𝑣2 = 2 ∗ 7 = 14
7
𝐹̂ =
= 1,4 ≱ 𝐹10;14;0,05 = 2,6
4+1
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 ausgedruckte Variante beim Vergleich mit lediglich am Bildschirm angezeigten PDFSpezifikationen 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 Vergleich 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
32
7 Analyse und Interpretation
Der Arbeitshypothese HA2_2 entgegen wird zur Überprüfung die Nullhypothese formuliert.
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.
wobei 𝐹̂ =
xa2
xd2 +1
𝐹̂ ≥ 𝐹𝑣1 ;𝑣2;0,05
und 𝑣1 = 2(xd2 + 1), 𝑣2 = 2 ∗ xa2
𝑣1 = 2(37 + 1) = 76, 𝑣2 = 2 ∗ 40 = 80
40
𝐹̂ =
= 1,05 ≱ 𝐹76;80;0,05 = 1,53
37 + 1
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ängig 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 Lesegeschwindigkeit 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 Spezifikation 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, werden die Teilnehmer bei ihr vermutlich mit einer anderen Geschwindigkeit gelesen
haben. Um die resultierende erhöhte Varianz innerhalb der Messgruppen auszugleichen, 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 Versuchsbedingungen 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 durchgeführt wird.
33
7 Analyse und Interpretation
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 bekommt 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 Rangsummen 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 jeweiligen 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 getestet, 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.
34
7 Analyse und Interpretation
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.
∑4𝑖=1(𝑥𝑖 − 𝑥̅ )2
> 𝜒 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
̂2 =
𝜒
Der zu überschreitende Grenzwert 𝜒 2 3;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 werden 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 Teilnehmer 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 Projektabhä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 welche 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 (unwichtig)
Für diese Rollen und Abschnitte wird die Nullhypothese auf dem 5%-Niveau abgelehnt. 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 Abschnitt 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-Verteilung 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 Vergleichsvariante konnte bei den anderen drei Rollen nicht verwendet werden, da dort
die Teilnehmeranzahl pro Rolle nicht ausreicht, um signifikante Ergebnisse zu erhalten.
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“.
35
7 Analyse und Interpretation
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 abgelehnt 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 zweiseitigen 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 einzelnen 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 werden, 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 nebenbei 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
36
7 Analyse und Interpretation
den gleichen Umständen, also auch beim Lesen derselben Spezifikationen aufgenommen 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 tendenziell 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 hindeutet und anders herum. Dies erfolgt mit der folgenden Formel.
𝑃(𝑥)
𝑖𝑠 (𝑥) = 5 − (
∗ 3 + 1)
|𝑋|
s
wobei 𝑖𝑠 (𝑥): skalierte Intensität der Leseintensität x in 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 zwischen den Mittelwerten der Bewertungen für die einzelnen Abschnitte und Rollen
maximal um 1,0 abweicht. Andernfalls, wird dies als Hinweis erachtet, dass Bewertung 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önnen. Nicht beachtet werden dabei Abweichungen bei den Abschnitten „MockUps“,
sowie „Abnahmetestfälle“, da diese wie in Abschnitt 5.1 beschrieben aus den Spezifikationen entfernt wurden und daher natürlich nicht intensiv gelesen werden
konnten.
Bei der derartigen Analyse der Daten konnten folgende Abweichungen zwischen Bewertung 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)
37
7 Analyse und Interpretation

Entwickler: Use Case-Beschreibungen (1,38 – 2,64), Inkrementelle Arbeit
(2,13 – 3,35)
Die vergleichsweise geringen Abweichungen beim Abschnitt „Domänenbeschreibungen“ 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 ungenau ist. Außerdem ist die Wahrscheinlichkeit, dass ein „leerer Blick“, also ein
Anschauen eines Punktes ohne Verarbeitung der aufgenommenen visuellen Informationen auf so einen kurzen Abschnitt trifft, relativ gering. Die Abweichungen
werden daher nicht als maßgeblich erachtet. Ebenso verhält es sich bei den Abschnitten „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 haben. 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 daher 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 Leseintensität (M7) untersucht, ob es signifikante Unterschiede zwischen den Rollen gibt.
Damit wird festgestellt, ob eine Definition von unterschiedlichen Sichten auf Anforderungsdokumente 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 notwendigen 𝐹𝑣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.
38
8 Reflektion zu Studien mit Eye Tracking
Nachdem die Planung, Vorbereitung und Durchführung der Studie, sowie die Analyse 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 Aufwand 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 festgelegt, wie viele Kalibrierungspunkte aufgenommen werden sollen. Diese ist
standardmäßig auf 1-Punkt-Kalibrierung gesetzt. Bei dem Erstellen eines neuen Experiments kann man diese Einstellungen für alle Aufnahmen gemeinsam festlegen
und zusätzlich noch Eigenschaften („Properties“) erstellen, die dann für jeden Teilnehmer 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 nachdem, wie viele Abschnitte dieses umfasst, ist die Vorarbeit dementsprechend
zeitaufwändig. In jedem Fall wird zu Beginn ein Experiment erstellt, in das man verschiedene Stimuli, wie z.B. Bilder, Text, Fragen, PDF-Dokumente oder Webseiten
einfügen kann. Jeder Stimulus hat dabei je nach Art unterschiedliche Editierungsmö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 Aufnahme starten, wobei jedem Teilnehmer ein individueller Name gegeben werden
kann, über den die Daten letztendlich zu finden sind.
39
8 Reflektion zu Studien mit Eye Tracking
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 angeschlossene 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 zurü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 Trackern 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 Brillenkamera, 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 einzelnen 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 anschließend genau ausgewertete Daten, wie die jeweilige Blickdauer oder die
durchschnittliche Anzahl an Fixationen anzeigen lassen. Auch andere Auswertungsmöglichkeiten, wie z.B. Heat Maps lassen sich nun nutzen.
40
8 Reflektion zu Studien mit Eye Tracking
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 daher 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 statisches 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 dafü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 Lesegeschwindigkeiten 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 Messmethoden ausreichend oder geeigneter sind.
41
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, jeweils 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 Resultate, 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 ausgedruckte 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 Antworten 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 Geschwindigkeiten der Größe nach geordnet paarweise gegenübergestellt. Die Länge
der Balken gibt auf der y-Achse die jeweilige Gesamtgeschwindigkeit für das Dokument an. Anhand der Daten lässt sich der Trend erkennen, dass am Bildschirm
angezeigte Spezifikationen tendenziell schneller gelesen werden, es lässt sich jedoch nicht nachweisen, dass diese Unterschiede nicht zufällig sind.
Geschwindigkeit: Translate
1,40
1,20
1,00
0,80
0,60
0,40
0,20
0,00
1
2
3
4
5
Wertepaare nach Größe sortiert
ausgedruckt
Geschwindigkeit [cm/s]
Geschwindigkeit [cm/s]
Geschwindigkeit: Set
1,00
0,80
0,60
0,40
0,20
0,00
1
2
3
4
5
Wertepaare nach Größe sortiert
am Bildschirm
ausgedruckt
Abbildung 9.1: Geschwindigkeitsübersichten der Spezifikationen
42
am Bildschirm
9 Auswertung und Schlussfolgerung
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 untersucht und anschließend die erkennbaren Trends mit den Leseintensitäten der
Abschnitte verglichen. Bei der Betrachtung der Bewertungen der Wichtigkeit der Abschnitte ergaben sich die in Abbildung 9.2 dargestellten Werte. In der linken Spalte
sind die einzelnen Abschnitte der Spezifikation dargestellt. In den vier Spalten daneben 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 Tabelle 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ßnahmen 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 Problems“ 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, wobei keine auffälligen Unterschiede gefunden werden konnten, was die Aussagekraft
der Bewertungen bestätigt.
43
9 Auswertung und Schlussfolgerung
Bewertung der Rollen
SpezifikationsSoftwareUI-Designer
Tester
abschnitt
architekt
1.1 Erläuterung des zu lösenden
1,50
1,00 (*)
1,50
Problems
1.2 Wünsche und Prioritäten des
1,50
1,50
1,75
Kunden
1.3 Domänenbeschreibung
2,00
2,00
2,50
1.4 Maßnahmen zur
2,75
3,50
3,75
Anforderungsanalyse
2.1 Einschränkungen und
1,75
2,25
2,50
Vorgaben
2.2 Anwender
1,75
2,75
2,00
2.3 Schnittstellen und
2,75
1,50
3,50
angrenzende Systeme
3.1 Use Case-Diagramm
2,00
2,00
1,50
3.2 Use Case-Beschreibungen
1,25
2,75
1,00 (*)
3.3 Technische Anforderungen
2,75
2,25
2,50
4.1 Qualitätsziele des Projekts
2,00 (*)
1,75
1,50
4.2 Qualitätsprioritäten des
1,75
1,75
1,50
Kunden
4.3 Wie Qualitätsziele erreicht
2,50
1,75
2,50
werden sollen
5 Probleme und Risiken
2,75
3,50
3,75
6.1 Mögliche Abstriche
2,25
2,25
3,25
6.2 Inkrementelle Arbeit
2,50
2,00
4,00 (*)
7 MockUps
1,00 (*)
3,75
2,50
8 Glossar
3,00
3,00
3,25
9 Abnahmetestfälle
3,00
2,50
3,00
1 = "sehr wichtig", 2 = "wichtig", 3 = "weniger wichtig", 4 = "unwichtig"
(*) = statistisch signifikant auf dem 5%-Niveau
Abbildung 9.2: Durchschnittliche Bewertungen der Rollen
Entwickler
gesamt
1,50 (*)
1,50 (*)
2,50
3,63 (*)
1,75 (*)
1,88
1,88
2,38
1,38 (*)
1,88 (*)
2,38
2,25
2,38
2,75
2,50
2,13 (*)
1,38 (*)
3,50 (*)
2,38
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 Stichprobengröß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, Softwarearchitekten 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 generieren.
44
9 Auswertung und Schlussfolgerung
9.2 Vergleich mit einschlägigen Studien
Die Ergebnisse der Studie wurden nach deren Ermittlung und Überprüfung mit ähnlichen 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 Papier 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 Verhä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 Rahmen 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 Bildschirm feststellen (Dillon92). Die Teilnehmer der Studie haben hingegen mehrheitlich
für die ausgedruckte Fassung gestimmt, die jedoch nicht als signifikant nachgewiesen 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 festgestellt werden, dass diese darauf hindeuten, dass sich das Lesen von
Spezifikationen nicht mit dem Lesen herkömmlicher Texte vergleichen lässt. Aufgrund 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 behandelten ebenfalls den Ansatz für verschiedene Rollen eine eigene Sicht auf
Anforderungsdokumente zu generieren. Die verwendeten Spezifikation wurden jedoch mit dem TORE-Framework (Adam09) erstellt und damit nicht nach dem
Template der Spezifikationen dieser Studie. Darüber hinaus wurden dort nur die Rollen 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 durchschnittlichen Bewertungen der vergleichbaren Artefakte sind in Abbildung 10.3
gezeigt. Die Farben und Bewertungen wurden dabei genauso abgebildet, wie in Abbildung 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
45
9 Auswertung und Schlussfolgerung
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 Fraunhofer IESE Studien nicht bekannt sind. Für alle Differenzen zusammen ergibt der tTest für paarweise angeordnete Messwerte jedoch keinen statistisch signifikanten
Unterschied auf dem 5%-Niveau.
Abschnitt
nach TORE
Bewertungen
Bewertungen nach TORE dieser Studie
Abschnitt
nach SWP-Template
UISoftwareAS
AE
UE
UT
Designer
architekt
Descriptions
Anwender
2,46
2
1
1,78
1,75
2,75
of Stakeholders
Descriptions of
Erläuterung des zu
2,31
1
2
1,5
1,5
1
Stakeholder Goals
lösenden Problems
Descriptons of
Domänen2,69 1,5
2
2,78
2
2
Domain Data
beschreibung
Descriptions of
Qualitätsziele des
Quality Attributes/
Projekts bzw. Quali1,58 1,5
2
1,875
1,75
NFRs
tätsziele des Kunden
Descriptions of
Technische
1,77
1
2,5
2,75
2,25
Technical Constraints Anforderungen
AS: Architekten der SE-Projekt Studie, AE: Architekten der Eye Tracking Studie, UE: Usabilityexperten der Eye Tracking Studie, UT: Usability der Tutorial Studie, NFRs: nichtfunktionale
Funktionsanforderungen
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, Softwarearchitekt 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-Beschreibungen. 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 Anforderungen“,
„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ätzung nicht ausreichte, um statistisch signifikante Aussagen treffen zu können, sind
weitere Studien nötig, um empirisch fundiert deren Wichtigkeit für die einzelnen Rollen beurteilen zu können.
46
9 Auswertung und Schlussfolgerung
Um eventuelle Varianzen innerhalb der Rollen auszugleichen ist es darüber hinaus
sinnvoll, dass das entsprechende Tool, das rollenabhängige Sichten auf Anforderungsspezifikationen 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 betrachteten Kriterien Präferenz der Leser, Lesegeschwindigkeit, sowie Wiedergabefähigkeit
hätte, da dort auf dem 5%-Niveau keine signifikanten Effekte nachgewiesen werden
konnten.
47
10 Einschränkungen der Validität
Eine wichtige Frage bei dem Durchführen einer Studie ist die Validität der Ergebnisse. 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 Resultate 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 gleiche Signifikanzniveau von 5% verwendet wurde. Auch Einschränkungen, wie
maximal zulässige oder minimal notwendige Stichprobengrenzen wurden berücksichtigt.
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 Tatsache, 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“ verglichen 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 wurden 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 Fragebö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 Darstellungsmedien. Das wurde jedoch umgangen, indem mittels Blockingverfahren die
verwendeten Spezifikationen getrennt analysiert wurden. Somit verfügt die Studie
über eine hohe interne Validität.
48
10 Einschränkungen der Validität
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 Teilnehmer 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 entnommen 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 Informatiker teilgenommen haben, die bereits erste Erfahrungen in der Entwicklung von
Softwareprodukten haben, lassen sich die Ergebnisse auf jeden Fall auf akademische 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.
49
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. Dabei 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 Anforderungsspezifikationen enthaltenen Informationen für die Rollen UI-Designer, Softwarearchitekt,
Tester und Entwickler unterschiedlich relevant sind und es zu dem signifikante Unterschiede 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 rollenabhä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 Herausfiltern 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 gestellt 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 Textinhalte 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 Bewertungen der Abschnitte die Signifikanz der Ergebnisse nachgewiesen werden.
Hierfür sind weitere Untersuchungen nötig. Dazu ist es zu empfehlen auch Anforderungsspezifikationen größerer Projekt, sowie andere Templates und Frameworks zu
betrachten, um möglichst umfassende Kenntnisse über den Zusammenhang zwischen 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 Unterschied zu den Rollen der direkt an der Entwicklung beteiligten Rollen vermutet wird.
Diese benötigen jedoch aufgrund der umfassenden Tätigkeiten größere Stichproben, 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 Kosten- und Zeitersparnis gesehen.
50
Literaturverzeichnis
(Adam09) Sebastian Adam, Joerg Doerr, Michael Eisenbarth, Anne Gross: Using
Task-oriented Requirements Engineering in Different Domains – Experience of Application 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 Framework for Systematic Requirements Development in Information Systems, In:
Requirements Engineering Magazine, Ausgabe 04/2014
(Brau11) Henning Brau, Andreas Lehmann, Kostanija Petrovic, Matthias C. Schroeder: 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.verlag, 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: Messprogramm 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 Requirements Specifications, In: IEEE TwinPeaks 2012, Chiacgo, Illinois, USA, 2012
(Gross12d) Anne Gross, Steffen Hess: Was erwarten Usability Experten von Anforderungsdokumenten?, 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 – Concept of Operations (ConOps) Document, In: IEEE Standard 1362-1998, 1998
51
Literaturverzeichnis
(IEEE98b) IEEE: IEEE Recommended practice for Software Requirements Specifications, In: IEEE Standard 830-1998, 1998
(Lemke14) Michael Lemke: Sind wir wirklich reif für E-only? Nutzerbedarf und Leseverhalten als Kriterien einer monographischen Erwerbungspolitik an
wissenschaftlichen Bibliotheken, In: Perspektive Bibliothek, Band 3, Nr. 2, 2014, S.743
(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: Springer-Verlag, Berlin, 1993
(Schall14) Andrew Schall, Jennifer Romano Bergstorm: Eye Tracking in User Experience Design, In: Elsevier, Morgan Kaufmann, 2014
(Schmidts07) Hermann Schmidts: Usability-Evaluation: Eine Studie zur Identifizierung 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/products/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, Christian Missling, Renate Stücka: Anforderungsmanagement, In: Springer-Verlag, Berlin,
2003
(Wohlin00) Claes Wohlin, Per Runeson, Martin Höst, Magnus C. Ohlsson, Björn Regnell, 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/Reading_Fixations_Saccades.jpg (letzter Zugriff: 13.08.15)
52
A. Anhang
53
A. Anhang
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 haben 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 erstellen. 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 Hintergrund 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 Angaben 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!
54
A. Anhang
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 haben dabei die Rolle des Entwicklers von einzelnen Komponenten und
Schnittstellen. Das heißt, Ihre Tätigkeit umfasst das Entwickeln aller Funktionalitäten, die im Hintergrund laufen, sowie das Anbieten von Schnittstellen für
angrenzende Systeme und die Benutzeroberfläche. Die Oberfläche und alle grafischen 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 erstellen. 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 Hintergrund 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 Angaben 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!
55
A. Anhang
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 haben 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 Hintergrund 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 Angaben 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!
56
A. Anhang
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 haben 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, sowie Klassendiagramme für die wesentlichen Komponenten zu erstellen und
Testfälle (Setup, Eingabe, Sollausgabe) abzuleiten, die die gewünschte Funktionalitä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 Hintergrund 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 Angaben 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!
57
A. Anhang
A.2 Fragebögen
A.2.1 Erster Fragebogen
Frage
Antwortmöglichkeiten
1.1 Was ist Ihr Studiengang?
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?
1.4 Wie alt sind Sie?
1.5 Wie gut sind Ihre
Deutschkenntnisse?
O1
O4
O7
O2
O5
O≥8
O3
O6
O kein Student
O ≤ 20
O 26-30
O 41-50
O 21-25
O 31-40
O > 50
O Sehr gut
O Gut
O Weniger gut
O Schlecht
1.6 Über wie viel Berufser- O Sehr viel (mind. 1 Jahr Vollzeit oder vergleichbar)
fahrung im Bereich
O Viel (mind. 1 Jahr Teilzeit-/ Hiwi-Job)
Softwareentwicklung verfüO Wenig (Hiwi-Job < 1 Jahr, kleiner Nebenjob oder
gen Sie?
vergleichbar)
O Keine
1.7 Haben Sie schon einmal nach einer
Spezifikation entwickelt?
O ja
1.8 Haben Sie bereits an
der Lehrveranstaltung
„Software-Projekt“ teilgenommen?
O ja
1.9 Haben Sie schon einmal Klassendiagramme
erstellt?
O ja
O nein
O nein
O nein
58
A. Anhang
Frage
Antwortmöglichkeiten
O Sehr gut
1.10 Wie gut kennen Sie
sich mit der Entwicklung
O Gut
grafischer BenutzeroberfläO Weniger gut
chen (GUIs) aus?
O Schlecht
1.11 Haben Sie schon ein- O ja
mal Testfälle erstellt?
O nein
1.12 Welche Darstellungs- O ausgedruckt
form von Spezifikationen
O am Bildschirm
bevorzugen Sie (unabhängig von den Spezifikationen
dieser Studie)?
59
A. Anhang
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 – zunä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 denen 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 angeklickt hat, kein Set
vorliegt?
O Der Spieler muss drei Karten abgeben, sofern dies
möglich
(Mission des Projekts)
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 Anwendung nutzen?
O Die Anwendung soll hauptsächlich von jungen Nutzern
(Rahmenbedingungen und Verwendung finden. Dabei können keine technischen
Umfeld)
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- O Dem Spieler wird ein vom System generierter
dern des Spielernamens, Name
wenn ein Fehler vorliegt? zugewiesen.
(Funktionale AnforderunO Wenn der Spielername 0 oder mehr als 20 Zeichen
gen)
umfasst,
wird eine Fehlermeldung ausgegeben.
O Der Spieler wird aufgefordert seinen Namen erneut
einzugeben.
60
A. Anhang
Frage
Antwortmöglichkeiten
2.4 Können im Mehrspie- O Nein, jeder Spieler muss anzeigen, dass er ein Set
lermodus mehrere Spieler markieren
gleichzeitig ein Set markie- möchte. Dann ist diese Möglichkeit für alle anderen
ren?
Mitspieler gesperrt.
(Funktionale AnforderunO Ja. Derjenige, der zuerst ein Set vollständig margen)
kiert hat,
bekommt die Punkte. Die Markierung des anderen
Spielers
wird wieder zurückgesetzt.
O Es gibt eine Einstellungsmöglichkeit, ob dies möglich sein
soll oder nicht. In der Standardeinstellung ist es nicht
möglich.
2.5 Was sind die wichtigsten 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 notwendige Netzwerkverbindung
zwischen Server und Client
nicht hergestellt werden
kann oder nicht funktioniert, DANN …
(Probleme und Risiken)
O … wird es nicht möglich sein ein Spiel im Mehrspielermodus
zu spielen.
O … wird alternativ ein Mehrspielermodus an einem
PC
umgesetzt.
O … muss erneute Rücksprache mit dem Kunden gehalten
werden.
61
A. Anhang
Nun werden Sie noch gebeten, die Abschnitte der Spezifikation, die Sie soeben gelesen 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ötigen.
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 Problems
O Sehr wichtig
O Wichtig
O Weniger wichtig
O Unwichtig
1.2 Wünsche und Prioritäten des Kunden
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- O Sehr wichtig
lyse
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
62
A. Anhang
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
63
A. Anhang
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- O Sehr wichtig
fläche/ (GUI-)MockUps
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
64
A. Anhang
Abschnitt
Kommentar
An dieser Stelle haben Sie die Möglichkeit noch einen Kommentar
hinzuzufügen. Dieser kann beispielsweise Gründe für Ihre Bewertung
enthalten, welche Informationen Sie in
der Spezifikation für Ihre Rolle besonders wichtig/ unwichtig fanden oder ob
Sie sich vielleicht noch weitere Angaben, die nicht enthalten waren,
gewünscht hätten.
65
A. Anhang
A.2.3 Inhaltliche Fragen des zweiten Fragebogens der Spezifikation Translate
Frage
Antwortmöglichkeiten
2.1 Welche Sprachen soll O Englisch und Deutsch
die Anwendung verarbeiten O Es sollen weitere Sprachen hinzufügbar sein. Stankönnen?
dard sind Englisch und Deutsch.
(Mission des Projekts)
O Englisch, Deutsch, Spanisch und Französisch
2.2 Wer soll die Anwendung nutzen?
O Die Anwendung soll Studenten Im Übungsbetrieb
von
(Rahmenbedingungen und Vorlesungen zur Verfügung stehen.
Umfeld)
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- O Chrome, Firefox, Safari, Internet Explorer ab Versern soll die Anwendung
sion 10
laufen?
O Chrome, Firefox, Safari, Opera
(Rahmenbedingungen und O Chrome ist der empfohlene Browser, auf dem die
Umfeld)
Anwendung zur Abnahme laufen soll.
2.4 Welchen Spezialfall
O Wenn gespeichert wird, obwohl keine Werte geängibt es bei der Angabe von dert
Gewichtungen?
wurden, erscheint eine entsprechende Meldung.
(Funktionale AnforderunO Wenn keine ganzzahligen Werte eingegeben wergen)
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- O Bedienbarkeit, Zuverlässigkeit, Korrektheit, Integritätsaspekte vom Kunden
tät,
priorisiert (Auflistung in ab- Wartbarkeit, Effizienz
steigender Reihenfolge)?
O Bedienbarkeit, Integrität, Portabilität, Wartbarkeit,
(Qualitätsanforderungen) Effizient, Korrektheit
O Korrektheit, Effizienz, Bedienbarkeit, Integrität,
Wartbarkeit, Portabilität
66
A. Anhang
Frage
Antwortmöglichkeiten
2.6 Wie ist der Erfahrungs- O Die meisten Mitglieder haben schon einmal damit
stand im Team bezüglich gearbeitet.
des Play!-Frameworks?
O Die meisten Mitglieder haben keine Erfahrung da(Probleme und Risiken)
mit.
O Keins der Mitglieder hat bereits damit Erfahrung.
67
A. Anhang
A.3 Ergebnisdaten der Studie
A.3.1 Erster Fragebogen
68
A. Anhang
A.3.2 Zweiter Fragebogen
Rolle
Komponenten
Set Set Trans_a _d late_a
1.
Translate_d
2.
1.
Tester
2.
Komponenten
UI-Designer
1.
2.
1.
2.
Tester
1.
2.
Entwickler
Entwickler
1.
2.
1.
2.
UI-Designer
Entwickler
Entwickler
Entwickler
1.
2.
1.
1.
2.
1.
2.
Frage
Teilnehmer
002
002
003
003
004
004
005
005
006
006
007
007
008
008
010
010
011
012
012
013
013
69
Frage Frage Frage Frage Frage Frage
2.1
2.2
2.3
2.4
2.5
2.6
3
2
1
3
1
2
1
1
3
1
2
1
3
2
1
3
2
3
2
2
2
2
2
2
2
2
2
2
2
2
2
2
3
1
1
x
1
3
1
3
3
x
3
2
3
1
1
3
1
2
3
1
3
1
2
3
2
3
1
3
3
3
x
2
3
2
3
3
3
3
3
3
3
3
2
3
3
3
x
3
3
2
2
1
3
1
2
1
1
2
1
3
2
1
2
1
3
3
1
2
2
2
2
2
3
2
3
3
1
x
1
1
1
2
x
2
3
3
3
x
3
1
3
2
x
1
A. Anhang
A.3.3 Relevanzeinschätzungen der Teilnehmer
Teilnehmer
002
002
003
003
004
004
005
005
006
006
007
007
008
008
010
010
011
012
012
013
013
Abschnitte
1. 1. 1.
1 2 3
1 2 2
1 1 3
2 3 2
1 2 2
1 1 2
1 2 1
1 1 1
1 2 2
1 1 3
2 1 3
2 1 3
1 2 3
2 1 2
2 1 2
2 2 2
2 1 3
1 3 3
1 2 3
1 1 2
2 2 3
1 2 2
1.
4
3
4
4
4
3
4
2
2
3
4
4
4
3
4
4
3
4
4
4
3
3
2.
1
1
2
2
2
3
3
1
2
3
3
2
1
2
2
2
2
3
2
2
1
2
2.
2
2
2
1
3
4
3
1
1
2
2
1
2
3
3
2
3
3
2
2
1
1
2.
3
1
3
3
3
1
1
3
3
4
4
2
3
1
1
3
2
3
3
2
1
2
3.
1
3
3
1
2
1
1
3
3
1
2
3
2
1
2
1
1
2
4
4
1
2
70
3.
2
4
4
1
1
2
1
1
1
1
1
1
1
1
2
2
1
1
2
2
1
1
3.
3
3
2
1
2
2
2
3
3
3
4
2
2
3
1
2
3
3
2
2
1
2
4.
1
2
2
1
3
1
2
2
2
1
1
3
3
3
1
2
2
2
3
3
1
2
4.
2
2
1
1
3
2
2
1
2
1
1
3
3
1
1
2
2
2
3
3
2
2
4.
3
2
2
1
3
1
2
2
3
3
3
2
3
2
3
2
3
2
2
3
2
2
5
4
4
3
4
3
3
2
3
4
4
4
3
2
1
3
3
3
3
3
3
3
6.
1
2
3
4
4
2
2
2
3
2
3
2
2
3
3
2
2
2
2
2
3
3
6.
2
2
2
4
4
3
1
2
3
4
4
2
2
2
2
2
3
3
3
2
2
2
7
4
4
1
2
3
4
1
1
3
4
1
1
1
2
1
1
1
2
2
1
1
8
4
4
2
3
2
2
1
3
4
4
4
4
4
4
4
4
4
3
3
3
3
9
4
4
4
1
1
1
2
2
3
4
1
1
2
3
4
4
1
3
3
3
3
A. Anhang
A.3.4 Lesezeiten der Abschnitte
Lesezeiten [ms]
Teilnehmer
002
002
003
003
004
004
005
005
006
006
007
007
008
008
010
010
012
012
013
013
011
7
17
5
20
10
24
6
21
7
0
9
3
8
4
3
10
11
8
0
16
12
21
10
14
31
9
25
3
24
4
6
7
4
2
1
1
13
10
3
1
8
2
1.1
1.2
1.
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
3
9
249
41
144
57
145
26
168
47
127
23
112
20
237
7
174
62
274
34
97
23
86
88
204
111
120
56
140
45
192
41
62
40
24
62
6
60
306
26
127
73
128
64
4
1
14
11
11
16
3
1
7
6
1
7
1
2
0
1
5
8
1
1
5
0
0
0
4
2
1
0
1
0
0
0
0
0
0
0
1
0
1
2
1
5
9
6
4
23
2
22
11
2
8
10
5
2
6
4
3
32
6
16
2
3
2
29
8
57
30
22
5
16
6
30
8
48
4
22
11
2
20
34
14
14
2
19
3
4
14
26
26
6
4
15
14
7
7
10
10
6
1
28
5
12
6
0
6
11 26 12
15 10
1
9 18 87
14
8 190
32 54 213
30 107 134
3
6 163
9
2 264
14 22 273
24 16 230
9 18 236
21 26 240
3 21 155
14 58 226
0
5 261
32 81 29
7 20 128
15 17 24
2 17 119
1 65 109
6 17 353
71
0
0
7
0
0
9
1
2
0
3
1
7
8
6
0
0
6
6
1
1
6
2
4
59
17
19
8
22
52
0
72
4
28
13
6
0
2
15
25
33
2
23
1
2
51
6
15
1
37
6
0
6
2
3
5
1
0
1
17
4
7
0
8
1
12
6
43
13
4
5
13
0
11
0
7
5
3
0
1
8
16
1
0
8
2
3
17
16
29
9
9
4
0
13
0
11
5
17
0
6
14
18
2
4
14
1 0 0 2
0 0 0 3
6 2 1 3
5 1 0 6
21 15 1 17
1 22 0 5
3 2 0 1
1 0 0 13
0 0 0 0
2 2 0 3
0 0 1 4
2 0 0 3
14 0 4 2
2 0 0 1
0 0 0 0
1 0 4 2
13 5 1 4
8 8 0 4
1 0 2 4
2 0 0 2
13 0 4 4
A. Anhang
A.3.5 Übersicht über Leseintensitäten
relativer Durchschnitt der Lesezeiten: ausgedruckt
10,000
Lesezeit/ Länge [s/cm]
9,000
8,000
7,000
6,000
5,000
4,000
3,000
2,000
1,000
0,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
8
9
8
9
Abschnitt
Lesezeit/ Länge [s/cm]
relativer Durchschnitt der Lesezeiten: am Bildschirm
10,000
9,000
8,000
7,000
6,000
5,000
4,000
3,000
2,000
1,000
0,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
Abschnitt
relativer Durchschnitt der Lesezeiten: Set
Lesezeit/ Länge [s/cm]
7,000
6,000
5,000
4,000
3,000
2,000
1,000
0,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
Abschnitt
72
A. Anhang
Lesezeit/ Länge [s/cm]
relativer Durchschnitt der Lesezeiten: Translate
20,000
18,000
16,000
14,000
12,000
10,000
8,000
6,000
4,000
2,000
0,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
8
9
8
9
Abschnitt
A.3.6 Übersicht über die Lesegeschwindigkeiten
Geschwindigkeit: ausgedruckt
Geschwindigkeit [cm/s]
7
6
5
4
3
2
1
0
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
Abschnitt
Geschwindigkeit: am Bildschirm
4,5
Geschwindigkeit [cm/s]
4
3,5
3
2,5
2
1,5
1
0,5
0
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
Abschnitt
73
A. Anhang
A.3.7 Übersicht über die durchschnittlichen Bewertungen
Spezifikationsabschnitt
1.1 Erläuterung des zu
lösenden Problems
Bewertung der Rollen (1=sehr wichtig, 2=wichtig, 3=weniger wichtig, 4=unwichtig)
UI-Desig- Software- Tes- Entwickler Entwickler Entwickler
ner
architekt
ter
Student
erfahren
gesamt
1,50
1,00
1,50
1,75
1,25
1,50
1.2 Wünsche und Prioritäten des Kunden
1,50
1,50
1,75
1,25
1,75
1,50
1.3 Domänenbeschreibung
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-Diagramm
2,00
2,00
1,50
2,00
2,75
2,38
3.2 Use Case-Beschreibungen
1,25
2,75
1,00
1,25
1,50
1,38
3.3 Technische Anforderungen
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 Risiken
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 Arbeit
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
74
A. Anhang
A.3.8 Übersicht über die relativierten durchschnittlichen Lesezeiten der Abschnitte
Spezifikationsabschnitt
1.1 Erläuterung des zu
lösenden Problems
Lesezeiten der Rollen, umskaliert auf 4 bis 1 (1=sehr intensiv gelesen)
UI-Desig- Software- Tes- Entwickler Entwickler Entwickler
ner
architekt
ter
Student
erfahren
gesamt
4,19
1,13
1,25
1,32
1,22
1,27
1.2 Wünsche und Prioritäten des Kunden
1,03
1,06
1,19
1,63
1,16
1,39
1.3 Domänenbeschreibung
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-Diagramm
2,01
1,41
2,45
1,69
1,79
1,74
3.2 Use Case-Beschreibungen
2,58
3,15
2,29
2,17
3,12
2,64
3.3 Technische Anforderungen
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 Arbeit
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
75

BRINGT BESONDERES ZUSAMMEN Eye Tracking

Gemeinsam können wir etwas bewegen

Seminar "Doktoranden- und Forschungsseminar

Editorial: Nachtfilme – Filmnächte. Die Nacht als

Spezifikationen "Samsung QM105D"

Katalogkriterien

Klassische Indische Musik und Jazz

Ökumenische Bibelwoche Velten 2015