Study smarter with Fiveable
Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.
Requirements gathering is the foundation of every successful design and software project—and it's where most projects fail. You're being tested on your ability to select the right technique for the right context, not just list methods from memory. Understanding when to use interviews versus surveys, or why observation catches what questionnaires miss, demonstrates the kind of strategic thinking that separates competent designers from great ones.
These techniques connect directly to core course concepts: user-centered design, stakeholder alignment, iterative development, and validation methods. Each approach reveals different types of requirements—functional, non-functional, explicit, and latent. Don't just memorize what each technique is—know why you'd choose one over another and what type of insight each delivers best.
These techniques involve asking users and stakeholders directly about their needs. They work best when users can articulate what they want—but remember, users often don't know what they need until they see it.
Compare: Interviews vs. Focus Groups—both involve direct conversation, but interviews capture individual depth while focus groups reveal social dynamics and consensus patterns. If an FRQ asks about understanding diverse stakeholder perspectives efficiently, focus groups are your answer.
These techniques capture what users actually do rather than what they say they do. The gap between reported and actual behavior is one of the biggest blind spots in requirements gathering.
Compare: Observation vs. Document Analysis—observation captures current behavior, while document analysis reveals intended processes and historical decisions. Use both to identify the gap between how systems were designed to work and how they're actually used.
These techniques bring multiple stakeholders together for intensive, focused requirements work. They accelerate alignment but require skilled facilitation to manage group dynamics.
Compare: JAD vs. Requirements Workshops—both are collaborative, but JAD specifically targets cross-functional alignment with decision-making authority in the room, while requirements workshops focus on systematic elicitation and prioritization. Choose JAD when stakeholder buy-in is the bottleneck.
These techniques translate gathered requirements into testable formats. They bridge the gap between understanding needs and confirming that your solution addresses them.
Compare: Use Cases vs. Prototyping—use cases document what the system should do in words, while prototypes show how it might work visually. Use cases catch logical gaps; prototypes catch usability issues. Strong requirements processes use both.
| Concept | Best Examples |
|---|---|
| Deep individual insight | Interviews, Observation |
| Scalable quantitative data | Surveys and Questionnaires |
| Group perspective gathering | Focus Groups, Brainstorming Sessions |
| Stakeholder alignment | JAD, Requirements Workshops |
| Uncovering latent needs | Observation, Prototyping |
| Documenting functional requirements | Use Cases, Document Analysis |
| Early validation | Prototyping, Use Cases |
| Historical context | Document Analysis |
Which two techniques are best suited for discovering unarticulated user needs that users themselves can't verbalize, and why do they succeed where direct questioning fails?
A project has 500 potential users spread across multiple locations with limited budget. Compare surveys and interviews—which would you prioritize and what trade-offs would you accept?
Explain the key difference between JAD sessions and requirements workshops in terms of participant composition and primary objectives.
Your prototype testing reveals that users struggle with a feature they specifically requested in interviews. What does this gap illustrate about the relationship between stated requirements and actual needs?
If an FRQ asks you to design a requirements gathering strategy for a complex enterprise system with multiple stakeholder groups, which three techniques would you combine and in what sequence? Justify your approach.