Turn a vague brief into decision criteria
A requirements list is a decision tool, not a catalogue of everything that might be nice. It clarifies what the product must achieve, the constraints it must respect and the evidence needed before a claim earns a score.
Write each requirement as an observable need with an owner, importance, evidence source and decision rule. Separate non-negotiables from weighted preferences. Include people, workflow, compatibility, accessibility, security, privacy, support, total cost and exit—not only product features.
Build a shortlist-ready requirements sheet
- Outcome: the task or result that must improve.
- Users: skills, access needs, number of people and shared ownership.
- Workflow: the critical actions, information and handovers involved.
- Compatibility: devices, operating systems, services, formats, networks and accessories.
- Security and privacy: data sensitivity, account access, updates, recovery and controls.
- Support: minimum support life, help route, repair, replacement and service level where relevant.
- Cost: purchase, setup, subscription, accessories, training, maintenance, repair and exit.
- Evidence: current documentation, trial result, contract term, demonstration or real-world test.
Use three kinds of requirement
Non-negotiable
A failure means the option cannot proceed: a required accessibility function, a mandatory integration, approved data handling or a minimum support commitment.
Weighted preference
A desirable attribute that can be compared once every viable option meets the essentials: portability, optional automation, design, speed or convenience.
Open question
An uncertainty that needs evidence before scoring: a trial task, a written confirmation, an account-recovery route or a pricing clarification.
Do not confuse a claim with evidence
Record where each answer came from and whether it is current. A public feature page may show intent; a current support policy, contract term, product documentation or real task test may provide stronger evidence. For a transparent comparison method, use how to compare technology options fairly.
Requirements FAQs
How many requirements should I have?
Use enough to expose the real decision, but not so many that every minor preference becomes a false red line. Start with the outcome and risks, then remove requirements that would not change the choice.
Should a vendor help write our requirements?
A vendor can clarify what its product does, but should not be the only source defining the problem or the score. Keep the requirements owned by the buyer and validate important claims independently.
What is a good evidence source?
The source depends on the claim. A current contract, official support policy, accessible demonstration, verified trial, technical documentation or direct answer in writing can be useful when it clearly addresses the requirement.
Continue the buying decision
Use the next guide that fits the decision still in front of you. Keep the need, non-negotiables, evidence and uncertainty visible until you can explain why this option is the better fit.
