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.

Häufig gestellte Fragen

What is the difference between a requirements document (Lastenheft) and a functional specification (Pflichtenheft)?

DIN 69901-5 clearly separates the two documents: the requirements document (Lastenheft) describes the totality of the requirements for deliverables and services specified by the customer — the what and the why — and is created by the ERP user before vendor selection. The functional specification (Pflichtenheft) contains the implementation specifications drawn up by the contractor on the basis of the requirements document, and thus answers the how and the with-what. In practice, the customer sends the requirements document to several bidders, each of which then produces a functional specification. Both documents become part of the contract once they are contractually incorporated, which is why the functional specification should be formally signed off by the chosen vendor.

Who in the company should create the ERP requirements document?

Responsibility lies with the customer, usually with a cross-departmental project team drawn from IT, business departments and management, sometimes supplemented by external consultants. The key users from the business departments contribute the majority of the functional requirements, as they know the operational processes best. Involving the business departments too late is among the most common mistakes and leads to costly change requests. Broad involvement that starts early also increases acceptance of the future system in day-to-day operations.

How long does it take to create an ERP requirements document?

For mid-market projects with roughly 50 to 200 users, three to six months are realistic, while larger or more complex projects can take six to twelve months. Most of that time is needed for collecting, structuring and prioritising the requirements from all business departments. Requirements documents produced in a very short time usually remain too superficial and do not provide a reliable basis for comparison. The apparent extra effort pays off, because vendors quote more accurately against a precise requirements document, reducing later budget deviations.

How are the requirements in the document prioritised?

The MoSCoW method has proven itself, dividing requirements into Must-have, Should-have, Could-have and Won't-have. As a rule of thumb, the must-have requirements should account for no more than around 60 percent of the total effort, as a higher share endangers project success; Should-have typically sits at 20 to 30 percent, and a buffer of about 20 percent should be planned for the Could-haves. In addition, each requirement is given a numerical weight for the subsequent evaluation matrix, in which a vendor's total score is calculated as the weighted sum of weight and degree of fulfilment. Without clear prioritisation, the requirements document becomes an arbitrary wish list and the selection outcome loses credibility.

Should I engage an external consultant for the requirements document?

For investments above 250,000 EUR, experienced selection advisory support is often worthwhile, because it avoids expensive lessons and significantly speeds up the process. Licence fees typically account for only 25 to 35 percent of total project costs; the remaining 65 to 75 percent goes to implementation, customising, training and data migration. It is important that the consultant works independently and vendor-neutrally, so the requirements document is not skewed in favour of one system. Cloud models lower the initial investment but shift costs permanently into ongoing operating expenses.

How far may the requirements document predetermine which vendor wins?

The requirements document should be worded in an industry-neutral way and avoid vendor-specific terms or architectures, as the selection otherwise becomes contestable and individual bidders are given improper preference. It fundamentally describes only the what and the why, never the how, and leaves the concrete solution to the bidder. A robust selection combines the requirements document with a demo based on your own data, reference visits to comparable companies and a proof of concept on two or three critical processes. Since the requirements document becomes part of the contract when contractually incorporated, clean, neutral wording also creates legal clarity for both sides.