CCAR-P 6.1 — Structured discovery and requirements

Structured discovery, end to end

Frame the problembusiness outcome, not “use AI”
Map stakeholderssponsor, users, IT, risk, legal
Gather requirementsworkflow, data, constraints
Agree success criteriaspecific, measurable, signed

Open questions or conflicts → go back and ask before designing

Each step produces something written down. Discovery ends with success criteria the client has signed — not with a demo.

Start from the problem, not the product

Clients usually arrive with a solution already in mind: “we want a chatbot”, “we want an agent that reads every contract”. Structured discovery politely sets that aside and asks what outcome the business needs. Is the claims team too slow? Are errors costing money? Is a regulator asking for consistency? The answer changes the architecture. A slow team might need a simple summarisation step inside an existing tool; an error problem might need extraction with human review; a consistency problem might need a fixed workflow rather than an open-ended agent.

Anthropic’s own guidance on agents makes the same point from the engineering side: start with the simplest thing that could work, and only add agentic complexity when simpler approaches demonstrably fall short, because agents trade extra latency and cost for better performance on open-ended tasks. You cannot make that call without knowing the task — which is what discovery is for.

The client says	Discovery question	What it tells you
“We want a chatbot for customers.”	Which questions arrive today, how many, and which ones cost the most to answer?	Scope, volume and where the value really is
“It must be accurate.”	Accurate at what? What happens when it is wrong, and who notices?	The error that matters and the review step it needs
“It should be fast.”	Fast for whom — an agent on a live call, or an overnight report?	Latency target, and whether batch processing is acceptable
“Use all our documents.”	Which systems hold them, who owns them, and what may leave the building?	Data sources, access rights and residency limits

Who to talk to

A single enthusiastic sponsor is not a requirements source. Each group sees a different slice of the problem, and the one you skip is the one that blocks go-live. The sponsor owns the outcome and the budget. Frontline users know the real workflow, including the workarounds nobody wrote down. IT owns the systems you must integrate with and the identity provider. Risk, compliance and legal own the rules — data handling, retention, what must have a human decision. Security will review how data flows to the model. Operations will run it after you leave.

Stakeholders around one engagement

Discoveryone shared requirements log

Sponsoroutcome, budget, deadline
Frontline usersreal workflow, edge cases
IT / platformsystems, identity, hosting
Risk & legaldata rules, human sign-off
Securitydata flows, access review
Operationswho runs it after launch

Each spoke owns requirements the others cannot give you. Missing one usually surfaces late, as a blocker.

Worked example · A regional insurer’s “claims copilot”

The head of claims at a mid-sized insurer asks for “a Claude copilot that handles first notice of loss”. She wants a demo in two weeks.

Frame the problem. In the kickoff you ask what “handles” means. It turns out handlers spend about 20 minutes re-keying details from emailed claim forms into the claims system. The outcome is shorter handling time, not full automation.
Talk to users. Two handlers show you their workflow. Half the forms arrive as scanned PDFs with handwriting, and fraud flags must stay with a human. Neither fact was in the brief.
Talk to IT and risk. IT says the claims system has a REST API but writes need an approval step. Compliance says policyholder data may only be processed in approved regions and every AI-filled field must be reviewable.
Write the requirements. Extract 14 named fields from emails and PDFs into a draft claim; a handler confirms before submission; no automatic decisions on fraud or payout.
Agree success criteria. Field-level accuracy of at least 95% on 300 historical claims chosen by the claims team, including 50 handwritten ones; median handling time under 8 minutes in a four-week pilot; zero fields submitted without handler confirmation.

Takeaway: The two-week demo would have shown a chatbot. Discovery found an extraction workflow with a human checkpoint, plus a test set to prove it — a smaller, safer and more valuable build.

Turning wishes into testable requirements

Anthropic’s documentation on evaluation says good success criteria are specific, measurable, achievable and relevant. “Safe outputs” is a wish; “fewer than 0.1% of 10,000 test outputs flagged by the content filter” is a criterion. The same docs list the dimensions most use cases care about — task fidelity, consistency, relevance and coherence, tone and style, privacy preservation, context utilisation, latency and price — and stress that most projects need several at once. Walk the client through that list; it is a fast way to surface requirements they had not thought to state.

From wish to requirement

What the sponsor wrotetext

Goal: AI assistant for claims.
Must be accurate and fast.
Should use our data.
Needs to be secure.
Launch next quarter.

After discoverytext

Task: extract 14 fields from
  FNOL emails + PDFs to a draft.
Accuracy: >=95% per field on
  300 labelled claims (owner:
  claims QA lead).
Latency: draft ready < 60 s.
Human: handler confirms every
  draft; no fraud/payout calls.
Data: approved region only;
  no training on client data.
Pilot: 4 weeks, 12 handlers.

The right-hand version can be tested, priced and signed. Every line names a number, a data set or an owner.

Separate functional requirements (what the system does) from non-functional ones (how well, how fast, under what rules). Non-functional requirements are the ones clients forget and architects get blamed for: peak volume, latency, availability, cost ceiling, data residency, audit logging, accessibility. Also record what is explicitly out of scope — it protects both sides when the pilot succeeds and the wish list grows.

A discovery question bank (reuse per engagement)text

OUTCOME   What decision or task gets better? How is it measured today?
USERS     Who uses it, how often, on what device, in what language?
WORKFLOW  Walk me through the last real case, step by step.
DATA      Where does input live? Who owns it? What may not leave?
ERRORS    What does a bad answer cost? Who catches it today?
HUMAN     Which decisions must stay with a person?
VOLUME    Requests per day, peak hour, growth next year?
LATENCY   Live (seconds) or offline (hours)?
BUDGET    Cost ceiling per task or per month?
SUCCESS   What number, on what test set, means "go"?
OUT       What are we deliberately not doing in phase one?

Handling conflict and ambiguity

Stakeholders disagree, and discovery is where you find out. The sponsor wants full automation; compliance wants a human on every decision. Do not resolve it by quietly picking a side in the design. Write the conflict down, show the options with their consequences, and get the person who owns the decision to make it. Communicating those trade-offs is covered in 6.2; here the skill is noticing and recording the conflict before it is buried in the architecture.

Worked example · A hospital’s discharge summaries

A hospital’s digital lead wants Claude to draft discharge summaries. The chief nursing officer, IT security and the privacy officer have not been involved.

Map stakeholders. You add clinicians (who sign summaries), the privacy officer and IT security to the discovery plan, not just the digital lead.
Find the conflict. Clinicians want drafts inside the electronic record; security will not allow a new integration this year. You log it as an open decision with two options: a read-only export to a separate review tool, or waiting for the integration window.
Pin the rule. The privacy officer confirms the contractual and regulatory conditions for processing patient data (the compliance detail belongs to domain 5). You record them as hard constraints, not preferences.
Agree the test. A panel of three clinicians grades 100 drafts from de-identified past cases against a written rubric; the target and the rubric are signed before build starts.

Takeaway: The architecture is still undecided — correctly. Discovery produced the constraints, the open decision and its owner, and a way to measure success.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Choosing a model or building an agent in the first meeting because the sponsor asked for one.	Frame the business problem and constraints first; pick the simplest architecture that meets them.
Taking requirements only from the executive sponsor.	Include frontline users, IT, security, risk/legal and operations; each owns requirements others cannot give.
Accepting “accurate”, “fast” and “secure” as requirements.	Convert each into a measurable criterion with a test set, a threshold and an owner.
Resolving stakeholder conflicts silently inside the design.	Log the conflict, present options with consequences, and have the decision owner choose.
Leaving scope open-ended to seem flexible.	Write down what is out of scope for phase one so success can be declared.

You should now be able to

Reframe a solution-shaped request (“we want a chatbot”) as a business problem with a measurable outcome.
Identify the stakeholder groups for an engagement and the requirements each one owns.
Separate functional and non-functional requirements, including latency, cost, volume and data constraints.
Write success criteria that are specific, measurable, achievable and relevant, with a test set and owner.
Record conflicts, open decisions and out-of-scope items instead of resolving them silently.

Structured discovery and requirements