How to Write Software Requirements — Free Template
Good software requirements describe what the system should do, not how. Start with user stories (As a [user], I want [goal] so that [reason]), then add acceptance criteria for each story.
Good software requirements describe what the system should do, not how. Start with user stories in the format "As a [user], I want [goal] so that [reason]," then add acceptance criteria for each story. Separate functional requirements (features) from non-functional requirements (performance, security). Avoid technical jargon and keep each requirement testable.
What requirements are and why they matter
Software requirements are a written description of what a software system must do. They serve as the single source of truth for everyone involved in the project: the client who funds it, the product manager who prioritises it, the designers who mock it up, and the developers who build it.
Without written requirements, every team member has a different picture of what the final product looks like. The client imagines one thing, the developer interprets something else, and the result is rework, missed deadlines, and strained relationships. In fact, unclear requirements are the top cause of software project failure.
A good requirements document prevents this by forcing everyone to agree on specifics before a single line of code is written. For more on why projects go wrong, read our analysis of why software projects fail.
User story format
The most effective format for writing software requirements is the user story. It follows a simple structure:
As a [type of user], I want [goal] so that [reason].
For example: "As a customer, I want to save items to a wishlist so that I can purchase them later."
User stories keep the focus on the user and their motivation, not on implementation details. They are intentionally short because the details live in the acceptance criteria. A good user story is independent, negotiable, valuable, estimable, small, and testable (the INVEST principle).
Acceptance criteria
Acceptance criteria turn a user story into something a developer can build and a tester can verify. They are a checklist of conditions that must be true for the story to be considered done:
- Given the user is logged in and on their wishlist page
- When they click "Add to wishlist" on a product
- Then the product appears in their wishlist with a success message
- And the wishlist count in the header updates immediately
Write acceptance criteria in plain language using the Given-When-Then format. Avoid technical implementation details (no database queries, no API endpoints). Keep each criterion independently testable so the QA team can mark them pass/fail.
Functional vs non-functional requirements
| Type | Description | Example |
|---|---|---|
| Functional | What the system does | User can reset their password via email link |
| Functional | Data the system stores | System stores order history for 3 years |
| Functional | Interactions the system supports | Admin can export reports as CSV or PDF |
| Non-functional | Performance | Page loads in under 2 seconds on 4G |
| Non-functional | Security | All data encrypted at rest (AES-256) |
| Non-functional | Scalability | System supports 1,000 concurrent users |
| Non-functional | Availability | Uptime of 99.9% excluding scheduled maintenance |
Both types are essential. Functional requirements define the scope; non-functional requirements define the quality. Many projects fail not because they built the wrong features, but because the features did not perform well enough for users to tolerate them.
Common mistakes
The most common mistakes in software requirements include:
- Writing solution requirements, not problem requirements. "The system uses React" tells you nothing about what it does. "The user can search products by name and category" describes the actual need.
- Being too vague. "Fast performance" is not a requirement. "The product search returns results within 500 milliseconds" is.
- Mixing requirements and design. Requirements describe what. Wireframes and mockups describe how. Keep them separate.
- Not involving the development team. Requirements written in isolation often describe something technically infeasible or unnecessarily expensive to build.
For more on avoiding these pitfalls, read our guide on how to choose a software development partner.
Free requirements template
To help you get started, we offer a free software requirements template in Google Docs format. It includes sections for project overview, user stories with acceptance criteria, functional requirements, non-functional requirements, and assumptions. Contact us and we will share the template with you at no cost.
If you are still deciding whether custom software is right for your business, read our comparison of build vs buy software to help you decide.
Frequently asked questions
A software requirements document (often called an SRS or PRD) describes what a software system should do. It lists functional requirements (features), non-functional requirements (performance, security), and constraints (budget, timeline, tech stack).
Functional requirements describe what the system does: login, search, checkout, reporting. Non-functional requirements describe how well it does it: must load in under 2 seconds, support 1,000 concurrent users, or encrypt all data at rest.
Use the standard format: As a [type of user], I want [goal] so that [reason]. Keep it simple, write it from the user's perspective, and make sure it delivers value. Each story should be estimable and testable.
Acceptance criteria are the conditions that a feature must meet to be considered complete. They are written as a checklist of pass/fail tests that both the development team and client agree on before work begins.
A business analyst or product manager typically writes requirements, but the best results come from collaboration. The client provides domain expertise, the development team provides technical feasibility input, and a facilitator reconciles the two.