4.3 Requirements Analysis & Claude Application Design

Requirements Analysis & Claude Application Design

Exam Blueprint Focus: Understanding Requirements (3.4%) and Claude Application Design (8.6%) together make up 12% of CCDV-F — more than Tools and MCPs. These sub-skills are not about API syntax at all. They test whether you can read a stakeholder's request and decide, before writing code, whether Claude belongs in the solution and what shape the system should take.

The First Question: Should Claude Do This At All?

The most valuable requirements skill on this exam is recognising when an LLM is the wrong component. Claude is probabilistic, latency-variable, and priced per token. Three categories of requirement should route away from it:

A hybrid is usually the right answer rather than a binary: let code do what code does well, and give Claude the language-shaped part of the task. A tax application should compute the liability in Python and use Claude to explain it in plain English. Getting that split right is what "Claude Application Design" means.

Eliciting Testable Requirements

Vague requirements produce unevaluable systems. Convert each stakeholder statement into something you could write an assertion against.

Five dimensions to elicit on every project, because each one changes the architecture:

1. Quality bar and failure cost. What happens when the output is wrong? A wrong product recommendation is a bad day; a wrong medication instruction is an incident. This sets the model tier and whether you need human review.
2. Latency envelope. Interactive, near-real-time, or offline? Offline unlocks the Batch API's 50% discount immediately.
3. Volume and budget. Requests per day multiplied by cost per request is the number that decides whether caching and routing are optional or mandatory.
4. Data sensitivity and residency. PII, PHI, or regulated data changes redaction, logging, and possibly inference_geo.
5. Determinism requirements. Which parts of the output must be structurally guaranteed? Those become tool schemas, not prose instructions.

Requirements to Architecture: A Decision Path

Is the task language-shaped?  --no--> Write ordinary code.
        | yes
Does one model call with good context solve it?  --yes--> Augmented LLM. Ship it.
        | no
Are the steps known in advance?  --yes--> Deterministic workflow (chain / route / parallelize).
        | no
Does the task need dynamic tool selection over many turns?  --yes--> Agent, with hard turn and budget ceilings.

The governing principle is to start with the simplest design that works. Each step down that path adds cost, latency, non-determinism, and debugging surface. An agent is not a more advanced answer to a workflow question; on the exam it is the wrong answer to a workflow question.

Designing the Claude Application

1. Separate the control plane from the data plane

The control plane is your instructions: the system prompt, tool schemas, and business rules. The data plane is untrusted content: user messages, retrieved documents, tool output, uploaded files. Keep them structurally distinct — instructions in system, untrusted content wrapped in XML tags inside messages — so that text arriving from a document can never be read as an instruction.

2. Make the API boundary explicit

Claude sits behind your service, never in front of it. Your backend owns authentication, authorization, rate limiting, quota enforcement, and audit logging. The model never decides whether a caller is allowed to do something.

3. Choose the output contract before the prompt

Decide what the caller needs — prose, a typed object, or a side effect — and pick the mechanism accordingly:

4. Design for statelessness from turn one

The Messages API holds no session. Conversation state is your database's job, and the schema needs to hold whole content blocks — thinking blocks with signatures, tool_use and tool_result pairs — not flattened strings. Teams that store only role and text discover on the first tool-use turn that they cannot rehydrate a valid conversation.

5. Plan the cost model with the design, not after it

Sketch the token budget while the architecture is still on a whiteboard: what is static across requests (cache it), what is bulk and asynchronous (batch it), what is simple enough for a cheaper tier (route it). Retrofitting a cache breakpoint into a system whose prompt starts with a timestamp is far more expensive than designing the prefix to be stable.

A Worked Requirements Translation

"We want AI to handle our insurance claim intake. Adjusters spend hours reading PDFs. It needs to be accurate because these are legal documents, and we process about 8,000 claims a day."

Decompose it:

Resulting architecture: upload each PDF through the Files API, submit extraction requests through the Message Batches API on a capable tier with a cached instruction prefix and a forced extraction tool, enable citations so every extracted field points at a page, and route any claim whose confidence falls below threshold to an adjuster instead of straight into the claims system.

Notice how much of that came from requirements the stakeholder never stated. Surfacing the unstated requirements is the skill being tested.

Common Traps

1. Building an agent because agents are interesting. If the steps are knowable, a workflow is cheaper, faster, and debuggable.
2. Accepting "it shouldn't hallucinate" as a requirement. Convert it into a grounding rule and an eval you can run.
3. Asking Claude to do arithmetic that appears on a regulated document. Compute in code; let Claude explain.
4. Designing the prompt before the output contract. The contract determines whether you need a tool schema, citations, or streamed prose.
5. Treating cost as a post-launch optimisation. Prefix stability and batch eligibility are architectural decisions, not tuning knobs.