What you’ll be able to do
- Turn interview notes, emails and meeting transcripts into a structured requirements draft with Claude
- Prompt Claude to stress-test requirements for gaps, contradictions and untested assumptions
- Rank candidate use cases by how well they suit Claude, and explain why
What you need to know
Requirements analysis is a thinking task, not a summarizing task
Most requirements arrive messy: a kickoff meeting transcript, three stakeholder emails, a slide from last quarter's strategy deck. Claude is very good at reading all of that at once and producing a clean, organized draft — who needs what, by when, and why. That alone saves hours.
But the real value comes from asking Claude to interrogate the material, not just tidy it. A summary repeats what people said. An analysis tells you what they didn't say, where two people said incompatible things, and which "requirements" are really unexamined assumptions. Ask for both, explicitly, and ask for them as separate sections so the tidy draft doesn't hide the open questions.
- Gaps: "What would a person building this need to know that isn't stated here?"
- Conflicts: "Where do the stakeholders' requests contradict each other?"
- Ambiguity: "Which requirements could be read two different ways?"
- Assumptions: "What is being taken for granted that should be confirmed?"
Ground the analysis in the actual source material
Claude can only analyze what you give it. If you describe the project in one sentence and ask "what are the requirements?", Claude will produce a plausible, generic list drawn from how similar projects usually look — which may have little to do with your organization. Upload or paste the real inputs (with sensitive details handled per policy) and ask Claude to tie each requirement back to where it came from. A requirement with no traceable source is a candidate for "Claude assumed this" and needs checking.
Claude surfaces conflicts; people resolve them
When two stakeholders want incompatible things — finance wants the report monthly, operations wants it daily — Claude can lay out the trade-off clearly, suggest options and list the questions that would settle it. It should not quietly pick one. The decision belongs to whoever owns the requirement, because they hold context and accountability Claude doesn't have. Your output should be a clearer conversation with stakeholders, not a replacement for it.
Make requirements specific enough to test
A requirement like "the report should be user-friendly" can't be checked. Claude is useful for rewriting vague statements into ones a person could verify: "a regional manager can find their region's figures within the first page" or "the form can be completed in under five minutes." Ask Claude to flag every requirement that uses words such as fast, simple, flexible or as needed, and to propose a measurable version of each. You can also ask it to draft a few acceptance checks — short "how we'll know this works" statements — for the most important items.
Treat Claude's rewrites as proposals. A measurable target is still a business decision: "under five minutes" may be right, or the stakeholder may have meant something quite different. Mark each rewritten requirement as "to confirm" until its owner agrees.
Choosing good use cases
Use-case analysis is the same skill pointed at your own work: which tasks in a process would benefit from Claude? Start from the business problem — what is slow, repetitive, error-prone or bottlenecked — rather than from "where could we put AI?". Good early candidates tend to be:
- Frequent and well-defined — weekly status summaries, first drafts of standard replies, meeting-note clean-up.
- Easy to check — a person can quickly verify the output is right.
- Low cost of a mistake — an error is caught in review before it reaches anyone it could harm.
- Text- and document-heavy — reading, drafting, comparing, organizing.
Weaker candidates are rare one-off tasks, outputs nobody can verify, and decisions where a mistake has serious consequences for a person. Those may still involve Claude as an assistant, but not as the decision-maker (see lesson 6.1). Some candidates are good ideas that need more than chat — connecting several systems or running unattended — which is a signal to involve a Claude Developer or Architect (lesson 4.3).
Key concept
Ask Claude to find what is missing, conflicting or assumed in the requirements — then take those findings back to the people who own the decisions.
Exam questions often offer a tempting option where Claude's polished requirements list is sent straight to the build team, or where Claude "resolves" a disagreement. The better answer uses Claude to expose the open questions and routes them to stakeholders for confirmation.
Practice scenario
Work it through, then open this
The list looks complete, but a summary prompt only reorganizes what was said — it didn’t look for tension. A second-review step for large contracts may make a two-day onboarding target impossible for those vendors. The better move is to ask Claude explicitly for conflicts, gaps and assumptions, with each tied to its source, then bring the conflict to legal and finance to decide (for example, a longer target for high-value contracts). Claude should not pick the answer, and the 18-item list should not go to the process designers until the open questions are settled.
Hands-on exercise — Stress-test a set of requirements
Beginner · 15 min
What you’ll learn
- Separating a clean requirements draft from an analysis of its weak spots
- Tracing each requirement to its source
- Turning Claude’s findings into questions for stakeholders
-
Paste or upload notes from a real or invented project kickoff (remove anything sensitive first) and ask Claude to draft a requirements list grouped by stakeholder, quoting the source line for each item.
- Why: Traceability shows you which requirements came from people and which Claude filled in on its own.
- You should see: A structured list where each item points back to a line in your notes; anything without a source deserves a second look.
-
In the same chat, ask Claude to list gaps, conflicts between stakeholders, ambiguous items and assumptions — as four separate sections.
- Why: Asking for each category explicitly gets you analysis rather than a restated summary.
- You should see: At least one conflict or ambiguity you hadn’t noticed, plus some items you judge to be non-issues — that judgment is your job.
-
Ask Claude to turn the confirmed issues into a short list of questions, each addressed to the stakeholder who can answer it.
- Why: The output of requirements analysis is a better conversation with the decision-owners.
- You should see: A send-ready question list that you edit before sharing, not a set of decisions made on anyone’s behalf.
Exam traps
Treating Claude’s list of requirements as complete because it looks thorough
A well-formatted list can still miss things nobody wrote down. Completeness has to be checked against stakeholders, not inferred from polish.
Asking Claude to summarize requirements when the job is to find gaps and conflicts
A summary restates; it rarely flags contradictions. Ask for gaps, conflicts, ambiguities and assumptions explicitly.
Letting Claude resolve a stakeholder conflict by picking a side
Claude can frame the trade-off and options, but the requirement’s owner holds the context and the accountability to decide.
Starting with ‘where can we use AI?’ instead of the business problem
Use-case analysis begins with what is slow, repetitive or error-prone, then asks whether Claude helps — not the other way round.
Choosing a use case because it is impressive rather than frequent and well-defined
Frequent, checkable, low-risk tasks deliver reliable value; flashy one-offs are hard to verify and rarely pay back.
Leaving out the source material and asking Claude to infer the requirements
Without the real inputs, Claude produces a plausible generic list. Give it the actual notes and ask it to cite them.
Sources
- Claude Help Center
- Claude Docs
- Anthropic, Claude Certified Associate – Foundations Exam Guide v1.0 (July 2026)