Een programma van eisen is een gestructureerde lijst van alle functionele, technische en organisatorische eisen die een nieuw softwaresysteem moet vervullen. Het verschilt van een RFP (Request for Proposal) doordat het PvE alleen de eisen zelf bevat, terwijl de RFP daar de volledige uitvraag omheen bouwt (bedrijfscontext, vragen, tijdlijn, beoordelingscriteria). Zie voor de volledige uitvraag onze RFP-template.
Het grootste risico bij een PvE is een lijst met honderden eisen waarin alles "belangrijk" is. Dat maakt vergelijken onmogelijk: als elke eis even zwaar telt, wint het pakket dat toevallig de meeste vinkjes zet, niet het pakket dat je grootste probleem oplost. De oplossing is prioritering, en de meest gebruikte methode daarvoor is MoSCoW.
De MoSCoW-methode uitgelegd
MoSCoW is een prioriteringstechniek die elke eis in een van vier categorieën plaatst: Must have, Should have, Could have en Won't have (dit keer). Deze indeling dwingt je om echt na te denken over wat een pakket moet kunnen om überhaupt in aanmerking te komen, in plaats van een wensenlijst zonder rangorde.
| Categorie | Betekenis | Effect bij scoring |
|---|---|---|
| Must have | Zonder deze functie valt het pakket direct af | Knock-out criterium: niet voldaan = uitsluiten |
| Should have | Belangrijk, maar met een tijdelijke workaround te overbruggen | Zwaar wegend in de score, geen directe uitsluiting |
| Could have | Wenselijk, geeft een voorkeur bij een gelijke stand | Licht wegend, tie-breaker tussen vergelijkbare pakketten |
| Won't have (dit keer) | Bewust buiten scope, bijvoorbeeld voor een latere fase | Telt niet mee in de score, voorkomt scope creep |
Voorbeeld programma van eisen per softwarecategorie
Onderstaande voorbeelden zijn een startpunt, geen uitputtende lijst. Vul ze aan met je eigen situatie: branche-specifieke wetgeving, bestaande koppelingen en het aantal gebruikers bepalen uiteindelijk je volledige PvE.
| Categorie | Must have (voorbeeld) | Should have (voorbeeld) | Could have (voorbeeld) |
|---|---|---|---|
| ERP & boekhouding | Automatische BTW-aangifte, UBL-facturatie, koppeling met NL-bank | Voorraadbeheer, multi-valuta, accountantskoppeling | Ingebouwde AI-boekingsvoorstellen |
| CRM & sales | Pijplijnbeheer, e-mailintegratie, offertes genereren | Koppeling met boekhoudpakket, rapportagedashboard | Voorspellende leadscoring |
| HR & salaris | NL loonaangifteketen, CAO-ondersteuning, verzuimregistratie | Zelfservice-portaal voor medewerkers, onboarding-flow | Skills- en opleidingsmanagement |
| Projectmanagement | Taakbeheer, urenregistratie, deadlines en afhankelijkheden | Facturatie vanuit geboekte uren, resource-planning | Ingebouwde tijdregistratie via mobiele app |
Stappen om je eigen programma van eisen op te stellen
- Betrek de daadwerkelijke gebruikers, niet alleen de manager of eigenaar: zij weten waar het huidige proces vastloopt.
- Beschrijf elke eis als een concreet, toetsbaar resultaat ("het systeem genereert automatisch een BTW-aangifte") in plaats van een vaag doel ("het systeem moet gebruiksvriendelijk zijn").
- Verdeel de eisen over categorieën volgens MoSCoW voordat je leveranciers benadert, niet erna: achteraf prioriteren leidt tot bevestigingsvooroordeel richting het pakket dat je toevallig het leukst vond.
- Beperk het aantal must-haves tot een kern van tien tot vijftien punten: te veel knock-outcriteria sluit vaak alle pakketten uit, inclusief de pakketten die met een kleine aanpassing wel hadden gepast.
- Neem naast functionele eisen ook niet-functionele eisen op: performance, beveiliging, hosting-locatie, integratiemogelijkheden en gebruiksvriendelijkheid.
Veelvoorkomende valkuilen
- Eisen kopiëren uit de marketingtekst van je huidige (ontevreden makende) leverancier, waardoor je onbewust naar een vergelijkbaar pakket zoekt.
- Geen onderscheid maken tussen wat het systeem moet doen en hoe het dat moet doen: leg het "wat" vast, laat leveranciers het "hoe" voorstellen.
- Het PvE nooit meer aanpassen tijdens het traject, ook niet als voortschrijdend inzicht (bijvoorbeeld na een demo) een eis verandert.
- Geen eigenaar aanwijzen voor het PvE, waardoor niemand verantwoordelijk is voor de uiteindelijke, consistente versie.
Veelgestelde vragen
Wat is het verschil tussen een programma van eisen en een RFP?+
Het PvE bevat alleen de eisen zelf. De RFP is de volledige, formele uitvraag aan leveranciers waarin het PvE als onderdeel is opgenomen, samen met bedrijfscontext, vragen, tijdlijn en beoordelingscriteria. Zie de <a href="/kennisbank/rfp-template-software" class="text-blue-600 hover:text-blue-500">RFP-template</a> voor het volledige format.
Hoeveel eisen moet een programma van eisen bevatten?+
Voor een gemiddeld MKB-traject werkt een lijst van 40 tot 80 eisen goed: genoeg om onderscheidend te vergelijken, niet zoveel dat leveranciers afhaken op de omvang van de uitvraag.
Wie moet het programma van eisen opstellen?+
Idealiter een klein kernteam met de belangrijkste eindgebruikers, aangevuld met IT (voor technische eisen) en financiën (voor budget- en rapportage-eisen). Een externe, onafhankelijke adviseur kan helpen om het proces gestructureerd en objectief te houden.
Kan ik de MoSCoW-methode ook gebruiken voor een klein softwareproject?+
Ja, MoSCoW schaalt goed naar kleinere trajecten. Bij een kleine aanschaf volstaat vaak een kortere lijst van tien tot twintig eisen, verdeeld over must- en should-have.
Vraag een gratis, onafhankelijke selectiescan aan
In drie korte stappen naar een eerste advies. Betaald door jou als afnemer, nooit door een leverancier.
Start je selectiescan