Skip to main content

ERP Requirements Document — a concrete example

An ERP requirements document is the buyer's definition of what the future system must do, written before vendor demos and shaped without reference to any specific product. This page shows what such a document actually looks like — the 12 chapters that a mature US mid-market template uses, the MoSCoW prioritization discipline that prevents the requirements list from growing into wish-list theater, and an extract from a real requirements catalog with the kind of entries vendors can answer cleanly.

The companion template that you can copy and fill in lives at /en/erp-requirements-document/. This page is the worked example.

The 12-chapter structure

A complete requirements document for a US mid-market ERP project covers twelve chapters. Skipping any of them creates a vendor-side opportunity to over-promise and under-deliver later.

  1. Project context — company profile, headcount, revenue, sites, key business model facts
  2. Project goals — the three to five outcomes the migration must achieve, with measurable success criteria
  3. Scope and out-of-scope — the modules and processes that belong in the project, and the explicit list of those that do not
  4. As-is process landscape — the current ERP, the surrounding systems, the major interfaces, the pain points
  5. Target processes — the future-state process map at the level of detail the project requires
  6. Functional requirements — the structured catalog, organized by module
  7. Non-functional requirements — performance, availability, security, data residency, languages, accessibility
  8. Technical requirements — deployment model preference, integration patterns, API standards, browser support
  9. Volumes and growth — users, transactions, master-data counts, expected growth over the contract horizon
  10. Implementation expectations — timeline, methodology preference, training, hypercare
  11. Commercial framework — total budget envelope, license model preference, contract term, exit clauses
  12. Evaluation criteria — the weighted scorecard against which vendor offers will be assessed

MoSCoW prioritization

Every functional requirement carries a priority tag: Must, Should, Could, Won't.

  • Must — non-negotiable, a vendor that cannot meet it is out of the running
  • Should — important, but a vendor with a credible workaround or roadmap commitment can stay in
  • Could — nice to have, contributes to the score but does not by itself eliminate
  • Won't — explicitly out of scope for this phase, included only to prevent re-litigation

The realistic distribution in a mature requirements document is roughly 15–25 % Must, 35–45 % Should, 25–35 % Could and 5–15 % Won't. Documents with 60 % Must are wish-lists; documents with 5 % Must lack the discipline to make a real choice. The Must threshold is the lever buyers use to widen or narrow the long-list during selection.

Extract from the requirements catalog

The requirements catalog itself is a structured table, usually maintained in Excel or a requirements tool, with one row per requirement. Fields per row: ID, module, sub-module, requirement statement, priority (MoSCoW), rationale, acceptance criteria, vendor response, vendor evidence.

A short extract from the financial-accounting section of a sample document:

  • FI-001 (Must): The system shall ship with a configurable, US GAAP-ready chart of accounts and allow company-specific accounts and account groups to be defined and mapped via a maintainable mapping table, with dimensions (location, department, project) captured independently of the natural account. Acceptance: vendor demonstrates a customized chart of accounts active in a sandbox tenant within 30 minutes.
  • FI-012 (Must): The system shall produce a complete, tamper-evident audit trail covering every posting, with timestamp, user, source-document reference and immutable audit-record storage, supporting SOX internal-control and IRS record-retention requirements (financial records retained at least seven years). Acceptance: audit trail extracted for a sample period passes review by the company's external auditor or CPA.
  • FI-024 (Should): The system shall support automated general-ledger and journal export in standard formats (CSV, IIF, or API) for monthly handover to the external accounting firm and for 1099 vendor-reporting data. Acceptance: live export to the firm's tax/accounting software demonstrated in the vendor demo.
  • FI-031 (Should): The system shall produce structured electronic invoices for federal government (B2G) submission via the Invoice Processing Platform, and support emerging interoperability standards (Peppol / DBNAlliance) for B2B exchange. Acceptance: a sample structured invoice validated against the target portal or network schema.
  • FI-047 (Could): The system shall support multi-GAAP parallel ledgers for US GAAP and IFRS reporting within the same legal entity. Acceptance: documented in vendor reference architecture.

Each entry follows the same structure: testable statement, clear priority, explicit acceptance criterion. Requirements written as ‘the system should be user-friendly’ are unscorable and waste space.

Typical requirements-document mistakes

Three failure patterns appear in almost every weak requirements document. Vendor-feature transcription: requirements that read like a feature list from the incumbent vendor's product sheet rather than from the customer's business. The fix is to write requirements in business language and let vendors map their features to them, not the other way round.

Aspiration creep: teams add requirements that the current business does not need but that ‘might one day be useful’ — AI, blockchain, IoT, predictive analytics. Each adds shortlist-narrowing pressure and rarely buys real business value. The discipline is to demote them to Could or Won't.

Process underspecification: the chapter on target processes ends up at a level of detail that vendors cannot scope against. The result is a fixed-price implementation offer that turns into time-and-materials within three months of project start. The fix is process diagrams plus a process narrative, validated by key users from each affected department before issuing the document.

How the requirements document fits into the RFP process

The requirements document is the input to the RFP, not a substitute for it. After issuing the document, the buyer sends it (with covering RFP letter, evaluation criteria and submission instructions) to the long-list, holds an optional Q&A round, receives vendor offers, scores them and narrows to a short-list for demos. The detailed mechanics live in our ERP RFP process guide and the full template at /en/erp-requirements-document/.

The document remains a living artifact through implementation: it is the reference for fit-gap analysis, the baseline for change-request governance and the basis for hypercare acceptance. Buyers that treat the requirements document as a vendor-selection asset only and then file it after signature systematically lose change-control battles.

Related Topics