CCAO-F 4.1 — Analysing requirements and use cases

From a vague ask to a reviewable requirement

Collect inputsnotes, tickets, emails, current process
Draft structureClaude groups and phrases requirements
Probe the gapsask Claude what is missing or ambiguous
Confirm with ownersstakeholders correct and approve
Record the agreed setkeep it where the work happens

New input — a ticket, an objection, a constraint — sends you round again

Claude does the middle three steps quickly. The first and last steps are yours — and the exam’s correct answers almost always include the last one.

What “analysing requirements” actually means here

A requirement is a statement of what something must do, specific enough that two people would agree whether it has been met. Most real requests do not arrive that way. They arrive as “we need something better for supplier onboarding”, or as a forty-message email thread, or as a sentence in a board deck. The analysis work is separating the problem from the proposed solution, finding the constraints nobody wrote down, sorting what is essential from what is merely wanted, and surfacing the questions that still need answers.

Claude is genuinely strong at the parts of that work which are reading and writing: absorbing long, unstructured input, grouping it, phrasing it consistently, spotting contradictions between two documents, and generating the list of questions a careful analyst would ask. It is not able to decide what your organisation actually wants. That difference — good at structuring, not authorised to decide — is the line the exam keeps drawing.

Claude does this well	You still own this
Turning notes, tickets and transcripts into grouped, consistently worded requirements	Deciding which requirements are in scope and who signs them off
Listing ambiguities, contradictions and missing information	Getting answers from the people who know
Drafting acceptance criteria and edge cases you had not considered	Judging which edge cases matter enough to build for
Rewriting a requirement for a different audience — finance, legal, IT	Confirming that the rewrite still means the same thing
Proposing a priority order and explaining the trade-offs	Setting the actual priority, with budget and politics in view

Briefing Claude so the draft is worth reviewing

The quality of a requirements draft is set almost entirely by the brief. Anthropic’s prompting guidance is direct about this: explain why the work matters rather than only what to produce, because Claude generalises from the explanation; state the output format you want; and ask explicitly for anything extra, because current models tend to do what was asked rather than volunteer more. The practical version for requirements work is a brief that names the audience, the inputs, the format, and the two instructions that make the draft checkable — mark assumptions, and list open questions.

The same request, briefed two ways

Produces a plausible listtext

Read these notes and write the
requirements for the new supplier
onboarding process.

Produces a reviewable drafttext

Turn the attached interview notes into
supplier onboarding requirements, for
procurement, finance and legal to review.

1. Group by theme; one testable line
   each; mark Must / Should / Could.
2. Name the interview each came from.
3. "Assumptions": anything you inferred
   rather than read in the notes.
4. "Open questions": what the notes do
   not answer, and who could answer it.
5. "Conflicts": where two interviews
   disagree, quoting both.

Use only the notes. Do not invent
requirements no interview supports.

The right-hand brief fixes the format, forbids invention, and forces the unknowns into the open where a stakeholder can answer them.

Four of those five instructions exist to make review fast. Traceability to a named interview means a reviewer can check a requirement in seconds. The assumptions section separates what Claude read from what it inferred. Open questions turn silence into a task. And the conflicts section is often the highest-value part of the output, because contradictions between stakeholders are exactly what a busy analyst skims past.

Worked example · Supplier onboarding, from nine interviews

Dana is a procurement lead at a mid-sized manufacturer. She has nine interview write-ups — buyers, finance, legal, two plant managers — and a fortnight to produce requirements for a new supplier onboarding process.

She sets up the inputs. All nine write-ups go into a Project so every chat about this work starts from the same material, and she names each file after the person and role so it is obvious where a requirement came from.
She asks for structure, not answers. Using the brief above, she gets 34 requirements grouped into six themes, each traced to an interview, each marked Must, Should or Could.
She reads the conflicts section first. Legal wants sanctions screening before any purchase order; one plant manager wants emergency suppliers usable the same day. Nobody had put those two sentences next to each other before.
She works the open questions. Eleven questions, of which four she can answer herself. The remaining seven go out in one email rather than seven separate conversations.
She checks the assumptions. Two are wrong: Claude inferred a single approval threshold, where the company has three by spend band. She corrects them in the draft rather than re-prompting.
She circulates the draft for sign-off — clearly labelled as a draft — and asks each interviewee to confirm only the requirements traced to them.

Takeaway: Claude compressed a week of reading and reorganising into an afternoon. What made the output usable was not its polish but its traceability: every line could be checked against a named source, and everything unsupported was confined to a section labelled as such.

Analysing the use case: is this a job for Claude?

The second half of this objective is narrower and easier to score on. Given a business request, is Claude the right tool, the wrong tool, or the right tool for part of it? The reliable test has three parts. Is the work mostly language and judgement, rather than arithmetic on a system of record? Is there source material Claude can actually read, or would it be working from general knowledge? And can somebody check the output before it has consequences?

Sorting a request

What kind of work is being asked for?

Reading, drafting, comparing
Strong fitgive it the sources and a format
Decisions about people or money
Fit with reviewa qualified person signs off
Exact, repeatable calculation
Use the systemthe ledger or tool is the source of truth
No source material exists
Gather firstgeneral knowledge is not your data

Most real requests land on the middle two branches — a genuine fit, but scoped down, and with a named reviewer.

The third branch is worth dwelling on, because it is where enthusiastic teams lose credibility. If the question is “what did we invoice this customer last quarter”, the answer lives in the finance system, and the right design is to take the figure from the system and ask Claude to explain, summarise or draft around it. Anthropic’s own help centre warns against treating Claude as a singular source of truth and notes that it may be confused about recent events, because its training has a cutoff. A use case built on Claude recalling your numbers is built on sand; a use case built on Claude interpreting numbers you supplied is on solid ground.

Worked example · “Can Claude answer our refund emails?”

A customer service manager at an online retailer asks whether Claude can handle the refund queue, which runs to roughly 400 emails a week.

Restating the ask. The request bundles four different jobs: reading the email, checking the order and the refund policy, deciding the outcome, and writing the reply.
Testing each against the three questions. Reading and writing are language work — a strong fit. Checking the order is a lookup in the order system, not something Claude should recall. Deciding a refund affects money and a customer relationship.
Scoping it down. Claude summarises each email into a structured triage note, retrieves the relevant policy clause from the policy document, and drafts a reply. An agent confirms the order details, makes the decision and sends.
Naming the measure. Handling time per email today is the baseline; the pilot measures the same thing over four weeks, plus how often the drafted reply is sent with no edit.
Writing down what it will not do. No automatic sending, no refund decisions, no cases flagged as complaints or legal threats.

Takeaway: “Can Claude do X?” is rarely a yes-or-no question. Splitting the request into its underlying jobs turns an unusable ask into a scoped pilot with a baseline, a boundary and a named human decision point.

Finding use cases instead of waiting for them

Organisations that get value from Claude tend to run this analysis deliberately rather than case by case. Anthropic’s published customer story for Advantage Solutions, a retail services company, describes exactly that shape: an AI office reporting to an executive steering committee, training that started with the leadership team and cascaded down, a pilot of around 150 people that grew to thousands, and more than fifty business-unit champions building solutions. The story reports that the number of use cases surfaced across the business roughly doubled, from around fifty at the initial diagnostic to over a hundred. Use cases were collected, assessed and prioritised, not discovered by accident.

You can borrow the mechanics at any scale. Ask the team to list the tasks that eat time and produce text. Score each one on the three questions above, plus two practical ones: how often does it happen, and what does an error cost? The tasks that are frequent, language-heavy, source-backed and cheap to get wrong are where you start. The rare, high-stakes, judgement-only tasks are where you stop — or where you use Claude only to prepare material for a human decision.

Scoring a candidate use case

Passes: The work is mostly reading, writing or comparingdrafting a reply from a policy clause
Passes: The source material can be given to Claudepolicy document and a triage note
Check: Facts come from a system, not from recallorder details must be looked up, not remembered
Passes: A person reviews before it has consequencesthe agent sends
Passes: It happens often enough to be worth the setupabout 400 emails a week
Missing: A baseline measure existshandling time was never recorded

A use case that fails one of these is not dead — it is a use case that needs scoping down, as in the refund example.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Treating Claude’s requirements draft as agreed requirements	Circulate it as a draft and have the process owners confirm each item.
Jumping from a one-line ask straight to a solution	Separate the problem from the proposed solution, then scope the jobs inside it.
Asking Claude for facts that live in a system of record	Pull the figures from the system and ask Claude to interpret or draft around them.
Accepting a requirements list with no traceability	Require each requirement to name its source, and confine inferences to an assumptions section.
Piloting a use case with no baseline measure	Record today’s handling time, volume or error rate before you change anything.

You should now be able to

Brief Claude so a requirements draft is traceable, with assumptions, open questions and conflicts separated out.
Separate what Claude structures well from what only a stakeholder can decide.
Judge whether a business request is a good fit for Claude, and split a mixed request into the parts that are.
Identify when a task needs a system of record rather than a language model.
Score and prioritise candidate use cases by frequency, source availability, review cost and error cost.

Analysing requirements and use cases