Requirements Document vs Functional Specification

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.
Non-functional requirements. Performance, availability, scalability, accessibility, multi-language.
Compliance and regulatory. GoBD, DATEV, ZUGFeRD, XRechnung, industry-specific regulations.
Integration estate. Current systems, integrations to retain, integration patterns required.
Data migration. Volumes, retention requirements, legacy systems to migrate from.
Commercial framework. Pricing preferences, licence-model preferences, SLA expectations.
Selection process. Timeline, decision criteria, contact information.

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.
User-interface design. Screen layouts, navigation structure, role-based access design.
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.

Frequently Asked Questions

Who writes the Lastenheft?

The buyer writes the Lastenheft, either internally or with the help of a selection advisor. The implementation partner does not write the Lastenheft — that would compromise the independence of the document. Common internal authors are project managers in IT or operations, with subject-matter expert input from each functional area. Specialist selection advisors (1,000 to 1,800 EUR per day) frequently lead the effort for first-time selections.

Who writes the Pflichtenheft?

The implementation partner (the selected supplier) writes the Pflichtenheft, working with the buyer's subject-matter experts in design workshops. The Pflichtenheft typically goes through several iterations before sign-off, with the buyer's process owners validating the platform-specific design against their business processes. Sign-off requires both parties; ownership of the document after sign-off is shared.

Can we skip the Pflichtenheft and go straight to implementation?

In agile-led implementations, the formal Pflichtenheft is sometimes replaced by iterative design with sprint-level documentation. For complex mid-market and enterprise ERP implementations, skipping the Pflichtenheft is risky: scope drifts, change orders accumulate, and disputes become harder to resolve. Most successful DACH mid-market implementations retain a formal Pflichtenheft phase even when the implementation methodology is otherwise agile.

How long does Pflichtenheft creation take?

For a mid-market ERP implementation, the Pflichtenheft phase typically runs 6 to 12 weeks after contract signature. Smaller SMB implementations compress this to 3 to 5 weeks. Enterprise implementations regularly run 12 to 24 weeks of formal design. Process workshops account for most of the elapsed time; the writing itself is a smaller portion of the effort. Compressing below 4 weeks for any meaningful project usually produces design gaps that surface mid-implementation.

Is the Pflichtenheft legally binding?

The Pflichtenheft itself is technical documentation; its legal weight comes from being referenced in the implementation contract as the scope-of-work appendix. Once signed off and incorporated by reference, the Pflichtenheft defines what the supplier is committed to deliver and what acceptance looks like. Disputes about scope are resolved by reference to the signed Pflichtenheft, which is why investment in getting it right matters.