Functionele eisen beschrijven wat een systeem moet doen; niet-functionele eisen beschrijven hoe goed het dat moet doen. Functionele eisen zijn concreet en taakgericht, zoals “de gebruiker kan inloggen met een wachtwoord.” Niet-functionele eisen zijn kwaliteitsgericht, zoals “het systeem reageert binnen twee seconden.” Beide soorten eisen zijn onmisbaar voor een succesvol IT-project. In dit artikel beantwoorden we de meest gestelde vragen over het verschil, de voorbeelden en de toepassing van functionele en niet-functionele eisen in de praktijk.
Hoe verhouden functionele en niet-functionele eisen zich tot elkaar?
Functionele en niet-functionele eisen zijn complementair: de ene soort bepaalt de functionaliteit van een systeem, de andere bepaalt de kwaliteit ervan. Zonder functionele eisen weet een ontwikkelteam niet wat het moet bouwen. Zonder niet-functionele eisen weet het team niet aan welke kwaliteitsstandaard het resultaat moet voldoen. Samen vormen ze de volledige set van systeemeisen waarop een IT-oplossing wordt beoordeeld.
Een handige manier om het onderscheid te begrijpen: functionele eisen beantwoorden de vraag “wat doet het systeem?” en niet-functionele eisen beantwoorden de vraag “hoe presteert het systeem?” Een webapplicatie die bestellingen verwerkt, heeft als functionele eis dat bestellingen worden opgeslagen in een database. De niet-functionele eis bepaalt vervolgens dat dit binnen 500 milliseconden moet gebeuren en dat de applicatie beschikbaar moet zijn voor 99,9% van de tijd.
In de praktijk zien we bij IT-projecten dat functionele eisen doorgaans vroeg en relatief eenvoudig worden opgesteld, terwijl niet-functionele eisen later en minder systematisch worden meegenomen. Dat is een veelgemaakte fout met grote gevolgen, waarover later meer.
Wat zijn voorbeelden van functionele eisen?
Functionele eisen zijn concrete beschrijvingen van acties, processen of gedrag dat een systeem moet ondersteunen. Ze zijn direct te koppelen aan gebruikershandelingen of systeemprocessen, en vormen de basis van elke requirements-analyse in softwareontwikkeling.
Veelvoorkomende voorbeelden van functionele eisen zijn:
- De gebruiker kan een account aanmaken met een e-mailadres en wachtwoord.
- Het systeem verstuurt een bevestigingsmail na een succesvolle bestelling.
- Een beheerder kan gebruikersrollen toewijzen en intrekken.
- Het systeem genereert automatisch een factuur bij afsluiting van een contract.
- De applicatie toont een overzicht van alle openstaande taken per gebruiker.
- Bij een mislukte inlogpoging wordt na drie pogingen het account tijdelijk geblokkeerd.
Wat deze eisen gemeen hebben: ze zijn meetbaar, testbaar en direct te vertalen naar concrete functionaliteit. Een testteam kan na oplevering precies controleren of aan elke functionele eis is voldaan. Dat maakt ze relatief eenvoudig te valideren, maar ook eenvoudig te overschatten als enige maatstaf voor projectsucces.
Wat zijn voorbeelden van niet-functionele eisen?
Niet-functionele eisen, ook wel kwaliteitseisen of non-functional requirements (NFR) genoemd, beschrijven de kwaliteitsattributen waaraan een systeem moet voldoen. Ze gaan niet over wat het systeem doet, maar over hoe het dat doet: snel, veilig, betrouwbaar, schaalbaar en onderhoudbaar.
Gangbare categorieën en voorbeelden van niet-functionele eisen:
- Prestatie: Het systeem verwerkt minimaal 500 gelijktijdige gebruikers zonder merkbare vertraging.
- Beschikbaarheid: De applicatie is 99,5% van de tijd beschikbaar, exclusief geplande onderhoudsmomenten.
- Beveiliging: Alle communicatie verloopt via versleutelde verbindingen; toegang is gebaseerd op het principe van minimale rechten.
- Schaalbaarheid: Het systeem kan zonder aanpassingen doorgroeien van 1.000 naar 10.000 gebruikers.
- Onderhoudbaarheid: Nieuwe functionaliteit kan worden toegevoegd zonder bestaande modules te wijzigen.
- Compliance: De verwerking van persoonsgegevens voldoet aan de AVG en de vereisten van de NIS2-richtlijn.
- Gebruiksvriendelijkheid: Een nieuwe gebruiker kan de kernfuncties bedienen zonder training.
Niet-functionele eisen zijn doorgaans moeilijker te testen dan functionele eisen, maar hun impact is minstens zo groot. Een systeem dat functioneel correct is maar traag, onveilig of moeilijk te onderhouden, voldoet in de praktijk niet aan de verwachtingen van de organisatie.
Waarom worden niet-functionele eisen zo vaak over het hoofd gezien?
Niet-functionele eisen worden vaker genegeerd dan functionele eisen omdat ze minder zichtbaar zijn voor eindgebruikers en opdrachtgevers. Ze zijn abstracter, moeilijker te kwantificeren en komen pas later in het project pijnlijk naar boven, namelijk bij acceptatietests, productie-incidenten of beveiligingsaudits.
Er zijn drie structurele oorzaken voor dit probleem:
- Onvoldoende betrokkenheid van de juiste stakeholders. Niet-functionele eisen raken architectuur, beveiliging, infrastructuur en compliancevereisten. Als deze disciplines niet vroeg aan tafel zitten, worden de bijbehorende eisen niet opgesteld.
- Gebrek aan meetbare definities. “Het systeem moet snel zijn” is geen niet-functionele eis. Pas als er een concrete drempelwaarde staat, zoals “maximaal 1,5 seconde responstijd bij 200 gelijktijdige gebruikers,” is de eis bruikbaar. Het ontbreken van deze specificiteit maakt niet-functionele eisen onzichtbaar in planningen en backlogs.
- Druk op functionaliteit boven kwaliteit. In projecten met strakke deadlines en beperkte budgetten worden niet-functionele eisen als optioneel beschouwd. Ze worden uitgesteld naar een volgende fase die er in de praktijk zelden van komt.
De gevolgen zijn aanzienlijk: systemen die na oplevering slecht presteren, beveiligingslekken bevatten of niet voldoen aan wet- en regelgeving zoals de AVG of NIS2. Herstelwerk achteraf is vrijwel altijd duurder dan het correct opstellen van eisen aan het begin van een project.
Wie is verantwoordelijk voor het vastleggen van beide soorten eisen?
De verantwoordelijkheid voor het vastleggen van functionele en niet-functionele eisen ligt bij meerdere rollen tegelijk. Er is geen enkele persoon die dit volledig alleen kan dragen, maar de business analist of informatieanalist speelt doorgaans de centrale coördinerende rol in het requirements-proces.
De verdeling in de praktijk ziet er als volgt uit:
- Business analist of informatieanalist: Inventariseert en structureert functionele eisen op basis van gesprekken met stakeholders en eindgebruikers. Bewaakt de volledigheid van het requirements-document.
- Architect (solution, enterprise of security): Vertaalt technische en organisatorische kaders naar niet-functionele eisen op het gebied van schaalbaarheid, beveiliging en onderhoudbaarheid.
- Product Owner: Prioriteert eisen in de backlog en bewaakt de balans tussen functionele waarde en kwaliteitsattributen.
- Compliance officer of privacy officer: Zorgt dat niet-functionele eisen op het gebied van beveiliging, privacy en wet- en regelgeving correct zijn opgenomen.
- Testmanager of QA-lead: Maakt eisen testbaar door acceptatiecriteria te definiëren voor zowel functionele als niet-functionele eisen.
In organisaties die werken met externe IT-professionals via IT-detachering is het gebruikelijk dat een senior business analist of solution architect tijdelijk wordt ingehuurd om dit proces te structureren, met name bij complexe projecten of transformatietrajecten waar interne capaciteit ontbreekt.
Hoe gebruik je functionele en niet-functionele eisen in een IT-project?
Functionele en niet-functionele eisen gebruik je als fundament voor elke fase van een IT-project: van ontwerp en ontwikkeling tot testen en acceptatie. Ze vormen samen de contractuele basis tussen opdrachtgever en uitvoerend team, en bepalen de criteria waarop het eindresultaat wordt beoordeeld.
Requirements ophalen en vastleggen
Begin vroeg in het project met het ophalen van eisen via gestructureerde sessies met stakeholders: eindgebruikers, proceseigenaren, architecten en complianceverantwoordelijken. Leg functionele eisen vast in user stories of use cases. Leg niet-functionele eisen vast in een apart NFR-document of als acceptatiecriteria per user story, met concrete meetwaarden. Vermijd vage omschrijvingen: elke eis moet testbaar zijn.
Eisen meenemen in ontwerp en ontwikkeling
Niet-functionele eisen zijn geen bijlage die na oplevering wordt gecontroleerd. Ze moeten het ontwerp van de architectuur sturen. Een eis op het gebied van beveiliging bepaalt de keuze voor authenticatiemethoden; een eis op het gebied van schaalbaarheid bepaalt de keuze voor cloudinfrastructuur. Architecten en ontwikkelaars moeten deze eisen actief meenemen in technische beslissingen.
Testen op beide soorten eisen
Functionele eisen worden getest met functionele tests: klopt het gedrag van het systeem met de beschreven gebruiksscenario’s? Niet-functionele eisen vereisen andere testvormen: prestatietests, penetratietests, beschikbaarheidstests en gebruiksvriendelijkheidstests. Een volledig testplan dekt beide categorieën. Organisaties die werken met een gespecialiseerd projectteam voor IT-implementaties betrekken een QA-lead of testarchitect vroeg in het proces om dit testplan op te stellen.
In complexe IT-trajecten, zoals cloudmigraties, legacy-vervanging of complianceprojecten rondom NIS2 en cybersecurity, zijn niet-functionele eisen op het gebied van beveiliging, beschikbaarheid en compliance niet optioneel. Ze zijn wettelijk verplicht en vormen de basis van de risicobeheersing van de organisatie. Organisaties die hier ondersteuning bij zoeken, kunnen terecht bij Ventus, een IT-detacheringsbureau met ruim 25 jaar ervaring in het leveren van senior IT-professionals die requirements-trajecten in de praktijk begeleiden en uitvoeren.
Wil je weten welke professional het beste past bij jouw requirements-vraagstuk? Neem contact op voor een vrijblijvend gesprek.