ERP Requirements Document — Requirements Document for ERP Projects
An ERP requirements document, known in the German-speaking market as the Lastenheft, is the client-side specification that describes what an organisation expects an ERP system to deliver. It captures business processes, functional and technical requirements, integration needs and acceptance criteria in a structured, vendor-neutral form. Compiled before any product is chosen, it provides the common reference against which prospective systems and implementation partners are evaluated. The requirements document is the foundation for the tender, for comparing offers on a like-for-like basis, and later for the supplier's response in the functional specification. A clear document reduces scope disputes and keeps the selection objective.
- Term
- ERP Requirements Document (Lastenheft)
- Entity type
- Master-data artefact
- Domain
- ERP selection and project documentation
- Canonical definition
- An ERP requirements document is the client-authored specification that describes the functional, technical and organisational requirements an ERP system must satisfy, serving as the neutral basis for vendor selection and tendering.
- Classification
- Belongs to the project-documentation phase that precedes product selection, paired with the supplier's functional specification.
- Related terms
- Functional specification, ERP, ERP migration, Customising, Data migration, TCO of ERP
- Source / maintainer
- erp-software.org editorial team (independent, vendor-neutral)
What ERP Requirements Document (Lastenheft) is NOT — disambiguation
- Not the functional specification: The requirements document states what the client needs, whereas the functional specification describes how a chosen vendor will deliver it.
- Not a contract: It informs and is referenced by the contract but is itself a description of requirements, not the legally binding agreement.
- Not a project plan: It defines scope and requirements rather than schedules, milestones or resource allocation.
- Not customising configuration: It precedes any setup work and does not contain product-specific configuration settings.
Purpose and role in ERP selection
The requirements document answers the question "what do we need?" rather than "how will it be built?". It is authored by the buying organisation, often with help from internal departments and independent consultants, and is deliberately product-agnostic so that several vendors can respond to the same brief. In a typical ERP project it precedes the request for proposal, accompanies the shortlist process, and is referenced throughout contract negotiation. Because it defines the agreed scope, it also serves as a baseline for change control: anything requested later that is not in the document can be identified and priced as an extension.
Typical contents
While there is no single mandatory format, a thorough requirements document usually covers:
- Organisational context, goals and the reasons for replacing or introducing a system, including links to any ERP migration plans.
- As-is and to-be business processes across the relevant areas such as sales, procurement, production and finance.
- Functional requirements per module, often prioritised as mandatory, important or optional.
- Non-functional requirements: performance, availability, security, the intended role concept and data protection expectations.
- Interface and integration requirements, for example to existing systems via a REST API or established exchange formats.
- Data volumes, migration scope, reporting needs and acceptance criteria.
Distinction from the functional specification
The requirements document and the functional specification are complementary but distinct. The requirements document states the client's needs; the supplier then responds with a functional specification that explains how those needs will be met within a specific product. Treating the two as the same artefact is a common source of confusion. Keeping them separate makes responsibilities clear: the buyer owns the requirements, the vendor owns the solution design, and both documents together form the contractual description of what will be delivered.
Good practice
A useful requirements document is specific without prescribing a particular implementation, measurable where possible, and prioritised so that essential capabilities are not lost among nice-to-haves. Requirements should be traceable, each with an identifier that can be followed through evaluation, contract and acceptance testing. Involving the people who will actually use the system improves accuracy, while a neutral structure keeps vendor comparisons fair. Over-specifying technical detail can narrow the field of suitable products prematurely, so the focus should remain on outcomes and processes rather than on dictating internal architecture.
Related Topics
Frequently Asked Questions
Who writes the ERP requirements document?
The buyer owns the document. Practically, the central project lead drafts it together with key users from every affected business area (purchasing, production, finance, HR, IT). External consultants typically facilitate workshops, provide templates and benchmarks, and challenge wish-list thinking — but the buyer must sign off on every requirement, otherwise vendor scoring becomes indefensible.
How long should an ERP requirements document be?
For mid-market ERP procurement: typically 80–150 pages of narrative plus a functional-requirements catalogue with 300–1,200 line items. Larger enterprises easily reach 300+ pages. The functional catalogue is the document that vendors actually answer point-by-point; the narrative is read once for context. Keep the catalogue testable and the narrative concise.
Can we use vendor templates for the requirements document?
Vendor templates produce vendor-biased requirements — the template will reflect what that vendor does well. Use them as a checklist, not as the source. Better starting points: industry-association templates (VDMA for engineering, BVL for logistics), the GPM-IPMA project management standards, and structured catalogues from independent ERP consultants who maintain cross-vendor benchmarks.