Features Pricing Our AI AI Project Plan Generator
Industries Internal projects Use Cases Case Studies
Blog Knowledge library Comparisons PM Templates Free Tools Integrations AI Project Management API & Developers
Login Get started free
Requirements specification example

ERP requirements specification: example and template

An ERP requirements specification decides whether vendors submit comparable proposals — and whether the rollout later fails on missing requirements. This example shows a complete document for a machinery manufacturer with two sites: materials management, production planning, barcode warehouse and an accounting interface.

10 Chapters 18 Requirements 15 MUST requirements

Requirements specification template and guide · Requirements spec generator

Requirements specification

Customer Requirements Specification for the New ERP System

The company requires a new ERP system for materials management, production planning, barcode-supported warehouse management and integration with the accounting system. The system shall replace spreadsheet-based processes and the existing 15-year-old production system and shall be operational at both sites by 30 September 2027 (assumption).

1. Introduction and objectives

The company manufactures machinery, employs approximately 180 people and operates two sites. Purchasing and production currently use spreadsheets and a 15-year-old production system, which limits process integration and data transparency.

The objective is to establish one controlled ERP system for materials, purchasing, production planning, warehouse operations and accounting-related data exchange.

  • Reduce duplicate data entry and spreadsheet-dependent processes.
  • Improve visibility of stock, material availability, production orders and delivery-relevant dates.
  • Create consistent master data and traceable business transactions across both sites.
  • Enable barcode-supported warehouse processes and reliable data transfer to accounting.

2. Current state

Purchasing and production planning are performed partly in spreadsheets. Production transactions are also recorded in a 15-year-old production system; its interfaces, data structures and remaining support period are currently not documented.

Warehouse processes are not centrally described and barcode coverage is incomplete or unavailable (assumption). The existing accounting system remains in operation and must receive agreed accounting-relevant data through an interface.

  • Material and supplier information may be maintained in more than one location (assumption).
  • Stock, open purchase orders and production requirements are not available in one consistent real-time view (assumption).
  • Production planning depends on manually maintained spreadsheets and data transfers (assumption).
  • The current production system has been in use for approximately 15 years and may contain historical data requiring assessment before migration.

3. Functional requirements

The ERP system shall support the core processes of the two-site machinery manufacturer without requiring uncontrolled spreadsheet workarounds. Configuration shall permit site-specific warehouses, responsibilities and inventory locations while maintaining one common data model.

  • All transactions shall be attributable to a site, user, date and time.
  • The system shall provide test and production environments before go-live (assumption).
F-01MUST

Material and item master data

The system shall manage materials and items with item number, description, unit of measure, material group, site-specific planning parameters, supplier references, lead times, stock limits and lifecycle status.

Acceptance: In UAT, an authorised user can create, amend, block and reactivate an item; mandatory fields are validated and every change is recorded with user, date and previous value.

F-02MUST

Supplier and purchasing management

The system shall support purchase requisitions, purchase orders, supplier confirmations, goods receipts and purchase order status tracking for both sites.

Acceptance: For a test material, a requisition can be converted into a purchase order, received partially and completely, and the system shows the remaining quantity and current status.

F-03MUST

Multi-site inventory management

The system shall manage stock by site, warehouse and storage location, including available, reserved, blocked and in-transit quantities.

Acceptance: A test transfer between the two sites creates an outbound and inbound transaction, updates both stock balances and shows the transfer status until receipt.

F-04MUST

Barcode warehouse operations

The system shall support barcode-based receiving, put-away, internal transfers, picking, material issue, stock counting and goods dispatch using handheld devices or fixed scanners.

Acceptance: In UAT, a warehouse user scans a valid item and location barcode for receiving, transfer and issue; stock is updated immediately and an invalid or unauthorised scan is rejected with an explanatory message.

F-05MUST

Bills of material and routings

The system shall manage multi-level bills of material, production routings, work centres, quantities, operations, revisions and effective dates for manufactured machinery and components.

Acceptance: A released production order uses the bill of material and routing revision valid on its planned start date, and a superseded revision cannot be selected for a new order.

F-06MUST

Material requirements planning

The system shall calculate material requirements from production demand, bills of material, stock, reservations, open purchase orders, open production orders and replenishment lead times.

Acceptance: For a defined test scenario, the planning run creates the expected purchase and production proposals and identifies shortages with the required quantity and date.

F-07MUST

Production planning and scheduling

The system shall support creation, release, rescheduling and monitoring of production orders, including operation sequence, planned dates, work centres and material availability.

Acceptance: A planner can release a production order only after the configured checks have been completed, can reschedule it, and can view the resulting dates and capacity or material exceptions.

F-08MUST

Production execution recording

The system shall record material consumption, produced quantities, scrap, operation status and completion against production orders.

Acceptance: In UAT, a production operator records partial output, scrap and material consumption; the production order, stock balances and remaining quantities are updated consistently.

F-09SHOULD

Traceability and transaction history

The system shall provide traceability from a material receipt through warehouse movements and production consumption to the relevant production order and finished item, where lot or serial tracking is configured.

Acceptance: For a test lot or serial number, an authorised user can retrieve the related receipt, warehouse movements, consumption transaction and production order without accessing database tables directly.

F-10MUST

Accounting system interface

The ERP system shall exchange agreed master data and accounting-relevant transactions with the existing accounting system, including validation, error handling and duplicate prevention.

Acceptance: During an interface test, an agreed set of supplier, item, purchase and stock-related transactions is transferred, accepted by accounting, logged with a reference and rejected with an actionable error when mandatory data is missing.

F-11SHOULD

Operational reporting

The system shall provide role-based reports for stock levels, shortages, purchase order status, supplier deliveries, production order status, material consumption and inventory movements.

Acceptance: Authorised users can run the agreed standard reports for either site and export the displayed result to a commonly used format such as CSV or PDF.

F-12MUST

Roles, approvals and audit trail

The system shall support role-based access and configurable approval rules for purchasing, master data changes, production order release and inventory adjustments.

Acceptance: A test user without purchasing approval rights cannot approve a purchase order, while an authorised approver can do so; the approval history shows user, date, time and decision.

4. Non-functional requirements

The ERP system shall be suitable for daily operation at two sites with an initial user base of approximately 80 named users and shared warehouse devices (assumption).

The supplier shall document the agreed service levels, technical architecture, security controls, backup concept and operating responsibilities before implementation approval.

  • Performance shall be measured under a representative test load before acceptance.
  • System times and time zones shall be consistent for both sites.
  • Planned maintenance windows shall be agreed with the company in advance.
N-01MUST

Performance

For the assumed initial load of 80 named users and up to 25 concurrent barcode users, standard searches, stock postings and order status transactions shall normally complete within three seconds, excluding reports processing more than 10,000 records.

Acceptance: A documented performance test using representative master data achieves the three-second target for at least 95 percent of the defined standard transactions.

N-02MUST

Availability

The production system shall provide at least 99.5 percent availability during agreed business hours per calendar month, excluding pre-announced maintenance and force majeure events.

Acceptance: The supplier provides monthly availability reports and the first full operating month meets or exceeds the agreed availability target.

N-03MUST

Security and access control

Access shall be role-based, authenticated individually and protected in transit by current encryption standards. Administrative actions, logins, failed logins and security-relevant data changes shall be logged.

Acceptance: A security test confirms that users can access only permitted functions and data, communications use encrypted connections and the defined audit events are retrievable by authorised administrators.

N-04SHOULD

Usability

The system shall provide workflows suitable for purchasing, planning, production and warehouse users with clear validation messages and a user interface in English or German as agreed during design (assumption).

Acceptance: Representative users complete the agreed receiving, stock transfer, purchase order and production recording scenarios after standard training without undocumented workarounds.

N-05MUST

Backup and recovery

The service shall provide automated backups with a maximum data loss of 24 hours and a maximum recovery time of four hours (assumption).

Acceptance: A documented recovery test restores the ERP service and the test data within four hours, with no more than the agreed 24-hour recovery point.

N-06MUST

Operations and supportability

The supplier shall provide monitoring, incident classification, support contact details, release management and technical documentation sufficient for the company or its IT service provider to operate the system.

Acceptance: Before go-live, monitoring alerts, escalation contacts, severity definitions, operating procedures and the release process have been tested and approved by the company.

5. Interfaces and data migration

The ERP system shall interface with the existing accounting system and shall replace or integrate with the 15-year-old production system. The supplier shall document interface ownership, data formats, frequency, monitoring, error handling and reconciliation procedures.

Data migration shall be preceded by profiling, cleansing, mapping and reconciliation. The company expects to migrate active master data and open transactions; the migration of historical transactions is subject to confirmation.

  • Source data shall include spreadsheets used by purchasing and production, the existing production system and the accounting system where relevant.
  • The initial migration scope shall cover items, units of measure, suppliers, warehouses, locations, bills of material, routings, stock balances, open purchase orders and open production orders (assumption).
  • Historical production and purchasing transactions shall be retained in the legacy system or migrated according to an agreed retention and reporting concept.
  • At least one full mock migration and one final migration rehearsal shall be completed before go-live (assumption).
  • Migrated stock balances and open transactions shall be reconciled against source-system totals and approved by the process owners.

6. Framework conditions

The solution shall comply with the GDPR and applicable German data protection requirements. Personal data shall be limited to what is necessary for the processes, retained for defined periods and protected against unauthorised access.

If the system records employee time, individual performance, work output, production status or other employee-monitoring information, the company shall involve the works council before configuration and use. A data processing agreement shall be concluded where the supplier processes personal data on behalf of the company.

  • The supplier shall provide a description of processing activities, subprocessors, data locations, retention options and technical and organisational measures.
  • The solution shall support access restriction, correction, deletion or anonymisation where legally applicable, and export of personal data for data subject requests.
  • Security responsibilities shall be divided between the company, the hosting provider and the ERP supplier and documented before go-live.
  • The hosting location shall be within the European Economic Area, with encrypted backups and controlled administrative access (assumption).
  • The supplier shall notify the company of security incidents and support legally required investigations within agreed response times.

7. Volume and users

The ERP system shall support the company's 180 employees across two sites. The initial deployment is estimated at 80 named users and up to 25 concurrent barcode or shared-device users (assumption).

The initial data volume is estimated at 5,000 active items, 1,000 bills of material, 500 active suppliers and 100,000 stock movements per year (assumption). The design shall allow growth of at least 50 percent without replacing the platform (assumption).

  • Purchasing, materials management and planning: approximately 20 named users (assumption).
  • Production and warehouse operations: approximately 40 named or shared-device users (assumption).
  • Finance, management, administration and IT: approximately 20 named users (assumption).
  • Both sites shall be supported by the same ERP installation or logically integrated instances with consistent master data.

8. Scope of delivery

The implementation scope shall include requirements validation, solution design, configuration, barcode process design, interface development, migration, testing, training, go-live support and handover to operations.

The supplier shall provide documentation that enables the company to operate the system, maintain master data, manage users and perform agreed standard administration.

  • Project management, implementation planning and a responsibility matrix.
  • Configuration of materials management, purchasing, production planning, production execution and warehouse processes.
  • Development and testing of the accounting interface and any required legacy-system data extraction.
  • User acceptance testing support, migration rehearsals and cutover planning.
  • Training for key users, process users, warehouse users and system administrators; six key-user sessions and four end-user sessions are planned (assumption).
  • At least three months of enhanced support after go-live are required (assumption).

9. Time frame and budget frame

The ERP system shall go live no later than 30 September 2027, interpreted as the end of Q3 of the next calendar year (assumption). Project mobilisation is expected during Q4 2026 or Q1 2027 (assumption).

The preliminary budget frame is EUR 350,000 excluding VAT for software licences or subscriptions, implementation, interfaces, migration, training and initial support (assumption).

  • Requirements and supplier selection: Q4 2026 to Q1 2027 (assumption).
  • Design, configuration and interface development: Q1 to Q2 2027 (assumption).
  • Migration rehearsals, integration testing and user acceptance: Q2 to Q3 2027 (assumption).
  • Final cutover and go-live: by 30 September 2027, followed by enhanced support (assumption).
  • The supplier shall identify any prerequisites that could threaten the target date or budget.

10. Acceptance

Acceptance shall be based on successful completion of agreed functional, integration, migration, security, performance and operational tests. The company shall approve the acceptance test catalogue before formal testing begins.

The system shall not be accepted if a critical process cannot be completed, if accounting interface reconciliation fails, if material migrated data is incomplete or if unresolved critical defects prevent safe daily operation.

  • All MUST requirements shall pass their documented acceptance criteria.
  • The two-site end-to-end scenarios for purchasing, receipt, barcode warehouse movement, material planning, production execution, stock reconciliation and accounting transfer shall be completed successfully.
  • No open severity-one defects and no unresolved defects that prevent a core business process shall remain at acceptance.
  • A minimum two-week operational pilot with representative users shall be completed before final acceptance (assumption).
  • Acceptance shall be recorded in writing by the company's project sponsor after delivery of the agreed documentation, training evidence and support handover.

To clarify before use

These points and assumptions are open in the example — your initiative needs to settle them.

  • Which accounting system, version and interface technology are currently in use, and which accounting data flows are mandatory?
  • What is the vendor, technical condition and export capability of the 15-year-old production system?
  • What are the exact names, responsibilities and connectivity conditions of the two sites?
  • Which user numbers, roles, languages and device types are required, and should the assumption of 80 named users and 25 concurrent barcode users be confirmed?
  • Which master data and historical transactions must be migrated, and what retention period applies to legacy data?
  • Does a works council exist, and will the ERP system record employee time, individual performance or other potentially monitoring-related data?
  • Should the assumed European Economic Area hosting model and EUR 350,000 excluding VAT budget frame be confirmed, and is cloud hosting acceptable?

Next step: the project plan: ERP implementation project plan

The requirements turn into an initiative with phases, schedule, budget and risks. · Planning an ERP implementation with AI

How this example was created
Created with the PathHub requirements specification generator from this description: “Introduce a new ERP system for a machinery manufacturer with 180 employees at two sites. Purchasing and production currently work with spreadsheets and a 15-year-old production system. Key areas: materials management, production planning, barcode warehouse management and an interface to the accounting system. Go-live by the end of Q3 next year.” — without company context. For your initiative: adapt the description and create your own document.

Frequently asked questions

What goes into a Requirements specification for an ERP system?
In the example: Introduction and objectives, Current state, Functional requirements, Non-functional requirements, Interfaces and data migration, Framework conditions, Volume and users, Scope of delivery, Time frame and budget frame, Acceptance. The core is 18 numbered requirements, 15 of them MUST requirements, each with a testable acceptance criterion.
Which requirements matter most for an ERP system?
Rated MUST in the example: Material and item master data; Supplier and purchasing management; Multi-site inventory management; Barcode warehouse operations; Bills of material and routings.
Can I use the example as a template?
Yes. Download it as a Word file and adapt figures, systems and priorities to your initiative — or let the generator create a document from your own description in about a minute.
What is the difference between a requirements and a functional specification?
The client writes the requirements specification: what is needed and why. The contractor writes the functional specification: how the requirements are implemented and tested.

More examples

Your own requirements specification in a minute

Describe your initiative — PathHub writes the document with numbered requirements and Word export. Free, no sign-up.

Create document →