Een programma van eisen voor software schrijven, zodat offertes vergelijkbaar worden

U stuurt hetzelfde idee in een mail van twee alinea’s naar drie leveranciers. U krijgt € 25.000, € 70.000 en € 140.000 terug. Niemand zit ernaast. Ieder heeft een ander systeem geprijsd: het systeem dat hij voor zich zag bij het lezen van uw mail.

Een programma van eisen lost dat op. Het is geen bureaucratie. Het is de goedkoopste manier om ervoor te zorgen dat iedereen hetzelfde offreert, en dat u het systeem krijgt dat u in gedachten had.

De cijfers bevestigen het. In een onderzoek van het Project Management Institute was gebrekkig requirementsmanagement in bijna de helft van de gevallen (47 %) de hoofdoorzaak wanneer projecten hun doelen niet haalden, en ging 5,1 % van elke in projecten geïnvesteerde dollar daardoor verloren.

Wat een programma van eisen is, en wat niet

Het beschrijft wat het systeem moet doen en waarom. Niet hoe. Het hoe is het werk van de leverancier, en hem ruimte geven voor een eigen oplossing is een van de dingen waarvoor u hem betaalt.

In Duitstalige landen heeft dit onderscheid zelfs namen: de opdrachtgever schrijft het Lastenheft (wat en waarom), de leverancier antwoordt met een Pflichtenheft (hoe en waarmee), zoals vastgelegd in DIN 69901-5. Internationaal beschrijft ISO/IEC/IEEE 29148 requirements engineering in detail.

Voor een middelgroot bedrijf hebt u geen honderd pagina’s nodig. Vijf tot vijftien pagina’s die de juiste vragen beantwoorden, zijn genoeg.

Wat erin hoort

Onderdeel	Welke vraag het beantwoordt	Voorbeeld
Doel	Waarom het systeem, en hoe u succes meet	“Drie mensen typen elke dag twee uur bestellingen over uit e-mail. Doel: onder de 30 minuten.”
Huidige situatie	Hoe het nu werkt, met welke middelen	“Bestellingen komen binnen per e-mail en Excel en worden met de hand in het ERP gezet.”
Gebruikers en rollen	Wie het gebruikt en wat zij mogen	“Verkoop maakt bestellingen aan, het magazijn bevestigt ze, beheerders zien alles.”
Processen	De belangrijkste stromen, stap voor stap	“Bestelling komt binnen, voorraad wordt gecontroleerd, bestelling wordt bevestigd, factuur gaat eruit.”
Gegevens	Welke gegevens, waar vandaan, hoeveel	“Zo’n 300 bestellingen per dag en 5.000 klanten, geïmporteerd uit het ERP.”
Koppelingen	Met welke systemen het moet praten	“ERP via de REST-API, e-mail, boekhouding.”
Niet-functionele eisen	Snelheid, beveiliging, beschikbaarheid, privacy, apparaten	“Inloggen met Microsoft 365, gegevens in de EU, werkt op een tablet in het magazijn.”
Acceptatiecriteria	Hoe u controleert dat het af is	“Een bestelling uit een e-mail staat binnen vijf minuten in het ERP, zonder handmatige invoer.”
Leveringsomvang	Wat er naast de code bij hoort	“Training, documentatie, overdracht, de eerste drie maanden support.”
Prioriteiten	Wat er in de eerste versie moet	Must, should, could

Schrijf eisen die toetsbaar zijn

De meest voorkomende zwakte is een eis die niemand kan toetsen. “Snel” betekent iets anders voor u, voor de leverancier en voor een gebruiker met een trage verbinding. Elke eis moet bij de oplevering te testen zijn:

Vaag	Toetsbaar
Het systeem moet snel zijn	De bestellijst laadt in minder dan twee seconden met 10.000 bestellingen
Gebruiksvriendelijk	Een nieuwe magazijnmedewerker bevestigt een bestelling zonder training, binnen een minuut
Veilig	Inloggen met Microsoft 365 en tweestapsverificatie; elke wijziging aan een bestelling wordt gelogd met gebruiker en tijd
Koppeling met het ERP	Nieuwe bestellingen staan binnen vijf minuten in het ERP; is het ERP onbereikbaar, dan wordt opnieuw verzonden en krijgt een beheerder een melding

Wat u weglaat

• Schermontwerpen tot op de pixel, tenzij het er echt toe doet. Beschrijf wat de gebruiker moet doen, niet waar de knop staat.
• Technologiekeuzes zonder reden. Is er een reden, schrijf die dan op: “moet op onze SQL Server draaien”, “ons team onderhoudt .NET”. Laat anders de leveranciers voorstellen doen.
• Elke uitzondering in de eerste versie. Markeer open vragen. Een goede leverancier vraagt ernaar, en de antwoorden maken het document beter.

Must, should, could

Geef elke eis een prioriteit. Must: zonder dit is het systeem nutteloos. Should: belangrijk, maar er is een omweg. Could: leuk om te hebben.

Dat levert twee dingen op. De offertes worden vergelijkbaar, omdat iedereen dezelfde eerste versie prijst. En u krijgt een natuurlijke eerste release: alleen de musts, snel in productie, de rest volgt als de gebruikers het gezien hebben.

Hoe gedetailleerd het document moet zijn, hangt ook af van het contract. Bij een vaste prijs wordt het onderdeel van het contract en vraagt het veel meer detail. Meer daarover in ons artikel over vaste prijs of nacalculatie.

Laat AI de eerste versie schrijven

Het schrijven van het document is vaak wat een project maandenlang ophoudt. AI maakt dat flink korter. Neem een gesprek op met de mensen die het werk nu doen, of beschrijf het proces in uw eigen woorden, en geef dat samen met de tabel hierboven aan een AI-assistent. Vraag om een concept en een lijst met open vragen.

U leest en corrigeert nog steeds elke regel, want alleen u kent uw bedrijf. Maar een concept corrigeren kost uren, een leeg vel vullen weken. Eén regel: plak geen vertrouwelijke gegevens in een openbare chattool. Gebruik de versie die uw bedrijf heeft goedgekeurd, met uw privacy-instellingen.

Hoe het verder gaat

Stuur hetzelfde document naar drie leveranciers en vraag ieder om eis voor eis te antwoorden: hoe ze het zouden oplossen, wat het kost en wat onduidelijk is. In Duitstalige landen is dat antwoord het Pflichtenheft.

Vergelijk daarna de antwoorden, niet alleen de totalen. Een leverancier die goede vragen stelt, heeft het document gelezen. Een die geen vragen stelt, heeft een gok geprijsd. Realistische prijsbandbreedtes vindt u in ons artikel Wat kost een applicatie laten maken?

Hoe wij werken

Precies hier beginnen we vaak. ProCoding is een .NET-studio uit Split, Kroatië: we bouwen bedrijfsapplicaties in .NET en Blazor en brengen AI in bedrijfsprocessen. In een korte analyse lopen we uw processen door met de mensen die ze kennen, schrijven we samen met u het programma van eisen en geven we een schatting in bandbreedtes. Het document is van u, en u kunt het ook aan andere leveranciers voorleggen. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• Requirements Management: A Core Competency for Project and Program Success, PMI’s Pulse of the Profession, Project Management Institute, augustus 2014
• Lastenheft, Wikipedia (definities volgens DIN 69901-5)
• ISO/IEC/IEEE 29148:2018, Requirements engineering, ISO