1. Choose one end-to-end workflow
Do not start by describing the entire company. Select a path with a clear start and result, such as order, reservation, picking and dispatch. Record people, decisions and exceptions. For a shop with production, add where manufacturing demand starts and who confirms readiness. This describes work, not a wish list of modules.
2. Assign data ownership
Decide who owns products, prices, customers and stock. Agree on rules for creating and changing records. If the same item has several codes, define a mapping before import. Otherwise, duplicates and inconsistencies move into the new system.
- Unique product codes and variant rules.
- Units and pack conversion rules.
- Storage locations and opening stock at a defined time.
- Required fields and responsibility for validation.
3. Separate configuration, integration and development
Record the business reason behind each requirement. Then assess with the implementer what configuration can cover, what needs external data exchange and what needs custom code. Confirm the version, edition, hosting and extension constraints before choosing implementation methods. Do not assume any module can be installed in every environment.
4. Define integration rules
For a storefront or CRM, agree on ownership of each field. One system might own prices while another owns delivery status. Include retries, lost connections and partial operations. A rule such as “a repeated order with the same external ID does not create another record” is already a testable scenario.
5. Agree on acceptance before launch
Showing a screen is not enough. The team should run representative operations with test data. Write down the expected result and who approves it. Include more than a successful full transaction.
- Full and partial dispatch.
- Returns, cancellation and order changes.
- Repeated integration requests and recovery after failure.
- Different roles and access rights.
- A reference report after operations complete.
Turn a wish into an acceptance test
Illustrative specification examples. Agree on the exact roles and rules with your team.
Scroll horizontally to read the table.
| Wish | Test scenario | Expected result |
|---|---|---|
| “Correct stock” | Reserve goods, dispatch part and cancel the remainder. | Physical quantity and reservations change separately under agreed rules. |
| “Reliable exchange” | Submit the same external order ID again. | No second order is created; the processing outcome can be checked. |
| “Useful permissions” | Run an operation using different user roles. | Each role sees and changes only permitted data. |
Takeaway. Assign an acceptance owner to each test. A feature appearing on a screen does not mean the workflow is ready.
6. Plan the transition
Define the opening-stock time, which open documents to migrate and who reconciles totals. Agree on when the team stops entering data in the old system. Establish stop and recovery conditions, owners and current backups before a problematic launch occurs. After launch, collect user questions and improve instructions.
A minimal brief for the first conversation
You do not need a large specification to begin. Prepare a short description and agree separately on sharing confidential files and access.
- One workflow and the problem to solve.
- Current systems and required integrations.
- Key reference-data structures without customer records.
- User roles and the person accepting the result.
- Launch constraints: seasonality, team availability and dependencies.