Software requirements specification template: from idea to fixed price

A requirements specification is the document that turns an idea into something a supplier can price. Without it you get quotes that cannot be compared and projects where everyone thought they agreed. With it you get comparable prices, fewer surprises and a shared answer to the question “are we done?”. The template below is the one we wish every client sent us.

Template: the eight blocks of a requirements specification

1. Goal and objectives: What problem does the system solve, and how will you measure whether it works? For example “halve the time spent on bookings”.
2. Users and roles: Who uses the system, and what can each role see and do? For example customer, employee and administrator.
3. User stories: What does each role need to do? Write one sentence per need.
4. Priorities (must, should, could): What goes into version one, what is wanted, and what can wait?
5. Integrations: Which systems must the solution talk to, such as e-conomic, MobilePay, MitID or your CRM?
6. Data: What data exists today, where does it live, and does it need migrating?
7. Non-functional requirements: GDPR, security, login, performance, accessibility and which devices must be supported.
8. Acceptance criteria: How will you know a feature is finished and works as agreed?

Example: a requirements specification for a booking system

How do you write good user stories?

Use the form “As a [role] I want to [action] so that [benefit]”. The benefit is the most important part, because it tells the supplier why the feature exists, and often opens the door to a simpler solution than the one you had in mind. Write 20 short user stories rather than five long ones. Each story should be testable with an acceptance criterion, such as “once the customer has paid, the booking shows as paid in the admin panel”. Group your user stories by role, so it is easy to see whether a user has been forgotten, and whether the administrator has the tools needed to look after the system day to day.

Who should write the requirements specification?

The person who knows the workflow best, not necessarily the most technical one. Often it is the owner, an operations lead or the employee who keeps the spreadsheet alive today. Talk to the people who will use the system every day before you write: what takes time, what goes wrong, and what do customers ask about? You do not need to know the technical answers. Translating your needs into features, integrations and a price is the supplier’s job.

The most common mistakes in a requirements specification

• Describing the solution instead of the problem, such as “a button top right” instead of “the customer must be able to cancel”.
• Making everything a must-have. Then there is no prioritisation and version one gets too big.
• Forgetting the administrator. Someone has to manage users, content and data behind the screens.
• Skipping the integrations. They are often the single biggest item in the project.
• Writing 40 pages nobody reads. Short and precise beats long and exhaustive.
• Leaving out acceptance criteria, so “done” becomes a matter of opinion.

If you are unsure how the screens should fit together, a clickable prototype is often a better specification than text. At Grundfos we used field research and clickable prototypes to make the customer portals concrete before they were built. If you are still deciding whether to build or buy, read custom software vs off-the-shelf.

From requirements specification to a fixed-price proposal

Because the packages have a set number of features and integrations, a good specification translates directly into a price. Small is DKK 18,000 plus DKK 600 a month, Medium DKK 36,000 plus DKK 900 and Large DKK 54,000 plus DKK 1,200. Read why we prefer fixed price over hourly billing, or see all pricing.

Have a specification, a draft or just an idea? Send it to us and we will come back with questions and a written fixed-price proposal within 24 hours.