Documentation Plan Example

Abstract
Software Information:
Operating System:
Author Information:
United Bank of Switzerland,
Copyright © 1998 by United Bank of Switzerland (UBS).
Documentation Plan
(for a Generic Project or Consultancy Service)
(DRAFT)
Version 0.2
9th Sept. 1998
This document contains a generic documentation plan which
can be customised for any product or project. It can also be
used as the basis for a consultancy report.
<XYZ Application Vx.y>
<Windows NT 4.0 SP3>
G. Turnbull, xxx, yyy,
[C:DocsConsult.Bok]
I7MK-TUB, Zürich.

ii Documentation Consultancy
Copyright © 1998 by United Bank of Switzerland (UBS).
The information contained in this document is proprietary to UBS, and must not be repro-
duced, stored in a retrieval system, or transmitted in any form, or by any means (electronic,
mechanical, photocopy, or otherwise), nor can it be distributed to any third party or exter-
nal organization without prior written consent from UBS.
Trademarks
The following are registered trademarks of the Microsoft Corporation:
Microsoft MS MS-DOS
Windows Windows NT Windows ‘95

Documentation Consultancy iii
Table of Contents
Preface ......................................................................................................................1-v
1 Introduction ......................................................................................................1-1
1.1 Project/Product Overview ..............................................................................1
1.2 General Considerations ..................................................................................1
1.3 What Type of Documentation? ......................................................................2
1.4 Program Texts ................................................................................................3
1.5 Training Materials ..........................................................................................3
1.6 On-Line Documents.......................................................................................3
1.7 Structure of a Typical Document....................................................................4
1.8 Document Contents........................................................................................5
1.9 Sources of Information...................................................................................5
1.10 User Considerations .......................................................................................6
1.11 Documentation Tools .....................................................................................7
1.12 Graphics .........................................................................................................7
1.13 Printing...........................................................................................................8
1.14 Documentation Staff.......................................................................................8
1.15 Document Standards ......................................................................................9
1.16 Document Distribution...................................................................................9
1.17 Document Storage........................................................................................10
1.18 Product Lifecycle .........................................................................................10
1.19 Document Maintenance................................................................................ 11
1.20 Security and Confidentiality......................................................................... 11
1.21 Copyright and Liability................................................................................12
1.22 Internationalisation.......................................................................................12
1.23 Timescales....................................................................................................12
1.24 Costs.............................................................................................................13

Table of Contents
iv Documentation Consultancy
2 Document Descriptions ....................................................................................2-1
2.1 Document #1 ..................................................................................................1
3 Conclusions & Recommendations ..................................................................3-1
Appendix A Additional Information..................................................................1
Appendix B Bibliography ...................................................................................1
Index

Documentation Consultancy v
Preface
This document contains the documentation plan for <XYZ>.
Intended Audience
This document is intended for:
• Management
• Project Managers
• Documentation Staff
Organization of this Document
This document is organized as follows:
• Chapter 1 describes the documentation considerations.
• Chapter 2 contains the document descriptions.
• Chapter 3 contains the conclusions and recommendations.
• Appendix A contains additional information.
• Appendix B is a Bibliography of related documents.
Change History
This is a new document.

Preface
vi Documentation Consultancy

Documentation Consultancy 1-1
1 Introduction
This document contains the documentation analysis, considerations, and recom-
mendations for <Product XYZ>. This plan defines what documents will be pro-
duced, where the information to do this will be obtained, how the documents will
be produced, what tools and standards will be used, who will carry out the work,
some cost and timescale guidelines, and any other relevant considerations.
1.1 Project/Product Overview
<Add a brief Summary or Overview of the Product or Project here.>
This shows that the consultant has listened carefully to the client, read all the back-
ground material, and understood the full scope/functions of the product/project.
1.2 General Considerations
This section defines the general considerations that affect documentation:
• What type of documentation is required?
Hardcopy (printed), CD-ROM/on-line (PDF or Help), web-based (HTML),
etc.
• What type of work is involved?
Creation of new documents from scratch, editing/updating existing infor-
mation, or an on-going project with regular updates, etc.
• What sort of staff are required?
Internal (current or new), on-site Contractor, or Third-Party (specialist)
Company.
• What hardware systems are in use?
(Mac, PC, Unix, VAX, etc.); note that the users and developers may have
different systems!
• Operating System (W98, NT4, Unix, VMS, etc.); this is obviously hard-
ware-related.
• Office Space, Building Access, Secretarial Facilities, etc.; if the documenta-
tion is being done by contractors or an external company, then they must
have access to client facilities (at least occasionally).
Note that the client management and project staff should read this document care-
fully, then reconsider this section to determine what type of documentation project
should be initiated.

What Type of Documentation?
1-2 Documentation Consultancy
1.3 What Type of Documentation?
This section defines what types of documentation will be produced. Once a careful
study of the product or project has been made, specific document descriptions can
be given in Chapter 2. Examples include:
• Release Notes
• Installation Guide
• Configuration Guide (if not in the above)
• System Manager’s Guide
• Operator’s Guide (if not in the above)
• Project/Product Overview (can be used for presentations and marketing)
• User’s Guide (simple or detailed)
• Tutorials (optional, possibly on-line [multimedia] versions?)
• Training courses and handouts
• Reports and Presentation materials
• Quick-Reference Guide (special format/printing)
• Technical Reference Guide (including a Glossary of Terms)
• Marketing/Promotional Materials (use of colour, special printing, etc.)
Generic documents, such as overviews, templates, and a glossary of terms/bibliog-
raphy should also be maintained.
Also, on-line Help, program texts, web information, etc. High profile, complex
products may require the creation of training courses and courseware. Note that
this is something of a specialist subject, and is obviously expensive, labour-inten-
sive, and time-consuming.

Program Texts
1.4 Program Texts
This section describes the documentation considerations for program texts. Tech-
nical writers can often advise developers on the human interface aspects of com-
puter software, which is one reason why they should be consulted early and get
involved in the project lifecycle. In addition, the texts that the users see should
always be reviewed by a technical writer for clarity, usefulness, language, etc.
Program texts include:
• Menus
• Information Messages
• Error Messages
• Help screens
• Dialog boxes
This is often an overlooked, but important aspect of documentation. It is important
because the user may be incapable of using a product if it is not immediately clear
what should be done. If possible, the developer should create such texts in an
ASCII text file; these simplify the editing and updating process, and are especially
useful if the documentation will be translated.
1.5 Training Materials
This is a special class of documentation and ranges from simple tutorials and on-
line Help to full training course and related materials (either on-line or in a class-
room environment).
1.6 On-Line Documents
This section describes the considerations for the on-line materials. Note that it is
not sufficient to simply dump the contents of the printed manuals in an electronic
format and call it “on-line Help”. On-line Help should be specific, brief, usually
task-oriented, with real-world examples; if possible, it should also be context-sen-
sitive. This can either be done by using conditional text in the printed documenta-
tion, or by custom documentation files which are maintained separately (object-
oriented documentation systems, such as Interleaf, are useful here). In the PC
world, the latest thing in on-line Help is Microsoft’s HTML Help format, which is
an executable file compiled from several HTML topic files; a ToC and a search-
able Index can be added.

Structure of a Typical Document
1.7 Structure of a Typical Document
This section describes the structure of a typical document.
Note: All documents of a particular series should have a similar appearance. This
usually involves the use of style files and templates, which should be designed and
made available in advance of the project.
• Cover Page: This should be a standard, clear layout containing only rele-
vant information (project/product & document title, version, print date, soft-
ware information, author information, document information, etc.) and the
company’s logo.
• Front Material (copyright notices, trademarks, acknowledgments, etc.)
• Table of Contents (automatic, but should be checked for clarity; a useful
method of evaluating the document’s structure if an Outliner is not being
used.)
• List of Figures/Tables/[Equations] (as necessary)
• Preface (may be optional in short documents, but should include certain
standard sections, such as a brief overview, intended audience, prerequisite
knowledge, structure of the document, terms and conventions used, docu-
ment history, related documents (if no Bibliography), etc.)
• Note that some large, technical documents are divided into logical Parts.
• Introduction (or Summary, Overview, etc.; the first chapter.)
• Body Text: the bulk of the document organized into logical chapters, each
one subdivided into clear, organized sections); note that technical docu-
ments often use numbered sections for ease of reference; more general doc-
uments may not require this.
• Appendices: any additional or related information which is either too large,
or would otherwise interrupt the flow of the main document. Once again
this information should be organized into logical sections.
• Glossary of Terms: If the document contains a lot of complex or unfamiliar
terms, it may be useful to list these and expand them in a Glossary at the end
of the document. (Note that a generic Glossary can then be maintained for
the whole documentation set). It is especially important to define terms that
may be familiar to the user, but which are used slightly differently in this
document (although this practice is not recommended).
• Bibliography: If necessary, full details of all the documents quoted in the
text.
• Index: This is an essential, often overlooked aspect of the documentation.
Users seldom read documents more than a few pages from cover to cover.

Document Contents
Instead, they will try to locate the information they need from the product,
the [searchable] on-line Help (if any), and then (often as a last resort) from
the printed texts. Because this is a universal truth, it is necessary that users
can locate the information they require quickly and easily; otherwise they
will give up and call Technical Support or the Help Desk (if available). This
means that a high quality Table of Contents and Index are essential items of
any document (the only exception being short, introductory documents
which will only be read once, and therefore do not need an index).
Indexing is a complex, difficult task, and whole books have been written on
the subject. The software will often provide the basic tools required to cre-
ate an index, but it is left to the experience of the documentation staff to cre-
ate a high quality index (with synonyms, good structure, etc.) that users
often need and seldom get. On-line documentation, which can be indexed,
and is available for full-text searching is often an advantage here, as is task-
oriented, context-sensitive on-line Help.
1.8 Document Contents
This section gives some general guidelines to the contents of the documentation.
1.9 Sources of Information
This section describes how the documentation staff will obtain the information
required to create the documentation:
• Developers (demonstrations & discussions)
• Existing Documents (Project Specifications, Documentation, etc.)
• Applications (i.e., using the product)
• Code/Comments (a time-consuming last resort!)
• Feedback from users (not always possible)

User Considerations
1.10 User Considerations
Is the documentation intended for internal use only, or will it be supplied to exter-
nal users? Internal documentation is subject to less stringent requirements than
external documentation, and therefore can be produced quicker and cheaper.
External documentation must be produced to the highest standard time and money
will allow in order to enhance the product, and also to reflect a credible company
image.
Note that there are various levels of user who all have different documentation
requirements. It may be necessary to either use conditional text (if available), or
maintain different documentation sets for each user group:
• Novice Users: No assumptions about existing knowledge or experience can
(or should) be made. If necessary, documentation will have to start from
absolute basics in a step-by-step manner in order to build up knowledge
about a product in a simple, easy to assimilate manner. This group of users
prefer task-oriented documentation with meaningful examples, e.g., Getting
Started, Tutorials, on-line Help, etc.
• Advanced Users: Some assumptions about background knowledge can be
made (if necessary), or quick summaries and related document lists can be
used instead. These users do not like detailed descriptions of relatively sim-
ple tasks, they prefer task-specific on-line Help or reference documents
(with good Indices and Table of Contents).
• Specialist Users: System Managers, Operators, etc. These users have very
specific tasks to perform, and the documentation for them should reflect
this.
If possible, the consultant should try to get some idea of the user requirements. For
internal documentation, it may be possible to interview current or potential users,
see what sort of things they want and need. For external documents, this will be a
more difficult task (feedback forms are rarely, if ever, completed). However, it
should be brought to the attention of the project staff and management, as it is of
paramount importance to the documentation staff when creating the documenta-
tion.
All documentation must be written with the appropriate users in mind, otherwise it
is useless. N.B.: This aspect of documentation cannot be over-emphasized. Entire
books have been written on this subject; reference the ISTC documentation, for
example.

Documentation Tools
1.11 Documentation Tools
This section defines the tools to be used to create the documentation. Obviously
this may be related to the hardware and operating system being used in the devel-
opment environment.
• Word Processors: DECwrite (VAX/VMS), MS Word, WordPerfect, etc.
(PC/Mac), etc. Note that these tools are adequate for simple documents with
few graphics or chapters, but not for large, complex documentation or spe-
cialist tasks. These tools often do not usually use styles properly, and so
may be inconsistent and hard to map to other output formats.
• Desktop Publishing (DTP): FrameMaker, Interleaf, etc.; N.B.: may
involve specialist markup languages such as SGML. These tools are com-
plex and require professional knowledge, but are capable of very high qual-
ity results for large, complex documentation tasks. These tools are style-
based, and thus can often be mapped to other formats, such as HTML.
• Web Publishing: Front Page ‘98, Adobe Acrobat (for PDF files), document
mapping/conversion tools (e.g., HTML Transit for Word, WebWorks Pub-
lisher for FrameMaker, etc.)
• On-Line Help: MS HTML Help Workshop, Robohelp, Doc-2-Help, etc.;
mostly associated with MS Word documents on a PC, or HTML files.
• Graphics: Corel Draw, Photoshop, Visio, PowerPoint, etc.; note that docu-
mentation staff can often create simple graphics, but [external] specialists
may be required for more complex diagrams.
Note that specialist documentation tools can be expensive, but that only one-two
licences are usually required.
1.12 Graphics
This section describes the special considerations for graphics. As mentioned
above, simple graphics can be created within word processing or DTP software,
although this can sometimes make updating the graphics more complex if the
source files are moved to other staff in other locations. Screen captures should be
saved with the documents in a standard format (GIF, BMP, etc.).
Complex graphics can be created using special software, such as Visio Pro, Corel
Draw or Adobe Photoshop, and saved with the documentation in a standard format
(JPG, TIF, etc.). Note that the use of complex graphic applications requires profes-
sional skills, as well as knowledge of layout and design. It may sometimes be nec-
essary to use contract or other external specialist staff to create the best quality
images. This can be cost-effective, as high quality images can also be used in
advertising, and reflect well on the image of the company and the product.

Printing
1.13 Printing
This section describes any special considerations for printing. In-house double-
sided printing on black & white laser-printers will be sufficient for small print
runs. Large print runs of small documents, or any sort of print run for large docu-
ments should be given to a professional printing company. Once the company has
been defined (based on cost, speed, and quality considerations), then the format
(PS, PDF, etc.) and distribution method (Zip drive, CD-ROM, Email, etc.) can be
determined.
Note that advertising and promotional material which uses colour will require
some special (and potentially costly) printing considerations. Such documents
should be properly designed, carefully written and checked, and printed on high
quality paper. This sort of material is cost-effective as it reflects a good company/
product image.
1.14 Documentation Staff
This section describes the staff who will carry out the documentation tasks:
• Existing internal staff; note that developers are not usually the best people
to document their own products!
• New Internal Staff; i.e., hire a full-time documentation/graphics/web per-
son. Note that some training time will be required.
• External Contractor: if the project is relatively short-term, then an agency
can be used to locate a documentation contractor to work on-site.
• Specialist Third-Party Company: There are many specialist documentation
companies which offer a full range of services, sometimes including trans-
lation facilities. Note that this will be costly, has potential security/confi-
dentiality/timescale considerations, and will relinquish some control over
the documentation.
• Other Specialists: e.g., for graphics, web site/page creation, etc.
Even Technical Writers make occasional mistakes. Review your own work, pref-
erably after a break of a few days, and (if possible) have an Editor review it too.
Obviously, the development staff will need to review documentation for technical
accuracy, and this time should be planned in the project’s lifecycle. (Note that spe-
cial software is available to allow multiple users to mark-up and review documen-
tation.)

Document Standards
1.15 Document Standards
This section describes the applicable the documentation standards.
Some companies have in-house documentation guidelines; if not, relevant interna-
tional standards should be applied (BSI, IEEE, ISO9000, etc.). Standards also
extend to the use of style files and templates, which allow a high level of consis-
tency across a product range, or for an entire company.
Note that reflecting a good company image is important for a documentation set,
as first impressions of a product or company often come from this material. The
company logo should be featured prominently on all documentation. For further
considerations on style files templates and standards, refer to the Generic Docu-
mentation Guidelines and example style files and templates.
1.16 Document Distribution
This section describes how the documentation will be distributed:
Hardcopy: printed documents delivered with the product. This is the traditional
method, which is often combined with one or more on-line delivery formats. Note
that some high profile products will require special printing and binders for the
documentation.
On-Line: source files (not recommended), printable versions of documents (e.g.,
PDF or PS files). Note that it is a cost consideration whether or not you require the
users to print their own documentation, but it does help to be able to browse/search
the documentation on-line. On-line files can be delivered either with the product
(on CD-ROM) or via the Internet (this has the advantage that updates can be deliv-
ered quickly and easily).
Note that on-line files are often different to the hardcopy documents. On-line doc-
uments should be concise, and more topic- or problem-oriented. This can be done
either by the use of conditional text (if support by the creation tools), or by the
maintenance of separate information (this is more time-consuming, but will ulti-
mately result in better quality documentation for the users).
Note that a CD-ROM burner can be used for initial tests, but an external company
should be used to produce the distribution CDs with the proper product informa-
tion, logos, cases, etc.
Help Format: Documentation can be delivered as on-line Help files, either stand-
alone or integrated with the product (via an API), e.g., MicroSoft’s new HTML
Help format. Note that these files may differ from the on-line Help provided for
the product.
Web-based: HTML files created via conversion, style mapping, or independently.
Note that large documents need to be segmented, and that user navigation will be

Document Storage
required. It is often insufficient to merely convert or save documents in HTML
format. (N.B.: Some search engines can now even index Adobe PDF files.)
1.17 Document Storage
This section describes the considerations for the storage of documentation.
Source files should be kept on accessible (server) disks (as more than one person
may need to add information, and several groups will require access for reviewing
the information), in meaningful folder names, and should have meaningful file-
names themselves. Note that old versions of the documents should be retained,
and that the source files should always be regularly backed up. Graphics files
should be kept with the documentation so that they can be easily located, and so
internal references do not get broken if the documentation is moved.
The best method is to use some form of access control/versioning software, such
as Visual SourceSafe, ClearCase, or a similar product. This will ensure that the
same document is not simultaneously being updated by multiple authors. Note that
meaningful comments should be used when files are updated.
1.18 Product Lifecycle
This section describes the documentation considerations for the product lifecycle.
Documentation staff should be involved as early as possible in the project life-
cycle so that the documentation considerations are made known, and that advice
on documentation aspects can be given. The initial result of this is the Documenta-
tion Plan (a customized version of a document such as this), so that all groups are
aware of the documentation requirements.
Once the product is under development, early access to test software and project
specifications is required. Once initial versions are ready, the development team
will be required to review documentation. Before release, documentation staff
should be allowed to review the program texts (see above). Once products are
updated, additional time will be required to review the updates. Note that timely
information should always be provided to the documentation staff, who require a
high level of cooperation and liaison with the development team.

Document Maintenance
1.19 Document Maintenance
This section describes the considerations for updating and maintaining the docu-
mentation.
Once updates to the product are required, the documentation staff should be
informed as soon as possible, so that these updates can be planned, and that new
versions of the documents will be ready at the same time as the software. The
developers should allow time to review updates to the documentation, and a Tech-
nical Writer should review the program information (menus, dialog boxes, error
messages, etc.).
Changes to the documentation should be indicated in the text by the use of change
bars, and a document history should be maintained in the Preface. Old versions of
the documents should be maintained on the system, and if versioning software is
in available, meaningful comments should be used whenever the files are updated.
For example: New section on <xyz> added by <abc> on <date>.
If documents are distributed via the Internet, then a “What’s New?” page can be
maintained.
For the users, either the whole document can be reissued, or (if the changes are
only minor) just the updated pages (note that users often dislike having to add or
replace pages in a document). The use of web-based updates is of great advantage
here. Use an Email distribution list (if possible) to inform registered users of the
changes.
1.20 Security and Confidentiality
This section describes the considerations for security and the confidentiality of the
documentation.
It is often not a good idea to distribute the source files of product documentation,
as the users could modify and redistribute them. Consideration should also be
given to the confidentiality of the information contained in the documents. Is the
company giving away too many secrets or ideas to its competitors? In extreme
cases, a non-disclosure agreement may be required.

Copyright and Liability
1.21 Copyright and Liability
This section describes the considerations for copyright and product liability of the
documentation.
Consideration should be given to copyright issues if sections of other documents
or graphics are used in the product documentation. Management should also con-
sider taking out liability insurance for certain types of documentation, where mon-
etary or personal risks are involved, e.g., aircraft and automotive industries, etc.
Disclaimers should be checked by legal personnel. Note that liability legislation
will vary from country to country.
1.22 Internationalisation
This section describes the considerations for internationalisation of the documen-
tation.
What language will be used to write the documentation? Note that there are spell-
ing, grammatical, and cultural differences even between US and British English.
Will the documentation be required in other languages so that translation services
will be required? Note that this increases the time required and the maintenance
cost of the documentation, as multiple versions have to be updated.
Program texts also have to be translated, and guidelines should be given about the
length and position of the texts (if there are any limitations).
1.23 Timescales
This section describes the considerations for timescales of the documentation.
Time, as they say, is money, and quality takes time. Concise documents also take
longer to produce than verbose ones, because more time is required to plan and
review the documents. Documentation considerations should be involved as early
as possible in the project lifecycle. Technical Writers can also advise developers
on the human-interface aspects of products.
As always, it is very difficult to give accurate timescale estimates, as conditions
change over time, and writing documentation is a group activity with review
cycles, dependencies, etc.

Costs
1.24 Costs
This section describes the considerations for costs of the documentation.
As for timescales, it is always difficult to give accurate cost estimates for docu-
mentation, as this involves:
• cost of documentation personnel
• cost of software or special tools
• time required by developers for discussion, demonstrations, reviews, etc.
• special graphics costs (if any)
• printing and distribution costs, etc.

Costs

2 Document Descriptions
This chapter contains full descriptions of the documents to be created for the prod-
uct or project.
2.1 Document #1
Details to be added:
name, language, special considerations, timescales, requirements, dependencies,
etc. Use examples.

Document #1

3 Conclusions & Recommendations
This chapter contains the specific conclusions and recommendations for this prod-
uct or project.

Documentation Consultancy Appendix A-1
Appendix A Additional Information
This appendix contains any additional information that is referenced from the text.

Appendix A-2 Documentation Consultancy

Documentation Consultancy Bibliography-1
Appendix B Bibliography
This appendix lists the documents referenced in the text.
[1] Generic Documentation Guidelines, G. Turnbull, TUB, UBS-Zurich, CH,
Date?
[2] FrameMaker V5.x Style Files/Templates for a generic document, by G.
Turnbull, I7MK-TUB, VA314, x64814.
[3] MS Word Style File/Template for a generic document, G. Turnbull,
I7MK-TUB, VA314, x64814.
[4] ???

Bibliography-2 Documentation Consultancy

Documentation Consultancy Index-1
Index
A
Additional Information............................... A-1
Advanced Users.......................................... 1-6
Appendices.................................................1-4
B
Bibliography.................... 1-4, Bibliography-1
C
Conclusions................................................3-1
Confidentiality.......................................... 1-11
Copyright................................................. 1-12
Costs........................................................1-13
Cover Page.................................................1-4
D
Desktop Publishing ..................................... 1-7
Dialog boxes .............................................. 1-3
Distribution of Documents...........................1-9
Document
Contents................................................1-5
Distribution ........................................... 1-9
Maintenance........................................ 1-11
Standards .............................................. 1-9
Storage................................................ 1-10
Documentation
Staff......................................................1-8
Tools.....................................................1-7
Types.................................................... 1-2
E
Error Messages ........................................... 1-3
F
Front Material.............................................1-4
G
General Considerations................................ 1-1
Glossary of Terms.......................................1-4
Graphics.....................................................1-7
H
Hardware Systems ......................................1-1
Help screens ...............................................1-3
I
Index.......................................................... 1-4
Information Sources.................................... 1-5
Installation Guides ......................................1-2
Internationalisation....................................1-12
Introduction................................................1-1
L
Liability ...................................................1-12
Lifecycle Considerations ...........................1-10
List of
Equations .............................................. 1-4
Figures.................................................. 1-4
Tables ................................................... 1-4
M
Maintenance of Documents........................ 1-11
Marketing................................................... 1-2
Menus........................................................1-3
N
Novice Users .............................................. 1-6
O
On-Line
Documents ............................................1-3
Help...................................................... 1-7
Operating Systems ......................................1-1
Operator’s Guides .......................................1-2
P
Parts........................................................... 1-4
Personnel ................................................... 1-8
Preface....................................................... 1-4
Presentation Materials ................................. 1-2

Index
Index-2 Documentation Consultancy
Printing...................................................... 1-8
Product Lifecycle...................................... 1-10
Program Texts ............................................ 1-3
Project Overview........................................ 1-1
Promotional Materials................................. 1-2
Q
Quick-Reference Guides ............................. 1-2
R
Recommendations ...................................... 3-1
Release Notes............................................. 1-2
Reports ...................................................... 1-2
S
Security ....................................................1-11
Sources of Information................................ 1-5
Specialist Users .......................................... 1-6
Storage of Documents............................... 1-10
Structure of a Typical Document.................. 1-4
System Manager’s Guides ........................... 1-2
T
Table of Contents........................................ 1-4
Technical Reference Guides......................... 1-2
Timescales ............................................... 1-12
Tools.......................................................... 1-7
Training Materials ...............................1-2, 1-3
Tutorials..................................................... 1-2
Types of Documentation.............................. 1-2
U
Updating Documents..................................1-11
User
Considerations....................................... 1-6
Guides .................................................. 1-2
W
Web Publishing .......................................... 1-7
Word Processors ......................................... 1-7

Documentation Plan Example

More Related Content

What's hot (20)

Similar to Documentation Plan Example (20)

Documentation Plan Example