Structured discovery and requirements

What you’ll be able to do

• Run discovery that covers the business outcome, users and workflow, data, constraints and risk tolerance
• Translate vague asks into measurable functional and non-functional requirements with a baseline
• Identify every stakeholder with a veto or a dependency, including security, legal and data owners, early
• Use real sample data and a feasibility probe to test assumptions before committing to a design

What you need to know

Why discovery has to be structured

Most failed Claude projects didn't fail on prompts or models. They failed because nobody agreed what "good" meant, the data turned out to be inaccessible, or a reviewer with veto power appeared after the build. Unstructured discovery ("let's chat about what you want") reliably captures the sponsor's enthusiasm and misses the constraints. Structured discovery works through a fixed set of questions so the gaps are visible, and ends with written requirements that the stakeholders have signed off on.

The areas discovery must cover

• Outcome and baseline. What business result changes, and how is it measured today? "Reduce average handling time for billing tickets" is a start; "from the current measured average, with first-contact resolution not falling" is a requirement. Without a baseline, no one can say later whether the system worked.
• Users and workflow. Who uses the output, at what point in their work, and what do they do with it? A draft an agent edits has very different error tolerance from an answer a customer reads unaided. Shadowing the actual workflow often reveals that the real bottleneck is somewhere else.
• Data. Which sources hold the needed knowledge, who owns them, how current and clean they are, how sensitive (personal data, health records, privileged legal material), where they must stay, and whether access can actually be granted. Data questions are the most common source of late surprises.
• Constraints. Regulatory scope, data residency, latency expectations, volume and peaks, budget, existing systems to integrate with, and deployment environment requirements.
• Risk tolerance. What does a wrong output cost? Which decisions need a human? Is there an existing review process the system has to fit into?
• Acceptance criteria. The test, agreed in advance, that decides go-live: measured on which data, at what threshold, signed off by whom.

The stakeholder map

List everyone who can block, fund, use, or be harmed by the system, and talk to each group directly. The sponsor knows the goal. Front-line users know the workflow and the edge cases. Security and privacy own data-handling requirements. Legal and compliance own regulatory interpretation and retention rules. Data owners control access. Operations will run it. Finance cares about the cost model. Each has requirements the others don't know about, and the ones discovered late are the expensive ones. Record who owns each requirement and who decides when two conflict.

From vague asks to testable requirements

Requests arrive as solutions ("we need a chatbot") or adjectives ("accurate", "fast", "secure"). Convert each into something you can test:

• "Accurate" becomes "on a labeled set of real past tickets, correct category on at least the agreed share, and no answer that contradicts current policy".
• "Fast" becomes a latency target at a percentile, for a named interaction, under stated load.
• "Secure" becomes specific controls: which data may be sent, who can see outputs, what's logged and for how long.

Separate what the system must do from how well it must do it (functional and non-functional), and mark which requirements are fixed (regulatory) and which are negotiable trade-offs (latency against cost). Ask also which parts of the problem don't need a model at all: deterministic routing rules, lookups and calculations are often better done in code, with Claude handling the parts that need language understanding or judgment.

Test assumptions with real data early

Ask for a representative sample of real inputs during discovery, with the hard and messy cases included and sensitive data handled under the agreed controls. That sample does three jobs: it exposes data problems (scanned PDFs, missing fields, five languages nobody mentioned), it becomes the seed of the evaluation set, and it powers a short feasibility probe. A probe is a time-boxed test of the riskiest assumption ("can Claude extract these fields from these forms well enough?"), not a prototype to show executives. Its result can change the design, the scope, or whether the project should proceed. Hand-picked or synthetic examples make every probe look good.

Key concept

Discovery is complete when the outcome has a measured baseline and target, every requirement is testable and owned, every stakeholder with a veto has been consulted, and the riskiest assumption has been tested on real data.

Questions often describe a team eager to build. The best first step is usually a discovery action (establish a baseline, get real sample data, bring in security or legal, define acceptance criteria) rather than a technical choice.

Practice scenario

Build exercise — Run a discovery canvas on a real request

Advanced · 50 min

What you’ll learn

• Covering every discovery area systematically
• Converting adjectives into testable requirements with owners
• Designing a feasibility probe around the riskiest assumption

1. Take a real or realistic AI request and fill in a canvas with one section each for outcome and baseline, users and workflow, data, constraints, risk tolerance and acceptance criteria. Mark every cell you can’t fill.

   • Why: The empty cells are your discovery agenda; filling them from assumption is how projects fail late.
   • You should see: Several empty cells, most likely in data access, baseline and risk tolerance.

2. Build the stakeholder map, and for each stakeholder write two requirements they would raise. Rewrite every adjective requirement as a measurable one with an owner.

   • Why: Requirements surface from the people who hold them, and only testable requirements can be accepted or rejected.
   • You should see: At least one requirement from security, legal or operations that the sponsor’s brief didn’t mention.

3. Identify the single riskiest assumption and design a probe on real sample data: the question, the data, the pass mark and the decision each result would trigger.

   • Why: A probe exists to change decisions; if no result would change anything, it isn’t testing the right assumption.
   • You should see: A one-page plan where a failing result would alter scope or design.

Exam traps

Starting discovery by choosing a model, framework or architecture pattern

Technical choices follow from requirements and constraints. Picking them first anchors the whole project on an assumption.

Accepting “as accurate as possible” as a requirement

It can’t be tested or traded off. Define accuracy on named data with a threshold and an owner.

Gathering requirements only from the executive sponsor

The sponsor knows the goal, not the workflow, the data or the controls. Users, security, legal, data owners and operations hold requirements too.

Leaving data access, residency and legal review until after the design is approved

These are the most common late blockers. Bring them in during discovery.

Validating feasibility on synthetic or hand-picked examples instead of real data

Clean examples hide the messy cases production will see. Use a representative real sample under agreed controls.

Setting a success target without measuring today’s baseline

Without a baseline you can’t show improvement or notice regression. Measure the current process first.

Assuming every part of the problem needs an LLM

Deterministic rules, lookups and calculations are often cheaper and more reliable in code. Use Claude where language or judgment is required.

Sources

• Anthropic
• Claude Developer Platform Docs
• Anthropic, Claude Certified Architect – Professional Exam Guide v1.0 (July 2026)