Iso 25065-2019
Iso 25065-2019
Iso 25065-2019
STANDARD 25065
First edition
2019-05
Reference number
ISO 25065:2019(E)
© ISO 2019
ISO 25065:2019(E)
Contents Page
Foreword......................................................................................................................................................................................................................................... iv
Introduction...................................................................................................................................................................................................................................v
1 Scope.................................................................................................................................................................................................................................. 1
2 Normative references....................................................................................................................................................................................... 1
3 Terms and definitions...................................................................................................................................................................................... 1
3.1 Terms related to user requirements...................................................................................................................................... 2
3.2 Terms related to interactive systems.................................................................................................................................... 4
3.3 Terms related to the concept of usability.......................................................................................................................... 5
4 Conformance.............................................................................................................................................................................................................. 6
5 User requirements specification.......................................................................................................................................................... 6
5.1 General............................................................................................................................................................................................................ 6
5.2 Relationship between user requirements specification and stakeholder
requirements specification............................................................................................................................................................ 7
5.3 Types of user requirements.......................................................................................................................................................... 7
5.3.1 General...................................................................................................................................................................................... 7
5.3.2 User-system interaction requirements......................................................................................................... 7
5.3.3 Use-related quality requirements...................................................................................................................... 7
6 Content elements of a user requirements specification.............................................................................................. 8
6.1 Overview on the content elements......................................................................................................................................... 8
6.2 Interactive system for which a set of user requirements are specified.................................................. 8
6.2.1 Identification of interactive system.................................................................................................................. 8
6.2.2 Predecessors or previous versions of the interactive system (if applicable)............... 8
6.3 Constraints on design......................................................................................................................................................................... 8
6.4 Context of use for which the user requirements apply......................................................................................... 9
6.5 Goals and tasks to be supported............................................................................................................................................... 9
6.6 User requirements............................................................................................................................................................................. 10
6.6.1 Stating user requirements..................................................................................................................................... 10
6.6.2 Information to be provided with each user requirement........................................................... 12
6.6.3 Structure for presenting the user requirements................................................................................ 14
6.7 User interface design guidance to be applied............................................................................................................ 15
Annex A (informative) Example of content elements from a user requirements specification............16
Bibliography.............................................................................................................................................................................................................................. 20
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso
.org/iso/foreword.html.
This document was prepared jointly by Technical Committee ISO/TC 159, Ergonomics, Subcommittee
SC 4, Ergonomics of human-system interaction and Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 7, Software and systems engineering.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
Introduction
Specifying user requirements in a consistent manner will assist those developing and acquiring
interactive systems that are usable. The term "user requirements" is used in this document to refer
to user-system interaction requirements (that specify the required interaction to achieve intended
outcomes) and use-related quality requirements (expressed in terms of effectiveness, efficiency and
satisfaction). It describes a set of content elements for user requirements specifications as part of a
human-centred approach to design of an interactive system. A common industry format for a user
requirements specification is intended to assist human-centred design teams in specifying user
requirements for an interactive system.
The Common Industry Format (CIF) for usability is described in ISO/IEC TR 25060 and is part of the
SQuaRE series (ISO/IEC 25000–ISO/IEC 2509x) on systems and software product quality requirements
and evaluation.
Usability as used in the CIF standards refers to effectiveness, efficiency, and satisfaction as defined in
ISO 9241-11, where it is defined as an outcome of use, rather than as a product quality which is an
alternate use of the term also provided in ISO/IEC 25010.
CIF standards published or planned for include the following information items:
— usability test reports (see ISO/IEC 25062);
— context of use description (see ISO/IEC 25063);
— user needs report (see ISO/IEC 25064);
— user requirements specification (this document);
— usability evaluation report (see ISO/IEC 25066);
The CIF standards are part of the "Extension Division" of the ISO/IEC 25000 SQuaRE series. Table 1
presents an overview of the structure and the contents of the SQuaRE series.
Figure 1 illustrates the interdependence of these CIF documents with the outputs of human-centred
design activities described in ISO 9241-210 as well as the corresponding system lifecycle processes
described in ISO/IEC/IEEE 15288. Standards listed in bold represent CIF process outputs. The figure
depicts the outputs of the activities as a set of intersecting circles. The circles overlap to represent that:
— human-centred design aims at satisfying user needs; and
— 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
endpoint, or linear process intended.
The human-centred design approach of ISO 9241-210 focuses on ensuring that systems are usable.
Human-centred design is enabled by the identification and communication of all of the relevant types of
information
NOTE ISO 9241-220 broadens the objectives of human-centred design to human-centred quality: usability,
accessibility, user experience and avoidance of harm from use. Human-centred quality can be achieved by
applying human-centred design throughout the lifecycle.
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). The user needs report
is an intermediate deliverable that links the context of use description (ISO/IEC 25063) containing
information about the users, their tasks and the organizational and physical environment, to the user
requirements. User requirements are, in turn, documented in the user requirements specification
(ISO 25065). These information items are developed as part of the stakeholders requirements definition
process described in ISO/IEC 15288.
The "designed solutions" activity focuses on designing user interaction that meets user requirements.
This activity takes place during the architectural design, implementation, and integration processes
described in ISO/IEC/IEEE 15288 and produces the information items "user interaction specification"
and the "user interface specification".
The "evaluation results" 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 developed and can produce various types of evaluation reports. Usability
data, such as that described in ISO/IEC 25062, can support the ISO/IEC/IEEE 15288 validation process,
which confirms that the system complies with the stakeholders requirements.
1 Scope
This document provides a framework and consistent terminology for specifying user requirements. It
specifies the common industry format (CIF) for a user requirement specification including the content
elements and the format for stating those requirements.
NOTE 1 A user requirements specification is the formal documentation of a set of user requirements, which
aids in the development and evaluation of usable interactive systems.
The content elements of a user requirements specification are intended to be used as part of
documentation resulting from the activities specified in ISO 9241-210, and from human centred design
processes, such as those in ISO 9241-220.
This document is intended to be used by requirements engineers, business analysts, product managers,
product owners, and people acquiring systems from third parties.
The CIF series of standards addresses usability-related information (as described in ISO 9241-11 and
ISO/IEC TR 25060).
NOTE 3 In addition to usability, user requirements can include other perspectives, such as human-centred
quality introduced in ISO 9241-220, and other quality perspectives presented in ISO/IEC 25010, ISO/IEC TS 25011,
and ISO/IEC 25030.
NOTE 4 While this document was developed for interactive systems, the guidance can also be applied in other
domains.
This document does not prescribe any kind of method, lifecycle or process. The content elements of a
user requirements specification can be used in iterative development which includes the elaboration
and evolution of requirements (e.g. as in agile development).
2 Normative references
There are no normative references in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
Note 2 to entry: This definition is used in this document because it explicitly differentiates between user needs
and user requirements which the ISO/IEC/IEEE 12207 definition does not explicitly differentiate.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3431/2, modified — The Notes to entry have been added.]
3.1.2
quality requirement
requirement (3.1.1) for quality properties or attributes of a product, data or service that satisfy needs
which ensue from the purpose for which that product, data or service is to be used
[SOURCE: ISO/IEC DIS 25030:2018, 4.16, modified — Note 1 to entry has been deleted.]
3.1.3
user
person who interacts with a system, product or service
Note 1 to entry: Users of a system, product or service include people who operate the system, people who make
use of the output of the system and people who support the system (including providing maintenance and
training).
Note 2 to entry: This term corresponds to the definition "direct user" that is found in ISO/IEC 25010.
[SOURCE: ISO 9241-11:2018, 3.1.7, modified — Note 2 to entry has been added]
3.1.4
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
Note 1 to entry: Stakeholders can include: users, purchasers, systems owners or managers and people who are
indirectly affected by the operation of a system, product or service.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.44, modified — The Example has been removed, Note 1 to
entry has been replaced and Note 2 to entry has been added.]
3.1.5
user group
subset of intended users (3.1.2) who are differentiated from other intended users by characteristics of
the users, tasks (3.1.7) or environments that can influence usability (3.3.1)
[SOURCE: ISO 9241-11:2018, 3.1.8]
3.1.6
context of use
combination of users (3.1.2), goals (3.1.6) and tasks (3.1.7), resources, and environment
Note 1 to entry: The "environment" in a context of use includes the technical, physical, social, cultural and
organizational environments.
Note 2 to entry: This can apply to an existing context of use or an intended context of use.
[SOURCE: ISO 9241-11:2018, 3.1.15, modified — Note 2 to entry has been added]
3.1.7
goal
intended outcome
[SOURCE: ISO 9241-11:2018, 3.1.10]
3.1.8
task
set of activities undertaken to achieve a specific goal (3.1.6)
Note 1 to entry: These activities can be physical, perceptual and/or cognitive.
Note 2 to entry: While goals are independent of the means used to achieve them, tasks describe particular means
of achieving goals.
EXAMPLE 2 An account manager (user) needs to know the number of invoices received and their amounts
(prerequisite), in order to complete the daily accounting log (goal) as part of monitoring the cash flow (context
of use).
Note 1 to entry: A user need is independent of any proposed solution for that need.
Note 2 to entry: User needs are identified based on various approaches including interviews with users,
observations, surveys, evaluations, expert analysis, etc.
Note 3 to entry: User needs often represent gaps (or discrepancies) between what should be and what is.
Note 4 to entry: User needs are transformed into user requirements (3.1.10) considering the context of use, user
priorities, trade-offs with other system requirements and constraints.
[SOURCE: ISO/IEC 25064:2013, 4.19, modified — The expression "intended outcome" has been changed
to "goal" in Examples 1 and 2.]
3.1.10
user requirements
set of requirements (3.1.1) for use that provide the basis for design and evaluation of interactive systems
(3.2.1) to meet identified user needs (3.1.8)
Note 1 to entry: User requirements are derived from user needs and capabilities in order to allow the user to
make use of the system in an effective, efficient, safe and satisfying manner.
Note 3 to entry: User requirements include user-system interaction requirements (3.1.11) and use-related quality
requirements (3.1.12).
Note 4 to entry: In software engineering terms, user requirements include both "functional" and "non-functional"
requirements derived from user needs and capabilities.
Note 2 to entry: This definition emphasizes that the user interacts with the system. An interactive system
provides feedback to user input and initiates further actions within the system or by other systems as required.
[SOURCE: ISO 9241-11:2018, 3.1.5, modified — Note 2 to entry has been added.]
3.2.2
user interface
set of all the components of an interactive system (3.2.1) (software or hardware) that provide information
and controls for the user (3.1.2) to accomplish specific tasks (3.1.7) with the interactive system (3.2.1)
[SOURCE: ISO 9241-220:2019, 3.43]
3.2.3
user-system interaction
exchange of information between a user and an interactive system via the user interface to complete
the intended task
[SOURCE: ISO/IEC TR 25060:2010, 2.22, modified — The term has been modified from “user interaction”
to “user-system interaction”. The Notes to entry have been removed.]
3.2.4
user interface design guidance
design guidance
principle, requirement (3.1.1), recommendation or established convention for designing the user
interaction and/or the user interface
Note 1 to entry: Specific requirements, recommendations or established conventions are also referred to as “user
interface guidelines”.
Note 2 to entry: Principles, requirements and recommendations are published in various sources including the
ISO 9241 series and apply across user interface platforms.
Note 3 to entry: “Established conventions” include rules published by suppliers of the user interface platforms
such as “Windows” or “Mac OS”.
Note 4 to entry: User interface design guidance is sometimes referred to as user interface requirements.
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.7, modified — In Note 1 to entry, "may" has been changed
to "can".]
Note 2 to entry: The word "usability" is also used as a qualifier to refer to the design knowledge, competencies,
activities and design attributes that contribute to usability, such as usability expertise, usability professional,
usability engineering, usability method, usability evaluation, usability heuristic.
3.3.5
accessibility
extent to which products, systems, services, environments and facilities can be used by people from
a population with the widest range of user needs (3.1.8), characteristics and capabilities to achieve
identified goals (3.1.6) in identified contexts of use (3.1.5)
Note 1 to entry: Context of use includes direct use or use supported by assistive technologies.
Note 2 to entry: A complete system includes all of the associated equipment, facilities, material, computer
programs, firmware, technical documentation, services and personnel required for operations and support to
the degree necessary for self-sufficient use in its intended environment.
Note 3 to entry: A system can be composed of a product, service, built environment or combination thereof,
and people.
Note 2 to entry: The “customer” is a user, and does not necessarily have a financial relationship.
4 Conformance
A user requirements specification conforms to this document if it contains all user requirements
identified for the interactive system and meets the requirements on the content elements specified in
Clause 6.
NOTE 1 A user requirements specification does not have to be separated from other specifications.
NOTE 2 User requirements can be documented in various media, including: paper, electronic documents, and
requirements management systems.
5.1 General
A user requirements specification provides a basis for designing and evaluating the interaction with
user interfaces of interactive systems. It can also serve as one of the sources for specifying system
requirements. The CIF for user requirements, as specified in this document, provides a format for
specifying a set of user requirements and the necessary related information.
5.3.1 General
User requirements are requirements for use that provide the basis for design and evaluation of
interactive systems to meet identified user needs. User requirements can be met by various system
designs. User requirements do not prescribe a specific system solution, they prescribe the outcomes to
be achieved. User requirements are not requirements on the users.
NOTE A user requirement can be expressed as "With the system, the user shall be able to… ", while a system
requirement can be expressed as "The system shall…".
User-system interaction requirements specify the required interactions to achieve the intended
outcomes of use, expressed in terms of what the users are enabled to do.
Use-related quality requirements specify the intended outcomes of use of the interactive system
and associated quality criteria in terms of the effectiveness, efficiency, satisfaction or other types of
qualities to be achieved when using the interactive system.
NOTE 1 Use-related quality requirements can exist for the whole system, for any goal, task or sub-task. User-
system interaction requirements typically exist at the lowest level of tasks or sub-tasks.
NOTE 2 Use-related quality requirements can be used as criteria for systems acceptance.
NOTE 3 Use-related quality requirements, described in this document, relate to usability. Use-related
quality requirements can also relate to: accessibility, avoidance of harm from use, and other aspects of use (see
ISO 9241-11, ISO 9241-220 and ISO/IEC 25010).
6.2 Interactive system for which a set of user requirements are specified
The specific interactive system (including version, if applicable) shall be identified as part of a user
requirements specification.
NOTE It is important that this identification has sufficient precision to distinguish it from any other
interactive systems.
Any predecessors or previous versions of the interactive system should be identified in the user
requirements specification.
Available previous specifications of user requirements should be identified and referenced.
Goals are the intended outcome(s) of use. They include the overall goals of use of the interactive
systems, and sub-goals of use. Goals are independent of the means used to achieve them. Goals focus on
what is to be achieved without necessarily specifying criteria (such as levels of effectiveness, efficiency
or satisfaction).
Tasks consist of one or more activities undertaken to achieve a goal. Different combinations of activities
can provide different ways of achieving the same goal and can lead to different levels of usability.
NOTE 1 Tasks of users are not the same as organizational procedures that describe how information and
resources are interchanged within and across departments within an organization. Organizational procedures
include the users’ tasks. Tasks are described in terms of the activities undertaken by users to achieve an intended
outcome.
Goals and tasks can be decomposed into sub-goals and subtasks that can include intermediate outcomes.
NOTE 2 Sub-goals and intermediate outcomes are also identified as part of the context of use.
NOTE 3 The goals and tasks to be supported are based on goals and tasks identified in the context of use but
can be modified based on identified user needs.
EXAMPLE
NOTE 4 There are different approaches to structuring goals and/or tasks which can be used. However, it is
important that goals and tasks are structured in a consistent manner that is suitable for the reader of the user
requirements specification.
User requirements shall be described from the perspective of outcomes of use, rather than the
perspective of the system.
NOTE 1 Describing user requirements from the perspective of outcomes of use enables validation that users
are able to do what is needed and that they experience the system in the intended ways.
NOTE 2 An intended outcome of use can be achieved during interaction or after the interaction has stopped.
EXAMPLE An outcome is achieved after use when one arrives at the intended destination, having driven by
car. An outcome is achieved during use when the driver enjoys driving the car.
User-system interaction requirements relate to specific outcomes to be achieved when completing a task.
1) <to recognize> addresses required information and can be substituted by other verbs, for example: “to see”,
“to read”, “to hear”, “to retrieve” or “to perceive” by other means (e.g. vibration), etc.
2) <to select> addresses required choices and can be substituted by other verbs, for example: “to choose which
other individuals or organizations have access to specific information”, “to reserve an available flight”, “to
confirm reception of a letter”, “to change the pick-up time for a rental car”, etc.
3) <to input> addresses required information and/or resources that the user shall be able to input and can be
substituted by other verbs, for example: “to enter”, “to submit”, “to place”, “to put in (in)to the interactive
system". In the case of hardware, this can also include "to place” (e.g. 3 pizza plates into the dish washer).
4) <to receive> addresses a system output that the user shall be able to take away and can be substituted by
other verbs, for example: "to share", "to take out", "to print" or "to export", etc.
NOTE 3 The order of the phrasing of elements in the requirement depends on the grammatical structure of
the language in which it is presented. For example, to set the context for the requirement, English or Japanese
phrasing usually has the conditions at the start of a sentence.
EXAMPLE A user requirement for the task of stabilizing a patient during an emergency is worded “UR 7.3:
With the monitor the emergency room doctor shall be able to recognize if the heart rate of the patient is rising,
remaining stable or decreasing during an emergency”, rather than “The system shall display the heart rate of the
patient”.
NOTE 4 The <Conditions> under which a user requirement applies can include any components of the context of
use, e.g. a specific location, order in which things are done, dependencies on other components of the context of use.
Use-related quality requirements can apply to all contexts of use or to specific aspects of the context of
use of the system, such as achieving specific outcomes or carrying out specific tasks.
Statements of use-related quality requirements shall include the following elements:
a) if there is more than one user group, the user group(s) that the user requirement applies to;
NOTE 2 Within use-related quality requirement statements that address satisfaction, the expression “be
satisfied with” can be replaced by the terms that are the most suitable to precede the intended outcome.
NOTE 3 In this syntax, the goal or task can be identified in the <identifier> (see 6.6.3).
NOTE 4 The order of the phrasing of elements in the requirement depends on the grammatical structure of
the language in which it is presented. For example, to set the context for the requirement, English or Japanese
phrasing usually has the conditions at the start of a sentence.
NOTE 5 If the requirement applies across the whole user population, the term “users” can replace the name of
the user group(s).
NOTE 6 Outcome can be specified across or within tasks to be supported with the interactive system.
EXAMPLE 1 A use-related quality requirement addressing satisfaction is, "80 % of all potential users of the
ticket machine shall prefer the use of the ticket machine to the use of the ticket counter".
EXAMPLE 2 A use-related quality requirement addressing effectiveness is, "With the ticket machine, 95 % of
users shall be able to buy the cheapest ticket to a location within 30 seconds".
NOTE 8 <Conditions> under which a user requirement applies can include any components of the context of
use, e.g. location, order in which things are done, dependencies on other components of the context of use.
Each user requirement shall have an identifier that uniquely identifies it as a user requirement and
differentiates it from other requirements.
NOTE Identifiers typically provide a reference to the task or location within a structure of goals and tasks.
The structure of goals and tasks applies to the intended context of use.
EXAMPLE UR 7.1.3 is "User requirement" No. 3 for supported sub-goal 1 within goal 7.
Wherever user needs have been identified leading to a user requirement, information about the user
need(s) and associated context of use should be stated or referenced.
NOTE ISO/IEC 25064 provides a common industry format for user needs reports.
EXAMPLE Table 2 gives examples for user requirements with the identified user needs and context of use
that they are based on.
Table 2 — Examples for user requirements in relation to the relevant part of the context of use
and the identified user needs
Interactive system Reference to the con- Resulting user require-
Identified user need(s)
to be designed text of use ment(s)
Airline booking People who book flights The person booking a flight a) With the system, the
system often have the choice of needs to know, which alter- user shall be able to
various airports that are native flights are available input his home address
around the target destina- from his home location to his and the target address
tion. It is not always clear target location, in order to (rather than the target
which flight goes to which choose a flight. airport) for his flight
airport. journey when booking a
flight online.
Where other sources of information (e.g. test results, design guidance, human-factors data, customer
complaints) have been identified leading to a user requirement, this information should be stated or
referenced.
If a user requirement has been modified after it was stated within the user requirements specification,
the version history of the requirement shall be provided for each modified user requirement.
NOTE Version history can include the rationale for the change.
If appropriate, the importance to the users should be provided for each user requirement.
6.6.2.3.3 Status
If appropriate, the status of the requirement should be provided for each user requirement.
EXAMPLE The status of a user requirement for a particular system include:
c) accepted/rejected/deferred;
e) implemented/not implemented.
If applicable, references should be made to other requirements in order to see relevant dependencies
and/or conflicts.
User requirements shall be structured by the goals (the intended outcomes of use) and the tasks to be
supported by the interactive system, not by potential components of the system.
NOTE 1 The following structure illustrates how user requirements can be structured based on tasks:
Goal
All tasks
— User requirement 1
— User requirement 2
— …
— User requirement n
Task 1
— …
Subtask 1.1
Subtask 1.2
Task 2
Subtask 2.1
Subtask 2.2
Annex A
(informative)
A.1 General
This annex provides examples of excerpts from the content elements of a user requirements
specification to help illustrate Clause 6.
A.2 Identification of the interactive system for which user requirements are
specified
System: Automated entry checking and authorisation kiosk for an immigration processing system,
hereinafter referred to as an immigration kiosk.
A.4 Reference to the overall context of use for the interactive system
Reference: See document “Context of use for immigration processing, Version 7.4” available at <URL>
A.5.2 Example of one goal and the decomposition and associated content elements
Interactive system for which user requirements are to be specified: an automated entry checking and
authorization kiosk.
Table A.1 shows one potential task involved in achieving these. There are other potential tasks that are
not included in this example.
Table A.1 — Example of a goal, task, associated preconditions and subtasks for a user group
Goal(s) The traveller has entered the country.
Task Complete the immigration process using the automated entry checking and
authorization process.
User group(s) and their char- Air passengers travelling to visit a foreign country for a limited period of time.
acteristics
Characteristics: Age range 16–90 with characteristics that include the
5th–95th percentiles for the relevant sensory, physical and cognitive abilities.
People with disabilities are also included, for example, wheelchair users,
blind users and users who are deaf.
Pre-condition(s) The users:
— are 16 years or older;
— U-QR1 With the immigration processing system, the average time that air passengers entering the country
take to pass through immigration shall be half the average time taken currently.
— U-QR2 With the immigration processing system, arriving passengers shall experience screening at current
levels of security and safety.
— UR-Q3 The immigration processing system shall be accessible to the widest possible range of users (including
people in wheel chairs and persons with smaller stature).
b) User requirements by tasks to be supported for air passengers entering the country:
1) User requirements for Task 1: Entering a foreign country via immigration using an automat-
ed entry checking and authorization kiosk
U-QR1.1 95 % of all users shall be able to successfully complete the authorization process
without assistance.
U-QR1.2 When the user is in front of an available kiosk, the user shall be able to complete the
authorization process in 2 minutes on average.
i) Subtask 1.1 Identify whether eligible to use the automated entry checking and authori-
zation system
U-IR 1.1.1 With the system, the user shall be able to recognize that the automated entry
checking and authorization kiosk is present, once having reached the immigration hall.
U-QR 1.1.1 With the system, at least 95 % of eligible users shall recognize that they are
eligible to use the automated system, once having reached the immigration hall.
U-IR 1.2.1 For each available kiosk, the user shall be able to recognize whether it is
ready for use or not.
U-IR 1.3.1 With the system, the user shall be able to recognize which activity needs to
be performed next.
U-IR 1.4.1 With the system, the user shall be able to recognize how to place the pass-
port, so it can be read by the system.
U-IR 1.4.2 With the system, the user shall be able to place the passport, so it can be
read by the system.
U-QR 1.4.1 95 % of users shall correctly insert their passport within 15 seconds.
U-IR 1.5.1 With the system, the user shall be able to recognize how to position himself
to initiate the facial recognition.
U-IR 1.5.2 With the system, the user shall be able to position himself to initiate the
facial recognition.
U-QR 1.5.3 With the system, 95 % of users shall correctly position themselves within
10 seconds
vi) Subtask 1.6 Receive confirmation that authorization was granted or that manual
checking is required
U-IR 1.6.1 With the system, the user shall be able to receive record confirming that the
process has been successfully completed or that manual checking is required.
U-IR 1.6.2 If authorization is not granted by the system, the user shall be able to recog-
nize what to do next.
U-IR 1.6.3 If authorization is granted, the user shall be able to recognize how to pro-
ceed to the country.
Bibliography
ICS 13.180; 35.080
Price based on 20 pages