ERP requirements should describe how business events become controlled outcomes across roles and systems. Start with an end-to-end process, then specify decisions, data, controls, exceptions and evidence. A feature name is not a requirement until it supports an observable scenario.
Use requirements to expose operating choices before configuration. This reduces the risk of copying inconsistent legacy steps into a more integrated platform.
Select the process and boundary
Name the start event, end outcome, customers, roles, locations, entities and systems involved. For order to cash, the boundary might begin with an accepted order and end with allocated cash and resolved exceptions—not merely an invoice screen.
Record what is outside scope and which adjacent process owns it. Ambiguous boundaries create duplicate requirements and unowned hand-offs.
Observe the current process without preserving it
Trace representative transactions and difficult exceptions. Capture decisions, approvals, re-entry, waiting, reconciliations and workarounds. Separate business policy from limitations of the current software.
Ask why each step exists and what evidence proves it is complete. A control may need to remain while its manual implementation can change.
Write event-based scenarios
| Element | Order-to-cash example |
|---|---|
| Trigger | approved customer order received |
| Starting data | customer, terms, items, price, availability and tax context |
| Roles | sales, credit, fulfilment, finance and manager |
| Normal outcome | fulfilled, invoiced and reconciled transaction |
| Exception | credit hold, partial fulfilment, return or disputed payment |
| Evidence | status, approvals, entries and control totals |
Express rules and decisions
State who may decide, what information they use, the allowed outcomes and the retained evidence. Replace “supports credit management” with the conditions that place an order on hold, who can release it and how the decision appears in audit and downstream processing.
Keep policy decisions visible. Configuration workshops should not silently invent approval limits or ownership rules.
Define the data contract
For every scenario, name the authoritative objects and identifiers, required quality, creation and change rights, retention and downstream consumers. Mark fields needed for execution separately from fields wanted for later analysis.
Include migration and interface behavior: mapping, validation, rejected records, retries, timing and reconciliation. “Integrates with CRM” is not testable without direction, event, identifier and failure path.
Specify non-functional outcomes in context
Link performance, availability, recovery, security, privacy and accessibility to the process. State volumes, peak windows, role locations, response needed for a decision and acceptable recovery point.
A generic requirement such as “fast” or “highly available” cannot guide design or acceptance. A close process may have a different critical window from routine inquiry.
Prioritise with consequence
Classify a requirement as mandatory only when failure would block the target outcome, violate a control or create unacceptable risk. Record the consequence and owner. Preferences can be scored later; unresolved policy stays a decision, not a software requirement.
Group requirements by scenario so a shortlist cannot score well by collecting many minor features while failing an end-to-end process.
Run a requirements workshop that produces decisions
Bring the process owner, experienced users, control owner, data/integration representatives and implementation lead around one scenario. Walk the event and exception with evidence from current work. Stop when participants use the same term differently or cannot name authority; record the decision rather than converting disagreement into several requirements.
After the workshop, return a concise process map, scenario set, decisions, open questions and requirements for confirmation. Do not circulate hundreds of isolated statements with no explanation of how they work together.
Separate configuration from procedure
For each requirement, decide whether the response is standard product behavior, configuration, integration, data control, operating procedure or a combination. This makes cost and ownership visible. A procedure may be appropriate for a rare exception; using it for daily core work is a different design choice.
Where the solution depends on future customisation, define the unsupported gap and fallback. Do not score a roadmap promise as if it were available acceptance evidence.
Create the traceability record
- Give each scenario and requirement a stable identifier.
- Link it to the business outcome and process owner.
- Record source policy, observation or decision.
- Map proposed configuration, integration or procedure.
- Link demonstration, test and acceptance evidence.
- Retain deviations and approved residual risk.
Traceability should remain usable after selection; it becomes the basis for configuration, testing, training and change.
Test vendors through the process
Provide a controlled dataset and script. Ask each product to complete the normal path and material exception, then trace operational and financial outcomes. Observe workarounds, administrative effort and unanswered questions.
The resulting requirement set is valuable because it describes how the business intends to operate. It does not prescribe every screen, and it does not let a broad feature claim substitute for evidence.
After selection, repeat the scenarios at design, build and release acceptance. Mark requirements changed by an approved process decision and retain the reason. This prevents the contract requirement, configured behavior and test evidence from becoming three unrelated versions of intent.
Close each scenario with a named acceptance owner and retained result. A demonstration comment is not acceptance evidence unless the relevant process and control owners understand the limitations and approve the outcome.