Functional and Requirements Specification.

The terms come from classic project management and are described in standards; in German-speaking countries they are known as Lastenheft and Pflichtenheft. The requirements specification is written by the client. It describes the starting point, goals, user groups, desired functions, constraints such as budget and deadline, and non-negotiable requirements such as data storage in Switzerland. It says what is needed, not how it is to be solved technically.

The functional specification is written by the contractor in response to the requirements specification. It describes how the requirements will be implemented: architecture, technologies, functions in detail, interfaces, data model, test concept and acceptance criteria. Once approved by the client, it is the binding basis. Anything not in the functional specification is, in case of doubt, not owed — a frequent bone of contention in projects with an unclear description.

In agile projects it is often argued that functional specifications are outdated. That is only partly true. It is true that a hundred-page document written at the outset rarely matches reality. It is not true that you therefore need no requirements. A lean form works well: a requirements specification with goals, users and must-have criteria, a discovery phase to clarify things, and a functional specification that describes the first implementation step bindingly and later steps as a framework.

For SMEs the requirements specification is the most important tool for getting comparable quotes. Without a description, every provider calculates on different assumptions and the prices lie far apart. With a clear requirements specification you can tell who has understood the task — and who is merely naming a price.