CMMS requirements documents are usually long, and length is what makes them useless: a hundred-row matrix gets a yes from every vendor, because almost every product in this category has almost every feature. Requirements that actually discriminate are short, behavioural and testable in a demo by you rather than described by a salesperson. Ten of those tell you more than a hundred rows of features. This page is how to write them, with the ten that matter most for a small maintenance team.
Write behaviours, not features
'Work order management' is a feature and everybody has it. 'A technician can raise a job at the machine on a phone, offline, in under a minute, without help' is a behaviour, and it is testable in front of you. Every requirement worth having can be phrased as something somebody does.
Ten lines, and score them yourself in the demo
Raise time. Offline. One-job-one-asset enforced. Findings hard to skip. Schedule shown in hours per technician. Deferral visible without a report. Two clocks, calendar and usage. Bulk edit. Full self-service export. History retention of at least two years. That list fits on a page and every line has a yes or no answer you can obtain.
Say what you will NOT be doing
If you do not hold spare parts, write that down. It stops the conversation drifting into EAM, stops you being priced for inventory modules, and stops a vendor scoping an implementation around something you will never turn on.
Include the numbers you will test against
Your asset count, your task count, your technician headcount and your PM load in hours: 66 a month on the worked example this site publishes. A vendor who cannot show your schedule as hours against your headcount has failed a requirement rather than a preference.
Questions people ask about cmms requirements
Do we need a formal RFP?
For a small team, no. A one-page requirements list and three demos you drive yourself will produce a better decision faster.
What is CMMS/EAM scope in practice?
The line is inventory, purchasing and multi-site consolidation. Write down which side of it you are on before you talk to anybody, because it decides the category and therefore the price.
Should requirements include integrations?
Only if you will build them in the first year. Integration requirements specified early and never configured are the commonest wasted line in this category.