gekürzte Version ohne Sperrvermerk Sperrvermerk.pdf · Ruf des Produktes, des Unternehmens und der...

M

Anwenderanforderungen und Qualittskriterienim Dokumentationsbereich Fernsteuerung von Messgerten –

Eine Studie am Beispiel von Rohde & Schwarz

Zur Erlangung des akademischen GradesMaster of Arts (M.A.)

vorgelegt dem Fachbereich Mathematik, Naturwissenschaften und Informatik

der Technischen Hochschule Mittelhessen

im Studiengang Technische Redaktion und Multimediale Dokumentation

vonTheresia Kiesel

5087659

imAugust 2017

Referent: Prof. Dr. Benedikt ModelKoreferent: Dipl. Biol. Silvia Brunold

gekürzte Version ohne Sperrvermerk

Foto der Titelseite: © Rohde & Schwarz GmbH & Co. KG

Sperrvermerk

Bei der vorliegenden Version der Masterarbeit handelt es sich um eine gekürzte Version. Diese unterliegt keinem Sperrvermerk und darf veröf-fentlicht und vervielfältigt werden.

Elektronischer Anhang ohne Sperrvermerk:

Masterarbeit_ohne Sperrvermerk.pdf

Internetquellen

Eine Einsicht in die vollständige Version der Masterarbeit ist nur mit Genehmigung durch die ROHDE & SCHWARZ GmbH & Co. KG gestat-tet, da sie zu Teilen einem Sperrvermerk unterliegt. Sie beinhaltet ver-trauliche Informationen der ROHDE & SCHWARZ GmbH & Co. KGund darf im Gesamten Dritten - außer Mitarbeitern der Hochschule im Rahmen des hochschulinternen Prüfungsverfahrens - nicht zugänglich gemacht werden.

Kapitel mit Sperrvermerk:

10 Rohde & Schwarz

11 Test des Systems am Beispiel Rohde & Schwarz

Veröfentlichungen und Vervielfältigungen dieser beiden Kapitel, auch nur auszugsweise, sind ohne ausdrückliche Genehmigung der ROHDE & SCHWARZ GmbH & Co. KG untersagt. Zu diesen Kapiteln gehören auch die angeführten Verweise auf den elektronischen Anhang der Masterarbeit (Anhang A) und die vorliegende Version der Masterarbeit als PDF. Damit unterliegen folgende Dateien, Ordner beziehungsweise Unterordner des elektronischen Anhangs dem Sperrvermerk:

Masterarbeit_mit Sperrvermerk.pdf

R&S_Graue Literatur

R&S_Stufe 1_Ermittlung der Anwenderanforderungen (EdA)

Hauptstudie

Vorstudie

R&S_Stufe 2_Bewertung der Qualitt (BdQ)

R&S_Stufe 3_Identiikation von Verbesserungspotenzial (IvV)

________________________ ________________________Datum Unterschrift Theresia Kiesel

Sperrvermerk

Eidesstattliche Erklrung

Ich, Theresia Kiesel, versichere hiermit, dass ich meine Masterarbeit mit dem Titel

Anwenderanforderungen und Qualittskriterienim Dokumentationsbereich Fernsteuerung von Messgerten –


selbstständig und ohne fremde Hilfe verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Die Stellen der Arbeit, die dem Wortlaut oder dem Sinne nach anderen Werken entnommen wurden, sind in jedem Fall unter Angabe der Quelle kenntlich gemacht.

Die Arbeit ist noch nicht veröfentlicht oder in anderer Form als Prfungs-leistung vorgelegt worden.

________________________ ________________________Datum Unterschrift Theresia Kiesel

Eidesstaattliche Erklrung

I

Inhaltsverzeichnis

Inhaltsverzeichnis

1 Einleitung ..........................................................................................11.1 Relevanz des Themas ......................................................................11.2 Aufbau der Arbeit ..............................................................................3

2 Begrifsdeinitionen ........................................................................52.1 Technische Dokumentation .............................................................52.2 System................................................................................................52.3 Abgrenzung des Begrifs Anwender ...............................................52.4 Anforderung beziehungsweise Anwenderanforderung ................72.5 Qualität ...............................................................................................72.6 Verbesserung ....................................................................................8

3 Grundzüge der Messtechnik ........................................................93.1 Einführung ..........................................................................................93.2 Entwicklung und Bedeutung ............................................................93.3 Messtechnische Begrife ............................................................... 103.4 Elektrische Messtechnik.................................................................113.5 Digitale Messsysteme ................................................................... 123.5.1 Einsatz ...............................................................................................12

3.5.2 Hardware ...........................................................................................12

3.5.3 Software ............................................................................................13

3.5.4 SCPI ..................................................................................................13

4 Software- Dokumentation ........................................................... 154.1 Einführung ....................................................................................... 154.2 Dokumentation der Fernsteuerung von Messgeräten ............... 154.3 Beispiele für die Fernsteuerung von Messgeräten .................... 164.4 Dokumentationsformen und weitere Abgrenzungen ................. 174.5 Zusammenarbeit zwischen Entwicklung und Redaktion .......... 214.6 Normative Grundlagen .................................................................. 224.6.1 Normenreihe „Systems and Software Engineering“ ..........................22

4.6.2 Software-Ergonomie und Software-Dokumentation ..........................24

4.6.3 Sonstige Normen ...............................................................................24

5 Anforderungen in der Software- Entwicklung ....................... 255.1 Einführung ....................................................................................... 255.2 Anforderungsanalyse..................................................................... 255.3 Nutzerorientierte Methoden der Software- Entwicklung ............ 265.3.1 Einführung .........................................................................................26

5.3.2 Contextual Inquiry ..............................................................................27

5.3.3 Personas und Szenarien ...................................................................28

5.3.4 Storyboards .......................................................................................28

5.3.5 UX Prototyping ..................................................................................28

5.3.6 Use Cases und User Stories .............................................................29

5.3.7 Usability-Test .....................................................................................29

II

Inhaltsverzeichnis

6 Forschungsstand ......................................................................... 316.1 Der Stand der Technik ................................................................... 316.2 Forschungslücke ............................................................................ 316.3 Forschungsfragen .......................................................................... 326.4 Forschungsziel ............................................................................... 33

7 Ermittlung der Anwenderanforderungen ............................... 357.1 Einführung ....................................................................................... 357.2 Theoretische Vorüberlegungen der Erhebung ........................... 367.2.1 Konstruktion des Erhebungsinstruments ...........................................36

7.2.2 Festlegung der Untersuchungsform ..................................................38

7.2.3 Stichprobenverfahren ........................................................................39

7.3 Methodenauswahl für Datenerhebung und -auswertung .......... 397.3.1 Einführung .........................................................................................39

7.3.2 Vorstudie, Datenerhebung: Problemzentriertes Interview .................40

7.3.3 Hauptstudie, Datenerhebung: Contextual Inquiry ..............................42

7.3.4 Hauptstudie, Datenerhebung: Usability-Test .....................................44

7.3.5 Hauptstudie, Datenerhebung: Standardisiertes Interview .................44

7.3.6 Hauptstudie, Datenerhebung: Abfolge der Methoden .......................45

7.3.7 Hauptstudie, Datenauswertung: User Stories ...................................45

7.4 Datenerhebung ............................................................................. 467.4.1 Vorstudie: Problemzentriertes Interview ............................................46

7.4.2 Hauptstudie: Contextual Inquiry ........................................................48

7.4.3 Hauptstudie: Usability-Test ................................................................50

7.5 Datenerfassung .............................................................................. 517.6 Datenauswertung ........................................................................... 527.6.1 Vorstudie: Problemzentriertes Interview ............................................52

7.6.2 Hauptstudie: Contextual Inquiry ........................................................53

7.6.3 Hauptstudie: Usability-Test ................................................................53

7.6.4 Hauptstudie: Anforderungsmatrix ......................................................54

7.7 Berichterstattung ........................................................................... 547.8 Zusammenfassung ........................................................................ 55

8 Bewertung der Qualitt der Dokumentation .......................... 578.1 Einführung ....................................................................................... 578.2 Theoretische Vorüberlegungen der Erhebung ........................... 578.3 Methodenauswahl .......................................................................... 598.4 Datenerhebung ............................................................................... 608.5 Datenerfassung .............................................................................. 628.6 Datenauswertung ........................................................................... 628.7 Berichterstattung ............................................................................ 628.8 Zusammenfassung ........................................................................ 62

III

Inhaltsverzeichnis

9 Identiikation von Verbesserungspotenzial ........................... 659.1 Einführung ....................................................................................... 659.2 Theoretische Vorüberlegungen der Erhebung ........................... 659.3 Methodenauswahl .......................................................................... 669.4 Datenerhebung ............................................................................... 669.5 Datenerfassung .............................................................................. 679.6 Datenauswertung ........................................................................... 679.7 Berichterstattung ............................................................................ 679.8 Zusammenfassung ........................................................................ 67

10 Rohde & Schwarz .......................................................................... 6910.1 Firmenportrait ................................................................................. 6910.2 Beispielgerät R&S®FSW ............................................................... 7110.3 Fernsteuerung von Messgeräten ................................................. 7110.3.1 Kundenanfragen zum Thema Fernsteuerung ....................................71

10.3.2 Abgeschlossene und laufende Projekte ............................................72

10.4 Dokumentation der Fernsteuerung von Messgeräten ............... 7310.4.1 Grundgesamtheit ...............................................................................73

10.4.2 Form ..................................................................................................73

10.4.3 Prozessbeschreibung ........................................................................74

10.4.4 Umfragen ...........................................................................................76

11 Test des Systems am Beispiel Rohde & Schwarz ................. 7911.1 Ermittlung der Anwenderanforderungen ..................................... 7911.1.1 Vorstudie ............................................................................................79

11.1.2 Hauptstudie .......................................................................................82

11.2 Bewertung der Qualität ................................................................. 9011.3 Identiikation von Verbesserungspotenzial ................................. 9411.3.1 Verbesserungspotenzial ....................................................................94

11.3.2 Verbesserungsvorschläge .................................................................97

12 Diferenzierte Betrachtung des Systems ............................. 10312.1 Ermittlung der Anwenderanforderungen ................................... 10312.1.1 Allgemeine Betrachtung ..................................................................103

12.1.2 Überprüfung der 15 Erfolgsfaktoren nach R ...............................104

12.2 Bewertung der Qualität ............................................................... 10712.3 Identiikation von Verbesserungspotenzial ............................... 107

13 Fazit ............................................................................................... 109

14 Ausblick ........................................................................................111

Anhangsverzeichnis ...................................................................................A-1

A: Übersicht des in elektronischen Anhangs ................................... A-2

B: Schritt für Schritt-Anleitungen ........................................................ A-3Stufe 1: Ermittlung der Anwenderanforderungen ................................A-3Stufe 2: Bewertung der Qualität ........................................................A-25Stufe 3: Identiikation von Verbesserungspotenzial ...........................A-29

Literaturverzeichnis ....................................................................................... V

IV

Abbildungsverzeichnis

AbbildungsverzeichnisAbb. 1: Umsatz Mess-, Kontroll-, Navigations- u. ä. .............................. 2

Abb. 2: Umsatz der deutschen Automationsindustrie nach Sektor ........ 3

Abb. 3: Übersicht des Inhalts ................................................................. 4

Abb. 4: Struktur einer elektrischen Messeinrichtung .............................11

Abb. 5: SCPI-Baumstruktur am Beispiel des SENSe-Befehls ............. 14

Abb. 6: Auszug aus der Dokumentation von Keysight Technologies ... 16

Abb. 7: Auszug aus der Dokumentation von Rohde & Schwarz ........... 17

Abb. 8: Dokumentationsformen der Software- Dokumentation ............. 18

Abb. 9: Nutzungsgruppen und Informationsarten ............................... 19

Abb. 10: Klassiizierung von Software- Dokumentation ........................ 20

Abb. 11: Die Normenreihe im Überblick ............................................... 23

Abb. 12: Übersicht nutzerorientierter Methoden .................................. 26

Abb. 13: Veranschaulichung der Forschungsfragen ............................ 33

Abb. 14: Merkmalsträger, Variable, Kategorien.................................... 37

Abb. 15: Stufe 1 des entwickelten Systems ......................................... 55

Abb. 16: Beispiel-Dokumentation der Funktion einer Tabelle .............. 61

Abb. 17: Stufe 1 und Stufe 2 des entwickelten Systems ..................... 63

Abb. 18: Übersicht des entwickelten Systems ..................................... 68

Abb. 19: Umsatz von Rohde & Schwarz nach Regionen ..................... 70

Abb. 20: Best Practice: Worklow Datenbank ...................................... 76

Abb. 21: Pinnwand mit Gesprächsverläufen ........................................ 80

Abb. 22: Pinnwand mit Anforderungsmatrix ......................................... 81

Abb. 23: Versuchsaufbau Usability-Test München ............................... 85

Abb. 24: Pinnwand mit User Stories .................................................... 87

Abb. 25: Wichtigste Anforderungen ..................................................... 88

Abb. 26: Vergleich der genannten Anforderungen ............................... 89

Abb. 27: Vergleich der Bewertung der Qualität .................................... 92

Abb. 28: Bewertete Qualität der Oberbegrife ...................................... 93

Abb. 29: Durchführbarkeit Verbesserungsvorschläge n. Kategorien ... 95

Abb. 30: Bedeutung der Anforderungen der Oberbegrife ................... 96

Abb. 31: Startseite der aktuellen Fernsteuerungsseite ...................... 100

Abb. 32: Startseite der neuen Fernsteuerungsseite .......................... 101

TabellenverzeichnisTabelle 1: Regeln fr die Zuordnung zu den Oberbegrifen .................. 92

Tabelle 2: Betrachtung gemäß den Erfolgsfaktoren nach R ......... 104

1

EinleitungRelevanz des Themas

1 Einleitung

1.1 Relevanz des Themas

Im Jahr 2015 wurden in Deutschland rund 26 Millionen Smartphones verkauft,1 weltweit waren es über 1,4 Milliarden Geräte.2 Der Käufer erwartet, dass die Smartphones reibungslos funktionieren. Um das zu gewährleisten, muss die Funktionstüchtigkeit der Geräte vor der Auslie-ferung überprüft werden. Zugesicherte Eigenschaften der Smartphones wie die Mobilfunktechnologien WLAN, LTE und Bluetooth® müssen getes-tet werden.Jedes Mobiltelefon einzeln überprüfen zu müssen wäre extrem zeit- und kostenintensiv. Daher werden die Testabläufe, ähnlich wie viele andere Abläufe in der Produktion, automatisiert durchgeführt. Im Gegensatz zur manuellen Bedienung ermöglicht die Fernsteuerung von Messgerä-ten das Ausführen einer festgelegten, zu wiederholenden Sequenz von Bedienschritten – Tests von Mobilfunktechnologien sind nur ein Beispiel. Weitere Vorteile liegen darin, dass der Steuer-PC weit entfernt vom Messgerät installiert sein kann und mehrere Messgeräte gleichzeitig ferngesteuert werden können. Zudem können Messgeräte ohne graphi-sche Bedienoberläche hergestellt werden, was das Angebot gnstigerer Geräte ermöglicht.Verschiedene Gründe sprechen dafür, Messgeräte fernzusteuern. Damit Anwender die Messabläufe automatisieren können, benötigen sie eine Technische Dokumentation des Messgerätes, welche die Anforderungen der Anwender erfüllt.Der Technische Redakteur im Bereich Dokumentation der Fernsteuerung

von Messgeräten indet bei dieser Herausforderung kaum Untersttzung durch geeignete Fachliteratur. Aus dieser Forschungslücke leiten sich die Forschungsfragen der Masterarbeit ab:Wie ermittle ich Anwenderanforderungen für den speziellen Dokumentationsbereich Fernsteuerung von Messgerten auf eiziente Art, bewerte daraufhin die Qualität der Dokumentation und leite daraus Verbesserungspotenzial ab?Das Forschungsziel der Masterarbeit ist die Forschungsfragen durch die Entwicklung eines dreistuigen, aufeinander aufbauenden Systems zu beantworten und abschließend Verbesserungspotenzial aufzuzeigen.

1 Vgl. Statista, Absatz von Smartphones in Deutschland, 2017.2 Vgl. Statista, Endkundenabsatz von Smartphones weltweit, 2017.

2

EinleitungRelevanz des Themas

Dass eine genauere Betrachtung der Dokumentation im Bereich Fern-steuerung von Messgeräten relevant ist, zeigen die Umsatzzahlen.Die deutsche Branche Herstellung von Mess-, Kontroll-, Navigations- und ähnlichen Instrumenten und Vorrichtungen wird im Jahr 2017 voraus-sichtlich knapp 32 Milliarden Euro Umsatz erwirtschaften, im Jahr 2014 lag die Zahl bei etwa 30 Milliarden Euro.3

Abb. 1: Umsatz Mess-, Kontroll-, Navigations- u. ä.4

Im Vergleich dazu hat die umsatzstärkste deutsche Industriebranche, der Kraftfahrzeugbau, im Jahr 2014 einen Umsatz von 371 Milliarden Euro eingebracht.5

Für die Masterarbeit ist aber insbesondere die Fernsteuerung der Mess-geräte interessant, die in den Bereich der Automationsindustrie fällt. Die deutsche Automationsindustrie hat im Jahr 2014 einen Umsatz von knapp 47 Milliarden Euro erzielt, im Jahr 2016 waren es über 50 Milli-arden Euro.6 Der Umsatz teilt sich auf folgende drei Bereiche auf: ers-tens Messtechnik und Prozessautomatisierung, zweitens Schaltgeräte, Schaltanlagen, Industriesteuerung und drittens elektrische Antriebe.7

3 Vgl. Statista, Umsatz Mess-, Kontroll-, Navigations- u. ä., 2017.4 Statista, Umsatz Mess-, Kontroll-, Navigations- u. ä., 2017.5 Vgl. Statista, Umsatz der wichtigsten Industriebranchen, 2017.6 Vgl. Statista, Industrielle Automation in Deutschland, 2017, S. 10.7 Vgl. Statista, Industrielle Automation in Deutschland, 2017, S. 11.

3

EinleitungAufbau der Arbeit

Schaltgeräte, Schaltanlagen, IndustriesteuerungenMesstechnik und Prozessautomatisierung Elektrische Antriebe

2015 2016

Um

satz

in M

illia

rde

n E

uro

2121,5

19 19,4

9,2 9,3

20

15

10

5

0

Abb. 2: Umsatz der deutschen Automationsindustrie nach Sektor8

Der Bereich Messtechnik und Prozessautomatisierung war sowohl im Jahr 2016 als auch im Jahr 2017 am umsatzstärksten.Die Zahlen lassen darauf schließen, dass eine große Anzahl an Techni-schen Redakteuren die Aufgabe hat, die Dokumentation zur Fernsteu-erung der Messgeräte zu schreiben. Da es kaum Literatur zu diesem Thema gibt, bietet die Masterarbeit diesen Technischen Redakteuren bei der Erstellung einer qualitativ hochwertigen Dokumentation im Hinblick auf die Anwenderanforderungen eine Hilfestellung.Neben Anwendern proitieren Unternehmen von einer qualitativ hoch-wertigen Dokumentation, beispielsweise werden die Kosten von Training und Support reduziert. Zudem verbessert eine gute Dokumentation den Ruf des Produktes, des Unternehmens und der Zulieferer.9 Der wahr-genommene Wert und Nutzen der Dokumentation für den Anwender ist damit neben der vorgesehenen Funktion und Leistung der Produkte sowie Dienstleistungen ein integraler Bestandteil der Qualität.10

1.2 Aufbau der Arbeit

Der Technische Redakteur, der das entwickelte System direkt auf seine Dokumentation anwenden möchte, kann in den Anhang zu Kapitel „B: Schritt für Schritt-Anleitungen“ springen.

8 Statista, Industrielle Automation in Deutschland, 2017, S. 11.9 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. ix.10 Vgl. DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 10.

4

EinleitungAufbau der Arbeit

Am Anfang der Masterarbeit werden die theoretischen Grundlagen behandelt. Kapitel 2 „Begrifsdeinitionen“ betrachtet für die Masterarbeit wichtige Begrife. Anschlieaend gibt Kapitel 3 „Grundzüge der Messtech-nik“ einen kurzen Einstieg in den messtechnischen Bereich. Das Kapitel 4 „Software- Dokumentation“ ordnet die Dokumentation zur Fernsteuerung von Messgeräten in diesen Bereich ein und in Kapitel 5 „Anforderungen in der Software- Entwicklung“ geht der Blick über den Tellerrand der „klas-sischen“ Methoden der Empirischen Sozialforschung hinaus.

Kapitel 6 „Forschungsstand“ steigt in den Forschungsteil ein. Darauf folgt das Herzstck der Arbeit, die Entwicklung des dreistuigen Systems fr den Technischen Redakteur im Dokumentationsbereich Fernsteuerung von Messgeräten. Der Entwicklung jeder der drei Stufen ist jeweils ein Kapitel gewidmet. An Kapitel 7 „Ermittlung der Anwenderanforderungen“ schließt Kapitel 8 „Bewertung der Qualität der Dokumentation“ und Kapi-tel 9 „Identiikation von Verbesserungspotenzial“ an.

Bevor das dreistuige System in Kapitel 11 „Test des Systems am Bei-spiel Rohde & Schwarz“ angewandt wird, liegt der Fokus in Kapitel 10 „Rohde & Schwarz“ auf dem Unternehmen, welches unter anderem im Bereich Messtechnik tätigt ist.

In Kapitel 12 „Diferenzierte Betrachtung des Systems“ wird der Test des Systems kritisch relektiert. Kapitel 13 „Fazit“ und Kapitel 14 „Ausblick“ runden die Masterarbeit ab.

Wie bereits beschrieben, beindet sich im Anhang eine Schritt fr Schritt-Anleitung für den Technischen Redakteur. Zudem steht dort eine Übersicht des elektronischen Anhangs, das heißt der Internetquellen, der grauen Literatur sowie der Ergebnisse von Kapitel 11.

1 Einleitung2 Begriffsdefinitionen3 Einführung in die Messtechnik4 Software-Dokumentation5 Anforderungen in der Software-Entwicklung6 Forschungsstand7 Ermittlung der Anwenderanforderungen 8 Bewertung der Qualität der Dokumentation9 Identifikation von Verbesserungspotenzial 10 Rohde & Schwarz 11 Test des Systems am Beispiel Rohde & Schwarz12 Differenzierte Betrachtung des Systems13 Fazit14 AusblickAnhang

Einleitung

Theorie

Entwicklung des Systems

Test des Systems am BeispielRohde & Schwarz

Schluss

Schritt-für-Schritt Anleitung

Abb. 3: Übersicht des Inhalts

5

BegrifsdeinitionenTechnische Dokumentation

2 Begrifsdeinitionen

2.1 Technische Dokumentation

Der Begrif Technische Dokumentation kann in die interne Technische

Dokumentation und die externe Technische Dokumentation unterteilt werden. Während die interne Technische Dokumentation alle techni-schen Informationen zu einem Produkt umfasst, die im Unternehmen verbleiben, beinhaltet die externe Technische Dokumentation technische Informationen eines Produktes für Vertrieb, Anwender und Verbraucher.11 In der Masterarbeit wird Dokumentation oder Technische Dokumentation

als Synonym für die externe Technische Dokumentation verwendet.

2.2 System

Ein System ist unter anderem deiniert als „wissenschaftliches Schema“.12 Für ein Schema wiederum wird folgende Deinition angefhrt: „Konzept, das jemand [in Gedanken] von einem Sachverhalt hat und nach dem er sich bei der Beurteilung oder Ausführung von etwas richtet.“13 Ein Kon-

zept ist unter anderem als „klar umrissener Plan“ deiniert.14

Genau das soll das in der Masterarbeit entwickelte System leisten: Dem Technischen Redakteur einen auf wissenschaftlichen Grundlagen basie-renden Plan an die Hand geben, nach dem er sich bei der Beurteilung und Ausführung richten kann.

2.3 Abgrenzung des Begrifs Anwender

Für den Dokumentationsbereich Fernsteuerung von Messgeräten ist es wichtig, zwischen Anwendern und Nutzern zu unterscheiden. Während die Anwender die Dokumentation verwenden, um beispielsweise Skripte zu schreiben, führen die Nutzer, z. B. die Mitarbeiter in der Produktion, diese lediglich aus.In der Literatur wird der Begrif Anwender aber oft nicht von dem Begrif Nutzer abgegrenzt und zudem unterschiedlich deiniert. Das ist bereits in einer tekom-Schrift, Z ü T D , der Fall. B deiniert Anwender als „den Empfänger einer Information, [ … ] welcher unter Nutzung von Medien Inhalte konsumiert.“15 Anwender

11 Vgl. VDI 4500-1, Technische Dokumentation: Begrifsdeinitionen, S. 4f.12 Duden, System, 2017, S. 1.13 Duden, Schema, 2017, S. 1.14 Duden, Konzept, 2017, S. 1.15 Beier, H., Zielgruppengerechte Zugänge zu dig. Inhalten, 2013, S. 100.

6

BegrifsdeinitionenAbgrenzung des Begrifs Anwender

technischer Produkte oder Servicetechniker sowie Support-Mitarbei-ter sieht er als Zielgruppe der Technischen Kommunikation im engeren Sinne.16 N sieht im Vergleich zu Kunden die Anwender ebenso als wichtigste Zielgruppe der Technischen Dokumentation.17 L -

konkretisiert das, für sie visieren „Technische Redakteure die tat-sächlichen Anwender oder Benutzer an, die sich efektiv eininden hinter den beschrieben Produktkategorien, den globalen Märkten, den eingesetzten Medien, dem Beschreibungsumfang und den rechtlichen Anforderungen.“18 Die Deinitionen sind unterschiedlich konkret. Ihnen gemein ist, dass sie alle Anwender als Zielgruppe der Technischen Dokumentation sehen sowie Anwender und (Be-)Nutzer als Synonyme verwenden. Ebenso nutzt J die Begrife Benutzer und Anwender synonym.19

Manche Deinitionen lassen Spielraum fr andere Zielgruppen neben Anwendern, für andere sind Anwender die einzige Zielgruppe von Tech-nischen Redakteuren. Je nach Deinition kann eine Zielgruppenanalyse entweder auf verschiedene Gruppen oder nur auf Anwender bezogen werden. Das ist bei der Überlegung entscheidend inwiefern die Instru-mente der Zielgruppenanalyse auf die Anforderungen von Anwendern übertragen und erweitert werden können, denn die Anwender werden oft nur implizit nach ihren Anforderungen gefragt.Auch J führt beispielhafte Fragen zur Zielgruppenanalyse an die Anwender auf. Die Frage: „Welche Tätigkeiten führen Sie an solchen Geräten aus?“20, lässt zwar eine Beschreibung der Zielgruppe zu und die Antwort ermöglicht Rückschlüsse auf die Anforderungen der Anwen-der, die Frage: Welche Erwartungen haben Sie von dem Gerät, wenn Sie ihren Tätigkeiten ausführen?, würde hingegen die Anforderungen der Anwender direkt abfragen. Um zu wissen, was sich die Anwender von der Technischen Dokumentation wünschen, ist diese Frage unabdingbar. Dadurch würde ein konkretes Bild der Anwendungsszenarien entstehen und diese müssten nicht wie von J lediglich vermutet werden.21

Da in dieser Masterarbeit aber wie bereits angesprochen zwischen Anwen-der und Benutzer der Dokumentation unterschieden wird, werden dife-renzierende Deinitionen verwendet. Die DIN EN ISO 9241-11:2017-01 beschreibt den Benutzer als eine „Person, die mit einem System, einem Produkt oder einer Dienstleistung interagiert “22 Der Nutzer führt in einer

16 Vgl. Beier, H., Zielgruppengerechte Zugänge zu dig. Inhalten, 2013, S. 100f.17 Vgl. Nickl, M., Mit Methodik zur Zielgruppe, 2013, S. 14.18 Lehrndorfer, A., Zielgruppenspeziisches Texten, 2013, S. 112.19 Vgl. Juhl, D., Technische Dokumentation, 2015, XX.20 Vgl. Juhl, D., Technische Dokumentation, 2015, S. 8.21 Vgl. Juhl, D., Technische Dokumentation, 2015, S. 11.22 DIN EN ISO 9241-11:2017-01(E), Mensch-System-Interaktion, S. 9.

7

BegrifsdeinitionenAnforderung beziehungsweise Anwenderanforderung

Interaktion mit einem Messgerät beispielsweise ein Skript aus. Der Anwender beschäftigt sich aber tiefer mit dem Messgerät und dessen Dokumentation, er konsumiert die Inhalte nach B .23

2.4 Anforderung beziehungsweise Anwenderanforderung

Zudem muss der Begrif Anforderungen deiniert werden. Nach DIN EN ISO 9000:2015-11 ist eine Anforderung eine „Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verplichtend ist“.24 Auch in der DIN 69901-5 zum Thema Projektmanagement wird Anforde-rung deiniert: „Beschafenheit, Fähigkeit oder Leistung, die ein Produkt, Prozess oder die am Prozess beteiligte Person erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Speziikation oder andere, for-mell vorgegebene Dokumente zu erfüllen.“25 Diese Deinition lässt sich auf die Technische Dokumentation übertragen: Eine Anforderung ist eine formell vorgegebene Beschafenheit der Technischen Dokumen-tation. Zusammengesetzt mit dem Begrif Anwender entsteht folgende Deinition:

Eine Anwenderanforderung ist eine durch einen Anwender gewünschte

Beschafenheit der Technischen Dokumentation.

2.5 Qualität

In der DIN EN ISO 9000:2015-11 indet sich der Begrif Anforderungen

in der Deinition der Qualität wieder: „Grad, in dem ein Satz inhärenter Merkmale (3.10.1) eines Objekts (3.6.1) Anforderungen (3.6.4) erfüllt.“26

Die Qualität ist damit als Grad deiniert, inwieweit ein Produkt mit dessen Anforderungen übereinstimmt.

Dabei kann die Qualität durch Adjektive wie schlecht, gut oder ausge-

zeichnet beschrieben werden.27 Des Weiteren wird die Qualitätsanforderung aufgeführt als „Anforderung (3.6.4) bezüglich Qualität (3.6.2).“28

23 Beier, H., Zielgruppengerechte Zugänge zu dig. Inhalten, 2013, S. 100.24 DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 39.25 DIN 69901-5:2009-01, Projektmanagement, S. 6.26 DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 39.27 Vgl. DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 39.28 DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 40.

8

BegrifsdeinitionenVerbesserung

2.6 Verbesserung

Die DIN EN ISO 9000:2015-11 deiniert Verbesserung als „Tätigkeit zum Steigern der Leistung“29. Diese Tätigkeit kann sowohl einmalig als auch wiederkehrend sein kann.30 Die Leistung ist ein „messbares Ergebnis“31.Neben der Verbesserung wird die Qualitätsverbesserung deiniert: „Teil des Qualitätsmanagements (3.3.4), der auf die Erhöhung der Eignung zur Erfüllung der Qualitätsanforderungen (3.6.5) gerichtet ist.“32

29 DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 30.30 Vgl. DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 30.31 DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 45.32 DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 32.

9

Grundzüge der MesstechnikEinführung

3 Grundzüge der Messtechnik

3.1 Einführung

Eine Masterarbeit mit dem Thema Fernsteuerung von Messgeräten muss in den Bereich Messtechnik einführen. Die Auswirkungen von Messtech-nik auf unseren Alltag sowie die Deinitionen zentraler messtechnischer Begrife sind fr das Verständnis der Masterarbeit essentiell. Erläuterun-gen der Entwicklung von elektrischer Messtechnik und digitalen Mess-systemen tragen dazu entscheidend bei.

3.2 Entwicklung und Bedeutung

Der Wissensbereich, der sich auf Messungen bezieht, die sogenannte Metrologie, war bereits in der Antike von Bedeutung. Die Menschen nutzten die Messtechnik in ihrem Alltag, um Entfernungen zu messen. Die verwendeten Maßeinheiten wurden vom menschlichen Körper abge-leitet, z. B. Fuß oder Klafter. Außerdem wurden Waren bereits Jahrtau-sende vor Christus gewogen. Eines der ältesten Maßsysteme, welches aus Babylon stammt, enthielt bereits Einheiten für Volumen und Gewicht. Während der Französischen Revolution wurden neben dem Meter andere Maae deiniert33, „[u]m dem im Laufe der Jahrhunderte entstan-denen Wildwuchs an Maßeinheiten Einhalt zu gebieten“34.„Die messtechnische Erfassung von physikalisch-technischen Gegen-ständen und Prozessen stellt zusammen mit der logischen Denkfähigkeit des Menschen […] eine wesentliche Grundlage aller Natur- und Ingeni-eurwissenschaften dar.“35 Ebenso war und ist die Messtechnik für deren Weiterentwicklung essen-tiell, denn die Ergebnisse von Messungen helfen „neue Erkenntnisse zu erzielen, Zusammenhänge zu erkennen oder Theorien experimentell zu überprüfen.“36

Ein Beispiel für die Bedeutung der Messtechnik in der modernen Techno-logie- und Industrielandschaft ist der durch eine Zeitmessung gelieferte Nachweis für Unregelmäßigkeiten bei der Erdrotation.37 Um diese auszu-gleichen und zu verhindern, dass Sonnenstand und Kalender auseinan-der gehen, gibt es Schaltjahre.38

33 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 1f.34 Lerch, R., Elektrische Messtechnik, 2016, S. 2.35 Lerch, R., Elektrische Messtechnik, 2016, S. 1.36 Mühl, T., Elektrische Messtechnik, 2017, S. 1.37 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 2.38 Vgl. Schellen, P., Das hat schon etwas Paradoxes, taz.de, 28.02.2016.

10

Grundzüge der MesstechnikMesstechnische Begrife

Zudem wird die gesetzliche Zeit in Deutschland messtechnisch über-wacht und überprüft. Das ist Aufgabe des nationalen Metrologie-Instituts, der Physikalisch-Technischen Bundesanstalt. Funkuhren, Bahnhofsuh-ren und Industrieuhren orientieren sich an dieser rund um die Uhr über-wachten Zeit.39

3.3 Messtechnische Begrife

Die Erfassung der physikalischen Größen muss objektiv, reproduzier-bar und quantitativ sein.40 Unter einer Messung wird das „Ausführen von geplanten Tätigkeiten zum quantitativen Vergleich der Meßgröße [ sic ] mit einer Einheit“41, verstanden. Eine der drei unabdingbaren Vorausset-zungen für Messungen ist die Festlegung der Einheit. 1960 wurde das Einheitensystem „Système International d’Unités“ (SI) eingeführt. Das System besteht aus sieben Basiseinheiten, welche als Grundlage die-nen, um weitere Einheiten durch Multiplikation und Division abzuleiten. Das System ist in vielen Ländern gesetzlich vorgeschrieben, wie auch in Deutschland in der ISO 1000 und der DIN 1301.42 Die beiden anderen Voraussetzungen für Messungen sind die Existenz eines Zahlensystems und die Deinition einer Messgröae.43 Die Mess-

größe ist „die physikalische Größe, der die Messung [ ... ] gilt“.44

Um Messgrößen zu messen sind Messgeräte vorgesehen, die helfen den Teil der Natur zugänglich zu machen, der über den menschlichen Sinnesbereich hinausgeht, wie Schall im Ultraschallbereich, der sich auaerhalb des menschlichen Hörfrequenzbereichs beindet.45 Die „Größe in einem Messgerät oder einer Messeinrichtung, die der Messgröße eindeutig zugeordnet ist“,46 wird als Messsignal bezeichnet. Wird das Signal nach dem Messen ausgegeben, ist es als Messwert deiniert.47

Die „Gesamtheit aller Meßgeräte [ sic ] und zusätzlicher Einrichtungen zur Erzielung eines Meßergebnisses [ sic ]“48 ist eine Messeinrichtung. Abbildung 4 zeigt beispielhaft eine elektrische Messeinrichtung und ver-deutlicht den Zusammenhang zwischen Messgröße, - signal und - wert.

39 Vgl. Schow, E., EFR-Zeit ist jetzt auch gesetzliche Zeit, PTB, 22.05.2017.40 Vgl. Mühl, T., Elektrische Messtechnik, 2017, S. 1.41 DIN 1319-1:1995-01, Grundlagen der Meßtechnik, S. 4.42 Vgl. Mühl, T., Elektrische Messtechnik, 2017, S. 9.43 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 3.44 DIN 1319-1:1995-01, Grundlagen der Meßtechnik, S. 2.45 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 3.46 DIN 1319-1:1995-01, Grundlagen der Meßtechnik, S. 8.47 Vgl. DIN 1319-1:1995-01, Grundlagen der Meatechnik, S. 9f.48 DIN 1319-1:1995-01, Grundlagen der Meßtechnik, S. 18.

11

Grundzüge der MesstechnikElektrische Messtechnik

Hilfsgerät(Hilfsenergie)

Aufnehmer Anpasser Ausgeber

Messeinrichtung

Messgröße Messwert

Mess-signal

z.B.Messumformer

z.B.Messverstärker,elektronischesRechengerät

z.B.Anzeiger,Schreiber,

Zähler

MessketteMessgeräte

Mess-signal

y1 y2

zx

Abb. 4: Struktur einer elektrischen Messeinrichtung49

Zunächst wird die Messgröße in ein elektrisches Messsignal umgewan-delt, entweder direkt oder über andere physikalische Größen. Das Mess-signal gelangt anschließend zu den Anpassern, welche Messgeräte wie Messverstärker oder elektronische Rechengeräte enthalten. Im letzten Schritt wird das Messsignal als Messwert entweder ausgegeben, bei-spielsweise über eine Anzeige, oder, falls das Signal nicht ohne Spe-zialvorrichtung lesbar ist, indirekt zur weiteren Informationsverarbeitung weitergegeben.50

Die „[p]hysikalische Grundlage der Messung“51 wird als Messprinzip

bezeichnet. Davon unabhängig beschreibt die Messmethode die Art des Vorgehens bei der Messung. Ein Messverfahren bezeichnet die Anwen-dung eines Messprinzips und einer Messmethode.52

3.4 Elektrische Messtechnik

Elektrische Messverfahren und deren stetig wachsende Verwendung stellen einen wichtigen Trend in der Messtechnik dar.53 Aufnehmer kön-nen auch für nicht elektrische Messgrößen entwickelt werden. Mit Hilfe von Sensoren stellen Aufnehmer Messgrößen fest, setzen sie in elektri-sche Signale um und verarbeiten sie weiter.54 Beispielsweise kann Druck mit Sensoren in eine elektrische Größe umgeformt, die Frequenzände-rung elektrisch gemessen und das Signal weiterverarbeitet werden.55

49 Lerch, R., Elektrische Messtechnik, 2016, S. 6.50 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 5f.51 DIN 1319-1:1995-01, Grundlagen der Meßtechnik, S. 7.52 Vgl. DIN 1319-1:1995-01, Grundlagen der Meßtechnik, S. 7.53 Vgl. Mühl, T., Elektrische Messtechnik, 2017, S. 2.54 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 3f.55 Vgl. Mühl, T., Elektrische Messtechnik, 2017, S. 2.

12

Grundzüge der MesstechnikDigitale Messsysteme

Ein Grund für den Anstieg elektrischer Messverfahren ist das gute Ver-hältnis der Präzision zum Aufwand. Verglichen mit mechanischen Grö-aen liefern elektrische Signale eine gröaere Aulösung bei einem relativ geringen Verarbeitungs- und Speicheraufwand.56 Zudem ist eine Über-tragung über weite Entfernungen einfach.57

3.5 Digitale Messsysteme

3.5.1 EinsatzNeben dem stark zunehmenden Einsatz elektrischer Messverfahren sind computerbasierte, digitale Messsysteme der wichtigste Trend innerhalb der Messtechnik.58 Mit der voranschreitenden Entwicklung der Rechner im Digitalbereich wurden immer häuiger Rechner fr komplexe Messun-gen herangezogen, insbesondere in den Bereichen Messdatenerfassung und Messsignalverarbeitung.59 Die Messdaten können auf verschiedenen Wegen zum Rechner gelan-gen. Eine Methode „basiert auf an den Rechnerbus angeschlossenen Messmodulen, die auf einer Computereinsteckkarte realisiert sind (Inst-rument-on-a-Card) und in der Regel einen Analog-Digital-Umsetzer mit vorgeschaltetem Multiplexer enthalten.“60 Eine andere Methode ist die Fernsteuerung der Geräte.61

Die wichtigsten Vorteile für die Verwendung computergestützter Messda-tenerfassung sind nach L :• Automatisierung kompletter Messabläufe• Einsparung redundanter Hardware (durch zeitlichen Multiplexbetrieb)• sichere und eiziente Speicherung von Messdaten• Ersatz von dedizierten und an spezielle Aufgaben gebundene Hard-

ware-Komponenten durch anwendungslexible Software-Module, z. B. bei der Filterung

• gute Visualisierungs- und Archivierungsmöglichkeiten durch Nutzung vielfach vorhandener Standard-PC-Software

• leichte Einbindung der Messdatenerfassung in Regelsysteme oder Anlagen der Automatisierungstechnik62

3.5.2 HardwareUnabdingbar für die Messdatenerfassung sind ein Steuerrechner mit Schnittstellen sowie die Prozessperipherie. 1965 stellte die Firma

56 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 3.57 Vgl. Mühl, T., Elektrische Messtechnik, 2017, S. 2.58 Vgl. Mühl, T., Elektrische Messtechnik, 2017, S. 2.59 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 515.60 Lerch, R., Elektrische Messtechnik, 2016, S. 515f.61 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 516.62 Lerch, R., Elektrische Messtechnik, 2016, S.516.

13


Hewlett Packard ein Interface-System vor, welches es ermöglichen sollte, Messgeräte verschiedener Hersteller über eine Busstruktur zu verbinden.63 Denn kommerzielle vom Computer aus gesteuerte Mess-geräte, die in den 1960ern eingeführt wurden, verwendeten eine große Bandbreite an nicht standardisierten, eigenen Schnittstellen. 1975 verab-schiedete das Institute of Electrical and Electronic Engineers (IEEE) den IEEE 488-197-Standard. IEEE 488 deiniert eine standardisierte elektri-sche und mechanische Schnittstelle für Verbindungen und Kabel.64 1975 erstellte die International Electrotechnical Commission (IEC) einen Nor-mentwurf, der heute als IEC625 gültig ist.65

3.5.3 SoftwareNeben der Hardware ist für die Messdatenerfassung eine Treibersoft-ware notwendig, „die dem Benutzer eine nach Möglichkeit komfortable Software-Schnittstelle zu der von ihm verwendeten Computer-Hochspra-che zur Verfügung stellt.“66 Dadurch wird die Softwaresteuerung der zur Prozessperipherie gehörenden Hardware möglich.67

Eine Messdatenerfassungssoftware sollte nach L folgende Aufga-ben durchführen können:• Erfassen von Daten über Schnittstellen und Einsteckkarten• Speichern von Daten• Graphische Darstellung von Daten• Analyse der Daten mit mathematischen Werkzeugen• Berechnung von Ausgangsgrößen68

3.5.4 SCPIEine weitere Digitalisierung von Messgeräten, die für die Masterarbeit interessant ist, ist die Fernsteuerung der Messgeräte. Um für die Befehle zur Steuerung von Messgeräten einen Standard zu schafen, wurden die Standard Commands for Programmable Ins-

truments (SCPI) entwickelt. Der Standard lehnt sich an die bereits erwähnte IEEE 488 und deren Versionierungen an.69 SCPI sollte die Ent-wicklungszeit für Programme von Messgeräten durch eine konsistente Programmierumgebung für Kontrollinstrumente und Datennutzung redu-zieren, wie deinierte Programmnachrichten, Antworten der Geräte und Dateiformate.70

63 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 555.64 Vgl. SCPI Consortium, Vol 1 Syntax and Style, 1999, S. ii.65 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 555.66 Lerch, R., Elektrische Messtechnik, 2016, S. 681f.67 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 681f.68 Lerch, R., Elektrische Messtechnik, 2016, S. 688.69 Vgl. Lerch, R., Elektrische Messtechnik, 2016, S. 682.70 Vgl. SCPI Consortium, Vol 1 Syntax and Style, 1999, Introduction 1-1f.

14


SCPI wollte in drei Ebenen Kompatibilität erreichen. Die Kompatibilität auf der vertikalen Ebene sollte erreichen, dass zwei Instrumente derselben Geräteklasse identisch kontrolliert werden können. Auf der Ebene der horizontalen Kompatibilität sollten zwei Instrumente dieselben Befehle für dieselbe Messung verwenden. Die dritte Ebene der Kompatibilität bezog sich auf die Funktionalität. Messgeräte, welche dieselbe Funktion ausführen, sollten das mit demselben Befehl machen.71 Ein SCPI-Befehl besteht aus einem sogenannten „Program Header“, welcher den Befehl identiiziert. Die ersten Buchstaben, die in Groabuchstaben dargestellt werden, stellen die Kurzform dar. Der gesamte Befehl ist die Langform. Dabei dient die Groß- und Kleinschreibung lediglich der Veranschauli-chung der beiden gültigen Befehlsformen auf die ein Messgerät reagiert.

SCPI-Befehle bauen auf einer hierarchischen Baumstruktur auf, wie in Abbildung 5 an einem Beispiel zu sehen ist.72

SENSeSENSe

UPPerUPPer AUTO AUTOAUTO

RESolutionRANGeRANGe RESolution

CURRentCURRent

AUTOUPPer AUTOAUTO

RANGe RESolutionRESolutionRANGe

VOLTageVOLTage

Abb. 5: SCPI-Baumstruktur am Beispiel des SENSe-Befehls73

Alle Befehle haben die Möglichkeit Werte abzufragen, was durch ein Fra-gezeichen ausgedrückt wird.74

71 Vgl. SCPI Consortium, Vol 1 Syntax and Style, 1999, Instrument Model 2-1f.72 Vgl. SCPI Consortium, Vol 1 Syntax and Style, 1999, Program Headers 6-1f.73 Lerch, R., Elektrische Messtechnik, 2016, S. 684.74 Vgl. SCPI Consortium, Vol 1 Syntax and Style, 1999, Program Headers 6-1f.

15

Software- DokumentationEinführung

4 Software- Dokumentation

4.1 Einführung

Um ein System für die Dokumentation zur Fernsteuerung von Messge-räten entwickeln zu können, ist es essentiell, diesen Dokumentations-bereich im weiten Feld der Technischen Dokumentation einzuordnen. Nach der Einordnung in die Software-Dokumentation veranschaulichen zunächst zwei Beispiele den Dokumentationsbereich Fernsteuerung von Messgeräten. Anschließend wird die Software-Dokumentation und deren Zusammenspiel mit der Software-Entwicklung betrachtet. Daraufhin wird der Blick auf normative Grundlagen der Software- Dokumentation gerich-tet. Ziel der Aulistung ist es nicht, sämtliche Normen wiederzugeben. Vielmehr geht es um eine Referenz für die Entwicklung und Umsetzung des Systems.

4.2 Dokumentation der Fernsteuerung von Messgeräten

Im Rahmen der Masterarbeit wurde aus folgendem Grund festgelegt die Dokumentation zur Fernsteuerung als Ergänzung zum Rest der Doku-mentation, der Gerätebeschreibung, zu betrachten: Viele Anwender wer-den sich zum Einstieg mit der manuellen Bedienung auseinandersetzen und erst danach zur Fernsteuerung übergehen. Anwender, die das Gerät nur manuell bedienen möchten, werden die Ergänzung für die Fernsteu-erung nicht nutzen. Das in der Masterarbeit entwickelte System für den Technischen Redak-teur konzentriert sich auf diesen ergänzenden Dokumentationsbereich.

Die Dokumentation der Fernsteuerung von Messgeräten erklärt bei-spielsweise, wie Befehle an Messgeräte gesendet werden, wie Werte abgefragt werden und wie ein Skript für die Programmierung der Mess-geräte erstellt wird. Daher kann dieser Teil der Dokumentationen unter die Dokumentation von Programmiersprachen gefasst werden. G ü -

zählt ihn neben der Dokumentation von Anwendungssoftware und Systemsoftware zur Software- Dokumentation.75 Auch für T geht Software- Dokumentation über die reine Anwendungssoftware hinaus. Normen aus dem Bereich „lassen sich auch auf andere Software-Typen

75 Vgl. Grünwied, G., Software- Dokumentation, 2013, S. 1.

16

Software- DokumentationBeispiele für die Fernsteuerung von Messgeräten

übertragen, z. B. auf Steuerungssoftware von Anlagen, Geräten und Maschinen.“76 Diese Aussage spricht für die Einordnung der Dokumen-tation der Fernsteuerung von Messgeräten in den Bereich Software- Dokumentation, da Messgeräte programmiert werden, um sie zu steuern.

4.3 Beispiele für die Fernsteuerung von Messgeräten

Bevor der Bereich Software-Dokumentation genauer betrachtet wird, ver-anschaulichen zwei Screenshots die Dokumentation zur Fernsteuerung von Messgeräten. Die Beispiele stammen von den Messgeräte-Herstel-lern Keysight Technologies und Rohde & Schwarz.

Abb. 6: Auszug aus der Dokumentation von Keysight Technologies77

76 Thiele, U., TechDok light, 2011, S. 204.77 Keysight Technologies, IniniiVision, Programmer‘s Guide, 2017, S. 223.

17

Software- DokumentationDokumentationsformen und weitere Abgrenzungen

Abb. 7: Auszug aus der Dokumentation von Rohde & Schwarz78

Die Gegenüberstellung der beiden Dokumentationen zeigt, dass sie ähnlich aufgebaut sind. Ein Abschnitt wird jeweils mit dem entspre-chenden Kommando eingeleitet. Anschließend wird das Kommando genauer erklärt und Hinweise gegeben. Keysight Technologies verweist auf weitere Informationen unter „See Also“. In der Dokumentation von Rohde & Schwarz inden sich bei dem Beispiel zwar keine Links zu weite-ren Informationen, grundsätzlich gibt es in der Dokumentation aber Ver-weise, wenn auch in einem geringeren Umfang.Grundsätzlich unterscheiden sich die Dokumentationen der Fernsteu-erung der Messgeräte darin, dass Keysight Technologies einen abge-schlossenen P ‘ G anbietet, während Rohde & Schwarz die Fernsteuerbefehle in das Handbuch der manuellen Bedienung integriert.

4.4 Dokumentationsformen und weitere Abgrenzungen

Da die Fernsteuerung von Messgeräten in die Software-Dokumentation eingeordnet wurde, muss der Bereich mit seinen Dokumentationsformen

78 Rohde & Schwarz, FSW User Manual, 01.08.2017, S. 730.

18


und Abgrenzungen genauer betrachtet werden. Dieser Schritt ist essen-tiell, um Aspekte der Software-Dokumentation auf die Entwicklung des Systems zur Fernsteuerung von Messgeräten transferieren zu können.Nach G ü kann Software- Dokumentation gemäß den Erstellern der Dokumentation unterteilt werden. G ü führt daher folgende vier Dokumentationsformen an: Systemdokumentation, Benutzerinfor-

mation, Styleguides und Projekt- und Prozessdokumentation.

System-dokumentation

Benutzerinformation Styleguides

Projekt- undProzessdokumentation

Softwareentwickler Software-RedakteurDesigner und

Usability-Experten Projektverantwortliche

Dokumentationsformen

1110110100

Abb. 8: Dokumentationsformen der Software- Dokumentation79

Demnach haben Software-Entwickler die Aufgabe, die Entwicklung der Software intern zu dokumentieren, z. B. deren Architektur. Designer und Usability-Experten fassen in internen Styleguides ihre Konzepte für eine an den Nutzern orientierte Gebrauchstauglichkeit und benutzer-freundliche Oberläche zusammen. Die Projektverantwortlichen wiede-rum haben beispielsweise die Aufgabe, interne Planungsdokumente zu erstellen.80 Die Benutzerinformation der Software-Redakteure erklärt den Nutzern die Software, z. B. in Form von Online-Hilfen, und stellt damit eine externe Dokumentation dar. Rü unterteilt die Dokumentation mit den Formen System-, Produkt- sowie Projekt- und Prozessdokumentation ähnlich. Nach seiner Deini-tion thematisiert die Systemdokumentation die innere Funktionsweise der Software, unter Produktdokumentation fasst er die gesamte Dokumenta-tion zusammen, die sich an den Nutzer richtet, die Projektdokumentation beschreibt den Fortschritt des Projekts und die Prozessdokumentation

79 Grünwied, G., Kurz notiert, Software- Dokumentation, 2017, S. 25.80 Vgl. Grünwied, G., Kurz notiert, Software- Dokumentation, 2017, S. 24f.

19


die allgemeine Vorgehensweise im Projekt.81

Da in der Masterarbeit lediglich die Dokumentation betrachtet wird, wel-che für die Nutzer bestimmt ist, das heißt die externe Dokumentation, ist nach der angefhrten Deinition ihr Inhalt die Benutzerinformation bezie-hungsweise die Produktdokumentation.Bö und R unterscheiden Software- Dokumentation gemäß vier Nutzungsgruppen und fünf Informationsarten.

SystemEvalutors

System Administrators Novice UsersExperienced

Users

FunktionelleBeschreibung

Installations-Anleitung

EinführendeAnleitung

Referenz-Handbuch

Wie das Systeminstalliert wird

Erste Schrittemit dem System

Wie das Systembetrieben undgewartet wird

Beschreibungunterstützter

Funktionalitäten

Details zurNutzung allerFunktionen

Wie das Systembetrieben undgewartet wird

SystemAdministrators

Guide

Abb. 9: Nutzungsgruppen und Informationsarten82

Die System Evaluators entscheiden anhand der Funktionalitäten, ob eine Software gekauft wird. Für die System Administrators ist die Informa-tion wichtig, wie ein System installiert, betrieben und gewartet wird. Die Novice Users erwarten sich eine einführende Anleitung und die Experi-

enced Users suchen die benötigte Information im Referenzhandbuch.83

Software- Dokumentation kann zudem aufgrund ihres Präsentationsme-diums als OnScreen-Dokumentation oder Print-Dokumentation bezeich-net werden. Ein Beispiel zeigt, dass die Einordnung nicht immer einfach ist: Ein PDF einer Dokumentation, welches am Rechner angesehen wird, ist meistens zum Drucken erstellt worden und wird daher als Print-Doku-mentation angesehen.Neben dieser Einteilung kann Software- Dokumentation aufgrund ihrer Informationsweitergabe klassiiziert werden, wie Speicher-, Präsenta-tions- und Wahrnehmungsmedien.84

81 Vgl. Rüping, A., Dokumentation in agilen Projekten, 2013, S. 15f.82 Böcker, M.; Robers, R., Kundendokumentationen, 2015, S. 186.83 Vgl. Böcker, M.; Robers, R., Kundendokumentationen, 2015, S. 187.84 Vgl. Grünwied, G., Software- Dokumentation, 2013, S. 24.

20


Speicher-Medien

Print-Dokumentation Papier

CDPapierFolie

TextBild Visuell

Visuell

Auditiv

FestplatteCD/DVDServerInternet

BildschirmDisplay

Lautsprecher

TextBild

AnimationSprache

GeräuschMelodie

OnScreen-Dokumentation

Wahrnehmungs-Medien

Präsentations-Medien

Abb. 10: Klassiizierung von Software- Dokumentation85

Die Entscheidung bezüglich der Medien muss der Technische Redak-teur mit Blick auf die Anforderungen der zu erstellenden Dokumentation trefen. Beispielsweise hängt die Frage nach der Aktualisierbarkeit mit dem Speicher-Medium zusammen und das Präsentations-Medium wirkt sich auf die Farben aus. Im Vergleich zu Print-Dokumentationen, die jeder Anwender in gleicher Form vor sich liegen hat (bei einem durchgängigen Farbmanagement), weiß der Technische Redakteur bei OnScreen-Do-kumentationen nicht, wie der Anwender sie sehen wird. Eine Print-Do-kumentation gibt dem Anwender eine lineare Struktur vor, was zu einer anderen Wahrnehmung und Aufnahme des Inhalts führt als bei OnScreen-Dokumentationen.86 Es ist ein Trend der verstärkten Nutzung von OnScreen-Dokumentatio-nen bei Softwareprodukten zu verzeichnen. Für Anfänger bieten jedoch Print-Dokumentationen Vorteile, da beispielsweise das Lesen an sich oder das Arbeiten mit der Dokumentation, z. B. durch Unterstreichungen, einfacher ist.87

Eine Möglichkeit der Diferenzierung von OnScreen-Dokumentationen wiederum liegt in der Frage, ob eine Dokumentation produktgekoppelt

85 Grünwied, G., Software- Dokumentation, 2013, S. 25.86 Vgl. Grnwied, G., Software- Dokumentation, 2013, S. 25f.87 Vgl. Grünwied, G., Software- Dokumentation, 2013, S. 29.

21

Software- DokumentationZusammenarbeit zwischen Entwicklung und Redaktion

oder (nur) produktabhängig ist. Ein Beispiel für eine produktgekoppelte OnScreen-Dokumentation ist ein Software-Assistent, für eine produktab-hängige Dokumentation ist es die Webseite eines Software-Herstellers. Die Entscheidung muss der Technische Redakteur in Hinblick auf die spätere Dokumentation trefen. Zudem können OnScreen-Dokumen-tationen bezüglich der Kontextsensitivität unterschieden werden. Wäh-rend kontextunabhängige Dokumentationen immer gesamt aufgerufen werden, ist die kontextsensitive Hilfe abhängig von der Situation des Anwenders.88 Des Weiteren kann die Dokumentation dahingehend unterschieden wer-den, ob sie bereits vor dem Kauf oder erst danach zugänglich ist.89

4.5 Zusammenarbeit zwischen Entwicklung und Redaktion

Bei der Erstellung von Software-Dokumentation sind funktionie-rende Informationslsse zwischen Software-Redaktion und Software- Entwicklung notwendig.Beispielsweise benötigen die Redakteure schon zu einem frühen Zeit-punkt Zugrif auf die Systemdokumentation um die Technische Dokumen-tation erstellen zu können. Auch im weiteren Verlauf der Entwicklung, z. B. bei Änderungen an der Software, müssen die Redakteure informiert werden. Je stärker der Redakteur in den Entwicklungsprozess integriert ist, desto besser funktioniert der Informationsluss.Funktionierende Informationslsse sind im Hinblick auf den Freigabe-prozess wichtig. Bei der Freigabe einer Software muss die Dokumenta-tion als Bestandteil korrekt und vollständig sein.90

Eine Möglichkeit sind automatisch generierte Freigabemitteilungen aus den Systemen der Entwickler. Dadurch kann der Redakteur neue und geänderte Funktionen direkt dokumentieren. Neben den automatischen Freigabemitteilungen gibt es den Weg der direkten Kommunikation, bei-spielsweise durch Meetings.91

Eine weitere Möglichkeit optimale Informationslsse sowie Terminein-haltungen zu gewährleisten ist „[d]ie Integration von Software-Redakteu-ren in das Entwicklungsteam“92. Ein weiterer Vorteil der Zusammenarbeit ist, dass die Software-Redakteure ihre Sprachexpertise direkt in die Software- Entwicklung einlieaen lassen und eine konsistente Terminolo-gie durchführen können.93

88 Vgl. Grnwied, G., Software- Dokumentation, 2013, S. 25f.89 Vgl. Grünwied, G., Software- Dokumentation, 2013, S. 30.90 Vgl. Grünwied, G., Kurz notiert, Softwaredokumentation, 2017, S. 25.91 Vgl. Grünwied, G., Kurz notiert, Softwaredokumentation, 2017, S. 25.92 Grünwied, G., Kurz notiert, Softwaredokumentation, 2017, S. 25.93 Vgl. Grünwied, G., Kurz notiert, Softwaredokumentation, 2017, S. 25f.

22

Software- DokumentationNormative Grundlagen

Auch ohne Integration der Redakteure in das Team müssen funktionie-rende Informationslsse sichergestellt werden.94 „[N]ur solche Konzepte [können] eine gebrauchstaugliche Software einschließlich Benutzerinfor-mation erzielen.“95

4.6 Normative Grundlagen

4.6.1 Normenreihe „Systems and Software Engineering“Den bereits beschriebenen Zusammenhang zwischen der Gebrauchs-tauglichkeit sowie einem funktionierendem Informationsluss zwischen Software- Entwicklung und Software-Redaktion bestärkt die Norm ISO/IEC 26514:2008(E).Gemäß dieser Norm stellt die Dokumentation einen wesentlichen Teil der Benutzerfreundlichkeit der Software dar.96 Damit ist eine qualitativ hochwertige Dokumentation eine Grundvoraussetzung um ein Soft-wareprodukt zu erstellen, welches die Erwartungen und Bedürfnisse der Benutzer erfüllt.97

Die Herausforderungen bei der Arbeit mit Software-Dokumentation werden in einer eigenständigen Normenreihe mit der zentralen Norm ISO/IEC 26514:2008(E) für Technische Redakteure behandelt. Die Nor-menreihe thematisiert die verschiedenen Rollen rund um das Thema System- und Softwareanforderungen und Benutzerdokumentation.

Die Normenreihe, insbesondere die ISO/IEC 26514:2008(E), themati-siert Software-Dokumentation allgemein, während sich die Masterarbeit auf die Anforderungen der Anwender im speziellen Dokumentationsbe-reich konzentriert. Da die Masterarbeit aber dennoch eng mit der Norm zusammenhängt, wird der Blick genauer auf die normativen Grundlagen gerichtet.

94 Vgl. Grünwied, G., Kurz notiert, Softwaredokumentation, 2017, S. 27.95 Grünwied, G., Kurz notiert, Softwaredokumentation, 2017, S. 27.96 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 17.97 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 13.

23


Norm Ausgabedatum Systems and Software requirements

Beschreibung

ISO/IEC/IEEE 26511

2012 Requirements for managers of user documentation

Die internationale Norm speziiziert die Anforderungen an Strategie, Planung, Durchführung und Steuerung aus Sicht der Verantwortlichen für Softwaredokumentation.

ISO/IEC/IEEE 26512

2011 (Ersatz für ISO/IEC 15910:1999)

Requirements for acquirers and suppliers of user documentation

Die internationale Norm stellt die Zusammenarbeit zwischen Auftraggebern und Dienstleistern bei der Dokumentationserstellung in den Vordergrund.

IEEE 26513 2010 Requirements for Testers and Reviewers of User Documentation

Die internationale Norm adressiert die Verantwortlichen für die Evaluierung von Softwaredokumentation und schildert dazu die verschiedenen Aktivitäten, Tests, Methoden und Abläufe.

IEEE 26514 2010 (vormals ISO/IEC 26514:2008) [1]

Anforderungen an Designer und Entwickler von Benutzerdokumentationen

Die zentrale Norm für Softwaredokumentation enthält sowohl die Richtlinien für den Erstellungsprozess als auch die Qualitätskriterien an das Dokumentationsprodukt.

ISO/IEC/IEEE 26515

2012 Systems and software engineering -Developing user documentation in an agile environment

Die internationale Norm unterstützt Technische Redakteure und Dokumentationsverantwortliche speziell bei Projekten der agilen Softwareentwicklung.

Abb. 11: Die Normenreihe im Überblick98

Beispielsweise werden in der ISO/IEC 26514:2008(E) Aussagen getrof-fen, welche Informationen als Print-Dokumentation vorliegen müssen: • Anforderungen an Hardware, Betriebssystem, Browser und andere

Software-Anforderungen für die Software und die Dokumentation• Informationen zur Koniguration und Installation sowie Informationen zu

Recovery-Aktionen und Fehlerbehebung bei Installationsanleitungen• Anleitung zum Starten der Software• Anleitung zum Zugrif auf die OnScreen-Dokumentation• Kontaktinformationen zum Technischen Support99

98 Grünwied, G., Ein vielfältiges Spektrum, 2013.99 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc, S. 60.

24


Das ist die einzige Möglichkeit eine Hilfe für den Anwender zu liefern, falls die Software nicht mehr funktioniert.100

4.6.2 Software-Ergonomie und Software-DokumentationSoftware muss möglichst intuitiv bedienbar sein.101 Von ihr „wird stär-ker als von anderen technischen Produkten erwartet, dass diese einen hohen Grad an Selbstbeschreibungsfähigkeit hat.“102 Die Anforderun-gen an Software werden in der Normenreihe DIN EN ISO 9241 dei-niert, die vom Komitee Ergonomie der Mensch-System-Interaktion erarbeitet wurde. In der DIN EN ISO 9241-1 wird eine Übersicht über die Normenreihe geliefert. Demnach gelten DIN EN ISO 9241-10 bis DIN EN ISO 9241-11 für den allgemeinen Anwendungsbereich und DIN EN ISO 9241-12 bis DIN EN ISO 9241-17 für den Anwendungsbe-reich Software.Die Normen werden nicht näher betrachtet, weil nicht die Software, son-dern die Software- Dokumentation Gegenstand der Masterarbeit ist.103

4.6.3 Sonstige NormenDa der Fokus auf der Dokumentation liegt, lieat die IEC 82079-1:2012-08 als Norm zur Erstellung von Gebrauchsanleitungen mit ein. Die DIN 66270:1998-01 beschäftigt sich zwar mit dem Bewerten von Software-Dokumenten, wurde aber wegen ihrer geplanten Zurückzie-hung im Monat der Abgabe der Masterarbeit nicht weiter berücksichtigt.

Gemäß ISO/IEC 12207:2008 ist Software-Dokumentation ein Teil des Software-Produkts. Daher sollte die Dokumentation gemeinsam mit der Software entstehen. So kann die Software und deren Dokumentation gemeinsam getestet, verteilt und gewartet werden.104 „Die thematische und zeitliche Synchronisation von Dokumentations- und Lebenszyklus-prozess stärkt den Stellenwert der Benutzerdokumentation als notwendi-gen Bestandteil eines vollständigen Softwareproduktes. “105

100 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 60.101 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. ix.102 Grünwied, G., Software- Dokumentation, 2013, S. 15.103 Vgl. DIN EN ISO 9241-1:1997 + A1:2001, Ergonomische Anforderungen, S. 7f.104 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 10.105 Grünwied, G., Ein vielfältiges Spektrum, 2013.

25

Anforderungen in der Software- EntwicklungEinführung

5 Anforderungen in der Software- Entwicklung

5.1 Einführung

In der Technischen Dokumentation bilden Zielgruppen- und Tätigkeits-analyse die Basis für Anforderungen. Auch in der Software- Entwicklung werden Anforderungen festgehalten, um den Entwicklern aufzuzeigen, was implementiert werden muss. In diesem Kapitel wird ein Blick auf die dabei verwendeten Methoden geworfen, um sie zum Teil in der Master-arbeit heranziehen zu können. Die nähere Auseinandersetzung zeigt, dass sich insbesondere die Methoden Contextual Inquiry, User Stories sowie Usability-Tests für das System eignen würden.Zuvor wird der Stellenwert von Anforderungen in der Software- Entwicklung beschrieben.

5.2 Anforderungsanalyse

Der R U P ® von IBM beschreibt sechs Hauptdis-ziplinen der Software- Entwicklung. Die Anforderungsanalyse (Require-ments) nimmt dabei einen eigenen Punkt ein:• Geschäftsprozessmodellierung (Business Modeling)• Anforderungsanalyse (Requirements)• Analyse und Entwurf (Analysis & Design)• Implementierung (Implementation)• Test• Auslieferung (Deployment)106

In der Anforderungsanalyse wird genau beschrieben, welche Funktionen das System haben soll und was Kunden und Entwickler eine Orientie-rung bieten soll.107

Die Anforderungen der Nutzergruppen werden im sogenannten Require-ments Engineering durch verschiedene Methoden, wie Gespräche und Workshops, herausgearbeitet,108 dabei bringen „[s]chon wenige qualita-tive Interviews mit Benutzern [ ... ] die konkreten Bedürfnisse und Schwie-rigkeiten sowie deren Hintergründe und Zusammenhänge ans Licht.“109

106 Vgl. IBM (Hg.), Rational Uniied Processb, 1998, S. 10.107 Vgl. IBM (Hg.), Rational Uniied Processb, 1998, S. 11.108 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 30f.109 Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 31.

26

Anforderungen in der Software- EntwicklungNutzerorientierte Methoden der Software- Entwicklung

Aus den erforderlichen Funktionalitäten und Systemgrenzen werden sogenannte Use Cases erstellt, die genau beschreiben, wie das System Schritt für Schritt mit dem Anwender interagieren soll. Da die Anwender bei der Entwicklung direkt einbezogen werden, ist es wahrscheinlicher, dass die Umsetzung den Anforderungen der Anwender entspricht.110 Da in der agilen Software- Entwicklung in kleinen Schritten vorgegan-gen wird, kann die Software stets entsprechend überprüft und verfeinert werden.111

5.3 Nutzerorientierte Methoden der Software- Entwicklung

5.3.1 EinführungDie sich aus der stark nutzerorientierten Idee der modernen Software- Entwicklung ergebenden Vorteile können auch für das System der Masterarbeit im Dokumentationsbereich Fernsteuerung von Messgerä-ten genutzt werden. Als Orientierungsgrundlage wird die Übersicht von R und F ü in Abbildung 12 herangezogen.

Methode Zweck

Contextual Inquiry Analyse der Benutzer und des Einsatzumfelds des neuenSystems

Personas und Szenarien Modellieren der unterschiedlichen Benutzergruppen undder Anwendung aus Benutzersicht

Storyboards Kommunizieren ausgewählter Abläufe mit dem neuenSystem

UX Prototyping Entwickeln von Produktideen, Klären derAnforderungen, Konzipieren und Optimieren derBenutzerschnittstelle

Use Cases und UserStories

Funktionale Anforderungen in die Entwicklung tragen

Guidelines und Style-guides

Deinieren der Gestaltungsrichtlinien

Usability Testing Beurteilen des neuen Systems durch Benutzer

Fragebögen Sammeln aussagekräftiger Zahlen zur Analyse vonBenutzern und Kontext oder zur Beurteilung einesSystems oder Prototyps

Abb. 12: Übersicht nutzerorientierter Methoden112

110 Vgl. IBM (Hg.), Rational Uniied Processb, 1998, S. 11.111 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 26f.112 Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 46.

27


Die Guidelines und Styleguides werden nicht näher betrachtet, weil die einschlägigen Normen, welche die Masterarbeit betrefen, bereits in Kapitel 4.6 „Normative Grundlagen“ aufgeführt wurden. Auch Frage-

bögen werden nicht näher beschrieben, da sie als klassische Methode der empirischen Sozialforschung bei der Methodenauswahl für das Sys-tem ohnehin in Betracht gezogen werden. Ziel dieses Kapitels ist es aber die „klassischen“ Methoden durch nutzerorientierte Methoden der Software-Entwicklung zu ergänzen.

5.3.2 Contextual InquiryContextual Inquiry wurde von B und H im Hinblick auf fol-gende Fragestellungen entwickelt: Wie kommt man an die tatsächlichen Arbeitsstrukturen heran und muss sie nicht aus Marktbeschreibungen entnehmen? Wie indet die Details der Arbeitsweise heraus, die gewohn-heitsmäßig und daher schwer zu erfassen sind?113

Die Methode basiert auf dem Prinzip des Umfelds, welches W und W geprägt haben. Der grundsätzliche Ablauf der Methode ist simpel: Gehe dorthin, wo der Kunde arbeitet, beobachte ihn bei der Arbeit und rede mit ihm über seine Arbeit.114 Die „Erhebung im Umfeld der Kun-den“ gibt der Methode den Namen „Contextual Inquiry“.Nach B und H tritt der Interviewer dem Kunden gemäß eines partnerschaftlichen Verhältnisses gegenüber. Nach dem klassi-schen Interview-Beziehungsmodell hat der Interviewer zu viel Macht, immerhin ist der Kunde derjenige, der seine Arbeit kennt. Das klassische Meister-Lehrling-Modell würde wiederum dem Kunden zu viel Macht verleihen. Die vier Prinzipien des Contextual Inquiry modiizieren das Modell um bessere Daten zu erhalten: Kontext, Partnerschaft, Interpretation und Fokus. Damit geht die Rolle des Designers über die eines Lehrlings hin-aus. Er muss Muster in der Arbeitsweise erkennen und gezielt nachfra-gen, um die für ihn relevanten Informationen zu erlangen.115 Zudem hat der Designer die Möglichkeit im Kundenkontakt direktes Feedback für seine Ideen zu erhalten. Bei der Ausführung muss der Interviewer darauf achten, dass er dem Kunden Freiraum lässt, seine Arbeit zu zeigen und die Durchführung nicht in ein starres Frage-Antwort-Spiel mündet. Zudem muss der Inter-viewer aufpassen, sich selbst nicht in einen Expertenstatus zu erheben.

113 Vgl. Beyer, H.; Holtzblatt, K., Contextual design, 1998, S. 37.114 Vgl. Beyer, H.; Holtzblatt, K., Contextual design, 1998, S. 47.115 Vgl. Beyer, H.; Holtzblatt, K., Contextual design, 1998, S. 42f.

28


Er muss den Kunden am Anfang darauf hinweisen, dass er seine Arbeits-weise kennenlernen möchte. Darüber hinaus darf sich der Interviewer nicht zu sehr in eine Gastrolle versetzen lassen und muss ausreichend Fragen stellen. Oft sind mehrere Durchgänge nötig, um die Arbeitsweise der Beobachteten vollständig verstehen zu können. Die Befragten soll-ten möglichst verschiedene Bereiche abdecken, die Auswahl muss aber keinen repräsentativen Ansprüchen gerecht werden.116

5.3.3 Personas und SzenarienPersonas sind eine Methode, die auch in der Technischen Dokumenta-tion angewandt wird. Der Steckbrief mehrerer Personen der Zielgruppe wird dabei iktiv erstellt, um diese zu charakterisieren und dadurch zu veranschaulichen.117 Auch in der Software- Entwicklung wird die Methode angewandt, um sich die künftigen Benutzer der Software vorstellen zu können. Grundlage bilden beispielsweise vorhergehende Befragungen.118 Wie bei Personas ist bei Szenarien weniger die formale Korrektheit als die inhaltliche Korrektheit ausschlaggebend. Ein Szenario stellt beispiel-haft dar, wie ein Benutzer mit dem System arbeiten wird.119

5.3.4 StoryboardsWie in der Filmbranche visualisieren Storyboards in der Software- Entwicklung einen künftigen Ablauf. Gegenstand der Betrachtung ist aber nicht die Handlung eines Films, sondern die Anwendung der Software. Dabei wird die beispielhafte Anwendung der Software, das heißt ein Sze-nario, durch Bilder ergänzt. Das erleichtert beispielsweise Konzepte zu veranschaulichen, die schwierig in Worte zu fassen sind. Zudem sind Bilder oft leichter zu verstehen.120

5.3.5 UX PrototypingUX Prototyping setzt in einem frühen Stadium der Software- Entwicklung an. Ein Prototyp der Benutzerschnittstelle dient dazu, noch vor der Existenz einer ersten laufähigen Software die Schnittstelle mit knfti-gen Anwendern zu testen und so deren Anforderungen aufzudecken. Dadurch können deren Anmerkungen und Wünsche direkt in die weitere Entwicklung der Software einlieaen.121

Diese Methode ist im Hinblick auf das Forschungsziel für die Masterar-beit wenig geeignet.

116 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 48f.117 Vgl. Juhl, D., Technische Dokumentation, 2015, S. 8f.118 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 57-60.119 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 60-66.120 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 66-72.121 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 72-84.

29


5.3.6 Use Cases und User StoriesUser Stories werden als Planungshilfe bei der Software- Entwicklung ein-gesetzt. Sie thematisieren die Anforderungen aus Sicht der Anwender. User Stories sind aus Use Cases entstanden, einer Methode, die auch außerhalb der agilen Software- Entwicklung eingesetzt wird.122 User Stories bestehen aus drei Teilen: der schriftlichen Beschreibung der Story, Gesprächen über die Story und Akzeptanztests. Die schriftliche Beschreibung der Story dient als Hilfe bei der Planung. Die Details wie-derum werden in Gesprächen herausgearbeitet. Im Akzeptanztest zeigt sich, ob eine Story vollständig umgesetzt ist und alle von den Anwendern formulierten Akzeptanzkriterien erfüllt wurden.123 Des Weiteren sollte eine User Story die folgenden sechs Eigenschaf-ten haben: unabhängig, verhandelbar, werthaltig für User oder Kunden, schätzbar, klein und testbar.124

Vor der Erstellung der Stories müssen verschiedene Nutzerrollen der künftigen Software festgelegt werden, denn „bei vielen Projekten wer-den die Stories so geschrieben, als gäbe es nur einen Nutzertyp“125. Um Informationen für die User Stories zu bekommen, können verschiedene Methoden angewandt werden, beispielsweise Interviews mit Usern, Fra-gebögen, Beobachtungen und Story-Workshops126.

5.3.7 Usability-TestEine weitere nutzerorientierte Methode ist der Usability-Test. Ein Usability-Test läuft folgendermaßen ab: Die Tests werden in speziellen Usability-Labs durchgeführt. Sie bestehen aus einem Testraum, in wel-chem die Testperson mit Hilfe einer Standardaufgabe die Software tes-tet und dabei geilmt wird. Die Testperson kann den Test unterbrechen beziehungsweise abbrechen und soll währenddessen „laut denken“. Die Testleiter und Usability-Experten sitzen hinter einer Glasscheibe, um den Probanden nicht zu beeinlussen. Sie protokollieren Aufälligkeiten in der Vorgehensweise des Beobachteten. Anschließend besprechen sie den Verlauf des Tests mit dem Probanden. Zudem hat der Proband die Mög-lichkeit, die Aufgabe frei zu kommentieren.127

Danach können die Usability-Experten aus der beobachteten Vorgehens-weise und den Schwierigkeiten der Nutzer sowie deren Äußerungen und gegebenenfalls Messungen, z. B. der Dauer bis zur Lösung der Aufgabe, Verbesserungspotenzial aufzeigen.128

122 Vgl. Rüping, A., Dokumentation in agilen Projekten, 2013, S. 51.123 Vgl. Cohn, M., User Stories, 2010, S. 26.124 Vgl. Cohn, M., User Stories, 2010, S. 39.125 Cohn, M., User Stories, 2010, S. 51.126 Vgl. Cohn, M., User Stories, 2010, S. 65.127 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 109f.128 Vgl. Sarodnick, F; Brau, H, Methoden der Usability Evaluation, 2011, S. 163.

31

ForschungsstandDer Stand der Technik

6 Forschungsstand

6.1 Der Stand der Technik

In Kapitel 3.5 „Digitale Messsysteme“ wurde bereits der Stand der Mes-stechnik mit dem Trend zu digitalen Messsystemen beschrieben. Mit der Automatisierung von Messabläufen wird auch das Thema Fernsteuerung immer wichtiger. Deren Dokumentation kann, wie in Kapitel 4.1 „Einführung“ erläutert, als Dokumentation von Programmiersprachen in den Bereich Software- Dokumentation eingeordnet werden.

Bereits 2009, mit Erscheinen der Norm ISO/IEC 26514:2008(E) S - S E - R D

D U D , zog G ü die Bilanz, dass Software- Dokumentation an Bedeutung gewinnt, da Normen den Stand der Technik verkörpern.129

Zu diesem Zeitpunkt hatte G ü bereits zwei Aulagen von S - D : G - P - Lö ver-öfentlicht. 2013 erschien die dritte und derzeit aktuelle Aulage. G ü -

behandelt in ihrem Werk die externe Anwenderdokumentation von Softwareprodukten.130

Auch Bö und R widmen sich in K ü K - I ü in einem Kapitel der Software-

Dokumentation.131 Zudem thematisieren Rü sowie R und F ü Software- Dokumentation, jedoch eher aus Prozesssicht der Software- Entwicklung.

6.2 Forschungslücke

Neben den aufgefhrten Werken indet sich kaum Literatur, die einem Technischen Redakteur mit der Aufgabe eine externe Software- Dokumentation zu erstellen eine Hilfestellung bietet. Beispielsweise geht J in seinem Standardwerk T D nur sehr kurz auf Software- Dokumentation ein.132

Noch weniger Literatur fr Technische Redakteure indet sich zur Doku-mentation von Programmiersprachen. Die vorhandenen Werke zur

129 Vgl. Grünwied, G., Softwaredokumentation gewinnt an Bedeutung, 2009.130 Vgl. Grünwied, G., Software- Dokumentation, 2013, Vorwort.131 Vgl. Böcker, M.; Robers, R., Kundendokumentationen, 2015, S.185f.132 Juhl, D., Technische Dokumentation, 2015, S. 117f. u. S. 309f.

32

ForschungsstandForschungsfragen

Software- Dokumentation behandeln das Thema nur im Ansatz, wie G ü in S - D .133 Auch die Normenreihe ISO/IEC 26514:2008(E) S S E - R -

D D U D richtet sich primär nur an die Software-Benutzerdokumentation. Der Absatz zu Programmiersprachen umfasst weniger als eine halbe Seite.134

Im Internet gibt es zahlreiche Plattformen, die Programmiersprachen dokumentieren und das Angebot immer weiter ausbauen, wie S O 135. Ein Standardwerk für den Technischen Redakteur, wie er Programmiersprachen am besten dokumentiert, existiert aber nicht. Dabei sieht sich der Technische Redakteur im Bereich Dokumentation von Programmiersprachen einigen Besonderheiten bezüglich der Anwen-deranforderungen gegenüber. Verglichen mit der normalen Dokumenta-tion ist beispielsweise die Korrektheit ausschlaggebender, da bereits ein Tippfehler dazu führt, dass der Befehl nicht mehr funktioniert. Zudem ist die Programmierung weniger intuitiv, da der Anwender die Befehle ent-weder kennen oder nachschlagen muss und die Funktionen nicht einfach ausprobieren kann. Daher ist auch die Vollständigkeit der Dokumentation entscheidend.Genau diesen Herausforderungen sieht sich der Technische Redakteur bei der Erstellung der Dokumentation zur Fernsteuerung von Messgerä-ten gegenüber. Bei der Bewältigung steht ihm aktuell keine Literatur oder Anleitung zur Verfügung.

6.3 Forschungsfragen

An diese Forschungslücke der Dokumentation zur Fernsteuerung von Messgeräten setzt die Masterarbeit mit diesen Forschungsfragen an:

Wie ermittle ich Anwenderanforderungen für den speziellen Doku-mentationsbereich Fernsteuerung von Messgeräten auf eiziente Art, bewerte daraufhin die Qualität der Dokumentation und leite dar-aus Verbesserungspotenzial ab?

133 Vgl. Grünwied, G., Software- Dokumentation, 2013, S. 1.134 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc. S. 54.135 Vgl. Stckler, M., Stack Overlow: Dokumentationen ausbauen, 2016.

33

ForschungsstandForschungsziel

1Wie ermittle ich die Anwender-anforderungen auf effiziente Art?

Dreistufiges Systemfür den Dokumentationsbereich Fernsteuerung von Messgerten

2Wie bewerte ich daraufhin die Qualität der Dokumentation?

3Wie leite ich daraus Verbesserungs-potenzial ab?

Datenerhebung Datenauswertung

?

Stufe

Verbesserungs-potenzial

??

?? ?

? ? ?

Abb. 13: Veranschaulichung der Forschungsfragen

6.4 Forschungsziel

Das Forschungsziel der Masterarbeit ist, die Forschungsfragen durch die Entwicklung eines dreistuigen, aufeinander aufbauenden Systems zu beantworten und abschlieaend Verbesserungspotenzial zu identiizieren.

Mit Hilfe dieses Systems soll der Technische Redakteur im Dokumenta-tionsbereich Fernsteuerung von Messgeräten die Anforderungen seiner Anwender ermitteln, daraufhin die Qualität der Dokumentation bewerten und daraus Verbesserungspotenzial ableiten können.

Zur Entwicklung des Systems werden Aspekte der Benutzerdokumenta-tion von Anwendungssoftware auf die Dokumentation von Programmier-sprachen transferiert.Die erste Stufe dient dazu herauszuinden, was sich die Anwender in Hinblick auf die Kategorien Struktur, Inhalt und Form wünschen. Darauf-hin wird in der zweiten Stufe auf den ermittelten Anwenderanforderun-gen aufbauend die Qualität der bestehenden Dokumentationen eines

34

ForschungsstandForschungsziel

Beispielgeräts bewertet. Abschließend wird in der dritten Stufe Verbes-serungspotenzial identiiziert. Hierbei wird der Blick auch auf die Zusam-menarbeit zwischen Technischem Redakteur und Software-Entwickler gerichtet.136 Neben den klassischen sozialwissenschaftlichen Methoden werden Methoden der Software- Entwicklung in Betracht gezogen, um ein möglichst diferenziertes Bild der Anwenderanforderungen zu erlangen.

Es muss dargelegt werden, dass insbesondere Stufe 2 und 3 des Sys-tems nicht konkret beschrieben werden können, da sie auf Stufe 1 auf-bauen und daher stark von den ermittelten Anwenderanforderungen abhängen. Zudem ist davon auszugehen, dass sich die Ressourcen und Kapazitäten der jeweiligen Dokumentationsabteilung, z. B. hinsichtlich der Teamstärke unterscheiden und das System unterschiedlich intensiv umsetzen können, was es ebenso erschwert eine konkrete Anleitung zu verfassen.

In den folgenden drei Kapiteln wird jeweils die Entwicklung einer Stufe des Systems für den Dokumentationsbereich Fernsteuerung von Mess-geräten beschrieben. In den Kapiteln werden folgende Forschungsfragen beantwortet:

Kapitel 7 „Ermittlung der Anwenderanforderungen“ Wie ermittle ich Anwenderanforderungen auf eiziente Art?

Kapitel 8 „Bewertung der Qualität der Dokumentation“Wie bewerte ich die Qualitt der Dokumentation im Hinblick auf die Anwenderanforderungen?

Kapitel 9 „Identiikation von Verbesserungspotenzial“ Wie leite ich daraus Verbesserungspotenzial ab?

Das System wird nach den fünf Hauptphasen von D entwi-ckelt. Denn „vielleicht ist es in der empirischen Sozialforschung wie beim Schachspiel: Wer noch nicht sicher das Terrain beherrscht, tut gut daran, gewisse Standardregeln zu befolgen.“137

136 Vgl. Grünwied, G., Kurz notiert, Software- Dokumentation, 2017, S. 25.137 Diekmann, A., Empirische Sozialforschung, 2016, S. 188.

35

Ermittlung der AnwenderanforderungenEinführung

7 Ermittlung der Anwenderanforderungen

7.1 Einführung

Die erste Stufe des Systems, die Ermittlung der Anwenderanforderungen (EdA), beantwortet die Forschungsfrage:

Wie ermittle ich die Anwenderanforderungen auf eiziente Art?

Das Forschungsproblem leitet sich aus der Forschungsfrage ab und äußert sich darin, dass der Technische Redakteur kein umfassendes und durch Untersuchungen fundiertes Bild der Anforderungen seiner Anwender hat. Auch in der Literatur hat der Redakteur keine empirischen Ergebnisse zu seinem speziellen Dokumentationsbereich Fernsteuerung von Messgeräten gefunden. Ihm ist aber bewusst, dass seine Kollegen sowie andere Mitarbeiter im Laufe ihrer Zeit beim Unternehmen Eindrü-cke von den Anforderungen der Anwender bekommen haben.

Um daraus einen situationsbezogenen Ansatzpunkt schafen zu können, wird die Stufe in eine Vorstudie für die indirekten Informationen und in eine Hauptstudie für den direkten Anwenderkontakt geteilt. „Die explora-tive Phase dient dann der Gewinnung von Hypothesen, die in der Haupt-studie genauer geprüft und elaboriert werden können.“138

Die Entwicklung der ersten Stufe des Systems folgt dabei dem Verständ-nis von R R sowie C , die das Ermitteln von Anforderungen mit dem Fischfang vergleichen. So wie ein Fischer ein Netz durchs Wasser zieht, muss der Technische Redakteur ein Netz durch den Anwenderpool ziehen, um möglichst jede Anforderung zu „fan-gen“. Dabei muss er systematisch vorgehen. Mit ein bisschen Erfahrung und guten Techniken weia er, wo er ischen muss, um die Fische zu bekommen, die er möchte. Auch der Technische Redakteur benötigt gute und verschiedene Methoden für seinen Fischfang.139

C hat den Vergleich weitergeführt. Bei jedem Fischzug können mit engmaschigeren Netzen kleinere Anforderungen geischt werden. Dabei werden auch andere Dinge als Fische ins Netz gehen. Zudem können Anforderungen, wie Fische, sterben.140

138 Diekmann, A., Empirische Sozialforschung, 2016, S. 34.139 Vgl. Robertson, S., Robertson, J., Requirements process, 2013, S. 87f.140 Vgl. Cohn, M., User Stories, 2010, S. 63f.

36

Ermittlung der AnwenderanforderungenTheoretische Vorüberlegungen der Erhebung

Auch R hat sich mit Anforderungen beschäftigt. R hat in U -ä A in der Zeitschrift T K

das bereits erwähnte Requirements Engineering auf die Technische Redaktion transferiert und 15 Erfolgsfaktoren für den Umgang mit Anforderungen erstellt.141 Da der Artikel am 19. Mai 2017 und nach Fertigstellung des ersten Teils der Masterarbeit sowie dessen Test an Rohde & Schwarz erschienen ist, konnte er nicht von Anfang an betrach-tet werden. Er wurde aber fr die diferenzierte Betrachtung der ersten Stufe des Systems in Kapitel 12.1 „Ermittlung der Anwenderanforderun-gen“ herangezogen.

7.2 Theoretische Vorüberlegungen der Erhebung

7.2.1 Konstruktion des ErhebungsinstrumentsDie Formulierung des Forschungsproblems, die die erste Phase nach D darstellt, wurde in Kapitel 6.3 „Forschungsfragen“ bereits behandelt. Ebenso wurde in Kapitel 2.4 „Anforderung beziehungsweise Anwenderanforderung“ bereits der Begrif Anwenderanforderungen dei-niert, was essentiell ist, um diese ermitteln zu können.Anschließend muss mindestens eine Variable als Gegenstand der Unter-suchung festgelegt werden. Die Variable Anforderung bezeichnet eine Merkmalsdimension von dem Merkmalsträger Anwender. Eine Varia-ble muss mindestens zwei Ausprägungen haben, diese sind aber, wie die Bezeichnung der Variable selbst, abhängig von der Deinition.142 Bei der Deinition der Ausprägungen beziehungsweise der Kategorien muss beachtet werden, dass „[j]ede denkbare Beobachtung bezüglich einer Variablen [ ... ] eindeutig einer Kategorie zugewiesen werden können [sollte].Um die Voraussetzungen zu erfüllen, werden für die Variable Anforde-rung drei Ausprägungen deiniert: Struktur, Inhalt und Form. Die Unter-teilung wurde von der ISO/IEC 26514:2008(E) S S E - R D D U D übernomme .143

Unter Struktur wird in der Norm die Art und Weise verstanden, wie die Dokumentation unterteilt ist und in welcher Reihenfolge die Teile stehen. Beispielsweise kann die Dokumentation in einem einzigen Dokumentfestgehalten sein oder in mehreren Teilen.144

141 Vgl. Ried, T., Erfolgreicher Umgang mit Anforderungen, 2017, S. 35f.142 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 117.143 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. ix.144 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 41.

37


Der Inhalt wird durch seinen Zweck deiniert. Er dient entweder als Anlei-tung und erklärt, wie die Software verwendet werden muss, oder als Referenz, das heißt, wie erlernte Inhalte wieder ins Gedächtnis gerufen werden können. Dabei kann die Anleitung entweder informations- oder aufgabenorientiert sein. Die Referenz kann kontextsensitiv und in die Software eingebettet sein.145

Unter Format wird einerseits das Medium der Dokumentation verstanden. Die Norm unterscheidet zwischen Print- und OnScreen- Dokumentation. Andererseits gehören Stil, Typograie sowie graphische Elemente zum Format.146

Anforderung

Variable bzw.Merkmal(sdimension)

Anwender

Merkmalsträger

Inhalt

Kategorie bzw.Merkmalsausprägung

Form


Struktur


Abb. 14: Merkmalsträger, Variable, Kategorien

Anschließend muss die Variable einer Messung zugänglich gemacht werden, was als Operationalisierung bezeichnet wird. Dabei muss „eine Menge hinreichend genauer Anweisungen, nach denen Untersuchungs-einheiten den Kategorien einer Variablen zugewiesen werden“147, deiniert werden. Die Zuweisung der Variable Anforderung in Kategorien wurde mit der Beschreibung der Kategorien Struktur, Inhalt und Form bereits erfüllt. „Die Operationalisierung von Variablen setzt nicht unbedingt die Verwendung von Zahlen oder numerischen Operationen voraus. Dies ist

145 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 47.146 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 59.147 Diekmann, A., Empirische Sozialforschung, 2016, S. 239.

38


erst bei der Messung, Skalierung und Indexbildung der Fall.“148

Es muss beachtet werden, dass im Fall der Anwenderanforderungen das „Prinzip der Messung nicht direkt beobachtbarer Eigenschaften“149 greift. Denn die Anforderungen der Anwender sind ein theoretisches Konstrukt. „Diese theoretische Variable muss durch Indikatoren indirekt gemessen werden.“150 Durch eine Messung mit verschiedenen Indikatoren wird die Qualität der Messung verbessert, da Messfehler leicht identiiziert wer-den können.151 Das hilft, folgendem Anspruch gerecht zu werden: „Mes-sungen sollen möglichst objektiv, zuverlässig und gültig sein.“152

Die Häuigkeit einzelner Anwenderanforderungen an sich und die Häu-igkeit der Nennung der Anforderungen innerhalb der Kategorien Struk-tur, Inhalt und Form kann mit einer Absolutskala gemessen werden.153 Um die Messung auf mehreren Indikatoren basieren zu lassen, werden neben den Anwendern selbst auch Mitarbeiter im Unternehmen befragt, welche mit Anwendern arbeiten. Zudem werden die Anwender beobach-tet. Neben Befragungsindikatoren kommen Beobachtungsindikatoren ins Spiel, aus welchen gemeinsam mit der Messskala das Erhebungsinstru-ment im Hinblick auf die Methode der Erhebung später konstruiert wird.154

7.2.2 Festlegung der UntersuchungsformDa es sich bei der Variable Anforderung um ein Kollektivmerkmal handelt, ist die Ebene der Untersuchung das Kollektiv aller Anwender. Der Tech-nische Redakteur befragt die Anwender in einer kurzen Zeitspanne, was einer Datenerhebung in Form eines Querschnittdesigns entspricht.155

Das Untersuchungsdesign der Hauptstudie soll es ermöglichen, die ver-schiedenen Anwendergruppen, die in der Vorstudie genannt wurden, zu überprüfen. Da eine Einordnung der Anwender in die Gruppen nur nachträglich aufgrund ihrer eigenen Einschätzungen möglich ist, z. B. Kenntnisstand der Geräte und Programmierkenntnisse, wird ein Ex-post-

facto Design herangezogen. Die Anwender werden nicht zufällig auf die Gruppen aufgeteilt, sondern gemäß ihrer Anwendergruppe. Aus diesem Grund kann kein experimentelles Design durchgeführt werden, was für die Prüfung der Hypothesen ideal wäre.156

148 Diekmann, A., Empirische Sozialforschung, 2016, S. 239.149 Diekmann, A., Empirische Sozialforschung, 2016, S. 231.150 Diekmann, A., Empirische Sozialforschung, 2016, S. 231.151 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 231.152 Diekmann, A., Empirische Sozialforschung, 2016, S. 247.153 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 290.154 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 194.155 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 304f.156 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 329f.

39

Ermittlung der AnwenderanforderungenMethodenauswahl für Datenerhebung und -auswertung

7.2.3 StichprobenverfahrenIn der Vorstudie bilden alle Mitarbeiter im Unternehmen, die bei ihrer Arbeit mit Anwendern im Kontakt sind, die Grundgesamtheit. Diese zu erfassen kann für den Technischen Redakteur je nach Größe des Unter-nehmens schwierig werden. Daher können die Probanden nicht durch eine Zufallsauswahl gezogen werden. Eine Alternative, welche sich mit dem Forschungsziel in Einklang bringen lässt, ist die Bewusste Auswahl. Aus der bereits deinierten Grundgesamtheit kann mit bewussten Ent-scheidungskriterien, eine Stichprobe gezogen werden.157 Es ist sinnvoll sowohl fachliche als auch organisatorische Kriterien zu beachten. Von der fachlichen Seite her müssen Personen ausgewählt werden, die durch ihre Tätigkeit im Unternehmen seit Längerem im Kontakt mit den Anwendern stehen. Zudem ist es wichtig, dass sich die Anwender für die Befragung bereit erklären und zum geplanten Zeitpunkt der Erhebung anwesend sind.

Die Grundgesamtheit der Hauptstudie sind alle Anwender, welche die Dokumentation zur Fernsteuerung von Messgeräten benutzen. Auch in der Hauptstudie ist eine Zufallsauswahl für den Technischen Redakteur nur schwierig durchführbar. Er würde exakte Zahlen benötigen, die in vielen Fällen nicht vorliegen werden. Das Unternehmen müsste expli-zit erheben, wie viele der verkauften Messgeräte ferngesteuert werden. Zudem steht in der Produktion oft nur ein kleines Team hinter vielen Messgeräten der gleichen Reihe und steuert sie von zentraler Stelle aus fern, was die Angabe einer Zahl der Anwender noch weiter erschwert. Deswegen muss auf die Bewusste Auswahl zurckgegrifen werden. Ein Kriterium für die Auswahl muss die in der Vorstudie entwickelte These zu den Anwendergruppen sein. Daher müssen aus jeder Anwendergruppe möglichst mehrere Anwender befragt werden. Zudem sollten organisato-rische Aspekte einlieaen, wie die generelle Bereitschaft zur Teilnahme und eine mögliche Anwesenheit vor Ort während der Erhebung.

7.3 Methodenauswahl für Datenerhebung und -auswertung

7.3.1 EinführungUm das Forschungsproblem zu lösen, „sollte in der Regel nicht die Methode das Problem, sondern umgekehrt das Problem die Auswahl der

157 Vgl. Stein, P., Forschungsdesign, 2014, S. 149.

40


Methode bestimmen“.158 Das ist nur möglich, wenn bei der Entwicklung einer Erhebung der Blick auf alle gebräuchlichen Methoden richtet.159 „Die Gesamtheit dieser Methoden stellt das Inventar der <Werkzeug-kiste> der empirischen Sozialforschung dar.“160

D nennt folgende vier Erhebungsmethoden: Befragung, Beob-

achtung, Inhaltsanalyse und nichtreaktive Erhebungsmethoden. Die zu trefende Entscheidung bezglich der Methode hängt „(a) vom For-schungsziel ab, (b) von den Forschungsressourcen (Zeit, Personal, Sachmittel) und (c) von der eigenen Einschätzung der mit Blick auf das Forschungsziel bestgeeigneten Methode.“161 In der Masterarbeit werden die angewandten Methoden zum Teil ange-passt. Denn „[für] eine konkrete Fragestellung können, ja sollen sie modiiziert, an die jeweiligen Bedingungen und Bedrfnisse angepasst werden. Das ist ja gerade eine der Stärken qualitativer Forschung, dass durch diese Flexibilität die Ergebnisse gegenstandsadäquater werden können.“162 Die Modiikation wird aber stets erläutert und begrndet.Für die Stufe zur Ermittlung der Anwenderanforderungen wurden ver-schiedene Methoden ausgewählt, die alle in anderer Form auf den For-schungsgegenstand zugreifen. Das gleicht Schwächen aus und ermög-licht ein höheres Maß an der Validität der Ergebnisse, das heißt, der Gültigkeit. Das Vorgehen wird als Methodentriangulation bezeichnet.163 Neben der Validität wurden die beiden anderen Gütekriterien der Mes-sung befolgt, die Objektivität und die Reliabilität. Um dem Anspruch der Objektivität gerecht zu werden, versucht die Stufe konkrete Handlungs-anweisungen zu geben, damit „die Ergebnisse unabhängig sind von der jeweiligen Person, die das Messinstrument anwendet.“164 Das hilft repro-duzierbare Messergebnisse zu liefern und dem Anspruch der Reliabilität Genüge zu tun.165

7.3.2 Vorstudie, Datenerhebung: Problemzentriertes InterviewIn der explorativen Untersuchung, der Vorstudie, werden weitgehend unbekannte Anforderungen wissenschaftlich ermittelt. Dabei wird aber „auch die Exploration nicht an eine Tabula-rasa-Situation anknüpfen. Irgendeine Art von Vorwissen, Vermutungen und vage Hypothesen wer-den den Beobachtungen immer vorangehen und die Aufmerksamkeit in eine bestimme Richtung lenken.“166

Wie bereits angesprochen, bilden bei der Vorstudie Mitarbeiter im

158 Diekmann, A., Empirische Sozialforschung, 2016, S. 20.159 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 20.160 Diekmann, A., Empirische Sozialforschung, 2016, S. 18.161 Diekmann, A., Empirische Sozialforschung, 2016, S. 191f.162 Mayring, P., Einführung in die qualitative Sozialforschung, 2016, S. 65.163 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 141f.164 Diekmann, A., Empirische Sozialforschung, 2016, S. 249.165 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 250.166 Diekmann, A., Empirische Sozialforschung, 2016, S. 34.

41


Unternehmen, die bei ihrer Arbeit mit Anwendern im Kontakt sind, die Grundgesamtheit. Da davon auszugehen ist, dass die Mitarbeiter am glei-chen Ort wie der Technische Redakteur arbeiten, liegt eine Face-to-Face-

Befragung nahe, denn „[s]ubjektive Bedeutungen lassen sich nur schwer aus Beobachtungen ableiten. Man muss die Subjekte selbst zur Sprache kommen lassen [ ... ].“167 Befragungen werden bei explorativen Untersu-chungen angewandt. Insbesondere qualitative Methoden der Befragung haben unter anderem das Ziel der „[ ... ] Gewinnung von Hypothesen am empirischen Material“168.Im Gegensatz dazu ist „die Konstruktion standardisierter Interviews nur dann zweckmäßig, wenn ein erhebliches Vorwissen über die zu erfor-schende Situation existiert.“169 Zudem besteht bei einem standardisier-ten Interview die Gefahr, dass „soziale Phänomene, die außerhalb des Fragerasters und der vorgegeben Antwortkategorien liegen [ ... ] aus dem Blickfeld der Forschung ausgeblendet [würden]“.170

Für die Auswahl einer qualitativen Methode spricht zudem, dass kleinere Stichproben üblich sind und es dadurch möglich ist „stärker in die Tiefe zu gehen, die interviewten Personen ausführlicher zu Wort kommen zu las-sen und das gewonnene Material intensiver auszuwerten und nicht nur auf statische Kennwerte zu verdichten.“171 Die qualitative Methode muss ofen sein, um den explorativen Charakter der Vorstudie zu untersttzen.L führt drei Formen qualitativer Interviews auf, die diese Prämis-sen erfüllen: das Narrative Interview, das Episodische Interview und das Problemzentrierte Interview.172 Die Ofenheit ist beim Narrativen Interview am größten. Der Befragte würde lediglich einmalig aufgefordert, etwas über seine Erfahrungen bezüglich Anwenderanforderungen zu erzählen. Dafür müsste der Befragte die Fähigkeit des freien Erzählens besitzen, wovon nicht generell ausgegangen werden kann. Das Episodische und das Problemzentrierte Interview ähneln sich stark. Da beim Problemzen-trieren Interview die Kommunikation zielorientierter ist, fällt die Wahl auf diese Methode für die Vorstudie.173

Im Problemzentrierten Interview wird die Sichtweise von Individuen bezüglich eines gesellschaftlichen Themas untersucht. Ziel des Inter-views ist die Generierung einer Theorie174, „zentrales Prinzip ist dabei das Erzählen (Narration).“175

Die Methode muss in der Masterarbeit im Hinblick auf das Forschungsziel modiiziert werden. Das Problemzentrierte Interview kann nicht bereits in

167 Mayring, P., Einführung in die qualitative Sozialforschung, 2016, S. 66.168 Diekmann, A., Empirische Sozialforschung, 2016, S. 532.169 Diekmann, A., Empirische Sozialforschung, 2016, S. 438.170 Diekmann, A., Empirische Sozialforschung, 2016, S. 531.171 Diekmann, A., Empirische Sozialforschung, 2016, S. 531.172 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 350.173 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 350.174 Vgl. Misoch, S., Qualitative Interviews, 2015, S.71.175 Misoch, S., Qualitative Interviews, 2015, S.71.

42


der Vorstudie, wie von W vorgeschlagen, mit anderen Methoden kombiniert werden, weil das die zeitlich begrenzten Forschungsressour-cen des Technischen Redakteurs übersteigen würde. Die Methode wird als Einzelmethode angewandt und folgt damit L Darstellung.176

Zudem setzt das Problemzentrierte Interview eigentlich an gesellschaftli-

che Problemstellungen an.177 Die Ermittlung der Anforderungen im Doku-mentationsbereich Fernsteuerung von Messgeräten ist kein Problem, welches die gesamte Gesellschaft betrift. Die Methode wird aber den-noch ausgewählt, da insbesondere ihre Prozessorientierung zielführend ist, die eine lexible Anpassung des Leitfadens vorsieht.178

Die Mitarbeiter im Unternehmen erfahren durch die Auswahl für das Interview „einen Expertenstatus [ ... ], was [ihnen] das Antworten sehr erleichtert.“179 An dieser Stelle muss begründet werden, warum nicht das Experteninterview ausgewählt wurde, welches ebenso leitfadengestützt durchgeführt werden kann. In der Literatur ist ein Experte unterschiedlich deiniert. Neben der Komponente bezüglich seines Fachwissens, was auch im Rahmen der Masterarbeit interessant ist, ist oft eine zweite Komponente enthalten: „Wir befragen Experten, weil ihre Handlungsorientierungen, ihr Wissen und ihre Einschätzungen die Handlungsbedingungen anderer Akteure in entscheidender Weise (mit-) strukturieren.“180 Auch M und N gehen auf die Auswirkungen der Handlungen der Experten auf ihre Umwelt ein: „Dies bedeutet, dass der Experte über die Möglichkeit verfügt, in einem bestimmten organisationalen Funktionskontext seine Handlungsorientierungen, Relevanzen etc. durchzusetzen.“181

Da diese Komponente nicht ausschlaggebend ist und die Vorgehens-weise im Problemzentrierten Interview, insbesondere die Allgemeine

Sondierung, die Speziische Sondierung und die anschließenden direkten Fragen sowie die Prozessorientierung im Hinblick auf das Forschungs-ziel geeigneter sind, wurde das Problemzentrierte Interview ausgewählt.

7.3.3 Hauptstudie, Datenerhebung: Contextual InquiryIn der Hauptstudie stehen die Anwender selbst im Fokus. Sie dienen als direkte Quelle um ihre Anforderungen im Dokumentationsbereich Fern-steuerung von Messgeräten zu ermitteln und die Thesen der Vorstudie zu überprüfen, was „eine der vorrangigen Aufgaben wissenschaftlicher Sozialforschung ist“182.

176 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 332f.177 Vgl. Mayring, P., Einführung in die qualitative Sozialforschung, 2016, S. 68.178 Vgl. Misoch, S., Qualitative Interviews, 2015, 72.179 Lamnek, S., Qualitative Sozialforschung, 2010, S. 354.180 Bogner, A.; Littig, B.; Menz, W., Interviews mit Experten, 2014, S. 13.181 In Lamnek, S., Qualitative Sozialforschung, 2010, S. 658.182 Diekmann, A., Empirische Sozialforschung, 2016, S. 37.

43


Aufgrund des Forschungsgegenstandes kommen lediglich die Methoden Befragung und Beobachtung in Frage. Auch die ISO/IEC 26514:2008(E)S S E - R D -

D U D fordert, über Befra-gungen, Beobachtungen und Aufnahmen Informationen zu sammeln, was die Anwender tun.183 Eine Kombination von Befragung und Beob-achtung bietet die aus der Software- Entwicklung stammende nutzenori-entierte Methode Contextual Inquiry, welche in Kapitel 5.3.2 „Contextual Inquiry“ näher beschrieben wurde.Die Befragung im gewohnten Umfeld der Anwender kommt dem For-schungsziel entgegen, da bei einer Befragung der Anwender außer-halb ihres gewohnten Umfeldes davon auszugehen ist, „dass [ ... ][sie] Wissen, das sie in einer bestimmten Situation anwenden, nicht einfach abrufen können.“184 Zudem ermöglicht die „Kombination von Beobach-tung und Befragung [ ... ] einerseits, das wirkliche Geschehen im Detail zu erfassen, und andererseits, die Gründe und Zusammenhänge dahinter zu durchleuchten.“185 Durch die teilnehmende Beobachtung erreicht „[ ... ] der Forscher eine größtmögliche Nähe zu seinem Gegenstand [ ... ].“186 Ein weiterer Vorteil ist, dass der Technische Redakteur die Methode durchführen kann, ohne dem Anwender seine Ergebnisse der Vorstu-die ofenlegen zu mssen. Des Weiteren kann die Durchfhrung der Methode den Forschungsressourcen des Technischen Redakteurs ange-passt werden.187

Wegen der beschriebenen Vorteile wurde Contextual Inquiry ausgewählt.

Die Methode wird in der Masterarbeit in einer modiizierten Form ange-wandt. In der Software- Entwicklung wird der Teilnehmer bei seiner alltäg-lichen Arbeit betrachtet. Bezüglich der Dokumentation zur Fernsteuerung von Messgeräten ist aber davon auszugehen, dass der Anwender die Dokumentation nicht ständig verwendet. Es ist wenig zielführend, wenn der Technische Redakteur auf unbestimmte Zeit den Anwender beob-achtet und dieser die Dokumentation währenddessen möglicherweise gar nicht benötigt. Daher muss der Technische Redakteur den Anwender aufordern ihm zu zeigen, wie er typischerweise mit der Dokumentation zur Fernsteuerung von Messgeräten arbeitet. Auch wenn es sich dabei um eine konstruierte Situation handelt, kann der Technische Redakteur den Anwender beobachten, nachfragen und Schwachstellen diskutieren.

183 ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 28.184 Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 47.185 Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 47.186 Mayring, P., Einführung in die qualitative Sozialforschung, 2016, S. 81.187 Vgl. Richter, M.; Flckiger, M., Usability und UX kompakt, 2016, S. 50f.

44


Währenddessen muss der Technische Redakteur darauf achten, dass gemäß der Verzerrung durch selektive Wahrnehmung „vorrangig Erschei-nungen, die die Hypothese bestätigen“188, wahrgenommen werden. Ein weiteres Problem liegt in der (Fehl-)Interpretation des Beobachteten.189 Zudem ist es eine Herausforderung für den Technischen Redakteur bei der Flle von Eindrcken die wichtigen Informationen herauszuiltern.190

7.3.4 Hauptstudie, Datenerhebung: Usability-TestEine weitere nutzerorientierte Methode mit der Anforderungen im Doku-mentationsbereich Fernsteuerung von Messgeräten ermittelt und die Thesen der Vorstudie überprüft werden können, ist der Usability-Test. Die Methode wurde bereits in Kapitel 5.3.7 „Usability-Test“ beschrie-ben. In Ergänzung zum Contextual Inquiry kann sie weitere Anfor-derungen aufzeigen. Zudem könnte ein Usability-Test Aufschluss zu den verschiedenen Anwendergruppen liefern. Da zudem gemäß der ISO/IEC 26514:2008(E) S S E - R -

D D U D Anwendertests am besten geeignet sind um zu überprüfen, ob die Infor-mation in der Dokumentation das ist, was die Anwender wollen,191 wurde der Usability-Test für die Hauptstudie ausgewählt.Nach R und F ü genügen fünf bis sieben Testpersonen in der Software- Entwicklung, „um die wichtigsten Anwendungsszenarien einer Applikation anhand eines Prototyps zu prüfen und gezielte Ver-besserungsmaßnahmen einzuleiten.“192 Da bei der Durchführung der Methode im Dokumentationsbereich Fernsteuerung von Messgeräten ähnliche Ziele bestehen, wird diese Richtlinie an Testpersonen übernom-men. Auch in diesem Bereich ist davon auszugehen, dass „wenn zwei oder drei Testpersonen an der derselben Stelle der Anwendung Mühe bekun-den, [ ... ] ein Stolperstein vorliegt.“193 Daraus ließe sich eine Anforderung der Anwender ableiten. Diese Vorgehensweise entspricht einer Modii-kation der Methode. Die eigentlichen Ergebnisse der Tests interessieren nur im Hinblick auf die Überprüfung zur These der Anwendergruppen.

7.3.5 Hauptstudie, Datenerhebung: Standardisiertes InterviewUm die Anforderungen aus der Vorstudie überprüfen zu können, wurde zudem ein standardisiertes Interview mit dem Anwender ausge-wählt. Darin werden allen Anforderungen aus der Vorstudie mit einer

188 Diekmann, A., Empirische Sozialforschung, 2016, S. 550.189 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 550f.190 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 55.191 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 39.192 Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 105.193 Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 111.

45


Ordinalskala abgefragt, die weder im Contextual Inquiry noch im Usabili-ty-Test der Hauptstudie genannt wurden.

7.3.6 Hauptstudie, Datenerhebung: Abfolge der MethodenDa mehrere Erhebungsmethoden für die Hauptstudie ausgewählt wur-den, muss eine Reihenfolge festgelegt werden. Beim Blick auf die ersten beiden Methoden ist die Gefahr gering, dass der Anwender durch eine Methode beeinlusst wird. Es wurde die Entscheidung getrofen, Contex-tual Inquiry zuerst durchzuführen, weil danach ein konkreteres Bild der Anwenderanforderungen vorliegt und der Usability-Test zielgerichteter aufgebaut werden kann. Da das standardisierte Interview alle Anforde-rungen der Vorstudie abfragt, wird es als letztes durchgeführt. Zu einem früheren Zeitpunkt ist die Gefahr hoch, die Anwender durch die Nennung verschiedener Anforderungen zu beeinlussen.

7.3.7 Hauptstudie, Datenauswertung: User StoriesNeben den Erhebungsmethoden der Hauptstudie wurde eine weitere Methode der Software- Entwicklung für die Auswertung herangezogen: User Stories. C deiniert fr sie folgendes Muster: „Als (Akteur) möchte ich (folgende Funktion durchführen), um (daraus folgenden Nut-zen zu ziehen).“194 Übertragen auf die Technische Dokumentation und die konkrete Fragestellung der Masterarbeit entsteht folgendes Muster: Als Anwender der Dokumentation zur Fernsteuerung von Messgeräten wünsche ich mir (folgende Funktion), um (daraus folgenden Nutzen zu ziehen).Des Weiteren stimmen die Methoden Befragung und Beobachtung mit der üblichen Ausgangsbasis von User Stories überein: „Interviews mit Usern, Fragebögen, Beobachtung oder Story-Workshops“.195

Zudem hilft die Ich-Form dem Technischen Redakteur dabei, sich in die Sicht des Anwenders zu versetzen. Als Maßstab für die spätere Bewer-tung der Qualität dienen die Akzeptanzkriterien, die für jede User Story aufgestellt werden müssen ebenso wie ein mögliche Priorisierung.196

Die Abfrage der einzelnen Bestandteile von User Stories während Befra-gungen kommt einem leitfadengestützten Interview gleich. Dadurch ist die Informationstiefe sichergestellt. Zudem bilden sie neben den eigent-lichen Anforderungen den Nutzen der Anforderung ab und sind dadurch verständlicher. Im Hinblick auf das Forschungsziel, im letzten Schritt

194 Rau, K., Agile objektorientierte Software-Entwicklung, 2016, 42.195 Cohn, M., User Stories, 2010, S. 65.196 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 95.

46

Ermittlung der AnwenderanforderungenDatenerhebung

Verbesserungspotenzial aufzuzeigen, ist dieser Vorteil von User Stories entscheidend. Damit die Anwendung von User Stories nicht zu umfangreich wird, wird lediglich der sichtbare Teil, die Stories selbst, umgesetzt, was einer Modi-ikation der Methode entspricht. Die nach C beschriebenen anderen Teile, Gespräche und Tests, werden nicht verwendet.

Die Entscheidung ist auf User Stories und nicht auf Use Cases gefallen, da User Stories die für das Forschungsziel benötigten Informationen zu den Anwenderanforderungen kompakt und in völlig ausreichender Weise zusammenfassen. Use Cases sind deutlich ausführlicher, was für das entwickelte System nicht zielführend ist.197

R und F ü schlagen zur Auswertung von Contextual Inquiry eine andere Methode als User Stories vor: Ein Ainitätsdiagramm. Dabei werden die bei der Beobachtung und Befragung gesammelten Erkenntnisse auf Karteikarten festgehalten, in einem Workshop disku-tiert, interpretiert und in mehreren Stufen zu Anforderungen verdichtet.198 Die Vorgehensweise ist aber zu aufwendig. Der Technische Redakteur müsste ausführlich von allen Interviews berichten oder die anderen Teil-nehmer müssten sämtliche Transkripte lesen.

7.4 Datenerhebung

7.4.1 Vorstudie: Problemzentriertes InterviewIm Folgenden wird die Entwicklung des Systems zur der Datenerhebung der Ermittlung der Anwenderanforderungen beschrieben. Das Ergeb-nis, das heißt, die konkrete Vorgehensweise der Datenerhebung, wird in Kapitel „B: Schritt für Schritt-Anleitungen“ beschrieben.

Für die Durchführung des Problemzentrierten Interviews bestimmt der Technische Redakteur in einer Bewussten Auswahl, mit wem er die Gespräche durchführt. Durch seine bisherige Arbeit im Unternehmen hat er mit sehr hoher Wahrscheinlichkeit eine Idee, welche Mitarbeiter für die Befragung im Hinblick auf das Forschungsziel geeignet sind und gege-benenfalls informelle Kontakte zu ihnen.

197 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 85f.198 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 51f.

47


Der Forscher darf aber nicht davon ausgehen, „dass diese informellen Kontakte so weitreichend und umfassend sind, dass er alle relevanten und typischen Handlungs- und Deutungsmuster erfasst hat.“199

Eine Möglichkeit, den beschränkten Personenkreis zu erweitern, ist das Schneeballprinzip. Hierbei werden alle Befragten nach weiteren Interviewpartnern gefragt. So lässt sich der Personenkreis schnell um ein Vielfaches erweitern. Daher wurde das Schneeballprinzip in den Leit-faden aufgenommen.200

Das Interview muss aufgezeichnet werden, „um die Güte der Daten und Interpretationen zu sichern.“201

Das Problemzentrierte Interview besteht aus folgenden fünf Teilen: Ein-leitung, Allgemeine Sondierung, Speziische Sondierung, direkte Fragen und dem Kurzfragebogen.202 Das Problemzentrierte Interview zeichnet sich dadurch aus, dass der Interviewer aktiv in die Erzählungen des Befragten eingreift, aber „die Bedeutungsstrukturierung der sozialen Wirklichkeit bleibt dem Befrag-ten allein überlassen.“203 Dabei muss der Interviewer darauf achten, den Befragten nicht aus seinem Erzählluss zu bringen. Das ist der Grund dafür, dass die allgemeinen Daten zur Tätigkeit des Befragten mit Hilfe eines Kurzfragebogens ermittelt werden.204 Bei der Methode des Pro-blemzentrierten Interviews ist die Verwendung eines Leitfadens vorge-geben. Auch im Hinblick auf das Forschungsziel ist es zielführend, die Abfrage wichtiger Themenbereiche im Interview sicherzustellen.

H stellt folgende sechs Anforderungen an einen Leitfaden:• Beachten der Grundprinzipien qualitativer Sozialforschung und des

Prinzips der Ofenheit• Begrenzung der Fragenanzahl (ausreichend Zeit fr ofene

Erzähldarstellungen)• formale Übersichtlichkeit und gute Handhabbarkeit (Unterstützung

des Interviewenden und keine Ablenkung)• Aufbau gemäa dem Erinnerungs- oder Argumentationsluss (keine

abrupten Themenwechsel)• Ofene Erzählauforderungen und kein starres Ablesen von Fragen• Platz fr ofene Erzählungen und Vertiefungen (kein Abblocken von

Informationen durch enge Vorgaben)205

199 Lamnek, S., Qualitative Sozialforschung, 2010, S. 351.200 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 351.201 Lamnek, S., Qualitative Sozialforschung, 2010, S. 354.202 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 334.203 Lamnek, S., Qualitative Sozialforschung, 2010, S. 333.204 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 335.205 Vgl. Helferich, C., Die Qualität qualitativer Daten, 2011, S. 180.

48


Um den Leitfaden zu erstellen, müssen vier Schritte durchgeführt wer-den: Sammeln, Prüfen, Sortieren und Subsumieren.206 „Dieses Vorgehen hat einen wichtigen Nebenefekt: Es dient gleichzeitig der Vergegenwär-tigung und dem Explizieren des eigenen theoretischen Vorwissens und der impliziten Erwartungen an die von den Interviewten zu produzieren-den Erzählungen.“207

Im ersten Schritt werden demnach möglichst viele Fragen gesammelt. Da durch den Kurzfragebogen bereits alle allgemeinen Fragen zur Tätig-keit des Befragten beantwortet wurden, können die Anforderungen der Anwender im Fokus stehen. Nach einer Reduzierung und Strukturie-rung werden die Fragen sortiert. Abschließend ergeben sich Erzählauf-forderungen für den Leitfaden. Die Empfehlung liegt bei maximal vier Erzählauforderungen. Diese werden im Interview nur gestellt, falls die Themen während des Erzähllusses des Befragten nicht ohnehin ange-sprochen werden. 208

7.4.2 Hauptstudie: Contextual InquiryIm Folgenden wird die Datenerhebung der Hauptstudie mit Hilfe der Methode Contextual Inquiry im entwickelten System der Masterarbeit beschrieben.Das kontextuelle Interview ist die meist verwendete Struktur für Cont-extual Inquiry. Jedes Interview besteht aus vier Teilen: Conventional

Interview (konventionelles Interview), Transition (Übergang), Contex-

tual Interview Proper (eigentliches kontextuelles Interview) und Wrap-up

(Nachbereitung).In der ersten Phase stellt sich der Technische Redakteur dem Befragten vor und erklärt ihm, welche Informationen relevant sind. In der zweiten Phase erklärt der Interviewer dem Anwender den Ablauf. Der Anwender wird seine Arbeit wie gewohnt durchführen, der Intervie-wer wird ihn dabei beobachten und ihn unterbrechen. Die Transition ist kurz, aber wichtig. Denn ohne die Erklärung der Regeln, müsste der Interviewer soziale Normen ohne Vorwarnung brechen. Das kann dazu führen, dass das Interview konventionell bleibt und der Anwender nicht in den Erzählluss kommt.Im eigentlichen kontextuellen Interview führt der Anwender seine Arbeit durch. Der Technische Redakteur ist auf der einen Seite der Lehrling und beobachtet, schlägt darüber hinausgehend aber Interpretationen des

206 Vgl. Helferich, C., Die Qualität qualitativer Daten, 2011, S. 182.207 Helferich, C., Die Qualität qualitativer Daten, 2011, S. 182.208 Vgl. Helferich, C., Die Qualität qualitativer Daten, 2011, S. 181.

49


Verhaltens vor und stellt Fragen zu den Zusammenhängen. Zudem muss er den Anwender immer wieder zurückführen zu den für ihn relevanten Informationen. Hierbei muss er seine Beobachtungen notieren. In der abschließenden Phase sollte der Interviewer nochmals sein Ver-ständnis der Arbeit des Anwenders zusammenfassen.209

Die Beobachtungsdimension des Contextual Inquiry entspricht einer teil-nehmenden Beobachtung. Bei jeder Beobachtung muss eine Entschei-dung für den Grad der Strukturierung getrofen werden. „Ähnlich dem Interview kann [ ... ][dieser] als Kontinuum mit den Polen «unstrukturiert» und «hochstrukturiert» aufgefasst werden.“210 Da im Contextual Inquiry sowohl Elemente der Beobachtung als auch des Interviews zum Ein-satz kommen, ist die Frage nach der Strukturierung umso wichtiger.211 Die Strukturierung stellt eine Herausforderung dar, da der Technische Redakteur auf verschiedene Situationen trefen wird, wie einen Anwen-der an einem chaotischen Arbeitsplatz im Büro oder einen Anwender in einer Produktionshalle mit hohem Lärmpegel.Ein Leitfaden in welchem sich die vier Phasen widerspiegeln, bietet dem Technischen Redakteur bei der Durchführung des Contextual Inquiry eine Hilfestellung.Des Weiteren hilft die Anforderungsmatrix aus der Vorstudie, welche eine Strukturierung der Beobachtung ermöglicht. Um dem Anwender aber beim Zeigen seiner Arbeitsweise mit der Dokumentation nicht vorzugrei-fen, darf die Matrix nicht ofengelegt werden.Eine weitere Strukturierung ermöglicht die Verwendung eines Kurzfrage-bogens, um allgemeine Informationen zur Tätigkeit abzufragen. Zudem lassen sich mögliche Thesen zu verschiedenen Anwendergruppen lm Kurzfragebogen gut abfragen. Da die Abfrage aber auf den individuellen Ergebnissen der Vorstudie beruht, können die Punkte nicht in der Schritt für Schritt-Anleitung im Anhang vorgegeben werden. Zudem muss ein Postskript verwendet werden, um die Rahmenbedin-gungen zu notieren. Auch M weist auf die Dokumentation der Beob-achtungen hin, beispielsweise des Arbeitsumfelds des Teilnehmers.212 Hinweise aus dem Leitfaden unterstützen den Technischen Redakteur möglichst gut bei der Umsetzung. Sie erinnern ihn beispielsweise daran, dass aus der Hauptstudie User Stories hervorgehen sollen und er des-wegen stets gezielt beim Anwender nachfragen muss.

209 Vgl. Beyer, H.; Holtzblatt, K., Contextual design, 1998, S. 64f.210 Diekmann, A., Empirische Sozialforschung, 2016, S. 569.211 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 569.212 Vgl. Moser, C., User Experience Design, 2012, S. 63.

50


7.4.3 Hauptstudie: Usability-TestDa die wenigsten Technischen Redakteure ein klassisches Usability-Lab wie in Kapitel 5.3.7 „Usability-Test“ zur Verfügung haben werden, muss für die Erhebung eine Alternative gesucht werden: Ein mobiles Usabi-

lity-Lab ermöglicht dem Technischen Redakteur die Durchführung von Usability-Tests im Unternehmen. Das hat den Vorteil, dass die Messgeräte, welche zur Durchführung der Standardaufgabe benötigt werden, schon vor Ort sind. Die Messgeräte können temporär in einem Besprechungsraum installiert und ein Laptop mit Zugang zur Dokumentation eingerichtet werden. In dem Raum kann der Technische Redakteur den Testablauf mit seinem Smartphone auf-nehmen. Die Qualität der Aufnahme ist hierbei nicht ausschlaggebend, sie dient lediglich der Möglichkeit die Vorgehensweise nachzuvollzie-hen.213 Die Umsetzung ist im Einklang mit dem von Bö und R bemerkten Trend bezüglich Usability-Tests, dass „[m]oderne Ansätze häuig auch mit weniger aus[kommen].“214 Bei der Durchführung des Usability-Tests muss dem Technischen Redak-teur bewusst sein, dass die zeitlichen Ressourcen über den Test hinaus-gehen. Die Vorbereitung der Tests bedarf im Vorlauf Zeit und auch für den eigentlichen Test muss Zeit für den Aufbau eingeplant werden.Ein wichtiger Teil der Vorbereitung ist die Auswahl der Aufgabe sowie eines Beispielgerätes und der Dokumentation. Dabei muss das For-schungsziel stets im Blick behalten werden, was für die Qualität der Ergebnisse entscheidend ist. Je nach zeitlichen und personalen Ressourcen können entsprechend lange und eine Vielzahl an Aufgaben ausgewählt werden. Dabei sind verschiedene Kriterien zu beachten: Die Aufgabe muss realistisch sein, das heißt, die Aufgabe könnte dem Anwender in der Praxis so begegnen. Zudem muss der typische Anwender die Aufgabe lösen können, weshalb ein mittlerer Schwierigkeitsgrad gewählt werden sollte. Des Weiteren muss die Aufgabenstellung ofen sein, um dem Anwender beim Lösen der Aufgabe nicht vorweg zu greifen. Auaerdem mssen Begrife und Bezeichnungen, die in der Applikation vorkommen, vermieden werden und die Durchführung der Aufgaben sollte maximal eine Stunde dauern.215 Vor der Erhebung muss der Redakteur den Anwender darauf hinwei-sen laut zu denken, damit seine Vorgehensweise nachvollzogen werden kann. 216 Des Weiteren muss der Technische Redakteur dem Anwender

213 Vgl. Richter, M.; Flückiger, M., Usability und UX kompakt, 2016, S. 109f.214 Böcker, M.; Robers, R., Kundendokumentationen, 2015, S. 413.215 Vgl. Richter, M.; Flckiger, M., Usability und UX kompakt, 2016, S. 103f.216 Vgl. Barnum, C., Usability testing essentials, 2010, S. 200f.

51

Ermittlung der AnwenderanforderungenDatenerfassung

seine Rolle des stillen Beobachters während der Durchführung erklären. Um eine möglichst natrliche Situation zu schafen ist es wichtig, dass sich der Anwender wohl fühlt. Daher muss der Technische Redakteur ihm erklären, dass nicht er getestet wird, sondern es darum geht zu sehen, wie er mit der Dokumentation bei einer standardisierten Aufgabe arbei-tet, um verdeckte Anforderungen zu ermitteln.217 Das ist zudem wichtig, um trotz der Kamera, die unabdingbar für Auswertung ist, eine möglichst normale Forschungssituation herzustellen.218 Auch die Nachbesprechung ist ein wichtiger Teil. Währenddessen müs-sen sämtliche Unsicherheiten bezüglich des richtigen Verständnisses der Anforderungen besprochen werden, damit sie in der Auswertung richtig eingeordnet werden können.219 Zudem hat der Versuchsteilnehmer die Möglichkeit, die Aufgabe zu kommentieren.220

7.5 Datenerfassung

Bevor die Auswertung erfolgen kann, müssen die erhobenen Daten erfasst werden.221 Die Tonaufnahme der Vorstudie und des Contextual Inquiry muss transkribiert werden. Dabei ist die Wörtliche Transkription

am geeignetsten, da sie „eine vollständige Textfassung verbal erhobe-nen Materials [herstellt], was die Basis für eine ausführliche interpretative Auswertung bietet.“222 Währenddessen wird der Text in normales Schrift-deutsch übertragen: „Der Dialekt wird bereinigt, Satzbaufehler werden behoben [und] der Stil wird geglättet.“223 Bei der Arbeit mit der vollständi-gen Transkription ist die Nachvollziehbarkeit im Gegensatz zum zusam-menfassenden Protokoll gewährleistet. Auch die Daten des Kurzfragebogens und des Postskripts müssen erfasst werden. Das Postskript enthält Informationen über die Rahmenbedin-gungen und die Gespräche vor und nach Einschalten des Aufnahmege-rätes, denn „[e]iner der grundlegenden Vorzüge qualitativer Interviews liegt in der Möglichkeit, zusätzliche Informationen in die Interpretation mit einzubeziehen. Dies können Informationen zum Befragten und seiner Situation sein, aber auch Eindrücke des Interviewers [ ... ]“224.Beim Usability-Test muss neben der Transkription des Gesagten das Handeln erfasst werden. Für die Überprüfung zur These der Anwender-gruppen ist es zudem nötig, alle Testverläufe in einer Tabelle als Über-sicht zu erstellen.

217 Vgl. Barnum, C., Usability testing essentials, 2010, S. 200f.218 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 359.219 Vgl. Barnum, C., Usability testing essentials, 2010, S. 243.220 Vgl. Böcker, M.; Robers, R., Kundendokumentationen, 2015, S. 411.221 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 196.222 Mayring, P., Einführung in die qualitative Sozialforschung, 2016, S. 89.223 Mayring, P., Einführung in die qualitative Sozialforschung, 2016, S. 91.224 Lamnek, S., Qualitative Sozialforschung, 2010, S. 357.

52

Ermittlung der AnwenderanforderungenDatenauswertung

7.6 Datenauswertung

7.6.1 Vorstudie: Problemzentriertes InterviewKlassischerweise läuft die Auswertung des Problemzentrierten Interviews in den folgenden drei Stufen ab: Methodologische Kommentierung, Kont-

rollierte Interpretation und Vergleichende Systematisierung.225

Für die Auswertung und Analyse qualitativer Interviews führt L fol-gende vier allgemeine Phasen der Auswertung an: Transkription, Einze-

lanalyse, generalisierende Analyse und Kontrollphase.226 J -G gliedert die Analyse in fünf Phasen: Transkription, Entwicklung thematischer Verläufe, Erstellen einer Themenmatrix, Klas-

siikation des Materials und Themenorientierte Darstellung.227 Wird die Transkription in der Datenerfassung verortet, ist allen Abläufen gemeinsam, dass sie von der Betrachtung eines Interviews ihren Blick auf alle Interviews richten, Vergleiche ziehen und versuchen, ein allge-meines System zu identiizieren. Ziel der Vorstudie ist es, eine Hypothesenbildung für die Befragung der Anwender in der Hauptstudie zur Ermittlung der Anwenderanforderun-gen zu ermöglichen. Zu diesem Zweck ist eine gute Übersicht der Vorstu-die hilfreich. Da die Anwender zudem klassiiziert werden sollen, ist die Analyse nach J -G am geeignetsten für das Forschungs-ziel und wird daher für die Auswertung des Problemzentrierten Interviews angewandt. Auch diese Methode der Auswertung muss im Hinblick auf die zeitlichen Ressourcen des Technischen Redakteurs etwas modiiziert werden, daher wird die Umsetzung mit Karteikarten und einem Whiteboard durch-geführt. Die Einordnung der erhobenen Anforderungen im Dokumenta-tionsbereich Fernsteuerung von Messgeräten in die drei betrachteten Kategorien Struktur, Inhalt und Form kann so direkt erfolgen. Die The-menmatrix nach J -G wird als Anforderungsmatrix bezeich-net und mit Hilfe der Gesprächsverläufe am Whiteboard entsprechend der Kategorien ausgearbeitet. Ergänzend werden die Kurzfragebögen steckbriefartig auf Karteikarten notiert und in die Betrachtung miteinbe-zogen, ebenso die Postskripts.Die Vorgehensweise ermöglicht es, eine These zu den Anforderungen der Anwender und den möglichen Anwendergruppen aufzustellen.

225 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 335.226 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 368f.227 Vgl. Lamnek, S., Qualitative Sozialforschung, 2010, S. 369f.

53

Ermittlung der AnwenderanforderungenDatenauswertung

7.6.2 Hauptstudie: Contextual InquiryDie vorliegenden Transkripte müssen so ausgewertet werden, dass der Technische Redakteur als Ergebnis erste User Stories erhält. Jede im Gespräch aufkommende Anforderung wurde optimaler Weise nach dem Schema einer User Story abgefragt. Da die Abfrage aufgezeichnet wurde, kann der Technische Redakteur ein Transkript nach dem anderen durchgehen, sämtliche Anforderungen markieren und zu jeder einzelnen eine User Story verfassen. Währenddessen kann er überprüfen, ob die genannten Anforderungen in der Anforderungsmatrix bereits auftauchen und sie markieren. Sonst kann er die Matrix entsprechend ergänzen.

7.6.3 Hauptstudie: Usability-TestNach B erfolgt die Auswertung in drei Stufen: Beobachtungen, Interpretationen, Folgen.228 Im ersten Schritt müssen alle Beobachtungen durch das Lesen der Protokolle und Transkripte ins Gedächtnis gerufen werden. Anschließend müssen die sich daraus ableitbaren Anforderun-gen markiert werden, was Interpretationen entspricht. Diese können wie-derum im dritten Schritt in die in der Vorstudie erstellten und durch den ersten Teil der Hauptstudie erweiterte Anforderungsmatrix eingeordnet werden. Die Vorgehensweise bei der Auswertung entspricht einem Top-

down-Prinzip. Im Gegensatz zum Bottom-up-Prinzip229, welches aus den Ergebnissen heraus Kategorien erstellt wie in einem Ainitätsdiagramm, spart das Vorgehen Zeit. Zudem wurde dieses Prinzip bereits in der Vor-studie angewandt. Es macht aber dennoch Sinn, das Bottom-up-Prinzip mit dem hauptsächlich angewandten Top-down-Prinzip zu kombinieren. So können neue Anforderungen, die während der Testphase auftau-chen, mit in die Anforderungsmatrix aufgenommen werden. Durch die dadurch bestehen bleibende Flexibilität müssen die Anforderungen nicht in die vorgegebenen Raster gezwängt werden. Gemäß diesen neuen Anforderungen müssen weitere User Stories für die jeweiligen Anwender geschrieben werden. Neben der Überprüfung der in der Vorstudie genannten Anforderungen durch die Anforderungsmatrix, darf die These zu den Anwendergruppen nicht vergessen werden. Daher muss bei der Auswertung überprüft wer-den, ob es gemäß den verschiedenen Anwendergruppen und deren Vor-gehensweise Aufälligkeiten gibt, auch im Hinblick auf ihre Anforderungen.Zudem kann nach der Erstellung einer Tabelle, in welcher die Nennungen

228 Vgl. Barnum, C., Usability testing essentials, 2010, S. 239f.229 Vgl. Barnum, C., Usability testing essentials, 2010, S. 240f.

54

Ermittlung der AnwenderanforderungenBerichterstattung

der Anforderungen festgehalten sind, die Häuigkeit dieser aus der Vor-studie und der Hauptstudie verglichen werden.

7.6.4 Hauptstudie: AnforderungsmatrixDie Relevanz der Anforderungen, welche in der Vorstudie genannt wur-den, aber nicht mehr in der Hauptstudie, muss noch überprüft werden. Hierzu werden die Ergebnisse der standardisierten Interviews heran-gezogen, in welchen die gesamte Anforderungsmatrix durchgegangen wurde. So kann in einer Tabelle festgehalten werden, wie viele Anwen-der die Anforderung für den Dokumentationsbereich Fernsteuerung von Messgeräten aus ihrer persönlichen Sicht als relevant empfanden und falls ja, als wie wichtig sie die Anforderung sehen.

Empindet mehr als die Hälfte der Anwender die Anforderung als rele-vant, ist davon auszugehen, dass es sich um eine weitere Anforderung handelt, welche eine Grundlage für die zweite Stufe des Systems bildet. Die Schwelle für die Anwenderanforderungen ist höher als bei den User Stories, da die Anforderungen nicht eigenständig genannt wurden, son-dern nur durch eine direkte Abfrage zur Sprache kamen. Diese Anforderungen werden im Folgenden als Einzelne Anforderungen bezeichnet, um sie von den User Stories abzugrenzen.

7.7 Berichterstattung

Der Technische Redakteur, welcher die Ermittlung der Anwenderanfor-derungen Schritt für Schritt durchführt, muss seine Vorgehensweise und Ergebnisse dokumentieren und seinen Kollegen präsentieren. So ermög-licht er „eine Fehlerkontrolle und sachgerechte Auseinandersetzung über die zur Diskussion gestellten empirischen Befunde.“230 Das kann zu einer Überarbeitung der Anleitung für das eigene Unternehmen und einer Opti-mierung der Ergebnisse führen.

230 Diekmann, A., Empirische Sozialforschung, 2016, S. 197.

55

Ermittlung der AnwenderanforderungenZusammenfassung

7.8 Zusammenfassung

Die Forschungsfrage der ersten Stufe des Systems

Wie ermittle ich die Anwenderanforderungen auf eiziente Art?

ist am Ende dieses Kapitels beantwortet und somit der erste Teil der Ent-wicklung des Systems abgeschlossen.

Die Datenerhebung wurde in Vorstudie und Hauptstudie aufgeteilt. In der Vorstudie wird ein Problemzentriertes Interview angewandt, in der Hauptstudie werden die Methoden Contextual Inquiry, Usability-Test und ein standardisiertes Interview kombiniert.Als Ergebnis der Ermittlung der Anwenderanforderungen im Dokumen-tationsbereich Fernsteuerung von Messgeräten fasst eine Anforderungs-matrix die ausgewerteten User Stories und Einzelnen Anforderungen zusammen.

Vorstudie1Wie ermittle ich die Anwender-anforderungen auf effiziente Art?

Contextual InquiryUsability-Test

Standardisiertes Interview




Problemzentriertes Interview

Hauptstudie


AnforderungsmatrixUser Stories

Einzelne Anforderungen

?

Stufe


??

? ? ?

Abb. 15: Stufe 1 des entwickelten Systems

57

Bewertung der Qualitt der DokumentationEinführung

8 Bewertung der Qualitt der Dokumentation

8.1 Einführung

Die zweite Stufe des Systems, die Bewertung der Qualität der Dokumen-tation (BdQ), beantwortet die Forschungsfrage:

Wie bewerte ich die Qualitt der Dokumentation im Hinblick auf die Anwenderanforderungen?

Die zweite Stufe des Systems baut auf der ersten Stufe, der Ermittlung der Anwenderanforderungen, auf. Es wird überprüft, inwiefern die erho-benen User Stories und Einzelnen Anforderungen in der Dokumentation erfüllt sind.Diese Vorgehensweise orientiert sich an der Deinition der DIN EN ISO 9000:2015-11, die Qualität als Grad deiniert, inwieweit ein Produkt mit dessen Anforderungen übereinstimmt. Das führt zu der Schlussfolgerung, dass die Qualität der Dokumentation je höher ist, desto mehr Anwenderanforderungen erfüllt sind. Die Qualität ist entscheidend, da sie bestimmt „ob und inwieweit die jeweiligen Zielgruppen die angebo-tenen Leistungen und Funktionen der Produkte und Prozesse vorteilhaft für sich nutzen können.“231

Die zweite Stufe beschreibt die Vorgehensweise zur Bewertung der Qua-lität der Dokumentation eines Beispielgerätes, welche sich auf jede wei-tere Dokumentation des Unternehmens übertragen lässt.


Die Überlegungen zur Bewertung der Qualität ähneln denen in der Ermittlung der Anwenderanforderungen in Kapitel 7.2 „Theoretische Vorüberlegungen der Erhebung“. Auch für diese Stufe wurde das For-schungsproblem in Kapitel 6.3 „Forschungsfragen“ bereits behandelt und der Begrif Qualität in Kapitel 2.5 „Qualität“ deiniert.In der zweiten Stufe wird die Variable Qualität betrachtet. Sie muss einer Messung zugänglich gemacht, das heißt, operationalisiert werden. Als the-oretisches Konstrukt kann die Qualität nur indirekt gemessen werden.232 Da sie mit der Erfüllung der Anwenderanforderungen zusammenhängt,

231 VDI 4500-1, Technische Dokumentation: Begrifsdeinitionen, S. 6.232 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 231.

58

Bewertung der Qualitt der DokumentationTheoretische Vorüberlegungen der Erhebung

wird die Anforderungsmatrix der ersten Stufe des Systems herangezo-gen. Die Anforderungsmatrix kann für Struktur, Inhalt und Form identisch angewandt werden. Zunächst muss der Frage „Wie wichtig ist die Anfor-derung?“, nachgegangen werden, da davon auszugehen ist, dass die befragten Anwender die Anforderungen in der ersten Stufe unterschied-lich häuig genannt haben. Zudem haben sie vermutlich nicht alle Anfor-derungen genannt, die durch die Vorstudie vorgegeben wurden. Dieser unterschiedlichen Gewichtung muss in einem System, welches basie-rend auf Anwenderanforderungen Verbesserungspotenzial aufzeigen soll, Rechnung getragen werden.Neben der Bedeutung der Anwenderanforderung muss der Grad der Erfüllung der Qualität gemessen werden, was mit Hilfe einer Ordinals-kala und den Faktoren 0, 1 und 2 umgesetzt wird. Die dreistuige Bewer-tung spiegelt die in der DIN EN ISO 9000:2015-11 genannten Adjektive schlecht, gut oder ausgezeichnet wider.233 Schlecht wird der 0 zugeord-net, und damit beschrieben, dass die Anforderung nicht erfüllt ist. Gut wird der 1 zugeordnet und damit beschrieben, dass die Anforderung zum Teil erfüllt ist und die 2 steht für ausgezeichnet und beschreibt eine voll-ständig erfüllte Anforderung.Eine Multiplikation der Gewichtung jeder Anforderung mit dem je nach Erfüllungsgrad erreichten Faktor ergibt für jede Anforderung einen Wert, den erreichten Wert. Die Werte können alle addiert und im Vergleich zum maximal möglichen Wert, dem maximalen Wert, interpretiert werden, was Aufschluss über die Qualität der Dokumentation gibt.

Der Technische Redakteur wendet die Anforderungsmatrix zur Bewer-tung der Qualität in einer kurzen Zeitspanne auf eine Beispieldokumen-tation an, was einer Datenerhebung in Form eines Querschnittdesigns entspricht.234 Das Untersuchungsdesign soll ermöglichen, die Qualität der Dokumentation zu überprüfen.Bei der Bewertung der Qualität der Dokumentation ist die Grundgesamt-heit zunächst sämtliche Externe Dokumentation des Unternehmens. Wie in Kapitel 8.1 „Einführung“ beschrieben, wird die Stufe auf die gesamte Dokumentation eines Messgerätes angewandt. Die Dokumentation hat der Technische Redakteur in der ersten Stufe mit der Standardaufgabe des Usability-Tests bereits ausgewählt.

233 Vgl. DIN EN ISO 9000:2015-11, Qualitätsmanagementsysteme, S. 39.234 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 304f.

59

Bewertung der Qualitt der DokumentationMethodenauswahl

8.3 Methodenauswahl

Um die Qualität der Dokumentation bewerten und die Faktoren entspre-chend vergeben zu können, kommt wegen der Kategorien Struktur, Inhalt und Form nur eine analysierende Methode in Frage.Eine analysierende Methode ist die Inhaltsanalyse, die sich „mit der sys-tematischen Erhebung und Auswertung von Texten, Bildern und Filmen befasst.235 Auch wenn sich diese Methode neben Inhalten von Texten auf formale Gesichtspunkte, wie die Länge von Sätzen bezieht,236 stößt sie insbesondere bei der in der Masterarbeit deinierten Kategorie Form an ihre Grenzen. Beispielsweise lässt sich die Anforderung, dass es ver-schiedener Zugrifsarten auf die Dokumentation, z. B. eine PDF-Datei oder eine Hilfe am Messgerät, geben soll, nach der eben angeführten Deinition nicht mit Hilfe einer Inhaltsanalyse berprfen. Dies muss eine Methode, die die Qualität der Dokumentation im Hinblick auf die Anwen-deranforderungen bewerten soll, aber ermöglichen.Zudem muss die Methode auf der Anforderungsmatrix, die in der ersten Stufe des Systems zur Ermittlung der Anwenderanforderungen erstellt wurde, aufbauen im Hinblick darauf die Qualität bewerten können.Da die Inhaltsanalyse dies ermöglicht und die Einzelnen Anforderungen und User Stories direkt als Unterkategorie verwendet werden können, fällt die Wahl auf diese Methode.

Wie bereits beschrieben muss sie aber modiiziert fr das System ange-wandt werden, da die weit gefasste Deinition fr die Kategorien Struktur, Inhalt und Form nicht genügt. Die Methode wird auf diese Kategorien übertragen und daher nicht mehr als Inhaltsanalyse, sondern als Analyse bezeichnet.Um neben den Schlussfolgerungen zu den Kategorien Struktur, Inhalt und Form eine weitere Diferenzierung ermöglichen zu können, muss ein wei-teres Kategoriensystem erarbeitet werden. Dabei ist zu überlegen, unter welche Oberbegrife mehrere Anforderungen zusammengefasst werden können. Diese Oberbegrife mssen solange gebildet werden, bis jede Anforderung einem dieser Oberbegrife zugeordnet werden kann.

235 Diekmann, A., Empirische Sozialforschung, 2016, S. 576.236 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 576.

60

Bewertung der Qualitt der DokumentationDatenerhebung

8.4 Datenerhebung

Die ausgewählte Dokumentation muss mit Hilfe der Anforderungsmatrix Schritt für Schritt durchgegangen und jeder Anforderung einer der drei möglichen Erfüllungsgrade schlecht (Faktor 0), gut (Faktor 1) oder aus-gezeichnet (Faktor 2) zugeordnet werden.Da diese Stufe auf der ersten Stufe aufbaut und daher fallbezogen ist, ist es nicht möglich dem Technischen Redakteur zu sagen, wie er im Einzelfall die Qualität bewerten kann. Um ihm die Einstufung des Erfül-lungsgrades insbesondere in Grenzfällen zu erleichtern, wird folgende Regel aufgestellt:Sobald ein Positivbeispiel gefunden wurde, darf für die Anforderung nicht mehr der Faktor 0 verwendet werden. Wurde mindestens ein Negativbeispiel gefunden, darf der Faktor 2 der Anforderung nicht mehr zugeordnet werden.Die Regel ist wichtig, um die Nachvollziehbarkeit und die Gültigkeit der Ergebnisse zu gewährleisten.Zudem werden dem Technischen Redakteur konkrete Hinweise gege-ben, wo er weitergehende Informationen indet, mit deren Hilfe er den Erfüllungsgrad der Anforderungen bewerten kann.Beispielsweise ist die Norm ISO/IEC 26514:2008(E) S S -

E - R D D U D eine gute Richtlinie, da sie in ihrem zweiten

Abschnitt die Minimalanforderungen an Struktur, Inhalt und Form sowohl fr Print- als auch fr On-Screen-Dokumentation deiniert. Auch wenn die Norm sich primär auf die Software-Benutzerdokumentation bezieht, können viele Aspekte transferiert werden.237 In einem Kapitel beschäftigt sich die Norm mit Softwarebefehlen. Dem-nach muss die Dokumentation die Syntax der Software befolgen. Zudem muss der Aufbau sowie Ablauf für die Befehle, die der Anwender eingibt, erklärt werden sowie benötigte und optionale Parameter, voreingestellte Optionen, die Reihenfolge der Befehle und die Syntax.238 Zudem müssen Beispiele in der Dokumentation zur Veranschaulichung der Befehle ver-wendet werden, da Anwender bei Problemen in der Dokumentation nach konkreten Beispielen suchen, die ihrer eigenen Situation ähneln. Des Weiteren muss die Dokumentation erklären, wie ein Vorgang während der Ausführung unterbrochen sowie rückgängig gemacht wird und er,

237 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 1.238 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 54.

61

Bewertung der Qualitt der DokumentationDatenerhebung

falls möglich, neugestartet werden kann. Außerdem muss die Dokumen-tation beschreiben, wie erkannt werden kann, ob ein Befehl erfolgreich ausgeführt oder abgebrochen wurde.239

In der ISO/IEC 26514:2008(E) S S E - R D D U D -

wird der Aufbau durch ein Beispiel veranschaulicht.

Abb. 16: Beispiel-Dokumentation der Funktion einer Tabelle240

Zur Datenerhebung muss der Technische Redakteur seine Anforde-rungsmatrix durchgehen und jede Anforderung einzeln bewerten. Die jeweilige Entscheidung muss notiert werden, um die Nachvollziehbarkeit zu gewährleisten. Auch Beispiele aus der Dokumentation, die die Ent-scheidung stützen, müssen angeführt werden.

239 Vgl. ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 54.240 ISO/IEC 26514:2008(E), Designers and developers of user doc., S. 55.

62

Bewertung der Qualitt der DokumentationDatenerfassung

8.5 Datenerfassung

Die ausgefüllte Anforderungsmatrix muss digital festgehalten werden, damit eine Nachvollziehbarkeit gewährleistet ist.

8.6 Datenauswertung

Nachdem alle Anforderungen bewerten wurden, muss der erreichte Wert der Anforderung errechnet werden. Anschließend muss der erreichte Wert der drei Kategorien sowie der Gesamtwert errechnet werden. Eine Gleichsetzung des jeweils erreichten Wertes mit dem maximal möglichen Wert ermöglicht es Aussagen über den Erfüllungsgrad und damit über die Qualität der Dokumentation zu trefen. Neben der Auswertung jeder ein-zelnen Anforderung, können Aussagen zu den Kategorien Struktur, Inhalt und Form getrofen werden sowie zu den neu erhobenen Oberbegrifen.


Das Ergebnis sollte der Technische Redakteur seinen Kollegen berich-ten. So kann der Technische Redakteur überprüfen, ob seine Entschei-dungen nachvollziehbar sind. Dabei sollte er sich zwar auf Diskussionen einlassen, aber darauf achten, dass die Ergebnisse durch seine Kollegen nicht unbegründet nach oben geschoben und damit verzerrt werden.

8.8 Zusammenfassung

Die Forschungsfrage der zweiten Stufe des Systems,

Wie bewerte ich die Qualitt der Dokumentation im Hinblick auf die Anwenderanforderungen?

ist am Ende dieses Kapitels beantwortet und somit neben dem ersten auch der zweite Teil der Entwicklung des Systems abgeschlossen. Die Datenerhebung wurde in zwei folgende Fragestellungen aufgeteilt:

Wie wichtig sind die Anforderungen?Wie gut sind die Anforderungen erfüllt?

63

Bewertung der Qualitt der DokumentationZusammenfassung

Die erste Fragestellung wurde basierend auf der ersten Stufe mit Hilfe der Anforderungsmatrix und der Häuigkeit der Nennungen der User Sto-ries und Einzelnen Anforderungen beantwortet. Das Ergebnis sind die maximal möglichen Werte für jede User Story und Einzelne Anforderung.

Die zweite Fragestellung wurde mit Hilfe einer Analyse beantwortet. Als Ergebnis liegen die erreichten Werte jeder User Story und einzelnen Anforderung vor. Damit kann jede User Story und Einzelne Anforderung bezüglich ihrer Qualität bewertet werden.








Hauptstudie




Wie wichtig sind die Anforderungen?Anforderungsmatrix

Wie gut sind die Anforderungen erfüllt?

Analyse

erreichte Wertemaximale Werte

User StoriesEinzelne Anforderungen

?

Stufe


??

Abb. 17: Stufe 1 und Stufe 2 des entwickelten Systems

65

Identiikation von VerbesserungspotenzialEinführung

9 Identiikation von Verbesserungspotenzial

9.1 Einführung

Die dritte Stufe des Systems, der Identiikation des Verbesserungspoten-zials (IvV), beantwortet die Forschungsfrage:

Wie leite ich aus der bewerteten Qualitt der Dokumentation Ver-besserungspotenzial ab?

Die dritte Stufe des Systems baut auf der zweiten Stufe, der Bewertung der Qualität, auf. Sie zeigt dem Technischen Redakteur auf, wie er Ver-besserungspotenzial identiizieren und Verbesserungsvorschläge ein-bringen kann.


Auch die Überlegungen zur Identiikation von Verbesserungspotenzial ähneln denen in der Ermittlung der Anwenderanforderungen in Kapi-tel 7.2 „Theoretische Vorüberlegungen der Erhebung“. Auch für diese Stufe wurde das Forschungsproblem in Kapitel 6.3 „Forschungsfragen“ bereits behandelt und der Begrif Verbesserung in Kapitel 2.6 „Verbes-serung“ deiniert. Da die dritte Stufe auf der Stufe zur Bewertung der Qualität basiert, wird insbesondere der Begrif Qualitätsverbesserung zugrunde gelegt und wie in der DIN EN ISO 9000:2015-11 in Zusammen-hang mit der Erfüllung der Qualitätsanforderungen gesehen. Der Grad der Erfüllung muss erhöht werden.In der vorherigen Stufe wurde der Grad der Erfüllung mit der Variable Qualität beurteilt. Die Variable wurde in der zweiten Stufe bereits einer Messung zugänglich gemacht.241 Die zentrale Frage der dritten Stufe „Wo gibt es Verbesserungspotenzial?“, ist nur durch die Vorarbeit in den anderen Stufen zu beantworten.Da nur verbessert werden kann, was nicht optimal ist und das Ziel die Erhöhung des Erfüllungsgrades ist, werden aus der vorliegenden bewer-teten Anforderungsmatrix lediglich die Anforderungen herausgeiltert, die im Hinblick auf die Dokumentation des Beispielgerätes mit schlecht (Fak-tor 0) und gut (Faktor 1) bewertet wurden.

241 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 231.

66

Identiikation von VerbesserungspotenzialMethodenauswahl

Um Verbesserungspotenzial identiizieren zu können, macht es insbe-sondere Sinn, die Oberbegrife zu betrachten und die Bedeutung der Anforderungen dem Erfüllungsgrad gegenüber zu stellen. Der Techni-sche Redakteur wird dies in einer kurzen Zeitspanne durchführen, was einer Datenerhebung in Form eines Querschnittdesigns entspricht.242 Bei der Identiikation von Verbesserungspotenzial ist die Grundgesamt-heit ebenso die gesamte Externe Dokumentation. Da der Technische Redakteur die bewertete Anforderungsmatrix aber aus der vorherigen Stufe nimmt, ist die Grundlage dasselbe Messgerät und damit dieselbe Dokumentation.

9.3 Methodenauswahl

Die dritte Stufe des Systems knüpft an die Analyse der vorherigen Stufe an und interpretiert die erreichten und maximalen Werte.Zudem müssen die Daten für die Erhebung in drei Schritten vorbereitet werden. Als Erstes werden die Anforderungen, denen eine 0 und eine 1 zugeordnet wurde, herausgeiltert.Als Zweites muss sich der technische Redakteur für jede Anforderung mit Blick in Quellen, wie S D von G ü über-legen, wie die Dokumentation hinsichtlich der Anforderungen verbessert werden könnte.Als Drittes muss er die Verbesserungsvorschläge in drei Stufen bewer-ten. Er muss ein leicht vergeben für alle Verbesserungsvorschläge, die er selbst umsetzen kann. Mit mittel kann er alle Vorschläge kennzeichnen, die innerhalb der Abteilung umgesetzt werden können und mit schwer alle Vorschläge, die komplexer umzusetzen sind und übergreifende Abspra-chen benötigen. Bei der Erarbeitung der Verbesserungsvorschläge muss der Redakteur kreativ bleiben und Vorschläge notieren, die zu dem aktu-ellen Zeitpunkt „unlösbar“ scheinen.

9.4 Datenerhebung

Die Erhebung erfolgt in zwei Schritten. Der Technische Redakteur muss seinen Blick auf die zusammengefassten Oberbegrife werfen. Er muss die fnf wichtigsten Oberbegrife markieren und zudem die fnf Oberbe-grife, mit dem geringsten Erfllungsgrad.

242 Vgl. Diekmann, A., Empirische Sozialforschung, 2016, S. 304f.

67

Identiikation von VerbesserungspotenzialDatenerfassung

9.5 Datenerfassung

Die Verbesserungsvorschläge müssen notiert werden, um die Nachvoll-ziehbarkeit zu gewährleisten. Auch die markierten Oberbegrife mssen festgehalten werden.

9.6 Datenauswertung

Gibt es dabei Überschneidungspunkte hat der Technische Redakteur das gröate Verbesserungspotenzial bereits identiiziert. Zudem stellen die anderen markierten Punkte wichtiges Verbesserungspotenzial dar.

Er kann die Verbesserungspotenzial entsprechend der Kategorien bezie-hungsweise Oberbegrife, auf die er eingehen möchte, iltern und die Ver-besserungsvorschläge entsprechend exportieren.


Der Technische Redakteure muss die Ergebnisse vorstellen, damit die Dokumentation zur Fernsteuerung von Messgeräten für das ausge-wählte Gerät verbessert werden kann. Dabei sollte er auf den aktuellen State of the Art eingehen und einen Ausblick geben.Zudem kann der Technische Redakteur darauf hinweisen, dass das dreistuige System fr den Dokumentationsbereich Fernsteuerung von Messgeräten auch auf andere Messgeräte anwendbar ist.

9.8 Zusammenfassung

Die Forschungsfrage der dritten Stufe des Systems,

Wie leite ich aus der bewerteten Qualitt der Dokumentation Ver-besserungspotenzial ab?

ist am Ende dieses Kapitels beantwortet und somit die Entwicklung des gesamten Systems abgeschlossen.

68

Identiikation von VerbesserungspotenzialZusammenfassung

Die Datenerhebung wurde in zwei folgende Fragestellungen aufgeteilt:

Welche Anforderungen sind am wichtigsten?Welche Anforderungen haben den geringsten Erfüllungsgrad?

Die erste Fragestellung wurde basierend auf der zweiten Stufe mit Hilfe der maximalen Werte beantwortet.Die zweite Fragestellung wurde mit Hilfe des Verhältnisses zwischen erreichen und maximalen Werten beantwortet.

Die Kombination dieser beiden Fragestellungen liefert die Kategorien, Oberbegrife, User Stories und Einzelnen Anforderungen, deren Verbes-serungspotenzial am größten ist und die Umsetzung deren Verbesse-rungsvorschläge sich am meisten lohnt.








Hauptstudie




Wie wichtig sind die Anforderungen?Anforderungsmatrix

Wie gut sind die Anforderungen erfüllt?

Analyse

erreichte Wertemaximale Werte

User StoriesEinzelne Anforderungen

Welche Anforderungen sind

am wichtigsten?maximale Werte der

User Stories und Einzelne Anforderungen

Welche Anforderungen haben den geringsten

Erfüllungsgrad?Verhältnis: erreichte und maximale

Werte der User Stories und Einzelne Anforderungen

Stufe


inwiefern lohnt sich die Umsetzung der

Verbesserungsvorschläge

Abb. 18: Übersicht des entwickelten Systems

gekürz

te V

ersi

on ohne

Sper

rver

mer

k

daher

ohne Kap

itel 1

0 und 11

103

Diferenzierte Betrachtung des SystemsErmittlung der Anwenderanforderungen

12 Diferenzierte Betrachtung des Systems

12.1 Ermittlung der Anwenderanforderungen

12.1.1 Allgemeine BetrachtungDas System hat seiner ersten Probe, die in Kapitel 11 „Test des Systems am Beispiel Rohde & Schwarz“ beschrieben ist, Stand gehalten.Die Ermittlung der Anwenderanforderungen hat eine Vielzahl von Anfor-derungen der Anwender im Dokumentationsbereich Fernsteuerung von Messgeräten ans Licht gebracht. Lediglich bezüglich des Aufdeckens der verschiedenen Anwendergruppen ist die erste Stufe des Systems an ihre Grenzen gestoßen, weil die Mitarbeiter zum einen viele verschiedene Anwendergruppen genannt haben und zum anderen nur interne Anwen-der, die sich alle als Programmierexperten bezeichnet haben, befragt werden konnten.Eine weitere Herausforderung lag in der Methode Contextual Inquiry. Die Befragung der Anwender an ihrem Arbeitsplatz war sehr aufschluss-reich, durch die bei Rohde & Schwarz existierenden Großraumbüros war der Störfaktor jedoch größer als zuvor erwartet. So konnte nicht ausge-schlossen werden, dass sich weitere Anwender ins Gespräch einschalte-ten. Die Pluralität der Meinungen hat dem Ergebnis aber keinen Nachteil gebracht, weshalb das als wenig problematisch eingestuft wurde. Zudem lag eine Herausforderung im Contextual Inquiry darin, dass eine Viel-zahl an Informationen ans Licht kam, die nicht immer das Forschungsziel betraf. Es war nicht immer leicht, den Befragten in die richtige Richtung zu führen. Auch die in der Vorstudie erarbeitete Anforderungsmatrix stieß teilweise in der Hauptstudie an ihre Grenzen. Für manche Befragte war es schwer, die Anforderungen mit einem ja oder nein zu beantworten, weil sie teilweise sehr individuell und zu utopisch aus Sicht der Anwender waren.Zudem war es schwer, eine Diferenzierung fr jede Anforderung von 1 bis 3 während des Contextual Inquiry und des Usability-Tests durch-zuführen. Wenn nicht anders als von den Versuchspersonen genannt, wurde allen Anforderungen eine 3 zugeordnet. Die Diferenzierung ist im Hinblick auf die standardisierte Abfrage der dabei nicht genannten Anfor-derungen aber sinnvoll. Dadurch konnte eine Gewichtung erzielt werden.Die bereitgestellten Dokumente und Leitfäden konnten zum Großteil

104


eins zu eins eingesetzt werden. Lediglich bei der Vorstudie mussten nach den ersten beiden Gesprächen Anpassungen vorgenommen werden.

12.1.2 Überprüfung der 15 Erfolgsfaktoren nach RWie bereits angesprochen hat sich auch R mit dem Thema Anfor-derungen auseinandergesetzt. Er hat Bausteine des Requirements Engineering auf die Technische Redaktion übertragen und 15 Erfolgsfak-toren eines Anforderungsmodells zusammengestellt.338 Das Modell wird als Leitfaden herangezogen, um das in der Masterarbeit entwickelte Sys-tem diferenziert zu betrachten.

Nr. Erfolgsfaktor nach Ri In der Masterarbeit umgesetzt

1 Eine Anforderung soll gefunden, erfasst und angewandt werden. Für jede Phase muss eine passende Umsetzung gefunden werden.

Durch die Pluralität der Methoden war für jede Stufe des Systems eine zielorientierte Umsetzung möglich.

2 In dem Faktor wird die Bedeutung eines klaren Ziels des Anforde-rungsmodells thematisiert.

Der Faktor wird durch die klar dei-nierte Forschungsfrage erfüllt.

3 R geht auf normative Anforde-rungen ein.Zudem geht er auf das Erheben von Anforderungen beispielsweise mittels Fragebögen und Interviews ein.

Normative Anforderungen wer-den zwar nicht in der ersten Stufe thematisiert, aber in den anderen Stufen des Systems wird ihnen Beachtung geschenkt.Die genannten Methoden wurden auch im System angewandt.

4 Eine Möglichkeit der leistungsfähi-gen Strukturierung ist die Uniied Modeling Language.

Der Standard wurde im System nicht angewandt, auf eine Struktu-rierung wurde dennoch nicht ver-zichtet. Diese wurde mit Hilfe einer Pinnwand umgesetzt.

338 Ried, T., Erfolgreicher Umgang mit Anforderungen, 2017, S. 35f.

105



5 Die Identiikation der Anforderun-gen muss sichergestellt sein.

Das System wird dem Faktor durch das Nummerieren der Anforderun-gen gerecht.

6 Die Anforderungen muss benannt werden.

Auch im System wurden die An-forderungen benannt. Zwar wurde nicht das von R vorgeschlagene System befolgt, aber jede Anforde-rung hat einen kurzen Titel erhalten.

7 Eine Anforderung muss jederzeit verstanden werden können. Eine standardisierte Beschreibung hilft.

Die Anforderungen wurden anhand eines festgelegten Schemas in User Stories beschrieben.

8 R fordert jede Anforderung mit nur einer Forderung zu verbinden.

Das wurde im System nicht konse-quent erfüllt, da Anforderungen zu-sammengefasst wurden. So konnte zwar die Anzahl verringert werden, dies erschwert aber die Überprü-fung des Erfüllungsgrades.

9 Jede Anforderung muss überprüf-bar sein.

Da die Anforderungen von den An-wendern stammen, kann das nicht direkt erfüllt werden.Im System wird die Kreativität des Technischen Redakteurs bezüglich einer Lösung angeregt.

10 Der Erfolgsfaktor liefert keine konkrete Empfehlung, sondern verweist auf das Ziel des Anforde-rungsmodells.

Je nachdem müsste der Detaillie-rungsgrad umgesetzt sein, was je-doch bei Normen nicht immer leicht ist. Im System hängt die Detailtiefe jeder Anforderung von den Anwen-dern ab.

106



11 Anforderungen dürfen sich nicht gegenseitig ausschließen.

Im System war es nicht möglich da-rauf zu achten, da die Anforderun-gen von den Anwendern genannt wurden.

12 Anforderungen mssen klassiiziert und priorisiert werden.

Die beschriebene Priorität wurde in-direkt über die Anzahl der Nennun-gen erhoben und dient im zweiten System als Gewichtungsmaßstab. Zudem wurde eine nicht genannte Klassiikation im System umgesetzt bezüglich Struktur, Inhalt und Form sowie Oberbegrifen.

13 R vertritt die Meinung, dass zu-nächst nicht zu viel über die Reali-sierung nachgedacht werden darf.

Bei der Frage, was sich die Anwen-der wünschen, wurde nicht auf die Realisierbarkeit geachtet.

14 In diesem Faktor wird die Brücke zur Zielgruppe geschlagen. Die-se trift die Entscheidung ber die Qualität des Anforderungsmodells.

Dem Faktor trägt das System voll-ständig Rechnung, dadurch dass es auf den ermittelten Anforderungen der Anwender basiert.

15 Die Anforderungen müssen in einer geeigneten Weise verwaltet wer-den, was insbesondere bei Bezie-hungen untereinander eine Heraus-forderung darstellt.

Im System liegen keine Beziehun-gen vor. Das würde der Forderung der User Stories nach Unabhängig-keit widersprechen. Die Anforderun-gen wurden aber übersichtlich und nachvollziehbar verwaltet.

Tabelle 2: Betrachtung gemß den Erfolgsfaktoren nach Ri

107

Diferenzierte Betrachtung des SystemsBewertung der Qualität

Die Auseinandersetzung mit den 15 Erfolgsfaktoren nach R hat gezeigt, dass der Großteil der Erfolgsfaktoren in der Stufe zur Ermittlung der Anwenderanforderungen bereits umgesetzt wurde.

Dennoch kann die Anleitung im Hinblick auf die Vereinzelung, die Über-prüfbarkeit verbessert werden. Das ist relativ leicht umzusetzen. Anforde-rungen, dürfen nicht mit Hilfe eines „und“ oder „oders“ zusammengefasst werden.Zudem muss öfter auf die Norm ISO/IEC 26514:2008(E) S

- R - verwiesen werden, da sie verschiedene

Möglichkeiten aufzeigt und Ideen liefert, wie Anforderungen getestet wer-den können.

12.2 Bewertung der Qualität

Auch in der zweiten Stufe des Systems, der Bewertung der Qualität der Dokumentation, war die ISO/IEC 26514:2008(E) S -

- R für die Begründung der Entscheidung hilfreich.

Dadurch konnte die Stufe des Systems problemlos durchgeführt werden. Teilweise waren kleine Anpassungen der Anforderungen nötig, aber auch hierbei konnte die Norm unterstützen.Die Bewertung der Qualität war durch die Schafung eines Vergleichs-wertes möglich. Damit wurde das Forschungsziel erreicht.

12.3 Identiikation von Verbesserungspotenzial

Die inale Stufe des Systems konnte ihren Zweck erfllen und Verbes-serungspotenzial aufzeigen. Durch die Kombination mit der Erarbeitung von Verbesserungsvorschlägen, können der Technischen Dokumen-tation abschließend konkrete Pläne zur Umsetzung vorgelegt werden. Dabei hilft die Einteilung der Verbesserungsvorschläge bezüglich der Durchführbarkeit.

109

FazitIdentiikation von Verbesserungspotenzial

13 Fazit

Forschungsziel der Masterarbeit war es, dem Technischen Redakteur eine Antwort auf folgende Forschungsfragen zu liefern, um ihm damit eine Hilfestellung zu geben:

Wie ermittle ich Anwenderanforderungen für den speziellen Doku-mentationsbereich Fernsteuerung von Messgeräten auf eiziente Art, bewerte die Qualität der Dokumentation und leite daraus Ver-besserungspotenzial ab?

Durch die Entwicklung des Systems mit den drei Stufen Ermittlung der Anwenderanforderungen, Bewertung der Qualität und Identiikation von Verbesserungspotenzial wurde das Ziel erreicht und die in dem Bereich bestehende Forschungslücke ein Stück weit geschlossen.Der Technische Redakteur hat mit dem in der Masterarbeit entwickel-ten System eine Hilfestellung in einem Dokumentationsbereich, in dem er bisher wenig Unterstützung hatte. Verschiedene Aspekte der Benut-zerdokumentation und der Anwendungssoftware aus der Normenreihe IEEE 26514 und von G ü konnten auf das System für den speziel-len Dokumentationsbereich Fernsteuerung von Messgeräten transferiert werden. Um ein möglichst diferenziertes Bild der Anwenderanforderun-gen zu ermöglichen, wurden verschiedene Methoden kombiniert.

Um den Mehrwert für den Technischen Redakteur möglichst groß zu gestalten, wurde für die Umsetzung des Systems eine Schritt für Schritt-Anleitung geliefert. Zudem wurde das System bereits in der Praxis erprobt, indem es erfolg-reich auf Rohde & Schwarz und ein Beispielgerät, den R&S®FSW, ange-wandt wurde. Damit wird dem Technischen Redakteur für die Umsetzung in seinem Unternehmen ein Beispiel als Orientierungsrahmen an die Hand gegeben.

Der Test am Beispiel Rohde & Schwarz zeigt, dass die Dokumentation zur Fernsteuerung von Messgeräten stark von äuaerlichen Einlssen und Rahmenbedingungen abhängig ist. Beispielhaft ist die Software- Entwicklung der Messgeräte zu nennen, da bei einer Dokumentation, die

110

FazitIdentiikation von Verbesserungspotenzial

die Anforderungen der Anwender möglichst gut erfüllen soll, ein funktio-nierender Informationsluss zwischen Software-Redaktion und Software- Dokumentation essentiell ist.Zudem zeigen die nach Durchfhrbarkeit gestafelten Verbesserungsvor-schläge, dass nicht alles in der Hand der Technischen Redaktion liegt. Im Hinblick auf die Suche beispielsweise ist technisches Know-How anderer Abteilungen nötig, um die Anwenderanforderungen erfüllen zu können.

Verbesserungsvorschläge der Oberbegrife Beispiele, Handhabung und NavMittel haben das größte Verbesserungspotenzial bei der Dokumen-tation des R&S®FSW.Unter den Oberbegrif Beispiele sind alle User Stories beziehungsweise Einzelne Anforderungen gefasst, die etwas mit Beispielen zu tun haben. Zwei Verbesserungsvorschläge sehen beispielsweise vor, dass jedes Kommando durch einen Beispielcode veranschaulicht wird und dieser Beispielcode, falls er aus mehr als drei Bestandteilen besteht und damit komplexer ist, erklärt wird.Unter den Oberbegrif Handhabung fallen alle User Stories beziehungs-weise Einzelne Anforderungen, die dem Anwender die Anwendung der Dokumentation erleichtern. Zum Beispiel besteht ein Verbesserungs-vorschlag um die benötigte Information schneller Auinden zu können darin, die Informationen zu- und aufklappen und damit leichter handeln zu können.Unter den Oberbegrif NavMittel fallen alle User Stories beziehungsweise Einzelne Anforderungen, die Navigationsmittel (außer Links) thematisie-ren. Ein Verbesserungsvorschlag sieht vor, in jeder Ansicht der Doku-mentation Breadcrumbs einzubinden und damit das Zurücknavigieren zu erleichtern.

Abschließend ist zu sagen, dass dem Unternehmen Rohde & Schwarz mit Hilfe des in der Masterarbeit entwickelten Systems Verbesserungs-potenzial der Dokumentation zur Fernsteuerung des R&S®FSW aufge-zeigt und konkrete Verbesserungsvorschläge vorgelegt werden konnten..

111

AusblickIdentiikation von Verbesserungspotenzial

14 Ausblick

Da mit der fortschreitenden Digitalisierung die Bedeutung der Automa-tionsindustrie stetig zunimmt, wird die Fernsteuerung von Messgeräten immer wichtiger werden.Damit sich Messgerätehersteller im Markt durchsetzen können, spielt die Kundenzufriedenheit eine große Rolle, wozu die Dokumentation zur Fernsteuerung der Messgeräte einen wichtigen Beitrag leistet. Die Anwender erwarten schnell und unkompliziert eine Hilfestellung zu ihrem Problem zu inden, um ihre Arbeit fortfhren zu können.

Eine Aufgabe der Technischen Redaktion ist es die verschiedenen Anfor-derungen unterschiedlicher Anwendergruppen zu erfüllen. Durch die Besonderheiten in diesem Bereich, wie die enorme Bedeutung einer fehlerfreien Dokumentation sowie die wenig intuitive Bedienung, stehen die Technischen Redakteure vor einer besonderen Herausforderung. Als Hilfestellung für die Herausforderung liefert die Masterarbeit ein System, welches dem Technischen Redakteur ermöglicht, die bestehende Doku-mentation im Hinblick auf die Anwenderanforderungen zu verbessern.

Eine weitere Herausforderung liegt darin, dass sich die Technik der Messgeräte stetig weiterentwickelt. Dadurch werden beispielsweise Sicherheitsaspekte, wie der geschtzte Zugrif auf Messgeräte, immer wichtiger.

Zudem muss die Technische Redaktion die Form der Dokumentation immer wieder in Frage stellen: Sind PDFs noch zeitgemäß? Könnte der Anwender die gesuchte Information nicht schneller inden?Eine Weiterverfolgung des Gedankens führt schnell zu einer intelligenten Suche, ähnlich der Google-Suche. Wäre es nicht toll, wenn der Anwen-der seine individuelle Frage in die Dokumentation eingeben könnte und in dem Bruchteil einer Sekunde die Antwort erhalten würde? Wenn er zusätzlich Informationen angezeigt bekommt, die ihn interessieren könnten? Beispielsweise eine eizientere Lösung seiner aktuellen Mes-sabläufe? Oder sogar das Redaktionssystem aus den Anfragen des Anwenders lernt und immer besser passende Antworten gibt? Und über einen Sprachassistenten ähnlich wie Amazon Echo laufen kann?

112

AusblickIdentiikation von Verbesserungspotenzial

Die Fragen zeigen, dass mit dem Fortschritt der Technik die Anwender immer neue Forderungen an die Dokumentation zur Fernsteuerung von Messgeräten haben werden. Lösungen im derzeit machbaren Bereich umzusetzen, beispielsweise mit einem umfangreichen Metadaten-Konzept, könnte der Bestandteil einer weiteren Abschlussarbeit sein. Um das Konzept den Anforderungen der Anwender anzupassen, könnte das System auf verschiedene Unterneh-men angewandt werden, um ein diferenziertes Bild als Grundlage zu haben.

Eine an die Masterarbeit anschließende Arbeit könnte das entwickelte System im Hinblick auf die Ermittlung der verschiedenen Anwender-gruppen im Dokumentationsbereich Fernsteuerung von Messgeräten optimieren.

In einer weiteren Abschlussarbeit bei Rohde & Schwarz könnte die erste Stufe des Systems, die Ermittlung der Anwenderanforderungen, mit externen Anwender durchgeführt werden. Es wäre interessant die Anfor-derungen der internen Anwender, die in der Masterarbeit erhoben wur-den, mit den Anforderungen der externen Anwender zu vergleichen.

Zudem könnte in einer weiteren Abschlussarbeit Verbesserungspoten-zial für sämtliche Messgeräte von Rohde & Schwarz aufgezeigt werden. Dabei könnte an das Ergebnis der ersten Stufe des Systems angeknüpft werden.

Die verschiedenen Anknüpfungspunkte zeigen, dass es noch viel For-schungspotenzial im Dokumentationsbereich Fernsteuerung von Mess-geräten gibt.

Die Forschungslücke konnte durch die Masterarbeit

Anwenderanforderungen und Qualittskriterien im Dokumentationsbereich Fernsteuerung von Messgerten –


ein Stück weit geschlossen werden.

A-1

Anhangsverzeichnis

Anhangsverzeichnis

A: Übersicht des elektronischen Anhangs .....................................A-2

B: Schritt für Schritt-Anleitungen ....................................................A-3

Stufe 1: Ermittlung der Anwenderanforderungen ................................A-3

1 Vorstudie ...............................................................................A-3

2 Hauptstudie: Einführung ....................................................A-10

3 Hauptstudie: Contextual Inquiry .......................................A-10

4 Hauptstudie: Usability-Test ...............................................A-14

5 Hauptstudie: Anforderungsmatrix ....................................A-17

6 Dokumente ..........................................................................A-19

Stufe 2: Bewertung der Qualität ........................................................A-25

1 Planung und Vorbereitung .................................................A-25

2 Datenerhebung beziehungsweise - erfassung ................A-27

3 Datenauswertung ................................................................A-28

4 Berichterstattung ................................................................A-28

Stufe 3: Identiikation von Verbesserungspotenzial ...........................A-29

1 Planung und Vorbereitung .................................................A-29

2 Datenerhebung beziehungsweise - erfassung ................A-29

3 Datenauswertung ................................................................A-29

4 Berichterstattung ................................................................A-29

A-2

A: Übersicht des in elektronischen Anhangs

A: Übersicht des in elektronischen Anhangs

Der Teil A des Anhangs liegt ausschließlich in digitaler Form auf einem USB-Stick am Ende der Arbeit vor. Dies gilt für alle Dokumente, die im Text mit dem Beginn „Anhang A“ zitiert wurden.

Der Aufbau der Ordnerstruktur und der Aufbau der Zitate sind aufeinan-der abgestimmt.

Im Anhang beinden sich folgende Dateien, Ordner beziehungsweise Unterordner:

Masterarbeit_mit Sperrvermerk.pdf

Masterarbeit_ohne Sperrvermerk.pdf

Internetquellen

R&S_Graue Literatur

R&S_Stufe 1_Ermittlung der Anwenderanforderungen (EdA)

Hauptstudie

Vorstudie

R&S_Stufe 2_Bewertung der Qualitt (BdQ)

R&S_Stufe 3_Identiikation von Verbesserungspotenzial (IvV)

A-3

B: Schritt für Schritt-AnleitungenStufe 1: Ermittlung der Anwenderanforderungen

B: Schritt für Schritt-Anleitungen

Stufe 1: Ermittlung der Anwenderanforderungen

1 Vorstudie

1.1 Einführung

Die folgende Schritt für Schritt-Anleitung erklärt, wie Sie die Anforderun-gen der Anwender im Dokumentationsbereich Fernsteuerung von Mess-geräten empirisch ermitteln können.

Greifen Sie zunächst im Rahmen einer Vorstudie auf das im Unterneh-men vorhandene Wissen zurück. Verschiedene Abteilungen arbeiten mit Anwendern zusammen und insbesondere langjährige Mitarbeiter haben ein relativ konkretes Bild der Anforderungen der Anwender im Kopf. Durch eine Befragung dieser mit Hilfe eines Problemzentrierten Inter-views können Sie eine erste Wissensgrundlage schafen, noch bevor Sie mit den Anwendern selbst sprechen.Die Vorstudie wird Ihnen eine erste Idee davon geben, was sich Ihre Anwender in Hinblick auf die Kategorien Struktur, Inhalt und Form wnschen. Die folgenden Deinitionen der Begrife helfen Ihnen bei der Einordnung der Anforderungen. Die Deinitionen sind der ISO/IEC 26514:2008(E)S S E - R

D D U D entnom-men. Wie der Titel schon sagt, beschäftigt sich die Norm mit Anforderun-gen an Technische Redakteure im Bereich Software- Dokumentation.Unter Struktur wird in der Norm die Art und Weise verstanden, wie die Dokumentation unterteilt ist und in welcher Reihenfolge diese Teile ste-hen. Beispielsweise kann die Dokumentation in einem einzigen Doku-ment untergebracht sein oder in mehreren Teilen. Dabei ist beispielsweise eine Anforderung an die Struktur, dass sie dem Benutzer hilft, den Inhalt zu inden und zu verstehen.Der Inhalt wird durch seinen Zweck deiniert. Er dient entweder als Anlei-tung und erklärt, wie die Software verwendet werden muss, oder als Referenz und zeigt, wie erlernte Inhalte wieder ins Gedächtnis gerufen werden können. Dabei kann die Anleitung entweder informations- oder aufgabenorientiert sein. Die Referenz könnte kontextsensitiv und in die Software eingebettet sein. Beispiele und Illustrationen helfen beim Verstehen.Unter der Form wird zum einen das Medium der Dokumentation ver-standen. Generell wird zwischen Print- und OnScreen-Dokumentation unterschieden. Zum anderen gehören nach der Deinition Stil, Typograie sowie graphischen Elemente zur Form.

A-4


1.2 Planung und Vorbereitung

Erstellen Sie als Vorbereitung eine Liste aller Mitarbeiter des Unter-nehmens, die durch ihre Stelle im Unternehmen die Anforderungen der Anwender kennen. Befragen Sie dazu auch Ihre Kollegen in der Techni-schen Dokumentation. Vereinbaren Sie anschließend Termine.

Für das Problemzentrierte Interview benötigen Sie folgende Dokumente. Diese inden Sie in Kapitel 6 „Dokumente“:• Kurzfragebogen

Fragen zur Tätigkeit des Interviewpartners im Allgemeinen• Leitfaden

Orientierungsrahmen für Sie zur Durchführung des Interviews• Postskript

Festhalten der Rahmenbedingungen des Gesprächs sowie der Gespräche außerhalb der Aufnahme

Stellen Sie ein Gerät zur Tonaufnahme bereit, um das Gespräch anschließend transkribieren zu können. Das ist für die wissenschaftliche Nachprüfbarkeit und auch für die Auswertung unabdingbar.

Im Folgenden wird die Vorgehensweise beim Interview zum Verständnis ausführlich erklärt. Im eigentlichen Interview unterstützt Sie der Leitfa-den. Ein Vorteil der Methode des Problemzentrierten Interviews ist, dass Sie den Leitfaden nicht starr über die gesamte Erhebungsphase verwen-den müssen. Wenn Sie merken, dass Sie mit dem zur Verfügung gestell-ten Leitfaden nicht zu dem gewünschten Ergebnis kommen, können Sie ihn überarbeiten.

Führen Sie vor der eigentlichen Erhebung einen Pretest durch um sicher-zustellen, dass die bereitgestellten Dokumente auf Ihr Unternehmen anwendbar sind. Zudem hilft Ihnen diese Vorgehensweise dabei, sich mit dem Ablauf des Interviews vertraut zu machen sowie die benötigte Zeit pro Interview einschätzen zu können.

1.3 Datenerhebung

1.3.1 Einleitung des Interviews

Danken Sie dem Befragten zunächst für seine Teilnahmebereitschaft und stellen Sie sich vor. Erklären Sie ihm anschließend, dass es Ziel des Interviews ist, ein möglichst konkretes Bild der Anwenderanforde-rungen im Dokumentationsbereich Fernsteuerung von Messgeräten zu bekommen. Sie befragen ihn als wichtige Quelle in seiner Funktion im Unternehmen. Dadurch verhelfen Sie dem Befragten zu einem gewissen Expertenstatus und dieser fühlt sich im Interview wohler. Informieren Sie ihn über die Gesprächsdauer und bitten Sie ihn möglichst detailliert zu

A-5


erzählen. Weisen Sie ihn auf die Tonbandaufnahme für die Transkrip-tion und die vertrauliche Behandlung seiner Daten hin. Geben Sie dem Befragten die Möglichkeit, Fragen zu stellen.

1.3.2 Kurzfragebogen

Gehen Sie vor dem eigentlichen Interview den Kurzfragebogen gemein-sam mit dem Befragten durch.Diese Vorgehensweise bietet einen guten Einstieg ins Thema und bringt den Befragten dazu, Gedächtnisinhalte abzurufen.

Starten Sie anschließend die Tonaufnahme.

1.3.3 Allgemeine Sondierung

Stimulieren Sie in der Allgemeinen Sondierung die Erzählphase des Befragten. Erklären Sie ihm hierzu die Gründe für die Befragung. Das gewährleistet einen standardisierten Einstieg ins Thema.

1.3.4 Speziische Sondierung

Die Speziische Sondierung ist zugleich die Erzählphase. Beginnen Sie mit einer der vier Erzählauforderungen des Leitfadens. Die Reihenfolge ist nicht wichtig, es müssen lediglich alle Aspekte abgedeckt werden.Konzentrieren Sie sich auf die Erzählungen des Befragten. Um das rich-tige Verständnis zu gewährleisten, beispielsweise der Kategorie, welche die Anforderung betrift, mssen Sie mit Hilfe folgender Möglichkeiten aktiv teilnehmen:• Zurückspiegelung

Fassen Sie die Aussage des Befragten in Ihren eigenen Worten zusammen. Dadurch haben Sie die Möglichkeit zu überprüfen, ob Sie den Befragten richtig verstanden haben.

• VerständnisfrageFragen Sie nach, wenn Sie eine Aussage des Befragten nicht ver-standen oder mehr Informationen zu einem Thema haben möchten.

• KonfrontationBemerken Sie Widersprüche in der Aussage des Befragten, können Sie ihn damit konfrontieren. Dabei ist Fingerspitzengefühl gefragt, denn unter dieser Möglichkeit kann das Interviewklima stark leiden.

1.3.5 Direkte Fragen

Nachdem der Befragte seine Erzählungen abgeschlossen hat, können Sie direkte Fragen stellen und dadurch sicherstellen, dass alle Erzählauf-forderungen vollständig abgedeckt wurden.

Stoppen Sie anschließend die Tonaufnahme.

A-6


1.3.6 Abschluss

Danken Sie dem Befragten, dass er an dem Interview teilgenommen hat. Erklären Sie ihm, wie Sie in der Hauptstudie vorgehen werden. Fragen Sie ihn zum Abschluss, ob er Ihnen weitere Interviewpartner empfehlen kann und ob er Dateien, z. B. von Befragungen, hat, die Ihnen weiterhel-fen könnten. Fragen Sie ihn auch, ob er Ihnen den Kontakt zu Anwen-dern vermitteln und Ihnen Tipps für die Beobachtungen in der Hauptstu-die geben kann.

1.3.7 Postskript

Füllen Sie direkt im Anschluss an das Gespräch das Postskript aus, um Informationen über die Rahmenbedingungen und die Gespräche vor und nach Einschalten des Aufnahmegerätes festzuhalten.

1.3.8 Eventuelle Änderung des Fragebogens

Ein Vorteil des Problemzentrierten Interviews ist es, dass der Leitfaden während der Erhebung angepasst werden kann. Wenn Sie merken, dass Erzählauforderungen nicht zu Aussagen bezglich des Forschungsziels führen, können Sie diese anpassen.

1.4 Datenerfassung

Neben dem ausgefüllten Kurzfragebogen und dem Postskript liegt Ihnen am Ende jedes Interviews eine Tonaufzeichnung vor, welche Sie transkri-bieren müssen.

1.5 Datenauswertung- und analyse

Für die Auswertung benötigen Sie eine Pinnwand beziehungsweise eine gröaere Wandläche. Zudem benötigen Sie Karteikarten (einfarbig und bunt) und Pinnnadeln beziehungsweise Klebestreifen. Organisieren Sie zudem bunte Aufkleber entsprechend der Farben der Karteikarten. Unter dem jeweiligen Auswertungsschritt wurde eine Graik angefgt, die veranschaulicht, wie die Pinnwand etwa aussehen sollte.

1. Überblick der GesprchsverlufeBetrachten Sie die schriftlich vorliegenden Interviews einzeln und markie-ren Sie die Aussagen zu den Anwenderanforderungen sowie den gege-benenfalls genannten verschiedenen Anwendergruppen. Notieren Sie aus dem dazugehörigen Postskript heraus den Gesprächsrahmen auf eine Karteikarte und pinnen Sie diese links, fast ganz oben in die Ecke. Eine horizontale Reihe müssen Sie für später noch freilassen. Erstellen Sie zudem aus dem dazugehörigen Kurzfragebogen einen Steckbrief und notieren Sie diesen auf eine Karteikarte. Pinnen Sie diese rechts

A-7


neben den Gesprächsrahmen.Rechts daneben pinnen Sie, jeweils auf einer Karteikarte notiert, die genannten Anwendergruppen. Falls in dem Interview auf die Anforderun-gen verschiedener Anwendergruppen eingegangen wurde, müssen Sie mehrere Schienen für die einzelnen Anwendergruppen anlegen, um die Anforderungen entsprechend zuordnen zu können. Schreiben Sie die markierten Anwenderanforderungen jeweils auf eine Karteikarte und fügen Sie, falls genannt, die Gründe hinzu. Wenn sich Anforderungen im Gespräch wiederholen, wählen Sie die Stelle aus, an der sie am besten beschrieben sind. Pinnen Sie Anforderungen gemäß des Gesprächsverlaufs und der Anwendergruppe rechts neben diese. Wiederholen Sie den Vorgang für alle Interviews.

Interviews

1

Anwender-gruppen

Gesprchsverlufe

Gesprächs-rahmen 1

Steck-brief 1

Anwender-gruppe 1.1

Anwender-gruppe 1.2

2Gesprächs-rahmen 2

Steck-brief 2

Anwender-gruppe 2


Steck-brief 3

Anwender-gruppe 3.1

Anwender-gruppe 3.2

Anwender-gruppe 3.3

Anforderung1.1.1

Anforderung1.2.1

Anforderung2.1

Anforderung3.1.1

Anforderung3.2.1

Anforderung3.3.1

Anforderung1.1.2

Anforderung1.1.3

Anforderung1.1.4

Anforderung1.2.2

Anforderung1.2.3

Anforderung2.2

Anforderung2.3

Anforderung2.4

Anforderung3.1.1

Anforderung3.2.2

Anforderung3.3.2

Anforderung3.2.3

Anforderung3.2.4

Anforderung3.3.3

2. Zuordnen der KategorienLegen Sie die Aufkleber in drei verschiedenen Farben bereit. Legen Sie für jede der drei Kategorien Struktur, Inhalt und Form eine Farbe fest. Ordnen Sie abschließend alle Anforderungen der Gesprächsverläufe einer der Kategorien Struktur, Inhalt und Form zu, indem Sie auf jede Karteikarte einen entsprechenden Aufkleber kleben.

Interviews

1

Anweder-gruppen

Gesprchsverlufe

Gesprächs-rahmen 1

Steck-brief 1

Anwender-gruppe 1.1

Anwender-gruppe 1.2


Steck-brief 2

Anwender-gruppe 2


Steck-brief 3

Anwender-gruppe 3.1

Anwender-gruppe 3.2

Anwender-gruppe 3.3

Anforderung1.1.1

Anforderung1.2.1

Anforderung2.1

Anforderung3.1.1

Anforderung3.2.1

Anforderung3.3.1

Anforderung1.1.2

Anforderung1.1.3

Anforderung1.1.4

Anforderung1.2.2

Anforderung1.2.3

Anforderung2.2

Anforderung2.3

Anforderung2.4

Anforderung3.1.1

Anforderung3.2.2

Anforderung3.3.2

Anforderung3.2.3

Anforderung3.2.4

Anforderung3.3.3

FormInhaltStruktur

A-8


3. Erstellen einer AnforderungsmatrixDer erstellte Überblick über die Gesprächsverläufe ermöglicht Ihnen eine Anforderungsmatrix zu erstellen. Gehen Sie dazu die Gesprächsverläufe eine Anforderung nach der anderen durch. Erstellen Sie für jede neue Anforderung eine neue Karteikarte in der entsprechenden Farbe der Kategorie der Anforderung. Stoßen Sie auf Anforderungen, die bereits auf anderen Karteikarten niedergeschriebenen Anforderungen ähneln oder sich unter einen gemeinsamen Anforderungsbereich fassen lassen, fügen Sie diese Anforderung zu der bereits existierenden dazu. Setzen Sie pro Nennung in den Gesprächsverläufen einen Strich auf die Karte.

Durch dieses Vorgehen erhalten Sie einen Überblick über alle ange-sprochenen Anwenderanforderungen während aller Gesprächsverläufe, deren Häuigkeit und die Verteilung auf die Kategorien. Um die Häuigkeit der Nennungen klarer hervorzuheben, können Sie die Anforderungen entsprechend dieser von oben nach unten anordnen.

Interviews

1

Anweder-gruppen

Gesprchsverlufe

Gesprächs-rahmen 1

Steck-brief 1

Anwender-gruppe 1.1

Anwender-gruppe 1.2


Steck-brief 2

Anwender-gruppe 2


Steck-brief 3

Anwender-gruppe 3.1

Anwender-gruppe 3.2

Anwender-gruppe 3.3

Anforderung1.1.1

Anforderung1.2.1

Anforderung2.1

Anforderung3.1.1

Anforderung3.2.1

Anforderung3.3.1

Anforderung1.1.2

Anforderung1.1.3

Anforderung1.1.4

Anforderung1.2.2

Anforderung1.2.3

Anforderung2.2

Anforderung2.3

Anforderung2.4

Anforderung3.1.1

Anforderung3.2.2

Anforderung3.3.2

Anforderung3.2.3

Anforderung3.2.4

Anforderung3.3.3

FormInhaltStruktur

Anforderungsmatrix

Anforderung AIII

Anforderung BII

Anforderung DII

Anforderung CI

Anforderung HI

Anforderung III

Anforderung FI

Anforderung JII

Anforderung EII

Anforderung GIIII

4. Klassiikation des Materials nach den AnwendergruppenKonzentrieren Sie sich auf die verschiedenen Anwendergruppen. Betrach-ten Sie dafür zunächst die Steckbriefe der einzelnen Interviews und fas-sen Sie die Anwendergruppen auf Karteikarten zusammen. Pinnen Sie die Anwendergruppen über die Anforderungsmatrix und ordnen Sie die Einzelnen Anforderungen den Anwendergruppen zu. Markieren Sie die Anforderungen, die auf mehrere Anwendergruppen zutrefen. Beachten Sie hierbei, dass die verschiedenen genannten Anwendergruppen eine subjektive Einschätzung der Mitarbeiter sind. Die Nennungen ermögli-chen es Ihnen aber eine These über die Anwendergruppen aufzustellen, die Sie in der Hauptstudie überprüfen können.

A-9


Interviews

1

Anweder-gruppen

Gesprchsverlufe

Gesprächs-rahmen 1

Steck-brief 1

Anwender-gruppe 1.1

Anwender-gruppe 1.2


Steck-brief 2

Anwender-gruppe 2


Steck-brief 3

Anwender-gruppe 3.1

Anwender-gruppe 3.2

Anwender-gruppe 3.3

Anforderung1.1.1

Anforderung1.2.1

Anforderung2.1

Anforderung3.1.1

Anforderung3.2.1

Anforderung3.3.1

Anforderung1.1.2

Anforderung1.1.3

Anforderung1.1.4

Anforderung1.2.2

Anforderung1.2.3

Anforderung2.2

Anforderung2.3

Anforderung2.4

Anforderung3.1.1

Anforderung3.2.2

Anforderung3.3.2

Anforderung3.2.3

Anforderung3.2.4

Anforderung3.3.3

FormInhaltStruktur

Anforderungsmatrix

Anforderung AIII

Anforderung BII

Anforderung DII

Anforderung CI

Anforderung HI

Anforderung III

Anforderung FI

Anforderung JII

Anforderung EII

Anforderung GIIII

Anwender-gruppe a

Anwender-gruppe b

Anwender-gruppe c

X X

X

X

X

X X X

X

X

X X X

X

X

X

X

5. Anwenderorientierte DarstellungNach dem Herausarbeiten der Gesprächsverläufe, der Anforderungs-matrix sowie der Anwendergruppen können Sie erste Aussagen zu den Anwenderanforderungen ableiten. Beispielsweise könnte das so ausse-hen: Ein Anwender der Anwendergruppe 1 will A 8 in der Dokumentation erfllt sehen, damit er sich schneller zurechtindet.Diese Vorgehensweise hilft Ihnen sich noch einmal abschließend mit den Interviews zu beschäftigten und die Ergebnisse zusammenzufassen. Das erleichtert es Ihnen, Thesen zu entwickeln, die Sie in der Hauptstu-die im direkten Kontakt mit den Anwendern überprüfen können. Stellen Sie Thesen zu den Anforderungen der Anwender und den verschiedenen Anwendergruppen auf. Erstellen Sie eine Tabelle, die Sie abhaken kön-nen, um die Anwenderanforderungen in der Hauptstudie überprüfen zu können. Dies dient Ihnen als Leitfaden in der Hauptstudie.

Struktur

Anforderungsmatrix

Anforderung A

Anforderung B

Anforderung D

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3

Anforderung relevant?

Falls „ja“ Inhalt

Anforderung C

Anforderung H

Anforderung I

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3


Falls „ja“ Form

Anforderung E

Anforderung G

ja nein 1 2 3

ja nein 1 2 3


Falls „ja“

Anforderung F

Anforderung J

ja nein 1 2 3

ja nein 1 2 3

1: weniger wichtig 2: wichtig 3: sehr wichtig


Fassen Sie nach dem Abschluss der Vorstudie Ihr Vorgehen und Ihre Ergebnisse kurz zusammen und präsentieren Sie diese Ihren Kollegen. Eine Diskussion zu diesem frühen Zeitpunkt kann zu einer Optimierung der Ergebnisse in Hinblick auf die Hauptstudie führen.

A-10


2 Hauptstudie: Einführung

In der Hauptstudie stehen die Anwender selbst im Fokus. Mit Hilfe der Methode des Contextual Inquiry können Sie Beobachtung und Befragung kombinieren. Dies bringt den Vorteil, dass die Anwender während der Tätigkeit auch Anforderungen benennen, welche diese in einer Befra-gung möglicherweise nicht direkt abrufen könnten. Führen Sie zudem einen Usability-Test durch um weitere verdeckte Anforderungen ofenzu-legen zu können.Ziel der Hauptstudie ist es, die These zu den Anwendergruppen und Anforderungen aus der Vorstudie zu überprüfen, zu konkretisieren und zu ergänzen. Dabei helfen Ihnen User Stories. Diese Methode stammt aus der Software-Entwicklung und wird dort dazu verwendet, die Anfor-derungen der User an eine neue Software festzuhalten.

3 Hauptstudie: Contextual Inquiry


Erstellen Sie eine Liste aller Anwender, die Sie kontaktieren können. Beziehen Sie dabei mögliche Nennungen aus den Interviews der Vor-studie mit ein und befragen Sie ihre Kollegen in der Technischen Doku-mentation. Versuchen Sie die in Ihrer These zu den Anwendergruppen vorkommenden Gruppen möglichst gut durch verschiedene Anwender abzudecken.Fragen Sie die Anwender, ob Sie sie am Arbeitsplatz besuchen dürfen, um sie bei ihrer Arbeit mit der Dokumentation der Fernsteuerung der Messgeräte zu beobachten und Fragen zu stellen. Erklären Sie ihnen zudem, dass Sie die Gespräche mit dem Tonaufnah-megerät aufzeichnen werden. Falls die Anwender dem nicht zustimmen, müssen Sie das Gespräch absagen. Versuchen Sie die Anwender von der Teilnahme zu überzeugen, in dem Sie ihnen vermitteln, dass auch sie auch von der Befragung proitieren.Vereinbaren Sie anschließend Termine mit den Anwendern.

Für die Durchführung benötigen Sie folgende Dokumente, die Sie in Kapi-tel 6 „Dokumente“ inden. Ihre individuelle Anforderungsmatrix haben Sie als Abschluss der Vorstudie selbst erstellt.• Kurzfragebogen

Fragen zur Tätigkeit im Allgemeinen, gegebenenfalls ergänzen durch eine Abfrage der These zu den Anwendergruppen

• Interview-LeitfadenGedächtnisstütze und Orientierungsrahmen

• Anforderungsmatrix der VorstudieLeitfaden

• PostskriptNotizen zur Beobachtung

A-11


Stellen Sie ein Gerät zur Tonaufnahme bereit, damit Sie das Gespräch transkribieren zu können. Dies ist für die wissenschaftliche Nachprüfbar-keit und die Auswertung unabdingbar.Im Folgenden wird die Vorgehensweise beim Interview ausführlich erklärt. Im eigentlichen Interview unterstützt Sie der Leitfaden.

Führen Sie vor der eigentlichen Erhebung einen Pretest durch, um sicherzustellen, dass die bereitgestellten Dokumente auf Ihr Unterneh-men anwendbar sind. Zudem hilft Ihnen diese Vorgehensweise dabei, sich mit dem Ablauf des Interviews vertraut zu machen sowie die benö-tigte Zeit pro Interview einschätzen zu können.

3.2 Datenerhebung

3.2.1 Einleitung: Conventional Interview

Danken Sie dem Befragten in der Einleitung zunächst für seine Teilnah-mebereitschaft und stellen sich bei ihm vor. Erklären Sie ihm anschlie-ßend, dass es Ziel des Interviews ist, ein möglichst konkretes Bild der Anwenderanforderungen im Dokumentationsbereich Fernsteuerung von Messgeräten zu bekommen. Bitten Sie den Anwender bei seiner Arbeit laut zu denken. Weisen Sie ihn auf die Tonbandaufnahme für die Tran-skription und die vertrauliche Behandlung seiner Daten hin. Geben Sie dem Befragten die Möglichkeit, Fragen zu stellen.


Gehen Sie vor dem eigentlichen Interview den Kurzfragebogen mit dem Befragten durch. Diese Vorgehensweise bietet einen guten Einstieg ins Thema und bringt den Befragten dazu, Gedächtnisinhalte abzuru-fen. Außerdem bekommen Sie eine kurze Zusammenfassung seiner Tätigkeit.

3.2.3 Transition

Erklären Sie dem Anwender die Regeln der angewandten Methode Con-textual Inquiry. Dieser Teil ist kurz, aber wichtig, weil Sie während der Beobachtung soziale Normen brechen müssen. Fällt Ihnen ein interes-santer Aspekt auf, müssen Sie den Anwender unterbrechen, bevor die-ser zum nächsten Punkt weitergeht. Warnen Sie den Anwender daher vor, um ihn nicht zu verwirren.

Starten Sie anschließend die Tonaufnahme.

A-12


3.2.4 Contextual Interview

Fordern Sie den Anwender auf Ihnen zu zeigen, wie er typischerweise mit der Dokumentation zur Fernsteuerung der Messgeräte arbeitet. Bit-ten Sie ihn erneut darum laut zu denken. Nehmen Sie die Rolle eines Lehrlings ein, das heißt, beobachten Sie den Anwender aufmerksam und stellen Sie ihm Verständnisfragen. Ihre Rolle geht aber darüber hinaus. Interpretieren Sie das Verhalten der Anwender bezüglich deren Anfor-derungen und sprechen Sie diese aus. So können Sie die Anforderun-gen noch während der Durchführung im Gespräch mit dem Anwender besprechen und er kann Ihnen weitere Punkte direkt zeigen.Behalten Sie stets Ihr Forschungsziel vor Augen und weisen Sie den Anwender immer wieder darauf hin. So vermeiden Sie es für Ihre Unter-suchung irrelevante Informationen zu bekommen.Die Anforderungsmatrix aus der Vorstudie dient Ihnen als Unterstützung. Denken Sie an die User Stories, die Sie nach dem Interview erstellen wollen. Das hilft Ihnen dabei, die relevanten Informationen abzufragen.

3.2.5 Wrap-Up

Fassen Sie die Vorgehensweise und Anforderungen in Ihren eigenen Worten zusammen, um das richtige Verständnis zu prüfen. Des Weiteren können Sie in diesem Teil noch ofene Punkte klären, z. B. wie wichtig dem Anwender die Anforderungen sind, die Sie während der Beobach-tung in der Anforderungsmatrix notiert und aufgenommen haben.

Stoppen Sie anschließend die Tonaufnahme.

3.2.6 Abschluss

Danken Sie dem Befragten, dass er am Contextual Inquiry teilgenommen hat. Fragen Sie den Anwender, ob er auch am Usability-Test teilnehmen würde. Vereinbaren Sie einen weiteren Termin, um gegebenenfalls den Usability-Test durchzuführen und die Anforderungsmatrix abzufragen.

3.2.7 Postskript

Füllen Sie direkt im Anschluss an das Gespräch das Postskript aus, um Informationen über die Rahmenbedingungen und die Gespräche vor und nach Einschalten des Aufnahmegerätes festzuhalten.

3.3 Datenerfassung

Neben dem ausgefüllten Kurzfragebogen und dem Postskript liegt Ihnen am Ende jedes Interviews eine Tonaufzeichnung vor, welche Sie für die Auswertung vollständig transkribiert müssen. Scannen Sie alle Doku-mente ein.

A-13



Sie benötigen für die Auswertung eine Pinnwand beziehungsweise eine gröaere Wandläche. Zudem benötigen Sie einfarbige Karteikarten und Pinnnadeln beziehungsweise Klebestreifen. Drucken Sie alle Transkripte aus und legen Sie für jeden Anwender die Anforderungsmatrix bereit.

1. Überblick der Contextual InterviewsNotieren Sie aus dem zum Interview gehörigen Postskript heraus den Gesprächsrahmen auf eine Karteikarte und pinnen Sie diese links oben in die Ecke. Erstellen Sie zudem aus dem dazugehörigen Kurzfragebo-gen einen Steckbrief und notieren Sie diesen auf eine Karteikarte. Pin-nen Sie diese rechts neben den Gesprächsrahmen.

2. Anforderungen nummerierenBetrachten Sie die Transkripte einzeln und markieren Sie die Aussagen zu den Anwenderanforderungen. Geben Sie jeder Anforderung eine Num-mer nach folgendem Schema: (Nummer Anwender) (Nummer Anforde-rung). Für die fünfte Anforderung des zuerst befragten Anwenders ist die Nummer beispielsweise „1.5“. Wenn sich eine Anforderung wiederholt, wählen Sie die Stelle aus, an der sie am besten beschrieben ist.

3. User Stories schreibenSchreiben Sie für jede nummerierte Anforderung eine User Story auf eine Karteikarte. Folgen Sie dabei diesem Muster aus Sicht der Anwender: „Als Anwender der Dokumentation zur Fernsteuerung von Messgeräten wünsche ich mir (folgende Funktion), um (daraus folgenden Nutzen zu ziehen)“. Pinnen Sie diese gemäß des Interviewverlaufs rechts neben den Steckbrief.

Interviews

1

Interviewverlufe

Gesprächs-rahmen 1

Steck-brief 1


Steck-brief 2


Steck-brief 3

User Story3.1

Als Anwender der Dokumentation zur Fernsteuerung von Messgeräten wünsche ich mir ....

User Story2.2

User Story2.1

User Story1.4

User Story1.3

User Story1.1

User Story1.2

User Story2.3

User Story3.2

User Story2.4

User Story2.5

4. Anforderungsmatrix bearbeitenIn diesem Schritt müssen Sie die Anforderung jeder User Story in der Anforderungsmatrix festhalten. Falls die entsprechende Anforderung bereits in der Matrix vorhanden ist, markieren Sie diese mit einem „o“ als relevant und schlagen im Transkript die vom Anwender empfundene Wichtigkeit dieser Anforderung nach. Ergänzen Sie die Anforderungsma-trix, falls es sich um eine neue Anforderung handelt.

A-14


Struktur

Anforderungsmatrix

Anforderung A

Anforderung B

Anforderung D

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3



Anforderung C

Anforderung H

Anforderung I

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3


Falls „ja“ Form

Anforderung E

Anforderung G

ja nein 1 2 3

ja nein 1 2 3


Falls „ja“

Anforderung F

Anforderung J

ja nein 1 2 3

ja nein 1 2 3


oo o

o

o

o

o

Anforderung K

Anforderung L

Anforderung M

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3

oo

o

Wiederholen Sie diesen Vorgang für alle Interviews.

4 Hauptstudie: Usability-Test


Um den Usability-Test für die Dokumentation zur Fernsteuerung von Messgeräten durchführen zu können, müssen Sie im ersten Schritt Auf-gaben sowie eine Beispielgerät festlegen, um eine gewisse Vergleich-barkeit zu gewährleisten. Die Auswahl ist für die Qualität der Ergebnisse entscheidend. Achten Sie darauf, dass die Aufgabe realistisch, ofen gestellt und nicht zu schwierig ist. Zudem sollten die Aufgaben in einer Stunde durchführbar sein. Formulieren Sie die Aufgaben und drucken Sie diese aus.Des Weiteren ist es essentiell, Anwender als Testpersonen zu haben. Die Rekrutierung haben Sie bereits über den ersten Schritt der Haupt-studie versucht. Haben sich zwischen fünf und sieben Personen für die Teilnahme bereit erklärt, ist das ausreichend um Verbesserungspotenzial aufzuzeigen.

Im Anschluss daran müssen Sie den Test selbst vorbereiten und die benötigten Messgeräte, einen Laptop und die Videokamera, aufbauen. Stellen Sie die Kamera so, dass sie dem Anwender ber die Schulter ilmt und zu sehen ist, wie er mit dem Messgerät beziehungsweise auf dem Laptop mit der Dokumentation arbeitet. Stellen Sie zudem eine Stoppuhr bereit. Platzieren Sie diese aber so, dass der Anwender sie während der Durchführung der Aufgabe nicht sieht und dadurch nicht unter Druck gesetzt wird. Stellen Sie einen Stuhl für sich an der Seite auf, sodass Sie nicht im Aufnahmebild sind und den Anwender nicht stören, seine Vorge-hensweise aber dennoch problemlos beobachten können.Führen Sie die Aufgabe des Usability-Tests vor der Erhebung selbst durch, um die Vorgehensweise des Anwenders möglichst gut nachvoll-ziehen zu können. So können Sie auch einen reibungslosen Ablauf wäh-rend der eigentlichen Erhebung sicherstellen.

A-15


4.2 Datenerhebung

Die Datenerhebung indet während des Vorgesprächs, des eigentlichen Usability-Tests und der Nachbesprechung statt. Überprüfen Sie vor jedem Test den Aufbau und stellen Sie sicher, dass alles funktioniert. Um den Fokus auf die Arbeit des Anwenders mit der Dokumentation legen zu können ist es essentiell, dass er nicht durch andere Faktoren gestört wird beziehungsweise sich um diese kümmern muss, z. B. den Verbindungs-aufbau zum Internet.

4.2.1 Brieing

Erklären Sie dem Anwender den Ablauf des Usability-Tests. Fordern Sie ihn auf, während der gesamten Zeit laut zu denken. Weisen Sie ihn zudem darauf hin, dass es nicht darum geht ihn zu bewerten, sondern zu sehen, wie er mit der Dokumentation bei einer standardisierten Aufgabe arbeitet, um Anforderungen zu ermitteln. Erklären Sie ihm, dass Sie wäh-rend der Testphase nur als stiller Beobachter anwesend sind und ihm nicht beim Lösen der Aufgabe helfen werden.

4.2.2 Testphase

Starten Sie die Videoaufnahme und die Stoppuhr.

Beobachten Sie den Anwender aufmerksam und machen Sie sich Noti-zen. Interpretieren Sie das Verhalten des Anwenders bezüglich dessen Anforderungen und notieren Sie diese. Greifen Sie grundsätzlich nicht in die Testphase ein. Unterstützen Sie den Anwender nur, wenn er Prob-leme mit Dingen hat, die die Aufgabe nicht direkt betrefen, zum Beispiel den Browser nicht indet, um die Dokumentation abrufen zu können.

Wenn der Anwender alle Aufgaben erfüllt hat, stoppen Sie die Stoppuhr und notieren die Zeit. Stoppen Sie die Stoppuhr spätestens nach Ablauf des von Ihnen festgelegten Zeitrahmens und beenden den Test.

4.2.3 Nachbesprechung

Starten Sie die Nachbesprechung damit, dass Sie dem Anwender die Möglichkeit geben die Aufgabe frei zu kommentieren. Gehen Sie im Anschluss mit ihm Ihre Beobachtungen durch. Besprechen Sie mit ihm die Interpretationen bezüglich der Anforderungen.

4.3 Datenerfassung

Neben dem Leitfaden mit den Notizen und der gestoppten Zeit liegt Ihnen am Ende jedes Tests eine Videoaufzeichnung vor. Erstellen Sie für jeden Test eine Tabelle mit folgenden drei Spalten: Zeit, Bild und Ton. Gehen

A-16


Sie jedes Video durch und füllen Sie die Tabelle entsprechend. Nutzen Sie dabei für jeden Handlungsschritt eine Zeile. Scannen Sie alle Dokumente ein. Erstellen Sie zudem eine Tabelle mit allen Tests im Überblick.


Für die Auswertung werden Sie an der Pinnwand beziehungsweise der gröaeren Wandläche weiterarbeiten, welche Sie bereits bei der Auswer-tung des Contextual Inquiry genutzt haben. Sie benötigen bunte Kartei-karten und Pinnnadeln beziehungsweise Klebestreifen. Drucken Sie alle Tabellen aus und legen Sie für jeden Anwender wieder seine Anforde-rungsmatrix bereit.

1. Anforderungen nummerierenBetrachten Sie die Tabellen einzeln und markieren Sie die Aussagen zu den Anwenderanforderungen. Geben Sie jeder Anforderung eine Num-mer nach folgendem Schema: (Nummer Anwender) (Buchstabe Anforde-rung). Für die fünfte Anforderung des zuerst befragten Anwenders ist die Nummer beispielsweise „1.B“. Wenn sich eine Anforderung wiederholt, wählen Sie die Stelle aus, an der sie am besten beschrieben sind.

2. Anforderungsmatrix bearbeitenIn diesem Schritt müssen Sie mit Hilfe der Anforderungsmatrix überprü-fen, ob der Anwender diese Anforderung bereits im Contextual Inquiry hatte oder ob es eine neue Anforderung ist. Nutzen Sie für die Anforde-rungen diesmal ein „-“ (im Contextual Inquiry wurde „o“ verwendet).Ist es eine Anforderung, die nicht im Contextual Inquiry aufkam, müssen Sie prüfen, ob diese schon in der Anforderungsmatrix vorkommt. Falls ja markieren Sie diese entsprechend. Ist es eine Anforderung, die noch nicht in der Anforderungsmatrix vorkommt, müssen Sie diese ergänzen.

Struktur

Anforderungsmatrix

Anforderung A

Anforderung B

Anforderung D

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3



Anforderung C

Anforderung H

Anforderung I

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3


Falls „ja“ Form

Anforderung E

Anforderung G

ja nein 1 2 3

ja nein 1 2 3


Falls „ja“

Anforderung F

Anforderung J

ja nein 1 2 3

ja nein 1 2 3


oo o

o

o

o

o

Anforderung K

Anforderung L

Anforderung M

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3

Anforderung N

Anforderung O

ja nein 1 2 3

ja nein 1 2 3

Anforderung P

Anforderung Q

Anforderung TAnforderung R

ja nein 1 2 3

ja nein 1 2 3

ja nein 1 2 3ja nein 1 2 3

o

oo

3. User Stories schreibenSchreiben Sie für jede neue Anforderung eine User Story auf eine Kar-teikarte. Pinnen Sie diese gemäß des Videoverlaufs rechts neben die User Stories aus dem Contextual Inquiry. Für Anforderungen, die sich

A-17


aus dem Contextual Inquiry wiederholen, müssen Sie keine neue User Story schreiben. Fügen Sie lediglich auf die „alte“ dazugehörige User Story die Nummer der im Usability-Test genannten Anforderung hinzu.

Interviews

1

Interviewverlufe

Gesprächs-rahmen 1

Steck-brief 1


Steck-brief 2


Steck-brief 3

User Story3.1 + 3.B

Als Anwender der Dokumentation zur Fernsteuerung von Messgeräten wünsche ich mir ....

User Story2.2

User Story2.1

User Story1.4

User Story1.3

User Story1.1 + 1.D

User Story1.2 + 1.A

User Story2.3

User Story3.2

User Story2.4

User Story2.A

User Story1.B

User Story1.C

User Story3.A

User Story3.C

User Story3.D

User Story1.E

User Story2.B

Wiederholen Sie Schritt 2 und Schritt 3 für alle Tests.

4. Übersichtsanforderungsmatrix erstellenErstellen Sie eine Tabelle, in der Sie die Ergebnisse der einzelnen Anfor-derungsmatrizen aus dem Contextual Inquiry und dem Usability-Test zusammenfassen.

5. User Stories zusammenfassenFassen Sie anhand der Übersichtsanforderungsmatrix alle User Stories zusammen.

5 Hauptstudie: Anforderungsmatrix


Vereinbaren Sie einen letzten Termin mit allen Anwendern. Stellen Sie sicher, dass Sie zu diesem Zeitpunkt die anderen Auswertungen voll-ständig abgeschlossen haben und die Anforderungsmatrix, wie in den vorhergehenden Schritten beschrieben, bearbeitet wurde.

5.2 Datenerhebung

Gehen Sie mit dem Anwender die noch ofenen Anforderungen seiner Anforderungsmatrix Schritt für Schritt durch. Fragen Sie den Anwender, ob die Anforderung für ihn im Hinblick auf die Dokumentation zur Fernsteu-erung der Messgeräte relevant ist und falls ja, wie wichtig sie für ihn ist. Markieren Sie die entsprechenden Antworten in der Anforderungsmatrix.

5.3 Datenerfassung

Scannen Sie die Anforderungsmatrizen ein. Vervollständigen Sie die Tabelle der Übersichtsanforderungsmatrix aus Schritt 4 des Usability- Tests, indem Sie die Nennung der vorher nicht genannten Anforderungen mitaufnehmen.

A-18


5.4 Datenauswertung

Nun können Sie überprüfen, ob die in der Vorstudie genannten Anforde-rungen auch für den befragten Anwender von Bedeutung sind und sich bestätigen. Zudem können Sie die Nennungen in den einzelnen Katego-rien miteinander vergleichen.


Sie können ihren Kollegen von den Ergebnissen berichten. Die Ergeb-nisse bilden die Grundlage, um die Dokumentation der Fernsteuerung der Messgeräte hinsichtlich ihrer Qualität zu bewerten. Sie können dabei die Nachvollziehbarkeit ihrer Ergebnisse prüfen und diese in einer sach-gerechten Auseinandersetzung mit ihren Kollegen diskutieren.

A-19


6 Dokumente

6.1 Vorstudie


Allgemeine Fragen zur Ttigkeit

Seit wann sind Sie bei [Unternehmen] tätig? ________________________________________________________

Wie lautet Ihre Stellenbezeichnung? ________________________________________________________

Inwiefern haben Sie bei Ihrer Arbeit mit Anwendern zu tun? ________________________________________________________ ________________________________________________________ ________________________________________________________

Wie oft sind Sie im Kontakt mit Anwendern? ________________________________________________________

Mit welchen Anwendergruppen sind Sie im Kontakt? ________________________________________________________ ________________________________________________________ ________________________________________________________

Mit wie vielen verschiedenen Anwendern sind Sie im Kontakt? ________________________________________________________ ________________________________________________________ ________________________________________________________

A-20


6.1.2 Leitfaden: Problemzentriertes Interview

1. Einleitung Dank für Teilnahmebereitschaft Vorstellung: Person und Projekt (kurz) Vorgehen: Gesprächsdauer, Erzählung wichtig Vertraulichkeit und Datenschutz: Tonbandaufnahme, Anonymisierung der Daten, Transkription, Einverständnis einholen Fragen des Interviewpartners

2. Kurzfragebogen (eigenes Dokument)

Aufnahme starten

3. Allgemeine Sondierung, Projekt näher erklären Was wünschen sich die Anwender von der Dokumentation zur Fernsteuerung der Messgeräte?

4. Erzählauforderungen Interview: a) Welche Anwendergruppen benutzen die Dokumentation zur Fernsteuerung der Messgeräte? b) Welche Anforderungen haben die einzelnen Anwendergruppen? Gehen Sie auch darauf ein, inwiefern sich diese unterscheiden. c) Nennen Sie die Anforderungen, deren Erfüllung Ihrer Meinung nach für die Anwender am wichtigsten ist. Gehen Sie dabei auf die Kategorien Struktur, Inhalt und Form ein. d) Eine Besonderheit von den SCPI-Kommandos ist, dass deren Aus- führung für den Anwender genau beschrieben werden muss, weil sie keine intuitive Bedienung erlauben. Zudem müssen die Kommandos in der Dokumentation fehlerfrei sein, da bereits ein Buchstabendreher dazu führt, dass der Befehl nicht funktioniert. Fällt Ihnen noch mehr zu den Besonderheiten bezüglich der Dokumentation zur Fernsteuerung der Messgeräte ein?

5. Direkte Fragen ________________________________________________________

Aufnahme stoppen

6. Abschluss Dank für Auskunfts- und Teilnahmebereitschaft Frage nach weiteren Interviewpartnern _________________________ Frage nach Dateien, z. B. Befragungen _________________________ Frage nach möglichen Kontakt zu Anwendern ___________________ Beobachtungstipps für Hauptstudie ____________________________

7. Postskript (eigenes Dokument)

A-21


6.1.3 Postskript

Interviewer: ________________________________________________________

Datum des Interviews: ________________________________________________________

Ort des Interviews: ________________________________________________________

Beginn des Interviews: ________________________________________________________

Ende des Interviews: ________________________________________________________

Dauer des Interviews: ________________________________________________________

Interviewsituation: ________________________________________________________

Besondere Vorkommnisse während des Interviews: ________________________________________________________

Gespräche vor Einschalten des Aufnahmegeräts: ________________________________________________________

Gespräche nach Abschalten des Aufnahmegeräts: ________________________________________________________

Verhalten des Interviewten: ________________________________________________________

A-22


6.2 Hauptstudie


Allgemeine Fragen zur Ttigkeit

Seit wann sind Sie bei [Unternehmen] tätig? ________________________________________________________

Wie lautet Ihre Stellenbezeichnung? ________________________________________________________

Platz für Fragen, die eine Überprüfung der Thesen aus der Vorstudie

ermöglichen.

[Beispiel:

Auf einer Skala von 1 bis 4, wie gut würden Sie Ihre Programmierkennt- nisse bezüglich der Fernsteuerung von Messgeräten einschätzen? Sehr Wenig Wenig Gut Sehr gut 1 2 3 4

Welche verschiedenen Geräte steuern Sie fern? ________________________________________________________

Auf einer Skala von 1 bis 4, wie gut kennen Sie sich mit den Geräten aus? Sehr Wenig Wenig Gut Sehr gut Gerät 1: ________ 1 2 3 4 Gerät 2: ________ 1 2 3 4 Gerät 3: ________ 1 2 3 4 Gerät 4: ________ 1 2 3 4 Gerät 5: ________ 1 2 3 4

Ende Beispiel]

A-23


6.2.2 Leitfaden: Contextual Inquiry

A) Contextual Inquiry 1. Conventional Interview: Allgemeine Informationen Dank für Teilnahmebereitschaft Vorstellung: Person und Projekt (kurz) Vorgehen: Gesprächsdauer, Erzählung wichtig Vertraulichkeit und Datenschutz: Tonbandaufnahme, Anonymisierung der Daten, Transkription, Einverständnis einholen Fragen des Interviewpartners

Kurzfragebogen (eigenes Dokument)

2. Transition: Vorgehensweise des Contextual Inquiry erklren

Aufnahme starten

Was wünschen Sie sich als Anwender von der Dokumentation zur Fernsteuerung von Messgeräten?

User Stories als Ziel, alle Informationen müssen vorhanden sein

• Als Anwender der Fernsteuerung von Messgeräten möchte ich (Ziel), damit (Begrndung).

• Akzeptanzkriterien fr Anforderungen

• Priorität

3. Contextual Inquiry: Beobachtung mit Anforderungsmatrix Auftretende Anforderungen abfragen; Interpretationen richtig? ________________________________________________________

4. Wrap-Up: Zusammenfassung, ofene Punkte klären

B) Bereitschaft an Usability-Test teilzunehmen? Weitere und ggf. andere Anforderungen aufdecken • Ja? Termin vereinbaren • Nein? Termin vereinbaren fr C)

C) Anforderungsmatrix: noch ofene Anforderungen ansprechen • Oberbegrife abfragen, relevant ja oder nein? Falls ja, wie wichtig von 1 (weniger wichtig) bis 3 (sehr wichtig) • Falls ja, Darunterfallende abfragen, relevant ja oder nein? Falls ja, wie wichtig von 1 (weniger wichtig) bis 3 (sehr wichtig) • Falls bereits Anforderungen von einem Bereich genannt wurden, bliche abfragen, aber nicht mehr auf Oberbegrif eingehen Aufnahme stoppen

Dank für Auskunfts- und Teilnahmebereitschaft

Postskript (eigenes Dokument)

A-24


6.2.3 Postskript

Interviewer: ________________________________________________________

Datum des Interviews: ________________________________________________________

Ort des Interviews: ________________________________________________________

Beginn des Interviews: ________________________________________________________

Ende des Interviews: ________________________________________________________

Dauer des Interviews: ________________________________________________________

Interviewsituation: ________________________________________________________

Besondere Vorkommnisse während des Interviews: ________________________________________________________

Gespräche vor Einschalten des Aufnahmegeräts: ________________________________________________________

Gespräche nach Abschalten des Aufnahmegeräts: ________________________________________________________

Verhalten des Interviewten: ________________________________________________________

Arbeitsumfeld: ________________________________________________________

A-25

B: Schritt für Schritt-AnleitungenStufe 2: Bewertung der Qualität

Stufe 2: Bewertung der Qualitt

Im Folgenden wird Schritt für Schritt erklärt, wie Sie die Dokumentation des Beispielgerätes, welches Sie bereits im Usability-Test ausgewählt haben, bezüglich der Qualität bewerten. Als Grundlage dienen die in der ersten Stufe erhobenen Anwenderanforderungen. Damit folgt die Stufe der DIN EN ISO 9000:2015-11, die Qualität als Grad deiniert, inwieweit ein Produkt mit dessen Anforderungen übereinstimmt. Je mehr Anforde-rungen erfüllt sind, desto höher ist die Qualität der Dokumentation.

1 Planung und Vorbereitung

Öfnen Sie die Übersichtsanforderungsmatrix, die Sie abschlieaend erstellt haben. Speichern Sie diese unter einem neuen Namen. Kopieren Sie die Einzelnen Anforderungen untereinander in ein neues Blatt.Kopieren Sie die User Stories untereinander und fügen Sie zehn neue Spalten hinzu. Geben Sie der ersten Spalte den Namen „Anzahl Nen-nungen“ und fügen Sie entsprechend die Anzahl der Nennungen aus der ersten Stufe (EdA) ein. Die zweite Spalte ist die „Gewichtung User Story“.

Errechnen Sie die Gewichtung jeder User Story indem Sie die entspre-chende Anzahl der Nennungen für eine Anforderung (AN) durch die Gesamtzahl aller Nennungen (GN) dividieren. Multiplizieren Sie die Werte mit 100. Diese Werte geben an, welchen Teil eine Nennung im Vergleich zu allen Nennungen darstellt und damit wie groß die Bedeutung dieser gemäß der in der ersten Stufe ermittelten Anwenderanforderungen ist.

Gewichtung User Story:(AN : GN) x 100

Beispiel: Sie haben in der Hauptstudie aus 150 Nennungen 75 User Stories zusammengefasst. Eine Nennung entspricht einer Gewichtung von etwa 0,00667 (1 : 150). Multiplizieren Sie den Wert mit 100 und tra-gen Sie in die Spalte „Gewichtung User Story“ 0,667 ein.

Neben den User Stories haben Sie aber noch die Einzelnen Anforderun-gen vorliegen, die von den Anwendern weder während des Contextual Inquiry noch während des Usability-Tests genannt wurden. Auch diese Ergebnisse müssen Sie gewichten, um die Qualität der Dokumentation bewerten zu können. Die Anwender konnten sagen, ob sie die Anforderung als relevant erach-ten. Betrachten Sie im Folgenden lediglich die Anforderungen, die mehr als die Hälfte der Befragten als relevant eingestuft haben.Diese Anforderungen konnten die Anwender auf einer Skala von eins (weniger wichtig) bis drei (sehr wichtig) einstufen, was berücksichtigt werden muss. Multiplizieren Sie für jede Anforderung die Anzahl der Nennungen unter eins mit dem Faktor eins, die Anzahl der Nennungen

A-26


unter zwei mit dem Faktor zwei und die Anzahl der Nennungen unter drei mit dem Faktor drei.

Berechnung des Wertes einer einzelnen Anforderung:1 x (Anzahl Nennungen weniger wichtig) +2 x (Anzahl Nennungen wichtig) + 3 x (Anzahl Nennungen sehr wichtig)

Beispiel: Sie haben in der Hauptstudie insgesamt sieben Anwender befragt. Eine Anforderung wurde von allen Anwendern als relevant ein-gestuft und wurde nicht unter weniger wichtig eingeordnet, dreimal unter wichtig und viermal als sehr wichtig. Damit erhält Sie durch diese Rech-nung 1 x 0 + 2 x 3 + 3 x 4 den Wert 18.

Je nach Anzahl der während der Hauptstudie Befragten (B) ergibt sich der maximal mögliche Wert für jede Anforderung.

Maximaler Wert für eine Einzelne Anforderung:3 x (B)

Beispiel: Sie haben in der Hauptstudie insgesamt sieben Anwender befragt. Alle habe die eine Anforderung als sehr wichtig eingestuft, dadurch ergibt sich ein maximal möglicher wert von 3 x 7 = 24.

Diesen Wert benötigen Sie, um die Anforderungen mit den User Stories vergleichbar zu machen. Ordnen Sie dem maximalen Wert die Gewich-tung zu, die eine einzelne Nennung einer User Story entspricht. Diese Vorgehensweise folgt der Annahme, dass die User Stories, die selbst von den Befragten genannt wurden wichtiger sind, als die Anforderun-gen, welche standardisiert abgefragt wurden.Teilen Sie diesen Wert durch den maximalen Wert. Mit dieser Grund-lage können Sie für alle Anforderungen, nachdem Sie ihren Wert mit den Faktoren berechnet haben, eine entsprechende Gewichtung zuordnen. Fügen Sie diese Werte am besten in die Tabelle ein.

Gewichtung Einzelne Anforderungen:Min. Gewichtungswert User Stories : Max. Wert einzelner Anforderungen

Beispiel: Der Wert 24 wird mit 0,667 gleichgesetzt. Teilt der Technische Redakteur 0,667 Prozent durch 24, erhält er die Gewichtung für den Wert 1, was gerundet 0,028 entspricht. Der Wert 18 entspricht 18 x 0,028 das heißt 0,501.

Nachdem Sie sowohl allen User Stories als auch allen Anforderungen einen Prozentsatz über die beschriebenen Rechnungen zugeordnet haben, haben Sie den User Stories und Anforderungen eine unterschied-liche Gewichtung gemäß Ihrer Ergebnisse der Hauptstudie zugeordnet.

A-27


Geben Sie der dritten neu eingefügten Spalte den Namen „Anmerkung – Anpassung der Anforderung nötig“. Falls Sie bei der Erhebung in der ersten Stufe nicht stets darauf geachtet haben, überprüfbare Anforde-rungen zu erheben, müssen Sie manche Anforderungen gegebenenfalls anpassen und eine Möglichkeit inden, diese zu prfen. Beispielsweise könnte ein Anwender von dem „Schnellen Auinden der benötigten Infor-mation“ gesprochen haben. Wenn Sie ihn nicht genau gefragt haben, was er damit gemeint hat, müssen Sie festlegen, wann diese Anforde-rung als erfüllt gilt. Die bereits angesprochene Literatur hilft Ihnen weiter. So könnten Sie wie in ISO/IEC 26514:2008(E), Systems and software engineering, S.42 beschrieben, für “schnell” festlegen, dass der Anwen-der nie mehr als drei Sprünge durchführen muss, um zur gesuchten Information zu kommen.Geben Sie der vierten Spalte den Namen “Oberbegrif”. Geben Sie den Anforderungen Schlagworte, um diese demnach zu ordnen und zusam-mengehörige Anforderungen über die Kategorien hinaus gemeinsam betrachten zu können.Die fünfte Spalte ist „schlecht, Faktor 0“, die sechste Spalte „gut Faktor 1“ und die siebte Spalte ist „ausgezeichnet, Faktor 2“. Geben Sie der achten Spalte den Namen „Begründung der Entscheidung“, der neunten Spalte den Namen „erreicht“ und der zehnten Spalte den Namen „maximal“.Berechnen Sie die Werte für die maximal möglichen Werte für die Spalte „maximal“.

Erhebung User Stories

User Story A

User Story B

User Story D

User Story C

User Story H

User Story I

User Story F

User Story J

User Story K

User Story L

User Story P

User Story Q

User Story T

User Story N

User Story R

User Story E

User Story G

User Story M

User Story O

Anzahl Nennungen

GewichtungUser Story

Anmerkung - Anpassung nötig

Ober-begriff

schlecht,Faktor 0

gut,Faktor 1

ausgez.,Faktor 2

Begründung der Entscheidung erreicht maximal

2 1,351 bereits in Arbeit Beispiele 0 kein Positivbeispiel 0 2,703

2 Datenerhebung beziehungsweise - erfassung

Gehen Sie die Dokumentation für jede User Story und Anforderung durch und überprüfen Sie, ob und wie gut diese erfüllt sind. Verteilen Sie für nicht erfüllte Anforderungen ein schlecht (Faktor 0), ein gut (Faktor 1) für teils erfüllte Anforderungen und ein ausgezeichnet (Faktor 2) für

A-28


vollständig erfüllte Anforderungen. Entscheiden Sie sich stets für einen Erfüllungsgrad. Dies ist für die Auswertung und die Stufe zum Aufzeigen von Verbesserungspotenzial essentiell. Die Beachtung folgender Regeln hilft Ihnen dabei: Sobald Sie ein Positivbeispiel gefunden haben, dürfen Sie für die Anfor-derung nicht mehr der Faktor 0 verwenden. Haben Sie mindestens ein Negativbeispiel gefunden, dürfen Sie der Anforderung den Faktor 2 nicht mehr zuordnen.Nutzen Sie die Spalte „Begründung der Entscheidung“ um Ihre Abwä-gungen und entsprechende Negativ- und Positivbeispiele festzuhalten und ihre Entscheidungen dadurch nachvollziehbar zu machen.

3 Datenauswertung

Rechnen Sie anschließend den Wert für jede Anforderung aus, in dem Sie die Punktzahl mit dem Prozentsatz multiplizieren. Notieren Sie die-sen Wert in der Spalte „erreicht“. Zum Abschluss zählen Sie alle diese Werte zusammen. Sie erhalten einen Wert für die Qualität ihrer Dokumentation. Um diesen einordnen zu können, müssen Sie noch den maximalen Wert ermitteln. Für die User Stories ist dieser 200. Für die Einzelnen Anforderungen müssen Sie den maximalen Wert für eine Anforderung mit der Anzahl der Anforderungen multiplizieren. Anschließend müssen Sie diesen Wert noch mit 2 multi-plizieren. Addieren Sie diesen Wert zu 200 Prozent und Sie erhalten die maximal mögliche Punktzahl. Erstellen Sie ein Diagramm, in welchem Sie die Oberbegrife und ihre Bedeutung darstellen. Erstellen Sie zudem in einem neuen Blatt eine Übersicht der User Stories sowie der Einzelnen Anforderungen.

4 Berichterstattung

Berichten Sie in Ihrer Abteilung über die Qualität der Beispieldokumen-tation. Erklären Sie Ihren Kollegen die Entscheidungen, die Sie getrofen haben. Dadurch können Sie überprüfen, ob diese nachvollziehbar sind. Lassen Sie sich auf Diskussionen ein und passen Sie den Erfüllungsgrad gegebenenfalls an, achten Sie aber darauf, dass Ergebnis nicht unbe-gründet nach oben zu verschieben.

A-29

B: Schritt für Schritt-AnleitungenStufe 3: Identiikation von Verbesserungspotenzial

Stufe 3: Identiikation von Verbesserungspotenzial

Im Folgenden wird Ihnen Schritt für Schritt erklärt, wie Sie Verbesserungs-potenzial der Dokumentation ihres Beispielgerätes identiizieren. Als Grundlage dient die Tabelle, welche sie in der Stufe 2 zur Bewertung der Qualität erstellt haben.

1 Planung und Vorbereitung

Erstellen Sie eine neue Tabelle, in der sie sowohl die User Stories als auch die Einzelnen Anforderungen der Tabelle der zweiten Stufe her-auskopieren, die Sie mit 0 oder 1 bewertet haben. Fügen Sie zwei wei-tere Spalten ein und nennen sie diese „Verbesserungsvorschläge“ und „Durchführbarkeit“.

2 Datenerhebung beziehungsweise - erfassung

Überlegen Sie sich für jede der verbleibenden Anforderungen einen Verbesserungsvorschlag mit Hilfe der bereits angesprochenen Literatur und notieren Sie ihn in der Spalte „Verbesserungsvorschläge“. Bewer-ten Sie die Durchführbarkeit des Verbesserungsvorschlags. Vergeben Sie ein leicht für Vorschläge, die sie selbst umsetzen können, mittel für Vorschläge, die innerhalb der Abteilung umgesetzt werden können und schwer für Vorschläge, die übergreifende Absprachen benötigen. Blei-ben Sie bei der Erarbeitung der Vorschläge ofen und notieren Sie auch Vorschläge, die zum aktuellen Zeitpunkt unlösbar erscheinen.

3 Datenauswertung

Ihren zeitlichen Ressourcen entsprechend, können Sie die Auswertung in mehreren Ebenen durchführen. Markieren Sie zunächst die fünf nach Stufe 2 wichtigsten Oberbegrife sowie die fnf Oberbegrife mit dem geringsten Erfüllungsgrad. Gibt es Überschneidungen, besteht großes Verbesserungspotenzial. Betrachten Sie auch die anderen Oberbegrife genauer. In der zweiten Ebene können Sie die Kategorien Struktur, Inhalt und Form analysieren und wie bei den Oberbegrifen beschrieben vorge-hen. Haben Sie noch zeitliche Ressourcen übrig, lohnt es sich auch die Verbesserungsvorschläge der User Stories und Einzelnen Anforderun-gen anzusehen.

4 Berichterstattung

Berichten Sie in Ihrer Abteilung über das Verbesserungspotenzial. Besteht großes Verbesserungspotenzial und die Verbesserungsvorschläge sind leicht umzusetzen, können Sie mit wenig Aufwand die Qualität der Doku-mentation ihres Beispielgerätes hinsichtlich der Anwenderanforderungen erhöhen.

V

LiteraturverzeichnisStufe 3: Identiikation von Verbesserungspotenzial

Literaturverzeichnis

B , Carol M.: Usability testing essentials, Ready, Set…Test!, Burlington Mass. 2010, Elsevier Inc.

B , Nina; B , Jörg (Hg.) 2014: Handbuch Methoden der empirischen Sozialforschung, Wies-baden, Springer Fachmedien.

B , Heiko 2013: Zielgruppengerechte Zugänge zu digitalen Inhalten. In: Jörg Hennig und Marita Tjarks-Sobhani (Hg.): Zielgruppen für Technische Kommunikation. Lübeck: Schmidt-Römhild (Tekom-Schriften zur technischen Kommunikation, 17), S. 100–110.

B , Herbert: NF- und HF-Messtechnik, Messen mit Oszilloskopen, Netzwerkanalysatoren und Spektrumanalysator, Wiesbaden 2015, Springer Fachmedien.

B , Hugh; H , Karen: Contextual design, Deining Customer-Centered Systems, San Francisco 1998, Academic Press (Morgan Kaufmann Series in Interactive Technologies).

Bö , Martin; R , Ralf: Kundendokumentationen für Konsum- und Investitionsgüter, Kritische Erfolgsfaktoren für Management und Erstellung, Berlin 2015, Beuth Verlag GmbH (Doku-mentation).

B , Alexander; L , Beate; M , Wolfgang: Interviews mit Experten, Eine praxisorientierte Einführung, Wiesbaden 2014, Springer Fachmedien.

C , M.: User Stories, für die agile Software-Entwicklung mit Scrum, XP u.a. Unter Mitarbeit von M. Hesse-Hujber, Heidelberg, München, Landsberg, Frechen, Hamburg 2010, mitp.

DIN EN ISO 9241-11:2017-01(E): Ergonomie der Mensch-System-Interaktion - Teil 11: Gebrauch-stauglichkeit: Begrife und Konzepte.

DIN 1319-1:1995-01: Grundlagen der Meßtechnik - Teil 1: Grundbegrife.

DIN 69901-5:2009-01: Projektmanagement – Projektmanagementsysteme – Teil 5: Begrife.

DIN EN ISO 9000:2015-11: Qualitätsmanagementsysteme – Grundlagen und Begrife.

D , Andreas: Empirische Sozialforschung, Grundlagen, Methoden, Anwendungen, Reinbek bei Hamburg, 20 2016 [1 1995], Rowohlt Taschenbuch Verlag (rowohlts enzyklopädie, 55678).

Duden 2017: Konzept, Rechtschreibung, Bedeutung, Deinition, Synonyme, Herkunft. Hg. v. Bibliographisches Institut GmbH. Dudenverlag. Online verfügbar unter http://www.duden.de/rechtschreibung/Konzept, zuletzt geprüft am 04.08.2017.

Duden 2017: Schema, Rechtschreibung, Bedeutung, Deinition, Synonyme, Herkunft. Hg. v. Bibliographisches Institut GmbH. Dudenverlag. Online verfügbar unter http://www.duden.de/rechtschreibung/Schema, zuletzt geprüft am 04.08.2017.

Duden 2017: System, Rechtschreibung, Bedeutung, Deinition, Synonyme, Herkunft. Hg. v. Bibliog-raphisches Institut GmbH. Dudenverlag. Online verfügbar unter http://www.duden.de/rechtsch-reibung/System, zuletzt geprüft am 04.08.2017.

G ü w , Gertrud 2009: Softwaredokumentation gewinnt an Bedeutung. In: TEKOM (Hg.) - tech-nische kommunikation (4/2009), S. 48–52. Online verfügbar unter http://www.tekom.de/fachar-tikel/elektronische-informationsprodukte/softwaredokumentation-gewinnt-an-bedeutung.html, zuletzt geprüft am 04.08.2017.

G ü w , Gertrud 2013: Ein vielfältiges Spektrum. In: TEKOM (Hg.) - technische kommunikation (3/2013), S. 22–25. Online verfügbar unter http://www.tekom.de/fachartikel/elektronische-infor-mationsprodukte/ein-vielfaeltiges-spektrum.html, zuletzt geprüft am 04.08.2017.

G ü w , Gertrud: Software-Dokumentation, Grundlagen - Praxis - Lösungen, Renningen, 3 2013 [1 2005], expert verlag (Kontakt & Studium, 668).

G ü w , Gertrud 2017: Kurz notiert, Softwaredokumentation aktuell und gebrauchstauglich halten. In: iX Developer (01/2017), S. 24–27.

H , Cornelia: Die Qualität qualitativer Daten, Manual für die Durchführung qualitativer Interviews, Wiesbaden, 4 2011 [1 2004], Springer Fachmedien.

VI


H , Jörg; T -S , Marita (Hg.) 2013: Zielgruppen für Technische Kommunikation, Lübeck, Schmidt-Römhild (Tekom-Schriften zur technischen Kommunikation, 17).

H , Kelly 2017: Top 12 telecom test and measurement companies by revenue. In: RCR Wireless News: Intelligence on all things wireless, 12.01.2017. Online verfügbar unter http://www.rcrwire-less.com/20170112/test-and-measurement/top-12-telecom-test-measurement-companies-rev-enue-tag6-tag99, zuletzt geprüft am 04.08.2017.

IEC 82079-1:2012-08: Preparation of instructions for use – Structuring, content and presentation – Part 1: General principles and detailed requirements.

ISO/IEC 26514:2008(E): Systems and software engineering - Requirements for designers and devel-opers of user documentation.

J , Dietrich: Technische Dokumentation, Praktische Anleitungen und Beispiele, Berlin, Heidel-berg, 3 2015 [1 2002], Springer Verlag.

Keysight Technologies 2017: Keysight IniniiVision 6000 X-Series Oscilloscopes, Programmer’s Guide. Online verfügbar unter http://www.keysight.com/upload/cmc_upload/All/6k_X-Series_prog_guide.pdf, zuletzt aktualisiert am 01.03.2017, zuletzt geprüft am 04.08.2017.

L , Siegfried: Qualitative Sozialforschung, Lehrbuch ; [Online-Materialien]. Unter Mitarbeit von Claudia Krell, Weinheim, 5 2010 [1 1989], Beltz (Grundlagen Psychologie).

L , Anne 2013: Zielgruppenspeziisches Texten in der Technischer Dokumentation. In: Jörg Hennig und Marita Tjarks-Sobhani (Hg.): Zielgruppen für Technische Kommunikation. Lü-beck: Schmidt-Römhild (Tekom-Schriften zur technischen Kommunikation, 17), S. 111–130.

L , Reinhard: Elektrische Messtechnik, Analoge, digitale und computergestützte Verfahren, Berlin, Heidelberg, 7 2016 [1 1996], Springer Verlag.

M , Philipp: Einführung in die qualitative Sozialforschung, Eine Anleitung zu qualitativem Denken, 6 2016 [1 1990], Beltz (Pädagogik).

M , Sabina: Qualitative Interviews, Berlin, München, Boston 2015, Walter de Gruyter GmbH.

M , Christian: User Experience Design, Mit erlebniszentrierter Software-Entwicklung zu Produk-ten, die begeistern, Berlin, Heidelberg 2012, Springer-Verlag (X.media.press).

Mü , Thomas: Elektrische Messtechnik, Grundlagen, Messverfahren, Anwendungen, Wiesbaden, 5 2017 [1 2001], Springer Fachmedien.

Neuhaeusler; Chlodwig 2013: SCPI-Recorder, Test Automation at Your Fingertips. Application Note. Hg. v. Rohde & Schwarz GmbH & Co. KG (Application Note). Online verfügbar unter https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_application/application_notes/1gp98/1G-P98_1E_SCPI_Recorder.pdf, zuletzt geprüft am 04.08.2017.

N , Markus 2013: Mit Methodik zur Zielgruppe. In: Jörg Hennig und Marita Tjarks-Sobhani (Hg.): Zielgruppen für Technische Kommunikation. Lübeck: Schmidt-Römhild (Tekom-Schriften zur technischen Kommunikation, 17), S. 13–24.

Rational Software 1998: Rational Uniied Process, Best Practices for Software Development Teams. Hg. v. IBM. Online verfügbar unter https://www.ibm.com/developerworks/rational/library/con-tent/03July/1000/1251/1251_bestpractices_TP026B.pdf, zuletzt geprüft am 04.08.2017.

R , Karl-Heinz: Agile objektorientierte Software-Entwicklung, Schritt für Schritt vom Geschäfts-prozess zum Java-Programm, Wiesbaden 2016, Springer Fachmedien (Lehrbuch).

R , Michael; F ü , Markus D.: Usability und UX kompakt, Produkte für Menschen, Berlin, Heidelberg, 4 2016 [1 2007], Springer-Verlag (IT kompakt).

R , Tilo 2017: Erfolgreicher Umgang mit Anforderungen. In: TEKOM (Hg.) – technische kommu-nikation 39 (03/2017), S. 35–41.

R , Suzanne; R , James: Mastering the requirements process, Getting require-ments right, Upper Saddle River, N.J, 3 2013 [1 1999], Pearson Education, Inc.

Rohde & Schwarz GmbH & Co. KG: R&S®FSW Signal- und Spektrumanalysator, Merkmale. On-line verfügbar unter https://www.rohde-schwarz.com/de/produkt/fsw-powerslave_63491-11793.html, zuletzt geprüft am 04.08.2017.

VII


Rohde & Schwarz GmbH & Co. KG 2017: Arbeitsgebiete, Hightech und Innovation. Online ver-fügbar unter https://www.rohde-schwarz.com/de/unternehmen/arbeitsgebiete/arbeitsgebie-te_229375.html, zuletzt geprüft am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: Behörden und Sicherheit. Online verfügbar unter https://www.rohde-schwarz.com/de/loesungen/sicherheit-fuer-behoerden/sicherheit-fuer-be-hoerden-uebersicht/sicherheit-fuer-behoerden-uebersicht_229840.html, zuletzt geprüft am 04.08.17.

Rohde & Schwarz GmbH & Co. KG 2017: Broadcast- und Medientechnik von Rohde & Schwarz. Online verfügbar unter https://www.rohde-schwarz.com/de/loesungen/rundfunk-und-medi-entechnik/rundfunk-und-medientechnik-uebersicht/rundfunk-uebersicht_229836.html, zuletzt geprüft am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: Daten + Fakten, Geschäftsjahr 2015 I 2016. Online ver-fügbaryunteryhttps://www.rohde-schwarz.com/de/general-information-germany/facts_and_ig-ures_1/daten_und_fakten_231061.html, zuletzt geprüft am 04.08.17.

Rohde & Schwarz GmbH & Co. KG 2017: Elektronikentwicklung, Messtechniklösungen für En-twickler von elektronischen Schaltungen. Online verfügbar unter https://www.rohde-schwarz.com/de/loesungen/electronic-design/electronic_design_overview-contentpackagewing/elek-tronikentwicklung-uebersicht_230522.html, zuletzt aktualisiert am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: Forschungsbeispiel: Teilchenbeschleuniger, Teilchenbes-chleuniger. Online verfügbar unter https://www.rohde-schwarz.com/de/loesungen/research/par-ticle-accelerators/teilchenbeschleuniger-uebersicht/teilchenbeschleuniger-uebersicht_230804.html, zuletzt geprüft am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: Luftfahrt und Verteidigung. Online verfügbar unter https://www.rohde-schwarz.com/de/loesungen/luftfahrt-und-verteidigung/luftfahrt-vertei-digung-uebersicht/luftfahrt-verteidigung-uebersicht_229832.html, zuletzt aktualisiert am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: Mobilfunk. Online verfügbar unter https://www.rohde-schwarz.com/de/loesungen/drahtlose-kommunikation/drahtlose-kommunikation-uebersicht/drahtlose-kommunikation-uebersicht_229844.html, zuletzt geprüft am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: R&S FSW Signal and Spectrum Analyzer, User Manual. Online verfügbar unter https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_common_library/dl_manuals/gb_1/f/fsw_1/FSW_UserManual_en_29.pdf, zuletzt aktualisiert am 01.08.2017, zuletzt geprüft am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: R&S FSW Signal and Spectrum Analyzer, Getting Started. Online verfügbar unter https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_common_library/dl_manuals/gb_1/f/fsw_1/FSW_GettingStarted_en_23_web.pdf, zuletzt aktualisiert am 27.06.2017, zuletzt geprüft am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: Rohde & Schwarz – Ihr Partner für Automotive Testing, Mess- und Testlösungen für die Automobilindustrie. Online verfügbar unter https://www.rohde-schwarz.com/de/loesungen/automotive/auto/automotive/automotive-uebersicht_230640.html, zuletzt geprüft am 04.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: Treiber und Fernsteuerung. Online verfügbar unter https://www.rohde-schwarz.com/de/driver-pages/fernsteuerung/uebersicht_110753.html, zuletzt geprüft am 22.08.2017.

Rohde & Schwarz GmbH & Co. KG 2017: Unternehmensproil. Online verfügbar unter https://www.rohde-schwarz.com/de/news-und-presse/pressebereich/unternehmensproil_229354.html,yzuletzt geprüft am 04.08.17.

Rü , Andreas: Dokumentation in agilen Projekten, Lösungsmuster für ein bedarfsgerechtes Vorgehen, Heidelberg 2013, dpunkt.verlag.

S , Florian; B , Henning: Methoden der Usability Evaluation, Wissenschaftliche Grun-dlagen und praktische Anwendung, Bern, 2 2011 [1 2006], Huber (Wirtschaftspsychologie in Anwendung).

S , Petra 2016: „Das hat schon etwas Paradoxes“, Interview mit Ekkehard Peik. Hg. v. taz.de, Berlin. Online verfügbar unter http://www.taz.de/!5278588/, zuletzt geprüft am 04.08.2017.

VIII


S w, Erika 2017: “EFR-Zeit” ist jetzt auch gesetzliche Zeit. Hg. v. Physikalisch-Technische Bundesanstalt (PTB). Online verfügbar unter https://www.ptb.de/cms/service-seiten/news/news-details.html?tx_news_pi1%5Bnews%5D=8327&tx_news_pi1%5Bcontroller%5D=News&tx_news_pi1%5Baction%5D=detail&cHash=e97f09d64c6781b622a2e897f5391f73, zuletzt geprüft am 02.08.2017.

SCPI Consortium (Hg.) 1999: Standard Commands for Programmable Instruments (SCPI), 1999.0, San Diego. Online verfügbar unter http://www.ivifoundation.org/docs/scpi-99.pdf, zuletzt geprüft am 04.08.2017.

SCPI Consortium 1999: Standard Commands for Programmable Instruments (SCPI). In: SCPI Consortiumy(Hg.):yStandardyCommandsyforyProgrammableyInstrumentsy(SCPI).y1999.0.yAul.ySanyDiego, zuletzt geprüft am 04.08.2017.

Statista 2017: Absatz von Smartphones in Deutschland in den Jahren 2009 bis 2017 (in Millionen Stück). Online verfügbar unter https://de.statista.com/statistik/daten/studie/77637/umfrage/ab-satzmenge-fuer-smartphones-in-deutschland-seit-2008, zuletzt geprüft am 04.08.2017.

Statista 2017: Endkundenabsatz von Smartphones weltweit von 2007 bis 2016 (in Millionen Stück). Online verfügbar unter https://de.statista.com/statistik/daten/studie/12856/umfrage/absa-tz-von-smartphones-weltweit-seit-2007/, zuletzt geprüft am 04.08.2017.

Statista 2017: Industrielle Automation in Deutschland, 2017, Dossier. Online verfügbar unter https://de.statista.com/statistik/studie/id/31557/dokument/industrielle-automation-in-deutsch-land-statista-dossier, zuletzt geprüft am 04.08.2017.

Statista 2017: Umsatz der Branche Herstellung von Mess-, Kontroll-, Navigations- u. ä. Instru-menten und Vorrichtungen in Deutschland von 2009 bis 2014 und Prognose bis zum Jahr 2020 (in Millionen Euro). Online verfügbar unter https://de.statista.com/prognosen/400275/herstel-lung-von-mess--kontroll--navigationsinstrumenten-in-deutschland---umsatzprognose, zuletzt geprüft am 04.08.2017.

Statista 2017: Umsatz der wichtigsten Industriebranchen in Deutschland von 2008 bis 2015 (in Milliarden Euro). Online verfügbar unter https://de.statista.com/statistik/daten/studie/203580/umfrage/umsaetze-der-wichtigsten-industriebranchen-in-deutschland, zuletzt geprüft am 04.08.2017.

S , Petra 2014: Forschungsdesign für die quantitative Sozialforschung. In: Nina Baur und Jörg Blasius (Hg.): Handbuch Methoden der empirischen Sozialforschung. Wiesbaden: Springer Fach-medien.

S ü , Moritz 2016: Stack Overlow will Dokumentationen für Programmiersprachen mithilfe der Community verbessern.yHg.yv.ystackoverlow.yOnlineyverfügbaryunteryhttp://t3n.de/news/stack-overlow-dokumentationen-728255/,yzuletztygeprüftyamy04.08.2017.T , Ulrich: TechDok light, Der schnelle Einstieg in die Technische Dokumentation, Kissing 2011, WEKA-Media (Fachbuch).

VDI 4500-1, Juni 2006: Technische Dokumentation: Begrifsdeinitionen und rechtliche Grundlagen.

gekürzte Version ohne Sperrvermerk Sperrvermerk.pdf · Ruf des Produktes, des Unternehmens und der...

Documents

Transcript of gekürzte Version ohne Sperrvermerk Sperrvermerk.pdf · Ruf des Produktes, des Unternehmens und der...