Functional specification: structure, contents and how to write it in three steps
By Lukas Ebner, founder of Leadtime · Updated: November 2026
A functional specification (German: Pflichtenheft) describes how the service provider will meet the requirements in the client’s requirements specification, and with what: structured by epics (big themes) and work packages (parts with a testable result that get estimated), with exclusions, assumptions, client responsibilities (what the client contributes) and acceptance criteria. It becomes binding once it is part of the contract, usually after the client has approved it.
In brief
One document, four jobs.
Requirements specs are rarely written by specialists on the client side, so they have gaps. That is why the functional spec has to be precise. Once the client has approved it, it replaces the requirements spec as the basis for the whole project.
- Describe the requirements
- It sets out exactly what the solution must do, with all functions, properties and constraints.
- Communicate
- Everyone involved, on the client side and in your own team, works from the same version.
- Contract
- Once it is part of the contract, what is in it is owed. What is not in it is usually treated as a change.
- Acceptance
- It is the yardstick for checking, at the end, whether the project has been delivered.
The functional spec is most valuable to whoever writes it. Having to write down every requirement is how you find the stumbling blocks before the price is fixed.
What it looks like
The ten sections of a functional spec.
You can adopt this outline as it is. Open a section to see what goes into it, with a sample sentence from the fictional case in the book: the insurance group Auenhof commissions the service provider Hanselink to build a broker portal.
1Background and goal
What should be achieved, in three to five sentences.
ExampleAuenhof works with around 1,200 brokers through an old broker portal. The goal is a platform for working with the brokers across all companies in the group, connected to the CRM.
2People involved
Contacts on both sides, who decides, who accepts the result.
ExampleAt Auenhof: the project owner from broker support, the head of IT and, for the CRM connection, the external service provider who looks after the CRM.
3Scope by epics and work packages
For each package: description, the client’s answers, result, effort.
ExampleEpic 4 “Languages”, package 4.1 “Additional languages”. Client’s answer: English, French, Italian. Result: the three languages are set up and tested alongside German.
4Exclusions
What is explicitly not included.
ExampleThe client supplies the translations. Coordinating a translation agency is not included.
5Assumptions
What the estimate is based on. Every assumption starts with “We assume that …”.
ExampleWe assume that the CRM provides a documented interface.
6Client responsibilities
What the client delivers, by when and through whom: data, content, access, contacts, testing.
ExampleThe client supplies the translated texts for each language as a file, no later than two weeks before the acceptance test.
7Dependencies
Which packages wait for which, including dependencies on third parties. With names: who delivers what by when?
ExampleThe CRM connection can only be tested once the client’s CRM service provider has delivered their part.
8Schedule
Milestones, counted from the order date.
ExampleFunctional spec approved in week 3, delivery without the CRM integration by week 9, testing by week 11, go-live in week 13 with two weeks’ reserve.
9Acceptance
Test cases per package, the acceptance procedure and the three possible results: passed, passed with limitations, failed.
ExampleWhen a broker has French selected, the user interface, emails and reports appear entirely in French.
10Changes
How new requests during the project are handled and charged.
ExampleWork beyond the approved functional spec is quoted separately as a change request and charged by time spent at the agreed hourly rate.
Section 8 in the Auenhof example: four milestones, counted from the order date.
Outline from appendix A3; sample sentences from the fictional Auenhof case in the book “Projects that pay off.” (chapters 7 to 9). About the book →
The problem
What is almost always missing, and what does not belong.
Alongside the work packages, five parts belong in the functional spec that are often missing and later cause most of the disputes. In the book’s fictional case, the old functional spec template ran to twelve pages without a single exclusion.
- ExclusionsWhat is explicitly outside the scope.
- Client responsibilitiesWhat the client contributes, by when and through whom.
- AssumptionsWhat the estimate is based on.
- Acceptance criteriaHow to tell each package has been delivered, ideally written as a test case straight away.
- Handling changesHow new requests during the project are handled and what they cost.
What does not belong in it
- internal notes
- technical build instructions for the team
- hourly rates of individual people
- anything that may change during delivery without consequences for the client
Tasks for the team are created from the work packages only after approval. They are not part of the functional spec.
Service providers in particular hesitate over acceptance criteria, because the criteria pin them down. Christof Ebert sees this as working against them: without agreed criteria, acceptance turns into a negotiation. He describes a project in which both sides had changed requirements along the way but written none of it down. The provider considered it finished; the client refused to pay.
Step by step
The functional spec in three steps.
The starting point is always the requirements spec. The result is a document the client and the team can follow without prior knowledge.
- 1
Structure the requirements spec
Read the requirements spec thoroughly, looking at how things connect rather than at technical detail: what does the client want to achieve, which requirements belong together, where do they contradict each other? From that, you build an outline of epics and work packages.
- 2
Close the gaps in calls
Short video calls with a shared screen, one per package or epic, with the people who know about it. For an interface, the client’s own service provider joins the call. After each call, short minutes go to the client for approval.
- 3
Write it up precisely
From the requirements spec and the call results, you write a structured document in plain language. Technical details leave no room for interpretation, and jargon is explained. Anything complicated is often clearer as a diagram or mock-up than as text.
A guide for the clarification call, one hour per package or epic, is on the requirements analysis page. It also shows how to get from a requirement, via questions and options, to packages you can estimate. Call guide →
Covered in detail in chapters 7 and 8 of “Projects that pay off.”
To take away
Five rules for a good work package.
Work packages are the units you estimate, quote and describe in the functional spec. Epics are their sum, and tasks for the team come later. There is no formula for the right size, but these rules help.
- A testable resultIf you cannot say how you will know it is finished, it is a topic, not a package.
RolesBroker role set up and tested - One ownerIf three people from three disciplines have to work on it at once, it is too big.
- An estimate you can stand behindRule of thumb from chapter 7 of the book: no package over three working days. Anything bigger gets split.
- Clear to the clientThe client has to be able to read what they are getting.
Extend the data modelBrokers can filter documents by line of business - It recursCut packages so that they come up again in the next project. Then you don’t have to estimate them from scratch every time.
French for Switzerland at AuenhofSet up a language
How the example breaks a project down: estimates happen at package level.
Covered in detail in chapter 7 of “Projects that pay off.”
Frequently asked questions
What people often ask.
How is a functional spec structured?
In ten sections: background and goal, people involved, scope by epics and work packages, exclusions, assumptions, client responsibilities, dependencies, schedule, acceptance and changes. The scope takes up the most space. Sections 4 to 6 prevent the most disputes. The ten sections ↑
Who writes the functional spec?
The service provider, usually the project lead who will go on to deliver the project. The client supplies the answers in the clarification calls and approves the result.
Who pays for the functional spec?
Ideally the client, as a separate service before the actual project: they pay for a few weeks of clarification and get a document they could take to another provider. If the project does not go ahead, the functional spec is still paid for. On the usual route, the provider writes it after winning the contract and the effort is part of the project price. The two routes →
How long is a functional spec?
There is no fixed length, and page count says little. A functional spec is long enough when every work package has a testable result and the exclusions, assumptions and client responsibilities are not empty. The old template in the book’s fictional case ran to twelve pages without a single exclusion. It was long, yet the most important part was missing.
What is a Pflichtenheft in English?
It is usually called a “functional specification”, or “functional spec” for short. The Lastenheft is the “requirements specification”. More on the terms →
What happens if something changes after approval?
The approved functional spec is the single baseline on which the estimate, the plan and the price rest. The specialist literature advises recording every change to it as a requirement in its own right, in a new version. It is assessed and decided before anyone works on it, even if it is small and was agreed over the phone. It helps to collect change requests and decide on them together at fixed intervals. How they are charged is set out in the changes section. The ten sections ↑
Does the client have to approve the functional spec?
Yes, otherwise it remains a proposal. Once approved, it replaces the requirements spec as the basis of the project. It becomes binding when the contract names it as the scope of work. Agree the exact wording with your lawyer. This is not legal advice.
Read on
Where to go next.
Next step
Got a requirements spec from a client? Turn it into a functional spec.
Upload the requirements spec and answer ten questions at most, only the ones that change the effort. You get a structured draft functional spec with your logo, as Word and PDF. Anything still unclear is marked as open. You estimate the hours yourself.
- Freeno account, email address optional
- 10 questions at mosteverything else is marked as open in the spec
- Word and PDFwith your logo and colour