Name the problem before you look at anything
Most selections start with a product somebody liked. The requirements are then written to describe it.
The honest sequence of events in a lot of software purchases runs like this. Somebody sees a product — at a conference, in an advert, at a previous employer. They like it. They arrange a demo. Somewhere between the demo and the invoice, a requirements document appears that the product satisfies unusually well.
This is not dishonesty. It is what happens when the first concrete thing in the process is a product rather than a problem, because everything after the first concrete thing is measured against it. If visibility into work is part of the problem, a category page for employee monitoring software should still be treated as vendor evidence to test against your own requirements, not as the requirements themselves.
Write the problem as a cost
A problem stated as a cost is checkable. A problem stated as a frustration is not, and it cannot be used to judge whether anything fixed it.
'Scheduling is a mess' is a frustration. 'The office manager spends six hours a week rebuilding the rota and we paid four hundred in unplanned overtime last month' is a cost. The second version tells you what a solution is worth, which is the number you need before anyone quotes you a price.
A problem with no number attached will be solved by whichever product demos best, because there is no other basis for comparison.
Separate the symptom from the cause
A large share of software is bought to treat a symptom whose cause is a process. The team cannot find documents, so a document management system is purchased; the cause was that nobody agreed a naming convention, and the new system now contains the same chaos with a search box.
Before specifying anything, ask what would have to change for the problem to go away without buying anything. Sometimes the answer is nothing, and the purchase is justified. Often the answer is a decision nobody has made, and the software is being asked to make it.
Describe the current process, honestly
Write down what actually happens now, step by step, including the workarounds. Not the official process — the real one, with the spreadsheet somebody maintains privately and the message thread where the real decisions get made.
This is uncomfortable and it is the single most useful artefact in a selection. It reveals where the time goes, which steps are genuinely required, and — frequently — that two of the steps exist only because of a system you are about to replace.
State what success looks like, with a number and a date
Before looking at products, agree what would have to be true in twelve months for this to have been worth doing. Rota preparation under two hours a week. Unplanned overtime down by half. Invoices out within three days of month end.
Two things follow. You now have criteria that can rule products in and out. And you have committed, in advance, to a measurement that will tell you afterwards whether it worked — which is the check almost every organisation skips, and the reason so many products sit unused without anyone calling it a failure.
Then, finally, look at products
Once the problem, the cost, the current process and the success measure are written down, looking at products becomes a filtering exercise rather than a shopping one.
It also makes the demo conversation completely different. A vendor shown a specific problem with a number attached will tell you fairly quickly whether their product addresses it. A vendor asked for a general demo will show you the general demo.
When requirements involve personal data, the NIST Privacy Framework is a useful independent reference.