Understanding Requirements

Understanding Requirements is 3.4 percent of the CCDV-F blueprint, close to two questions of the 53. It is the smallest sub-skill in the largest domain, and the one candidates most often assume they can answer from general experience. That assumption half holds. The elicitation craft is the same as for any system, but three requirement types behave differently once a language model is in the design, and the questions are built around those three.

The first is the quality bar. "It should be accurate" is not a requirement, because there is no threshold to test against and no way to tell a regression from ordinary variation. A usable version names the task, the acceptable failure rate, and how a sample will be judged.

The second is the operating envelope. Latency, throughput and cost per unit of work are not implementation details here. They decide the whole shape of the design, and a requirement fixing an answer inside one second rules out approaches that a twenty-minute allowance would welcome.

The third is data handling: what may be sent, where inference may physically run, how long anything is retained. Those are constraints on the platform itself, and finding one late invalidates architecture rather than code.

What the exam tests here

• •Converting a stated goal into an acceptance criterion measurable on a sample of real inputs
• •Separating what the system must do from how well, how fast and how cheaply it must do it
• •Recognising when a requirement rules out a language model entirely
• •Eliciting data-handling constraints before design begins, not after
• •Specifying the behaviour when the system is wrong, not only when it is right
• •Spotting the requirement that silently fixes the architecture, such as a hard interactive latency ceiling

A quality bar is a number and a judge

The requirement that matters most is the one stakeholders find hardest to state: how good is good enough. Pinning it takes three parts. A representative sample of real inputs rather than invented ones. A rule for deciding whether a single output passes, ideally objective and at worst a written rubric two people apply consistently. And a threshold on that sample the system must clear before release.

Doing this before any building has a second payoff beyond having a target. The exercise routinely reveals that stakeholders disagree about what a correct answer even looks like, which is far cheaper to discover in a meeting than in a post-launch review. Without those three parts you have an aspiration, and aspirations cannot detect regressions.

The operating envelope decides the architecture

Three numbers constrain the design more than any functional statement: how long a user will wait, how many requests arrive at peak, and what one completed unit of work may cost.

They interact with the platform in specific ways. A sub-second interactive ceiling pushes towards a smaller model, a shorter prompt and a streamed first token. A tolerance measured in hours opens asynchronous batch processing, which bills at half the standard rate. A per-item cost ceiling rules out multi-pass designs that call the model several times for each unit.

Gather all three early, because a design chosen against the wrong envelope is not tuned into compliance afterwards. It is rebuilt.

Data constraints are platform constraints

Ask what the system is allowed to be sent before deciding what it will be sent. Regulated inputs, customer records and proprietary source code all carry rules, and the answers change the platform rather than the prompt.

Whether inference may run outside a given jurisdiction is a real request parameter, not a line in a policy document. Retention rules interact with model availability, since some models are not offered under a zero-retention configuration. Third-party tools reached by an agent push the boundary further out, because content it fetches and results it sends leave your control.

Capture these as named requirements with an owner, and revisit them every time the tool surface grows.

Specify the failure behaviour

A requirements document describing only success is incomplete for a system that will sometimes be confidently wrong. Ask what the product does when confidence is low, when the model declines, when the dependency is unavailable, and when the answer is plausible but incorrect.

Those answers are product decisions rather than engineering ones. Abstain and hand to a human, present with a citation the user can check, degrade to a simpler deterministic path, or fail loudly. Each choice implies different work: an abstention needs a route to a person, citations need retrieval that can supply them.

Deciding it at requirements time is what prevents the default outcome, which is presenting a wrong answer with complete assurance.

Where candidates go wrong

Common questions