Practice requirements gathering vocabulary: wants vs. needs, uncovering underlying requirements, MoSCoW prioritisation, and clarifying ambiguous requirements through workshops.
0 / 10 completed
1 / 10
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 / 10
'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 / 10
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 / 10
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 / 10
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'.
6 / 10
John, the senior developer, left a comment on your PR saying: 'This doesn't handle edge cases.' What does he likely mean in the context of requirements gathering?
John's comment focuses on a critical aspect of requirements – edge cases. 'Edge cases' refer to unusual or extreme inputs that a requirement might not explicitly address, leading to unexpected behavior if the code doesn't handle them correctly. This highlights the need for more thorough clarification during the initial gathering phase.
7 / 10
During a Slack discussion about a new feature request, Sarah (Product Owner) says: 'We need to ensure users can upload files larger than 10MB.' Which of the following best describes the purpose of this statement in requirements gathering?
Sarah's statement is a functional requirement. Functional requirements describe *what* the system should do – in this case, allowing users to upload files larger than 10MB. While it touches on performance implications (scalability), the core focus remains on the user's ability to perform the intended action as defined by the requirement.
8 / 10
You are writing a PR description for a new API endpoint. The request body includes a field called 'user_id'. Which of the following best describes how this field should be documented within the requirements document?
The API documentation needs to clearly define the 'user_id' parameter. Specifying that it's an *optional* parameter representing a unique identifier (likely an integer or string) is crucial for developers to understand how to use the endpoint correctly and handle potential errors if it's missing.
9 / 10
Mark (Lead Developer) asks you during a standup update: 'How are we handling the requirement to support both JSON and XML input?' What's the MOST appropriate response in terms of requirements gathering?
Mark's question highlights a potential ambiguity in the requirement. Simply accepting both formats isn't sufficient; you need to understand *how* they must be supported and whether one is prioritized. Clarifying this allows for more effective design and implementation decisions.
10 / 10
A stakeholder states: 'The system should display the customer's name.' What is the primary challenge this statement presents to a requirements engineer in terms of gathering accurate requirements?
The statement 'The system should display the customer's name' is too vague. It lacks crucial details about *how* the name should be presented – font, size, location, etc. This ambiguity can lead to significant discrepancies in implementation and a final product that doesn't meet the stakeholder's expectations.
What will I learn from the "Requirements Gathering Vocabulary" exercise?
Practice requirements gathering vocabulary: wants vs. needs, uncovering underlying requirements, MoSCoW prioritisation, and clarifying ambiguous requirements through workshops.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Stakeholder Management exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss stakeholder management topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Stakeholder Management exercises?
See the full Stakeholder Management exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.