Software Requirements Document: A Plain-English Guide for Owners

"So, walk me through it. A customer calls. What happens next?"

That's usually the first real question in a software meeting, and it's remarkable how many sharp, successful owners go quiet for a second. Not because they don't know their business. They know it cold. It's just that nobody has ever asked them to say it out loud, step by step, in order, with the odd exceptions included.

That's what a software requirements document is for. The name sounds like something an engineer produces in a windowless room. It isn't. At its best it's a plain description of how your business works and what you want the software to do about it, written by the person who knows the business best. You.

This guide is for owners who don't write code and don't want to. You'll get a simple outline you can copy, some questions to answer along the way, and a handful of mistakes to avoid. It won't take you a month. An honest first draft can be a long afternoon.

What a software requirements document actually is

Strip away the jargon and it's a shared description. It answers four questions for whoever is going to build the thing:

• Who will use this, and what are they trying to get done?
• What happens, step by step, in the work this software touches?
• What rules does the business follow that the software has to respect?
• How will we know it's finished and working?

That's all. It isn't a design, and it doesn't say what technology to use. Those are the builder's decisions. Your job is to describe the problem and the business, not to solve it with code.

Think of it like briefing a contractor on a kitchen remodel. You don't tell them which saw to use. You tell them who cooks, how many people are in the house, what annoys you about the current layout, and that the dog needs to stay out of the pantry. The better that brief, the less they have to guess, and the fewer expensive surprises show up once the cabinets are in.

Why it saves you money (and arguments)

Most trouble in software projects traces back to something that was assumed instead of said. The builder assumed invoices were per project, and you meant per milestone. You assumed "client login" included a place to upload files, and it didn't, because no one wrote it down.

A written description pays off in a few specific ways:

• Quotes become comparable. If three builders quote the same written description, you can see what differs. If each hears a different story, you're comparing three different projects.
• Scope gets clear. A shared document makes "is this included?" a question with an answer, not a negotiation.
• You find out what you don't know. Half the value is noticing the gaps. Better to find them on paper than halfway through a build.

Cost is driven by scope, so clarity about scope is clarity about cost. Our Price Guide explains what moves the number on a custom build. A good requirements document gives each of those drivers a straight answer.

Start with the people

Begin with who. Software is only useful to people, and "everyone" is not a useful answer.

List every kind of person who will touch the system. Not individuals, roles. For a typical small business that might be: you, the office manager, field staff, a bookkeeper who sees only the money side, and clients. For each role, write two or three lines:

• What do they need to get done?
• What should they be able to see?
• What should they not be able to see or change?

That last question matters more than people expect. A contractor shouldn't see your margins. A client shouldn't see another client's files. Writing down who can do what is the foundation for privacy and security, and it's hard to bolt on later.

Be specific about the pain too. "Staff find it annoying" isn't a requirement. "Our scheduler retypes every job into a spreadsheet after getting the email" is. The specific version tells a builder exactly where the time goes.

Then describe the work

Now the part you were asked about in the meeting: what happens, in order.

Pick one important process and walk through it as a story. Start with the trigger, the thing that kicks it off, and follow it to the end. A new request arrives. Who sees it first? What do they check? Where does the information get recorded? Who gets told? When does money change hands? What's the last step that says "this one's done"?

Write it as plain numbered steps. It doesn't need to be pretty:

1. Customer emails or calls with a request.
2. Office manager logs it in the shared sheet with name, address and what they want.
3. Owner reviews it and sets a price, usually the same day.
4. Quote goes out by email. If no answer in three days, office manager follows up.
5. Once accepted, a crew gets assigned and the job goes on the calendar.

Then, and this is the part people skip, write the exceptions. What happens when the customer changes their mind? When the crew can't make it? When a job is half done and the scope changes? Exceptions are where generic tools fall over and where custom software earns its keep. They're also where most of the surprise cost lives, so the more you name now, the better.

Do this for your top three to five processes, not all of them. If you're wondering which to choose, pick the ones that eat the most time or cause the most mistakes. We cover how to find those in our article on how to replace spreadsheets with software.

Write down the rules

Every business has rules, and half of them live in somebody's head. Software can follow rules perfectly, but only once someone has said what they are.

Rules sound like this:

• "Any quote over a certain size needs the owner's sign-off."
• "Deposits are due before we order materials."
• "We never schedule two crews at the same address on the same day."
• "Clients on the monthly plan get invoiced on the first; everyone else on completion."
• "If a payment is more than two weeks late, we pause new work."

Write yours in "if this, then that" sentences. Try to catch the ones you do automatically, without thinking. A useful trick: ask the person who's been with you longest, "What's something we always do that a new hire would get wrong?" The answers are usually rules nobody wrote down.

It's okay if some rules are fuzzy. "I use my judgment" is a legitimate entry, and a builder can plan for a human decision point. What you don't want is for a fuzzy rule to look like a clear one, because the software will treat it as clear.

Describe the information

Next, the data. This is the part owners fear most, and it's much simpler than it sounds. You're not designing a database. You're listing the things you keep track of and what you need to know about each.

For a service business that might read:

• Customer: name, phone, email, billing address, how they found us, notes.
• Job: address, type of work, status, assigned crew, price, dates.
• Invoice: amount, date sent, date paid, which job it belongs to.

Then note how they connect. A customer has many jobs. A job has one or more invoices. If you can say that in a sentence, you've done the hard part.

Add two things most people forget. First, where the information lives today: which spreadsheet, which app, which inbox. If you're moving off existing tools, someone will need to bring that data across, and the messier it is, the more careful the plan needs to be. Second, what needs to stay. Some records you have to keep for tax or legal reasons, and a good builder will want to know before deciding how to store them.

If you use other tools that should keep working alongside the new system, list those too. Each one is worth knowing about early.

Define what "done" looks like

This is the section that saves friendships.

"Done" isn't "it feels finished." It's a short list of things you will be able to do, on a given day, that you can't do now. Write it in the form "I can ___" for each role:

• "As the office manager, I can log a new job once and see it on the calendar without retyping."
• "As the owner, I can see everything waiting for my approval on one screen."
• "As a client, I can check where my project stands without emailing anyone."

Then add the practical conditions: how many people will use it at once, what devices they use (phones in the field, or desks only), how fast it needs to feel, and what must never be lost.

Include what is not part of this first version. A short "later, not now" list is one of the healthiest things a project can have. It keeps phase one small enough to finish, and it makes sure good ideas aren't lost, just scheduled.

If you want a reference on writing clearly for the people who'll use something, the Nielsen Norman Group publishes plain, research-based writing on how people actually use software and what trips them up.

A simple outline you can copy

Here's the whole thing on one page. Copy it into a document and fill in what you know. Leave the rest blank or write "not sure."

Notice what's missing: technology, screens and features. That's deliberate. If you describe the people, work, rules and information well, the features mostly write themselves, and a good builder will propose them. Do attach messy extras: a photo of the whiteboard, a sample invoice, a screenshot of the spreadsheet you hate. Real examples beat polish.

Mistakes to avoid

A few patterns show up often enough to name:

• Writing a feature list instead of a story. "Needs a calendar, a chat, an invoice screen" tells a builder very little. "The scheduler double-books because the calendar and the job list don't agree" tells them everything.
• Describing the process you wish you had. Write what happens today first, even if it's embarrassing. Improvements come next, and they're easier to spot once the real thing is on paper.
• Making it perfect before sharing it. An 80% draft shared early beats a polished one that took a month. The conversation fills the gaps.
• Leaving out the people who do the work. Show your draft to whoever actually does the job. They'll find three things you missed in ten minutes.

And one more, which is about the decision before this one. If you haven't yet worked out whether to build at all, start with our build vs buy software framework. A requirements document is the right next step once the answer leans toward building.

What happens next

Once you've got a draft, even a rough one, you're ready for the useful conversation. That's what a discovery call is for. You bring your notes, we ask questions about the gaps, and we tell you honestly whether what you describe needs custom software or a well-chosen subscription.

If it does lead to a project, our process shows how we move from that first conversation to a fixed scope, a plan and the build itself. Your document becomes the backbone of it, getting sharper with each round, and the version you end up with is usually a lot better than the one you started with.

So set aside an afternoon. Grab a coffee, open a blank page, and start with the question from the top of this article: a customer calls. What happens next?