Spotting Undocumented Assumptions for the CCAR-P Exam

Why a reasonable requirement can still be wrong

Discovery produces a translation table whose assumption column exists precisely so that unconfirmed items are flagged. This skill is the audit that catches the ones that were not flagged. The CCAR-P exam frames it as an analyse-level task: given a requirements document and the discovery-call record it came from, find the item that no stakeholder actually said and that was never labelled as an assumption.

The difficulty is that the smuggled item does not look wrong. It reads as reasonable, it is consistent with the requirements around it, and it often sounds more diligent than the ones that are genuinely sourced. That plausibility is exactly what lets it survive a casual review. The audit has to resist judging by feel and instead check each line against the record.

The traceability rule

The rule that makes the audit mechanical is simple: every requirement in the document must trace back to one of two things, a stakeholder statement or an explicitly labelled assumption with an owner. Anything that traces to neither is an undocumented assumption, regardless of how sensible it sounds. This converts a vague "does this feel right?" into a checkable procedure: for each line, point to the statement in the discovery record that supports it, or to the assumption label that flags it. If you can point to neither, you have found the problem.

This is why the discipline of the translation table matters upstream. If assumptions were labelled honestly during discovery, the audit is short. If they were quietly folded into decisions as if they were facts, the audit is where that finally surfaces, hopefully before the design is built around them.

Plausibility is the trap, not the test

The requirement that fits naturally with its neighbours is the dangerous one, not the safe one. An audit that asks "does this requirement make sense alongside the others?" will pass exactly the assumptions it should catch, because a well-chosen assumption is designed to fit. Consider a requirements document for a support assistant whose stakeholder said "anything big needs a person's sign-off," "draft the reply but we send it ourselves," and "it has to feel instant." Requirements about human send, human approval of large refunds, and a low latency budget all trace cleanly to those statements. A fourth requirement, "retain transcripts sixty days for analytics," sounds perfectly reasonable and fits the set, but no stakeholder statement supports it. It is the undocumented assumption, and its plausibility is precisely why it slips through.

Where assumptions like to hide

Retention and data-handling requirements are a recurring hiding place. A line like "transcripts retained ninety days" or "PII masked before logging" reads as technically diligent, the kind of thing a careful architect would include, so reviewers nod past it. But a retention period is a specific claim with legal and cost consequences, and if no stakeholder set that number, the architect chose it, which makes it an assumption in need of confirmation. The lesson generalises: the more a requirement sounds like responsible default engineering, the more worth checking it is against the record, because that is exactly the register in which invented requirements are written.

What the exam trips candidates on

The first trap is assuming a requirement is legitimate because it fits naturally with the others. The exam builds documents where the smuggled assumption is the most consistent-seeming line, so a candidate reasoning from coherence rather than traceability picks a genuinely sourced requirement as the odd one out. The credited move ignores fit and checks the record.

The second trap is overlooking a plausible-sounding retention or data-handling requirement that no stakeholder statement supports. Because these read as diligent, they are easy to accept as obviously fine. The exam rewards treating a specific data-handling figure with no source as suspect precisely because it sounds responsible.

Common misreadings to avoid

How this shows up on the exam

Questions present a requirements document alongside a discovery summary and ask which item is the undocumented assumption. The dependable method is to match each requirement to the record and pick the one with no supporting statement, ignoring how reasonable it sounds, and to watch retention and data-handling lines especially closely because that is where smuggled assumptions cluster.

This audit is the analyse-level counterpart to building the discovery translation table, whose assumption discipline it enforces, and it shares its logic with the premature-design-sketch failure, where unasked questions leave constraints undocumented in the first place. The same traceability mindset returns in the documentation completeness test.