Understanding Requirements

What You Need to Know

A requirement states what a system must achieve, do or have. Requirements belong to 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 the behaviour continues to work under real load. Functional requirements describe behaviour. Non-functional requirements describe a quality of that behaviour, or a constraint on it.

This lesson uses one made-up example throughout: the engineering team at an online retailer, which is building a Claude assistant for order enquiries. The product specification mixes all three layers. The first skill in Domain 2 is to read the specification and put each requirement on the correct layer.

The Derivation Chain

Business: "halve the time customers wait for an answer about an order". Functional: "identify the order from the customer's message and route a return request to the right support team". Infrastructure: "absorb the documented Monday-morning enquiry peak inside the organisation's input-token-per-minute limit, and keep customer data in-region". In-region means that the data stays in the customers' own region, a constraint called data residency.

The chain runs one way. Business requirements produce functional ones. Functional requirements and the architecture produce infrastructure ones. If you skip a layer, or reverse the chain, a requirement has no source that it can be traced to.

The business layer can be recognised by its form. A statement that names no system behaviour and no platform property is a business requirement, however prominent its place in the specification is. "Halve the wait for an answer" 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, so it is functional. "First token within two seconds at Monday-morning peak" promises a quality of that behaviour under load, so it is non-functional. Latency targets, minimum throughput, availability, data residency, maximum cost and isolation guarantees are all non-functional, however many digits they contain. An isolation guarantee promises that one customer's data stays separate from another's. A number measures how well a behaviour happens. It does not add a behaviour.

There are two ways to confuse the two classes. Promotion is when you call the most specific, measurable statement functional because it is specific and measurable. Demotion is when you call a genuine behaviour a constraint because it sounds operational. An example is "route a return request to the right support team". Behaviour is functional. A quality or constraint on behaviour is not.

Rate Limits and Context Windows Are Requirement Inputs

Claude applications bring capacity constraints that 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. A cache stores the start of a request, called the prefix, for reuse. Under the API's default rate limits, cache reads do not count toward ITPM, so the caching layer is part of the capacity question too.

The context window limits how much material one request can contain. This limit makes "summarise the customer's whole order history" a design input, not a phrasing choice.

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. If you size peak load without checking these headers, you follow an anti-pattern. This anti-pattern assumes that production traffic will fit because the prototype traffic fit.

The Architecture Decides Which Constraints Bind

Requirements are derived against the proposed solution architecture, never in isolation, because the architecture decides which constraints matter. A realtime interactive path, like the retailer's chat, has two constraints that must be met. One is time-to-first-token, the wait before the first part of the answer appears. The other is streaming support, which sends the answer as it is generated. An overnight batch path, such as sorting emailed enquiries, replaces those constraints with two others. One is the Batches API's 24-hour completion window. The other is its queue limits, which cap how many batch requests can be in the processing queue at once. With a caching layer, a repeated 30,000-token context, such as the retailer's returns and delivery policies, is not a throughput problem. It is a requirement on how to design the prefix (the start of each request, which the cache stores). The same business goal therefore produces different infrastructure requirements under different architectures.

In the exam

Domain 2 is 33.1% of the CCDV-F exam, which is about a third. The 2.1 questions are classification and derivation tests. They give a set of statements. They test whether you know which layer each statement is on and which layer it should come from. Answers that skip a layer or run the chain backwards are wrong.

The most common wrong option is promotion. Demotion also appears. The questions state the architecture, and the right answer is the matching requirement, not a generic checklist.

The harder type of question asks you to derive the requirement that the proposal implies but never states. Examples are data residency for a personalisation store and peak token throughput for a documented traffic spike. Its wrong options state requirements that 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