Describe the current situation and target process
Choose a real transaction, anonymised where possible. Describe its trigger, the roles involved, data used, decisions and expected outcome. Record where information is missing or entered again. This creates a business context that someone outside your team can understand.
The target process describes the desired workflow. A clear sequence is enough at this stage; you do not need to design the interface. Explain significant changes from the current process. If an approval is being removed, establish which control replaces it or why it is no longer needed.
Give each requirement a specific purpose
“Manage everything centrally” does not explain which information supports which decision. A better entry identifies a role, a situation, a desired action and a verifiable outcome. Give each requirement a stable identifier so that supplier responses, tests and later changes can refer to the same item.
- Initial request
- “We need a better overview of billing.”
- Requirement ERP-01
- Finance can select approved service items in a project that have not yet been transferred.
- Acceptance criterion
- An unapproved item remains excluded. An item already transferred is not offered for transfer again.
Verifiability is also defined as a quality characteristic in the IREB glossary of requirements and acceptance criteria. The example above is our planning aid, not wording prescribed by a standard.
Explain must-have, important and optional priorities
Invite each affected department to contribute, and appoint someone to resolve conflicts between requirements. Business owners explain the process. IT assesses technical prerequisites. Management or a designated decision group sets priorities and confirms scope.
| Priority | Meaning for selection | What to record |
|---|---|---|
| Must have | The agreed use case cannot operate without it | Reason, test and decision owner |
| Important | Valuable, but a justified alternative may be acceptable | Benefit, possible interim approach and authority to accept it |
| Optional | An addition that does not block the initial usable scope | Conditions for reconsidering it later |
Agree on these definitions together. A must-have should not be outweighed by a large number of convenience features. Equally, marking every requirement as essential makes meaningful trade-offs impossible. Check whether a requested feature is truly necessary or simply a familiar solution to a problem that could be described differently.
Record data, interfaces and roles
A function cannot be evaluated properly without identifying the data it needs. List customers, orders, service items or other relevant objects and their relationships. Record current sources, required fields, quality issues and responsible people.
An interface requirement needs more than two application names. Explain which data moves in which direction, what triggers a transfer and what happens when it fails. If a customer name changes in the CRM, for example, specify whether the ERP should receive that change and which data should remain untouched.
Permission rules should describe both permitted and prohibited actions. Which role may change commercial terms? Who can see internal costs? Who can export data? Ask the relevant business, privacy and legal specialists to review sensitive data, retention and deletion requirements. A general request for “compliance” does not settle these decisions.
Make operational and quality requirements testable
The specification also needs operational and quality requirements. These include response times, expected data volumes, concurrent use, backup and restoration, and availability during your working hours. Choose values based on the actual use case instead of copying arbitrary targets from a template.
State the measurement conditions as well. “Fast search” cannot be verified. A usable requirement identifies the search operation, agreed test dataset, environment and acceptable limit. If a value is undecided, mark it as an open decision.
Operation and future development also need owners. Establish who manages access, investigates defects and commissions changes. Data export, documentation and handover to a future support partner may be requirements in their own right. Our ERP cost overview separates project and operational cost items.
Prepare acceptance using consistent scenarios
A demonstration scenario connects several requirements within a traceable transaction. It contains starting data, a role, actions and the expected result. Include the exceptions that matter to your business: missing required information, an unauthorised role, a withdrawn approval or a repeated transfer.
- RequirementERP-01 · Transfer approved items only
- DemonstrationSelect an approved item and a pending item together
- EvidencePending item excluded; transfer recorded
- DecisionMet, clarification needed or not met
Give every candidate the same scenarios. Record whether an outcome works in the demonstrated solution, needs configuration, requires an extension or remains unresolved. “Yes, possible” is not a sufficient supplier response. Ask about prerequisites, dependencies and the scope included in the proposal.
Actual acceptance arrangements are agreed within the project. The applicable document versions and treatment of changes belong in the specific agreement, with legal review where needed.
Complete the template and keep it current
The open template contains a requirements register with example rows and fields for your own entries. It is a working aid, not a finished specification for every industry.
Download the requirements register as CSV
Download the specification outline as Markdown
Start with one target process and its decisive requirements. Replace the labelled examples, assign owners and have affected departments review the entries. The CSV uses semicolons and UTF-8; import identifiers as text in your spreadsheet application where necessary.
Version the approved baseline. Each later addition should record its reason and a decision on scope, effort and timing. This preserves visibility of what has changed. For rollout, training and the move into operation, continue with our ERP implementation guide.
If important requirements still conflict, the next step is a business decision. A longer feature list will not resolve that conflict. A useful starting point for a discussion with SYNQ is one example process and the points where your current system is holding it back.