What you will be able to do
- Break a use case into the separate tasks Claude must perform, and use Claude to interview you into a draft specification
- Write success criteria that are specific, measurable, achievable and relevant before delegating any work
- Test a use case on real sample data and verify Claude-drafted requirements before relying on them
1.Break the use case into tasks
A use case that sounds like one job is usually several. Anthropic's customer-support guide starts its analysis with a narrative: "Outline an ideal customer interaction to define how and when you expect the customer to interact with Claude." That outline is what tells you the technical requirements. In the guide's car-insurance example, one chat contains a greeting, product questions, steering off-topic requests back on track, and collecting details to generate a quote through a tool.
The guide then makes this a rule for the analysis: "Before you start building, break down your ideal customer interaction into every task you want Claude to be able to perform." The reason is practical. A list of separate tasks lets you write instructions and evaluations for each one, and it shows the full range of situations your test cases have to cover. The insurance example ends up with four task groups: greeting and general guidance, product information, conversation management, and quote generation. Each group has its own expected behaviours.
Claude can help with this breakdown. You don't have to write the specification alone. You can ask Claude to interview you about the idea, probing the parts that are easy to skip. Anthropic's Claude Code best practices give a prompt for this, asking Claude to "Keep interviewing until we've covered everything, then write a complete spec to SPEC.md." The prompt sets the interview's focus: "Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered." The same technique works for business requirements. Claude asks the questions, and the stakeholders supply the answers that only they know.
Checkpoint 1 of 5· Check yourself
A team has written a one-paragraph description of a customer-support chatbot. According to Anthropic's guidance, what should happen before anyone writes prompts or builds anything?
Breaking the interaction into tasks means every task can be prompted and evaluated. It also shows the range of interactions that test cases have to cover.
“Before you start building, break down your ideal customer interaction into every task you want Claude to be able to perform.”Source: platform.claude.com
2.Define what good looks like before delegating
Once the tasks are listed, each one needs a definition of success that is agreed before Claude does any of the work. Anthropic's evaluation guidance says good success criteria have four properties:
| Property | What it requires |
|---|---|
| Specific | Clearly define what you want to achieve: "accurate sentiment classification", not "good performance" |
| Measurable | Quantitative metrics or well-defined qualitative scales |
| Achievable | Targets based on industry benchmarks, prior experiments, AI research, or expert knowledge |
| Relevant | Aligned with the application's purpose and user needs |
The guide contrasts two versions. The bad one is "The model should classify sentiments well." The good one names an F1 score of at least 0.85 on a held-out test set of 10,000 diverse posts, which is a 5% improvement over the current baseline. The AI Fluency builders course sets a plain-language test for the same idea: each statement of "done" must be "concrete enough that a stranger could tell you whether the finished product passes or fails." Its example of a good statement is "A patient with a basic smartphone can find the current wait time in under 30 seconds without creating an account." Its example of a bad one is "The system is easy to use."
Two more points matter for analysing a use case. First, one number is rarely enough: "Most use cases need multidimensional evaluation along several success criteria." The guide's expanded example combines accuracy, toxicity, how severe the errors are, and response time. Second, the criteria belong to the business, not to whoever writes the prompts. The ticket-routing and support guides both tell you to work with the team that does the job today: "Work with your support team to define success criteria and write detailed evaluations with measurable benchmarks and goals." Those criteria can include business measures, such as how often queries are resolved without human intervention, alongside measures of task quality.
Checkpoint 2 of 5· Check yourself
Which requirement best meets the guidance on success criteria for a ticket-classification use case?
Only this option is specific and measurable, tied to the business, and agreed with the team before the work is delegated. The others are vague, not tied to the business, or put off until after launch.
“Work with your support team to define success criteria and write detailed evaluations with measurable benchmarks and goals.”Source: platform.claude.com
Checkpoint 3 of 5· Exam question
A product manager is using Claude to help define the minimum viable product (MVP) for a new feature. Which approach should they use?
Correct answer: B — Ask Claude to prioritize features considering business value, feasibility, and strategic alignment.
- A. Incorrect. Randomly picking features without criteria does not create a principled MVP and can lead to a misaligned product that fails to address core user needs or business goals. This approach lacks structure and strategic thinking.
- B. Correct. Prioritizing features based on business value, feasibility, and strategic alignment ensures the MVP delivers the most impact with the least risk. This structured approach helps define a lean, focused product that addresses key user needs while remaining realistic to build.
- C. Incorrect. Relying solely on the most senior stakeholder's endorsement can overlook critical user needs, technical constraints, and broader business objectives. It introduces bias and reduces objectivity. Good prioritization should be evidence-based and cross-functional.
- D. Incorrect. Expanding the feature list for the MVP goes against the principle of minimalism and focus. An MVP should be lean and targeted, not bloated with additional ideas. The key task is prioritization and selection, not ideation.
3.Test on real samples, then verify and own the output
Criteria only matter if you test against them before the full handover. The ticket-routing guide lists "A sample set of historical support tickets for testing" as a prerequisite. That is real, past work, not invented examples. The evaluation guide adds: "Design evals that mirror your real-world task distribution. Don't forget to factor in edge cases!" Its examples of edge cases include irrelevant input, overly long input, and "Ambiguous test cases where even humans would find it hard to reach an assessment consensus". These ambiguous cases tend to be the same ones your process mapping flagged as needing human judgment.
The same discipline applies to requirements that Claude itself drafts. Part of Platform Awareness is knowing the limits. The builders course lists them: "Current limits include knowledge cutoffs, hallucinations, and unreliable complex reasoning." The K-12 course explains why this is easy to miss: a model trained this way can discuss almost any topic but can also sound confident when it's wrong. A requirements list Claude writes without your internal documents may read well and still be generic, out of date or simply wrong for your organisation. Treat it as a draft to check against the process you mapped, not as content ready to paste into a brief.
This is where Diligence completes the outer loop. It includes "Transparency Diligence (being honest about AI's role)" and "Deployment Diligence (verifying and vouching for outputs)". When most of a requirements catalogue is drafted with Claude, a named person still checks it, vouches for it and is accountable for it. Being open that Claude helped is part of the same duty.
Checkpoint 4 of 5· Check yourself
A programme sponsor asks who is accountable for a requirements catalogue that was largely drafted with Claude. Which answer reflects the framework?
Under Diligence, people verify and vouch for AI outputs and are honest about the AI's role. Disclosure and AI review do not replace a human owner who has checked the work.
“Deployment Diligence (verifying and vouching for outputs)”Source: academy.claude.com
Checkpoint 5 of 5· Exam question
What is the most effective way to use Claude to analyze and categorize a list of requirements?
Correct answer: B — Ask Claude to classify each requirement as functional, non-functional, or constraint with explanations.
- A. Incorrect. Designing a spreadsheet layout focuses on formatting rather than analyzing or categorizing requirements. It does not leverage Claude's ability to classify requirements but instead adds a workflow artifact that doesn't directly address the need for analysis.
- B. Correct. This directly uses Claude's strength in analysis and classification by categorizing requirements into functional, non-functional, or constraint, along with explanations. It enhances clarity, traceability, and follows best practices for requirements analysis.
- C. Incorrect. Randomly removing requirements is not a valid analysis or categorization technique and risks losing essential information. It compromises the completeness of the requirements set and fails to achieve proper classification.
- D. Incorrect. This approach only evaluates quality attributes but does not categorize requirements, which is the primary goal of analysis. It fails to leverage Claude's classification capabilities, missing the chance to organize and understand requirements effectively.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A single headline metric, such as overall accuracy, is enough to define success for a use case.Why is that wrong?
Most use cases need several criteria evaluated together, for example accuracy, how severe the errors are, response time and correct escalation.
2.Requirements Claude produces from general knowledge are reliable enough to paste straight into a project brief.Why is that wrong?
Claude can hallucinate and sound confident when wrong, and without your internal context its output is generic. A person must check it and vouch for it before it is used.
Covered in Test on real samples, then verify and own the output
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Outline an ideal customer interaction to define how and when you expect the customer to interact with Claude.”
↩︎ Break the use case into tasks“Before you start building, break down your ideal customer interaction into every task you want Claude to be able to perform.”
↩︎ Break the use case into tasks“Work with your support team to define success criteria and write detailed evaluations with measurable benchmarks and goals.”
↩︎ Checkpoint - 2.https://code.claude.com/docs/en/best-practicesOfficial docs
“Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.”
↩︎ Break the use case into tasks“Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.”
↩︎ Break the use case into tasks - 3.
“Base your targets on industry benchmarks, prior experiments, AI research, or expert knowledge.”
↩︎ Define what good looks like before delegating“Align your criteria with your application's purpose and user needs.”
↩︎ Define what good looks like before delegating“Most use cases need multidimensional evaluation along several success criteria.”
↩︎ Define what good looks like before delegating“Design evals that mirror your real-world task distribution. Don't forget to factor in edge cases!”
↩︎ Test on real samples, then verify and own the output“Ambiguous test cases where even humans would find it hard to reach an assessment consensus”
↩︎ Test on real samples, then verify and own the output“Most use cases need multidimensional evaluation along several success criteria.”
↩︎ Exam trap 1 - 4.https://academy.claude.com/courses/ai-fluency-for-builders/delegation-the-builder-s-toolkitOfficial docs
“Each must be concrete enough that a stranger could tell you whether the finished product passes or fails.”
↩︎ Define what good looks like before delegating - 5.
“A sample set of historical support tickets for testing”
↩︎ Test on real samples, then verify and own the output“Before you automate, it's crucial to understand your existing ticketing system.”
↩︎ Test on real samples, then verify and own the output - 6.https://academy.claude.com/courses/ai-fluency-for-builders/ai-capabilities-and-limitationsOfficial docs
“Current limits include knowledge cutoffs, hallucinations, and unreliable complex reasoning.”
↩︎ Test on real samples, then verify and own the output“Current limits include knowledge cutoffs, hallucinations, and unreliable complex reasoning.”
↩︎ Exam trap 2 - 7.https://academy.claude.com/courses/ai-fluency-for-k-12-educators/ai-capabilities-and-limitationsOfficial docs
“can discuss almost any topic but can also sound confident when it's wrong.”
↩︎ Test on real samples, then verify and own the output - 8.
“Transparency Diligence (being honest about AI's role)”
↩︎ Test on real samples, then verify and own the output“Deployment Diligence (verifying and vouching for outputs)”
↩︎ Test on real samples, then verify and own the output