Definitie: Functionele eisen beschrijven wat een softwaresysteem moet doen: welke handelingen een gebruiker kan uitvoeren, welke gegevens worden vastgelegd en hoe het systeem reageert op invoer. Niet-functionele eisen beschrijven hoe goed het systeem dat doet, zoals snelheid, beveiliging, beschikbaarheid en gebruiksgemak.
In het kort
- Een functionele eis is bijvoorbeeld: “Een planner kan een opdracht toewijzen aan een monteur.”
- Een niet-functionele eis is bijvoorbeeld: “Het overzicht laadt binnen twee seconden bij duizend opdrachten.”
- Goede eisen zijn concreet, toetsbaar en voorzien van een prioriteit, bijvoorbeeld met de MoSCoW-methode.
- Eisen worden vaak vastgelegd in een programma van eisen, als user stories met acceptatiecriteria of in een combinatie daarvan.
Wat zijn functionele eisen?
Functionele eisen, in het Engels functional requirements, leggen vast wat de software moet kunnen. Ze beschrijven het gedrag van het systeem vanuit het perspectief van de gebruiker en het proces. Denk aan inloggen, een aanvraag indienen, een offerte goedkeuren, een rapport exporteren of een melding versturen als een termijn verloopt.
Een functionele eis beantwoordt de vraag: wat gebeurt er? Wie doet iets, met welke gegevens, en wat is het resultaat? Hoe concreter die beschrijving, hoe kleiner de kans dat opdrachtgever en ontwikkelaar iets anders voor ogen hebben.
Functionele eisen gaan over verschillende onderwerpen: de handelingen van gebruikers, de rollen en rechten, de gegevens die worden vastgelegd, berekeningen en regels, meldingen en rapportages, en koppelingen met andere systemen. Samen beschrijven ze het complete gedrag van de software.
Wat zijn niet-functionele eisen?
Niet-functionele eisen, ook wel kwaliteitseisen genoemd, beschrijven de eigenschappen van het systeem. Ze gaan niet over een specifieke handeling, maar over hoe het systeem zich gedraagt. Voorbeelden zijn:
- Prestaties. Hoe snel reageert het systeem, ook bij veel gebruikers of gegevens?
- Beveiliging. Wie mag wat zien en doen, hoe worden gegevens beschermd en hoe wordt ingelogd?
- Beschikbaarheid. Wanneer moet het systeem bereikbaar zijn, en hoe snel moet het na een storing weer werken?
- Gebruiksgemak. Kan een nieuwe gebruiker zonder uitleg een taak afronden?
- Schaalbaarheid. Kan het systeem groeien in gebruikers en gegevens?
- Onderhoudbaarheid. Kan een andere ontwikkelaar de code begrijpen en aanpassen?
- Privacy en wetgeving. Voldoet het systeem aan de AVG en andere regels?
- Compatibiliteit. Op welke apparaten en browsers moet het werken?
De internationale norm ISO/IEC 25010 beschrijft een model van kwaliteitskenmerken voor software, dat vaak als houvast wordt gebruikt bij het opstellen van niet-functionele eisen.
Functionele en niet-functionele eisen naast elkaar
| Functionele eisen | Niet-functionele eisen | |
|---|---|---|
| Vraag | Wat doet het systeem? | Hoe goed doet het systeem dat? |
| Voorbeeld | Een klant kan een retour aanmelden | Het formulier werkt op mobiel en is toegankelijk |
| Voorbeeld | De beheerder kan gebruikers toevoegen | Alleen beheerders zien persoonsgegevens van anderen |
| Voorbeeld | Het systeem verstuurt een herinnering na zeven dagen | Herinneringen worden binnen vijf minuten verstuurd |
| Toetsen | Werkt de functie zoals beschreven? | Wordt de norm gehaald, gemeten met een test? |
| Gevolg als het ontbreekt | Een functie mist | Het systeem werkt, maar traag, onveilig of onhandig |
Voorbeelden van functionele eisen
Voor een eenvoudig systeem voor offerteaanvragen kunnen de functionele eisen er zo uitzien:
- Een bezoeker kan via een formulier een offerte aanvragen met naam, e-mailadres, product en hoeveelheid.
- Het systeem controleert of alle verplichte velden zijn ingevuld voordat de aanvraag wordt verstuurd.
- Een nieuwe aanvraag krijgt de status “nieuw” en verschijnt in het overzicht van de binnendienst.
- Een medewerker kan een aanvraag aan zichzelf toewijzen.
- Een medewerker kan een offerte opstellen en als PDF naar de klant versturen.
- Het systeem verstuurt een herinnering aan de medewerker als een aanvraag na twee werkdagen nog geen offerte heeft.
- Een leidinggevende ziet per week hoeveel aanvragen zijn binnengekomen en omgezet.
Hoe schrijf je goede eisen?
Een goede eis is:
- Concreet. Niet “het systeem moet gebruiksvriendelijk zijn”, maar “een nieuwe medewerker kan zonder uitleg een aanvraag toewijzen.”
- Toetsbaar. Je kunt na de bouw controleren of de eis is gehaald.
- Eenduidig. Er is maar één manier om de eis te lezen.
- Haalbaar binnen techniek, tijd en budget.
- Gekoppeld aan een doel of gebruiker, zodat duidelijk is waarom de eis bestaat.
- Voorzien van een prioriteit, zodat je kunt kiezen als niet alles in de eerste versie past.
Vermijd vage woorden als “snel”, “makkelijk”, “veilig” of “flexibel” zonder ze meetbaar te maken. Wat voor de een snel is, is voor de ander traag.
User stories en acceptatiecriteria
Veel teams leggen functionele eisen vast als user stories. Die volgen een vaste vorm:
Als planner wil ik een opdracht aan een monteur toewijzen, zodat de monteur weet wat hij vandaag moet doen.
Bij elke user story horen acceptatiecriteria: de voorwaarden waaronder de story als af geldt. Bijvoorbeeld:
- De planner kan alleen monteurs kiezen die op die dag beschikbaar zijn.
- De monteur ziet de opdracht direct in zijn dagoverzicht.
- Een toegewezen opdracht krijgt de status “ingepland”.
User stories houden de eis dicht bij de gebruiker en het doel. Acceptatiecriteria maken haar toetsbaar.
Prioriteren met MoSCoW
Niet alle eisen zijn even belangrijk. De MoSCoW-methode verdeelt eisen in vier groepen:
| Categorie | Betekenis |
|---|---|
| Must have | Zonder deze eis is de eerste versie niet bruikbaar |
| Should have | Belangrijk, maar er is een tijdelijke oplossing mogelijk |
| Could have | Wenselijk als er tijd en budget over is |
| Won’t have (this time) | Bewust niet in deze versie |
Vooral de laatste categorie is waardevol. Door expliciet vast te leggen wat er niet in komt, voorkom je discussie en meerwerk.
Niet-functionele eisen meetbaar maken
Niet-functionele eisen zijn het lastigst om concreet te maken. Een paar voorbeelden van hoe je een vage wens omzet in een toetsbare eis:
| Vage wens | Toetsbare eis |
|---|---|
| Het systeem moet snel zijn | Zoekresultaten verschijnen binnen twee seconden bij tienduizend records |
| Het moet veilig zijn | Gebruikers loggen in met tweestapsverificatie; medewerkers zien alleen klanten van hun eigen vestiging |
| Het moet altijd werken | Het systeem is tijdens kantooruren beschikbaar, met een maximale uitval van één uur per maand |
| Het moet makkelijk zijn | Vier van de vijf testgebruikers ronden de taak zonder hulp af binnen drie minuten |
| Het moet op mobiel werken | Alle schermen zijn bruikbaar op een smartphone met een schermbreedte vanaf 375 pixels |
Spreek ook af hoe je de eis toetst: met een belastingtest, een beveiligingscontrole of een test met gebruikers.
Wie stelt de eisen op?
Eisen ontstaan in samenwerking. De opdrachtgever weet wat het systeem moet opleveren en welke prioriteiten gelden. Gebruikers weten hoe het werk nu verloopt en welke uitzonderingen er zijn. De ontwikkelaar vertaalt dat naar haalbare, toetsbare eisen en wijst op niet-functionele eisen die anders worden vergeten. Een korte reeks gesprekken en een gezamenlijke review van de lijst voorkomt dat eisen alleen vanuit één perspectief worden geschreven.
Waar leg je eisen vast?
- Programma van eisen. Een document met alle functionele en niet-functionele eisen, vaak gebruikt bij offertes en aanbestedingen.
- Backlog met user stories. Een lijst met stories in een tool als Jira of Linear, geschikt bij iteratief ontwikkelen.
- Schermschetsen of een prototype. Laat zien hoe de eisen in schermen worden vertaald.
- Procesbeschrijving. De route van begin tot eind, met de plekken waar het systeem een rol speelt.
In de praktijk werkt een combinatie goed: een korte procesbeschrijving, schetsen van de belangrijkste schermen en een lijst met eisen en prioriteiten.
Veelgemaakte fouten
- Oplossingen in plaats van eisen. “We willen een dropdown” zegt iets over het ontwerp. De eis is: “de gebruiker kiest één van de vijf productcategorieën.”
- Niet-functionele eisen vergeten. Ze komen vaak pas op tafel als het systeem traag of onveilig blijkt.
- Uitzonderingen overslaan. Wat gebeurt er bij een lege lijst, een dubbele aanvraag of een gebruiker zonder rechten?
- Alles is een must have. Dan is er geen keuze meer mogelijk als tijd of budget krap wordt.
- Eisen zonder eigenaar. Iemand moet kunnen beslissen als eisen elkaar tegenspreken.
- Eisen die niet meegroeien. Tijdens de bouw leer je bij. Werk de lijst bij, zodat hij blijft beschrijven wat er echt wordt opgeleverd.
Wat betekent dit voor jouw project?
In Leadooo, mijn eigen kleine CRM-app, zit een onderscheid dat goed laat zien hoe precies een functionele eis moet zijn. Een status vertelt waar iets staat, een geplande actie vertelt wat er moet gebeuren. Dat lijkt een detail, maar het bepaalt welke schermen, velden en herinneringen nodig zijn.
In mijn werkwijze worden de eisen vastgelegd in de betaalde blauwdruk, samen met het afgebakende proces, schermschetsen en afhankelijkheden. Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen, en daar horen ook de dingen bij die bewust later komen.
Wil je je idee vertalen naar concrete eisen voor een eerste versie? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap.
Veelgestelde vragen over functionele eisen
Wat zijn functionele eisen?
Functionele eisen beschrijven wat een softwaresysteem moet doen: welke handelingen een gebruiker kan uitvoeren, welke gegevens worden vastgelegd en hoe het systeem reageert op invoer.
Wat is het verschil tussen functionele en niet-functionele eisen?
Functionele eisen beschrijven wat het systeem doet, zoals een aanvraag indienen of een rapport maken. Niet-functionele eisen beschrijven hoe goed het systeem dat doet, zoals snelheid, beveiliging, beschikbaarheid en gebruiksgemak.
Wat is een voorbeeld van een niet-functionele eis?
Een voorbeeld is: het overzicht laadt binnen twee seconden bij duizend opdrachten. Andere voorbeelden zijn dat alleen beheerders persoonsgegevens van anderen zien, of dat het systeem op mobiel en desktop werkt.
Verwante termen
Programma van eisen · Discovery-fase · Klikbaar prototype · Prototype · MVP (Minimum Viable Product) · Fixed price vs nacalculatie
← Terug naar de kennisbank