A functional design describes what custom software must do for the people who use it: which processes it supports, which users and permissions exist, which data, screens, rules, and integrations are needed, and when a feature counts as done. How the system is built belongs in the technical design. A good functional design is short, testable, and evolves with the project.
The effort pays off. The Project Management Institute (PMI) surveyed more than 2,000 project practitioners in 2014. When projects missed their goals, poor requirements management was the primary cause 47% of the time. The same report found that 5.1% of every dollar spent on projects was wasted through poor requirements management, or US$51 million for every US$1 billion.
This guide covers what goes into a functional design, how much detail you need when you work agile, who writes it, and how it carries through to acceptance testing. A complete template follows further down.
What a functional design covers
A functional design (often called a functional specification) captures the behavior of the software from the point of view of the user and the business process. A project manager, an end user, and a tester should all be able to read it without knowing how to code. Every requirement in it is written so you can later check whether the software meets it.
That last property comes straight from the international standard for requirements, ISO/IEC/IEEE 29148. Among other things, it describes a good requirement as unambiguous, complete, consistent, and verifiable. "The system must be fast" doesn't meet that bar. "A search by order number shows the result within two seconds" does.
Teams often confuse the functional design with two other documents. Each one answers a different question:
| Document | Answers | Example | Readers |
|---|---|---|---|
| Functional design | What the system does and under which rules | Any application above a set amount goes to a second reviewer | Client, users, developers, testers |
| Technical design | How it's built | Data model, architecture, APIs, application hosting | Developers and architects |
| User story | Which slice of value we deliver this sprint | As a reviewer, I want to see applications above the threshold separately so I can handle them first | The Scrum team |
User stories and a functional design work together. A story is a small, plannable unit of work. The functional design holds the big picture: the rules that apply across all stories, the roles, and how the processes connect. Without it, that knowledge ends up scattered over hundreds of tickets nobody can take in at once.
How much detail a functional design needs in agile projects
Agile teams are sometimes wary of design documents. That wariness traces back to the Manifesto for Agile Software Development from 2001:
"Working software over comprehensive documentation." Manifesto for Agile Software Development
The authors add right after that there is value in the items on the right as well. Documentation belongs in the process as long as it serves working software.
A workable split for agile projects looks like this:
- Up front: goal and scope, roles and permissions, the main processes, the data model in outline, integrations, and requirements for performance and security. These choices are expensive to reverse later.
- Per sprint: screen details, copy, exceptions, and the acceptance criteria for upcoming stories.
- After each sprint: update what's been built and approved, so the document reflects how the system actually works.
For a first release with a small scope, such as an MVP, a functional design of a handful of pages is often enough. It needs to capture the decisions the team can't make without you.
Who writes the functional design
The writing usually falls to a functional designer, business analyst, or product owner. The document is only as good as the knowledge that goes into it:
- The client or sponsor sets goal, scope, and priorities, and decides when wishes conflict.
- End users and process owners explain how the work is done today, where it gets stuck, and which exceptions occur.
- Developers and an architect check whether requirements are feasible and flag choices with major consequences for the build.
- Testers review for testability, so every requirement has an outcome you can verify.
If an external partner builds your software, agree up front who writes the functional design and who signs it off. Some vendors expect a finished document, others work it out with you in a discovery phase. Our article on software development outsourcing covers how such a partnership works, and how to choose a software company lists the questions to ask a vendor about it.
Functional design template: a table of contents
Use this table of contents as a starting point. Drop what doesn't apply and add chapters when your system calls for them.
- Introduction and goal. The problem the software solves, the intended result, and how you'll measure it.
- Scope. What's in this release and what's deliberately left out. The second list prevents a lot of debate.
- Glossary. Clear definitions of terms like customer, application, or order, so everyone means the same thing.
- Users and roles. For each role: who it is, what they do, and their permissions to view, edit, and approve.
- Processes. The main processes end to end, with a process diagram and the exceptions that happen in practice.
- Functional requirements. A numbered, testable requirement for each function, with a priority such as MoSCoW (must, should, could, won't).
- Business rules. Calculations, thresholds, status changes, and validations, numbered separately so you can refer to them.
- Data. The key data and how it relates, with its source and owner.
- Screens and reports. Sketches or wireframes of the main screens and the overviews users need.
- Integrations. Which systems exchange data, in which direction, how often, and what happens when a connection fails.
- Nonfunctional requirements. Performance, availability, security, usability, and maintainability, each with a measurable target.
- Acceptance criteria. For each requirement or group of requirements, the conditions under which you approve the feature.
- Open issues and decisions. What still needs to be worked out, and which decisions were made, when, and by whom.
- Version history. Version number, date, author, and a short description of each change.
Five common mistakes in a functional design
Most problems with a functional design only surface during the build or acceptance testing. These five come up most often:
- Prescribing solutions. "There will be a dropdown with all customers" locks in a technical choice. Describe the need instead: the user must be able to find a customer quickly by name or number.
- Vague words. Fast, user friendly, and flexible can't be tested. Turn them into a number or a specific behavior.
- Only the happy path. The flow where everything goes right is usually the smallest part of the work. Rejections, corrections, and failures take up most of the build time.
- No owner for decisions. When nobody has the authority to choose, open issues stay open until the team makes its own assumption.
- A document that freezes after kickoff. A functional design that no longer matches reality stops being used, including for maintenance and the next extension.
How the functional design feeds acceptance and testing
A functional design is also the basis for acceptance testing. Each numbered requirement gets one or more test cases with an expected result. That gives you one overview of which requirements have been tested and approved and which are still open. This link from requirement to test is called traceability.
Many organizations don't formalize this check. In the PMI study, 46% of organizations used a formal process to validate requirements objectively. The report also names inaccurate requirements gathering as a primary cause of project failure, at 37% in 2014, up from 32% a year earlier.
In agile teams, this connects to the Definition of Done from the Scrum Guide: a backlog item is done when it meets the agreed quality measures. So put the acceptance criteria from the functional design into the story, have testers read them before the build starts, and automate the tests that must run again with every release. More on this approach in QA and testing.
We've been building custom software for more than 30 years, from aviation MRO software to a subsidy administration platform and RFID in the supply chain. With 30+ engineers in Nijmegen (the Netherlands) and Sarajevo (Bosnia and Herzegovina), more than 100 projects, and ISO 9001 and ISO 27001 certification, we help clients get from a first idea to a testable functional design. Book a call to talk through your own functional design.
Frequently asked questions
What is the difference between a functional and a technical design?
A functional design describes what the software does for users and under which rules. A technical design describes how it's built: architecture, data model, technical integration details, and the chosen technology. The technical design follows from the functional design.
Do you need a functional design if you work with user stories?
Yes, though it can be shorter. User stories describe separate slices of value per sprint. The functional design keeps the whole consistent: roles, business rules, data, integrations, and nonfunctional requirements that apply to every story.
How long is a functional design?
That depends on the size and risk of the system. A small first release often fits in a handful of pages, while a system with many roles, rules, and integrations needs more. The test is that every requirement can be verified and the team doesn't have to guess at important decisions.
Who approves the functional design?
The client or product owner approves it, after input from end users, developers, and testers. Record who holds that authority and how changes after approval are discussed and documented.
