Een functioneel ontwerp beschrijft wat maatwerksoftware moet doen voor de mensen die ermee werken: welke processen het ondersteunt, welke gebruikers en rechten er zijn, welke gegevens, schermen, regels en koppelingen nodig zijn, en wanneer een functie af is. Hoe het systeem technisch wordt gebouwd, staat in het technisch ontwerp. Een goed functioneel ontwerp is kort, toetsbaar en groeit mee met het project.
Het loont om hier tijd in te steken. Het Project Management Institute (PMI) ondervroeg in 2014 ruim 2.000 projectprofessionals. Bij projecten die hun doelen niet haalden, was slecht eisenmanagement in 47% van de gevallen de hoofdoorzaak. Volgens hetzelfde rapport ging 5,1% van elke uitgegeven projectdollar verloren door slecht eisenmanagement, ofwel US$51 miljoen per miljard.
Hieronder lees je wat er in een functioneel ontwerp hoort, hoeveel detail je nodig hebt als je agile werkt, wie het schrijft en hoe het doorwerkt tot in de acceptatietest. Onderaan staat een uitgeschreven template.
Wat een functioneel ontwerp beschrijft
Een functioneel ontwerp legt het gedrag van de software vast vanuit de gebruiker en het bedrijfsproces. Een projectleider, een eindgebruiker en een tester moeten het kunnen lezen zonder programmeerkennis. Elke eis erin is zo geformuleerd dat je achteraf kunt vaststellen of de software eraan voldoet.
Die laatste eigenschap komt rechtstreeks uit de internationale norm voor eisen, ISO/IEC/IEEE 29148. Die beschrijft onder meer dat een goede eis eenduidig, volledig, consistent en verifieerbaar is. Een zin als "het systeem moet snel zijn" haalt die lat niet. "Een zoekopdracht op ordernummer toont binnen twee seconden het resultaat" wel.
Het functioneel ontwerp wordt vaak verward met twee andere documenten. Het verschil zit in de vraag die elk document beantwoordt:
| Document | Beantwoordt | Voorbeeld | Lezers |
|---|---|---|---|
| Functioneel ontwerp | Wat moet het systeem doen en onder welke regels | Een aanvraag boven een drempelbedrag gaat naar een tweede beoordelaar | Opdrachtgever, gebruikers, ontwikkelaars, testers |
| Technisch ontwerp | Hoe wordt het gebouwd | Datamodel, architectuur, API's, hosting van de applicatie | Ontwikkelaars en architecten |
| User story | Welk stukje waarde leveren we deze sprint | Als beoordelaar wil ik aanvragen boven de drempel apart zien, zodat ik ze eerst oppak | Het scrumteam |
User stories en een functioneel ontwerp vullen elkaar aan. Een story is een kleine, planbare eenheid werk. Het functioneel ontwerp geeft de samenhang: welke regels over alle stories heen gelden, welke rollen er zijn en hoe de processen op elkaar aansluiten. Zonder die samenhang zit de kennis verspreid over honderden tickets die niemand meer in één keer overziet.
Hoeveel detail een functioneel ontwerp nodig heeft bij agile werken
Agile teams zijn soms huiverig voor ontwerpdocumenten. Dat heeft een herkenbare oorsprong in het Manifest voor agile softwareontwikkeling uit 2001:
"Working software over comprehensive documentation." Manifesto for Agile Software Development
Direct daarna schrijven de opstellers dat de punten aan de rechterkant ook waarde hebben. Documentatie hoort er dus bij, zolang die in dienst staat van werkende software.
Een werkbare verdeling bij agile werken ziet er zo uit:
- Vooraf uitwerken: doel en scope, rollen en rechten, de hoofdprocessen, het gegevensmodel op hoofdlijnen, koppelingen en de eisen aan prestaties en beveiliging. Dit zijn keuzes die later duur zijn om terug te draaien.
- Per sprint uitwerken: schermdetails, teksten, uitzonderingen en de acceptatiecriteria van de stories die eraan komen.
- Na elke sprint bijwerken: wat is gebouwd en goedgekeurd, zodat het document de actuele werking beschrijft.
Voor een eerste versie met een kleine scope, zoals een MVP, volstaat vaak een functioneel ontwerp van een handvol pagina's. Het moet de keuzes vastleggen die het team zonder jou niet kan maken.
Wie het functioneel ontwerp schrijft
De pen ligt meestal bij een functioneel ontwerper, business analist of productowner. Het document is alleen goed als de juiste mensen hun kennis inbrengen:
- De opdrachtgever bepaalt doel, scope en prioriteiten, en neemt besluiten bij tegenstrijdige wensen.
- Eindgebruikers en proceseigenaren vertellen hoe het werk nu gaat, waar het knelt en welke uitzonderingen voorkomen.
- Ontwikkelaars en een architect toetsen of eisen haalbaar zijn en wijzen op keuzes met grote gevolgen voor de bouw.
- Testers lezen mee op toetsbaarheid, zodat elke eis een controleerbare uitkomst heeft.
Laat je software bouwen door een externe partij, bespreek dan vooraf wie het functioneel ontwerp schrijft en wie het goedkeurt. Sommige leveranciers verwachten een compleet document, andere werken het samen met je uit in een startfase. In ons artikel over software laten maken lees je hoe zo'n traject verder verloopt, en in hoe kies je een softwarebedrijf staan de vragen die je een leverancier hierover kunt stellen.
Template: inhoudsopgave van een functioneel ontwerp
Gebruik deze inhoudsopgave als startpunt. Schrap wat niet past en voeg hoofdstukken toe als je systeem daarom vraagt.
- Inleiding en doel. Het probleem dat de software oplost, het beoogde resultaat en hoe je dat meet.
- Scope. Wat in deze versie zit en wat er bewust buiten valt. De tweede lijst voorkomt veel discussie.
- Begrippenlijst. Eenduidige definities van termen als klant, aanvraag of order, zodat iedereen hetzelfde bedoelt.
- Gebruikers en rollen. Per rol: wie het is, wat die doet en welke rechten die heeft om te lezen, wijzigen en goed te keuren.
- Processen. De hoofdprocessen van begin tot eind, met een processchema en de uitzonderingen die in de praktijk voorkomen.
- Functionele eisen. Per functie een genummerde, toetsbare eis met prioriteit, bijvoorbeeld volgens MoSCoW (must, should, could, won't).
- Bedrijfsregels. Berekeningen, drempels, statusovergangen en validaties, apart genummerd zodat je ernaar kunt verwijzen.
- Gegevens. De belangrijkste gegevens en hun onderlinge relaties, met herkomst en eigenaar.
- Schermen en rapportages. Schetsen of wireframes van de belangrijkste schermen en de overzichten die gebruikers nodig hebben.
- Koppelingen. Met welke systemen gegevens worden uitgewisseld, in welke richting, hoe vaak en wat er gebeurt bij een storing.
- Niet functionele eisen. Prestaties, beschikbaarheid, beveiliging, gebruiksgemak en onderhoudbaarheid, elk met een meetbare norm.
- Acceptatiecriteria. Per eis of groep eisen de voorwaarden waaronder je de functie goedkeurt.
- Open punten en besluiten. Wat nog uitgezocht moet worden, en welke besluiten wanneer en door wie zijn genomen.
- Versiebeheer. Versienummer, datum, auteur en een korte omschrijving van elke wijziging.
Vijf veelgemaakte fouten in een functioneel ontwerp
De meeste problemen met een functioneel ontwerp komen pas aan het licht tijdens de bouw of de acceptatietest. Deze vijf zien we het vaakst:
- Oplossingen voorschrijven. "Er komt een dropdown met alle klanten" legt een technische keuze vast. Beschrijf liever de behoefte: de gebruiker moet een klant snel kunnen vinden op naam of nummer.
- Vage woorden. Snel, gebruiksvriendelijk en flexibel zijn niet toetsbaar. Maak er een getal of een concreet gedrag van.
- Alleen het ideale pad. Het proces waarin alles goed gaat, is meestal het kleinste deel van het werk. Afwijzingen, correcties en storingen kosten de meeste bouwtijd.
- Geen eigenaar voor besluiten. Als niemand bevoegd is om te kiezen, blijven open punten openstaan tot het team zelf een aanname doet.
- Een document dat na de start stilstaat. Een functioneel ontwerp dat de werkelijkheid niet meer beschrijft, gebruikt niemand meer, ook niet bij onderhoud of een volgende uitbreiding.
Hoe het functioneel ontwerp doorwerkt in acceptatie en testen
Een functioneel ontwerp is ook de basis voor de acceptatietest. Elke genummerde eis krijgt een of meer testgevallen met een verwachte uitkomst. Zo zie je in één overzicht welke eisen getest en goedgekeurd zijn, en welke nog openstaan. Die koppeling van eis naar test heet traceerbaarheid.
Veel organisaties regelen die toets niet formeel. In het onderzoek van PMI gebruikte 46% van de organisaties een formeel proces om eisen objectief te valideren. Het rapport noemt onnauwkeurig verzamelde eisen bovendien als een hoofdoorzaak van mislukte projecten, bij 37% in 2014 tegen 32% een jaar eerder.
Bij agile werken sluit dit aan op de Definition of Done uit de Scrum Guide: een story is pas klaar als hij aan de afgesproken kwaliteitsnormen voldoet. Zet de acceptatiecriteria uit het functioneel ontwerp daarom in de story, laat testers ze vooraf lezen en automatiseer de tests die bij elke release opnieuw moeten draaien.
Wij bouwen al ruim dertig jaar maatwerk software, van MRO software voor de luchtvaart tot een platform voor subsidieadministratie en RFID in de supply chain. Met 30+ engineers in Nijmegen en Sarajevo, meer dan 100 projecten en certificering voor ISO 9001 en ISO 27001 helpen we opdrachtgevers om van een eerste idee naar een toetsbaar functioneel ontwerp te komen. Lees hoe we werken bij software laten ontwikkelen of plan een gesprek over je eigen functioneel ontwerp.
Veelgestelde vragen
Wat is het verschil tussen een functioneel en een technisch ontwerp?
Een functioneel ontwerp beschrijft wat de software doet voor gebruikers en onder welke regels. Een technisch ontwerp beschrijft hoe het wordt gebouwd: architectuur, datamodel, koppelingen op technisch niveau en de gekozen technologie. Het technisch ontwerp volgt uit het functioneel ontwerp.
Heb je een functioneel ontwerp nodig als je met user stories werkt?
Ja, al kan het korter zijn. User stories beschrijven losse stukjes waarde per sprint. Het functioneel ontwerp bewaakt de samenhang: rollen, bedrijfsregels, gegevens, koppelingen en niet functionele eisen die voor alle stories gelden.
Hoe lang is een functioneel ontwerp?
Dat hangt af van de omvang en het risico van het systeem. Een kleine eerste versie past vaak in een handvol pagina's; een systeem met veel rollen, regels en koppelingen vraagt meer. De maatstaf is dat elke eis toetsbaar is en dat het team geen belangrijke keuzes zelf hoeft te raden.
Wie keurt het functioneel ontwerp goed?
De opdrachtgever of productowner keurt het goed, na inbreng van eindgebruikers, ontwikkelaars en testers. Leg vast wie die bevoegdheid heeft en hoe wijzigingen na goedkeuring worden besproken en vastgelegd.
