4.1 Analyzing Requirements and Use Cases
4.1.1 Understand the Problem Before You Prompt
Picture a colleague sliding into your chat with, "Can you get Claude to handle our weekly client update?" It's tempting to open a chat window and start drafting immediately. Resist that pull. "Use Claude" is not a requirement — it's a destination without a map. The actual ask is hiding behind it: maybe the real problem is that the update takes three hours every Friday, or that four people write it four different ways, or that it's fine as-is and just needs a faster first draft. Until you know which, jumping to a prompt is a guess dressed up as progress.
This is the discipline Domain 4 opens with: before applying Claude to anything, use Claude itself as a thinking partner to clarify what the task actually is. Concretely, that means asking Claude to restate a fuzzy request in clearer terms so you can check shared understanding, list the stakeholders and constraints that bear on the work, surface edge cases a first read might miss, and draft acceptance criteria so "done" is defined before anyone starts. This clarification step is distinct from — and comes before — asking Claude to produce the actual deliverable.
4.1.1 — Key Concept
Requirements clarification is its own step, separate from and prior to producing the deliverable: restate the ask, list stakeholders and constraints, surface edge cases, and draft acceptance criteria before you ever ask Claude to draft the real output.
4.1.2 The AI Fluency Lens: Delegation and Description
This clarification habit maps onto two ideas from AI Fluency. **Delegation** is the decision of what to hand to Claude at all, as opposed to handling it yourself or routing it to a colleague — not every piece of a task belongs with Claude, and deciding that deliberately is itself a skill. **Description** is framing the work clearly enough that Claude (or a person) can act on it without guessing — a vague ask produces a vague result, and the fix is upstream of the prompt, not downstream of it.
Put together, Delegation and Description are what separate deliberate use of Claude from reflexive use. Reflexive use looks like typing the first version of the request straight into the chat box. Deliberate use looks like pausing to decide whether this piece belongs with Claude at all, and if so, restating it precisely enough that the output can actually be judged against something. That pause costs a minute and saves several rounds of rework.
Where this shows up on the exam
Delegation asks "should this go to Claude at all?" Description asks "is this framed clearly enough to act on?" Both questions precede the actual prompt for the deliverable.
4.1.3 Good-Fit vs. Poor-Fit Use Cases
Once the ask is clarified, the next judgment call is whether it's actually a good fit for Claude. A good-fit task carries all three of these traits together — missing one changes the calculus.
| Trait | What it means |
|---|---|
| Language- or knowledge-heavy | Drafting, summarizing, analyzing, researching, brainstorming — work that's fundamentally about language and knowledge |
| Reviewable / verifiable output | A human can check the result before anyone relies on it |
| Value in speed, consistency, or first drafts | The win is a faster, more consistent reviewable draft — not a guaranteed-correct final answer |
All three traits together define a good-fit use case. "Language-heavy" alone is not sufficient.
Poor fits fall into two buckets: tasks that need guaranteed factual precision with no one checking the output, and tasks that require capabilities entirely outside Claude's scope. Neither is fixed by a bigger model or a cleverer prompt — the fix is a different approach altogether, whether that's a stricter verification process or a human doing the task directly.
4.1.3 — Exam Trap
Common exam trap: reaching for "the most powerful model" or "build a multi-agent system" as the first move on a task. The actual first move is analyzing fit and deciding how the output will be verified — model choice and system complexity come later, if at all.
4.1.4 Augment the Right Steps, Not Every Step
A fit assessment is not a one-time gate for an entire process — it applies step by step. A multi-step workflow rarely deserves a uniform answer of "automate all of it" or "automate none of it." Some steps are language-heavy and easily checked (a strong candidate for Claude); others need guaranteed precision or hinge on judgment a person has to own outright (a poor candidate, regardless of how well-phrased the prompt is).
- •Use the clarification step (4.1.1) to identify which specific steps of a process are worth handing to Claude, rather than defaulting to "automate everything."
- •A good-fit step still needs a human review point — good fit means reviewable, not unsupervised.
- •A poor-fit step needs a different remedy: stricter verification, a different tool, or a person doing it directly — not a bigger model.
The one idea to hold onto
The recurring trap across this task statement: assuming every step of a process should be automated. The actual goal is augmenting the steps where Claude adds the most value, identified through the clarification and fit-assessment work covered in this lesson.
Key Takeaways
- ✓Use Claude as a thinking partner to restate the ask, list stakeholders/constraints, surface edge cases, and draft acceptance criteria before doing the task itself.
- ✓This clarification step mirrors AI Fluency's Delegation (what to hand off) and Description (how to frame it clearly).
- ✓A good-fit use case is language/knowledge-heavy, produces reviewable/verifiable output, and derives its value from speed, consistency, or first drafts — not a guaranteed-correct final answer.
- ✓A poor fit needs guaranteed factual precision with no review, or requires capability outside Claude's scope entirely — neither is fixed by a bigger model.
- ✓Assess fit step by step within a process rather than as a single blanket decision; not every step of a workflow deserves the same answer.
- ✓The correct first move on any task is analyzing fit and a verification plan — not choosing a model or building a system.
Check Your Understanding
Test what you learned in this lesson.
Q1.A colleague says, "Get Claude to write our weekly client update." What should happen before any drafting begins?
Q2.Which pair of AI Fluency ideas frames the requirements-clarification step described in this lesson?
Q3.A task requires guaranteed-correct output with no one available to review it before it's used. What does this indicate?
Q4.A five-step process includes one step that's highly repetitive drafting and one step that requires a licensed professional's sign-off with no room for error. What is the best fit-assessment approach?
Practice This Lesson