ISO/IEC 25063:2014

INTERNATIONAL ISO/IEC
STANDARD 25063
First edition
2014-03-15
Systems and software engineering —
Systems and software product
Quality Requirements and Evaluation
(SQuaRE) — Common Industry Format
(CIF) for usability: Context of use
description
Ingénierie des systèmes et du logiciel — Exigences de qualité et
évaluation des systèmes et du logiciel (SQuaRE) — Format industriel
commun (CIF) pour l’utilisabilité: Description du contexte d’utilisation
Reference number
©
ISO/IEC 2014
© ISO/IEC 2014
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested 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 2014 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Conformance . 1
3 Terms and definitions . 1
4 Purposes and types of context of use descriptions . 4
4.1 General . 4
4.2 Initial outline of the context of use . 6
4.3 Detailed context of use descriptions . 6
4.4 Context of use for an evaluation . 7
4.5 Context of use information included in a product description. 7
5 Elements of a context of use description . 8
5.1 General . 8
5.2 Subject of the context of use description . 9
5.3 User population .10
5.4 Goals and responsibilities of the user group and the organization .13
5.5 Tasks of the users .14
5.6 Environment(s) of the user .16
5.7 Problems .18
Annex A (informative) Initial outline of the context of use .20
Annex B (informative) Users of the context of use .21
Annex C (informative) Example of a context of use checklist .23
Bibliography .32
© ISO/IEC 2014 – 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 shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 25063 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in collaboration with Technical Committee
ISO/TC 159, Ergonomics, Subcommittee SC 4, Ergonomics of human-system interaction.
iv © ISO/IEC 2014 – All rights reserved

Introduction
[4]
The human-centred design approach of ISO 9241-210 is well established and focuses specifically
on making systems usable. Usability can be achieved by applying human-centred design and testing
throughout the life cycle. In order to enable a human-centred approach to be adopted, it is important
that all the relevant types of information related to usability (information items) are identified and
communicated. This identification and communication enables the usability of a system to be designed
and tested.
This International Standard provides a framework and consistent terminology for describing the context
of use of an interactive system. It is intended to assist developers in documenting and communicating
usability-related information through the system development life cycle.
The Common Industry Format (CIF) for Usability family of International Standards is described in
[19] [17]
ISO/IEC TR 25060 and is part of the SQuaRE series (ISO/IEC 25000 to ISO/IEC 25099) of standards
on systems and software product quality requirements and evaluation.
The CIF family of standards uses definitions that are consistent with the ISO 9241 series of standards
(Ergonomics of human system interaction), as this is the terminology that is normally used for this
subject matter.
CIF standards are planned for the following information items:
— Context of use description (ISO/IEC 25063);
— User needs report (ISO/IEC 25064);
— User requirements specification (planned ISO/IEC 25065);
— User interaction specification;
— User interface specification;
— Evaluation report (planned ISO/IEC 25066);
— Field data report.
The CIF standards are part of the “Extension Division” of the ISO/IEC 25000 “SQuaRE” series of
International Standards (see Figure 1).
Figure 1 — Organization of SQuaRE series of International Standards
[2] [18]
Context of use is defined in ISO 9241-11. The system quality model in ISO/IEC 25010 incorporates
context of use.
© ISO/IEC 2014 – All rights reserved v

[4]
Figure 2 — Relationship of CIF documents to user centred design in ISO 9241-210 and system
[7]
life cycle processes in ISO/IEC 15288
Figure 2 illustrates the interdependence of these information items with the human-centred design
[4]
activities described in ISO 9241-210 as well as the corresponding System Life Cycle processes
[7]
described in ISO/IEC 15288. The figure depicts the activities as a set of intersecting areas. The circles
overlap to represent that the activities are not separate, but rather, overlapping in time and scope and
the outcome of each activity provides the input to one or more other activities. As each human-centred
design activity can provide input to any other, there is no starting point, no end point, or linear process
intended.
Human-centred design relies on user needs that are first identified based on the Context of Use analysis.
User needs are documented in the User Needs Report (ISO/IEC 25064), which is an intermediate
deliverable that links the Context of Use Description (ISO/IEC 25063) that contains Information about
the users, their tasks and the organizational and physical environment, to the user requirements.
These items are developed during the Stakeholders Requirements Definition Process described in
[7]
ISO/IEC 15288.
The “Produce design solutions” activity focuses on designing user interaction that meets user
requirements. This activity takes place during the Architectural Design, Implementation, and Integration
[7]
processes described in ISO/IEC 15288 and produces the information items “User Interaction
Specification” and the “User Interface Specification”.
The “Evaluate” activity starts at the earliest stages in the project, evaluating design concepts to obtain
a better understanding of the user needs. Design solutions can be evaluated multiple times as the
interactive system is being developed, and can produce various types of evaluation report, and usability
[20] [7]
data such as that described in ISO/IEC 25062 can support the ISO/IEC 15288 validation process
that confirms that the system complies with the stakeholder requirements.
vi © ISO/IEC 2014 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 25063:2014(E)
Systems and software engineering — Systems and software
product Quality Requirements and Evaluation (SQuaRE) —
Common Industry Format (CIF) for usability: Context of use
description
1 Scope
This International Standard specifies the contents of both high-level and detailed descriptions of context
of use for an existing, intended, designed or implemented system, product or service.
The context of use description is applicable to software and hardware systems, products or services
(excluding generic products, such as a display screen or keyboard). The description of the context of
use is intended to be used as part of system-level documentation resulting from development processes
such as those in ISO 9241-210 and ISO/IEC JTC 1/SC 7 process standards.
This International Standard does not prescribe any kind of method, life cycle or process.
The context of use information item can be integrated into any type of process model.
[16] [9]
NOTE For the purpose of establishing process models, ISO/IEC TR 24774 and ISO/IEC 15504-2 specify
[8]
the format and conformance requirements for process models, respectively. In addition, ISO/IEC 15289 defines
the types and content of information items developed and used in process models for system and software life cycle
[10] [11]
management. ISO/IEC 15504-5 and ISO/IEC 15504-6 define work products, including information items,
for the purpose of process capability assessment. Process models and associated information items for human-
[13] [12]
centred design of interactive systems are contained in ISO/TR 18529 and ISO/TS 18152 , respectively.
This International Standard also describes the purposes for which context of use descriptions are used,
and identifies the intended users of context of use descriptions.
While this International Standard specifies the required content elements of a context of use description,
it does not prescribe any particular structure or layout for documenting the context of use.
2 Conformance
A description of the context of use conforms to this International Standard if it contains all the required
elements specified in Clause 5.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
accessibility
extent to which products, systems, services, environments and facilities can be used by people from
a population with the widest range of characteristics and capabilities to achieve a specified goal in a
specified context of use
Note 1 to entry: Context of use includes direct use or use supported by assistive technologies.
[SOURCE: ISO 26800:2011, 2.1]
© ISO/IEC 2014 – All rights reserved 1

3.2
context of use
users, tasks, equipment (hardware, software and materials), and the physical and social environments
in which a system, product or service is used
[SOURCE: ISO 9241-11:1998, 3.5, modified — In the definition, “product” has been replaced by “system,
product or service”.]
Note 1 to entry: In this International Standard, equipment is described as part of the technical and technological
environment.
3.3
effectiveness
accuracy and completeness with which users achieve specified goals
[SOURCE: ISO 9241-11:1998, 3.2]
3.4
efficiency
resources expended in relation to the accuracy and completeness with which users achieve goals
[SOURCE: ISO 9241-11:1998, 3.3]
3.5
goal
intended outcome
[SOURCE: ISO 9241-11:1998, 3.8]
3.6
human-centred design
approach to system design and development that aims to make interactive systems more usable by
focusing on the use of the system; applying human factors, ergonomics and usability knowledge and
techniques
Note 1 to entry: The term “human-centred design” is used rather than “user-centred design” in order to emphasize
that this standard also addresses impacts on a number of stakeholders, not just those typically considered as
users. However, in practice, these terms are often used synonymously.
Note 2 to entry: Usable systems can provide a number of benefits including improved productivity, enhanced user
wellbeing, avoidance of stress, increased accessibility, and reduced risk of harm.
[SOURCE: ISO 9241-210:2010, 2.7]
3.7
information item
separately identifiable body of information that is produced and stored for human use during a system
or software life cycle
[SOURCE: ISO/IEC 15289:2006, 5.11]
3.8
interactive system
combination of hardware, software and/or services that receives input from and communicates output
to users
Note 1 to entry: This includes, where appropriate, packaging, branding, user documentation, online help, support
and training.
[SOURCE: ISO 9241-210:2010, 2.8]
2 © ISO/IEC 2014 – All rights reserved

3.9
persona
representation of a type of user that includes a concise summary of the characteristics of the user that
is most informative to the design or illustrative of specific user requirements
Note 1 to entry: A persona typically includes behaviour patterns, goals, skills, attitudes, and environment, with a
few fictional personal details to make the persona a realistic character.
3.10
requirement
condition or capability that must be met or possessed by a system, system component, product, or
service to satisfy an agreement, standard, specification, or other formally imposed documents
Note 1 to entry: Requirements include the quantified and documented needs, wants, and expectations of the
sponsor, customer, and other stakeholders.
[SOURCE: ISO/IEC/IEEE 24765:2010, 3.2506]
3.11
satisfaction
freedom from discomfort, and positive attitudes towards the use of the product
[SOURCE: ISO 9241-11:1998, 3.4]
3.12
stakeholder
individual or organization having a right, share, claim, or interest in a system or in its possession of
characteristics that meet their needs and expectations
[SOURCE: ISO/IEC 15288:2008, 4.29]
3.13
system
combination of interacting elements organized to achieve one or more stated purposes
Note 1 to entry: A system may be considered as a product or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative
noun, e.g. aircraft system. Alternatively the word system may be substituted simply by a context-dependent
synonym, e.g. aircraft, though this may then obscure a system principles perspective.
[SOURCE: ISO/IEC 15288:2008, 4.31]
3.14
task
activities required to achieve a goal
[SOURCE: ISO 9241-11:1998, 3.9]
3.15
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, 2.13]
3.16
user
person who interacts with a system, product or service
Note 1 to entry: A person who uses the output or service provided by a system. For example, a bank customer who
visits a branch, receives a paper statement, or carries out telephone banking using a call centre can be considered
a user.
© ISO/IEC 2014 – All rights reserved 3

[SOURCE: ISO 26800:2011, 2.10]
3.17
user experience
person’s perceptions and responses that result from the use and/or anticipated use of a product, system
or service
Note 1 to entry: User experience includes all the users’ emotions, beliefs, preferences, perceptions, physical and
psychological responses, behaviours and accomplishments that occur before, during and after use.
Note 2 to entry: User experience is a consequence of brand image, presentation, functionality, system performance,
interactive behaviour, and assistive capabilities of the interactive system; the user’s internal and physical state
resulting from prior experiences, attitudes, skills and personality; and the context of use.
Note 3 to entry: Usability, when interpreted from the perspective of the users’ personal goals, can include the
kind of perceptual and emotional aspects typically associated with user experience. Usability criteria can be
established so as to assess aspects of user experience.
[SOURCE: ISO 9241-210:2010, 2.15]
3.18
user interface
all components of an interactive system (software or hardware) that provide information and controls
for the user to accomplish specific tasks with the interactive system
[SOURCE: ISO 9241-110:2006, 3.9]
3.19
user need
prerequisite identified as necessary for a user, or a set of users, to achieve an intended outcome, implied
or stated within a specific context of use
[SOURCE: ISO/IEC 25064:2013, 4.19]
3.20
user requirements
usage requirements
requirements for use that provide the basis for design and evaluation of interactive systems to meet
identified user needs
Note 1 to entry: User requirements are derived from user needs and capabilities in order to make use of the
system in an effective, efficient, safe and satisfying manner.
Note 2 to entry: User requirements specify the extent to which user needs and capabilities are to be met when
using the system. They are not requirements on the users.
Note 3 to entry: In software-engineering terms, user requirements comprise both “functional” and “non-
functional” requirements based on user needs and capabilities.
[SOURCE: ISO/IEC TR 25060:2010, 2.21]
4 Purposes and types of context of use descriptions
4.1 General
The description of the context of use provides common information that is needed for use in conjunction
with the other information items that are to be produced relating to human centred design. Information
about the context of use provides a basis for designing a product that is usable in the intended context of
use, and helps maintain a human-centred design focus within the project.
4 © ISO/IEC 2014 – All rights reserved

Context of use information can be captured in a variety of forms, and descriptions of the context of use
can be formatted to meet the needs of particular audiences.
EXAMPLE 1 Sources of context of use information include:
— Documentation of conducted interviews with users.
— Documentation of observations of users in their real environment.
— Diaries completed by users over a period of time describing their real context of use.
— Documentation of conducted observations of users.
— Documentation of user performance measurements.
— Video files of individual users showing them in their real environment.
EXAMPLE 2 Examples of different representations that can be used to describe the context of use (or parts of
the context of use) include:
— Complete descriptions of users, tasks, equipment (hardware, software and materials), and the physical and
social environments that constitute a detailed context of use description using a structured format (such as
Annex C).
— Narrative descriptions of the context of use (referred to as “scenarios of use”, “context scenarios”, “as is”
scenarios or “problem scenarios”) for each user group, typically based on user interviews.
— Descriptions of users in terms of personas, which represent a type of user by providing a concise summary
of characteristics of an instance of a user, and can include issues such as goals, tasks, skills, attitudes, and
environmental conditions.
The most common types of context of use descriptions are listed below, described in more detail in
the sub-clauses indicated. Depending on the particular design and development situation it could be
necessary to describe some or all of these.
4.2 Initial outline of the context of use
4.3 Detailed context of use descriptions
4.3.1 Current context of use
4.3.2 Intended context of use
4.3.3 Context of use specified as a part of user requirements
4.3.4 Context of use of the implemented system, product or service
4.3.5 Context of use of the deployed system, product or service
4.4 Context of use for an evaluation
4.5 Context of use as part of a system, product or service description
The potential users of each type of context of use description are listed in Annex B.
A context of use description should be treated as an evolving repository of information. The content of
the description will grow as an increasing amount of detail is added in the course of the design process.
NOTE Information about a particular context of use can be used in the development of more than one
interactive system.
© ISO/IEC 2014 – All rights reserved 5

4.2 Initial outline of the context of use
An initial description of the context of use can be based on the assumptions of the project (often derived
from the business case). At this stage it will not be complete, although some aspects, such as the potential
users, will be known. For more details, see Annex A.
4.3 Detailed context of use descriptions
4.3.1 Current context of use
Analysis of the context of use of existing or similar systems, products or services (including manual
systems if appropriate) can provide information on a whole range of context issues including deficiencies
and baseline levels of performance and satisfaction. Information about the current context of use can be
used to identify needs, problems and constraints that might otherwise be overlooked, but which design
of the future system should take account of.
NOTE 1 Some aspects of the current context will persist, even if the system is highly novel.
NOTE 2 If a product concept is available or an existing product (such as a predecessor or a competitive product)
is used as the reference point for a new design, information in the current context of use will provide an outline of
the goals of the users of such a product, their tasks and the way in which the tasks are to be performed that will
be relevant for the intended context of use.
4.3.2 Intended context of use
The purpose of this description of the context of use is to provide a basis for designing the system,
product or service for the types of users who are intended to use it, the tasks that are to be undertaken
and the environment(s) in which it is intended to be used. It will incorporate the relevant aspects of the
existing context of use, if there is one.
The intended context of use of a system, product or service might include changes to the current context
of use.
EXAMPLE 1 A manufacturer of monitoring equipment, which is currently used by medical practitioners in
clinical settings, wishes to respond to the increasing demand for monitoring equipment that can be used by
patients, and their carers, in their own homes.
The context of use description should differentiate those components of the context of use that will
remain fixed and those components of the context of use that can be subject to change.
EXAMPLE 2 When designing an interactive whiteboard for a primary school, the teaching room is part of the
given technical environment, that can’t be changed. When designing a whole teaching room, the teaching room
can be designed in conjunction with the interactive whiteboard.
EXAMPLE 3 When designing a universal remote control, the products to be remote-controlled are part of the
given technical environment, that can’t be changed. When designing a remote control as part of a specific product,
the remote control is part of the system to be designed.
NOTE The intended context of use will be refined iteratively, taking account of an evolving understanding
of user and business needs and practical constraints including the development time and budget, until a realistic
range of user types and characteristics, environmental characteristics and tasks can be specified as part of user
requirements for which the system is required to achieve specified levels of usability.
4.3.3 Context of use specified as a part of user requirements
The context of use should be specified as a part of the user requirements specification to clearly
identify the conditions under which the requirements apply. Each relevant user, task and environmental
characteristic needs to be identified in order that the full range of contextual issues can be taken into
account in design.
6 © ISO/IEC 2014 – All rights reserved

This makes the scope of user requirements explicit by defining the contexts of use in which the system
product or service is required to achieve acceptable levels of usability (derived from the intended context
of use).
NOTE The specified context of use could be documented separately for use in conjunction with the user
requirements, or the relevant parts could be embedded in the user requirements.
Practical constraints could mean that the specified context of use is a subset of the originally intended
context of use, or the results of user research could result in a specified context of use that is wider than
the originally intended context of use.
4.3.4 Context of use of the implemented system, product or service
The description of the context of use of the implemented system, product or service is often more
detailed than that specified as part of the user requirements, for example including details of tasks and
user interactions. This additional information should be documented and should provide the basis for
the specific context(s) to be used for evaluation (4.4) and context of use information that is included as
part of the product description (4.5).
NOTE Any differences between the originally intended context of use, the context of use specified as part
of the user requirements, and the context of use of the implemented system need to be identified, in case these
differences could affect the usability of the system.
4.3.5 Context of use of the deployed system, product or service
The context of use of the system, product or service after deployment takes account of any new ways the
system is being used, and is typically determined by follow-up evaluation studies.
NOTE Follow-up evaluation studies can be aimed at determining if the system/product/service is meeting its
requirements or at determining how its use is evolving. For example, users often find ways of using the system to
carry out tasks not included in the original context of use, or user groups not previously anticipated might start
using the system. Differences between the specified context of use and the context of use of the deployed system
may require changes in the design to accommodate the changed context of use.
4.4 Context of use for an evaluation
Depending on the purpose of the evaluation, the description of the context of use that is part of an
evaluation report will be derived from the current context of use of an existing or implemented system,
product or service, the intended context of use or the context of use in which user requirements apply.
The context of use for evaluation needs to be described as part of the test scenarios for user based
testing, and for expert inspections when these are based on usage scenarios.
Some components of the context of use are not applicable for every type of evaluation (for example,
tasks are not used for some types of inspections).
NOTE 1 For user-based testing, the context of use for evaluation needs to reproduce the key aspects of a subset
of the context of use in order for evaluation results to be valid.
NOTE 2 A future CIF standard is intended to provide requirements and recommendations for the content of
usability evaluation reports. When published, the provisions of that standard will supersede the provisions in
this International Standard for the context of use to be used for evaluation.
4.5 Context of use information included in a product description
A product description intended for potential acquirers of interactive systems or users should include a
description of the intended context of use of the product.
NOTE The level of detail can vary, for example a description on the Web might contain more detailed
information than a printed product description.
© ISO/IEC 2014 – All rights reserved 7

5 Elements of a context of use description
5.1 General
5.1.1 Overview of requirements and recommendations
A detailed description of the context of use as described in 4.3 (current, intended, part of user
requirements, for the implemented system and for the deployed system) shall include all the elements
specified in 5.2 to 5.6.
Other types of context of use description described in Clause 4 (initial outline, used for evaluations,
used as part of a product description) only need to include the items indicated in the relevant columns
in Table 1.
Table 1 — Items that can be included in a context of use description
Context
Context
Initial Detailed of use as
of use as
outline of description part of a
part of an
the context of the context product
evaluation
of use of use descript-
report
tion
Subject of this context of use description (5.2)
The system, product, service or concept (for which the context of
shall shall shall shall
use is being described).
The purpose of the system, product, service or concept from the
perspective of the intended users of the context of use descrip- shall shall shall shall
tion.
Summary of any preconditions and/or constraints that affect the
shall
design of the interactive system.
User groups (5.3)
Identification of all the user groups. Separate description of each
shall shall shall[1] shall
distinctly different user group of the system, product or service.
Identification of other stakeholders who could have an impact on
shall shall
the use of the system, product or service
The relationship between each relevant user group and the sys-
shall
tem, product or service in terms of key goals and constraints.
The characteristics of each user group including any users whose
physical or psychological characteristics are at the extremes of shall shall[1]
the normal range.
Description of characteristics that are judged to be likely to
affect usability with an explanation of the basis for the judge- shall shall*
ment.
Goals (5.4)
A list of the goals of the different user groups described as
intended outcomes that people are trying to accomplish (includ- shall shall shall[2] shall
ing personal goals when relevant).
Any goals defined by the organization that provides and/or
shall
develops the interactive system that are likely to affect usability.
Any responsibilities that are judged to be likely to affect usability shall shall*
Tasks (5.5)
A list of tasks that are to be carried out by each user group to
shall shall*
achieve their goals.
For each task, the characteristics that are judged to be likely to
affect usability with an explanation of the basis for the judge- shall shall*
ment.
8 © ISO/IEC 2014 – All rights reserved

Table 1 (continued)
Context
Context
Initial Detailed of use as
of use as
outline of description part of a
part of an
the context of the context product
evaluation
of use of use descript-
report
tion
Environment(s) (5.6)
All actual or intended usage environments. shall shall*
Characteristics that are judged to be likely to affect usability. shall shall*
KEY
shall = required, blank = optional, * = if applicable,
[1] = the groups for which usability is being evaluated, [2] = the goals that are within the scope of the evaluation
The assessment of which characteristics are likely to affect usability should be based on human factors
knowledge and any previous experience with this type of system, product or service.
EXAMPLE It would not be necessary to include “sufficient electrical power” and “absence of vibrations” in
the description of the context of use of office software, even though vibrations would negatively affect mouse
pointing accuracy, and a power outage would stop the system altogether.
There is always some uncertainty about which characteristics of the context of use will definitely affect
usability and which will not. Therefore the extent of the description of the context of use is a matter of
judgement of the likelihood of the impact of each characteristic on usability. There are risks associated
with either underspecifying or overspecifying the context of use.
A description of the current context of use can include any identified problems that are observed or
reported (see 5.7).
5.1.2 Scope of the context of use
A context of use description can be of one instance of a context of use, or could include a range of contexts
of use in which the system, product or service is used, or in which it is intended to be used.
The description could also clarify how the context of use changes with time (for example, users’ expertise,
tasks and usage environments could change as users gain more experience with using a system).
5.2 Subject of the context of use description
5.2.1 System, product or service and its purpose
The system, product, service or concept (for which the context of use is being described) shall be
identified.
EXAMPLE 1 A new planning tool for ergonomic seating design is to be developed. There is no similar product
available, nor a detailed product specification. There is a concept of the product, focusing on the characteristics of
the product’s capabilities, design guidelines and innovations to be introduced in the product.
The purpose of the system, product, service or concept shall be described. This description shall be from
the perspective of the intended users of the context of use description (for example the development
team).
NOTE This provides the basis for identifying and describing the context of use. It is important to identify and
resolve any discrepancies between the intended or assumed purpose of the system, product or service, and the
actual usage identified as a result of user research.
© ISO/IEC 2014 – All rights reserved 9

The scope of what is the subject of design or evaluation will determine what needs to be described as
part of the context of use.
EXAMPLE 2 When designing or evaluating software for an existing model of cell phone, the software is the
subject of the context of use description and the physical cell phone is part of the technical environment that is
described in the context of use. When designing or evaluating a cell phone and its software, both the cell phone
and the software are the subject of the context of use description (so the cell phone would not be described as part
of the context of use).
5.2.2 Preconditions and constraints
In a detailed description of the context of use, preconditions or constraints that could affect the design
of the interactive system in a way that affects the usability shall be summarized in the description of
the subject of the context of use description and detailed in the relevant sections of the context of use
description (typically the organizational environment).
NOTE This can be regarded as the context of use of the design and development process (but with different
content to the context of use of a system, product or service).
The preconditions and/or constraints include design precondition and/or constraints, and organizational
preconditions and/or constraints. The former are imposed from sources other than the organization
developing the system, product or service whereas the latter are imposed by the organization itself.
Design preconditions and/or constraints (not imposed by the organization) include the following:
— Legal considerations (also jurisdiction);
— Available Information (e.g. existing knowledge, research findings);
— Business intelligence;
— Competition; and
— Seasonal determinants (e.g. number of users varies because of holiday season).
Development organizational preconditions and/or constraints (imposed by the organization) include
the following:
— Corporate design;
— Budget constraints;
— Time constraints for the duration of development and deployment;
— Strategic focus of business;
— Confidentiality policies; and
— Access to users.
5.3 User population
5.3.1 Users and other stakeholder groups
All the user groups (existing or intended users, or for an evaluation report the groups for which usability
is being evaluated) shall be identified.
Users include both:
— users directly interacting with the system; and
— users of the products or service provided by the system (indirect users).
10 © ISO/IEC 2014 – All rights reserved

Users can be classified as primary or secondary:
— primary users carry out the tasks that produce the intended output of the system; and
— secondary users carry out support tasks (such as administering or maintaining the system).
User groups can be differentiated by the tasks they are performing, their jobs, the environment in which
they are using the system, product or service, or in terms of their characteristics, capabilities or personal
style. If user groups have been identified but are not further documented for the system to be designed
or evaluated, these user groups should be stated.
In an initial outline or detailed description of the context of use, the context of use description shall
include other stakeholders who could have an impact on the use of the system, product or service (for
example managers of users).
EXAMPLE 1 A medical advice call centre is set up supported by an online system. The staff in the call centre
are users of the online system, and the callers receiving information are users of the service provided by the call
centre. Administrators monitoring use of the system would be secondary users. Other stakeholders include the
sponsors who might determine the care pathways to be followed.
NOTE 1 Applying a classification to the users of an interactive system provides information on which to base
user needs research and user requirements specification.
EXAMPLE 2 The users of a mobile phone are expected to be 80 % English speaking, 10 % French speaking and
10 % speakers of other languages. User needs research will have to address users with different native languages
and language specifics.
In a detailed description of the context of use, the relationship between each relevant user group and the
system, product or service shall be described in terms of key goals and constraints.
NOTE 2 Important aspects of the context of use can be communicated using personas.
5.3.2 The characteristics of each user group
5.3.2.1 General
In a detailed description of the context of use and a context use for evaluation, the characteristics of each
user group shall be documented.
The description of the characteristics shall include the range of actual or intended users including any
users whose physical or psychological characteristics are at the extremes of the normal range.
NOTE 1 The inclusion of information about the characteristics and capabilities of users with disabilities will
enable the design to take account of accessibility as well as usability objectives.
There are sometimes alternative ways of identifying user characteristics: either by describing the
specific psychological, social, physical and sensory characteristics, or by identifying groups with specific
tasks, job roles or demographics that are associated with particular characteristics.
NOTE 2 The characteristics of a user group can also be documented by exclusion, i.e. by describing who does
not belong to the user group.
EXAMPLE “All users who are aged between 18 and 25”.
5.3.2.2 Psychological and social characteristics
Any variations in psychological and social characteristics that are judged to be likely to affect usability
shall be described in a detailed description of the context of use and when applicable in an evaluation
report. An explanation of the basis for the judgement shall be provided. Any other variations in
psychological and social characteristics that could potentially affect usability may also be identified.
© ISO/IEC 2014 – All rights reserved 11

The following list gives examples of characteristics that could be relevant:
a) Long term characteristics:
— Cognitive abilities, including memory and reaction time;
— Cultural background, including conventions, stereotypes and mindsets;
— Language(s); and
— Level of literacy.
b) Task-related characteristics:
— Knowledge and skills.
User expectations and mental models based on their previous experience can affect knowledge and
skills. Even with a new product, people can have experience with similar prod
...