# Translating Business Requirements into Claude Solutions > Translating a business problem into a Claude solution means producing a build-ready requirements spec, not picking an architecture pattern. The spec has four parts: functional requirements (what the system must do), infrastructure requirements (what it must run on or integrate with), constraints (cost, latency, compliance, risk tolerance), and a measurable success metric. Only once that spec exists does the separate workflow-vs-agent-vs-augmented-LLM decision (see that concept page) have anything concrete to be applied to. **Domain:** CCARP-D1 · Solution Design & Architecture (17% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/requirements-to-solution-design **Last reviewed:** 2026-05-04 ## Quick stats - **Requirements categories:** 4 - **Primary exam domain:** CCARP-D1 (17%) - **Certs testing this:** 3 - **CCD-F weight (Applications & Integration):** 33.1% - **Design output:** 1-page requirements brief ## What it is This is the first move a Claude Certified Architect - Professional has to make correctly: taking a stated business problem (reduce support-ticket handle time, automate contract review, speed up research synthesis) and translating it into a concrete, buildable requirements spec - not just "add AI," and not yet a pattern choice. Anthropic's enterprise guidance frames the whole exercise as decision-first, outcome-anchored work: before any architecture gets sketched, an architect needs to know what the system must do, what it must connect to, what constraints bound it, and how success will be measured. Getting this translation wrong most often means skipping it entirely - jumping straight from a one-line business ask ("automate contract review") to a pattern or a prototype with no written functional requirements, infrastructure requirements, constraints, or success metric to build against or evaluate later. This step is deliberately upstream of, and distinct from, choosing workflow vs. agent vs. augmented LLM - that pattern-selection decision is a separate concept (see "Workflow vs Agent: Choosing the Right Architecture") that consumes this spec as its input, it does not replace it. ## How it works Functional requirements: what the system must do. Specify the input shape (what arrives, in what format), the required transformation or task (extract which fields, answer which question, generate what artifact), and the output contract (structured JSON, a summary, a routed decision) - concretely enough that two different engineers would build compatible systems from the same brief. This is also where an architect identifies what augmentations the task needs beyond the base model - retrieval over a specific corpus, a specific external tool, persistent memory across turns - since those are functional needs, not architecture choices. Infrastructure requirements: what it must run on or integrate with. Name the systems the solution touches (a claims database, a CRM, an internal MCP server), what auth or data-access scope each integration needs, and where the solution has to live (embedded in an existing app, a standalone service, a chat interface). This is the CCD-F-facing half of the same translation: turning a business ask into requirements a solution architecture can actually be built against, not left implicit until implementation surfaces the gap. Constraints: what bounds the design before any pattern is chosen. Cost ceiling per unit of work, a latency or accuracy SLA, compliance or data-residency rules, and how much judgment can run unattended versus needing a human in the loop are all constraints the requirements step should surface explicitly - each one narrows, sometimes decisively, which architecture pattern the next step can pick from. A measurable success metric, tied to a narrow pilot. Anthropic's enterprise transformation materials frame the translation step as tied to success metrics defined up front - enterprises that succeed define a metric and a narrow pilot scope before expanding, rather than translating a vague mandate ("use AI more") directly into a system design. Treat the requirements spec as a hypothesis, not a one-shot document. Anthropic's planning-to-production guidance stresses that implementation is iterative: the first translation of a business problem into functional requirements, infrastructure requirements, constraints, and a metric is expected to be revised against real usage data, not treated as final the moment it's written down. ## Where you'll see it in production ### Claims re-keying automation Functional: extract a defined field set from PDFs into a structured schema with a validation loop. Infrastructure: reads from the existing document-intake system, writes via the claims system's existing API. Constraint: no PII stored beyond the existing retention policy. Success metric: re-keying time reduced by a stated %. The pattern choice (a workflow, once these are pinned down) is a separate, later step. ### Enterprise AI pilot scoping A vague "use AI more" mandate translated into a narrow pilot with a defined success metric and named constraints (department, data scope, budget ceiling) before any department-wide rollout or pattern gets chosen. ## Decision tree 1. **Can you state the input shape, the required transformation, and the output contract in one paragraph?** - **Yes:** Functional requirements are captured - move to infrastructure. - **No:** Stop and pin these down first; a pattern choice built on an unstated functional requirement will be wrong regardless of which pattern gets picked. 2. **Have you named every system this solution touches and what auth/data-access scope each integration needs?** - **Yes:** Infrastructure requirements are captured. - **No:** Surface them now - discovering a missing integration mid-build is the most common cause of a requirements-to-architecture mismatch. 3. **Are there stated constraints (cost ceiling, latency/accuracy SLA, compliance, human-in-the-loop threshold)?** - **Yes:** Good - these will bound the downstream pattern choice. - **No:** Define them explicitly; an unstated constraint doesn't mean there isn't one, it means the architect guesses at it later. 4. **Is there a clear, quantifiable success metric you can pilot narrowly before scaling?** - **Yes:** Scope a narrow pilot around that metric before expanding, per Anthropic's enterprise transformation guidance. - **No:** Define the metric first - translating a vague mandate directly into a system design is the most common failure mode here. ## Exam-pattern questions ### Q1. A VP says the claims team spends 40% of its time re-keying PDF data into the claims system. An architect's first move is to sketch an architecture diagram with no written brief. What is the error? Skipping the requirements spec - before any pattern is chosen, the architect needs the input shape (what the PDFs look like), the output contract (what fields the claims system expects), which systems this touches and what auth it needs, and a success metric (re-keying time reduced by X%). Named distractor: "sketch the architecture first, requirements can be filled in during implementation" - a pattern chosen against unstated requirements cannot be verified against what was actually asked for. ### Q2. A stakeholder mandate says "use AI more" with no specific metric. The architect starts building a broad system across five departments at once. What is the correct translation-step move instead? Define a measurable success metric and a narrow pilot scope before expanding - a vague mandate should not be translated directly into a broad system design. Named distractor: "start broad so you can prove value across the whole org fast" - that inverts the enterprise-transformation guidance that ties translation to a narrow, metrics-first pilot. ### Q3. The first version of a contract-review solution ships against a written requirements spec. Six weeks later, real usage shows 30% of contracts need judgment calls the original functional requirements never anticipated. What should the architect conclude? The requirements spec was a hypothesis, not a final document - it should be revised against the real usage data (the functional requirements need a new branch for judgment-heavy cases), which may in turn change which architecture pattern fits. Named distractor: "the original requirements were simply wrong and the whole project should restart from a blank page" - Anthropic's guidance treats implementation as iterative revision, not a restart. ### Q4. An architect writes a functional-requirements paragraph for an extraction pipeline (input shape, transformation, output contract) but never states which system the input arrives from, what auth the pipeline needs, or where the output is written. What category of requirement is missing? Infrastructure requirements - which systems the solution touches and what auth/data-access scope each integration needs, the CCD-F-facing half of this translation. Named distractor: "functional requirements are enough to start building" - a correct functional spec with no stated infrastructure requirements still leaves the integration surface undefined, a gap that surfaces expensively during implementation instead of during design. ### Q5. A team writes a one-line spec, "automate contract review," and starts prototyping the same day. What's missing before this should be built against? All four requirement categories: functional (what fields/clauses to extract, in what output format), infrastructure (which document system it reads from, what auth it needs), constraints (data residency, cost ceiling, how much can run unattended), and a success metric (what improvement is being measured). Named distractor: "a one-line spec is fine as long as the architecture pattern is well chosen" - a well-chosen pattern built against an unwritten spec cannot be evaluated against the actual business ask. ## FAQ ### Q1. Does 'translate business problems into Claude solutions' mean picking workflow vs. agent? No - that's a separate, later decision (see "Workflow vs Agent: Choosing the Right Architecture"). This step's job is producing the requirements spec - functional requirements, infrastructure requirements, constraints, and a success metric - that the pattern decision is then applied to. ### Q2. What is the deliverable of this translation step? A one-page requirements brief: functional requirements (input shape, transformation, output contract), infrastructure requirements (systems, auth, data access), constraints (cost, latency, compliance, human-in-the-loop threshold), and a measurable success metric - before any pattern or prompt gets chosen. --- **Source:** https://claudearchitectcertification.com/concepts/requirements-to-solution-design **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.