Een eisendocument voor een website schrijven
Een eisendocument bestaat zodat jij en de ontwikkelaar dezelfde website beschrijven. Het hoeft niet lang te zijn. Een opdracht van vier pagina's die beide partijen echt gelezen hebben voorkomt meer geschillen dan een specificatie van vijftig pagina's die geen van beiden heeft uitgelezen.
Deze gids behandelt wat erin hoort, wat je weglaat, en hoe je het belangrijkste deel schrijft: wat het project niet is.
Waar een eisendocument voor dient#
Het heeft drie taken: meerdere ontwikkelaars hetzelfde laten offreren zodat de offertes vergelijkbaar zijn, jou een referentie geven bij onenigheid over de scope, en je dwingen beslissingen te nemen terwijl ze nog goedkoop zijn.
Het is geen ontwerpbriefing en geen technische specificatie. «De site moet snel laden» is een eis; «gebruik Redis voor objectcaching» is een oplossing, en die kiezen voordat je iemand hebt ingehuurd haalt precies de expertise weg waarvoor je betaalt.
- Beschrijf uitkomsten en randvoorwaarden, geen implementaties.
- Schrijf het zo dat iemand buiten je organisatie het begrijpt zonder telefoontje.
- Houd het kort genoeg om in één keer te lezen — vier tot acht pagina's is ruim voldoende voor de meeste sites.
- Zet er een datum en versie op, want het gaat veranderen.
De secties die de moeite waard zijn#
Deze opzet dekt de meeste webprojecten. Sla over wat niet van toepassing is in plaats van het op te vullen.
| Sectie | Wat erin komt |
|---|---|
| Achtergrond | Wat de organisatie doet en waarom de site wordt gebouwd of vervangen |
| Doelen | Het hoofddoel, de nevendoelen, en hoe succes wordt gemeten |
| Publiek | Twee of drie bezoekersgroepen en de vraag waarmee elk aankomt |
| Paginastructuur | Elke pagina, gegroepeerd in secties, gemarkeerd als kritiek of later |
| Functionele eisen | Formulieren, zoeken, accounts, filteren, boeken, afrekenen — wat elk moet doen |
| Koppelingen | Elk extern systeem, met een contactpersoon en een link naar de API-documentatie |
| Content | Wie welke pagina schrijft, wie goedkeurt, wanneer het af moet |
| Niet-functioneel | Snelheid, toegankelijkheid, browsers en apparaten, talen, beveiliging |
| Buiten scope | Expliciet uitgesloten werk — de waardevolste sectie |
| Randvoorwaarden | Budgetbandbreedte, deadline en elke vaste keuze (huidige host, verplicht CMS) |
Schrijf eisen die je kunt toetsen#
Een eis is bruikbaar wanneer beide partijen achteraf kunnen vaststellen of eraan is voldaan. «De site moet snel zijn» is niet toetsbaar; «de productoverzichtspagina haalt Largest Contentful Paint onder 2,5 seconden op een middenklasse-Android via 4G» wel.
Hetzelfde geldt voor functionaliteit. «Een contactformulier» laat elke vraag die ertoe doet open.
| Vaag | Toetsbaar |
|---|---|
| Een contactformulier | Zes velden, spambescherming, opslag in database, mail naar twee adressen, AVG-toestemmingsregel |
| Geschikt voor mobiel | Bruikbaar bij 320 px, alle aanraakdoelen minstens 44 px, geen horizontaal scrollen |
| Snel | LCP onder 2,5 s en CLS onder 0,1 op de vier hoofdsjablonen, gemeten via 4G |
| Toegankelijk | WCAG 2.2 AA op de sjablonen, gecontroleerd met toetsenbord en schermlezer |
| SEO-vriendelijk | Bewerkbare titels en beschrijvingen, schone URL's, sitemap, gestructureerde data op artikelen |
| Meertalig | Drie talen, vertaalde URL's, hreflang-tags, taalkiezer op elke pagina |
De lijst buiten scope#
Dit is de sectie die men overslaat en degene die het project redt. Schrijf op wat een redelijk mens zou aannemen dat het is inbegrepen, en zeg helder dat het dat niet is — of neem het op, als dat wel zou moeten.
Dit doen vóórdat de offertes binnenkomen maakt de offertes vergelijkbaar. Het achteraf doen betekent ruzie.
- Teksten schrijven en corrigeren — ga ervan uit dat dit bij jou ligt tenzij de offerte anders zegt.
- Fotografie, illustratie en licenties voor beeldbanken.
- Content invoeren: wie typt 200 producten in het CMS?
- E-mailinrichting, DNS-migratie en overdracht van het hostingaccount.
- Doorlopend SEO-werk, onderscheiden van de technische inrichting bij lancering.
- Training, documentatie en overdracht.
- Ondersteuning na lancering: wat is gedekt, hoelang, en wat wordt gefactureerd.
Een goede ontwikkelaar vult deze lijst ongevraagd aan. Wie zonder vragen overal ja op zegt, heeft hem meestal niet gelezen, en het meningsverschil is dan simpelweg uitgesteld.
Veelgestelde vragen
Hoelang moet een eisendocument zijn?
Vier tot acht pagina's dekt de meeste zakelijke websites. Webshops en applicaties worden langer omdat het functionele deel groeit, maar boven de twintig pagina's mag je je afvragen wat er beschreven wordt dat een gesprek niet zou oplossen. De maatstaf is of beide partijen het gelezen hebben, niet of het volledig is.
Moet ik de technologie voorschrijven?
Alleen waar je een echte randvoorwaarde hebt: een CMS dat je team kent, een host waar je op moet blijven, een systeem dat gekoppeld moet worden. Beschrijf verder de uitkomst en laat de mensen die je inhuurt de implementatie kiezen. Een stack voorschrijven die je niet begrijpt beperkt je opties en levert een slechter antwoord op.
Heb ik ook wireframes nodig?
Grove wireframes voor de drie of vier belangrijkste sjablonen halen met heel weinig moeite veel dubbelzinnigheid weg, en ze zijn veel goedkoper te wijzigen dan een ontwerp. Ze vervangen de schriftelijke eisen niet — ze tonen indeling, geen gedrag — maar samen laten ze zich veel nauwkeuriger beprijzen dan elk apart.
En als ik sommige antwoorden niet weet?
Schrijf «nog te bepalen» en noem wie beslist en wanneer. Een eerlijke leemte met een eigenaar is prima; een verzonnen antwoord niet, want de offerte wordt erop gebouwd. Ontwikkelaars beprijzen onzekerheid toch wel, dus die zichtbaar maken levert je meestal een beter bedrag op dan hem verbergen.
website eisendocumentwebsite briefingwebsite specificatiewebsite offerteaanvraagscope webprojecteisen webontwikkeling
