Anyone putting software out to tender or introducing it almost always meets two documents. In German-speaking countries they are the “Lastenheft” and the “Pflichtenheft”: the requirements specification and the functional specification. They are often confused, yet the difference is simple.
The requirements specification: what you want
The requirements specification (Lastenheft) is written by the client, in other words you. It describes what the software should do, not how. It typically states:
- which workflow should be supported, and why
- who works with it
- which requirements are essential and which are nice to have
- which systems must be connected
- which conditions apply, such as data protection or running it in-house
The requirements specification is the basis for quotes. Several suppliers can respond to it, and their quotes become comparable.
The functional specification: how it will be built
The functional specification (Pflichtenheft) is written by the supplier. It responds to the requirements specification and describes how the requirements will be met: with which screens, rules, interfaces and technical means. Once agreed, it is the basis for the implementation and later for acceptance.
The difference at a glance
| Requirements specification | Functional specification | |
|---|---|---|
| Who writes it? | the client | the supplier |
| Question | What should the software do? | How will it be built? |
| Language | the business’s | the implementation’s |
| Purpose | obtaining and comparing quotes | implementation and acceptance |
Where both fail in practice
On paper it is all neat. In daily life, the same problems come up again and again:
- The requirements specification lists wishes instead of workflows. “The system should be user-friendly” helps nobody. “An order should become an invoice without re-entering the customer data” does.
- It is written at a desk. Whoever describes the workflow without talking to the people who do it every day forgets the exceptions - and those cost the most later.
- It gets too thick. Nobody reads two hundred pages in full, not even the supplier.
- It goes out of date. By the time everything is written down, the workflow has changed again.
- The functional specification becomes a contract text. Instead of looking for the best solution together, every change is checked for whether it is “in there”.
What a good requirements specification contains
If you write one, pay attention to these points:
- Starting point: how does it work today, and what gets in the way?
- Goal: what should be better afterwards, measurably if possible?
- Workflows: the most important workflows step by step, with the most common exceptions
- People involved: who works with it, who approves, who evaluates?
- Must and can: what is essential, what would be nice?
- Systems: which programs exist, which stay, which data flows where?
- Framework: operation, data protection, access on the move, number of users
And how do high-level and detailed concepts fit in?
The high-level concept and the detailed concept are a leaner route to the same goal. Instead of one big requirements specification for everything, a high-level concept for the whole comes first: where should it go, in which order? Then a detailed concept is written for the first area, as precise as a functional specification - but only for that area. More in our guide to high-level and detailed concepts.
The advantage: you never commit to more than you can oversee, and every detailed concept benefits from what was learned in the previous area.
Do you need a requirements specification at all?
A classic requirements specification pays off above all when you are putting standard software out to tender and want to compare several quotes, or when a public tender requires one. If, on the other hand, software is to be developed for your workflow, the step-by-step route is usually faster and safer. Either way: the start is not writing, but looking at how the workflow really runs today.
