6.1 — Structured Discovery and Requirement Gathering

CCAR-P Domain 6 · Task 6.1

What You Need to Know

The request is not the requirement. Discovery finds the problem behind the request.

Six Outputs Discovery Must Produce

1. Business problem with measured baseline — hours, error rates, backlog, revenue at risk
2. Real workflow (including workarounds)
3. Output the system must produce (fixes task shape)
4. Consequence when that output is wrong + thresholded, owned success criteria
5. Data — what exists, quality, ownership, lawful basis
6. Constraints and accountable decision-maker

Consequence of Error Sets the Bar

Wrong suggestion reviewed by a human vs wrong figure flowing into a payment sets different accuracy thresholds, human-checkpoint needs, and cost/latency envelopes.

Success Criteria

Specific, measurable, achievable, relevant. Targets from benchmarks/prior experiments/expert knowledge. Most use cases need several at once. Directional criteria (“improve the customer experience”) cannot end a project.

Feasibility Triage

1. Decidable task with verifiable output?
2. Data exists, good enough, lawfully usable?
3. Cost of being wrong tolerable at achievable accuracy?

A “no” is a finding, not a failure. The honest no is a professional output.

Exam Traps (Four Failure Postures)

• Capitulation — agrees to the impossible (early price, demo before characterisation)
• Evasion — complies silently or builds it your own way without saying so
• Obstruction — escalates over the accountable owner
• Theatre — more meetings, more metrics, more documents