Pakketselectie: zo maak je een programma van eisen voor software
Maak een toetsbaar programma van eisen voor software. Met voorbeelden, prioriteiten, acceptatiecriteria en een invulmodel voor je pakketselectie.
Een programma van eisen voor software beschrijft wat een oplossing aantoonbaar moet kunnen en onder welke voorwaarden je ermee kunt werken. Leg per eis het proces, de gebruiker, prioriteit, acceptatiecriteria en het benodigde bewijs vast. Neem naast functies ook koppelingen, gebruik, beveiliging, migratie, beheer en gegevensoverdracht mee. Zo wordt je pakketselectie een toetsbaar onderzoek.
Inhoud van dit artikel
Wat hoort in een programma van eisen?
Een bruikbaar PvE is meer dan een lijst met vinkjes. Het vertelt waarom een eis nodig is, waar die in het proces speelt en hoe een leverancier kan bewijzen dat hij eraan voldoet. Daarmee geef je aanbieders dezelfde uitgangspunten en voorkom je onvergelijkbare antwoorden.
Beschrijf eerst de huidige situatie en het gewenste resultaat. Benoem welke systemen blijven staan, wie de software gaat gebruiken en welke informatie wordt verwerkt. Zet aannames en open vragen apart. Bij pakketselectie hoef je niet elk scherm voor te schrijven; wel moet duidelijk zijn welk resultaat een gebruiker nodig heeft.
Maak ook onderscheid tussen productmogelijkheden en de aangeboden inrichting. Een functie kan bestaan in een duurdere editie of pas werken na het bouwen van een koppeling. Laat de leverancier dat in zijn antwoord expliciet maken, inclusief kosten en verantwoordelijkheid.
Functionele en niet-functionele eisen
Functionele eisen gaan over wat de software doet: een factuur aanmaken, een ticket toewijzen of een order verwerken. Niet-functionele eisen gaan over de manier waarop dat gebeurt, zoals snelheid, toegankelijkheid, herstel en beheersbaarheid. De overheidsrichtlijn over niet-functionele eisen benadrukt dat verschillende belangen en gebruikssituaties moeten worden meegewogen.
| Domein | Voorbeeldvraag | Bewijs dat je kunt vragen |
|---|---|---|
| Procesfuncties | Kan een collega een aanvraag met volledige historie overnemen? | Een demonstratie met twee gebruikersrollen. |
| Koppelingen | Welke klant- en factuurgegevens worden in beide richtingen gedeeld? | Een test inclusief wijziging, foutmelding en herstel. |
| Gebruikers en toegang | Wie mag financiële gegevens zien of wijzigen? | Een rollenproef met afgesproken voorbeeldaccounts. |
| Prestaties en volumes | Blijft de taak uitvoerbaar bij ons aantal gegevens en gelijktijdige gebruikers? | Een representatieve test met vooraf afgesproken grenswaarden. |
| Migratie en continuïteit | Welke gegevens gaan mee en hoe worden aantallen en saldi gecontroleerd? | Een proefmigratie met een aansluitingsverslag. |
| Beheer en exit | Kunnen we gegevens en documentatie meenemen? | Een exportproef en beschrijving van overdrachtsafspraken. |
Zo maak je een vage wens toetsbaar
Schrijf vanuit een echte taak. Een handige formulering is: “Als [rol] wil ik [handeling], zodat [resultaat].” Voeg de situatie, grens en test toe. Dat maakt het mogelijk om de leverancier op dezelfde vraag te beoordelen zonder één specifieke technische oplossing voor te schrijven.
| Vage wens | Toetsbare eis | Acceptatievoorbeeld |
|---|---|---|
| Gebruiksvriendelijk CRM | Een vervangende verkoper vindt de historie en eerstvolgende actie van een open kans. | Een toekomstige gebruiker voert de taak zelfstandig uit met de afgesproken instructie. |
| Goede koppeling | Een gewijzigd factuuradres wordt naar de boekhouding doorgegeven zonder een tweede klantrecord te maken. | Wijzig het adres, controleer beide systemen en toon wat er gebeurt bij een tijdelijke storing. |
| Snelle rapportages | De teamleider ziet open tickets per verantwoordelijke bij het afgesproken testvolume. | Spreek vooraf een meetbare responstijd en dataset af en meet de uitkomst. |
De genoemde testen zijn voorbeelden, geen universele normen. Kies grenswaarden die passen bij jouw proces en gegevensomvang. Laat de toekomstige gebruikers aangeven welk resultaat werkbaar is.
Een compact model voor je eisenlijst
Gebruik één regel per toetsbaar onderdeel. Geef de eis een herkenbaar nummer en wijs een eigenaar aan. Houd versies bij, zodat duidelijk blijft welke eisenlijst bij een offerte en demo hoort. Onderstaand voorbeeld kun je als kolommenstructuur overnemen in een spreadsheet.
| ID en eigenaar | Eis en prioriteit | Bewijs en status |
|---|---|---|
| CRM-01 · Sales | Iedere open kans heeft een eigenaar en vervolgactie. Harde eis. | Demo met overdracht; aangetoond in editie X, datum en deelnemer noteren. |
| INT-02 · Finance/IT | Factuurgegevens worden één keer ingevoerd en gecontroleerd overgedragen. Harde eis. | Koppelingstest; nog te onderzoeken met de voorgestelde connector. |
| BEH-03 · Functioneel beheer | Teamleider kan een nieuw teamlid de juiste rol geven. Wens. | Gebruikersproef; deels aangetoond, aanvullende instructie nodig. |
Voeg waar nodig kolommen toe voor pakketeditie, standaardfunctie of maatwerk, eenmalige kosten, terugkerende kosten en de verwijzing naar een offerte. Houd de hoofdvraag wel leesbaar: wat moet kunnen, waarom en welk bewijs ontbreekt nog?
Prioriteiten en beoordeling: voorkom een vinkjeswedstrijd
Een harde eis kan niet worden gecompenseerd door twintig prettige extra functies. Beoordeel noodzakelijke eisen daarom eerst als beslispunt. Gebruik voor overige criteria een eenvoudige, vooraf afgesproken schaal en motiveer je beoordeling. Een leveranciersantwoord “ja” is een claim; een uitgevoerde test is bewijs van een specifieke situatie.
Vraag leveranciers per regel aan te geven of iets standaard werkt, extra configuratie vraagt, via een aanvullende module loopt of maatwerk is. Laat verwijzen naar de aangeboden editie. Noteer daarnaast welke aannames de leverancier maakt over jouw gegevens, werkwijze en systemen.
De ene aanbieder toont een volledige suite en de andere alleen een basislicentie. Zonder editie en scope lijken beide aan de eisen te voldoen. Vraag daarom dezelfde procesketen en alle benodigde onderdelen uit voordat je prijzen of scores naast elkaar zet.
Van eisenlijst naar demo en afspraken
Vertaal de belangrijkste eisen naar enkele samenhangende praktijkcases. Gebruik fictieve gegevens en neem een uitzondering mee. Laat zien hoe de testresultaten worden opgeslagen en welke vragen nog openstaan. Betrek de proceseigenaar bij acceptatie; IT kan de technische werking beoordelen, maar bepaalt niet alleen of een proces bruikbaar is.
Bespreek de uitkomsten met de implementatiepartner en laat werkzaamheden aansluiten op wat nog moet worden ingericht. Het NCSC biedt gespreksonderwerpen voor leveranciersafspraken. Neem in je eigen selectie ook de overdracht van gegevens en beheer mee.
Veelgestelde vragen
Hoe uitgebreid moet een programma van eisen voor software zijn?
Uitgebreid genoeg om de verschillen en risico’s van jouw keuze te toetsen. Begin met de belangrijkste processen en harde eisen. Voeg detail toe waar koppelingen, gegevensmigratie, toegangsrechten of continuïteit daarom vragen.
Wat is het verschil tussen een eis en een wens?
Een eis is noodzakelijk om het afgesproken proces verantwoord te kunnen uitvoeren. Een wens heeft waarde, maar kan worden afgewogen tegen kosten of andere voordelen. Spreek vooraf af wat de gevolgen zijn als een kandidaat een eis niet aantoont.
Is een leveranciersvragenlijst voldoende?
Een vragenlijst helpt om informatie te verzamelen. Combineer antwoorden met demo’s, documentatie en waar nodig een proef. Leg vast welke claims werkelijk zijn aangetoond en welke inrichting of extra module daarvoor nodig is.
Bronnen en verantwoording
Redactie: Softwarematch. Inhoud en bronnen gecontroleerd op . De praktische voorbeelden zijn illustratief. Productinformatie en tarieven kunnen veranderen; controleer de aangeboden editie en voorwaarden bij de leverancier.