Collecting and Analyzing User Requirements¶

Status: established
Last updated: 2026-05-31
Sources: 9781119636113.Ch37.Pdf
Tags: [user-research, user-requirements, personas, contextual-inquiry, focus-groups, participatory-design, ethnography, human-centered-design, UX-methods]

Summary¶

User requirements provide the basis for the design and evaluation of interactive systems to meet identified user needs (ISO 25065:2017). They describe the desired attributes, capabilities, or behaviors of a system from the users' perspectives. User requirements do not prescribe design solutions, but they specify what a user shall be able to achieve with the system and/or what a user can experience while interacting with it (Peissner, Pollmann, & Fronemann, 2021).

User requirements are a key deliverable in the human-centered design process (ISO 9241-210), as they make higher-level quality objectives (usability, user experience, accessibility, avoidance of harm) more concrete and usable in system development. They summarize findings from analysis and user research activities and translate them into intended properties or outcomes of interaction.

Body¶

Context¶

Peissner, Pollmann, and Fronemann (2021), in their handbook chapter on collecting and analyzing user insights, examine how user requirements are gathered, documented, and used in human-centered design. Following ISO standards, they treat user requirements as the basis for designing and evaluating interactive systems to meet identified user needs, describing the desired attributes, capabilities, or behaviours of a system from the users' perspective without prescribing design solutions. The chapter organises documentation formats by purpose and surveys methods for collecting requirements. Within this knowledge base the article is the front end of the human-centred design process: it precedes and feeds the design-and-evaluation work in Usability And User Experience, draws on the work-description methods in Task Analysis (hierarchical task analysis is one of its collection techniques), and supports inclusive design in Design For All and the situational understanding in Situation Awareness.

Key Points¶

User requirements are a key deliverable of the human-centered design process (ISO 9241-210), making higher-level quality objectives — usability, user experience, accessibility, avoidance of harm — concrete and usable in development. They rest on the context of use: information about users and stakeholder groups, their goals and tasks, and the environments in which the system will be used. The user layer covers knowledge and skills, culture and language, cognitive abilities, physical and sensory characteristics, mental models, needs, and values; the goals-and-tasks layer covers pragmatic, organizational, and hedonic goals, processes, and the social environment (PDF pp. 1–2, orig. pp. 960–961); the environment layer covers physical, organizational, and technical conditions. ISO/IEC 25063 provides the Common Industry Format for documenting context of use (PDF pp. 1–2, orig. pp. 960–961).

Requirements are typed in several ways. Functional requirements describe system functionalities and services; non-functional requirements specify quality aspects such as reliability, performance, and usability (ISO/IEC 24765; Sommerville, 2004). User requirements specify intended outcomes from the user's perspective in high-level natural language, while system requirements specify capabilities and characteristics from the supplier's perspective in more formal terms (PDF p. 5, orig. p. 964).

User requirements documents serve three purposes, each with its own formats. To record insights from user and context research: context of use descriptions, personas, empathy maps, scenarios, and use cases. To guide and inspire design, where prioritising key requirements and inspiration matter more than complete coverage: opportunity areas and design principles. To provide a baseline for evaluation and quality assurance, where IEEE-recommended specifications are unambiguous, complete, verifiable, and traceable: the User Requirements Document per ISO/IEC CD 25065 (PDF p. 3, orig. p. 962).

The documentation formats each have a distinct role. A context of use description documents users, goals and tasks, and environments, where user needs are "prerequisite[s] identified as necessary for a user... to achieve an intended outcome... within a specific context of use" (ISO/IEC CD 25065). Personas are fictional "hypothetical archetypes of actual users" (Cooper, 1999) built from research to make a user group real, tangible, and decision-relevant, and should be believable rather than stereotypical, usually with no more than three primary personas. Empathy maps cluster research data into what users say, think, do, and feel to help teams empathise. Scenarios are narratives of how a product is used to achieve a user's objectives, useful as a starting point for eliciting requirements but criticised for incompleteness and selection bias (Diaper, 2002). Use cases describe more formally how a user reaches a goal — actors, preconditions, main path, alternative paths, and end state — with essential use cases specifying intentions and responsibilities in a technology-independent way. Opportunity areas reframe insights as "How might we...?" questions, and design principles state core filters for ideas in a "From... to..." headline format. The User Requirements Document (ISO/IEC CD 25065) combines all results into a structured specification of the system, constraints, user-related quality and interaction requirements, context, goals and tasks, and any design guidance (PDF pp. 3–6, orig. pp. 962–965).

Collection methods divide into asking (self-reports capturing explicit knowledge and attitudes) and observing (behaviour capturing implicit needs and problems), which the authors advise always combining, across further dimensions of qualitative versus quantitative and laboratory versus natural environment. Hierarchical task analysis breaks tasks into smaller action units to reveal information needs and capabilities at each step, providing understanding from which requirements are discovered rather than requirements directly. Interviews are the most popular qualitative asking method, structured, semi-structured, or unstructured, yielding rich individual insight but time-consuming and not generalisable, and best done face-to-face with open, non-leading questions. Contextual inquiry adapts ethnography for design (Beyer & Holtzblatt, 1998), observing and interviewing users in their natural environment under four principles — context, partnership, interpretation, and focus — to capture explicit and tacit knowledge. Focus groups are moderated group discussions of 5–10 participants for identifying needs at early concept stages, revealing perceived needs quickly and cheaply but limited to what participants can articulate. Participatory design workshops treat users as "experts by experience" and designers as enablers (Sanders & Stappers, 2008), co-creating ideas and surfacing requirements, with creativity ranging across doing, adopting, making, and creating. Cultural probes (Gaver, Dunne & Pacenti, 1999) give users packages of materials to record their lives over weeks, inspiring design rather than yielding concrete requirements. Ethnography, from anthropology, immerses a researcher in users' environment for months to discover latent needs of which users are unaware (D'Souza & Greenstein, 2003), but is intrusive, slow, and expensive (PDF pp. 6–11, orig. pp. 965–970).

Conclusion¶

Peissner, Pollmann, and Fronemann (2021) conclude that user-centered development always combines several methods, chosen by the system at hand, the questions relevant to the current phase, and trade-offs between asking and observing, qualitative and quantitative, and laboratory and field. All requirements documentation shares one principle: it avoids detailing technical realisation or interface design and focuses instead on user goals and the system responsibilities needed to achieve them (Beyer & Holtzblatt, 1998; Constantine & Lockwood, 1999).

Related¶

• Human Factors Ergonomics Discipline
• Situation Awareness
• Design For All

References¶

Beyer, H. & Holtzblatt, K. (1998). Contextual design: Defining customer-centered systems. Burlington, MA: Morgan Kaufmann Publishers. To be validated.

Constantine, L. L. & Lockwood, L. A. (1999). Software for use: A practical guide to the models and methods of usage-centered design. Reading, MA: Addison-Wesley. To be validated.

Cooper, A. (1999). The inmates are running the asylum. Carmel, IN: Sams Publishing. To be validated.

Diaper, D. (2002). Scenarios and task analysis. Interacting with Computers, 14(4), 379-395. To be validated.

D'Souza, M. E. & Greenstein, J. S. (2003). Listening to users in a manufacturing organization: A context-based approach to the development of a computer-supported collaborative work system. International Journal of Industrial Ergonomics, 32, 251-264. To be validated.

Gaver, B., Dunne, T. & Pacenti, E. (1999). Design: Cultural probes. Interactions, 6(1), 21-29. To be validated.

Peissner, M., Pollmann, K. & Fronemann, N. (2021). Collecting and analyzing user insights. In G. Salvendy & W. Karwowski (Eds.), Handbook of Human Factors and Ergonomics (5th ed., pp. 960-971). John Wiley & Sons. peissner2021userinsights

Sanders, E. B. N. & Stappers, P. J. (2008). Co-creation and the new landscapes of design. Co-Design, 4(1), 5-18. To be validated.

Sommerville, I. (2004). Software engineering (7th ed.). Harlow: Pearson Education. To be validated.

Open Questions¶

• How can organizations balance the depth of ethnographic methods with practical time and resource constraints?
• What approaches best integrate implicit user needs discovered through observation with explicit requirements from interviews?
• How should participatory design methods be adapted for remote or distributed user groups?
• What validation methods ensure personas remain representative as user populations evolve?
• How can cultural probes be structured to provide both inspirational insights and actionable requirements?