Describe the task and starting conditions
State who is using the feature, what information exists and what they are trying to achieve. Replace vague requirements such as “easy reporting” with a concrete task. For example, an authorised user might need to select a reporting period and export the records included in a defined metric. The conditions make the expected behaviour testable.
Specify the result and important boundaries
Describe what should change, what should be displayed and what must remain unchanged. Include limits, permissions and required validation. Avoid prescribing every implementation detail unless it is a genuine constraint. The aim is agreement about the outcome, while leaving room for the team to choose a maintainable technical approach.
Add failure and recovery examples
Consider missing data, invalid input, a disconnected service and a user without permission. Explain the message and recovery action expected in each case. A feature is not ready merely because the ideal path works. Decide which errors require support intervention and which a user should be able to correct without losing their work.
Review with users before development finishes
Walk through the criteria using a prototype or an early build. Confirm that the business reviewer understands how to evaluate them. Record changes as the team learns more, rather than leaving contradictory requirements in separate documents. Use the agreed checks at handover so acceptance is based on observable behaviour instead of an undefined impression of completeness.
Your practical checklist
- Name the user, task and starting state
- Define observable results and boundaries
- Include errors, permissions and recovery
- Agree the review method before handover
Working through a similar question?
We’re happy to help you find a practical starting point.
Talk to AMGK