Requirements Specification (Lastenheft)

What belongs in a requirements specification?

A good requirements specification is complete, free of contradictions and understandable for everyone involved – from the department to the vendor. It cleanly separates the description of the current state, the goals and the actual requirements. Each requirement should be unambiguous, verifiable and worded as solution-neutral as possible, so that vendors can propose their own way of meeting it.

Requirements specification vs. functional specification

The requirements specification (Lastenheft) and the functional specification (Pflichtenheft) are frequently confused, but they denote two consecutive documents with clearly separate roles. The requirements specification comes from the client and describes the requirements – the „what“. The functional specification comes from the contractor and, in response, describes the concrete implementation – the „how“. Figuratively: in the requirements specification the client states their wishes, and in the functional specification the vendor explains how they will realize them with their system.

Chronologically, the requirements specification is created first, usually during ERP selection before the tender. The functional specification follows after the vendor decision at project start and often becomes part of the contract. Only once the client signs off the functional specification is it bindingly settled that requirement and planned solution match. This two-stage approach protects both sides: the client need not prescribe technical solutions, and the vendor receives a verifiable requirements basis and documents its commitments in a traceable way.

The requirements specification in the ERP selection process

In the flow of an ERP selection, the requirements specification sits at the transition from internal requirements analysis to approaching the market. From the captured as-is processes and target goals of the departments emerges the requirements catalog, which is then sent to the shortlisted vendors. It is thus the most important link between what the company needs and what the market offers.

The practical benefit is twofold. First, the requirements specification makes bids comparable, because all vendors answer the same catalog – without this common basis you compare apples with oranges. Second, creating it forces the company to clarify its own processes and priorities; often this internal clarification process is at least as valuable as the finished document. A precise requirements specification later reduces change requests, add-ons and budget overruns, because misunderstandings become visible early. Conversely, a vague or missing requirements specification is one of the most common causes of failed or overpriced ERP implementations.

Common mistakes in requirements specifications

The most common mistake is prescribing the solution instead of describing the requirement – for example „The system must use a particular database“ instead of „Stock levels must be consistent in real time across all channels“. Such prescriptions unnecessarily constrain the vendor and forgo better standard solutions. Equally problematic are vague, unverifiable formulations such as „should be user-friendly“, which cannot be assessed objectively after the fact.

Further classics are a missing prioritization, in which every requirement appears equally important, as well as forgetting non-functional requirements such as interfaces, data migration, a roles-and-permissions concept or legal obligations. An overloaded „wish list“ with no relation to actual needs drives up costs, while a requirements specification that is too thin leaves room for interpretation that is later renegotiated expensively. A middle level of detail is sensible: precise on the business-critical processes, open enough wherever the vendor should contribute its strengths.

DACH specifics and standards

In the German-speaking region, the requirements and functional specifications are clearly defined in terminology by DIN 69901-5 (project management) and historically by the VDI 2519 guideline – a separation that often does not exist internationally, where both merge under „requirements specification“. This standardized two-part structure shapes DACH tenders to this day and is especially relevant in public procurement law, where a complete, non-discriminatory requirements specification is a precondition for a legally sound procedure.

For ERP projects in the DACH mid-market, additional content specifics belong in the requirements specification: GoBD compliance, a DATEV or BMD interface for accounting, requirements for the E-Rechnung (electronic invoice) as well as – for multiple entities – multi-tenancy. Whoever documents these points early as must-have requirements immediately filters out unsuitable systems and avoids regulatory gaps only surfacing during the implementation.