Overview
Based on Mastering the Requirements Process by Suzanne & James Robertson - the Fit Criteria concept, where every requirement gets a quantified, measurable condition that proves it has been satisfied. Also draws on User Stories Applied by Mike Cohn for the 3 C's (Card, Conversation, Confirmation) where Confirmation = acceptance criteria, and Writing Effective Use Cases by Alistair Cockburn where the Success Guarantee (postcondition) is the use case's acceptance criterion. The key insight from Robertson: if you cannot write a fit criterion for a requirement, the requirement is too vague to implement.
Workflow
Step 1: Identify the requirement or story to test
Start from a documented requirement (FR-XXX), user story, or use case. Extract:
- What the system should do (the behavior)
- Why it matters (the rationale - drives which edge cases to cover)
- Who is the actor (drives the perspective of the criteria)
Step 2: Write the primary acceptance criterion (happy path)
Use Robertson's Fit Criterion format for precision:
FIT CRITERION: [Measurable condition that proves the requirement is met]
MEASUREMENT: [How to verify - manual test, automated check, metric threshold]
Or Gherkin format for scenario-based criteria:
GIVEN [precondition / context]
WHEN [action / trigger]
THEN [expected outcome / observable result]
Step 3: Write criteria for the four paths
Every requirement needs criteria covering:
- Happy path: The expected successful flow
- Edge cases: Boundary conditions, empty states, maximum values
- Error path: Invalid input, system failures, timeout scenarios
- Empty/null path: No data, first-time use, zero results
Example for a search feature:
Happy: GIVEN products exist WHEN user searches "laptop" THEN matching results display within 500ms
Edge: GIVEN 10,000+ results WHEN user searches THEN first page loads with pagination controls
Error: GIVEN search service is unavailable WHEN user searches THEN error message displays with retry option
Empty: GIVEN no products match WHEN user searches "xyznonexistent" THEN "no results" message displays with suggestions
Step 4: Quantify vague criteria (Robertson's Fit Criteria)
Convert subjective requirements into measurable conditions:
| Vague | Fit Criterion |
|---|
| "Easy to use" | 80% of new users complete [task] within 5 minutes without assistance |
| "Fast" | 95th percentile response time < 500ms under [load condition] |
| "Secure" | Passes [standard] penetration test with zero critical findings |
| "Reliable" | 99.9% uptime measured monthly; mean time to recovery < 4 hours |
| "Scalable" | Supports [N] concurrent users with < 10% performance degradation |
Step 5: Link criteria to test type
For each criterion, specify how it will be verified:
AC-001: [criterion]
TEST TYPE: [unit / integration / E2E / manual / performance / security]
AUTOMATION: [yes / no - with justification if no]
Step 6: Review with the "three amigos"
Walk through criteria with: the BA (requirements perspective), a developer (feasibility), and a tester (completeness). Criteria that the tester cannot execute or the developer cannot implement need revision.
Anti-Patterns
1. Vague criteria that cannot be tested
Bad: "The system should be user-friendly."
Good: "80% of users complete the checkout flow in under 3 minutes on first attempt."
2. Only happy-path criteria
Bad: Acceptance criteria that only describe the successful flow.
Good: Criteria covering happy, edge, error, and empty paths for every requirement.
3. Implementation-specific criteria
Bad: "The React component renders a dropdown with CSS class .select-primary."
Good: "The user can select a value from a constrained list of options."
4. Criteria without a measurement method
Bad: "The system loads quickly." (How will you measure this?)
Good: "Page load < 2 seconds measured at the 95th percentile using [monitoring tool]."
5. Copy-paste criteria across stories
Bad: Same generic acceptance criteria on every story ("meets coding standards").
Good: Each story has criteria specific to its behavior and business logic.
Quality Checklist