Requirements specification: what goes in it and how to spot a good one
By Lukas Ebner, founder of Leadtime · Updated: November 2026
A requirements specification (German: Lastenheft) describes what should be delivered and why, without fixing how: goals, functional and non-functional requirements, budget and deadline. The client writes it. On that basis, the service provider writes the functional specification (German: Pflichtenheft).
In brief
The client writes down what they need.
The requirements spec comes at the start of a project, before a service provider has been chosen. It says what should be achieved and leaves open how.
- Who writes it?
- The client. Ideally an experienced project lead who talks to everyone involved, resolves contradictions and only then starts writing. In practice, it is often whoever in the department happens to have time.
- When?
- Before providers are asked for quotes. In a tender, every bidder gets the same requirements spec. Without a tender it is often missing entirely, and there is only a conversation and some notes.
- What for?
- It is the basis for quotes and for comparing providers. On its own it is not binding. For delivery, the functional spec counts once the client has approved it.
- What does not belong in it
- The solution. Technology, work packages (parts with a testable result that are estimated one by one) and effort are for the service provider to set out in the functional spec. The difference in detail →
In brief
Contents and structure: eight sections.
A good requirements spec settles at least four points: goals, functional requirements, non-functional requirements and the constraints. Spread over eight sections, the outline looks like this. Most sections show which question of the checklist below they answer.
- 1
Background
Who is the client, what prompted the project, why now?
- 2
Goals Core point
What should the project achieve, in one sentence? How will you know afterwards that it has?
Checklist: question 1 - 3
Current state and volumes
How does it work today? How many users, records, languages, companies, pages or products?
Checklist: question 3 - 4
Functional requirements Core point
What exactly should the solution do? One requirement per line, each with a sentence on how to tell it has been met. No line that is just one word.
Checklist: questions 2 and 9 - 5
Non-functional requirements Core point
What quality is expected, for example in speed, reliability or ease of use?
- 6
Interfaces and data
Which systems must the solution talk to, and who can describe them? Which data is migrated, from which system, in what state?
Checklist: questions 4 and 5 - 7
Constraints: budget and deadline Core point
What budget, what deadline? And what is the deadline tied to: a trade fair, the end of a contract, or just a wish?
Checklist: question 7 - 8
People, client responsibilities and acceptance
Who decides, who accepts the result, who answers questions before the quote? What does the client contribute: content, data, translations, testing?
Checklist: questions 6, 8 and 10
In Germany, the terms Lastenheft and Pflichtenheft are defined in DIN 69901-5:2009 (project management, project management systems, part 5: terms). It does not prescribe a fixed outline. The eight sections here are this page’s suggestion, not a standard. Together they cover the ten questions of the checklist from the book.
The problem
Why requirements specs so often have gaps.
A solid requirements spec takes method, technical understanding and precise wording. There are three reasons it so often goes wrong. On top of that, many clients don’t even notice how incomplete their spec is.
- Little practiceFew people write long technical documents regularly. Anyone writing one for the first time will make mistakes.
- No timeWhen the spec is written alongside day-to-day work, the result is fragments and sentences that can be read either way.
- The wrong expectationStating requirements precisely is the client’s job. Yet it is often assumed that the provider will fill the gaps. They are the expert, after all.
For the service provider, this means translating from the client’s language into the language of delivery. So they ask questions before naming a price, and get what they need for a sound quote. How to clarify requirements →
The specialist literature names two gaps that turn up in requirements specs again and again. The first is implicit requirements: what is obvious to the client does not get written down, and the service provider has no way of knowing it. The second is the boundary: what is explicitly not to be delivered is almost never in the spec. The quickest way to clear up both is a conversation before the quote (question 10 of the checklist).
Covered in detail in chapter 5 of “Projects that pay off.” About the book →
To take away
Is this requirements spec solid enough? Ten questions.
Ask these questions before you name a fixed price. Every no goes into the quote as an assumption, or into the indicative quote as an open item: a first price, not yet binding, with a status for each item. Click yes or no for each question.
Does it state what the project should achieve, in one sentence?
Goal in one sentenceIs it clear for every requirement how you will know it has been met?
How to tell a requirement is metAre volumes stated: users, records, languages, companies, pages, products?
VolumesIs there a description for every interface, or a contact who can provide one?
InterfacesDoes it describe which data is migrated, from which system and in what state?
Data migrationIs it clear what the client contributes: content, data, translations, testing, contacts?
Client responsibilitiesIs there a reason for the deadline (trade fair, conference, end of a contract)?
Reason for the deadlineIs it clear who decides and who accepts the result on the client side?
Who decides and accepts the resultIs the spec free of requirements that are just one word (“multilingual”, “search”, “modern”)?
One-word requirementsCan you speak to someone who knows the requirements before you quote?
A conversation before the quote
For clients: the same ten questions show what a service provider needs. The more of them your spec answers with yes, the easier it is to quote a fixed price. Question 9 is turned round compared with the book, so that yes is always the good answer.
What it looks like
Five lines that sound clear.
In the fictional case from the book, the insurance group Auenhof commissions the service provider Hanselink to build a broker portal for around 1,200 brokers. The requirements spec is a table of 48 lines, most of them one sentence. Every line sounds clear. Next to each is the checklist question it fails.
Auenhof broker portal requirements spec, extract (5 of 48 lines). Apart from 7, the line numbers are examples.
- Line 4
Separate areas for all companies in the group.
Each company gets its own separate area. How many companies, with what differences? Question 3 - Line 7
The platform must be multilingual.
Which languages, what gets translated, who translates? There are twelve questions behind it. Questions 3, 6, 9 - Line 9
Role and permission concept as specified by Auenhof.
The specifications are missing. With goodwill, almost any later wish fits in. Question 2 - Line 22
Migration of existing data from the current broker portal.
Which data, in what state, and who decides what is migrated? Question 5 - Line 31
Two-way interface to the CRM.
No description, no contact. When asked, the only answer was that IT would take care of it. Question 4
Checked against the whole checklist, only 11 of the 48 lines pass. The service provider had quoted all 48 at a fixed price. What line 7 alone turned into is shown in the full example. The full example through to the quote →
Fictional case from the book “Projects that pay off.” (chapters 1, 3, 5 and 7). The wording of the lines is from the book. About the book →
Frequently asked questions
What people often ask.
What goes into a requirements specification?
At least the project’s goals, the functional requirements (what the solution should do), the non-functional requirements (what quality is expected) and the constraints: budget and deadline. In practice it also covers the current state with volumes, interfaces and data, the people involved and what the client contributes. How it will be delivered is not part of it.
Who writes the requirements specification?
The client. Ideally a project lead who knows the processes and the technical environment and talks to everyone involved. The service provider can help, for example in a joint workshop. But the client decides what is needed.
Is a requirements spec still relevant?
Yes, as soon as the client needs a fixed price or date, for example in a tender. Delivery can still be agile afterwards. More on this →
How do I recognise a good requirement?
You can decide with a yes or no, on the finished result, whether it has been met. Christof Ebert advises reading every requirement the way a tester reads it: how would I check this before handover? If there is no answer, it is too vague. “The platform must be multilingual” fails this test. “A broker at the Swiss company who has French set as their language receives their notifications in French” passes it.
Which words should you avoid in a requirements spec?
Words that everyone can read differently. Specialist literature keeps lists of such words; here is a selection. “Fast”, “easy” and “user-friendly” cannot be tested unless a figure or condition goes with them. “Supports” leaves open how far the support goes. “Etc.” and “for example” turn a list into an open-ended one, and “and/or” leaves open whether both are meant. “Should” and “could” leave open whether something is mandatory. It is better to mark importance with a priority. And write only one requirement per sentence.
Which standard covers the requirements spec?
In Germany, DIN 69901-5:2009 (project management, project management systems, part 5: terms) defines Lastenheft and Pflichtenheft. It defines the terms, not a structure. For automation projects, the guideline VDI/VDE 3694 covers both documents in more detail. Internationally, ISO/IEC/IEEE 29148 describes requirements engineering for systems and software, without using the German terms. A good spec needs none of them; a clear structure is enough.
What if no questions are allowed before the quote?
In tenders, questions are often only allowed in writing and only up to a deadline. Collect yours and submit them in writing in good time. Whatever stays open goes into the quote as an assumption: “We assume that …”. More on this →
What is a Lastenheft in English?
It is usually called a “requirements specification”, or more precisely a “customer requirements specification”. The Pflichtenheft is a “functional specification”. More on the terms →
Is there a template or an example?
Yes. The Word template follows the eight sections above, with guidance on what to fill in. A complete example shows the requirements spec for a software project and the functional spec that comes out of it. Both without sign-up. See the templates → See the example →
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