Turn business intent into owned requirements

Learning objective

Express architecture requirements as business outcomes, functional requirements, nonfunctional constraints, service-level objectives, and stakeholder ownership.

Core idea

An architecture requirement should tell you what success means and who can accept it. As an architect, translate business intent into outcomes, functions, constraints, and measurable service targets before choosing a Claude delivery pattern.

Anthropic’s success-criteria guidance distinguishes specific, measurable, achievable, and relevant criteria. “Build an AI assistant” names a proposed solution; it does not explain the business improvement or the acceptable conditions of delivery.

How it works

A business outcome states the improvement the organization wants: less manual handling, better coverage, or shorter turnaround. Identify the baseline, intended change, population, and accountable business owner. See 1.1.1 for deciding which work Claude should own and 1.1.2 for the acceptance contract.

A functional requirement states what the system must do. “Draft a response from approved policy documents” defines behavior; “route unresolved requests to a caseworker” defines another behavior. State observable inputs and outputs rather than choosing an implementation prematurely.

A nonfunctional constraint limits how the behavior is delivered. Examples include access restrictions, processing location, supported volume, latency, cost, and reliability. Make each constraint testable or explicitly assign the stakeholder who determines compliance. See 6.1.3 for eliciting these constraints and assessing data and system readiness.

A service level indicator (SLI) measures an aspect of delivered service. A service level objective (SLO) sets a target value or range for that indicator. For example, the fraction of eligible requests completed within eight seconds is an SLI; requiring that fraction to reach 95% over a calendar month is an SLO. The figures are example requirements, not a Claude service guarantee.

A service level agreement (SLA) adds an agreement with consequences for missing service expectations. Google’s SRE guidance separates it from an SLO and assigns business and legal teams a role in choosing breach consequences. See 6.3.2 for negotiating objectives, exclusions, handoffs, and support ownership; 1.6.3 owns translating user journeys into performance targets.

Finally, attach stakeholder ownership to each requirement. The business owner accepts the outcome, domain experts define answer acceptability, security owners approve access constraints, and operations owners maintain service measurements and response procedures. These are proposed responsibilities to agree with the team, not automatic assignments supplied by an API. Record who decides when two requirements conflict; see 6.1.1 for discovery and decision owners.

Key distinctions and trade-offs

Outcome versus function: Reducing turnaround is an outcome. Drafting a summary is a function that might help achieve it.

Constraint versus target: A prohibited data destination is a boundary the design must respect. A latency SLO is a measurable performance objective with an allowed miss rate.

Measurement versus commitment: An observed p95 does not become an SLO until stakeholders agree the target and conditions. An SLO does not become an SLA merely because it appears in a dashboard.

Stricter objectives can demand more resources or narrower scope. Google’s SRE guidance says choosing targets is not a purely technical activity: product and business implications shape it, and site reliability engineering (SRE) advises on risk and viability. Record the agreed compromise so implementation teams do not independently redefine success.

Architecture / decision scenario

A government agency wants to reduce routine caseworker drafting time by 25% against its measured baseline. A six-person delivery team has a fixed operating budget and must keep access limited to assigned cases.

You record the outcome separately from two functions: draft a cited response and hand unresolved cases to a caseworker. The access boundary and monthly budget are constraints. The proposed SLO requires 95% of eligible draft requests to complete within eight seconds over a calendar month; the team explicitly defines eligibility and completion.

The service manager accepts the business outcome, policy specialists assess draft quality, the security owner accepts case access, and operations owns the SLI. The agency agrees exclusions and breach consequences before treating any promise as an SLA. This requirement set can evaluate competing architectures without assuming that a successful model call completes the casework.

Common exam traps

• Writing a technology choice where a business outcome is needed.
• Calling an observed metric an agreed SLO.
• Promising an SLA without exclusions, consequences, or stakeholder ownership.

What to remember

State the outcome, required behavior, delivery constraints, measured target, and decision owner. Those distinctions make an architecture proposal testable and defensible.

Knowledge check

References

• Anthropic, Define success criteria and build evaluations.
• Google, Site Reliability Engineering: Service Level Objectives.