Skip to main content

Requirements Document (ERP)

An ERP requirements document is the structured specification of what a company needs from its future ERP system — functional requirements by process area, non-functional requirements such as integrations and security, and the constraints of budget and timeline. It is the backbone of a disciplined selection: it feeds the RFP, scripts the vendor demos, anchors the fit-gap analysis, and typically ends up as an exhibit to the implementation contract. Projects that skip it tend to select on demo charisma and discover their real requirements during implementation, at change-order prices.

What belongs in the document

A workable structure has four parts. Context: business model, locations, legal entities, user counts, and volume metrics — order lines per day, SKUs, invoices per month. Vendors size and price on these numbers, so they belong up front. Functional requirements by process area: finance and accounting, order-to-cash, procure-to-pay, manufacturing, warehouse and shipping, service — written as business outcomes, not screen descriptions. Non-functional requirements: integration landscape and APIs, data migration scope, security and compliance expectations (for SaaS candidates, a current SOC 2 Type II report), reporting and analytics, performance, and hosting policy. Constraints: budget range, target timeline, internal resource availability. A full walkthrough with section-by-section guidance is at ERP requirements document, and a ready-to-use starting point at ERP requirements document template.

MoSCoW prioritization

MoSCoW sorts every requirement into Must have (the project fails without it), Should have (important, workaround exists), Could have (desirable), and Won’t have this time (explicitly deferred). Two rules of thumb keep it honest. First, if more than roughly a third of all requirements are Musts, prioritization has not actually happened — a Must should be defensible with a concrete business consequence, not a preference. Second, the Won’t category is not filler: writing down what is out of scope prevents the quiet scope creep that inflates mid-market implementations. Some teams prefer weighted scoring (1–5 per requirement); either works, as long as vendors can see which requirements decide the deal.

Role in the RFP process

The requirements document is the core of the request for proposal. Vendors respond per requirement on a defined scale — standard functionality, configuration, partner add-on, customization, or roadmap — and the pattern of those answers is a selection signal in itself: a vendor answering yes to every line has not read the document. The Must-have requirements then become the demo script: scripted demonstrations with your own scenarios and sample data expose gaps that free-form feature tours are designed to hide. After selection, the document and the vendor’s responses typically become a contract exhibit, which turns optimistic sales answers into commitments. The step-by-step process is covered in the ERP RFP process guide.

Fit-gap analysis

Fit-gap maps each requirement against the candidate system’s standard functionality — first at evaluation depth during selection, then in detail during implementation design. Every gap gets an explicit disposition: change the business process to fit the standard, configure, adopt a partner add-on, integrate a third-party product, or customize. The disposition mix drives long-term economics, because customizations carry ongoing test and upgrade cost across the system’s life — a total-cost question rather than a license question (see TCO of ERP; the ERP TCO calculator lets you model it). A healthy mid-market fit-gap resolves most gaps through process change and configuration and reserves customization for genuine competitive differentiators.

Common mistakes

Four recur across US mid-market projects. The 1,500-row checklist: exhaustive feature lists that every vendor answers with yes produce no differentiation and exhaust the team that writes them. Documenting the legacy system: writing requirements as descriptions of current screens re-implements the old system on new technology, including its workarounds. Deferring non-functional requirements: integrations, data migration, and security surface at contract stage as expensive surprises when they are left out of the document. No prioritization: when everything is equally important, every fit-gap finding becomes a negotiation crisis instead of a triaged decision.

Selection criteria for US buyers

  • Aim for 100–300 differentiating requirements: document what separates your business from a generic one in your industry; assume standard ERP capabilities exist without listing them.
  • Give every Must an owner and a consequence: a named process owner who can explain what breaks without it — this keeps the Must list short and defensible.
  • Let process owners write, not only IT: requirements drafted solely by IT or an external consultant miss the operational detail that decides daily usability.
  • Include integration, migration, and security from day one: these areas drive more budget variance than functional gaps in most mid-market projects.
  • Reuse the document downstream: as demo script, as scoring sheet, and as contract exhibit — one artifact, three uses, and vendors know their answers will bind them.
  • Start from a template, then cut: adapting a proven structure such as the requirements document template is faster than starting blank — the discipline lies in deleting what does not apply.

Comparable terms

An RFI (request for information) precedes the RFP and screens the market with a lighter question set. The RFP is the full request package in which the requirements document is the central section. A statement of work (SOW) defines the implementation scope with the chosen partner after selection. A BRD or functional specification details individual requirements at implementation depth. Fit-gap analysis is the method that connects the requirements document to a specific product’s standard functionality.

Related Topics