Skip to content
Domain 4Task 4.1

Analysing Requirements and Use Cases

Learn this interactively

What You Need to Know

A requirement is a statement of what a piece of work must achieve. Use-case analysis is judging whether a task is a good candidate for Claude before any effort goes into it. A theme is a named group of related comments. The objective tests two related skills: using Claude to turn messy input into structured requirements, and use-case analysis. Every workflow decision in this domain starts there: what does this work require, and does Claude belong anywhere near it? One discipline joins them: Claude structures, the human validates and owns the result.

Take a newsagent that runs home deliveries. The owner wants to rework her paper rounds. Her material is customer emails, staff meeting notes, order-book comments and remarks from the counter.

Structure from Mess

Real requirements arrive as complaint threads, meeting notes, survey comments and half-remembered conversations, never as a tidy list. The Help Center lists summarising long documents and conversations among Claude's core uses, alongside generating viewpoints and providing recommendations. Given the raw material, Claude clusters it into themes and separates what people asked for from what they appear to need. It also surfaces where two groups want incompatible things, and names what nobody mentioned.

For the newsagent, Claude might return themes like late papers and wrong magazines. It might flag that one estate wants papers before seven, while staff want later starts. An afternoon of reading becomes minutes, and the people involved get a shape of the problem they can question.

A Theme Is a Hypothesis

Claude organises what it was given. It has no way of knowing what your organisation needs. A theme it names is a hypothesis about your input, not a finding about your business. The people whose requirements it describes must confirm it before anything gets designed on top. Anthropic's AI Fluency framework draws the same division of labour. Discernment, evaluating what the AI produced, and Diligence, staying accountable for the result, sit with the human.

So the owner checks the early-papers conflict with the estate's customers and her staff before redrawing any round. Designing straight from Claude's clusters would mistake tidy output for validated requirements. The confirmation is the cheap part.

The Shape of a Strong Candidate

Good Claude use cases share a recognisable shape:

  • The work is language-shaped: drafting, summarising, reformatting, explaining, comparing. This is the territory the Help Center's use-case article documents.
  • The material needed is material you can provide.
  • The output can be checked by someone competent to check it.
  • Either the volume is high or the blank page is the expensive part.

AI Fluency names this judgement Delegation, deciding what work to hand to the AI. It treats Delegation as a skill in its own right that comes before any prompt is written. Weak candidates have the opposite shape. The work needs the authority to decide rather than the ability to draft. Or it depends on information Claude has no access to. Or it is relationship work rather than document work.

At the newsagent, a letter announcing new delivery times is a strong candidate: the owner can check it. Choosing who takes which round needs authority. Knowing whether a paper reached a doorstep needs information Claude lacks. Calling the regular who cancelled is relationship work.

The Checker Test

The checker test is the one people skip: if you couldn't tell whether the answer was wrong, you're not ready to use Claude on that task. Without a checker, a wrong output passes as easily as a right one. High stakes are not a reason to abandon the work, and neither is a missing checker. Both mean finding the person who can tell good output from bad and putting them in the process.

The test also breaks up the blank-cheque use case: the announcement that Claude will handle a whole category of work. A category mixes strong and weak candidates. The blanket commitment comes before the analysis that should have shaped it. Handing Claude all the delivery admin would bundle the letter with the round allocation.

In the exam

The exam's favourite failure here is the skipped confirmation step. Whether and where the work suits Claude is this objective's question. How the request is then phrased is Domain 1's skill, and which product feature carries it is Domain 3's.

Key Concept

When a 4.1 stem ends with Claude's freshly clustered themes on the table, the keyed answer takes them back to the people who own the requirements before design begins. The distractors adopt the themes as findings, hand Claude the decision itself, or abandon the work because the stakes feel high.

Exam Traps

Exam Trap

Adopting Claude's themes as validated findings because they arrived quickly and read plausibly

A theme is a hypothesis about the input, not a finding about the business. Designing on an unconfirmed contradiction builds the wrong thing confidently, so the keyed answer takes the structure back to the stakeholders first; confirmation is the cheap step, and skipping it is the expensive one.

Exam Trap

Handing Claude the decision along with the analysis

The authority to decide never delegates. Claude structures the material and drafts around the decision, but choosing the policy, picking the winner or resolving the dispute stays with the people accountable for it. Options that outsource the judgement are wrong however efficient they sound.

Exam Trap

Ruling work out as too important for Claude to touch

Abstinence mistakes the stakes for the risk. High stakes argue for a named, competent checker in the process, not for abandoning the drafting help. The checker test is the fix, and the exam treats blanket refusal as a wrong answer just as it treats blanket adoption.

Practice Scenario

The manager of a Saturday street market has a folder of complaint emails and comments from traders about how pitches are allocated. She wants to establish what a fairer allocation approach must do before anyone designs one. Claude clusters the material into six themes, including a contradiction: regular traders believe casual traders get the best corner pitches, while casual traders describe those same corners as reserved for regulars. She has no time to work through the folder again herself. What should she do next?

Build Exercise

Build Exercise

Cluster, Confirm, Then Classify

Difficulty
30 minutes

What you'll learn

  • How to get Claude to structure genuinely messy input
  • How to treat themes as hypotheses and confirm them with their owners
  • How to sort candidate work into Claude-shaped and not
  • How to apply the checker test before committing to a use case
  1. Collect a genuinely messy input you own: a feedback thread, the notes from your last three team meetings, or the complaints folder for one process

    Why: The skill only shows against real mess; a tidy input hides exactly the structuring work this objective tests.

    You should see: A single pile of raw material, unedited, in one document or conversation.

  2. Ask Claude to cluster the material into themes, flag where two people want incompatible things, and name what nobody mentioned

    Why: These three asks cover what the material resists most: patterns, contradictions and absences.

    You should see: A set of named themes, at least one flagged tension, and one or two gaps.

  3. Mark each theme confirmed or hypothesis, then take the two most load-bearing hypotheses back to the people who own them and record what changes

    Why: This is the discipline the exam tests: a theme is a hypothesis about your input until its owners confirm it.

    You should see: At least one theme revised or reframed after a real conversation.

  4. List the pieces of work the confirmed requirements imply, and sort them: language-shaped with providable material, or dependent on authority, access or relationships

    Why: Use-case analysis happens per piece of work, never per category; sorting makes the strong and weak candidates visible.

    You should see: Two lists, with each piece of work in exactly one of them.

  5. For every piece you would hand to Claude, name the person who could tell a wrong output from a right one; if there is no name, the use case is not ready

    Why: The checker test is the sharpest filter in the objective, and naming a real person is what makes it honest.

    You should see: A named checker beside every Claude-bound piece of work, or a note on who to recruit.

Sources