Writing a software requirements document, often called a functional specification, means putting on paper what your software must do, for whom and why. Not yet how it works technically, but what a user does with it. It's your wish list, only so clear that a developer can give you a fair price and timeline based on it.
You don't need any IT knowledge for it. You know your business, your customers and your processes best. In this article you'll learn what belongs in a functional specification, how to write one step by step and which mistakes to avoid.
What exactly is a functional specification?
A functional specification (in Dutch often shortened to FO) describes how a system behaves from the user's point of view. Think of sentences like: a customer can log in and download their invoices, or an employee sees every morning which jobs are planned for today. The technical design comes after that and deals with databases, servers and code. You leave that to the developer.
It's sometimes also called a requirements specification or a list of functional requirements. The name doesn't matter much. What counts: everyone reads the same document and afterwards shares the same picture of the end result.
Why a wish list saves you money and hassle
Without a clear wish list, a developer guesses what you mean. That often goes wrong on the details, and it's exactly those details that take time. A good functional specification helps in a few ways:
- You get quotes you can really compare, because every supplier prices the same thing.
- You spot earlier where you still need to make choices, before any code is written.
- Changes halfway through get smaller, because the broad outlines are fixed.
- After delivery you have something to tick off against: does the system do what we agreed?
Also read how to compare web agency quotes. A functional specification is the foundation for that.
What belongs in a software requirements document?
A functional specification for a small or medium-sized project doesn't have to be a thick report. Five to fifteen pages is usually enough. These parts belong in it:
- Goal: which problem are you solving and how will you know it worked? For example: quotes in ten minutes instead of an hour.
- Users and roles: who will use it? Customer, employee, administrator. What can each role see and do?
- Features: what can each user do? Write this per screen or per task.
- Data: what information do you record? Customer name, address, order number, status, attachments.
- Integrations: which other systems must it talk to, such as your accounting, calendar or webshop?
- Screen sketches: simple drawings on paper or in a free tool are enough.
- Constraints: number of users, languages, privacy, accessibility and when it needs to be ready.
How to write a functional specification in six steps
You can write the functional specification in a few afternoons. Work in this order and it stays manageable.
- Step 1. Describe the current process. How does it work now, with which Excel lists, emails and phone calls? Also write down where it pinches.
- Step 2. Talk to the people who will use it. Colleagues and sometimes customers see things you miss.
- Step 3. Write user stories. These are short sentences in the form: as a [role] I want to [action], so that [goal]. For example: as a planner I want to drag a job to another day, so I can reshuffle quickly when someone is ill.
- Step 4. Set a priority for each wish. Use must, should, could and won't. Everything that's a must belongs in the first version.
- Step 5. Sketch the most important screens. Pen and paper is fine. It's about the content, not the colours.
- Step 6. Have it read by someone who wasn't involved. Does that person understand what the system does? Then it's clear enough.
Functional specification example: a simple customer portal
Say you run an installation company and want a portal where customers can see their maintenance appointments. Part of your functional specification could look like this:
- Goal: fewer phone calls about appointments and invoices.
- Roles: customer, technician, office.
- As a customer I want to see my next maintenance appointment, so I know when the technician is coming.
- As a customer I want to be able to move an appointment within the available times, so I don't have to call.
- As the office I want a notification for every rescheduled appointment, so the schedule is correct.
- As a customer I want to download my invoices as PDFs. Integration: accounting package.
- Priority: seeing appointments and invoices are must, rescheduling is should, a chat feature is won't for version 1.
As you can see: no technical words, but very concrete. Read more about this kind of project in the article on getting a customer portal built.
Common mistakes when writing functional requirements
Writing a functional specification isn't hard, but a few pitfalls come up again and again:
- Prescribing solutions instead of describing problems. Don't write: there must be a dropdown. Write: the user chooses from five fixed statuses.
- Everything is equally important. If everything is a must, the first version gets too big, too expensive and too late.
- Forgetting exceptions. What happens if a customer has two addresses, or a payment fails?
- Staying too vague. User-friendly and fast aren't requirements. Describe instead what someone must be able to do in how many clicks.
- Not updating the document after the start. A functional specification is a living document. Change it when you decide something different together.
Do you have to write the requirements document yourself?
Not necessarily. You bring the knowledge of your business; the developer helps turn it into clear functional requirements. For smaller projects, a good conversation plus a short wish list is often enough. For larger systems it pays to work out the design together before the build starts. Read how the rest of that process goes in how software development works.
Still unsure whether you need custom work at all? Then it helps to first check whether custom or an off-the-shelf package fits better. That choice is also easier with a wish list on paper.
How we work with your wish list at Violexa
At Violexa we start every software project with your wishes, in plain language. Hisham walks through your process with you, asks the questions you may not have thought of yet and turns it into a clear plan with priorities. So you know up front what you'll get. Larger projects get a fixed price up front, in writing.
A custom web application with us starts from €1,799 excl. VAT (€2,177 incl. VAT) per project, including design, development, a design that works on every screen and training. What your project costs depends on what's on your wish list.
Want your wish list reviewed? Book a free quickscan. In 30 minutes, online or on site, we discuss your plan. Afterwards you get short written advice with a price indication, with no obligation.
Frequently asked questions
How do you write a functional specification?
Start with the goal and the people who will use the system. Then describe per role what someone must be able to do, ideally as short user stories. Give each wish a priority and make simple sketches of the most important screens.
What is the difference between a functional and a technical design?
A functional design describes what the system does from the user's point of view. A technical design describes how it's built, with databases, servers and code. As the client, you mainly help write the functional part.
How long should a functional specification be?
For a small or medium-sized project, five to fifteen pages is usually enough. Length isn't the goal. It must be clear enough that someone who wasn't involved understands what the system has to do.
What are user stories?
User stories are short sentences that describe a wish from the user's point of view: as a [role] I want to [action], so that [goal]. They help you focus on what someone wants to achieve, rather than on technical solutions.
