What is a functional specifica­tion (Pflichten­heft)?

Functional specifica­tion: definition

According to DIN 69901-5, the Pflichtenheft contains the implementation specifications developed by the contractor on the basis of the Lastenheft. It translates the customer's requirements into a concrete, technically verifiable description of the solution.

While the requirements specification is written from the client's perspective, the functional specification is where the service provider speaks: this is how we will build it, these are the technologies we will use, and this is how we will measure whether a requirement has been met.

In practice, the functional specification is often developed jointly in workshops. This way, the client's domain knowledge flows directly into the technical planning, and open questions are clarified before any development effort is incurred.

How a functional specifica­tion is structured

The functional specification usually follows the structure of the requirements specification so that each requirement can be mapped to a solution. It is worded so precisely that, in the end, it can be clearly verified whether a feature has been delivered.

Instead of “The search should be fast,” it contains a measurable criterion, such as a maximum response time for a given amount of data—with values that both sides define together.

• Mapping of each requirement to a concrete solution
• System architecture and technologies used
• Data model and interface descriptions
• User interfaces, user roles, and permissions
• Test and acceptance criteria
• Project plan with milestones

Benefits and limitations of a functional specifica­tion

A functional specification creates commitment. Both sides know what will be delivered, and acceptance is based on previously agreed, traceable criteria. Later change requests can be clearly identified and assessed as extensions.

The effort required for a complete functional specification is considerable and pays off mainly for clearly defined fixed-price projects. For projects with many unknowns, it is often limited to the key points and supplemented by iterative coordination.

• Shared understanding before development starts
• Basis for fixed-price quotes and acceptance
• Changes become transparent
• High effort to create when requirements are unclear

Real-world example: from requirements specifica­tion to fixed price

In the requirements specification, a retailer describes that its B2B online store should take over customer-specific prices from the ERP and automatically send orders back. In the functional specification, the service provider defines which interface is used for the sync, how often prices are synchronized, how errors are handled, and which test orders will be used to accept the feature.

When the scope is clearly defined, Nano Concepts prefers to prepare a fixed-price quote on this basis. Whether the functional specification becomes part of the contract and what effect it has is governed by the respective contract—this note does not replace legal advice.