Most software projects that go over budget don't fail because of bad code. They fail because people meant different things by the same words. "Users can manage their account" sounds clear until a developer asks: can they delete it? Change their email? Add teammates? Good requirements turn assumptions into shared, testable agreements. Here's how to write them, even if you're not technical.
What good requirements do
- Explain why the software is being built
- Describe who will use it and what they need to achieve
- Define what it must do, in testable terms
- Set how well it must work: speed, security, accessibility
- Make priorities clear, so trade-offs can be made sensibly
The key sections
| Section | What it covers | Example |
|---|---|---|
| Goals | The business outcomes | "Cut manual order processing time in half" |
| Users | Who uses the system and what they need | Customers, warehouse staff, admins |
| Scope | What's in and out of this phase | "Mobile app is out of scope for phase 1" |
| Features / user stories | What users can do | "As a customer, I want to track my order" |
| Acceptance criteria | How we know each feature works | "Status updates within 5 minutes of dispatch" |
| Non-functional requirements | Performance, security, accessibility, reliability | "Pages load in under 2.5 seconds on mobile" |
| Integrations | Other systems involved | Stripe, Xero, the warehouse system |
| Data | What's stored, migrated and reported | Customer records, order history |
| Constraints | Budget, deadlines, technology, regulations | "Launch before the spring sale" |
Writing user stories
As a [type of user], I want [goal] so that [benefit].
| Vague requirement | User story |
|---|---|
| "Order tracking" | As a customer, I want to see where my order is so that I know when to expect it. |
| "Reports" | As a sales manager, I want a weekly report of new leads by source so that I can see which campaigns work. |
| "User management" | As an account owner, I want to invite teammates with limited permissions so that they can help without seeing billing. |
Acceptance criteria: defining "done"
Acceptance criteria turn stories into testable conditions. A common format is Given / When / Then:
Given I'm a logged-in customer with a dispatched order, When I open the order page, Then I see the courier, tracking number and latest status.
Include edge cases: what happens if there's no tracking number yet, or the courier's system is down?
Don't forget non-functional requirements
| Area | Example requirement |
|---|---|
| Performance | Key pages load in under 2.5 seconds on a mid-range phone |
| Security | Two-factor authentication for admin users; data encrypted in transit and at rest |
| Accessibility | Meets WCAG 2.2 AA |
| Reliability | 99.9% uptime target, daily backups |
| Scalability | Handles three times current order volume |
| Privacy | Personal data handled in line with UK GDPR |
| Browser and device support | Latest two versions of major browsers; iOS and Android |
Prioritise ruthlessly
Use MoSCoW to make trade-offs explicit:
| Priority | Meaning |
|---|---|
| Must have | The release fails without it |
| Should have | Important, but there's a workaround |
| Could have | Nice to have if time allows |
| Won't have (this time) | Agreed as out of scope for now |
Being clear about "won't have" is one of the best ways to prevent scope creep.
A simple requirements template
1. Overview and goals
2. Users and their needs
3. Scope (in / out)
4. User stories with acceptance criteria (prioritised)
5. Non-functional requirements
6. Integrations and data
7. Constraints and assumptions
8. Open questions
9. Glossary of terms
Tips for non-technical writers
- Describe problems and outcomes, not technical solutions
- Use real examples and screenshots of current processes
- Define terms in a glossary, so "customer" means the same to everyone
- Include sketches or wireframes where they clarify; see our guide to wireframes and user flows
- Keep a list of open questions instead of guessing
Common mistakes
- Requirements that describe solutions instead of needs
- No acceptance criteria, so "done" is a matter of opinion
- Forgetting admin users, reporting and edge cases
- Ignoring non-functional requirements until late
- Treating the document as fixed when learning shows something better
Example: requirements for an online booking feature
User story
As a customer, I want to book an available appointment online so that I don't have to phone during opening hours.
Acceptance criteria
- Customers see available times for the next 30 days, by service and staff member
- Times already booked or outside opening hours aren't shown
- Customers enter name, email and phone before confirming
- A confirmation email is sent immediately, with options to reschedule or cancel
- A reminder is sent 24 hours before the appointment
- Staff see new bookings in the admin calendar within one minute
- If two people try to book the same slot, only the first succeeds and the second sees a clear message
Non-functional
- Booking pages load in under 2.5 seconds on mobile
- Pages meet WCAG 2.2 AA
- Personal data handled in line with the privacy policy
Reviewing requirements with developers
- Walk through each story together and ask: is anything ambiguous?
- Let developers flag stories that are expensive or risky, and discuss alternatives.
- Agree estimates and priorities together.
- Keep the document updated as decisions are made, with a change log.
How we help
Every custom web application and SaaS MVP we build starts with discovery workshops that turn your goals into prioritised stories and acceptance criteria. Not sure about scope yet? Try the free AI Project Blueprint, and read our guide on commissioning a SaaS MVP.
The short version
Write down goals, users and scope, express features as user stories with clear acceptance criteria, add non-functional requirements, list integrations and constraints, prioritise with MoSCoW and keep a glossary and open questions list. Describe needs, not solutions.
