Translating Business Requirements into Technical Scope: The FDE Method

The short answer

Requirements translation fails at predictable joints: goals stay vague, metrics go unmeasured, boundaries stay unwritten. The method below forces each hop into writing, with the customer confirming - because an unconfirmed translation is a future change request.

The five hops

1. Business goal. "Reduce invoice exceptions." (Needs a number.)
2. Observable workflow. Where exceptions arise today, step by step, with volumes.
3. Measurable success. "Exceptions < 5% of invoices within 90 days of go-live." (Customer signs this.)
4. Technical boundary. Which systems we touch, which we read, which we never modify.
5. Acceptance criteria. Testable statements: "Given a duplicate invoice ID from SAP, the pipeline quarantines and alerts - never double-posts."

Worked example

Business ask: "Our support routing is chaos, use AI to fix it."

Hop 2: shadow two agents; 40% of tickets misrouted initially; reassignment costs ~3 h/day team-wide. Hop 3: success = misrouting < 12% in 60 days, measured by ticket audit field. Hop 4: read ticket API + historical labels; write routing suggestion field only; never auto-move without agent approval. Hop 5: criteria like "Given a billing refund ticket in TR, the model suggests 'billing/refunds' with ≥0.7 confidence, else 'needs-human'."

Note what this produced: not "an AI," but a bounded assist with a human gate and a metric. That's the difference between a deployment and a liability. The AI decisions module drills this pattern.

Anti-patterns

• Starting from the technology ("we bought vector DB, find a use").
• Accepting "improve efficiency" as a metric.
• Writing scope alone and emailing it for "review."

Continue: FDE discovery questions · Handling scope changes