Definitie: Een technisch ontwerp (TO) is een document dat beschrijft hoe een softwareapplicatie wordt gebouwd: de architectuur, het datamodel, de koppelingen, de beveiliging en de keuzes voor techniek en hosting. Waar een functioneel ontwerp vastlegt wat de software moet doen, legt het technisch ontwerp vast hoe dat technisch wordt gerealiseerd.
In het kort
- Een technisch ontwerp vertaalt functionele eisen naar een bouwplan voor ontwikkelaars.
- Vaste onderdelen zijn architectuur, datamodel, koppelingen en API’s, rollen en rechten, beveiliging, hosting, teststrategie en eventuele datamigratie.
- In agile projecten is het technisch ontwerp vaak compacter en groeit het mee, met vastgelegde architectuurbeslissingen in plaats van één dik document.
- Een goed technisch ontwerp maakt keuzes controleerbaar en helpt een volgende ontwikkelaar om de applicatie te begrijpen.
Wat is een technisch ontwerp?
Een technisch ontwerp is het bouwplan van een applicatie. Het beschrijft welke onderdelen er zijn, hoe ze samenwerken, waar gegevens worden opgeslagen, hoe de applicatie met andere systemen praat en welke technische keuzes daaraan ten grondslag liggen. Atlassian noemt het softwareontwerpdocument een technische blauwdruk waarin architectuur, componenten en gegevensmodellen worden vastgelegd voordat de ontwikkeling begint.
Het document is bedoeld voor ontwikkelaars, architecten en beheerders. Het is geen tekst voor eindgebruikers. Toch is het voor een opdrachtgever nuttig om te weten wat erin staat, omdat technische keuzes gevolgen hebben voor kosten, beheer, beveiliging en de vrijheid om later met een andere partij verder te gaan.
Het technisch ontwerp volgt meestal op een functioneel ontwerp of een set functionele eisen. Eerst bepaal je wat de software moet kunnen, dan hoe je dat bouwt. In de praktijk lopen die twee vaak door elkaar: een technische beperking kan een functionele keuze veranderen, en andersom.
Functioneel ontwerp en technisch ontwerp: wat is het verschil?
| Functioneel ontwerp | Technisch ontwerp | |
|---|---|---|
| Vraag | Wat moet de software doen? | Hoe wordt de software gebouwd? |
| Doelgroep | Opdrachtgever, gebruikers, ontwikkelaars | Ontwikkelaars, architecten, beheerders |
| Inhoud | Processen, schermen, gebruikersverhalen, regels | Architectuur, datamodel, API’s, beveiliging, hosting |
| Taal | Begrijpelijk voor niet-technische lezers | Technisch, met diagrammen en specificaties |
| Voorbeeld | “Een klant kan een offerte digitaal accorderen” | “Akkoord wordt opgeslagen met tijdstempel en gebruikers-ID; bij akkoord start een taak die een pdf genereert en mailt” |
ClickUp vat het verschil zo samen: een functioneel ontwerp beschrijft wat de gebruiker met de software kan doen, een technisch ontwerp beschrijft hoe het systeem wordt gebouwd en welke software, datastructuren en talen daarvoor nodig zijn.
Wat staat er in een technisch ontwerp?
Er is geen wettelijk of verplicht format, maar de meeste technische ontwerpen bevatten dezelfde onderdelen. Niet elk project heeft ze allemaal nodig.
1. Inleiding en context
Het doel van de applicatie, de reikwijdte van het ontwerp en een verwijzing naar het functioneel ontwerp of de eisen. Ook wat er bewust buiten valt.
2. Architectuur
Een overzicht van de grote onderdelen en hoe ze samenwerken. Bijvoorbeeld een webapplicatie met een backend, een database, een wachtrij voor achtergrondtaken en koppelingen met een boekhoudpakket en een e-maildienst. Vaak met een diagram dat in één oogopslag laat zien wat waar draait.
3. Techniekkeuze
De programmeertaal, het framework, de database en eventuele belangrijke pakketten. Met een korte onderbouwing: waarom deze keuze, welke alternatieven zijn overwogen en wat de gevolgen zijn voor beheer en overdraagbaarheid.
4. Datamodel
Welke gegevens worden opgeslagen, in welke tabellen of entiteiten, en hoe ze met elkaar samenhangen. Dit is vaak het belangrijkste onderdeel. Een fout in het datamodel is later lastig te herstellen, omdat alles erop voortbouwt.
5. Koppelingen en API’s
Met welke systemen de applicatie gegevens uitwisselt, welke kant op, hoe vaak, in welk formaat en wat er gebeurt als een koppeling faalt. Ook of de applicatie zelf een API aanbiedt aan anderen.
6. Rollen, rechten en authenticatie
Hoe gebruikers inloggen, welke rollen er zijn en hoe de applicatie afdwingt wie wat mag zien en doen. Bij een klantportaal hoort hier ook hoe gegevens van verschillende klanten gescheiden blijven.
7. Beveiliging en privacy
Welke maatregelen er zijn tegen bekende aanvallen, hoe gevoelige gegevens worden opgeslagen, welke gegevens worden gelogd en hoe de applicatie voldoet aan de AVG.
8. Niet-functionele eisen
Prestaties, beschikbaarheid, schaalbaarheid en toegankelijkheid. Bijvoorbeeld hoeveel gelijktijdige gebruikers de applicatie aankan of hoe snel een pagina moet laden.
9. Hosting, uitrol en beheer
Waar de applicatie draait, hoe nieuwe versies online komen, hoe back-ups werken en hoe fouten worden gemonitord.
10. Teststrategie
Welke onderdelen automatisch worden getest, hoe handmatig wordt getest en wie een versie goedkeurt.
11. Datamigratie
Als er gegevens uit een bestaand systeem over moeten, hoe die worden omgezet, gecontroleerd en ingelezen.
12. Aannames, risico’s en open punten
Wat is aangenomen maar nog niet bevestigd, welke afhankelijkheden zijn er van derden, en welke keuzes moeten nog worden gemaakt.
Een voorbeeld: van functionele eis naar technisch ontwerp
Stel dat een functionele eis luidt: “Na het versturen van een aanvraagformulier op de website krijgt de juiste medewerker een taak, en de aanvrager een bevestiging.” In het technisch ontwerp wordt dat bijvoorbeeld uitgewerkt als:
- Het formulier stuurt de gegevens naar een endpoint van de applicatie, met validatie op verplichte velden.
- De aanvraag wordt opgeslagen in de tabel aanvragen, met status “nieuw” en een koppeling naar het type aanvraag.
- Op basis van het type wordt een taak aangemaakt voor de verantwoordelijke rol, niet voor een vaste persoon.
- Een achtergrondtaak verstuurt de bevestigingsmail via de e-maildienst; mislukt dat, dan wordt het opnieuw geprobeerd en gelogd.
- Persoonsgegevens worden na een vastgestelde termijn geanonimiseerd.
Zo wordt één zin uit het functioneel ontwerp vijf concrete afspraken waar een ontwikkelaar mee verder kan, en die een tester kan controleren.
Welke diagrammen horen in een technisch ontwerp?
Een diagram zegt vaak meer dan een pagina tekst. ClickUp noemt stroomdiagrammen als manier om technische specificaties begrijpelijk te maken. Deze soorten worden het meest gebruikt:
| Diagram | Wat het laat zien | Wanneer nuttig |
|---|---|---|
| Architectuurdiagram | De grote onderdelen en hun verbindingen | Altijd, als startpunt van het ontwerp |
| Datamodel of ERD | Tabellen, velden en relaties | Bij elke applicatie met eigen gegevens |
| Stroomdiagram | De stappen van een proces met beslispunten | Bij workflows met statussen en uitzonderingen |
| Sequentiediagram | Welke onderdelen in welke volgorde met elkaar communiceren | Bij koppelingen en betalingen |
| Deploymentdiagram | Waar onderdelen draaien en hoe ze bereikbaar zijn | Bij complexere hosting of meerdere omgevingen |
Houd diagrammen eenvoudig en bij de tijd. Een schets op een whiteboard die het team helpt een keuze te maken, is waardevoller dan een perfecte tekening die niemand bijhoudt.
Een voorbeeld van een vastgelegde architectuurbeslissing
Een architectuurbeslissing past vaak op een halve pagina. Een voorbeeld van de opbouw:
- Titel: Achtergrondtaken via een wachtrij.
- Context: Na een aanvraag moeten een bevestigingsmail en een pdf worden gemaakt. Dat kan enkele seconden duren.
- Besluit: Deze taken lopen via een wachtrij, los van het verzoek van de gebruiker.
- Alternatieven: Direct uitvoeren tijdens het verzoek, of een externe automatiseringsdienst.
- Gevolgen: De gebruiker krijgt sneller een reactie. Er is wel een proces nodig dat de wachtrij verwerkt en bewaakt.
Zo kan iemand over een jaar nog zien waarom het zo is gebouwd, en beoordelen of die reden nog geldt.
Heb je in een agile project nog een technisch ontwerp nodig?
Dat is een terechte vraag. Al in 2012 stelde een opiniestuk op Computable dat het gedetailleerde technisch ontwerp “in de prullenbak” hoort: het past niet bij werkwijzen als Scrum, is lastig actueel te houden en wordt in de praktijk weinig gelezen. Wel bleef documentatie op architectuurniveau volgens het stuk nuttig.
Die kritiek is deels terecht. Een dik document dat vooraf elk detail vastlegt, veroudert zodra de bouw begint. Tegelijk heeft vrijwel elk project baat bij een paar vastgelegde keuzes. Veel teams werken daarom met een lichtere vorm:
- Een compact architectuurdocument met de grote lijnen, het datamodel en de koppelingen.
- Architectuurbeslissingen als losse korte notities: welke keuze, waarom, welke alternatieven en welke gevolgen. Die worden vaak architecture decision records genoemd.
- Documentatie in de code en in de repository, zodat die meegroeit met de software.
- Diagrammen die op verschillende niveaus inzoomen, van het systeem als geheel tot de onderdelen daarbinnen.
De vuistregel: leg vast wat lastig terug te draaien is, wat een ander moet weten om verder te bouwen, en wat een opdrachtgever moet kunnen controleren.
Wanneer schrijf je het technisch ontwerp?
Het moment hangt af van de werkwijze. Bij een klassieke aanpak komt het technisch ontwerp na het functioneel ontwerp en vóór de bouw. Bij een agile aanpak wordt eerst de architectuur op hoofdlijnen vastgelegd, en worden details per onderdeel uitgewerkt vlak voordat dat onderdeel wordt gebouwd. In beide gevallen geldt: de keuzes die het lastigst terug te draaien zijn, zoals het datamodel, de hosting en de belangrijkste koppelingen, wil je vroeg helder hebben.
Hoe gedetailleerd moet een technisch ontwerp zijn?
Dat hangt af van het project. Deze factoren vragen om meer detail:
| Factor | Waarom meer detail |
|---|---|
| Meerdere ontwikkelaars of partijen | Iedereen moet van dezelfde afspraken uitgaan |
| Gevoelige gegevens | Beveiliging en privacy moeten aantoonbaar zijn |
| Veel koppelingen | Elke koppeling heeft eigen afspraken en foutsituaties |
| Aanbesteding of vaste prijs | Het ontwerp is basis voor de afspraak over prijs en scope |
| Lange levensduur | Een volgende ontwikkelaar moet keuzes kunnen begrijpen |
| Gereguleerde sector | Audits vragen om vastgelegde ontwerpbeslissingen |
Voor een kleine interne tool met één ontwikkelaar kan een paar pagina’s met datamodel, koppelingen en hosting voldoende zijn. Voor een platform met veel gebruikers en koppelingen is een uitgebreider ontwerp verstandig.
Technisch ontwerp en de afspraak over prijs
Bij een vaste prijs of een aanbesteding is het ontwerp vaak de basis van de afspraak. Hoe concreter de koppelingen, het datamodel en de rollen zijn beschreven, hoe beter een ontwikkelaar kan inschatten wat het werk is. Een vaag ontwerp leidt tot ruime marges of tot discussie tijdens de bouw.
Bij werken op basis van nacalculatie is het ontwerp minder bepalend voor de prijs, maar nog steeds nuttig om verrassingen te voorkomen. Een koppeling die achteraf veel complexer blijkt, of een migratie van rommelige gegevens, zijn typische posten die in een goed ontwerp vooraf zichtbaar worden.
Wie schrijft het technisch ontwerp?
Meestal stelt de ontwikkelaar of architect het technisch ontwerp op, op basis van het functioneel ontwerp. Bij grotere projecten doet een softwarearchitect het architectuurdeel en werken ontwikkelaars de details uit. De opdrachtgever hoeft het niet te schrijven, maar het is wel verstandig om het te laten toelichten. Stel vragen als: waar staan de gegevens, wat gebeurt er als een koppeling uitvalt, en kan een andere partij hiermee verder?
Veelgemaakte fouten
- Te vroeg te veel detail. Een ontwerp dat elk scherm technisch uitwerkt voordat het proces helder is, moet steeds worden herschreven.
- Geen onderbouwing van keuzes. “We gebruiken X” zonder waarom, maakt het lastig om later te beoordelen of de keuze nog klopt.
- Foutsituaties vergeten. Wat gebeurt er als een betaling mislukt, een koppeling niet reageert of een gebruiker halverwege stopt?
- Rechten als bijzaak. Rollen en rechten raken bijna elk onderdeel en horen er vanaf het begin in.
- Niet bijhouden. Een technisch ontwerp dat niet meer klopt met de software, is erger dan geen ontwerp, omdat het mensen op het verkeerde been zet.
- Alleen voor ontwikkelaars leesbaar. Een korte samenvatting in gewone taal helpt de opdrachtgever om de belangrijkste keuzes te begrijpen.
Checklist voor een bruikbaar technisch ontwerp
- Is duidelijk welke functionele eisen het ontwerp afdekt?
- Staat er een overzicht van de architectuur, liefst met een diagram?
- Is het datamodel beschreven, inclusief relaties?
- Zijn alle koppelingen benoemd, met richting, frequentie en foutafhandeling?
- Zijn rollen, rechten en de scheiding van gegevens uitgewerkt?
- Is beschreven hoe de applicatie wordt gehost, uitgerold en geback-upt?
- Zijn de belangrijkste keuzes onderbouwd?
- Staan aannames en risico’s expliciet vermeld?
- Is afgesproken wie het document bijhoudt?
Wat betekent dit voor jouw project?
Voor mij begint een ontwerp niet bij techniek, maar bij het proces: wat komt binnen, wie moet ermee verder en welke informatie heeft die persoon nodig? Het antwoord op die vragen bepaalt het datamodel, de rollen en de koppelingen. Pas daarna is een technische keuze zinvol.
Na een procesgesprek van ongeveer twintig minuten werk ik een betaalde blauwdruk uit. Daarin staan het afgebakende proces, schermschetsen, de afhankelijkheden en een voorstel voor de eerste versie. Het is geen dik technisch document, maar het legt wel vast wat lastig terug te draaien is. Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen, en welke koppelingen en gegevens daarvoor nodig zijn.
Vraag? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap. Lees ook hoe ik een webapplicatie bouw.
Veelgestelde vragen over technisch ontwerp
Wat is een technisch ontwerp?
Een technisch ontwerp is een document dat beschrijft hoe een applicatie technisch wordt gebouwd. Het legt de architectuur, het datamodel, de koppelingen, de beveiliging en de hosting vast, en vormt het bouwplan voor ontwikkelaars.
Wat is het verschil tussen een functioneel en een technisch ontwerp?
Een functioneel ontwerp beschrijft wat de software moet doen, in taal die gebruikers en opdrachtgevers begrijpen. Een technisch ontwerp beschrijft hoe de software wordt gebouwd, met keuzes over architectuur, gegevens, techniek en beveiliging.
Wat staat er in een technisch ontwerp van software?
Meestal een inleiding, de architectuur, de techniekkeuze, het datamodel, koppelingen en API’s, rollen en rechten, beveiliging, niet-functionele eisen, hosting, een teststrategie en eventueel datamigratie. Hoe uitgebreid het is, hangt af van de omvang en de risico’s van het project.
Verwante termen
Functionele eisen · Programma van eisen · Discovery-fase · Wireframe · Rollen en rechten · API-koppeling · Datamigratie · Technische schuld
← Terug naar de kennisbank