Häufig gestellte Fragen
What is the difference between a requirements specification (Lastenheft) and a functional specification (Pflichtenheft)?
The requirements specification (Lastenheft) describes from the customer's perspective WHAT the system is supposed to deliver, while the functional specification (Pflichtenheft) describes from the contractor's perspective HOW and with what means these requirements will be implemented. DIN 69901-5 defines the Pflichtenheft as the implementation specifications drawn up by the contractor on the basis of implementing the Lastenheft provided by the customer. In ERP projects, the functional specification thus responds point by point to the customer-side requirements specification and concretises modules, configurations and interfaces. In everyday business practice, however, the two terms are frequently mixed up or used synonymously.
Who writes the functional specification, the vendor or the customer?
The functional specification is drawn up by the contractor, i.e. the ERP vendor or the implementation partner, based on the requirements specification supplied by the customer. The customer then reviews the document, comments on assumptions and formally approves it; only then should the actual implementation begin. This division of roles is the theoretical ideal; in practice, the specific arrangement varies depending on the industry, company size class and customising depth of the ERP setup. In smaller projects, the requirements specification and functional specification are sometimes combined into a single, jointly developed requirements document.
Is the functional specification legally binding and part of the contract?
The functional specification is not a standalone contract in itself, but it is regularly used as an annex to the implementation contract and thereby acquires binding character. Once the customer has approved it, it describes the services owed — under a contract-for-work arrangement within the meaning of Section 631 of the German Civil Code (BGB): what is in the functional specification is a contractual obligation, and what is not in it is, in case of doubt, not owed. At acceptance, it serves as an objective reference for checking completeness and functionality against the agreed criteria. Later changes should therefore go through a formal change management process and be confirmed by both parties.
How many requirements are realistic in an ERP functional specification?
For mid-market projects, roughly 200 to 600 specific use cases or requirements are a practical range, while extensive corporate requirements specifications can reach several thousand requirements. More important than the sheer number is traceability: every requirement from the requirements specification should be reflected in the functional specification and classified as standard, configuration or custom development. Experience shows that over-specification leads to lengthy selection and coordination processes without necessarily resulting in a better-fitting system. It makes sense to prioritise requirements and clearly separate must-have criteria from nice-to-have criteria.
How long does it take to create a functional specification?
For mid-market projects, around 4 to 10 weeks are realistic depending on complexity, while large projects can take several months. Practical experience and industry studies show that many ERP projects overrun their original schedule, frequently in the range of roughly 20 to 40 percent. The most important lever for staying on schedule is a dedicated internal project manager with decision-making authority and high availability. External consulting is usually budgeted as a share of total project costs and speeds up the creation, but it does not replace the professional input of the key users.
Do agile ERP projects still need a functional specification?
In purely agile approaches such as Scrum, the classic functional specification is not part of the model; its place is taken by a prioritised product backlog with user stories and iterative sprint results, which deliberately start out incomplete and grow as insights are gained. The underlying idea of a binding, traceable implementation description remains, however, and is simply documented differently. In ERP projects, hybrid approaches often prevail, in which a lean functional specification defines the contractual framework and acceptance criteria, while detailed requirements are refined in an agile way in the backlog. Which form fits depends on the contract model, customising depth and the governance culture of the organisations involved.