Lesson 2.4 — Functional vs. Technical Requirements
Content
This lesson introduces the distinction between functional and technical requirements, explains why functional specifications are far more innovation-friendly, and presents key methods for developing high-quality procurement requirements.
What you will learn:
— Functional specifications defined: the public buyer sets minimum requirements to avoid abnormally low-performing tenders, but is not overly prescriptive regarding the means of achieving a desired outcome
— Functional vs. technical requirements illustrated with seven domain examples: Authentication (“users must log in securely” vs. OAuth 2.0 + 256-bit encryption), Microscopy (cellular resolution vs. specific camera specs), Reporting (monthly financial reports vs. PDF/SQL/SharePoint), Collaboration (remote team support vs. Zoom + 1080p + 100 participants), Data Storage (10-year patient record security vs. PostgreSQL + AES-256), Energy Efficiency (minimise energy consumption vs. HVAC inverter + LED + R-value), Accessibility (usability by visually impaired vs. WCAG 2.1 AA compliance)
— Why functional specs are far more innovation-friendly: 80% of EC-funded innovation procurement projects used this approach; they shift performance responsibility to the market; economic operators gain openness and flexibility to reach optimal performance
— The nuance: descriptive requirements can attract innovation too, but functional requirements make it significantly easier by leaving the market free to compete with solutions fit for the challenge
— The MoSCoW Prioritisation Framework: Must Have (critical requirements), Should Have (important features), Could Have (nice-to-have), Won’t Have (excluded items)
— Four primary methods for developing requirements: Voice of the Customer (interviews, surveys), Stakeholder Mapping & Inclusion (identify all parties, RACI matrix, multi-stakeholder consultations), Functional Requirement Analysis (define what items must DO, translate functions into measurable criteria, validate with users), Minimum Viable Requirement — MVR (define minimum acceptable performance, prevent over-specification, separate must-have vs. value-add)
— Four additional methods: Total Cost of Ownership (durability, maintenance + ops cost, warranties), Risk-Based Specification (high-impact risks, risk-based criteria prioritisation, mitigation through specs), Benchmarking & Market Research (industry standards, peer organisations, PMC/RFI market sounding), Iterative Drafting & Validation (draft → review → market test → refine, ensure realism and clarity)
— Why functional specifications foster innovation across seven dimensions: creative solutions, open competition, adaptability, focus on value not compliance, stimulate collaboration, reduce obsolescence risk, drive continuous improvement
— Niguarda Hospital (Italy) case study: WIBGIF need — automated system to move hospital beds avoiding accidents and injuries to nursing staff; functional specs for life cycle 1 (easy to learn, install without calibration); outcome — new cost-effective automated universal medical device for moving hospital beds

