Requirements Elicitation & the Six Design Dimensions
CoreTranslate a business problem into a Claude-based solution design · Difficulty 2/5
Explanation
An architect starts from the business outcome, not the technology. The design flow is: elicit the requirement -> derive functional and non-functional requirements -> choose the architecture that meets them at acceptable cost.
The Six Dimensions to Extract
Before choosing any pattern, extract:
| Dimension | Questions it answers |
|---|---|
| Latency | Interactive (must feel instant) or batch-tolerant? Is there an SLA? |
| Volume / scale | Requests per second, peak vs. steady, growth trajectory |
| Criticality | What is the blast radius of a wrong or unavailable answer? |
| Data sensitivity | PII, regulated data, residency requirements (drives Domain 5) |
| Cost ceiling | Per-request and total budget -- bounds model tier and design |
| Quality bar | Acceptable accuracy; is a human reviewing the output? |
Why These Dimensions Drive Everything Downstream
These constraints -- not preference -- decide:
- Realtime vs. batch processing
- The model tier (Domain 2: which Claude model fits the latency/cost/quality envelope)
- The integration protocol (Domain 3: MCP, direct API, agent-to-agent)
- Where humans sit in the loop (Domain 5: review gates, escalation paths)
An architect who cannot state which of the six dimensions justifies a given design decision has not finished the requirements step. Every subsequent choice -- pattern, model, protocol, human oversight -- should be traceable back to one or more of these dimensions.
Applying the Flow
- Elicit: Ask the business stakeholder what outcome they need, not what technology they want.
- Derive: Convert the outcome into functional requirements (what the system must do) and non-functional requirements (the six dimensions above).
- Choose: Select the architecture that satisfies those requirements at the lowest acceptable cost and complexity.
This flow is the antidote to solution-first thinking, where a team picks an exciting pattern (multi-agent, fully autonomous) before confirming the business actually needs that level of complexity.
Key Takeaways
- Design flow: elicit the requirement -> derive functional/non-functional requirements -> choose the architecture that meets them at acceptable cost
- Extract six dimensions before picking a pattern: latency, volume/scale, criticality, data sensitivity, cost ceiling, quality bar
- These constraints decide realtime vs. batch, model tier, integration protocol, and human-in-the-loop placement
- Every architectural decision should be traceable to a stated constraint, not a default preference
Glossary Terms
A commitment about a system's latency and reliability that must be grounded in what the chosen model tier, retrieval steps, and infrastructure can actually deliver, not in aspiration. A common exam trap is promising sub-second latency on a multi-step agentic pipeline with reranking -- both add latency the SLA must account for. Re-alignment is continuous: a model version, data change, or scaling need can shift what's feasible.
The practice of eliciting a business outcome and its non-functional constraints (latency/SLA, volume, criticality, data sensitivity, cost ceiling, quality bar) through deliberate, structured questions rather than open-ended ones, separating must-have needs from preferred-implementation wants, and validating the result by reflecting it back to stakeholders before design begins.
Related Concepts