In het kort
Een functioneel ontwerp beschrijft wat software voor gebruikers moet doen, onder welke voorwaarden en met welke uitkomst. Het verbindt de bedrijfsbehoefte met de werking die je gaat bouwen en toetsen. Beschrijf daarom meer dan schermen: neem ook rollen, gegevens, bedrijfsregels, uitzonderingen en acceptatiecriteria op. Begin met één belangrijke werktaak en werk die volledig uit voordat je het document uitbreidt.
Wat is een functioneel ontwerp?
Een functioneel ontwerp, vaak afgekort tot FO, legt de gewenste werking van software vast vanuit het werk dat mensen ermee doen. Wie mag een reservering maken? Welke informatie is verplicht? Wanneer krijgt iemand een bevestiging en wat gebeurt er bij een conflict? Het document maakt zulke afspraken bespreekbaar voordat ze alleen nog in code of in het hoofd van een medewerker bestaan. De vorm kan een compact document, een verzameling uitgewerkte scenario’s of een combinatie met schetsen zijn.
Het doel is een gedeeld beeld van de werking. Een opdrachtgever moet kunnen beoordelen of het proces klopt, een gebruiker of de taak uitvoerbaar is en een ontwikkelaar wat er gebouwd moet worden. Een functioneel ontwerp is daarmee meer dan een mooi schermontwerp. Een getekende knop vertelt nog niet wie erop mag drukken, welke controle volgt of wat er na een fout bewaard blijft. Die betekenis hoort expliciet bij het ontwerp.
Het verschil tussen eisen, functioneel en technisch ontwerp
Een eisenlijst benoemt de behoefte en de voorwaarden waaraan een oplossing moet voldoen. Het functioneel ontwerp werkt de afgesproken werking uit. Een technisch ontwerp beschrijft vervolgens hoe de oplossing technisch wordt gerealiseerd, bijvoorbeeld met gegevensstructuren, componenten en aansluitingen op andere systemen. De grenzen kunnen per project verschillen en onderdelen mogen in één document staan. Spreek daarom af wat jullie onder elke term verstaan. Voor de selectie van een CRM kun je eerst de CRM-eisen- en wensenlijst gebruiken.
Neem de wens om dubbele reserveringen te voorkomen. De behoefte is dat een meetset niet tegelijk aan twee teams wordt toegezegd. De functionele afspraak beschrijft wanneer tijdvakken overlappen, wie een reservering mag vastleggen en welke melding bij een conflict verschijnt. Het technische ontwerp bepaalt hoe de software die afspraak betrouwbaar uitvoert, ook wanneer twee aanvragen tegelijk binnenkomen. Een acceptatiecriterium maakt ten slotte zichtbaar hoe je controleert dat de afgesproken werking is geleverd.
Een praktische opzet die je kunt overnemen
Begin met doel en afbakening: welk probleem wil je oplossen, voor welke gebruikers en welke taken vallen binnen de eerste versie? Noteer daarna de rollen en hun bevoegdheden. Werk per kerntaak de aanleiding, beginsituatie, invoer, stappen en verwachte uitkomst uit. Voeg de bedrijfsregels, foutpaden en betrokken koppelingen toe. Sluit af met acceptatiecriteria, open beslispunten en versieafspraken. Deze opzet is een praktisch hulpmiddel, geen universeel verplicht documentformat.
Gebruik per functie een vaste invulregel: ID; doel; verantwoordelijke; gebruikersrol; beginsituatie; verplichte gegevens; normale stappen; bedrijfsregels; uitzonderingen; resultaat; acceptatiecriteria; open vragen. Een schets van het scherm mag erbij, zolang je uitlegt wat de gebruiker ermee moet kunnen doen. Geef regels en vragen eigen nummers. Dan kun je tijdens overleg naar één concrete afspraak verwijzen in plaats van naar een onduidelijke opmerking ergens in een document.
Maak onzekerheid zichtbaar. Zet bijvoorbeeld bij een koppeling die nog moet worden onderzocht dat de beschikbaarheid onbekend is, wie dit uitzoekt en wanneer de beslissing nodig is. Schrijf niet alvast dat de koppeling werkt. Een open vraag die herkenbaar is vastgelegd helpt de planning; een aanname die als afgeronde afspraak wordt gepresenteerd kan later een verkeerde offerte, bouwkeuze of test opleveren.
Een ingevuld voorbeeld: een meetset reserveren
Stel dat een fictief installatiebedrijf één meetset tussen teams deelt. Planners reserveren de set voor een tijdvak; medewerkers bekijken de planning. Het bedrijfsdoel is te voorkomen dat twee teams dezelfde set tegelijk toegezegd krijgen. Voor de eerste versie vallen uitlevering, facturatie en automatische klantberichten buiten scope. Alle rollen, tijden en regels hieronder zijn uitsluitend voorbeeldafspraken. Ze beschrijven geen bestaande klant, wettelijke norm of door Softora geleverd resultaat.
Functie FO-01 heet meetset reserveren. De rol is planner en de beginsituatie is een ingelogde planner met toegang tot de gezamenlijke planning. Verplichte invoer: meetset, team, starttijd en eindtijd. De eindtijd moet na de starttijd liggen. De planner kiest de gegevens en vraagt bevestiging. Bij succes verschijnt een reserveringsnummer met de status bevestigd en staat hetzelfde tijdvak in het overzicht. Een medewerker kan die reservering bekijken, maar niet wijzigen.
De overlapregel is bewust precies: een nieuwe reservering mag beginnen op het tijdstip waarop de vorige eindigt. Start de nieuwe reservering vóór het einde van een bestaande reservering en eindigt zij ná het begin daarvan, dan is er overlap. Een geannuleerde reservering blokkeert het tijdvak niet. Een bedrijf dat voorbereidingstijd of reistijd nodig heeft, moet daar een aanvullende afspraak over maken. Dat staat in dit voorbeeld nog buiten de gekozen regel.
Bij een conflict bewaart het systeem geen tweede bevestigde reservering. Het toont dat het tijdvak bezet is en vraagt de planner een andere tijd te kiezen; de ingevulde gegevens blijven beschikbaar om aan te passen. Ook twee gelijktijdige verzoeken voor hetzelfde vrije tijdvak mogen samen slechts één bevestigde reservering opleveren. Welke aanvraag wint, is hier niet voorgeschreven. De verliezende aanvraag krijgt een conflictmelding. De leverancier moet de technische borging daarvan uitwerken en aantonen.
Beschrijf rechten en uitzonderingen vóór de bouw
Schrijf per rol op welke gegevens iemand mag lezen en welke handelingen zijn toegestaan. OWASP adviseert al tijdens het ontwerp de combinatie van gebruiker, object en bewerking te bepalen en rechten bij ieder verzoek te controleren. Alleen een knop verbergen regelt die toegang niet. In het voorbeeld mag een medewerker dus ook via een rechtstreeks verzoek geen reservering wijzigen. Het functioneel ontwerp legt de bedrijfsafspraak vast; de beveiligde uitvoering en passende tests vragen verdere technische uitwerking.
Loop daarna bewust de afwijkende routes door. Wat gebeurt er als een verplicht veld ontbreekt, de verbinding wegvalt of een planner twee keer op bevestigen drukt? Beschrijf wat de gebruiker ziet, wat is opgeslagen en hoe die veilig verdergaat. Voeg geen eindeloze verzameling denkbare rampen toe, maar werk de fouten uit die het dagelijkse proces kunnen verstoren. Bij twijfel over opslag na een onderbreking hoort de gebruiker de status te kunnen controleren voordat opnieuw een reservering wordt aangevraagd.
Benoem ook uitzonderingen die nog een beslissing vragen. Wie mag annuleren? Tot welk moment mag het team veranderen? Wat gebeurt er als de meetset onverwacht defect is? Zet zulke punten op de vragenlijst met een eigenaar. Ze zijn in het ingevulde voorbeeld nog niet allemaal opgelost. Zo blijft het onderscheid zichtbaar tussen uitgewerkt gedrag en keuzes die het installatiebedrijf nog moet maken.
Verbind een gebruikersverhaal aan concrete criteria
Een gebruikersverhaal helpt de bedoeling kort te formuleren. Het GOV.UK Service Manual beschrijft daarvoor de gebruiker, de gewenste handeling en het doel, aangevuld met acceptatiecriteria. Dat is bruikbare uitleg uit de Britse overheidspraktijk, geen verplichte standaard voor Nederlandse bedrijven. Voor onze meetset kan het verhaal luiden: als planner wil ik een beschikbaar tijdvak reserveren, zodat mijn team weet wanneer de meetset voor ons is vastgelegd.
Maak de uitkomsten vervolgens afzonderlijk toetsbaar. Criterium AT-01: bij geldige invoer in een vrij tijdvak ontstaat precies één bevestigde reservering met een nummer. AT-02: een overlappend tijdvak levert een conflictmelding op en geen tweede reservering. AT-03: een aansluitend tijdvak met een start precies op de vorige eindtijd is toegestaan. AT-04: een medewerker kan de reservering lezen maar niet wijzigen. AT-05: twee gelijktijdige aanvragen voor hetzelfde vrije tijdvak leveren samen één bevestiging op.
Deze criteria beschrijven het verwachte resultaat; ze zijn nog geen bewijs dat software eraan voldoet. Werk voor uitvoering de testgegevens, stappen en waarnemingen uit. Het stappenplan voor een acceptatietest van software gaat op die volgende fase in. Houd in het ontwerp de verbinding tussen behoefte E-01, functie FO-01 en criteria AT-01 tot en met AT-05 zichtbaar. Dan weet je welke controles opnieuw aandacht vragen wanneer een bedrijfsregel verandert.
Wie maakt het ontwerp en hoe houd je het actueel?
Laat de mensen die het proces kennen de regels en uitzonderingen toelichten. De opdrachtgever bewaakt doel en scope; een analist of leverancier kan het document uitwerken en de ontwikkelaar onderzoekt technische haalbaarheid. De precieze taakverdeling verschilt per project. Loop in ieder geval samen een normale en een afwijkende route door. Vraag een toekomstige gebruiker te vertellen wat die verwacht, zonder dat de opsteller ieder antwoord vooraf invult.
Geef het ontwerp een versie, datum en verantwoordelijke. Noteer per wijziging welke regel verandert, waarom, wie erover beslist en welke functies of criteria geraakt worden. Spreek bijvoorbeeld af dat een extra reserveringsbuffer pas onderdeel van versie 1.1 wordt nadat de invloed op bestaande boekingen is besproken. Een bijgewerkt plaatje zonder bijgewerkte overlapregel en tests laat anders twee verschillende afspraken naast elkaar bestaan.
Verbind de afgesproken versie aan de opdracht en laat onopgeloste vragen herkenbaar terugkomen. Controleer in het voorstel wat de leverancier uitwerkt, welke aannames gelden en hoe wijzigingen worden beoordeeld. De gids voor het beoordelen van een maatwerk software offerte helpt die scope en verantwoordelijkheden te bespreken. Een ontwerp hoeft niet vanaf dag één volledig te zijn, maar iedereen moet kunnen zien welke afspraken op dat moment de basis vormen.
Begin met één volledig uitgewerkte werktaak
Kies een proces waarover nu onduidelijkheid bestaat. Vul voor één taak het format in, laat een gebruiker het scenario doorlopen en bespreek de open vragen met de leverancier. Je merkt dan snel of termen als beschikbaar, bevestigd of bevoegd voor iedereen hetzelfde betekenen. Werk daarna pas verwante functies uit. De bruikbaarheid van het ontwerp zit in heldere beslissingen en controleerbaar gedrag, niet in het aantal pagina’s.
Onderzoek je bedrijfssoftware op maat, neem dan deze ene uitgewerkte taak, de belangrijkste uitzonderingen en de nog openstaande keuzes mee in het eerste gesprek. Daarmee kan Softora gerichter bespreken welke werking nodig is en wat eerst onderzocht moet worden. Het ontwerp legt de gewenste uitkomst vast; de bouw en de latere controles moeten laten zien of die uitkomst ook werkelijk wordt geleverd.
Over deze uitleg
Dit artikel is door Softora met hulp van AI opgesteld en gecontroleerd aan de genoemde openbare bronnen. Het installatiebedrijf, de meetset, de documentnummers en de regels zijn fictief en dienen uitsluitend als uitleg. De illustraties zijn eigen vectorbeelden voor dit artikel, met hulp van code gemaakt; het zijn geen schermopnamen of klantresultaten. Het documentformat is een praktisch voorstel, geen certificeringsnorm.
