In brief
The requirement specification states what the warehouse system must achieve and why. Target processes and system boundaries come before individual software functions.
What belongs in a WMS requirement specification?
It describes objectives, processes, volumes, roles, functions, system boundaries, interfaces, data, quality requirements, migration, testing and acceptance from the client's perspective.
Requirement and system specification
The requirement specification states what is needed and why. The system specification explains how and with what the supplier will implement it. This distinction follows VDI/VDE 3694:2014-04. A revision is underway, so the announced project is not treated as an already valid replacement.
Process
Who does what, when and with which exception?
System
Which function belongs to ERP, WMS, WCS or equipment?
Data
Which objects, states and messages are required?
Evidence
How is each critical requirement tested?
1. Target processes first
Receiving, put-away, replenishment, picking, packing, shipping, inventory, returns and exception processes are defined with roles, rules, volumes, peaks and service levels before software functions are selected.
2. Boundaries and interfaces
ERP, WMS, WCS, material-flow control, equipment and peripheral systems receive clear responsibilities. Functional messages such as expected receipt, confirmation, provision order and execution report are described independently of the protocol. VDI 3969 remains a useful functional view and is extended with current API, event, security and monitoring requirements.
3. Testable requirements
Performance, availability, authorization, logging, recovery, maintainability and support include a boundary, test condition and acceptance method. Migration defines owners and quality rules for master data, inventory, locations and open work. End-to-end tests, load tests and cutover rehearsals precede go-live.
Related services: warehouse management systems and warehouse planning.