A business requirements document template for software

Direct answer

A requirements document records what must be true when the software is finished, not how it will be built. It gives a vendor something to price, gives your team something to review, and gives everyone something to test against at the end. It does not need to be long: clarity beats volume. The outline below has eight parts. Fill each in plain language, mark what you do not yet know as an open question, and keep technology choices out unless there is a real constraint. Wording here is business guidance only and is not legal wording; if the document will become part of a contract, have the contract reviewed by a qualified professional. For the constraints that are easy to forget, pair it with the non-functional requirements checklist.

1. Purpose and background

Two or three short paragraphs. State the problem in the words of the people who have it, what currently happens, and why it needs to change. Then state what a good outcome looks like and how you will recognise it. Avoid describing screens here; describe the situation. A reader who has never worked at your company should understand why the project exists after this section.

2. Stakeholders

List every group affected and one named contact for each:

• The decision-maker who signs off requirements and resolves disagreements
• The daily users, by role, not by individual
• The people who administer connected systems
• Anyone who receives outputs such as reports, invoices or notifications
• Anyone who must be consulted for compliance or policy reasons

3. Business rules

Business rules are statements that are true regardless of the software: who may approve what, when a record counts as closed, what makes two records duplicates, how exceptions are handled. Write each as a single sentence and give it a number so it can be referenced. These are where projects most often go wrong, because people apply them from memory and differently. If two people cannot agree on a rule, that is a finding worth having early.

4. Functional requirements

Functional requirements describe what the system must let people do. Write each as a short statement using the same pattern, for example 'A sales manager can reassign a record to another owner.' Group them by area, number them, and add a priority such as must, should or later, defined by you. Avoid vague verbs like 'support' or 'handle'. If you cannot imagine a test for a requirement, rewrite it until you can.

5. User stories

User stories are optional but helpful for showing intent. The usual shape is: as a role, I want an action, so that a reason. The reason is the valuable part; it lets a builder propose a better way than the one you imagined. Use stories for the main journeys, and keep the numbered functional requirements as the checklist for completeness.

6. Data and reports

Describe the main records, the fields each needs, which are required, and where the data comes from. List every report or export people need, who reads it, how often, and what decision it supports. Say which existing data must be carried over and how tidy you believe it is. A rough table with headings for record, fields, source and owner is enough. If a number on a report must match another system, name that system.

7. Out of scope

This short list prevents more arguments than any other. Write down things a reader might reasonably assume are included but are not: other departments, a mobile app, historical data older than a date you choose, integrations you will add later. If you find the list is empty, you have not thought about it yet.

8. Open questions and sign-off

Keep a running list of unanswered questions, each with an owner and a date by which it must be answered. At the end, record who approved the document and on which version. When something changes later, add a dated note rather than editing silently; the change request process covers this. Sign-off does not freeze thinking; it gives a reference point so that changes are visible.

Common mistakes

Watch for these when reviewing your own draft:

• Describing a solution ('a dropdown here') instead of a need
• Requirements that cannot be tested
• Rules that only one person knows
• A missing out-of-scope list
• Combining several requirements in one sentence
• No named owner for open questions