Functional requirement
A capability or behavior that the system must provide.
Exam context: 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.
See also: 2.1 Understanding Requirements
Non-functional requirement
A quality attribute or operational constraint for the system.
Exam context: 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.
See also: 2.1 Understanding Requirements
Acceptance criteria
Specific conditions used to determine whether a requirement has been satisfied.
Exam context: 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.
See also: 2.1 Understanding Requirements
Scalability
The ability of a system to handle increasing workload or demand.
Exam context: 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.
See also: 2.1 Understanding Requirements
Performance requirement
A measurable constraint on system responsiveness or throughput.
Exam context: 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.
See also: 2.1 Understanding Requirements
Infrastructure requirement
Operational or platform capability required to support the application.
Exam context: 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.
See also: 2.1 Understanding Requirements
Requirements
The statement of outcomes and measurable constraints, before a model or a framework is chosen.
Exam context: Later stages have nothing to verify if this stage stays vague. When: A new system, or a change that alters what users were promised. When not: You already have an accepted requirement and you are fixing a defect inside it.
See also: 2.2 Systems Life Cycle
Verification
Tests and evaluations that show the acceptance criteria hold.
Exam context: A 200 from the API does not show that the summary, the tool call, or the cost target is right. When: Before release, and again when the prompt, tool, or model version changes. When not: You treat a single happy-path transcript as the whole test.
See also: 2.2 Systems Life Cycle
Operation
The running system, watched for latency, errors, spend, and quality.
Exam context: Production traffic is the input distribution you did not write by hand. When: After release, for as long as the system is in use. When not: You stop looking once the deploy pipeline is green.
See also: 2.2 Systems Life Cycle
Change control
A named version of the model, prompt, and tool contract, reviewed before it replaces the last one.
Exam context: Those three can change behavior with no type error. When: An upgrade, a prompt edit, or a schema change. When not: You edit the live prompt in place because the diff looks small.
See also: 2.2 Systems Life Cycle
Messages API
A stateless HTTPS request. The client sends system content and the full message list.
Exam context: Nothing on the server reconstructs the dialogue for you. When: Interactive work, or any job that needs another turn after a tool result. When not: A large pile of independent requests that nobody is waiting on. That is a batch candidate.
See also: 2.3 Claude API Mechanics
stop_reason
The field that says the turn finished, wants a tool, or was truncated.
Exam context: The first content block can be text while a later block is a tool call. When: Every client that loops. When not: You scan the assistant's prose for a sentence that says it is done.
See also: 2.3 Claude API Mechanics
Streaming
Tokens delivered as they are generated.
Exam context: A person who is watching should not wait for the full body. When: Someone is waiting on the reply. When not: You are trying to reduce the token bill. Streaming does not do that.
See also: 2.3 Claude API Mechanics
Message Batches
An asynchronous bulk API. Notes: lower cost, up to about a day, custom ids, no multi-turn tool use.
Exam context: Independent overnight work should not pay real-time rates. When: Nobody is waiting, and each item can finish in one request. When not: A user is watching, or the item must call a tool and then continue.
See also: 2.3 Claude API Mechanics
Prompt caching
Reuse of a stable prefix.
Exam context: Policies and examples that never change should not be reprocessed at full price. When: The prefix is identical across calls and placed first. When not: The user text, the date, or a retrieved document sits at the front of the cached region.
See also: 2.3 Claude API Mechanics
REST and JSON
HTTP methods, status codes, and a JSON body the client parses.
Exam context: The API fails in the ordinary ways: auth, bad body, rate limit, timeout, server error. When: Every Messages call and every tool that wraps another HTTP API. When not: You treat every non-200 as the same retry.
See also: 2.4 Software Engineering Foundations
Asynchronous client
The call yields, times out, and can be cancelled. Independent calls can overlap.
Exam context: Model latency is long compared with local work. When: A request, a stream, or a set of independent documents. When not: The next call needs this call's output. Those stay ordered.
See also: 2.4 Software Engineering Foundations
Version control
Prompts, schemas, and model ids committed with the caller.
Exam context: They are behavior. A missing diff is a missing review. When: Any change a teammate should be able to revert. When not: A secret. Tokens stay out of the repository.
See also: 2.4 Software Engineering Foundations
Review and refactor
A human check of the diff, and a split that makes the next diff small.
Exam context: Language behavior will not fail the type checker. When: A prompt, a schema, or a function that does too many jobs. When not: You restyle code that already has a clear contract and no behavior change.
See also: 2.4 Software Engineering Foundations
Surface
Claude Code, Desktop, claude.ai, or the API and SDKs.
Exam context: Each one loads different tools and different configuration. When: The user already lives in that product, or you must own the loop. When not: You assume a CLAUDE.md rule applies to an API service.
See also: 2.5 Claude Application Design
Content boundary
Instructions in one place, untrusted text in another.
Exam context: Text in the instruction channel is treated as instructions. When: The input is a user, a document, a web page, or a tool result you did not author. When not: The text is a policy your team wrote and you intend as an instruction.
See also: 2.5 Claude Application Design
Schema
The shape the application parses and rejects on mismatch.
Exam context: Downstream code needs fields, not a paragraph that happens to contain them. When: A later step reads an amount, an id, or a list. When not: The user only wanted prose and nothing in your system branches on it.
See also: 2.5 Claude Application Design
Session hygiene
The history you resend still matches the world.
Exam context: The API will treat stale tool results as facts. When: Files, records, or policy changed after the tool ran. When not: The same task is continuing and the tool results are still the ones you would fetch now.
See also: 2.5 Claude Application Design
Plugin
An installable extension of a Claude surface, versioned like a dependency.
Exam context: Behavior that depends on an undeclared plugin is not reproducible. When: The surface is Code or Desktop and the capability comes from a plugin. When not: You are on the raw API. There, the equivalent is a tool you implemented and shipped in your service.
See also: 2.5 Claude Application Design
Project CLAUDE.md
Instructions committed with the repository.
Exam context: A clone should receive the team's conventions. When: Commands, layout, and review rules everyone follows. When not: A personal preference, or a rule that must be enforced even when the model ignores text.
See also: 2.6 Configuration Management
User CLAUDE.md
Instructions in the home directory, not in git.
Exam context: They must not become the team's undocumented standard. When: Something only you want. When not: A convention a new teammate is expected to follow.
See also: 2.6 Configuration Management
settings.json
Client configuration with precedence. This repo's lesson order is managed, local, project, then user.
Exam context: Enforcement does not depend on the model reading a paragraph. When: Permissions and other controls that must hold. When not: You are explaining a coding style. That can live in CLAUDE.md.
See also: 2.6 Configuration Management
Pin and version
A model id and a prompt text that change only through review.
Exam context: Both change behavior without a compile error. When: Production and any shared environment. When not: A local experiment that is not the team's running configuration.
See also: 2.6 Configuration Management
Plugin dependency
A named, versioned plugin the project expects.
Exam context: Capability that exists on one laptop is not part of the shared system. When: The surface is Claude Code or Desktop and the workflow needs that plugin. When not: The plugin is a personal experiment. Leave it in user configuration.
See also: 2.6 Configuration Management