Why the requirements catalog matters in the DACH Mittelstand in 2026
Two drivers make the catalog non-optional in 2026: regulatory density (NIS-2, EU AI Act from 06.04.2026, CSRD, GoBD, BSI 200-1) and hard economics (DSAG Investment Report 2026, Trovarit 2024/25). Both layers must be documented — or they return later as supplier-rate change requests.
Managing directors in the DACH Mittelstand face double pressure in 2026. Regulation has tightened: the BSI Standard 200-1 has provided the ISMS framework since 2017; with NIS-2 transposition it becomes directly applicable for many Mittelstand companies. The EU AI Act enters high-risk obligations on 06.04.2026. CSRD and GoBD apply continuously. All belong in the catalog — or they return later as supplier-rate change requests.
Second, the economics have tightened. The DSAG Investment Report 2026 documents that 38 percent of DACH companies deploy IT budgets more selectively; close to 50 percent plan S/4HANA migration only by end of 2030. An ERP procurement in 2026 carries a long liquidity commitment — the catalog protects it.
From our experience in over 1,200 projects we have seen that 60 percent of DACH Mittelstand companies enter contract negotiations without a structured catalog — and produce six-figure change requests in year one after go-live. The Trovarit study ERP in Practice 2024/25 records a service-quality rating of 1.96 — slightly down — the indirect signal of contract gaps a sloppy catalog leaves.
Worked example: capability-based catalog at a Mittelstand kitchen manufacturer
Mittelstand kitchen manufacturer, roughly 1,500 kitchens per year in the contract-project segment, three plants, grown ERP. A capability-based catalog narrowed the vendor longlist from 11 to 3 verified candidates. The lever: strict separation of capability and feature.
We worked with a mid-sized kitchen manufacturer from southern Germany — around 1,500 kitchens per year in the contract-project segment, three plants, approximately 280 employees — and built the requirements catalog capability-based. The starting point was typical for the DACH Mittelstand: a grown ERP, three plants with local quirks, configuration depth across carcass, front, fittings and logistics sequence. The first market sounding invited 11 vendors — each replied formally with "fulfilled" without the special business models being addressed.
We re-anchored the catalog around 18 business capabilities derived from the EAM groundwork, generating 142 requirements with one binary-testable acceptance criterion each. The decisive step was not the template — it was forcing every vendor response into a case-study walkthrough where the acceptance criteria, not the marketing material, decided the next round.
The result was measurable. The vendor list narrowed from 11 to 3 verified candidates, who had to demonstrate their capability fulfilment in an end-to-end case-study walkthrough. Three vendors failed on configuration depth, four on sequence logistics, one on multi-plant booking logic. The contract contained 142 acceptance criteria — and these criteria were used at the cut-over for acceptance. The lever was not the tool but the three-layer separation and the clean alignment with the capability map from the EAM groundwork.
What most requirements-catalog guides won't tell you
Three uncomfortable truths rarely stated in the public guides — anchored on IREB CPRE-FL, VDI 2519, BSI 200-1, the DSAG Investment Report 2026, and our 1,200+ Mittelstand projects. Ignoring them means buying licence, not effect.
1. Capability vs. feature — the lever nobody shows
Most guides categorise requirements as functional, non-functional, technical, regulatory. Not wrong — but incomplete. Unlike most four-category schemes, we draw a hard line between capability (what the business must do), requirement (what the system must do for it), and feature (how a supplier solves it). The top layer comes from the EAM groundwork — without it, you compare feature lists, not capabilities, and supplier wording lands directly in the contract. From our experience in over 1,200 projects we have seen that 80 percent of DACH Mittelstand procurements start without a capability layer — and produce the most expensive change requests.
2. The 2026 compliance obligations are not a footnote — they are dedicated layers
NIS-2, the EU AI Act (high-risk obligations from 06.04.2026), CSRD, and GoBD are still handled as one "data protection" line in many 2026 catalogs. Not enough. The catalog needs four explicit layers: audit trail (BSI 200-1, GoBD); AI transparency (EU AI Act) for high-risk use cases; ESG data model (CSRD); security (BSI 200-1, NIS-2) with ISMS-conformant minimum requirements. For publicly funded procurements, the EU Procurement Directive in its consolidated 2026 version applies (thresholds 140,000 / 216,000 EUR).
3. Seven recurring DACH Mittelstand anti-patterns
Seven errors recur systematically: feature inflation (300+ lines, no prioritisation); supplier-wording copy-paste; missing interface specifications; vague data-volume statements; unclear roles and rights; missing migration requirements; no acceptance criteria. Eliminating these patterns — even without new methodology — gets you a better catalog than 80 percent of the market.
Our take
A requirements catalog is not an Excel exercise. It is the contractually load-bearing layer between business model and system solution. Treating it as a wish list buys licence, not effect — and you pay the difference twice later.
How we build requirements catalogs methodically
Four phases on every ERP procurement — capability mapping from the EAM groundwork, requirements derivation, acceptance-criteria definition, market sounding via case-study walkthrough. The frame matters more than the template.
Phase 1 — capability mapping. We start not with the requirement but with the business capability. What must the company be able to do in 2026, 2028, 2030? Which does the ERP carry? Which stay in specialist systems? Only from that map do requirements emerge — in business language, not supplier wording. The capability layer comes from the EAM groundwork; in our SCOReX® reference frame it is anchored and non-negotiable.
Phase 2 — requirements derivation. Per VDI 2519, phase two derives requirements from capabilities. A capability typically produces three to eight. We formulate each against the IREB CPRE quality criteria: unambiguous, complete, consistent, testable. A non-testable requirement is a wish.
Phase 3 — acceptance criteria. We define one acceptance criterion per requirement — quantitative or binary-testable. Instead of "the system supports variant configuration" we write: "configures a 3-row island kitchen with 24 cabinets, 4 special heights and sequence delivery in under 90 seconds response time". These become the acceptance checklist — and belong before the contract, not after.
Phase 4 — market sounding via case study. Feature lists always favour the largest marketing budget; we make candidates solve the same case-study walkthrough against our acceptance criteria. The method is documented in our consultant insights and refined across 1,200+ projects. In our work on ERP selection it is the operating basis.
Common mistakes when building a requirements catalog
Four patterns we see again and again — almost none of them method problems. Spotting them saves contract disputes and change requests after go-live.
Mistake 1 — template-first approach. The company picks an Excel template, fills it in without a capability prelude, and believes it has a catalog. In reality it has a feature list. Classic Excel lists invite supplier-wording copy-paste and resist testable structure.
Mistake 2 — unclear modelling depth. Some model every click (300+ lines, unreadable); others sit at 30,000 feet (untestable). Neither carries contract value. We use three layers with at most four modelling levels per layer.
Mistake 3 — missing interface and master-data specification. A catalog without data-volume, frequency, and error-behaviour statements in interfaces is paper. We profile data quality before the catalog — especially master data — and write hard thresholds into it.
Mistake 4 — missing logic check. Requirements often contradict each other. The catalog must pass a logic check — correlations and causal links surfaced. In our projects we repeatedly see suppliers exploit those gaps once the contract is signed. The German Digital Trades guide, the Asana documentation guide, and the VDI 2519 standard describe the same discipline.
Frequently asked questions
The catalog is the core; the Lastenheft is the wrapper; the Pflichtenheft is the supplier's response. Per VDI 2519 Sheet 1, the Lastenheft is the buyer's full requirements document — catalog plus boundary conditions, project structure, contract clauses. The Pflichtenheft describes how the supplier intends to implement. Using the three terms interchangeably lets the supplier define fulfilment. We keep the catalog as a standalone document and embed it inside the Lastenheft.
A blanket line count is the wrong metric. The IREB CPRE-FL syllabus sets no volume target. From our projects, Mittelstand catalogs run 80 to 200 requirements per business unit, derived from 12 to 25 capabilities. Testability is the decisive metric. 500 requirements without acceptance criteria is a wish list. 142 with one clear acceptance criterion each is a contract. At the kitchen manufacturer at 1,500 kitchens per year we landed on 142 requirements from 18 capabilities — typical for the DACH Mittelstand.
The executive board defines the capability layer — what the company has to be able to do in 2028 and 2030. Business units derive the requirements and acceptance criteria. IT checks technical consistency and interfaces. The DSAG Investment Report 2026 shows that mandate clarity is the central lever for selective IT investment. Without a board mandate the catalog becomes a wish list; without business participation it becomes an IT document. We recommend a tandem of board (capability mandate), business unit (requirements), and IT (consistency and integration).
From our experience in over 1,200 projects with DACH Mittelstand companies the alignment in 2026 takes a concrete form: NIS-2 obligations (BSI 200-1 derived) and the EU AI Act (in force 06.04.2026) appear as explicit catalog line items rather than as footnote risks. We recommend documenting transparency, audit trail, data-residency and human-in-the-loop requirements at the same level of detail as functional requirements. In our practice this prevents the typical late-stage compliance scramble during vendor selection.
Next steps
A solid catalog starts with the capability map, not the Excel template. Begin with a stock-take: is a capability map in place? Are the compliance obligations (NIS-2, EU AI Act, CSRD, GoBD) identified as dedicated layers? Is there a testable acceptance criterion per requirement? Dreher Consulting has guided DACH Mittelstand companies through ERP procurements since 1992 — from ERP consulting through the Lastenheft to implementation. More than 1,200 ERP projects stand behind the method. Background on the broader methodology is in our Insights.
30 minutes with Dr. Dreher
A structured assessment of your current catalog or starting position — vendor-neutral, drawing on 30+ years of project practice.
