From our experience with over 1,200 projects at Dreher Consulting and more than 30 years in the DACH Mittelstand, we see a different truth from the textbook reading: architecture before software. The Lastenheft is the shell, the Anforderungskatalog is the core, the Pflichtenheft is the vendor's response. Conflating these three layers means buying software blind.
What Is a Lastenheft? Definition and Core Characteristics
A Lastenheft (German requirements specification) is the requirements document produced by the contracting client for a delivery or service — describing the what, not the how. Per VDI 2519 Sheet 1 — the authoritative guideline for Lasten- and Pflichtenhefte — it is the buyer's full requirements document. In the ERP context it is the target architecture translated into contract-grade requirements, not a wishlist.
Five characteristics distinguish an architecture-grade Lastenheft from the decorative requirements compilation we regularly see on tables in our DACH Mittelstand engagements:
- Client perspective throughout — the Lastenheft describes from the company's perspective what is to be delivered. The vendor answers in the Pflichtenheft how it will be solved.
- Functional and non-functional requirements separated — functions (order processing, reporting) sit alongside non-functional requirements (performance, security, data protection).
- Must, Should and Could requirements prioritised — every requirement carries a clear priority, otherwise the document becomes a negotiation sleight-of-hand.
- Architecture link traceable — every requirement is anchored to a core process of the process landscape map and to a business capability.
- Contract anchor and Pflichtenheft link — the Lastenheft becomes part of the later contract and the basis for the Pflichtenheft produced by the vendor.
The boundary matters: the Lastenheft is the shell, the Anforderungskatalog the core, the Pflichtenheft the answer. Conflating Anforderungskatalog with Lastenheft loses the architecture layer; pre-empting the Pflichtenheft hands the vendor a constrained brief.
Why the Lastenheft Matters in the DACH Mittelstand in 2026
Three drivers act simultaneously — end-to-end process complexity is growing, regulatory obligations demand documented requirements, and ERP modernisation stalls without a robust requirements specification. From our consulting projects over the past 24 months we have documented this across mechanical engineering, food manufacturing and educational-material suppliers.
First — the structural weakness. The Bitkom study Digitalisation of the Economy 2025 shows that 53 percent of German companies report difficulty in coping with digitalisation — robust requirements documentation is a central prerequisite for closing that gap.
Second — the regulatory duty. The EU NIS-2 Directive (2022/2555) and its national transposition, the EU AI Act phasing in, plus GoBD and CSRD, remain mandatory. These obligations belong in the Lastenheft as dedicated framework chapters — not as marketing phrases.
Third — the architecture gap before any ERP selection. Contrary to the textbook reading we see the Lastenheft not as a desk exercise but as a contract anchor and risk brake. Projects with a documented, architecture-validated Lastenheft run shorter in our experience and produce markedly fewer change requests after contract signature.
Across our engagements with DACH machine builders and educational-material manufacturers we see it repeatedly: the Lastenheft treated as an isolated Excel list instead of an architecture document — typical result, six to nine extra months of implementation after contract signature. The same effect runs across our Mittelstand mandates.
Project Example: DACH Machine Builder (anonymised, c. 1,500 employees)
At a southern-German machine builder with around 1,500 employees we documented the target architecture before ERP selection and translated it into an architecture-validated Lastenheft. Sales, engineering, production planning and service each held their own view of the order-to-cash process before the engagement — no one had seen the end-to-end process in a single consolidated document.
In this machine-builder mandate with around 1,500 employees we built up the target architecture over three months — no vendor talks before the Lastenheft stands. In a two-day workshop with managing directors and department heads we presented the process landscape map, decomposed the core processes into business capabilities, then classified each capability as differentiator or commodity.
Differentiators became Must requirements, commodities became Should or Could. The Lastenheft contained five mandatory chapters: As-Is, To-Be, functional requirements per core process, non-functional requirements and framework conditions (GDPR, GoBD, CSRD from 2026). This separation is exactly what VDI 2519 Sheet 1 prescribes for the creation of Lasten- and Pflichtenhefte.
Six months later the ERP selection was complete, three vendors had submitted Pflichtenhefte, the contract was negotiated against the Lastenheft — change-request risk bounded by the Must-Should-Could prioritisation. The lesson: the Lastenheft decides whether the ERP rollout is controlled or ends in contract dispute.
What Lastenheft Guides Leave Out
Three points that rarely surface in German-language Lastenheft guides and vendor templates, but in the DACH Mittelstand they decide between project success and project abort. They follow from our 1,200+ projects and the consistent application of the three-layer model of Lastenheft, Anforderungskatalog and Pflichtenheft.
1. The Lastenheft Is an Architecture Document — Not a Feature List
The usual practice: the Lastenheft is born as an Excel list with hundreds of requirements that one department after another contributes. In our view it is the extension of the target architecture into contract-grade requirements. Architecture before software. Treating the Lastenheft as a feature wishlist sends software into a blank spot — repaired at double cost in implementation.
2. Lastenheft (Shell), Anforderungskatalog (Core), Pflichtenheft (Response) Are Three Different Documents
In most German top-10 guides the terms blur. We separate them deliberately: the Lastenheft is the umbrella contract-grade document; the Anforderungskatalog the structured core list of requirements within it; the Pflichtenheft the vendor's technical response. Three documents, three accountabilities — anchored in the IIBA BABOK Guide (Requirements Architecture).
3. Compliance Layers 2026 Are Their Own Chapters, Not Marketing Phrases
NIS-2, EU AI Act, CSRD, GoBD — these obligation frameworks are not „naturally fulfilled" by every modern software. They demand explicit requirement chapters in the Lastenheft, with clear acceptance criteria per vendor. We regularly see Lastenhefte in which „GDPR-conformant" stands as a generic sentence — without deletion concepts, processor agreements, or authorisation models. That does not hold up in court or before an auditor.
Our reading
A Lastenheft without architecture link, without a clear three-layer separation, and without worked-out compliance chapters is a contractual risk — expensive to produce, dangerous in dispute. Architecture before software, every time.
How We Use the Lastenheft Methodically (Four-Phase Approach)
We set up the Lastenheft in four phases — architecture pre-clarification, requirements elicitation, structuring, sign-off. The order is not arbitrary: target architecture first, then requirements, then structuring as a contract document. From our experience every ERP project otherwise breaks down here.
In the vendor-neutral ERP consulting at Dreher Consulting we treat the Lastenheft as an extension of Enterprise Architecture Management (EAM) for the Mittelstand. Four phases:
- Architecture pre-clarification — process landscape map and capabilities. We load the process landscape map and business capabilities as input. Without this pre-clarification every Lastenheft starts as a wishlist.
- Requirements elicitation — structured interviews and workshops. A named process owner per core process. Requirements are written in client voice, free of vendor bias.
- Structuring — Must, Should, Could. Every requirement receives a clear priority and an architecture anchor. Master-data requirements get their own chapter because they otherwise fall under the table.
- Sign-off and contract basis — Lastenheft as annex to the contract. Management signs off, the document becomes annex to the contract, the Pflichtenheft is produced by the vendor.
Train-the-trainer in practice
We write the Lastenheft with the company, not for it. Stage 1 — we draft with the subject leads. Stage 2 — the process owners maintain it under coaching. Stage 3 — they own it independently after project end.
The methodology is anchored in the IREB CPRE Foundation Level syllabus and in VDI 2519 Sheet 1. But the Lastenheft is measured against the project — not the textbook.
Common Mistakes in Mittelstand Lastenheft Projects
Four error patterns we see repeatedly in Mittelstand Lastenheft projects. All four are avoidable if addressed before ERP selection. None of them have their root in modelling software — we have documented them across DACH machine building, kitchen manufacturers and educational-material producers.
Mistake 1 — feature list instead of architecture document. The Lastenheft is born as an Excel compilation from departments, with no link to the target architecture. Fix: architecture before requirements — process landscape map and business capabilities first.
Mistake 2 — Anforderungskatalog equals Lastenheft equals Pflichtenheft. The three documents are blurred, every accountability disappears. Fix: three-layer model — Lastenheft (shell), Anforderungskatalog (core), Pflichtenheft (response).
Mistake 3 — compliance as a marketing phrase. „GDPR-conformant" as a one-liner without acceptance criteria. Fix: separate chapters for NIS-2, EU AI Act, GoBD, CSRD — with clear acceptance criteria per vendor.
Mistake 4 — external consultants write alone. Six months after project end no one inside the company can explain the Lastenheft. Fix: train-the-trainer in three stages — model first, review jointly, then maintain independently.
Our reading
The mistakes are rarely technical. They are organisational and methodical — and that is exactly where vendor-neutral consulting earns its keep. Architecture before software, every time.
Frequently Asked Questions
The Lastenheft describes from the client perspective what is to be delivered; the Pflichtenheft describes from the contractor perspective how. VDI 2519 Sheet 1, the authoritative guideline for Lasten- and Pflichtenhefte, describes the Lastenheft as the buyer's full requirements document; the Pflichtenheft is the vendor's solution description. In the DACH Mittelstand both become annexes to the contract; in dispute the Lastenheft, not the Pflichtenheft, sets the measuring stick.
Seven mandatory chapters have become standard from our 1,200+ projects: As-Is and To-Be, functional requirements per core process, non-functional requirements (performance, security, scalability), framework conditions (GDPR, GoBD, NIS-2, EU AI Act, CSRD), interfaces and data migration, Must-Should-Could prioritisation, and an appendix with glossary and acronyms. This matches the approach prescribed by VDI 2519 Sheet 1.
Methodically the ERP project lead in a staff function owns the Lastenheft as a whole; per core process the process owner carries subject accountability. The executive board commissions and signs off, because only it can take binding decisions on architecture, investments, and contract partners. External consulting is a midwife in the first weeks, not a permanent owner — the Lastenheft must be carried internally.
Next Steps
Before any ERP selection, migration or major digitalisation decision, an eight- to twelve-week pre-clarification step pays back: process landscape map, business capabilities, Lastenheft as architecture-validated requirements document. Skipping it risks a doubly expensive re-set project after eighteen to twenty-four months.
If you want to explore these topics, the place to start is our vendor-neutral ERP selection, our ERP consulting and specifications service and our digitalisation services. We work 100 percent vendor-neutrally.
For complementary reading, our wiki entries on Anforderungskatalog, Pflichtenheft and ERP system extend the picture. Current case studies are available in our insights; for a 30-minute conversation reach us via the contact page.
30 minutes with Dreher Consulting
A structured assessment of your Lastenheft or your starting position before ERP selection — architecture link, three-layer separation and compliance chapters, vendor-neutral and drawn from over 1,200 projects in the DACH Mittelstand.
