Understanding requirements: CCDV-F study guide

CCDV-F · Applications and Integration, topic weight 3.4% of the exam

Understanding Requirements is a 3.4% topic inside Applications and Integration, the largest CCDV-F domain at 33.1% of the exam. It tests whether you can turn a business requirement into the functional and infrastructure requirements a Claude application must meet, and spot the one requirement that rules an option out.

What the official guide covers

The Claude Certified Developer Foundations exam guide (version 1.0, effective July 2026) describes this topic as functional and infrastructure requirements "based on business requirements and solution architecture".

What the guide lists	What it means in practice
Functional requirements	What Claude must do: the task, the inputs (text, images, PDFs), the tools it must call, and the shape of the output
Infrastructure requirements	Where and how it runs: latency, volume, data residency, data retention, context size and the cloud platform
Derived from business requirements	"The agent sees a draft while the customer waits" becomes streaming and a fast model tier
Derived from solution architecture	An AWS-only company calls Claude through Amazon Bedrock; a team on Google Cloud uses Vertex AI

From a business problem to requirements you can check

A business problem such as "help support agents answer faster" still falls short of a requirement. Turn it into statements of behaviour that a test can pass or fail: "route every ticket to one of four queues", "write a draft reply that names the policy section it relied on", "never send a reply without an agent's approval". Each statement becomes an eval case and a review criterion. "Fast and accurate" can be neither.

Infrastructure requirements are rarely stated in the business problem. Derive them by asking four questions during scoping, before anyone has a favourite platform:

Latency. How fast must the first text and the full answer arrive, measured from where the users are, not from a developer's laptop?
Scale. How many requests per day, and what does the peak hour look like?
Residency. In which location must processing happen, and which contract or regulation requires it?
Identity. Who or what makes the call, under which credentials, and what must be logged for audit?

Write the answers into a short requirements record that names the source of each constraint. When a reviewer later asks why you chose a platform, the record shows that the choice follows from the requirements, not from habit.

Keep three kinds of statement apart. "A person approves each summary before it is stored" is functional: it says what the system does. "Transcripts are processed only in the EU" is infrastructure: it says where and how the system runs. "Use the approved prompt template" or "use Bedrock" is a design choice: it answers how you will meet a requirement, so it belongs in the design unless a contract mandates it, in which case the contract is the source you record.

# requirements.yaml: agreed with the customer before design starts
business_problem: "Support agents take too long to answer billing tickets"
functional:
  - id: F1
    statement: "Classify each ticket as billing, technical, account or other"
    check: "Eval: 95% agreement on 200 labelled tickets"
  - id: F2
    statement: "Draft a reply that cites the policy section it used"
    check: "Eval: every cited section exists in the policy set"
  - id: F3
    statement: "Never send a reply without an agent's approval"
    check: "Integration test: send endpoint rejects unapproved drafts"
infrastructure:
  - id: I1
    statement: "First text visible within 2 seconds for agents in Frankfurt"
    source: "Support operations target"
  - id: I2
    statement: "Ticket text processed only in the EU"
    source: "Customer data processing agreement"
  - id: I3
    statement: "Calls run under a service identity and are logged with the ticket ID"
    source: "Internal audit policy"

Functional requirements for a Claude feature

Write these down before you pick a model or an API:

The task and how you will judge it. Anthropic's evaluation guidance asks for success criteria that are specific and measurable, such as "classifies the ticket into one of 12 queues", not "works well".
The inputs. Text, images (JPEG, PNG, GIF or WebP as image blocks) or PDFs (as document blocks). Each one has to be supported by the model and the platform you choose.
The tools. Which systems Claude must read or change. Client tools run in your code and return a tool_result. Server tools, such as web search, run on Anthropic's infrastructure.
The output. Free text for a person, or JSON that another system parses. If a program reads it, plan for structured outputs and validation.

Infrastructure requirements and the Claude setting that meets each

Requirement	Claude feature or setting	How to check it
Users wait for the answer	Streaming (`stream: true` or `client.messages.stream`) so text appears as it is generated; a faster tier or lower effort for total time	Log time to first text delta and time to `message_stop`
Work can wait hours	Message Batches API, which processes requests asynchronously within 24 hours	Results arrive by `custom_id`, not in input order
Large inputs	Count tokens with `client.messages.count_tokens`; read `max_input_tokens` from the Models API	An input over the window returns a 400 `invalid_request_error` ("prompt is too long")
Inference must stay in the US	`inference_geo: "us"` on the Claude API; workspace `allowed_inference_geos` and `default_inference_geo`	The response `usage.inference_geo` field shows where inference ran
Inference must stay in the EU	Google Cloud Vertex AI with the `eu` multi-region endpoint, or an EU regional option on Amazon Bedrock	`inference_geo` does not apply on Bedrock or Vertex AI
No prompts or outputs stored at rest	A Zero Data Retention (ZDR) arrangement with Anthropic	Covers the Messages API and token counting, not the Batches or Files APIs
Company runs on one cloud	Claude in Amazon Bedrock, Claude on Google Cloud or Claude in Microsoft Foundry	Check the platform page: some features, such as the Message Batches API and Files API, are not offered there
AWS billing and IAM, but Anthropic's own feature set and model IDs	Claude Platform on AWS: Anthropic operates inference, AWS provides authentication and billing	The AWS region scopes IAM and billing, not where inference runs; use `inference_geo` for that
Calls must run under a company identity with an audit trail	The cloud's identity: AWS IAM roles on Bedrock, Google Cloud IAM on Google Cloud, Microsoft Entra ID on Foundry	Log every call with your own request reference and the returned request ID

inference_geo works only on newer models. Older models return a 400 error if you set it, so the residency requirement can also constrain the model choice.

When requirements conflict

Requirements often remove options. Find the hard constraint first, then design around it.

Situation	Choose	Why
ZDR is mandatory and the plan used nightly batches	Messages API with your own queue and concurrency limit	Batch processing stores requests for asynchronous work, so it is outside ZDR
PDFs must be sent many times under ZDR	Send them inline as base64 `document` blocks	The Files API keeps files until deletion, so it is outside ZDR
AWS-only procurement and a large offline job	Check Bedrock's feature list before designing	Anthropic's Message Batches API is not available on Bedrock
Average input fits but some contracts are huge	Size from the largest real input, then chunk or summarise the outliers	The window is a hard limit, not an average
Agent needs internal systems only	Client tools or an MCP server inside your network, with an egress allowlist	Server tools reach the public web, which the requirement may forbid
Team prefers the platform it knows; the customer requires EU-only processing	The platform and region that meet the rule, decided in scoping	Residency is pass or fail. Found at security review, it means a rebuild
Workload handles health data under a HIPAA BAA	Messages API on a HIPAA-enabled organisation, without batch, Files API, code execution or Managed Agents	Those features are not eligible for HIPAA use

Worked example: check a model against the requirements

This script turns two requirements into checks: the model must accept images, PDFs and structured outputs, and the largest real case must fit. TOOLS is your tool list.

import os
import anthropic

client = anthropic.Anthropic()
MODEL = os.environ["CLAUDE_MODEL"]           # the pinned model ID you plan to ship
REQUIRED = ["image_input", "pdf_input", "structured_outputs"]

info = client.models.retrieve(MODEL)
caps = info.model_dump().get("capabilities") or {}
missing = [c for c in REQUIRED if not (caps.get(c) or {}).get("supported")]

count = client.messages.count_tokens(
    model=MODEL,
    system=open("system_prompt.txt").read(),
    tools=TOOLS,
    messages=[{"role": "user", "content": open("largest_case.txt").read()}],
)
headroom = (info.max_input_tokens or 0) - count.input_tokens

print(f"Missing capabilities: {missing or 'none'}")
print(f"Largest case: {count.input_tokens} input tokens, headroom {headroom}")

Token counts are estimates, so keep headroom for the reply and for conversation growth. Re-run the script whenever the model, the system prompt or the tool list changes.

Rules that decide exam answers

A requirement must be checkable. "Fast and accurate" is a wish. "First text within two seconds, measured where the users are" is a requirement.
Data rules are met by platform settings, not prompts. Residency and retention are met by inference_geo, the cloud region or a ZDR arrangement. An instruction in the prompt never meets them.
Check retention terms and the platform before the design. Under ZDR, plan for the Messages API and token counting, not the Batches or Files APIs. Bedrock and Vertex AI also lack some Claude API features, and a design that depends on a missing one fails however good it is.
Fix the constraint that failed. If a review rejects a design for residency, change the platform or region and re-measure latency from the customer's region. Tuning code or adding caching does not touch the failed requirement.
Size from the largest real input. Count tokens on the worst case with count_tokens. Average sizes and character estimates hide the request that fails.
Separate waiting time from total time. Streaming fixes a blank screen. A faster model or lower effort shortens total time. Batch makes results slower and cheaper.

Where it appears in the exam

Understanding Requirements is 3.4% of the exam, inside Applications and Integration (33.1%). On a 53-item exam that is about two items. The guide describes the topic as requirements drawn from business needs and solution architecture, so expect a scenario with one business constraint, such as a retention rule, a residency rule, a deadline or a latency complaint, and a choice of designs where only one meets it.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A bank's compliance team rules that the model provider must not store prompts or responses at rest. The developers planned to run nightly summaries through the Message Batches API and to upload reference PDFs once with the Files API. Which design meets the rule?

A. Keep the plan and add a system prompt line telling Claude not to retain any data.B. Keep the Batches API but delete each batch's results as soon as they are downloaded.C. Move the workload to Amazon Bedrock and keep using Anthropic's Message Batches API there.D. Arrange Zero Data Retention and use the Messages API, sending the PDFs inline each time.

Answer: D. ZDR covers the Messages API, and inline PDFs avoid file storage. A relies on a prompt, which cannot control provider storage. B still stores the batch while it is processed. C fails because Anthropic's Message Batches API is not offered on Bedrock.

Question 2

A support tool shows Claude's draft reply on the agent's screen while a customer waits on the phone. Agents say the screen stays blank for several seconds and then the whole reply appears at once. Reply quality is fine. Which requirement was missed, and what fixes it?

A. Perceived latency; stream the response so text appears as Claude generates it.B. Volume; move the drafts to the Message Batches API to spread the load.C. Context size; split the conversation history across two separate requests.D. Data residency; set inference_geo so the requests run in a nearer region.

Answer: A. The complaint is the wait before any text appears, which streaming fixes. B makes results arrive later, within hours. C changes nothing because the input fits. D controls where inference runs for compliance; it is not a latency setting.

Build exercise

Write a one-page requirements sheet for a Claude feature you know: task, success criteria, inputs, tools, output shape, latency, residency, retention and platform.
Run the script above against your chosen model ID with your largest real input. Record the headroom.
On a model that supports it, send one request with inference_geo: "us" and read usage.inference_geo in the response.
Send the same request with streaming and log the time to the first text_delta and to message_stop. Write down which number your users actually feel.

Practise this topic

Claude Certified Developer practice exam: free, 20 questions, no sign-up
CCDV-F study guide: all topics
Previous topic: Agent Patterns and Frameworks
Next topic: Systems Life Cycle

Sources

Claude Certified Developer Foundations Exam Guide, version 1.0, effective July 2026 (Anthropic), Domain 2 topic: Understanding Requirements
Anthropic documentation: Data residency
Anthropic documentation: API and data retention
Anthropic documentation: Token counting
Anthropic documentation: Claude on Google Cloud