Rubric
Contents — domains, guide and mocks

From business need to requirements

CCDV-F 2.110 min read · checked 21 September 2026

Task statementUnderstanding Requirements (3.4%) — functional and infrastructure requirements derived from business requirements and solution architecture

Where requirements come from

business outcome at the top, running system at the bottom

  1. Business requirementthe outcome someone is paying for
  2. Success criteriameasurable targets: quality, latency, cost
  3. Functional requirementswhat the system must do, input to output
  4. Infrastructure requirementsvolume, residency, retention, spend
  5. Solution architecturethe components you then choose
Each layer is derived from the one above it and constrains the one below. A design decision that cannot be traced up to a business outcome is a preference, not a requirement.

Make the business requirement measurable first

A business requirement is a statement of outcome: fewer escalations, faster claims, less manual review. It is not yet testable. Anthropic's own guidance on success criteria is the bridge: criteria should be specific, measurable, achievable and relevant. “Safe outputs” is none of those; “fewer than 0.1% of 10,000 sampled outputs flagged by the content filter” is all four.

The documentation also lists the dimensions worth measuring, and they are rarely one number: task fidelity, consistency, relevance and coherence, tone and style, privacy preservation, context utilisation, and latency and price. Most real applications need several at once, which matters for requirements work because a target on quality alone will quietly be met by an architecture nobody can afford.

What the business saidRequirement it actually containsWhat you must go and check
“Summarise every claim that came in overnight”Bulk, asynchronous, tolerant of hours of delayWhether the Message Batches API's 24-hour window fits
“Agents shouldn't wait while it thinks”Perceived latency target on an interactive pathStreaming, and a realistic time to first token
“It must handle Black Friday”Peak throughput in requests and tokens per minuteYour organisation's rate limits and usage tier
“Nothing leaves our cloud account”Data residency and processing-location constraintThird-party platform access and regional endpoints
“Finance needs to know what this costs”Cost per unit of work, and a capToken accounting, caching, and spend limits

Functional requirements for a Claude application

Functional requirements describe behaviour you could write a test for. For an application built on Claude they cluster into five questions. What goes in — plain text, images, PDFs, rows from a database? What must come out, and in what shape: prose for a person, or a record another system will parse? What must the system be able to do on its own behalf, meaning which tools it needs? Where does a human have to be in the loop? And what has to be recorded afterwards for audit or dispute?

Each of those has a concrete consequence. Documents and images as input pull in file handling: the Files API lets you upload once and reference a file_id in later requests instead of re-encoding the same attachment on every turn. A machine-readable output pulls in schema design, which task statement 2.5 covers. A human approval step is a control you implement, not a sentence you add to a prompt.

A requirements brief, checked

  • Passes: Business outcome statedtriage under ten minutes
  • Passes: Quality target with a baselineagreement on a 500-claim sample
  • Check: Peak volume in requests and tokensclaims per hour given; token size never estimated
  • Missing: Latency budget per pathinteractive and overnight not separated
  • Missing: Data residency and retentionpersonal data, no processing location agreed
  • Passes: Cost ceiling per unit of workmust beat the manual cost
  • Fails: Who is accountable for a wrong answerno human step defined for declines
Three gaps. Each is the kind of thing a scenario question hides in the second sentence — and each changes the architecture, not just the prompt.

Infrastructure requirements: the four that bite

Infrastructure requirements are the ones that make a working prototype fail in production. Four recur.

Throughput. Claude API limits are enforced per organisation and per model on three axes at once: requests per minute, input tokens per minute and output tokens per minute. Exceeding any of them returns HTTP 429 with a retry-after header. Crucially, on most models only uncached input counts toward the input-token limit, so a design that caches a large shared prefix has more headroom than one that does not. “4,000 claims an hour” is not yet a requirement — “4,000 claims an hour, each about 3,000 input tokens plus two photographs” is.

Latency shape. Ask whether a human is waiting. If yes, the requirement is about perceived responsiveness, and streaming matters more than total time. If no — an overnight run, a nightly re-scoring — the Message Batches API processes asynchronously at a 50% discount, with results guaranteed within 24 hours and most batches finishing in under an hour. That trade is the subject of 2.3; the requirements job is only to establish which path each workload is on.

Placement of data. If the business says data must stay inside its own cloud account or a named region, that is an infrastructure requirement with an architectural answer: Claude is available through Amazon Bedrock, Google Cloud and Microsoft Foundry, where authentication uses the cloud provider's credentials rather than an Anthropic API key, and Bedrock offers regional endpoints for guaranteed residency at a pricing premium. Some features are not available on every platform, so “we must run in our own account” can remove options you were assuming.

Spend. Organisations sit in usage tiers with monthly spend caps, and reaching a cap returns 429 with no retry-after — it clears at the start of the next month or when the limits are raised. A cost requirement is therefore two numbers: the expected cost per unit of work, and the ceiling at which you would rather fail than keep spending.

Which requirement decides the path

What does the workload actually demand?
  • A person is waiting
    Interactive, streamedoptimise time to first token
  • Runs overnight
    Batch50% cheaper, up to 24 hours
  • Must stay in our cloud
    Third-party platformcloud credentials, regional endpoints
  • Spiky peak load
    Queue and backoffsize against per-minute limits
Read the branch labels as things a stakeholder says. Each maps to a different integration shape before any model is chosen.

Traps the wrong answers are built from

Tempting but wrongDo this instead
Choosing a model, SDK or framework in the first meetingWrite the measurable success criteria first; the architecture follows from them.
Recording volume in items per day onlyConvert to requests and tokens per minute at peak, since that is what the limits are expressed in.
Treating “accurate” or “secure” as a requirementState a target with a unit and a sample you can measure it against.
Discovering residency and retention rules during security reviewCapture where data may be processed and how long it may be kept as an infrastructure requirement up front.
Assuming every workload is interactiveAsk whether a human is waiting; if not, an asynchronous path is usually cheaper and simpler.

You should now be able to

  • Turn a business outcome into specific, measurable success criteria across more than one dimension.
  • Separate functional requirements from infrastructure requirements for a Claude application.
  • Express expected load in the units that rate limits use, and identify what headroom caching buys.
  • Identify residency, retention and approval constraints before they become architecture rework.
  • Explain which requirement decides between an interactive and an asynchronous integration.

Practice questions

Original questions written for this lesson, in the exam’s style. Answer first, then open the reasoning — every option is explained, including why the wrong ones are tempting.

  1. Question 1

    A hospital's administration team asks for “automatic summaries of discharge letters so coders don't read every one”. The letters are PDFs, coding happens the following morning, and the summaries feed a billing system.

    Which item is the strongest infrastructure requirement to capture from that sentence?

    1. AThat the summaries should read naturally for a clinician audience.
    2. BThat coding happens the next morning, so the workload is asynchronous.
    3. CThat the output should be JSON so billing can parse it.
    4. DThat the model should be the most capable one available.
    Show answer and reasoning
    1. AIncorrect. This is a quality and tone criterion — worth writing down, but it constrains prompts rather than infrastructure.
    2. BCorrect. Nobody is waiting on a response, which allows a batch path and a different cost and latency profile from an interactive design.
    3. CIncorrect. That is a functional requirement about output shape; it says nothing about volume, placement or timing.
    4. DIncorrect. Model choice is a design decision, and it cannot be made before the quality and cost targets exist.

  2. Question 2

    A payments company estimates 500 support conversations an hour at peak, each sending a 6,000-token policy manual plus about 800 tokens of conversation. The team's capacity plan lists only “500 requests per hour”.

    What is missing from the plan, and why does it matter?

    1. AThe output token target, because output tokens are the only billed dimension.
    2. BNothing: requests per hour converts directly to the request-per-minute limit.
    3. CThe token volume per minute, because input and output token limits apply alongside the request limit.
    4. DThe number of concurrent users, because limits are enforced per user.
    Show answer and reasoning
    1. AIncorrect. Output tokens are billed and limited, but they are not the only dimension, and the gap here is the unmeasured input side.
    2. BIncorrect. It converts for requests only, and requests are one of three limits enforced at once.
    3. CCorrect. Limits are enforced on requests, input tokens and output tokens per minute; 500 requests is comfortable while the token volume may not be, and a cached policy manual changes the answer.
    4. DIncorrect. Limits are enforced per organisation and model, not per end user of your application.

  3. Question 3

    A law firm wants an internal research assistant. In passing, the managing partner mentions that client material may not be processed outside the firm's own cloud tenancy, and that every answer must be attributable.

    How should those two remarks be recorded?

    1. AAs deployment preferences to revisit once a prototype proves the idea works.
    2. BAs a security review item, handled by the security team separately from the build.
    3. CAs prompt instructions telling Claude to keep data internal and cite its sources.
    4. DAs an infrastructure requirement on processing location and a functional requirement for source attribution.
    Show answer and reasoning
    1. AIncorrect. Both change which platforms and patterns are even eligible, so discovering them after a prototype usually means rebuilding it.
    2. BIncorrect. Security review will catch them eventually, but they are requirements that shape the architecture, not a later sign-off.
    3. CIncorrect. A prompt cannot change where a request is processed, and asking for citations is not the same as an auditable record.
    4. DCorrect. Residency decides the platform and endpoint; attribution decides the output shape and what your application must store alongside each answer.

Practise every question in Domain 2 →

Sources

Drafted with AI assistance and checked against the sources above; expert review is in progress. Spotted an error? Tell us and it gets fixed, dated and listed on how this is written.