Businesses often begin CRM or ERP selection with hundreds of features: customer cards, warehouse functions, reports, integrations and mobile access. Vendors mark them as available, yet after launch the order still follows the wrong rules, stock updates arrive late and management cannot make the expected decision.
A feature without a scenario guarantees very little. Requirements should state who performs an action, with which data, under which rule, what happens in an exception and how success will be tested.
Turn business pain into a testable requirement
| Weak statement | Working requirement | Acceptance test |
|---|---|---|
| Control incoming leads | Every website, telephone and messenger enquiry creates a record with source and owner | Test enquiries from three channels appear without duplication |
| We need inventory | Sales sees physical, reserved and available stock by warehouse | A reservation reduces availability but not physical stock |
| We need reports | The owner sees contribution by product, customer and channel | Each total drills down to source orders and costs |
| We need permissions | A salesperson edits their own deals; a manager sees the team | A negative test confirms access to another owner's record is denied |
This wording makes solutions comparable and results verifiable. “The warehouse module exists” is no longer an adequate answer.
A practical requirements structure
- Project objectives. Measurable problems to reduce: lost enquiries, stock errors or report preparation time.
- First-release scope. Processes included now and those deliberately deferred.
- Roles. Who creates, approves, performs, controls and corrects data.
- Scenarios. Normal operation and important exceptions.
- Data. Master records, mandatory fields, sources, quality owners and history.
- Integrations. System of record and behaviour when exchange fails.
- Reporting and controls. The decision supported by each measure.
- Acceptance criteria. Specific tests, expected results and owner.
Describe a process as events
Instead of “manage sales”, record a sequence: enquiry received → duplicate checked → owner assigned → need qualified → quotation created → stock reserved → payment received → shipment created.
For each event define its input, output and transition rule. If a customer exceeds a credit limit or stock is insufficient, the system must not silently move the deal forward.
| Scenario element | Question to answer |
|---|---|
| Trigger | Which event starts the action? |
| Owner | Who is responsible for outcome and time? |
| Inputs | What must be known before execution? |
| Rule | Under which conditions is the action allowed or blocked? |
| Result | Which document, state or movement is created? |
| Exception | What happens when data or an external service is unavailable? |
Define the system of record
Customers may exist in CRM, products on the website, stock in an accounting package and payments in the bank. For every entity, name its owner: where it is created, where it may be edited and who resolves a conflict.
Without this rule, integration becomes two-way overwriting. A corrected customer name returns from the legacy system, while sales and the website show different stock.
Separate essential from desirable
| Priority | Meaning | Example |
|---|---|---|
| Required for go-live | The process or control fails without it | Unique order reference and stock reservation |
| Needed in the first release | Creates material value but has a temporary workaround | Automatic overdue-payment reminder |
| Later release | Extends an already stable process | Repeat-purchase prediction |
| Out of scope | Deliberately excluded from this project | Complete replacement of statutory accounting |
Priority must not mean that everything is critical. If every requirement receives the highest level, the team cannot build a controlled first release.
Acceptance criteria are stronger than prose
Create test data and an expected result for every key scenario. Include duplicate customers, insufficient stock, cancellation, repeated integration events and prohibited role actions—not only the happy path.
“Works correctly” is not a criterion. State which record appears, which status changes, what reaches the audit trail and which total the report returns.
Common requirements mistakes
- copying features from a sales presentation;
- describing only the ideal process;
- omitting data ownership and duplicate rules;
- putting every department into one release;
- confusing a requirement with a particular button design;
- having no acceptance tests or responsibility boundaries.
Conclusion
ERP/CRM requirements should connect a business objective, event, role, data, rule, result and test. The document then becomes a basis for estimation, configuration, development and acceptance rather than a wish list.
Once requirements are agreed, the next risk is importing duplicate customers, broken master data and incorrect opening balances into the new system. Explore the Business Reactor core.
