User Research and Requirements Analysis
This domain tests whether you can gather trustworthy user evidence and convert it into requirements that are unambiguous, traceable and testable. It also tests whether you know the difference between verification and validation.
Research choices
- Qualitative methods (interviews, contextual inquiry, diary studies) explain why and how. Quantitative methods (surveys, analytics, task timing) estimate how many and how much.
- Sampling matters: a convenience sample of colleagues is not representative. State the population, recruitment route and sample size, and report limitations.
- Interview technique: ask about past behaviour and concrete incidents, not hypotheticals. Avoid leading questions such as “Wouldn’t you find this easier?”
- Usability testing observes tasks; it is not a focus group. Five to eight participants per user segment often expose most major usability problems, but not prevalence.
From voice of customer to requirements
Requirements should be singular, verifiable and free of design solutions. Classify them as functional, non-functional (performance, safety, environmental), and constraints. Use MoSCoW for prioritisation and Kano to separate must-be, performance and delight attributes. Maintain a traceability matrix from user need to requirement to test. Verification asks “did we build it right?” against the specification; validation asks “did we build the right thing?” in the user context.
Worked example
A stakeholder requirement says: “The device must be easy to pair.” This cannot be tested. Rewrite it as: “A first-time user completes pairing with a smartphone in 90 seconds or less, without written instructions; at least 18 of 20 participants from the target segment succeed on the first attempt.” The test method, population, threshold and condition are now explicit. If the prototype achieves 14 of 20, the requirement fails and the team iterates rather than redefining success after the test.
Traps that cost marks
- Confusing a user want with a validated need.
- Writing compound requirements joined by “and” that cannot pass or fail independently.
- Using leading or hypothetical questions and reporting them as evidence.
- Treating verification and validation as interchangeable.
- Omitting non-functional requirements such as noise, ingress protection or recyclability.