Anforderungen an Benutzer-Dokumentationen für betriebswirtschaftliche Anwendersoftware

Inhaltsverzeichnis

Abstract

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Vorwort

1. Einführung
1.1 Wegweiser durch die Diplomarbeit
1.2 Begriffe und Organisationsumfeld der Benutzer-Dokumentation
1.2.1 Grundlegende Begriffe, Definitionen und Abgrenzungen
1.2.1.1 Benutzer-Dokumentation
1.2.1.2 Betriebswirtschaftliche Anwenderprogramme
1.2.1.3 Anforderungen
1.2.2 Organisationsumfeld der Benutzer-Dokumentation
1.2.2.1 Auftraggeber
1.2.2.2 Auftragnehmer
1.2.2.3 Normungsorganisationen
1.2.2.4 Benutzer und Verbraucherschutzverbände
1.2.2.5 Rechtsprechung
1.3 Checkliste für Dokumentationsanforderungen

2. Welche Arten von Dokumentation gibt es?
2.1 Projekt-Dokumentation
2.2 Technische Dokumentation
2.2.1 Entwicklungs-Dokumentation
2.2.2 Programm-Dokumentation
2.2.2.2 Benutzer-Dokumentation
2.2.2.3 Gegenüberstellung DV-Handbuch und Benutzer-Dokumentation

3. Allgemeine Anforderungen an Benutzer-Dokumentationen
3.1. Aufbau einer Benutzer-Dokumentation
3.1.1 Äußere Gestaltung
3.1.2 Gliederung
3.1.3 Version
3.1.4 Innere Gestaltung
3.1.5 Terminologie
3.2 Konkrete Anforderungen

4. Anforderung der Normungsorganisationen
4.1 ISO und IEC
4.2 IEEE
4.3 CEN und CENELEC
4.4 DIN

5. Anforderung aus Recht und Rechtsprechung
5.1 Allgemeines
5.2 Rechtsrahmen
5.3 Haftung mit Verschulden nach BGB
5.4 Haftung ohne Verschulden nach ProdHaftG
5.5 Rechtsprechung
5.6 Rechtsfolgen

6. Anforderungen aus Kommunikations- und Motivationslehren
6.1 Der Kommunikationsprozess
6.2 Störfaktoren im Kommunikationsprozess
6.3 Folgen der Kommunikationsstörungen
6.4 Möglichkeiten der Kommunikationsverbesserung
6.5 Die vier Seiten einer Botschaft
6.6 Das Hamburger Verständlichkeitskonzept
6.7 Der Motivationsprozess
6.8 Der Lernprozess
6.9 Didaktische Aspekte

7. Anforderungen des Marketings
7.1 Ziele und Aufgaben des Marketings
7.2 Marktforschung
7.3 Marketingpolitische Instrumente
7.3.1 Produktpolitik
7.3.2 Kontrahierungspolitik
7.3.3 Distributionspolitik
7.3.4 Kommunikationspolitik
7.3.4.1 Werbung
7.3.4.2 Verkaufsförderung und persönlicher Verkauf
7.3.4.3 Öffentlichkeitsarbeit
7.4 Kritische und praktische Würdigung

8. Anforderungen aus Entwicklung und Technik
8.1 Anforderungen des technischen Produkts
8.2 Anforderungen an die technische Umsetzung
8.2.1 Content-Management-Systeme
8.2.1.1 Grundlagen und Begriffe
8.2.1.2 Anforderungen an Content Management Systeme
8.2.2 XML
8.2.3 Zusammenfassung und Ausblick

9. Umsetzung in der Praxis
9.1 Vor Einführung eines neuen Anwenderprogramms
9.2 Multimediale Benutzer-Dokumentation und -einweisung
9.2.1 Computergestützte Benutzer-Dokumentation
9.2.2 Tutorial
9.2.3 Masken- und Dialoggestaltung
9.2.4 Hilfefunktion und Hilfetexte
9.2.5 Schulungsunterlagen und Kurzanleitung
9.3 Software-Ergonomie
9.4 Die Einführung eines neuen Anwenderprogramms
9.5 Nach der Einführung eines neuen Anwenderprogramms

10. Test- und Beurteilungsmethoden für Dokumentationen
10.1 Beurteilung nach der PentaQuest-Methode
10.1.1 Wer? - Sender
10.1.2 Wem? - Zielgruppe
10.1.3 Warum? - Nutzenkategorien
10.1.4 Was? – Notwendige Informationen
10.1.5 Wie? - Zielgruppengerecht
10.2 Checkliste zur Beurteilung von Anwenderhandbüchern
10.3 Prüfung von Dokumentationen durch den TÜV
10.4 Prüfung durch Wirtschaftsprüfer
10.5 Prüfung anhand der DIN-Norm EN 62079
10.6 Praktische Tests

11. Fazit

Anhang A

Anhang B

Anhang C

Literaturverzeichnis

Abstract

Die Anforderungen an Benutzer-Dokumentationen für betriebswirtschaftliche Anwenderprogramme sind sehr vielfältig, kommen aus den verschiedensten Bereich und sind oft interdependent. Ziel dieser Diplomarbeit ist es, diese verschiedenen Anforderungen vor zu stellen und zwar in einer möglichst strukturierten, allgemeingültigen und übersichtlichen Form.

Dazu habe ich zunächst die wichtigsten Anforderungen gesammelt und einzelnen Themenbereichen zugeordnet. Denn neben einer einfachen Auflistung dieser Anforderungen soll hier auch das dazu notwendige jeweilige Hintergrundwissen grob vermittelt werden, um die Wichtigkeit und Umsetzbarkeit dieser Anforderungen in der Praxis besser einschätzen und bewerten zu können.

Aufbauend auf diesen Anforderungen werden verschiedene Möglichkeiten vorgestellt, wie man Benutzer-Dokumentation im weitesten Sinne in der Praxis realisieren kann und was man bei der Einführung eines neuen betriebswirtschaftlichen Anwenderprogramms und dessen Benutzer-Dokumentation alles beachten sollte. Darüber hinaus gibt diese Diplomarbeit einen Überblick über einige Methoden, Benutzer-Dokumentationen in der Praxis prüfen und hinsichtlich ihrer Qualität beurteilen zu können.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Wegweiser durch die Diplomarbeit

Abbildung 2: Übersicht der Anforderungen an Benutzerdokumentationen

Abbildung 3: Schnittstellen zu anderen Organisationseinheiten

Abbildung 4: Checkliste für Dokumentationsanforderungen

Abbildung 5: Software-Fabrik

Abbildung 6: Einteilung der EDV-Dokumentation in Teilbereiche

Abbildung 7: Phasenkonzept eines EDV-Anwendungssystems

Abbildung 8: Unterteilung Technische Dokumentation

Abbildung 9: Unterteilung Programmdokumentation

Abbildung 10: DV-Handbuch und Benutzer-Dokumentation

Abbildung 11: Allgemeine Anforderungen

Abbildung 12: Aufbau einer Benutzer-Dokumentation

Abbildung 13: Anforderungen der Normenorganisationen

Abbildung 14: Internationale und nationale Normungsorganisationen

Abbildung 15: Anforderungen aus Recht und Rechtsprechung

Abbildung 16: Übersicht Recht

Abbildung 17: Anforderungen aus Kommunikations- und Motivationslehren

Abbildung 18: „Man kann nicht nicht kommunizieren!“

Abbildung 19: Modell der Kommunikationsstörungen

Abbildung 20: Die vier Seiten einer Botschaft

Abbildung 21: Vier Dimensionen der Verständlichkeit

Abbildung 22: Die einzelnen Phasen des Motivationsprozesses

Abbildung 23: Motivation und Motivierung

Abbildung 24: Lernerfolg

Abbildung 25: Die Hierarchie der Bedürfnisse nach Maslow (1954)

Abbildung 26: Die Halbwertzeit des Wissens

Abbildung 27: Das HDI-Modell

Abbildung 28: Anforderungen des Marketings

Abbildung 29: Kreislauf Unternehmensinformation – Konsum

Abbildung 30: Produkteigenschaften und Darbietung

Abbildung 31: Anforderung aus Technik und Entwicklung

Abbildung 32: Technische Einflüsse auf die Benutzer-Dokumentation

Abbildung 33: Eingabemaske von Norton SystemWorks 2003

Abbildung 34: Startmenü von Windows XP Professional

Abbildung 35: Beispiel für die Hilfefunktion in Norton SystemWorks 2003

Abbildung 36: Die PentaQuest-Methode im Überblick

Tabellenverzeichnis

Tabelle 1: Normenorganisationen

Tabelle 2: Beispiele für Anleitungstexte

Tabelle 3: Dokumentationsbereiche

Tabelle 4: Schnittstellen zwischen den Entwicklungsabschnitten

Tabelle 5: Gliederung DV-Handbuchs und Benutzer-Dokumentation

Tabelle 6: Components of software user documentation

Tabelle 7: DIN-Normen

Tabelle 8: Störfaktoren in der Kommunikation

Tabelle 9: Beispiele für einen eindeutigen Stil

Tabelle 10: Begriffliches und bildliches Denken

Tabelle 11: Didaktische Grundprinzipien

Tabelle 12: Quantitative und qualitative Marketingziele

Tabelle 13: Marketingpolitische Instrumente

Tabelle 14: Kommunikationspolitik

Tabelle 15: Kurzübersicht über Corporate-Identity

Tabelle 16: Aussagen in der Unternehmenswerbung

Tabelle 17: Vor- und Nachteile computergestützter Dokumentation

Vorwort

Der Siegeszug der Personal Computer (PC) und seiner Anwendungen setzt sich fort - nicht nur in unserer Arbeitswelt, sondern auch in unserem Privatleben ist der Umgang mit dem Computer alltäglich geworden. Wir schreiben Briefe mit dem PC, erstellen aufwendige Tabellen, surfen im Internet, empfangen und versenden Emails und benutzen den PC zur Erledigung unserer Bankgeschäfte über Online-Banking. Dabei wird die Fülle der Möglichkeiten, die uns der Computer zur Bewältigung der verschiedensten Aufgaben bietet, immer größer und die einzelnen Programme immer komplexer.

Ein Beispiel hierfür ist ein Textverarbeitungsprogramm, das allerdings mehr kann als nur Briefe erstellen – die Möglichkeiten, die es bietet, übersteigen dabei weit die Grenzen der Textverarbeitung. Alleine das Handbuch zu Microsoft Word hat 864 Seiten. Neben diesem umfassenden Original-Handbuch von Microsoft füllen allerdings noch etliche andere Handbücher und Anleitungen zu Microsoft Word die Regale der großen Buchhandlungen. Daraus lässt sich schließen, dass die Nachfrage der Benutzer nach Anleitungen und Erklärungen entsprechend hoch ist.

Was schon für ein überschaubares Arbeitsgebiet wie die Textverarbeitung gilt, das kann man ebenfalls auf weitaus größere betriebswirtschaftliche Anwendungen übertragen. Anwendersoftware im allgemeinen wird immer umfangreicher und somit auch der Umfang der erklärenden und beschreibenden Texte hierzu wie z.B. Installationsanleitungen, Benutzer-Dokumentationen, Online-Hilfen und Schulungsunterlagen.

Auf der Seite der Softwareentwickler und –hersteller hat diese Entwicklung bereits ein Umdenken eingeleitet: die Bestrebungen führen dahin, Anwendersoftware intuitiv bedienbar zu gestalten. An allen denkbaren Stellen sollen Online-Hilfen und –texte dem Benutzer die Bedienung erleichtern.

Für die Anwender ist allerdings die schriftliche Benutzer-Dokumentation in den letzten Jahren immer wichtiger geworden und immer mehr in der Vordergrund gerückt. Es beschäftigen sich immer mehr Menschen mit immer komplexer werdenden Programmen. Durch die sich rasant verändernde Technologie und die erhöhten Anforderungen an die Anpassungsfähigkeiten der Benutzer, steigt auch deren Bedürfnis nach Erklärungen, Transparenz und Beherrschbarkeit der Programme.

Auf schriftliche Benutzer-Dokumentationen kann also nicht verzichtet werden. Das hat auch die Rechtsprechung erkannt, die die Dokumentation als rechtlichen Hauptbestandteil jeder Anwendersoftware definiert.^[1]

Darüber hinaus ist jede Benutzer-Dokumentation aber auch als ein zusätzliches, von der Konkurrenz abgrenzendes Marketinginstrument zu betrachten. Die Benutzer-Dokumentation ist ein wesentlicher Bestandteil der Unternehmenskommunikation und hat somit einen oft unterschätzten Stellenwert.

Die Benutzer-Dokumentation im speziellen hat die Aufgabe, Softwareprodukte für den Benutzer so zu erläutern, dass ihm die vorgesehene Nutzung des Systems ermöglicht wird. Die Komplexität dieser Aufgabe wächst mit der Funktionalität der benutzten Softwareprodukte.^[2]

Die Entwicklung von Benutzer-Dokumentationen hat einen interdisziplinären Charakter, da sie Kenntnisse auf verschiedenen Fachgebieten erfordert. Diese Fachgebiete betreffen u. a. neben dem Gegenstandsbereich der Dokumentation und der Arbeitsgebiete der potentiellen Benutzer auch psychologische Theorien über die Verarbeitung und das Verstehen von Texten sowie pädagogische Fragestellungen.^[3]

Um diesen interdisziplinären Anforderungen gewachsen zu sein, entwickelte sich das Berufsbild des Technischen Autors. In Deutschland wurde der erste akademische Ausbildungsgang 1990 an der Fachhochschule Hannover aufgebaut,^[4] wohingegen in Großbritannien und den USA der Beruf auf eine mindestens 50-jährige Geschichte zurückblicken kann.^[5]

Anwenderprobleme, für die eine Benutzer-Dokumentation keine Lösung anbietet, zerstören das Vertrauen der Benutzer nicht nur in das Produkt, sondern in das ganze Unternehmen. Eine gute Benutzer-Dokumentation dagegen verhindert Negativerlebnisse und hilft damit den Unternehmen, Geld zu sparen – bei Reklamationen, bei Reparaturen, beim Kundendienst, beim Service, in der Werbung und in der Öffentlichkeitsarbeit.

Diese Diplomarbeit gibt einen umfassenden Überblick über alle Anforderungen und Einflussgrößen, die sich auf Benutzer-Dokumentationen beziehen.

1. Einführung

Für eine ernsthafte Auseinandersetzung mit dem Thema „Anforderungen an Benutzer-Dokumentationen für betriebswirtschaftliche Anwenderprogramme“ zählen folgende Gründe:

- die kritische Haltung der Verbrauchervereinigungen, der Stiftung Warentest und der Presse gegenüber schlampiger Produktaufklärung,
- die verschärfte Auslegung der Produkthaftung,
- die zunehmende Qualitäts- und Kundenorientierung im Marketing sowie die Einflüsse der Corporate Identity-Strategen,
- die hohen Kosten im Kundendienst, in der Reklamationsbearbeitung und in der Garantieabwicklung,
- die nachlassende Beratungsqualität nachgelagerter Absatzmittler (z. B. „Aldi-Computer“)^[6]

Diese Diplomarbeit soll die tatsächliche Bedeutung des Themas hervorheben und die rechtlichen, wirtschaftlichen und strategischen Vor- und Nachteile einer intensiven Beachtung bzw. Vernachlässigung dieses Themas aufzeigen.

1.1 Wegweiser durch die Diplomarbeit

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Wegweiser durch die Diplomarbeit^[7]

In Kapitel 1 erfolgt neben der Einführung in das Thema eine Klärung der grundlegenden Begriffe dieser Diplomarbeit und deren Zusammenhang. Wichtige Begriffe wie z. B. Benutzer-Dokumentation und Anwenderprogramme werden definiert und das organisatorische Umfeld der Benutzer-Dokumentation wird betrachtet. In diesem Zusammenhang werden auch schon erste Einflussgrößen auf die Benutzer-Dokumentation und Anforderungen an diese herausgearbeitet. Das Kapitel 1 schließt sodann mit der Zusammenstellung von Anforderungen an Benutzer-Dokumentationen in Form einer Checkliste. Die Punkte dieser Checkliste werden in den nachfolgenden Kapiteln noch einmal aufgegriffen und vertieft.

Kapitel 2 soll einen Überblick geben über die verschiedenen Arten von Dokumentationen. Ziel dieses Kapitels ist ein besseres Verständnis des Gesamtzusammenhangs und damit die Eingrenzung dieses Themas.

Kapitel 3 beginnt sodann mit der Betrachtung erster allgemeiner Anforderungen an Benutzer-Dokumentationen. Hier wird zunächst einmal auf die äußere und innere Gestaltung von Benutzer-Dokumentationen eingegangen. Wie sollte die Benutzer-Dokumentation aussehen und wie sollte sie gegliedert sein? Darüber hinaus stellt das Kapitel 3.2 schon erste konkrete Anforderungen vor und erläutert sie. Diese Anforderungen an die Benutzer-Dokumentation sind allgemein gültig. Sie werden auch in den folgenden Kapiteln jeweils noch einmal angesprochen und vertieft.

Kapitel 4 ist den Normenorganisationen und deren Anforderungen an Benutzer-Dokumentationen gewidmet. Die wichtigsten Normenorganisationen sowie deren wichtigste Normen bezüglich Benutzer-Dokumentationen werden vorgestellt und erklärt.

Welche Gesetze Einfluss auf die Benutzer-Dokumentation haben, wird in Kapitel 5 dargestellt. Hier wird insbesondere auf den Schuldrechtsteil des BGB, auf das Produkthaftungsgesetz sowie auf die aktuelle Rechtsprechung eingegangen. Es soll explizit dargelegt werden, warum die Beachtung dieser Gesetze für Benutzer-Dokumentationen wichtig ist und welche Folgen die Nicht-Beachtung bzw. mangelnde Umsetzung dieser Anforderungen in der Praxis hat.

Kapitel 6 gibt eine Einführung in drei besonders wichtige und interessante Einflussbereiche auf Benutzer-Dokumentationen. Zuerst werden verschiedene Kommunikationstheorien betrachtet, die wichtig sind für die verständliche und empfängerorientierte Mitteilung der Benutzerinformationen. Die Motivationstheorien sollen sodann dabei helfen, zu verstehen, mit welcher Motivation sich die Benutzer dem Anwenderprogramm und seiner Dokumentation stellen und wie man diese Motivation positiv beeinflussen kann. Abschließend werden Erkenntnisse aus der Lernpsychologie und Didaktik wiedergegeben, die als Hintergrundwissen bei der Erstellung von Benutzer-Dokumentationen nützlich sind.

Kapitel 7 beschäftigt sich mit den Anforderungen des Marketings an Benutzer-Dokumentationen. Dazu werden neben den Aufgaben des Marketings auch die Marktforschung und die marketingpolitischen Instrumente betrachtet. Speziell im Marketing spielt die Benutzer-Dokumentation eine besondere Rolle.

Als letzte Anforderungen an Benutzer-Dokumentationen behandelt Kapitel 8 die Anforderungen aus Entwicklung und Technik. Hier wird zum einen auf die Anforderungen des technischen Produkts selbst eingegangen als auch auf die Anforderungen der Realisierung und Umsetzung der Benutzer-Dokumentation in einem Content-Management-System.

In Kapitel 9 werden sodann die Möglichkeiten der Umsetzung der Benutzer-Dokumentation in der Praxis erläutert. Hier kommen auch die verschiedenen Formen und Ausprägungen der Benutzer-Dokumentation im weitesten Sinne zum Einsatz wie beispielsweise die computergestützte Benutzer-Dokumentation und Tutorials. Daneben werden auch psychologische Aspekte vor, während und nach der Einführung eines neuen Anwenderprogramms angesprochen sowie die Software-Ergonomie.

Das 10. Kapitel beschäftigt sich ebenfalls mit der Praxis und zwar mit den Möglichkeiten zur Beurteilung von Benutzer-Dokumentationen. Hier gibt es verschiedene Methoden von verschiedenen Institutionen und Ansätzen her beispielsweise die PentaQuest-Methode oder die Prüfung durch Wirtschaftsprüfer.

Diese Diplomarbeit schließt ab mit einer Zusammenfassung und einem Fazit in Kapitel 11.

1.2 Begriffe und Organisationsumfeld der Benutzer-Dokumentation

Diese Diplomarbeit beschäftigt sich mit allen Arten von Anforderungen, die an Benutzer-Dokumentationen für betriebswirtschaftliche Anwenderprogramme gestellt werden.

Um das Thema genauer einzugrenzen und verständlicher zu machen, möchte ich schon vorweg einige der für diese Diplomarbeit elementaren Begriffe näher erläutern.

1.2.1 Grundlegende Begriffe, Definitionen und Abgrenzungen

1.2.1.1 Benutzer-Dokumentation

„Unter Benutzer-Dokumentation versteht man den Teil der Dokumentation des Programms, der für den Endanwender, den sogenannten Benutzer, bestimmt ist. Dazu gehört insbesondere das Handbuch, das erläutert, wie man mit der jeweiligen Software arbeitet.“^[8]

1.2.1.2 Betriebswirtschaftliche Anwenderprogramme

Unter betriebswirtschaftlichen Anwenderprogrammen versteht man alle Arten von Software, die zur Lösung betriebswirtschaftlicher Aufgabenstellungen beitragen sollen. Synonym dazu werden auch die Begriffe Anwendersoftware oder Anwendungssoftware benutzt. Das Spektrum dieser Anwenderprogramme reicht von kleineren Insellösungen wie z. B. einer einzelnen Buchhaltungssoftware bis zu Komplett-Lösungen wie z. B. das Enterprise Ressource Planning (ERP) System SAP R/3. In dieser Definition sind nicht enthalten Betriebssysteme, Programmiersoftware und alle Arten reiner „Vergnügungs-Software“.

Diese Abgrenzung der Anwenderprogramme ist meiner Meinung nach sinnvoll aus folgenden Gründen:

a) Die Zielgruppen der Anwender sind sehr unterschiedlich: z. B. die Programmierer, die sich beruflich mit Betriebssystemen befassen; die Jugendlichen, die sich in ihrer Freizeit gerne mit Computerspielen beschäftigen oder die Büroangestellten, die sich beruflich mit Buchhaltungs- und Textverarbeitungsprogrammen auseinandersetzen müssen.
b) Ebenso unterscheidet sich der Verwendungszweck der Software: Betriebssysteme haben den Zweck, eine Schnittstelle zwischen der Maschine und dem Benutzer herzustellen. Sie bilden lediglich die Plattform, um andere Anwendungen betreiben zu können. Während man sich mit Computerspielen in seiner Freizeit zum reinen Vergnügen beschäftigt, werden dagegen Anwenderprogramme hauptsächlich zum beruflichen Einsatz gebraucht.
c) Demzufolge ist auch die Motivation der Benutzer der Software sehr unterschiedlich: Der Spieler wird nur freiwillig und mit Spaß an seine Software herangehen (das Programm selbst ist motivierend è siehe Kapitel 3.4.5), während Anwender eines betriebswirtschaftlichen Programms eher beruflich mit der Software in Kontakt kommen und sie wohl eher von außen dazu motiviert werden, sich mit dem Programm zu beschäftigen (siehe Kapitel 3.4.5).

Betriebssysteme, Vergnügungssoftware und Anwenderprogramme besitzen somit verschiedene Voraussetzungen zur Erstellung von Benutzer-Dokumentation. Es sind jeweils andere Gesichtspunkte und Anforderungen zu beachten. Dennoch können auch die im Folgenden herausgearbeiteten Anforderungen analog zur Geltung kommen.

1.2.1.3 Anforderungen

Die Anforderungen, die an Benutzer-Dokumentationen gestellt werden, sind sehr vielfältig und kommen aus den verschiedensten Bereichen. Dies soll die folgende Übersicht veranschaulichen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Übersicht der Anforderungen an Benutzerdokumentationen^[9]

Alle Personen oder Organisationseinheiten, die mit der Benutzer-Dokumentation in Berührung kommen, stellen Anforderungen an diese. In vielen Punkten sind diese Anforderungen identisch, aber oft kommen auch immer wieder neue Aspekte hinzu. Diese unterschiedlichen Anforderungen stehen in Wechselwirkung miteinander und gelegentlich auch im Widerspruch zueinander.

Walter Rupietta berichtet aus der Praxis als Handbuch-Autor folgendes: „Es ist in der Praxis nicht die Regel, dass eine Dokumentationsanforderung im hier beschriebenen Sinne tatsächlich explizit formuliert und schriftlich fixiert wird. Häufig besteht die gesamte Anforderung in einem Satz wie ‚Zu dem neuen Produkt XYZ brauchen wir noch eine Benutzer-Dokumentation’.“^[10] Eine genaue Festlegung und Fixierung der Anforderungen ist jedoch zwingend erforderlich, um ein genaues Konzept zur Erstellung einer Benutzer-Dokumentation festzulegen und spätere Entwürfe dahingehend prüfen zu können, ob sie dem Konzept genügen.^[11]

1.2.2 Organisationsumfeld der Benutzer-Dokumentation

Die in der Abbildung 1 dargestellten Personen und Organisationseinheiten (Auftraggeber, Auftragnehmer, Benutzer, Verbraucherverbände, Normungsorganisationen, rechtliche Institutionen) sind nur Beispiele, die für bestimmte Rollen und Funktionen stehen. Von diesen Funktionen im Zusammenhang mit der Entwicklung von Benutzer-Dokumentationen gehen bestimmte Einflussfaktoren aus, die in jedem Fall wirksam sind – unabhängig davon, ob die oben genannten Personen und Organisationseinheiten tatsächlich vorhanden sind oder nicht. Im Extremfall sind alle Funktionen in einer Person vereinigt.^[12]

1.2.2.1 Auftraggeber

Auftraggeber einer Benutzer-Dokumentation ist in der Regel das Unternehmen, das die zu beschreibende Software auf den Markt bringt. Abhängig von der Art und der Größe dieser Unternehmensorganisation können unterschiedliche Organisationseinheiten als Auftraggeber in Betracht kommen. In einem kleinen bis mittelständigen Unternehmen wird es wahrscheinlich der Firmeninhaber oder Geschäftsführer sein, der den Auftrag vergibt. In größeren Unternehmen kann sowohl die Entwicklungsabteilung, die Marketingabteilung oder allgemein die Verwaltung dafür verantwortlich sein. Je nach verantwortlichem Abteilungsbereich können auch die dort gestellten Anforderungen an die Benutzer-Dokumentation unterschiedlich sein. Die Marketingabteilung legt eventuell einen besonders hohen Stellenwert auf die Werbewirksamkeit und Zielgruppengenauigkeit der Benutzer-Dokumentation, die Entwicklungsabteilung stellt vielleicht besonders die Komplexität des Programms und dessen Möglichkeiten in den Vordergrund während die Verwaltung auf möglichst geringe Kosten bei hoher Auflage achtet.

1.2.2.2 Auftragnehmer

Auftragnehmer sind häufig interne oder externe Technische Autoren, die auf die Erstellung von Benutzer-Dokumentationen spezialisiert sind. Ein interner technischer Redakteur kann direkt einer Softwaregruppe, die ein Softwareprodukt entwickelt oder einer Softwareentwicklungsabteilung angehören und ist damit in der Lage, aufgrund seiner unmittelbaren Beteiligung an der Produktentwicklung die Dokumentation parallel dazu zu entwickeln. Externe technische Autoren sind selbständig tätig und somit nicht in der Unternehmensorganisation des Auftraggebers verankert. Dadurch haben sie eventuell einen objektiveren und unverstellteren Blick auf das Produkt und seine Zielgruppe. Oft ist es auch ein Team von externen technischen Redakteuren, die sich auf unterschiedliche Aspekte der Benutzer-Dokumentation spezialisiert haben.^[13]

Darüber hinaus können die Auftragnehmer aber auch aus dem Marketing- oder Vertriebsbereich des Unternehmens kommen. Diese haben in der Regel bessere Kenntnisse über die Zielgruppen, die die Benutzer-Dokumentation ansprechen soll, aber auch andere Anforderungen an die Benutzer-Dokumentation als beispielsweise die Entwicklungsabteilung.^[14]

In kleineren Unternehmen erstellt häufig auch ein Softwareentwickler in einer Entwicklungsabteilung neben Softwaremodulen auch die Benutzer-Dokumentation. Das ist ein Beispiel, in dem mehrere oder alle der aufgezählten Funktionen in einer Person vereinigt sind.^[15]

In der Regel wird der Auftragnehmer die Benutzer-Dokumentation nicht isoliert, sondern in Zusammenarbeit mit anderen Organisationseinheiten erstellen. Hieraus ergeben sich Schnittstellen zu anderen Unternehmensbereichen, wie z. B. zur Entwicklungsabteilung oder zur Marketingabteilung. Welche Schnittstellen letztendlich eine Rolle spielen, hängt natürlich von der Art und der Größe des Unternehmens und der zu erstellenden Benutzer-Dokumentation ab. Einige mögliche Schnittstellen verdeutlicht die folgende Abbildung:^[16]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Schnittstellen zu anderen Organisationseinheiten^[17]

- Aus der Softwareentwicklung kommen die technischen Informationen zu dem zu beschreibenden Produkt. Insbesondere bei neu entwickelten Produkten kommt aus dieser Abteilung der entscheidende Input.
- Die Marketingabteilung bzw. der Vertrieb gibt Informationen über den Markt für das Produkt und über die Zielgruppe der Dokumentation. Dies kann besonders wichtig sein bei überarbeiteten Dokumentationen zu bereits existierenden Produkten, die den Einsatzzweck oder die Zielgruppe der Anwendersoftware genauer und direkter ansprechen soll.
- Die Schulungsabteilung kann Hilfestellung leisten in Bezug auf didaktische Fragen beim Aufbau der Dokumentation. Darüber hinaus sollten weitere Schulungsmaßnahmen mit ihr abgestimmt werden.
- Unter die zentralen technischen Dienste fallen alle Dienstleistungen, die ein Autor bei der Erstellung der Benutzer-Dokumentation benötigt, z. B. Schreibdienst, Fotograf und Fotolabor, technische Zeichner und Druckerei.^[18]

1.2.2.3 Normungsorganisationen

Die wichtigsten Normungsorganisationen sind:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Normenorganisationen^[19]

Diese Normungsorganisationen haben zur Vereinheitlichung der Dokumentationstechniken eine Reihe von Normen erarbeitet und veröffentlicht. Für den deutschsprachigen Raum sind die DIN-Normen am bedeutsamsten.

Diese Normen sind nicht rechtlich zwingend (d.h. müssen nicht befolgt werden). Dennoch empfiehlt sich ihre Einhaltung, da einerseits die Wirtschaft insgesamt um Vergleichbarkeit und Standardisierung bemüht ist und andererseits die eigene Rechtsposition im Zweifelsfall gestärkt ist.

Auf die Normungsorganisationen gehe ich in Kapitel 4 noch näher ein.

1.2.2.4 Benutzer und Verbraucherschutzverbände

Weitere Anforderungen an die Benutzer-Dokumentation stellen natürlich auch die Benutzer und für diese stellvertretend auch die Verbraucherschutzverbände. Denn was nutzt einem Benutzer die ausführlichste Dokumentation, wenn sie ihn nicht zum Gebrauch der Software befähigt?

Manche Verbraucherzeitschriften räumen sogar jeden Monat unverständlichen Gebrauchsanleitungen eine eigene Spalte ein.

Hier einige anschauliche Beispiele aus Zeitschriften zum Thema Benutzer-Dokumentation (bzw. Gebrauchsanweisung):

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Beispiele für Anleitungstexte^[22]

1.2.2.5 Rechtsprechung

Als sozusagen letzte Instanz stellt die Rechtsprechung ebenfalls Anforderungen an Benutzer-Dokumentationen. Bei gerichtlichen Auseinandersetzungen über die Vollständigkeit und Richtigkeit von Softwareprodukten und ihrer Dokumentation muss die Rechtsprechung abschließend darüber entscheiden, ob die an eine Benutzer-Dokumentation (zu Recht) gestellten Erwartungen und Anforderungen auch tatsächlich erfüllt sind. Dazu greift sie oft genug auf die DIN-Vorschriften zurück (siehe Kapitel 5).

In der folgenden „Checkliste“ möchte ich noch einmal alle bisher kennengelernten Anforderungen an Benutzer-Dokumentationen zusammenfassend festhalten. In den weiteren Kapiteln wird diese Checkliste abgearbeitet: d.h. die einzelnen Punkten werden angesprochen, weitergehend erklärt und spezifiziert.

1.3 Checkliste für Dokumentationsanforderungen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Checkliste für Dokumentationsanforderungen^[23]

2. Welche Arten von Dokumentation gibt es?

Der Erfolg jeder Anwendersoftware hängt von den folgenden drei dargestellten Säulen ab. Dieses Bild zeigt, dass die Dokumentation ein integraler Bestandteil des Gesamtsystems ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Software-Fabrik^[24]

Gemäß einer Definition von Schulze ist Dokumentation die Tätigkeit der „Beschreibung und Aufbewahrung aller Unterlagen, die bei der Erstellung eines Programms entstanden sind.“ Aber nicht nur die Tätigkeit der Dokumentation selbst, sondern auch das Ergebnis dieser Tätigkeit (nämlich die entstandenen Unterlagen und Dokumente) wird üblicherweise als Dokumentation bezeichnet.^[25]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Einteilung der EDV-Dokumentation in Teilbereiche^[26]

Grundsätzlich teilt man die Gesamtdokumentation eines Software-Projektes in zwei große Bereiche

- Projekt-Dokumentation
- Technische Dokumentation

ein. Die Projekt-Dokumentation nimmt dabei eine gewisse Sonderstellung ein, da sie zwar für den Ablauf der Projektabwicklung wichtig ist, nach Abschluss des Projektes aber nur noch geringe Bedeutung hat (z. B. für die Nachkontrolle der Aufwandsabschätzungen usw.).^[27]

Die Technische Dokumentation kann man wiederum in zwei Untergruppen unterteilen:

- Entwicklungs-Dokumentation
- Programm-Dokumentation

Die folgende Tabelle 1 zeigt eine Übersicht über diese drei Dokumentationsgruppen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Dokumentationsbereiche^[28]

Während einer Software-Entwicklung ist die Dokumentation in den Ablauf eines Phasenkonzepts eingebettet. Die folgende Übersicht veranschaulicht die parallele Entwicklung der Software und der Dokumentation und zeigt beispielsweise ein solches Phasenkonzept. In der Fachliteratur der EDV-Dokumentation sind auch andere Bezeichnungen, Untergliederungen und Abgrenzungen anzutreffen.^[29]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Phasenkonzept eines EDV-Anwendungssystems^[30]

2.1 Projekt-Dokumentation

Die Projekt-Dokumentation umfasst alle Unterlagen zur Auslösung, Planung und Steuerung des Softwareprojekts. Gleichbedeutend ist der Ausdruck Projektablaufdokumentation oder Projektmanagementdokumentation. Hierzu zählen beispielsweise folgende wesentliche Unterlagen:

- der Projektauftrag
- Schriftwechsel über den Projektablauf
- Wirtschaftlichkeitsberechnungen
- Arbeitsaufträge
- Zeitüberwachungsblätter
- Wichtige Sitzungsprotokolle

Die Projekt-Dokumentation soll jederzeit Auskunft geben können über wichtige Ergebnisse und Fortschritte sowie den Status des Projekts. Das Projektbudget weist dabei die Höhe der Projektinvestitionen aus und Kosten-/Nutzenrechnungen geben Auskunft über die Wirtschaftlichkeit.^[31]

2.2 Technische Dokumentation

Der Projekt-Dokumentation steht die Technische Dokumentation gegenüber. Sie hat die Dokumentation aller Entwicklungs- und Implementierungsphasen eines Software-Projekts zum Inhalt. Sie wird in der Fachliteratur auch Systemdokumentation, Anwendungsdokumentation oder Verfahrensdokumentation genannt.^[32]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Unterteilung Technische Dokumentation^[33]

Die technische Dokumentation wird unterteilt in die Entwicklungs-Dokumentation und in die Programm-Dokumentation.

2.2.1 Entwicklungs-Dokumentation

Was die Entwicklungs-Dokumentation alles enthalten und beschreiben sollte, legt die DIN-Norm 66 231 vom Oktober 1982 fest. Diese Norm ist als Hilfsmittel gedacht für jeden, der sich im weiteren Sinne mit der Entwicklung von Software beschäftigen muß. Sie soll der Kommunikation zwischen allen an der Programmentwicklung beteiligten Personen dienen.

Die Norm setzt sich folgende Ziele:

- Festlegung der sachlichen Voraussetzungen bei der Zusammenarbeit verschiedener Aufgabenträger an einer Programmentwicklung
- Erleichterung einer Weiter- oder Neuentwicklung eines Programms
- Möglichkeit der Überprüfung der Programmentwicklung^[34]

Allerdings hat das Deutsche Institut für Normung e. V. dieser DIN-Norm kein einheitliches Phasenkonzept vorgeschrieben, da dies aufgrund der vielfältigen Anwendungsgebiete im kaufmännischen, technischen oder wissenschaftlichen Bereich sowie der jeweils verschiedenen organisatorischen Rahmenbedingungen kaum möglich ist. Deshalb muss der Anwender der Norm selbst die für den jeweiligen Entwicklungsprozess relevanten Schnittstellen bestimmen und festlegen. Die Schnittstellen ergeben sich jeweils an zwei aufeinanderfolgenden Entwicklungsabschnitten.^[35]

An diesen selbst bestimmten Schnittstellen fordert die Norm die Bereitstellung der folgenden Angaben:

- Angabe der sachlichen Grundlagen für die Programmentwicklung bis zur nächsten Schnittstelle (Entwicklungsabschnitt)
- „Begründung für die während der Programmentwicklung getroffenen Sachentscheidungen, z. B. über die Auswahl von Verfahren und Festlegung des Leistungsumfangs.“^[36]

Im Anhang B der Norm findet sich auch ein Beispiel für die Erstellung eines Planes für eine Programmentwicklungsdokumentation. Anhand der nachfolgenden Tabelle kann man sodann schon erahnen, was diese Dokumentation im Einzelnen alles umfasst:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Schnittstellen zwischen den Entwicklungsabschnitten^[37]

Die DIN-Norm 66231 zur Programmentwicklungsdokumentation stellt auch die Grundlage dar für eine darauf aufbauende Programmdokumentation nach DIN 66230.^[38]

2.2.2 Programm-Dokumentation

Die Deutsche Industrie-Norm DIN 66230 vom Januar 1981 bezeichnet die Programm-Dokumentation als die Gesamtheit der zur Anwendung von Software erforderlichen Angaben.

„Die Programmdokumentation ist notwendige Voraussetzung für die Anwendung eines Programms. Sie dient als Grundlage für die Entscheidung über den Einsatz eines Programms sowie als Hilfsmittel bei der zweckentsprechenden und wirtschaftlichen Installierung, Benutzung, Fehlerbeseitigung, Aktualisierung und Schulung.“^[39]

Die DIN-Norm 66230 legt den Inhalt der Programm-Dokumentation fest. Eine vollständige Programm-Dokumentation muss Aussagen zu allen vorgegebenen Teilen machen, kann aber dazu auf andere Dokumentationswerke verweisen. Wenn bestimmte Angaben nicht zutreffen oder aus wirtschaftlichen Gründen nicht weitergegeben werden sollen, muss angegeben werden, dass diese entfallen. Die Nutzung der Software darf dadurch aber nicht beeinträchtigt werden.^[40]

Die Dokumentation von Betriebssystemen (einschließlich betriebssystem-nahen Steuerprogrammen) wird durch die DIN 66230 nicht abgedeckt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Unterteilung Programmdokumentation^[41]

Die DIN 66230 gliedert die Programmdokumentation in zwei Teile. Dabei geht sie davon aus, dass für die Anwendung des Programms (z. B. im Fachbereich) und für die Installierung, Betrieb und Pflege des Programms (im Datenverarbeitungsbereich) unterschiedliche Informationen benötigt werden. Demnach werden alle der Norm nach erforderlichen Angaben entweder der Benutzer-Dokumentation (Anwendungshandbuch) oder der Datenverarbeitungstechnischen Dokumentation (DV-Handbuch) zugeordnet. Dabei versucht die Norm Wiederholungen und
Überschneidungen weitgehend zu vermeiden. ^[42]

2.2.2.1 Datenverarbeitungstechnische Dokumentation (DV-Handbuch)

Gemäß der DIN-Norm 66230 enthält das DV-Handbuch alle „Informationen, die zur Installierung, zum Betrieb und zur Pflege des Programms notwendig sind.“^[43] Hierunter fällt auch die Rechenzentrums-Dokumentation und die Wartungs-Dokumentation (siehe Abbildung 7).

Das DV-Handbuch enthält neben den Programmkenndaten eine komplette Programmbeschreibung. Diese enthält beispielsweise Angaben über die interne Programmstruktur, über Programmbausteine, Algorithmen, Datenfluß- und Programmablaufbeschreibungen sowie über die Datensicherung. In einem weiteren Kapitel sollen alle Informationen bezüglich Installierung und Tests des Programms dokumentiert werden. Abschließend enthält das DV-Handbuch eine ausführliche Dokumentation des Programm-Betriebs. Dazu gehört die Beschreibung des Gerätebedarfs (Zentraleinheit, Daten- und Prozessperipherie, etc.), Informationen zur Bedienung (Betriebsarten, Steueranweisungen, etc.) sowie zu Unterbrechungen im Programmablauf und den Wiederanlauf.

2.2.2.2 Benutzer-Dokumentation

Die DIN-Norm 66230 nennt die Benutzer-Dokumentation Anwendungshandbuch und definiert es wie folgt: „Das Anwendungshandbuch soll allen, die das Programm für die Lösung ihrer Aufgaben einsetzen, die für die sinnvolle Anwendung des Programms erforderlichen Informationen zur Verfügung stellen.“^[44]

Da diese Diplomarbeit sich im allgemeinen mit der Benutzer-Dokumentation und im speziellen mit den Anforderungen an diese beschäftigt, möchte ich an dieser Stelle nicht weiter auf die Benutzer-Dokumentation als solche eingehen. An dieser Stelle soll lediglich eine Einordnung in den Gesamtzusammenhang stattfinden.

2.2.2.3 Gegenüberstellung DV-Handbuch und Benutzer-Dokumentation

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: DV-Handbuch und Benutzer-Dokumentation^[45]

Die obige Abbildung zeigt schon deutlich den Unterschied im Umfang der beiden Dokumentationsarten.

Zur Veranschaulichung der inhaltlichen Unterschiede dieser beiden Teile der Programm-Dokumentation stelle ich im folgenden die gekürzten Gliederungen einander gegenüber.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 5: Gliederung DV-Handbuchs und Benutzer-Dokumentation^[46]

3. Allgemeine Anforderungen an Benutzer-Dokumentationen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Allgemeine Anforderungen^[47]

In dieser Einführung möchte ich mich dem Thema zunächst einmal von außen nähern: Wie sollte eine Benutzer-Dokumentation aussehen?

Sodann kann sich jeder schon einmal mehr unter diesem Thema vorstellen und hat einen groben Überblick über den Aufbau einer Benutzer-Dokumentation. Zu dem Aufbau möchte ich anschließend noch einige allgemeine Anmerkungen machen, bevor ich in den nächsten Kapiteln zu möglichst allgemeingültigen Anforderungen an die Benutzer-Dokumentation und somit zum Inhalt dieser komme.

3.1. Aufbau einer Benutzer-Dokumentation

Wie sollte eine Benutzer-Dokumentation aussehen?

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Aufbau einer Benutzer-Dokumentation^[48]

3.1.1 Äußere Gestaltung

Zunächst einmal gibt es ein typisches Aussehen der Benutzer-Dokumentationen für Software-Produkte:

Die häufigsten Formate sind entweder Buch-Format oder Ordner-Format. Liegt die Benutzer-Dokumentation im Buch-Format (DIN A5) vor, so ist sie entweder in gebundener Form oder als Taschenbuch verfügbar. Beim Ordner-Format (DIN A4) ist eine „Lose-Blatt-Sammlung“ in Ringordnern üblich, aber auch eine eingebundene Form möglich.

Für Benutzer-Dokumentationen einer Firma spielt hier das „Corporate Design“ der Firma eine große Rolle. Die Benutzer-Dokumentationen sollten diesem Corporate Design folgen und einheitlich aussehen. Um verschiede Bände zu verschiedenen Software-Produkten oder verschiedene Versions-Nummern gut unterscheiden zu können, sollten z. B. verschiedene Kennfarben eingesetzt werden. In jedem Fall wichtig ist die eindeutige Kennzeichnung auf dem Buch- (bzw. Ordner-) rücken mit Angabe des Kurztitels und der Versions-Nummer. Ein ansprechendes Äußeres spielt neben dem Inhalt ebenfalls eine große Rolle, da es beim potentiellen Käufer oder Benutzer der Software den ersten Eindruck ausmacht.

3.1.2 Gliederung

Schlägt man nun die Benutzer-Dokumentation auf, so können die hier gängigsten Bausteine aus der obigen Abbildung bereits im Inhaltsverzeichnis abgelesen werden. Die hier gewählte Reihenfolge der Bausteine ist frei gewählt und nicht festgelegt.

a) Inhaltsverzeichnis
b) Produktidentifizierung
c) Produktbeschreibung
d) Sicherheitshinweise
e) Vorwort / Einleitung
f) Fachwörter, Abkürzungen
g) Anleitungsteil
h) Angaben zu Pflege, Wartung und Störungshilfe
i) Optionale Module und Extras
j) Garantie- und Kundendiensthinweise
k) Technische Daten
l) Literatur, Stichwörter, Glossar

An dieser Stelle möchte ich kurz zu den erwähnten Bausteine Stellung nehmen:

Zu a) Inhaltsverzeichnis

Ein Inhaltsverzeichnis am Anfang verdeutlicht Textaufbau und –gliederung und gibt Hinweise zum Nachschlagen ausgewählter Aspekte.

Zu b) Produktidentifizierung

Die Benutzer-Dokumentation muss klar auf die gelieferte Software bezogen sein. Dazu gehören Angaben wie beispielsweise die Produktmarke und Typbezeichnung, die Produktversion, die Release-Nummer, Name und Adresse des Herstellers oder Lieferanten. Darüber hinaus ist aber auch die Benutzer-Dokumentation genau zu kennzeichnen, damit der Benutzer auch erkennen kann, dass es sich um eine aktuelle Version handelt. Die Anleitung sollte zumindest gekennzeichnet sein mit einer Identitätsnummer und einem Ausgabedatum.

[...]

---

^[1] vgl. BGH, Urteil vom 04.11.1992, BGH CR 1993, S. 203 ff.

^[2] vgl. Rupietta, W., Benutzer-Dokumentation für Softwareprodukte, Angewandte Informatik, Bd. 3, Zürich, 1987, S. 5

^[3] vgl. Rupietta, a. a. O. Seite 6

^[4] vgl. Obert, A., Qualifikation Technischer Redakteur, http://www.techwriter.de/thema/qualifik.htm vom 10.04.03

^[5] vgl. O. V.: tekom-Leitlinie Aus- und Weiterbildung, http://www.tekom.de/pdf/leit_auw.pdf, S. 6, vom 10.04.03

^[6] vgl. o.V., Bevor die Fetzen fliegen, Absatzwirtschaft 10/88, S. 102

^[7] eigene

^[8] Redeker, H., Der EDV-Prozeß, München, 1992, S. 255

^[9] eigene

^[10] Rupietta, W., Benutzerdokumentation für Softwareprodukte, Angewandte Informatik, Bd. 3, Zürich, 1987, S. 27

^[11] vgl. Rupietta, W., Benutzerdokumentation für Softwareprodukte, Angewandte Informatik, Bd. 3, Zürich, 1987, S. 27

^[12] vgl. Rupietta, a. a. O. Seite 18

^[13] vgl. Rupietta, W., Benutzerdokumentation für Softwareprodukte, Angewandte Informatik, Bd. 3, Zürich, 1987, S. 18

^[14] vgl. Rupietta, a. a. O. Seite 18

^[15] vgl. Rupietta, a. a. O. Seite 18

^[16] vgl. Rupietta, a. a. O. Seite 18

^[17] Rupietta, W., Benutzerdokumentation für Softwareprodukte, Angewandte Informatik, Bd. 3, Zürich, 1987, S. 19, Abb. 1-1

^[18] vgl. Rupietta a. a. O Seite 19/20

^[19] eigene

^[20] Schmidt, W., Nix verstehen – Gebrauchsanweisungen, Capital, 9/2001, S. 112-114

^[21] o. V., Gebrauchsanleitungen: Text vom Techniker, Wirtschaftswoche, Nr. 42, 1987, S. 77-80

^[22] eigene

^[23] eigene

^[24] Scheibl, H., Wie dokumentiere ich ein DV-Projekt?, Kontakt & Studium, Bd. 169, Sindelfingen, 1985, S. 48

^[25] vgl. Schulze, H., Lexikon zur Datenverarbeitung, Reinbek, 1978

^[26] eigene

^[27] vgl. Scheibl, H., Wie dokumentiere ich ein DV-Projekt?, Kontakt & Studium, Bd. 169, Sindelfingen, 1985, S. 15

^[28] vgl. Biewald, J., Dokumentation von Automatisierungs-Software, Regelungs-technische Praxis, 1983, S. 238

^[29] vgl. Grupp, B., EDV-Projekte richtig dokumentieren, Köln, 1991, S. 10

^[30] vgl. Grupp, B., EDV-Projekte richtig dokumentieren, Köln, 1991, S. 10, Bild 1-2

^[31] vgl. Grupp, B., EDV-Projekte richtig dokumentieren, Köln, 1991, S. 35

^[32] vgl. Grupp, B., EDV-Projekte richtig dokumentieren, Köln, 1991, S. 61

^[33] eigene

^[34] vgl. DIN 66231, Programmentwicklungsdokumentation, 1982, S. 1

^[35] vgl. DIN 66231, Programmentwicklungsdokumentation, 1982, S. 27

^[36] DIN 66231, Programmentwicklungsdokumentation, 1982, S. 1

^[37] DIN 66231, Programmentwicklungsdokumentation, 1982, S. 25, Bild B 1

^[38] vgl. DIN 66231, Programmentwicklungsdokumentation, 1982, S. 27

^[39] DIN 66230, Programmdokumentation, 1981, S. 1

^[40] vgl. DIN 66230, Programmdokumentation, 1981, S. 1

^[41] eigene

^[42] vgl. DIN 66230, Programmdokumentation, 1981, S. 13

^[43] DIN 66230, Programmdokumentation, 1981, S. 14

^[44] DIN 66230, Programmdokumentation, 1981, S. 13

^[45] vgl. Zahrnt, C., DV-Verträge: Rechtsfragen und Rechtsprechung, Hallbergmoos, 1987, S. 33

^[46] vgl. DIN 66230, Programmdokumentation, 1981, S. 13

^[47] eigene

^[48] vgl. Scheibl, H., Wie dokumentiere ich ein DV-Projekt?, Kontakt & Studium, Bd. 169, Sindelfingen, 1985, S. 9