3.3. Requirements Gathering

💡 First Principle: Every requirements-gathering technique produces requirements, but each is built for a different constraint — group size, stakeholder availability, need for consensus, or complexity of the subject matter. The exam expects you to pick the technique that fits the scenario's specific constraint, not just any valid technique.

Traceability: RTM and product backlog. A requirements traceability matrix (RTM) links each requirement to its source, its design element, and the test that confirms it was met — the predictive-world version of "don't lose track of a requirement." A product backlog does the same conceptual job in an adaptive project: each backlog item traces back to a need and forward to the increment that delivers it. Different document, same underlying purpose — keeping "why we're building this" connected to "what we actually built."

⚠️ Exam Trap: Don't assume the requirements traceability matrix is exclusively a predictive-project artifact. A scenario describing an adaptive team tracking each backlog item back to a business need is describing the same traceability concept in a different, adaptive-native form — not "skipping" traceability because it isn't called an RTM.

⚠️ Exam Trap: Interviews, surveys, and workshops are not interchangeable "pick whichever is fastest" options. A scenario describing a large, geographically distributed stakeholder group is steering you toward a survey, not an interview — using the wrong technique for the constraint described is a common wrong-answer pattern, even though all three techniques are individually valid tools.

Defaulting to one technique regardless of situation. A team that uses surveys for every requirements-gathering need, simply because surveys are fast and low-effort, will eventually miss what a workshop is specifically built to catch: live conflict between stakeholders with genuinely competing priorities. Surveys are efficient at reaching a large group, but they don't create the real-time back-and-forth needed to resolve disagreement — a gap that often doesn't surface until much later, when the unresolved conflict finally derails the project.

Use case versus user story, side by side. Both document requirements, but at different grain and for different structural purposes. A use case maps a process with multiple actors and branching paths — useful when a workflow genuinely has several participants making different decisions along the way. A user story captures a single, backlog-sized requirement from one perspective, typically the end user's. A scenario describing a multi-step process involving a customer, a staff member, and a backend system is calling for a use case; a scenario describing one specific feature request from a user's point of view is calling for a user story.