Requirements specification and functional specification: what does a web project need?
Many projects are delayed because they wait for a complete document that nobody can write. This text explains the terms, names the cases in which they are really needed, and says what is enough otherwise.
What you will learn
Two documents, two authors
The Lastenheft (requirements specification) describes what the client needs: the task, the constraints, the goals. It is written by you, in your language.
The Pflichtenheft (functional specification) describes how the contractor intends to implement it: solution approach, technology, scope boundaries. It is created at the developer, based on the Lastenheft, and is accepted by you.
In practice, this clean separation occurs mainly in public tenders and in regulated sectors. In a mid-sized web project, a single shared document usually emerges — and that is not a shortcoming but appropriate.
When the effort pays off
An elaborate requirements specification pays off if at least one of these points applies:
Where none of this applies, an extensive document can even do harm: it ties up weeks, becomes outdated during implementation and creates the illusion that everything has been settled. The important questions arise anyway once you see the first screens.
Six details that are enough to start
The fifth point is almost always forgotten and is the most valuable. It prevents the discussion after acceptance in which both sides are right.
An example from practice
What you do not yet know belongs in it anyway
No requirements specification is complete, and that is fine — as long as the gaps are named. A sentence such as "How cancelled orders are handled in the annual report is still open" is worth more than a seemingly complete document that glosses over this question.
A developer who sees a named gap plans a decision for it. An unnamed gap is silently filled with an assumption — and assumptions come to light at acceptance, not before.
Common misconceptions
About the author
Fabian Lücker is the managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and concept design, and here he writes about decisions that arise in real projects.