Structured Discovery & Requirement Gathering

Good architecture starts with disciplined discovery -- the same requirement extraction that solution design depends on, done *with* stakeholders rather than assumed on their behalf.

What Discovery Elicits

• Business outcome first: what success looks like, before any technical constraint is discussed
• Constraints second: latency/SLA, volume, criticality, data sensitivity, cost ceiling, and the acceptable quality bar
• Non-functional requirements stakeholders may not volunteer: regulatory context, data residency, peak load, failure tolerance -- these require structured questions, not open-ended ones

Wants vs. Needs

Discovery must separate the must-have outcome (the need) from preferred implementations (the wants). Preserving this distinction gives the design room to make the right tradeoffs later -- a stakeholder's preferred implementation may not be the best way to serve their actual need.

Validating Understanding

Discovery is not complete until requirements are reflected back to stakeholders and confirmed. This validation step catches misunderstandings before they become costly rework, and it produces the artifact that matters most: a shared, agreed statement of what success means. Every later tradeoff conversation is justified against this agreed statement.

Common exam traps

• Jumping to a solution before discovery is complete. Without agreed constraints -- especially the SLA and data sensitivity -- an architect cannot justify model, protocol, or governance choices. A scenario item that proposes a design before establishing constraints is testing whether you'll flag the missing discovery step.