A software specification explains what a new system must do. It names the users and the proof needed at the end. A useful spec starts with the business problem. It turns real user needs into clear tests. That gives each supplier the same job to quote.
You do not need to design the database or choose the programming language. That is the developer's job. For bespoke software development, you need to explain the work, the rules and the result you expect.
What is a software specification?
A software specification is the agreed plan for a system. It records the goals, users, tasks, data, rules and limits that matter. It should also say how each key need will be tested.
The document may be called a software requirements specification (SRS), a functional spec or a project brief. The name matters less than the content.
ISO/IEC/IEEE 29148:2018 is the current global standard for this work. It covers how teams record and manage system needs. ISO confirmed the 2018 edition in 2024. A new edition is now in progress. Check the official record when a contract names the standard.
Most small firms do not need a brief written to the full standard. Its main lesson still applies. Each need requires a clear form, an owner and a way to test it.
Start with the business problem
Write one short paragraph about what happens now. Name the people involved, the task they are trying to finish and where the process breaks. Add the effect on customers or staff.
Use evidence where you have it. Support tickets, failed handovers, duplicate records and manual checks all help. Avoid made-up savings or targets. If you do not have a number, describe the event instead.
The GOV.UK Service Manual says user needs should come from research rather than opinion. It also says they should focus on the user's problem, not a chosen answer. That approach works just as well for a private business system.
Write a clear outcome
State what should be different when the software works. Keep it broad enough to allow a good technical answer. For example:
Customer service staff need one current order record. They must see payment, delivery and contact history without checking three other systems.
This goal gives the project a clear path. Later needs can be checked against it. If a feature does not help, ask why it is in the build.
List the users and their permissions
A system rarely has one kind of user. Sales staff, finance staff, managers, customers and support teams see different data. They may also take different actions.
List each user group. Write what they need to see, create, change, approve and export. Include people who support the system as well as the main users. Add outside users such as customers or suppliers when they have access.
| User | View | Change | Approve | Export |
|---|---|---|---|---|
| Sales adviser | Own leads and customer records | Contact notes and quote details | No | No |
| Sales manager | All sales records | Team assignments | Discounts above the set limit | Sales reports |
| Finance user | Orders and payment status | Invoice references | Refund requests | Finance reports |
| System administrator | All records needed for support | Users, roles and settings | Access requests | Audit records |
This is only an example. Your matrix should use your real job roles and approval rules. It should also record what users must never see or change.
Map the work as it happens now
Walk through a normal job from start to finish. Do it with the staff who handle the task. Managers often know the stated route. Staff know the short cuts, odd cases and missing data.
Record each trigger, decision, handover and result. Mark where a person copies data, waits for approval or leaves the system to finish the job. Include the awkward cases. Returns, credit holds, missing documents and cancelled orders often expose more than the happy path.
The process map does not need special software. A list or clear chart is enough. Give every step an owner. Note the data that enters and leaves it.
Use this annotated requirements template
The Teal Book needs chapter was updated on 1 July 2026. It says each need should have an ID, notes, type, version, author, risk, rank and owner. The plan below adapts that idea for business software.
- Problem and outcome. Explain what fails now and what a good result changes.
- Scope. Name the teams, tasks and locations included. State what is outside the first release.
- Users and access. List each user group and its permissions.
- Workflows. Describe the main tasks, decisions, approvals and exceptions.
- Functional requirements. State what users must be able to do.
- Data. List the records, key fields, ownership, retention and any data that must move from an old system.
- Integrations. Name each system that must send or receive data. Record the event, direction and error response.
- Quality requirements. Cover speed, availability, accessibility, browser support, capacity and recovery where they matter.
- Security and privacy. Record sensitive data, access rules, audit needs, login controls and legal duties.
- Acceptance criteria. Define the evidence that will prove each requirement is met.
- Priority and owner. Give each item a named decision owner and a clear release priority.
- Open questions. Keep unknowns visible. Add an owner and a decision date rather than hiding an assumption in the text.
Give every need a short ID such as ORD-014 or SEC-006. IDs make reviews and change requests much clearer than phrases such as "the reporting bit".
Write requirements that can be tested
Words such as easy, fast, flexible and secure sound useful. They cannot be signed off. Replace them with a result people can see and the rules around it.
| Vague | Testable example | What changed |
|---|---|---|
| The system should be fast. | For the agreed test data, 95% of signed-in dashboard requests complete within two seconds. | The page, test data, measure and threshold are named. |
| Search must be easy. | A service user can find an order by number, customer name or postcode and open it without changing screens. | The user, inputs and result are clear. |
| The system must be secure. | Privileged accounts require multi-factor authentication. Users cannot view records outside their assigned role. | Two security controls can be checked. |
| Reports should be flexible. | A manager can filter the order report by status, owner and date, then export the filtered rows as CSV. | The allowed actions and output are named. |
The figures above are examples, not set targets. Agree tests that fit your users, risk and working needs.
Give each requirement acceptance criteria
Pass rules describe the proof. A simple format is:
- Given a known starting point;
- when the user takes an action;
- then the system produces an observable result.
For example: "Given an order is awaiting approval, when a sales manager approves it, then the status changes to approved. The audit history records the manager, date and time."
Add failure cases too. What happens when the user lacks access, a system link is down or key data is missing? A good spec defines the safe result, not just the successful one. Use our UAT guide to turn those results into launch checks.
Record data, integrations and security
Data questions can change the shape of a project. List the sources you trust and the records that need cleaning. Name the people who may fix them. State which system owns each key fact. If two systems can change the same field, say which one wins.
For every system link, record what starts the swap and which way data moves. State how often it runs. Say what staff should see when the other system fails. An API link that fails in silence can leave staff using old data.
Add non-functional requirements
Some needs describe what the software does. Others set the rules around it. They cover speed, access, trust, support and other quality limits.
Name each outside system and link. State how fast a common task should respond under an agreed load. Record the browsers, devices and work settings that matter. Include the notes and reports staff need after launch.
Security belongs in the brief. The NCSC Software Security Code guide says teams should record their needs. It also calls for security tests, threat checks, strong login controls, input checks and safe storage of private data.
Do not paste passwords, access keys or real customer data into the brief. Share secrets through a safe channel once the project needs them.
Set priorities without hiding dependencies
Mark each need as must, should, could or not in the first release. Use the labels in the same way each time.
| Priority | Meaning | Question to ask |
|---|---|---|
| Must | The release cannot meet its agreed outcome without it. | What stops if this is absent? |
| Should | Important, but there is an acceptable short-term route around it. | What is the temporary workaround? |
| Could | Useful when it fits without putting must items at risk. | Which user need does it support? |
| Not in this release | Kept for later review, with no promise that it will be built. | What must change before this is reconsidered? |
One task may rely on another. That can move it up the build order without adding more value. For example, access rules may be needed before a manager can approve work. Record both the rank and the link.
Prepare the same quote pack for every supplier
Give each supplier the same version of the brief. Include the process map, access table, sample files and known limits. Remove real personal data first.
Ask suppliers to state what they assume and leave out. A quote may look complete but use a different meaning for "system link", "data move" or "support". Clear notes make quotes easier to compare.
Keep a question log. Share key answers with every supplier still involved. This stops one supplier quoting with better facts than another.
The brief will change as people learn. That is normal. Keep a version number and a short change log. Once work starts, link each agreed change to the need it affects. The bespoke software page shows how an agreed scope becomes a build.
Software specification checklist
Use this list before you send the brief out.
- The problem is clear before any product or feature list.
- The expected business outcome is written in plain English.
- Real users helped describe the current process.
- Each user group has clear view, change and approval rights.
- The main workflow includes decisions, handovers and exceptions.
- Every requirement has an ID, owner and priority.
- Vague words have been replaced with observable results.
- Acceptance criteria cover success and failure cases.
- Data sources, ownership, retention and migration needs are known.
- Each integration has a trigger, direction and failure response.
- Security and privacy needs are part of the scope.
- Accessibility, browser and device needs are stated.
- Dependencies and open questions are visible.
- Sample files contain no real secrets or personal data.
- Every supplier receives the same version and question answers.
A good brief makes the job easier to question, quote, build and test. It does not need to predict every screen. It gives the buyer and build team one clear view of the problem.
If the work is spread across notes, sheets and staff memory, start there. Show us how the work happens now. We can turn it into a scope a build team can test.
Sources and standards
These sources were checked on 22 July 2026.
- ISO/IEC/IEEE 29148:2018: requirements engineering processes and information across the system life cycle. ISO confirmed this edition in 2024 and lists a replacement as under development.
- GOV.UK Service Manual: learning about users and their needs: user needs should come from evidence. They should focus on the problem rather than a chosen answer.
- The Teal Book, Chapter 31: requirements ownership, registers, priority, traceability, approval and validation. Updated 1 July 2026.
- NCSC Software Security Code implementation guidance: recorded requirements, secure design, security testing, authentication, input checks and sensitive-data protection.
