CCDV-F - Applications and Integration (33.1% of the exam) - Section 2.1
Derive functional and infrastructure requirements from business requirements and solution architecture.
Published skill weight 3.4 percent. Covers translating a stated business need into the functional behaviour a Claude application must exhibit and the infrastructure it will require, working from the solution architecture rather than from implementation preference.
lock_openFree sampleApplications and Integrationmedium
A business requirement for an internal HR assistant reads: the assistant should give trustworthy answers about leave policy. The solution architecture already places the approved policy text in a document store the assistant can search, and a named policy owner is available to adjudicate answers. Which restatement is a usable functional requirement?
AThe assistant should be tuned and re-prompted until the reviewers on the project agree that its leave answers feel trustworthy during day-to-day use of the internal tool.
BThe assistant must be built on the largest model available to the team, on the grounds that answer quality on policy questions rises with model capability.
CFor each question in a fixed review set, the assistant must return an answer whose cited policy clause matches the clause the policy owner selects for that question.check_circle Correct
DThe assistant must carry a system-prompt instruction telling it to answer only from approved policy documents and to decline any question those documents do not cover.
A functional requirement derived from a business requirement must state an observable, testable condition rather than an intention or an implementation choice. Business requirements state desired outcomes in business language. Deriving a functional requirement means naming the observable behaviour, the input set it applies to and the authority that decides pass or fail, so that the same check can be run before and after any change.
Why A is wrong: Tempting because it names a review step and sounds rigorous, but it restates the vague word in the business requirement rather than replacing it, so there is no condition an engineer can build against or a test can fail.
Why B is wrong: Tempting because capability does correlate with quality, but this fixes an implementation choice instead of stating the behaviour required, and it can be satisfied in full while the assistant still answers from stale or unapproved text.
Why C is correct: Correct: it converts the business intent into an observable pass or fail condition, using a fixed input set and an authoritative human judgement, so the requirement can be tested repeatedly and regressions are visible.
Why D is wrong: Tempting because the wording sounds like a control, but an instruction describes intended behaviour rather than a checkable outcome, so nothing in it tells a tester whether a given answer met the requirement.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCDV-F bank for this domain.
The sampling temperature must be lowered for the duration of the peak hour, so that replies are shorter and more of the available capacity is left for the additional conversations.
errorWhy it is wrong: Tempting because temperature is an easy runtime knob, but it changes the variability of the sampled text rather than the volume of requests the service admits, so it leaves the capacity shortfall exactly where it was.
Raise max_tokens on the request, so the model has enough room to emit the tool call rather than stopping after its prose preamble.
errorWhy it is wrong: Truncation is a real cause of missing content and worth ruling out, but the failing responses end in prose rather than being cut short, so a larger output cap changes nothing about whether a tool is chosen.
Cap the model's output length so that no single conversation can exceed the per ticket figure, and review the cap monthly against the tickets that were cut off before an answer was reached.
errorWhy it is wrong: Tempting because an output cap does bound one component of spend, but it truncates answers instead of reducing work, so the saving is paid for in tickets that have to be handled again by a person.