ISO/IEC 26513:2009

INTERNATIONAL ISO/IEC
STANDARD 26513
First edition
2009-10-15
Systems and software engineering —
Requirements for testers and reviewers
of user documentation
Ingénierie des systèmes et du logiciel — Exigences pour testeurs et
vérificateurs de documentation utilisateur

Reference number
©
ISO/IEC 2009
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2009 – All rights reserved

Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Conformance .2
2.1 Definition of conformance.2
2.2 Conformance situations .3
3 Terms and definitions .3
4 User documentation process within the systems/software life cycle .8
5 Documentation evaluation process requirements, objectives, and constraints.9
5.1 General .9
5.2 Documentation evaluation activities .10
5.3 Selection of an evaluation method .10
5.4 Documentation review .10
5.5 Documentation test .11
5.6 Project requirements affecting documentation evaluation.11
5.7 Resource requirements and planning.12
5.7.1 Impact of evaluation on project schedules.13
6 Documentation evaluation methods and procedures .13
6.1 Documentation review .14
6.1.1 Planning documentation review .14
6.1.2 Documentation review procedures .16
6.1.3 Managing the results of documentation review.17
6.1.4 Problem resolution and the documentation review cycle.17
6.2 System test of documentation .17
6.2.1 Planning system test of documentation .18
6.2.2 Performing and assessing results of system test of documentation.22
6.2.3 Problem resolution and the system test of documentation life cycle .22
6.3 Usability testing of documentation .22
6.3.1 Objectives for usability testing of documentation.23
6.3.2 Measures and metrics for documentation usability testing .23
6.3.3 Planning usability tests .24
6.3.4 Performing usability test of documentation.26
6.3.5 Problem resolution for documentation usability tests.27
6.4 Accessibility testing of documentation .27
6.4.1 Planning accessibility tests.27
6.4.2 Performing accessibility tests .28
6.5 Localization and customization testing .28
6.5.1 Planning for localization and customization testing .28
6.5.2 Performing localization and customization testing .28
6.6 Problem resolution process.29
Annex A (informative) Checklists for user documentation .30
Annex B (informative) Test and review checklist .37
Bibliography.53

© ISO/IEC 2009 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 26513 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.

iv © ISO/IEC 2009 – All rights reserved

Introduction
Anyone who uses application software needs accurate information about how the software will help the users
accomplish a task. The documentation might be the first tangible item that the users see, and so influences
the first impressions the users have of the product. If the information is supplied in a convenient form and is
easy to find and understand, the users can quickly become proficient at using the product. Therefore, well-
designed documentation not only assists the users and helps to reduce the cost of training and support, but
also enhances the reputation of the product, its producer, and its suppliers.
This International Standard addresses the evaluation and testing of user documentation. It applies to both
initial development and subsequent releases of the software and user documentation.
This International Standard is independent of the software tools that might be used to produce documentation,
and applies to both printed documentation and on-screen documentation. Much of its guidance is applicable to
user documentation for systems including hardware as well as to software user documentation.
This International Standard conforms with ISO/IEC 26514:2008 Systems and software engineering —
Requirements for designers and developers of user documentation, ISO/IEC 15288:2008, Systems and
software engineering — System life cycle processes, and ISO/IEC 12207:2008, Systems and software
engineering — Software life cycle processes. This International Standard was developed to assist those who
test and review software user documentation as part of the software life cycle process. This International
Standard defines the Documentation Management and Validation processes of ISO/IEC 12207:2008 from the
tester's standpoint. This International Standard may be used as a conformance or a guidance document for
products, projects and organizations claiming conformance to ISO/IEC 15288:2008 or ISO/IEC 12207:2008.

© ISO/IEC 2009 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 26513:2009(E)

Systems and software engineering — Requirements for testers
and reviewers of user documentation
1 Scope
This International Standard supports the interest of software users in receiving consistent, complete, accurate,
and usable documentation. This International Standard defines the process in which user documentation
products are tested.
This International Standard is intended neither to encourage nor discourage the use of either printed or
electronic (on-screen) media for documentation, or of any particular documentation testing or management
tools or methodologies.
This International Standard specifies processes for use in testing and reviewing of user documentation
(Clause 5). It is not limited to the test and review phase of the life cycle, but includes activities throughout the
Information Management and Documentation Management processes.
This International Standard provides the minimum requirements for the testing and reviewing of user
documentation (Clause 6), including both printed and on-screen documents used in the work environment by
the users of systems software. It applies to printed user manuals, online help, tutorials, and user reference
documentation.
The order of clauses in this International Standard does not imply that the software user documentation
should be tested in this order.
In each clause, the requirements are media-independent, as far as possible. The informative checklists found
in Annexes A and B may be used at each phase of the documentation process to verify that the appropriate
steps have been carried out, and that the finished product has acceptable quality.
This International Standard can be helpful for testing and reviewing the following types of documentation:
• documentation of products other than software, for example, hardware or devices;
• multimedia systems using animation, video, and sound;
• computer-based training (CBT) packages and specialized course materials intended primarily for use
in formal training programs;
• documentation produced for installers, computer operators, or system administrators who are not end
users;
• maintenance documentation describing the internal operation of systems software.
This International Standard is applicable to testers, reviewers, and other related roles, including a variety of
specialists:
• usability testers, documentation reviewers, and subject-matter experts;
• information designers and architects who plan the structure and format of products in a documentation
set;
© ISO/IEC 2009 – All rights reserved 1

• usability specialists and business analysts who identify the tasks the intended users will perform with
the software.
The International Standard can also be consulted by those with other roles and interests in the documentation
process.
Managers of the software development process or the documentation process should consider the testing of
documentation as part of their planning and management activities. Project managers, in particular, have an
important role in planning the testing and reviewing of documentation.
Testing of the documentation is likely to highlight any defects or nonconformances in tools that are used to
create or display on-screen documentation. Similarly, usability testing of the documentation is likely to
highlight defects or nonconformances with the presentation or layout of documentation and associated
graphics and other media. As a result, there are a number of roles that should be involved in the testing of
documentation because their work affects the content, display or presentation of documentation for the user,
for example, developers of tools for creating on-screen documentation, graphic designers producing material
displayed as part of the documentation, and human-factors experts who identify principles for making
documentation more accessible and easily used, also user interface designers and ergonomics experts
working together to design the presentation of the documentation on-screen. In some organizations these
roles may have different titles, or an individual may perform more than one of these roles.
There are other roles that need to understand the test processes for the documentation, for example authors
should understand the test processed for the documentation that they have produced and acquirers of
documentation prepared by another department or organization might want to know what testing has been
performed and the processes followed for the documentation that they are acquiring from a supplier.
This International Standard is intended for use in all types of organizations, whether or not a dedicated
documentation department is present. In all cases, it may be used as a basis for local standards and
procedures. Readers are assumed to have experience or general knowledge of testing or reviewing
processes.
This International Standard deals with the evaluation of documentation only, and not with the evaluation of the
software it supports. Documentation is also included in evaluation of the software product, as in the
ISO/IEC 25000 series of standards. In particular, ISO/IEC 25051:2006 Software engineering — Software
product Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Commercial-Off-The-
Shelf (COTS) software product and instructions for testing.
The works listed in the Bibliography provide additional guidance on the processes of managing, preparing,
and testing user documentation.
2 Conformance
This International Standard may be used as a conformance or a guidance document for projects and
organizations claiming conformance to ISO/IEC 15288:2008, Systems and software engineering — System
life cycle processes, ISO/IEC 12207:2008, Systems and software engineering — Software life cycle
processes or both.
2.1 Definition of conformance
When the selected software life cycle processes are tailored, the organization or project may claim
conformance to this International Standard for its documentation process.
Throughout this International Standard, "shall" is used to express a provision that is binding, "should" to
express a recommendation among other possibilities, and "may" to indicate a course of action permissible
within the limits of this International Standard. When using this International Standard as a guide, replace the
term “shall” with “should”.
2 © ISO/IEC 2009 – All rights reserved

This International 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 should be specified in the contract.
NOTE: ISO/IEC 12207:2008 Annex A defines the tailoring process.
Use of the nomenclature of this International Standard for the parts of user documentation (that is, chapters,
topics, pages, screens, windows, etc.) is not required to claim conformance.
2.2 Conformance situations
Conformance may be interpreted differently for various situations. The relevant situation shall be identified in
the claim of conformance:
a) When conformance is claimed for an organization, the organization shall make public a document
declaring its tailoring of the life cycle process;
NOTE 1: One possible way for an organization to deal with clauses that cite "the documentation plan" or the "test
plan" is to specify that they shall be interpreted in the project plans for any particular documentation project.
b) When conformance is claimed for a project, the project plans or the contract shall document the tailoring
of the documentation requirements;
NOTE 2: A project’s claim of conformance is typically specified with respect to the organization’s claim of
conformance.
c) When conformance is claimed for a multi-supplier program, it may be the case that no individual project
may claim conformance because no single contract calls for all the required activities. Nevertheless, the
program, as a whole, may claim conformance if each of the required activities are produced by an
identified party. The program plans shall document the tailoring of the required tasks, and their
assignment to the various parties, as well as the interpretation of any clauses of the standard that
reference "the contract".
This International 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 shall deliver user documentation
testing or reviewing and editing services in accordance with the standard. This International Standard may
also be adopted as an in-house standard by a project or organization that decides to test or assess
documentation in accordance with it.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
NOTE: Throughout this International Standard, the term documentation refers to software user documentation. Use of
the terminology in this International Standard is for ease of reference and is not mandatory for conformance.
ISO/IEC 24765, Software and Systems Engineering Vocabulary may be referenced for terms not defined in this clause.
This source is available at the following Web site: http://www.computer.org/sevocab.
3.1
accessibility
usability of a product, service, environment or facility by people with the widest range of capabilities
NOTE: Although "accessibility" typically addresses users who have disabilities, the concept is not limited to disability
issues.
© ISO/IEC 2009 – All rights reserved 3

3.2
audience
category of users sharing the same or similar characteristics, and needs (for example, purpose in using the
documentation, tasks, education level, abilities, training, experience) that determine the content, structure, and
use of the intended documentation
NOTE: There might be a number of different audiences for a software product’s documentation (for example,
management, data entry, maintenance).
3.3
author
person designing or developing user documentation
3.4
caution
advisory in software user documentation that performing some action might lead to consequences that are
unwanted or undefined, such as loss of data or an equipment problem
NOTE: See also warning and note.
3.5
context-sensitive help
information displayed relevant to the user’s current context, e.g. location, sequence of user’s action and
operation, in the application
3.6
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
3.7
customization
process of adapting a product to the needs of a particular user or group of users
3.8
design
phase of development concerned with determining what documentation shall be provided in a product and
what the nature of the documentation shall be
3.9
development
activity of preparing documentation after it has been designed
3.10
display
information presented on a screen or in a window of a screen
3.11
document
an item of documentation
3.12
documentation
information that explains how to use a software product
3.13
document set
collection of documentation that has been segmented into separately identified volumes or products for ease
of distribution or use
4 © ISO/IEC 2009 – All rights reserved

3.14
effectiveness
relation of the goals of using the product to the accuracy and completeness with which these goals might be
achieved
NOTE: Common measures include percentage of task completion, frequency of defects, frequency of assists,
frequency of accesses to help or documentation.
3.15
efficiency
relation of the level of effectiveness achieved to the quantity of resources expended
NOTE: Time-on-task is the main measure of efficiency. Also Completion Rate/Mean Time-On-Task (defect rates vs
time to achieve task).
3.16
embedded documentation
information that is delivered as an integral part of a piece of software
EXAMPLE: On-screen help provided with the software.
3.17
evaluation
systematic determination of the extent to which an entity meets its specified criteria
3.18
function
part of an application that provides facilities for users to carry out their tasks
3.19
illustration
graphic element set apart from the main body of text and normally cited within the main text
NOTE: In this International 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.
3.20
internationalization
process of developing information so that it is suitable for an international audience and may be localized
3.21
link
navigation method that takes the user from one item of on-screen documentation to another item
3.22
localization
creation of a national or specific regional version of a product
NOTE: Localization may be carried out separately from the translation process.
3.23
navigation
process of accessing on-screen documentation and moving between different items of information
3.24
note
helpful hint or other information that might assist the user by emphasizing or supplementing important points
of the main text
NOTE: See also caution and warning.
© ISO/IEC 2009 – All rights reserved 5

3.25
on-screen documentation
information about the software that is intended to be read on the computer screen by the user while using the
software
3.26
platform
the combination of an operating system and hardware that makes up the operating environment in which a
program runs
3.27
pop-up
embedded, context-sensitive information that is displayed when invoked by user action
3.28
printed documentation
documentation that is either provided in printed form, or provided in an electronic form for the customer or
user to print
3.29
procedure
ordered series of steps that a user follows to do one or more tasks
3.30
product
complete set of computer programs, procedures, and associated documentation designed for delivery to a
user
NOTE: See also software.
3.31
product authority
person with overall responsibility for the capabilities and quality of a product
3.32
project
set of activities for developing a new product or enhancing an existing one
3.33
project manager
person with overall responsibility for the management and running of a project
3.34
satisfaction
user's subjective response when using the product
NOTE: Questionnaires are often used to measure user satisfaction and associated attitudes, such as usefulness and
ease of use.
3.35
software
part of a product that is the computer program or the set of computer programs
NOTE: For the purposes of this International Standard, the term software does not include on-screen documentation.
3.36
software user documentation
electronic or printed body of material that provides information to users of software
6 © ISO/IEC 2009 – All rights reserved

3.37
step
one element of a procedure. A step contains one or more actions
3.38
style
set of language-specific editorial conventions covering grammar, terminology, punctuation, capitalization, and
word choice of documentation
3.39
system test of user documentation
testing performed with both the software and the documentation to evaluate that the documentation is fit for
purpose and supports the users sufficiently in their use of the software
3.40
technical contact
person responsible for providing an author with technical information about a product or for checking the
technical accuracy of drafts of user documentation
3.41
topic
small part of a document that deals with a single subject
NOTE 1: In printed documentation, a topic is equivalent to a section (heading; subheading) and its content. In onscreen
documentation, a topic consists of a title (heading) and information about a subject (typically, a task or a concept or
reference information).
NOTE 2: For on-screen documentation, the system may present a topic without user intervention.
EXAMPLE: Instructions on how to print the current document and displayed separately as part of the on-screen
documentation.
3.42
tutorial
Instructional procedure in which the user performs software functions using sample data supplied with the
software or documentation
3.43
use case
sequence of tasks that a system can perform, interacting with users of the system and providing a measurable
result of value for the user
3.44
user
person who employs software to perform a task
3.45
validation
confirmation, through the provision of objective evidence, that the requirements for a specific intended use or
application have been fulfilled
3.46
verification
confirmation, through the provision of objective evidence, that specified requirements have been fulfilled
3.47
warning
advisory in software user documentation that performing some action might lead to serious or dangerous
consequences
© ISO/IEC 2009 – All rights reserved 7

NOTE: See also caution and note.
4 User documentation process within the systems/software life cycle
This clause covers the processes involved in testing and reviewing user documentation.
Testers and reviewers of software user documentation work within the life cycle processes of the software
product, which are defined in ISO/IEC 12207:2008, Software life cycle processes. The applicable processes
are the Software Implementation process of Software Qualification Testing, and the Software Support
Processes of Documentation Management and Validation. ISO/IEC 12207 also describes the activities of the
documentation management process:
• process implementation;
• development and review;
• production;
• maintenance.
Within the Documentation Management process described in ISO/IEC 12207:2008, review of the
documentation and approval of adequacy by authorized personnel prior to issue is described as part of the
design and development process. This includes review for format, technical content, and presentation style
against documentation standards. Within the Software Validation process and activities described in
ISO/IEC 12207:2008, the relevant activities are tested so that representative users can successfully achieve
their intended task, and that the product satisfies its intended use.
Therefore, testing and reviewing of the user documentation should be part of the same processes as the
product life cycle, and ideally performed in conjunction with the development of the software, so that the
software and the user documentation are tested, distributed, and maintained together. The testing of all the
documentation, including on-screen documentation and printed documentation, should be a part of the
development of the product as a whole, not a separate exercise. Although accurate user documentation
cannot be completed until the software product has been fully developed, the user documentation and the
product both benefit from concurrent development and testing.
Ideally, documentation testing is carried out in conjunction with the development of the software. Aspects of
the Measurement life cycle process from ISO/IEC 12207:2008 are also relevant to this International Standard.
The test process applies to software and documentation developed under both the classic documentation
development process (development of a new product with new user manual), and also more complex
circumstances, such as:
• a previously documented software product is being upgraded, offered in a new version or on different
operating system platforms, or customized as part of system integration requiring the revision of
previous documentation;
• previous documentation must be converted to a different format or different media, or in different
languages or versions, such as tutorials, online help, or advanced reference guides;
• previous documentation must be adapted or used as models for different products acquired or
supplied by an organization;
• previous documentation must be modified to adhere to new regulations, business process guidelines,
or compliance requirements.
Testing and reviewing software user documentation is greatly assisted by the presence of other
documentation produced during the software life cycle, such as a Documentation Plan, System Design
Document, System Test Plan, Release Records, and Problem Reports. Other documentation specific to the
8 © ISO/IEC 2009 – All rights reserved

documentation process may be produced, such as style guides and organizational procedures for content
management and documentation reviews.
NOTE: ISO/IEC 15289:2006 Systems and Software Engineering — Content of systems and software life cycle
process information products (Documentation) provides recommendations for the required documents throughout the
systems/software life cycle.
This International Standard is also related to the following standards: ISO/IEC 25000:2005 Software
Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE and
ISO/IEC 14598, Information technology — Software product evaluation Parts 1-6, 1998-2001. These
standards describe the quality metrics characteristics of software and the evaluation process for ensuring
quality in a software product. The same processes may be used to ensure that the documentation meets the
required quality through the use of evaluation metrics.
For the sake of simplicity, this standard describes the life cycle as if there were a clear starting point for
developing documentation, and a clear end point. However, there is not a single sequence of activities that
might be followed in all cases for all products and all types of information. For example, implementation and
review activities are very closely inter-linked, as are testing and maintenance, and the way they link together
varies between projects.
5 Documentation evaluation process requirements, objectives, and constraints
5.1 General
The purpose of documentation evaluation is to ensure that documentation is acceptable for use. This clause
describes the processes of documentation evaluation in two forms: testing and reviewing. Documentation
evaluations are performed throughout the document's development, production, and maintenance.
Documentation evaluation shall be based on the required functions and qualities. Ultimate acceptance comes
from the end-users, but the managers, developers, testers, and maintainers must accept the quality before the
documentation can be released to the user. Evaluation of documentation quality depends on the recognition of
various perspectives for acceptability:
• manager's view. Managers might be more concerned with overall quality than with specific quality
characteristics. They might assign different weights to certain characteristics to reflect the business
needs of the organization, comparing the documentation to what is commercially available in the
market and what is less costly to produce. Managers should be aware that the quality of
documentation might appreciably affect costs for customer support and future sales.
• developer's view. Developers might be concerned with how the product operates in its innovative or
advanced functions, more than with how the product supports the users' tasks.
• tester's view. Testers might be concerned with how the product operates in its innovative or
advanced functions in the same way as other developers, but should have a better understanding of
how the product supports the users' tasks, and whether the documentation matches the product and
helps the user to accomplish tasks.
• maintainer's view. Those who will have to maintain the documentation systems will have special
requirements for quality in addition to those of other developers. They will be concerned with, for
example, the simplicity and clarity of the documentation structures, the ease with which new versions
of the documentation might be created, and portability to new technology for content management and
production.
• user’s view. Users are likely to measure quality in terms, such as inclusion of needed information,
reliability, and ease of finding information and applying it to accomplish needed tasks.
© ISO/IEC 2009 – All rights reserved 9

5.2 Documentation evaluation activities
Documentation evaluation shall include the following four activities: Plan, Do, Check, Act.
• Plan: The organization shall identify the requirements for acceptable performance or quality. The
organization shall prepare for the evaluation exercise by specifying the schedule, the resources
needed, how the evaluation will be carried out (test scenarios and scripts), how the results will be
measured and recorded, how the results will be analyzed, and the pass/fail criteria for the evaluation.
• Do: The organization shall draw up test scenarios and scripts based on the requirements from the
planning stage. The organization shall then evaluate the documentation against the requirements,
using measures, and record the results. Tests may be carried out by members of the project team
during development, following the test scripts to ensure tests are systematic and complete.
• Check: The organization shall analyze and report the results of the evaluation, recommending next
steps.
• Act: Based on the evaluation results and recommendations, the organization shall revise the
documentation and the product, and determine if further evaluation cycles are needed.
NOTE: Revisions may entail changes in the project schedule and documentation plan or even changes in the
requirements to produce acceptable results. For example, documentation of advanced functions might be deferred until a
later project phase, or product release dates might be deferred until acceptable documentation is produced.
The documentation evaluation activities recommended in this International Standard should be carried out
under the control of the quality management system being used for the software product. Users of this
International Standard are recommended to operate a quality management system, which may be
independently assessed for ISO 9000 compliance.
5.3 Selection of an evaluation method
The evaluation method selected depends on a variety of factors including:
• the reasons for carrying out the evaluation;
• the phase in the life cycle at which the evaluation is being carried out;
• the resources available;
• the time available;
• the amount of information available about the documentation;
• the availability of users with the appropriate ranges of experience and skill;
• the availability of experts in documentation design;
• the availability of experts in usability.
Different methods may be used at different phases in the development, after the documentation is complete
and when the documentation has been used for a specified period. A combination of methods is likely to be
appropriate in each case.
5.4 Documentation review
The documentation review process as further detailed in 6.1 includes:
• editorial reviews of the documentation's structure, format, and style compared to plans, requirements,
and established standards;
• content reviews;
10 © ISO/IEC 2009 – All rights reserved

• topic coverage;
• technical accuracy (consistency with the product);
• safety (provision of critical information to protect against hazards or defects);
• legal, statutory and regulatory requirements.
5.5 Documentation test
Documentation test requirements shall be specific and measurable. The purpose of the test process is to
provide formal evidence that the user documentation:
• enables the users to accomplish their goals;
• meets the requirements and constraints, such as the documentation policy and standard formats and
styles set by the producer of the software product;
• is consistent with the software product; that is, the documentation is accurate, sufficient, and useful
NOTE: Consult Clause 11.1 in ISO/IEC 26514:2008. Systems and software engineering—Requirements for designers
and developers of user documentation for additional information on the completeness of documentation.
• meets usability requirements, that is, information is easy to find, easy to use, and easy to understand;
• meets the needs of the intended acquirer and end users of the software product and documentation.
The documentation test process, as further detailed in 6.2 to 6.6, includes:
• operational testing to ensure that the documentation performs correctly and responsively (for example,
on-screen documentation is appropriately linked to the software topic and navigation operation is
consistent and as expected; the index in printed documentation has accurate references);
• usability testing of documentation with the product, to determine whether the intended audience can
perform their tasks with the aid of the documentation.
5.6 Project requirements affecting documentation evaluation
The user documentation tester or reviewer shall gather or receive information about the testing of the whole
project, to understand the requirements that affect the testing of the documentation components.
Documentation testers and reviewers need the following information in order to plan the evaluation of the
documentation:
• who are the users, and in what contexts will they use the product?
• what formats will the documentation be provided in for the end user?
• are there users with special needs?
• what is the purpose of the software product? What will it do?
• is there a previous version? If so, which features have to be changed and which have to remain the
same?
• is the product standalone, or is it part of a suite of products?
• when will the documentation be available to assess and test?
• when will the testing need to be completed?
• will the documentation be available to test at the same time as the software?
• what types of documentation will be produced?
© ISO/IEC 2009 – All rights reserved 11

• what is the scope of the evaluation; that is, how much documentation needs to be tested?
• on what platforms will the product run at this release? Are there plans for other platforms later?
• is the product being developed for a specific organization or organizations? If so, are those
organizations the exclusive users?
• will localized or customized versions of the product be required?
• Will the documentation be translated into foreign languages? What languages?
Documentation testers need to know the following about the product development schedule:
• when will the alpha, beta, and acceptance testing start and be completed?
• when will the testing need to be completed?
• what is the delivery date for the finished product?
• what are the major dependencies between different activities in the overall project?
5.7 Resource requirements and planning
The documentation evaluator should obtain information on the planned or required tools for:
• reviewing the documentation;
• testing the documentation; including performing usability tests and tests of accessibility.
If the new product is part of a suite of products, consider the use of any tools already specified for testing
documentation for that suite.
In planning the evaluation of the documentation, the availability of resources should be considered. The
evaluation plan should include the time and effort to include acquisition of resources or services that are not
already available in the organization. A working model or prototype of the documentation should be provided
where testing is scheduled to take place before software or documentation development is complete. The
acquirer or project sponsor should provide people to participate in the usability tests. These people shall have
the same characteristics as the defined audience. The purpose of the test sha
...