Het is belangrijk de functionele wensen en eisen met betrekking tot maatwerksoftware helder te hebben voordat er gestart wordt met de ontwikkeling van een softwareoplossing. De eisen zijn de onderdelen die je zeker terug wilt zien in de software. De wensen zijn je voorkeuren, en kunnen uit kostenoverweging wel of niet worden meegenomen in de ontwikkeling.
Neem vooral de tijd om je programma van eisen en wensen op te stellen want dit luistert heel nauw. Neem de metafoor “Ik wil een gat in de muur” als voorbeeld. Stel, je wilt een schilderij ophangen en stelt de eis van het gat in de muur aan verschillende mensen. Dan zal de één een gat boren en er een plug in plaatsen omdat hij/zij goed heeft doorgevraagd, terwijl de ander een gat zal maken waar je doorheen kunt lopen omdat deze je eis letterlijk heeft uitgevoerd.
TIP van REINDER : Begin klein en bouw je applicatie langzaam uit. Daarmee spreid je de kosten en het risico, maar bovenal zorgt het ervoor dat je het project zelf blijft overzien.
De voorbereiding van het programma van eisen en wensen
Begin overzichtelijk en leg vast voor welk doel je de software wilt gaan gebruiken. Inventariseer vervolgens welke primaire processen van je organisatie met de software moeten worden beheerd en beheerst.
Voordat je nu verder de diepte in gaat inventariseer je welke software er al is en of er reeds datastromen bestaan die je kunt gaan gebruiken in je nieuwe software. De meeste organisaties beschikken bijvoorbeeld over boekhoudsoftware waar al een fors deel van de klantgegevens of (in geval van een ERP) HRM-gegevens et cetera zijn vastgelegd. Als deze software toegankelijk is middels bijvoorbeeld een API dan hoeft deze structuur niet helemaal opnieuw bedacht te worden.
Nu je helder hebt waar je naar toe wilt en welke middelen je al in handen hebt kun je het programma van eisen en wensen verder uitwerken.
Technische specificatie
Beschrijf, zo exact mogelijk, waar je software aan moet voldoen maar verzand nog niet in details. Beschrijf in eerste instantie je behoeftes en vergeet nog even de beperkingen of voorwaarden die niet strikt noodzakelijk zijn. Vaak denken we vanuit ons ervaringsgebied, wat niet wil zeggen dat er andere oplossingen zijn die beter zouden passen bij jouw specifieke situatie.
Stel dat je hele wagenpark bestaat uit 3,5T bestelbussen en de vraag van je klant is: ‘Ik wil dagelijks een pakket van 100 kg. vervoeren van a naar b voor de komende drie jaar, waarbij de afstand tussen a en b over deze drie jaar gelijk is aan de levensduur van een bestelbus. Ga je deze opdracht dan uitvoeren met de huidige bestelbus of schaf je hiervoor een kleinere combo aan? Precies voor deze beslissing heb je meer informatie nodig want wellicht past deze opdracht perfect op een reeds bestaande route.
Als je beperkingen opstelt beargumenteer deze dan goed, want de beperking is vanuit jouw specifieke situatie opgesteld. Stel dat in bovenstaande voorbeeld de klant als beperking opgeeft dat de rit alleen met een 3.5T bestelbus mag worden uitgevoerd. Zonder argumentatie kan het zo zijn dat jij de verkeerde aanbieding doet, terwijl de argumentatie ook zou kunnen zijn dat er pas 24 uur van tevoren bekend is dat de vracht in plaats van 100 kg. wordt opgeschaald naar 1000 kg. Dit betekent dus dat je misschien een andere beslissing zou hebben genomen.
Functionele specificatie
Wat is het gebruikersdoel en het beoogde resultaat van je software? ‘n Lastige vraag, maar enorm belangrijk in het voortraject. Vaak heb je al een fysiek beeld van hoe de software eruit moet gaan zien. Vergeet dit beeld en verzand niet in de plek van een button maar beperk je tot de primaire functies van een applicatie.
Stel, je wilt software waarmee je facturen kunt maken en waarmee je artikelen vast kunt leggen die je in de factuurregels wilt gaan gebruiken. Zonder een functionele beschrijving zal de softwareontwikkelaar je in de meeste gevallen een scherm aanbieden waarin je een artikel aan kunt maken, een btw-percentage voor het artikel vast kan leggen en een prijs.
Als je in de functionele specificatie niet hebt vastgelegd dat je ook werkt met buitenlandse klanten en voor groepen klanten gebruikmaakt van een afwijkende prijs dan heb je dus niets aan de geleverde software. Een nauwkeurigere specificatie had je een aanzienlijke tijds- en kostenbesparing op kunnen leveren.
Wensen
Wensen is altijd een bijzonder mooi hoofdstuk, want je kunt enerzijds helemaal losgaan op wensen en anderzijds is het voor de softwareontwikkelaar een moment om te kunnen scoren. Maar al te vaak is de aanbieder die de meeste wensen weet in te vullen de partij aan wie een opdracht wordt gegund. Vergeet echter niet dat een functionaliteit de complexiteit van je software met een behoorlijke factor kan verhogen. Dit heeft dan misschien niet direct invloed op de initiële investering maar kan wel een forse impact hebben op je TCO (Total Cost of Ownership).
Motiveer je wensen dus goed en volledig en vraag altijd naar de impact op kosten van onderhoud en eventuele doorontwikkeling.