The Four Requirement Categories for the CCAR-P Exam

Four buckets that force a vague ask into requirements

Once you are translating preferences into constraints, you need somewhere to put what you surface, and you need to know when you have covered enough ground. The four requirement categories do both. The CCAR-P exam treats them as an understand-level framework: a statement like "we want this to feel seamless" is not yet designable, and forcing it through four questions is what turns it into requirements the architecture can be built against.

The four categories are what the system must do, must not do, must cost, and must prove. A vague ask usually hides one or more specific answers in each bucket, and working through all four is what stops a discovery call from collecting only the half of the requirements the stakeholder happened to mention.

The two categories stakeholders give you freely

Must do captures the capabilities the deployment is responsible for delivering, expressed as business outcomes rather than features. This is where you separate the work Claude owns from the work that stays with an existing system or a human. Stakeholders describe this readily, because it is the outcome they came to talk about.

Must cost captures the budget-side constraints, expressed in terms the stakeholder controls: a latency target, a per-interaction cost ceiling, or a volume forecast. These become hard design constraints, not afterthoughts, and stakeholders will usually engage with them once you ask, because cost is a language the business already speaks. The trap is not that these two categories are hard to elicit; it is that they feel complete on their own.

The two categories you have to go get

Must not do captures the boundaries, the prohibited actions, and the cases that must route to a human. Stakeholders rarely volunteer these, because a boundary is not the outcome they are excited about, so you have to ask for them explicitly. "What should this never do on its own?" and "what has to go to a person?" are the questions that surface them. Left unasked, the design silently permits actions the business never intended to allow.

Must prove captures the evidence the deployment must be able to produce. In a regulated or audited workflow, proof obligations are part of the requirement set, not a compliance nicety. An audit trail, a data-handling record, an authorization log: these are requirements the same way a latency budget is. Identifying them in discovery is dramatically cheaper than discovering them during a legal review weeks later, when the design is already built and the missing evidence forces a costly retrofit. Treating a proof obligation as a nice-to-have is one of the most expensive mistakes a discovery call can make.

Why all four, not three

The value of the framework is that it makes omissions visible. If your notes are full of must-do items and a latency number but empty on boundaries and evidence, the framework tells you the call is not finished, regardless of how productive it felt. "Seamless" may really mean a latency budget the user should not notice (must cost), a handoff that should not interrupt the flow (must do), a failure state that must not expose internals (must not do), and an audit record the workflow legally has to keep (must prove). One preference, four categories, and you only have a designable requirement set once each has been checked.

What the exam trips candidates on

The first trap is asking only about what the system must do and skipping must-not-do and must-prove because the stakeholder never raised them. That is exactly the point of the framework: those two categories are the ones stakeholders omit, so the architect who waits to be told will systematically miss them. The credited answer treats the stakeholder's silence on boundaries and evidence as a prompt to ask, not as confirmation there are none.

The second trap is treating a proof obligation as a nice-to-have rather than a first-class requirement. An audit trail or evidence artifact for a regulated workflow ranks alongside the must-do capability, and downgrading it is how a deployment sails through functional testing and then fails a compliance review. The exam rewards putting must-prove on equal footing with the rest.

Common misreadings to avoid

How this shows up on the exam

Expect a discovery scenario and a question about which requirement category was neglected, or which requirement an architect failed to elicit. The reliable reading is that the neglected category is almost always must-not-do or must-prove, because those are the ones stakeholders do not raise on their own, and that a proof obligation is a first-class requirement rather than an optional add-on.

This framework builds on translating preferences into constraints, which produces the raw constraints the categories organise, and it feeds the discovery translation table, where each finding becomes a row. The must-prove and must-not-do categories are also what you check options against when recommending an option against stated constraints.