Infrastructure and Non-Functional Requirements for the Developer Exam

Non-functional requirements: how well the system must perform

Where functional requirements say what a system must do, non-functional requirements say how well it must do it. For a Claude solution that means the targets that surround the behaviour: how fast a response must come back, how many requests per minute the system must sustain, how much each call is allowed to cost, how available the service must be, and what security posture it must hold. This knowledge point sits in task statement 2.1 of the Claude Certified Developer - Foundations (CCDV-F) exam, and it builds directly on functional requirements for Claude solutions, because you cannot state how well a behaviour must perform until you have named the behaviour.

These qualities are not decoration. A support assistant that must answer inside two seconds, a nightly document pipeline that must process fifty thousand files before morning, and a system that must never exceed a fixed monthly spend are all shaped far more by their non-functional targets than by the raw behaviour they implement. The exam treats this at the understand level: you are expected to recognise these categories and to see how they push on the architecture.

The five categories that recur

Five categories cover most non-functional requirements on a Claude project, and it pays to be able to name them. Latency is the time a single response is allowed to take, which matters most for interactive, user-facing features. Throughput is the volume the system must sustain, requests per second or documents per hour, which matters most for pipelines and bulk jobs. Cost sets a ceiling on spend, per call or per period, and on a token-billed API this is a first-class constraint rather than an accounting concern. Availability states how much downtime is tolerable and shapes retry, fallback, and redundancy design. Security posture covers how untrusted input, secrets, and sensitive data must be handled.

The reason to hold all five in mind is that they frequently pull against each other, and the exam likes to probe that tension. The highest-capability model may give the best quality but the worst latency and the highest cost. A tight cost ceiling may push you toward a smaller model or aggressive caching. Recognising that these are competing targets, not a checklist to maximise independently, is the heart of thinking about non-functional requirements well.

Infrastructure requirements follow from the targets

Infrastructure requirements are the concrete provisioning and design choices that the non-functional targets force. They are downstream: you do not start by deciding to use the batch API, you arrive there because a throughput-and-cost target for high-volume, low-urgency work makes batching the right fit. A latency target for an interactive feature might instead push you toward streaming responses so the user sees output as it is generated, and a cost target on repeated, stable context often points to prompt caching to avoid paying for the same tokens twice.

The pattern to internalise is direction of causation. A non-functional target is stated first as a business-driven number, two-second response, fifty thousand documents overnight, spend under a fixed monthly figure. The infrastructure choice is the answer to that target. When you see a design that has picked an API mode or a caching strategy with no target behind it, the requirement was skipped and the choice is a guess, the same ordering error that haunts functional requirements.

These requirements constrain model, API mode, and caching

The most exam-relevant consequence is that non-functional requirements constrain three specific downstream decisions: which model you use, which API mode you call it through, and whether you cache. A latency budget can rule out the largest model for a given call. A throughput-and-cost target can move work from real-time requests to the batch API. A cost ceiling on repeated context can make caching mandatory rather than optional. In each case the requirement is the cause and the technical choice is the effect.

This is exactly why the exam trap here is so sharp: assuming the highest-capability model is always acceptable regardless of the latency budget. Capability is only one axis. If the requirement says a user must see a first response within a second, a slower flagship model can fail the requirement no matter how good its answers are, and the correct design uses a faster model, streaming, or both. The companion trap is treating cost and latency as afterthoughts to be checked at the end rather than as requirements that drive the architecture from the start. On a token-billed, latency-sensitive platform, cost and latency are design inputs, not post-launch surprises.

A worked example

Common misreadings to avoid

How this is tested on the CCDV-F exam

Expect scenarios that hand you a functional behaviour plus one or two sharp non-functional targets and ask for the design that fits. The winning answer respects the target that is doing the work: a latency budget favours a faster model or streaming; a high-volume, low-urgency target favours the batch API; a cost ceiling on repeated context favours caching. The losing answers usually reach for the biggest model or ignore the stated target entirely. Recognising which target dominates a scenario, and letting it constrain the choice, is the skill.

With functional behaviour named and non-functional targets captured, the last step of task statement 2.1 is joining them into a coherent design, which is mapping business requirements to solution architecture.