How to Write Technology Requirements Vendors Can Price Accurately

Why requirements go wrong

• A brand or model is specified without a reason, which limits competition.
• Words such as "fast", "secure" and "reliable" mean different things to each vendor.
• Quantities are missing, so vendors guess.
• Site conditions are unknown until installation starts.
• There are no acceptance criteria, so "done" is argued about later.
• Unrelated work is bundled together, hiding the cost of each part.

Structure of a good requirements document

1. Background and objectives.
2. Current environment.
3. Scope of work, with inclusions and exclusions.
4. Functional requirements.
5. Technical and performance requirements.
6. Security, privacy and compliance requirements.
7. Site information and constraints.
8. Deliverables, including documentation and training.
9. Schedule and milestones.
10. Acceptance criteria and tests.
11. Warranty, support and service levels.
12. Vendor qualifications and submission requirements.
13. Pricing format.
14. Evaluation criteria.

Make requirements measurable

Scope boundaries

Quantities and site information

• Scaled floor plans with the number of outlets, access points or cameras per area.
• Cable routes, ceiling types and any areas that are hard to reach.
• Building rules, working hours and permit requirements.
• Photos of equipment rooms and existing installations.
• A scheduled site visit for all interested vendors before the quotation deadline.

Standards and brands

Reference standards and interoperability requirements rather than brands: cabling standards for structured cabling, ONVIF profiles for IP cameras, WCAG 2.2 for websites. If compatibility with existing systems genuinely requires a brand, say why and consider accepting equivalents. For government buyers, the New Government Procurement Act (Republic Act No. 12009) does not allow reference to brand names except for reasons such as technical compatibility, interoperability, servicing and maintenance; follow its implementing rules and Government Procurement Policy Board issuances.

Acceptance criteria

• Define the evidence for each deliverable: cable test reports, Wi-Fi survey results, failover and restore tests, security scan results.
• List required documentation: as-built drawings, configurations, asset lists and credentials handed over securely.
• Describe the sign-off process and how defects found during acceptance are handled.
• Link payment milestones to acceptance.

Pricing format

• An itemized bill of quantities for hardware, software licences with terms, labor and services.
• Recurring costs separated from one-time costs, over an agreed number of years.
• Optional items priced separately.
• Assumptions listed explicitly.
• Currency, taxes and how long the quotation remains valid.

Evaluation

• Publish evaluation criteria and their weights.
• Ask vendors to complete a compliance matrix stating whether each requirement is met fully, partly or not at all.
• Run clarifications in writing and share answers with all vendors.
• Compare total cost over the agreed period, not just the initial price.