На главнуюНаписать письмоКарта сайта

Международные стандарты

Стандарты принятые боильшинством стран мира и предназначенные для разработки документов междунродного уровня (стандарт ИСО).

Забыли пароль?
Ещё не зарегистрированы? Регистрация

Наши партнеры

IEEE Std 1063-2001 IEEE Standard for Software User Documentation

1. Overview

This clause presents the scope, purpose, organization, and candidate uses of this standard.

1.1 Scope

This standard provides minimum requirements for the structure, information content, and format of user
documentation, including both printed and electronic documents used in the work environment by users of systems containing software. This standard is limited to the software documentation product and does not include the processes of developing or managing software user documentation; it applies to printed user manuals, online help, and user reference documentation. It does not apply to specialized course materials intended primarily for use in formal training programs.

This standard is intended neither to encourage nor discourage the use of either printed or electronic (online) media for documentation, or of any particular documentation development or management tools or methodologies.

Users of this standard may want to develop a style manual for use within their own organizations to
complement the guidance provided in the standard, or to adopt an industry-recognized style guide. Users of this standard may also want to perform usability testing on the software user documentation. The works listed in the bibliography provide guidance on the processes of managing, preparing, and testing user documentation
(see Annex A).

1.2 Purpose

This revision provides requirements for the structure, information content, and format of both printed and
electronic documentation. It addresses the interests of software acquirers, producers, and users in standards for consistent, complete, accurate, and usable documentation.

1.3 Organization of the standard

After Clause 2, this standard is organized according to the different aspects of user documentation: structure (Clause 3), information content (Clause 4), and format (Clause 5). In each clause, the requirements are media-independent, as far as possible. Requirements specific to either print or electronic media are identified as such, particularly in Clause 5. The order of clauses in this standard does not imply that the software user documentation should be developed in this order or presented to the user in this order.

1.4 Candidate uses

The wording of each clause in this standard assists those intending to claim conformance with the standard.

The term shall identifies mandatory requirements to claim conformance with this standard. The term should identifies an approach that is recommended, but not required, to claim conformance with this standard. The term may identifies an approach that is permitted within the limits of the standard, but not required to claim conformance with this standard.

This standard may be included or referenced in contracts or similar agreements when the parties (called the acquirer and the producer or supplier) agree that the supplier will deliver documentation in accordance with the standard. This standard may also be adopted as an in-house standard by a project or organization that decides to produce documentation in accordance with the standard. Although this standard is intended for software documentation for end users, it may be applied to documentation produced for computer operators or system administrators who are not end users.

This standard is meant to be tailored so that only necessary and cost-effective requirements are applied.

Tailoring may take the form of specifying approaches to comply with its mandatory requirements, or altering its non-mandatory recommendations and approaches to reflect the particular software and documentation product more explicitly. Tailoring decisions made by the acquirer should be specified in the contract.

2. Definitions

Throughout this standard, the term documentation refers to software user documentation. Use of the terminology in this standard is for ease of reference and is not mandatory for conformance with the standard. For the purposes of this standard, the following terms and definitions apply. IEEE 100, The Authoritative Dictionary of IEEE Standards Terms , Seventh

Edition [B9] 1 , should be referenced for terms not defined in this clause.

2.1 action:

Element of a step that a user performs to complete a procedure.

2.2 caution:

Advisory in software user documentation that performing some action may lead to consequences
that are unwanted or undefined, such as loss of data or an equipment problem. (See also:warning and note .)

2.3 critical information:

Information on the safe use of the software, the security of the information created with the software, or the privacy of the information created by or stored with the software.

2.4 document set:

A collection of documentation that has been segmented into separately identified volumes or products for ease of distribution or use.

2.5 illustration:

Graphic element set apart from the main body of text and normally cited within the main text. In this standard, the term illustration is used as the generic term for tables, figures, exhibits, screen captures, flow charts, diagrams, drawings, icons, and other graphic elements.

2.6 instructional mode:

Usage mode that is intended to teach the use of software in performing tasks.

2.7 note:

Helpful hint(s) and other information that may assist the user by emphasizing or supplementing important points of the main text. ( See also: warning and caution.)

2.8 procedure:

Ordered series of steps that a user follows to do one or more tasks.

2.9 reference mode:

Usage mode that is intended to provide quick access to specific information for software users who are generally familiar with the software functions.

2.10 software product:

One or more computer programs together with any accompanying ancillary nonelectronic, non-mechanical items such as documentation and worksheets, delivered under a single name for use by others.

2.11 software user documentation:

Electronic or printed body of material that provides information to users of software.

2.12 step:

One element of a procedure. A step contains one or more actions.

2.13 style:

Set of editorial conventions covering grammar, terminology, punctuation, capitalization, and layout of a software user document.

2.14 tutorial:

Instructional procedure in which the user exercises software functions using sample data supplied with the software or documentation.

2.15 usage mode:

Primary manner in which the document issuer expects the document to be used. This standard recognizes two usage modes: instructional and reference.

2.16 user:

Person who employs software to perform a task.

2.17 warning:

Advisory in software user documentation that performing some action may lead to serious or dangerous consequences. (See also: caution and note.)

3. Structure of software user documentation

The structure of software user documentation, both printed and electronic, includes how it is organized into segments and in what order the segments are presented. Documentation may be structured into a single document or a document set of printed and/or electronic documents. The structure of software user documentation should aid the user in locating and understanding the information content. When a document set will address audiences with widely differing needs, at least one of the following structures shall be used:

— Separate sections devoted to the needs of specific audiences. The audiences and their needs shall beidentified specifically in the introduction, allowing each user to identify the sections of interest.

— Separate documents or document sets for each specific audience.

Table 1 lists required and optional structural, content, and format components of the document. The components may be arranged in this order in printed documentation. The required components shall be included in software user documentation unless the information does not exist or is not applicable for a specific document. For example, a description of conventions may not be applicable in an overview document. The components may be renamed; for example, information suggested for the introduction could go in a section labeled “Preface.”

3.1 Overall structure of documentation

A document set may consist of one or more documents, and each document of a document set may be one or more volumes. For example, a printed command manual might have one volume covering one half of the commands and a second volume covering the other half of the commands.

Documents shall be structured into units with unique content. Well-structured documentation makes information available where it is needed without redundancy.

For purposes of this standard, the following non-mandatory nomenclature is used for the structural parts of software user documentation. A printed document is structured into logical units called chapters, subdivided into topics, which may be subdivided into subtopics, and printed on physical units called
pages. An electronic document is structured into logical units called topics and presented in physical units called pages or screens. Because of variations among physical display devices, the term screen as used here does not necessarily refer to the material displayed to the user at a single instant, but rather to the entire collection of material available by simple scrolling operations.

Each page or screen shall be uniquely labeled (for example, with a page or topic number, or screen name or number). When viewed or printed, each topic in an electronic document should be identifiable as belonging to the parent document. For example, a status bar or header shows the document or file name.

Printed documents shall be structured with no more than three levels of subdivision within a chapter. For example, a subtopic numbered would be at the lowest level of subdivision. Electronic documents shall be structured so that information can be accessed with no more than three jumps (links) from the initial page of a topic (not counting any action required to open the document).

Table 1—Components of software user documentation


See subclause


Identification data (package label/title page)



Table of contents


Yes, in documents of more than eight pages after
the identification data

List of illustrations






Information for use of the documentation



Concept of operations




4.6, 4.7

Yes (instructional mode)

Information on software commands


Yes (reference mode)

Error messages and problem resolution





Yes, if documentation contains unfamiliar terms

Related information sources



Navigational features





Yes, in documents of more than 40 pages

Search capability


Yes, in electronic documents

The documentation structure, length of a chapter or topic, and amount of information presented on a page or screen (physical unit) depend on several considerations:
— Access to the documentation while using the software
— Amount of information
— Audience familiarity with the information
— Limitations of the media
— Usage modes

The organization of documentation shall support its usage mode (instructional or reference). When a document contains both instructional and reference material, the two shall be clearly separated into different chapters or topics, or distinguished by formatting within the chapter or topic.

Task-oriented instructional mode documentation shall include procedures structured according to the user’s tasks. Related tasks should be grouped in the same chapter or topic. Chapters and topics should be organized to facilitate learning by presenting simpler, more common, or initial tasks before more complex, less utilized, or subsequent tasks.
Reference mode documentation should be arranged to facilitate random access to individual units of information.

For example, a list of software commands or error messages should be arranged alphabetically.

3.2 Initial components

Each individual document shall be structured to begin with identification data (see 4.3), followed by a table of contents (see 5.7.1) and an introduction; that is, the introduction is the first chapter or topic of the document.

The introduction shall describe the intended audience, scope, and purpose for the document and include a brief overview of the software purpose, functions, and operating environment.
Introductions shall be provided within a document for each chapter and topic. Introductory sections should be provided for each major feature or function of the software being documented. The introductory sections shall provide an overview of the topic, the purpose of the function, and any environmental requirements, warnings, cautions, or user requirements unique to the topic.

3.3 Placement of critical information

Critical information should be placed in a prominent location in the documentation. General warnings or cautions that apply throughout the use of the software or documentation shall appear in the initial components.

Specific warnings and cautions shall appear on the same page or screen and immediately before the procedure or step that requires care.

4. Information content of software user documentation

This clause specifies characteristics of information contained in user documentation (see 4.1 and 4.2), including completeness and accuracy. This clause also defines the required information for inclusion in user documentation (see 4.3 through 4.11). The information required in this clause shall be included in software user documentation unless the information does not exist or is not applicable for a specific document.

The content of documentation is related to its usage mode. Users of software need documents either to learn about the software (instructional mode) or to refresh their memory about it (reference mode). Instructional mode documents may be either information- or task-oriented. Information-oriented documents instruct the user on the concepts and technical information needed to use the software properly (see 4.5). Task-oriented documents show the user how to complete procedures to reach a goal (see 4.6). Reference mode documentation may be context-sensitive and integrated in the software, for example, pop-up or drop-down lists of acceptable data values or commands. In either instructional or reference documentation, the content of documentation can be improved by the inclusion of examples and illustrations.

4.1 Completeness of information

Documentation shall provide complete instructional and reference information for all critical software functions (software whose failure could have an impact on safety, or could cause large financial or social loss).

Instructional mode documentation shall include complete information to enable performance of selected
tasks using the software functions by the least experienced members of the audience. Reference mode documentation shall include all instances of the selected elements being documented.

For example, if reference mode documentation covers a subset of software commands, it shall include all user-entered and systemdisplayed commands and error messages in that subset.

4.2 Accuracy of information

Documentation shall accurately reflect the functions and results of the applicable software version. If the previous documentation version is no longer accurate, new documentation shall be available with software updates or upgrades. Documentation corrections and updates may be provided via a new manual, a read-me file or errata sheet, or a downloaded file from a web site.

4.3 Content of identification data

Documentation shall contain unique identification data. The identification data shall include the following:
a) Documentation title
b) Documentation version and date published
c) Software product and version
d) Issuing organization

Identification data shall appear on a package label, legible without opening the package, and on a title page.

A package label is not required if the title page is legible without opening the package. Each document in a document set shall have a unique title page. For single-page documents, such as quick reference cards, the identification data may appear on the same page as the rest of the document.

The title of the document should indicate its nature and scope and should not include abbreviations or acronyms unless they are familiar to the intended audience. If different versions of the software are available for different operating environments, the title page should specify the applicable operating environment(s), including version(s) of hardware, communications, and operating system(s). Other information, including document or software product part numbers, serial numbers, and restrictions on use, may be included on the package label and on the title page or following pages. The package label and pages immediately following the title page should include copyright and trademark notices, restrictions on copying or distributing the documentation, information for contacting the issuing organization (reader’s comments), warranties, contractual obligations or disclaimers, and general warnings and cautions.
The identification of the document and the software shall be consistent with the configuration management practices of the issuing organization or the acquiring organization. Information (change history) shall be provided in the document set to document the date of issue and version number of the current version and each previous version of the documentation.

4.4 Information for use of the documentation

The documentation shall include information on how it is to be used (for example, help on help), and an explanation of the notation (a description of formats and conventions—see 5.8). At least one document in a  document set shall identify all documents in the set by title and intended use, including recommendations on which members of the audience should consult which sections of the documentation. In document sets comprising many volumes or products, this information may be provided in a separate “road map” or guide to the document set.

Documentation may include identification and discussion of notable changes from the previous version of the document set and the software.

4.5 Concept of operations

Documentation shall explain the conceptual background for use of the software, using such methods as a visual or verbal overview of the process or workflow; or the theory, rationale, algorithms, or general concept of operation. Explanations of the concept of operation should be adapted to the expected familiarity of the users with any specialized terminology for user tasks and software functions. Documentation shall relate each documented function to the overall process or tasks. Conceptual information may be presented in one section or immediately preceding each applicable procedure.

4.6 Information for general use of the software

Task-oriented instructional mode documentation shall include instructions for routine activities that are applied to several functions:
— Software installation and de-installation, if performed by the user
— Orientation to use of the features of the graphical user interface (see 5.6)
— Access, or log-on and sign-off the software
— Navigation through the software to access and to exit from functions
— Data operations (enter, save, read, print, update, and delete)
— Methods of canceling, interrupting, and restarting operations

These common procedures should be presented once to avoid redundancy when they are used in more complex functions.

4.7 Information for procedures and tutorials

Instructional mode documentation provides directions for performing procedures. Instructions shall include preliminary information, instructional steps, and completion information.

Preliminary information common to several procedures may be grouped and presented once to avoid redundancy.

Preliminary information for instructions shall include the following:
— A brief overview of the purpose of the procedure and definitions or explanations of necessary concepts not elsewhere included
— Identification of technical or administrative activities that must be done before starting the task
— A list of materials the user will need to complete the task, which may include data, documents, passwords, additional software, and identification of drivers, interfaces, or protocols
— Relevant warnings, cautions, and notes that apply to the entire procedure

Relevant warnings, cautions, and notes shall immediately precede each applicable instructional step or group of steps. Instructional steps shall use the imperative mood for the user’s action.

Instructional steps shall indicate the expected result or system response. Instructional steps shall include or provide references to documentation of the acceptable range, maximum length and applicable format, and unit of measurement of data fields for user-supplied data. Acceptable data formats and values are commonly documented through pop-up lists. Instructional steps shall include or provide references to explanations of error messages and recovery procedures.

Instructional steps shall be presented in the order of performance. Alternative or repeated procedures should be clearly indicated, so the user can determine which alternate or repeated steps to perform or skip and where to rejoin the main procedure.

Completion information for instructions shall indicate which is the last step in the procedure, how the user can determine whether the procedure has successfully completed, and how the user should exit from the procedure.

4.8 Information on software commands

Documentation shall explain the formats and procedures for user-entered software commands, including required parameters, optional parameters, default options, order of commands, and syntax. Documentation may be provided on the development and maintenance of macros and scripts. Reference mode documentation shall contain a reference listing of all reserved words or commands. Examples should illustrate the use of commands. Documentation shall explain how to interrupt and undo operation during execution of a command and how to restart it, if possible. Documentation shall describe how to recognize that the command has successfully executed or abnormally terminated.

4.9 Information on error messages and problem resolution

Documentation should address all known problems in using the software in sufficient detail such that the users can either recover from the problems themselves or clearly report the problem to technical support personnel. Reference mode documentation shall include each error message with an identification of the problem, probable cause, and corrective actions that the user should take. A quick reference card may address error messages by referring the user to more detailed reference documentation. The documentation on resolving problems shall also include contact information for reporting problems with software or its documentation and suggesting improvements.

4.10 Information on terminology

Documentation shall include a glossary, if terms or their specific uses in the software user interface or documentation are likely to be unfamiliar to the audience. The glossary shall include an alphabetical list of terms and definitions. Documentation using abbreviations and acronyms unfamiliar to the audience shall include a list with definitions, which may be integrated with the glossary. Terms included in the glossary should also be defined on their first appearance in printed documentation. Electronic documentation may include links from terms to glossaries or explanations in secondary windows.

4.11 Information on related information sources

Documentation may contain information on accessing related information sources, such as a bibliography, list of references, or links to related web pages. Related information sources and references may include the following:
— Requirement specifications, design specifications, and applicable standards for the software and the documentation
— Test plans and procedures for the software and the documentation
— Configuration management policies and procedures for the software and the documentation
— Documentation for the hardware and software environment
— Explanations of the concept of operations or scientific, technical, or business processes embodied in the software.
The documentation should indicate whether the references contain mandatory requirements or informative background material.

5. Format of software user documentation

The documentation format includes the selected electronic or print media and presentation conventions for stylistic, typographic, and graphic elements. This clause specifies formats for various documentation components.

The format for reference mode documentation should be accessible and usable in the expected users’ work environment. The size of printed and bound reference documentation, or required equipment, electronic storage space, operating system software, and browsers to access online reference documentation, shall be consistent with the capacity of the expected users’ work environment.

The documentation should be provided in media and formats that allow its use by those with a vision, hearing, or other physical limitation, if they are able to use the software and to perform the tasks supported by the software. Alternative documentation media and formats for users with physical limitations may require special adaptive software and equipment not provided with the user software or the user software documentation.

5.1 Consistency of terminology and formats

Documentation shall use consistent terminology throughout a document set for elements of the user interface, data elements, field names, functions, pages, topics, and processes. Formatting conventions for highlighting information of special importance, such as warnings, cautions and notes, shall be applied consistently throughout the document set. The documentation may use special formatting to identify new or changed content. Formatting conventions may include colors, borders, indenting, spacing, and font variations.

Similar material, such as sets of instructions, shall be presented in a consistent format.

If documentation is adapted for use in another operating environment, language, or culture, a commonglossary and style guides for text and illustrations should be used to assist documentation developers and translators in maintaining consistency. Consideration should be given to selecting terminology, examples, graphics, and colors that are not culture-specific, so documentation can be more easily adapted, localized, or translated while preserving the intended meaning of the original.

5.2 Use of printed or electronic formats

Whether or not electronic documentation is provided, the following documentation shall be presented in printed form:
— Hardware, operating system, and browser software requirements for the software and the documentation
— Installation information, including recovery and troubleshooting information for installation instructions
— Instructions for starting the software
— Instructions for access to any electronic documentation
— Information for contacting technical support or performing recovery actions available to users

A description of how to print the electronic documentation should be included in both the electronic and the printed documentation. A means shall be provided for printing online documentation for those software systems designed for use when attached to a printer. The system should include software features designed to enable printing of electronic documentation.

Online documentation shall be available for display at any time when user input to the software is possible.

The user should be able to perform a function and read the relevant function-specific online documentation simultaneously. The user should be able to view the online documentation and navigate to related software functions during system operations.

5.3 Legibility

Printed and electronic documentation shall be legible to the user, considering the distance between the user and the documentation in the expected work environment. Documentation shall use a font style and color that is legible against the expected background (paper color or screen background color). Online documentation shall remain legible if the user is able to enlarge, shrink, or reshape the screen or window. Uppercase (all capital) letters shall not be used for continuous text of more than 25 words. Text, including text in illustrations, shall be no smaller than 3 mm (approximately 7.5 points).

Online documentation should be legible in the users’ expected work environment, which includes the anticipated combination of computer monitor or display and software graphics drivers.

Legibility may be affected by output devices (monitors and printers) that are monochrome, have limited resolution, render colors differently, or support a limited range of colors. Some output devices may apply substitute fonts or special characters if the specified font is not available. Distinctions that depend on more than two gradations of colors or shades of gray may not be visible. Because some users cannot distinguish between colors, documentation should provide text cues rather than using colors such as red and green as the only way to convey meaning.

5.4 Formats for warnings, cautions, and notes

Warnings, cautions, and notes shall be displayed in a consistent format that is readily distinguishable from ordinary text or instructional steps. The flag word (for example, warning, caution, or note ) shall precede the accompanying text. The term notes hall not be used to identify hazards. Warnings and cautions shall be identified by consistent and distinct graphics symbols, for example, an exclamation point or lightning bolt inside a triangle. A warning or caution shall include the following parts:
— Flag word
— Graphic symbol
— Brief description of the hazard
— Instructional text on avoiding the hazard
— Consequences of incurring the hazard
— User’s remedies for the adverse consequences, if any

5.5 Format for instructions

Instructional steps shall be consecutively numbered. A consistent numbering or lettering convention should be established for substeps or actions, alternative steps, and repeated procedures.

5.6 Formats for representing user interface elements

Graphical user interface (GUI) elements of the software, such as buttons, icons, variable cursors and pointers; special uses of keyboard keys or combinations of keys; and system responses shall be represented in documentation by consistent graphic or typographical formats so that the various elements are each distinguished from the text. Documentation should include a representation of the element, its purpose, and an explanation of its action (functional consequence), with examples of actual operational instances. Online documentation may include pop-up text labels for GUI elements.

Documentation formats for user-entered commands or codes shall clearly distinguish between literals (to be input exactly as shown) and variables (to be selected by the user). Quotation marks should not be used in command representations unless the user should input them literally. Documentation should address variations in keyboards or data entry devices in the expected users’ work environment.

5.7 Formats for documentation features for accessing information

Documentation shall contain features to provide access to information, including a table of contents; a list of figures, tables, or illustrations; an index; and electronic search capabilities.

5.7.1 Table of contents

A table of contents shall immediately follow the identification data (see 4.3). The table of contents shall list the headings of the chapters or topics of a document with an access point for each (its initial page number or an electronic link). Documents with fewer than eight pages after the identification data may omit the table of contents.

The table of contents may be comprehensive or simple. A comprehensive table of contents lists all chapter or topic titles (headings) down to the third level. A simple table of contents includes only the first-level headings. Documents with a simple table of contents may include secondary comprehensive tables of contents appearing at the beginning of each chapter or topic, or accessible through pop-ups, expandable lists, or secondary windows. Electronic documentation may display tables of contents in expandable and collapsible formats to provide top-level and detailed access to headings without excessive scrolling. At least one volume of a document set shall include a simple table of contents for all volumes in the set.

The table of contents shall include all portions of the documentation, including front matter that follows the table of contents and back matter (for example, appendixes, glossary, and index). The headings in the table of contents shall be identical in wording to those in the document, including chapter or topic numbers. The format of the table of contents shall distinguish the hierarchy of headings by consistent typography or indentation.

In printed documentation, the table of contents shall list the headings in the same order as in the text.

For electronic documentation, the table of contents should order the headings according to browse sequence, task, topic type, or other logical criteria.

5.7.2 List of illustrations

Documentation should contain a list of tables, a list of figures, or a list of illustrations (including both tables and figures) if the document contains more than five numbered illustrations and the illustrations are not visible at the same time as text references to them. The list of illustrations shall list the illustration numbers and titles with an access point for each (such as its initial page number or an electronic link). The titles in the list of tables, figures, or illustrations shall be identical in wording to those in the document, including table, figure, or illustration numbers.

5.7.3 Index

An index is an alphabetical listing of keywords, graphics, or concepts with an access point for each. Printed documents more than 40 pages shall include an index, whose access points may be page numbers, topic numbers, illustration numbers, or references to another index entry. Electronic documents more than 40 topics shall include either a search tool (see 5.7.4) or an index whose access points are electronic links. Annex B provides guidance for indexing user documentation. An index entry may cross-reference another index entry; however, the referenced entry shall give an access point to the documentation and shall not point to a third index entry.

5.7.4 Search capability

Electronic documentation shall provide a method of locating words in the text. Electronic search capabilities may include full text search of the document or document set; search for words in illustrations; keyword search; finding a text string in the current topic; a Boolean search; and the restriction of a search to specific chapters, topics, or pages.

5.8 Formats for features for navigation

Features for navigation include chapter and topic headings; page or screen titles; chapter, title, page, and screen numbers; tabs; page headers and footers; bookmarks; jumps (links); cross references; navigational icons; and buttons. Features for navigation shall be provided such that users can determine their location within the printed or electronic document and all of the locations to which they can move from their current location. Documentation shall include explanations of system- and document-specific navigational features.
In printed documentation, each page shall have a unique page number. In electronic documentation, each page or screen shall have a unique identifier (alphanumeric and/or caption) accessible to the user. Navigation features shall allow documentation users to go to the following locations:
Back , to return to the section/page most recently jumped from (linked)
Next, next logical topic/page in the sequence of topics (if any)
Previous, logical topic/page just prior to the one being viewed (if any)
Table of contents (if any)
Index (if any)

Navigation features shall use consistent formats for typography such as underscored links, color, or graphics to distinguish them from plain text. Navigation features should remain accessible in a static location if electronic documentation allows scrolling through the text.

Jumps (links) shall provide a clear indication of the destination of the link. For example, use “More troubleshooting tips” rather than “Click here.” Links should provide information that the user expects in one jump, rather than requiring a link to another link that has the sought information. If the destination is outside the documentation, the documentation should provide users with an alternate way of locating the information, in case the link has been broken or the destination removed. Links between related topics shall be bidirectional, so that whichever topic the users access first, they can jump to the related information on the other topic.

Electronic reference mode documentation shall be accessible from the software it documents, and shall provide a clear means of exiting the documentation and returning to the software.

Software may be linked to online help, tutorials, or reference mode documentation in various ways, such as the following:
— Through a help menu linked to a listing of topics or a point of entry to the help system
— Through help buttons on the software screens providing information on a particular topic (dialog box and field level help)
— Through context-sensitive help and pop-up text (tool tips)

5.9 Formats for illustrations

Illustrations that accompany text should appear adjacent to their first reference in the text, so the associated text and illustration can be viewed simultaneously. In documentation with more than five illustrations, each illustration should have a unique number and title (see 5.7.2). Informal illustrations, referred to only once in the text or having no text, may be untitled and unnumbered.

The format of illustrations of similar content shall be consistent for scale, screen size, fonts, line thickness, and use of color. In electronic documentation, illustrations should be sized so they are legible and viewable in their entirety, without scrolling, on the expected viewing device. Consider simplifying or showing only salient features of a large graphic so it is visible at one time without scrolling. Long tables that cannot fit on a single page shall repeat the table title and column or row headings on each page or two-page spread. Long tables that span multiple pages should also be identified with a sheet number, for example, “Table 15. Metric units (sheet 2 of 4).”

Documentation that is intended for both print and electronic distribution should be logically complete, including illustrations and references to illustrations, in both media. Fewer illustrations may be needed in electronic documentation that allows links to the actual software screens. Representations of GUI elements in documentation should be consistent with the version of the software being documented.

Annex A (informative)


[B1] Brockmann, R. J., Writing Better Computer Documentation: From Paper to Hypertext, John Wiley &
Sons, New York, 1990.
[B2] British Standard BS7649:1993, Guide to the design and preparation of documentation for users of
application software.
[B3] British Standard BS7830:1996, Guide to the design and preparation of on-screen documentation for
users of application software.
[B4] Dumas, J. S., and Redish, J. C., A Practical Guide to Usability Testing, rev. ed., Intellect, 1999.
[B5] Hackos, J. T., Managing Your Documentation Projects, John Wiley & Sons, New York, 1990.
[B6] Hackos, J. T., and Stevens, D. M., Standards for Online Communication: Publishing Information for
the Internet/World Wide Web/Help Systems/Corporate Internets, John Wiley & Sons, New York, 1997.
[B7] Hackos, J. T., and Redish, J. C., User and Task Analysis for Interface Design, John Wiley & Sons, New
York, 1998.
[B8] Horton, W., Designing and Writing Online Documentation: Hypermedia for Self-supporting Products,
2nd ed., John Wiley & Sons, New York, 1994.
[B9] IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition.
[B10] IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
[B11] IEEE Std 1465-1998, IEEE Standard Adoption of ISO/IEC 12119:1994 (E) International Standard—
Information Technology—Software Packages—Quality Requirements and Testing.
[B12] IEEE/EIA 12207.1-1997, Guide—Industry Implementation of International Standard ISO/IEC 12207:
1995 (ISO/IEC 12207) Standard for Information Technology—Software life cycle processes—Life cycle
[B13] ISO/IEC 15910:1999, Information technology—Software user documentation process.
[B14] ISO/IEC TR 9294:1990, Information Technology—Guidelines for the Management of Software
[B15] Nagle, J. G., Handbook for Preparing Engineering Documents: From Concept to Completion, IEEE
Press, New York, 1996.
[B16] Price, J., and Korman, H., How to Communicate Technical Information: A Handbook of Software and
Hardware Documentation, Benjamin/Cummings, Redwood City, CA, 1993.
[B17] Schriver, K. A., Dynamics in Document Design: Creating Texts for Users, John Wiley & Sons, New
York, 1994.

Annex B (informative)

Indexing software user documentation

An index is an important information retrieval device and should be constructed in a way that makes it easy for users to locate the information they seek. This annex provides guidance on good practices for indexing software user documentation.

Use words that users are likely to look up and list all the topics in the document. Thoroughly indexed software user documentation can have two to five entries per topic. Index the preface, the appendixes, warnings, cautions, and notes. In electronic documents, index non-textual items such as graphics and multimedia.

Avoid overly general keywords and use descriptive terms for entries, placing the main word first. For example, for the text heading, “Using file manager,” use the index heading, “file manager, using.” Double-post entries. For example, the topic that appears as “saving files” and “files, saving” is double-posted. Use synonyms
to provide alternate terms for access.

Indicate the importance of information by placing minor key words under major ones. Break up entries that have multiple references in the document into sub-entries that indicate which aspect of the topic is covered.

Use detailed primary entries rather than secondary or tertiary entries. Optionally, identify major page references by marking the page number in bold.

Optionally, for document sets, include a global index in addition to the indexes in the individual volumes.

The global index provides users with the means of looking for information in a single index, instead of looking it up in the indexes of the individual documents. Give location references for each entry that include an abbreviation of the document title in addition to the page numbers.


abbreviations, 4.10
accessing information, 5.7
accuracy, 4.2
acronyms, 4.10
action, 2.1, 4.7
audience, Clause 3

back matter, 5.7.1
bibliography, Annex A
bookmark, 5.8

capital letters, 5.3
caution, 2.2, 3.3, 4.7, 5.4, Annex B
chapter, 3.1
color, 5.3
command, software, 4.8, 5.6
completeness of information, 4.1
concept of operations, Clause 3, 4.5
consistency, 5.1
content of documentation, Clause 4
copyright notice, 4.3
critical function, 4.1
critical information, 2.3, 3.3
cross reference, 5.8

definitions, Clause 2
document components, Clause 3
document set, 2.4, Clause 3, 4.4, Annex B

environment. See work environment, users’. See operating environment.
errata sheet, 4.2
error message, Clause 3, 4.9
exhibit. See illustration.

figure. See illustration.
flag word, 5.4
font, 5.3
footer, 5.8
format, 5.8
front matter, 5.7.1
function, critical, 4.1

glossary, Clause 3, 4.10
graphical user interface (GUI), 5.6, 5.9
gray, 5.3
green, 5.3

hazard, 5.4
header, 5.8
heading, 5.8
help, 4.4, 5.8

icon, 5.6, 5.8
identification data, Clause 3, 3.2, 4.3
illustration, 2.5, 5.9
illustrations, list of, 5.7.2
index, Clause 3, 5.7, 5.7.3, Annex B
information content, Clause 4
information for use of the documentation, 4.4
information for use of the software, 4.6
initial components, 3.2
instructional mode, 2.6, 3.1, 4.7
instructions, 4.7
introduction, Clause 3, 3.2

jump, 3.1, 5.8

keyboard, 5.6
keyword, Annex B

label, package, 4.3
legibility, 5.3
levels of subdivision, 3.1
link, 3.1, 5.8
list of illustrations, Clause 3, 5.7.2
literals, 5.6

mode, usage, 2.15, Clause 4

navigation, Clause 3, 4.6, 5.8
note, 2.7, 5.1, 5.4
notices, copyright and trademark, 4.3

online format, Clause 5
operating environment, 4.3
organization. See structure.

package label, 4.3
page, 3.1
page number, 5.8
preface, Clause 3
print, 5.2
problem resolution, 4.9
procedure, 2.8, Clause 3, 3.1, 4.7
purpose, 1.2

red, 5.3
reference mode, 2.9, 3.1, Clause 4, 4.1, 4.8, 4.9, Clause 5, 5.8
related information sources, Clause 3, 4.11
restrictions, 4.3

scope, 1.1
screen, 3.1
search capability, Clause 3, 5.7.4
size of documentation, Clause 5
software commands, Clause 3, 3.1, 4.8
software user documentation, 2.11
step, 2.12
steps, instructional, 4.7, 5.4, 5.5
steps, numbered, 5.5
structure, Clause 3
style, 2.13
subdivision, levels of, 3.1

tab, 5.8
table. See illustration.
table of contents, Clause 3, 3.2, 5.7.1
tailoring, 1.4
task-oriented. See instructional mode.
technical support, 5.2
terminology, 5.1
theory of operations. See concept of operations.
title, 5.7.1, 5.7.2, 5.8
title page, Clause 3, 4.3
title, illustration, 5.9
topic, 3.1, 3.2
trademark notice, 4.3
tutorial, 2.14, 4.7

updates, 4.2
usage mode, 2.15, Clause 4
use of standard, Clause 1
user, 2.16
user interface element, 5.6

variables, 5.6

warning, 2.17, 3.2, 3.3, 4.3, 4.7, 5.1, 5.4, Annex B
work environment, users’, Clause 5, 5.6

© 2009. IT-GOST.RU – оформление проектной документации (ГОСТ 34, 19, СТ РК, ИСО). Все права защищены.
Дизайн и разработка сайта Kasimoff.ru