A requirement is useful when the buyer can test what meeting it means.
Outcome → condition → evidence
Replace “robust reporting” with a named user, task, operating condition and acceptable result. For example: a category manager must export line-level spend with legal supplier names and contract identifiers, subject to approved access controls, without a paid consulting engagement.
State the business reason alongside the requirement. Suppliers can then explain a different way to meet the outcome. Prescribe the method only where a real compatibility, safety, security or operating constraint requires it.
Keep requirement types distinct
| Type | What to specify | Evidence |
|---|---|---|
| Business / functional | User task, volume and expected outcome. | Scripted scenario using representative data. |
| Technical / integration | Interfaces, identity, environments and ownership. | Architecture review and integration test. |
| Security / data | Access, retention, incident handling and approved locations. | Specialist assessment and applicable assurance evidence. |
| Implementation / support | Resourcing, acceptance, coverage and escalation. | Named delivery plan and service commitments. |
| Commercial / contractual | Units, growth, renewal, dependencies and exit. | Completed pricing schedule and recorded deviations. |
Do not use a generic security questionnaire as a substitute for understanding the actual service boundary. Identify what the supplier operates, what an underlying provider operates and what remains the buyer’s responsibility.
Separate gates from preferences
A mandatory requirement should be important enough that failure truly prevents award, unless an authorized exception process says otherwise. Too many mandatory requirements exclude useful alternatives. Too few let a serious compliance or operating gap disappear inside an average score.
Use evaluated criteria for tradeoffs. Use optional items for incremental capability that is not necessary to the initial outcome. Require suppliers to distinguish currently available capability, configuration, customization, third-party products and roadmap plans. Record the cost and support implications of each.
Freeze the evaluation basis responsibly
Review the draft with business, technical, security, finance and legal owners. Test whether two evaluators would interpret it similarly. After issue, log changes and communicate material amendments consistently. Keep a link between each critical requirement, its evidence, the selected offer and the eventual acceptance test.
Sources & context
- U.S. FAR 15.304 · Evaluation factors ↗U.S. federal procurement requirements, cited for context. They are not presented as rules governing private purchases.
The decision frameworks and illustrative examples are original editorial guidance. Sources support the stated context; they do not endorse this guide.