How to Write a Software Requirements Document (With a Free Template)

The number one cause of software projects going over budget is unclear requirements. When developers have to guess, quotes vary wildly, features get rebuilt and timelines slip.

The good news: you do not need to be technical to write good requirements. You need to describe your business clearly. This guide shows you how, with a template you can copy.

Why requirements matter

A clear requirements document helps you:

• Get accurate, comparable quotes from different companies
• Prevent scope creep and surprise costs
• Keep everyone aligned on what "done" means
• Prioritise what goes into version one

The 8 sections of a great requirements document

1. Project overview

Two or three paragraphs: what the business does, the problem the software solves, and what success looks like.

Example: "We run 40 rental properties and manage bookings, rent and maintenance in spreadsheets. We want a system that tracks availability, collects rent, and logs maintenance requests, reducing admin time by half."

2. Goals and success metrics

Make them measurable where you can:

• Reduce manual data entry by 10 hours a week
• Respond to every enquiry within 15 minutes
• Let customers book and pay online

3. Users and roles

List every type of user and what they need to do.

4. Features (with priorities)

Group features by area and mark each Must have, Should have or Later.

5. User stories and workflows

Describe how people will use the system:

• "As a customer, I want to see available dates so I can book without calling."
• "As a manager, I want a daily list of overdue payments so I can follow up."

For key processes, list the steps: Enquiry → Quote → Approval → Booking → Payment → Confirmation.

6. Integrations and data

• Systems to connect: payment gateway, accounting software, WhatsApp, email, maps
• Existing data to import: spreadsheets, old systems
• Reports and exports you need

7. Non-functional requirements

• Platforms: web, iOS, Android
• Users: how many now, how many in two years
• Security: logins, permissions, data sensitivity
• Performance: page speed expectations
• Languages and currencies
• Hosting preferences

8. Constraints

Budget range, deadline, must-use technologies, compliance needs, and anything explicitly out of scope.

Tips for writing better requirements

• Describe problems, not just solutions. "Staff forget renewals" is more useful than "add a bell icon".
• Use real examples: screenshots of tools you like, sample reports, existing spreadsheets.
• Define priorities honestly. Not everything can be a must-have.
• Mark unknowns. It is fine to say "not sure yet"; a good partner will help you decide.
• Keep it a living document and update it as decisions are made.

A worked example

Vague requirement:

"We need a system to manage our orders."

The same requirement, written usefully:

Problem: Orders arrive by phone, WhatsApp and email. Our team copies them into a spreadsheet, then again into invoices. We lose orders and make pricing mistakes.

Users: 2 office staff (create and edit orders), 1 manager (pricing, reports), 6 delivery staff (view today's deliveries, mark delivered).

Must have: create an order with customer, items, quantity and price; automatic price from a price list with customer-specific rates; generate an invoice PDF; a delivery list for each day; mark delivered with a photo; daily sales report.

Should have: WhatsApp the invoice to the customer; low-stock alerts.

Later: customer self-service ordering.

Volume: about 60 orders a day, 400 customers, 200 products.

The second version can be quoted accurately. The first cannot.

Write user stories that developers can build

A good user story names who, what and why:

• "As office staff, I want the price to fill in automatically from the customer's rate list, so I stop making pricing mistakes."
• "As a manager, I want to see yesterday's sales by salesperson, so I can review targets each morning."
• "As delivery staff, I want today's deliveries in order of route, so I do not waste time."

Add acceptance criteria so "done" is not a matter of opinion:

Given a customer with a special rate, when I add a product to their order, then the special rate is used, and the manager can override it with a reason.

Say what happens when things go wrong

Most missed requirements hide in the edge cases. For each key workflow, answer:

• What if the customer has no rate set?
• What if stock is insufficient?
• What if a payment fails halfway?
• Who can edit or cancel an order after it is confirmed, and is that recorded?
• What happens with a poor internet connection?
• Who receives an alert when something fails?

Numbers that shape the architecture

Give realistic figures. They decide the technical approach and the hosting cost:

• Users today, and in two years
• Records: customers, orders, products, documents
• Peak usage times (for example month-end)
• File sizes and storage (photos, PDFs, videos)
• Reporting periods needed (daily, monthly, yearly comparisons)

Copy-paste template

1. PROJECT OVERVIEW
   Business background:
   Problem to solve:
   What success looks like:

2. GOALS
   - 
   - 

3. USERS & ROLES
   Role | What they need to do

4. FEATURES
   Area | Feature | Priority (Must / Should / Later)

5. KEY WORKFLOWS
   Workflow name: step → step → step

6. INTEGRATIONS & DATA
   Systems to connect:
   Data to import:
   Reports needed:

7. NON-FUNCTIONAL
   Platforms:
   Number of users (now / 2 years):
   Security & privacy:
   Languages / currencies:

8. CONSTRAINTS
   Budget range:
   Target launch date:
   Out of scope:

What happens next

Share the document with two or three development companies and compare their questions as much as their prices. The best partners ask sharp questions that improve your plan. Use our checklist on how to choose a software development company.

Not sure where to start?

Our free quote form walks you through the key questions in about two minutes. Then we help you turn your answers into a clear scope with a fixed price. Explore our custom software development services.