ERP Requirements Gathering

Why ERP requirements turn into wish lists

Ask a department what it wants from a new ERP and you will usually get one of two answers: "everything the current system does" or a long list of features someone saw in a demo. Neither is a requirement. Both lead to the same outcome: a document that every vendor claims to meet, that nobody can prioritize, and that gives no real basis for choosing between platforms.

The common symptoms are easy to spot:

• requirements written as solutions, such as "a dashboard" rather than the decision it should support;
• everything marked as critical, so nothing is;
• old workarounds carried forward as if they were business rules;
• missing non-functional needs, so security, audit and performance are discovered late;
• no owner, so nobody can say whether a requirement is still valid.

Good ERP requirements gathering fixes this at the source. Each requirement states a business need, names the person accountable for it, and explains what happens if it is not met. That last question is the fastest way to separate a genuine must-have from a preference. If you have not yet done the underlying discovery, start with ERP business analysis, then move to requirements.

Functional and non-functional requirements

I split requirements into two families and treat both with the same care.

Functional requirements describe what the ERP must do. They are organized by process, for example: create a quotation with customer-specific pricing; block a sales order when a credit limit is exceeded; receive partial deliveries against a purchase order; track batch or serial numbers; post intercompany transactions; produce a project profitability report.

Non-functional requirements describe how the system must behave. They are often missed and frequently decide the platform choice:

• roles, permissions and segregation of duties;
• audit trails and document retention;
• data hosting location and privacy obligations;
• multi-company, multi-currency and multi-language support;
• performance at your expected transaction volumes;
• integration methods, such as APIs or file exchange;
• support, backup and upgrade expectations.

For a practical starting list across modules, my ERP requirements checklist covers the areas most businesses need to think about. The checklist is a prompt, not an answer: your own requirements must come from your processes.

MoSCoW prioritization in practice

Prioritization is where requirements gathering earns its value. I use MoSCoW because business owners understand it without training:

I run prioritization with the process owner, not the loudest voice in the room, and I challenge any Must that cannot explain its consequence. The Won't category matters too: writing down what is deliberately excluded protects the project from scope creep and gives vendors an honest picture.

A prioritized list makes later steps far easier. It drives the scoring weights in an ERP evaluation, focuses the gap analysis on what really matters, and tells the implementation team where to spend effort first.

Requirement traceability from goal to test

Requirements change during an ERP program. Some are refined, some are split, some are dropped when a better process is agreed. Without traceability, those changes happen silently and nobody can later explain why a feature exists or why something the business expected is missing.

I maintain a traceability matrix that links each requirement to:

• the business objective it supports;
• the process step where it applies;
• its owner and priority;
• its fit-gap result on the chosen platform;
• the design decision that addresses it;
• the UAT test case that proves it works.

This sounds administrative, but it is one of the most useful control tools in an ERP project. When a vendor says scope has grown, you can show what was agreed. When a tester finds a problem, you can see which requirement and owner it affects. When leadership asks whether the project still serves its original goals, the answer is on one page.

The same matrix becomes the backbone of the requirements chapter in a business requirement document and the acceptance criteria used in ERP testing and UAT.

Why independent requirements gathering matters

When a vendor gathers your requirements, there is a natural pull toward describing needs in terms its product already handles well. That is not dishonest, but it quietly narrows your options before you have compared anything. Requirements written by an independent consultant describe your business, not a product, so every platform is tested against the same neutral standard.

Not sure which ERP you need? Do not choose software first. Write down what the business needs, agree the priorities, and only then look at platforms. The vendor conversations that follow are shorter and more useful, because you are asking them to prove specific things rather than watching a general demo.

You also keep ownership. The requirement set is your document, in a format you can reuse for an ERP RFP, a vendor shortlist or an internal build. If you would like a second opinion on requirements you already have, I can review them as a short, fixed-scope piece of work. Get in touch to discuss it.