← Domain 2: Applications and Integration

2.1 · 3.4% of the exam · Topic 1 of 6

Understanding Requirements

Translate business goals into functional, non-functional, infrastructure, and measurable technical requirements that can drive Claude application architecture.

Learning objectives

Distinguish functional requirements from non-functional and infrastructure requirements.
Translate vague business goals into measurable technical requirements.
Identify performance, scalability, availability, security, cost, and integration constraints.
Connect requirements to architecture and implementation decisions.
Recognize missing requirements that should be clarified before implementation.
Use acceptance criteria to determine whether a requirement has been satisfied.

Detailed theory

From business requirements to technical requirements

A business requirement describes the outcome the organization or user needs. It should not automatically determine a specific technology or model choice.

An engineering team should translate the business requirement into functional capabilities and measurable technical constraints before selecting an architecture.

For Claude applications, this translation can influence model selection, latency strategy, streaming, tool design, authentication, authorization, infrastructure, observability, and cost controls.

Start with the business outcome.
Identify what the system must do.
Identify quality and operational constraints.
Make important constraints measurable.
Map the requirements to architecture decisions.
Define acceptance criteria before implementation.

Functional requirements

Functional requirements describe what the application must do. They define capabilities, behaviors, workflows, or interactions that users or connected systems need.

For a Claude application, examples include summarizing documents, answering questions, creating CRM tickets, retrieving customer information, or invoking an approved external tool.

Users can summarize uploaded documents.
Claude can retrieve customer information from a CRM.
Users can create support tickets.
The application can classify incoming documents.
Claude can call an approved external tool.

Non-functional and infrastructure requirements

Non-functional requirements describe qualities or constraints under which the system must operate. They commonly include performance, scalability, availability, security, reliability, cost, and compliance.

Infrastructure requirements describe the operational capabilities needed to satisfy these constraints, such as concurrency capacity, networking, deployment environments, storage, observability, and access controls.

95% of requests must begin responding within two seconds.
The application must support 5,000 concurrent users.
Customer data must be encrypted.
The service must meet a defined availability target.
The application must remain within an approved API budget.

Measurable requirements and acceptance criteria

Vague requirements such as 'the assistant should be fast' are difficult to test and difficult to use for architecture decisions.

A stronger requirement defines a measurable target and, where appropriate, the population or percentile being measured.

Acceptance criteria provide an objective way to determine whether the implementation satisfies the requirement.

Weak: The assistant should be fast.
Better: 95% of requests must begin responding within two seconds.
Weak: The system should scale.
Better: The service must support 5,000 concurrent requests.

Requirements influence architecture

Requirements should drive architecture decisions rather than the other way around. The same Claude capability can require different architectures depending on latency, scale, security, reliability, and cost requirements.

For example, an interactive application may benefit from streaming when users need progressive output, while a large overnight workload may be better suited to asynchronous or batch processing.

Latency requirements can influence model, streaming, caching, and timeout decisions.
Scale requirements can influence concurrency controls, queues, rate limits, and infrastructure.
Security requirements can influence authentication, authorization, encryption, and audit logging.
Cost requirements can influence model selection, caching, batching, and request strategy.
Integration requirements can influence tool design, APIs, webhooks, or other communication patterns.

Clarifying incomplete requirements

A business request often leaves important technical questions unanswered. Before implementation, the engineering team should identify ambiguity and ask questions that expose the missing constraints.

For a Claude-powered support assistant, useful questions include who the users are, which systems Claude must access, what latency is acceptable, how much traffic is expected, what data is sensitive, what actions require approval, and what happens when dependencies fail.

Who are the users?
What tasks must the application perform?
Which external systems must it access?
What latency is acceptable?
How much traffic is expected?
What data is sensitive?
What actions require authorization or approval?
What are the failure and recovery expectations?
What are the cost constraints?

Core concepts

Functional requirement

What: A capability or behavior that the system must provide.
Why: It defines what the application is expected to do.
When: Use it when describing features, workflows, actions, or system behavior.
When not: Do not use it for requirements such as latency, uptime, capacity, or security constraints.

Non-functional requirement

What: A quality attribute or operational constraint for the system.
Why: It determines how well or under what constraints the system must operate.
When: Use it for performance, scalability, availability, reliability, security, cost, and similar constraints.
When not: Do not treat a user-facing capability itself as a non-functional requirement.

Acceptance criteria

What: Specific conditions used to determine whether a requirement has been satisfied.
Why: They make requirements testable and reduce ambiguity.
When: Use them before implementation and during testing.
When not: Avoid vague criteria that cannot be objectively verified.

Scalability

What: The ability of a system to handle increasing workload or demand.
Why: AI applications can experience large changes in request volume and concurrency.
When: Use it when capacity, traffic, concurrency, or workload growth matters.
When not: Do not confuse scalability with availability or latency.

Performance requirement

What: A measurable constraint on system responsiveness or throughput.
Why: Latency and throughput can directly affect architecture and user experience.
When: Use it when the business specifies response-time or processing-rate expectations.
When not: Do not treat a general feature requirement as a performance requirement.

Infrastructure requirement

What: Operational or platform capability required to support the application.
Why: The application architecture must have the infrastructure necessary to meet its requirements.
When: Use it for deployment, capacity, networking, observability, storage, access, and operational constraints.
When not: Do not choose infrastructure before understanding the requirements it needs to satisfy.

Practical examples

Customer support assistant

Business request: The support team wants an AI assistant that provides faster answers.

Engineering interpretation: Clarify the acceptable response latency, expected traffic, data sources, required integrations, authentication model, and acceptable cost before choosing an implementation.

The final architecture might involve Claude, a knowledge source, CRM tools, authentication, authorization, streaming, rate limits, logging, and monitoring.

Document processing workload

Business request: Process a large collection of documents overnight.

The key requirement is that results do not need to be delivered immediately to a user. That changes the architecture compared with an interactive application.

The engineering team can consider asynchronous or batch processing, workload management, retries, monitoring, and cost controls.

High-risk external action

Business request: Allow Claude to issue refunds through a payment system.

The requirement is not only that the function exists. The architecture must clarify authorization, user identity, approval requirements, permissions, auditing, and failure handling.

The higher-risk action therefore introduces additional security and control requirements.

Claude-specific considerations

Claude model selection should follow application requirements such as quality, latency, capability, and cost rather than being selected before requirements are understood.
Streaming can be relevant when interactive users need progressive output and latency is an important requirement.
Tool use introduces requirements around authorization, external-system failures, validation, and potentially user approval.
Applications that process large asynchronous workloads may have different API and infrastructure requirements from interactive applications.
Sensitive data requirements should be identified before deciding what information is sent to Claude or external systems.
Requirements should be revisited when application scope, traffic, integrations, or business constraints change.

Architecture decisions

SituationChooseBecause

Users need progressive responses during an interactive session.Consider streaming.Progressive output can improve perceived responsiveness when the complete response takes time.

A large workload can be processed asynchronously overnight.Consider batch or asynchronous processing.The workload does not require an immediate interactive response.

Claude can perform a financially sensitive external action.Require explicit authorization and appropriate controls.External high-impact actions require identity, permissions, validation, and potentially approval.

A requirement says the system must be fast.Clarify and measure the latency requirement.A vague performance requirement cannot reliably drive architecture or testing.

Expected traffic will increase significantly.Define capacity and scalability requirements.Architecture needs measurable workload and concurrency targets to plan capacity.

Tradeoffs

Requirements often force tradeoffs between user experience, quality, latency, scalability, reliability, and cost.

AxisRequirement priorityArchitecture implication

Low latencyFast response is prioritized.May favor faster models, streaming, caching, or simpler workflows.

Higher qualityMore capable reasoning/output is prioritized.May increase latency or cost depending on the workload.

High scaleLarge concurrent workload is expected.May require queues, rate limits, concurrency controls, and scalable infrastructure.

Low costBudget is a major constraint.May favor model selection, caching, batching, and reduced unnecessary context.

High securitySensitive data or high-impact actions are involved.Requires stronger identity, authorization, data protection, and auditing controls.

Quick reference

Functional = what the system does.
Non-functional = how well or under what constraints it operates.
Performance includes measurable latency and throughput requirements.
Scalability concerns increasing workload and concurrency.
Availability describes the expected ability of the service to remain operational.
Security requirements influence authentication, authorization, encryption, and auditing.
Cost constraints can influence model, caching, batching, and architecture decisions.
Convert vague requirements into measurable acceptance criteria.
Architecture decisions should be derived from requirements.
Clarify missing requirements before implementation.

Decision rules for the exam

If the question says…The answer is likely…

The system must do X.Functional requirement.

The system must respond within Y seconds.Performance requirement.

The system must support Z concurrent users.Scalability/capacity requirement.

The system must remain available for a defined percentage of time.Availability requirement.

The system must protect sensitive customer data.Security/privacy requirement.

The requirement says 'fast' without a measurable target.Clarify and define measurable acceptance criteria.

Common exam traps

TrapCorrect answer

Choosing a Claude model before clarifying the actual requirements.First identify quality, latency, scale, cost, and capability requirements; then evaluate model options.

Treating latency as a functional feature.Latency is generally a performance/non-functional requirement.

Assuming scalability and availability mean the same thing.Scalability concerns workload/capacity; availability concerns whether the service remains operational.

Accepting vague requirements such as 'make it fast'.Translate vague goals into measurable requirements and acceptance criteria.

Ignoring external-system requirements for Claude tools.Tool integrations introduce requirements around authentication, authorization, errors, validation, and external-system behavior.

Open the Domain 2 sheet

Exam tips

When a question gives a business statement, first identify the actual business outcome before thinking about implementation.
Look for measurable values such as latency, throughput, concurrency, availability, and budget.
If a requirement is vague, the correct engineering action is often to clarify it rather than immediately select a technology.
Separate what the system must do from how well it must do it.
When Claude can affect an external system, consider authorization, failure handling, and operational requirements.
Architecture choices should be justified by requirements rather than personal technology preference.

Common mistakes

Starting implementation from a vague business request.
Clarify users, capabilities, constraints, integrations, scale, security, cost, and acceptance criteria first.
Confusing functional and non-functional requirements.
Ask whether the statement describes what the system does or the quality/constraint under which it operates.
Using unmeasurable requirements.
Convert terms such as fast, scalable, and reliable into measurable targets.
Choosing the model before understanding the workload.
Establish quality, latency, cost, context, and scale requirements before model selection.
Ignoring requirements around external actions.
Identify authentication, authorization, approval, validation, auditing, and failure requirements.

Practice questions

Original questions for this topic. They are study items, not questions from the live exam.

Scenario questions

Customer support assistant

A company wants a Claude-powered support assistant and says only that it should provide answers quickly. The engineering team wants to choose a model immediately.

What should the engineering team do first?

Option AChoose the most capable modelOption BDefine measurable latency, workload, quality, security, and cost requirementsOption CAdd every available toolOption DIncrease the context window

High-volume document processing

A business needs 100,000 documents processed overnight. No user needs an immediate response, but the company has a strict cost budget.

Which requirements should most strongly influence the architecture?

Option AInteractive latency onlyOption BAsynchronous processing, throughput, reliability, and costOption CBrowser rendering speed onlyOption DConversation history length only

Build exercise

Build a Requirements-to-Architecture Planner

Beginner · 40 minutes

What you will learn

Classify business statements as functional or non-functional requirements.
Identify performance, scalability, security, and cost constraints.
Convert vague requirements into measurable acceptance criteria.
Map requirements to architecture considerations.

Step 1
Create the requirement data
Create a small TypeScript array containing five to ten business requirements for a Claude application.
Why: Real architecture work starts with understanding and organizing the requirements.
You should see: Your application contains a structured list of requirement statements.
Step 2
Classify each requirement
Add a classification such as functional, performance, scalability, security, availability, cost, or integration.
Why: Different requirement categories lead to different architecture decisions.
You should see: Each requirement has a clear category.
Step 3
Add measurable acceptance criteria
Rewrite at least two vague requirements into measurable statements.
Why: Measurable requirements can be validated through testing and monitoring.
You should see: Requirements such as 'fast' become statements with explicit latency targets.
Step 4
Map requirements to architecture
For each requirement, record one architecture consideration that could help satisfy it.
Why: Architecture should be driven by requirements rather than technology preference.
You should see: Each requirement has an associated architecture consideration.

Review checklist

Checks are saved in this browser.

I can distinguish functional and non-functional requirements.
I can identify performance and scalability requirements.
I can identify security, availability, reliability, and cost constraints.
I can turn vague requirements into measurable acceptance criteria.
I can explain how requirements influence Claude application architecture.
I know when requirements should be clarified before implementation.
I can identify additional requirements for high-impact external actions.

Key takeaways

Start with business outcomes before selecting technology.
Functional requirements describe what the system does.
Non-functional requirements describe qualities and constraints.
Make important requirements measurable.
Acceptance criteria make requirements testable.
Architecture decisions should be derived from requirements.
Claude applications need requirements for latency, quality, scale, security, cost, and integrations.
High-impact external actions require additional authorization and control requirements.

Sources

Anthropic API Documentation — Primary documentation for Claude API capabilities and application integration.
Anthropic Claude Code Documentation — Reference for Claude application and development workflows.

Domain 2 overview · Quick reference

View progress