A requirements list becomes useful when each requirement can be traced to real maintenance work in your plant. The best place to start is your plant.
Use one reasoning chain
OPERATING REALITY → NEED → REQUIRED CAPABILITY → SCENARIO → EVIDENCE → ACCEPTANCE
Read the evidence on requirements and proof →
1. How maintenance work begins
Document the events that can create work, who can report them, what information is required, and who decides what happens next.
2. Preventive maintenance
For runtime-based work, state whether runtime is manual, imported, equipment-generated or calculated; how current it must be; and what happens when it is missing or fails.
Some products can update asset counters from production hours or production quantity; Microsoft documents this as one possible implementation.[1] Confirm how your candidate products and systems would handle it.
Develop the detail with Preventive Maintenance Software.
3. Asset identity
A possible hierarchy is plant → area → line → machine → subsystem → component. It is an example, not a prescribed model.
At what level do we need to plan work, capture failures, consume parts, record cost and make decisions?
A hierarchy that is too shallow hides useful distinctions. One with more detail than the organization can maintain creates unreliable records.
Don't inventory an asset just because the software has a field for it.
Read the asset-information evidence →
4. Technician execution
Write requirements around the real setting: a workstation, shared device, phone or tablet; connectivity; gloves; shifts; and the information needed at the equipment.
Manufacturing work becomes practically executable when three conditions line up: the asset can be released, maintenance is ready with the required labor, skills, parts, tools and procedures, and an operational opportunity exists with an acceptable production consequence.
Buyer question: Can we see when the asset, the maintenance resources and the operational opportunity come together?
Scheduling follows from those conditions. A peer-reviewed manufacturing case study specified that a CMMS should support scheduling maintenance activities while considering available resources and planned production.[2]
Ask whether the software supports the decisions behind the schedule, rather than whether it has a scheduling screen.
Planned shutdowns are scarce maintenance opportunities. Useful shutdown work may need its scope, plan, parts, labor, contractors and permits ready before the window opens.
5. Parts inventory
Decide where inventory is managed first—the CMMS, ERP or another system—then define what the CMMS does.
A low-cost bearing available tomorrow creates one kind of maintenance risk. The same bearing with a long lead time, required by the only machine capable of a critical production step, creates a different operational exposure.
Buyer question: Can maintenance understand which unavailable parts can prevent important work from being executed?
6. Information across shifts
Define which conditions, temporary actions, access limits and unresolved decisions must survive a shift change, where they are recorded, and who owns the handoff.
7. ERP and MES boundaries
Authority before interface.
Name the authoritative system for every important record. Define the information exchanged, direction, trigger, timing, reconciliation and failure response.
Maintenance may need machine state, runtime, cycle or production counts, changeovers and production windows. Production may need planned downtime, work status, estimated return to service and actual return to service.
These records do not all have to live in the CMMS. Their ownership and movement are system-boundary questions.
Don't ask only whether it integrates. Ask what actually happens across the boundary.
Read the integration evidence →
Map the enterprise boundary with CMMS vs ERP.
8. Reporting
Define the operational question, source events, timestamps, ownership and exclusions behind every important report.
Reports depend on maintenance history. NIST notes that much of the available knowledge about a maintenance workflow may exist in historical work orders, while inconsistent data collection, cleaning and analysis make it difficult to use.[3]
In one NIST manufacturing example, researchers manually reviewed a manufacturer’s maintenance records and found that hydraulic leaks had occurred more than 40 times in three months. The pattern was difficult to recognize because technicians described similar events in different ways, including “hyd leak,” “hydraulics were leaking” and “hydaurlic burst and leak.” The lesson is about the records and their structure, not a criticism of the technicians who created them.[4]
Rigid categories bring their own problems. NIST has separately studied categorization errors when people enter maintenance information into controlled-vocabulary fields.[5] Decide which future questions the history must answer, then test whether technicians can capture that information accurately during real work.
Capture enough structure to make the history useful without turning technicians into data-entry clerks.
Never trust an SLA dashboard until you know what real-world event sits behind every timestamp.
9. Implementation
Implementation is something the buyer and provider produce together.
State what the provider supplies, what your team supplies, who owns each dependency, and what observable result shows that the work happened.
If this does not happen, who owns the fact that it did not happen?
Read the implementation evidence →
10. Acceptance
Go-live is not acceptance.
Define acceptance around representative work and agreed conditions.
Read the acceptance evidence →
Weigh requirements differently
- Conveniences
- Model-affecting requirements
- Configuration-dependent requirements
- Hard-to-change requirements
The weight of proof should follow the consequence of being wrong.
When you can't eliminate uncertainty, limit the commitment.
Read the bounded-commitment evidence →
Manufacturing CMMS requirements worksheet
| Operating reality | Need | Requirement | Dependency | Evidence | Acceptance |
|---|---|---|---|---|---|
| Operator reports can omit equipment, condition or time. | Maintenance needs enough context to triage. | A request is tied to identifiable equipment and preserves triage information. | Equipment identity is usable by production and maintenance. | A representative user reports a condition through triage. | Production creates the request, maintenance identifies equipment, and triage information survives the handoff. |
Requirements should survive vendor selection
OPERATING NEED → REQUIREMENT → VENDOR EVIDENCE → IMPLEMENTATION → ACCEPTANCE → OPERATIONAL EVIDENCE
Next: Make vendors prove the important requirements →
We don't tell you what to buy. We teach you how to buy it.
For planning responsibilities around ready work, see Maintenance Planning Software.
For the broader asset record and decision context, see Asset Maintenance Management.
The requirement-to-proof chain is also documented in this public evidence note.
Sources
- Microsoft Learn — Maintenance plans · Automatic update of asset counters
Used for time-based and counter-based maintenance triggers and counters updated from production hours or production quantity.
- Lopes et al. — Requirements Specification of a Computerized Maintenance Management System: A Case Study
Peer-reviewed manufacturing case study used for company-specific CMMS requirements and scheduling that considers available resources and planned production.
- NIST — Standards Needs for Maintenance Work Order Analysis in Manufacturing
Used for historical maintenance work orders as a source of workflow knowledge and the challenges of collecting, cleaning and analyzing that information.
- NIST — When a Manufacturer Asks “How Do We Get Smart?”
Primary source for the manufacturer example involving more than 40 hydraulic leaks in three months hidden by inconsistent descriptions.
- NIST — Categorization Errors for Data Entry in Maintenance Work-Orders
Used for the human-error challenges involved in entering maintenance information into controlled-vocabulary fields.