Quiz: Do You Really Understand Requirements Gathering? (Delivery Lead Edition)

Eight questions that test what most delivery leads guess about

Eight multiple-choice questions on requirements gathering practice. Each has one correct answer. The right answers reflect what works retrospectively, across a range of enterprise services projects — not necessarily what feels intuitive in the moment.

Work through them honestly. Score yourself: 7-8 correct means strong practice; 5-6 means typical; below 5 means several habits worth revisiting. Rationales are provided for each answer.

Question 1

A stakeholder describes a requirement using a vague phrase ('the system should be flexible'). What's the best next step?

A. Document it as written and clarify during execution. B. Push back: 'Flexible in what specific dimension? What would inflexible look like?' C. Translate it into a measurable requirement based on your best interpretation. D. Skip it; vague requirements always get clarified by demos.

Correct: B. Vague requirements that aren't clarified at gathering time become the source of late-stage disputes. The cost of clarification is highest after the team has built against an interpretation and lowest at the moment the requirement is first stated. Pushing back is uncomfortable; doing it later is more uncomfortable.

Why not A: Documenting vague requirements verbatim defers the work and increases its cost. Why not C: Translating without stakeholder input puts the PM's interpretation into the record as if it were the stakeholder's. Why not D: Demos surface some clarifications, but late-stage clarification is expensive — the team has already built.

Question 2

You're running a requirements workshop with eight stakeholders from four different teams. One stakeholder dominates. What's the best response?

A. Let them dominate; their domain is probably the most relevant. B. Cut them off and call on a quieter stakeholder. C. Use a structured technique (round-robin, written input, breakouts) to surface other voices without singling anyone out. D. Pause the workshop and address it privately later.

Correct: C. A dominant voice in a workshop produces requirements that reflect one stakeholder's perspective, not the project's. Structured techniques surface other voices without making the conversation confrontational. Round-robin format and written-then-discussed input both work.

Why not A: Domain relevance varies by topic; one stakeholder is rarely the most relevant for everything. Why not B: Cutting off a stakeholder publicly creates political damage that outweighs the immediate gain. Why not D: Addressing it later means the workshop's output is already biased.

Question 3

A stakeholder says 'I need this by end of quarter.' You suspect the deadline is artificial. What's the best response?

A. Accept the deadline and plan accordingly. B. Ask 'what happens if we deliver in week 2 of next quarter?' to test how hard the deadline really is. C. Push back: 'That deadline isn't realistic given the scope.' D. Negotiate a later date based on your gut.

Correct: B. Asking what happens if you miss the deadline distinguishes hard deadlines (regulatory, contractual, externally announced) from soft ones (internal preference, fiscal year alignment). The conversation is informative and non-confrontational.

Why not A: Accepting an unexamined deadline produces a project plan that fights against the deadline rather than serving it. Why not C: Pushing back without information is a debate; asking 'what happens if' is a discovery. Why not D: Gut-based negotiation produces dates that are no more reliable than the original.

Question 4

Mid-project, a stakeholder says 'we should also include feature X.' Feature X wasn't in the original requirements. What's the best response?

A. Add it; stakeholders know what they need. B. Refuse it; scope is fixed. C. Document it as a change request and walk through the trade-offs. D. Ask the team if they have time.

Correct: C. Mid-project additions are change requests, not new requirements, and they have trade-offs (other work shifts, schedule extends, or scope is reduced elsewhere). The change request process makes the trade-offs visible to the stakeholder. They may still want the feature; with full information, they make a different kind of decision.

Why not A: Adding without trade-off discussion is silent expansion. Why not B: Fixed scope without a change process leaves stakeholders no way to surface evolving needs. Why not D: Team capacity is one input; the stakeholder's trade-off awareness is another, more important input.

Question 5

Which of these is most likely to produce requirements that survive execution?

A. A 50-page detailed requirements document signed by all stakeholders. B. A 5-page document focused on outcomes, with appendices for detail. C. A backlog of user stories without a unifying document. D. A deck presented at kickoff and never revisited.

Correct: B. Requirements documents that survive execution are short enough to be re-read, structured around outcomes (which are durable) rather than features (which evolve), and detailed where needed via appendices. The 5-page main body can be re-read in 15 minutes; the appendices are reference material.

Why not A: A 50-page document is rarely re-read after signing. Unread requirements drift. Why not C: A pure backlog without a unifying document loses the connection between individual stories and overall outcomes. Why not D: Decks are presentation artifacts, not reference documents.

Question 6

You're handing off requirements to engineering. The engineering lead says 'looks good, we'll figure it out.' What's the best response?

A. Trust them; they're the experts. B. Walk through the requirements with them, line by line, asking 'what does this mean to you?' C. Insist on a written sign-off. D. Escalate to engineering management.

Correct: B. 'Looks good, we'll figure it out' is the single most reliable indicator of an upcoming handoff failure. The line-by-line walkthrough surfaces interpretive differences while the requirements are still mutable. The walkthrough takes 30-60 minutes; the recovery from a handoff failure can take weeks.

Why not A: Trust is good; verification is better. Why not C: Written sign-off without walkthrough produces a signed document and an interpretive gap. Why not D: Escalation is appropriate when the engineering lead is unwilling to engage; not when they're willing but moving too fast.

Question 7

A requirement is technically possible but expensive. The stakeholder doesn't know it's expensive. What's the best response?

A. Implement it; cost is engineering's problem. B. Quietly drop it and hope nobody notices. C. Make the cost visible to the stakeholder and let them decide. D. Flag it as a risk in the requirements document.

Correct: C. Cost visibility lets the stakeholder make an informed decision. They may still want the feature, accept the cost, and proceed. They may decide the cost isn't worth it and drop the feature. Either decision is legitimate; the wrong move is making the decision for them.

Why not A: Treating cost as engineering's problem produces silent overruns. Why not B: Quietly dropping a requirement is a fidelity loss the stakeholder has no chance to address. Why not D: Flagging as a risk is half the work; the stakeholder needs to make a decision, not be aware of a risk.

Question 8

Which practice most reliably reduces requirements drift across multi-month projects?

A. A signed requirements document with a change control process. B. Daily standups where the team discusses requirements. C. A monthly re-read of the requirements document with the full team. D. Detailed user stories with acceptance criteria.

Correct: C. Re-reading the requirements document monthly forces the team to compare current understanding against original intent. Drift becomes visible at the moment of re-reading rather than at the moment of demo. The other options have value but don't surface drift; only re-reading does.

Why not A: Change control is necessary but doesn't catch drift that happens without explicit changes. Why not B: Daily standups discuss execution, not requirements alignment. Why not D: Acceptance criteria help individual stories but don't surface drift at the program level.

The quiz is a 10-minute diagnostic, not a fix. The fix is in the practices the questions point at, particularly the monthly re-read (question 8) and the line-by-line handoff walkthrough (question 6). For the heavy corrective when drift has already accumulated, see the heavy recovery playbook; for early detection, see spotting requirements problems early; for the new-PM version of this quiz, see the new-PM requirements quiz.