Functioneel ontwerp: wat het is en hoe het eruitziet

Een functioneel ontwerp beschrijft wat een systeem moet doen, in taal die de opdrachtgever kan lezen. Het gaat over gedrag, niet over techniek: welke schermen er zijn, wat er gebeurt als iemand op een knop drukt, welke regels gelden en wat er moet gebeuren als iets misgaat. Hoe het gebouwd wordt staat er niet in; dat is het technisch ontwerp.

Dat onderscheid is de kern. Zodra er in een functioneel ontwerp tabelnamen of frameworks opduiken, leest de opdrachtgever niet meer mee. En juist die moet het kunnen goedkeuren, want hij is degene die weet of het klopt.

Waarom je een functioneel ontwerp maakt

Bij een project van enige omvang praten opdrachtgever en bouwer over hetzelfde woord met een ander beeld erbij. "De klant kan zijn bestelling aanpassen" klinkt duidelijk, tot je vraagt tot welk moment, welke velden, en wat er gebeurt met een order die al is ingepakt. Die vragen komen er toch, alleen: stel je ze vooraf, dan kosten ze een gesprek. Stel je ze tijdens het bouwen, dan kosten ze een verbouwing.

Een functioneel ontwerp geeft daarnaast iets om aan af te rekenen. Bij oplevering leg je het document naast de software. Wat erin staat, hoort te werken. Wat er niet in staat, is meerwerk. Dat voorkomt de discussie die anders aan het eind van elk project ontstaat.

Hoe een functioneel ontwerp eruitziet

Er is geen voorgeschreven vorm, maar de meeste documenten volgen dezelfde opbouw. Een voorbeeld van die indeling:

• Aanleiding en doel. Welk probleem lost dit op, en waaraan meet je straks of dat gelukt is.
• Betrokkenen en rollen. Wie gebruikt het systeem, en wat mag elke rol.
• Processen. De stappen die iemand doorloopt, van begin tot eind, inclusief de afwijkende paden.
• Schermen. Per scherm de velden, de knoppen en wat er na een handeling gebeurt.
• Bedrijfsregels. Berekeningen, voorwaarden en uitzonderingen, in gewone zinnen.
• Koppelingen. Welke andere systemen erbij komen, welke gegevens heen en weer gaan, en hoe vaak.
• Beheer. Wat de beheerder zelf moet kunnen aanpassen zonder een ontwikkelaar.
• Buiten scope. Wat er nadrukkelijk niet in zit.

Die laatste is de belangrijkste en wordt het vaakst vergeten. Wat je opschrijft dat er niet in zit, hoef je later niet uit te leggen.

Een voorbeeld van een bedrijfsregel

Vaag: "klanten met een account krijgen korting." Bruikbaar: "een klant met een goedgekeurd zakelijk account krijgt het staffelprijs-tarief van zijn prijslijst. Staat er geen prijslijst, dan geldt de standaardprijs. De korting geldt niet op artikelen die als actie zijn gemarkeerd."

Het verschil is dat de tweede versie te bouwen en te testen is. Bij elke regel die je opschrijft helpt de vraag: kan iemand die dit leest bepalen of het systeem het goed doet? Kan dat niet, dan is de regel nog niet af.

Waar het in de praktijk misgaat

De meest gemaakte fout is een document dat alleen de gelukkige route beschrijft. Alles werkt, iedereen vult netjes in. In de praktijk gaat een betaling mis, is een voorraad ineens nul en typt iemand een adres verkeerd. Beschrijf per proces wat er dan hoort te gebeuren, anders bepaalt de ontwikkelaar dat zelf.

De tweede is een ontwerp dat te lang blijft liggen. Een document van tachtig pagina's dat drie maanden duurde, klopt bij de start van het bouwen alweer niet. Beter is een compacter ontwerp dat je bijwerkt zodra er iets verandert.

De derde is het overslaan ervan bij een klein project. Dat kan prima, maar leg dan wel de bedrijfsregels vast. Juist die worden vergeten en juist die kosten geld als ze verkeerd blijken.

Wanneer je het nodig hebt

Bij een standaardwebshop zonder bijzondere regels is een functioneel ontwerp overdreven. Zodra er koppelingen bij komen, of afspraken per klant, of processen die van je eigen manier van werken afhangen, verdient het zichzelf terug. Bij ons is dat de fase voordat er een regel code wordt geschreven: eerst opschrijven wat het moet doen, dan pas hoe.