ISO/IEC/IEEE 26513:2017

INTERNATIONAL ISO/IEC/
STANDARD IEEE
Second edition
2017-10
Systems and software engineering —
Requirements for testers and
reviewers of information for users
Ingénierie des systèmes et du logiciel — Exigences pour testeurs et
vérificateurs de documentation utilisateur
Reference number
©
ISO/IEC 2017
©
IEEE 2017
© ISO/IEC 2017, Published in Switzerland
© IEEE 2017
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 ISO, IEC or IEEE at
the respective address below.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
Ch. de Blandonnet 8 • CP 401 3 Park Avenue, New York
CH-1214 Vernier, Geneva, Switzerland NY 10016-5997, USA
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org stds.ipr@ieee.org
www.iso.org www.ieee.org
© ISO/IEC 2017 – All rights reserved
ii © IEEE 2017 – All rights reserved

ISO/IEC/IEEE 26513:2017(E)
Contents Page
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Conformance . 9
4.1 Definition of conformance . 9
4.2 Conformance situations . 9
5 Review and assessment processes of user documentation within the software lifecycle . 10
5.1 Process overview . 10
5.2 Review and assessment activities . 10
6 Documentation evaluation strategy . 12
6.1 Requirements, objectives, and constraints . 12
6.2 Documentation evaluation activities . 13
6.3 Selection of an evaluation method . 14
6.4 Documentation evaluation criteria . 14
6.5 Documentation test process . 14
6.6 Project requirements affecting documentation evaluation . 15
6.7 Resource requirements and planning . 15
General . 15
Resources for documentation evaluation . 16
Impact of evaluation on project schedules . 16
7 Documentation evaluation methods and procedures . 17
7.1 General . 17
7.2 Documentation review . 17
Planning documentation review . 17
Administering quality review . 19
Managing the results of documentation review . 20
Configuration change review . 20
7.3 System test of documentation . 20
7.3.3 Creating the system test plan for documentation . 22
System test plan for documentation approvals . 23
Problem management and the system test of documentation lifecycle . 23
7.4 Usability testing of documentation . 23
General . 23
Objectives and activities for usability testing of documentation . 24
Measures and metrics for documentation usability testing goals . 25
Planning documentation usability tests . 25
Performing usability evaluation of documentation . 27
Problem management for documentation usability tests . 28
7.5 Accessibility testing of documentation . 28
Scope of accessibility testing . 28
Performing accessibility tests . 29
7.6 Translation and localization review and testing . 29
General . 29
Planning for translation and localization review and testing . 29
Performing translation and localization review and testing . 29
Annex A (informative) User-centered test and review guidelines . 31
A.1 Support for an action-oriented approach . 31
A.2 Support for real tasks . 32
A.3 Support for error recognition and recovery . 33
iii
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

A.4 Support for information access . 33
A.5 Content for translation . 34
Bibliography . 35

iv
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

ISO/IEC/IEEE 26513:2017(E)
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.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of
the IEEE Standards Association (IEEE­SA) Standards Board. The IEEE develops its standards through a consensus
development process, approved by the American National Standards Institute, which brings together volunteers
representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members
of the Institute and serve without compensation. While the IEEE administers the process and establishes rules to
promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify
the accuracy of any of the information contained in its standards.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of ISO/IEC JTC 1 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 called to the possibility that implementation of this document may require the use of subject matter
covered by patent rights. By publication of this document, no position is taken with respect to the existence or
validity of any patent rights in connection therewith. ISO/IEC and IEEE is not responsible for identifying essential
patents or patent claims for which a license may be required, for conducting inquiries into the legal validity or scope
of patents or patent claims or determining whether any licensing terms or conditions provided in connection with
submission of a Letter of Assurance or a Patent Statement and Licensing Declaration Form, if any, or in any licensing
agreements are reasonable or non­discriminatory. Users of this document are expressly advised that determination
of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility.
Further information may be obtained from ISO or the IEEE Standards Association.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 7,
Software and systems engineering, in cooperation with the Software & Systems Engineering Standards Committee
of the IEEE Computer Society, under the Partner Standards Development Organization cooperation agreement
between ISO and IEEE.
This second edition of ISO/IEC/IEEE 26513 cancels and replaces ISO/IEC 26513:2009 which has been
technically revised. The main changes compared to the previous edition are as follows:
― additions to the Terms and Definitions;
― updates to the Documentation Review and System Test of Documentation sections;
― expanded sections for Accessibility Testing and Translation and Localization Review and Testing;
― replacement of the editorial checklists in Annex A with User­centered Test and Review Guidelines;
― editorial changes; and
― additions to the bibliography.
v
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

Introduction
Well­designed documentation not only assists users and helps to reduce the cost of training and support, but also
enhances the reputation of the product, its producer, and its suppliers. Verification, validation testing, and expert
review of content during development provides feedback to information developers regarding the accuracy and
usability of their work. This document addresses the evaluation and testing of information provided for users to
perform tasks, make decisions in context, and gain understanding. It applies to both initial development and
subsequent releases of the software and user documentation.
This document is independent of the software tools that may be used to produce documentation and applies to
printed and electronic documentation, embedded content in the software, and online documentation. Much of its
guidance is applicable to user documentation for systems including software user documentation as well as the
software used to control machinery or hardware devices.
This document was developed to assist those who test and review software user documentation as part of the
software lifecycle process. This document defines the information management and validation processes of
ISO/IEC/IEEE 12207:2017 from the information assessors' and testers' standpoints. This document can be used
as a conformance or a guidance document for products, projects, and organizations claiming conformance to
ISO/IEC/IEEE 15288:2015 or ISO/IEC/IEEE 12207:2017. Readers are assumed to have experience with or general
knowledge of reviewing and testing processes.

vi
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC/IEEE 26513:2017(E)
Systems and software engineering — Requirements for testers
and reviewers of information for users
1 Scope
This document supports the interest of software users in receiving consistent, complete, accurate, and
usable documentation and specifies processes for use in testing and reviewing of user documentation
(Clause 6). It is not limited to the test and review stage of the lifecycle, but includes activities throughout
the information management and documentation management process.
This document is intended for use in all types of organizations, whether or not a dedicated documentation
department is present. In all cases, it can 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 document deals with the evaluation of end­user content only, and not with the evaluation of the
software it supports.
NOTE 1 Documentation is also included in evaluation of the software product, as in the ISO/IEC 25000 and
29000 series of standards. In particular:
— ISO/IEC TR 25060;
— ISO/IEC 25062;
— ISO/IEC 25063:2014;
— ISO/IEC 25064:2013; and
— ISO/IEC/IEEE 29119­3:2013.
This document provides the minimum requirements for testing and reviewing user documentation
(Clause 7), including both printed and online documents used in work and other environments by the
users of software which includes application software, systems software, apps on mobile devices, and
software that controls machinery or hardware devices. It applies to printed user manuals, online help,
user assistance, tutorials, websites, and user reference documentation.
This document can also 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;
— tutorial 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; and
— maintenance documentation describing the internal operation of systems software.
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

This document is applicable to testers, reviewers, and other related roles, including a variety of
specialists:
— usability testers, documentation reviewers, and subject­matter experts;
— information developers and architects who plan the structure and format of products in a
documentation set;
— usability analysts and business analysts who identify the tasks the intended users perform with
the software;
— editors;
— test participants;
— installers, computer operators, or system administrators; and
— customer support groups such as training, help desks, repair, and return.
The document can also be consulted by those with other roles and interests in the information
management process. Managers of the software development process or the information management
process consider the testing of documentation as part of their planning and management activities.
Project managers, in particular, have an important role in supporting the review and testing of
documentation.
Testing of the documentation is likely to highlight any defects or nonconformances in tools that are used
to create or display online documentation. Similarly, usability testing of the documentation is likely to
identify additional operational concerns or misunderstandings of end users.
NOTE 2 Testing of documentation can highlight problems with the software being documented. Resolving
problems with the software is not in the scope of this document.
There are other roles that need to understand the test processes for the documentation; for example,
information developers should understand the test processes 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.
The order of clauses in this document does not imply that software user documentation is meant to be
reviewed, assessed, edited, or tested in this order.
In each clause, the requirements are media­independent, as far as possible. The informative guidelines
found in Annex A, User-Centered Test and Review Guidelines, can be used at each stage of the information
management process to verify that the correct steps have been carried out and that the finished product
has acceptable quality.
The works listed in the Bibliography provide additional guidance on the processes of managing,
preparing, and testing of user documentation.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

ISO/IEC/IEEE 26513:2017(E)
ISO, IEC and IEEE maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org
— ISO Online browsing platform: available at http://www.iso.org/obp
— IEEE Standards Dictionary Online: available at http://dictionary.ieee.org
NOTE ISO/IEC/IEEE 24765 Software and Systems Engineering Vocabulary can 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
A/B testing
technique to determine the effectiveness of minor changes in a product or design where “A”
represents the original version and “B” represents the modified version
Note 1 to entry: This notation is typically used in usability testing. In this instance, A/B does not refer to alpha and
beta testing.
3.2
accessibility
consideration of a product, service, environment, or facility by people with the widest range of
capabilities
Note 1 to entry: Although "accessibility" typically addresses users who have disabilities, the concept is not limited
to disability issues.
3.3
assistive technology
hardware or software that is added to or incorporated within a system that increases
accessibility for an individual
EXAMPLE Braille displays, screen readers, screen magnification software, and eye tracking devices
are assistive technologies.
[SOURCE: ISO/IEC/IEEE 24765:2010]
3.4
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 1 to entry: See also persona (3.29).
Note 2 to entry: There may be a number of audiences for a software product’s documentation (for example,
management, data entry, maintenance, engineering, business professionals).
3.5
caution
hazardous situation which, if not avoided, can result in minor or moderate injury
Note 1 to entry: See also danger (3.8) and warning (3.50).
[SOURCE: ISO/DIS 3864­2:2015, definition 3.1, Modified, ""signal word" removed from definition.]
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.6
complete
all critical information and any necessary, relevant information for the
intended audience
[SOURCE: ISO/IEC/IEEE 15289:2017]
3.7
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.8
danger
hazardous situation, which if not avoided, can result in death or serious injury
Note 1 to entry: See also caution (3.5) and warning (3.50).
[SOURCE: ISO/DIS 3864­2:2015, definition 3.3, Modified, "signal word used to indicate" removed from
definition.]
3.9
document (noun)
uniquely identified unit of information for human use
EXAMPLE Report, specification, manual, or book in printed or electronic form.
Note 1 to entry: A document can be a single information item or part of a larger information item.
[SOURCE: ISO/IEC/IEEE 15289:2017]
3.10
documentation
information that explains how to use software, devices, applications, or services
Note 1 to entry: Throughout this document, the term documentation refers to software user
documentation. "Software" includes application software, systems software, and software that controls
machinery or hardware devices. Documentation may include a wide variety of products such as user
guides, reference manuals, tutorials, wikis, input forms, error messages, user interfaces, and online help.
3.11
document set
collection of documentation that has been segmented into separately identified volumes or
products for ease of distribution or use
3.12
effectiveness
accuracy and completeness with which users achieve specified goals

[SOURCE: ISO/IEC 25062:2006, definition 4.2]
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

ISO/IEC/IEEE 26513:2017(E)
3.13
efficiency
resources expended in relation to the accuracy and completeness with which users achieve
goals
Note 1 to entry: Efficiency in the context of usability is related to productivity rather than to its meaning in the
context of software efficiency.
[SOURCE: ISO/IEC 25062:2006, definition 4.3]
3.14
embedded documentation
information that is delivered as an integral part of a piece of software
EXAMPLE Tool tips or other text displayed or provided with the software.
3.15
evaluation
systematic determination of the extent to which an entity meets its specified criteria
3.16
function
part of a software application that provides features for users to carry out their tasks
3.17
hazard
source of potential harm
[SOURCE: ISO/DIS 3864­2:2015, definition 3.6, Modified, Note 1 to entry removed.]
3.18
heuristic evaluation
assessment by one or more experts who judge conformance to a recognized set of principles
3.19
illustration
graphical element set apart from the main body of text and normally cited within the main text
Note 1 to entry: In this document, the term illustration is used as the generic term for tables, figures, exhibits,
screen captures, flow charts, diagrams, drawings, icons, and other graphical elements.
3.20
information architect
person who develops the structure of an information space and the semantics for accessing
required task objects, system objects, and other information
3.21
information development
process of development concerned with determining what content and visuals shall be provided
in product documentation and what the nature of the information shall be
3.22
information developer
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

person who prepares the content and visuals for product documentation
3.23
information development lead
person who leads the activities of preparing documentation
3.24
link
reference from some part of one document to some other part of another document or another
part of the same document
Note 1 to entry: Synonym: hyperlink
3.25
localization
creation of a national or specific regional version of a product or its documentation
Note 1 to entry: Documentation can be localized even if the product has not been localized.
3.26
mobile device
portable computing device, typically having a wireless internet connection and a display screen
with touch, pen, or keyboard input, and possibly auditory input and output features
Note 1 to entry: Mobile devices have to fulfil special usability requirements due to their size and available
features for input and output.
3.27
navigation
process of accessing information and moving between different items of information
3.28
online help
information about the software that is intended to be read on the screen by the user while using
the software
Note 1 to entry: Online help can be displayed in a variety of forms (contextual help, screen tips, and examples).
3.29
persona
model of a user with defined characteristics, based on research
3.30
platform
combination of an operating system and hardware that makes up the operating environment in
which a program runs
3.31
procedure
ordered series of steps that a user follows to perform one or more tasks
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

ISO/IEC/IEEE 26513:2017(E)
3.32
project manager
person with overall responsibility for the management and running of a project
3.33
satisfaction
freedom from discomfort and positive attitudes towards the use of the product

[SOURCE: ISO/IEC 25062:2006, definition 4.4]
3.34
software
part of a product that is the computer program or the set of computer programs
Note 1 to entry: For the purposes of this document, the term software does not include information developed for
users.
3.35
software user documentation
electronic or printed body of material that provides information and assistance to users of
software
3.36
step
element of a procedure containing one or more actions that enables a user to perform a task
3.37
style
set of language­specific editorial conventions covering grammar, terminology, punctuation,
capitalization, usage, word choice, structured authoring elements, and images in documentation
3.38
tailoring
process by which individual requirements in specifications, standards, and related documents
are evaluated and made applicable to a specific project by selection, and in some exceptional
cases, modification of existing or addition of new requirements
[SOURCE: ISO 27025:2010, definition 3.1.3]
3.39
test lead
person who leads entire testing process
3.40
test participant
person who provides feedback and allows data collection to test that the information in the
software documentation is sufficient to accomplish tasks correctly and form a conceptual
understanding of the system
3.41
test protocol
list of the steps to be followed in the test
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

3.42
testing
activity in which a system or component is executed under specified conditions, the results are
observed or recorded, and an evaluation is made of some aspect of the system or component
3.43
topic
unit of information that deals with a single subject
3.44
usability
extent to which a system, product, or service can be used by specified users to achieve specified
goals with effectiveness, efficiency, and satisfaction in a specified context of use

[SOURCE: ISO 9241­210:2010, Modified, Note 1 to entry removed.]

3.45
usability analyst
person who observes users performing tasks using the software and documentation and records
the actions the user took, problems the user encountered, and comments the user made during
the test; and interprets these records to evaluate the results of the testing
3.46
use case
description of the behavioral requirements of a system and its interaction with a user
3.47
user
person who employs software to learn or to perform a task
3.48
validation
confirmation, through the provision of objective evidence, that the requirements for a specific
intended use or application have been fulfilled
Note 1 to entry: A system is able to accomplish its intended use, goals, and objectives (i.e., meet stakeholder
requirements) in the intended operational environment.
[SOURCE: ISO 9000:2015, Modified, Note 1 to entry has been modified, Notes 2 and 3 to entry have been
removed.]
3.49
verification
confirmation, through the provision of objective evidence, that specified requirements have
been fulfilled
Note 1 to entry: Verification is a set of activities that compares a system or system element against the required
characteristics. This includes, but is not limited to, specified requirements, design description, and the system itself.
[SOURCE: ISO 9000:2015, Modified, Note 1 to entry has been modified, Notes 2 and 3 to entry have been
removed.]
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

ISO/IEC/IEEE 26513:2017(E)
3.50
warning
hazardous situation, which if not avoided, can result in death or serious injury
Note 1 to entry: See also caution (3.5) and danger (3.8).
[SOURCE: ISO/DIS 3864­2:2015, definition 3.18, Modified, "signal word" removed from definition.]
4 Conformance
4.1 Definition of conformance
This document may be used as a conformance or a guidance document for projects and organizations
claiming conformance to:
— ISO/IEC 26514:2008, Systems and software engineering — Requirements for designers and
developers of user documentation;
— ISO/IEC/IEEE 15288:2015, Systems and software engineering — System lifecycle processes;
— ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software lifecycle processes.
When the selected software lifecycle processes are tailored, the organization or project may claim
conformance to this document for its information testing process.
Throughout this document, "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 document. When using this document as a guide, replace the term "shall" with "should".
NOTE ISO/IEC/IEEE 12207:2017 Annex A defines the tailoring process.
4.2 Conformance situations
Conformance may be interpreted differently for various situations. The relevant situation shall be
identified in the claim of conformance:
— When conformance is claimed for a project, the project plans or the contract shall document
the tailoring of the assessment and test (validation) process;
— 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 is 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 document that reference "the contract."
— This document 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 document.
This document may also be adopted as an in­house standard by a project or organization that
decides to test or assess documentation in accordance with the document.
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

5 Review and assessment processes of user documentation within the software
lifecycle
5.1 Process overview
This clause covers the processes involved in testing and reviewing user documentation.
Testers and reviewers of software user documentation work within the lifecycle processes of the
software product, which are defined in ISO/IEC/IEEE 12207:2017. The applicable processes are the
following:
— implementation;
— validation;
— verification; and
— maintenance.
5.2 Review and assessment activities
The typical lifecycle of documentation and its testing and review includes the following activities:

— user needs assessment;
— task analysis;
— user documentation requirements definition;
— document (information) design;
— draft or prototype;
— revision;
— early testing (prototype, information architecture, issue identification);
— beta review (accuracy, editing);
— evaluative testing (efficiency, effectiveness, satisfaction, accessibility);
— final release; and
— evaluative testing, optional (performance, learnability, A/B testing).
In addition to leading the activities of preparing documentation, the information development lead
identifies reviewers during the design and development stages. Review activities include review of
structure, format, and technical content against established guidelines and documentation standards.
Within the Software Validation process described in ISO/IEC/IEEE 12207:2017, the relevant
functions are performed so that representative users can successfully complete their intended tasks
and the product satisfies its intended use.
Testing and reviewing user information, which includes the user interface, the navigation, and the
information architecture, should be part of the same processes as the product lifecycle and should be
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
should be a part of the development of the product as a whole and 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.
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

ISO/IEC/IEEE 26513:2017(E)
The validation and verification processes apply to software and documentation developed under both
the classic documentation development process (development of a new product with a new user manual),
and also more complex circumstances, such as previous documentation that should be:
— converted to a different format or different media, such as mobile device interfaces;
— converted into different information products such as tutorials, online help, or advanced
reference guides;
— adapted or used as models for different products acquired or supplied by an organization;
— modified to adhere to new regulations, business process guidelines, or compliance
requirements;
— converted into different languages or variants including localization and tailoring.

In addition, the test process should also be applied in the following circumstances:

— a previously documented software product is being upgraded, offered in a new version or on
different operating system platforms, or tailored as part of system integration requiring the
revision of previous documentation;
— documentation developed along with software product development methods such as Agile or
eXtreme that require multiple iterations before release;
— software or documentation delivered on multiple platforms with tailoring for these
environments; and
— documentation migrated from unstructured content to structured content.
Testing and reviewing software user documentation is greatly assisted by the presence of other
documentation produced during the software lifecycle, such as a documentation plan, prototypes,
system design document, system test plan, release records, and usability reports. Other documentation
specific to the information management process may be produced, such as style guides and business
processes for content management and documentation reviews, and accessibility standards.
NOTE 1 ISO/IEC/IEEE 15289:2017 provides recommendations for the required documents throughout the
systems and software lifecycle.
NOTE 2 This document is also related to the following standards: ISO/IEC 25000:2015 and ISO/IEC 14598, Parts
1­6, 1998­2001. These documents describe the quality metrics characteristics of software and the evaluation
process for providing quality in a software product. The same processes can be used to help the documentation
meet the required quality through the use of evaluation metrics (such as effectiveness and satisfaction, learnability,
errors, and safety).
NOTE 3 Of particular relevance is ISO/IEC 25066:2015, as usability performance targets are often closely
associated with information design and content.
For the sake of simplicity, this document describes the lifecycle as if there were a clear starting point
for developing documentation and a clear end point. However, there is no sequence of activities that can
be followed in all cases for all products and all types of information. For example, implementation and
review activities are very closely related, as are testing and maintenance, and the way they relate
together varies among projects.
© ISO/IEC 2017 – All rights reserved
© IEEE 2017 – All rights reserved

6 Documentation evaluation strategy
6.1 Requirements, objectives, and constraints
The purpose of documentation evaluation is to help ensure that documentation assists end users achieve
their goals. This clause describes the processes of documentation evaluation in two forms: reviewing and
testing. Documentation evaluations are performed throughout the document's development, production,
and maintenance lifecycle.
Documentation evaluation shall be based on documentation quality. Quality is the ability of
documentation to meet user needs, expectations, and requirements. Managers, developers, testers, and
maintainers should evaluate the quality of the documentation. Managers shall be responsible for assuring
that the quality of user documentation has been evaluated. Evaluations can be performed by developers,
testers, maintainers, managers, and other roles. Ultimately, the users should be satisfied with the
documentation quality; however, managers, developers, testers, and maintainers shall accept the quality
before the documentation is released to the users. The evaluation of documentation quality depends on
the recognition of various perspectives for acceptability:
— Managers. Managers are more concerned with overall quality than with specific quality
characteristics. They can 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 can appreciably affect costs for customer support and future sales.
— Software developers. Developers are concerned with the conformance of documentation to the
software functionality.
— Product testers. Testers are 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 users to accomplish tasks. For online information, interface design, and
navigation, product test can provide valuable assessment of content accuracy. Product testers can
stress­test to assess performance under extreme or sensitive conditions.
— Product support staff. Staff who maintain the software and systems after the product release
have special requirements for quality in addition to those of other developers. Product
support staff can be concerned with the accuracy, the availability, and the searchability of
different versions of the documentation.
— Content managers. Content managers are concerned with how documentation can be controlled
for subsequent document releases, different versions, information reuse, metadata associated
with content for search and retrieval, and translation and localization.
— Editors. Editors are concerned with documentation conformance to organizational style, formats,
language, terminology, and structure.
— Usability analysts. Analysts record the actions of the test participants, the problems the
participants encountered, and comments made during and after the test activity. They also
interpret records of usability test data (such as user actions, problems, and comments, time­on­
task, and successful task completion) to evaluate the results of the testing. Usability analysts can
be concerned with whether the documentation meets the end users' needs with satisfaction. Early
in the development cycle, usability analysts identify design issues and errors; later, the focus can
shift to performance, satisfaction, and learnability measures
...