FDE Foundations · Module 3: Problem Framing & Scope
Requirements and Acceptance Criteria
A requirement is testable when you can write the check before the feature. 'Given a duplicate invoice, when uploaded, then the system marks it and notifies finance' is a requirement. 'Handle duplicates well' is a wish.
9 min reading
Objectives
- Write acceptance criteria that a test can verify
- Use given-when-then style for behavioral requirements
- Reject untestable requirements at review time
Testable language
Each requirement becomes one or more acceptance criteria in the form: given a state, when an action happens, then an observable result follows. If you cannot fill the three parts, the requirement is not ready. Numbers help: "processes 500 invoices in under 10 minutes" is testable; "fast processing" is not.
Examples
- Given a 40 MB PDF with a scanned signature, when submitted, then the system stores it and flags it for manual review within 60 seconds.
- Given a user with viewer role, when they request the export endpoint, then the response is 403 and an audit event is written.
What to do with untestable asks
When a stakeholder hands you "make it user friendly", translate: which screen, which task, how measured? Offer a draft criterion and confirm. The translation step is where expectations get aligned cheaply.
Coverage check
Before build starts, confirm every in-scope capability has at least one acceptance criterion and every criterion maps to a capability. Orphans on either side mean scope is still fuzzy.
Quick check
An optional 2-3 question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Exercise
Take these three wishes and rewrite each as a testable acceptance criterion: 'fast search', 'secure enough', 'easy onboarding'. Add a given-when-then line for each.
Pass criteria
Three rewritten criteria, each with a measurable threshold and given-when-then structure; no criteria use vague words like fast or easy.