6.1 · Lesson 1 of 5
Conduct structured discovery and requirement gathering
What You Need to Know
Structured discovery is how architects turn vague “AI on X” asks into goals, constraints, data realities, owners, and measurable success metrics. Interview business owners and operators — often separately — so incentives and operational constraints surface before anyone buys a vector database. Non-functional requirements (latency, cost, risk, compliance) belong in discovery alongside functional goals, not in postmortems.
Findings must become testable requirements with owners and acceptance measures. Document non-goals that bound the design. Stack selection — models, RAG, tools — is gated on discovery exit criteria. Skipping interviews and picking infrastructure on day one is the exam’s favorite trap.
Discovery outputs
- Outcomes and success metrics with named owners
- Constraints: data, latency, cost, risk, compliance
- Non-goals and out-of-scope asks
- Operator realities: tools, escalations, known failure modes
- Testable requirements that can feed evals and SLAs
Decision rules
- Discovery before stack — no day-one vector DB without problem framing.
- Interview owners and operators when their knowledge differs.
- Capture NFRs early alongside functional goals.
- Turn findings into testable requirements with owners and metrics.
- Use discovery exit criteria before design and procurement.
Why stack-first fails
A vector DB or model tier is a solution shape, not a business outcome. Without discovery, teams optimize the wrong problem, miss NFRs, and inherit operator pain they never heard. Professional architects delay procurement until the problem is written down and owned.
Review checklist
- Were owners and operators interviewed (separately if needed)?
- Are NFRs written, not implied?
- Are success metrics measurable and owned?
- Are non-goals explicit?
- Is stack selection blocked until discovery exit criteria pass?
Exam stems that show an architect buying infrastructure on day one reward calling out missing structured discovery — not praising decisiveness.
Exam application
Prefer answers that reopen discovery for goals, constraints, and metrics. Distractors: stack-first moves, skipping interviews, postponing NFRs, or claiming discovery needs no artifacts.
Exam traps
Stack-first discovery
Buying RAG, models, or tools before goals and metrics is the classic fail. Exam stems reward problem framing first.
Interviewing only executives
Owners and operators often disagree on constraints and failure modes. Separate interviews surface NFRs and operational reality.
Functional goals without NFRs
Latency, cost, risk, and compliance belong early — not only in postmortems.
Vague wishes instead of testable requirements
“Make it smart” is not a requirement. Turn findings into measurable outcomes with owners.
Practice scenario
An architect skips stakeholder interviews and buys a vector database on day one for “AI on our CRM.” What is the primary failure?
Build exercise
Run structured discovery for a CRM support-copilot ask
35 minutes
What you'll learn
- Interview owners and operators separately
- Capture functional goals and NFRs together
- Write testable requirements with owners
- Gate stack selection on discovery exit criteria
Step 1
Plan discovery interviews by role
Schedule separate sessions with business owners and operators/support. Capture goals, pain points, constraints, and what “done” means for each.
Why: Role-separated discovery reveals conflicting incentives before design locks them in.
You should see: Interview plan with roles, questions, and success-metric prompts.
Step 2
Capture functional and non-functional requirements together
Write functional outcomes alongside latency, cost, accuracy floors, compliance, and audit needs. Mark unknowns explicitly.
Why: NFRs late become expensive redesigns. Exam items put NFRs in discovery.
You should see: Requirements table: requirement, type (F/NFR), owner, measure, unknown?
Step 3
Turn findings into testable requirements
Rewrite vague asks into measurable statements with owners and acceptance checks. Document non-goals that bound scope.
Why: Testable requirements feed evals and SLAs. Vague wishes do not.
You should see: A short PRD slice: outcome, metric, owner, non-goals.
Step 4
Gate stack selection on discovery exit criteria
Refuse model/RAG/tool purchases until goals, constraints, owners, and metrics clear a written discovery exit checklist.
Why: Exit criteria prevent day-one vector DB theater.
You should see: Discovery exit checklist signed by owner and architect.
Sources
- Build with Claude overview — docs.anthropic.com — capability fit after problem framing
- Test and evaluate overview — docs.anthropic.com — metrics discovery must produce
- Models overview — docs.anthropic.com — choose models after requirements exist