Understanding Requirements

What You Need to Know

A requirement states what a system must achieve, do or have. Requirements sit on three layers. A business requirement says why the system exists. A functional requirement says what the system does to serve that outcome. An infrastructure requirement says what the platform must provide so that behaviour holds under real load. Functional requirements describe behaviour; non-functional ones describe a quality of, or constraint on, that behaviour.

Take a computer repair shop that wants a Claude assistant for repair enquiries. The owner's specification mixes all three layers. Reading it without misfiling anything is the first skill in Domain 2.

The Derivation Chain

Business: "halve the time customers wait for a repair quote". Functional: "identify the device from the fault description and route the booking to the right technician". Infrastructure: "absorb the documented Monday-morning enquiry peak inside the organisation's input-token-per-minute limit, and keep customer data in-region".

The chain runs one way. Business begets functional; functional plus architecture begets infrastructure. Skip a layer, or run backwards, and a requirement has nothing to trace to.

The business layer has a structural tell. A statement that names no system behaviour and no platform property is a business requirement, however prominently it sits in the specification. "Halve the wait for a quote" names neither.

Functional Versus Non-Functional

The class depends on the kind of promise a statement makes, not on whether it contains a number. "Answer in the customer's language" promises behaviour: functional. "First token within two seconds at Saturday peak" promises a quality of that behaviour under load: non-functional. Latency targets, throughput floors, availability, data residency, cost ceilings and isolation guarantees are all non-functional, however many digits they carry. A number measures how well a behaviour happens. It does not add a behaviour.

Mixing the two goes wrong in two directions. Promotion calls the most specific, measurable statement functional because it is specific and measurable. Demotion calls a genuine behaviour, such as "route laptop repairs to the right technician", a constraint because it reads operationally. Behaviour is functional. A quality or constraint on behaviour is not.

Rate Limits and Context Windows Are Requirement Inputs

Claude applications bring capacity constraints most requirements processes have never had to model. The API enforces requests per minute (RPM), input tokens per minute (ITPM) and output tokens per minute (OTPM) per model class. So peak concurrency and prompt size become infrastructure requirements with documented numbers behind them. Cache reads do not count toward ITPM on most models, so the caching layer is part of the capacity story too.

The context window bounds how much material one request can carry. That turns "summarise the customer's whole repair history" from a phrasing choice into a design input.

Every API response reports your organisation's live limits in its headers.

import anthropic

client = anthropic.Anthropic()

response = client.messages.with_raw_response.create(
    model="claude-sonnet-5-5",
    max_tokens=256,
    messages=[{"role": "user", "content": "Reply with one word."}],
)

for name, value in response.headers.items():
    if name.startswith("anthropic-ratelimit-"):
        print(f"{name}: {value}")

The anthropic-ratelimit-* headers report the limit, the remaining allowance and the reset time for each enforced class. Sizing peak load without consulting them is the capacity-by-optimism anti-pattern: assuming production traffic will fit because the prototype did.

The Architecture Decides Which Constraints Bind

Requirements are derived against the proposed solution architecture, never in a vacuum, because the architecture decides which constraints matter. A realtime interactive path, like the shop's chat, makes time-to-first-token and streaming support binding. An overnight batch path, such as sorting emailed enquiries, swaps those for the Batches API's 24-hour completion window and its queue limits. The queue limits cap how many batch requests can sit in the processing queue at once. A caching layer converts a repeated 30,000-token context, say the shop's price list, from a throughput problem into a prefix-design obligation. The same business goal therefore produces different infrastructure requirements under different architectures.

In the exam

Domain 2 carries 33.1% of the CCDV-F exam, about a third. The 2.1 items are classification and derivation tests. Given a stack of statements, they reward knowing which layer each lives on and which it should come from. Answers that skip a layer or run the chain backwards lose.

The favourite distractor is promotion; demotion also appears. Stems state the architecture and reward the matching requirement, not a generic checklist.

The harder item shape derives the requirement the proposal implies but never states. Examples are data residency for a personalisation store and peak token throughput for a documented traffic spike. Its distractors state requirements the stated architecture does not need.

Exam Traps

Practice Scenario

Build Exercise

Sources

• Rate limits — Claude Docs, RPM/ITPM/OTPM per model class and the anthropic-ratelimit response headers
• Models overview — Claude Docs, context windows and model-tier characteristics as requirement inputs
• Batch processing — Claude Docs, the batch path whose binding constraints differ from realtime
• Claude Certified Developer Foundations Exam Guide — Domain 2, Understanding Requirements — Anthropic