2.1 — Understanding Requirements

CCDV-F Domain 2 · Task 2.1

What You Need to Know

Requirements sit on three layers:

Layer	What it states
Business	Why the system exists (names no system behaviour and no platform property)
Functional	What the system does to serve that outcome (behaviour)
Infrastructure / non-functional	What the platform must provide so behaviour holds under real load (quality or constraint on behaviour)

The Derivation Chain

Business → functional → infrastructure. Skip a layer, or run backwards, and a requirement has nothing to trace to.

Functional Versus Non-Functional

Classify by what the statement promises, not whether it contains a number. “Answer in the customer’s language” = functional. “First token within two seconds at Saturday peak” = non-functional.

Rate Limits and Context Windows Are Requirement Inputs

API enforces RPM, ITPM and OTPM per model class. Peak concurrency and prompt size become infrastructure requirements. Cache reads do not count toward ITPM on most models. Context window bounds how much material one request can carry. Every API response reports live limits in anthropic-ratelimit-* headers.

The Architecture Decides Which Constraints Bind

Realtime interactive path → time-to-first-token and streaming. Overnight batch path → Batches API 24-hour window and queue limits. Caching layer converts a repeated large context from a throughput problem into a prefix-design obligation.

Key Concept: Requirements NAME the constraint. Choosing a model against that constraint is Domain 5’s job.

Exam Traps

• Classifying a latency target or throughput floor as functional because it is the most measurable statement
• Answering a requirements question with a model recommendation when the scenario mentions latency or cost
• Treating rate limits and context windows as implementation details to discover during development