How to write a software requirements document (with a template)

Requirements are the most common reason software projects miss their goals. What a good requirements document does, the tools people use to write one, and a section-by-section template you can copy.

A software requirements document describes what a piece of software must do, for whom, and why, clearly enough that a builder can price it and you can check the result. You'll also see it called a product requirements document (PRD), a specification or a brief. You don't need to be technical to write a good one. You need to describe your business clearly, and this guide includes a template that walks you through it.

What the research says about requirements

• Requirements are the most common reason projects miss their goals. PMI's 2014 Pulse of the Profession in-depth report, based on a survey of more than 2,000 practitioners, found that when projects don't meet their original goals and business objectives, inaccurate requirements management is the primary cause almost half of the time (47%). (PMI)
• Communication problems hit requirements hardest. In the same report, three in four organisations that named poor communication as a primary cause of failure said it hurt requirements management. (PMI)
• The cost of getting it wrong is lopsided. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects. The average cost overrun was 27%, but one in six was a "black swan", with an average cost overrun of 200% and a schedule overrun of almost 70%. (Flyvbjerg and Budzier, Harvard Business Review / arXiv) A clear, shared understanding of what's being built is one of the cheapest protections against becoming one of them.

What a good requirements document does

1. Explains the problem, not just the solution, so the builder can suggest better ways to solve it.
2. Describes how work happens today, including the tools, the handoffs and the workarounds.
3. Names the users and what each kind of user needs to do.
4. Lists what the software must do, in plain language, with examples.
5. States the rules: calculations, approvals, permissions and limits.
6. Lists the connections to other systems, and the data involved.
7. Defines "done": how you'll know it works.
8. Says what's not included in this version.

The most useful requirements documents are short and specific. Ten clear pages beat fifty vague ones.

The tools people use to write requirements

Documents: Google Docs, Microsoft Word and Notion

How they work: a shared document, often from a template. Notion and Confluence both offer PRD templates that structure the sections for you.

Where they shine: easy to write, comment on and share, with no learning curve.

Where they stop: they're static. They drift from reality as decisions are made in meetings and email, unless someone keeps them up to date.

Backlog tools: Jira, Linear and Trello

How they work: requirements are broken into "user stories" or tickets, such as "As a dispatcher, I want to see today's jobs on a map so I can assign the nearest engineer", which the development team works through.

Where they shine: turning agreed requirements into trackable work.

Where they stop: a list of tickets is hard to read as a whole. Business owners lose the big picture, so it works best alongside a short overview document.

Sketches and prototypes: paper, Figma and clickable prototypes

How they work: rough drawings of the screens, or a clickable prototype you can try before anything is built. AI tools now make quick prototypes much cheaper.

Where they shine: catching misunderstandings early. People react to a screen far better than to a paragraph.

Where they stop: a prototype shows the screens, not the rules, data and connections behind them. Those still need writing down.

AI writing assistants

How they work: tools like ChatGPT or Claude can turn rough notes into a structured draft.

Where they shine: getting past the blank page, and spotting missing sections.

Where they stop: they'll confidently fill gaps with plausible guesses. Only you know how your business actually works, so treat their draft as a checklist, not an answer.

The requirements document template

Copy these sections into a document and fill them in. Short answers are fine.

1. Summary

• The problem, in two or three sentences. What's going wrong today, and what it costs.
• The goal of this version, in one sentence. For example: "Replace the job spreadsheet so dispatchers can assign and track every job in one place."
• How we'll measure success. For example: "Invoices go out within one day of job completion", or "No more double entry between the CRM and Xero."

2. How it works today

• The steps, from start to finish, as a numbered list.
• The tools used at each step, including spreadsheets, email and paper.
• Where it goes wrong: delays, errors and retyping.
• Attach real examples: a filled-in form, a typical email, a screenshot of the spreadsheet with private data removed.

3. Users

For each kind of user, such as staff, managers, customers or suppliers:

• Who they are and roughly how many.
• What they need to do, as a short list.
• What they must not see or change.
• Where they'll use it: desk, phone, on site, with poor signal.

4. What it must do

Write each requirement as a short sentence, with an example where you can. Group them by the user or step they belong to. Mark each one as:

• Must have: the first version is useless without it.
• Should have: important, but could wait a few weeks.
• Could have: nice to have, if time allows.

For example: "Must have: a dispatcher can assign a job to an engineer, and the engineer gets a notification on their phone."

5. Rules

• Calculations: prices, discounts, tax, commissions and how each is worked out, with a worked example.
• Approvals: who must approve what, and at what limits.
• Validation: what must be filled in and which values are allowed.
• Edge cases: cancellations, refunds, partial deliveries, public holidays, whatever is unusual in your business.

6. Connections and data

• Systems it must connect to, such as accounting, CRM, email, calendar or payment provider, and what information flows each way.
• Existing data to bring across: where it lives today, roughly how much, and how clean it is.
• Reports and exports you need.

7. Constraints

• Deadline, and why. A real event or just a preference?
• Budget range, even a rough one, so the builder can propose a sensible first version.
• Compliance: data protection, industry rules, data location.
• Preferences: hosting, existing tools you want to keep, accessibility needs.

8. Not in this version

A short list of things you're deliberately leaving out. This is one of the most valuable sections, because it stops the scope growing quietly.

9. After launch

• Who will look after it: hosting, fixes, updates, small changes.
• Who owns the code and data.
• Training the team will need.

Common mistakes

• Describing a solution instead of the problem. "We need a mobile app" is a solution. "Engineers can't see job details on site" is the problem, and there may be a simpler answer.
• Leaving out the boring parts. Permissions, data import and edge cases are where projects grow.
• No examples. One real example is worth a page of description.
• Writing it alone. Ask the people who do the work. They know the workarounds.
• Treating it as final. It should be revised after the first conversation with a builder and after the first prototype.

How we turn requirements into software at Lephlo

You don't need a perfect document to talk to us. Many clients arrive with a page of notes and a spreadsheet. In our free consultation we walk through how the work happens today, and for clear projects we send a fixed price for the agreed scope. For bigger or less certain projects, we suggest a short, paid Scoping Sprint that produces a clickable prototype, a written build plan and a fixed price.

We build internal tools, customer portals and integrations that connect to the tools you already use. That's why the "how it works today" and "connections" sections above matter so much. You own the code, fixes are free during the fix period after launch, and we stay on hand as it grows.

Our free Build Scope Planner asks the same questions as this template and suggests a sensible first version. Related reading: what an MVP is in software and how much custom software costs. When you're ready, book a free consultation.

Frequently asked questions

What is the difference between a PRD and a software requirements specification? A product requirements document focuses on what the product must do and why, from the user's point of view. A software requirements specification (SRS) is usually more technical and detailed. For most small business projects, a clear PRD-style document is enough.

How long should a requirements document be? As short as it can be while still being clear. For a focused first version, five to fifteen pages, plus examples, is typical.

Should I write requirements before talking to a developer? Write down what you know, especially how the work happens today and what's going wrong, then refine it with your builder. A good builder will ask questions that improve it.

What are user stories? Short requirements written from a user's point of view: "As a [kind of user], I want [to do something] so that [reason]." They're useful for planning work, but work best alongside an overview document.

Sources

• Project Management Institute, Pulse of the Profession In-Depth Report: Requirements Management (2014)
• Bent Flyvbjerg and Alexander Budzier, Why Your IT Project May Be Riskier Than You Think, Harvard Business Review (2011)