Who this is for: Manufacturers commissioning or updating software that supports production operations.
An industrial software specification should explain the activities the system supports, the information it uses, its connections to other applications and how it will be accepted. A list of screens or a request for a dashboard is not enough to obtain comparable proposals.
The document does not need to anticipate every technical detail. It needs to make objectives, constraints, responsibilities and unresolved questions visible. That gives suppliers a common result to price and makes any preliminary analysis identifiable from the start.
Describe users, activities and exceptions
For each function, say who uses it, when they need it and what they should achieve. An operator may record a reason, a supervisor may correct an association and management may review a summary. Specify which actions need authorisation and which information each role should see.
Include less frequent situations such as shift changes, cancelled orders, input mistakes and shared devices. Describe the physical setting too: available screen, use with gloves and reading distance. These details can shape the interface more strongly than a preferred visual style. Ask actual users to confirm that the description reflects their work before treating it as an agreed requirement.
Turn objectives into requirements that can be checked
Replace broad terms such as fast, intuitive and integrated with observable conditions. Numerical thresholds must suit the real use case: specify how they will be measured, at which data volumes and in what environment. A successful trial with a few records may not represent behaviour after months of production use.
The table suggests a way to frame acceptance. Give each requirement a priority and an owner who can confirm the result. State which functions are deferred so that a usable first release is not confused with completion of every possible future enhancement.
Scroll horizontally to see every column.
| Initial request | What to specify | How to check it |
|---|---|---|
| The system must be fast | Action, data volume and agreed response time | Measure the representative scenario |
| It must connect to our ERP | Data, directions, intervals and errors | Compare the input with the applied outcome |
| It must be easy to use | Activities and users involved | Have operators perform the task |
| Data must be recoverable | Copies, retention and restoration | Run an agreed recovery exercise |
Include security and change management in the scope
Ask how access, software dependencies, updates and vulnerability reports are managed. NIST’s SSDF offers a reference for discussing secure development practices with a supplier. Mentioning the framework in a specification is not evidence that those practices are actually followed.
Request proportionate evidence: permitted roles, release procedures, environment separation and responsibility for fixes. Avoid shared access without accountability. Where a change could affect a physical process, involve the machine’s technical owners and define the limits of the new software’s role. Keep these responsibilities visible in the proposal rather than assuming they will be resolved during installation.
References: NIST — SP 800-218, Secure Software Development Framework
Define handover, support and future changes
Specify the deliverables: the application, configurations, interface documentation, operating instructions and training materials. Agree contractual rights of use, source-code availability where applicable and data export. These conditions affect the ability to maintain and evolve the system after the initial supplier engagement ends.
Separate defect correction, operational support and additional features. Agree contact channels, coverage hours and response priorities instead of relying on a vague statement that support is included. Distinguish initial development, recurring services and optional work in the proposal. Where essential requirements depend on a third party, ask for those dependencies to be checked before committing to the whole implementation.
The minimum information to share with suppliers
- Operational objective and functions included in the first release.
- Users, permissions and shop-floor conditions of use.
- Data sources, connected applications and external contacts.
- Expected volumes and representative test scenarios.
- Acceptance criteria and people responsible for checking them.
- Documentation, training, maintenance and recurring costs.
- Outstanding constraints to resolve before confirming the project.
Common questions
Do we need a finished specification before talking to you?
No. Start with the problem, existing systems and examples of everyday work. Initial analysis can turn that information into requirements. It is useful, however, to distinguish the cost of that analysis from the price of an implementation whose scope is still being defined.
How should we compare quotes with very different prices?
Use the same matrix for included functions, integrations, acceptance, handover and support. Check exclusions and responsibilities assigned to your team. A lower initial price may cover a different scope. Ask suppliers to make those differences explicit before choosing between proposals.
Sources and further reading
Apply this to your project.
Describe the process and the result you want to achieve. We can help turn them into clear requirements for industrial software development.
Discuss your industrial software