Mapping Business Requirements to Architecture on the Developer Exam

Mapping requirements to architecture: joining the two halves

This knowledge point is where the two earlier pieces of task statement 2.1 come together. You have named what the system must do as functional requirements, and you have captured how well it must perform as infrastructure and non-functional requirements. Mapping is the act of turning those into a coherent solution architecture, where each business goal is linked to the behaviour that serves it and the infrastructure that delivers that behaviour. On the Claude Certified Developer - Foundations (CCDV-F) exam this is an apply-level skill: you are not just recognising good requirements, you are building the chain from goal to design and judging whether a proposed architecture holds up.

The reason this deserves its own knowledge point is that a pile of good requirements is not yet an architecture. Requirements describe the target; the mapping produces the design that hits it and, crucially, records why each part of the design exists. That record is what separates a disciplined solution from an accumulation of components someone thought seemed reasonable.

The mapping is a chain from goal to infrastructure

The core of the mapping is a chain. A business goal, say reduce contract review time, connects to one or more functional behaviours, extract key clauses and flag unusual terms, and each behaviour connects to the infrastructure that delivers it under its non-functional targets, a model sized to the task, an API mode, and a caching strategy that meets the latency and cost budgets. Read forward, the chain shows how a business goal becomes a running system. Read backward, it shows why every component exists.

Building this chain well is the apply skill. It is not enough to know the categories; you have to connect a specific goal to specific behaviour to specific infrastructure, and defend the connections. When a stakeholder asks why the design uses the batch API, the answer is not "it is cheaper" but "the throughput-and-cost target on this overnight job, which serves the goal of a morning compliance report, points to batch." The mapping turns opinions about the design into justifications rooted in requirements.

Traceability keeps scope disciplined

The property that makes a mapping trustworthy is traceability: every architecture decision can be traced back to a requirement, and every requirement can be traced forward to some part of the design. Traceability is not paperwork; it is the mechanism that keeps scope honest in both directions. Trace forward from requirements and you find gaps, a stated need that nothing in the design serves. Trace backward from the design and you find scope creep, a component that answers no requirement and should be cut.

This is exactly why the first exam trap on this knowledge point is designing an architecture that is not traceable to any stated requirement. An untraceable component is a liability: it adds cost, surface area, and maintenance with no justification, and no one can later say whether it is safe to remove. On a Claude project the temptation is often a shiny capability, an extra tool, a bigger model, a caching layer, that no requirement actually asked for. The disciplined move is to add nothing that cannot name the requirement it serves, and to flag any requirement that no component yet delivers.

Resolving conflicting requirements explicitly

Requirements often conflict, and the classic conflict on a Claude project is cost versus latency, or cost versus quality. A tight latency budget wants a faster, possibly larger, model; a firm cost ceiling wants a smaller model or heavier caching. These cannot both be maximised, so the mapping has to resolve the tension, and the second exam trap is resolving it silently. Quietly choosing to spend more for quality, or quietly accepting slower responses to save money, hides a business decision inside an engineering choice.

The correct move is to surface the conflict and resolve it explicitly against the business priority. That means naming the tradeoff, "we can meet the latency target with the larger model but it exceeds the cost ceiling, or we hit the ceiling with a smaller model that adds roughly a second," and confirming which the business values more before committing. The architect does not get to decide unilaterally whether this product prizes speed or spend; that is a business call, and the mapping's job is to make it visible so the right owner makes it. An explicit, confirmed resolution is traceable; a silent one is not.

A worked mapping

Common misreadings to avoid

How this is tested on the CCDV-F exam

Because this is an apply-level knowledge point, questions give you a business goal and a set of requirements and ask you to choose or critique an architecture. The strongest answers show a clean chain from goal to behaviour to infrastructure and can name the requirement behind each decision; the weakest include a component nothing asked for or quietly resolve a cost-versus-quality conflict without confirming the business priority. Watch specifically for a distractor that sounds impressive, an extra model or tool, that no stated requirement justifies, and for one that picks a side of a tradeoff without surfacing it.

This closes task statement 2.1. Once a design is traceable to requirements, it is ready to move through the phases of delivery, which is where the systems life cycle in systems development life cycle phases takes over.