Requirements spec or functional spec: who writes what, and what comes first?
By Lukas Ebner, founder of Leadtime · Updated: November 2026
The requirements specification (German: Lastenheft) comes first and is written by the client. It describes what should be achieved. The functional specification (German: Pflichtenheft) follows, written by the service provider. It describes how the requirements will be met and with what effort. The functional spec becomes binding once it is part of the contract, usually after the client has approved it.
In brief
The difference in one table.
| Aspect | Requirements spec | Functional spec |
|---|---|---|
| Written by | the client | the service provider |
| Describes | the what: goals and requirements | the how: packages, results, effort |
| Typical form | a table, one requirement per line | structured by epics (the big themes) and work packages (parts with a testable result that get estimated) |
| Boundaries | rarely stated | exclusions, client responsibilities (what the client contributes), assumptions |
| Serves as | basis for the tender | basis for contract and acceptance |
| Binding | not on its own | yes, once it is part of the contract (usually after client approval) |
| In German | Lastenheft | Pflichtenheft |
To remember it: in German, Last means load and Pflicht means duty. The Lastenheft holds the load the client puts on the provider. The Pflichtenheft holds what the provider commits to.
Step by step
First the requirements, then the functional spec, then the price.
That is the ideal. In practice the client wants a price first. An indicative quote then bridges the gap to the binding one: a first price, not yet binding, that states for each item what is already firm and what is still open.
Ideal route
- Requirements spec
- Order the functional spec
- Functional spec approved
- binding quote
- Delivery
If the client declines afterwards, the hours for the functional spec are still paid.
Usual route
- Check and break down the requirements spec
- indicative quote
- Contract awarded, then close the gaps and write the functional spec
- binding quote
- Delivery
The indicative quote labels each item: firm, based on assumptions, range or open.
The problem
One line in the requirements spec becomes a chapter in the functional spec.
The requirements spec says what is needed. The functional spec turns it into packages with a result, an effort and boundaries. In the fictional case from the book, the insurance group Auenhof commissions the service provider Hanselink to build a broker portal. This is how one line becomes a chapter there:
Auenhof requirements spec, line 7
“The platform must be multilingual.”
Functional spec, epic 4: languages
| Work package | Result | Effort |
|---|---|---|
| 4.1 Additional languages | French, Italian and English set up and tested alongside German | 18 hrs |
| 4.2 Translated areas | Document templates, emails and reports in all three languages | 36 hrs |
| 4.3 Text variants per company | Own texts and contacts for Austria and Switzerland | 12 hrs |
- Exclusion
- The client supplies the translations. Coordinating a translation agency is not included.
- Client responsibility
- The client supplies the translated texts for each language as a file, no later than two weeks before the acceptance test.
- Assumption
- The user interface already exists in German and English. French and Italian are added through the existing language management.
- Acceptance
- Test case 4.2-1: a broker at the Swiss company who has French set as their language receives a notification in French that names the contact at their company.
Fictional case from the book “Projects that pay off.” (chapters 7 and 8). The questions behind it, and why this shows 66 hours rather than 82 when the service provider coordinates the translations, are in the full example →
What is different
Does a requirements spec still make sense in agile projects?
Yes, as soon as the client needs a fixed price or date. Agile methods rightly assume you cannot know everything up front. That is little help in a fixed-price tender, where you need a requirements spec and a functional spec at the start. The team can still deliver in an agile way afterwards.
- Requirements spec and functional specfixed price or fixed date, a tender, several client projects in parallel
- Agile without a functional speclong product development with a fixed team, a monthly budget instead of a fixed scope, real unknowns a prototype has to settle
Frequently asked questions
What people often ask.
What comes first, the requirements spec or the functional spec?
The requirements spec. The client writes it and sends it to potential service providers. The functional spec is written afterwards by the service provider, based on the requirements spec and conversations with the client.
Who writes the requirements spec, who writes the functional spec?
The client writes the requirements spec, ideally a project lead who knows the processes. The service provider writes the functional spec, usually the project lead who will go on to deliver the project.
Can the service provider write the requirements spec?
They can help, for example in a workshop. But the client decides what is needed. Alternatively, the client commissions the functional spec as a separate, paid piece of work.
Do you always need both?
For small jobs, a quote with a precise scope of work is often enough. Once a fixed price rests on a requirements spec with gaps, the functional spec pays off. It is the yardstick for acceptance at the end. In smaller projects, both can also live in one document, with separate chapters for the what and the how and an owner for each. Christof Ebert recommends this explicitly for smaller companies, because misunderstandings come to light early.
What if the requirements spec already prescribes a solution?
Then it is a constraint set by the client and belongs in the requirements spec. According to the specialist literature, what matters is who decides: if the client prescribes a particular shop system, the service provider sticks to it. If the client only wants to be able to maintain their own products, the provider chooses the technology and describes it in the functional spec. For every solution named in the requirements spec, ask whether it is fixed or was only meant as an example. The answer often changes the effort.
Is a functional spec legally binding?
If the contract names it as the scope of work, it is part of the contract. What is in it is then owed; what is not in it is usually treated as a change. Agree the exact wording with your lawyer. This is not legal advice.
What are the English and German terms?
The requirements spec is usually called a “requirements specification” (or “customer requirements specification”) and the functional spec a “functional specification”. German projects call them “Lastenheft” and “Pflichtenheft”. An “SRS” (software requirements specification) is usually written by the delivering side, so it is closer to a functional spec. A “PRD” (product requirements document) is an internal product document. The specialist literature explains why German practice has two documents: one requirement often needs several parts of the solution, and one part of the solution often meets several requirements. Separate documents or chapters capture that more cleanly than a single specification.
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