Practice requirements gathering vocabulary: wants vs. needs, uncovering underlying requirements, MoSCoW prioritisation, and clarifying ambiguous requirements through workshops.
0 / 5 completed
1 / 5
A BA says 'the stakeholder has a want vs. a need'. What is the practical difference?
A stakeholder's want is often a proposed solution ('I want a daily email report'). Their need is the underlying problem they're trying to solve ('I need to monitor system health without logging in'). Good requirements gathering uncovers the need so the team can build the best solution, which may differ from the want.
2 / 5
'Uncovering the underlying requirement' — what technique is commonly used to do this?
The 5 Whys technique involves asking 'why' repeatedly in response to each answer until the root cause or true underlying need is revealed. For example: 'I want a report' → why? 'To check daily errors' → why manually? 'Because I have no automated alerts' → the real need is alerting, not reporting.
3 / 5
A BA says 'the requirement was ambiguous — we clarified it via workshop'. What is a requirements workshop?
A requirements workshop (sometimes called a JAD session — Joint Application Development) brings together stakeholders and the team to collaboratively define requirements. It surfaces conflicts between stakeholders, resolves ambiguities, and produces a shared, agreed understanding faster than sequential one-on-one interviews.
4 / 5
What does 'MoSCoW prioritisation' stand for?
MoSCoW is a prioritisation framework: Must have (critical for launch), Should have (important but not critical), Could have (nice to have if time allows), Won't have this time (explicitly out of scope for now). It forces stakeholders to categorise requirements rather than treating everything as equally critical.
5 / 5
A BA says 'the requirement was ambiguous'. What does an ambiguous requirement look like?
An ambiguous requirement lacks specific, measurable criteria. 'The system should be fast' could mean anything — fast for one person might be a 10-second response, for another it means 100ms. Good requirements replace vague qualifiers with testable metrics: 'the page must load within 2 seconds for 95% of requests under normal load'.