IT Project Acceptance: Moving Disputes Upstream to Requirements

Where disputes come from

"We built the feature." "That's not what I meant." Disagreements like these trace back to requirements without verifiable acceptance criteria. When requirements say "easy to use", "looks good" or "responds quickly", acceptance becomes subjective.

Writing verifiable requirements

• Replace adjectives with measurable numbers: instead of "fast response", specify "list page first paint under 2 seconds at 2 million records"
• State edge cases: behaviour on empty data, oversized input, concurrent operations and insufficient permissions
• Define done: one executable verification step per feature
• Agree exclusions: state explicitly what is out of scope to avoid scope-creep arguments

Process support

We recommend drafting acceptance test cases during requirements sign-off and having both parties approve them. Update the cases whenever requirements change, so delivery is never measured against a stale standard.