The ERP Requirements Document
The requirements document — also called the requirements specification — is the cornerstone artifact 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, organizational 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 (SOX internal controls and IRS recordkeeping, CCPA/CPRA and state privacy laws, cybersecurity, 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 a typical mid-market company.
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 (SOX and audit relevance, revenue recognition under ASC 606, personal data subject to CCPA/CPRA and other state privacy laws, sales-tax and economic-nexus handling, 1099 reporting, industry rules such as HIPAA or FDA 21 CFR Part 11). Avoid: writing the requirements as the current system's screen-by-screen behavior — 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 a long-list of 8-15 vendors against high-level fit; reduce to 4-6 for the RFP. (2) RFP: convert MUST and SHOULD requirements into a 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 artifact — IT plays editor and architect, not author. (2) Use MUST/SHOULD/COULD prioritization 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 most US mid-market projects English is sufficient, with Spanish a consideration for multi-site or cross-border operations. (5) Plan 30-90 days of focused effort. Less than 30 days produces shallow requirements; more than 90 days produces over-analyzed requirements no vendor can map cleanly.