Structured Discovery and Requirement Gathering

What You Need to Know

Discovery is the opening work of an engagement: finding the problem behind a request. The request is what a stakeholder asks for; the requirement is the problem underneath. A baseline is that problem's measured cost. The consequence of error is what a wrong output costs.

The Request Is Not the Requirement

A chiropody clinic's owner asks for an assistant that drafts insurance claims, "like the one across town". Stakeholders often arrive carrying a solution: a named artefact, a named tool, sometimes a named competitor. That solution is evidence about the problem, never a substitute for it.

The architect's first act is to establish what is broken, for whom, at what measured cost, and what would count as fixed. At the clinic, that might be rejected claims and the receptionist's hours redoing them.

Two early moves fail. Building produces a demo on cooperative sample data, and every later conversation negotiates against a shape nobody justified. Pricing quotes work nobody has scoped, converting the architect's uncertainty into somebody else's contract.

What Discovery Has to Produce

Judge discovery by its six outputs, not by how many people were consulted.

• The business problem with a measured baseline: hours, error rates, backlog, revenue at risk. Every later benefit claim is a delta against it, and it cannot be reconstructed once the system has changed the process. At the clinic, that means the receptionist's hours on claims, measured before anything changes.
• The real workflow, workarounds included, not the process diagram somebody drew years ago.
• The output the system must produce, which fixes the task shape and rules out half the candidate architectures.
• The consequence when that output is wrong, and success criteria that are thresholded and owned.
• The data: what exists, its quality, who owns it, and whether it may lawfully be used here. Domain 5 owns those obligations. Surfacing them now makes them cheap. The clinic's data is patient notes, so the lawful-basis question comes first.
• The constraints and the accountable decision-maker: budget, latency, integration surface, regulatory exposure, and the ones nobody volunteers, such as the two people who will operate this. At the clinic, they are the receptionist and the chiropodist. A requirement with no named owner cannot be traded off later, because nobody can accept the consequence.

Consequence of Error Sets the Bar

The answer to what happens when the output is wrong prices the rest of the engagement. A wrong suggestion a human reviews before acting sets one bar. A wrong figure flowing unchecked into a payment or a regulatory filing sets another. At the clinic, that is a draft claim the chiropodist checks versus a wrong fee sent straight to an insurer.

That answer sets the accuracy threshold worth committing to and decides whether a human checkpoint is structural. It also fixes how much verification the pipeline carries, which prices the latency and cost envelope. Discovery that captured a feature list and never asked it produced only a scope.

Success Criteria You Can Pass or Fail

Anthropic's success-criteria guidance is the discovery standard here, and the interlock with Domain 4. Criteria should be specific, measurable, achievable and relevant. Targets come from benchmarks, prior experiments or expert knowledge rather than optimism. Most use cases need several at once, not one headline number.

Its worked contrast is the shape a discovery record must reach. "The model should classify sentiments well" fails. The passing version names a held-out set of stated size, a quality floor and a safety rate. It splits inconvenient errors from serious ones and bounds response time. Criteria phrased as a direction cannot end a project: nobody can show they are met. The clinic's "claims should go more smoothly" fails the same way.

Feasibility Triage and the Honest No

Three questions decide whether the engagement proceeds in this shape.

1. Is there a decidable task with a verifiable output, or an aesthetic judgement with no ground truth?
2. Does the data exist, is it good enough, and may it be used here?
3. Is the cost of being wrong tolerable at an achievable accuracy?

A no to any of them is a finding, not a failure. Patient notes the clinic may not lawfully use would be one. Anthropic's agent guidance points the same way: find the simplest solution possible, and add complexity only when it demonstrably improves outcomes.

In the exam

This domain looks soft, so strong engineers skip it and lose nine items any experienced practitioner could answer. Every keyed answer is a professional behaviour under pressure, and the exam does key the honest no. The distractors come from four failure postures that recur across all five objectives.

• Capitulation agrees to the impossible.
• Evasion complies silently, or builds it your own way without saying so.
• Obstruction escalates over the accountable owner.
• Theatre offers more meetings, more metrics, more documents.

At the clinic, an early price is capitulation and a staff survey is theatre.

The postures are this site's framing, not Anthropic's, and they make the domain predictable.

Exam Traps

Practice Scenario

Build Exercise

Sources

• Define success criteria and build evaluations — Anthropic
• Building Effective AI Agents — Anthropic
• Claude Certified Architect Professional Exam Guide (v1.0) — Domain 6 — Anthropic