Een programma van eisen (PvE) is het document waarin staat wat de software moet doen, voor wie, en aan welke voorwaarden het moet voldoen. Voor een bureau is het de basis van de offerte, de planning en de oplevering.
Een goed PvE heeft vaste onderdelen: doel, gebruikers, functionele eisen, niet-functionele eisen, randvoorwaarden en wat buiten scope valt. Elke eis is toetsbaar, zodat je bij oplevering kunt aanwijzen wat er is gehaald. Laat de opdrachtgever het tekenen voordat je een vaste prijs noemt.
Waarom heeft je bureau een PvE nodig?
Omdat de discussie bij oplevering anders over herinneringen gaat. ‘Dit hadden we toch besproken’ is geen argument als niemand het heeft opgeschreven. Met een getekend PvE wijs je de eis aan, of het ontbreken ervan.
Het PvE doet drie dingen voor je bureau:
- Het begrenst de scope. Wat er niet in staat, is meerwerk.
- Het maakt een vaste prijs mogelijk. Zonder vaste scope is een vaste prijs een gok. Met een vage scope werk je beter op nacalculatie.
- Het maakt acceptatie toetsbaar. De klant test tegen de genummerde eisen in het PvE.
Hoe stel je een programma van eisen op?
Acht stappen, in deze volgorde.
Stap 1: Leg het doel vast
Eén alinea. Welk probleem lost de software op, en hoe weet de opdrachtgever dat het gelukt is? ‘Orderverwerking van drie dagen naar één dag’ is een doel. ‘Een moderne webapp’ niet.
Stap 2: Beschrijf de gebruikers
Wie gaat ermee werken? Medewerkers, klanten, beheerders. Hoeveel, op welke apparaten, met welke kennis. Dit bepaalt later de keuzes voor interface, rechten en performance.
Stap 3: Schrijf de functionele eisen
Wat moet het systeem kunnen? Schrijf per eis één zin, met een nummer. Gebruik een vaste vorm, bijvoorbeeld: ‘Als [gebruiker] wil ik [actie], zodat [resultaat].’
Geef elke eis een prioriteit. MoSCoW werkt goed:
| Prioriteit | Betekenis | In de offerte |
|---|---|---|
| Must | Moet erin | In de vaste prijs |
| Should | Hoort erin als het kan | Optie |
| Could | Mag erin | Optie |
| Won’t | Nu niet | Buiten scope |
Stap 4: Schrijf de niet-functionele eisen
Performance, beschikbaarheid, beveiliging, toegankelijkheid, browsers en apparaten, privacy. Maak ze meetbaar, bijvoorbeeld: ‘pagina laadt binnen 2 seconden bij 100 gelijktijdige gebruikers’.
Stap 5: Noteer de randvoorwaarden
- koppelingen met bestaande systemen;
- verplichte technologie;
- hosting;
- wie content en testdata levert;
- deadlines die vastliggen.
Zet erbij wat de opdrachtgever moet aanleveren en wanneer. Een koppeling die wacht op een API-sleutel van de klant is vertraging voor rekening van de klant, als het zo in het PvE staat.
Stap 6: Schrijf op wat buiten scope valt
Het onderdeel dat bureaus overslaan en later missen. Migratie van oude data, content invoeren, training, onderhoud na oplevering, extra talen. Alles wat de klant zou kunnen verwachten maar wat niet in de prijs zit.
Stap 7: Spreek de acceptatie af
Hoe test de klant, hoe lang heeft hij daarvoor, en wat geldt als acceptatie?
Stap 8: Laat het tekenen
Het PvE wordt onderdeel van de overeenkomst. Wijzigingen gaan via een schriftelijk wijzigingsverzoek met prijs en planning. Zo blijft het PvE het document waar iedereen naar verwijst.
Wat zijn veelgemaakte fouten?
- Eisen die niet toetsbaar zijn. ‘Intuïtief’, ‘schaalbaar’, ‘modern’. Vraag door tot je iets meetbaars hebt.
- Oplossingen die als eis zijn opgeschreven. ‘Er moet een dropdown komen’ is een ontwerpkeuze. Vraag wat de gebruiker wil bereiken.
- Geen prioriteiten. Als alles must is, kun je niet schuiven als het budget krap wordt.
- Geen versiebeheer. Het PvE verandert tijdens het traject. Nummer de versies en bewaar ze.
Wat heeft het PvE met je code te maken?
Het PvE bepaalt wat je voor de klant bouwt, en dus ook wat níet voor de klant is. Componenten, tools en bibliotheken die je meeneemt en die niet in het PvE staan, kun je in het contract bij je bureau houden.
Wat je zo overhoudt, kan later geld opleveren: kijk op wat is code waard.