1 Introduction

Understanding user requirements and making them available as part of the development process is a key activity in human-centred design. It provides the basis for an appropriate design solution and its evaluation. Without proper statements of user requirements, the development process cannot be informed about what is required from the perspective of the use of the interactive system. Existing published approaches describe a process and the methods that can be used to gather information about users and their tasks, e.g. [1, 7, 23, 24]. For example, commonly used methods are contextual interviews, surveys, user needs analysis, card sorting, group task analysis, focus groups and field studies. But what are the resulting requirements that provide a basis for design and evaluation of the system from the perspective of its users, and how should these be specified? User requirements are often ignored.

There is extensive literature on what aspects of usability and user experience can be evaluated, but these are rarely expressed in advance as requirements for the design of the interactive system [1]. Cohelo emphasizes the need to specify ‘experience’ requirements relating to users’ expected perceptions and responses about a system or service in addition to task-related requirements and usability requirements [5].

When a new system is being commissioned, a general requirements analysis will take place which will include the business goals and the requirements of the identified stakeholders. One consideration is how user requirements will be differentiated from other types of requirements (e.g. market requirements and organizational requirements). A distinction that is often made is between functional requirements (which specify what the system should do) and non-functional (which specifies how well it does those things) [22, 26]. The non-functional requirements are often considered to include usability and other quality requirements [21]. However, the term “non-functional” is rather disparaging, and not well-defined, as “non-functional” requirements need functions to be specified to implement them. Quality requirements provide a more positive concept that is widely used, for example in ISO/IEC 25010 “System and software quality models”.

2 Standards Containing Guidance on User Requirements

The ISO standard for usability, ISO 9241-11 (1998) defined usability as the “extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use”. The standard contains an example of a usability requirements specification that defines the intended goals and context of use, and specifies measures and criterion levels for effectiveness, efficiency and satisfaction for the product under development. In 2001 an industry working group led by the US National Institute of Standards and Technology (NIST) published a Common Industry Format for documenting the results of a summative usability evaluation of effectiveness, efficiency and satisfaction [2] to enable the usability test results for products to be compared. This was subsequently adopted by ISO as ISO/IEC 25062 [16]. Although the document does not explicitly mention requirements, it implicitly provides a basis for specifying usability requirements. A parallel document, the Common Industry Specification for Usability—Requirements (2007) was subsequently developed by NIST for specifying usability requirements [25], highlighting the value of high-level quantitative requirements for effectiveness, efficiency and satisfaction. Based on this experience, the EU PRUE project successfully trialled the use of usability requirements in several companies [3].

3 What Are User Requirements?

There are now many papers and textbooks that explain how to collect user requirements (e.g. [1, 7, 23, 24]), but very little guidance about what information to include in user requirements, or how they should be specified.

There is also some confusion between the meaning of “user requirements” and “usability requirements”. For example, the Specification for Usability Requirements published by NIST [25] included in addition to the components of usability (effectiveness, efficiency and satisfaction), other types of requirements:

Design guidance

  1. (a)

    Design principles

  2. (b)

    Human factors and ergonomics

  3. (c)

    Style guides

  4. (d)

    Standards

Usability features

  1. (a)

    Accessibility

  2. (b)

    Understandability

  3. (c)

    Learnability

  4. (d)

    Operability

  5. (e)

    Attractiveness

Content and functions

  1. (a)

    Functionality

  2. (b)

    Content

  3. (c)

    Complete, accurate, up to date, style

  4. (d)

    Effectiveness (for learning)

  5. (e)

    Trust

  6. (f)

    Platform independence

These types of requirements would now be commonly regarded as “user requirements”.

4 First Draft of the Standard for User Requirements

An ISO joint working group, with experts from the systems and software engineering and ergonomics committees, has been developing a series of standard Common Industry Formats for the usability-related information that is produced and used during systems development. The documents that have been produced so far are:

  • ISO/IEC 25060 (2010) General framework for usability-related information

  • ISO/IEC 25063 (2014) Context of use description

  • ISO/IEC 25064 (2013) User needs report

  • ISO/IEC 25065 (2016) Evaluation report

ISO/IEC 25064 describes what should be included in a user needs report, and notes that “the user needs report is a critical input into specifying user requirements”. However, it does not explain how user requirements differ from user needs, and why an additional step of defining user requirements is necessary prior to implementation of the system. Some authors clearly differentiate between user needs and user requirements [7].

As long ago as 2010, the joint working group agreed a definition of user requirements: “requirements for use that provide the basis for design and evaluation of interactive systems to meet identified user needs”, and started work on the ISO/IEC 25065 standard for the contents of user requirements specifications. But, despite extensive discussion, development was terminated after two years because no consensus had been reached on the scope of user requirements and how to classify them. The project was restarted in 2014, positioning user requirements in relation to other types of requirements.

The initial draft for ballot (ISO/IEC CD 25065, issued in March 2017) explained that system requirements describe what the system has to do and to what extent it should do it, in order to meet each individual stakeholder requirement.

System requirements for the technical solution “specify, from the supplier’s perspective, what characteristics, attributes, and functional and performance requirements the system is to possess, in order to satisfy stakeholder requirements” (ISO/IEC 15288). Stakeholder requirements describe what is required from the viewpoint of each individual stakeholder group. Stakeholder requirements “express the intended interaction the system will have with its operational environment and that are the reference against which each resulting operational capability is validated” (ISO/IEC 15288), as illustrated by Fig. 1 from ISO/IEC 29148:2011.

Fig. 1.
figure 1

Stakeholder requirements in relation to system requirements.

Full size image

User requirements are one type of stakeholder requirement [8]. They provide a basis for system requirements from the viewpoint of the user of the interactive system.

According to the first draft, user requirements specify what a user shall be able to do and/or experience with the system in each particular context of use in order to satisfy one or more user needs. The purpose of user requirements was given as enabling the design of a system with which users could achieve levels of usability, accessibility, user experience and/or avoidance of harm from use (referred to as human-centred quality in ISO 9241-220). Human-centred quality objectives are high-level project objectives that can subsequently form the basis for more specific acceptance criteria for the system. Although they were included in a user requirements specification, they were labelled as objectives rather than requirements.

User requirements themselves were requirements for: a user to be able to recognize specific information in the interactive system (e.g. departure times of trains); or to be able to input a physical entity (e.g. coins) or information (user’s age); or to be able to select a physical entity or information (e.g. destination); or to have a specific perception or response (i.e. user experience, e.g. a sense of enjoyment).

Stakeholder requirements other than user requirements can be sources for user requirements as shown in Fig. 2 [8]. All stakeholder requirements are intended to serve as the basis for deriving system requirements.

Fig. 2.
figure 2

Types of stakeholder requirements leading to system requirements

Full size image

Legal requirements (also called regulatory requirements) are constraints set by legal entities (e. g. the Government or a government institution). They are contained in laws and other regulatory documents including harmonized standards. Legal requirements often enforce processes within specific types of organizations. For example: “Section 508 requires that when federal agencies develop, procure, maintain, or use electronic and information technology, federal employees with disabilities have access to and use of information and data that is comparable to the access and use by federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency.” (Section 508 in the USA).

Market requirements are set by manufacturers and describe which capabilities the system shall possess or meet, so that purchasers, or purchase decision makers, buy the product (or in case of free-of-charge products decide to use the product). For example: “The smart phone shall be cheaper than the equivalent model from a major competitor”.

Organizational requirements are requirements on the behaviour of the organization and on the humans within organizations that describe how people within the organization have to act when performing their tasks. For example: “The physician shall wear gloves during surgery” or “The sales representative shall get quotations higher than 100.000 EUR signed off by the sales director before sending them to the client”.

User requirements on the system output prescribe the required outputs of the interactive system and the attributes of theses outputs (including the accuracy) that these outputs shall have (where applicable). For example: “The invoice produced by the system shall contain the contract number that it relates to”, or “The hard-boiled egg produced by the system shall not contain any liquid egg yolk”).

User requirements are typically included as part of a stakeholder requirements specification document as described in ISO/IEC/IEEE 29148 (Requirements Engineering).

Figure 3 from the draft illustrates the suggested relationship between user requirements and other information items related to human-centred design.

Fig. 3.
figure 3

The interrelationship between user requirements and other information items related to human-centred design.

Full size image

5 Second Draft of the Standard for User Requirements

The second draft, ISO/IEC CD 25065.2, was issued in January 2018. Changes include:

  • The interpretation of user requirements has been broadened from what a user shall be able to do and/or experience with the system to include requirements for “use-related qualities” (such as the usability or accessibility) with which intended outcomes are achieved using the interactive system (see Sect. 5.3).

  • The standard focusses on the content of user requirements specifications, removing the explanation of the role of user requirements in systems development (as this is beyond the intended purpose of the standard).

5.1 Content of a User Requirements Specification

The second draft states that the following information should be included in a user requirements specification:

  • Interactive system for which the user requirements are specified.

  • Any constraints in terms of factors known to limit the freedom of design and implementation of solutions to satisfy the user requirements and the interactive system to be developed. These include technical, budget, time, legal, environmental, social and organizational constraints. (This differs from a view commonly held by developers that user requirements are constraints on the freedom of design and implementation of solutions to satisfy the functional requirements.)

  • The overall context of use: the users, goals and tasks, resources, and environment for use of the interactive system (this can be in a separate document). It specifies the contexts of use in which the system is required to be usable.

  • Goals (intended outcomes) and the tasks to be supported. Goals are the intended outcome(s) to be achieved using the interactive system. 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.

  • User requirements

    • User-system interaction requirements (see Sect. 5.2).

    • Use-related quality requirements (see Sect. 5.3).

Each user requirement should include:

  • The user group(s) to which the user requirement applies.

  • The goal(s) or task(s) to which the user requirement applies.

  • The condition(s) (including relevant aspects of the context of use) under which the user requirement applies.

    • Design guidance to be applied (such as a style guide).

    • If appropriate, recommendations for design solutions emerging from the user requirements.

5.2 User-System Interaction Requirements

User-system interaction requirements specify the outcome of use, in terms of required interaction, e.g. to be able to:

  • Recognize specific information in the interactive system (e.g. departure times of trains).

  • Input a physical entity (e.g. coins) or information (user’s age).

  • Select a physical entity or information (e.g. destination).

  • Receive (take away) a physical entity (e.g. the printed ticket) or information from the interactive system (an electronic receipt).

The following syntax is suggested to phrase use-related quality requirements: “With the <interactive system> the <user group> shall be able to achieve <outcome in terms of interaction> under <condition(s)> (if applicable).”

5.3 Use-Related Quality Requirements

Use-related quality requirements specify criteria for components of use-related quality:

  • Effectiveness (e.g. extent to which the alarm is set correctly).

  • Efficiency (e.g. time taken to set the alarm).

  • Satisfaction (e.g. user feels secure that he will wake up as intended).

  • Other components of use-related quality (e.g. accessibility, user experience, avoidance of harm from use).

These requirements can be at the level of the overall task outcome (e.g. setting an alarm on a clock) or when appropriate be for elements of user-system interaction (e.g. the effectiveness or efficiency of inputting or selecting information).

5.4 Structuring User Requirements Within a User Requirements Specification

Use-related quality requirements can apply to use of the whole system or product, as well as to the achievement of sub-goals and sub-tasks. User-system interaction requirements typically specify interaction at the lowest level of tasks or sub-tasks, which describe required interaction with the user interface. User requirements should be structured by the goals and tasks to be supported by the interactive system rather than by the characteristics of the system.

6 Conclusions

6.1 Benefits

ISO/IEC 25065 helps differentiate two concepts that are often confused: user requirements and user needs (user needs are already described in ISO/IEC 25064).

Reaching an agreement on the meaning and content of user requirements has not been easy. The current draft identifies the information to be included in a specification of requirements for the user interactions with, and the interfaces of, interactive systems. This includes two important types of user requirements at the detailed level of user-system interaction: (a) what requirements does a user have to be able to recognize, select, input or receive information or a physical entity? And (b) are there any quality requirements (effectiveness, efficiency, satisfaction, user experience, accessibility or avoidance of harm from use), for any of these detailed elements of interaction, or as evidence of achievement of higher level goals? Specification of quality requirements is likely to be reserved for aspects of interaction where particular levels of quality (such as efficiency, accessibility or pleasure from use) are important for the success of the system and the specification (and potential evaluation) of these requirements is necessary to ensure that they are achieved.

Uniformity and precision in the definition of user requirements is beneficial in the specification of requirements in both formal and less formal development environments. ISO/IEC 25065 helps to align user requirements with the terminology and processes used in standards such as ISO/IEC 15288 and 29148 which are used to specify requirements, for large, critical and complex systems.

6.2 Types of User Requirements

The focus of the current draft of ISO/IEC 25065 is on two types of user requirements: user-system interaction requirements, and use-related quality requirements for task and sub-task outcomes. There are other types of requirements related to use that are frequently identified within design activities, but appear to be outside the scope of either type described in the standard, such as:

  • Requirements for the project that would make it possible for the project to develop systems with human-centred quality (such as the plans, activities, methods, staff competence and resources).

  • User requirements for the enabling systems that realise, operate and maintain the system of interest, (e.g. production, installation, training, maintenance, support/supply/inform, management/command/governance etc.).

  • User requirements for properties of the system that go beyond a specific user interaction (e.g. “When using the transport system, the user shall be able to use the same ticket when transferring from metro to bus”).

  • User requirements for functionality (e.g. “The user shall be able to specify a keyboard shortcut for every menu item”).

  • User requirements specifically relating to the context of use (e.g. “The user shall be able to use the product in the dark”).

It would be useful to clarify how these requirements relate to the scope and content of the current standard, in order to either refine this standard and/or identity the need for further standardisation relating to user requirements. This might be within the CIF series of standards for stating usability-related information, or in the ISO 9241-200 series of standards that address the processes, activities and methods used to generate and transform that information.

6.3 Participation in Standards Development

If you would like to contribute to the future development of this or other standards related to usability [4], or to comment on drafts, you can either do this via your national standards body [10], or if you are a member of one of the ISO TC159/SC4 liaison organisations [11] such as UXPA [27] you can participate through the liaison organisation.