In a warehouse management systems an enterprise application that controls all activities and sub systems has to fulfill several non-functional requirements also known as software system requirements.
Probably you don't want to know about system requirements on software but more about the runtime and development requirements of openwms.org, than visit the download page.
The following list is not sorted by importance.
As each software system openwms.org has to be user friendly, easy to use and appealing to work with. Not often users have to work the whole day with only a set of views to achieve their daily business. Hence the software must be self-explained, system messages must be expressed meaningful and an user interaction must respond in shortest time - accessibility does also belong to this category. In typical warehouse management systems, the range of devices and operating systems is very broaden and users operate in different ways with the software system. Some workstations prefer to operate with keyboards only, while a mouse is very handy to use on control panels. In modern warehouses touch-screens are no a rarity at all. These topics of usability must be considered when choosing the proper technologies in the conceptual phase and during the implementation time later on.
Even though a WMS software is mostly applied to local companies without the need to guarantee a completely 24/7 availability however it is important to ensure a certain degree of availability of the software system itself. Enterprise applications and systems they depend on must be laid-out to run stable and credible. Downtimes are only acceptable for system maintenance. In case of a failure the software system must handle the failure situation in a reliable manner and recover to the latest stable point to assure data consistency and integrity.
Typical WMS systems exist ten years and more. It is rarely uncommon that a proven WMS system is being replaced before. This affects the selection of technologies and runtime environments. It is essential to minimize the number of technologies and choose the right ones that are future-proven and will be supported for a measurable period of time. Taking hype frameworks in a version <1.0 would not be a good choice here.
For project engineers that have to customize the software for their needs it must be handy to do so. This requires a high degree of documentation that is not written to complex for a better understanding. Even if a WMS system can be very complex the learning curve of openwms.org and the underlying technologies must not be to steep, otherwise it'll not be accepted. An integrated development environment with a proper build lifecycle and a clean project structure is essential for all project newcomers.
In general the whole software lifecycle of WMS systems spans several years. Therefore it is essential to design and structure the software components in a flexible and extendible way. Choosing basic design patterns guarantees a high degree of maintainability years after the initial installation. Incoming change requests might be handled by people who are new in the project and cannot rely on the knowledge of the primary project team. It is much easier for those new engineers when the software system is designed in a modular and lose-coupled way instead of a monolithic dinosaur application.
Nothing new to an application that spans a long lifetime, is the requirement of portability. After an amount of years hardware components have be sorted out or replaced by completely new systems. Runtime environments like application servers have to be upgraded to newer versions as well. Hence the enterprise application on top must be built to be the most portable as possible. This requirement is closely tied to Longevity of course.
Each enterprise application must provide some kind of security. Because openwms.org is not tend to run as an internet application, security is not such important like it is for real web applications but a adequate portion of security must be provided. User authentication is mandatory as well as role-based authorization is. Furthermore a fine-grained grant-based authorization concept is desirable. Aspects of security that are not considered: secured channel communication, method-level security or any kind of attack or intrusion protection. This must be covered by the chosen frameworks and technologies.
Not the same but comparable in this context. An actor of a WMS software system like openwms.org is not only a human being. Most actions are performed by subsystems like PLC systems (controls) or host-systems (ERP). The rate of transactions those automatic systems perform is much higher then the actions effected by an operator. To guarantee a reasonable response-time for all actors (throughput) the system must perform well. Performance must be considered in all phases of the project development and depends highly on architecture and design decisions.
Any WMS project is different, regarding customer requirements. The amount of users, the applied warehouse layout and the transport unit size and speed of the logistic warehouse system are some of the indicators to measure the size of the over all system. In any case it is mandatory that the application is scalable and can cover the needs of each project. Huge projects with hundreds of frontend users and hundreds of PLCs are not seldom and must accomplished by the application in a scalable manner. Scaling up vertically and out horizontally is mandatory for modern enterprise applications even though for openwms.org.