Drie manieren om een behoefte te specificeren

Technische specificaties bepalen de vereiste kenmerken van de gevraagde levering of dienst. Binnen ICT-opdrachten worden drie benaderingen vaak naast elkaar gebruikt. De juiste keuze hangt af van het doel, de bestaande omgeving, het risico en de ruimte die de markt nodig heeft.

Functionele eisen beschrijven wat gebruikers moeten kunnen doen

Een functionele eis vertrekt vanuit een taak, proces of gewenste mogelijkheid. Bijvoorbeeld: “Een dossierbeheerder kan een aanvraag opzoeken op dossiernummer, naam en datum.” De eis schrijft niet voor welke softwarecomponent of zoektechnologie daarvoor wordt gebruikt.

Prestatie-eisen beschrijven welk resultaat moet worden gehaald

Een prestatie-eis maakt een kwaliteitsniveau meetbaar. Bijvoorbeeld: “Voor 95% van de zoekopdrachten verschijnt het resultaat binnen twee seconden bij de afgesproken belasting.” Prestatie-eisen kunnen betrekking hebben op beschikbaarheid, capaciteit, responstijd, herstel, nauwkeurigheid, energiegebruik of andere relevante resultaten.

Technische eisen beschrijven kenmerken, interfaces of standaarden

Een technische eis legt een concrete randvoorwaarde vast, zoals een protocol, gegevensformaat, beveiligingsmechanisme, compatibiliteitsvereiste of architectuurregel. Ze is nuttig wanneer interoperabiliteit, veiligheid, bestaande infrastructuur of wettelijke verplichtingen weinig oplossingsruimte toelaten.

KernideeFunctionele eisen creëren oplossingsruimte. Technische eisen beschermen noodzakelijke grenzen. Prestatie-eisen maken het resultaat toetsbaar.

Wanneer kiest u welke vorm?

Kies functioneel wanneer meerdere oplossingen mogelijk zijn

Functionele specificaties zijn sterk wanneer de markt beter geplaatst is om de oplossing te ontwerpen, wanneer technologie snel evolueert of wanneer innovatie gewenst is. Ze helpen voorkomen dat een historisch systeem onbedoeld wordt gekopieerd in een nieuwe opdracht.

Kies prestatiegericht wanneer de uitkomst objectief meetbaar is

Gebruik prestatie-eisen voor aspecten die tijdens beoordeling, acceptatie of uitvoering aantoonbaar moeten zijn. Definieer daarbij meetmethode, omstandigheden, frequentie en eventuele toleranties. “Snel”, “gebruiksvriendelijk” of “zeer beschikbaar” zijn zonder meetwijze onvoldoende precies.

Kies technisch wanneer compatibiliteit of beheersing noodzakelijk is

Technische eisen zijn passend voor kritieke interfaces, gegevensuitwisseling, security-baselines, toegestane omgevingen en bewezen standaarden. Controleer wel of iedere technische beperking werkelijk noodzakelijk en proportioneel is. Een voorkeur van één intern team is niet automatisch een objectieve randvoorwaarde.

Wees terughoudend met merken en productspecifieke kenmerken

De Europese aanbestedingsregels verlangen gelijke toegang en verbieden ongerechtvaardigde belemmeringen van de mededinging. Een verwijzing naar een merk, herkomst, octrooi of specifiek type is in beginsel niet de normale route. Waar een dergelijke verwijzing uitzonderlijk nodig is om de behoefte voldoende precies te beschrijven, hoort gelijkwaardigheid correct te worden behandeld. Laat dit voor een concreet dossier juridisch controleren.

In de praktijk is een bewuste combinatie meestal het sterkst

Een ICT-bestek hoeft niet volledig functioneel of volledig technisch te zijn. De Europese regels voorzien uitdrukkelijk verschillende formuleringen en combinaties. Een bruikbare opbouw is:

  1. Doelstelling: waarom de organisatie dit nodig heeft.
  2. Functionele behoefte: welke processen en gebruikersmogelijkheden vereist zijn.
  3. Prestatieniveau: welke meetbare kwaliteit minimaal moet worden gehaald.
  4. Technische grenzen: welke interfaces, standaarden en beveiliging noodzakelijk zijn.
  5. Bewijs en verificatie: hoe een inschrijver conformiteit aantoont en hoe de opdrachtgever test.

Voorbeeld: schrijf niet alleen “de oplossing gebruikt technologie X”. Beschrijf eerst dat gegevens veilig en tijdig met systeem Y moeten worden uitgewisseld. Leg vervolgens het noodzakelijke gegevensformaat, protocol, authenticatieniveau, volume en prestatieniveau vast. Zo blijft de eis verbonden met het doel.

Maak iedere eis eenduidig en toetsbaar

Gebruik één verplichting per eis

Geef iedere eis een uniek nummer en vermijd lange paragrafen met meerdere verplichtingen. Dat maakt vragen, antwoorden, conformiteitscontrole en latere wijzigingen beter beheersbaar.

Vermeld het vereiste niveau

Maak duidelijk of iets verplicht, gewenst of informatief is. Meng geen minimumeis en gunningswens in dezelfde formulering. Leg vooraf vast hoe een afwijking wordt behandeld.

Vraag passend bewijs

Bepaal of een verklaring, technische documentatie, certificaat, test, demo of proof of concept nodig is. Het bewijs moet verband houden met de eis en proportioneel blijven. Houd rekening met gelijkwaardige bewijsmiddelen waar de regels dat vereisen.

Koppel eisen aan acceptatie en contractopvolging

Een eis die belangrijk genoeg is voor het bestek moet waar relevant terugkomen in het testplan, de acceptatiecriteria, SLA, rapportering of contractuele deliverables. Anders dreigt ze na de gunning haar betekenis te verliezen.

Valkuilen die marktwerking en uitvoering verzwakken

  • het bestaande product of contract woordelijk kopiëren;
  • functionele wensen formuleren zonder prioriteit of acceptatiemethode;
  • technische voorkeuren als absolute noodzaak presenteren;
  • normen noemen zonder gelijkwaardigheid correct te behandelen;
  • tegenstrijdige eisen verspreiden over verschillende documenten;
  • te veel detail voorschrijven en tegelijk resultaatverantwoordelijkheid bij de leverancier leggen;
  • eisen opnemen die tijdens de uitvoering niet kunnen worden gecontroleerd.

Checklist voor het requirements-overleg

  • Is duidelijk welk probleem of resultaat achter iedere belangrijke eis zit?
  • Kan de eis functioneel of prestatiegericht worden geformuleerd?
  • Is iedere technische beperking aantoonbaar noodzakelijk?
  • Zijn volumes, omstandigheden en meetmethoden beschreven?
  • Zijn begrippen en normen eenduidig gedefinieerd?
  • Kunnen verschillende leveranciers de eis op gelijkwaardige wijze beantwoorden?
  • Is het gevraagde bewijs relevant en proportioneel?
  • Is duidelijk hoe de eis bij acceptatie of uitvoering wordt gecontroleerd?
  • Zijn eisen onderling consistent en traceerbaar naar de behoefte?
Praktische conclusieSchrijf functioneel waar de markt oplossingsruimte verdient, technisch waar de organisatie aantoonbaar grenzen nodig heeft en prestatiegericht waar het resultaat objectief moet kunnen worden bewezen.

Officiële achtergrond

Dit artikel biedt algemene informatie en vervangt geen juridisch of professioneel advies voor een concrete plaatsingsprocedure, offerte of overeenkomst.