The German engineering tradition distinguishes formally between two project documents that English-speaking practice often blurs into one: the Requirements Document (requirements document) and the Pflichtenheft (functional specification). The Requirements Document is the buyer's statement of what the system must do; the Pflichtenheft is the supplier's statement of how those requirements will be met on the specific platform that has been chosen. The distinction is codified in DIN 69901-5, the project-management standard, and has been a fixture of deutsche software contracts for decades.
For ERP buyers in DACH, the Requirements Document vs Pflichtenheft distinction matters because it shapes contracts, defines acceptance criteria, and clarifies who is responsible for what. Buyers who do not understand the distinction often end up with implementations that nominally satisfy the contract but functionally disappoint, or with implementations that exceed the budget because scope was never properly fixed. This guide describes both documents, the hand-over between them, the DIN 69901-5 norm that governs them, and the international equivalents (Statement of Work, requirements document, functional design document) that buyers operating across regions need to understand.
What a Requirements Document (requirements document) contains
The Requirements Document is the buyer's document. It describes what the system must do, not how. It is written before vendor selection and is the basis on which vendors respond in the RFP phase. The standard contents:
Company profile and business context. Headcount, revenue, industry vertical, locations, growth ambition. Frames the supplier's understanding of fit.
Business processes. End-to-end process descriptions for the in-scope functional areas. Process maps where helpful. Volumes per process.
Functional requirements. Detailed requirements catalogue with MoSCoW priority. Usually delivered as an Excel attachment with 200 to 600 line items in mid-market scope.
The Requirements Document is platform-agnostic. It should be answerable by at least five candidate vendors without bias. Naming specific vendors in the Requirements Document signals favouritism and reduces the quality of vendor responses. Length runs 40 to 80 pages for mid-market scope. Our requirements document template provides the detailed structure.
What a Pflichtenheft (functional specification) contains
The Pflichtenheft is the supplier's document. It describes how the requirements from the Requirements Document will be implemented on the specific platform that has been selected. It is written after vendor selection, typically by the implementation partner working with the buyer's subject-matter experts. The standard contents:
Confirmed scope. The Requirements Document requirements are repeated, with explicit confirmation of how each one will be addressed (standard configuration, customisation, workaround, out of scope).
Solution design. Platform-specific design for each in-scope process, with configuration details, customisation specifications, integration interface designs.
Data model. Master-data structure on the chosen platform, key data fields, mandatory and optional attributes.
Integration design. Interface specifications for each system integration, including data flows, transformation rules, error handling.
Reports and analytics. List of reports to be delivered, their layout and data sources.
Test plan. Test scenarios that will be used to validate the implementation against the Requirements Document.
Acceptance criteria. Specific criteria that must be met for each work package to be accepted.
Project plan. Detailed timeline with milestones tied to the Requirements Document requirements.
The Pflichtenheft is platform-specific. It would be different on SAP S/4HANA than on Microsoft Dynamics 365 BC than on Oracle NetSuite, even for the same Requirements Document. Length runs 80 to 200 pages for mid-market scope. The Pflichtenheft becomes the binding scope-of-work appendix to the implementation contract.
The hand-over from Requirements Document to Pflichtenheft
The hand-over between Requirements Document and Pflichtenheft is the formal moment when responsibility transfers from buyer to supplier. The typical sequence:
Buyer publishes Requirements Document (week 0 of selection).
Vendors respond to Requirements Document via RFP (weeks 4 to 10).
Buyer selects vendor (weeks 14 to 18).
Vendor and buyer co-write Pflichtenheft (weeks 18 to 26 of the project, often called the “design phase” in agile-friendly methodologies). Subject-matter experts from the buyer side work with consultants from the supplier side. Workshops by functional area resolve the open questions from the Requirements Document and produce the platform-specific design.
Buyer signs off Pflichtenheft (week 26). This formal sign-off is the moment when the buyer commits to the design and the supplier commits to implementing it. Subsequent changes become formal change orders with cost and timeline implications.
Implementation begins against the Pflichtenheft (week 26 onwards).
The Pflichtenheft hand-over is the project moment most prone to dispute. Buyers sometimes treat it as an internal document and skip the sign-off discipline, leaving scope undefined and disputes likely. Suppliers sometimes minimise the Pflichtenheft effort and discover scope gaps mid-implementation. The Pflichtenheft sign-off is genuinely binding and worth investing the workshop effort to get right.
DIN 69901-5 — the underlying norm
The Requirements Document and Pflichtenheft are codified in DIN 69901-5, the German Industrial Norm for project management terminology. Section 3.78 of the standard defines the Requirements Document as “the total set of requirements of the customer for the deliverables and services of a contractor.” Section 3.119 defines the Pflichtenheft as “the technical specifications by which the contractor describes how he intends to meet the requirements of the customer.” The definitions are concise but consequential: they establish that the Requirements Document is the buyer's document and the Pflichtenheft is the supplier's document, which clarifies authorship and ownership.
VDI 2519 (Verein Deutscher Ingenieure) extends the DIN framework with specific guidance for engineering procurement, including ERP. It recommends a structured walkthrough of the Requirements Document with shortlisted vendors before final RFP submission — a practice known as the Requirements Document-Workshop — which materially improves vendor response quality and reduces post-contract surprises. Mid-market buyers who follow VDI 2519 in addition to DIN 69901-5 tend to run cleaner selection processes than those who do not.
Neither standard is legally mandatory; they are commercial standards that contracts can reference. Most deutsche ERP contracts explicitly reference DIN 69901-5 and VDI 2519, and the standards carry weight in any subsequent dispute. International vendors selling into DACH should expect to encounter these references and treat them as part of the contract framework.
International equivalents to Requirements Document and Pflichtenheft
Other regions distinguish the same documents under different names and with different degrees of formality:
USA and UK: the closest equivalent to the Requirements Document is the “Requirements Document” or “Business Requirements Document” (BRD). The closest equivalent to the Pflichtenheft is the “Functional Specification Document” (FSD), “Functional Design Document” (FDD) or “Statement of Work” (SoW). The distinction is less formally codified than in DACH but the underlying logic is the same.
France: the Requirements Document is called “cahier des charges fonctionnel”; the Pflichtenheft is called “cahier des charges technique” or sometimes “specifications fonctionnelles detaillees”. The norm AFNOR X 50-151 codifies the framework.
Spain: “pliego de prescripciones” (Requirements Document) and “documento de especificacion funcional” (Pflichtenheft). The distinction is recognised but less formally enforced than in DACH or France.
Agile international practice: in agile-heavy projects, the Requirements Document is sometimes replaced by a Product Backlog and high-level Epics; the Pflichtenheft is replaced by sprint-level User Stories. The underlying responsibility distinction (buyer says what, supplier says how) is preserved but the documentation is lighter.
For DACH buyers contracting with international suppliers, it pays to specify which framework applies and which document equivalents will be produced. Suppliers from agile international practice sometimes resist the formal Pflichtenheft sign-off in favour of iterative design; DACH buyers should resist the resistance when scope discipline matters.
What is the main difference between a requirements document (Lastenheft) and a functional specification (Pflichtenheft)?
The requirements document (Lastenheft) defines the WHAT and comes from the client. The functional specification (Pflichtenheft) defines the HOW and is produced by the contractor. The requirements document comes first; the functional specification follows later, after the contract has been signed.
Who writes the functional specification?
The contractor — the ERP vendor or implementation partner. The client reviews and approves it. In practice, the exact form varies by industry, company size and the customisation depth of the specific ERP setup.
Do I need both?
For larger ERP projects, yes — both documents protect the client and the vendor legally. For very small cloud ERPs, a requirements catalogue is often sufficient. In practice, the exact form varies by industry, company size and the customisation depth of the specific ERP setup.
How extensive is a typical requirements document?
For mid-sized companies: 30–80 pages plus an Excel requirements matrix. For large corporations: 100–300 pages. In practice, the exact form varies by industry, company size and the customisation depth of the specific ERP setup.
Who is liable for defects in the requirements document?
In principle the client, since they create the requirements document. When external selection advisors provide consulting, duties of care are often regulated contractually. A structured selection process combines the requirements document, a demo with your own data, reference visits to comparable companies and a proof of concept covering 2-3 critical processes.
How extensive should a functional specification be?
For mid-sized companies: 50-150 pages plus an Excel requirements matrix. For large corporations: 150-500 pages plus use-case diagrams and interface specifications. In practice, the exact form varies by industry, company size and the customisation depth of the specific ERP setup.
Can we change requirements later on?
Yes, via change requests within the functional specification lifecycle. The prerequisite is a clearly documented change-control process in the contract, including the impact on schedule and budget. In practice, the exact form varies by industry, company size and the customisation depth of the specific ERP setup.
