Programma van eisen opstellen voor software: wat erin hoort en hoe je het kort houdt

Een programma van eisen opstellen is voor veel ondernemers het moment waarop een softwareproject echt begint. Niet omdat een leverancier erom vraagt, maar omdat je jezelf dwingt scherp te krijgen wat je eigenlijk wil. De grootste reden dat projecten uitlopen en duurder worden, is niet slechte code, maar onduidelijke verwachtingen. Een programma van eisen is het document dat dat voorkomt.

Het hoeft geen lijvig rapport te zijn. Een goed programma van eisen voor een MKB-project past vaak op een paar pagina's. Het doel is niet volledigheid op papier, maar dat jij en de bouwer hetzelfde beeld hebben voordat er een euro wordt uitgegeven.

Wat hoort er in een programma van eisen?

De volgorde hieronder werkt voor vrijwel elk softwareproject, van een intern dashboard tot een klantportaal. Loop hem van boven naar beneden door en je hebt een bruikbaar document.

• Doel en aanleiding: welk probleem los je op en waarom nu? Eén alinea die de rest in context zet.
• Gebruikers en rollen: wie gaat de software gebruiken en wat mag elk type gebruiker? Een beheerder, een klant en een medewerker hebben elk andere rechten.
• Functionele eisen: wat moet de software kunnen? Beschrijf dit als concrete handelingen, niet als features. "Een klant kan een factuur downloaden" is bruikbaarder dan "facturatiemodule".
• Niet-functionele eisen: hoe moet het werken? Denk aan snelheid, beschikbaarheid, beveiliging en op welke apparaten het moet draaien.
• Koppelingen: met welke bestaande systemen moet de software praten? Boekhouding, CRM, betaalprovider, e-mail.
• Wat erbuiten valt: minstens zo belangrijk als wat erin zit. Wat ga je expliciet nog niet bouwen, om scope-creep te voorkomen?

Beschrijf wat, niet hoe

De meestgemaakte fout is technische oplossingen voorschrijven die je nog niet kent. Schrijf op dat klanten veilig moeten kunnen inloggen, niet welke inlogtechniek gebruikt moet worden. Schrijf op dat het systeem duizend gebruikers tegelijk aan moet kunnen, niet welke database daarvoor nodig is. Het wat is jouw domein, het hoe is dat van de bouwer. Door die scheiding te bewaken houd je het document leesbaar en geef je de bouwer ruimte om de beste oplossing te kiezen.

Maak eisen toetsbaar

Een eis die je niet kunt afvinken, is geen eis maar een wens. "De applicatie moet snel zijn" is niet toetsbaar; "een pagina moet binnen twee seconden laden" wel. "Gebruiksvriendelijk" zegt niets; "een nieuwe medewerker kan zonder training een bestelling invoeren" is wel te beoordelen. Hoe concreter je eisen, hoe minder ruimte voor discussie achteraf over of iets nu wel of niet geleverd is.

Een goed programma van eisen is niet het dikste document, maar het document waarover jij en de bouwer het na één keer lezen eens zijn.

Een hulpmiddel, geen contract in beton

Een programma van eisen geeft richting, maar gaandeweg leer je dingen die je vooraf niet kon weten. Bij een goed bouwtraject is het document een startpunt dat meebeweegt, geen keurslijf. Het hoort bij de voorbereiding van maatwerk software, en juist die voorbereiding bepaalt of een project soepel verloopt of halverwege vastloopt op bijstellingen.

Weet je nog niet hoe je je idee in eisen vertaalt? Dat hoeft ook niet alleen. Plan een vrijblijvend gesprek, vertel wat je voor ogen hebt, en we helpen je de eisen scherp krijgen voordat er gebouwd wordt.