Häufig gestellte Fragen
What is the difference between a requirements document (Lastenheft) and a functional specification (Pflichtenheft)?
The requirements document describes, from the customer's perspective, what the future ERP system is expected to deliver, and is drawn up before vendor selection. The functional specification then answers, from the vendor's perspective, the question of how these requirements will actually be implemented. The sequence is therefore fixed: first the requirements document, then the selection, then the functional specification. The requirements document alone is not legally binding, whereas a functional specification becomes binding as soon as it forms part of the contract.
Who writes the requirements document — IT or the business departments?
In practice the two work together: the functional requirements come from the business departments, the technical and integration aspects from IT. A project manager consolidates both perspectives, frequently supplemented by external consultants. A requirements document written purely by IT or purely by the business regularly leads to gaps, for instance around interfaces or special processes that are not covered. Involving the users early also increases later acceptance of the system.
How long should an ERP requirements document be?
In the mid-market, 50 to 150 pages plus a requirements catalogue are typical, while larger corporate groups often reach several hundred pages. More important than sheer length, however, is substantive precision: better a concise document with clearly prioritised requirements than a bloated catalogue without weighting. Anyone who prescribes every single screen unnecessarily restricts the vendors' sensible standard processes and drives up costs. A realistic balance between completeness and openness — as detailed as necessary, as open as possible — is decisive.
How should requirements be prioritised in the requirements document?
A common approach is to classify requirements as must, should and could criteria, or alternatively to use the MoSCoW method with the levels Must, Should, Could and Won't have. This weighting facilitates an objective vendor comparison and prevents minor wishes from dominating the decision. It is crucial that must criteria really are indispensable — if almost everything is marked as a must, no actual prioritisation takes place. Legally mandatory requirements, for instance on unalterable, audit-proof archiving in accordance with the GoBD, fundamentally belong to the non-negotiable must criteria.
How long does it take to create an ERP requirements document?
Depending on complexity, the actual writing usually takes several weeks, since interviews with the business departments, an as-is analysis, the target definition and internal alignment all take time. Adding the upstream planning and coordination phase, mid-sized companies should realistically allow several months, and correspondingly more for complex structures. If the work is supported externally, additional consulting costs arise, which depending on the scope can be in the low to mid five-figure range. However, the effort usually pays off over the further course of the project, because it avoids expensive wrong decisions and subsequent customising.
Do I need a requirements document if I want standard cloud software?
Even with standard-oriented SaaS solutions, a requirements document is worthwhile, but then with a focus on business requirements, interfaces and non-functional topics rather than exhaustively detailed functional fields. It helps to select the right standard solution instead of demanding expensive customisations that cancel out the cloud advantage. Licence fees account for only part of the total costs anyway — the larger share arises from implementation, customising, training and data migration. It is precisely these items that can be managed far better with a clear requirements document.
Is a requirements document template useful, or is it better to write freely?
A template — frequently an Excel or Word file with a pre-structured requirements catalogue — saves time and ensures that no important subject areas are overlooked. However, it does not replace the company-specific work: standard lists have to be adapted to your own processes, volumes and special cases, otherwise the result is a generic document without real substance. A proven approach is a table organised by business department that contains a priority and a response field for the vendors for each requirement. That way the structure remains comparable while the content stays individual.