4.1 — Analyzing Requirements Before Reaching for Claude

Before you design any solution involving Claude, the first real decision isn't "how do I prompt this well" — it's "should Claude be doing this part at all." A surprising amount of failed AI rollouts trace back to skipping this step: someone sees Claude write a strong first draft in a demo and assumes it can own an entire process end to end, including pieces that were never a good match for what a language model actually does well.

Requirements analysis for a Claude-based solution means looking at a candidate task and asking a specific, answerable question: does this task have a well-defined input, a well-defined output, and does turning one into the other mostly require language understanding and judgment? If yes, it's a strong candidate. If the task instead depends on something outside those boundaries, Claude may still have a role, but not as the sole owner of that step.

What Makes a Task a Good Fit

Good-fit tasks share a recognizable shape: the input is something you can hand over in text (a document, a transcript, a spreadsheet export, a policy, a set of emails), the output is something Claude can produce in language or structured text (a summary, a draft, a classification, a recommendation with reasoning), and the hard part of the task is genuinely about understanding, synthesizing, or judging — not about looking something up live or performing an exact calculation. Drafting a stakeholder update from a project's status notes, triaging incoming support tickets by category and urgency, turning a rough meeting transcript into structured action items, or comparing three vendor proposals against a stated set of criteria are all this shape: bounded input, bounded output, judgment-plus-language in between.

What Makes a Task a Poor Fit

Three failure shapes come up repeatedly. First, tasks that need live, real-time data Claude has no access to on its own — "what's our current inventory level" or "has this invoice been paid yet" depend on a system of record changing in real time, and Claude answering from memory or from a stale paste risks a confidently wrong answer. (A Claude with connectors to those live systems can close part of this gap — see lesson 4.5 — but that's a different, more deliberately integrated solution than just asking Claude the question in isolation.) Second, tasks that need deterministic, fully auditable calculation — payroll totals, tax withholding, financial reconciliation — are a poor fit for having Claude be the calculation engine, because language models can make arithmetic slips at exactly the volume and stakes where a wrong answer is expensive and hard to catch. Third, tasks that need specialized, regulated professional judgment — a licensed clinician's diagnosis, a licensed attorney's binding legal opinion, a compliance sign-off with legal liability attached — require a credentialed human to hold accountability that Claude cannot hold, regardless of how good its draft reasoning is.

None of this means Claude has zero role in these cases. Claude can draft the reconciliation summary a human then checks against the ledger; it can summarize case law for an attorney who still forms the opinion; it can flag which invoices look overdue based on data you paste in, as a first pass a human verifies against the live system. The distinction that matters is between Claude owning a step outright and Claude assisting a step that still needs a human or a system of record as the actual source of truth.