Functional Specification (Pflichtenheft)
The functional specification (Pflichtenheft) is the document produced by the supplier that describes how and with which means the requirements set out in the requirements specification (Lastenheft) will be implemented – the binding answer to the requirements spec and the contractual basis of an ERP project.
A functional specification (Pflichtenheft) is the document produced by the supplier – the ERP vendor or implementation partner – that describes in concrete terms how and by what means the requirements formulated by the client in the requirements specification (Lastenheft) will be implemented. While the requirements specification answers the question "What should the system do?" from the customer perspective, the functional specification clarifies the "How": it translates each requirement into a technical and organisational solution and thereby defines what the supplier will bindingly deliver. In DACH projects the functional specification is defined under DIN 69901-5 and regularly serves as an annex to the contract.
The functional specification is typically created at the start of an ERP implementation project, once client and supplier have come together. It makes scope of delivery, interfaces, customisations, deadlines and acceptance criteria verifiable and protects both sides: the customer receives a documented commitment as to what they will get; the supplier delineates what is not included. Because an ERP system reaches deep into a company's processes, a precise functional specification is one of the most important instruments for avoiding misunderstandings, add-ons and disputes over the scope of delivery.
At a glance
- The supplier's answer to the requirements spec: describes the "How", not the "What"
- Defines the realisation, interfaces, customisations, deadlines and acceptance criteria
- Defined in DACH under DIN 69901-5, often a binding contract annex
- Created at project start after the vendor has been selected
- Basis for acceptance, effort estimation and change requests
What a functional specification delivers in an ERP project
The functional specification translates the client's wishes into a robust, verifiable solution description. It takes up every requirement from the requirements specification and assigns it a concrete implementation – for example which module covers a function, which individual customisation is needed, over which interface data flows and which requirement is met with the standard. In this way a collection of target ideas becomes a blueprint for the project.
The functional specification thereby fulfils several functions at once: it serves as the basis for effort and cost estimation, as the reference for later acceptance, and as the yardstick for whether an additional requirement lies within the agreed scope or is treated as a chargeable change request. A cleanly produced functional specification approved by the client thus reduces the biggest risk in ERP projects – disputes over the scope of delivery – to a minimum.
Structure and components of a functional specification
A functional specification usually follows the structure of the underlying requirements specification, so that requirement and solution can be mapped unambiguously. A consistent numbering system ensures that every requirements-spec item receives a traceable answer.
Typical chapters
The usual components include an objective definition and project description, the functional and non-functional requirements together with their respective implementation, the data model including migration of the master data, the required interfaces (for example to a shop, DATEV or shipping providers), requirements for performance, availability and security, and a test and acceptance concept. This is supplemented by deadlines, milestones and the delineation of what is explicitly not part of the delivery.
Making requirements traceable
A proven approach is to mark each requirement with a classification: met by standard, met by configuration, met by individual development, or not met. This traceability shows at a glance how much customisation effort a system demands and later provides a clear checklist for acceptance. The more concrete and measurable a requirement is described, the less room for interpretation remains.
Functional specification vs. requirements specification: the clear distinction
The requirements specification (Lastenheft) and the functional specification (Pflichtenheft) form a pair but are frequently confused. The requirements specification is produced by the client and describes, from the client's perspective, which requirements and goals the ERP system must fulfil – deliberately open to solutions and without technical determination. The functional specification is the supplier's answer to it and describes, solution-oriented, how these requirements will be realised.
Memory aid: the requirements specification carries the "load" (Last) of the customer's requirements, the functional specification the "duty" (Pflicht) of the supplier to implement. In terms of timing, the requirements specification is created first during the ERP selection, then – after the decision for a supplier – the functional specification at project start. In practice, for smaller projects the two documents are sometimes merged into a joint "requirements/functional specification"; for clean responsibilities and acceptance, however, keeping them separate remains the standard.
Why the functional specification matters for ERP success
Many failed ERP implementations can be traced back to an unclear scope of delivery – to requirements that no one recorded concretely, and to expectations that client and supplier understood differently. The functional specification works precisely against this: it forces both sides to establish a shared, documented understanding before the project starts, and makes later discussions decidable against a binding reference document.
At the same time the functional specification is economically relevant. It is the basis for a robust quotation and the effort estimation, it defines the acceptance criteria from which a service counts as rendered, and it steers change management. Without a functional specification, projects easily spiral into add-ons and budget overruns. With a precise functional specification, effort can be calculated, project progress measured and responsibility clearly assigned in case of doubt.
Characteristics of a good functional specification
A good functional specification is complete, free of contradictions and, above all, measurably formulated: every requirement should be described so that at acceptance it is unambiguously clear whether it was met. Vague formulations such as "fast" or "user-friendly" should be made concrete – for example through defined response times, volume figures or fixed click paths. Equally important is the formal approval by the client, because only that turns the document into a binding basis for implementation and acceptance.
DACH specifics and legal framework
In German-speaking countries, the requirements specification and the functional specification are defined in terms by DIN 69901-5 (project management); the standard still shapes the language used in tenders and contracts today. Historically, the distinction goes back to VDI guideline 2519. This normative anchoring is one reason why the functional specification plays a more formal role in DACH projects than in many other markets.
Legally, the distinction is particularly significant for works contracts (Werkvertrag): the functional specification defines the owed result and is often agreed as part of the contract, so that it forms the basis for acceptance and possible warranty. In agile ERP projects, the classic, fully pre-specified functional specification is increasingly supplemented or replaced by leaner forms such as prioritised backlogs and iteratively refined specifications. The core idea, however, remains the same: a traceable, verifiable description of what the supplier has to deliver.
Example
Example: an e-commerce retailer introduces a new ERP
An online retailer with 25 employees has decided on a supplier after the ERP selection. Based on the previously created requirements specification, the implementation partner draws up a functional specification that answers every requirement with a concrete solution: the connection to the shop runs via the existing API, the handover to DATEV via a standard interface, the required batch management through configuration – and the individual returns process through a chargeable customisation.
In the functional specification, every item is marked as "standard", "configuration" or "individual development". At go-live, exactly this list serves as the acceptance protocol: point by point it is checked whether the promised implementation works. When the retailer subsequently wants a marketplace connection, the functional specification documents that this was not included – the extension is cleanly commissioned as a change request instead of becoming a point of dispute.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about Functional Specification (Pflichtenheft) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.