ERP Requirements Document — The Requirements Document
The Requirements Document — or requirements document — is the cornerstone artefact of any disciplined ERP selection. It captures what the business needs from the new ERP, in enough detail and structure to drive vendor evaluation, RFP scoring, demo design and eventually the implementation scope. Skipping or rushing the Requirements Document is the most common reason mid-market ERP projects later find themselves in scope renegotiations and budget overruns.
Structure of a Requirements Document
A workable Requirements Document has six sections. (1) Company context — business model, organisational structure, key metrics, sites, languages, regulatory environment. 5-10 pages. (2) Process overview — end-to-end operational processes (order-to-cash, procure-to-pay, plan-to-produce, record-to-report) at a level any vendor can understand. 10-25 pages. (3) Functional requirements — the largest section, broken into ERP-module sub-sections (financials, sales, purchasing, inventory, production, etc.). 30-80 pages. (4) Non-functional requirements — performance targets, availability, security, regulatory (GoBD, GDPR, NIS-2, industry-specific). 5-10 pages. (5) Integration landscape — existing systems the new ERP must connect to, data flows, APIs. 5-15 pages. (6) Constraints and preferences — cloud vs on-premises, technology preferences, timeline constraints, budget envelope, geographic considerations. 2-5 pages. Total: 60-150 pages for typical mid-market.
Depth of detail
The right depth balances clarity against analysis paralysis. For each functional area, document: process flow (half-page narrative or BPMN diagram), key requirements (5-30 bullet points of must-have, should-have, could-have items), data volumes and frequencies (thousands of transactions per month, peak periods), integration touchpoints (which other systems hand off here), regulatory considerations (GoBD relevance, GDPR personal data, industry rules). Avoid: writing the requirements as the current system's screen-by-screen behaviour — this anchors the new system to the legacy one and reduces vendor creativity. Avoid: vague statements like 'must be modern' or 'must be user-friendly' that cannot be assessed.
How the Requirements Document is used
The Requirements Document drives four phases. (1) Vendor pre-qualification: filter long-list of 8-15 vendors against high-level fit; reduce to 4-6 for RFP. (2) RFP: convert MUST and SHOULD requirements into structured questionnaire for vendors to respond against. (3) Demo design: build scripted demo scenarios that exercise the highest-priority requirements through the vendors' systems. (4) Implementation contracting: the Requirements Document becomes the contractual basis of scope. Significant deviations during implementation get tracked as change requests against the original Requirements Document. The same document carries the project from early analysis through go-live.
Practical recommendations
(1) Let business operators write the operational sections. Finance leads on financials, sales operations leads on sales, etc. The Requirements Document is not an IT artefact — IT plays editor and architect, not author. (2) Use MUST/SHOULD/COULD prioritisation throughout. The 80/20 rule applies: 20% of requirements drive 80% of vendor differentiation. (3) Keep the document version-controlled and reviewed by the steering committee at each major iteration. (4) Translate to the vendors' working languages if needed — for DACH mid-market, German plus English typically covers all relevant vendors. (5) Plan 30-90 days of focused effort. Less than 30 days produces shallow requirements; more than 90 days produces over-analysed requirements no vendor can map cleanly.
Related Topics
Frequently Asked Questions
Lastenheft versus Pflichtenheft — what is the difference?
Lastenheft is the buyer's document — what the business needs. Pflichtenheft is the implementer's document — how the chosen system will deliver against those requirements. The Lastenheft is written first by the buyer; the Pflichtenheft is written by the implementation partner once the vendor is chosen and forms the implementation contract scope.
Can we use a template Lastenheft?
Templates from consultancies (BearingPoint, GSP, Sopra Steria) and industry associations (VDMA for machinery, BDS for distribution) provide a useful starting structure. The functional sections still require company-specific content — copying a template Lastenheft unedited produces a document that vendors recognise as generic and respond to with generic answers.
How does Agile fit with a heavyweight Lastenheft?
Agile ERP implementations still need a Lastenheft for vendor selection and scope agreement. The Agile flexibility happens during implementation — iterations, MVP-first delivery, continuous prioritisation — not during selection. Skipping the Lastenheft because the implementation will be Agile is a misunderstanding of how Agile works in regulated, multi-year ERP projects.