A software requirements document for a small business does not need to be forty pages. It needs to be one page that two people can read separately and picture the same thing. Plenty of projects go wrong the other way: a long, confident document that nobody agreed on, or no document at all.
You do not need technical vocabulary to write one. You need to describe who uses the software, what they need to do, how you will know it works, and what it will not do. That is a business exercise, and it is worth doing even if you never hire anyone, because it tells you whether you are describing one problem or six.
Below is a template you can copy, a plain way to write user stories, and a list of what to leave out. If you are still deciding whether to build at all, read our guide to custom software for small business first.
Have a draft already? Request an estimate and we will reply with scope and a price range for a sensible first phase.
Why one page beats forty
Long specifications try to answer every question before work starts, and they are wrong in the places that matter most, because nobody knows how people will really use the system until they use it. The goal of a requirements document is not to freeze every decision. It is to make the important ones visible: the problem, the users, the must-haves, the limits and the definition of done.
It also works as a filter. If you cannot fit the problem on one page, the project is probably several projects, and the cheapest first step is deciding which one comes first. Firms asked to quote against a vague wish list will either pad the price to cover the unknowns or guess. A clear page lets you compare quotes fairly, and our guide to what custom software development costs explains how scope drives price.
The one-page template
Copy these headings into a document and fill each one in plain sentences.
- The problem, in two or three sentences. What goes wrong today, who it affects, and what it costs you in time, money or missed work. Use numbers you measured, such as hours per week spent re-keying a registration list, not impressions.
- Who uses it. List each type of user: staff, volunteers, customers, vendors, an administrator. Each type is effectively another screen to design and test, so be honest about how many there really are.
- How the work happens today. The steps, in order, as they are really done. Ask three people who do the job to write their steps independently. If the versions differ, resolve that before building anything, because software makes one version permanent.
- The must-haves, as user stories. Five to ten, no more for a first phase (details below).
- Data and connections. What information the system holds, where it comes from today (spreadsheets, a payment processor, a mailing list), and which other tools it must talk to. Integrations are easy to underestimate, so list every one.
- Rules and limits. Hard facts: a date the system must be working by because an event or filing deadline depends on it, regulated data it will hold, accessibility needs, who must approve what.
- How we will know it worked. Two or three measurable outcomes, such as “volunteer sign-ups no longer need a staff member to re-enter them.”
- Out of scope. What this phase deliberately does not do. This section prevents more arguments than any other.
- Owner and open questions. The one named person who decides, and the questions still unanswered.
Writing user stories that work
A user story is a short sentence about what one kind of person needs and why. The Mountain Goat Software guide gives the common template: “As a [type of user], I [need/want/am required] to [do something], so that [reason or benefit].” The UK government's service manual uses the same three parts and calls the goal the most important one: it confirms you are solving the right problem, and if you struggle to write it, you should reconsider why you think you need that feature.
Examples for a small festival or nonprofit:
- As a vendor, I want to submit my application and payment online, so that I do not have to mail a paper form.
- As the coordinator, I want to see which applications are incomplete, so that I can follow up once instead of weekly.
- As a volunteer lead, I want to see who is signed up for each shift, so that I can spot gaps before the event.
Two habits make stories useful. First, add a short “it's done when” list. The service manual describes acceptance criteria as a checklist of outcomes that confirm the user need is met, often written that way. Second, treat the story as a reminder to talk, not a contract. The Mountain Goat guide says the sentence is a reminder to have a conversation, and the full requirement emerges through the conversation that follows. Anyone can write a story; what matters is who takes part in that conversation.
If a story would take more than a few weeks to build and test, the service manual calls it an epic and suggests splitting it into smaller stories. That advice fits small projects too.
What to leave out
A requirements page describes the problem and the outcome. It should not try to design the solution. Leave out:
- Technology choices. “Use React and a SQL database” is the developer's call, based on your needs and what they can maintain.
- Screen layouts and colors. Sketches are fine as illustration, but do not specify pixels before the stories are settled.
- Vague adjectives. “Modern,” “intuitive” and “user-friendly” cannot be tested. Replace them with a behavior: “a first-time vendor can finish an application without calling us.”
- The someday list. Park future ideas in a separate backlog. Mixing them in makes every feature look equally urgent.
- Competitor feature matrices. Copying everything a rival product does is the surest way to build the wrong thing.
- Things you have not decided. Put them under open questions. A guess written as a requirement becomes an expensive surprise.
Using the page with vendors and products
Send the same page to every firm you talk to, and to the vendors of any products you are considering. A product that meets your must-haves with settings alone should usually win, and our look at how to evaluate custom software companies shows what to ask next. If you are weighing outside help for the early analysis, see our small business automation consultant guide.
Ask each firm to price the smallest first phase that delivers real value, plus the questions they would want answered before starting. Firms that ask good questions about your page are telling you something useful about how they work.
The honest verdict
Write the page yourself if the project is small, the process is settled and you can name an owner. An hour on the template often reveals that a configurable product, or a change to your process, will do the job.
Get help when integrations, regulated data or several user types make the picture hard to see from inside. Early analysis is cheaper than a rebuilt first release.
Bring it to us when you have the page, or most of it. We will say plainly if a product fits better, and if a build is right we will start with a small, paid first phase. See our custom software for small business page for how that works.
Frequently Asked Questions
What should a software requirements document include?
For a small business, one page is enough: the problem and what it costs you, who will use the software, how the work happens today, five to ten must-have user stories, the data and other tools involved, hard rules and deadlines, how you will measure success, what is out of scope, and who owns decisions. Leave out technology choices, pixel-level designs and vague adjectives. A clear page lets any developer or vendor respond to the same question.
How do I write a user story?
Use three parts: who the user is, what they need to do, and why. A common form is “As a [type of user], I want to [do something], so that [benefit].” The benefit is the most important part because it shows whether you are solving the right problem. Add a short checklist of what must be true for the story to count as done, then discuss it with the people who will use it.
Do I need a requirements document before hiring a developer?
You do not need a formal one, but you do need your problem written down. A rough page lets you compare quotes fairly, helps a developer tell you honestly whether a product would fit, and exposes disagreements inside your team before they become paid change requests. If you cannot write it yourself, a good developer or consultant can help you draft it, ideally as a short paid first step.
What is the difference between requirements and specifications?
Requirements say what the business needs and why: the problem, users, outcomes and limits. Specifications say how the system will be built to meet them, including screens, data structures and technology. Owners should write requirements, and developers should propose specifications. When owners write specifications, such as exact layouts or tools, they often lock in a weaker solution before anyone has tested the real need.