Wie werden Spezifikationen gelesen? Eine empirische ... · presentation on paper. The goal of the study was to show nothing but the important The goal of the study was to show nothing

Gottfried Wilhelm

Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik

Institut für Praktische Informatik Fachgebiet Software Engineering

Wie werden Spezifikationen gelesen?

Eine empirische Untersuchung mit Eye Tracking

Bachelorarbeit

im Studiengang Informatik

von

Maike Ahrens

Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Joel Greenyer

Betreuer: Stephan Kiesling

Hannover, 28.08.2015

iii

Erklärung der Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbständig und ohne fremde Hilfe verfasst und keine anderen als die in der Arbeit ange-gebenen Quellen und Hilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form noch keinem anderen Prüfungsamt vorgelegen. Hannover, den 28.08.2015 i Vorname Nachname

iv

v

Zusammenfassung

Anforderungsspezifikationen werden von vielen an der Entwicklung beteiligten Nut-

zern mit unterschiedlichen Informationsbedarfen gelesen. Das Auffinden der jeweils

relevanten Informationen bindet für sie dabei viel Arbeitszeit und Ressourcen. Um

diesen Aufwand zu reduzieren wurde im Rahmen dieser Arbeit eine Eye Tracking

Studie durchgeführt, die analysiert, für welche Rolle des Lesers welche Spezifikati-

onsabschnitte relevant und welche unwichtig sind, sowie welche der beiden

Darstellungsformen ausgedruckt oder am Bildschirm geeigneter ist. Das Ziel dabei

war es, mit Hilfe rollenabhängiger Sichten auf Anforderungsdokumente nur die für

den Nutzer wichtigen Abschnitte anzuzeigen, wodurch eine Effizienzsteigerung bei

dem Lesen von Spezifikationen erreicht werden kann. Gleichzeitig bringt dies eine

Effektivitätssteigerung für die Anforderungsingenieure beim Erstellen der Dokumente

mit sich.

Die Studie konnte signifikante Unterschiede bei der Bewertung der Spezifikationsab-

schnitte, sowie zwischen den Rollen nachweisen. Bei der Darstellungsform konnte

hingegen kein Effekt verzeichnet werden.

vi

vii

Abstract

Requirements Specifications are read by several different users involved in the

development process. Each user has different information needs which are all

addressed by the same documents. This leads to a lot of time and ressources needed

to find the relevant information in the text. To reduce this effort, an eye tracking study

was conducted to investigate which artefacts are relevant for which role of the reader.

Furthermore it was analyzed if a presentation on screen is more appropriate than the

presentation on paper. The goal of the study was to show nothing but the important

information to the user, with the help of view-based specifications depending on the

user’s role. This results in a more efficient way of reading requirements documents

and even an increased effectivity writing the specification by the requirements

engineer.

The study could show significant differences in the ratings of the specification’s

artefacts and between the different roles. Concerning the presentation medium no

effect could be proved.

viii

ix

Inhaltsverzeichnis

1 Einleitung ............................................................................................................................. 1

1.1 Motivation ..................................................................................................................... 1 1.2 Zielsetzung .................................................................................................................... 1 1.3 Struktur der Arbeit ........................................................................................................ 2

2 Grundlagen ........................................................................................................................... 2

2.1 Eye Tracking .................................................................................................................. 3 2.1.1 Allgemeines zu Eye Tracking .................................................................................. 3

2.1.2 Grundlagen der visuellen Wahrnehmung .............................................................. 3

2.1.3 Funktionsweise von Eye Trackern .......................................................................... 4

2.1.4 Möglichkeiten und Grenzen von Eye Tracking ....................................................... 4

2.1.5 Eye Tracker ............................................................................................................. 5

2.1.6 Analyse der Eye Tracking Daten ............................................................................. 6

2.2 Vorgehensweise bei der Studie ..................................................................................... 6 2.2.1 GQM-Paradigma..................................................................................................... 6

2.2.2 Testen der Hypothesen .......................................................................................... 7

2.2.3 Sicherstellen der Validität ...................................................................................... 8

3 Verwandte Arbeiten ........................................................................................................... 10

3.1 Rechercheansatz und -ergebnisse .............................................................................. 10 3.2 Ähnliche Studien über sichtenbasierte Spezifikationen ............................................. 10

3.2.1 Eye Tracking Studie .............................................................................................. 11

3.2.2 Software Engineering Projekt Studie ................................................................... 12

3.2.3 Tutorial Studie ...................................................................................................... 13

3.3 Ähnliche Studien zum Vergleich der Darstellungsform .............................................. 13

4 Planung der Studie ............................................................................................................. 15

4.1 Ziele ............................................................................................................................. 15 4.1.1 Verbesserungsziele .............................................................................................. 15

4.1.2 Erreichung der Verbesserungsziele ...................................................................... 15

4.1.3 Betrachtete Darstellungsmedien ......................................................................... 16

4.1.4 Betrachtete Rollen ............................................................................................... 16

4.1.5 Von der Betrachtung ausgeschlossene Rollen ..................................................... 17

4.1.6 Messziel ................................................................................................................ 17

4.2 Fragen.......................................................................................................................... 18 4.3 Metriken ...................................................................................................................... 19

4.3.1 Beschreibung der Zwischenmetriken ................................................................... 20

5 Vorbereitung der Studie ..................................................................................................... 21

5.1 Auswahl der Untersuchungsobjekte ........................................................................... 21 5.2 Kontextbeschreibung .................................................................................................. 22

5.2.1 Testpersonen (Stichprobe) ................................................................................... 22

5.2.2 Untersuchungsumgebung .................................................................................... 23

5.3 Datenquellen und Messmethoden ............................................................................. 23 5.3.1 Fragebögen .......................................................................................................... 23

5.3.2 Experiment in der Eye Tracking Software ............................................................ 24

5.4 Design der Studie ........................................................................................................ 24 5.4.1 Randomisierung ................................................................................................... 24

5.4.2 Blocking ................................................................................................................ 24

5.4.3 Balancing .............................................................................................................. 25

x

5.5 Zuordnung der Untersuchungssubjekte und -objekte ................................................ 25 5.6 Beschreibung des Ablaufs ........................................................................................... 26

6 Durchführung der Studie .................................................................................................... 28

6.1 Beobachtungen während der Studie .......................................................................... 28 6.2 Änderungen im Ablauf ................................................................................................ 28

7 Analyse und Interpretation ................................................................................................ 30

7.1 Verarbeitung der Rohdaten ........................................................................................ 30 7.2 Validierung der Messdaten ......................................................................................... 30 7.3 Formale Prüfung der Hypothesen auf Signifikanz ....................................................... 31

7.3.1 F1: Darstellungsform ............................................................................................ 31

7.3.2 F2: Auswahl der Abschnitte.................................................................................. 34

7.3.3 F3: Unterschiede zwischen den Rollen ................................................................ 38

8 Reflektion zu Studien mit Eye Tracking .............................................................................. 39

8.1 Vorbereitung der Aufnahmen ..................................................................................... 39 8.1.1 Eye Tracking Glasses ............................................................................................. 39

8.1.2 Externer Eye Tracker ............................................................................................ 39

8.2 Durchführung der Aufnahmen .................................................................................... 40 8.2.1 Eye Tracking Glasses ............................................................................................. 40


8.3 Analyse der Daten und Auswertungsmöglichkeiten ................................................... 40 8.3.1 Eye Tracking Glasses ............................................................................................. 40


8.4 Fazit zur Durchführung von Studien mit Eye Tracking ................................................ 41

9 Auswertung und Schlussfolgerung ..................................................................................... 42

9.1 Ergebnisse der Studie .................................................................................................. 42 9.1.1 Effekt der Darstellungsform ................................................................................. 42

9.1.2 Relevanz der Abschnitte ....................................................................................... 43

9.1.3 Unterschiede zwischen den Rollen ...................................................................... 44

9.2 Vergleich mit einschlägigen Studien ........................................................................... 45 9.2.1 Effekt der Darstellungsform ................................................................................. 45

9.2.2 Relevanz der Abschnitte ....................................................................................... 45

9.3 Schlussfolgerung ......................................................................................................... 46

10 Einschränkungen der Validität ......................................................................................... 48

10.1 Validität der Schlussfolgerung ................................................................................... 48 10.2 Interne Validität ........................................................................................................ 48 10.3 Validität der Konstruktion ......................................................................................... 49 10.4 Externe Validität ........................................................................................................ 49

11 Abschließende Betrachtung ............................................................................................. 50

11.1 Zusammenfassung ..................................................................................................... 50 11.2 Ausblick ..................................................................................................................... 50

Literaturverzeichnis ............................................................................................................... 51

A. Anhang .............................................................................................................................. 53

A.1 Einführungen für die Teilnehmer ................................................................................ 54 A.2 Fragebögen ................................................................................................................. 58 A.3 Ergebnisdaten der Studie ............................................................................................ 68

1

1 Einleitung

1.1 Motivation

Spezifikationen spielen eine große Rolle im Softwareentwicklungsprozess, da sie die

Basis und Zielvorgabe bilden, auf dessen Grundlage weitergearbeitet wird. Nur was

klar und ausreichend beschrieben ist, kann auch richtig entwickelt werden (Ebert12).

Eine solche Beschreibung kann schnell sehr umfangreich werden und so ausführlich,

dass relevante Aspekte unter Umständen aus dem Blickfeld geraten (Gross12a). Das

Verfassen und Lesen dieser teils sehr langen Dokumente bindet daher viel Arbeits-

zeit und Ressourcen.

Hinzu kommt die Problematik, dass die Spezifikation aufgrund ihrer zentralen Rolle

eine wichtige Informations- und Kommunikationsquelle für sehr viele an der Entwick-

lung beteiligte Personen mit jeweils unterschiedlichem Informationsbedarf darstellt

(Gross12b). Für einen Usability Experten sind Benutzerbeschreibungen und Anwen-

dungsgebiete beispielsweise besonders relevant. Angaben zum Altsystem hingegen

sind weniger von Interesse. Andere Rollen, wie Projektleiter oder Kunden haben wie-

derum andere Anforderungen an die Spezifikation (Brau11).

Daraus ergibt sich für jeden die Schwierigkeit in der großen Menge an Artefakten,

die eine Spezifikation umfasst, die für die jeweilige Rolle relevanten Informationen

herauszufiltern. Aufgrund der Arbeit, die eine solche Informationssuche mit sich

bringt, besteht die Gefahr, dass die Spezifikationsdokumente dadurch in den Hinter-

grund rücken und somit wichtige ermittelte Systemanforderungen vernachlässigt

werden (Gross12a).

Da das Verfassen und Lesen von Spezifikationen sehr viel Zeit erfordert, wäre es

dementsprechend wünschenswert, wenn man diesen Aufwand möglichst reduzieren

und dessen Nutzen optimieren könnte.

1.2 Zielsetzung

Ziel dieser Arbeit ist es, den Schreib- und Leseprozess von Spezifikationen effizienter

und effektiver zu gestalten, wobei zwei Ansätze verfolgt werden. Zum einen werden

Tipps für eine sichtenbasierte Spezifikation entwickelt, die es möglich machen, ab-

hängig von der Rolle des Lesers das Dokument anzupassen, indem irrelevante

Abschnitte ausgeblendet und wichtige dagegen in den Vordergrund gesetzt werden.

Dazu ist es zunächst einmal nötig, herauszufinden, um welche Abschnitte es sich im

Einzelnen handelt, das heißt, welche Rolle welchen Informationsbedarf hat und wel-

che Darstellung bevorzugt wird. Dies erfolgt im Rahmen einer Eye Tracking Studie,

in der der Leseprozess verschiedener Benutzer mit unterschiedlichen Spezifikatio-

nen untersucht wird, wobei sich bei den Rollen der Leser auf die des UI-Designers,

des Softwarearchitekten, des Testers und des Entwicklers beschränkt wird. Das Au-

genmerk liegt dabei weniger auf dem konkreten Inhalt einzelner Abschnitte, sondern

vielmehr auf deren Reihenfolge und Relevanz für den Leser.

Darüber hinaus wird das Lesen von Spezifikationen auf dem Papier und am Bild-

schirm verglichen mit dem Ziel, herauszufinden, welche der beiden

Darstellungsformen geeigneter ist. Hierfür werden die Spezifikationsdokumente der

Studie den Teilnehmern entweder ausgedruckt oder in Papierform ausgehändigt.

1 Einleitung

2

1.3 Struktur der Arbeit

Zu Beginn der Arbeit werden zunächst notwendige Konzepte und Begrifflichkeiten im

Grundlagenteil erklärt. Anschließend folgt eine Beschreibung der Erkenntnisse, die

bisherige Arbeiten zu dem behandelten Thema bereits erlangen konnten. Auf dessen

Basis wurden die Ziele der durchgeführten Studie, sowie dessen Aufbau, untersuchte

Fragestellungen und betrachtete Metriken definiert. Im Anschluss daran ist die ge-

samte Umgebung der Studie beschrieben. Diese umfasst Aspekte wie die

verwendeten Untersuchungsobjekte und Messmethoden. Daraufhin ist der Ablauf

der Studie detailliert aufgeführt und es werden die resultierenden Daten analysiert,

interpretiert und die Ergebnisse auf statistische Aussagekraft überprüft. Schlussend-

lich werden die Resultate auf die Erreichung der Zielsetzung der Arbeit hin bewertet,

ihre Validität diskutiert und mögliche Schlussfolgerungen gezogen. Die erlangten Er-

kenntnisse werden zuletzt noch zusammengefasst und ein Ausblick über weitere

Möglichkeiten gegeben

3

2 Grundlagen

2.1 Eye Tracking

Die Studie, die im Rahmen dieser Arbeit durchgeführt wurde, nutzt die Methode des

Eye Tracking. Ein Überblick darüber, worum es sich dabei genau handelt und wel-

chen Nutzen man daraus ziehen kann, gibt dieses Kapitel.

2.1.1 Allgemeines zu Eye Tracking

Eye Tracking ist eine Methode zur Aufzeichnung von Blickbewegungen. Die Geräte,

die diese Aufzeichnung vornehmen, werden entsprechend Eye Tracker genannt. Mit

deren Hilfe ist es möglich zu detektieren, wo die Versuchsperson zu einem bestimm-

ten Zeitpunkt hinschaut, wie lange sie dort hinsieht und welchem Blickpfad die Augen

folgen. Damit hilft Eye Tracking Forschern dabei visuelle Aufmerksamkeit zu verste-

hen und einen Nutzen aus diesem Wissen zu ziehen (Schall14).

2.1.2 Grundlagen der visuellen Wahrnehmung

Um die Funktionsweise von Eye Trackern zu verstehen, ist es zunächst einmal nötig,

ein paar Grundlagen darüber zu kennen, wie Menschen visuelle Informationen auf-

nehmen. Dazu sind die beiden Grundbegriffe Fixationen und Sakkaden von

Relevanz. Bei Fixationen handelt es sich um eine Pause der Blickbewegung. Das

heißt, zu diesem Zeitpunkt verweilt das Auge auf einem bestimmten Bereich des

Blickfelds. Währenddessen kann das Auge visuelle Informationen aufnehmen. Sak-

kaden hingegen sind die Blicksprünge von einer Fixation zur nächsten (Schall14).

Während dieser Phase werden nur bereits wahrgenommene visuelle Informationen

verarbeitet, jedoch keine neuen aufgenommen (Schmidts07).

Mithilfe von Fixationen und Sakkaden ist es dem Gehirn möglich ein komplettes Bild

der wahrgenommenen Szene zusammenzusetzen. Die einzelnen Fixationen haben

typischerweise eine Dauer von 100 bis 600 Millisekunden und finden im fovealen

Blickfeld statt. Das ist der Bereich, in dem das Auge scharf und detailliert sieht. Die

dort aufgenommen visuellen Reize bilden jedoch nur knapp die Hälfte der insgesamt

wahrgenommenen visuellen Informationen. Der Rest befindet sich im parafovealen

und peripheren Bereich. Diese befinden sich um das fokussierte foveale Blickfeld

herum. Dort befindliche Objekte können nur grob wahrgenommen werden und man

erhält nur einen Eindruck ihrer generellen Form und Farbe. Meist ziehen sie nur in

Bewegung die Aufmerksamkeit auf sich.

Das Gehirn ist jedoch sehr gut in der Lage aus diesen grob aufgelösten Wahrneh-

mungen, die genaue Beschaffenheit der einzelnen Objekte zu erahnen und somit ein

scheinbar komplettes Bild eines Geschehens zu erzeugen (Schall14). Aus diesem

Grund ist es Menschen unter anderem möglich den Inhalt eines Textes zu erfassen,

ohne beim Lesen jeden oder jeden zweiten Buchstaben fokussieren zu müssen, da

aus der groben Form eines Wortes, sowie einzelnen Buchstaben bereits das Ge-

samtwort „erraten“ werden kann. Abbildung 2.2 stellt dar, wie ein solcher

Leseprozess aussehen kann. Die einzelnen Kreise repräsentieren Fixationen. Ihre

Größe ist dabei abhängig von der Dauer der Fixation. Je länger sie angedauert hat,

desto ist der jeweilige Kreis. Die Verbindungslinien zwischen den Kreisen stehen für

die Sakkaden, die den Blicksprung von einer Fixation zur nächsten darstellen.

2 Grundlagen

4

Abbildung 2.1: Beispieltext mit Fixationen und Sakkaden (Wiki15)

2.1.3 Funktionsweise von Eye Trackern

Während frühere Eye Tracker noch den gesamten Kopf und teilweise sogar die Au-

genlider fixieren mussten, sind die heutigen Geräte deutlich komfortabler für die

Versuchsperson. Der Großteil der neuen Eye Tracker nutzt die Methode der Horn-

hautreflexion, um die Position der Pupille während der Bewegung erkennen und

verfolgen zu können. Diese Methode umfasst eine Lichtquelle mit Infrarotlicht, die auf

das Auge gerichtet wird und dessen Reflexion auf der Hornhaut von einer hochauf-

lösenden Kamera aufgenommen wird (Schall14). Da am Ort der Pupille kein Licht

reflektiert wird, kann anschließend mittels spezieller Bildverarbeitungsalgorithmen

die Pupillenposition bestimmt werden (Schall14, Schmidts07). Um diese Position auf

das gesehene Bild der Versuchsperson abzubilden, wird anschließend noch eine Ka-

librierung benötigt. Bei dieser wird die Versuchsperson dazu aufgefordert einen

bestimmte Punkt oder mehrere Punkte hintereinander zu betrachten. Diese Informa-

tion nutzt dann der Eye Tracker, um den Zusammenhang zwischen Blickpunkten und

Aufnahmebild herzustellen.

2.1.4 Möglichkeiten und Grenzen von Eye Tracking

Untersuchungen mit Eye Tracking geben Aufschluss darüber, wo eine Person zu ei-

nem bestimmten Zeitpunkt hinsieht und bieten so die Möglichkeit das Blickverhalten

von Menschen genauestens zu analysieren. Damit lässt sich untersuchen, wo das

Zentrum der Aufmerksamkeit während bestimmter Ereignisse liegt. Des Weiteren

kann über die Dauer von Fixationen ausgesagt werden, wie lange ein bestimmter

Bereich fokussiert wurde. Die Auswertungsmöglichkeiten gehen sogar so weit, dass

man einen Anhaltspunkt darüber geben kann, ob eine Person nervös oder aufgeregt

ist, da dann das Blickverhalten sprunghafter und die Fixationen kürzer werden

(Schmidts07).

Entsprechend große Anwendung finden Eye Tracking Studien in Marktforschungs-

analysen, um die Wirksamkeit von Werbekampagnen zu testen. Ebenfalls ein großes

Anwendungsgebiet sind Studien über Benutzeroberflächen. Mittels Eye Tracking

kann ausgesagt werden, welche Elemente zu welchem Zeitpunkt, wie lange und in

welcher Reihenfolge dem Nutzer ins Auge springen. Damit lässt sich herausfinden,

wie anwenderfreundlich und bedienbar beispielsweise eine Webseite ist. Weitere An-

wendungsgebiete sind die Medizin oder auch immer mehr die Mensch-Computer-

2 Grundlagen

5

Interaktion, wo Eye Tracking zur Steuerung von Computern eingesetzt wird

(Schall14).

Jedoch ist bei der Auswertung der Eye Tracking Daten Vorsicht geboten, damit keine

falschen Schlüsse gezogen werden. Wie in Kapitel 2.1.1 bereits beschrieben, nimmt

der Mensch auch sehr viele Information über den peripheren Sehbereich auf. Wenn

bei einer Usability-Studie beispielsweise ein Webseitenelement nicht über eine Fixa-

tion direkt betrachtet wurde, heißt das nicht zwangsläufig, dass der Nutzer es nicht

wahrgenommen hat. Andersherum bedeutet eine Fixation auf einem Objekt nicht ge-

zwungenermaßen, dass die Person die visuellen Informationen auch wirklich

aufgenommen und verarbeitet hat. Dies ist insbesondere dann der Fall, wenn kogni-

tiv anspruchsvolle Aufgaben untersucht werden. Der Eye Tracker kann zudem nur

Aussagen über den Verlauf des Blickverhaltens machen, nicht jedoch über die

Gründe dafür, wie z.B. warum ein Nutzer einen Text besonders intensiv liest oder ein

Bild sehr lange betrachtet. Dafür sollten weitere Untersuchungsmethoden, wie Fra-

gebögen oder lautes Denken hinzugezogen werden (Schall14).

2.1.5 Eye Tracker

Eye Tracker werden in die beiden Kategorien externe und mobile Systeme unterteilt.

Externe Eye Tracker sind dabei die Geräte, die nicht an der Versuchsperson, son-

dern am Bildschirm befestigt werden oder sogar in ihn integriert sind. Diese zeichnen

dann parallel zu den Blickbewegungen das Bild des Monitors auf. Dabei kann es sich

beispielsweise um Bilder, Videos, Textdokumente oder Webseiten handeln. Das Ge-

rät, dass in der Studie dieser Arbeit verwendet wird, stammt von dem Unternehmen

SensoMotoric Instruments (SMI) und es handelt sich dabei um das Modell Red-m.

Es wird auf der Abbildung 2.4 gezeigt und lässt sich entweder an einen Monitor an-

bringen oder auf einen Laptop stellen (SMI15).

Abbildung 2.2: externer Eye Tracker Red-m von SMI (SMI15)

Im Gegensatz zu externen Eye Trackern werden mobile Systeme von der Versuchs-

person getragen. Ein Beispiel für ein solches auch head-mounted Eye Tracker

genanntes Gerät sind die Eye Tracking Glasses 1 Wireless von SensoMotoric Instru-

ments, die in der Studie dieser Arbeit verwendet wurden. Diese Brille wird auf

Abbildung 2.5 gezeigt. Sie kann entweder an eine mitgelieferte Aufnahmeeinheit (Re-

cording Unit), die aus einem Smartphone und einem zusätzlichen Akku für die Eye

Tracking Glasses besteht, angeschlossen werden oder direkt an einen Laptop

(SMI15).

2 Grundlagen

6

Abbildung 2.3: Eye Tracking Glasses 1 Wireless von SMI (SMI15)

2.1.6 Analyse der Eye Tracking Daten

Zu jedem Eye Tracker gehört eine passende Analysesoftware, die die Quantifizie-

rung, sowie Visualisierung der Daten ermöglicht. Dazu werden verschiedene

Möglichkeiten, wie beispielsweise der Gaze Plot, der auch in Abbildung 2.1 zu sehen

ist oder Heat Maps, in denen die Dauer der Fixationen in einem bestimmten Bereich

durch Verläufe von warmen zu kalten Farben dargestellt wird (Schall14). Eine Option,

um konkrete Blickwerte in Form von Zeiten in Millisekunden zu erhalten, ist darüber

hinaus das Definieren sogenannter „Areas of Interest“ (AOIs). Diese können entwe-

der in geometrischen oder handgezeichneten Formen auf Screenshots des

Kamerabildes des Eye Trackers gezogen werden oder auf selbst erstellte Referenz-

bilder. Anschließend berechnet die Analysesoftware Werte wie die durchschnittliche

Dauer einer Fixation auf diesem Bereich, die Blickdauer insgesamt oder die Anzahl

an Sakkaden (Schall14).

2.2 Vorgehensweise bei der Studie

2.2.1 GQM-Paradigma

Die im Rahmen der Arbeit durchgeführte Studie wurde nach dem GQM-Paradigma

geplant. GQM steht dabei für Goal, Question, Metric und beschreibt eine systemati-

sche Vorgehensweise zur Erstellung von Qualitätsmodellen. Dieser Ansatz gibt vor,

dass zu Beginn der Arbeit zunächst Ziele definiert werden, die mit der Studie erreicht

werden sollen. Diese lassen sich in die beiden Kategorien „Verbesserungsziel“ und

„Messziel“ unterteilen. Verbesserungsziele (Goals) beschreiben, welchen Prozess

oder Sachverhalt die Ergebnisse verbessern sollen, also welches übergeordnete Ziel

die Studie hat. Die Messziele hingegen verfeinern dieses Ziel, indem sie das konkrete

Objekt der Messung vorgeben. Dieses kann beispielsweise ein bestimmter Prozess

oder ein Produkt sein. Anschließend werden auf Basis des Messziels Fragen (Ques-

tions) aufgestellt, die das Messziel näher spezifizieren und angeben welche

Fragestellungen von den Messungen untersucht werden. Zu jeder Frage werden an-

schließend eine oder mehrere Metriken (Metrics) definiert, welche die Beantwortung

der Fragen ermöglichen, sowie Hypothesen über die erwartete Antwort festgelegt

(Solingen99). Abbildung 2.1 beschreibt das Vorgehen des GQM-Ansatzes noch ein-

mal anschaulich. Dort lässt sich auch der entsprechende Ablauf bei der Auswertung

entnehmen. Im Anschluss an die Definition der Ziele, Fragen und Metriken folgt dem-

nach die Datenerfassung, dessen Messdaten mit den Metriken validiert werden, um

sicherzustellen, dass die gewünschten Daten auf die richtige Weise erhoben wurden.

Ist dieser Schritt erfolgt, können die Messaufzeichnungen in Bezug auf die zuvor de-

finierten Hypothesen, Fragen und Messzielen analysiert werden. Daraufhin können

2 Grundlagen

7

die erlangten Erkenntnisse zu der ursprünglich angestrebten Verbesserung führen

(Freimut02).

Abbildung 2.4: Übersicht zum Vorgehen mit GQM (Freimut02)

2.2.2 Testen der Hypothesen

Vor der Durchführung der Studie werden zunächst die erwarteten Ergebnisse in Form

von Hypothesen festgehalten. Diese können auf vorherigen Untersuchungen oder

logischen Überlegungen beruhen. Die meisten Hypothesen lassen sich jedoch nur

indirekt prüfen, da meist schon ein Gegenbeispiel genügt, um sie zu widerlegen. Da-

her wird häufig zum Beweisen einer Hypothese die Gegenhypothese, auch

Nullhypothese H0 formuliert und diese geprüft. Wenn man beispielsweise zeigen

möchte, dass der Mittelwert 𝜇1 einer gemessenen Variable größer ist als ein anderer

Mittelwert 𝜇2, wäre die entsprechende Nullhypothese 𝜇1 ≤ 𝜇2. Das hat den Vorteil,

dass wenn die Gegenhypothese abgelehnt werden kann, automatisch die ursprüng-

liche Hypothese, auch Arbeitshypothese HA genannt, als wahr belegt wird.

Hypothesen können entweder einseitig oder zweiseitig aufgestellt werden (Sachs93).

Ein Beispiel für eine einseitige Fragestellung ist wie oben 𝜇1 > 𝜇2, wobei das Inter-

vall für den jeweiligen Mittelwert nur zu einer Seite offen ist. Bei zweiseitigen

Fragestellen, wie z.B. 𝜇1 ≠ 𝜇2, müssen die Mittelwerte nur unterschiedlich sein. Die

Art des Unterschieds ist dabei nicht vorgegeben. Der zweite Mittelwert kann entwe-

der größer oder kleiner sein, wodurch das Intervall zu zwei Seiten offen ist (Sachs93).

Zur Prüfung von Hypothesen werden statistische Tests verwendet, die einen gemes-

senen Trend, wie den Unterschied zweier Mittelwerte auf Signifikanz testen. Ein

statistisch signifikantes Ergebnis ist dabei ein Ergebnis, bei dem die Wahrscheinlich-

keit, dass der betrachtete Effekt zufällig auftritt, sehr gering ist. Diese

Wahrscheinlichkeit für ein zufälliges Auftreten, also ein irrtümliches Ablehnen der

Nullhypothese, wird mit 𝛼 bezeichnet und auch Fehler 1. Art genannt. Dem gegen-

über steht der Fehler 2. Art mit der Wahrscheinlichkeit 𝛽, dass die Nullhypothese

nicht abgelehnt wird, obwohl sie falsch ist. Anders gesagt ist 𝛽 die Wahrscheinlich-

keit, dass ein vorhandener Effekt nicht erkannt wird (Sachs93). Dabei gilt: je kleiner

𝛼, desto größer ist 𝛽. Je nachdem wie gravierend ein entsprechender Irrtum ist, dass

die Nullhypothese fälschlicherweise abgelehnt oder beibehalten wird, werden die je-

weiligen 𝛼- und 𝛽-Werte gewählt. Bei der Untersuchung, ob ein neues Medikament

die gleiche Wirkung zeigt wie das auf dem Markt bestehende, würde beispielsweise

2 Grundlagen

8

𝛼 besonders klein und 𝛽 dafür größer wählen, da eine irrtümliche Annahme über die

gleiche Wirkung also ein Ablehnen der Nullhypothese verheerende Folgen hätte. Üb-

licherweise wird für 𝛼 der Wert 0,05 gewählt. Das heißt, dass die Wahrscheinlichkeit

eines Irrtums bei Ablehnen der Nullhypothese 5% beträgt. In diesem Fall wird auch

von 5%-Signifikanzniveau gesprochen (Sachs93).

2.2.3 Sicherstellen der Validität

Das Durchführen einer Studie ist nur dann sinnvoll, wenn die Resultate auch an-

wendbar sind. Das heißt, wenn die Studie in sich valide und die dort untersuchten

Sachverhalte auf die gewünschte Umgebung übertragen werden können. Dazu prüft

man, ob die Untersuchungen durch sogenannte Einschränkungen der Validität ge-

fährdet werden. Um die verschiedenen Arten von Validität zu verstehen, ist zunächst

ein gewisses Verständnis für das Durchführen von Studien erforderlich. Eine Über-

sicht darüber gibt Abbildung 2.4. Studien können entweder off-line in einer definierten

Untersuchungsumgebung stattfinden oder on-line, beispielsweise in einem echten

Projekt innerhalb eines Unternehmens (Wohlin00). In beiden Fällen liegt den Be-

obachtungen eine gewisse Theorie zugrunde. Die Studie wird durchgeführt, um eine

bestimmte Ursache-Wirkung-Korrelation zu erforschen. Die Ursache wird dabei

durch bestimmte, in der Studie fest gesetzte Faktoren abgebildet. Der Effekt dieser

Faktoren wird anschließend im Ergebnis gemessen. Diese Eingabe-Ergebnis-Korre-

lation im Experiment entspricht dann der Ursache-Wirkung-Korrelation (Wohlin00).

Die verschiedenen Arten von Validität zielen auf verschiedene Zusammenhänge in

diesem Konstrukt ab. Wie gut die Abbildung der beiden Korrelationen ist beurteilt

dabei die Validität der Konstruktion. Das heißt, dabei stellt man sich die Frage, wie

gut die betrachteten Faktoren die zu untersuchende Wirkung und das gemessene

Ergebnis die entsprechende Wirkung darstellen. Einen negativen Einfluss auf diese

Art der Validität kann es zum Beispiel geben, wenn man in einer Studie die gemach-

ten Fehler in Programmcode untersucht und die Teilnehmer sich dessen bewusst

sind. In dem Fall würden sie besonders darauf Acht geben und somit versuchen die

Fehlerzahl zu reduzieren (Wohlin00).

Bezüglich des Feststellens einer Korrelation zwischen Eingabe und Ergebnis gibt es

zwei verschiedene Validitäten, die sich damit auseinander setzen. Zum einen ist das

die interne Validität, die sich damit beschäftigt, ob die beobachteten Faktoren über-

haupt die Ursache für den gemessenen Effekt sind und nicht ein anderer, nicht

berücksichtigter Faktor diesen bewirkt hat. Ein Beispiel für eine beeinträchtigte in-

terne Validität ist, wenn die Teilnehmer während der Studie durch äußere nicht

betrachtete Einflüsse abgelenkt werden und diese die Ergebnisse beeinflussen, man

jedoch fälschlicherweise annimmt, dass die festgelegten Faktoren der Studie diese

verursacht haben. Die zweite Validität, die sich mit der Beziehung zwischen Eingabe

und Ergebnis beschäftigt ist die Validität der Schlussfolgerung, auch statistische Va-

lidität genannt. Diese umfasst Faktoren, die beispielsweise durch den gewählten

Signifikanztest oder eine zu geringe Stichprobengröße entstehen können. Der beo-

bachtete Effekt könnte beispielsweise irrtümlich gefunden worden sein, wenn die

Voraussetzungen für den verwendeten Test nicht gegeben sind (Wohlin00).

Die letzte Kategorie der Validität ist die externe Validität. Diese thematisiert die Ver-

allgemeinerungsmöglichkeiten der Studienergebnisse auf andere Sachverhalte und

wird durch die Wahl der Untersuchungsobjekte, -subjekte und der Umgebung beein-

flusst. Erkenntnisse lassen sich beispielsweise schlecht generalisieren, wenn eine

sehr spezielle Gruppe an Teilnehmern gewählt wurde, die nicht repräsentativ für die

betrachtete Grundgesamtheit sind (Wohlin00). Ein Beispiel hierfür wäre, wenn man

2 Grundlagen

9

das Durchschnittsalter von Studenten bestimmen möchte und dafür Studenten in ei-

ner Erstsemesterveranstaltung befragt.

Einer schlechten Validität der Ergebnisse entgegen wirken die drei Experimentprin-

zipien Randomisierung, Blocking und Balancing. Die Randomisierung, also das

zufällige Wählen von Probanden, Reihenfolgen und weiteren Faktoren, die ebenfalls

einen Einfluss auf die Beobachtungen haben können, wirkt dabei einer schlechten

internen Validität entgegen. Das Blockingverfahren kann angewendet werden, wenn

nicht gewünschte Einflussfaktoren bekannt sind, z.B. wenn die Teilnehmer einen un-

terschiedlichen Erfahrungsstand haben. In dem Fall werden die Probanden dann in

zwei von der Erfahrung abhängige Gruppen aufgeteilt und anschließend wird der Ef-

fekt der untersuchten Faktoren nur innerhalb dieser Gruppen analysiert und

verglichen. Somit hat der ungewünschte Faktor jeweils den gleichen Wert und keinen

Einfluss auf die Erkenntnisse innerhalb der Gruppen. Das letzte Prinzip der Ausge-

glichenheit bzw. Balancing gibt vor, dass Vergleiche jeweils auf gleich großen

Stichprobengrößen und Anzahlen an Untersuchungsobjekten stattfinden sollten, um

eine möglichst gute statistische Testbarkeit und somit eine gute Validität der Schluss-

folgerung zu erhalten (Wohlin00).

Abbildung 2.5: Experimentprinzipien (aus (Wohlin00) ins Deutsche übertragen)

10

3 Verwandte Arbeiten

3.1 Rechercheansatz und -ergebnisse

Zu Beginn der Arbeit wurde zunächst nach bestehendem Material recherchiert. Dazu

wurde vor allem Google Scholar verwendet. Zu jeder Suchanfrage wurden die ersten

zwei bis drei Ergebnisseiten durchgesehen, je nachdem wie vielversprechend der

sich ergebende Eindruck war.

Anfangs wurde nach Quellen gesucht, die ebenfalls den Ansatz von rollenabhängi-

gen Spezifikationen behandelten. Jedoch führten erste einfache Suchanfragen,

bestehend aus Wörtern wie „Anforderungsmanagement“, „Spezifikationen“, „Soft-

ware Engineering“, „Probleme“ und „Problemansatz“, „Lesbarkeit“, „Risiken“,

„Verbesserung“ und „Verbesserungsansatz“, „Kriterien“ oder „Studie“ zu keinen Er-

gebnissen, die in die Richtung des Ziels der geplanten Studie gingen.

Es wurden viele Verbesserungsansätze für Spezifikationen gefunden. Einige dieser

betrafen dabei den Aufbau des Dokuments, wie verschiedene Standards, beispiels-

weise von dem Institute of Electrical and Electronics Engineers (IEEE) (IEEE98a,

IEEE98b) oder Templates und Frameworks, wie z.B. das Volere Template

(Robertson06) oder das TORE-Framework (Task-oriented Requirements Enginee-

ring) (Adam09). Diese sind jedoch meist sehr allgemein formuliert und adressierten

keine rollenspezifischen Bedürfnisse. Andere beinhalteten jedoch bereits die Idee

von Perspektiven auf Anforderungsdokumente, wie das perspective-based reading.

Dabei handelt es sich um eine Methode zur Inspektion von Spezifikationen zum effi-

zienten und möglichst vollständigem Auffinden von Fehlern in

Anforderungsspezifikationen (Wohlin00). Sie repräsentieren somit einen Ansatz, der

auf bereits erstellten Dokumenten aufbaut und nicht den Prozess des Erstellens und

Nutzens betrifft, wie es sichtenbasierte Spezifikationen tun (Gross12b).

Schließlich wurden mithilfe der Google Suchanfrage „Spezifikation abhängig vom Le-

ser“ bereits im ersten Ergebnis die Studien des Fraunhofer Instituts für

Experimentelles Software Engineering (IESE) entdeckt, die genau den Ansatz der

sichtenbasierten Anforderungsspezifikation behandeln (Gross12a). Diese sind im

nächsten Teilkapitel (3.2) noch näher beschrieben. Über diesen Beitrag wurden an-

schließend zwei Verfahren zum Auffinden weiterer einschlägiger Quellen verwendet.

Zum einen wurde nach den in passender Literatur aufgeführten Schlüsselwörtern,

wie beispielsweise „view-based requirements specification“ oder „perspective-based

requirements specification“ gesucht, um ähnliche Paper oder Bücher zu finden. Zum

anderen wurden nach dem Schneeballprinzip die Literaturangaben geeigneter Su-

chergebnisse auf verwendbare Informationen durchgesehen. Hat man hierbei einen

passenden Treffer gefunden, wurden wiederum dessen Quellen betrachtet und so

weiter. Es wurde jedoch über die Studien des IESE hinaus keine weitere Literatur

gefunden, die sich explizit mit der Entwicklung sichtenbasierter Spezifikationen und

der dazu erforderlichen empirischen Datenerhebung befasst.

3.2 Ähnliche Studien über sichtenbasierte Spezifikationen

Die Planung und der Aufbau der in dieser Arbeit durchgeführten Studie baut auf drei

Studien auf, die das bereits erwähnte Fraunhofer Institut für Experimentelles Soft-

ware Engineering (IESE) im Rahmen eines Dissertationsverfahrens durchgeführt

hat. Sie haben damit den gleichen Ansatz der „sichtenbasierten Anforderungsspezi-

fikation“ erforscht. Die Zielsetzung ihrer Arbeit war es, ebenfalls mithilfe empirischer


11

Studien und Literaturrecherchen fundiertes Wissen über die individuellen Informati-

onsbedürfnisse der Rollen zu erhalten, die Spezifikationen nutzen. Dieses Wissen

sollte anschließend dazu verwendet werden, Sichten auf Anforderungsspezifikatio-

nen zu generieren, welche die jeweiligen Ansprüche an das Dokument erfüllen

(Gross12a). Auf Basis dieser Zielsetzung haben sie sich die folgenden in Tabelle 3.1

aufgeführten zwei Forschungsziele mit dazugehörigen Fragen überlegt, dessen Be-

antwortung Daten für die Entwicklung von rollenabhängigen Sichten auf

Spezifikationsdokumente liefern sollen. Die drei durchgeführten Studien untersuchen

jeweils nur FZ1 (Gross12b).

Forschungsziel FZ1: Untersuchung der Informationsbedarfe von Entwickler-rollen bezüglich der Nutzung von Softwareanforderungs- spezifikationen (SAS)

Frage F1_1: Was sind typische Artefakttypen, die in SAS aus Sicht von Entwicklerrollen zur Bearbeitung ihrer Aufgaben enthalten sein sollten?

Frage F1_2: Wie detailliert sollten Artefakte eines bestimmten Typs spezifiziert werden?

Frage F1_3: Welche Notation sollte zur Spezifikation bestimmter Artefakttypen genutzt werden?

Forschungsziel FZ2: Untersuchen, ob es Unterschiede zwischen den Informa- tionsbedarfen aus Sicht unterschiedlicher Entwicklerrol-len gibt

Frage F2_1: Gibt es einen Unterschied zwischen den Informations- bedarfen verschiedener Rollen?

Frage F2_2: Gibt es sogar einen Unterschied zwischen Personen mit der gleichen Rolle?

Frage F2_3: Was sind Faktoren, die den Informationsbedarf von Entwicklungsingenieuren der gleichen Rolle beeinflus-sen?

Tabelle 3.1: Forschungsfragen des Fraunhofer IESE (übersetzt aus (Gross12b))

3.2.1 Eye Tracking Studie

Die erste Studie des IESE bezog sich auf die Fragestellungen F1_1 und F1_3. An ihr

nahmen zwei Architekturexperten und zwei Usabilityexperten teil. Ihre Aufgabe war

es eine in einem echten Softwareprojekt mithilfe des TORE Frameworks (Adam09)

erstellte Anforderungsspezifikation zu sichten und durch „lautes Denken“ die Rele-

vanz der enthaltenen Informationen für die Erstellung einer Architektur bzw. eines UI

Designs zu bewerten (Gross12a). Die verwendete Spezifikation umfasste 133 Seiten

mit Domänenanforderungen, 140 Seiten Systemanforderungen und weitere 82 Sei-

ten Anhang mit Zusatzmaterial und war daher in drei Dokumente aufgeteilt

(Gross12b).

Mithilfe eines mobilen Eye Trackers wurden das Blickverhalten der Versuchsteilneh-

mer aufgezeichnet, sodass beobachtet werden konnte, welche Stellen im Dokument

besondere Aufmerksamkeit erlangten. Zusätzlich wurde der Ablauf mit einer exter-

nen Kamera gefilmt und es waren jeweils ein bis drei Beobachter anwesend, die den

Umgang mit der Spezifikation protokollierten. Neben dem „lauten Denken“ zur Be-

stimmung der Relevanz der insgesamt 35 Artefakte wurde ein Fragebogen im

Nachgang an die Dokumentanalyse verwendet, indem die einzelnen Artefakttypen

mit einer Gewichtung von „Sehr wichtig“ bis „Unwichtig“ bewertet (Brau11) und zu-

sätzlich Kommentare abgegeben werden sollten, warum einzelne Teile als relevant


12

erachtet werden, ob eventuell Informationen fehlen und ob die gewählten Notationen

nützlich sind (Gross12b). Ein Bild der Studie zeigt die Abbildung 3.1.

Abbildung 3.1: Eye Tracking Studie des Fraunhofer IESE (Gross12c)

Als Ergebnis konnte festgestellt werden, dass aus Sicht des Architekten alle Artefakt-

typen wichtig oder sehr wichtig sind. Aus Sicht des UI-Designers sind dagegen nicht

alle Artefakte relevant. Demzufolge stechen besonders Stakeholder, Prozess- und

Interaktionsbeschreibungen als sehr wichtig hervor (Gross12a).

Als Fazit der Studie konnte festgehalten werden, dass zwar einige Schlüsse auf die

Informationsbedarfe der beiden Rollen Architekt und UI-Designer gezogen werden

konnten, die Stichprobe jedoch zu klein ist, um valide Ergebnisse zu erhalten und

daher weitere Studien notwendig sind. Zudem wurde ebenfalls in Bezug auf zukünf-

tige Studien der Hinweis gegeben, dass eine weitere Schwäche der Studie darin lag,

dass sich die Probanden die Situation der Analyse der Spezifikation vorstellen muss-

ten. Daher wird empfohlen den Teilnehmern tatsächlich den Auftrag zu geben,

beispielsweise eine Architektur zu designen. Des Weiteren hat man bei der Auswer-

tung der Daten festgestellt, dass die Informationen, die man aus dem „lauten

Denken“ ziehen konnte, die Methode des Eye Tracking praktisch überflüssig ge-

macht haben, da sie eine ähnliche Präzision boten (Gross12b).

3.2.2 Software Engineering Projekt Studie

Die zweite Studie untersuchte ebenfalls die Frage F1_1 in Bezug auf die Rolle Archi-

tekt. Sie fand im Rahmen eines Softwareentwicklungsprojektes an der Universität

Kaiserslautern statt. Dort hatten 13 Studenten in Teams von vier bis fünf Personen

die Aufgabe den kompletten Entwicklungsprozess über Anforderungserhebung, Er-

stellen der Spezifikation bis hin zur Fertigstellung des Softwareprodukts für ein

Accountmanagementsystem zu durchlaufen (Gross12b). Bei den Teilnehmern han-

delte es sich um neun Bachelor Informatikstudenten und vier Diplom

Wirtschaftsingenieure mit Spezialisierung auf Informatik. Jeder von ihnen hatte be-

reits zuvor einen Kurs zur Vorstellung von wesentlichen Software Engineering

Methoden besucht, in der auch das TORE-Framework (Adam09), mit dem die Spe-

zifikation erstellt wurde, vorgestellt wurde (Gross12b).

Im Anschluss an das dreimonatige Projekt bewerteten die Studenten die in der An-

forderungsspezifikation dokumentierten Informationen in einem Fragebogen mit

einer Relevanz. Die Skala stimmte dabei mit der aus der vorherigen Eye Tracking

Studie überein und umfasste vier Stufen von „Sehr wichtig“ bis „Unwichtig“

(Gross12a). Auch der Rest des Fragebogens, welcher Fragen zu fehlenden Informa-

tionen und nach Gründen für die Einschätzung umfasste, entsprach dem der Eye

Tracking Studie.


13

In der anschließenden Auswertung konnte man einen Unterschied zu der Bewertung

der Architektur- und Usabilityexperten in der ersten Studie feststellen. Als besonders

wichtig wurden Interaktionsbeschreibungen, Systemfunktionalitäten, Qualitäts- und

technische Anforderungen, sowie Stakeholder und Ziele bewertet. Als weniger wich-

tig erachteten die Studenten Datenanforderungen, sowie Beschreibungen von

Aufgaben und Arbeitsweisen. Der Teil über die bisherige Arbeitsweise (as-is work-

flow) wurde als absolut unwichtig beurteilt. Als Erklärung dafür diente, dass die

Studenten bei dem gesamten Entwicklungsprozess dabei waren und einen aktiven

Teil der Anforderungserhebung und dem Erstellen der Spezifikation darstellten. Das

kann einen großen Einfluss auf ihre Einschätzung gehabt haben. Außerdem konnte

eine starke Varianz der Bewertungen zwischen den Studenten beobachtet werden

(Gross12b).

3.2.3 Tutorial Studie

Die dritte und letzte durchgeführte Studie des IESE behandelt F1_1, F1_2 und F1_3 aus

der Perspektive von Usabilityexperten. Dazu sollten zehn Teilnehmer eines Tutorials

über aufgabenorientiertes Requirements Engineering basierend auf dem TORE-

Framework (Adam09) nach dessen Ende in einem Fragebogen die vorgestellten Ar-

tefakt-typen mit einer Relevanz bewerten (Gross12a). Die Art der Bewertung mittels

Stufen von „Sehr wichtig“ bis „Unwichtig“ stimmt dabei mit der Skala der vorherigen

beiden Studien überein, um Vergleichbarkeit sicherzustellen. Auch nach Gründen

der Bewertung und der Eignung der Notation wurde genauso wie in den bisherigen

Fragebögen gefragt. Zusätzlich wurden jedoch, im Hinblick auf Forschungsfrage F1_2,

die Punkte, die der Artefakttyp enthielt, aufgeführt und der Proband sollte angeben,

welche er für wichtig erachtet (Gross12b). Damit sollte eine Aussage darüber getrof-

fen werden, wie detailliert die Abschnitte ausfallen sollten.

Die Ergebnisse der Studie ergaben ebenfalls Unterschiede zu den Bewertungen der

UI-Experten aus der Eye Tracking Studie, sowie Varianzen innerhalb der Teilneh-

mergruppe (Gross12a). Demnach wurden alle Artefakttypen als wichtig oder sehr

wichtig eingestuft. Die einzige Ausnahme bilden die Interaktions- und Domänenda-

ten, die als eher unwichtig bewertet wurden (Gross12b). Dies ließ sich durch die

angegebenen Kommentare erklären, die aussagten, dass aus Sicht der Teilnehmer

relevante Daten eher zusammen mit Interaktionsbeschreibungen (wie beispielsweise

Use Case-Beschreibungen) spezifiziert werden sollten. Weitere Ergebnisse, die

ebenfalls die Frage F1_3 adressieren, sagen aus, dass von den untersuchten Usabi-

lityexperten visuelle Repräsentationen im Vergleich zu textuellen Beschreibungen

generell bevorzugt werden. Jedoch konnte auch bei dieser Studie eine mögliche Ge-

fährdung der Resultate identifiziert werden, da die Teilnehmer erneut keine echte

Aufgabe umzusetzen hatten, sondern sich lediglich in die Situation hineinversetzen

mussten. Dennoch werden Studien dieser Art als geeignetes Mittel der Datenerhe-

bung eingeschätzt. Als zusammenfassende Schlussfolgerung hat das Fraunhofer

IESE festgehalten, dass die bisherigen Studien noch nicht ausreichten, um valide

Schlüsse ziehen zu können, die beobachteten Tendenzen jedoch vielversprechend

und weitere aufbauende Studien daher durchaus lohnenswert seien (Gross12b).

3.3 Ähnliche Studien zum Vergleich der Darstellungsform

Über die soeben aufgeführten Studien hinaus, stützt sich die durchgeführte Studie

außerdem auf die Ergebnisse einiger Studien, die ebenfalls die beiden Darstellungs-

formen Papier und Bildschirm miteinander verglichen haben (Dillon02). Diese

wurden zwar nicht im Kontext von Anforderungsspezifikationen durchgeführt, können

dennoch als Vergleichsmöglichkeit für die Resultate dienen.


14

Der Autor Andrew Dillon hat in seinem Buch „Reading from paper versus screens: a

critical review of empirical literature“ einige bis zu dem Zeitpunkt durchgeführte Stu-

dienergebnisse verglichen und hinterfragt (Dillon92). Dabei hat er mögliche zu

messende Merkmale zum Vergleich von den beiden Darstellungsmedien Papier und

Bildschirm in Ergebnis- und Prozessmerkmale („outcome vs. process measures“ (Dil-

lon92)) unterteilt. Ergebnismerkmale beziehen sich dabei auf das was ein Leser von

dem Text erhält. Das können Metriken wie aufgenommene Informationen, Wieder-

gabefähigkeit oder benötigte Lesezeit. Prozessmerkmale hingegen konzentrieren

sich darauf, wie der Leser den Text verwendet, beispielsweise das Blickverhalten

währenddessen oder wie Veränderungen durch Notizen oder ähnliches vorgenom-

men werden. Die Literatur und Forschung beschäftigt sich dabei hauptsächlich mit

Ergebnismerkmalen, da diese auf ein größeres Interesse stoßen und diesbezüglich

mehr Hypothesen aufgestellt werden (Dillon92).

In diesem Abschnitt werden einige betrachtete Metriken und die diesbezüglichen Er-

kenntnisse zusammengefasst. Dabei liegt das Hauptaugenmerk auf den Messungen,

die auch in der Studie, die im Rahmen dieser Arbeit durchgeführt wurde, betrachtet

wurden. Zu den thematisierten Ergebnismerkmalen gehört zum einen die Lesege-

schwindigkeit. Diese ist die mit Abstand am meisten untersuchte Metrik. Das

häufigste Ergebnis dabei war, dass das Lesen am Bildschirm signifikant langsamer

ist als das Lesen auf Papier. Studien belegen hierbei einen Performanzverlust von

20% bis 30% bei dem Lesen am Monitor. Den Untersuchungen liegen jedoch jeweils

unterschiedliche Berechnungen und Experimentdesigns zugrunde. Daher ist nicht

klar, ob immer die gleichen Gründe zu diesem Geschwindigkeitsverlust geführt ha-

ben. Andere Studien konnten wiederum keinen signifikanten Unterschied zwischen

den beiden Darstellungsmedien bei der Lesegeschwindigkeit feststellen. Es wird da-

her vermutet, dass der gefundene Unterschied womöglich von der Größe, Qualität

und dem Typ des Monitors abhängig ist (Dillon92).

Ein weiteres Kriterium in Bezug auf den Vergleich von der Darstellung auf Papier und

Bildschirm ist Genauigkeit, wie beispielsweise bei dem Finden von Informationen in

einem Text, der Wiedergabe bestimmter Sektionen oder dem Auffinden von Recht-

schreib- und Grammatikfehlern. Einschlägige Studien hierzu haben zum Beispiel

Buchstaben von Wörtern in einem Text vertauscht, hinzugefügt oder weggelassen

und die Leser sollten diese auffinden. Dabei wurden jedoch keine signifikanten Er-

gebnisse gefunden. Anders sieht es da bei Untersuchungen der Wiedergabefähigkeit

aus oder generell bei Aufgaben mit einem höheren visuellen und kognitiven An-

spruch. Bei diesen konnte ein Performanzdefizit beim Lesen am Monitor

nachgewiesen werden (Dillon92).

Eine andere untersuchte Metrik ist außerdem die Präferenz des Lesers, welche Dar-

stellungsform bevorzugt wird. Erste Studien haben dazu unterschiedliche Ergebnisse

erhalten. Je aktueller die Untersuchungen jedoch sind, umso eindeutiger geht die

Tendenz zu der Bevorzugung der digitalen Darstellung. Das wird sich dadurch er-

klärt, dass sich die Bildqualität neuerer Monitore über die Jahre deutlich verbessert

hat. Darüber hinaus ebenfalls ein im Zuge der Verbreitung digitaler Medien häufig

diskutierter Punkt ist eine höhere Neigung zu Müdigkeit bei dem Lesen am Bild-

schirm. Aber auch die Verständlichkeit des Textes ist eine weitere betrachtete Metrik.

Diesen Ergebnismerkmalen gegenüber stehen die Prozessmerkmale. Diese werden

hier nicht weiter behandelt, da sie für die durchgeführte Studie keine Bedeutung ha-

ben. Beispiele sind das Untersuchen der Blickbewegungen oder der Navigation des

Lesers im Text (Dillon92).

15

4 Planung der Studie

Die Zielsetzung dieser Arbeit ist es, Spezifikationen effektiver erstellen und effizienter

nutzen zu können. Eine Übersicht, wie dieses Ziel erreicht werden kann, gibt Abbil-

dung 4.1. Darin wird dargestellt, dass um die Voraussetzung für eine sichtenbasierte

Anforderungsspezifikation bzw. ein entsprechendes Tool zu schaffen, zunächst die

Informationsbedarfe der einzelnen Rollen untersucht werden müssen, um festzustel-

len welche Abschnitte für wen relevant sind. Die dafür nötigen Daten werden

innerhalb einer Studie erhoben, deren Planungsschritte in diesem Kapitel ausführlich

dokumentiert sind. Darüber hinaus wird innerhalb der Studie eruiert, welchen Effekt

die Darstellung ausgedruckt auf Papier oder am Bildschirm auf den Leseprozess hat.

Grundlage dieser Studie sind im Wesentlichen die vom Fraunhofer IESE durchge-

führten Studien, insbesondere die Eye Tracking Studie. Bei der Planung wurden

daher die dort festgestellten Schwächen berücksichtigt.

Abbildung 4.1: Zielsetzung und Motivation der Studie (angelehnt an (Gross11))

4.1 Ziele

4.1.1 Verbesserungsziele

Die folgenden Verbesserungsziele werden von der Studie untersucht.

VZ1: Effizienzsteigerung bei der Nutzung (dem Lesen) von Anforderungsspezifika-tionen im Kontext von Softwareprojekten, abhängig vom Darstellungsmedium und der Rolle des Lesers.

VZ2: Effektivitätssteigerung bei der Erstellung von Spezifikationen im Kontext von Softwareprojekten aus der Perspektive von Anforderungsingenieuren.

4.1.2 Erreichung der Verbesserungsziele

Die beschriebene Effizienzsteigerung soll durch eine auf den Informationsbedarf des

Nutzers hin optimierte Umstrukturierung des Spezifikationsdokuments erreicht wer-

den. Dabei wird die Effizienz anhand der benötigten Zeit zum Auffinden relevanter

Informationen im Dokument bewertet. Durch die Entwicklung solcher sichtenbasier-

ten Spezifikationen wird versucht Zeit und Ressourcen, also Kosten zu sparen, indem

Sichtenbasierte Anforderungsspezifikationen

Informationsbedarfe empirisch erheben

(UI-Designer, Softwarearchitekt, Tester, Entwickler)

Sichten auf Anforderungsdokumente

(z.B. toolbasiert)

Effizientere/ effektivere Nutzung sowie Erstellung


16

der Leseaufwand für am Projekt beteiligte Personen reduziert wird. Zusätzlich wird

die Konformität des fertigen Softwareprodukts mit den Anforderungen erhöht, da

wichtige Aspekte schneller zugreifbar sind (Gross12b).

Im gleichen Zug wird so eine Effektivitätssteigerung für die Anforderungsingenieure

erreicht, da die Spezifikation so einen eindeutig identifizierbaren Adressaten hat, auf

den die enthaltenen Informationen abgestimmt werden können. Die Herausforderung

allen Ansprüchen der Nutzer gleichzeitig gerecht werden zu müssen, fällt daher wei-

testgehend weg. Dadurch wird die Gefahr vermieden, für alle Rollen irrelevante

Aspekte mit aufzunehmen. Darüber hinaus, wird so Zeit im Projekt gespart, da der

Softwarearchitekt beispielsweise bereits mit dem Entwurf eines Entwicklungskon-

zepts beginnen kann, bevor manche Abschnitte, die beispielsweise nur die Rolle des

Testers benötigt, fertig gestellt sind (Gross12b).

Über den Vergleich der Darstellungsmedien kann zusätzlich festgestellt werden, ob

Spezifikationen am Bildschirm oder ausgedruckt unterschiedlich effizient gelesen

werden. In den geplanten Messungen soll es jedoch zunächst darum gehen, den

konkreten Informationsbedarf und die individuellen Anforderungen der verschiede-

nen Rollen, die die Spezifikation nutzen, zu ermitteln, um schließlich das Grundgerüst

für sichtenbasierte Anforderungsspezifikationen bieten zu können.

4.1.3 Betrachtete Darstellungsmedien

Bei der Darstellung werden dabei Papier und Bildschirm berücksichtigt. Das heißt,

es werden einmal am Bildschirm gelesene Spezifikationen und einmal ausgedruckte

Versionen untersucht.

4.1.4 Betrachtete Rollen

Bei der Rolle des Lesers kann es sich entweder um UI-Designer, Softwarearchitek-

ten, Tester oder Entwickler im Allgemeinen handeln. Die Rollen UI-Designer,

Softwarearchitekt und Tester sind dabei in ihrem Aufgabenfeld disjunkt. Die Tätigkeit

des Entwicklers hingegen umfasst die Zuständigkeiten aller drei Rollen. Dies bein-

haltet das Erstellen erster Entwürfe, über deren Umsetzung bis hin zum Herleiten

von Testfällen und deren Ausführung zur Sicherstellung der Anforderungen, sämtli-

che Aufgaben, die zum Entwickeln des Systems notwendig sind.

Für die Rollen Softwarearchitekt, UI-Designer und Tester werden diese Aufgaben

klar aufgeteilt. Der Softwarearchitekt in diesem Sinne ist dabei für die Implementie-

rung sämtlicher Funktionen, die das System bieten soll, also insbesondere der

funktionalen Anforderungen, zuständig. Außerdem fallen das Verwalten von invol-

vierten Daten, sowie das Bereitstellen von Schnittstellen an bestehende

Randsysteme in ihren Aufgabenbereich (Eckstein09). Bei UI-Designern hingegen

handelt es sich um Personen, die sich mit der Gestaltung von Benutzeroberflächen

auskennen und entsprechend nur für dessen Entwicklung zuständig sind (Eck-

stein09). Das heißt, ihre Aufgabe ist es, zunächst Entwürfe zu erstellen und diese zu

implementieren. Sie sind verantwortlich für die Bedienbarkeit des fertigen Produkts,

dessen Verständlichkeit und intuitive Verwendbarkeit. Nicht-funktionale Anforderun-

gen müssen somit sowohl von Softwarearchitekten, als auch von UI-Designern

beachtet und sichergestellt werden.

Der Tester muss zum einen zu Beginn die Akzeptanzkriterien der Software definie-

ren, die er in Form von Abnahmetestfällen festhält. Zum anderen überprüft er

abschließend nach der Implementierung der Komponenten, deren Richtigkeit, also

die Erfüllung der Systemanforderungen, indem er zu diesem Zweck die entsprechen-

den Testfälle ausführt (Eckstein09). Diese Aufgabe hat besondere Priorität, da nur

so die gewünschte Funktionsweise gewährleistet werden kann.


17

In der Praxis werden Rollen unter Umständen auch durch mehrere Personen ausge-

füllt oder eine Person übernimmt mehrere Rollen (Eckstein09). In dieser Studie hat

jedoch jede Person genau eine Rolle und innerhalb eines Durchlaufs mit einem Teil-

nehmer wird diese Rolle auch nur durch eine Person repräsentiert. Dies dient der

Vereinfachung und Sicherung der Auswertung.

4.1.5 Von der Betrachtung ausgeschlossene Rollen

Ebenfalls maßgeblich am Projekt beteiligt und Stakeholder der Spezifikation sind na-

türlich auch weitere Rollen wie Kunden und die Projektleitung. Der Vollständigkeit

halber werden sie daher ebenfalls beschrieben.

Bei dem Kunden handelt es sich in der klassischen Kundensituation um ein Unter-

nehmen, das eine bestimmte Softwarelösung wünscht. Im Falle von

Produktentwicklungen kann auch der Markt die Rolle des Kunden einnehmen (Vers-

teegen03). Der Kunde wird entweder direkt vom Auftraggeber oder eine hierarchisch

tiefer gestellte Person des Fachgebiets vertreten (Günter13). Er tritt dabei als Ver-

tragspartner auf, dessen Grundlage die Spezifikation ist. In dieser müssen alle

gewünschten Funktionalitäten und Eigenschaften enthalten sein, da sich im Zwei-

felsfall darauf berufen werden kann. Der Kunde hat eine wesentliche Rolle im Projekt,

da er die Schnittstelle zwischen der Businesswelt, in der das Produkt Anwendung

findet und der Entwicklerseite bildet. Sämtliche Anforderungen werden mit seiner

Hilfe ermittelt. Unter Umständen liefert er sogar direkt Use Cases oder Testfälle

(Günter13).

Die Rolle des Projektleiters hat umfassend beschrieben die Aufgabe für das Team

eine Umgebung zu schaffen, in der jeder seiner Tätigkeit nachgehen und in Ruhe

arbeiten kann. Dazu kümmert er sich um organisatorische Angelegenheiten, wie die

Etablierung und Gewährleistung der Unterstützung des Projekts innerhalb des Soft-

wareunternehmens und ist zudem im Falle von Konfliktsituationen der verständige

Ansprechpartner für die Teammitglieder (Eckstein09). Darüber hinaus hat er die Ge-

samtverantwortung für das Projekt und wird in alle wichtigen Entscheidungen

integriert (Versteegen03). Oft ist er auch für die Organisation von Einstellungen neuer

geeigneter Mitarbeiter zuständig (Eckstein09).

Da die Tätigkeitsfelder dieser Rollen jedoch sehr umfassend sind und aufgrund des

Mangels an geeigneten Probanden, kann der Informationsbedarf dieser Rollen nur

sehr schwer in einem off-line Experiment, also einer Studie in nicht-industriellem

Rahmen, untersucht werden. Andernfalls wäre die Validität der Daten und somit der

Resultate gefährdet, wenn bestimmte Rollenaspekte unberücksichtigt oder Proban-

den zu sehr aus ihrem gewohnten Arbeitsumfeld entfremdet würden. Daher wurde

sich in dieser Studie lediglich die Rollen beschränkt, die die direkte Entwicklung des

Systems betreffen, um so Aussagen darüber treffen zu können, welche Abschnitte

der Spezifikation für diese Gruppen eine hohe Priorität haben oder irrelevant sind.

4.1.6 Messziel

Um die Verbesserungsziele der Studie erreichen zu können, muss zunächst der In-

formationsbedarf der betrachteten Rollen untersucht werden. Das primäre Ziel der

Messung ist somit die:

MZ1: Untersuchung des Informationsbedarfs der Nutzer von Spezifikationen unter Berücksichtigung dessen Rolle und dem verwendeten Darstellungsmedium.

Dieses deckt sich mit dem Forschungsziel FZ1 des Fraunhofer IESE, was die Ver-

gleichsmöglichkeiten der Resultate ermöglicht (Gross12b).


18

4.2 Fragen

Ausgehend von den Verbesserungs- und Messzielen wurden Fragen erarbeitet, des-

sen Betrachtung das Erreichen der Ziele ermöglicht. Im Anschluss wurden dazu

Metriken definiert, dessen Erfassung zur Beantwortung der Fragestellungen beitra-

gen. Alle Ziele, Fragen und Metriken, sowie dessen Zusammenhänge sind in

Abbildung 4.2 dargestellt. In dieser Studie wurde die Metrikebene des GQM-Para-

digmas in zwei Ebenen aufgespalten, um den Zusammenhang zwischen Metrik und

Fragestellung erkennbarer zu machen. Zu allen Metriken findet sich zudem eine aus-

führliche Beschreibung in Kapitel 4.3.

Abbildung 4.2: Übersicht über Ziele, Fragen und Metriken

Zwischen-

metriken

Verbesserungs-

ziele

Effizienzsteigerung bei der Nut-

zung von Spezifikationen im

Kontext von Softwareprojekten aus der Perspektive von UI-De-

signern, Architekten und

Testern

Effektivitätssteigerung bei der

Erstellung von Spezifikationen

im Kontext von Softwarepro-

jekten aus der Perspektive von

Anforderungsingenieuren

F1: Welche Dar-

stellungsform

(ausgedruckt oder

am Bildschirm) ist

geeigneter?

F2: Welche Ab-

schnitte sind

besonders wichtig/

unwichtig? (rollen-

abhängig)

Wiedergabe-

fähigkeit

Vorliebe

des Le-

sers

Geschwin-

digkeit Intensität

des Lesens

einzelner

Abschnitte

Frage-

bogen Lesezeiten

für AOIs auf

Abschnitten

Länge der

Spezifikations-

abschnitte in

Zentimetern

Gesamt-

lesezeit

Relevanz

F3: Gibt es Un-

terschiede

innerhalb der

Rollen? (rollen-

abhängig)

Untersuchung des Informationsbedarfs

der Nutzer von Spezifikationen unter

Berücksichtigung dessen Rolle und

dem Darstellungsmedium

Messziele

Fragen

Metriken


19

Zu jeder Frage werden im Anschluss überblicksartig die verwendeten Untersu-

chungsobjekte, zugehörige Metriken und zu erwartende Hypothesen aufgelistet.

F1: Darstellungsform

Frage Welche Darstellungsform (ausgedruckt oder am Bildschirm)

ist geeigneter?

Objekt Spezifikation ausgedruckt, Spezifikation am Bildschirm

Zwischenmetrik Vorliebe des Lesers, Wiedergabefähigkeit, Geschwindigkeit

Hypothese HA1_1: Die ausgedruckte Darstellung wird bevorzugt.

HA1_2: Die Wiedergabefähigkeit unterscheidet sich abhängig

von der Darstellungsart.

HA1_3: Die ausgedruckten Spezifikationen werden schneller

gelesen als die am Bildschirm gelesenen Spezifikationen.

F2: Auswahl der Abschnitte

Frage Welche Abschnitte sind für welche Rolle besonders relevant?

Welche sind weniger relevant?

Objekt Spezifikationen

Zwischenmetrik Priorisierung des Lesers, Intensität des Lesens einzelner Ab-

schnitte

Hypothese HA2_1: Die Abschnitte werden unterschiedlich bewertet.

F3: Unterschiede zwischen den Rollen

Frage Gibt es Unterschiede zwischen den Informationsbedarfen ein-

zelner Rollen?

Objekt Spezifikationen

Zwischenmetrik Priorisierung des Lesers

Hypothese HA3_1: Bei mindestens zwei Rollen unterscheiden sich die Mit-

telwerte der Relevanzbewertung.

HA3_2: Wichtig bewertete Abschnitte werden intensiver gele-

sen als unwichtig bewertete und umgekehrt.

4.3 Metriken

Die Metriken, die zur Beantwortung der zuvor aufgestellten Fragen nötig sind, werden

hier genau beschrieben. Die Metrik-Ebene des GQM-Paradigmas wurde, wie bereits

zuvor beschrieben, in die beiden Unterebenen Zwischenmetrik und Metrik aufgeteilt.

Zu jeder hier definierten Zwischenmetrik ist festgehalten, welche konkreten Metriken

zum Messen notwendig sind, wie diese ausgeführt werden und um welchen Skalen-

typ es sich handelt.


20

4.3.1 Beschreibung der Zwischenmetriken

M1: Präferenz des Lesers

Um festzustellen, welche Darstellungsform der Leser präferiert, wird ein Fragebogen

konzipiert, der dem Probanden vor dem Lesen der Spezifikation übergeben wird und

in dem dieser seine Vorliebe festhält (siehe A.2.1). Dort wählt er entweder ausge-

druckt oder am Bildschirm. Aufgrund der beiden voneinander unabhängigen

Antwortmöglichkeiten ohne implizierte Rangordnung, handelt es sich hierbei um eine

Nominalskala.

M2: Wiedergabefähigkeit

Unter Wiedergabefähigkeit wird hier die Fähigkeit verstanden, nach dem Lesen des

Dokuments darin befindliche Inhalte wiedergeben zu können. Dies erfolgt ebenfalls

in einem Fragebogen nach dem Lesen der Spezifikation. Dazu werden insgesamt

sechs Fragen zum Inhalt gestellt. Zu jeder Frage gibt es drei Antwortmöglichkeiten,

von denen jeweils genau eine richtig ist. Anschließend wird die Anzahl an richtigen

Antworten bestimmt, wobei es auch als falsch gewertet wird, wenn eine Frage nicht

beantwortet oder mehr als eine Antwort abgegeben wird. Bei den Fragen handelt es

sich jeweils um Nominalskalen, bei der Anzahl an richtigen Antworten, die daraus

ermittelt wird, um eine Verhältnisskala.

M3: Priorisierung des Lesers

Die Feststellung der Priorisierung des Lesers wird ebenso in demselben Fragebogen

gemessen. Dazu werden alle Abschnitte der gelesenen Spezifikation aufgelistet und

sind vom Probanden subjektiv mit sehr wichtig, wichtig, weniger wichtig oder unwich-

tig zu bewerten. In einer vorherigen Einleitung (siehe A.1) wird darauf hingewiesen,

dass es dabei nicht um die allgemeine Relevanz im Projekt geht, sondern nur darum,

ob der jeweilige Abschnitt wichtig ist, um die Tätigkeiten der Rolle des Teilnehmers

ausführen zu können. Dabei handelt sich um dieselbe Ordinalskala, die auch bei der

Studie des Fraunhofer IESE verwendet wurde, um die Ergebnisse später vergleichen

zu können (Gross12b).

M4: Geschwindigkeit

Die Geschwindigkeit mit der der Leser das Dokument liest wird in cm/s (Zentimeter

pro Sekunde) gemessen. Dazu wird zum einen die Länge der einzelnen Abschnitte

in Zentimetern bestimmt und zum anderen die jeweilige Lesedauer in Sekunden ge-

messen. Die Geschwindigkeit wird daraus indirekt errechnet, indem die Summe der

Abschnittslängen durch die Summe der Lesezeiten dividiert wird. Dabei sei darauf

hingewiesen, dass damit nicht die tatsächliche Lesegeschwindigkeit gemessen wird,

da nicht davon ausgegangen werden kann, dass jede Zeile gelesen wird. Es handelt

sich lediglich um einen Vergleichswert, wie viel Zeit Nutzer von Spezifikationen zum

Lesen benötigen, abhängig von der Darstellungsart. Bei der Messskala handelt es

sich hierbei um eine Verhältnisskala (ratio scale).

M5: Intensität des Lesens einzelner Abschnitte

Mit dieser Metrik wird gemessen wie intensiv die einzelnen Abschnitte gelesen wer-

den. Dazu wird auf jedem Abschnitt der Spezifikation mithilfe der EyeTracking

Analysesoftware ein Area of Interest (AOI) definiert und so die Lesezeiten für alle

Abschnitte miteinander verglichen. Um daraus zu ermitteln, wie intensiv der jeweilige

Teil gelesen wurde, werden die Werte für die Lesedauer anschließend mit den Län-

gen der Abschnitte relativiert. So erhält man die entsprechenden Leseintensitäten in

der Einheit s/cm (Sekunden pro Zentimeter). Die Messung der Lesezeiten und Ab-

schnittslängen erfolgt auf einer Verhältnisskala (ratio scale).

21

5 Vorbereitung der Studie

In diesem Kapitel werden die verwendeten Untersuchungsobjekte, Messverfahren

und -instrumente, sowie das konkrete Design der Studie beschrieben.

5.1 Auswahl der Untersuchungsobjekte

Bei den Untersuchungsobjekten der Messung handelt es sich um die jeweiligen Spe-

zifikationen, dessen Verwendung mithilfe des EyeTrackers Red-m, sowie den

EyeTracking Glasses untersucht wird. In dieser Studie werden zwei Spezifikationen

verwendet, die beide dem Spezifikationstemplate für Softwareprojekte des Fachge-

biets Software Engineering der Leibniz Universität Hannover folgen. Einen Überblick

darüber gibt Abbildung 5.1.

Für die Studie wurden die Spezifikationen jedoch insofern abgeändert, dass zum ei-

nen im Dokument vorkommende Namen entfernt oder anonymisiert wurden und

zusätzlich die Abschnitte „Entwurf der grafischen Benutzeroberfläche“ bzw.

„MockUps“ und „Abnahmetestfälle“ entfernt wurden, da die Probanden mit den Rol-

len UI-Designer, Tester und Entwickler andernfalls in Ihrer Aufgabe beeinflusst

würden.

Abbildung 5.1 macht außerdem deutlich, dass die Spezifikationen, die nach diesem

Template erstellt werden, eine Zusammenführung von Lasten- und Pflichtenheft sind.

In ihnen werden sowohl die Wünsche und Prioritäten des Kunden, aber auch kon-

krete Umsetzungsansätze der Entwickler genannt. Das hilft dabei im Nachhinein bei

der Auswertung Abschnitte beider Kategorien bewerten zu können und sich nicht auf

Lasten- oder Pflichtenheft beschränken zu müssen.

Bei der Auswahl der Spezifikationen wurde darauf geachtet, dass sie den Teilneh-

mern der Studie noch nicht bekannt waren, um Einflüsse durch Vorwissen, wie sie in

der zweiten Studie des IESE vorkamen (Gross12b), zu vermeiden.

Die erste Spezifikation enthält eine Beschreibung der Anwendung „Set!“. Set ist ein

Kartenspiel bei dem es darum geht bestimmte Muster in den für alle Mitspieler sicht-

bar ausgelegten Karten zu finden. Dieses Spiel soll in dem Projekt als

Desktopanwendung mit einem Einzelspielermodus und einem Mehrspielermodus

umgesetzt werden. Im Mehrspielermodus können bis zu sechs Spieler über eine Ser-

ververbindung an einem gemeinsamen Spiel teilnehmen. Die Anwendung soll in der

Programmiersprache Java entwickelt werden.

Bei der zweiten Spezifikation handelt es sich um die Beschreibung einer Überset-

zungsanwendung. Diese Webanwendung mit dem Namen „Translate“ soll Nutzer bei

dem Schreiben wissenschaftlicher Arbeiten bzw. dem Verstehen fremdsprachiger

Veröffentlichungen unterstützen, indem es zu einem Wort verschiedene Überset-

zungsmöglichkeiten, sowie Synonyme ausgibt. Die Übersetzung erfolgt vom

Deutschen ins Englische oder anders herum. Alle Ergebnisse werden dabei gegebe-

nen Übersetzungswebseiten, wie z.B. dict.leo.org oder translate.google.de,

entnommen. Dem Nutzer ist es zudem möglich weitere Onlinewörterbücher hinzuzu-

fügen und sie mit einer Gewichtung zu bewerten. Beide Spezifikationen kamen

einmal in digitaler und einmal in ausgedruckter Form zum Einsatz. Ausgedruckt wur-

den sie einseitig auf weißem Papier in Schriftgröße zwölf der Schriftart Times New

Roman. In digitaler Form wurden sie ganzseitig auf einem etwa 22“ großen Monitor

mit hoher Auflösung angezeigt.


22

Abbildung 5.1: SE-Template Spezifikationen (Schneider15)

5.2 Kontextbeschreibung

Die Studie wird im Rahmen eines off-line Quasi-Experiments durchgeführt. Das

heißt, die Studie findet nicht im Umfeld eines echten Projekts in einem Unternehmen

statt, sondern in einer definierten Forschungsumgebung. Das bringt jedoch den Vor-

teil guter Replikations- und Vergleichsmöglichkeiten mit sich, da der Kontext somit

klar spezifiziert ist und wieder herbeigeführt werden kann. Damit unterscheidet es

sich von einem echten Projekt, das nach Abschluss nicht wiederholt werden kann

(Wohlin00).

Ein Quasi-Experiment ist es deshalb, da die Auswahl der Teilnehmer nicht mit der

für ein echtes Experiment erforderlichen Zufälligkeit erfolgt (Wohlin00). Das ergibt

sich daraus, dass nicht eine zufällige Stichprobe der betrachteten Personengruppe

ausgewählt wurde, sondern die Teilnehmer sich auf freiwilliger Basis für die Studie

melden konnten.

5.2.1 Testpersonen (Stichprobe)

Bei acht der elf betrachteten Versuchsteilnehmer handelt es sich um Informatikstu-

denten der Leibniz Universität Hannover. Eine Hälfte von ihnen ist im zweiten oder

vierten Mastersemester, die andere Hälfte im sechsten oder achten Semester im Ba-

chelorstudium. Alle Teilnehmer sind zwischen 21 und 40 Jahre alt und haben gute

bis sehr gute Deutschkenntnisse. Das heißt, es sollte bei keinem Probanden zu

sprachlichen Verständnisproblemen der Spezifikationen gekommen sein. Zudem ha-

ben alle Testpersonen vorher schon einmal nach einer Spezifikation entwickelt oder

Spezifikationstemplate

Softwareprojekt, Leibniz Universität Hannover

1 Mission des Projekts

1.1 Erläuterungen des zu lösenden Problems

1.2 Wünsche und Prioritäten des Kunden

1.3 Domänenbeschreibung

1.4 Maßnahmen zur Anforderungsanalyse

2 Rahmenbedingungen und Umfeld

2.1 Einschränkungen und Vorgaben

2.2 Anwender

2.3 Schnittstellen und angrenzende Systeme

3 Funktionale Anforderungen

3.1 Use Case-Diagramme

3.2 Use Case-Beschreibungen

3.3 Technische Anforderungen

4 Qualitätsanforderungen

4.1 Qualitätsziele des Projekts

4.2 Qualitäts-Prioritäten des Kunden

4.3 Wie Qualitätsziele erreicht werden sollen

5 Probleme und Risiken

6 Optionen zur Aufwandsreduktion

6.1 Mögliche Abstriche

6.2 Inkrementelle Arbeit

7 MockUps

8 Glossar

9 Abnahme-Testfälle


23

sind zumindest in der Lehrveranstaltung „Software-Projekt“ damit in Berührung ge-

kommen.

Bei den drei Probanden, die keine Informatikstudenten (mehr) sind, handelt es sich

um erfahrene Entwickler. Einer von ihnen arbeitet als Produktmanager und Entwick-

ler in einem Startup. Der zweite ist in einem Unternehmen mit etwa 70 Mitarbeitern

als Softwareentwickler tätig, fungiert außerdem als Teamleiter berichtend für die

übergeordnete Ebene. Darüber hinaus hat er hin und wieder auch Kontakt mit den

Kunden. Der dritte und letzte erfahrene Versuchsteilnehmer arbeitet als Integrations-

architekt. In seinen Aufgabenbereich fallen Schnittstellen von Software, sowie das

Erstellen und „Reviewen“ von Spezifikationen und teilweise Programmiertätigkeiten.

5.2.2 Untersuchungsumgebung

Die Studie fand in einem geschlossenen Raum in der Leibniz Universität Hannover

statt. Die Umgebung war für die Teilnehmer ruhig und störungsfrei, sodass sie sich

voll und ganz auf die Inhalte der Studie konzentrieren konnten. Der Termin wurde für

jeden individuell festgelegt und lag zwischen 10:00 Uhr und 15:40 Uhr, im Zeitraum

von knapp drei Wochen. Außer Tageslicht wurden keine weiteren Lichtquellen ver-

wendet und um eine geeignete Messumgebung für das Eye Tracking zu schaffen

wurde direktes Sonnenlicht ggf. abgedämmt.

5.3 Datenquellen und Messmethoden

Sämtliche während der Studie erfasste Daten werden über Fragebögen, die entwe-

der auf Papier oder am Bildschirm beantwortet werden, den Eye Tracker Red-m für

die am Monitor gelesenen Spezifikationen und die Eye Tracking Glasses für die aus-

gedruckten Exemplare gesammelt. Die Datenerfassung erfolgt dabei komplett

anonym. Das heißt, die Angaben von jedem Teilnehmer werden mit einer Teilneh-

mer-ID, die fortlaufend von 001 bis 013 den Probanden zugeteilt wird, versehen und

so können die Daten der Fragebögen und die Aufnahmen der EyeTracker einander

zugeordnet werden.

5.3.1 Fragebögen

Der erste Fragebogen (siehe A.2.1), der vor dem Lesen der Spezifikation ausgehän-

digt wird, enthält Fragen zu dem Hintergrund der Teilnehmer. Dazu gehören das

Alter, der Erfahrungsstand und welche Darstellungsform bevorzugt wird, sowie im

Fall von Studenten der Studiengang und das Semester. Der zweite Fragebogen

(siehe A.2.2 und A.2.3) dagegen beinhaltet zunächst die sechs inhaltlichen Fragen,

die die Wiedergabefähigkeit feststellen sollen und anschließend sind die Abschnitte

der Spezifikation aufgelistet, zu denen der Teilnehmer jeweils eine Relevanzein-

schätzung von Sehr wichtig, über Wichtig und Weniger wichtig bis hin zu Unwichtig

abgeben kann. Diese Skala entspricht exakt der in den Studien des Fraunhofer IESE

(Gross12b) verwendeten Ordinalskala.

Die inhaltlichen Fragen wurden so konzipiert, dass zu beiden Spezifikationen eine

Frage zu dem Abschnitt „Mission des Projekts“, ein bis zwei Fragen zu den Abschnit-

ten „Rahmenbedingungen und Umfeld“, sowie „Funktionale Anforderungen“

enthalten sind und dazu noch jeweils eine Frage zu den Kapiteln „Qualitätsanforde-

rungen“ und „Probleme und Risiken“. So wird sichergestellt, dass mindestens eine

Frage einen Abschnitt betrifft, der für die Rolle des Probanden relevant ist. Dies ist

zwar für die Auswertung irrelevant, da die Ergebnisse der Fragen nur rollenübergrei-

fend verglichen werden, verunsichert die Probanden jedoch nicht so sehr.

Beide Fragebögen sind während der Studie zweimal zu beantworten – einmal aus-

gedruckt bei dem Durchlauf mit den Eye Tracking Glasses und einmal am PC bei


24

dem Durchlauf mit dem externen Eye Tracker. Die Reihenfolge variiert dabei zufällig

von Teilnehmer zu Teilnehmer. Im Falle des externen Eye Trackers werden die Fra-

gen jeweils bildschirmfüllend mit schwarzer Schrift auf hellgrauem Hintergrund

angezeigt. Dabei ist es nicht möglich, keine oder mehr als eine Antwort pro Frage

anzugeben.

5.3.2 Experiment in der Eye Tracking Software

Um Daten mithilfe des externen Eye Trackers am Monitor aufnehmen zu können,

muss dazu vorab ein Experiment erstellt und darin einzelne Stimuli, wie beispiels-

weise Fragen, Web- oder PDF-Seiten, definiert werden. Obwohl nur während dem

Lesen der Spezifikation Daten aufgenommen werden, wurden auch die Fragen des

ersten und zweiten Fragebogens für den Durchlauf mit der digitalen Spezifikation in

die Software integriert, um die Eingewöhnungsphase mit dem Eye Tracker auszu-

gleichen, da der Proband dann bereits einige Zeit am Bildschirm verbracht hat, wenn

mit der Aufnahme begonnen wird. Des Weiteren lassen sich die Daten in der Analyse

auf diese Weise nach den Antworten der Probanden filtern.

Das Experiment, dass für diese Studie erstellt wurde, besteht zunächst aus den zwölf

allgemeinen Fragen, gefolgt von einigen einführenden Worten und der Spezifikation.

Die beiden verwendeten Spezifikationen lassen sich aufgrund ihrer Länge nur als

PDF-Stimulus einbinden. Das bedeutet, dass die Spezifikation als PDF-Dokument

jeweils seitenweise, bildschirmfüllend angezeigt wird und der Proband die Möglich-

keit hat mithilfe der linken und rechten Pfeiltaste zu navigieren. Gewohnte

Interaktionen wie Zoomen, Scrollen innerhalb von Seiten oder die Suchfunktion, sind

hierbei nicht möglich. Nachdem der Teilnehmer die Spezifikation gelesen hat, gelangt

er zu den sechs inhaltlichen Fragen und wird anschließend durch die Überschriften

der einzelnen Spezifikationsabschnitte geleitet, bei denen er jeweils eine Relevanz

zwischen Sehr wichtig und Unwichtig auszuwählen hat.

5.4 Design der Studie

Da nun das Umfeld, sowie die Untersuchungssubjekte und -objekte beschrieben

sind, kann anschließend der Ablauf der Studie geplant werden. Jedem Probanden

wurden in der Studie beide ausgewählten Spezifikationen nacheinander zum Lesen

zur Verfügung gestellt. Davon ist jeweils eine in digitaler Form am Bildschirm und

eine in ausgedruckter Fassung auf Papier. Bei der Verteilung wurden die generellen

Designprinzipien Randomisierung, Blocking und Balancing berücksichtigt

(Wohlin00).

5.4.1 Randomisierung

Jeder Teilnehmer der Studie erhält eine Spezifikation ausgedruckt und eine zum Le-

sen am Bildschirm. Die Reihenfolge, welche der beiden Darstellungsarten zuerst

verwendet wird erfolgt zufällig. Auch die Auswahl der ersten Spezifikation und die

Zuordnung zu einer der Rollen geschieht zufällig, sodass das Prinzip der Randomi-

sierung eingehalten wird.

5.4.2 Blocking

Eine angepasste Version des Blocking-Ansatzes wird in diesem Fall insofern ange-

wandt, dass Unterschiede zwischen den Spezifikationen, die womöglich das

Ergebnis beeinflussen könnten, ausgeblendet werden, indem jede Spezifikation bei

jeder Rolle gleich oft untersucht wird. Das heißt, für jede Rolle werden die gleichen

Spezifikationen betrachtet, sodass eventuelle spezifikationsabhängige Faktoren bei

allen Gruppen gleich sind.


25

5.4.3 Balancing

Bei dem Design der Studie handelt es sich zudem um ein ausgeglichenes (balanced)

Design. Dies wurde erreicht, indem folgende Grundsätze eingehalten wurden.

1. Für jede Rolle und jede Spezifikation werden gleich viele Datensätze von der

gleichen Anzahl Probanden aufgenommen.

2. Jeder Teilnehmer nimmt genau eine Rolle ein und bekommt die gleiche An-

zahl Spezifikationen zum Lesen.

3. Den beiden Darstellungsarten ausgedruckt und am Bildschirm werden jeweils

gleich viele Teilnehmer, sowie Spezifikationen zugeordnet.

4. Jede Spezifikation wird gleich oft in ausgedruckter und digitaler Form unter-

sucht.

Die einzige Abweichung von diesem Designprinzip liegt bei den Aufnahmen der er-

fahrenen Entwickler vor, da hierbei drei Teilnehmer untersucht wurden und nicht nur

zwei, wie es bei den anderen Rollen der Fall war. Einer der Teilnehmer hat zudem,

da er es nicht anders einrichten konnte, nur die Hälfte der Studie absolviert. Das

heißt, er hat nur eine Spezifikation gelesen und die entsprechenden Fragebögen be-

antwortet und nimmt daher eine Sonderrolle ein. Diese Abweichung hat jedoch keine

weitreichenden Konsequenzen und wurde bei den entsprechenden Tests in der Aus-

wertung berücksichtigt, in dem in Einzelfällen die Daten dieser Versuchsperson nicht

mitberücksichtigt wurden.

5.5 Zuordnung der Untersuchungssubjekte und -objekte

Entsprechend der eben beschriebenen Designprinzipien wurde den Teilnehmern zu-

fällig eine Rolle und eine Reihenfolge der Spezifikation und Darstellungsart zugeteilt,

so dass am Ende alle Kombinationen gleichmäßig besetzt sind.

In Tabelle 5.1 ist diese Zuordnung dargestellt. In der ersten Spalte steht dabei die ID

des Teilnehmers, die den Probanden in chronologischer Reihenfolge zugeteilt wurde.

Das heißt, je höher die ID des Teilnehmers, desto später fand der entsprechende

Durchlauf der Studie statt. In den Spalten zwei bis fünf sind die Spezifikationen an-

gegeben. Die beiden verwendeten Spezifikationen „Set“ und „Translate“ erscheinen

jeweils einmal in ausgedruckter Form mit der Kennung „_a“ oder in digitaler Form am

Bildschirm mit der Kennung „_d“. Die in den Feldern angegebene Nummer impliziert

die Reihenfolge, in der die Spezifikationen den Probanden gegeben werden. Ab-

schließend ist in der letzten Spalte die zugeteilte Rolle vermerkt. Jede der vier

möglichen Rollen wurde dabei genau zweimal besetzt, um für jede Rolle einen Ver-

gleichswert zu haben. Die Anzahl an Teilnehmern wurde auf elf beschränkt, da die

Vor- und Nachbereitung und die Durchführung eines Durchlaufs, sowie die Analyse

der Aufnahmedaten der Eye Tracking Glasses sehr zeitaufwändig ist und sonst den

Rahmen der Studie überschreiten würde.


26

Tabelle 5.1: Übersicht über die Zuordnung der Probanden

5.6 Beschreibung des Ablaufs

Der Fortgang der Studie ist für jeden Teilnehmer genau gleich, abgesehen von der

Reihenfolge der ausgewählten Darstellungsmedien Papier und Monitor und der Rei-

henfolge der beiden Spezifikationen „Set“ und „Translate“. Alle Probanden werden

dabei von der gleichen Person betreut, um Fragen stellen zu können und durch das

Experiment begleitet zu werden. Eben diese Person ist auch dafür zuständig, Auffäl-

ligkeiten zu dokumentierten, die unter Umständen bei der Durchführung der Studie

auftreten könnten.

Zu Beginn der Studie wird der Proband gebeten sich zu setzen und bekommt zu-

nächst den allgemeinen Ablauf der Studie erklärt, um sich darauf einstellen zu

können. Anschließend liest er die Einführung (siehe A.1). In dieser sind weitere all-

gemeine Informationen zur Studie gegeben. Darüber hinaus erfährt der Teilnehmer

hier die Aufgabe, die er während der Studie zu bearbeiten hat. Diese umfasst die

ersten Tätigkeiten, die die zugewiesene Rolle umfasst (siehe 4.1.4). Es wurde gro-

ßen Wert darauf gelegt, dass die Teilnehmer sich nicht nur ihre Tätigkeit vorstellen,

sondern tatsächlich einen UI- oder Architekturentwurf konzipieren sollen, um Ein-

flüsse durch diese Abweichung von den realen Umständen zu umgehen (Gross12b).

Darüber hinaus sollen die Teilnehmer sich nur auf ihre Rolle und Aufgabe konzent-

rieren und nicht versuchen die Studienergebnisse in eine bestimmte Richtung zu

lenken. Daher wird ihnen nicht mitgeteilt, was das Ziel der Studie und die jeweilige

Hypothese ist, um solche Beeinflussungen zu vermeiden. Außerdem werden sie da-

rauf hingewiesen, dass die Studie anonym erfolgt und es kein Test ihrer Fähigkeiten

darstellt.

Nachdem der Teilnehmer die Einführung gelesen hat, hängt der weitere Verlauf da-

von ab, ob mit der ausgedruckten oder der am Bildschirm gelesenen Spezifikation

Teilnehmer Spezifikationen Rolle

Set_a Set_d Translate_a Translate_d

002 1. 2. Softwarearchi-tekt

003 2. 1. Tester

004 2. 1. Softwarearchi-tekt

005 2. 1. UI-Designer

006 1. 2. Tester

007 1. 2. Entwickler (Student)

008 1. 2. Entwickler (Student)


011 1. 2. Entwickler (mit Erfahrung)




27

begonnen wird. Im Fall der ausgedruckten Spezifikation beantwortet der Proband

nun den ersten Fragebogen (siehe A.2.1) und anschließend wird er gebeten die Eye

Tracking Brille aufzusetzen. Nachdem geprüft wurde, dass diese richtig sitzt und die

Software für die Kalibrierung bereit ist, wird diese durchgeführt und es kann mit der

Aufnahme begonnen werden. Zu diesem Zeitpunkt wird der Teilnehmer darauf hin-

gewiesen, dass ihm nun die Spezifikation ausgeteilt wird und er ab dann 20 Minuten

Zeit zum Lesen der Spezifikation und zum Bearbeiten seiner Aufgabe hat. Es wird

betont, dass die Bearbeitung auch schrittweise erfolgen kann und das Lesen der

Spezifikation für Notizen oder erste Skizzen unterbrochen werden darf. Die Vorgabe

ist lediglich nach 20 Minuten die Aufgabe zu beenden.

Anschließend, sobald der Teilnehmer dies bestätigt hat, erhält er die Spezifikation

und die Aufnahme der Brille, sowie die Zeit wird gestartet. In 5 Minuten Abständen,

sowie eine Minute vor Ablauf der Bearbeitungszeit wird dem Probanden der aktuelle

Zeitstand mitgeteilt. Die Zeit wird mit einer Stoppuhr gemessen und nach dessen

Ablauf wird die Aufnahme des Eye Trackers gestoppt und der Proband darf die Brille

wieder absetzen. Abschließend wird ihm noch der zweite Fragebogen ausgeteilt. Das

Bild in Abbildung 5.2 zeigt wie die Versuchsumgebung für die Teilnehmer bei dem

Lesen der ausgedruckten Spezifikation aussah.

Wird mit der am Bildschirm gelesenen Spezifikation begonnen, erfolgt die gesamte

Befragung für diese Spezifikation in dem zuvor erstellten Experiment in der Eye Tra-

cking Software Experiment Center. Um mit diesem beginnen zu können, wird vorerst

überprüft, ob der Teilnehmer den richtigen Abstand und Winkel zu dem Bildschirm

und dem Eye Tracker hat. Nachdem dieser ggf. nachjustiert wurde, kann die Auf-

nahme gestartet werden. Diese beginnt vorerst mit einer 5-Punkt Kalibrierung.

Anschließend wird der Proband Schritt für Schritt durch die Studie geführt. Das Ex-

periment besteht dabei zunächst aus einem Fragenteil, der dem ersten Fragebogen

entspricht. Daraufhin wird eine kurze Infomeldung angezeigt, die den Probanden auf

die Spezifikation im Anschluss, sowie das Zeitlimit hinweist. Der Ablauf während der

Bearbeitung erfolgt analog zu der ausgedruckten Spezifikation. Ist die Zeit abgelau-

fen, wird der PDF-Stimulus mit der Spezifikation vom Versuchsbetreuer abgebrochen

und der zweite Fragenteil beginnt.

Bevor jeweils mit der zweiten Hälfte begonnen wird, hat der Versuchsteilnehmer die

Möglichkeit eine kurze Pause einzulegen. Anschließend erfolgt der Durchlauf mit der

Spezifikation der jeweils anderen Darstellungsform. Änderungen im Ablauf, abhängig

davon, ob die Spezifikation dem Teilnehmer als erstes oder zweites zur Verfügung

gestellt wird, gibt es dabei nicht.

Abbildung 5.2: Untersuchungsumgebung bei ausgedruckten Spezifikationen

28

6 Durchführung der Studie

Die Studie konnte weitestgehend entsprechend des vorgesehen Ablaufs durchge-

führt werden. Die einzigen notwendigen Abweichungen von der ursprünglichen

Planung sind hier festgehalten.

6.1 Beobachtungen während der Studie

Während der konnte beobachtet werden, dass die Teilnehmer unterschiedlich mit

dem Dokument umgegangen sind. Einige Probanden haben die Spezifikation kom-

plett von vorne nach hinten durchgelesen, wohingegen andere sich jeweils

bestimmte Seiten an den Rand gelegt haben. Zu diesen Abschnitten gehörten die

Teile „Erläuterung des zu lösenden Problems“, „Wünsche und Prioritäten des Kun-

den“, sowie das Use Case-Diagramm.

Zudem konnte festgestellt werden, dass aufgrund des Zeitlimits von 20 Minuten nicht

alle Teilnehmer ihre Aufgabe haben beenden können. Besonders die Entwickler

standen unter starkem Zeitdruck. Diese Zeitknappheit haben die Versuchspersonen

jedoch unterschiedlich gehandhabt. Ein Teil der Probanden hat sich die Zeit eingeteilt

und alle Aufgabenteile gleichermaßen bearbeitet, wobei der andere Teil manche As-

pekte komplett weggelassen, die restlichen dafür vollständig und ausführlicher

bearbeitet hat.

6.2 Änderungen im Ablauf

Die folgenden Änderungen im Ablauf der Studie mussten aufgrund von Beobachtun-

gen während der Studie durchgeführt werden. Die daraus resultierenden

Konsequenzen für die Metriken und die Auswertung sind in Abschnitt 7.3 erläutert.

Änderung 1: Setzen eines Zeitlimits

Zunächst war den Teilnehmern kein Zeitlimit für die Bearbeitung der Aufgabe und

das Lesen der Spezifikationen gesetzt. Das heißt, es lag in ihrem Ermessen zu be-

urteilen, wann sie fertig sind. Der erste Teilnehmer hat infolgedessen jedoch zwei

Stunden für den gesamten Durchlauf der Studie benötigt. Dies umfasst ca. 1:10h für

das Beantworten der beiden Fragebögen und das Lesen und Bearbeiten der ersten

Spezifikation mit den Eye Tracking Glasses, sowie nochmals ca. 50 Minuten für den

gleichen Ablauf bei der zweiten Spezifikation mit dem externen Eye Tracker. Der

Zeitunterschied zwischen den beiden Abläufen ergibt sich daraus, dass die Kalibrie-

rung der Brille länger dauert als für den externen Eye Tracker und es außerdem zu

Verbindungsproblemen bei der Eye Tracking Brille kam, weshalb das Aufnahmepro-

gramm mehrfach neu gestartet werden musste. Der Proband wurde dadurch in

seiner Aufgabe nicht beeinträchtigt.

Da bei einer so langen Dauer allerdings Faktoren wie Müdigkeit, mangelndes Durch-

haltevermögen und Konzentrationsabnahme die Ergebnisse vermehrt

beeinträchtigen und die Bereitschaft von Studenten an Studien teilzunehmen sinkt je

Länger diese dauert, wurde daraufhin für alle Teilnehmer mit der ID 002 oder höher

ein Zeitlimit von 20min pro Spezifikation gesetzt. Das heißt, von dem Zeitpunkt an

hatten die Probanden genau 20 Minuten Zeit um die Spezifikation zu lesen und ihre

rollenspezifische Aufgabe zu bearbeiten.

6 Durchführung der Studie

29

Änderung 2: Wiederholung von Durchläufen

Des Weiteren wurden die folgenden zwei Durchläufe aus Tabelle 7.1 nochmals wie-

derholt und aus der Menge an auszuwertenden Daten entfernt, da die

Vergleichsmöglichkeit der Daten bzw. deren Validität gefährdet war.

Teilnehmer Spezifikationen Rolle

Set_a Set_d Translate_a Translate_d



Tabelle 7.1: Wiederholung von Durchläufen

Zum einen handelt es sich dabei um den Teilnehmer mit der ID 001, da diesem wie

zuvor beschrieben noch kein Zeitlimit gesetzt war und die Rahmenbedingungen der

Studie sich für ihn somit von den anderen Teilnehmern unterschieden haben. Da die

aufgenommenen Daten aus diesem Durchlauf daher nicht mit den anderen Teilneh-

mern vergleichbar sind, wurden die Einstellungen für Teilnehmer 001 nochmals mit

einem weiteren Probanden wiederholt. Das heißt, die Zuordnungstabelle wurde um

die Zeile mit der ID 009 ergänzt. Die Spezifikationen, deren Reihenfolge und Darstel-

lung entsprechen dabei genau denen von Teilnehmer 001.

Des Weiteren wurde anschließend bei dem Durchlauf des Teilnehmers mit der ID

009 festgestellt, dass dieser die Aufgabe nicht richtig verstanden hat, da er sich wäh-

rend den 20 Minuten lediglich Notizen zu seiner Aufgabe gemacht, diese jedoch nicht

vollständig bearbeitet hat. Zudem hat er im Nachhinein reflektiert, dass er sich immer

wieder daran erinnern musste, was seine Rolle ist und er die Spezifikation meist we-

niger als Informationsquelle für seine Aufgabe, sondern mehr aus Interesse gelesen

hat. Darüber hinaus, handelte es sich bei dem Probanden um einen Brillenträger und

am Bildschirm wäre das Lesen für ihn zu anstrengend geworden, weshalb er dafür

seine Brille aufbehalten hat. Das hatte jedoch zur Folge, dass der aufgenommene

Blickpunkt des Eye Trackers durch Reflexionen der Brille oder wenn der Brillenrah-

men die Kamera verdeckt, sehr instabil war und viele Sprünge beinhaltete. Deshalb

wurde der Durchgang ein weiteres Mal wiederholt. Der entsprechende Teilnehmer

trägt die ID 010. Beide Teilnehmer wurden in die Zuordnungstabelle eingefügt.

30

7 Analyse und Interpretation

In diesem Kapitel folgt eine formale Analyse der Daten. Diese umfasst die Beschrei-

bung sämtlicher Maßnahmen, die nötigt sind, um die Rohdaten der Messung in die

gewünschten Metriken zu überführen, deren Prüfung auf Validität, sowie die formalen

Tests der in Kapitel 4.2 aufgestellten Hypothesen.

7.1 Verarbeitung der Rohdaten

Bevor das Ergebnis der Metriken analysiert werden konnte, mussten die Aufnahme-

daten zunächst in die gewünschte auswertbare Form gebracht werden. Dazu wurden

die Ergebnisse der Fragebögen in Exceltabellen übertragen und die Anzahl an rich-

tigen Antworten bei den inhaltlichen Fragen, die Anzahl an Stimmen für die jeweiligen

Darstellungsformen und die durchschnittlichen Bewertungen der Relevanz der Spe-

zifikationsabschnitte abhängig von der Rolle des Lesers bestimmt.

Um die Lesezeiten für einzelne Abschnitte zu erhalten, wurden für die Daten des

externen EyeTracker AOIs auf den einzelnen Abschnitte definiert. Dazu wurden über

die jeweiligen Absätze, einschließlich der zugehörigen Überschrift und einem zusätz-

lichen Rand zum Ausgleich eventueller Ungenauigkeiten des Eye Trackers ein

rechteckiger AOI gezogen. Anschließend konnte für jeden Teilnehmer die entspre-

chende Lesedauer abgelesen und in die passende Tabelle übertragen werden.

Für die Auswertung der Daten der Eye Tracking Glasses musste noch ein zusätzli-

cher Zwischenschritt erfolgen, da die Aufnahme zunächst nur als Video vorlag, auf

dem jeweils der Blickpunkt des Teilnehmers abgetragen ist. Das Zusammenfügen

von Blickpunkt und Bild der Kamera musste jedoch manuell erfolgen, indem jeder

Blickpunkt einem Punkt auf dem Referenzbild zugewiesen wurde. Das Referenzbild

beinhaltet für diese Studie eine Auflistung aller Teilkapitel, die in den beiden verwen-

deten Spezifikationen enthalten sind. Für jede Fixation der Probanden wurde

ausgewählt zu welchem der Abschnitte auf dem Bild es gehört. Bei Zeitpunkten, zu

denen der Leser seinen Blick nicht auf die Spezifikation gerichtet hat, wurde auf einen

Bereich des Referenzbilds geklickt, der zu keinem Teil der Spezifikation gehört. An-

schließend wurden auf den farbig markierten Abschnitten der Referenz ebenfalls

AOIs definiert, sodass die entsprechenden Lesezeiten abgelesen und festgehalten

werden konnten.

7.2 Validierung der Messdaten

Nachdem sämtliche Daten in auswertbarer Form vorlagen, konnte die Validität der

Messdaten geprüft werden. Dazu wurde zunächst kontrolliert, ob alle Fragebögen

korrekt ausgefüllt waren. Beispielsweise würde es darauf hinweisen, dass ein Teil-

nehmer den Fragebogen nicht richtig verstanden hat oder nicht ernsthaft genug an

der Studie teilgenommen hat, wenn er bei den inhaltlichen Fragen mehrere Antwort-

möglichkeiten angekreuzt hätte, obwohl darauf hingewiesen wurde, dass jeweils nur

eine Antwort korrekt ist. Bei den erhobenen Daten konnten solche Vorkommnisse

jedoch nicht beobachtet werden. Anschließend wurden die Daten auf Ausreißer ge-

prüft. Dies erfolgte über eine graphische Darstellung der Stichprobendaten, um sich

einen Überblick über deren Verlauf verschaffen zu können. Anschließend wurde fest-

gestellt, ob einzelne Datenpunkte sehr weit von dem Rest entfernt lagen. Ein Beispiel

einer solchen graphischen Darstellung zeigt Abbildung 8.1. Darin ist der Verlauf der

Lesezeiten der Spezifikation „Set“ in der Darstellung am Bildschirm gezeigt. Auf der

x-Achse sind die einzelnen Kapitel der Spezifikation aufgetragen. Die beiden ersten


31

Intervalle tragen keine Beschriftung, da es sich dabei um das Deckblatt und das In-

haltsverzeichnis handelt. Auf der y-Achse sind die dazugehörigen Lesezeiten in

Millisekunden abgebildet. In dem Diagramm kann man sehr gut erkennen, dass sich

der Verlauf der Teilnehmerdaten stark ähnelt. Das weist auf einen Zusammenhang

der Daten hin, da es dafür spricht, dass es sich nicht um zufällige Beobachtungen

handelt.

Abbildung 8.1: Übersicht der Lesezeiten der Spezifikation Set_d

7.3 Formale Prüfung der Hypothesen auf Signifikanz

Da die Validität der Daten sichergestellt wurde, konnten im Anschluss die in Kapitel

4.2 aufgestellten Hypothesen, die zur Beantwortung der betrachteten Fragen dienen

sollen, auf Richtigkeit geprüft werden. Dazu wurden die jeweilig definierten Aussagen

mittels statistischer Tests auf Signifikanz untersucht. Die Betrachtungen wurden da-

bei nach der zugehörigen Fragestellung gruppiert.

7.3.1 F1: Darstellungsform

Zur Beantwortung der Frage, ob die ausgedruckte oder digitale Darstellung geeigne-

ter ist, wurden drei Zwischenmetriken verwendet. Zum einen wurden die Vorliebe des

Lesers und die Wiedergabefähigkeit abhängig von dem Darstellungsmedium Papier

oder Bildschirm bestimmt. Als weiteres Kriterium wurde die Lesegeschwindigkeit be-

trachtet.

M1: Präferenz des Lesers

Um herauszufinden, ob ausgedruckte oder am Bildschirm angezeigte Spezifikatio-

nen vom Nutzer bevorzugt werden, wurde im ersten Fragebogen nach der

favorisierten Darstellungsform gefragt. Die dazu aufgestellte Hypothese HA2_1 wird

über den Vergleich der Häufigkeit der beiden möglichen Antworten geprüft. Dazu

wurden die Tafeln der F-Verteilung verwendet (Sachs93).

Die dafür betrachteten Merkmale der Grundgesamtheit sind:

a1: Anteil an Personen, die die ausgedruckte Darstellung bevorzugen

d1: Anteil an Personen, die die digitale Darstellung bevorzugen


32

Die entsprechenden Metriken für die Stichprobe werden wie folgt symbolisiert:

xa1: Anzahl an Personen, die die ausgedruckte Darstellung bevorzugen

xd1: Anzahl an Personen, die die digitale Darstellung bevorzugen

Entgegen der Arbeitshypothese HA2_1 wird zur Überprüfung die Nullhypothese formu-

liert.

H02_1: a1 ≤ d1, das heißt, es bevorzugen mindestens so viele Personen die digitale

Darstellung, wie die ausgedruckte Form

Die ermittelten Häufigkeiten der Stichprobe sind xa1 = 7 und xd1 = 4. Um herauszufin-

den, ob die Nullhypothese auf dem 5%-Niveau abgelehnt werden kann, wird der

entsprechende �̂�-Wert berechnet und mit dem Grenzwert aus der zugehörigen Ta-

belle (Sachs93) verglichen.

�̂� ≥ 𝐹𝑣1;𝑣2;0,05

wobei �̂� = xa1

xd1+1 und 𝑣1 = 2(xd1 + 1), 𝑣2 = 2 ∗ xa1

𝑣1 = 2(4 + 1) = 10, 𝑣2 = 2 ∗ 7 = 14

�̂� = 7

4 + 1= 1,4 ≱ 𝐹10;14;0,05 = 2,6

Da der �̂�-Wert der Stichprobe nicht mindestens so groß wie der 𝐹𝑣1;𝑣2;0,05-Wert der

Tabelle ist, muss die Nullhypothese beibehalten werden. Das heißt, die Anzahl an

Personen, die die ausgedruckte Darstellung bevorzugen ist nicht signifikant höher

als die Anzahl an Personen, die die Darstellung am Bildschirm präferieren.

Bei den Werten ist jedoch aufgefallen, dass insbesondere die erfahrenen Entwickler

fast ausschließlich für die digitale Variante gestimmt haben. Den Kommentaren dazu

nach zu urteilen liegt das daran, dass sie größtenteils bereits Erfahrung mit Tools

zum Anzeigen von Spezifikationen haben und aufgrund dessen Funktionalität die

Variante am Bildschirm gewählt haben. Daher lässt sich vermuten, dass die ausge-

druckte Variante beim Vergleich mit lediglich am Bildschirm angezeigten PDF-

Spezifikationen ohne erweitere Funktionalität, bevorzugt wird. Diese Vermutung lässt

sich jedoch mit den gegebenen Daten nicht überprüfen.

M2: Wiedergabefähigkeit

Für die Wiedergabefähigkeit wird analog vorgegangen, da der gleiche statistische

Test verwendet werden kann. Dazu wird die Anzahl an richtigen Antworten auf die

gestellten inhaltlichen Fragen für die ausgedruckten und am Bildschirm gezeigten

Spezifikationen miteinander verglichen. Das heißt, es handelt sich erneut um ein Ver-

gleich zweier Häufigkeiten und es werden die Tafeln der F-Verteilung zur

Überprüfung der Arbeitshypothese angewendet (Sachs93).

Die für diese Fragestellung betrachteten Merkmale der Grundgesamtheit sind:

a2: Anteil an richtigen Antworten bei ausgedruckten Spezifikationen

d2: Anteil an richtigen Antworten bei Spezifikationen am Bildschirm

Die entsprechenden Metriken für die Stichprobe werden wie folgt symbolisiert.

xa2: Anzahl an richtigen Antworten der sechs gestellten inhaltlichen Fragen der Personen der Stichprobe bei ausgedruckten Spezifikationen

xd2: Anzahl an richtigen Antworten der sechs gestellten inhaltlichen Fragen der Personen der Stichprobe bei am Bildschirm gezeigten Spezifikationen


33

Der Arbeitshypothese HA2_2 entgegen wird zur Überprüfung die Nullhypothese formu-

liert.

H02_1: a2 ≠ d2, das heißt, es gibt einen Unterschied in der Wiedergabefähigkeit

abhängig von der Darstellungsart (ausgedruckt oder am Bildschirm)

Die gemessenen Häufigkeiten an richtigen Antworten sind xa1 = 37 und xd2 = 40. Um

zu testen, ob die Nullhypothese auf dem 5%-Niveau abgelehnt werden kann, wird

der entsprechende �̂�-Wert berechnet und mit dem Grenzwert aus der zugehörigen

Tabelle (Sachs93) verglichen.

�̂� ≥ 𝐹𝑣1;𝑣2;0,05

wobei �̂� = xa2

xd2+1 und 𝑣1 = 2(xd2 + 1), 𝑣2 = 2 ∗ xa2

𝑣1 = 2(37 + 1) = 76, 𝑣2 = 2 ∗ 40 = 80

�̂� = 40

37 + 1= 1,05 ≱ 𝐹76;80;0,05 = 1,53

Da der �̂�-Wert der Stichprobe nicht mindestens so groß wie der 𝐹𝑣1;𝑣2;0,05-Wert der

Tabelle ist, muss die Nullhypothese beibehalten werden. Das heißt, es gibt keinen

signifikanten Unterschied zwischen der Wiedergabefähigkeit der Teilnehmer abhän-

gig vom Darstellungsmedium. Auch im Fall einer einseitigen Fragestellung (a2 < d2)

würde der ermittelte �̂�-Wert der Stichprobe nicht für ein signifikantes Ergebnis auf

dem 5%-Niveau ausreichen.

M4: Geschwindigkeit

Um die Arbeitshypothese HA2_3 testen zu können, muss zunächst einmal die Lese-

geschwindigkeit der einzelnen Teilnehmer berechnet werden. Dies wird nach der

folgenden Formel berechnet.

Geschwindigkeit = Summe der Länge der Spezifikationsabschnitte

Summe der Lesezeiten der Spezifikationsabschnitte [

𝑐𝑚

𝑠]

Die errechneten Geschwindigkeiten können Tabelle 8.1 entnommen werden. Die

Werte sind jeweils auf drei Nachkommastellen gerundet. Da die Länge der Spezifi-

kation aufgrund des Zeitlimits höchstwahrscheinlich einen Einfluss auf die

Lesegeschwindigkeit hat, wird an dieser Stelle das Blocking-Prinzip angewandt. Da

die Translate-Spezifikation acht Seiten mehr umfasst als die Set-Spezifikation, wer-

den die Teilnehmer bei ihr vermutlich mit einer anderen Geschwindigkeit gelesen

haben. Um die resultierende erhöhte Varianz innerhalb der Messgruppen auszuglei-

chen, werden die Mittelwerte der Geschwindigkeiten daher getrennt für die beiden

Spezifikationen verglichen. Zum Test der Arbeitshypothese wird dazu ein Verfahren

von McDonald und Thompson verwendet, das auf den sogenannten Rangsummen

basiert. Dabei wird vorausgesetzt, dass die Daten den gleichen Verteilungstyp und

unter der Nullhypothese gleiche Parameter aufweisen (Sachs93). Das ist in diesem

Fall gegeben, da die Messwerte von den gleichen Teilnehmern unter gleichen Ver-

suchsbedingungen aufgenommen wurden. Die Daten von Teilnehmer 011 wurden

an dieser Stelle nicht mit ausgewertet, da dort nur Daten für die Spezifikation am

Bildschirm vorliegen und der Test nur für gleich große Messgruppen funktioniert

(Sachs93).

Zunächst wird wieder die Nullhypothese definiert. Diese ist in diesem Fall in zwei

Nullhypothesen aufgeteilt, da der Test je einmal für die beiden Spezifikationen durch-

geführt wird.


34

H02_31: Die am Bildschirm gelesenen Set-Spezifikationen werden genauso schnell oder langsamer gelesen als die ausgedruckten Spezifikationen.

H02_31: Die am Bildschirm gelesenen Translate-Spezifikationen werden genauso schnell oder langsamer gelesen als die ausgedruckten Spezifikationen.

Anschließend wird den Messwerten ein Rang zugewiesen. Der kleinste Wert be-

kommt dabei den Rang 1, der zweitkleinste den Rang 2 und so wird für die gesamten

Daten verfahren. Danach wird die Rangsumme berechnet. Beide Werte lassen sich

der Tabelle 8.1 entnehmen. Die Ränge entsprechen den eingeklammerten Zahlen

hinter den Geschwindigkeiten. Die Rangsumme befindet sich in der untersten Zeile.

Set-Spezifikation Translate-Spezifikation

ausgedruckt am Bildschirm ausgedruckt am Bildschirm

1,070 (9) 0,707 (1) 0,518 (4) 0,908 (10)

0,797 (2) 0,920 (5) 0,614 (5) 0,493 (3)

0,992 (6) 0,998 (8) 0,730 (6) 0,458 (1)

0,863 (4) 0,987 (7) 0,490 (2) 0,821 (7) 0,827 (3) 1,305 (10) 0,843 (9) 0,842 (8)

∑ 24 31 26 29

Tabelle 8.1: Geschwindigkeiten und Rangsummenvergleich der Spezifikationen

Der entsprechenden Tabelle aus der Literatur (Sachs93) lässt sich entnehmen, dass

bei fünf Messwerten und zwei Gruppen, die Rangsumme 37 betragen müsste, damit

die jeweilige Nullhypothese auf dem 5%-Niveau abgelehnt werden könnte. Die Rang-

summen der Stichprobe erreichen diesen Grenzwert nicht, daher muss die

Nullhypothese beibehalten werden. Demnach ist die Lesegeschwindigkeit bei am

Bildschirm gelesenen Spezifikation in dieser Studie nicht signifikant höher als bei

ausgedruckten Versionen.

7.3.2 F2: Auswahl der Abschnitte

Um herauszufinden welche Abschnitte besonders wichtig bzw. unwichtig für die je-

weiligen Rollen sind und somit die wichtigen Abschnitte für die Rollen auswählen zu

können, werden die beiden Metriken Bewertung und Lesezeiten betrachtet.


Für diese Metrik wurde der Chi-Quadrat-Test verwendet, mit dem es möglich ist die

Vereinbarkeit mehrerer Zählungen zu überprüfen (Sachs93). Das heißt, es wird ge-

testet, ob es einen signifikanten Unterschied zwischen den Bewertungen für einen

Abschnitt bei einer Rolle gibt. Dazu wird zunächst die Nullhypothese aufgestellt, die

für jeden Abschnitt bei jeder Rolle zu überprüfen ist.

H03_1: Alle Bewertungsschritte werden gleich häufig gewählt.


35

Mithilfe der 𝜒2-Prüfgröße lassen sich die Häufigkeiten der jeweiligen Bewertung von

„Sehr wichtig“ bis „Unwichtig“ miteinander vergleichen (Sachs93). Die Nullhypothese

wird dabei auf dem 5%-Niveau abgelehnt, sobald folgende Bedingung erfüllt ist.

𝜒2̂ = ∑ (𝑥𝑖 − �̅�)24

𝑖=1

�̅� > 𝜒2

𝑣;0,05

mit �̅�: der Mittelwert der Häufigkeiten der Bewertungsschritte,

v: Anzahl an Bewertungsschritten - 1 = 4 – 1 = 3

und 𝑥𝑖: Häufigkeit der i-ten Bewertung

Der zu überschreitende Grenzwert 𝜒23;0,05, der für alle Abschnitte und Rollen gleich

ist, da es in jedem Fall vier Bewertungsschritte gab, ist dabei 7,815 (Sachs93). Bei

der Errechnung der 𝜒2-Größe ergibt sich, dass die Nullhypothese nur abgelehnt wer-

den kann, wenn alle Teilnehmer einer Rolle die gleiche Bewertung abgegeben

haben. Die einzige Ausnahme bilden die Entwickler, da man dort nicht nur jeweils

zwei Teilnehmer mit jeweils zwei Bewertungen zur Verfügung hat, sondern vier Teil-

nehmer mit insgesamt acht Bewertungen. Der erfahrene Entwickler mit der

Teilnehmer-ID 011 blieb an dieser Stelle erneut unberücksichtigt, damit gleich viele

Messwerte für beide Spezifikationen betrachtet werden und so eventuelle Projektab-

hängigkeiten nicht ins Gewicht fallen. Außerdem können die Ergebnisse dieser

Metrik besser mit den Lesegeschwindigkeiten verglichen werden, da so die gleichen

Daten betrachtet wurden.

Außer für die Teilnehmergruppe der Entwickler ist daher lediglich zu prüfen, für wel-

che Abschnitte identische Bewertungen einer Rolle vorliegen. Das ist für die

nachfolgenden Abschnitte und Rollen der Fall.

UI-Designer: Qualitätsziele des Projekts (wichtig), MockUps (sehr wichtig)

Softwarearchitekt: Erläuterung des zu lösenden Problems (sehr wichtig)

Tester: Use-Case Beschreibungen (sehr wichtig), Inkrementelle Arbeit (un-

wichtig)

Für diese Rollen und Abschnitte wird die Nullhypothese auf dem 5%-Niveau abge-

lehnt. Das heißt, die Bewertungseinschätzungen sind bei diesen Artefakten

statistisch signifikant.

Für die Rolle des Entwicklers wurden die entsprechenden 𝜒2-Werte nicht berechnet,

da sie in dem Fall nur ausgesagt hätten, dass es signifikante Unterschiede zwischen

den Häufigkeiten gibt, jedoch nicht, welche Bewertung dominiert. Daher wurden die

Bewertungen in diesem Fall anders verglichen. Um aussagen zu können, ob ein Ab-

schnitt wichtig oder unwichtig bewertet worden ist, wurden die Anzahl an „Sehr

wichtig“- und „Wichtig“-Bewertungen, sowie an „Weniger wichtig“- und „Unwichtig“

Bewertungen jeweils zusammengezählt und mittels dem Test für den Vergleich

zweier Häufigkeiten verglichen. Das heißt, es wurden erneut die Tafeln der F-Vertei-

lung verwendet. Die resultierende Vereinfachung der Fragestellung von vier auf zwei

mögliche Antworten, stellt hierbei keinen Verlust dar, da bei der Auswertung sowieso

eindeutig über die Wichtigkeit der Abschnitte entschieden werden muss. Diese Ver-

gleichsvariante konnte bei den anderen drei Rollen nicht verwendet werden, da dort

die Teilnehmeranzahl pro Rolle nicht ausreicht, um signifikante Ergebnisse zu erhal-

ten.

Die entsprechende Nullhypothese für die Entwicklerrolle hierbei lautet somit wie folgt.

H03_2: Der Abschnitt wird gleich oft mit „Sehr wichtig“ oder „Unwichtig“ bewertet, wie mit „Weniger wichtig“ und „Unwichtig“.


36

Für den Test wird außerdem folgende Notation verwendet.

x1: größere Anzahl der „(Sehr) wichtig“- bzw. „Weniger wichtig“- und „Unwichtig“-Bewertungen

x2: kleinere Anzahl der „(Sehr) wichtig“- bzw. „Weniger wichtig“- und „Unwichtig“-Bewertungen

Mithilfe dieser Größen wird anschließend mit den entsprechenden Formeln

(Sachs93) der �̂�-Wert berechnet und mit den zugehörigen Tabellen verglichen, um

festzustellen, ob das gewünschte Signifikanzniveau erreicht werden kann.

�̂� = x1

x2+1 und 𝑣1 = 2(x2 + 1), 𝑣2 = 2 ∗ x1

Dabei konnte man feststellen, dass für die Rolle Entwickler die folgenden Abschnitte

und jeweils angegebene Bewertung die Nullhypothese auf dem 5%-Niveau abge-

lehnt werden konnte.

Erläuterungen des zu lösenden Problems (Wichtig)

Wünsche und Prioritäten des Kunden (Wichtig)

Maßnahmen zur Anforderungsanalyse (Unwichtig)

Einschränkungen und Vorgaben (Wichtig)

Use Case-Beschreibungen (Wichtig)

Technische Anforderungen (Wichtig)

Inkrementelle Arbeit (Wichtig)

MockUps (Wichtig)

Glossar (Unwichtig)

Bei dieser Untersuchung handelte es sich um eine zweiseitige Fragestellung. Da die

zu erreichenden �̂�-Werte für die einseitige Fragestellung unter denen der zweiseiti-

gen liegen, kann somit für jedes Ergebnis auch signifikant festgestellt werden, dass

die Werte nicht nur ungleich, sondern sogar echt größer sind.

M5: Intensität des Lesens einzelner Abschnitte

Die gemessenen Lesezeiten, die Rückschlüsse auf die Intensität des Lesens der ein-

zelnen Abschnitte geben, dienen lediglich als Vergleichsmöglichkeit für die

Bewertungen der Teilnehmer. Wenn ein Teilnehmer einen Abschnitt beispielsweise

nur überflogen hat, diesen jedoch als sehr wichtig für seine Rolle bewertet hat, weist

das auf eine geringe Aussagekraft der Bewertung hin.

Mit dieser Metrik kann darüber hinaus festgestellt werden, ob als unwichtig bewertete

Abschnitte auch weniger intensiv gelesen werden. Es kann so also untersucht wer-

den, ob es einen Zusammenhang zwischen Bewertung und Lesezeit gibt.

Über die einzelnen Leseintensitäten alleine kann jedoch keine signifikante Aussage

getroffen werden, ob diese für ein sehr intensives oder weniger intensives Lesen

stehen, da es keinen konkreten Vergleichswert gibt. Das hat den Grund, dass das

Lesen von Spezifikationen einen sehr speziellen Anwendungsfall darstellt, da zum

einen Abbildungen, Tabellen und Aufzählungen enthalten sind und zum anderen die

Absätze nicht nur zur reinen Informationsaufnahme gelesen werden, sondern neben-

bei Aufgaben bearbeitet werden. Die gemessenen Daten der Stichprobe können

jedoch als Referenz genommen werden, um für einzelne Intensitäten beurteilen zu

können, ob diese vergleichsweise hoch oder niedrig sind. Damit hat man zwar eine

Abhängigkeit von der Messausprägung, besitzt jedoch Vergleichswerte, die unter


37

den gleichen Umständen, also auch beim Lesen derselben Spezifikationen aufge-

nommen wurden.

Um die Intensität des Lesens der einzelnen Abschnitte beurteilen zu können, müssen

die gemessenen Lesezeiten zunächst mit deren Länge relativiert werden. Dies ist

notwendig, da ein kurzer Abschnitt bei gleicher Wichtigkeit und Komplexität stets ten-

denziell kürzere Lesezeiten erhalten wird als ein längerer Abschnitt. Dazu wird

folgende Formel verwendet.

Leseintensität = Lesedauer des Abschnitts

Länge des Abschnitts [

𝑠

𝑐𝑚]

Um diese Daten anschließend mit den Bewertungen der Teilnehmer vergleichen zu

können, werden sie anschließend auf die gleiche Skala von 1 (Sehr wichtig) bis 4

(Unwichtig) transformiert. Hierbei werden große Werte jedoch auf einen kleinen Wert

abgebildet, da eine hohe Leseintensität auf eine hohe Wichtigkeit des Abschnitts hin-

deutet und anders herum. Dies erfolgt mit der folgenden Formel.

𝑖𝑠(𝑥) = 5 − (𝑃(𝑥)

|𝑋|∗ 3 + 1)

wobei 𝑖𝑠(𝑥): skalierte Intensität der Leseintensität x in s

cm

𝑃(𝑥): die Position von x in der aufsteigend sortierten Liste aller

Leseintensitäten

|𝑋|: die Anzahl an Elementen in der Liste aller Leseintensitäten

Diese Transformierung kehrt Beziehungen wie „größer als“, „gleich“ oder „kleiner als“

lediglich genau um. Absolute Aussagen wie „doppelt „doppelt so groß wie“ oder

„kleinster Abstand zum nächsten Wert“ bleiben jedoch nicht erhalten (Wohlin00).

Da sich Daten, insbesondere bei der hier bestehenden Stichprobengröße, nicht so

einfach auf Gleichheit testen lassen, wird jeweils verglichen, ob der Unterschied zwi-

schen den Mittelwerten der Bewertungen für die einzelnen Abschnitte und Rollen

maximal um 1,0 abweicht. Andernfalls, wird dies als Hinweis erachtet, dass Bewer-

tung und Leseintensität nicht zueinander passen und die konkreten Datenpunkte

näher betrachtet werden müssen, um evtl. Gründe für die Abweichung finden zu kön-

nen. Nicht beachtet werden dabei Abweichungen bei den Abschnitten „MockUps“,

sowie „Abnahmetestfälle“, da diese wie in Abschnitt 5.1 beschrieben aus den Spezi-

fikationen entfernt wurden und daher natürlich nicht intensiv gelesen werden

konnten.

Bei der derartigen Analyse der Daten konnten folgende Abweichungen zwischen Be-

wertung und skalierter Leseintensität gefunden werden. Der erste Wert in den

Klammern gibt dabei die durchschnittliche Bewertung, der zweite die transformierte

Leseintensität an.

UI-Designer: Domänenbeschreibung (2,0 – 3,08), Use Case-Beschreibungen

(1,25 – 2,58), Probleme und Risiken (2,75 – 3,94), Inkrementelle Arbeit (2,5

– 3,87)

Softwarearchitekt: Qualitätsziele des Projekts (1,75 – 3,18), Qualitätsprioritä-

ten des Kunden (1,75 – 3,24), Wie Qualitätsziele erreicht werden sollen (1,75

– 2,77)

Tester: Domänenbeschreibung (2,5 – 1,38), Einschränkungen und Vorgaben

(2,5 – 1,28), Use Case-Beschreibungen (1,0 – 2,29), Mögliche Abstriche

(3,25 – 2,2)


38

Entwickler: Use Case-Beschreibungen (1,38 – 2,64), Inkrementelle Arbeit

(2,13 – 3,35)

Die vergleichsweise geringen Abweichungen beim Abschnitt „Domänenbeschreibun-

gen“ können dadurch erklärt werden, dass dieser Abschnitt nur 3,1cm bzw. 2,2cm

umfasst und die Messung des Eye Trackers bei so kurzen Abschnitten relativ unge-

nau ist. Außerdem ist die Wahrscheinlichkeit, dass ein „leerer Blick“, also ein

Anschauen eines Punktes ohne Verarbeitung der aufgenommenen visuellen Infor-

mationen auf so einen kurzen Abschnitt trifft, relativ gering. Die Abweichungen

werden daher nicht als maßgeblich erachtet. Ebenso verhält es sich bei den Ab-

schnitten „Einschränkungen und Vorgaben“, „Mögliche Abstriche“ und „Inkrementelle

Arbeit“.

Die Unterschiede bei dem Abschnitt „Use Case-Beschreibungen“ können dadurch

erklärt werden, dass sich dieser über mehrere Seiten erstreckt und viele Teilnehmer

zurückgemeldet haben, allein aus Zeitgründen nicht alle Use Cases gelesen zu ha-

ben. Daher können einzelne Seiten jeweils schon intensiv gelesen worden sein,

verteilt auf den gesamten Abschnitt erscheint die gemessene Leseintensität dennoch

gering.

Die letzte, ebenfalls vergleichsweise geringe Abweichung beim Abschnitt „Probleme

und Risiken“ könnten zum einen daran liegen, dass dieser Abschnitt Stichpunkte und

ein Diagramm enthielt, also Daten, die schneller erfassbar sind. Allerdings wurde bei

diesen Daten tatsächlich festgestellt, dass ein Teilnehmer diesen Abschnitten mit

„Weniger wichtig“ bewertet hat, ohne ihn gelesen zu haben. Diese Bewertung ist da-

her als wenig aussagekräftig zu betrachten. Entfernt man die Bewertung und

Leseintensität dieses Teilnehmers und berechnet die Werte erneut, ergibt sich eine

Differenz von unter eins und wird daher als nicht maßgeblich betrachtet.

7.3.3 F3: Unterschiede zwischen den Rollen

Bei dieser Fragestellung wird anhand der Metriken Bewertung (M5) und Leseinten-

sität (M7) untersucht, ob es signifikante Unterschiede zwischen den Rollen gibt.

Damit wird festgestellt, ob eine Definition von unterschiedlichen Sichten auf Anforde-

rungsdokumente für die betrachteten Rollen überhaupt Sinn ergibt.


Die Bewertungen der Teilnehmer wurden mit der sogenannten Welch-Statistik zum

Vergleich mehrerer Mittelwerte auf Unterschiede untersucht. Die Vereinbarkeit mit

der vorausgesetzten Normalverteilung wurde zuvor mit der Mittelwert-Kontrollkarte

(Sachs93) geprüft.

Die Nullhypothese in diesem Fall ist:

H04_1: Die Mittelwerte der Bewertungen sind alle gleich.

Anschließend prüft man mithilfe des �̂�-Wertes der Welch-Statistik, ob dieser den not-

wendigen 𝐹𝑣1;𝑣2;0,05 (Sachs93) übersteigt, wobei in diesem Fall v1 = 3 und v2 liegt je

nach Abschnitt zwischen sechs und acht. Dabei konnte festgestellt werden, dass die

Nullhypothese für folgende Abschnitte auf dem 5%-Niveau abgelehnt werden kann.

Schnittstellen und angrenzende Systeme

Inkrementelle Arbeit

MockUps

Die geringe Anzahl an signifikanten Unterschieden ist dabei jedoch auf die Größe

der Stichprobe zurückzuführen.

39

8 Reflektion zu Studien mit Eye Tracking

Nachdem die Planung, Vorbereitung und Durchführung der Studie, sowie die Ana-

lyse der Ergebnisdaten abgeschlossen ist, kann nun die jeweilige Arbeit mit dem Eye

Tracker reflektiert werden. Diese Reflektion umfasst, an welchen Stellen die Software

des Eye Trackers Vorteile bietet und welche Teile sehr viel Arbeit umfassen.

8.1 Vorbereitung der Aufnahmen

Bevor mit den Eye Tracking Aufnahmen begonnen werden kann, müssen je nach

Gerät bestimmte Vorbereitungen vorgenommen werden. Diese sind unterschiedlich

umfangreich und aufwändig. Generell gilt bei den Geräten und der Software von SMI:

Je mehr Arbeit man bei der Vorbereitung der Experimente hat, desto weniger Auf-

wand hat man bei der Analyse der Daten.

8.1.1 Eye Tracking Glasses

Bei den Eye Tracking Glasses hat man zwei Möglichkeiten, wie die Aufnahmen der

Daten durchgeführt werden sollen. Entweder nutzt man die Option des „Quick Runs“

oder man erstellt ein neues Experiment in dem Programm IView ETG. Im „Quick Run“

werden die Standardoptionen für die Kalibrierung verwendet. Beispielsweise ist fest-

gelegt, wie viele Kalibrierungspunkte aufgenommen werden sollen. Diese ist

standardmäßig auf 1-Punkt-Kalibrierung gesetzt. Bei dem Erstellen eines neuen Ex-

periments kann man diese Einstellungen für alle Aufnahmen gemeinsam festlegen

und zusätzlich noch Eigenschaften („Properties“) erstellen, die dann für jeden Teil-

nehmer individuell mit Werten belegt werden können. Anschließend kann sofort das

Experiment gestartet und mit der Aufnahme begonnen werden.

8.1.2 Externer Eye Tracker

Bei dem externen Eye Tracker sind die Vorbereitungen deutlich umfangreicher, da

zunächst der gesamte Ablauf des Experiments vorgegeben werden muss. Je nach-

dem, wie viele Abschnitte dieses umfasst, ist die Vorarbeit dementsprechend

zeitaufwändig. In jedem Fall wird zu Beginn ein Experiment erstellt, in das man ver-

schiedene Stimuli, wie z.B. Bilder, Text, Fragen, PDF-Dokumente oder Webseiten

einfügen kann. Jeder Stimulus hat dabei je nach Art unterschiedliche Editierungs-

möglichkeiten. Bei einer Frage lässt sich beispielsweise ein freier Text oder

vorgegebene Optionen als Antwort angeben und ob es als Teilnehmer möglich sein

soll, mehrere Antwortoptionen auszuwählen. Im Fall der Studie dieser Arbeit hat das

Erstellen der beiden benötigten Experimente für die Set- und Translate-Spezifikation

ca. 3 Stunden in Anspruch genommen, da trotz teils gleicher Antworten der Fragen

keine Antwortoptionen bei einer Frage kopiert und in eine andere eingefügt werden

können. Zudem ist es empfehlenswert, für jede Frage eine sogenannte „Property“ zu

definieren, um die Ergebnisdaten anschließend besser zuordnen zu können.

Wenn der gesamte Ablauf des Experiments auf diese Weise vorgegeben ist, kann

ausgewählt werden, während welcher Stimuli der Eye Tracker Blickdaten aufnehmen

soll. Dazu ist jeweils ein Kreuz zu setzen.

Sobald das Experiment vollständig eingestellt ist, gibt es auch hier die Möglichkeit

des „Quick Runs“. Dieser dient jedoch lediglich der Vorabansicht des Experiments

und es werden dabei keine Daten aufgenommen. Über „Record“ lässt sich die Auf-

nahme starten, wobei jedem Teilnehmer ein individueller Name gegeben werden

kann, über den die Daten letztendlich zu finden sind.


40

8.2 Durchführung der Aufnahmen

Die Durchführung der Aufnahmen ist bei beiden Eye Trackern ähnlich einfach und

umfasst wenig Aufwand von der Begleitperson der Studie.


Bei den Eye Tracking Glasses besteht die einzige Aufgabe (sofern die Studie nicht

weitere vorsieht) während der Aufnahme darin, aufzupassen, dass die Brille den

Blickpunkt des Probanden erkennt, dieser somit halbwegs mittig durch die Brille und

nicht an ihr vorbei schaut. Zudem wurden immer wieder Verbindungsprobleme mit

der Brille beobachtet. Das heißt, teilweise hat der an die Eye Tracking Glasses an-

geschlossene Rechner die Verbindung zu dieser verloren und die Aufnahme, das

Programm oder sogar der ganze Rechner mussten neu gestartet werden. Das führte

dazu, dass die Aufnahmedaten anschließend nicht mehr in einem Stück, sondern

aufgeteilt vorliegen. Es kommt jedoch nicht zum Verlust der Daten.


Bei dem externen Eye Tracker muss darauf geachtet werden, dass der Proband sich

nicht aus dem Aufnahmefeld des Eye Trackers bewegt, den Kopf nicht zu schräg legt

oder seine Arme zwischen Eye Tracker und Augen bring, was dazu führt, dass kein

Blickpunkt erkannt werden kann. Zudem sei darauf hingewiesen, dass sobald der

Teilnehmer zu einer neuen Frage navigiert, nicht mehr zum vorherigen Stimulus zu-

rückgekehrt werden kann, da die Software die Antwort der Frage verlangt.

8.3 Analyse der Daten und Auswertungsmöglichkeiten

Die Datenanalyse ist der Schritt, bei dem sich der Zeitaufwand bei beiden Eye Tra-

ckern am meisten unterscheidet, da diese bei den Eye Tracking Glasses aufwändiger

ist.


Zunächst liegen die Daten der Eye Tracking Glasses nach der Aufnahme nur in der

Software als Video vor, auf dem jeweils der Blickpunkt des Probanden abgetragen

ist. Mit diesem lassen sich jedoch Auswertungsmöglichkeiten, wie Areas of Interest,

Gaze Plot oder Heat Maps nicht nutzen, da es keine statische Referenz gibt. Bevor

man quantitative Messwerte aus den Aufnahmedaten erhält, muss jeder Blickpunkt

somit auf ein oder mehrere sogenannte Referenzbilder abgebildet werden. Als eine

solche Referenz lässt sich entweder ein eigenes Bild in die Analysesoftware laden

oder ein Screenshot des Videos nehmen.

Der Abbildungsprozess wird in Abbildung 8.1 dargestellt. Dort ist auf der linken Seite

das Referenzbild zu sehen und dem gegenüber die Aufnahmedaten der Brillenka-

mera, wo jeweils der aktuelle Blickpunkt zu dem Zeitpunkt angezeigt wird. Nun lässt

sich auf der linken Seite im Bild auswählen, zu welchem Abschnitt der Spezifikation

der Punkt gehört. Um Zeit zu sparen und weil eine genauere Auswertung für diese

Studie nicht notwendig war, wurden die Blickpunkte hier nur in Kategorien (die ein-

zelnen Teilkapitel der Spezifikation) eingeteilt und nicht punktgenau ausgewertet.

Das hat zur Folge, dass die genaue Lage der Punkte zwar keine Aussagekraft mehr

hat, man jedoch die Auswertungsmöglichkeit der Areas of Interest nutzen kann. Dazu

definiert man einen rechteckigen AOI-Bereich für jede Kategorie und kann sich an-

schließend genau ausgewertete Daten, wie die jeweilige Blickdauer oder die

durchschnittliche Anzahl an Fixationen anzeigen lassen. Auch andere Auswertungs-

möglichkeiten, wie z.B. Heat Maps lassen sich nun nutzen.


41

Abbildung 8.1: Abbilden der Blickpunkte auf ein statisches Referenzbild

Für die Studie, die im Rahmen dieser Arbeit durchgeführt wurde, hat die Analyse der

Daten auf diese Weise im Durchschnitt etwa 50 Minuten pro Teilnehmer in Anspruch

genommen, also das zwei- bis dreifache der Videozeit, die 20 Minuten betrug. Die

benötigte Zeit hängt jedoch stark von der Präzision der gewünschten Auswertung ab.

Je kleiner die betrachteten Bereiche und je öfter aufgrund der gestellten Aufgabe

zwisschen ihnen gewechselt wird, desto größer der Aufwand. Des Weiteren spielt

auch ein individueller Faktor des Probanden eine Rolle, da es Menschen gibt, die ein

deutlich sprunghafteres Blickverhalten haben als andere und dessen Blickdaten da-

her aufwändiger zu analysieren sind.


Im Gegenzug zu den Eye Tracking Glasses liefert der externe Eye Tracker für den

Monitor bereits sofort sämtliche Auswertungsmöglichkeiten und benötigt kein stati-

sches Referenzbild, da er dieses mit dem Monitor bereits gegeben hat. Die einzige

zeitaufwendige Aufgabe, die sich ergab, lag darin die Blickdaten der definierten AOIs

für jeden Teilnehmer in eine Exceltabelle zu übertragen, da die Analysesoftware da-

für keine geeignete Exportfunktion bietet. Bei den Daten dieser Studie kam hinzu,

dass die Software für jedes Mal, wenn der Proband eine PDF-Seite ein weiteres Mal

aufgerufen hat, ein neuer Datensatz erstellt wurde. Das heißt, für eine PDF-Seite

waren zum Beispiel für einen Probanden bis zu acht einzelne Elemente angezeigt.

Da eine Auswahl aller dazu führt, dass der Durchschnitt und nicht die Summe der

Blickdaten ermittelt wird, musste somit manuell jeder Datensatz durchgegangen und

anschließend alle Werte summiert werden. Dieser Prozess benötigte daher ohne die

Definition der AOIs etwa vier Stunden.

8.4 Fazit zur Durchführung von Studien mit Eye Tracking

Insgesamt lässt sich sagen, dass Eye Tracking eine sehr mächtige Methode darstellt,

da sie sehr genaue Aussagen darüber liefert, wie lange welcher untersuchte Bereich

betrachtet wird. Mithilfe dieser Daten lassen sich beispielsweise Lesegeschwindig-

keiten ermitteln oder Prioritätslisten von Elementen bestimmen. Um die

Ergebnisdaten zu erhalten, ist jedoch einiges an Zeit und Aufwand nötig. Daher sollte

abhängig vom zu untersuchenden Sachverhalt jeweils genau überlegt werden, ob

der entstehende Nutzen den nötigen Aufwand rechtfertigt oder ob andere Messme-

thoden ausreichend oder geeigneter sind.

42

9 Auswertung und Schlussfolgerung

In diesem Kapitel wird beschrieben, welche Schlüsse sich aus den Ergebnissen der

Studie ziehen ließen. Dazu wurden zunächst die Resultate zusammengefasst, je-

weils mit einem Hinweis auf die Signifikanz des Untersuchungsbefunds.

Anschließend konnten die ermittelten Erkenntnisse mit denen einschlägiger Literatur

verglichen werden. Daraufhin wurde eruiert welche Schlüsse aus den Ergebnissen

gezogen werden konnten, um die ursprünglich definierten Verbesserungsziele der

Studie zu erreichen.

9.1 Ergebnisse der Studie

Bei den Studienergebnisse wurden sowohl sich als signifikant herausgestellte Resul-

tate, sowie bei gegebener Stichprobengröße nicht ausreichend große Unterschiede

zusammengefasst. Bei jeder Erkenntnis ist daher das Signifikanzniveau angegeben.

9.1.1 Effekt der Darstellungsform

Bei der Darstellungsform wurden die Kriterien Vorliebe des Lesers, Wiedergabefä-

higkeit und Geschwindigkeit berücksichtigt. Bei der Vorliebe des Lesers haben vier

von elf Personen für die digitale Variante und sieben von elf Personen für die ausge-

druckte Version gestimmt. Dieser Unterschied reicht jedoch noch nicht für eine

Bestätigung der Hypothese auf dem 5%-Niveau, dass ausgedruckte Spezifikationen

bevorzugt werden. Ebenso verhält es sich bei der Wiedergabefähigkeit, die mittels

inhaltlicher Fragen nach dem Lesen der Spezifikation gemessen wurden. Dabei gab

es bei gleicher Fragenanzahl bei den ausgedruckten Spezifikationen 37 richtige Ant-

worten und bei den am Bildschirm gezeigten 40. Die Geschwindigkeit wurde in s/cm

gemessen und Mittels dem Vergleich mehrerer Mittelwerte auf einen signifikanten

Unterschied auf dem 5%-Niveau getestet. Dieser konnte jedoch nicht festgestellt

werden. Eine Übersicht über die Lesegeschwindigkeiten der Teilnehmer geben die

Balkendiagramme in Abbildung 9.1. Dort sind auf der x-Achse die einzelnen Ge-

schwindigkeiten der Größe nach geordnet paarweise gegenübergestellt. Die Länge

der Balken gibt auf der y-Achse die jeweilige Gesamtgeschwindigkeit für das Doku-

ment an. Anhand der Daten lässt sich der Trend erkennen, dass am Bildschirm

angezeigte Spezifikationen tendenziell schneller gelesen werden, es lässt sich je-

doch nicht nachweisen, dass diese Unterschiede nicht zufällig sind.

Abbildung 9.1: Geschwindigkeitsübersichten der Spezifikationen

0,00

0,20

0,40

0,60

0,80

1,00

1 2 3 4 5Ges

chw

ind

igke

it [

cm/s

]

Wertepaare nach Größe sortiert

Geschwindigkeit: Translate

ausgedruckt am Bildschirm

0,00

0,20

0,40

0,60

0,80

1,00

1,20

1,40

1 2 3 4 5Ges

chw

ind

igke

it [

cm/s

]

Wertepaare nach Größe sortiert

Geschwindigkeit: Set

ausgedruckt am Bildschirm


43

9.1.2 Relevanz der Abschnitte

Für die Beurteilung der Wichtigkeit der Abschnitte für die Tätigkeiten der einzelnen

Rollen wurden die Relevanzeinschätzungen der Studienteilnehmer zunächst unter-

sucht und anschließend die erkennbaren Trends mit den Leseintensitäten der

Abschnitte verglichen. Bei der Betrachtung der Bewertungen der Wichtigkeit der Ab-

schnitte ergaben sich die in Abbildung 9.2 dargestellten Werte. In der linken Spalte

sind die einzelnen Abschnitte der Spezifikation dargestellt. In den vier Spalten dane-

ben ist die jeweilige durchschnittliche Bewertung der Teilnehmer mit der

entsprechenden Rolle enthalten. Die Werte, die auf dem 5%-Niveau erfolgreich auf

statistische Signifikanz getestet wurden, sind mit einem Stern markiert. Die geringe

Anzahl an signifikanten Ergebnissen lässt sich dabei auf die geringe Probandenzahl

der einzelnen Rollen zurückführen. Die grün und türkis markierten Felder in der Ta-

belle stehen für (sehr) wichtige Abschnitte, die blau und rot markierten für weniger

wichtige und unwichtige Teile und die gelb eingefärbten stehen genau zwischen

wichtig und weniger wichtig. Es kann beobachtet werden, dass einige Abschnitte

deutlich als unwichtig bewertet wurden, wie zum Beispiel die Abschnitte „Maßnah-

men zur Anforderungsanalyse“ und „Glossar“. Zum Glossar ist jedoch anzumerken,

dass die Domäne der Spezifikationen keine komplizierten Begrifflichkeiten umfasste,

sodass diese ohne große Erklärungen für die Teilnehmer verständlich waren. Dies

deckt sich auch mit den Kommentaren in den Fragebögen. Als besonders wichtig

bewertet wurden insbesondere die Abschnitte „Erläuterung des zu lösenden Prob-

lems“ und „Wünsche und Prioritäten des Kunden“, die allgemeine Informationen zu

dem Projekt umfassen. Diese klare Tendenz zeigt sich auch in den Lesezeiten der

Abschnitte, da diese mit Abstand am intensivsten gelesen wurden. Die Bewertungen

aller anderen Abschnitte wurden ebenfalls mit den Leseintensitäten verglichen, wo-

bei keine auffälligen Unterschiede gefunden werden konnten, was die Aussagekraft

der Bewertungen bestätigt.


44

Bewertung der Rollen

Spezifikations- abschnitt

UI-Designer Software- architekt

Tester Entwickler

gesamt

1.1 Erläuterung des zu lösenden Problems

1,50 1,00 (*) 1,50 1,50 (*)

1.2 Wünsche und Prioritäten des Kunden

1,50 1,50 1,75 1,50 (*)

1.3 Domänenbeschreibung 2,00 2,00 2,50 2,50 1.4 Maßnahmen zur Anforderungsanalyse

2,75 3,50 3,75 3,63 (*)


1,75 2,25 2,50 1,75 (*)

2.2 Anwender 1,75 2,75 2,00 1,88 2.3 Schnittstellen und angrenzende Systeme

2,75 1,50 3,50 1,88

3.1 Use Case-Diagramm 2,00 2,00 1,50 2,38 3.2 Use Case-Beschreibungen 1,25 2,75 1,00 (*) 1,38 (*)

3.3 Technische Anforderungen 2,75 2,25 2,50 1,88 (*) 4.1 Qualitätsziele des Projekts 2,00 (*) 1,75 1,50 2,38

4.2 Qualitätsprioritäten des Kunden

1,75 1,75 1,50 2,25


2,50 1,75 2,50 2,38

5 Probleme und Risiken 2,75 3,50 3,75 2,75 6.1 Mögliche Abstriche 2,25 2,25 3,25 2,50

6.2 Inkrementelle Arbeit 2,50 2,00 4,00 (*) 2,13 (*) 7 MockUps 1,00 (*) 3,75 2,50 1,38 (*) 8 Glossar 3,00 3,00 3,25 3,50 (*)

9 Abnahmetestfälle 3,00 2,50 3,00 2,38

1 = "sehr wichtig", 2 = "wichtig", 3 = "weniger wichtig", 4 = "unwichtig" (*) = statistisch signifikant auf dem 5%-Niveau

Abbildung 9.2: Durchschnittliche Bewertungen der Rollen

9.1.3 Unterschiede zwischen den Rollen

Um festzustellen, wo es Unterschiede zwischen den Informationsbedarfen der Rollen

gibt und wo es somit nötig ist, unterschiedliche Spezifikationssichten zu definieren,

wurden die Bewertungen der verschiedenen Rollen miteinander verglichen und auf

signifikante Differenzen geprüft. Diese konnten vor allem wegen der kleinen Stich-

probengröße nur bei den Abschnitten „Schnittstellen und angrenzende Systeme“,

„Inkrementelle Arbeit“ und „MockUps“ gefunden werden. Das Signifikanzniveau ist

dabei erneut 5%.

Die Daten weisen darüber hinaus insgesamt darauf hin, dass sich insbesondere die

Daten des Testers besonders von den anderen abheben. Dieser Trend zeigt sich

auch in Abbildung 9.2. Die Unterschiede zwischen UI-Designern, Softwarearchitek-

ten und Entwicklern sind dagegen vergleichsweise gering. Bis auf den Abschnitt

„MockUps“, der nur für UI-Designer und Entwickler eine hohe Relevanz hat, weichen

die Werte kaum voneinander ab. Daraus lässt sich schließen, dass es sinnvoll ist, für

die Rolle des Testers eine eigene Sicht auf die Anforderungsdokumente zu generie-

ren.


45

9.2 Vergleich mit einschlägigen Studien

Die Ergebnisse der Studie wurden nach deren Ermittlung und Überprüfung mit ähn-

lichen Studien verglichen, um zu untersuchen, ob diese übereinstimmen und wo sich

Unterschiede aufzeigen lassen.

9.2.1 Effekt der Darstellungsform

Die Studien, die in einschlägiger Literatur zum Vergleich der Darstellungsformen Pa-

pier und Bildschirm aufgeführt werden, haben ebenfalls die Metriken

Geschwindigkeit, Wiedergabefähigkeit und Präferenz untersucht. Dabei konnte bei

der Lesegeschwindigkeit am Bildschirm ein signifikanter Performanzverlust von bis

zu 30% verzeichnet werden (Dillon92). Die Daten dieser Studie können dieses Ver-

hältnis jedoch nicht bestätigen. Nicht nur, dass kein signifikanter Unterschied

zwischen der Geschwindigkeit am Bildschirm und auf Papier festgestellt werden

konnte, die Durchschnittsgeschwindigkeiten der digitalen Spezifikation lagen zudem

über denen der ausgedruckten Versionen. Bei der Wiedergabefähigkeit hingegen

stimmen die Ergebnisse der bisher durchgeführten Studien, dass Informationen am

Bildschirm schlechter erinnert werden (Dillon92), mit dem Trend der in diesem Rah-

men durchgeführten Studie überein. Dieser Unterschied konnte wiederum nicht als

signifikant nachgewiesen werden und ist daher vorsichtig zu betrachten. Bei der Prä-

ferenz des Lesers widersprechen die Untersuchungsbefunde der vergangenen

Studien aus der Literatur erneut der Tendenz der ermittelten Daten dieser Studie.

Einschlägige Studien konnten vorwiegend eine Präferenz für die Darstellung am Bild-

schirm feststellen (Dillon92). Die Teilnehmer der Studie haben hingegen mehrheitlich

für die ausgedruckte Fassung gestimmt, die jedoch nicht als signifikant nachgewie-

sen werden konnte.

Die einheitliche Diskrepanz zwischen Literatur und Studienergebnisse kann dadurch

erklärt werden, dass die Nutzungsszenarien stark voneinander abweichen und das

Lesen von Spezifikationen einen anderen Anwendungsfall der Darstellungsformen

Papier und Bildschirm darstellt. Mit dem Vergleich der Ergebnisse konnte somit fest-

gestellt werden, dass diese darauf hindeuten, dass sich das Lesen von

Spezifikationen nicht mit dem Lesen herkömmlicher Texte vergleichen lässt. Auf-

grund der fehlenden statistischen Signifikanz dieser Erkenntnisse, sind jedoch

weitere Untersuchungen zur Sicherung nötig.

9.2.2 Relevanz der Abschnitte

Die Studien des Fraunhofer Instituts für Experimentelles Software Engineering be-

handelten ebenfalls den Ansatz für verschiedene Rollen eine eigene Sicht auf

Anforderungsdokumente zu generieren. Die verwendeten Spezifikation wurden je-

doch mit dem TORE-Framework (Adam09) erstellt und damit nicht nach dem

Template der Spezifikationen dieser Studie. Darüber hinaus wurden dort nur die Rol-

len Usabilityexperte und Softwarearchitekt untersucht (Gross12b). Die

Vergleichsmöglichkeiten sind daher relativ beschränkt. Da in den Fragebögen zur

Relevanzeinschätzung jedoch die gleiche Skala verwendet wurde, lassen sich die

übereinstimmenden Abschnitte sehr gut vergleichen. Die entsprechenden durch-

schnittlichen Bewertungen der vergleichbaren Artefakte sind in Abbildung 10.3

gezeigt. Die Farben und Bewertungen wurden dabei genauso abgebildet, wie in Ab-

bildung 10.2. Das heißt, 1 steht für „Sehr wichtig“, 2 für „Wichtig“, 3 für „Weniger

wichtig“ und 4 für „Unwichtig“ (Gross12b). In der Tabelle lässt sich erkennen, dass

sich die Bewertungen der UI-Designer stark ähneln. Auch die Einschätzungen der

Architekt sind weitestgehend identisch. Die einzige Ausnahme bilden die Abschnitte

„Anwender“ und „Technische Anforderungen“. Das lässt sich damit erklären, dass


46

diese Abschnitte in den Spezifikationen dieser Studie eher kurz ausfielen und daher

vermutlich schlechter bewertet wurden, da sie weniger Informationen boten. Somit

können keine gravierenden Differenzen festgestellt werden, was für die Vereinbarkeit

der beiden Ergebnisse spricht. Auf statistische Signifikanz lassen sich die einzelnen

Differenzen nicht testen, da die konkreten Bewertungen der Teilnehmer der Fraun-

hofer IESE Studien nicht bekannt sind. Für alle Differenzen zusammen ergibt der t-

Test für paarweise angeordnete Messwerte jedoch keinen statistisch signifikanten

Unterschied auf dem 5%-Niveau.

Abbildung 9.3: Vergleich mit Fraunhofer IESE Studie (Gross12b)

9.3 Schlussfolgerung

Anhand der untersuchten Unterschiede zwischen den Informationsbedarfen lässt

sich statistisch geprüft feststellen, dass es sinnvoll ist, für die Rollen Tester, Soft-

warearchitekt und UI-Designer bzw. Tester und Entwickler gesonderte Sichten auf

Anforderungsdokumente zu generieren. Dafür sollten für die Rolle des UI-Designers

auf jeden Fall die Abschnitte „Qualitätsziele des Projekts“ und MockUps enthalten

sein. Für die Rolle des Softwarearchitekten darf der Abschnitt „Erläuterung des zu

lösenden Problems“ nicht fehlen, sowie für den Tester die Use Case-Beschreibun-

gen. Informationen über die inkrementelle Vorgehensweise werden von der Rolle des

Testers hingegen nicht benötigt. Für Entwickler im Allgemeinen bilden die Abschnitte

„Erläuterung des zu lösenden Problems“, „Wünsche und Prioritäten des Kunden“,

„Einschränkungen und Vorgaben“, „Use Case-Beschreibungen“, „Technische Anfor-

derungen“, „Inkrementelle Arbeit“ und „MockUps“ eine wichtige

Informationsgrundlage. Auf die Sektion „Maßnahmen zur Anforderungsanalyse“

kann hingegen verzichtet werden. Bei dem Glossar muss außerdem berücksichtigt

werden, ob es sich bei dem Projekt um eine für Entwickler eher unbekannt Domäne

handelt. Andernfalls spielt dieser Abschnitt ebenfalls eine eher unwichtige Rolle. Für

alle anderen als wichtig oder unwichtig bewertete Artefakte, deren Relevanzeinschät-

zung nicht ausreichte, um statistisch signifikante Aussagen treffen zu können, sind

weitere Studien nötig, um empirisch fundiert deren Wichtigkeit für die einzelnen Rol-

len beurteilen zu können.

Abschnitt nach TORE

Abschnitt nach SWP-Template

Bewertungen nach TORE Bewertungen dieser Studie

AS AE UE UT UI-

Designer Software- architekt

Descriptions of Stakeholders

Anwender 2,46 2 1 1,78 1,75 2,75

Descriptions of Stakeholder Goals

Erläuterung des zu lösenden Problems

2,31 1 2 1,5 1,5 1

Descriptons of Domain Data

Domänen- beschreibung

2,69 1,5 2 2,78 2 2

Descriptions of Quality Attributes/ NFRs

Qualitätsziele des Projekts bzw. Quali-tätsziele des Kunden

1,58 1,5 2 - 1,875 1,75

Descriptions of Technical Constraints

Technische Anforderungen

1,77 1 2,5 - 2,75 2,25

AS: Architekten der SE-Projekt Studie, AE: Architekten der Eye Tracking Studie, UE: Usability- experten der Eye Tracking Studie, UT: Usability der Tutorial Studie, NFRs: nichtfunktionale Funktionsanforderungen


47

Um eventuelle Varianzen innerhalb der Rollen auszugleichen ist es darüber hinaus

sinnvoll, dass das entsprechende Tool, das rollenabhängige Sichten auf Anforde-

rungsspezifikationen zur Verfügung stellt, auch die Möglichkeit bietet herausgefilterte

Abschnitte dennoch aufrufen zu könne, sollte dies gewünscht sein. Der Vergleich

der beiden Darstellungsmedien Papier und Bildschirm deutet zudem daraufhin, dass

ein solches technisch unterstütztes Tool keine Nachteile in Bezug auf die betrachte-

ten Kriterien Präferenz der Leser, Lesegeschwindigkeit, sowie Wiedergabefähigkeit

hätte, da dort auf dem 5%-Niveau keine signifikanten Effekte nachgewiesen werden

konnten.

48

10 Einschränkungen der Validität

Eine wichtige Frage bei dem Durchführen einer Studie ist die Validität der Ergeb-

nisse. Diese sollte man schon in der Vorbereitungsphase berücksichtigen, um das

Design der Studie bereits mit Absicht auf ein möglichst hohes Maß an Validität planen

zu können (Wohlin00). Ein angemessenes Maß an Validität bedeutet, dass die Re-

sultate der Studie für die betrachtete Personengruppe geeignet sein sollten. Die vier

Kategorien von möglichen Einschränkungen der Validität werden in diesem Abschnitt

diskutiert.

10.1 Validität der Schlussfolgerung

Die Validität der Schlussfolgerung bezieht sich darauf, dass erlangte Erkenntnisse

statistisch richtig ausgewertet sein sollten (Wohlin00). Dies ist sichergestellt, da für

jeden verwendeten Signifikanztest die Voraussetzungen geprüft und stets das glei-

che Signifikanzniveau von 5% verwendet wurde. Auch Einschränkungen, wie

maximal zulässige oder minimal notwendige Stichprobengrenzen wurden berück-

sichtigt.

10.2 Interne Validität

Mögliche Faktoren, die die interne Validität negativ beeinflussen könnten, wurden

bereits in der Planungsphase ausgeschlossen. Dazu gehört beispielsweise die Tat-

sache, dass die verschiedenen Teilnehmer die einzelnen Fragen je nach Rolle

besser oder schlechter beantworten können, da die einzelnen Abschnitte für ihre Tä-

tigkeiten unterschiedlich relevant und daher auch unterschiedlich intensiv gelesen

werden. Dies spielt für die Auswertung jedoch keine Rolle, da am Ende die Werte

insgesamt für die beiden Darstellungsformen „ausgedruckt“ und „am Bildschirm“ ver-

glichen werden und jede Rolle dabei jeweils gleich häufig vertreten ist. Ebenso

verhält es sich mit Einflüssen, die sich durch die Reihenfolge der Spezifikation oder

Darstellungsform ergeben könnten, da diese zum einen zufällig ausgewählt wurde

und zum anderen jede Spezifikation, Darstellungsform und Kombination von beiden

gleich häufig als erstes und zweites zum Einsatz kam. Durch diese Maßnahmen wur-

den gleichzeitig auch ungewollte Lerneffekte im Verlauf der Studie ausgeglichen, da

diese bei allen betrachteten Metriken gleichermaßen vertreten sind. Des Weiteren

könnte die unterschiedliche Darstellungsform der Umfragebögen die Teilnehmer in

ihren Antworten beeinflussen, da z.B. auf den ausgedruckten Fragebögen mehrere

Fragen auf einer Seite und am Bildschirm jede Frage separat abgebildet wurde.

Diese Einflüsse wurden jedoch dadurch abgefangen, dass jeder Teilnehmer die Fra-

gebögen einmal auf Papier und einmal am Bildschirm ausgefüllt haben und die

Antworten anschließend miteinander abgeglichen wurden. Der letzte Faktor, der die

Studienergebnisse und somit die interne Validität hätte beeinflussen können, sind die

unterschiedlichen Längen der Spezifikationen. Diese spielen durch das gesetzte

Zeitlimit eine Rolle bei dem Geschwindigkeitsvergleich der beiden Darstellungsme-

dien. Das wurde jedoch umgangen, indem mittels Blockingverfahren die

verwendeten Spezifikationen getrennt analysiert wurden. Somit verfügt die Studie

über eine hohe interne Validität.

10 Einschränkungen der Validität

49

10.3 Validität der Konstruktion

Die Validität der Konstruktion wurde dadurch sichergestellt, dass die betrachteten

Rollen einen Ausschnitt aus denen realer Softwareprojekte darstellen und die Teil-

nehmer darüber hinaus echte Aufgaben zu bearbeiten hatten und sich daher nicht

nur in fiktive Szenarien hinein versetzen mussten. Die betrachteten Metriken wurden

zudem bestehender Literatur und bereits durchgeführten Untersuchungen entnom-

men und sind somit nicht zufällig gewählt, was zu künstlich herbeigeführten Effekten

hätte führen können.

10.4 Externe Validität

Die externe Validität beschreibt inwiefern die Resultate der Studie auf andere reale

Softwareprojekte übertragen werden können. Da an der Studie ausschließlich Infor-

matiker teilgenommen haben, die bereits erste Erfahrungen in der Entwicklung von

Softwareprodukten haben, lassen sich die Ergebnisse auf jeden Fall auf akademi-

sche Umgebungen, sowie Entwickler mit geringer Berufserfahrung übertragen. Da

zusätzliche erfahrene Entwickler hinzugezogen wurden und bei dem Vergleich ihrer

Messdaten mit denen der studentischen Entwickler kein signifikanter Unterschied auf

dem 5%-Niveau festgestellt werden konnte, sind die Erkenntnisse auch erfahrenere

Personen in Entwicklerrollen verallgemeinerbar.

Einzige Einschränkungen müssen bei der Art der Spezifikation gemacht werden, da

die Untersuchungsbefunde sich auf das Template der verwendeten Spezifikationen

beziehen und nichts über einen anderen Aufbau ausgesagt werden kann. Durch den

Vergleich mit den Studien des Fraunhofer IESE konnte jedoch festgestellt werden,

dass sich die Ergebnisse auch für längere Spezifikationen anwenden lassen.

50

11 Abschließende Betrachtung

11.1 Zusammenfassung

Die vorliegende Arbeit hat auf Basis der Erkenntnisse bisheriger Untersuchungen,

die die Abhängigkeit von der Relevanz von Spezifikationsabschnitten und der Rolle

des Lesers gezeigt haben, eine Eye Tracking Studie entworfen und durchgeführt.

Diese hat den Informationsbedarf von verschiedenen Entwicklerrollen analysiert. Da-

bei wurde untersucht, ob es Unterschiede in der Wichtigkeit der Abschnitte von

Spezifikationen, sowie Unterschiede zwischen den Informationsbedarfen der Rollen

gibt. Mithilfe dieser Ergebnisse konnte gezeigt werden, dass die in Anforderungsspe-

zifikationen enthaltenen Informationen für die Rollen UI-Designer, Softwarearchitekt,

Tester und Entwickler unterschiedlich relevant sind und es zu dem signifikante Un-

terschiede zwischen den Informationsbedarfen der einzelnen Rollen gibt. Diese

Ergebnisse stimmen mit denen einschlägiger Studien aus der Literatur überein.

Auf dieser Grundlage konnte gefolgert werden, dass die Generierung von rollenab-

hängigen Sichten auf Anforderungsdokumente, in denen nur noch für die jeweilige

Rolle wichtige Abschnitte gezeigt werden, eine erhebliche Effizienzsteigerung bei

dem Lesen von Spezifikationen bringen könnte. Der Grund liegt darin, dass das Her-

ausfiltern unwichtiger Sektionen wegfiele. Zudem ließe sich das Erstellen der

Dokumente teils aufteilen, da beispielsweise der Softwarearchitekt bereits mit seiner

Arbeit beginnen könnte bevor die für den UI-Designer notwendigen Teile fertig ge-

stellt sind. Das würde dazu beitragen, Fristen besser einhalten zu können.

Des Weiteren wurde im Zuge der durchgeführten Studie mittels Eye Tracking und

Fragebögen eruiert, ob die Darstellung der Spezifikation auf Papier oder am Monitor,

einen Effekt auf die Lesegeschwindigkeit, sowie die Wiedergabefähigkeit der Textin-

halte hat. Dabei konnte kein signifikanter Unterschied festgestellt werden. Auch in

der Präferenz der Leser konnte keine aussagekräftige Tendenz erkannt werden.

11.2 Ausblick

Aufgrund der kleinen Stichprobengröße konnte nicht für alle Unterschiede in den Be-

wertungen der Abschnitte die Signifikanz der Ergebnisse nachgewiesen werden.

Hierfür sind weitere Untersuchungen nötig. Dazu ist es zu empfehlen auch Anforde-

rungsspezifikationen größerer Projekt, sowie andere Templates und Frameworks zu

betrachten, um möglichst umfassende Kenntnisse über den Zusammenhang zwi-

schen den einzelnen Rollen und ihrem Informationsbedarf zu erhalten.

Darüber hinaus bietet der Ansatz noch Potenzial bei der Berücksichtigung weiterer

Rollen, wie Projektleitern oder Qualitätsbeauftragten, da dort ebenfalls ein Unter-

schied zu den Rollen der direkt an der Entwicklung beteiligten Rollen vermutet wird.

Diese benötigen jedoch aufgrund der umfassenden Tätigkeiten größere Stichpro-

ben, um valide Ergebnisse zu erhalten.

Sobald genügend empirische Daten erhoben wurden, müssen diese anschließend in

einem entsprechenden Tool umgesetzt werden, um die angestrebte Effizienz- und

Effektivitätssteigerung auch tatsächlich erreichen zu können. Durch die Umsetzung

dieser sichtenbasierten Anforderungsdokumente wird ein großes Potenzial zur Kos-

ten- und Zeitersparnis gesehen.

51

Literaturverzeichnis

(Adam09) Sebastian Adam, Joerg Doerr, Michael Eisenbarth, Anne Gross: Using

Task-oriented Requirements Engineering in Different Domains – Experience of Ap-

plication in Research and Industry, In: Proceedings of the 2009 17th IEEE

International Requirements Engineering Conference, RE (RE '09). IEEE Computer

Society, Washington, DC, USA, S. 267-272, 2009

(Adam14) Dr. Sebastian Adam, Norman Riegel, Dr. Joerg Doerr: TORE - A Frame-

work for Systematic Requirements Development in Information Systems, In:

Requirements Engineering Magazine, Ausgabe 04/2014

(Brau11) Henning Brau, Andreas Lehmann, Kostanija Petrovic, Matthias C. Schro-

eder: Usability Professionals 2011 - Tagungsband, S.24-29. German UPA e.V.

(Dillon92) Andrew Dillon: Reading from paper versus screens: a critical review of the

empirical literature, In: Ergonomics, 1992, Ausgabe 35, Nr. 10, S.1297-1326

(Ebert12) Christof Ebert: Systematisches Requirements Engineering, In dpunkt.ver-

lag, 2012, 4. überarbeitete Auflage

(Eckstein09) Jutta Eckstein: Agile Softwareentwicklung mit verteilten Teams, In:

dpunkt.verlag Heidelberg, 2009

(Freimut02) Bernd Freimut, Jochen Hiller, Ralf Kalmar, Teade Punter: Messpro-

gramm zur Minimierung der Fehlerrate in der Produktion des Produkts Top-Logic von

Bauer & Partner, In: IESE-Report Nr. 098.02/D, Version 1.0, 18.12.2002

(Gross12a) Anne Gross: Anforderungen an die Anforderungsspezifikation aus Sicht

von Architekten und Usability Experten, In Softwaretechnik-Trends, November 2012,

Ausgabe 32, Heft 4, S.7-8. Köllen Druck & Verlag GmbH

(Gross11) Anne Gross: Anforderungen an die Anforderungsspezifikation aus Sicht

von Architekten und Usability Experten, Fraunhofer IESE, Präsentation auf dem GI

Fachgruppentreffen RE, 24./25.11.2011, Hamburg

(Gross12b) Anne Gross, Joerg Doerr: What You Need Is What You Get! The Vision

of View-Based Requirements Specifications, IEEE RE 2012, Chicago, Illinois, USA,

S. 171-180

(Gross12c) Anne Gross, Joerg Doerr: What do Software Architects Expect from Re-

quirements Specifications, In: IEEE TwinPeaks 2012, Chiacgo, Illinois, USA, 2012

(Gross12d) Anne Gross, Steffen Hess: Was erwarten Usability Experten von Anfor-

derungsdokumenten?, In: I-com Zeitschrift für interaktive und kooperative Medien,

Ausgabe 11, Heft 2, Seiten 50-54. Oldenbourg Wissenschaftsverlag, August 2012

(Günter13) Matthias Günter: Die Kundenrolle in IT-Projekten, In: BoD – Books on

Demand, 2013

(IEEE98a) IEEE: IEEE Guide for InformationTechnology – System Definition – Con-

cept of Operations (ConOps) Document, In: IEEE Standard 1362-1998, 1998

Literaturverzeichnis

52

(IEEE98b) IEEE: IEEE Recommended practice for Software Requirements Specifi-

cations, In: IEEE Standard 830-1998, 1998

(Lemke14) Michael Lemke: Sind wir wirklich reif für E-only? Nutzerbedarf und Lese-

verhalten als Kriterien einer monographischen Erwerbungspolitik an

wissenschaftlichen Bibliotheken, In: Perspektive Bibliothek, Band 3, Nr. 2, 2014, S.7-

43

(Lemken99) Birgit Lemken: Ebook - the Missing Link between Paper and Screen, In:

Designing Electronic Books Workshop, CHI 1999 Conference, Pittsburgh, PA

(Robertson06) S. Robertson and J. Robertson: Volere Requirements Specification

Template, In: Mastering the Requirements Process, Affison-Wesley, 2006

(Sachs93) Lothar Sachs: Statistische Methoden: Planung und Auswertung, In: Sprin-

ger-Verlag, Berlin, 1993

(Schall14) Andrew Schall, Jennifer Romano Bergstorm: Eye Tracking in User Expe-

rience Design, In: Elsevier, Morgan Kaufmann, 2014

(Schmidts07) Hermann Schmidts: Usability-Evaluation: Eine Studie zur Identifizie-

rung von Nutzungsproblemen mittels Eye-Tracking-Parametern, Kapitel 3 und 4, In:

VDM Verlag Dr. Müller, Saarbrücken, 2007

(Schneider15) Kurt Schneider: Vorlesung: Requirements Engineering, In: Leibniz

Universität Hannover, Sommersemester 2015

(SMI15) SMI Webseite, http://www.smivision.com/en/gaze-and-eye-tracking-systems/pro-

ducts/redm.html (letzter Zugriff: 13.08.15)

(Solingen99) Rini van Solingen, Egon Berghout: The Goal/Question/Metric Methode:

a practical guide for quality improvement of software development, In: McGraw-Hill,

London, 1999

(Versteegen03) Gerhard Versteegen (Hrsg.), Alexander Heßeler, Colin Hood, Chris-

tian Missling, Renate Stücka: Anforderungsmanagement, In: Springer-Verlag, Berlin,

2003

(Wohlin00) Claes Wohlin, Per Runeson, Martin Höst, Magnus C. Ohlsson, Björn Reg-

nell, Anders Wesslen: Experimentation in Software Engineering: An Introduction, In:

Kluwer Academic Publishers, Boston/Dordrecht/London, 2000

(Wiki15) Abbildung 2.2: https://upload.wikimedia.org/wikipedia/commons/e/ef/Rea-

ding_Fixations_Saccades.jpg (letzter Zugriff: 13.08.15)

53

A. Anhang

A. Anhang

54

A.1 Einführungen für die Teilnehmer

A.1.1 Einführung für die Rolle UI-Designer

Herzlich Willkommen zu der Studie

„Lesen von Spezifikationen“!

In dieser Studie werden Ihnen zwei Spezifikationen zum Lesen gegeben. Sie ha-

ben dabei die Rolle des UI-Designers und sollen für das im Dokument

beschriebene System die Benutzeroberfläche entwerfen. Dazu ist Ihre Aufgabe im

Rahmen dieser Studie zunächst einige MockUps (erste Entwürfe) für diese zu er-

stellen. Anschließend werden Ihnen einige Fragen zum Inhalt des Dokuments

gestellt, sowie nach Ihrer subjektiven Bewertung der Relevanz der darin enthalte-

nen Abschnitte.

Vorher werden Sie jedoch noch darum gebeten, einige Fragen zu Ihrem Hinter-

grund zu beantworten. Dies dient lediglich dazu, die Teilnehmer der Studie

charakterisieren zu können. Es geht nicht darum, Ihre Fähigkeiten zu bewerten.

Alle Antworten werden anonym behandelt. Es wird nicht möglich sein, Ihre Anga-

ben auf Ihre Person zurückzuführen. Zu jeder Frage werden Ihnen einige

Antwortmöglichkeiten vorgegeben. Bitte geben Sie die für Sie zutreffende Antwort

an.

Vielen Dank für Ihre Teilnahme!

A. Anhang

55

A.1.2 Einführung für die Rolle Softwarearchitekt




ben dabei die Rolle des Entwicklers von einzelnen Komponenten und

Schnittstellen. Das heißt, Ihre Tätigkeit umfasst das Entwickeln aller Funktionali-

täten, die im Hintergrund laufen, sowie das Anbieten von Schnittstellen für

angrenzende Systeme und die Benutzeroberfläche. Die Oberfläche und alle grafi-

schen Elemente fallen nicht in Ihre Zuständigkeit.

Ihre Aufgabe im Rahmen dieser Studie ist es zunächst erste Entwürfe in Form

von Klassendiagrammen und Skizzen für die einzelnen Komponenten zu erstel-

len. Anschließend werden Ihnen einige Fragen zum Inhalt des Dokuments

gestellt, sowie nach Ihrer subjektiven Bewertung der Relevanz der darin enthalte-

nen Abschnitte.






Antwortmöglichkeiten vorgegeben. Bitte geben Sie die für Sie zutreffende Ant-

wort an.


A. Anhang

56

A.1.3 Einführung für die Rolle Tester




ben dabei die Rolle des Testers und sollen für das im Dokument angegebene

System Testfälle ableiten, die die beschriebenen Anforderungen sicherstellen.

Dazu ist Ihre Aufgabe im Rahmen dieser Studie einige Testfälle (Setup, Eingabe,

Sollwert) zu entwickeln. Anschließend werden Ihnen einige Fragen zum Inhalt

des Dokuments gestellt, sowie nach Ihrer subjektiven Bewertung der Relevanz

der darin enthaltenen Abschnitte.







wort an.


A. Anhang

57

A.1.4 Einführung für die Rolle Entwickler




ben dabei die Rolle des Entwicklers und sollen das System entsprechend den

Anforderungen im Dokument implementieren. Dazu ist Ihre Aufgabe im Rahmen

dieser Studie zunächst MockUps (erste Entwürfe) für die Benutzeroberfläche, so-

wie Klassendiagramme für die wesentlichen Komponenten zu erstellen und

Testfälle (Setup, Eingabe, Sollausgabe) abzuleiten, die die gewünschte Funktio-

nalität prüfen. Anschließend werden Ihnen einige Fragen zum Inhalt des

Dokuments gestellt, sowie nach Ihrer subjektiven Bewertung der Relevanz der

darin enthaltenen Abschnitte.







wort an.


A. Anhang

58

A.2 Fragebögen

A.2.1 Erster Fragebogen

Frage Antwortmöglichkeiten

1.1 Was ist Ihr Studien-

gang?

O Informatik

O Technische Informatik

O Informatik als Nebenfach

O Ich bin kein Student (mehr).

1.2 Was ist Ihr aktuelles

Studienziel?

O Bachelor

O Master

O Diplom

O Ich bin kein Student (mehr).

1.3 In welchem Semester

sind Sie?

O 1 O 4 O 7

O 2 O 5 O ≥ 8

O 3 O 6 O kein Student

1.4 Wie alt sind Sie? O ≤ 20 O 26-30 O 41-50

O 21-25 O 31-40 O > 50

1.5 Wie gut sind Ihre

Deutschkenntnisse?

O Sehr gut

O Gut

O Weniger gut

O Schlecht

1.6 Über wie viel Berufser-

fahrung im Bereich

Softwareentwicklung verfü-

gen Sie?

O Sehr viel (mind. 1 Jahr Vollzeit oder vergleichbar)

O Viel (mind. 1 Jahr Teilzeit-/ Hiwi-Job)

O Wenig (Hiwi-Job < 1 Jahr, kleiner Nebenjob oder

vergleichbar)

O Keine

1.7 Haben Sie schon ein-

mal nach einer

Spezifikation entwickelt?

O ja

O nein

1.8 Haben Sie bereits an

der Lehrveranstaltung

„Software-Projekt“ teilge-

nommen?

O ja

O nein


mal Klassendiagramme

erstellt?

O ja

O nein

A. Anhang

59


1.10 Wie gut kennen Sie

sich mit der Entwicklung

grafischer Benutzeroberflä-

chen (GUIs) aus?

O Sehr gut

O Gut

O Weniger gut

O Schlecht


mal Testfälle erstellt?

O ja

O nein

1.12 Welche Darstellungs-

form von Spezifikationen

bevorzugen Sie (unabhän-

gig von den Spezifikationen

dieser Studie)?

O ausgedruckt

O am Bildschirm

A. Anhang

60

A.2.2 Zweiter Fragebogen für die Spezifikation Set

Fragebogen II: SET

Sie haben es fast geschafft!

Schlussendlich werden Sie nun noch gebeten einige Fragen zu beantworten – zu-

nächst einige Fragen bezüglich des Inhalts der soeben gelesenen Spezifikation,

anschließend folgt Ihre Bewertung der Relevanz der einzelnen Abschnitte. Bei den

inhaltlichen Fragen werden jeweils drei Antwortmöglichkeiten vorgegeben, von de-

nen genau eine richtig ist. Wird keine oder mehr als eine Antwort angekreuzt, so wird

die Frage als falsch beantwortet gewertet.


2.1 Was passiert, wenn bei

den drei Karten, die der

Spieler im Einzelmodus an-

geklickt hat, kein Set

vorliegt?

(Mission des Projekts)

O Der Spieler muss drei Karten abgeben, sofern dies

möglich

ist.

O Dem Spieler werden drei Punkte abgezogen.

O Dem Spieler werden drei Punkte abgezogen und

er muss

drei Karten abgeben, sofern dies möglich ist.

2.2 Wer soll die Anwen-

dung nutzen?

(Rahmenbedingungen und

Umfeld)

O Die Anwendung soll hauptsächlich von jungen Nut-

zern

Verwendung finden. Dabei können keine technischen

Vorkenntnisse vorausgesetzt werden.

O Die Anwendung soll uneingeschränkt für jeden

nutzbar sein.

Entweder in Pausen zwischendurch oder im Rahmen

von

Spieleabenden.

O Die Anwendung ist hauptsächlich an ältere Nutzer

gerichtet,

da der intellektuelle Anspruch für Kinder zu hoch ist.

2.3 Was passiert beim Än-

dern des Spielernamens,

wenn ein Fehler vorliegt?

(Funktionale Anforderun-

gen)

O Dem Spieler wird ein vom System generierter

Name

zugewiesen.

O Wenn der Spielername 0 oder mehr als 20 Zeichen

umfasst,

wird eine Fehlermeldung ausgegeben.

O Der Spieler wird aufgefordert seinen Namen erneut

einzugeben.

A. Anhang

61


2.4 Können im Mehrspie-

lermodus mehrere Spieler

gleichzeitig ein Set markie-

ren?


gen)

O Nein, jeder Spieler muss anzeigen, dass er ein Set

markieren

möchte. Dann ist diese Möglichkeit für alle anderen

Mitspieler gesperrt.

O Ja. Derjenige, der zuerst ein Set vollständig mar-

kiert hat,

bekommt die Punkte. Die Markierung des anderen

Spielers

wird wieder zurückgesetzt.

O Es gibt eine Einstellungsmöglichkeit, ob dies mög-

lich sein

soll oder nicht. In der Standardeinstellung ist es nicht

möglich.

2.5 Was sind die wichtigs-

ten Qualitätsaspekte für

den Kunden?

(Qualitätsanforderungen)

O Korrektheit, Usability, Portabilität, Wartbarkeit und

Zuverlässigkeit

O Zuverlässigkeit, Portabilität, Wiederverwendbarkeit,

Korrektheit und Flexibilität

O Usability, Zuverlässigkeit, Korrektheit, Integrität

und

Wartbarkeit

2.6 WENN die für den

Mehrspielermodus notwen-

dige Netzwerkverbindung

zwischen Server und Client

nicht hergestellt werden

kann oder nicht funktio-

niert, DANN …

(Probleme und Risiken)

O … wird es nicht möglich sein ein Spiel im Mehr-

spielermodus

zu spielen.

O … wird alternativ ein Mehrspielermodus an einem

PC

umgesetzt.

O … muss erneute Rücksprache mit dem Kunden ge-

halten

werden.

A. Anhang

62

Nun werden Sie noch gebeten, die Abschnitte der Spezifikation, die Sie soeben ge-

lesen haben mit einer Relevanz von Sehr wichtig bis Unwichtig zu bewerten. Als wie

wichtig ordnen Sie persönlich die in dem Abschnitt gegebenen Informationen für Ihre

Rolle ein?

Damit ist nicht die Relevanz allgemein im Projekt gemeint, sondern nur, ob Sie diese

Inhalte für die Ausführung der gesamten Tätigkeiten, die Ihre Rolle umfasst, benöti-

gen.

Für diese Fragen gibt es natürlich keine falschen Antworten.

Abschnitt

1 Mission des Projekts

Unterabschnitt Priorität

1.1 Erläuterung des zu lösenden Prob-

lems

O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

1.2 Wünsche und Prioritäten des Kun-

den

O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

1.3 Domänenbeschreibung O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

1.4 Maßnahmen zur Anforderungsana-

lyse

O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

2 Rahmenbedingungen und Umfeld


2.1 Einschränkungen und Vorgaben O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

A. Anhang

63

Abschnitt

2.2 Anwender O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

2.3 Schnittstellen und angrenzende

Systeme

O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

3 Funktionale Anforderungen


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


4.1 Qualitätsziele des Projekts O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

4.2 Qualitätsprioritäten des Kunden O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

A. Anhang

64

Abschnitt

4.3 Wie Qualitätsziele erreicht werden

sollen

O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

Abschnitt Priorität

5 Probleme und Risiken O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

6 Optionen zur Aufwandsreduktion


6.1 Mögliche Abstriche O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

6.2 Inkrementelle Arbeit O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

Abschnitt Priorität

7 Entwurf der grafischen Benutzerober-

fläche/ (GUI-)MockUps

O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

8 Glossar O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

9 Abnahmetestfälle O Sehr wichtig

O Wichtig

O Weniger wichtig

O Unwichtig

A. Anhang

65

Abschnitt

Kommentar

An dieser Stelle haben Sie die Möglich-

keit noch einen Kommentar

hinzuzufügen. Dieser kann beispiels-

weise Gründe für Ihre Bewertung

enthalten, welche Informationen Sie in

der Spezifikation für Ihre Rolle beson-

ders wichtig/ unwichtig fanden oder ob

Sie sich vielleicht noch weitere Anga-

ben, die nicht enthalten waren,

gewünscht hätten.

A. Anhang

66

A.2.3 Inhaltliche Fragen des zweiten Fragebogens der Spezifika-

tion Translate


2.1 Welche Sprachen soll

die Anwendung verarbeiten

können?

(Mission des Projekts)

O Englisch und Deutsch

O Es sollen weitere Sprachen hinzufügbar sein. Stan-

dard sind Englisch und Deutsch.

O Englisch, Deutsch, Spanisch und Französisch

2.2 Wer soll die Anwen-

dung nutzen?


Umfeld)

O Die Anwendung soll Studenten Im Übungsbetrieb

von

Vorlesungen zur Verfügung stehen.

O Die Anwendung ist hauptsächlich an Studenten,

sowie Mitarbeiter der Universität zum Verfassen von

wissenschaftlichen Arbeiten gerichtet.

O Die Anwendung soll innerhalb von Unternehmen

die globale Kommunikation erleichtern. Aber auch

Studenten sollen das Tool nutzen können.

2.3 Auf welchen Webbrow-

sern soll die Anwendung

laufen?


Umfeld)

O Chrome, Firefox, Safari, Internet Explorer ab Ver-

sion 10

O Chrome, Firefox, Safari, Opera

O Chrome ist der empfohlene Browser, auf dem die

Anwendung zur Abnahme laufen soll.

2.4 Welchen Spezialfall

gibt es bei der Angabe von

Gewichtungen?


gen)

O Wenn gespeichert wird, obwohl keine Werte geän-

dert

wurden, erscheint eine entsprechende Meldung.

O Wenn keine ganzzahligen Werte eingegeben wer-

den,

erscheint eine Fehlermeldung.

O Wenn der Benutzer clientseitige Profilspeicherung

blockiert, behält die Anwendung die ursprüngliche

Gewichtung bei.

2.5 Wie werden die Quali-

tätsaspekte vom Kunden

priorisiert (Auflistung in ab-

steigender Reihenfolge)?

(Qualitätsanforderungen)

O Bedienbarkeit, Zuverlässigkeit, Korrektheit, Integri-

tät,

Wartbarkeit, Effizienz

O Bedienbarkeit, Integrität, Portabilität, Wartbarkeit,

Effizient, Korrektheit

O Korrektheit, Effizienz, Bedienbarkeit, Integrität,

Wartbarkeit, Portabilität

A. Anhang

67


2.6 Wie ist der Erfahrungs-

stand im Team bezüglich

des Play!-Frameworks?

(Probleme und Risiken)

O Die meisten Mitglieder haben schon einmal damit

gearbeitet.

O Die meisten Mitglieder haben keine Erfahrung da-

mit.

O Keins der Mitglieder hat bereits damit Erfahrung.

A. Anhang

68

A.3 Ergebnisdaten der Studie

A.3.1 Erster Fragebogen

A. Anhang

69

A.3.2 Zweiter Fragebogen

Frage Frage

2.1 Frage

2.2 Frage

2.3 Frage

2.4 Frage

2.5 Frage

2.6

Rolle Set_a

Set_d

Trans-late_a

Trans-late_d

Teil-neh-mer

Kompo-nenten

1. 002 3 2 3 1 3 3

2. 002 2 3 1 2 2 2

Tester 1. 003 1 2 1 3 3 2

2. 003 3 2 x 1 3 1

Kompo-nenten

1. 004 1 2 1 3 3 3

2. 004 2 2 3 1 3 1

UI-De-signer

1. 005 1 2 1 2 3 2

2. 005 1 2 3 3 3 1

Tester 1. 006 3 2 3 2 3 1

2. 006 1 2 x 3 3 2

Entwick-ler

1. 007 2 2 3 1 2 1

2. 007 1 2 2 3 3 3

Entwick-ler

1. 008 3 2 3 3 3 2

2. 008 2 2 1 3 3 1

UI-De-signer

1. 010 1 2 1 x x 2

2. 010 3 2 3 2 3 1

Entwick-ler 1. 011 3 2 3 1 3 1

Entwick-ler

1. 012 3 2 3 1 3 3

2. 012 1 2 1 2 3 2

Entwick-ler

1. 013 2 3 x x x x

2. 013 2 2 1 2 3 1

A. Anhang

70

A.3.3 Relevanzeinschätzungen der Teilnehmer

Abschnitte Teilneh-mer

1.1

1.2

1.3

1.4

2.1

2.2

2.3

3.1

3.2

3.3

4.1

4.2

4.3 5

6.1

6.2 7 8 9

002 1 2 2 3 1 2 1 3 4 3 2 2 2 4 2 2 4 4 4

002 1 1 3 4 2 2 3 3 4 2 2 1 2 4 3 2 4 4 4

003 2 3 2 4 2 1 3 1 1 1 1 1 1 3 4 4 1 2 4

003 1 2 2 4 2 3 3 2 1 2 3 3 3 4 4 4 2 3 1

004 1 1 2 3 3 4 1 1 2 2 1 2 1 3 2 3 3 2 1

004 1 2 1 4 3 3 1 1 1 2 2 2 2 3 2 1 4 2 1

005 1 1 1 2 1 1 3 3 1 3 2 1 2 2 2 2 1 1 2

005 1 2 2 2 2 1 3 3 1 3 2 2 3 3 3 3 1 3 2

006 1 1 3 3 3 2 4 1 1 3 1 1 3 4 2 4 3 4 3

006 2 1 3 4 3 2 4 2 1 4 1 1 3 4 3 4 4 4 4

007 2 1 3 4 2 1 2 3 1 2 3 3 2 4 2 2 1 4 1

007 1 2 3 4 1 2 3 2 1 2 3 3 3 3 2 2 1 4 1

008 2 1 2 3 2 3 1 1 1 3 3 1 2 2 3 2 1 4 2

008 2 1 2 4 2 3 1 2 2 1 1 1 3 1 3 2 2 4 3

010 2 2 2 4 2 2 3 1 2 2 2 2 2 3 2 2 1 4 4

010 2 1 3 3 2 3 2 1 1 3 2 2 3 3 2 3 1 4 4

011 1 3 3 4 3 3 3 2 1 3 2 2 2 3 2 3 1 4 1

012 1 2 3 4 2 2 3 4 2 2 3 3 2 3 2 3 2 3 3

012 1 1 2 4 2 2 2 4 2 2 3 3 3 3 2 2 2 3 3

013 2 2 3 3 1 1 1 1 1 1 1 2 2 3 3 2 1 3 3

013 1 2 2 3 2 1 2 2 1 2 2 2 2 3 3 2 1 3 3

A. Anhang

71

A.3.4 Lesezeiten der Abschnitte

Lesezei-ten [ms]

1.1 1.2 1.3

1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9

Teilneh-mer

002 7 21 249 88 4 9 29 3 11 26 12 0 2 1 1 2 1 0 0 2 0

002 17 10 41 204 1 6 8 4 15 10 1 0 4 2 12 3 0 0 0 3 0

003 5 14 144 111 14 4 57 14 9 18 87 7 59 51 6 17 6 2 1 3 0

003 20 31 57 120 11 23 30 26 14 8 190 0 17 6 43 16 5 1 0 6 4

004 10 9 145 56 11 2 22 26 32 54 213 0 19 15 13 29 21 15 1 17 2

004 24 25 26 140 16 22 5 6 30 107 134 9 8 1 4 9 1 22 0 5 1

005 6 3 168 45 3 11 16 4 3 6 163 1 22 37 5 9 3 2 0 1 0

005 21 24 47 192 1 2 6 15 9 2 264 2 52 6 13 4 1 0 0 13 1

006 7 4 127 41 7 8 30 14 14 22 273 0 0 0 0 0 0 0 0 0 0

006 0 6 23 62 6 10 8 7 24 16 230 3 72 6 11 13 2 2 0 3 0

007 9 7 112 40 1 5 48 7 9 18 236 1 4 2 0 0 0 0 1 4 0

007 3 4 20 24 7 2 4 10 21 26 240 7 28 3 7 11 2 0 0 3 0

008 8 2 237 62 1 6 22 10 3 21 155 8 13 5 5 5 14 0 4 2 0

008 4 1 7 6 2 4 11 6 14 58 226 6 6 1 3 17 2 0 0 1 0

010 3 1 174 60 0 3 2 1 0 5 261 0 0 0 0 0 0 0 0 0 0

010 10 13 62 306 1 32 20 28 32 81 29 0 2 1 1 6 1 0 4 2 1

012 11 10 274 26 5 6 34 5 7 20 128 6 15 17 8 14 13 5 1 4 0

012 8 3 34 127 8 16 14 12 15 17 24 6 25 4 16 18 8 8 0 4 1

013 0 1 97 73 1 2 14 6 2 17 119 1 33 7 1 2 1 0 2 4 2

013 16 8 23 128 1 3 2 0 1 65 109 1 2 0 0 4 2 0 0 2 1

011 12 2 86 64 5 2 19 6 6 17 353 6 23 8 8 14 13 0 4 4 5

A. Anhang

72

A.3.5 Übersicht über Leseintensitäten

0,000

1,000

2,000

3,000

4,000

5,000

6,000

7,000

8,000

9,000

10,000

1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9

Lese

zeit

/ Lä

nge

[s/

cm]

Abschnitt

relativer Durchschnitt der Lesezeiten: ausgedruckt

0,000

1,000

2,000

3,000

4,000

5,000

6,000

7,000

8,000

9,000

10,000

1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9

Lese

zeit

/ Lä

nge

[s/

cm]

Abschnitt

relativer Durchschnitt der Lesezeiten: am Bildschirm

0,000

1,000

2,000

3,000

4,000

5,000

6,000

7,000

1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9

Lese

zeit

/ Lä

nge

[s/

cm]

Abschnitt

relativer Durchschnitt der Lesezeiten: Set

A. Anhang

73

A.3.6 Übersicht über die Lesegeschwindigkeiten

0,000

2,000

4,000

6,000

8,000

10,000

12,000

14,000

16,000

18,000

20,000

1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9

Lese

zeit

/ Lä

nge

[s/

cm]

Abschnitt

relativer Durchschnitt der Lesezeiten: Translate

0

1

2

3

4

5

6

7

1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9

Ges

chw

ind

igke

it [

cm/s

]

Abschnitt

Geschwindigkeit: ausgedruckt

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

1.1 1.2 1.3 1.4 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5 6.1 6.2 7 8 9

Ges

chw

ind

igke

it [

cm/s

]

Abschnitt

Geschwindigkeit: am Bildschirm

A. Anhang

74

A.3.7 Übersicht über die durchschnittlichen Bewertungen

Bewertung der Rollen (1=sehr wichtig, 2=wichtig, 3=weniger wich-tig, 4=unwichtig)


UI-Desig-ner

Software- architekt

Tes-ter

Entwickler Student

Entwickler erfahren

Entwickler gesamt


1,50 1,00 1,50 1,75 1,25 1,50

1.2 Wünsche und Prio-ritäten des Kunden

1,50 1,50 1,75 1,25 1,75 1,50

1.3 Domänenbeschrei-bung

2,00 2,00 2,50 2,50 2,50 2,50


2,75 3,50 3,75 3,75 3,50 3,63


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,75 1,50 3,50 1,75 2,00 1,88

3.1 Use Case-Dia-gramm

2,00 2,00 1,50 2,00 2,75 2,38

3.2 Use Case-Beschrei-bungen

1,25 2,75 1,00 1,25 1,50 1,38

3.3 Technische Anfor-derungen

2,75 2,25 2,50 2,00 1,75 1,88


2,00 1,75 1,50 2,50 2,25 2,38


1,75 1,75 1,50 2,00 2,50 2,25


2,50 1,75 2,50 2,50 2,25 2,38

5 Probleme und Risi-ken

2,75 3,50 3,75 2,50 3,00 2,75

6.1 Mögliche Abstriche 2,25 2,25 3,25 2,50 2,50 2,50

6.2 Inkrementelle Ar-beit

2,50 2,00 4,00 2,00 2,25 2,13

7 MockUps 1,00 3,75 2,50 1,25 1,50 1,38

8 Glossar 3,00 3,00 3,25 4,00 3,00 3,50

9 Abnahmetestfälle 3,00 2,50 3,00 1,75 3,00 2,38

A. Anhang

75

A.3.8 Übersicht über die relativierten durchschnittlichen Lesezei-

ten der Abschnitte

Lesezeiten der Rollen, umskaliert auf 4 bis 1 (1=sehr intensiv gele-sen)


UI-Desig-ner

Software- architekt

Tes-ter

Entwickler Student

Entwickler erfahren

Entwickler gesamt


4,19 1,13 1,25 1,32 1,22 1,27

1.2 Wünsche und Prio-ritäten des Kunden

1,03 1,06 1,19 1,63 1,16 1,39

1.3 Domänenbeschrei-bung

3,08 1,44 1,38 2,26 2,14 2,20


2,89 2,99 2,93 3,72 3,34 3,53


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


1,88 1,35 1,51 1,82 2,55 2,18

3.1 Use Case-Dia-gramm

2,01 1,41 2,45 1,69 1,79 1,74

3.2 Use Case-Beschrei-bungen

2,58 3,15 2,29 2,17 3,12 2,64

3.3 Technische Anfor-derungen

3,62 2,64 2,23 1,54 2,07 1,81


2,48 3,18 1,76 2,80 2,36 2,58


2,45 3,24 2,04 3,37 2,83 3,10


3,31 2,77 2,33 3,40 2,96 3,18

5 Probleme und Risiken 3,94 3,53 3,43 3,75 3,62 3,68

6.1 Mögliche Abstriche 3,53 2,61 2,20 2,45 1,95 2,20

6.2 Inkrementelle Ar-beit

3,87 1,60 3,46 4,00 2,71 3,35

7 MockUps 2,74 3,84 3,65 2,67 3,24 2,96

8 Glossar 3,72 3,31 3,81 3,94 3,78 3,86

9 Abnahmetestfälle 3,56 3,08 2,86 4,00 3,08 3,54

Documents

Wie werden Spezifikationen gelesen? Eine empirische ... · presentation on paper. The goal of the study was to show nothing but the important The goal of the study was to show nothing