By Alpit Patel and the aibrevo team · October 31, 2026 · 6 min read
How to Write a Software Requirements Document
Quick answer
Write a software requirements document in seven parts: the problem and goals, the users and their roles, the workflows written as user stories with acceptance criteria, the data and integrations, non-functional requirements such as speed, security and compliance, what is out of scope, and priorities and constraints. Each requirement should be specific enough that a tester can check it. Below: a section-by-section template, how to write a requirement that can be tested, real examples drawn from one of our builds, and SRS vs BRD vs FRD.
Key takeaways
- A useful software requirements document has seven parts: problem and goals, users and roles, workflows as user stories, acceptance criteria, data and integrations, non-functional requirements, and out-of-scope items with priorities.
- Every requirement should be testable. 'Fast checkout' is not a requirement; 'checkout completes in under 3 seconds for 95% of orders' is.
- The current international standard for requirements engineering is ISO/IEC/IEEE 29148:2018, an active standard that replaced the 2011 edition, which itself superseded IEEE 830 for software requirements specifications.
- Out of scope is as important as in scope. Writing down what version one will not do is what makes a fixed-price quote and a short timeline possible.
- Length follows the product, not a page target. Our builds went live in 5 to 10 weeks each, and the requirements for a first release that size fit a document a team can read in one sitting.
Write a software requirements document in seven parts: the problem and goals, the users and their roles, the workflows as user stories, acceptance criteria for each, the data and integrations, non-functional requirements such as speed, security and compliance, and what is out of scope, with everything ranked by priority. Each requirement should be specific enough that a tester can prove it works or does not.
Checked October 31, 2026. We checked the status of the requirements engineering standard on IEEE’s site and drew the worked examples from a build in our own portfolio.
What sections does a software requirements document need?
Use this as a template. The right-hand column is what each section must answer.
| Section | What it answers |
|---|---|
| 1. Problem and goals | What is broken today, for whom, and what measurable result counts as success? |
| 2. Users and roles | Who uses the system, and what can each role see and do? |
| 3. Workflows (user stories) | What does each role need to do, step by step, and why? |
| 4. Acceptance criteria | What exact conditions prove each story works, including errors? |
| 5. Data and integrations | What records are stored, where data comes from, which outside systems connect? |
| 6. Non-functional requirements | How fast, how available, how secure, which regulations, which devices and browsers? |
| 7. Scope, priorities and constraints | What is out of scope, what is must-have, which dates, limits and technical constraints apply? |
| Appendix: glossary | What do your business terms mean, so nobody builds the wrong thing? |
How do you write a requirement that can be tested?
Each requirement should be about one thing, say who does it, and say what result proves it worked. Compare:
| Weak | Testable |
|---|---|
| The checkout should be fast. | Checkout completes in under 3 seconds for 95% of orders, measured on a mid-range phone on 4G. |
| Admins can manage users. | An admin can invite, deactivate and change the role of any user; a deactivated user cannot sign in and their records remain visible to admins. |
| The system should be secure. | All traffic uses HTTPS; passwords are never stored in plain text; staff accounts require two-factor sign-in. |
| Easy to upload the passenger list. | An organiser can upload a CSV of up to 500 passengers; rows with missing names are listed back with line numbers and the rest are saved. |
The numbers in the right-hand column are examples to show the form, not recommendations for your product. Pick targets that match your users.
A user story plus acceptance criteria looks like this:
Story: As a group organiser, I want to upload my passenger list as a file, so that I do not type every name into a form.
Acceptance criteria: Given a CSV with the required columns, when I upload it, then every valid row appears on the manifest. Given a row with a missing name, when I upload, then that row is rejected with its line number and the valid rows are still saved. Given the departure is less than 72 hours away, when I try to edit the manifest, then editing is locked.
What does that look like on a real project?
The examples above come from the shape of our Spirit Airlines group booking build, which went live in 10 weeks. Its main requirements, written as outcomes, were:
- A public group quote request form with CSV manifest upload, so an organiser pastes a passenger list instead of typing twenty names.
- A rules-based pricing engine that checks live fare inventory through the Sabre integration, applies the discount matrix and flags anything outside policy instead of approving it silently. Quotes carry an expiry timer so held inventory releases itself.
- An approval chain from agent to supervisor to revenue management, triggered by discount depth, not passenger count.
- Deposit and balance payments with automated reminders to the organiser at 30, 14 and 3 days.
- Manifest editing open until 72 hours before departure, with role-based permissions keeping pricing controls with authorised staff.
Each line names a user, an action and a rule a tester can check. The measurable goal behind them: the average group quote for parties of 20 or more went from 3 days to 40 minutes after launch.
Source: features and results stated on the Spirit Airlines case study, checked Oct 31, 2026.
What are non-functional requirements?
They describe how well the system works rather than what it does. Write them as numbers or named standards:
- Performance: page or action response times under expected load.
- Availability: acceptable downtime and when maintenance can happen.
- Security and privacy: sign-in rules, data encryption, who can see personal data, data retention.
- Compliance: any regulation that applies, such as HIPAA for health data or PCI DSS for card payments.
- Accessibility: the WCAG level the interface must meet.
- Compatibility: browsers, devices and operating system versions to support.
- Operations: backups, logging, monitoring and who gets alerted.
Why write down what is out of scope?
Because unwritten assumptions turn into disputes and overruns. A short “not in this release” list (a mobile app, a second language, reporting beyond three dashboards, a migration of old records) lets a vendor quote a fixed price for the rest, and lets you add those items later on purpose. It is the core of MVP development and of fixed-price contracts.
Is there a formal standard for requirements documents?
Yes. The current one is ISO/IEC/IEEE 29148:2018, Systems and software engineering, Life cycle processes, Requirements engineering. IEEE lists it as an active standard, published November 30, 2018, superseding the 2011 edition. Its scope covers the processes and work products of requirements engineering, what makes a good requirement, and the information items, such as a software requirements specification, that the process produces (IEEE Standards, checked Oct 31, 2026). IEEE also lists IEEE 830-1998, the older SRS recommended practice many templates online still cite, as “Superseded by ISO/IEC/IEEE 29148:2011” (IEEE Standards, checked Oct 31, 2026).
You do not need to follow a standard line by line to write a useful document, but large organisations, government buyers and regulated industries often expect its structure.
SRS vs BRD vs FRD: which one do you need?
| Document | Answers | Usually written by |
|---|---|---|
| Business requirements document (BRD) | Why are we doing this, and what does the business need? | Business owner or product lead |
| Functional requirements document (FRD) | What must the system do? | Product lead or business analyst |
| Software requirements specification (SRS) | Exactly what the software does and how well, in testable terms | Product and engineering together |
For most projects under a few months, one document with all seven sections covers all three. Separate documents make sense when different groups sign off on business goals and technical detail.
Who should write it?
You write the goals, users and workflows, because you know the work. The development team turns them into acceptance criteria, flags constraints, and estimates. Good vendors will help you get from a rough brief to a testable document before they quote; it is also a fair test of whether they understand your business, as covered in how to choose a software development company. Design work, such as wireframes and prototypes, often happens alongside; see UI and UX design.
Have a rough brief? Send it to us or book a free 30-minute call. We turn it into a scope and send a written quote after the call. See custom software development for how we build.
Sources
All pages opened on Oct 31, 2026.
- IEEE Standards Association, IEEE/ISO/IEC 29148-2018: Systems and software engineering, Life cycle processes, Requirements engineering: status, publication date, scope.
- IEEE Standards Association, IEEE 830-1998: Recommended Practice for Software Requirements Specifications: superseded by ISO/IEC/IEEE 29148:2011.
- aibrevo, Spirit Airlines group booking case study: features and results used in the worked examples.