Functional Specification (Pflichtenheft)

The Pflichtenheft (functional specification) is the implementer's detailed response to the customer's Requirements Document (requirements document). While the Requirements Document describes what the customer needs, the Pflichtenheft describes how the implementer will deliver against those needs in the chosen system. For DACH ERP projects, the Pflichtenheft is typically the contractual basis for scope and implementation deliverables. Significant deviations during implementation are tracked as change requests against the Pflichtenheft.

Structure of the Pflichtenheft

• Project overview — recap of Requirements Document scope and high-level approach
• System architecture — ERP modules, integrations, infrastructure
• Process design — per functional area, the implemented business processes with specific ERP configuration
• Data model — master data structures, key fields, classification
• Customisations — specific developments beyond standard ERP, with detailed technical specifications
• Integration points — data flows with surrounding systems, technologies, formats
• Reporting and analytics — specific reports, dashboards, KPIs delivered
• Authorisation concept — role design with privileges and SoD rules
• Migration approach — data-migration scope, methodology, validation
• Test approach — testing scope, methodology, acceptance criteria
• Training plan — user training scope, methods, success criteria

Requirements Document versus Pflichtenheft

The two documents serve different purposes at different project phases. Requirements Document (customer-written, pre-selection): describes business needs technology-neutrally. Used for vendor selection, RFP scoring, demo design. Owned by the customer's business operators. Pflichtenheft (implementer-written, post-selection): describes how the chosen system will deliver against the Requirements Document. Used as implementation contract scope, build-time reference, change-control baseline. Owned by the implementation partner with customer sign-off. The Pflichtenheft typically takes 4-12 weeks to develop after vendor selection, with intensive customer involvement in design workshops. Approval of the Pflichtenheft is the trigger for full implementation spending.

Practical considerations

Three patterns for effective Pflichtenheft work. (1) Detailed fit-to-standard analysis: for each Requirements Document requirement, document whether the ERP delivers it through standard configuration, configuration plus customisation, custom development, or third-party add-on. Gaps and customisation decisions made explicit, with cost implications. (2) Customer review and sign-off: the customer must understand and approve the Pflichtenheft, not just nod through it. Without active review, mid-project surprises produce material tension with the implementation partner. (3) Change-control discipline: post-Pflichtenheft scope changes follow formal change-request procedures with impact analysis and incremental contracting. Without discipline, scope drift inflates cost and timeline 30-50% over the Pflichtenheft baseline.

Modern Agile variations

Pure-waterfall Pflichtenheft (complete document before implementation starts) gives way to incremental patterns in modern projects. Skeleton Pflichtenheft: high-level scope and architecture agreed upfront; detailed specifications iterated per sprint or release. Suitable for cloud-ERP projects with rapid deployment cycles. Fit-to-standard methodology: SAP Activate, Microsoft Success by Design and similar implementation methodologies emphasise standard-process adoption with selective customisation. Document scope stays focused on customisations and integrations rather than reproducing standard-process descriptions. Cloud-first approach: when the ERP is largely a fixed standard product, the Pflichtenheft focuses on configuration choices, integrations and data migration rather than comprehensive functional design.

Related Topics

• Requirements document (Requirements Document)
• ERP selection
• Customising