Programma van eisen opstellen: van bedrijfsdoel naar software-eisen

Waarom een programma van eisen begint bij het bedrijfsdoel

Een programma van eisen (PvE), ook wel requirements-document genoemd, beschrijft de functionele en niet-functionele eisen waaraan software moet voldoen. Het zegt wat de software moet kunnen en onder welke voorwaarden, niet hoe de oplossing technisch wordt gebouwd. Technische details zoals hostingarchitectuur of API-specificaties horen er niet in; die komen pas bij de inrichting aan bod.

In de selectiefase beoordelen leveranciers hun oplossing aan de hand van jouw eisen. Jij beoordeelt hun aanbod met hetzelfde document.

Het grootste risico zit niet in wat er te veel in staat, maar in wat ontbreekt. Een document van twintig pagina's zonder één meetbare eis is een veelvoorkomend probleem bij softwaretrajecten. Het groeit uit tot een uitgebreide wensenlijst, leveranciers interpreteren die naar eigen inzicht en de gekozen oplossing sluit niet aan op wat de organisatie echt nodig had. Een sterk PvE is beknopt, concreet en onderbouwd.

Het opstellen van een PvE dwingt je vooraf na te denken over het gewenste product, of dat een goed of een dienst is. Omdat je de gewenste uitvoering of levering al behoorlijk gedetailleerd beschrijft vóór de opdrachtverstrekking, heb je bij de daadwerkelijke levering geen of veel minder discussie.

Begin daarom niet bij de software, maar bij het doel: definieer de doelstellingen en het beoogde nut van de nieuwe software. Maak expliciet wat iedereen ermee wil bereiken en wanneer.

Van bedrijfsdoel naar software-eisen

Bepaal eerst het resultaat en de scope

In de stappenreeks voor het opstellen van een PvE is stap 1: bepaal het resultaat. Stap 2 is de vraag wat dat resultaat moet doen of kunnen.

Vertaal dat naar doelstellingen die je later kunt toetsen, bijvoorbeeld een doorlooptijd verkorten, een foutpercentage in een registratie verlagen of gegevensuitwisseling tussen twee systemen automatiseren. Koppel aan elke doelstelling een moment waarop je wilt zien dat het resultaat er is; zo voorkom je dat het PvE een open wensenlijst blijft.

Daarna baken je de scope af. Leg vast welke processen, afdelingen en gebruikersrollen binnen het traject vallen, welke bestaande systemen en gegevensbronnen moeten worden gekoppeld, en welke processen of afdelingen expliciet buiten scope blijven. Een softwareselectie voor een warehousesysteem kent een andere scope dan die voor een applicatie voor creditmanagement of factuurverwerking; dezelfde eisenlijst werkt niet voor beide.

Maak de scope concreet per proces: welke rol voert de handeling uit, welke gegevens gaan erin en komen eruit, en welke uitzonderingen moeten worden ondersteund. Dat levert direct het materiaal op voor de functionele eisen in de volgende stap. Wat je hier overslaat, komt later terug als discussie over de vraag of iets wel of niet in de offerte zat.

Scope afbakenen: wat valt binnen en buiten het traject?

Betrek stakeholders en doe gedegen businessanalyse

Het opstellen van een goed PvE gebeurt in de praktijk vaak door een inhoudelijk deskundige die dit werk voor het eerst doet of slechts eens in de paar jaar. Dat is precies de situatie waarin eisen ontbreken of te veel op één afdeling zijn toegesneden. Een gedegen businessanalyse legt het fundament: de werkelijke behoefte achter de wens achterhalen, de huidige en gewenste procesgang in kaart brengen en die vertalen naar eisen.

Betrek in ieder geval de proceseigenaren en de mensen die de software dagelijks gaan gebruiken, de functioneel beheerder die het systeem na livegang moet onderhouden, IT of informatiemanagement, en inkoop of juridische zaken omdat het PvE later contractstuk wordt. Stem tussentijds af in overleggen in plaats van één keer aan het eind een concept rond te sturen.

Reken die afstemming mee in de planning. Een PvE kan in minder dan een uur zijn opgesteld, maar bij complexere zaken kost het minimaal een aantal weken of zelfs maanden doorlooptijd. Alle betrokkenen moeten in diverse overleggen op het document afstemmen.

Betrek deze stakeholders bij het PvE

Formuleer functionele eisen die toetsbaar zijn

Functionele eisen beschrijven de concrete taken en processen die de software moet ondersteunen, zoals het registreren van klantgegevens, het genereren van rapportages of het integreren met een bestaand ERP-systeem. Ze zijn specifiek en verifieerbaar.

'De software moet facturen kunnen verwerken' is te vaag. 'De software moet inkoopfacturen automatisch kunnen matchen aan purchase orders en afwijkingen van meer dan 5% signaleren' is een eis waaraan een leverancier concreet kan toetsen. Hoe concreter de eis, hoe beter leveranciers onderling te vergelijken zijn en hoe kleiner de kans op een verkeerde aanschaf.

Bij proceseisen kun je de gebruikersrol als vertrekpunt nemen: een koper wil de beoordelingen van anderen zien om de kwaliteit in te schatten. Dat beschrijft wat het systeem moet kunnen. Zo'n eis zegt niets over gebruiksvriendelijkheid; die regel je met een aparte, niet-functionele eis (zie de volgende sectie).

Loop bij het formuleren de belangrijkste processtappen langs: registreren en muteren van gegevens, goedkeurings- of controleproces, rapportage en export, en de koppelingen met andere systemen. Beschrijf per koppeling welke gegevens worden uitgewisseld, in welke richting en op welk moment in het proces. Leg bij rapportages vast welke gegevens de basis zijn, wie de uitvoer bekijkt en welke periode of selectie erop moet kunnen worden toegepast.

Vergeet niet-functionele eisen niet

Niet-functionele eisen gaan over de kwaliteitskenmerken van de oplossing: beschikbaarheid, beveiliging, schaalbaarheid, gebruiksvriendelijkheid en prestaties. Deze worden in de praktijk regelmatig vergeten. Maak ze meetbaar, zoals de eis dat de applicatie minimaal 99,5% van de tijd beschikbaar moet zijn, of dat de navigatiestructuur niet dieper is dan drie niveaus zodat de gebruiker de weg niet kwijtraakt.

Gebruik een kwaliteitsmodel als checklist. ISO 9126 kent zes hoofdkenmerken: functionaliteit, betrouwbaarheid, bruikbaarheid, efficiëntie, onderhoudbaarheid en overdraagbaarheid. In 2011 is deze norm vervangen door ISO 25010, die niet alleen kwaliteitseisen voor het systeem zelf definieert, maar ook eisen voor de kwaliteit tijdens het gebruik van het systeem. Neem die kenmerken vanaf het begin mee als kapstok, zodat je niet alleen functionaliteit afvinkt.

Behandel functionele en niet-functionele eisen gelijkwaardig vanaf het begin van het ontwikkelproces. Gebeurt dat niet, dan zie je na livegang performanceproblemen optreden of gebruikers toegang krijgen tot functionaliteit waarvoor ze niet geautoriseerd zijn. Formuleer bij elke niet-functionele eis ook hoe je gaat vaststellen dat eraan is voldaan: een meting, een test, een rapportage of een acceptatiecriterium in de overeenkomst.

Kwaliteitskenmerken voor niet-functionele eisen

Maak onderscheid tussen eisen en wensen

Een goed PvE bevat eisen én wensen. Aan eisen moet worden voldaan; aan wensen hoeft niet. Dat onderscheid is functioneel: juist door de wensen kan een leverancier zich onderscheiden.

Als aan alle eisen wordt voldaan en er geen wensen zijn, blijft alleen de prijs nog onderscheidend tussen de offertes. Dat kan de bedoeling zijn, maar bij complexere inkooptrajecten wil je niet uitsluitend op laagste prijs kiezen en moet je dus wensen opnemen.

Zet het onderscheid daarom vooraf in de beoordelingssystematiek. Bepaal welke eisen knock-out zijn (een leverancier die hierop niet voldoet, valt af) en maak een beoordelingslijst met wensen en voorwaarden, met per criterium een beschrijving van wat je onder een goede of minder goede invulling verstaat. Zo wordt de beoordeling van de aanbiedingen herhaalbaar en kun je later uitleggen waarom een oplossing is gekozen, ook als die niet de goedkoopste was.

Eisen versus wensen

Schrijf helder, ondubbelzinnig en op het juiste detailniveau

Eisen moeten ondubbelzinnig en helder zijn verwoord. Is dat niet het geval, dan kan later discussie ontstaan over wat precies is bedoeld.

Een programma van eisen en de beantwoording daarvan worden in de regel onderdeel van het contract; eenduidige en heldere teksten zijn daarom gewenst. Toekomstige discussies gaan meestal niet over de inhoud van het contract maar over de inhoud van de opdracht — de levering of dienst zelf — en die is in het PvE beschreven.

Houd het verschil tussen requirements en specificaties scherp. Een requirement beschrijft abstract wat je wilt bereiken, bijvoorbeeld dat de software een goedkeuringsproces moet ondersteunen. Specificaties zoomen in op de details: wat moet er goedgekeurd worden, welke data is daarvoor nodig, wat is de autorisatiematrix. Dat onderscheid wordt regelmatig onderschat, terwijl niemand op basis van alleen het woord 'goedkeuringsproces' weet wat er gebouwd of geconfigureerd moet worden.

Specificeer tot het niveau dat voldoende is voor de ontwikkelaar, niet verder. Je beschrijft niet hoe breed een knop moet zijn en waar die precies staat; dat werk je tijdens de implementatie uit.

Wanneer je vooraf elk detail vastlegt — de watervalmethode — weet je in theorie precies wat je krijgt, maar ontbreekt de ruimte om nieuwe inzichten te verwerken. Juist die inzichten kunnen het product van voldoende naar goed tillen. Een agile aanpak laat die ruimte voor voortschrijdend inzicht. Combineer dat voor de selectie: eisen en wensen op abstractieniveau in het PvE, werkelijke werking van de software vastleggen in specificaties tijdens de implementatie.

Requirement versus specificatie

Verken de markt voordat je eisen definitief maakt

Een PvE moet passen bij wat de markt te bieden heeft. Daarvoor is marktkennis nodig, en die vergaar je gericht: zoeken op internet, leveranciers spreken, documentatie bestuderen, een marktconsultatie op TenderNed uitzetten, nagaan hoe andere organisaties een vergelijkbaar vraagstuk hebben opgelost, of indicatieve offertes opvragen. Het belangrijkste doel is helder krijgen wat de onderscheidende factoren zijn tussen de beschikbare oplossingen.

Gebruik die verkenning om te toetsen of je eisen haalbaar en onderscheidend genoeg zijn. Vraag je af of een eis standaardfunctionaliteit raakt of maatwerk vraagt, en of het antwoord op een eis de oplossingen daadwerkelijk van elkaar scheidt. Vage eisen leiden bij complexe systemen — bij warehousesystemen bijvoorbeeld — vaak tot dure aanpassingen achteraf.

Van checklist naar softwareselectie en contract

Gebruik een checklist om te controleren of alle onderwerpen zijn behandeld: functionele eisen, niet-functionele eisen, wensen en voorwaarden. Die vier categorieën vormen samen het beoordelingskader voor de leveranciers en hun aanbod. Zet in dat kader vooraf vast hoe je de antwoorden beoordeelt: welke eisen knock-out zijn, hoe wensen worden gewogen en welke gegevens of demonstraties een leverancier moet aanleveren om een antwoord te onderbouwen.

Neem de definitieve eisenlijst, de wensenlijst en de antwoorden van de gekozen leverancier integraal op als bijlage. Controleer of de teksten in het PvE en het contract identiek zijn.

Beoordelingskader en contract: controleer deze categorieën

Verder lezen: Hoe stel je een Programma van Eisen op voor Softwareselectie (compenda.nl).