ERP Requirements Document — Requirements Document for ERP Projects
Definition: An ERP requirements document — in German Requirements Document — is a customer-side document that structures the functional, technical and organisational requirements for a new ERP system. It is the basis for vendor selection, for the supplier's later Pflichtenheft (functional specification) and for the contractual statement of work.
A well-prepared requirements document decisively shapes the success or failure of an ERP project. It forces the buyer to articulate target processes, weak points and strategic goals before approaching vendors — and that is what creates comparability and accountability in vendor responses.
Requirements document vs. functional specification
DIN 69901-5 draws a clean line between the two: the Requirements Document describes the what from the buyer's perspective — which requirements need to be met. The Pflichtenheft describes the how from the vendor's perspective — with which means, architecture and configuration the requirements will be met. Functional specifications typically follow on from the requirements document and are written by the chosen vendor.
In English-speaking RFP processes the equivalent pair is requirements document (sometimes called RFP requirements) and the vendor's solution-design document or statement-of-work. The principle is identical: separate buyer's needs from vendor's answer.
Structure of an ERP requirements document
A proven structure:
- Company description and business model
- Goals and constraints of the project
- As-is analysis of the existing system landscape
- To-be processes with functional requirements per module (purchasing, sales, production, warehouse, finance, HR)
- Non-functional requirements: performance, security, availability, compliance (GDPR, GoBD), multilingualism, multi-tenant capability
- Interfaces and integrations (DATEV, EDI, BI, web shops)
- Sizing (users, document volumes, data volumes)
- Technical requirements (cloud / on-premises, mobile capability, browser support)
- Vendor requirements (industry knowledge, references, support)
- Scoring model and selection process
Requirements catalogue and scoring
Functional requirements are usually formulated as a structured catalogue — commonly an Excel or database-driven questionnaire. A classification is standard: must (knock-out criterion), should (desired, weighted) and could (optional). Vendors answer each item with standard, configuration, customisation or not possible. The aggregate forms a weighted scoring matrix, complemented by workshops, use-case demos and reference-customer visits.
Critical point: requirements must be testable. Instead of the system should be fast, write order entry in under two seconds with 200 concurrent users. Vague requirements produce vague vendor answers and worthless scoring.
Success factors and common mistakes
Success factors: close involvement of business departments, clear prioritisation, realistic level of detail, separation of standard and special requirements, a valid as-is documentation.
Common mistakes: wish-lists without prioritisation, copied off-the-shelf catalogues with no relation to the company, missing non-functional requirements, unclear sizing. External support from an experienced ERP consultant is recommended — not to write the document for you, but to bring discipline and benchmark knowledge to the process. The buyer must own the document, otherwise vendor responses cannot be defended internally.
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.