Home › Study guides › CCAR-P › Domain 6 › Lesson 6.1

CCAR-P · Domain 6 · 14% of the exam · Lesson 6.1 · 22 min read

Structured discovery: stakeholders, evidence and requirements design can use

How an architect runs discovery for a Claude system: who to involve, watching the work, real samples early, measurable requirements and a canvas to design from.

Written against objective 6.1 of the official CCAR-P exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

6.1.1 What "80% automation" leaves unanswered

Baltasar is chief operating officer of Almendra Hotels, a group of 40 hotels across Spain and Portugal. Guests write to the hotels about 60,000 times a month, by email, the website form and a messaging app, in Spanish, Portuguese and English. They move dates, ask for a cot or a late check-out, check the parking, or complain about a noisy room. Front-desk staff answer between check-ins, so messages sent overnight wait for the morning shift. Baltasar's brief to Marisa, the solution architect, fits on one line: "Automate 80% of guest messages by next summer."

The brief has a number, a scope and a deadline, so it looks like a requirement. It is not one yet. Eighty percent of what: messages, conversations or staff hours? Does "automated" mean a reply sent with no person involved, or a draft a receptionist approves? Which messages can a system act on at all, and which must never be answered without a person? Most of the answers sit outside Baltasar's office: with the receptionists, the owner of the reservations system, the data protection officer (DPO), and in the messages themselves.

Structured discovery is the planned, time-boxed investigation that finds those answers before anyone designs. It gathers the facts a design depends on from the people and data that hold them, and it ends with a written output that design can start from. A building architect works the same way. The client asks for "a house full of light"; the site survey finds that the plot faces north and a sewer runs under the garden. The drawings start from the survey, not from the wish.

6.1.2 What discovery must establish, and who holds it

Here is the shortcut that sinks a lot of discovery: a long meeting with the sponsor, another with a manager, and a requirements list by Friday. The sponsor knows the goal, the budget and the deadline. Baltasar does not know that guests who booked through an online travel agency must change the booking through that agency. Nor does he know which hotels run an older reservations system, or how often guests paste card numbers into messages.

Discovery has seven things to establish, each settled by different evidence. Marisa's checklist shows what her first three weeks found.

Almost every row is settled by someone other than the sponsor, or by the data itself. So the first artefact of discovery is a stakeholder map: every group that holds a requirement or can block launch, and who in each can say yes.

Two of these groups are often forgotten, and each can stop the project alone. The reservations system owner knows what the system lets another program read and change. The DPO decides what guest data may be used, where, and for how long. Guests are users too; the sample of their messages is their voice in discovery.

6.1.3 Watch the work, and get real samples early

Interviews are where discovery starts, and where it most often goes wrong, because people describe the work as it is supposed to be done. Asked how she handles a date change, a receptionist at the Seville hotel says: "I find the booking, change the dates and reply." Sitting beside her for a shift tells a different story. First she checks where the booking came from, because agency bookings go back to the agency. Her hotel is one of twelve still on an older version of the reservations system, where the front desk cannot change a booking, so she emails the central reservations team. And before promising parking, she opens a spreadsheet of hotel facts she only half trusts.

That is a show-me session: you watch someone do real work on real cases and ask "why did you do that?" at each step. None of this came up in the interview, and each detail decides what can be automated. Anthropic's ticket-routing guide starts in the same place: learn how the team handles the work today, including any automated rules already in place and where they fail. Marisa drew what she saw as a process map, one per kind of message, marking the system each step touches and where the work stalls.

The second habit is to get real samples in the first week, not after design. Marisa asked for 500 messages from the last twelve months, spread across hotel types, languages, channels and seasons, complaints included. The DPO approved the use, including a test run through Claude, and had names, booking references and card numbers replaced before anyone on the project read them.

Tagged by intent, language, data and action needed, the sample corrected several beliefs. Information questions, not booking changes, were the largest group: 31% of messages, against 29% booking changes, 24% requests, 11% complaints and 5% everything else. One message in five asked for two things at once. About 7% mentioned health, such as an allergy or a wheelchair, which data protection law treats with extra care, and 2% contained a pasted card number.

Last came a quick feasibility test. Marisa ran 50 sampled messages from five hotels through a plain prompt with each hotel's fact sheet, asking Claude to label each message and draft a reply. Anthropic's multilingual guidance says to test the languages you actually use; its benchmark table lists Brazilian Portuguese, not the European Portuguese many Almendra guests write. The labels held up in all three languages. The bad drafts came from bad facts: one sheet said the pool was open in January. A few hours turned "clean hotel facts" into a requirement. The test calibrates requirements; it proves nothing about the finished system, which is a later proof of concept's job.

6.1.4 Functional and non-functional requirements for an AI system

The common failure in writing requirements is a list that says only what the system does: answer questions, change bookings, handle complaints. Two designs can do all of that and still differ in everything that matters. One replies in a minute and is right four times in five; the other takes an hour and is right 97 times in a hundred.

Functional requirements say what the system does, task by task. Anthropic's customer-support guide recommends breaking the interaction into every distinct task before building, so each can be prompted and evaluated. Almendra's list starts with identifying each message's intent and language and answering information questions from the hotel's fact sheet. It adds date changes on direct bookings in the newer reservations system, within the rate rules. Complaints, health mentions and agency bookings go to staff with a summary and a draft reply to approve, and anything else goes to staff with a summary.

Non-functional requirements say how well, how fast, how reliably, under which rules and at what cost. An AI system adds two twists. Quality is a rate measured on a representative test set, never a guarantee, so each quality requirement names its test set and its segments, such as each language. That set is usually a held-out sample: real messages kept aside and never used while writing the prompt, so the score reflects cases the system was not tuned on. And the costliest error gets its own, stricter bar: a wrong booking change hurts far more than a clumsy sentence.

Anthropic's guide to success criteria asks for targets that are specific, measurable, achievable and relevant. It lists latency, price and privacy beside task accuracy, and notes that most use cases need several criteria at once. Achievable means anchored in evidence: Marisa's quality bars come from the feasibility test and from grading today's staff replies with the same rubric. The ticket-routing guide suggests no more than a 5 to 10% accuracy drop in non-primary languages, hence the per-language targets. The retention line needs the provider's facts: Anthropic's privacy centre states that API inputs and outputs are deleted within 30 days by default, with exceptions it lists. Almendra's own copies, from logs to the sample, are the design's to decide.

6.1.5 Prioritise, record what you assumed, and hand design a canvas

Discovery tends to fail at the end in one of two ways. One is a wish list of sixty items, each marked essential by someone; the other is no end at all, because some answer is always a week away. Both leave design with nothing to start from.

The cure for the wish list is MoSCoW prioritisation: each requirement is a Must, Should, Could or Won't (this time). Rank value (how much volume and pain an item removes) against feasibility (whether the data is reachable and the constraints allow it). At Almendra, information questions and simple requests in three languages are a Must: the largest share of the volume, with data a clean fact sheet can hold. Date changes on direct bookings are a Should, since they depend on the reservations interface. Baltasar's room-upgrade offers are a Could. Changing agency bookings, or any booking at the older-system hotels, is a Won't for phase one, written down so nobody assumes it.

The cure for endless discovery is a time box and two honest lists. An assumption is something you treat as true without proof, recorded with an owner and a date by which it will be checked. An open question is something you know you do not know that blocks a decision, again with an owner and a deadline.

Almendra's biggest open question is the sponsor's own number. The sample suggests about 45% of messages could be resolved end to end with data reachable today. About 80% could get, within 15 minutes, either a correct reply or a draft ready for staff to approve. Anthropic's customer-support guide puts typical deflection targets (the share of enquiries handled with no person involved) at 70 to 80%, depending on how complex the enquiries are. The sample shows how complex Almendra's are. Discovery does not choose for Baltasar. It hands him both readings, with the evidence.

Marisa's output is a one-page use-case canvas, backed by the full requirements list. Look at the last three lines: each assumption and open question carries an owner and a date, so design can start on the Musts while the rest is settled.

Use case: first replies to guest messages for 40 hotels, in Spanish, Portuguese and English, by email, web form and messaging app.
Sponsor: Baltasar (chief operating officer). Can block launch: data protection officer, reservations system owner.
Today: about 60,000 messages a month, nearly double in August; answered between check-ins; median first reply about six hours.
Evidence: 500 real messages with identities removed; show-me sessions at six hotels; a 50-message feasibility test.
Mix: information 31%, booking changes 29%, requests 24%, complaints 11%, other 5%; one message in five asks for two things.
Must: information questions and simple requests in three languages; complaints and health mentions sent to staff with a summary and a draft to approve; card masking; fallback to the staff queue; audit log; a maintained fact sheet per hotel.
Should: date changes on direct bookings in the newer reservations system, within the rate rules.
Could: room-upgrade offers.
Won't (phase 1): changes to agency bookings; any booking change at the 12 older-system hotels.
Non-functional: quality per language, escalation, 15-minute first reply, fallback, retention, audit and cost per message, as in the requirements list.
Risks: a wrong booking change; a complaint answered as routine; stale hotel facts.
Assumption A1: hotel managers can bring all 40 fact sheets up to date within six weeks. Owner: operations director. Check: five pilot hotels by 15 November.
Assumption A2: the newer reservations interface allows date changes under the rate rules. Owner: reservations system owner. Check: test environment by 30 October.
Open question Q1: does "80% automation" mean resolved with no person involved, or answered within 15 minutes by a correct reply or a draft ready for staff approval? Owner: Baltasar. Needed before success criteria are fixed.

The test of a discovery output is whether a designer can start from it without calling you. Every requirement traces to evidence or a named stakeholder, every Must can be tested, and every unknown has an owner and a date. The canvas names no model, pattern or integration: those are design decisions, each justified later by pointing back at a line on this page.

6.1.6 The exam traps

Every trap below skips the evidence: it designs from the brief, from a manager's account of the work, or from examples someone made up.

• ✗ Taking the sponsor's number as the requirement. ✓ Define it: 80% of what, counted how, from which baseline. Competing readings go to the sponsor as an open question, with the evidence.
• ✗ Gathering requirements from the sponsor and managers only. ✓ Map every group that holds a requirement or can block launch, and talk to the people who do the work. The DPO and system owners are the usual late surprises.
• ✗ Trusting the process as people describe it. ✓ Watch the work in show-me sessions and map it. Workarounds, side spreadsheets and hidden hand-offs decide what can be automated.
• ✗ Writing requirements from invented or hand-picked examples. ✓ Collect a representative real sample in the first week, every language, channel and complaint included, under the data owner's rules.
• ✗ Listing only functions, or non-functional wishes such as "accurate" and "secure". ✓ Set measurable targets for quality per segment, latency, availability, compliance, auditability and cost, each with a measure and an owner.
• ✗ Choosing the model, pattern or integration during discovery. ✓ Record requirements, constraints and assumptions first. Anthropic's agent guidance favours the simplest solution that works, and only discovery's evidence shows what that is.

6.1.7 Put it together: run discovery on one inbox

You now have every piece: what to establish, who holds it, how to gather evidence, and how to write and rank requirements. Almendra's one-line brief has become a page design can start from, plus one question only Baltasar can answer. The quickest way to own the method is to run it once on an inbox you know.

The rest of this domain starts from that page. Communicating architectural decisions and trade-offs (6.2) justifies each design choice by pointing back at a requirement on it. Feedback loops and expectation alignment (6.3) turn the candidate success criteria, and Baltasar's open question, into commitments and SLAs both sides agree on. Documentation (6.4) keeps the requirements versioned beside the architecture, and lifecycle support (6.5) returns to discovery at every iteration, with production traffic as the new sample.

Key takeaways

• ✓ A sponsor's brief is a goal, not a requirement; discovery turns it into written, measurable, prioritised requirements.
• ✓ Discovery establishes stakeholders, current process and volumes, pain points, data, constraints, success criteria and risks, each from the people or evidence that hold it.
• ✓ Map every group that holds a requirement or can block launch; the people who do the work and the owners of systems and data are the easiest to skip.
• ✓ Watch the work in show-me sessions, map it, collect a representative real sample early, and use a quick feasibility test to calibrate requirements.
• ✓ For an AI system, non-functional requirements (quality as a measured rate per segment, latency, availability, compliance, auditability, cost) matter as much as the functions.
• ✓ Prioritise with Must, Should, Could and Won't, record assumptions and open questions with owners and dates, and hand design a canvas it can start from.

Check your understanding

4 questions written for this lesson, then one from the CCAR-P question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Define success criteria and build evaluations
• Customer support agent
• Ticket routing
• Multilingual support
• Building effective agents
• How long do you store my organization's data?
• The CCAR-P exam guide, summarised