A software requirements document describes what you want built and why. Its job is not to specify every button. Its job is to give a development team enough understanding to estimate accurately, ask the right questions and make good decisions on your behalf. Vague briefs lead to wide estimates and surprises. Clear briefs lead to accurate estimates and fewer changes mid-project.
This guide explains what to include, what to leave out and how to write it in plain language, even if you are not technical.
1. Start with the business goal
Open with a short paragraph on why the project exists. What problem does it solve, for whom, and how will you know it worked? For example: "Our office staff spend about two days a month building owner statements by hand. We want statements generated from bookings and expenses so a staff member only reviews them."
This paragraph is the most important part of the document. When a trade-off appears during the build, the team will check it against the goal.
2. Describe the users
List each type of user and what they need to do. Keep it concrete: "Office staff: create bookings, assign cleaners, review statements. Owners: view their statements and bookings. Cleaners: see today's jobs on a phone and mark them done."
Note how many users of each type you expect, and whether any use phones, work offline or need accessibility support. These details change the design and the estimate.
3. Walk through the workflows
Describe the main tasks step by step, as they should work in the new system. Write them as short numbered steps. Then add the exceptions, because that is where most of the cost hides: what happens when a booking is cancelled, when a payment fails, when two people edit the same record?
4. List features by priority
Now list the features, grouped as must-have, should-have and nice-to-have. Must-haves are what the first release cannot work without. Be strict: a long must-have list is a sign the scope is not yet focused. For a new product, see how to plan a SaaS MVP for how to cut scope.
Describe features in terms of what users achieve, not how screens look. "Owners can download a monthly statement as a PDF" is more useful than "a download button on the owner page".
5. Describe the data
List the main things the system stores, such as properties, owners, bookings and expenses, and the key facts about each. Mention where the data lives today, how much there is and whether it needs to be moved into the new system. Data migration is often underestimated.
6. Write down the business rules
Rules are the logic that makes your business work: pricing, approvals, deadlines, discounts, cut-off times and permissions. Write each one as a plain sentence, for example: "Expenses over 500 dollars need owner approval before they appear on a statement." Rules that live only in someone's head are the most common source of mistakes in new software.
7. List integrations
Name every system the new software must connect to, such as your CRM, accounting package, payment provider or calendar, and what should flow between them. Note whether each has an API and who owns the account. Integrations are a big part of most estimates, and unknown ones add risk. See API integration.
8. Note constraints and non-functional needs
Constraints shape the solution as much as features do. Include anything that applies:
- Deadlines and why they exist.
- Budget range, even a rough one.
- Security or compliance needs, such as data location or audit logs.
- Expected usage and growth.
- Preferred hosting or technology, if any, and why.
- Languages, accessibility and devices to support.
9. Add simple sketches
A few rough wireframes of the main screens remove a lot of ambiguity. They can be hand drawn and photographed. The point is to show what information appears where and in what order, not how it looks.
10. Mark what you do not know
Every project has open questions. List them honestly: "We have not decided whether owners can edit bookings." A good team will help you answer them, and knowing about them lets the team estimate the uncertainty instead of guessing.
What to leave out
Leave out technical instructions unless you have a real reason for them, such as a required database or hosting provider. Let the team propose the architecture. Also leave out long background history, marketing copy and features you might want in two years. They make the document longer without making estimates better.
Briefing an AI-accelerated team
Teams that build with AI tools benefit even more from clear written requirements, because the same descriptions can guide both people and tools. Clear workflows, rules and examples translate directly into faster, more accurate work. See how to brief an AI development team.
A simple template
- Goal: the problem, who has it and how success is measured.
- Users: types, numbers and devices.
- Workflows: numbered steps plus exceptions.
- Features: must, should and nice-to-have.
- Data: main records, current location, migration needs.
- Rules: pricing, approvals, deadlines, permissions.
- Integrations: systems, direction of data, API access.
- Constraints: deadline, budget, security, growth.
- Sketches: main screens.
- Open questions.
With this in hand, you can compare proposals fairly. Read fixed scope vs time and materials to choose how to contract the work.
After you send it
Expect a good team to come back with questions. That is a good sign: it means they are thinking about your business, not just pricing a list. Answer the questions in the document itself, so it stays the single source of truth for everyone. Keep it updated as decisions are made during the project, and it becomes the reference for testing and for anyone who joins later.
If you are comparing several teams, send them all the same document and the same answers. It is the only fair way to compare estimates, and differences in the questions they ask will tell you a lot about how each team works.
A short example
Here is how a small section might read. Goal: "Office staff spend two days each month building owner statements by hand. We want statements generated automatically, with staff reviewing them in under an hour." Users: "Office staff (three people, desktop), owners (about 60, mostly phone)." Workflow: "1. Bookings and expenses are recorded during the month. 2. On the first working day, statements are generated for each owner. 3. Staff review and approve each statement. 4. Owners receive an email with a link to download it." Exceptions: "Expenses over 500 dollars need owner approval first. Cancelled bookings with a fee still count as income."
That paragraph alone answers most of the questions a developer would ask about the feature, and it can be estimated with confidence.
Do not worry about making it perfect. A clear, honest document with open questions marked is far more useful than a long one that tries to settle everything in advance.