How to Build Your CMMS Requirements

A CMMS requirements list can get long very quickly.

Work orders. Preventive maintenance. Mobile access. Inventory. Reporting. Dashboards. Integrations. Barcodes. Notifications. Asset hierarchies.

Most CMMS products will cover many of those categories in some form.

That does not tell you which capabilities matter most to your maintenance operation or how they need to work.

A more useful requirements process begins with the operation you already have.

Follow how maintenance work happens. Identify what the people doing the work need. Document where information comes from and where it needs to go. Then turn those observations into requirements a software provider can demonstrate.

We use three steps:

MAP → DEFINE → PROVE

MAP the maintenance operation.

DEFINE what the CMMS needs to support.

PROVE the important requirements against actual software.

Start with the problem you are trying to solve

Before listing software requirements, write down why you are considering a CMMS.

Keep it concrete.

For example:

• maintenance requests are difficult to track;
• preventive maintenance is being missed;
• supervisors cannot easily see the backlog;
• equipment history is scattered across different records;
• technicians have to re-enter information after completing work;
• parts used on maintenance jobs are difficult to track;
• reporting requires manually assembling information;
• the current maintenance system depends heavily on one person's knowledge.

These problems give the requirements process a purpose.

NIST's research on technology implementation in maintenance management emphasizes identifying the organizational or process problem a technology is intended to address. The technology should be considered in the context of the maintenance process and the people performing it.[1]

Write the problems down before discussing products.

You will use them later when deciding which requirements deserve the most attention.

MAP: Follow the maintenance operation

Start with real maintenance work.

Take several recent jobs and trace what happened from beginning to end.

NIST's maintenance-management workflow follows maintenance from the initial equipment event through work request, work order, planning, scheduling, execution, findings and closure. The work order moves through the process while information about equipment, labor, materials and the work itself is captured along the way.[2]

Your process may be simpler or more complicated.

The point is to see how yours actually works.

Map how work enters maintenance

Ask:

• Who can request maintenance?
• How do requests arrive?
• What information is usually provided?
• Who reviews the request?
• How is priority determined?
• Can duplicate requests occur?
• Does the requester need status updates?
• When does a request become authorized maintenance work?

Do not worry about what a particular CMMS calls these steps.

Document what happens in your operation.

Map how work gets planned and assigned

For approved work, ask:

• Who decides what gets worked on?
• How are technicians assigned?
• Does work require a particular skill or certification?
• Do supervisors need to coordinate maintenance with production or operations?
• Are parts, tools, contractors or permits needed before work begins?
• How is scheduled work communicated?
• What causes work to be delayed or rescheduled?

Look for decisions and information that currently live outside the formal maintenance record.

Map what technicians need

Follow the job to the person performing the work.

What does the technician need before and during the job?

Possibilities include:

• asset identification;
• location;
• problem description;
• priority;
• equipment history;
• procedures;
• manuals or drawings;
• safety information;
• checklist;
• parts;
• tools;
• previous readings;
• photographs;
• instructions from a supervisor.

Then ask what the technician needs to record.

That may include:

• work performed;
• labor time;
• parts used;
• readings;
• condition;
• failure information;
• photographs;
• notes;
• follow-up work;
• completion status.

This is where a generic requirement such as mobile access begins to become useful.

Map preventive maintenance

Document how recurring maintenance is handled today.

Ask:

• What triggers the work?
• Is it calendar based?
• Runtime based?
• Meter based?
• Condition based?
• Who maintains the PM schedule?
• How does scheduled work become assigned work?
• What happens if the work cannot be completed when due?
• What happens when an asset is taken out of service?
• How far ahead does the team need to see upcoming work?

The Indian River County CMMS procurement, for example, required support for preventive maintenance based on time, usage, runtime or condition-based triggers. It also addressed future scheduling and what should happen to future PM work when assets are retired or taken out of service.[3]

Your operation may need only a fraction of that. The clearer the operational scope, the easier it becomes to understand what a vendor’s price actually covers, as the public CMMS cost research shows.

Map what it needs.

Map parts and materials

If parts are part of the maintenance process, ask:

• Where is inventory tracked now?
• Does a technician need to know whether a part is available?
• Should parts used be recorded against a work order?
• Should parts usage become part of equipment history or cost?
• Who can issue or adjust inventory?
• Does purchasing need information from maintenance?
• Is the CMMS expected to be the inventory system, or will another system remain responsible for inventory?

That last question is important.

A requirement should establish which system owns the information as well as what information needs to move.

Map the information managers need

Ask supervisors and managers what they regularly need to know.

For example:

• What work is open?
• What is overdue?
• What is highest priority?
• What PM is coming due?
• What work is waiting on parts?
• Which assets are requiring repeated maintenance?
• How much labor is being used?
• What maintenance history exists for a particular asset?
• What information is needed for audits or compliance?
• What information has to be sent to another department or system?

Then find where that information comes from today.

Historical maintenance work orders can contain substantial knowledge about maintenance activity, which makes the information captured during work important for later analysis.[4]

If a desired report depends on information that nobody records, adding the report to a requirements list will not solve the underlying problem.

Map the environment around the work

Requirements also come from the conditions in which the system will be used.

Document things such as:

• number of sites;
• number and types of assets;
• number of technicians and other users;
• shifts;
• shared devices versus individual devices;
• phones and tablets in use;
• Wi-Fi or cellular availability;
• areas with poor or no connectivity;
• languages;
• security requirements;
• existing asset labels, barcodes or QR codes;
• systems that contain related information;
• records that will need to be migrated.

These facts can materially change what a seemingly simple requirement means.

Consider:

Mobile access

For one organization, that may mean technicians can view work orders on company-issued phones with reliable Wi-Fi.

For another, technicians may work across a large facility or remote locations where connectivity disappears.

Indian River County's 2026 procurement required technicians to receive assignments, view asset and work information, complete tasks, enter labor and materials, capture photographs and document work through a mobile interface. It also required offline operation with synchronization when connectivity returned.[3]

Both organizations might write mobile access on a checklist.

They do not have the same requirement.

DEFINE: Turn the operation into requirements

Now translate what you learned into statements describing what the system needs to support.

Avoid vague labels where possible.

Instead of:

Work orders

write:

Supervisors need to create, prioritize, assign, reschedule and close maintenance work while preserving its status and history.

Instead of:

Mobile app

write:

Technicians need to receive assigned work, view asset information, record labor and parts, add completion notes and attach photographs from the field.

If connectivity is unreliable:

Technicians must be able to perform those activities without a network connection and synchronize the record when connectivity returns.

Instead of:

Preventive maintenance

write:

The system needs to generate recurring maintenance based on our existing calendar-based schedules and allow supervisors to see upcoming PM work before it becomes due.

Instead of:

Reporting

write:

Maintenance supervisors need to see open work by priority, overdue work, upcoming preventive maintenance and maintenance history by asset without manually combining separate files.

The more clearly a requirement describes the work, the easier it becomes to evaluate.

Connect each important requirement to its reason

For major requirements, record why they exist.

A simple structure is:

Current situation → Requirement → Reason

For example:

Current situation: Technicians write parts used on paper work orders and someone enters them later.

Requirement: Technicians need to record parts used while completing the work order in the field.

Reason: Reduce duplicate entry and preserve parts usage with the maintenance record.

Another:

Current situation: Some maintenance areas have unreliable connectivity.

Requirement: Technicians need to update assigned work without a network connection and synchronize later.

Reason: Field work cannot depend on continuous connectivity.

This makes it much harder for the requirements list to become a collection of features nobody can explain.

Separate requirements from preferences

Not every request should carry the same weight.

A useful first pass is:

Required

The operation cannot reasonably use the system without it.

Important

It would materially improve the process, but another workflow may be acceptable.

Useful

There is value in having it, but it should not drive the buying decision.

Future

The organization may need it later, but it is outside the immediate implementation.

Keep the categories simple.

The objective is to force a discussion about priority.

If everything is required, nothing is prioritized.

Include implementation requirements

Software capability is only part of a CMMS project.

Your requirements may also need to address:

• asset and equipment data;
• historical work records;
• PM schedules;
• parts and inventory data;
• data cleanup;
• configuration;
• integrations;
• user roles and permissions;
• training;
• implementation responsibilities;
• testing;
• go-live support;
• ongoing support.

Indian River County's CMMS procurement separately addressed data migration, configuration, training, change management, integrations, hosting, security, backup and recovery in addition to functional requirements.[3]

That is a useful reminder.

A product can support the required workflow and still require substantial work to become usable in your environment.

Define integration requirements from the information flow

Do not write ERP integration and stop there.

Ask:

• Which system contains the information today?
• Which system should remain the system of record?
• What information needs to move?
• In which direction?
• How often?
• What triggers the exchange?
• Who needs to see the resulting information?
• What happens if the integration fails?

You may discover that you do not need an integration at all.

Or you may discover that it is essential.

The operational information flow should determine the requirement.

PROVE: Turn important requirements into vendor scenarios

A vendor can answer yes to a feature question.

That does not show how the capability works.

For the requirements that matter most, create a realistic scenario and ask each vendor to demonstrate it.

For example:

Requirement

Technicians need to complete maintenance work where connectivity is unreliable.

Scenario

A technician receives an assigned work order for a pump.

Ask the vendor to demonstrate the technician:

1. opening the assigned work;
2. viewing the asset and relevant history;
3. completing a checklist;
4. recording labor;
5. recording a part used;
6. attaching a photograph;
7. entering completion notes;
8. losing connectivity;
9. completing the work;
10. synchronizing the record when connectivity returns.

Now you are evaluating how the system handles your work.

This approach is used in real procurement.

Indian River County's 2026 CMMS RFP specified demonstration scenarios covering core navigation, GIS-based work-order creation, mobile work execution, planned maintenance and reporting. Its mobile scenario specifically asked vendors to demonstrate assigned work, tasks, labor, parts, photographs, problem/cause/resolution information and loss of connectivity followed by synchronization.[3]

A scenario turns a requirement into evidence.

Use your difficult cases

Do not demonstrate only the easiest maintenance job.

Include situations that expose how the system behaves when the process becomes less tidy.

Examples:

• a technician finds additional work while completing the original job;
• a required part is unavailable;
• PM work is overdue;
• an asset is out of service;
• two people report the same problem;
• a technician has no network connection;
• work has to be reassigned;
• a supervisor needs the history of repeated failures;
• equipment is moved to another location;
• a contractor performs part of the work.

You do not need dozens of scenarios.

Choose the ones that represent meaningful operational risk or important differences between systems.

Build a requirements sheet you can actually use

Your requirements document does not need to be enormous.

A practical structure could contain:

One requirement might look like this:

This is much more useful during a vendor demonstration than a row that says:

Mobile app — Yes/No

Review the requirements with the people who do the work

Before sending the list to vendors, review it with the people represented in it.

That may include:

• maintenance technicians;
• supervisors;
• planners;
• reliability staff;
• storeroom or parts personnel;
• operations or production;
• IT;
• finance or purchasing;
• safety or compliance;
• management.

They do not all need to choose the software.

They can tell you whether the requirements describe the work accurately.

A technician may identify a field condition that was missed.

IT may identify an integration or security constraint.

A supervisor may point out an exception that happens every week.

That is useful before the vendor evaluation begins.

Your operation becomes the requirements document

A good CMMS requirements process should leave you with more than a list of software features.

You should be able to explain:

• how maintenance work enters the organization;
• how it is prioritized and assigned;
• what technicians need;
• what gets recorded;
• how recurring work operates;
• how assets, parts and maintenance history relate;
• what managers need to know;
• what other systems are involved;
• what conditions affect how the software will be used;
• which capabilities matter most;
• how vendors will prove the important ones.

That is the logic behind:

MAP → DEFINE → PROVE

Map how the operation works.

Define what the system needs to support.

Prove the important requirements with realistic scenarios.

The requirements were already in the operation.

The work was making them explicit.

Next: How CMMS Pricing Works

Once you know what you need, you can start making sense of what vendors are charging for.

How CMMS Pricing Works →