Name the problem before you look at anything
Most selections start with a product somebody liked. The requirements are then written to describe it.
Read the guideSection · 6 guides
Requirements
Working out what the problem actually is, and what would have to be true for any product to solve it.
Home/Requirements
Most software selections begin at the wrong end. Somebody sees a product, likes it, and works backwards to a justification. The requirements document, if one exists, is written afterwards and describes the product that has already been chosen.
This section is about the work that should happen first: naming the problem in terms of what it costs today, separating the handful of things that genuinely rule a product out from the long list of things that would be nice, and being honest about who has to agree. To see how a vendor frames workforce analytics in practice, workforce analytics software is useful as an example to translate into neutral requirements.
Requirements are easiest to write when the problem is already measured. If the complaint is that nobody knows where the week goes, the requirement is a number rather than a feeling — which is why a category like time tracking (Monitask and its competitors) is often evaluated badly: teams buy it to find out what the problem is, rather than deciding first what they would do with the answer.
Example note: Monitask is referenced only as an example of a software category or workflow, not as a recommendation or a statement of affiliation.
For practical security questions that small teams can put into requirements, CISA guidance for small businesses provides a useful external baseline.
Requirements that actually filter
A list of forty requirements that every serious product satisfies has not narrowed anything. It has just taken three weeks to write.
Read the guideThe must-have that turns out to be negotiable
Every selection contains a requirement that eliminated a good product and mattered to nobody once it was gone.
Read the guideWho should be in the room, and who should not
Selections fail late because somebody with a veto was consulted after the decision rather than before it.
Read the guideCosting the option of doing nothing
Every business case compares products to each other. The comparison that matters is against changing nothing at all.
Read the guideBuild, buy, or neither
The build option is usually dismissed on cost and the buy option on fit. Both dismissals are made too early and on the wrong grounds.
Read the guide