From Business Requirements to Functional & Infrastructure Requirements
CoreTranslate business requirements into functional and infrastructure requirements · Difficulty 1/5
Explanation
The Translation Step
Before writing code, a business requirement (the stakeholder's goal) has to be translated into two more concrete layers:
- Functional requirements -- what the system must do (e.g., summarize a support ticket, classify a document, answer a question against a knowledge base)
- Infrastructure requirements -- what the system needs to run: latency targets, throughput, data residency, availability, budget
A Claude application's design flows directly from these two layers. Get the translation wrong and every downstream choice -- model tier, realtime vs. batch, caching strategy -- inherits the mistake.
Five Questions to Extract
| Question | What it decides |
|---|---|
| Latency sensitivity | Interactive (streaming, fast model) vs. tolerant (batch) |
| Volume | A handful of requests vs. tens of thousands |
| Accuracy/criticality | Does output feed a human review step or an automated action? |
| Data sensitivity | PII or regulated data, which drives security design |
| Cost ceiling | Shapes model tier, caching, and batch use |
A low-latency, user-facing chat and an overnight bulk-analysis job sit at opposite ends of nearly every one of these axes -- opposite latency tolerance, opposite realtime/batch fit, and often opposite model-size fit (a fast, cheaper model for high-volume bulk work vs. a stronger model for a smaller number of high-stakes interactive turns).
Common exam traps
- Defaulting to the biggest model or the realtime API regardless of the requirement. Solution architecture is driven by the requirement, not by habit. "Cost is the primary concern and results aren't needed until morning" describes a batch requirement -- it is not a reason to parallelize synchronous calls to finish faster.
- Treating latency, volume, accuracy, data sensitivity, and cost as independent knobs rather than a single profile that should point to one coherent architecture.
Key Takeaways
- Business requirements translate into functional requirements (what the system does) and infrastructure requirements (latency, throughput, residency, availability, budget)
- Extract latency sensitivity, volume, accuracy/criticality, data sensitivity, and cost ceiling before choosing an architecture
- Opposite requirement profiles (interactive chat vs. overnight bulk job) call for opposite architectural choices
- Solution architecture must be driven by the requirement, not by defaulting to the biggest model or the realtime API
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