You know your business and you know what is wrong with the way it runs today. What you may not know is how to turn that into a document a development company can estimate and build from.
This guide explains how to write a software requirements document without a technical background: what to include, how to phrase it, how much detail is enough, and which gaps cause estimates to go wrong.
Quick answer
A software requirements document describes the problem you want solved, who will use the software, what they need to do with it, and the limits the solution must work within. It does not need to describe how the software will be built. That part is the developer's job.
A useful document covers the business goal, the types of users and their permissions, the key workflows, the data, the integrations, quality expectations such as speed, security, accessibility and backups, the constraints, what is out of scope, and your open questions. For a first conversation with a development company, a short document that covers these honestly is more useful than a long one that covers only features.
What a requirements document is for
The document has three jobs. It lets a developer estimate effort. It gives both sides a shared reference when someone later asks "was that included?". And it forces you to make decisions before they become expensive to change.
You will see several names for it: software requirements specification (SRS), product requirements document (PRD), business requirements document (BRD), or simply a project brief. The differences matter less than the content. There is a formal international standard for requirements engineering, ISO/IEC/IEEE 29148, but you do not need to follow it to brief a vendor. A clear plain-language document is enough.
It is also not a contract. The commercial terms belong in a statement of work, which we cover in our guide to outsourcing software development from the US and UK. The requirements document usually becomes an attachment to it.
What developers actually need to know
Throughout this section we use one illustrative scenario, not a client case study: a plumbing and heating company that wants to replace phone calls and spreadsheets with a job booking system.
1. The goal and the measure of success
Start with the problem, not the feature list. "We want a booking app" tells a developer very little. "Office staff spend most of the morning assigning jobs by phone, and customers call back to ask when the engineer will arrive" tells them what matters and lets them suggest simpler solutions than the one you had in mind. Add how you will know it worked: fewer inbound calls, invoices sent on the day of the visit.
2. Users and roles
List every type of person who will use the system and what each can see and do. In the example: customers, office dispatchers, field engineers, and an owner who sees reports. Say roughly how many of each there are, which devices they use, and whether anyone works without a reliable internet connection. Permissions are one of the largest hidden sources of work, so "an engineer can only see their own jobs" is worth writing down.
3. Key workflows
A workflow is a task from start to finish. Describe the five to ten that matter most, in numbered steps, including what happens when things go wrong. For example: a customer requests a visit, a dispatcher assigns an engineer, the engineer completes the job, and the customer receives an invoice. Then add the exceptions: the engineer is sick, the customer cancels, the part is not in stock.
4. Data
List the things the system needs to remember (customers, jobs, engineers, parts, invoices) and the important details of each. Then answer three questions: does existing data need to be imported and from what, how long must records be kept, and does any of it include personal, payment or health information?
5. Integrations
Name every other system the new software must exchange information with: accounting, payments, email and SMS, maps, a CRM, single sign-on. Give the exact product and plan where you can, because what an integration can do often depends on the plan you pay for. Say which direction the data flows.
6. Constraints
Constraints are the fixed points a solution must fit around: a launch date tied to an event, a budget range, a regulation, a hosting requirement from your IT team, or existing software that must stay. If you need a mobile app, say whether both iPhone and Android are required. The trade-offs are covered in our comparison of native, Flutter and React Native development.
7. What is out of scope
This is the section people skip and developers value most. Write down what you are deliberately not building in this phase: "no customer-facing mobile app in phase one", "no stock management", "English only". It prevents a vendor from padding the estimate for things you never wanted, and it prevents arguments later.
User stories and acceptance criteria in plain terms
A user story is one sentence describing something a user needs and why. The common pattern is:
As a [type of user], I want to [do something] so that [benefit].
For example: "As a dispatcher, I want to see which engineers are free tomorrow morning so that I can assign a job without phoning anyone." The "so that" part tells the developer the purpose, which lets them make sensible decisions about details you did not specify.
Acceptance criteria are the conditions that must be true for you to agree the story is done. They turn a wish into something testable. A widely used format is Given, When, Then, which the Gherkin reference describes as the starting context, the action or event, and the expected outcome. In plain words:
- Given an engineer already has a job from 9 to 11 on Tuesday,
- When a dispatcher tries to assign them another job at 10 on Tuesday,
- Then the system warns about the clash and asks for confirmation.
You do not have to use this format. A bulleted list under each story works as well, provided each line can be checked with a yes or no. "The calendar should be easy to use" cannot be checked. "A dispatcher can move a job to another engineer by dragging it" can.
Prioritize every story
An unprioritized list forces the vendor to estimate everything as if it were essential. A simple method is MoSCoW, which the Agile Business Consortium defines as Must Have, Should Have, Could Have and Won't Have this time. Its test for a Must Have is strict: without it there would be no point deploying the solution. The same guidance recommends that Must Haves account for no more than 60 percent of total effort, so that there is room to absorb surprises. If everything on your list is a Must, the list is not yet prioritized.
The non-functional requirements people forget
Functional requirements describe what the software does. Non-functional requirements describe how well it must do it. They rarely appear in a first brief, yet they change the architecture, the hosting bill and the estimate. You do not need to supply technical answers. You need to supply the business facts in the right-hand column below.
| Area | What to tell the developer | Why it changes the estimate |
|---|---|---|
| Performance and scale | Expected number of users now and in two years, busiest times, how much data accumulates per month | Decides hosting size, database design and whether heavy tasks must run in the background |
| Availability | The hours the system must be usable and what an hour of downtime costs you | Round-the-clock availability needs redundancy and monitoring that office-hours software does not |
| Security and access | What data is sensitive, who may see it, how people log in, whether you need an audit trail of who changed what | Affects authentication, permissions, encryption and testing effort |
| Privacy and compliance | Countries your users are in, types of personal data, industry rules that apply to you | May require consent handling, data deletion, retention rules and specific hosting regions |
| Accessibility | The standard you want to meet and whether you serve the public or public-sector customers | Cheap to design in from the start, costly to add after the interface is built |
| Backups and recovery | How much recent data you could afford to lose, and how quickly you need to be running again after a failure | Sets backup frequency, where copies are kept and how often restores are tested |
Accessibility: US and UK notes
The common technical benchmark is the Web Content Accessibility Guidelines. WCAG 2.2 is the current W3C Recommendation and has three conformance levels: A, AA and AAA. Most organizations specify level AA.
In the United States, Department of Justice guidance states that the Americans with Disabilities Act applies to goods and services offered on the web by businesses open to the public and by state and local governments, and it points to WCAG as helpful guidance. In the United Kingdom, government guidance says public sector websites and mobile apps meet the legal requirement if they meet WCAG 2.2 AA. This is a high-level summary, not legal advice; confirm your own obligations with a qualified adviser.
Privacy and security
If the system will hold personal data about people in the UK, the Information Commissioner's Office explains that UK GDPR requires data protection by design and by default, meaning privacy is considered from the design stage rather than added later. US obligations vary by state and by sector, so list the states you operate in and any industry rules you already follow. Again, this is not legal advice.
For security, state what must be protected and ask the vendor which standard they verify against. The OWASP Application Security Verification Standard is an open standard that provides a list of requirements for secure development and a basis for testing them.
How much detail is enough?
The right level of detail depends on what you will use the document for. Too little and the estimate is a guess. Too much and you have spent weeks designing a solution before anyone qualified has challenged it.
| Your situation | Detail needed | What to leave for later |
|---|---|---|
| First conversations, asking for a rough estimate | Goal, roles, a list of workflows, integrations by name, constraints, out of scope | Acceptance criteria, field-level data, screen layouts |
| Requesting a fixed-price quote | All of the above plus prioritized user stories with acceptance criteria, data import details and non-functional requirements | Visual design, technical architecture |
| Time and materials or a dedicated team | Goal, roles, constraints, and detailed stories for the first few weeks of work only | Detail for later phases, written shortly before each is built |
A practical test: hand the document to someone outside the project and ask them to explain back what the software does, who uses it and what it will not do. If they can, a developer can estimate from it. If they ask questions, add the answers to the document.
Describe the need, not the solution. "A dropdown with all customers" is a solution, and a poor one if you have thousands of customers. "The dispatcher needs to find a customer quickly by name, phone number or postcode (ZIP code in the US)" is a need, and it lets the developer choose the right design.
A section-by-section template
The structure below works for most business software. Keep each section short. Where you do not know an answer, write "unknown" and list it under open questions rather than leaving the section out.
| Section | What to write |
|---|---|
| 1. Background and goals | Your business in a few sentences, the problem today, what success looks like and how you will measure it |
| 2. Users and roles | Each user type, approximate numbers, devices, and what each may see and do |
| 3. Scope summary | The main capabilities in one list, each marked Must, Should or Could |
| 4. Key workflows | Numbered steps for each main task, with exceptions |
| 5. User stories and acceptance criteria | One story per need, with checkable criteria for the Must Haves |
| 6. Data | What records are stored, sensitive fields, import sources, retention |
| 7. Integrations | Each external system, product and plan, direction of data, who owns the account |
| 8. Non-functional requirements | Your answers to the table in the earlier section, including supported browsers and devices |
| 9. Constraints | Budget range, dates, legal or policy requirements, technology that must stay |
| 10. Out of scope | What this phase will not include |
| 11. Assumptions and open questions | What you have assumed and what you have not decided |
| 12. Reference material | Current spreadsheets, forms, screenshots, example reports, products you like |
Do not skip section 12. A real spreadsheet your team uses every day shows a developer the actual data and edge cases faster than any description.
Common mistakes that lead to bad estimates
- Listing features without goals. The vendor prices exactly what you wrote, even where a simpler approach would have met the goal.
- Vague quality words. "Fast", "secure", "user-friendly" and "scalable" mean different things to each reader. Replace them with a fact or an example.
- Describing only the happy path. Cancellations, refunds, duplicates, mistakes and missing information are a large share of real work.
- Forgetting the admin side. Someone has to add users, correct records, change prices and export reports. If no one writes these down, they arrive as change requests.
- Unchecked integrations and old data. "Connect to our accounting software" is not estimable until someone confirms what that product can exchange, and importing years of spreadsheets can be a project in itself.
- Hiding the budget. A range lets a vendor propose a scope that fits. Without one, you get estimates for different products that cannot be compared.
- No single owner. Requirements gathered from several departments and never reconciled contain contradictions. One named person should make the final call.
For technical readers
If you are a CTO or technical lead reviewing a document written by a non-technical colleague, a few additions make it estimable without rewriting it:
- Give each requirement a stable identifier so that estimates, tests and change requests can refer to it.
- Add a simple entity list with relationships and approximate volumes.
- Turn non-functional statements into measurable targets, for example a recovery point objective and recovery time objective for backups, and response-time targets for named operations under a stated load.
- For each integration, record the API version, authentication method, rate limits and whether a sandbox exists.
Frequently asked questions
Do I need a requirements document if we are using agile development?
Yes, but a lighter one. Agile teams still need the goal, roles, constraints, priorities and out-of-scope list at the start. What changes is that detailed stories and acceptance criteria are written shortly before each piece of work rather than all at once.
What is the difference between a BRD, a PRD and an SRS?
A business requirements document focuses on business goals and needs. A product requirements document describes what the product should do for its users. A software requirements specification is the most detailed and is usually written with or by the technical team. Companies use the terms loosely, so agree on the content rather than the label.
How long should a software requirements document be?
As long as it takes to cover the sections above without padding. A first brief for a small business application often fits in a handful of pages, and it grows as stories gain acceptance criteria. Length is not a measure of quality; unanswered questions are.
Can the development company write the requirements for me?
Many will, usually as a paid discovery or scoping phase, and it is often worth doing. They still need you to supply the goals, the workflows and the decisions. A short document from you makes that phase quicker and makes proposals from different vendors easier to compare.
Conclusion and next step
A good requirements document from a non-technical author is not a technical specification. It is a clear account of what you need, who needs it and what you are not building, with unknowns marked as unknowns. That is what a developer needs to produce an estimate you can rely on.
Start with the template: fill in sections 1, 2, 3 and 10 in one sitting, then add workflows over a few days. If you would like a development team to review a draft and point out the gaps before you request estimates, you can send your requirements to Entrant Technologies, which builds websites, web applications, mobile apps and custom software.
