CPUX-UR Curriculum - uxqb.org · 1.4 User requirements as a separate requirements category within...

CPUX-UR Curriculum

Certified Professional for Usability and User Experience – User Requirements Engineering

Version 1.3 EN: 7 June 2016

Published by: UXQB e. V. Contact: [email protected] www.uxqb.org

Authors: Thomas Geis, Knut Polkehn, Rolf Molich, Oliver Kluge

CPUX-UR Curriculum and Glossary Copyright 2016, UXQB e.V. of 84

Table of Contents

Introduction ............................................................................................................................................ 3

Preliminary notes ................................................................................................................................. 3

Structure of this document .................................................................................................................. 4

What does the CPUX-UR certificate confirm? .................................................................................... 5

Learning objectives and proficiency levels .......................................................................................... 5

Overview of learning units, main terms / concepts, methods and deliverables .................................. 7

1 Introduction to context of use analysis ................................................................................ 10

1.0 Terms in this chapter ............................................................................................................ 10

1.1 Learning unit “Differentiate between requirements and solutions” ....................................... 11

1.2 Learning unit “Differentiate between stakeholder requirements and system requirements” 12

1.3 Learning unit “The components of the context of use” ......................................................... 12

1.4 Learning unit “User requirements as a separate requirements category within the stakeholder requirements” .................................................................................................... 14

2 Plan context of use analyses ................................................................................................ 15


2.1 Learning unit “Identify the rationale and goals for the context of use analysis” ................... 16

2.2 Learning unit “Determine the approach for context of use analysis” .................................... 17

3 Gather and document context of use information .............................................................. 19


3.1 Learning unit “Select and recruit users for the gathering of context of use information” ..... 20

3.2 Learning unit “Prepare and execute the gathering of context of use information” ............... 20

3.3 Learning unit “Document context of use descriptions from context of use information in an analysable and accessible way” ........................................................................................... 22

4 Identify user needs in context of use information .............................................................. 23


4.1 Learning unit “Systematically identify and formulate user needs” ........................................ 23

5 Derive and structure user requirements from user needs ................................................. 26


5.1 Learning unit “Systematically transform user needs into user requirements” ...................... 26

5.2 Learning unit “Appropriately structure user requirements” ................................................... 29

6 Consolidate user requirements ............................................................................................. 30


6.1 Learning unit “Consolidate and prioritise user requirements with users” ............................. 30

6.2 Learning unit “Determine the implementation priority for user requirements together with project members” ................................................................................................................. 31

7 Cooperation between user requirements engineers and other roles / disciplines ......... 32


7.1 Learning unit “As a user requirements engineer, become a successful provider for other roles” ..................................................................................................................................... 33

8 Glossary .................................................................................................................................. 34

9 Annex 1 – Model seminar ...................................................................................................... 81

9.1 Concept of the seminar ........................................................................................................ 81

9.2 Timetable for the seminar ..................................................................................................... 81

10 Appendix 2 – Literature .......................................................................................................... 84


Introduction

Preliminary notes

This document describes the content covered by the test which must be taken in order to become a “Certified Professional for Usability and User Experience – Advanced Level User Requirements Engineering” (CPUX-UR).

This document consists of a curriculum (chapters 1 to 7) and a glossary (chapter 8). The curriculum and the glossary together contain all topics and technical terms that might come up in the theoretical exam as well as in the tasks of the practical exam.

The certification test will only include terms and topics that are described in the curriculum and glossary. The goal of the test is to evaluate:

what applicants know and what they can recall

whether applicants understand the terms and topics

whether applicants can apply the knowledge in practice

The glossary in chapter 8 contains terms from the CPUX-F glossary (plus extensions to those terms) as well as terms specific to the area of user requirements engineering. Term definitions are based on ISO standards wherever possible.

This document covers the human-centred design activities “Understand and specify the context of use” and “Specify the user requirements” of the human-centred design process as defined in ISO 9241-210 “Human-centred design process for interactive systems” (see figure 1).

The target audience for the curriculum and glossary are people familiar with context of use analysis. It is recommended that readers have performed at least one context of use analysis with real users prior to reading the document.

This document is primarily based on the following resources: 1. CPUX-F Curriculum (available at www.uxqb.org) 2. ISO 9241-210 “Human-centred design process for interactive systems” 3. ISO/IEC 25063 "Common Industry Format (CIF) for usability: Context of use description" 4. ISO/IEC 25064 "Common Industry Format (CIF) for usability: User needs report" 5. DAkkS Usability Guidebook („Leitfaden Usability“), Version 1.3,

http://www.dakks.de/sites/default/files/71_sd_2_007_leitfaden_usability_1.3_0.pdf ) Further resources are listed in appendix 2 - Bibliography. This document is not intended to be a tutorial on how to identify context of use information and depict this information in a context of use description, or how to identify user needs within the context of use and derive user requirements. Readers of this document should already have practical experience in conducting these activities.

http://www.uxqb.org/


Figure 1: Human-centred design activities and corresponding deliverables based on ISO 9241-210

Structure of this document

The curriculum consists of 7 chapters. (Chapter 1 to chapter 7) Every chapter of the curriculum

starts with a list of terms used in the respective chapter (e.g. 1.0)

contains one or more learning units (e.g. 1.1 to 1.4) Each learning unit contains

the purpose of the learning unit (e.g. 1.1.1)

the learning objectives of the learning unit (e.g. 1.1.2) o 1.1.2.1 (learning objective 1) o ... o 1.1.2.7 (learning objective 7)

the learning content of the learning unit (e.g. 1.1.3) The learning content mainly states what is to be taught in a preparatory course for the certification test CPUX-UR. The technical details corresponding to the learning content can be found in the glossary. If a learning unit contains technical details that go beyond what is given in the glossary, then these details are explicitly stated in the learning unit. In this case, explicit headings are given (e.g. Syntax rule for stating qualitative user requirements).


What does the CPUX-UR certificate confirm?

The certificate “Certified Professional for Usability and User Experience – Advanced Level User Requirements Engineering” (CPUX-UR) confirms the following:

The certificate holder is very familiar with the terms used in context of use analyses as well as with the derivation, structuring and prioritisation of user requirements for an interactive system.

The certificate holder is proficient in the techniques and methods used in context of use analyses as well as in the derivation, structuring and prioritisation of user requirements for an interactive system.

The certificate holder has successfully demonstrated his/her knowledge and proficiency, in a theoretical and a practical examination.

The content and learning units of chapters 1 to 7 are taught in preparatory courses for CPUX-UR. Here, the main focus is on understanding the terms and concepts from the curriculum for CPUX-F and applying them in practice as well as knowing about, understanding and being able to apply additional terms and concepts. Chapter 9 contains a timetable for a typical seminar, which can be used by training providers as a guide for the development of their own seminars.

Learning objectives and proficiency levels

Each learning objective is assigned to a proficiency level (K1, K2, K3). Proficiency level K3 includes level K2. Proficiency level K2 includes level K1. Table 1 states ways of demonstrating expertise for each proficiency level. The terms used are the same as those used to describe the learning objectives.

Proficiency level Ways of demonstrating expertise for each level

K1 (Know) list, identify, recognise, name, describe

K2 (Understand) analyse, apply, perform, justify, describe, assess, depict, devise, develop, complete, explain, exemplify, evaluate, formulate, identify, interpret, draw conclusions, transfer, differentiate, compare, understand, suggest, summarise

K3 (apply in practice)

K3.1 being able to plan

K3.2 being able to perform

K3.3 being able to analyse

K3.4 being able to document

K3.5 being able to communicate and pass on

Table 1: proficiency levels for the CPUX certification model

“Know” (K1) means being familiar with the basic terms and concepts in the area of usability and user experience. “Understand” (K2) means

being able to recognize relationships within and between concepts (e.g. the relationship between user need and user requirement)

being able to identify the suitable approach for a specific activity in relation to a given problem (e.g. the approach for recognising and formulating user needs in context of use information)

“Apply in practice” (K3) means being able to successfully apply the known and understood in specific use cases. The foundation level (CPUX-F) focuses on K1. The advanced levels (CPUX-UR, CPUX-UT, ...) focus on K2 and K3.


The proficiency level K1 constitutes the basis for the theoretical exam in the foundation level (CPUX-F). The proficiency level K2 constitutes the basis for the theoretical exam in the advanced level (CPUX-UR, CPUX-UT, ...). The practical exam in the advanced level CPUX-UR focuses on the proficiency levels K3.1, K3.3 and K3.4. To clarify: The proficiency “being able to perform” (K3.2) is essential for being successful as a usability engineer (e.g. conduct interviews, conduct observations). Nonetheless, for the practical exam in CPUX-UR, the emphasis is on “being able to analyse”, as this proficiency is especially important for the derivation, structuring and prioritisation of user requirements, and the corresponding learning content is not covered in other certification procedures.


Overview of learning units, main terms / concepts, methods and deliverables

This overview serves as the central theme for the CPUX-UR curriculum. It shows the content of each learning unit in a compact format (most important terms, methods and deliverables). The right column contains references to illustrative examples for deliverables in the appendix, if available.

Chapter Learning unit Important terms and concepts Methods in this learning unit

Deliverables in this learning unit

1 Introduction to context of use analysis

1.1 Differentiate between requirements and solutions

Request

Requirement

Solution

None, basic knowledge None, basic knowledge

1.2 Differentiate between stakeholder requirements and system requirements

Stakeholder requirement

System Requirement


1.3 The components of the context of use

User

Goal

Task

Task object

Social environment

Physical environment

Resources


1.4 User requirements as a separate requirements category within the stakeholder requirements

User requirement in contrast to

Legal / regulatory requirement

Market requirement

Organisational requirement

Domain-specific requirement


2 Plan context of use analyses

2.1 Identify the rationale and goals for the context of use analysis

Different rationales

Different goals


2.2 Determine the approach for context of use analysis

Classic context of use analysis

Model-based context of use analysis


3 Gather and document context of use information

3.1 Select and recruit users for the gathering of context of use information

User

User group

Grouping of users based on relevant differences in the context of use

User group profile

Recruitment screener




3.2 Prepare and execute the gathering of context of use information

Contextual interview

Observation

Focus group

Contextual interviews

Observations

Focus groups

User group profile

Recruitment screener

Interview checklist

3.3 Document context of use descriptions from context of use information in an analysable and accessible way

Context of use information

Context of use description

None, different documentation formats are presented

Context of use description in different formats:

As-is scenario

Persona

Further formats (see chapter 3.3.3)

4 Identify user needs in context of use information

4.1 Systematically identify and formulate user needs

User need o Resource need o Informational need o Competency need

User want

Identify required preconditions and goals in context of use information

Evaluated context of use description - Part 1 of 2: User needs

5 Derive and structure user requirements from user needs

5.1 Systematically transform user needs into user requirements

User requirement Identify necessary interactions with the interactive system (recognise, select, input)

Evaluated context of use description - Part 2 of 2: User needs and derived user requirements

5.2 Appropriately structure user requirements

Task

Subtask

Task model

Structure user requirements based on tasks and subtasks

Task model for each task

Structured list of user requirements

6 Consolidate user requirements

6.1 Consolidate and prioritise user requirements with users

Prioritisation (from the user’s view)

Kano scheme

Consolidation workshop with users

Structured list of user requirements - with prioritisation from the user’s view)

6.2 Determine the implementation priority for user requirements together with project members

Implementation priority

Product roadmap

Structured list of user requirements - with implementation priority




7 Cooperation between user requirements engineers and other roles / disciplines

7.1 As a user requirements engineer, become a successful provider for other roles

Roles and their responsibilities, for whom the user requirements engineer is a provider:

Information architect

Interaction designer

User interface designer

Usability tester

Product manager

Product Owner

Systems engineer

Project manager



1 Introduction to context of use analysis

1.0 Terms in this chapter

Term Same as in CPUX-F

Extended beyond CPUX-F

New in CPUX-UR

Requirement X

Task X

Task model X

Task object X

User X

CPRE X

Direct user X

User need X

Domain-specific requirement X

Request X

User interface guideline X

Immunisation trap X

Indirect user X

Interactive system X

IREB X

Solution X

Market requirement X

Human-centred design X

User requirement (qualitative) X

User requirement (quantitative) X

Context of use X

Context of use for design X

Context of use analysis X

Context of use information X

Task object in user interface X

Human-centred quality X

Organisational requirement X

Primary user X

Quality X

Resource X X

Risk X X

Secondary user X

Stakeholder X

Stakeholder requirement X

System requirement X

Technology-centred quality X

Subtask X

Environment X X

Validation X

Verification X

Goal X


1.1 Learning unit “Differentiate between requirements and solutions”

1.1.1 Purpose of this learning unit

Understand that requirements are helpful in enabling suitable solutions to be identified and unsuitable ones to be discarded, thereby allowing a consensus to be achieved regarding solution proposals that is based on facts rather than opinions.

1.1.2 Learning objectives

Know about the two basic types of quality for an interactive system (human-centred quality and technology-centred quality)

Know about the four types of information, 1.) context of use, 2.) user needs 3.) requirements and 4.) solutions

Know the difference between requirement and solution

Know the difference between request and requirement

Know the difference between problem space and solution space

Understand that requirements must be based on user needs in the context of use

Understand the difference between requirements and user interface guidelines

Be able to determine whether a textual statement contains a requirement or a solution

Know about the immunisation trap with respect to formulating requirements

1.1.3 Learning content

Human-centred quality and technology-centred quality o Differentiate between human-centred quality and technology-centred quality o Distinguish between the components of human-centred quality:

Accessibility Usability User experience and Freedom from unacceptable risk

o Distinguish these components from technology-centred quality: Functional appropriateness Performance Interoperability Reliability Security Maintainability Portability

Distinguish between context of use, user needs, requirements and solutions in a systematic way

o Context of use information as factual information o User needs as reasons for the need for assistance o Requirements as requested capabilities of an interactive system in order to provide a

suitable form of support o Solutions as interactive systems with suitable characteristics

Differentiate between requirements and requests o Requirements as justified criteria for evaluating the quality of the interactive system to

be delivered o Analyse requests (viewed as possible candidates for requirements) regarding

underlying user needs o Understand that user interface guidelines are generic requirements that are not

derived from the analysis of context of use

The benefits of taking requirements as the basis for the development of possible solutions o Narrow down the solution space based on requirements o Avoid the immunisation trap o Be able to create and selectively compare solution alternatives based on

requirements


1.2 Learning unit “Differentiate between stakeholder requirements and system requirements”


Make sure that the basis for the human-centred quality of the interactive system is fully derived and verifiable.


Know the difference between between stakeholder requirements and system requirements

Understand that stakeholder requirements are the basis for system requirements

Know about and be able to differentiate between types of stakeholder requirements

Understand that user requirements make up their own category within the stakeholder requirements

Know the difference between usability engineering and requirements engineering

Know what verification means and know what validation means

Know about IREB and CPRE


Classify stakeholder requirements

Differentiate between stakeholder requirements and system requirements o Identify stakeholder requirements as the basis for system requirements o Distinguish between system requirements and stakeholder requirements

Verification versus validation o Apply verification as an instrument to compare solutions with requirements o Apply validation as an instrument to confirm,

that requirements are correctly specified that solutions effectively support the requirements of the stakeholders

IREB and CPRE o Know that IREB is the publisher of “Certified Professional for requirements

engineering” (CPRE) o Know the difference between the curriculum for CPRE (focusing on system

requirements) and the curriculum for CPUX-UR (focusing on user requirements)

1.3 Learning unit “The components of the context of use”


Make sure that all components of the context of use from which user requirements for the interactive system can be derived are adequately taken into account in the requirements specification.


Be able to precisely differentiate between users, goals and tasks, resources, the social environment and the physical environment

Be able to formulate goals as intended outcomes

Be able to distinguish between task, task model and task object o Know about the term “task model” and its importance for the description of tasks o Know about the construct “task object” as the object for the completion of tasks o Know about the construct “task object in the user interface” as the representation of

the task object in the user interface

Be able to describe tasks with the components precondition, subtasks and intended outcome (postcondition) as a “task model”

Understand that the context of use for design is typically a subset of the given context of use and that it is used as a basis for the derivation of user requirements



The four components of the context of use according to ISO 9241-11 o Distinguish between users, goals and tasks, resources and environment o Avoid possible confusion between the components o Take all components of the context of use into account

Differentiate between and describe user groups based on goals and tasks o Describe primary users o Describe secondary users o Describe indirect users

Differentiate between user groups based on further context of use components o Characteristics, attitudes and experience of users o Social / organisational environment o Physical environment o Resources

Goals as intended outcomes o Goals versus subgoals o Identify and describe goals and subgoals

Identify and describe tasks and subtasks for the achievement of goals

The complete activity as the basis for task modelling o Develop task models taking into consideration the phases “plan”, “prepare”, “perform”,

“evaluate result”, “pass on result”

Examples of context of use information that is or is not used for the design


1.4 Learning unit “User requirements as a separate requirements category within the stakeholder requirements”


Make sure that the difference between user requirements and domain-specific requirements, organisational requirements, market requirements and legal requirements is understood.


Understand that the usability of an interactive system can significantly depend on whether or not a single user requirement is implemented or not

Understand that qualitative user requirements are the basis for the interaction design of the interactive system

Understand how user requirements can not only lead to other stakeholder requirements but can also be derived from other stakeholder requirements


Distinguish between qualitative user requirements and quantitative user requirements o Qualitative user requirements as the basis for the efficient use of interactive systems o Quantitative user requirements as acceptance criteria for the interactive system

Sources of qualitative user requirements

The elements of a qualitative user requirement o Specify qualitative user requirements o Examples of qualitative user requirements (for products, systems and services)

Sources of quantitative user requirements

The elements of a quantitative user requirement o Specify quantitative user requirements o Examples of quantitative user requirements

Examples of solutions that represent the implementation of user requirements

Examples of negative consequences if user requirements are not implemented

Examples of positive consequences if user requirements are implemented

Examples of organisational requirements and domain-specific requirements that result from user requirements


2 Plan context of use analyses




New in CPUX-UR

Human-centred quality objectives X

User group X

User group profile X

Design thinking X

Empirical information X

Classic context of use analysis X

Constructed information X

Lean UX X

Model-based context of use analysis X

Sponsor X


2.1 Learning unit “Identify the rationale and goals for the context of use analysis”


Make sure that the context of use analysis can be planned to a reasonable extent, with respect to the given rationale and the specified human-centred quality objectives.


Know about the different reasons for carrying out context of use analyses

Be able to define human-centred quality objectives for the design of the interactive system (in addition to general project goals)


Typical situations in which context of use analyses are carried out within a project for designing an interactive system

o A new interactive system is to be developed for which there is no predecessor o The acceptance / intensity of use is to be increased for a given interactive system o The efficiency in the use of an interactive system is to be increased for a specific user

group o An existing interactive system is to be extended in terms of its functionality (Increase of

effectiveness, e.g. for a new user group or for a new task with respect to an already supported user group)

o Relevant user requirements are to be identified for the execution of a usability evaluation of an interactive system

Human-centred quality objectives within a project, in the sense of “what should be achieved from the user’s point of view”

o Formulate human-centred quality objectives as part of every project in which an interactive system is to be created or modified

o Differentiate between human-centred quality objectives and general project goals


2.2 Learning unit “Determine the approach for context of use analysis”


Ensure that while executing the analysis of the context of use, known information is considered and unknown information is collected, both in a systematic manner.


Understand the assumptions about the context of use as the starting point for collecting empirical information (i.e. facts from the context of use)

Be able to apply the different approaches for context of use analysis (classic versus model-based)

Understand that context of use analysis does not conflict with activities associated with “Design Thinking” or “Lean UX”, but that these approaches are also based on a context of use analysis, just as almost any human- and user-centred approach is

Be able to plan resources for the respective approach taken for the context of use analysis


Establish consensus about the approach in the project o Set human-centred quality goals together with all project members o Gather known information and assumptions about the context of use in a systematic

manner o Identify knowledge gaps and uncertainties about the context of use o Devise appropriate research questions for context of use analyses o Identify participants for surveys or interviews o Decide on the approach to be taken (classic versus model-based) o Plan resources and ensure their availability

The classic approach versus the model-based approach o The classic approach to context of use analysis

Initial Situation:

Little or no information or dissent about the components of the context of use

The customer’s questions to be addressed in the context of use analysis are more general

High expectation of new insights from the context of use analysis

The innovation potential achievable as a result of using the interactive system is largely unknown

Procedure:

Reach consensus with the sponsor and other project stakeholders on selecting this approach for the given rationale

Specify user group profiles for each expected user group

Determine the questions to be addressed

Conduct contextual interviews, observations and/or focus groups

Document, analyse and structure the gathered context of use data o The model-based approach to context of use analysis

Initial Situation:

The customer has information about the users, tasks, resources and environment (physical and social)

The project members doubt that empirical data gathering with users will yield relevant insights

There is extensive experience in the use of an existing interactive system

A specific focus is set for the context of use analysis

The context of use analysis is expected to yield very specific insights

The questions to be addressed in the context of use analysis are very specific and build on each other

The customer seems to know by and large about the user requirements


Procedure:

Identify the assumptions and the knowledge about the context of use

Specify user group profiles for each expected user group

Construct task models with the customer for each task to be supported

Anticipate user requirements for each task

Identify gaps, ambiguities, need for optimisation and what is worth preserving from anticipated context of use descriptions, constructed task models and anticipated user requirements, in order to derive questions to be answered in further context of use analyses

Conduct contextual interviews and/or observations and/or focus groups, if needed

Document, analyse and structure the gathered context of use data

Context of use analysis as a field of action within human-centred design – Establish the relationship with the currently discussed approaches “Lean UX” and “Design thinking”

o Focus of each approach o Integration in the human-centred design process as defined in ISO 9241-210 o Explain where in Lean UX and design thinking there is a connection with context of use

analysis o Understand the additional value of formulating user requirements explicitly as opposed to

the implicit consideration of user requirements in Design thinking and Lean UX


3 Gather and document context of use information




New in CPUX-UR

Affinity diagram X

Task model X X

Task object X

User group X

User group profile X

Observer (Context of use analysis) X

Observation X

Cultural probe X

User need X

Focus group X

Closed question X

As-is scenario X

Contextual interview X

User want X

Master-apprentice model X

Mental model (of a user) X

Moderator (context of use analysis) X

Neutral question X

Context of use description X

Context of use information X

Use scenario (Target scenario) X

Open question X

Persona X

Recruitment screener X

Leading question X

Diary study X

User journey X

Goal catalogue X


3.1 Learning unit “Select and recruit users for the gathering of context of use information”


Make sure that realistic context of use information is gathered from actual representatives of each user group


Be able to develop user group profiles as a basis for recruitment screeners

Be able to develop recruitment screeners for selecting users for contextual interviews, observations and/or focus groups

Know how to recruit users for contextual interviews, observations and/or focus groups


The relationship between users, user groups and user group profiles

Identify and document user group profiles

Create recruitment screeners based on user group profiles

Recruit users 1. for developments within a specific organisation

Identify user group profiles with experts from the organisation Select users with the help of managers in the organisation

2. for developments executed by a manufacturer for users that are employees in customer organisations

Create user group profiles together with the manufacturer Create a recruitment screener for each user group together with the manufacturer Identify potential users in customer organisations, maybe together with a service

provider Verify potential users through a recruitment screener Recruit and invite selected and verified users for contextual interviews,

observations and/or focus groups 3. for developments executed for users as direct customers

Create user group profiles together with the manufacturer Create a recruitment screener for each user group together with the manufacturer Identify potential users, maybe together with a service provider Verify potential users through a recruitment screener Recruit and invite selected and verified users for contextual interviews,

observations and/or focus groups

3.2 Learning unit “Prepare and execute the gathering of context of use information”


Make sure that context of use information is collected using the appropriate methods and that the appropriate methods are selected and professionally applied for the context of use analysis.


Know which methods exist for the gathering of context of use information

Know how to decide which method or combination of methods to use

Be able to distinguish between context of use information, user needs, user requests and user’s ideas for the future

Know what to pay attention to when preparing and conducting contextual interviews

Know what to pay attention to when preparing and conducting observations

Know what to pay attention to when preparing and conducting focus groups

Know that data from interviews and observations are transitory unless logged / documented



Master-apprentice model (repeated from CPUX-F)

Gather qualitative data o Differentiate between context of use information, user needs, requests and ideas for

the future o Typical and atypical (recurring) situations and actual tasks o Intended outcomes from the user’s perspective o Further information that is discussed here

about the users about environmental conditions (social and physical) about resources

Typically used methods for the gathering of context of use information o Contextual interviews o Observations o Focus groups

Criteria for the selection or combination of methods depending on the rationale and the questions to be addressed in the context of use analysis

o Contextual interview, if all components of the context of use are of interest from the subjective perspective of the users

o Observation, if detailed information about the task execution needs to be collected in an objective manner in the actual context of use

o Focus groups, if a deep understanding of the problem space is required for a specific topic thereby taking different perspectives into account

Examples of method combinations o Combination of interview and observation o Combination of focus group and observation

User self-reporting as a special case of observation o Capture latent knowledge through “cultural probes” o “Diary study” as an often used way of user self-reporting

Procedure for each method o Contextual interviews

Typical process Typical mistakes Recommendations for the execution

o Observations Variants of observation (participatory, non-participatory) Focus during observation Record observations Recommendations for the execution

o Focus groups Group discussion / focus group Focus on topics Ways of focusing Group size and group composition Record focus groups Recommendations for the execution

Collect and document the heard and seen as facts instead of jumping to hasty conclusions or constructing interpretations


3.3 Learning unit “Document context of use descriptions from context of use information in an analysable and accessible way”


Make sure that the context of use information gathered can be understood and interpreted by others


Know about the types of context of use descriptions

Know that sometimes, user group profiles have to be adjusted based on contextual interviews, observations and/or focus groups that have been conducted

Understand the role of personas in comparison with user group profiles

Be able to document context of use information in a way that minimizes further enquiries and allows others to gain a deep understanding of the context of use


High-level context of use description versus detailed context of use description

Traceability of context information back to the source

Use notations for describing context of use information that allow the reader to immerse himself in the context of use, thereby allowing user needs to be identified directly from the documented context of use, which in turn is the basis for subsequently deriving user requirements

The notations for describing context of use information depend on which method is used

Notations for documenting contexts of use


4 Identify user needs in context of use information




New in CPUX-UR

User want X

User need X

Informational need X

Competency need X

Resource need X

Goal X

4.1 Learning unit “Systematically identify and formulate user needs”


Make sure that the user requirements can be specified correctly, based on more than just assumptions.


Know about and be able to differentiate between types of user needs

Know about and be able to apply quality factors for user needs

Be able to precisely recognize user needs in context of use information

Be able to formulate user needs in a way that enables requirements to be derived from them

Differentiate between user wants and user needs


Types of user needs o Resource need, Informational need, competency need

quality factors for user needs o User needs are always justified by the context of use o User needs are always objectively true for all users in a user group o User needs are always indisputable o User needs always consist of a precondition that must be met, formulated as a

condition, (either “have something available” or “know something” or “be capable of something”) and a goal supported by the precondition (“be able to decide something” or “be able to do something”)

o The interactive system (yet to be developed or evaluated) is not found in the user need

Syntax rules for stating user needs o Resource need:

The <user group> must have <resource> available in order to be able to <decide> or <perform action>. Examples: 1. The patient (user group) must have a fixed appointment (resource) in order to be

able to get treatment at a fixed point in time (goal). 2. The prospective taxi passenger (user group) who spontaneously needs a taxi

must have a taxi available in his/her vicinity (resource) in order to be able to reach his/her destination in time (goal).


o Informational need: The <user group> must know <information> in order to be able to <decide> or <perform action>.

Examples:

1. Shortly before his/her fixed appointment the patient (user group) must know when the treatment is expected to begin (information) in order to be able to make good use of the remaining time (action).

2. The prospective taxi passenger (user group) must know before entering the taxi how much the trip is likely to cost (information) in order to be able to decide if he/she wants to take the taxi or use a different form of transport (decision).

o Competency need:

The <user group> must have <competency/skill> in order to be able to <decide> or <perform action>.

Example:

1. The baker (user group) must have the skill to produce a Frankfurter Kranz (skill) in order to be able to produce it (action).

2. The car driver (user group) must be able to park a car (skill) in order to be able to park his/her car in the space available (action).

Systematically identify user needs in context of use information o Explicate goals in context of use information o Identify preconditions that support each goal

Each piece of context of use information can contain one or more user needs. It is therefore recommended to process context of use descriptions one sentence at a time and identify user needs following these central questions:

o Which resource is needed in the context of use and for what reason (goal)? o Which information is needed in the context of use and for what reason (goal)? o Which competency/skill is needed in the context of use and for what reason (goal)?

Table 2 provides examples of context of use information and how user needs can be derived from it.

Context of use information (Extract from a context of use description)

Identified user needs (examples)

Patients often need to make appointments a long time in advance, because good doctors are not available at short notice.

Example of a resource need: The patient (user group) must have a fixed appointment (resource) in order to be able to get treatment at a fixed point in time (goal).

Often, patients do not get their treatment at the time of their appointment. Having to wait is very annoying for the patients. Sometimes they sit in the waiting room for 90 minutes and they don’t know how long it will take until it is their turn.

Example of an informational need: The patient (user group) must know when it is actually going to be their turn (information) in order to be able to decide what to do with the remaining time (goal).

A doctor only has limited time for each patient. He often has to make a diagnosis within a few minutes.

Example of a competency need: The doctor (user group) has to be able to apply all methods necessary to make the correct diagnosis (competency) in order to be able to initiate the right treatment for each patient (goal).

Table 2: Context of use information with identified user needs


Many user needs come up repeatedly in interviews and observations within one user group. If, for example, the documentation of 5 contextual interviews (within one user group) is analysed, the overlap of user needs identified often exceeds 50%. It then makes sense to reference an already documented user need when it comes up again. Larger sets of user needs can be sorted according to the tasks to be supported.

Identify user needs contained in organisational requirements o User needs are mainly found in context of use information o Further user needs can be derived from organisational requirements if they address

users

1. Example of an organisational requirement:

If a quote relates to an order volume that exceeds EUR 100,000, then the salesperson must let the sales manager sign the quote.

2. Example of a user need resulting from the organisational requirement for the user group “salesperson”:

The salesperson must know the order volume limit above which he/she must submit his/her quotes to the sales manager for approval in order to be able to handle his/her quotes according to the rules of the organisation.

Distinguish between requests and user needs o Requests are often formulated as a desired solution for the interactive system, but are

not necessarily based on an actual user need from the context of use o When conducting contextual interviews, asking the user further questions can clarify if

a request is actually based on a user need from the context of use or if the request only reflects individual preferences of the user and cannot be generalised for product design


5 Derive and structure user requirements from user needs




New in CPUX-UR

User requirement (qualitative) X

User requirement (quantitative) X

Task model in the context of use X

Task model used for design X

5.1 Learning unit “Systematically transform user needs into user requirements”


Make sure that user requirements are correctly derived from user needs, so that required actions with the interactive system are captured and specified, and unnecessary actions are avoided.


Know about and be able to apply quality factors for user requirements

Be able to apply the syntax rule for a qualitative user requirement

Be able to derive qualitative user requirements from user needs

Be able to formulate quantitative user requirements

Be able to merge conflicting user needs from different sources into consensual user requirements


Types of user requirements o qualitative user requirements and quantitative user requirements

Quality factors for user requirements o For qualitative and quantitative user requirements

User requirements must always be formulated as a requirement with regard to the usage of the solution and not as a requested solution

User requirements must always refer to one or more user groups. o For qualitative user requirements

Qualitative user requirements must always be justified by user needs from the context of use

Qualitative user requirements must always consist of a requirement regarding the usage of an interactive system (input, select, recognise), if necessary. under certain conditions (and, if appropriate, with reference to a user need)

o For quantitative user requirements Quantitative user requirements must always be justified by stakeholder

requirements It must be possible to use quantitative user requirements as acceptance

criteria for the human-centred quality of the interactive system


Transform user needs into one or more user requirements (Central questions)

Qualitative user requirements can be derived from every user need by using the following central questions:

o What does the user need to be able to recognise in the interactive system

in order to fulfil his/her need? o What does the user need to be able to select in the interactive system

in order to fulfil his/her need? o What does the user need to be able to input in the interactive system

in order to fulfil his/her need? Table 3 provides examples of how user needs can be transformed into user requirements.

Context of use information (Extract from a context of use description)

Identified user needs (examples)

Derived user requirements

Patients often need to make appointments a long time in advance, because good doctors are not available at short notice.

The patient (user group) must have a fixed appointment (resource) in order to be able to get treatment at a fixed point in time (goal).

The user must be able to recognise in the system, which appointment times are available. The user must be able to select an appointment time in the system.

Often, patients do not get their treatment at the time of their appointment. Having to wait is very annoying for the patients. Sometimes they sit in the waiting room for 90 minutes and they don’t know how long it will take until it is their turn.

The patient (user group) must know when the treatment is actually going to begin (information) in order to be able to decide what to do with the remaining time (goal).

The user must be able to recognise in the system, when his/her treatment is expected to actually begin.

A doctor only has limited time for each patient. He often has to make a diagnosis within a few minutes.

The doctor (user group) has to be able to apply all methods necessary to make the correct diagnosis (competency) in order to be able to initiate the right treatment for each patient (goal).

no user requirement derivable

Table 3: Context of use descriptions with identified user needs and derived user requirements

Syntax rule for stating qualitative user requirements The following syntax rule can be used for stating qualitative user requirements.

Syntax rule: The user must be able to input / select / recognise <an information or resource> in the system under <optional condition>.

Examples:

1. Before opening (condition) the dishwasher (system), the user must be able to recognise that a full wash cycle has been completed (information).

2. Before cooking eggs (condition) with the egg boiler (system), the user must be able to select how many eggs are to be hard-boiled, how many medium-boiled, and how many soft-boiled (resource).


Formulate quantitative user requirements Quantitative user requirements can be formulated by taking the following components into consideration:

o The stakeholder who issued the requirement (e.g. employer or legislator) o User group(s) concerned who have to fulfil the requirement during use o The number or percentage of users who have to fulfil the requirement o Quantities (e.g. maximum available time, error rate, precision) o Special condition(s) of the context of use under which the use takes place

Example:

1. 95% of users of the intranet must be able to call up the travel expense form from their normal workplace within 10 seconds, regardless which application is currently running.

Identify conflicting user needs It might be that it is impossible to fulfil different goals at the same time within the same user group, as the necessary preconditions might be mutually exclusive. Example:

1. Upon returning to his/her home, the citizen (user group) must have a sufficiently high room temperature available, in order not to become sick.

2. The citizen (user group) must minimize his/her power consumption in order to keep the energy costs within limits.

It might be that it is impossible to fulfil goals at the same time for different user groups, as the necessary preconditions might be mutually exclusive. Example:

1. The emergency patient (user group) must receive treatment (resource) immediately, without a scheduled appointment, so that life-saving measures can be taken in an emergency (goal).

2. The “non-emergency” patient (user group) must have a fixed appointment (resource) in order to be able to get treatment at a fixed point in time (goal).

Identify user requirements that are derived from conflicting user needs and find a compromise within the solution space based on alternative solution drafts. User requirements derived from identified user needs must be documented, even if the user needs cannot be fulfilled at the same time. It is necessary to evaluate the consequences of taking or not taking a certain user requirement into account, in order to decide which of the seemingly conflicting user requirements should be further considered. When looking for solutions, user requirements can be lowered in priority or it might be possible to implement seemingly conflicting user requirements, e.g. through organisational solutions as a supplement to technical solutions, or multiple solutions that can be used alternatively. Example of an organisational solution for a previously mentioned user need:

3. Certain medical staff are reserved (organisationally) for treating emergency patients, meaning they are not available for appointments with “normal” patients. This way, emergency patients can also be treated.


5.2 Learning unit “Appropriately structure user requirements”


Make sure that user requirements can be used as the basis for the specification of use scenarios (instead of being collected in a simple list that might be just transferred into a “feature list”).


Be able to distinguish between the task model of the context of use and the task model used for design

Be able to assign a user requirement to a task and subtask to be supported

Be able to structure user requirements according to the tasks and subtasks to be supported


Group user requirements according to the tasks they are assigned to

Develop the task model used for design for each task to be supported o Identify tasks and subtasks to be supported based on

the phases of the task lifecycle, taking into account the task model of the current context of use

the given user requirements o Structure user requirements according to the tasks and subtasks to be supported


6 Consolidate user requirements




New in CPUX-UR

Kano scheme X

Prioritisation X

Product roadmap X

6.1 Learning unit “Consolidate and prioritise user requirements with users”


Make sure that the collected user requirements are confirmed by users as being complete and correct (consolidation) and that each user requirement’s relevance is ranked, so that all user requirements can be prioritised for the implementation from the project perspective.


Be able to determine the adequacy and completeness of the specified user requirements together with users

Understand the need to use a structured scheme for prioritisation

Know about publicly available schemes for prioritisation

Be able to rank the relevance of user requirements together with users


Conduct consolidation workshops with users in order to analyse specified user requirements regarding correctness, completeness and prioritisation (from the users’ perspective)

Use structured schemes together with users for ranking the relevance of user requirements o Schemes can be developed by oneself. It is however recommended to use a publicly

available scheme such as the Kano scheme, as they are well-proven and often likely to gain consensus.

Perform an exemplary classification using a specific scheme (e.g. the Kano scheme) o A prioritisation is performed using the Kano scheme with 7 to 10 user requirements

that belong to a task that the students know well


6.2 Learning unit “Determine the implementation priority for user requirements together with project members”


Make sure that user requirements are prioritised by the project members regarding when they are to be implemented, as typically not all user requirements can be implemented at the same time and a prioritisation as regards time can help to avoid conflicts about which user requirement to implement when.


Be able to communicate user requirements to stakeholders in the project

Be able to convey to stakeholders in the project the relevance of each user requirement identified

o It is the basis for the efficiency of the user when using the interactive system o It is the basis for acceptance of the interactive system o It is the basis for future systems that are supposed to support the same context of use

Know that user requirements should be documented in a robust and retrievable way, for example by using a product roadmap

Be able to reach consensus about the implementation priority for each user requirement together with the stakeholders of the project


Make clear to others how important the implementation of user requirements is for the human-centred quality of an interactive system

Communicate the consequences of not implementing user requirements that were assigned a high priority by the users

Prioritisation scheme for implementation priorities

Support the classification of user requirements based on implementation priorities

Integrate user requirements into a product roadmap for later implementation, if they are not implemented immediately


7 Cooperation between user requirements engineers and other roles / disciplines




New in CPUX-UR

Information architect X

Interaction designer X

Product owner X

Product management X

Product manager X

Project management X

Requirements engineering X

SCRUM X

Systems engineering X

Usability tester X

User requirements engineer X

User research X

User interface designer X


7.1 Learning unit “As a user requirements engineer, become a successful provider for other roles”


Make sure that the user requirements engineer knows about other disciplines and roles and that he/she can communicate his/her work products to them within their disciplines.


Know in which disciplines of product development the work products of the user requirements engineer are applied

Know about and be able to make clear to others how useful the work products of the user requirements engineer are for other roles

Know how to act responsibly as a user requirements engineer when confronted with limited resources and low acceptance among the stakeholders

Know what the main roles in the respective disciplines are and what their tasks are


Roles who receive work products from the user requirements engineer o Interaction designer o Project manager o Product manager o Product owner

Use a model-based context of use analysis when encountering scarcity of resources

Effectively communicate the work products from user requirements engineering to other roles o Product managers can use the work products from user requirements engineering as

a basis for product roadmaps and release planning o Product owners can use the work products from user requirements engineering as

part of a backlog and as the basis for user stories o Interaction designers can use the work products from user requirements engineering

as a basis for informed design decisions o Usability Engineers can use the work products from user requirements engineering

as a basis for planning human-centred design activities as input for the outsourcing of human-centred design activities (e.g. visual

design, evaluation) o Usability testers can use work products from user requirements engineering for the

following purposes: User profiles, as a basis for the recruitment of users Context of use descriptions, task models and user requirements (qualitative

and quantitative), as a basis for usability test cases o Software testers can use the work products from user requirements engineering as a

basis for test cases

Formulate assumptions about the context of use and communicate them (as assumptions)

View work products from user requirements engineering in relationship to the goals and expectations of stakeholders

Convey user requirements engineering as a main component of user research

Convey the difference between user requirements engineering and (system) requirements engineering

Differentiate between product management and project management

Know about SCRUM as a project management framework o The five activities in SCRUM o The three artefacts in SCRUM o The three roles in SCRUM


8 Glossary

Technical term

Definitions on white background: From CPUX-F

Definitions on grey background: Extended beyond CPUX-F or added in CPUX-UR

Affinity diagram An affinity diagram is a structured format for documenting results from the analysis of qualitative data. Ideas or statements belonging together are sorted into groups in a bottom-up fashion, with each group assigned a heading. The grouping and subsequent naming of related groups then make up the typical structure of an affinity diagram.

Notes:

1. Ideas or statements are first noted on cards (“affinity notes”) and then grouped hierarchically in several iterations. Each group of items or group of groups gets an appropriate heading

2. Affinity diagrams are typically created in a collaborative effort - regrouping is allowed.

3. The structure of an affinity diagram (levels: goals, topics, connections between items) can be better visualised using colours

Requirement A condition or capability that must be met or possessed by an interactive system to satisfy an agreement, standard, specification or other formally imposed documents.

Notes:

1. A requirement should have a determinable condition that makes it possible to validate it.

2. This glossary defines the following types of requirements:

a. Stakeholder requirement

b. Market requirement

c. Organisational requirement

d. User requirement.

3. This glossary further distinguishes between

qualitative user requirement, and

quantitative user requirement 4. In extension to CPUX-F, CPUX-UR uses a more complete

classification of stakeholder requirements see also stakeholder requirements.

Task Activities required to achieve a goal.

Notes:

1. Most tasks can be subdivided into subtasks.

2. Most subtasks require the possibility of choosing or input from the user or the recognition of information while using the interactive system.

3. Some subtasks can be subdivided into smaller subtasks.

4. Subtasks can result from tasks of the user identified in the context of use (“induced by the task”) or from necessary interactions with the interactive system (“induced by the system”).


Technical term



Examples of tasks:

1. Renting a car is a task. 2. Cancelling a reservation is a task. 3. Registering on a car rental website is a subtask. From the

user’s point of view, it is not a goal but an annoyance. 4. "Logging in" is a subtask. From the user’s point of view,

logging in is not a goal but an annoyance. It requires additional effort that is not necessary for carrying out the task.

5. Entering the user name and pressing the Tab key is one of several selection options or inputs required to complete the subtask "logging in".

6. Induced by the task:

Compare available cars

Cancel a reservation 7. Induced by the system:

Register on a car rental website

Authenticate yourself

Task model of the current context of use

A description of the tasks and subtasks currently performed by the user in the context of use in order to achieve his/her goals.

Notes:

1. A task model describes the logic of the task itself (content, execution, sequence), while a scenario describes how a person acts when performing one or more tasks in the context of use.

2. A task model of the context of use describes the tasks and subtasks currently performed, while the task model used for design describes the future logic of the tasks when supported by the new or revised interactive system.

3. The logic of a task (task lifecycle) typically consists of the following phases:

Plan

Prepare

Perform

Evaluate result

Pass on result 4. A task always starts with one or several preconditions and

ends with one or several postconditions. 5. Excessive structuring of tasks in several hierarchy levels

leads to complexity that is often not necessary. Therefore, it is advised to check every subtask for the following: a. whether there are actually two tasks that have been

accidentally merged into one task. Formulating the pre- and postconditions of the task at hand is a good test for this.

b. whether formulating a subtask as an action or a decision can result in a simplification. (Subtasks always consist of an action or a decision within a task.)

c. whether a user requirement has been formulated as a subtask by mistake.

Example: “Wake up at a scheduled point in time”


Technical term



Precondition: The person is willing to go to sleep.

Plan: o Determine the wake up time

Prepare: o Communicate the need for being woken up to the

person doing the waking Wake up time Wake up method (call, shake up, water) Number of wake up attempts

Perform: o Be woken up

Evaluate result: o Check if getting up can be postponed any further o Decide to stay in bed or not o If necessary, make sure that a new attempt to wake

the person up will happen if getting up is postponed

Pass on result: o Postponement of waking up, if applicable (have the

person doing the waking make some coffee first) o Communicate that no further wake up attempts are

required, if applicable o Communicate the request not to be woken up the

next day, if applicable o For oneself: Get up or stay in bed

Postcondition: The person is awake at the scheduled point in time and can get up.

Task model used for design A description of the tasks and subtasks that will be performed by the user in the future with the support of the new or revised interactive system in order to achieve his/her goals.

See also:

Task model of the context of use

Example: “Wake up by using an alarm clock”

Precondition: The person is willing to go to sleep.

Plan: o Determine the wake up time

Prepare: o Check if the alarm clock knows about the need for

being woken up Wake up time Wake up method (light, music, beeping) Number of wake up attempts

o Check if the alarm clock is activated o Make settings in the alarm clock, if necessary

Choose one of several stored wake up times

Set a new wake up time Change wake up method Activate alarm clock

Perform o Be woken up

Evaluate result: o Check if getting up can be postponed any further o Decide to doze a little longer or not


Technical term



o If necessary, make sure that a new attempt to wake the person up will happen if getting up is postponed

Pass on result: o Postponement of waking up, if applicable o Communicate that no further wake up attempts are

required, if applicable o Switch off alarm clock, if applicable

For oneself: Get up Postcondition: The person is awake at the scheduled point in time and can get up.

Task object The objects that were created or modified by a person or about which a person has learned something as the result of a task.

Notes:

1. Task objects are identified in contextual interviews or observations and are a component of the context of use description.

2. Identifying task objects in a task is a fundamental prerequisite for an efficient support of tasks through an interactive system, as they must typically be represented in the user interface. See also “task object (user interface)”.

3. Task objects are represented in the user interface of the interactive system either in part, completely or with complementary information. See also “task object (user interface)”.

Examples:

1. When executing the task “write an invoice”, a person creates the task object “invoice”.

2. When executing the task “clean the window”, a person modifies the task object “window”. Certain characteristics of the window have changed after executing the task: Before, it was dirty, afterwards, it is clean.

3. When executing the task “read newspaper”, the person learns something about the task object “news article”.

User want A desire regarding the design of an interactive system that is stated by a user.

Notes:

1. User wants can be collected in the context of use analysis. It is important for the acceptance of solutions that user wants are taken into account in the form of solution proposals, together with the user requirements for which the user wants are possible solutions. Nevertheless, user wants must not be the starting point when developing a solution.

2. User wants are often formulated as requests (e.g. “I want a steak”). In contrast, user needs describe what a user needs (e.g. “a regulated protein balance”).

3. The (subjective) user want is defined in contrast to the (objective) user need from the context of use.

4. User wants are often stated by users in contextual interviews, whereas user needs are typically implicit and only found by the user requirements engineer through analysis of the context of use information and problem descriptions.


Technical term



5. A user want is not necessarily part of the context of use, but can also be a basic condition to be considered, thereby leading to a user requirement.

6. User needs mainly lead to user requirements, whereas user wants mainly lead to market requirements and solution ideas.

7. The following are examples of desired emotional states that are relevant for product design and can be identified by questioning user wants in contextual interviews.

feel confident

have privacy

be motivated and determined

feel accepted (affiliation / acceptance)

feel satisfied

feel happy

act in a self-determined way

have control over a situation 8. Such desired emotional states can be essential for deciding

upon the relevance of certain user needs from the point of view of the user (see examples below).

Examples of user’s wishes:

1. When buying a medical device (specific situation), the doctor (target group) wants to be able to determine if he/she will be able to handle the device (prerequisite), so that he/she can feel confident about his/her purchase decision (emotional state).

2. When voting in a polling booth (specific situation), the voter (target group) wants to be able to determine if there is nobody observing (prerequisite), so that he/she can feel private while voting (emotional state).

3. When taking part in physical education class (specific situation), the student (target group) wants to wear shorts from an accepted brand (prerequisite), so that he/she feels accepted by his/her schoolmates (emotional state).

4. When buying a lottery ticket (specific situation), a lottery player (target group) wants to imagine himself winning the lottery (prerequisite), so that he/she feels happy (emotional state).

User Person who interacts with an interactive system or who uses the output of the system.

Notes:

1. "User" is subdivided into

a. direct user

b. indirect user

c. primary user

d. secondary user

2. Stakeholders may or may not be users. Stakeholders are not considered to be users if they are affected by an interactive system but neither interact with the interactive system nor use the output of the interactive system.

Examples of stakeholders who are not users:


Technical term



1. Managers of users

2. People affected by noise produced by the person using the interactive system

3. Marketers affected by the impact of the output on the brand name

Human-centred quality objectives

Goals that are to be achieved for the users of an interactive system when developing the interactive system.

Notes:

Human-centred quality objectives relate to one or more of the following dimensions of human-centred quality: usability, accessibility, user experience, freedom from unacceptable risk.

Human-centred quality objectives are goals of stakeholders regarding the human-centred quality of the interactive system to be created or revised. They are not yet user requirements.

Human-centred quality objectives are specified during the planning of human-centred design activities. The user requirements engineer acts here as a moderator, as he/she has specialised knowledge about this type of specification.

At the beginning of the project, explicitly specifying the human-centred quality objectives helps in adequately setting the focus and scope of the context of use analysis to be conducted. The actual user requirements then arise from the context of use analysis.

Human-centred quality objectives can be formulated as verifiable quantitative user requirements, so that they can serve as acceptance criteria for the project.

Examples of human-centred quality objectives:

Human-centred quality objectives for usability: o Travellers to the US are to be able to pass the entry

check twice as fast as before. o From the very start, users must be able to use the

web-based health record without help.

Human-centred quality objectives for accessibility: o Blind users must be able to recognise and understand

the content of the website. o Wheelchair users must be able to buy tickets at all

stations without assistance. o Visually impaired buyers must be able to find all

products in the store without assistance.

Human-centred quality objectives for user experience: o Already before using the travel expense settlement

system, users must get the impression that they will save time when using it.

o Users must have the feeling of complete privacy when using the electronic voting booth.

o Users must feel very confident that they are not producing avoidable waste (e.g. capsules) when using an automatic coffee machine.


Technical term



Human-centred quality objectives for freedom from unacceptable risk: o When using a system for creating prescriptions, the

user must not be able to prescribe drugs that are incompatible.

o People interested in buying a coffee machine must avoid producing hazardous waste (e.g. capsules).

o Users must not be able to irrevocably delete data in the system.

User group A collection of users with the same or similar personal characteristics and context of use related to the interactive system.

User group profile A generalised description of a user group.

Observer A person who watches users who discuss or carry out tasks that are related to the interactive system.

Notes:

1. Observer is a role in a usability activity, such as an observation, usability test session or focus group.

2. Observers must not interfere with the usability activity. However, observers may be actively involved in the analysis of the results.

Observation A technique for gathering contextual information relating to user needs in which an observer watches users who carry out tasks that are related to the interactive system.

Notes:

1. The observer does not interfere, except if he/she needs to occasionally ask a clarifying question.

2. If no interactive system is used, existing manual procedures should be observed.

3. Observation should take place in a context that is as natural as possible, for example at the user's workplace.

Quality factors:

Observations must be objective, reliable and valid, and thereby independent from the observation situation, the observer as a person and any other effects o Objective: The results of an observation are

independent of the observer, meaning that two observers come to the same result.

o Reliable: The observation reliably provides the same results as long as nothing changes in what is to be observed.

o Valid: The observation measures exactly what is supposed to be measured.

Observations must be documented as efficiently as possible, e.g. by using previously created recording sheets in order to capture activities quickly and automatically, maybe through several observers at once or with support from a technical system.


Technical term



Observations should be performed by at least two people (whenever possible): A moderator and a note-taker.

The observer or observers must together prepare for an observation, in order to familiarise themselves with the task at hand and to ensure that the observation is objective, reliable, valid and efficient.

Variants of an observation:

Structured versus unstructured:

A structured observation is directed and planned. Fixed

observation schemes and categories are used in order

to reduce the subjectivity of the observer. The

unstructured, “open” observation is undirected and

unplanned, subjective and open for anything that occurs.

It is therefore well-suited for forming hypotheses.

Participatory versus non-participatory:

When conducting a participatory observation, the

observer is also involved in the execution of the

activities to be observed. When conducting a non-

participatory observation, the observer is completely

passive with regard to the activities to be observed.

Note: A participatory observation where the observer

interacts with the observed environment by himself is

also called “ethnographic study”.

Open versus undercover:

When conducting an open observation, the observer

acts so that he/she is recognised as such. Other people

involved in the situation to be observed know at least the

purpose of the observer’s presence and can choose to

adapt their behaviour accordingly. In an undercover

observation, the observer disguises his/her identity (i.e.

he/she claims to have a different identity) in order to

influence the situation to be observed as little as

possible.

In the field versus in the lab:

A field observation happens in the natural surroundings

of the people to be observed. When conducting an

observation in a lab, the lab is modified according to the

observation objectives and resembles a situation that is

as realistic as possible for the people to be observed

and supports natural behaviour as far as possible.

The special case of self-observation (user self-reporting, see also cultural probe): The user observes himself/herself by keeping a diary (diary study) and collecting “probes” (traces) of his/her activity in the context of use which he/she then provides for analysis (e.g. photos, notes, sketches).

Typical procedure:


Technical term



Plan:

o Identify stakeholders who are relevant for the acceptance and processing of the observation results (e.g. product managers and sponsors)

o Invite stakeholders for the preparation of the observation

o Together with interested stakeholders, create a user group profile for each user group to be observed

o For each user group, clarify which tasks are to be observed and which questions the stakeholders have in mind

o If the people to be observed do not work for the customer and consequently need to be recruited externally, create a recruitment screener to make sure that the observed people are actual representatives of the user group in question

o Plan for two people per observation, if possible (an observer and a note-taker)

Prepare:

o Meet a person to be observed at the scheduled time for the duration planned (90 to 120 minutes) at the location for the observation

o Tell the person to be observed about the topic and goals of the observation (Topic = collect authentic information about the context of use and the actual process of tasks; Goal = Subsequent derivation of user requirements)

o Let the person to be observed describe, which tasks he or she typically performs, with whom he or she cooperates in the context

of those tasks, and what the outcome of each task is

o Name the tasks to be observed o Assure the person and his/her employer that the

documentation of the observation will be anonymised o Obtain a letter of agreement from the person for taking

photos (even if no photos are actually taken)

Perform:

o Have the person state the name of the task he or she is about to perform

o Observe the person during the execution of the task o Note in brief all observations and statements so that a

coherent text can be created afterwards o Ask questions for clarification whenever necessary o End the observation o Thank the observed person for their cooperation and

support

Document:

o Write down observations and statements as a coherent text (as-is scenario) so that stakeholders get a comprehensive overview of the context of use for the observed person without any need for further enquiry. Take photos as illustration for the text.


Technical term



Typical mistakes and problems regarding the procedure: a. Observations can get distorted through previous

knowledge and assumptions about the activities to be observed

b. Observations can get mixed up with evaluation and interpretation.

c. Premature evaluation can occur if abstraction regarding assumed connections is done too early.

d. The more familiar the observer becomes with the activities to be observed, the more his/her concentration and the reliability of the observation decrease

CPRE The certificate “Certified Professional for Requirements Engineering” from IREB e.V.

Notes:

1. The non-profit organisation “International Requirements Engineering Board e.V.” (IREB e.V.) is the publisher of the curriculum for “Certified Professional for Requirements Engineering” (CPRE).

2. While the certificate “Certified Professional for Requirements Engineering” (CPRE) focuses on system requirements, the CPUX-UR certificate is concerned with user requirements.

3. The main target group for the certificate “Certified Professional for Requirements Engineering” (CPRE) is the systems engineer.

4. The main target group for the certificate “Certified Professional for Usability – Advanced Level User Requirements Engineering” (CPUX-UR) is the usability professional.

Cultural probe A special case of observation where the user observes himself and collects “probes” (traces) of his/her activity in the context of use which he/she then provides for analysis, e.g. photos, notes, sketches, and so on.

Design thinking A keyword used to describe an approach for human-centred design with a heavy focus on the development of creative ideas through teamwork.

Notes:

1. The user requirements engineer must know about design thinking so as to be able to communicate with members of a design thinking project in a professional way.

2. A comprehensive and in-depth understanding of the problem space as well as a non-restrictive creative exploration of solution ideas are at the core of design thinking. The solution ideas are then adapted to the problem context.

3. This approach emphasises three important components:

People: Multi-disciplinary collaborating teams that act fast using their collective intelligence and creating their own effective work process, thereby achieving unique results.

Places: The best environment for ideas to unfold is an open and flexible work environment with variable project rooms, movable tables and walls, a lot of space


Technical term



for visualisations and a great variety of materials for illustrating ideas, thoughts and work products.

Process: The team navigates through the solution space based on an open “error culture” following an iterative, six-stage design process (understand, observe, define point of view, generate ideas, prototype, test).

4. Design thinking is a special way of working out a solution that corresponds to the problem context. But user requirements are considered only implicitly in this approach, they are not explicitly formulated or documented for later use.

Direct user Person who interacts with an interactive system.

Notes:

1. A direct user is either a primary user or a secondary user.

Examples of direct users:

1. A customer service adviser in a call centre using a computer system is a direct user of the computer system.

2. A customer who calls the call centre is a direct user of the customer service, but an indirect user of the computer system.

Empirical information Factual information that has been collected in the context of use through contextual interviews or observations.

User need A prerequisite identified as necessary for a user, or a user group, to achieve a goal, implied or stated within a specific context of use.

Notes:

1. A user need is independent of any proposed solution for that need. In other words: A user need must not refer for example to "the system" or "the website".

2. User needs are identified based on various approaches including interviews with users, observations, user surveys, usability evaluations, expert analysis, etc.

3. User needs often represent gaps (or discrepancies) between what should be and what is.

4. User needs are transformed into user requirements which take into account the context of use, user priorities, and interaction with other system requirements and constraints.

5. User needs are different from user wants. User needs can be transformed into user requirements, whereas user wants are transformed into market requirements.

6. User needs can be divided into resource needs, informational needs and competency needs.

7. Every component of the context of use (user, task, resources, physical environment, social environment) can be a source for user needs.

8. Syntax rules for stating user needs and a technique for identifying user needs in context of use information can be found in chapter 4.1.3.

Domain-specific requirement A requirement that defines one or more characteristics used to describe task objects. The totality of all domain-specific


Technical term



requirements make up a complete and correct description of task objects from the point of view of the users.

Notes:

Domain-specific requirements are about task objects (in the sense of “complete and correct output”), organisational requirements are about people working in an organisation (in the sense of “rules for task execution”).

Examples:

1. An invoice must always state the customer’s order number. 2. A newspaper article must always contain a title and an

author. 3. The annual fee for an insurance must be calculated based

on the rules of the insurance tariff.

Focus group A focused discussion where a moderator leads a group of participants through a set of questions or statements on a particular topic.

Notes:

1. Do not use focus groups for usability evaluation. 2. Focus groups are about opinions. In comparison,

usability tests are about observing actual user behaviour.

3. Focus groups are not a substitute for contextual interviews, observations or user surveys.

4. The results of a focus group must be viewed as context of use information that must be analysed afterwards to establish user needs and derivable user requirements.

5. Conducting focus groups is especially helpful if a. a deep understanding of the problem space is

required for a specific topic thereby taking different perspectives into account,

b. ideas need to be developed, or c. requirements for the solution need to be

worked out, considering different points of view. 6. The moderated discussion focusing on one specific topic

or question results in a thorough processing by the participants and can thereby lead to the acquisition of valuable insights and knowledge.

7. A focus group is a rather expensive qualitative method that requires not only good preparation and professional execution, but also detailed recording of notes and time-consuming analysis (e.g. development of affinity diagrams).

Quality factors:

Structured process using well-chosen methods for stimulating discussion among the participants and for the collection and discussion of their ideas and thoughts

Reasonable number of participants (typically 5 to 8) that enables and fosters a lively discussion

Reasonable composition of the group (e.g. operational expertise versus the participation of laymen, or homogeneity versus heterogeneity regarding the topics and questions to be discussed)


Technical term



Observations should be performed by at least two people (whenever possible): A moderator and a note-taker

Moderation expertise, meaning organisation of the group process without giving own input, as well as handling group phenomena such as individuals dominating or leading or the tendency for groupthink (answers focused on minimising conflict and reaching consensus)

Typical procedure:

Planning:

a. Identify stakeholders who are relevant for the acceptance and processing of the focus group results (e.g. product managers and sponsors)

b. Invite stakeholders for the preparation of the focus group

c. Clearly formulate the object of interest (e.g. a product idea or a topic) and the goal to be achieved in the focus group (e.g. “What does the actual context of the user group(s) look like with regard to the product idea?” or “Understand all that is included in the topic ‘heating’.”)

d. Together with interested stakeholders, create a user group profile for each user group to be involved

e. For each user group to be involved, clarify which open questions are best suited as a starting point for the discussion

f. If any participants of the focus group do not work for the customer and consequently need to be recruited externally, create a recruitment screener to make sure that the people are actual representatives of the user group in question

g. Invite the participants to attend at the scheduled time for the duration planned (90 to 240 minutes)

h. Plan for two people to moderate, if possible (a moderator and a note-taker)

Prepare:

i. Create moderation guidelines based on the goal of the focus group and the topic in question

Perform:

j. Introduce yourself as moderator and the note-taker k. Explain to the participants the goal of the focus

group and the approach taken l. Ensure the participants and their employers that the

documentation of the focus group will be anonymised

m. Clarify the code of behaviour for the interaction between the participants and with the moderator (e.g. raise hand before speaking)

n. Present the topic to be discussed o. Ask questions according to the moderation

guidelines p. Stimulate discussion among the participants


Technical term



q. When participants make a statement, generate a short complete sentence to capture its quintessence and review it with the participants

r. Write down every statement of every participant s. When all questions have been discussed, thank all

participants and end the focus group

Document:

t. Assign each statement to a topic or question of the focus group

u. Formulate recommendations for action based on the statements

v. Include statements in context of use descriptions if reasonable

Typical mistakes regarding the procedure:

Insufficient moderation expertise (see also the quality factors), especially

a. Previous knowledge and assumptions of the moderator about the topics and questions to be discussed influence how the discussion is stimulated; the discussion might no longer be about the opinions of the participants and/or the logging of statements from the participants might be distorted

b. Insufficient control of dominating participants who are leading or shouting down other participants

People are invited who cannot report about the topic from their own experience or conscious non-experience, but rather talk about their assumptions, which are then falsely recorded as valid knowledge or arguments

The exploration phase for a topic is too short, leading to early abstractions (assumed interrelations) and to results or premature decisions without actually considering all facets of the topic

Request A user’s wish or a stipulation stated by one or more stakeholders for the interactive system.

Notes:

1. Requests are typically not requirements, but requirements can be derived from requests through analysis of the underlying context of use.

2. Customer requests for changing a product are often called “change requests”.

3. Requests are often stated as a solution proposal without stating the underlying user requirement.

4. Requests are stated in contextual interviews, either when called upon or unsolicited. They are analysed for implied user needs and derivable user requirements, just as any other context of use information.

5. The differentiation between “request” and “requirement” is helpful for the communication between those who state requests and those who have to implement requirements.

6. Requests are often descriptions of “features” that a user wishes for a product. Features requested by individuals are not necessarily solutions suitable for all users.


Technical term



Example 1:

Request: After sending an email, the email program must automatically display the folder “Sent objects” instead of the email just sent.

Potential user requirement: After sending an email with the system, the user must be able to recognise whether or not the email has been sent.

Example 2:

Request: A dishwasher for commercial use must continue to beep after finishing the washing programme until the dishwasher has been emptied completely.

Potential user requirement: Before opening the dishwasher, the user must be able to recognize that a full wash cycle has been completed.

Freedom from unacceptable risk

Extent to which the interactive system reduces the potential risk with regard to the safety and health of stakeholders, economic aspects or the environment to an acceptable level.

Notes:

Freedom from unacceptable risk is a dimension of human-centred quality. It is taken into account when specifying human-centred quality objectives. See also the examples given for freedom from unacceptable risk under “human-centred quality objectives”.

Legal / regulatory requirement A stakeholder requirement enforced by law or by a regulatory document (e.g. an ISO standard, a specification from a regulatory authority) that needs to be respected when designing an interactive system.

Examples for legal / regulatory requirements:

An employer must regularly check, if working conditions pose a threat to health (Working Conditions Act)

The principles of ergonomics are to be applied especially for the processing of information by humans (German ordinance for work with visual display units)

The manufacturer must identify known or foreseeable hazards and hazardous situations, which could affect patients, users or others, related to use of the medical device. (IEC 62366-1:2016)

Closed question An interview question that requires an answer from a predetermined set of alternatives, often simply “yes” or “no”.

Notes:

1. Avoid several closed questions in sequence. They stop users talking because they sound like a police interrogation.

2. Compare with open question.

Example of a closed question:

"Have you ever rented a car?" Corresponding open question: "Please tell me about the last time you rented a car."


Technical term



User interface guideline Specific rule or recommendation for user interface design that leaves little room for interpretation thus ensuring different designers implement it similarly.

Notes:

1. Collections of user interface guidelines are called style guides.

2. Design patterns must comply with relevant user interface guidelines.

3. Compare user interface guideline with

a. Dialogue principle – a general goal for the design of dialogues. May be difficult to apply because of its generality.

a. Heuristic – A rule of thumb that helps to achieve dialogue principles. It is more specific and easier to apply than a dialogue principle.

Examples of user interface guidelines:

1. For all controls, such as buttons, select the safest, most secure value as the default setting to prevent loss of data or system access. If safety and security are not as relevant, select the most common or convenient value.

2. The company logo must appear in the upper left corner of each page. Its position must be exactly the same as on the home page. Clicking the logo must cause the home page to be displayed.

3. The height of a button must be 23 pixels.

Immunisation trap An approach chosen unconsciously for specifying requirements, where they represent known or imagined solutions instead of being derived from user needs in the context of use, independent of any solution.

Notes:

Requirements that were specified in this way are called immunised requirements.

The specific derivation of requirements based on context of use information avoids the immunisation trap.

Examples of immunised requirements:

1. a) Immunised: The user must be able to call up the pricing system at the ticket machine. b) Not immunised: The user must be able to recognise in the system the cost of the trip, based on the chosen destination.

2. a) Immunised: The user must be able to select one of the levels 1, 2, 3, 4, or 5 on the heating valve. b) Not immunised: The user must be able to select the preferred temperature on the heating system.

Indirect user Person who directly uses the output of the interactive system, but does not interact directly with the system.

Example of an indirect user:


Technical term



A bank customer who receives a paper or electronic statement, or visits a branch is an indirect user of the output produced by the bank computer system that is used by the bank employees.

Information architect A person who creates and organises the structure of information to enable each user group to efficiently locate required information when using interactive systems.

Notes:

1. Information architect is a process role in human-centred design.

Informational need A user need for the availability of an information.

Notes:

1. Informational needs typically lead to user requirements for interactive systems, because the latter can provide the information to the user in the user interface.

2. Informational needs are often implicit and are only recognised when analysing resource needs.

Examples:

1. Shortly before his/her fixed appointment, the patient must know when the treatment is expected to begin in order to be able to make good use of the remaining time.

2. The prospective taxi passenger must know before entering the taxi how much the trip is likely to cost in order to be able to decide if he/she wants to take the taxi or use a different form of transport.

Usability evaluation – Inspection based

Usability evaluation based on the judgment of one or more evaluators who examine or use an interactive system to identify potential problems and deviations from established criteria.

Notes:

1. Inspection-based usability evaluation is often performed by usability experts or subject matter experts who base their judgement on prior experience of usability problems encountered by users and their own knowledge of ergonomic user interface guidelines and style guides.

2. Heuristic evaluation is a technique for inspection-based usability evaluation.

Interaction designer A person who defines and designs the interaction between humans and systems based on user requirements and the context of use.

Notes:

1. Scenarios and personas are also important foundations for the work of the interaction designer

2. Interaction designer is a process role in human-centred design.

Interactive system A combination of hardware, software and/or services that receives input from and communicates output to users.

Notes:


Technical term



1. This includes, where appropriate, packaging, branding, user documentation, on-line help, support and training.

Interview A data-gathering technique that studies carefully selected individuals in depth to gain a thorough understanding of the work practice of the users. Commonalities and differences among the users of an interactive system are revealed, through inquiry and interpretation.

Notes:

1. In an interview, the interviewer (the user requirements engineer) typically conducts a briefing and then asks the user questions about typical procedures with the planned interactive system in mind. The interviewer uses an interview checklist to ensure that all relevant questions are asked.

2. The master-apprentice model should be applied when conducting interviews

3. Interview questions should be:

a. open rather than closed

b. neutral rather than leading

4. Compare with contextual interview, pre-session interview and post-session interview.

Interview checklist A written list of suitable questions and cues used by an interviewer during an interview to make sure that all relevant topics are addressed.

IREB The non-profit organisation “International Requirements Engineering Board e.V.” (IREB e.V.), publisher of the curriculum for “Certified Professional for Requirements Engineering” (CPRE).

As-is scenario A variant of a context of use description in the form of a narrative text describing how users currently perform their tasks.

Notes:

1. As-is scenarios describe the current context of use and serve as a basis for identifying user needs and deriving user requirements.

2. As-is scenarios mainly describe the interplay between the components of a given context of use.

3. By describing the behaviour of a user, an as-is scenario reveals problems that cause the execution of tasks to be less efficient than it could be.

4. A description of the future interaction with one or more interactive systems is given in a use scenario (target scenario).

Example:

“John Miller is a business traveller who takes several flights in the course of a week. He prefers to take his car to the airport. But every now and then he misses a flight and then regrets not having taken a taxi or the train to the airport. Today, it happened


Technical term



again: “Again and again I just underestimate the time buffer needed because of those long car queues at the entrance to the car park and the huge walking distance to the gate.”

Kano scheme A classification model for prioritising qualitative user requirements or functions of an interactive system (that might be derived from these requirements), from the users’ point of view.

Notes:

1. In a Kano scheme, requirements are categorised by potential users in the context of a survey, using the following categories:

a. That would be nice b. That is something I require c. That makes no difference to me d. That is barely acceptable. e. That would bother me very much.

Two questions are asked for each requirement. First, the person is asked how they would answer if the requirement were implemented. Then, the person is asked how they would answer if the requirement were not implemented.

The combination of both answers leads to one of the following requirement classifications

a. Must-be quality b. One-dimensional quality c. Attractive quality d. Indifferent quality e. Reverse quality

2. The Kano scheme can be used in consolidation workshops with users.

Typical procedure:

a. Plan i. Recruit 5 to 15 representative users per user

group (participants of previously conducted contextual interviews and/or observations are good candidates, as they typically are highly motivated to understand which requirements were derived from the interviews and observations)

ii. Only invite one user group per workshop, otherwise it might happen that disagreements between user groups interrupt the workshop

b. Introduce i. Explain that tasks were identified from

contextual interviews and/or observations conducted, which are to be used as the basis for the design of the interactive system

ii. Explain that tasks were divided into subtasks iii. Explain that for each subtask it was identified

what a user must be able to do with the interactive system (recognise, select, input)

iv. Explain that the participants are now asked to identify any incompleteness or inconsistencies in the constructed information


Technical term



c. Execute: i. Read out (and explain, if necessary) each task

and its subtasks ii. After presenting a task and its subtasks, collect

feedback from the participants (Is something unclear? Is something missing? Is something wrong?)

iii. For each task, read out (and explain, if necessary) the user requirements using the subtasks as guidance

iv. Have the participants directly ask questions about a user requirement if anything is unclear

v. Present the prioritisation scheme to be used (e.g. the Kano scheme); explain how the scheme is to be applied

vi. After presenting all user requirements for one task, let the participants prioritise them. A good way of doing this is to have each participant hold up a card with a number per category. The moderator or a note-taker then counts all votes per category of the scheme.

vii. Repeat the previous step for each task to be supported by the interactive system

d. Close i. Explain that a statistical analysis of the results

will not be performed (the number of participants is typically too small. If for example a requirement falls into multiple categories, then the votes are recorded for each category)

ii. Explain that the prioritisation thus established helps decisions to be made together with the project manager about the timeline for the implementation

Competency need A user need for a required competency / skill within one user group.

Notes:

1. Competency needs typically lead to organisational requirements, the implementation of which ensures that the required competency is available for the respective user group.

Examples:

1. The baker must have the skill to produce a Frankfurter Kranz in order to be able to sell it repeatedly.

2. The ophthalmologist must have the skill to perform a cataract surgery in order to be able to bring about the desired treatment effect for the patient.

Constructed information Information that is derived from empirical information.

Notes:

1. Information that cannot be traced back to empirical information is called an “assumption”. For example it could be an assumption that bank employees would also like to sell insurance to their customers, whereas a


Technical term



context of use analysis reveals that this user group actual fears selling insurance to bank customers.

Examples:

Examples of constructed information are personas, requirements, prototypes.

Contextual interview An interview for gathering context of use information that takes place at the location where the user's interaction with the interactive system usually takes place, for example the user's workplace.

Notes:

1. The combination of “contextual interview" and “observation” is often referred to as “contextual inquiry".

2. The goal of a contextual interview is to gain a deep understanding of the context of use (users, tasks, environment, resources) and how users currently achieve their goals, which user wants play a role here and to what extent they are met, in order to gather enough information to be able to identify the user needs of the context of use. This understanding must be gained independently of any solution currently in use or asked for by the users (user wants).

3. The identification of user needs and the derivation of user requirements demands a qualitative analysis of the information.

Quality factors for the execution:

1. Mindset of the interviewer: Application of the master-apprentice model, openness, open-mindedness, curiosity, ...

2. Methodical competence: Competent preparation (creating the interview checklist), execution with mastery of basic interviewing techniques (questioning techniques like active listening, paraphrasing = repeating what was said with one’s own words, verbalising = reflecting on non-verbal or body language), as well as identification of the underlying user wants in what is said (repeatedly asking: “why”, “why”, … )

3. Domain-specific competence: A basic understanding of the respective domain, so as to be able to ask the right questions and be able to understand the answers

4. Execution of pilot interviews with feedback (training as well as testing the checklist)

5. Variants: There are unstructured, semi-standardised and standardised interviews, which differ with regard to the development, structuring and order of questions (see also observation)

6. After performing an interview, the interview checklist should be revised if necessary (for the next interview)

Typical procedure:

Plan:

a. Identify stakeholders who are relevant for the acceptance and processing of the contextual


Technical term



interview results (e.g. product managers and sponsors)

b. Invite stakeholders to join in the preparation of the contextual interviews

c. Together with interested stakeholders, create a user group profile for each user group to be surveyed

d. Together with interested stakeholders, create questions for the interview checklist for each user group to be surveyed

e. If any participants in the contextual interviews do not work for the customer and consequently need to be recruited externally, create a recruitment screener to make sure that the people are actual representatives of the user group in question

f. Meet with the interviewee at the scheduled time at his/her workplace, for the duration planned, whereby the duration may differ substantially depending on the topic (A contextual interview about “boiling eggs” might take 15 minutes, whereas a contextual interview about “follow up on unpaid invoices” might take 90 minutes)

g. Plan for two people to conduct an interview, if possible (an interviewer and a note-taker)

Prepare:

h. Tell the interviewee about the topic and goals of the interview (Topic = Collecting authentic information about the context of use; Goal = Subsequent derivation of user requirements)

i. Assure the interviewees and their employers that the documentation of the interview will be anonymised

Execute:

j. Conduct the contextual interview using the questions from the interview checklist

k. If any statement of the interviewee is not understood, paraphrase what has been said so far and ask further questions

i. If the interviewee leaves the contextual level and starts proposing solutions, let the interviewee describe those solutions and then ask in which context that solution would help, letting him/her describe that context in detail

ii. If the interviewee leaves the contextual level and starts talking about problems with an interactive system, let the interviewee describe those problems and then ask in which context these arise, letting him/her describe that context in detail

l. Write down all statements of the interviewee m. At the end of the interview, ask the interviewee if

there are any further topics or statements he/she would like to address beyond what has been talked about and record any further statements

n. End the interview; if necessary, interviewer and note-taker should talk about the interview to check if anything needs to be optimised before the next interview


Technical term



Document:

o. Write down the statements of the interviewee as a coherent text (as-is scenario) so that stakeholders get a comprehensive overview of the context of use for the interviewee without any need for further enquiry.

p. The as-is scenario can be structured in line with the central questions of the contextual interview. This helps stakeholders to compare statements across interviews later on. The context of use description can be structured without reference to the central questions.

Typical mistakes regarding the procedure:

a) The interviewer sticks to the interview checklist (content and order of questions) instead of adapting to what is learned during the interview

b) The interviewer himself changes the level of the interview (context of use, user needs, user requirements, solutions) when paraphrasing

c) The interviewer repeats literally what is said (“parroting”) instead of checking if the statement of the interviewee was understood by paraphrasing it

d) The interviewer adds constructed contextual information e) The interviewer asks leading questions and closed

questions, and does not follow the master-apprentice model

Lean UX A keyword used to describe an approach for human-centred design that is based on a combination of different approaches (agile development, design thinking, lean startup) and tries to integrate principles and methods for usability and user experience into agile development, thereby achieving economic advantages from a cost-benefit perspective. Notes: 1. The user requirements engineer must know about Lean

UX so as to be able to communicate with members of a Lean UX project in a professional way.

2. Agile development processes are the basis for Lean UX, as the iterative approach in teams and the realisation of small, well-defined packages makes it possible for small and quick tests to be regularly carried out. The results from tests are then directly used in the next iteration (called “sprint”) for the further development. See also SCRUM.

3. Design thinking is the basis for Lean UX, as it helps project members to incorporate the users’ perspective into the development process through its solution-oriented way of thinking based on an in-depth understanding of the problem context.

4. Lean startup is the basis for Lean UX, as it suggests that at first, everything is a hypothesis and consequently needs to be validated. The team learns through experiments about the user and the market. Failure is part of the learning process - not every hypothesis is validated, not every experiment provides the desired results.


Technical term



5. A model-based context of use analysis is a suitable starting point for Lean UX: Instead of doing extensive user research upfront as in the classic context of use analysis, hypotheses to be validated are derived from known context of use information (e.g. from stakeholder interviews) and then validated or questioned in contextual interviews, observations or focus groups.

Solution One or several related product characteristics that are specified or implemented and are supposed to fulfil one or more requirements.

Solution space Collective term for user requirements and solutions that fulfil the user needs for reaching the user’s goals.

Notes:

1. User requirements are part of the solution space from the user’s perspective, as they are formulated with respect to an interactive system supporting them.

Market requirement A requirement for an interactive system based on the marketing policy of the supplier aimed at maximizing business opportunities, purchase and use of the interactive system.

Notes:

1. Market requirements are often referred to as customer requirements.

Example of market requirement:

1. "The website must be at least as usable as those of the two strongest competitors"

Master-apprentice model A behavioural principle for a successful interview: The interviewer treats the user as the master while the interviewer is the apprentice. The interviewer asks because they sincerely want to learn – not to demonstrate their knowledge

Human-centred design An approach to design that aims to make interactive systems more usable by focusing on the use of the interactive system and applying occupational science, ergonomics and usability knowledge and techniques.

Notes:

1. The concept "human-centred design" is used instead of "user-centred design" to emphasise the need to consider additional stakeholders who may not be users.

2. Feedback from users through usability evaluation is a critical source of information in human-centred design.

Mental model (of a user)

The perception people have of themselves, others, the environment, and the things with which they interact.

Notes:

1. Alternative, popular definition: A person's thought process about how something works in the real world.

2. People form mental models through experience, training, and instruction. The mental model of an interactive system is formed largely by interpreting its perceived actions and its


Technical term



visible structure. Expectations resulting from the use of other or similar systems are also of importance.

3. If a user's mental model of an interactive system is incomplete or contradictory, then the user cannot easily use the interactive system.

4. Disclosed mental models are an important source for identifying user needs. Example: The users of a dishwasher in an office think that it is always emptied by someone who has been charged with doing this once the wash cycle has finished. Therefore they carelessly load new dirty dishes into the dishwasher without checking if there might still be clean dishes inside.

User need: “The user must know if the dishes in the dishwasher are clean or dirty in order to avoid that clean and dirty dishes get mixed up.”

5. Mental models can be captured in contextual interviews by using the “teaching back” technique: The interviewee is asked to explain (“teach”) to the interviewer how he/she goes about performing tasks with the interactive system and how the system is operated.

Moderator (Context of use analysis)

A person who performs a contextual interview, an observation, or a focus group.

Notes:

1. Moderator is a role in a usability test session or focus group session.

2. The moderator's tasks during a usability test session are described under usability test session.

Facilitator is a frequently used synonym for moderator.

Neutral question A question in an interview that has no built-in assumptions, and no frame that excludes anything or directs the reply in a certain direction.

Notes:

1. Compare with leading question.

Examples of neutral (and open) interview questions:

1. What happened? 2. What do you mean by that? 3. What options do you have now? 4. What should the home page of the new car rental website

look like?

User requirement (qualitative) A statement of what users must be able to locate, recognize, understand, select or input as part of performing a task with the interactive system.

Notes:

1. Qualitative user requirements are the basis for efficient use of the interactive system. In contrast, quantitative user requirements can enable the efficiency of the interactive system to be measured –


Technical term



that is, whether users can solve particular tasks with the interactive system, e.g. in an acceptable time or with a specified maximum number of use errors.

2. Qualitative user requirements are not features. They provide the basis for features.

3. Compare with quantitative user requirement 4. For each qualitative user requirement, it must be possible

to trace it back to the underlying user needs and corresponding context of use information (“Traceability”). Compare with chapter 5.1.3, Table 3: Context of use descriptions with identified user needs and derived user requirements.

5. Qualitative user requirements are specified with the aid of the following elements:

User group

Type of usage (recognise, select, input)

Special condition(s) of the context of use for which the user requirement is relevant

6. Sources of qualitative user requirements

The direct source is always one or more user needs.

Indirect sources: o Human-centred quality objectives o Legal / regulatory requirements o Market requirements o Organisational requirements o Requests o Identified or anticipated problems with usage o Dialogue principles and heuristics that are used

for the specification of user requirements 7. Syntax rules for stating user requirements and a

technique for the derivation of qualitative user requirements from user needs can be found in chapter 5.1.3.

Examples:

1. Reasonable qualitative user requirements:

a. "The user must be able to compare the different cars that are available within a specific price range on the car rental website."

b. "The user must be able to select a car with automatic transmission on the car rental website."

c. "The user must be able to see the opening hours of a specific car rental office."

2. Incorrectly formulated qualitative user requirements:

a. "The user interface must be usable and support all user tasks" (too general)

b. "The user interface must have a big, red "Rent this car" button" (describes a solution)

User requirement (quantitative) Required level of usability to meet identified user needs expressed in terms of effectiveness, efficiency and user satisfaction in a specified context of use.

Notes:


Technical term



1. Quantitative user requirements are acceptance criteria for the effectiveness, efficiency and user satisfaction of the interactive system, for example whether users can solve a particular task with the system in an acceptable time or with a specified maximum number of use errors.

2. Compare with qualitative user requirement. In particular, compare the examples.

3. The elements of a quantitative user requirement

The stakeholder who issued the requirement (e.g. employer or legislator)

User group(s) concerned who have to fulfil the requirement during use

The number or percentage of users who have to fulfil the requirement

Object of use (task object (in the user interface), tool)

Quantities (e.g. maximum available time, error rate, precision)

Special condition(s) of the context of use under which the use takes place

4. Sources of quantitative user requirements

Quantitative user needs in the context of use (e.g. “The patient must close his/her eye within 60 seconds in order to have enough moisture on the retina.”)

Stakeholders who define acceptance criteria for the usability of an interactive system (e.g. for a usability test)

Examples:

1. "80% of users who have used the car rental website at least twice must be able to rent an economy size car within 5 minutes from Frankfurt Airport (Germany) for two days starting tomorrow at 09.00."

2. Compare the above example with the examples for qualitative user requirement.

Context of use Users, tasks, resources, and the physical and social environment in which an interactive system is used

Notes:

1. The results from observations and contextual interviews are described in the "context of use description". This description is the basis for identifying user needs and tracing them back to the context of use.

2. A context of use description contains: a) Outline context of use description

a. User groups and user group profiles, b. Tasks c. Environment(s), d. Resources

b) Detailed context of use description

a. Scenarios illustrating what happens in the context of use

3. The part of the context of use that is used as a basis for the design of an interactive system is called the context of use for design.


Technical term



4. There are different forms of notation for context of use information. See context of use description

Course note:

1. Helpful acronym: PACT = People, Activities, Contexts, Technologies

Examples:

1. Teenagers (user) use their mobile phones (interactive system) to hear (task) text messages from their friends (social environment) with earphones (resource) when they are on a bus (physical environment).

2. Secretaries (user) in a school (social environment) use Microsoft Word (interactive system) to create certificates for students and sign them (task) with a stamp (resource). This work happens in the school office (physical environment).

Context of use for design A subset of the context of use is used as a basis for the design of an interactive system and it is called the context of use for design.

Examples of context of use information that is not used for the design:

A differentiation between men and women as users is not considered when designing the interactive system.

“Silver surfer” as a possible user group for a mobile app is not considered in the design.

Using the interactive system “on the road” via mobile device is not considered in the design.

Context of use analysis Process of planning, gathering and documentation of authentic context of use information, identifying user needs contained therein and specifying user requirements.

Possible approaches for context of use analysis are “classic context of use analysis” and “model-based context of use analysis”.

1. Classic context of use analysis:

A systematic approach to context of use analysis where, first, context of use information is collected without making any assumptions and then user needs and derivable user requirements are identified.

2. Model-based context of use analysis:

An approach to context of use analysis where open questions about the context of use are collected based on

known context of use information,

given task models,

known user requirements and use scenarios and/or

existing prototypes.

Empirical information about the context of use is then gathered in a focused manner with the help of these open questions, using contextual interviews and/or observations.


Technical term



Notes:

1. The main difference between classic context of use analysis and model-based context of use analysis is that the interview checklist contains more specific questions for the latter and that task models and user requirements are partly assumed to be known.

2. The more empirical context of use information is already available to the project team, the more sense it makes economically to do a model-based context of use analysis. See also Lean UX.

3. The less empirical context of use information is available, the more risky it is to take the model-based context of use analysis approach when taking the immunisation trap into account.

4. Collected context of use information can be made available to project members via different forms of notation for documentation of the context of use, as presented in chapter 3.3.3.

Context of use description A description of the context of use containing the components users, goals, tasks, physical environment, social environment and resources.

Notes:

There are two types of context of use descriptions:

a) High-level context of use description

Notes for high-level context of use description:

1. High-level context of use descriptions contain keywords for the user groups of an interactive system, their tasks, their resources and their physical and social environment.

2. Typically at the beginning of a project, high-level context of use descriptions contain what is already known about the users and their tasks (without having performed any context of use analyses). For a model-based context of use analysis, this is usually the starting point.

3. High-level context of use descriptions are especially helpful for the planning of context of use analyses. However, they are not a substitute for detailed context of use descriptions.

4. After performing context of use analyses, high-level context of use descriptions can be used to communicate a summary of the results to stakeholders.

b) Detailed context of use description

A detailed context of use description is a coherent description of the users, their goals and tasks, resources and their physical and social environment, which is typically written in narrative form.

Notes for detailed context of use description:

1. Detailed context of use descriptions are typically documented in narrative form, from which structured (model-like) descriptions are derived. Known forms of documenting contexts of use are:


Technical term



a. Narrative descriptions i. As-is scenarios as a description of how

users or personas behave when performing their tasks

ii. Personas as a personalised illustration of users within a user group

b. Structured (model-like) descriptions i. User group profiles describe important

characteristics of user groups ii. Task models and task objects describe the

structure of tasks and subtasks as well as the actual object of the task execution

iii. Affinity diagrams describe semantic structures as seen by users

iv. User journeys describe the expectations, behaviour and emotions of users across all touchpoints with the interactive system

v. Goal catalogues describe different goals relevant for a specific user group

vi. Models of the environment (social and physical) describe important characteristics of those environments

vii. Information models (information objects) describe the informational structure of a task model and the task objects.

2. Detailed context of use descriptions provide people who did not participate in contextual interviews or observations with a comprehensive overview of the context of use without any need for further enquiry.

3. Detailed context of use descriptions enable the structured identification of user needs and the derivation of user requirements.

4. Detailed context of use descriptions are best suited for the structured identification of user needs and the derivation of user requirements. Structured (model-like) descriptions are best for the communication of context of use information to stakeholders or for identifying missing or incomplete context of use information.

Context of use information Fragment of a context of use description containing user needs.

Notes:

1. Every user need is based on at least one specific piece of context of use information.

2. A single piece of context of use information does not replace a (coherent) context of use description.

Example:

In an observation at the airport in Munich, one finding was that the majority of passengers arriving at the airport use the suburban train to leave the airport.

This piece of context of use information is a fragment of a context of use description containing the user need “After arrival, a passenger needs to have a valid ticket for the


Technical term



suburban train so that he/she can legally reach his/her final destination.”

Task object (user interface) The most important units of information or data with which users interact in order to carry out their tasks.

The representation of a task object in the user interface, usually extended or reduced to those properties that seem relevant based on the user requirements.

Notes:

1. It is important for the user requirements engineer to understand the difference between a task object and the task object in the user interface, in order to be able to communicate with the user interface design team in a targeted way. Given task objects can be suboptimal for the user when performing tasks. User requirements need to be taken into account when transforming task objects into task objects in the user interface for system design. The user requirements are used for the specification of task objects in the user interface to ensure effectiveness, efficiency and user satisfaction when using the interactive system.

Examples of task objects in the user interface:

1. For a customer management system:

A letter to a customer

A list of the customer's unpaid bills

An order from the customer 2. For a train ticket vending machine:

A ticket

A receipt for the purchase of a ticket

A travel plan 3. Examples of software:

A list of the customer's unpaid bills, represented in an invoice tracing system with important information (“unpaid”) highlighted

An order from a customer, represented in an order management system with necessary information (e.g. “new order”)

A letter to a customer, represented in a text processing system with the address prefilled

4. Examples of hardware:

In a train ticket vending machine, the ticket created with the machine is the task object. A preview of the ticket together with a display of the validity date and the possibility to print it is the task object in the user interface.

When using a surgical microscope, the organ that is treated is the task object. The display of the organ in the microscope together with additional information is the task object in the user interface.

Human-centred quality The degree to which the interactive system fulfils stakeholder requirements.


Technical term



Notes:

1. Human-centred quality consists of the quality dimensions usability, accessibility, user experience and freedom from unacceptable risk.

2. Human-centred quality is an important aspect of overall quality, together with technology-centred quality.

3. Human-centred quality is the aspect of quality recognised by users and other stakeholders when interacting with the interactive system, whereas technology-centred quality provides the basis for it.

4. While human-centred quality is the result of implementing stakeholder requirements, technology-centred quality is the result of implementing system requirements.

Use scenario (Target scenario) Description of how a user performs tasks with the future interactive system.

Notes:

1. The creation of use scenarios is not part of the CPUX-UR curriculum. However, it is important that the user requirements engineer understands that there are two types of scenarios, the as-is scenario and the use scenario.

2. Use scenarios are based on task models used for design and user requirements per task or subtask.

3. Use scenarios can be described in different forms (narrative text, table, diagram).

4. Use scenarios are used to create low-fidelity prototypes.

Example of a use scenario in narrative form:

“Before John Miller decides which means of transportation to use to get to the airport, he checks the situation at the car park at the airport on his mobile device with the new app from the airport company. If there are sufficient parking spaces available, he reserves a parking lot with his new app and then drives in a carefree manner to the airport with his car. He is not worried about any car queues at the car park entrance, because when the app was launched a separate entry was created for cars with reservations.”

Open question A question in an interview that does not give any indication of the expected format or content of the answer.

Notes:

1. Open questions should be favoured in interviews because they invite users to start talking and to provide extensive answers to questions.

2. Compare with closed question.

Examples:

1. For examples of open (and neutral) interview questions see neutral question.

Organisational requirement An organisational rule that users have to follow when performing their tasks.

Notes:


Technical term



1. Organisational requirements are often requirements for the users that originate from requirements for the interactive system or that lead to requirements for the interactive system.

2. Organisational requirements formulate rules about how users are to perform their tasks, e.g. “The radiological assistant must keep an eye on the patient while adjusting the patient table.”

3. In practice, the term “business requirement” is sometimes used. While business requirements provide the rationale for why an interactive system is to be created or purchased for the organisation, organisational requirements are requirements that have to be implemented within the project and are relevant for the operation of the interactive system.

Examples:

1. A salesperson must have a written approval from the director for quotes that exceed EUR 100,000.

2. An exact description of how a user must handle an order.

Persona A description of a user and what he or she intends to do when using an interactive system.

Notes:

1. Personas are not real; rather they are examples invented to represent real users based on empirically determined data, for example from observations or interviews.

2. Personas typically have a name, age, some background information, goals and desires. A persona description should include information about the persona's knowledge about and interest in the subject matter of the interactive system. Persona descriptions often but not always include a photo.

3. Personas provide a “face” for the users, so that all project members have a good idea of who the users of the interactive system will be, which characteristics they have, what motivates them and what goals they have.

4. There are primary and secondary personas. Primary personas represent the main target user groups, whereas secondary personas provide insight into further goals or characteristics that are also relevant for the derivation of user requirements but would overload the descriptions of primary personas.

5. Personas based on assumptions are called proto-personas. Lean UX uses proto-personas. They can be used as a starting point for a model-based context of use analysis.

6. So-called anti-personas can be used to represent users for whom the interactive system is explicitly not designed.

Quality factors for the development of personas:

1. A persona is created by those people who performed the context of use analysis.

2. The persona description does not represent a real person, but is equivalent to the description of a real person.

3. The persona combines characteristics of real users. 4. The persona description contains all important

characteristics and the most important goals.


Technical term



5. The basis for a persona must be empirical data, it must not be purely imaginary.

6. Proto-personas must be clearly labelled as such. 7. The number of personas should be 2 to 5 maximum, to be

able to efficiently work with them. 8. Personas as representations of real users must be checked

regularly and modified if necessary, as the context of use can change over time.

9. The responsibility for the creation, quality and maintenance of personas lies with the product team, even if the personas were initially created by others (e.g. an agency). It must be assured that all context of use information on which the creation and maintenance of personas is based remains available to the product team.

Primary user A person who interacts with an interactive system to achieve goals supported by the system.

Prioritisation An activity which involves determining if and when a requirement is implemented.

Notes:

1. Prioritisation should always first be done with respect to the human-centred quality objectives (how relevant is the implementation of requirements with respect to the users?) before considering other stakeholders.

2. The Kano scheme is well-suited for prioritisation with respect to the users.

3. A typical prioritisation scheme for the implementation of requirements is:

a. to be implemented in the current product version b. to be implemented in the next product version c. for future consideration d. out of scope

4. Requirements that are not going to be implemented in the current product version are included in the product roadmap.

Problem space Collective term for the context of use and the user needs for reaching user goals contained therein.

Notes:

1. User needs for reaching user goals that are not fulfilled mainly lead to requirements for the interactive system.

Product owner A role in a SCRUM project. The product owner is a specific variant of the role product manager in SCRUM projects.

Notes:

1. The product owner is responsible for the characteristics and the economic success of a product. He/she designs the product with the goal of maximising the economic value for his/her own company. He/she creates, prioritises and explains the product characteristics to be developed and he/she decides which characteristics have been completed at the end of a sprint. He/she is a person, not a committee. He/she alone is responsible for decisions about the product, its characteristics and the order of implementation.


Technical term



This way, he/she balances characteristics, delivery dates and costs.

2. The user requirements engineer must know about the meaning of the term product owner so as to be able to communicate with members of a SCRUM project in a professional way.

Product management Discipline in product development concerned with the planning and control of a product from its creation to its withdrawal from the market with the goal of reaching a result that is in line with market demands.

Notes:

1. Product management deals with product development across multiple release cycles, whereas project management always operates within one release cycle.

2. One part of product management is the management of stakeholder requirements (and corresponding user requirements) across product releases.

Product manager A role in product management typically responsible for the planning and control of a product from its creation to its withdrawal from the market.

Notes:

1. The user requirements engineer must know about the meaning of the term product manager so as to be able to communicate with product managers in a professional way.

2. The product manager is responsible for the gathering, documentation and management of stakeholder requirements as well as for the quality of their implementation, in contrast to the project manager who is responsible for achieving the next product version within a certain time period.

3. The derivation of user requirements is typically performed by the user requirements engineer as a service for the product manager.

Product roadmap A representation of how a product is supposed to develop across releases in defined time periods with regard to its functionality.

Notes:

1. Product roadmaps are used for communication between the disciplines product management, requirements engineering and systems engineering, as well as with management, in order to build a common understanding of the long-term product plan and the activities associated with that plan.

Project management Discipline in product development concerned with initiating, planning, controlling and finishing projects.

Notes:


Technical term



2. Part of project management is the planning of human-centred design activities such as context of use analysis and the specification of user requirements.

Project manager A role in project management typically responsible for initiating, planning, controlling and finishing projects.

Notes:

1. The user requirements engineer must know about the meaning of the term project manager so as to be able to communicate with product managers in a professional way.

2. The project manager is typically responsible for achieving the next product version within a certain time period, whereas the product manager is responsible for the success of the product in the market across several product versions.

3. The usability engineer plans and consults the project manager on the human-centred design activities such as context of use analysis and the specification of user requirements.

4. The user requirements engineer is the expert contact for project managers regarding this topic.

Note-taker (Context of use analysis)

A person who makes notes about statements and observations during a contextual interview, an observation or a focus group.

Notes:

1. The use of a note-taker allows the moderator to fully concentrate on the execution of the contextual interview, observation or focus group.

Quality The degree to which the interactive system fulfils requirements.

Notes:

1. The term quality covers the fulfilment of stakeholder requirements (human-centred quality) as well as the fulfilment of system requirements (technology-centred quality).

2. Examples of quality dimensions for human-centred quality are usability, accessibility, user experience and freedom from unacceptable risk. Examples of quality dimensions for technology-centred quality are correctness, reliability and maintainability.

Recruitment screener A series of questions for prospective participants to identify whether they represent the intended users and therefore qualify to participate in a human-centred activity, for example a usability test or a focus group.

Notes:

1. A recruitment screener is used during recruiting to determine whether candidates have the required qualifications to participate in the human-centred activity.


Technical term



2. Relevant qualifications include: Background, knowledge of the subject matter, attitudes and interests.

Requirements engineering Discipline concerned with the systematic specification and management of stakeholder requirements and system requirements.

Notes:

1. In requirements engineering, projects do not always make an explicit distinction between stakeholder requirements and system requirements.

2. The term “user requirement” and the professional field of “user requirements engineering” have been supported by the increasing importance of the quality dimensions usability and user experience for the development of interactive systems.

3. The role “requirements engineer” has long been found in development projects. He/she is typically focused on system requirements for the development of interactive systems. As the importance of user requirements becomes more and more evident, projects are seeing the need for the role of a “user requirements engineer”, sometimes also called “user researcher”.

4. “User requirements engineering” is a subdiscipline of “usability engineering” and at the same time a subdiscipline of “requirements engineering”.

Resource All means required to use an interactive system.

Notes:

1. Typical examples of resources are time, financial cost, physical and mental effort, hardware, software and materials.

2. Resources can be divided into - Inexhaustible resources, e.g. equipment, information,

support - Exhaustible resources, meaning not immediately or not

easily replaceable, e.g. available time, physical and mental effort, financial resources, materials.

3. Equipment as part of resources includes hardware, software and physical objects that are used by the user in combination with the interactive system to perform a certain task. The interactive system itself is not part of the equipment.

4. User groups are sometimes differentiated through the resources available to them.

Resource need A user need for the availability of a resource.

Notes:

1. Resource needs typically lead to organisational requirements to ensure that the required resources are available to the respective user group.

2. Resource needs help to identify informational needs, which in turn typically lead to user requirements for interactive systems.


Technical term



Examples:

1. The patient (user group) must have a fixed appointment (resource) in order to be able to get treatment at a fixed point in time (goal).

2. The prospective taxi passenger (user group) who spontaneously needs a taxi must have a taxi available in his/her vicinity (resource) in order to be able to reach his/her destination in time (goal).

Risk Combination of the probability of occurrence of harm and the severity of that harm.

Notes:

1. Harm is defined as physical injury or damage to the health of people or damage to property or the environment.

SCRUM A management system for agile project management that is used in software development; its roles and processes support performing requirements management in parallel with development.

Notes:

1. The user requirements engineer must know about the meaning of the term SCRUM so as to be able to communicate with members of a SCRUM project in a professional way.

2. In the SCRUM framework, the user requirements engineer delivers to the product owner. He/she delivers user requirements and task models as a basis for the product backlog (see note 4).

3. SCRUM is explicitly called a framework and not a process model, as it consists of only a few rules. These rules define five activities, three artefacts and three roles, which are at the heart of SCRUM. The rules are defined in the “agile atlas” or “SCRUM guide”.

4. The five activities in SCRUM are:

1. Sprint planning

1.1. Sprint planning, topic 1: What can be done in this Sprint?

1.2. Sprint planning, topic 2: How will the chosen work get done?

2. Daily SCRUM

3. Sprint review

4. Sprint retrospective

5. Product backlog refinement

5. The three artefacts in SCRUM are:

1. Product backlog The product backlog is an ordered list of requirements for the product. The product backlog is dynamic and constantly changing. All work done by the development team must have its origin in the product backlog. The product owner is responsible for the maintenance of the product backlog.


Technical term



He/she is responsible for the ordering / prioritisation of items.

2. Sprint backlog The sprint backlog is the plan for the tasks to be performed in the current sprint. It includes the product backlog items selected for the sprint and the tasks necessary to implement them. A task board is often used to visualise the sprint backlog.

3. Product increment The product increment is the sum of all the product backlog items completed during the current sprint and all previous sprints. At the end of a sprint, the new product increment must be in a useable condition and meet the SCRUM team’s definition of “Done.”

6. The three roles in SCRUM are:

1. Product owner The product owner is responsible for the characteristics and the economic success of a product. He/she designs the product with the goal of maximising the economic value for his/her own company. He/she creates, prioritises and explains the product characteristics to be developed and he/she decides about which characteristics have been completed at the end of a sprint. He/she is a person, not a committee. He/she alone is responsible for decisions about the product, its characteristics and the order of implementation. This way, he/she balances characteristics, delivery dates and costs.

2. Development team The development team is responsible for the delivery of product functionality in the order requested by the product owner. Moreover, it is responsible for compliance with the standards agreed upon. The development team organises its own work. Nobody, not even the SCRUM master, is allowed to direct the development team how to implement backlog items.

3. SCRUM master The SCRUM master is responsible for the success of SCRUM. He/she works closely together with the development team, but is typically not a member of the team. He/she introduces the SCRUM rules and checks for compliance with those rules, moderates the meetings and takes care of any disturbances and impediments. This includes lack of communication and cooperation as well as personal conflicts in the development team, disturbances in the cooperation between product owner and development team and disturbances from the outside, e.g. requests from departments for additional tasks during a sprint.

Secondary user A person who interacts with an interactive system to support the use of the system or maintain the system.

Examples of secondary users:

1. Security officer 2. Administrator 3. Trainer


Technical term



4. Service technician

Sponsor Stakeholder who provides the budget for the development project.

Notes:

1. The sponsor decides on the budget for human-centred design activities such as the gathering and documentation of context of use information or the specification of user requirements.

2. The sponsor (or his/her representative) may be involved in the development of interview checklists for context of use analyses. The user requirements engineer is the expert contact regarding this topic.

3. Other stakeholders in development projects are for example:

Users Product owner (in SCRUM projects)

Product manager

Project manager

Stakeholder Individual or organisation having a right, share, claim or interest in an interactive system or in its possession of characteristics that meet their needs and expectations.

Notes:

1. All users are stakeholders. 2. See also the various types of requirements. 3. The following examples illustrate the breadth of this

concept.

Examples of stakeholders:

1. Users 2. Support staff 3. Trainers 4. Documentation writers 5. Developers 6. Development managers 7. Marketing staff 8. Sponsors

Stakeholder requirement What the interactive system should be capable of from the point of view of the stakeholders.

Notes:

1. Stakeholder requirements can be classified as follows:

Legal / regulatory requirements (stakeholder is “Legislator”)

Market requirements (stakeholder is “Purchaser / Purchase decision maker”)

Organisational requirements (stakeholder is “Management of the organisation”)

Functional requirements (stakeholder is “indirect user”, i.e. a user of the work products that were created by the direct user using the interactive system)


Technical term



User requirements qualitative: (stakeholder is “direct user”) quantitative: (stakeholder is from one or more of the stakeholder groups mentioned above)

2. Stakeholder requirements from one category can lead to further stakeholder requirements in other categories.

3. Requirements for the interactive system are formulated so as to implement the stakeholder requirements. (see system requirements)

4. The degree to which stakeholder requirements are implemented determines the human-centred quality of the interactive system.

Leading question A question in an interview that signals a preference for certain answer options, or attempts to guide the answer in a certain direction.

Notes:

1. Compare with neutral question.

Example of a leading question:

"Would you like to have pretty colours on the home page of the new car rental website?" Corresponding neutral question: What should the home page of the new car rental website look like? Note that the neutral question doesn't even mention colour.

System requirement A requirement describing what the interactive system must be capable of in order to technically implement one or more stakeholder requirements.

Notes:

1. System requirements are always derived from stakeholder requirements.

2. System requirements are not technical solutions. They are the basis for technical solutions.

3. System requirements are the basis for the technical solution whereas user requirements are the basis for the user interface (without considering any required technology).

4. It is not the job of the user requirements engineer to specify system requirements. Deriving system requirements from user requirements is the job of systems engineering.

Example of a system requirement that can be derived from a user requirement:

User requirement: “The user must be able to recognise in the system, which customers have not been heard from for longer than average.”

Resulting system requirement: “The system must calculate the average time between two orders for each customer.”


Technical term



Systems engineering Discipline in product development responsible for the technical implementation of an interactive system.

Notes:

1. Systems engineering is responsible among others things for the implementation of system requirements that have been derived from stakeholder requirements.

2. Project team members working on the technical implementation of the interactive system are part of systems engineering.

3. The user requirements engineer is the expert contact for systems engineering regarding user requirements.

Diary study A special case of observation: The user observes himself and writes a diary. The diary typically must comply with stipulations regarding the frequency with which self-observation must take place, observation categories and criteria and the form of documentation.

Technology-centred quality The degree to which the interactive system fulfils system requirements.

Notes:

1. Technology-centred quality is an important aspect of overall quality, together with human-centred quality.

2. While technology-centred quality is the result of implementing system requirements, human-centred quality is the result of implementing stakeholder requirements.

3. Technology-centred quality is often considered a matter of course by users. The user of a washing machine for example assumes unconsciously that the laundry will get clean and that the machine’s clock shows the right time of day.

4. Technology-centred quality consists of the quality dimensions

a. functional appropriateness

b. technical performance

c. interoperability

d. reliability

e. security

f. maintainability

g. portability

Subtask Activity or decision made within a task that is necessary to reach a goal.

Notes:

1. Subtasks are components of the task model. 2. Subtasks are the basis for the interaction of the user with

the interactive system (recognise something, select something, input something) They are described independently from the actual interaction with the interactive system.


Technical term



Example of a subtask:

“Decide upon a suitable means of transportation for reaching the destination”

Example of a resulting interaction with the system:

“recognise in the system available means of transportation for reaching the destination, with departure time, arrival time and cost”

Environment The entirety of given circumstances or conditions under which a user performs his/her tasks. This includes the physical, social and technical environment.

Notes:

1. The social conditions include the organisational conditions.

Usability tester A person who evaluates user interfaces in various stages of realisation.

Notes:

1. In cooperation with other stakeholders, the usability tester

a. plans usability evaluations,

b. performs usability evaluations,

c. communicates usability findings to stakeholders.

2. During usability test sessions, the usability tester has the role of moderator or note-taker.

3. Usability tester is a process role in human-centred design.

Usability evaluation A process through which information about the usability of an interactive system is gathered in order to improve the interactive system (known as formative usability evaluation) or to determine the merit or worth of an interactive system (known as summative usability evaluation).

Notes:

1. Usability evaluation is a common term for

a. Usability evaluation - Inspection based

b. Usability evaluation – User based

2. The synonym "Evaluation" is also often used.

Usability test A usability evaluation that involves representative users performing specific tasks with the interactive system to enable identification of usability problems or the measurement of effectiveness, efficiency, and user satisfaction.

Notes:

1. A usability test is managed by a usability tester.

2. A usability test usually has three phases:

a. Planning, including writing the usability test plan, writing the usability test script, and recruiting suitable usability test participants


Technical term



b. Performing usability test sessions as described in note 3

c. Communicating usability findings, including writing the usability test report

3. A usability test consists of a number of usability test sessions. In each session, a usability test participant attempts to carry out representative usability test tasks using the interactive system or a prototype of the interactive system. Usually, usability test sessions are moderated by a moderator and observed by a number of observers, who are often stakeholders. A note-taker records important usability findings.

4. The concept "usability test" usually refers to a test where the usability test participant and the moderator are in the same physical location. Other forms of usability tests are remote usability test and unattended usability test.

5. Testing may result in qualitative or quantitative data.

6. Testing may occur at any time during human-centred design, from early analysis to interactive system delivery and beyond. Testing may be based on paper sketches or display mock-ups, as well as on interactive systems under design and completed interactive systems.

7. Roles in a usability test are:

a. Moderator

b. Note-taker

c. Observer

d. Usability test participant

User interface designer A person who creates interactive prototypes and implements the dialogue and user experience based on the design created by the interaction designer and the use scenarios created by the user requirements engineer.

Notes:

1. User interface designer is a process role in human-centred design.

User journey A technique used to create a description of all “encounters” of the user with the interactive system across all touchpoints where user experience occurs, making the overall user experience tangible for others.

All touchpoints are considered, extending from the first contact with the interactive system (e.g. “how did I hear about this new interactive service”) and the direct task-oriented interaction to communicating about the user experience with others (e.g. a report to colleagues about my experience with the new system).

A user journey is visualised using a user journey map.

Notes:

1. Besides depicting as-is scenarios and/or use scenarios, user journey maps can be used as a general communications medium to exemplify scenarios for


Technical term



stakeholders that extend beyond the actual use (e.g. from the discovery of the product to the purchase situation to the usage of the product).

2. User journey maps do not replace as-is scenarios and/or use scenarios.

User requirements engineer A person who identifies and describes the actual or intended context of use of users and derives the user requirements and related organisational requirements that need to be implemented for a specific project.

Notes:

1. The user requirements engineer identifies the context of use based on methods such as interviews with users, observations, user surveys, usability evaluations, expert analysis, etc.

2. The user requirements engineer generates personas and use scenarios designed to ensure effectiveness, efficiency and user satisfaction when tasks are performed with the interactive system.

3. User requirements engineer is a process role in human-centred design.

4. The role “user requirements engineer” is responsible for the execution of the following activities and the creation of corresponding work products:

Plan context of use analysis

Recruit users

Identify the context of use by applying user research methods

Create context of use descriptions

Identify user needs in context of use information

Derive user requirements from user needs in the context of use and other stakeholder requirements

Derive further stakeholder requirements from user requirements

Structure user requirements based on the task model

Prioritise and validate user requirements

User research User research incorporates all activities during analysis, design and usability evaluation of interactive systems where information is gathered together with users about

- the context of use, - wishes, likes and dislikes and - usage problems

when using the interactive system. User needs are then identified in this information and user requirements are derived.

Notes:

1. The user requirements engineer must know about the meaning of the term user research so as to be able to communicate with people using the term in projects in a professional way.

2. Context of use analysis and the derivation of user requirements are key components of user research.

3. Usability testing is also a key component of user research.


Technical term



Validation Process of determining whether all stakeholder requirements have been effectively implemented from the perspective of all stakeholders.

Notes:

1. The goal of validation is to ensure that all stakeholder requirements have been effectively implemented from the perspective of stakeholders, whereas the goal of verification is to determine if all requested stakeholder requirements and system requirements have been implemented in general or as specified.

2. A usability test for explicitly checking if user requirements have been implemented is a validation.

Verification Process of determining if all requirements are supported by a suitable product characteristic.

Notes:

1. The goal of verification is to determine if all requested stakeholder requirements and system requirements have been implemented in general or as specified, whereas the goal of validation is to ensure that all stakeholder requirements have been effectively implemented from the perspective of stakeholders.

2. An inspection-based usability evaluation is a verification if it explicitly checks for the fulfilment of inspection criteria such as user requirements and/or design rules.

Goal Intended outcome.

Notes:

1. Intended outcomes exist for tasks as well as for subtasks within a task.

2. The intended outcome of a subtask is also called a subgoal.

3. The intended outcome can be an observable postcondition after completion of the task or subtask (e.g. “The voter has placed the ballot into the ballot box”) or the fulfilment of user wants during the execution of the task or subtask (e.g. “The voter wants to be sure that nobody has been watching him vote”).

4. There are three different forms of observable postconditions:

A task object has been created

An existing task object has been modified

The user has generated new knowledge using an existing task object

Examples of goals in the form of an observable postcondition:

The bank customer has successfully started the transfer.

The driver has parked his/her car in the parking space without damage.

The voter has placed the completed ballot slip into the ballot box.

Examples of goals in the form of user wants:


Technical term



The bank customer wants to be sure that the recipient will receive the amount transferred.

The driver wants to be proud that he/she got into the parking position with only one manoeuvre.

The voter wants to be sure that nobody is watching while he/she fills out the ballot slip in the polling booth.

Goal catalogue A tabular display of all identified goals relevant for the user behaviour in the context of use. It must be stated for each goal, for which user groups or personas it is valid. The goal catalogue helps to verify if relevant goals have been identified and described for a user group and if there are any gaps or problems of comprehension.

CPUX-UR Curriculum and Glossary Copyright 2016, UXQB e.V. Page81 of 84

9 Annex 1 – Model seminar

9.1 Concept of the seminar

Participants must thoroughly familiarise themselves with the curriculum, the glossary, the illustrative examples and the exemplary questions for the theoretical and practical exam before the start of the seminar. Learning the terms and concepts, which is necessary for being able to pass the test, is not the main topic of the seminar. (Proficiency level K1 “Know”)

The seminar mainly focuses on conveying the relationships between terms and concepts with respect to the learning objectives (Proficiency level K2 “Understand”)

In the seminar, participants practise the methods of user requirements engineering. (Proficiency level K3 “Apply in practice”)

The practical exercises for learning units 4.1, 5.1 and 5.2 are carried out in the same format as the practical exam. This way, participants can adjust to the format of the practical exam.

9.2 Timetable for the seminar

Day Time Learning unit (no. and title) Format

1 10:00 – 10:45

1.1 Learning unit “Differentiate between requirements and solutions”

Interactive lecture (45 min.)

1 10:45 – 11:30

1.2 Learning unit “Differentiate between stakeholder requirements and system requirements”


1 11:30 – 11:45

Break

1 11:45 – 12:30

1.3 Learning unit “The components of the context of use”


1 12:30 – 13:15



1 13:15 – 14:15

Break

1 14:15 – 15:00


Exercise for 1.4 (45 min.)

1 15:00 – 15:30

2.1 Learning unit “Identify the rationale and goals for the context of use analysis”


1 15:30 – 15:45

Break

1 15:45 – 16:45

2.2 Learning unit “Determining the approach for context of use analysis”


1 16:45 – 17:30

3.1 Learning unit “Select and recruit users for contextual interviews and / or observations”




End of day 1

2 09:00 – 09:45

3.2 Learning unit “Prepare and execute the collection of context of use information“


2 09:45 – 11:15

3.2 Learning unit “Prepare and execute the collection of context of use information“

Exercise for 3.2 (90 min)

2 11:15 – 11:30

Break

2 11:30 – 12:15

3.3 Learning unit “Document context of use descriptions from context of use information in an analysable and accessible way”


2 12:15 – 12:35



12:35 –

13:00



2 13:00 – 14:00

Break

2 14:00 – 15:30



2 15:30 – 15:45

Break

2 15:45 – 17:15



End of day 2

3 09:00 – 09:45



3 09:45 – 10:30



3 10:30 – 10:45

Break



3 10:45 – 11:30

6.1 Learning unit “Consolidate and prioritise user requirements with users”


3 11:30 – 12:15

6.2 Learning unit “Determine the implementation priority for user requirements together with project members”


3 12:15 – 13:15

Break

3 13:15 – 14:00

7.1 “Learning unit “As a user requirements engineer, become a successful provider for other roles”


3 14:00 – 14:45

Clarify unresolved questions for the learning units discussed

Discussion (45 min.)

3 14:45 – 15:00

Break

3 15:00 – 17:00

Preparation for exam CPUX-UR Exercise (120 min.)

3 End of day 3

-/-


10 Appendix 2 – Literature

1. Beyer, H. and Holtzblatt, K. (1998). Contextual Design. Defining Customer-Centered Systems (Morgan Kaufmann Series in Interactive Technologies). San Francisco: Morgan Kaufmann.

2. Brown, T. and Katz, B. (2009). Change by design: How Design Thinking transforms organizations and inspires innovation. New York: HarperCollins.

3. Constantine, L. (2009). Model-driven Inquiry - A Streamlined Approach to Data Collection. User Experience, Volume 8, Issue 3, 3rd Quarter 2009.

4. Cooper, A. and Reimann, R. and Cronin, D. and Noessel, C. (2014). About Face: The Essentials of Interaction Design. 4th Edition. New York: John Wiley & Sons, 2014.

5. Deutsche Akkreditierungsstelle GmbH (DAkkS) (2010). Leitfaden Usability. [online] Available at http://www.dakks.de/sites/default/files/71_sd_2_007_leitfaden_usability_1.3_0.pdf

6. Geis, T. and Dzida, W. and Redtenbacher, W. (2004). Specifying usability requirements and test criteria for interactive systems. Germany: Federal Institute for Occupational Safety and Health.

7. Dzida, W. and Freitag, R. (1998). Making use of scenarios for validating analysis and design. IEEE Transactions on Software Engineering, Volume 24, Issue 12.

8. Gothelf, J. and Seiden, J. (2012). Lean UX: Applying Lean Principles to Improve User Experience. O'Reilly and Associates.

9. Hackos, J. and Redish, J. (1998). User and Task Analysis for Interface Design. Chichester: Wiley.

10. Hartson, R. and Pyla, P. (2012). The UX Book: Process and guidelines for ensuring a quality user experience. Morgan Kaufmann.

11. International Organization for Standardization (ISO) (2010) ISO 9241-210: 2010. Ergonomics of human-system interaction - Human-centred design for interactive systems. International Organization for Standardization (ISO).

12. International Organization for Standardization (ISO) (2011) ISO/IEC 25010:2011. System and software quality models. International Organization for Standardization (ISO).

13. International Organization for Standardization (ISO) (2014) ISO/IEC 25063:2014. Common Industry Format (CIF) for usability: Context of use description. International Organization for Standardization (ISO).

14. International Organization for Standardization (ISO) (2013) ISO/IEC 25064:2013. Common Industry Format (CIF) for usability: User needs report. International Organization for Standardization (ISO).

15. Riedemann, C. and Freitag, R. (2009). Modeling usage: Techniques and Tools. IEEE Transactions on Software Engineering, Volume 26, Issue 2.

16. Rosson, M. and Carroll, J. M. (2002). Usability Engineering: Scenario-Based Development of Human-Computer Interaction (Morgan Kaufmann Series in Interactive Technologies).

17. Van der Veer, G. C. (1994). Mental Models of Computer Systems: Visual Languages in the Mind. In: Tauber, M. and Mahling, D. and Arefi, F., ed., Cognitive Aspects of Visual Languages and Visual Interfaces. Amsterdam London New York Tokyo: North-Holland, pp. 3 ff.

18. Young, I. (2008). Mental Models. Aligning Design Strategy with Human Behavior. New York: Rosenfeld Media.

CPUX-UR Curriculum - uxqb.org · 1.4 User requirements as a separate requirements category within...

Documents

Transcript of CPUX-UR Curriculum - uxqb.org · 1.4 User requirements as a separate requirements category within...