Functional Requirements for Claude Solutions on the Developer Exam

Functional requirements: what the system must do

A functional requirement answers one question about a Claude-powered system: what must it actually do? It names the behaviour the system has to exhibit, the inputs it accepts, and the outputs it must produce, in language concrete enough that someone else could confirm whether the built system meets it. On the Claude Certified Developer - Foundations (CCDV-F) exam, task statement 2.1 opens the Applications and Integration domain with exactly this idea, because everything downstream, from model choice to tool design, only makes sense once the required behaviour is pinned down.

The discipline is easy to state and easy to skip. A functional requirement is not "use Claude to help with support tickets." It is "given a customer email, the system must classify it into one of five queue categories and extract the order number when one is present." The first is a wish; the second is a behaviour you can build to and check against. This knowledge point sits at the understand level, so the exam asks you to recognise well-formed requirements and to see why the ordering, requirements first, matters.

Requirements must be testable

The single property that separates a usable functional requirement from a slogan is testability. A requirement is testable when you can take a concrete input, run it through the intended behaviour, and check the output against a stated condition. That property is not a nicety on a Claude project; it is the bridge to evaluation. Because a well-written functional requirement already describes inputs and expected outputs, you can lift evaluation cases and acceptance checks straight out of it. The requirement and the eval are two views of the same statement.

This is why vague requirements are so damaging in AI work specifically. With a deterministic function you might get away with an underspecified requirement because the behaviour is obvious from the code. With a Claude solution the behaviour is probabilistic, so the only way to know whether it is good enough is to measure it against expected outputs. A requirement you cannot turn into a pass or fail check leaves you with nothing to measure, which is the second exam trap on this knowledge point: writing requirements so loose that no eval or acceptance test can be derived from them. When you write "the assistant should be helpful," ask what input and what checkable output would prove it; if you cannot answer, the requirement is not finished.

Business requirements come first, functional requirements next

Functional requirements do not appear from nowhere; they are the translation of business requirements into concrete system behaviour. A business owner says "we want to cut first-response time on support tickets." That is a goal, not a behaviour. Turning it into functional requirements means asking what the system must do to serve that goal: accept an inbound ticket, classify its topic, draft a suggested reply, and flag tickets that need a human. Each of those is a behaviour you can specify and test, and each traces back to the business need that justifies it.

Keeping that translation explicit is what disciplines scope later, which is why this knowledge point feeds directly into mapping business requirements to solution architecture. If a proposed behaviour cannot be traced to a business requirement, it is scope creep; if a business requirement has no functional requirement expressing it, there is a gap. The translation step is where both problems become visible, and it only works if it happens before anyone reaches for a model.

The ordering trap: requirements before model and tools

The defining mistake this knowledge point tests is inverting the order, reaching for a model, an SDK, or a tool integration before the functional requirements are written. It is a tempting mistake because model selection feels like progress. But choosing Opus, or deciding to use tool calling, or committing to a batch pipeline, is an architecture decision, and an architecture decision made before you know the required behaviour is a guess. The requirements decide what the system must do; the model and tools are merely how you will deliver it.

On the exam, a scenario that opens with "the team decided to use the largest model and then began listing what the feature should do" is describing this inversion directly. The correct move is always to define the functional requirements first, because they are what a model choice must later be justified against. This is also the natural boundary with the next knowledge point: once you know what the system must do, you capture the how well, the latency, cost, and availability targets, as infrastructure and non-functional requirements. Functional first, non-functional next, architecture last.

A worked translation

Common misreadings to avoid

How this is tested on the CCDV-F exam

Questions on this knowledge point are recognition questions. A scenario will present a mix of statements and ask which are well-formed functional requirements, or it will describe a team's process and ask what step was skipped or done out of order. The two things the exam trips candidates on are the ordering inversion, selecting a model or tool before requirements exist, and the untestable requirement that cannot become an eval. If you can spot both, you can answer this knowledge point reliably.

Hold onto the throughline: a functional requirement is a testable behaviour translated from a business need and written before any architecture is chosen. Everything else in task statement 2.1, the non-functional targets and the mapping to architecture, is built on top of getting these behaviours right first.