Software requirements spec and functional spec: an example through to the quote
A software requirements specification (German: Lastenheft) describes from the client’s point of view what the software should do, often as a table with one requirement per line. The service provider’s functional specification (German: Pflichtenheft) breaks each line into work packages with a result and an effort, and states exclusions, client responsibilities, assumptions and acceptance criteria. This example follows the route through a fictional case: the line “multilingual” turns into four work packages with 82 hours.
In brief
The five steps of the guide, on one case.
The case is fictional and comes from the book “Projects that pay off.”: the insurance group Auenhof commissions the service provider Hanselink to build a broker portal. At the centre is a single line: “multilingual”. The result in brief: Hanselink quoted all 48 lines at a fixed price, only 11 pass the check, and “multilingual” alone costs 82 hours, of which none had been quoted. An indicative quote would have shown what was firm and what was open.
- 1
Check the requirements spec
48 lines, most of them one sentence. Line 7: “The platform must be multilingual.” Ten questions show whether the spec is enough for a fixed price. 11 of 48 lines pass.
Go to step → - 2
Break it down
Twelve questions, six of which change the effort. They lead to four work packages and 82 hours. None of them had been quoted.
Go to step → - 3
Give an indicative quote
A first price, not yet binding. Every item says how certain it is: firm, based on assumptions, range or open.
Go to step → - 4
After the award: functional spec
The epic, meaning the big theme “Languages”, with packages, exclusions, client responsibilities, assumptions and an acceptance criterion.
Go to step → - 5
Give a binding quote
Once the functional spec is approved, the price usually becomes binding. The example stops before this step.
From indicative to binding quote →
The problem
A requirements spec with 48 lines, most of them one sentence.
Auenhof is a mid-sized insurer with several companies, including one subsidiary each in Austria and Switzerland. Around 1,200 brokers work with Auenhof, so far through an old broker portal. It is looking for a modern platform for working with its brokers, across all companies, in all languages, connected to its own CRM.
Auenhof invites four providers to bid. The documents: a cover letter and a 48-line table. Questions are allowed in writing only, and the deadline is three weeks. Hanselink estimates the project as a whole, gives a fixed price for all 48 lines and wins the contract. There is no functional spec. In week three it becomes clear what “multilingual” means: German, French, Italian and English, for the user interface, document templates, emails and reports.
Auenhof requirements spec, excerpt
- Set-up of the platform for all companies.
- Separate areas for all companies in the group.
- Role and permission concept as specified by Auenhof.
- Line 7 of 48The platform must be multilingual.
- Brokers should find everything in one place.
- Design in line with the corporate design.
- Migration of existing data from the current broker portal.
- Two-way interface to the CRM.
Wording from chapters 1 and 5 of the book. Only line 7 is numbered there.
Fictional case from the book “Projects that pay off.” (chapters 1 and 3). About the book →
Step by step
1 · The check: 11 of 48 lines pass.
Ten questions tell you whether a requirements spec is good enough for a fixed price. Ask them before you name a price. Every no goes into the quote as an assumption, or into the indicative quote as an open item. Hanselink only runs the Auenhof spec through the checklist afterwards.
Seven of the ten questions can be answered directly from the case. All seven fail:
The book says nothing about the other three for this spec (the goal in one sentence, a justified deadline, who decides and accepts the result). The full checklist is in appendix A1 and available as a template. See the templates →
- Can you tell for every requirement how you will know it has been met?No. “Role and permission concept as specified by Auenhof” is so general that you can read almost anything into it.
- Are quantities given: users, records, languages, companies?No. Line 7 does not name a single language.
- Is there a description or a contact for every interface?No. There is no description of the CRM, only the answer that IT will take care of it.
- Does it say which data will be migrated, from which system and in what state?No. The old portal holds twelve years of data, with duplicate entries. Nothing says what will be migrated.
- Is it clear what the client contributes: content, data, translations, tests?No. Who translates is not in the spec. Later Hanselink is expected to coordinate the translations.
- Is the spec free of one-word requirements?No: “multilingual”.
- Can you speak to someone who knows the requirements before you quote?No. Questions are allowed in writing only.
What is missing because it seems obvious: Christof Ebert calls gaps like this implicit requirements. What is clear to the client does not get written down, and the service provider has no way of knowing it. Which languages and which areas “multilingual” covered only became clear at Auenhof in week three. The remedy is question 10 of the checklist: a conversation before the quote. That is exactly what was not allowed here.
Covered in detail in chapter 5 and appendix A1 of “Projects that pay off.” About the book →
Step by step
2 · “Multilingual” turns into 82 hours.
Between a requirement and an estimate there are questions: each answer decides which packages are needed. Behind “multilingual” there are twelve questions, and six of them decide the effort. With Auenhof’s answers it looks like this:
| Question | Auenhof’s answer | Effect |
|---|---|---|
| Which languages besides German? | English, French, Italian | 3 languages |
| What gets translated? | user interface, document templates, emails, reports | 4 areas per language |
| Who translates? | Hanselink coordinates a translation agency | an extra package |
| Separate content per company? | Yes, for Switzerland and Austria | own text variants |
| CRM data in all languages? | No, German only | no hours, goes into the functional spec as an assumption |
| More languages later? | Perhaps Polish | no effect now, note it in the functional spec |
This gives four work packages.
Hanselink had allowed nothing for the multilingual part, because the platform already ran in German and English. The user interface did exist; nothing else did. Above all, the breakdown shows decisions: Auenhof would have had to answer “who translates?” before a price was fixed.
| Work package | Effort |
|---|---|
| Set up languages6 hrs per language | 18 hrs |
| Have templates, emails and reports translated and loaded3 areas per language at 4 hrs each | 36 hrs |
| Coordinate translationsliaising with the agency and the client; dropped if Auenhof does the translating (steps 3 and 4) | 16 hrs |
| Text variants per company2 companies at 6 hrs each | 12 hrs |
| Total for multilingual support | 82 hrs |
| of which quoted | 0 hrs |
Covered in detail in chapter 3 (the twelve questions) and chapter 7 (the breakdown) of “Projects that pay off.” About the book →
What is different
3 · The indicative quote separates what is firm from what is open.
Most clients want a price before the functional spec is finished. An indicative quote shows openly which work packages already have a firm effort and where clarification is still needed. For Auenhof it could have looked like this. The epic “Languages” appears with 66 rather than 82 hours and the status based on assumptions: the assumption is that Auenhof does the translating, which removes the 16 hours of coordination.
| Area | Status | Effort | Price* |
|---|---|---|---|
| Basic set-up, companies, roles | firm | 96 hrs | €10,560 |
| Corporate design | firm | 32 hrs | €3,520 |
| Languages (3 languages, translated by Auenhof) | based on assumptions | 66 hrs | €7,260 |
| Data migration from the broker portal | rangeafter data analysis | 40–90 hrs | €4,400–9,900 |
| Two-way CRM integration | openanalysis needed | analysis 16 hrs, then a quote | €1,760 + open |
| Training, testing, go-live | firm | 60 hrs | €6,600 |
| Total firm (incl. based on assumptions) | 254 hrs | €27,940 | |
| Total including ranges | 310–360 hrs + CRM | €34,100–39,600 + CRM | |
* Model calculation using the hourly rate from chapter 2 of the book (€110 per hour). The firm total covers basic set-up, design, and training, testing and go-live. It also includes the languages: they are based on assumptions, but their effort is fixed as long as the assumption holds.
Covered in detail in chapter 9 of “Projects that pay off.” How to give an indicative quote yourself is explained on the page Indicative quote →
What it looks like
4 · After the award, the line becomes an epic in the functional spec.
Next to the packages are the parts that are often missing from functional specs and later cause most disputes: exclusions, client responsibilities, assumptions and an acceptance criterion.
Set-up for Auenhof Insurance Group
Epic 4
Languages
The platform is set up in four languages for the companies in Germany, Austria and Switzerland.
| Work package | Effort |
|---|---|
| 4.1 Additional languagesSet up and test French, Italian and English alongside German, 6 hrs per language | 18 hrs |
| 4.2 Translated areasDocument templates, emails and reports in all three languages | 36 hrs |
| 4.3 Text variants per companySeparate texts and contacts for Austria and Switzerland | 12 hrs |
| Epic 4 total | 66 hrs |
- Exclusions
- Auenhof supplies the translations. Coordinating a translation agency is not included. Hanselink will quote further languages separately if needed.
- Client responsibilities
- Auenhof supplies the translated texts for each language as a file, no later than two weeks before the acceptance test. The contact is the project lead from broker support.
- Assumptions
- The user interface already exists in German and English. French and Italian are added through the existing language management.
- Acceptance criterion
- 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.
Covered in detail in chapters 7 and 8 of “Projects that pay off.” (figure 11). How the whole functional spec is structured is explained on the page Functional spec →
To take away
The full case, and your own.
Frequently asked questions
What people often ask.
How detailed does a software requirements spec need to be?
Precise enough for a service provider to quote without guessing. At a minimum it covers four points: goals, functional requirements, non-functional requirements (such as speed, reliability or usability) and the constraints: budget and deadline. The ten questions from step 1 show whether it is enough: every requirement is testable, quantities are given, interfaces are described and it is clear what the client contributes.
Which non-functional requirements belong in a software requirements spec?
Everything that describes how well the software should work: response times, availability, security, usability, maintainability, and which devices and systems it has to run on. The specialist literature points out that quality requirements like these are hard to describe and to test, and that they have a strong effect on the architecture. That is exactly why they stay vague in many requirements specs. For each one, write down a measurable value and the condition under which it applies.
How long is a functional spec for a software project?
There is no fixed page count. What matters is that all ten sections are complete, from background and goal to acceptance and changes, and that every work package has a testable result and an effort. In the book, Hanselink’s old functional spec template runs to twelve pages without a single exclusion. Length alone says little.
What does a functional spec cost?
There is no general figure. The price depends on the scope and on how well the client takes part. How to sell the functional spec as a separate service is covered on the indicative quote page.
Is the Auenhof case real?
No. Auenhof and Hanselink are a fictional case from the book “Projects that pay off.” The hours come from the book and add up across all chapters. The euro amounts are a model calculation at €110 per hour.
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