Functioneel ontwerp template: 12 secties voor je softwareproject

De meeste softwareprojecten die vastlopen, lopen niet vast op de techniek. Ze lopen vast omdat niemand in één zin kan opschrijven welk probleem er eigenlijk werd opgelost. Er was een demo, er was enthousiasme, er was een tool. En daarna een jaar discussie over of dit nu is wat we wilden.

Dit is het template dat ik bij elke discovery gebruik. Twaalf secties, van probleemdefinitie tot ondertekening. Het is geen dik document om een dik document te hebben. Het is een checklist die het gesprek in de juiste orde dwingt: eerst het probleem, dan het doel, dan pas de oplossing.

Waarom een functioneel ontwerp en niet gewoon een lijstje wensen

Een wensenlijst is een verzameling meningen. Een functioneel ontwerp is een besluit. Het verschil zit in vier dingen die je in een lijstje nooit terugvindt: wat het kost als je niets doet, wie er last van heeft, hoe je over drie maanden meet of het gelukt is, en wat je bewust níet gaat bouwen.

Dat laatste is het meest onderschat. De sectie "Won't (voor nu)" voorkomt de helft van je scopediscussies, omdat je niet nee hoeft te zeggen in een vergadering. Het staat al opgeschreven, en iedereen heeft eronder getekend.

De twaalf secties

Drie secties waar het meestal misgaat

Sectie 2: te vaag

"Onze processen zijn inefficiënt" is geen probleemdefinitie. "De order-planner zet elke ochtend anderhalf uur handmatig data over uit drie Excels, en vorige maand gingen daardoor vier orders de deur uit met de verkeerde levertijd" is er wel een. Concrete voorbeelden, meetbare klachten, wachttijden, fouten. Als je er geen getal bij kunt zetten, weet je het nog niet goed genoeg.

Sectie 3: te veel KPI's

Bij tien KPI's stuurt niemand meer op iets. Houd het op drie tot vijf, met per KPI een streefwaarde en een meetmoment. "Doorlooptijd offerte naar order, gemiddeld aantal dagen, maximaal 2, drie maanden na live." Dat is een afspraak. "Meer efficiëntie" is een gevoel.

Sectie 5.2: niet meetbaar

Bij niet-functionele eisen staat in het template letterlijk een kolom "meetbaar, ja of nee". Die kolom is de hele grap. "Het moet snel zijn" is nee. "Onder 2 seconden responstijd bij meer dan 100 gelijktijdige gebruikers" is ja. Hetzelfde voor beveiliging en beschikbaarheid: AVG-compliant met SSO via Azure AD, 99,5 procent per maand.

Hoe ik het in de praktijk invul

• Timebox je interviews. Maximaal 45 minuten per stakeholder, met het template als checklist. Dan hou je focus en praat je niet drie kwartier over één schermpje.
• Werk iteratief. Je vult dit niet in één sessie. Versie 0.1, intern afstemmen, 0.2. Nummer je versies en bewaar besluiten als opmerkingen in de zijlijn, zodat je in maand vijf nog kunt terugzien waarom iets is afgevallen.
• Visualiseer vroeg. Een simpele schets of mock-up in sectie 5.4 en 6 versnelt discussies enorm. Mensen reageren op een plaatje, niet op een alinea.
• Laat AI het zware werk doen. Neem je gespreksopname of je notulen, geef het template mee, en laat een model de eerste versie vullen. Jij bent daarna beoordelaar in plaats van typist. Wat er niet in het gesprek zat, laat je expliciet leeg: dat lege veld is precies je volgende vraag aan de klant.

Waarom dit in een AI-project extra telt

Bij AI-projecten is de verleiding om met de tool te beginnen het grootst. Er is een demo, die demo is indrukwekkend, en voor je het weet rol je licenties uit zonder dat iemand kan zeggen welk werk er nu anders gaat. Volgens onderzoek van MIT NANDA (2025) haalt maar 5 procent van de AI-pilots echte waarde. Bijna nooit door de techniek, bijna altijd door adoptie en een ontbrekend doel.

Dit template is daar het tegengif. Sectie 2 en 3 dwingen je om eerst op te schrijven welk werk beter moet, en hoe je dat over drie maanden meet. Daarna mag de tool.