2.1 Understanding Requirements
2.1.1 The Business Ask Is Not the Requirement
"We need Claude to handle our inbound support email" is a business ask, not a requirement you can design against. Before a single API call gets written, that ask has to be translated into two more concrete layers: functional requirements -- what the system must actually do (classify a ticket, draft a reply, escalate a refund) -- and infrastructure requirements -- what it needs to run: latency targets, throughput, data residency, availability, budget. Skip the translation and every downstream choice -- model tier, realtime vs. batch, caching strategy -- inherits the guess.
This is the developer-facing mirror of a theme that runs through the whole exam: a Claude application's design flows from its requirements, not from whichever pattern is most familiar or most impressive. A low-latency, user-facing chat and an overnight bulk-analysis job sit at opposite ends of nearly every design axis, and the requirement -- not your preference -- decides which end you're building for.
The one idea to hold onto
Translate every business ask into two layers before writing code: functional requirements (what the system must do) and infrastructure requirements (latency, throughput, residency, availability, budget). Both layers come from the same requirement -- neither is optional.
2.1.2 Five Questions to Extract Before You Design
Anthropic's blueprint gives five concrete questions to ask of any business requirement before you let yourself sketch an architecture. Treat them as a checklist for the first five minutes of any scoping conversation.
| 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 present -- drives the security design |
| Cost ceiling | Shapes model tier, caching strategy, and batch use |
Five extraction questions. Each one directly constrains a later, concrete implementation decision.
None of these are academic categories. A hard latency requirement rules out routing the request through an asynchronous batch job. A tight cost ceiling on a high-volume workload rules out defaulting every call to the largest, most expensive model. High data sensitivity forces decisions about where the data can be sent and processed at all. Extracting these five questions is what turns a vague ask into a design you can actually defend.
2.1.3 Opposite Profiles, Opposite Architectures
A low-latency, user-facing chat and an overnight bulk-analysis job answer the five questions in opposite ways, and that's exactly the point: opposite requirement profiles call for opposite architectural choices, not variations on the same design.
Same underlying model, opposite architectures -- because the requirement profile, not preference, decides realtime vs. batch and model tier.
"Cost is the primary concern and results aren't needed until morning" is a batch requirement. It is not a reason to fan out thousands of synchronous Messages API calls in parallel to finish faster -- that maximizes speed, which nobody asked for, while forgoing the batch discount, which the requirement explicitly cares about.
2.1.4 The Signature Exam Trap: Defaulting to Scale
The recurring wrong answer on this task statement looks technically impressive and is unjustified by anything in the requirement: reach for the biggest model, or the realtime API, by default. Solution architecture is driven by the stated requirement -- not by habit, and not by whichever choice sounds most sophisticated.
- •Defaulting to the largest model when the requirement never asked for maximum accuracy at any cost.
- •Defaulting to the realtime Messages API when the requirement describes a latency-tolerant, high-volume, cost-sensitive job -- the textbook Batches API case.
- •Treating latency, volume, accuracy, data sensitivity, and cost as independent knobs instead of a single coherent profile that should point to one architecture.
Exam trap
If a scenario states a constraint explicitly ("cost is the primary concern," "results aren't needed until morning," "a human reviews every output"), the correct answer is anchored to that constraint. An answer that ignores the stated constraint is wrong even if it sounds more capable.
2.1.5 Requirements Ripple Into Every Later Domain
The five extraction questions aren't a self-contained checklist that gets used once and discarded -- each answer mechanically constrains decisions you'll make throughout the rest of this domain and beyond. Latency sensitivity and volume together point toward realtime vs. batch (Task Statement 2.4). Cost ceiling and accuracy/criticality together bound which model tier is even affordable and which capabilities (extended thinking, a larger context window) are worth paying for. Data sensitivity determines what has to stay on a compliant path before a single line of integration code gets written.
This is why the exam treats requirement extraction as foundational rather than a warm-up exercise: get one of the five answers wrong, or skip asking it, and a later decision that looks locally correct -- "use the Batches API," "cache this prefix," "add a human-in-the-loop step" -- can be the wrong call for the actual system, simply because it was optimized against a requirement nobody actually stated.
Study tactic
When a scenario question gives you a paragraph of business context, mentally tag each sentence against the five questions before you look at the answer choices. The sentence the question emphasizes most is almost always the one the correct answer is anchored to.
2.1.6 Worked Example
Take a concrete ask: "Summarize 40,000 support transcripts from last quarter so leadership can spot recurring complaint themes; the report is due at next week's business review, and the team's Claude budget is tight this quarter." Run the five questions: latency is tolerant (a week out, not seconds); volume is large (40,000 documents); accuracy/criticality is moderate (a human -- leadership -- reads the summary, not an automated downstream action); data sensitivity is likely present (support transcripts may contain PII, which should route to a compliant handling path); and the cost ceiling is explicitly tight.
Every one of those answers points the same direction: a latency-tolerant, high-volume, cost-sensitive job with human review downstream is a batch workload on a cost-efficient model tier, not a realtime pipeline on the most capable model available. That's the translation step doing its job -- turning a business ask into an architecture you can justify line by line against the requirement.
Key Takeaways
- ✓A business ask must be translated into functional requirements (what the system does) and infrastructure requirements (latency, throughput, residency, availability, budget) before any design decision.
- ✓Extract five signals from every requirement: latency sensitivity, volume, accuracy/criticality, data sensitivity, and cost ceiling.
- ✓Opposite requirement profiles -- interactive chat vs. overnight bulk job -- call for opposite architectures, not variations on one design.
- ✓"Cost is the primary concern and results aren't needed until morning" describes a batch requirement, not a reason to parallelize synchronous calls.
- ✓Solution architecture must be driven by the stated requirement, not by defaulting to the biggest model or the realtime API.
Check Your Understanding
Test what you learned in this lesson.
Q1.A requirement states: "Results can wait until tomorrow morning; our Claude spend is the board's top concern this quarter." What does this most directly call for?
Q2.Which pair of concepts does a business requirement translate into before an architecture is chosen?
Q3.A support team says, "We just want to use Claude for our inbox." What should happen before any pattern or model is chosen?
Q4.Why is treating latency, volume, accuracy, data sensitivity, and cost as independent knobs a mistake?
Practice This Lesson