Home › Study guides › CCAO-F › Domain 4 › Lesson 4.1

CCAO-F · Domain 4 · 16% of the exam · Lesson 4.1 · 20 min read

Analysing requirements and use cases with Claude

How to turn messy stakeholder notes into traceable requirements with Claude, surface the gaps and conflicts, and decide which steps of a use case suit Claude.

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

4.1.1 Why a tidy list is not yet a set of requirements

Grace is a business analyst at Larchmere Insurance, a regional home and motor insurer. The company wants customers to report claims through an online form instead of by phone, and IT needs the requirements in three weeks. Grace has interview notes from two claims handlers, Freya and Tom, a summary of a customer focus group, an email from the compliance officer and a list of constraints from IT. Five documents, five writing styles, and some forty wishes scattered through them.

She pastes everything into Claude and asks: "Turn these notes into requirements." A minute later she has twenty-six neat statements, each starting "The form shall". Look closer, though. Freya wants damage photos to be mandatory and Tom wants them optional, yet the list says "The form shall allow photo upload", a compromise nobody agreed to. The focus group asked to save a half-finished claim, and the list lets customers return "within 30 days", a number no one gave. And nothing says who asked for what, so when IT pushes back, Grace cannot tell whom to call.

Claude did what the request asked: it made the notes tidy. Tidy is not analysed. Requirements analysis turns what stakeholders say into an agreed list of what a solution must do, and it has three jobs. Organise what people said so every line can be traced to its source. Find what they left out or disagree about. Then get the people who own those decisions to make them. Claude is very good at the first two; Anthropic's use-case guide on analysing feedback describes letting Claude do "the exhaustive reading and sorting". The third job is not Claude's: those decisions belong to the people who will answer for them.

The same week, Alan, the claims manager, asks Grace a second question: could Claude help triage incoming claims, sorting each one by type and urgency? That is a use case, a specific job someone proposes to hand to Claude, and the same division of labour answers it.

4.1.2 Sort what people said, and keep where it came from

It is tempting to ask for one clean list and put the notes away. Resist it. A requirement that has lost its source cannot be checked, questioned or defended. When IT says photo upload is expensive, Grace needs to know whether that wish came from a handler, from the focus group or from Claude itself.

The fix is traceability: every requirement points back to the person who asked for it, ideally with a short quote. Think of an expense report. It is useful only because every line still points to a receipt, and a line without a receipt gets queried. In the same way, traceability lets you check the list against the notes in minutes, and it exposes anything Claude added on its own, because that line has no receipt. Anthropic's advice on reducing invented details says the same: have Claude cite a source for each claim, so the answer can be audited.

Two more habits help. Group requirements by theme (reporting the claim, evidence, privacy, what happens next), so each stakeholder can find their part. And record priority as the source gave it, must-have or nice-to-have: the compliance officer writes "must", the focus group "would like". Claude records priority; it does not award it. You do not need to tidy the notes first, since Claude copes with mixed formats and incomplete notes. You do need to keep them apart.

Here is Grace's second attempt. Look at the goal stated first, and at the tags: a short label in angle brackets before and after each source, such as <interview_freya>, so Claude can tell one voice from another. Then look at the three rules, for Claude's own ideas, for disagreement and for vague wishes.

Context: Larchmere Insurance is replacing phone claims with an online claims form. The goals are fewer incomplete claims and faster first contact with the customer. I will share your output with the claims manager and IT.

Task: turn the five sources below into draft requirements for the form.

Output: a table with the columns Theme, Requirement, Must-have or nice-to-have (as the source puts it), and Source (who said it, with a short quote).

Rules:
- Use only these sources. If you add a requirement of your own, mark it SUGGESTION and leave Source empty.
- Where sources disagree, do not choose. List each conflict under the table, with both sides and their sources.
- Where a need is vague, write a question for the person who raised it instead of guessing a number.

<interview_freya>...</interview_freya>
<interview_tom>...</interview_tom>
<focus_group_summary>...</focus_group_summary>
<compliance_email>...</compliance_email>
<it_constraints>...</it_constraints>

4.1.3 Find the gaps, the conflicts and the open questions

With the sources labelled, Claude can do something a tired reader often cannot: hold all five documents in view at once and notice where they fail to fit. Tom wants the policy number checked the moment it is typed; the IT list says the form cannot reach the policy database this year. Read one at a time, the notes hide that clash.

Three kinds of problem are worth asking Claude for by name.

Learn the three kinds. Each one ends as a question to a named person, not as a line in the requirements.

Now the trap. Ask Claude to "resolve the conflicts" and it will, plausibly and quietly: photos become optional, and the output reads as if someone had decided. Nobody did. A clash between stakeholders is a business decision with costs on both sides. Optional photos may mean more incomplete claims; mandatory ones may shut out a customer whose car has been towed away. Claude can lay out the options and what each would cost, which helps Alan decide. The decision stays with him.

One limit remains. Claude can only spot gaps in what is in front of it. It cannot know that Larchmere's call centre promises a callback within one working day unless it is in what Grace gave it. So turn the tables and invite Claude to ask you questions about what the sources do not cover, as Anthropic's AI Fluency course suggests when you plan a project. Answer what you can, and add the rest to the question list.

4.1.4 Write each requirement so someone can check it

Take the sentence "The form must be quick and easy to use." Everyone agrees with it, and nobody can test it. A requirement earns its place when someone can tell, at the end, whether it has been met. Plain-language formats help, and the most common is the user story: "As a [who], I want [what], so that [why]." Each story carries acceptance criteria, the conditions under which it counts as done.

The format does two useful things. The "so that" keeps the reason attached, so IT can propose a cheaper way to meet the same need. And writing the criteria drags ambiguity into the open: you cannot write "done when" for photo upload without knowing how many photos, in which file types. Claude drafts stories and criteria quickly from a traced list. Your check is that every number and condition in the criteria comes from a source or is marked for checking.

Here is an excerpt from Grace's draft. Look at the [CHECK] markers, which keep an open conflict and a missing number visible instead of guessed.

Story 1: As a customer reporting damage to my car, I want to add photos from my phone, so that the handler can assess the damage without a visit. (Sources: Freya; focus group)
Done when:
- Photos can be added from the phone's camera or gallery.
- Only the file types on IT's list are accepted, with a plain message for any other type. (Source: IT constraints)
- [CHECK: Freya wants photos mandatory, Tom wants them optional. Open conflict for Alan.]
- Up to [CHECK] photos per claim. (No source gives a number.)

Story 2: As a customer with an injury, I want to know how to share medical details safely, so that I do not have to type them into a web form. (Source: compliance email)
Done when:
- The form asks no health questions. (Source: compliance email)
- The confirmation page tells the customer how medical details will be collected. [CHECK with compliance: which channel?]

4.1.5 Prioritise, label the assumptions, then validate

IT has already warned that not everything will fit into the first version, so the list needs an order. Three questions set it. Value: how much does the requirement serve the goal of fewer incomplete claims and faster contact? Effort: how hard is it to build? Risk: what goes wrong if it is missing or wrong, for customers, for compliance, for the company? Claude can draft a ranking in seconds. The danger is that the ranking looks equally solid everywhere, when some of its inputs are facts and others are guesses.

So ask Claude to label every input as a fact, with its source, or as an assumption. The fraud declaration is a must because the compliance email says it is mandatory: that is a fact. Saving a half-finished claim is "high effort": that is Claude's assumption, and only IT can confirm it. Even facts need care. Nine customers who volunteered for a focus group are not all customers. Anthropic's feedback-analysis guide makes the same point: Claude tells you what is in the data, and you judge whether the sample represents your users.

Then comes validation: the people who gave the requirements confirm them before anything goes to IT. A good waiter reads the order back before it goes to the kitchen; it takes a minute and saves a wasted meal. Grace sends each stakeholder the lines traced to them, with their open questions, and Alan settles the conflicts and the final order. Claude can draft those messages. The confirmation has to come from the people.

4.1.6 Size up a use case: Claude, a person or a technical build

Now Alan's question: could Claude help triage incoming claims? Both quick answers are wrong. "Yes, let it handle triage" hands Claude decisions about cover and urgency that someone must answer for. "No, it cannot connect to our claims system" throws away the parts it does well. The better answer starts where requirements start: what should triage achieve? Alan's answer is every claim with the right team within a day, and urgent cases, such as a family who cannot stay in their home, seen first.

Next, split the work into steps and put each one in one of three places. Reading, summarising, classifying, comparing and drafting suit Claude. Judgment, approval, relationships and accountability need a person: nobody can hand Claude the decision on cover, or the call to a customer whose kitchen has flooded. And any step that needs Claude wired into the company's own systems, such as writing the claim type into the claims system, is a technical build. That is not a prompt an Associate writes. It goes to IT or to Claude Architects and Developers, the technical specialists who build such connections.

Anthropic's AI Fluency course calls this delegation: understand the goal, know what the AI does well and badly, then divide the work, because the aim is not to automate everything. Two cautions follow. Decide the split before anyone writes a prompt or a specification, and have Alan confirm it: where Claude stops and a person approves is itself a requirement. And real claims carry personal and health details, so any trial uses only data your policy allows, such as anonymised past claims.

4.1.7 The exam traps

Every trap in this objective lets Claude, or the finished look of its output, stand in for a decision a person should make.

• ✗ Forwarding the tidy list from a one-line request. ✓ Ask for requirements traced to their sources, with conflicts and gaps listed separately. A polished list can hide merged views and invented numbers.
• ✗ Letting Claude settle a disagreement between stakeholders. ✓ Have Claude set out the options and their trade-offs, then take the decision to the person who owns it. Claude's pick would read as agreed when nobody agreed it.
• ✗ Filling a gap with Claude's best guess. ✓ Turn each gap or vague word into a question for the person who can answer it. A guessed number looks exactly as solid as a real one.
• ✗ Writing requirements as aims such as "fast" or "easy". ✓ Write user stories with acceptance criteria someone can test, with every number traced or marked for checking.
• ✗ Treating a confident priority ranking as fact. ✓ Label each input as fact or assumption, confirm the assumptions with the people who know, and validate the result with stakeholders. A ranking is only as sound as its inputs.
• ✗ Judging a use case as all Claude or not for Claude. ✓ Split it into steps: Claude for reading and drafting, people for judgment and approval, and a technical build, escalated, for anything wired into company systems.

4.1.8 Put it together: analyse a small set of requirements

You now have the whole method. Label and trace the sources, turn gaps and conflicts into questions, and write stories someone can test. Rank with assumptions labelled, validate with the owners, and split a use case by step. The quickest way to trust the method is to take one part away and watch what goes wrong.

Agreed requirements and a use case split into steps are where the rest of Domain 4 begins. Research and process optimisation (4.2) looks at how the work runs today and where the time goes. Solution design (4.3) turns validated requirements into a first version you can test with the people who asked. Workflow integration (4.4) decides where the Claude steps sit in a team's routine and who approves what.

Key takeaways

• ✓ Claude organises, traces and questions; the people who own a process decide, so a requirements list is finished only when they confirm it.
• ✓ Label each source, state the goal, and ask for every requirement with its source and the priority that source gave it.
• ✓ Ask for gaps, ambiguities and conflicts as questions to named people; Claude can lay out the options but does not settle a disagreement.
• ✓ Write requirements as user stories with acceptance criteria someone can test, with every number traced or marked for checking.
• ✓ Prioritise on value, effort and risk, label facts and assumptions, and validate the result with stakeholders before handing it over.
• ✓ Analyse a use case step by step: Claude for reading, sorting and drafting; people for judgment and approval; IT or Claude Architects and Developers for wiring Claude into the company's own systems.

Check your understanding

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

Sources

• Analyze patterns in user feedback (Claude use case)
• A closer look at Delegation (AI Fluency)
• Project planning and Delegation (AI Fluency)
• Capabilities and limitations (AI Fluency)
• Reduce hallucinations
• Prompting best practices
• The CCAO-F exam guide, summarised