Bain & Company's procurement research found that RFPs with categorised, numbered requirements receive 35 percent more accurately scoped proposals than RFPs with prose-only requirements. The reason is simple: vendors can prioritise solution effort against the requirements that matter most when those requirements are labelled, numbered, and classified. This is the section structure that delivers that.
Every requirement gets a unique identifier. The standard format is a three letter prefix plus a three or four digit number: REQ-001, FNC-024, NFR-015. The prefix can encode the requirement category (FNC functional, NFR non functional, INT integration, SEC security, RPT reporting). The number is sequential within the prefix and never reused even when requirements are deleted; deleted requirements stay listed with status "Removed" for audit traceability.
Why numbering matters: vendors can respond requirement by requirement, scoring is defensible per REQ-ID, change requests reference specific IDs, and post-implementation audits can map each delivered feature back to the requirement it satisfies. Unnumbered requirements in prose get lost; vendors cherry pick the ones they meet and skip the ones they do not.
| Prefix | Category | Example |
|---|---|---|
| FNC | Functional | FNC-014: User can submit timesheet for a week, with daily hour entry for up to 8 project codes |
| NFR | Non-functional (performance, scalability) | NFR-003: Timesheet submission completes within 2 seconds at p95 measured over a 30-day period |
| INT | Integration | INT-007: Approved timesheet data exported nightly to payroll system X via the documented REST API with reconciliation report |
| SEC | Security | SEC-002: User authentication via SAML 2.0 SSO with multi-factor enforced for admin role |
| RPT | Reporting / analytics | RPT-011: Manager dashboard shows team utilisation by week with drill-down to individual; refresh under 30 seconds at 50-person team |
| UI | User interface / accessibility | UI-005: WCAG 2.2 AA conformance on all production templates as confirmed by axe DevTools audit at handover |
| DAT | Data + retention | DAT-008: Timesheet records retained for 7 years per finance policy; deletion of records under 7 years requires admin override with audit log entry |
| OPS | Operations + monitoring | OPS-009: System exposes Prometheus-compatible metrics endpoint and ships logs to client SIEM in JSON format |
Every requirement carries a priority. MoSCoW is the most widely used scheme because the four buckets are intuitive and the trade off conversation it forces is the right one. The buckets:
Non-negotiable. Failing any Must Have requirement disqualifies the proposal. Reserve this for true non-negotiables: regulatory compliance, security baseline, core functional capability without which the system has no business value. As a rule of thumb, 40 to 60 percent of requirements should be Must Have; if everything is Must Have, prioritisation has not been done.
Important but not non-negotiable. Vendor proposal that meets all Must Haves and most Should Haves is competitive. Vendor proposal that meets all Must Haves and few Should Haves goes to the bottom of the shortlist. Typically 25 to 35 percent of requirements.
Desirable but acceptable to defer. Useful for surfacing the wish-list items that may matter in a future phase. Acceptable for the vendor to mark Not Meet, partial meet, or roadmap. Typically 10 to 20 percent of requirements.
Explicit exclusions. Items stakeholders might assume are in scope but are out of scope for this engagement. Listing them up front prevents disappointment at delivery. Typically 5 to 10 percent of the requirements list.
MoSCoW originates from DSDM (Dynamic Systems Development Method) but has long since become the cross-industry default. The BABOK Guide (Business Analysis Body of Knowledge) covers requirement prioritisation in chapter 8.
The single most common requirements failure is writing requirements that cannot be tested. Untestable requirements produce subjective acceptance decisions and disputes at UAT. The rewrite pattern is to add the measurable attribute that lets a third party decide whether the requirement is met.
| Weak (untestable) | Testable rewrite |
|---|---|
| System must be user-friendly | REQ-UI-001: System achieves SUS (System Usability Scale) score of 80+ in UAT with 20 representative users |
| System must be fast | REQ-NFR-003: Search results return within 2 seconds at p95 measured over 30 days on production traffic |
| System must be secure | REQ-SEC-007: Authentication via SAML 2.0 SSO with MFA enforced; SOC 2 Type II report covering past 12 months provided under NDA |
| System must support mobile | REQ-UI-004: Production templates render correctly on iOS Safari 16+ and Android Chrome 110+ at viewport widths 360px to 1920px |
| System must integrate with our HR system | REQ-INT-009: Nightly batch export to Workday in CSV format matching the agreed schema (Appendix C) with reconciliation report; failure alerts to client SRE on-call |
| System must be reliable | REQ-NFR-006: 99.9% monthly uptime measured by independent third-party probe (Pingdom or equivalent); service credit if missed |
| System must scale | REQ-NFR-008: Supports 10,000 concurrent users with p95 response time under 2s; demonstrated in load test before go-live |
| System must be accessible | REQ-UI-002: WCAG 2.2 Level AA conformance verified by axe DevTools and manual audit by an accessibility specialist on 10 representative templates |
Once requirements have IDs and priorities, build a traceability matrix that maps each requirement to its scope statement section, the vendor's proposed solution, and the acceptance test. The matrix is usually maintained in Excel or Confluence; for large engagements it lives in a dedicated requirements management tool (Jira, DOORS, Polarion). The matrix has columns:
The matrix becomes the single source of truth for the engagement. Change requests reference REQ-IDs and update the matrix. UAT scripts derive from the acceptance test column. Disputes about whether a feature was delivered reference the matrix row. For the requirements engineering framework see ISO/IEC/IEEE 29148 (requirements engineering) and the BABOK guide from IIBA.