Sort each requirement by asking what breaks without it. If the answer is a blocked release, a failed audit or a missed environment, it is a must. If it saves time but has a workaround, it is a should. If it is pleasant but not needed this year, it is a could. Then test every must for verifiability.
The three buckets
| Bucket | Meaning | What a vendor gap does |
|---|---|---|
| Must | Without it the tool cannot be used here | Disqualifies the vendor |
| Should | Strongly wanted, with a workaround | Costs points in scoring |
| Could | Nice if free, not worth paying for | Breaks ties only |
This is the familiar MoSCoW method with the fourth bucket ("won't this time") dropped. Writing a short "not now" list is still a good idea, because it stops scope creep during demos.
Three tests for a must
- The break test. What stops working if this is missing? Name it. "We would not be able to scan our Gradle projects" is a must. "Dashboard themes" is not.
- The audience test. Who is affected? A requirement that only one engineer cares about is probably a should.
- The proof test. Can you verify it on your own code or from a document? A must you cannot verify is a wish. Rewrite it until you can check it, for example "detects the vulnerable version in our lockfile, in a pull request, within one working day of publication."
A worked example
Suppose a platform team of twelve wants dependency risk tooling.
Must
- Reads lockfiles for the ecosystems in production.
- Runs in pull requests and reports back in the review.
- Exports a machine-readable bill of materials.
- Supports single sign-on for the reviewers.
Should
- Marks which vulnerable functions the code actually calls.
- Opens fix pull requests that a human approves.
- Maps findings to the audit framework the company uses.
Could
- Custom report themes.
- A mobile app.
- Chat integrations beyond the one the team uses.
Notice how the musts are about fit and the shoulds are about efficiency. That pattern holds up well.
Common traps
- Everything is a must. If the list has thirty musts, you have no list. Cap musts at about eight to twelve.
- Musts copied from one vendor's sheet. Rewrite them in your own words, tied to your environment.
- Musts nobody tests. Put the test next to the requirement in the same row.
- Musts that change in week three. Freeze the list before the first demo and log any change with a reason.
Writing each must so it can be tested
A requirement is only a must if you can check it. Here are five weak musts and their testable rewrites.
| Weak | Testable |
|---|---|
| Good coverage | Reads lockfiles and manifests for the five ecosystems listed in our environment section, shown on one of our repos |
| Works with CI | Posts a result into a pull request in our hosted CI within the time our reviewers will wait, shown during the trial |
| Easy to use | A developer who has never seen the tool can find the reason for a finding and its fix in under five minutes, observed with two volunteers |
| Secure | Supports single sign-on with our identity provider and records administrative actions in a log we can export |
| Scales | Completes the first scan of our largest repository within the window we state, shown in the trial |
Each rewrite names an object, a condition and a test.
Ranking shoulds with a simple vote
When the should list grows, use a quick vote to rank it. Give each panelist five dots to spread across the shoulds, with at most two on any item. Add the dots. The top three or four become scored items. The rest are tie-breakers. This takes ten minutes and avoids a long meeting.
Handling a must that no vendor meets
Sometimes every candidate fails one of your musts. That tells you either that the requirement is unusual or that it is a preference in disguise. Options include:
- Relax it to a should, with a written reason.
- Plan a workaround you can build yourself, and cost it.
- Keep the requirement and widen the search, perhaps to a different approach.
Do not quietly waive a must after the fact. Record the change and who approved it.
Handling a must that every vendor meets
A requirement that everyone passes does not help you choose. Keep it as a gate, and move your scoring weight to items that separate vendors. That is where your decision actually lives.
Review musts at the end
After the test, look back. Did any must turn out not to matter? Did you discover a new must that you had not listed, such as the way a tool handled monorepos? Update the template for next time. Over a few rounds, your requirements become a durable asset instead of a one-off document.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a pull request gate reports a finding, then decide whether "reports in the review" is a must or a should for your team.
Quick check
How many musts are reasonable?
About eight to twelve for most security tools. More than that usually means preferences have crept in.
Should a vendor that misses one must stay in the running?
No, by definition. If you would keep them anyway, the item was a should.
Who should approve the final must-have list?
The budget owner and the security lead, after the daily users have reviewed it. Freeze it before the first demo and log any later change.
When you reach scoring, Safeguard, whose GA capabilities include dependency scanning, SBOMs, reachability analysis, and policies and gates, can be checked against your musts like any other vendor. A free scan at https://gold.safeguard.sh/scan shows its output on your own repo.
Last reviewed: 19 October 2026.
