Website requirements opstellen: complete gids en checklist

Website requirements opstellen betekent dat je vóór ontwerp en bouw vastlegt wat je website moet bereiken, voor wie hij werkt en aan welke voorwaarden hij moet voldoen. Een goed requirementsdocument bevat bedrijfsdoelen, doelgroepen, pagina’s, content, functies, technische randvoorwaarden, meetbaarheid en acceptatiecriteria. Daarmee voorkom je dat offertes verschillende oplossingen vergelijken of dat belangrijke keuzes pas tijdens de bouw naar voren komen.

Wat zijn website requirements?

Website requirements zijn de eisen en afspraken voor een nieuwe website of websitevernieuwing. Ze vormen de brug tussen een zakelijk vraagstuk en een werkende website. Denk niet alleen aan onderdelen als een contactformulier of een nieuw design, maar vooral aan het gewenste gedrag en resultaat.

Een requirement is sterker wanneer het antwoord geeft op deze vragen:

• Welk bedrijfsdoel ondersteunt dit?
• Voor welke bezoeker is dit bedoeld?
• Welke actie moet die bezoeker kunnen uitvoeren?
• Wie levert content, informatie of toegang aan?
• Hoe controleren we bij oplevering of dit werkt?

Requirements zijn geen technisch bestek dat je volledig zelf moet schrijven. Ze zijn wel het vertrekpunt voor een goed gesprek met een bureau. Bekijk ook onze checklist voor het kiezen van een webdesignbureau als je requirements wilt gebruiken om aanbieders beter te vergelijken.

Waarom requirements vooraf verschil maken

Zonder duidelijke requirements wordt een websiteproject al snel gestuurd door losse voorkeuren: een functie die onderweg wordt toegevoegd, pagina’s waarvan de inhoud nog onbekend is of een koppeling die niet was meegenomen. Dat maakt scope, planning en offertevergelijking onduidelijker.

Met requirements kun je juist bewuste keuzes maken:

• wat nodig is voor de eerste livegang;
• welke wensen later kunnen volgen;
• welke input je organisatie moet aanleveren;
• welke technische of inhoudelijke afhankelijkheden er zijn;
• waarop je de oplevering beoordeelt.

Website requirements opstellen in stappen

1. Start met het bedrijfsdoel

Begin niet met kleuren, templates of een lijst functies. Beschrijf eerst waarom de website er komt of vernieuwd wordt. Mogelijke doelen zijn beter passende aanvragen ontvangen, diensten begrijpelijker presenteren, vacatures ondersteunen, bestaande klanten informeren of een handmatig proces vereenvoudigen.

Vertaal het doel vervolgens naar een gewenste bezoekeractie. Bijvoorbeeld: “Een potentiële klant kan na het lezen van een dienstpagina een aanvraag doen met voldoende informatie voor een eerste beoordeling.” Dit is concreter dan “meer leads” en helpt bij keuzes over content, formulieren en conversiemeting.

2. Beschrijf doelgroepen en hun taken

Maak per belangrijke doelgroep een kort profiel. Noteer wat deze bezoeker wil weten, welke twijfel er kan zijn en welke actie logisch is. Een inkoper zoekt vaak andere informatie dan een eindgebruiker of sollicitant.

Leg ook de belangrijkste gebruikersroutes vast. Een eenvoudige route kan zijn: zoekmachine, dienstpagina, bewijs of werkwijze, contactpagina, aanvraag. Zo voorkom je dat een sitemap alleen de interne organisatiestructuur volgt.

3. Bepaal de scope van pagina’s en content

Maak een voorlopige sitemap met de pagina’s die nodig zijn voor de eerste release. Zet per pagina het doel, de primaire doelgroep, de gewenste actie en de contenteigenaar erbij. Neem bestaande pagina’s mee die behouden, samengevoegd, herschreven of verwijderd worden.

Maak contentverantwoordelijkheid expliciet. Een bureau kan structuur, formats en redactie ondersteunen, maar technische bouw kan niet zonder beslissingen over teksten, beelden, referenties en inhoudelijke goedkeuring.

4. Leg functionele requirements vast

Functionele requirements beschrijven wat de bezoeker of beheerder kan doen. Schrijf ze vanuit gedrag, niet vanuit een voorkeursoplossing. Dus niet: “Er komt een ingewikkeld formulier”, maar: “Een bezoeker kan een aanvraag versturen en de organisatie ontvangt de ingevulde gegevens op een afgesproken plek.”

Denk onder meer aan formulieren, zoekfuncties, agenda- of boekingsprocessen, gated content, vacatureoverzichten, meertaligheid, koppelingen met andere systemen en beheerrechten.

5. Beschrijf ontwerp en gebruikservaring zonder alles dicht te zetten

Geef richting met merkuitgangspunten, voorbeelden van bestaande middelen, gewenste uitstraling en inhoudelijke prioriteiten. Beschrijf ook wat bezoekers gemakkelijk moeten kunnen vinden of uitvoeren op mobiel en desktop. Laat ruimte voor het ontwerpteam om daar een passende oplossing van te maken.

Vermijd requirements als “modern” of “professioneel” zonder toelichting. Benoem liever welke indruk de website moet wekken en welk gedrag het ontwerp moet ondersteunen.

6. Neem SEO, bestaande URL’s en meting mee

Een nieuwe website is ook een migratie wanneer er al een site bestaat. Inventariseer bestaande URL’s, belangrijke content, organisch verkeer, verwijzende links en pagina’s die een zakelijke functie hebben. Leg vast dat oude en nieuwe URL’s worden gemapt en dat redirects onderdeel zijn van de oplevering. Google adviseert bij URL-wijzigingen onder meer URL-mapping en permanente redirects zorgvuldig te plannen.

Neem daarnaast requirements op voor logische interne links, crawlbare pagina’s, een sitemap, mobiele bruikbaarheid en meetbaarheid van belangrijke acties. Wil je vooraf bepalen welke bedrijfsdoelen en KPI’s je website moet ondersteunen, lees dan SEO-doelstellingen bepalen.

Leg ook vast welke conversies je wilt meten, zoals een verstuurd formulier, klik op een telefoonnummer of aanvraag van een gesprek. Voor campagnes is een goede inrichting van meting extra belangrijk. Zie hiervoor Google Ads-conversietracking instellen en controleren.

7. Noteer technische en WordPress-requirements

Je hoeft geen serverbeheerder te zijn om goede technische vragen te stellen. Leg vast wie verantwoordelijk is voor domein, hosting, back-ups, toegang, updates, beveiliging, herstel bij problemen en documentatie bij overdracht.

Als WordPress de beoogde oplossing is, moet de hostingomgeving de actuele WordPress-vereisten ondersteunen. WordPress noemt HTTPS en actuele ondersteuning voor PHP en MariaDB of MySQL als belangrijke uitgangspunten. Vraag het bureau of de hostingpartij hoe dit wordt gecontroleerd en onderhouden.

Neem koppelingen expliciet op: welk systeem wordt gekoppeld, welke gegevens wisselen uit, wie beheert de koppeling en wat gebeurt er als deze niet beschikbaar is? Dit voorkomt dat een koppeling als los detail te laat in het project verschijnt.

8. Neem privacy, beveiliging en toegankelijkheid mee

Een zakelijke website verwerkt mogelijk persoonsgegevens via formulieren, cookies, nieuwsbrieven of gekoppelde systemen. Noteer welke gegevens worden verzameld, waarvoor ze dienen en wie hierover binnen de organisatie beslist. Controleer welke wettelijke informatie, privacy-informatie, cookie-instellingen en toegankelijkheidsverplichtingen op jouw organisatie van toepassing zijn. Dit is geen onderdeel om op basis van aannames af te ronden; laat het zo nodig beoordelen door een deskundige.

Beschrijf toegankelijkheid ook praktisch: content moet begrijpelijk zijn, navigatie moet bruikbaar zijn en essentiële acties moeten niet afhankelijk zijn van alleen kleur, muisgebruik of een specifiek apparaat.

9. Prioriteer en maak requirements toetsbaar

Niet alles hoeft bij de eerste livegang klaar te zijn. Gebruik een eenvoudige prioritering:

• Must-have: nodig om de website verantwoord te lanceren en het hoofddoel te ondersteunen.
• Should-have: belangrijk, maar alleen opnemen als scope en afhankelijkheden dit toelaten.
• Could-have: waardevol idee voor een latere fase.
• Uitgesteld: nu niet in scope en pas oppakken na een nieuw besluit.

Voeg per belangrijk punt een acceptatiecriterium toe. Daarmee wordt duidelijk wanneer iets klaar is. Bijvoorbeeld: “Een beheerder kan zelfstandig een nieuwe dienstpagina maken volgens het afgesproken contentformat, zonder wijzigingen in de broncode.”

Praktische requirements-scorecard voor een mkb-website

Gebruik onderstaande tabel als startdocument. Pas de voorbeelden aan op je eigen organisatie en voeg per regel een eigenaar toe voordat je offertes aanvraagt.

Onderdeel	Requirement	Prioriteit	Eigenaar	Acceptatiecriterium
Bedrijfsdoel	De website ondersteunt gekwalificeerde contactaanvragen voor de belangrijkste diensten.	Must-have	Directie of marketing	De belangrijkste dienstpagina’s hebben een duidelijke vervolgstap naar contact of aanvraag.
Doelgroep	Bezoekers kunnen per doelgroep snel zien welke dienst of oplossing relevant is.	Must-have	Marketing	De navigatie en dienstpagina’s verwijzen aantoonbaar naar de afgesproken doelgroeproutes.
Content	Elke kernpagina krijgt een inhoudelijk verantwoordelijke en een status voor aanlevering.	Must-have	Marketing en inhoudelijke experts	Voor livegang is per kernpagina duidelijk wie tekst en beeld heeft goedgekeurd.
Contactformulier	Bezoekers kunnen een aanvraag versturen met gegevens die nodig zijn voor opvolging.	Must-have	Sales of klantcontact	Een testaanvraag komt op de afgesproken plek binnen en bevat de benodigde informatie.
SEO-migratie	Bestaande relevante URL’s worden geïnventariseerd en gekoppeld aan een nieuwe URL of bewuste verwijdering.	Must-have	Marketing en development	Er is een goedgekeurd redirectoverzicht voor de relevante oude URL’s.
Meting	Belangrijke contact- en aanvraagacties zijn meetbaar ingericht.	Must-have	Marketing	De afgesproken acties zijn getest en worden in de gekozen meetomgeving geregistreerd.
Beheer	Beheerders kunnen teksten, beelden en pagina’s onderhouden volgens afgesproken rollen.	Should-have	Marketing	Een aangewezen beheerder voert een testwijziging uit en krijgt overdrachtsdocumentatie.
Integratie	Formuliergegevens worden doorgezet naar het gekozen CRM of opvolgproces.	Should-have	Sales en IT	Een testbericht is volledig zichtbaar in het afgesproken systeem of proces.
Uitbreiding	Een online boekingsmodule wordt onderzocht na evaluatie van de eerste release.	Uitgesteld	Directie en marketing	Er is geen bouwverplichting voor livegang; besluitvorming volgt in een aparte fase.

Voorbeelden van zwakke en sterke requirements

• Zwak: “De website moet snel zijn.”Sterker: “De website wordt getest op de afgesproken pagina’s en apparaten. Het bureau documenteert de bevindingen en optimalisaties vóór oplevering.”
• Zwak: “We willen goede SEO.”Sterker: “De bestaande belangrijke URL’s worden geïnventariseerd, redirects worden vooraf afgestemd en kernpagina’s krijgen een duidelijke URL- en interne-linkstructuur.”
• Zwak: “We willen een gebruiksvriendelijke website.”Sterker: “Een nieuwe bezoeker kan vanaf een dienstpagina zonder zoeken de relevante contact- of aanvraagactie vinden.”
• Zwak: “We willen een moderne website.”Sterker: “De uitstraling moet deskundig en toegankelijk zijn, met ruimte voor inhoudelijke bewijsvoering en heldere vervolgstappen.”

Van requirements naar briefing en offerteaanvraag

Stuur niet alleen een lijstje functies rond. Maak van je requirements een briefing met context: bedrijfsdoel, doelgroepen, huidige situatie, scope, planning, beschikbare content, technische omgeving en besluitvorming. Vraag bureaus vervolgens om aannames, afhankelijkheden en onderdelen buiten scope expliciet te benoemen.

Zo vergelijk je niet alleen een eindbedrag of een visueel voorstel, maar ook de kwaliteit van de voorgestelde aanpak. Voor hulp bij strategie, ontwerp en realisatie kun je terecht bij strategisch en creatief webdesign van LYNX Media. Bekijk ook het volledige overzicht van webdesign-, SEO- en online marketingdiensten.

Wordt je website onderdeel van een bredere campagne? Denk dan vooraf na over de landingspagina’s, formulieren en meetpunten die advertenties nodig hebben. Ook dynamische advertentie-elementen vragen om betrouwbare brongegevens; lees meer over ad customizers in Google Ads.

Veelgemaakte fouten

• Starten met vormgeving terwijl het bedrijfsdoel en de gewenste actie niet helder zijn.
• Alle wensen als even belangrijk behandelen, waardoor scope niet beheersbaar is.
• Content, beelden en interne goedkeuring niet aan een eigenaar koppelen.
• Bestaande URL’s, organische vindbaarheid en redirects pas na de bouw bespreken.
• Alleen functies benoemen en geen acceptatiecriteria vastleggen.
• Hosting, beheer, beveiliging en overdracht als vanzelfsprekend beschouwen.

Wanneer herzie je je requirements?

Herzie requirements zodra het bedrijfsdoel verandert, een cruciale koppeling niet haalbaar blijkt, de inhoudelijke scope verschuift of nieuwe informatie uit onderzoek en ontwerp tot een betere keuze leidt. Beheer wijzigingen bewust: noteer wat verandert, waarom het verandert en welk effect dat heeft op prioriteit en oplevering.

Maak van wensen een uitvoerbare websiteopdracht

Goede website requirements maken je geen webdeveloper. Ze zorgen er wel voor dat je betere keuzes kunt maken, verwachtingen kunt afstemmen en een nieuwe website kunt toetsen aan wat voor je bedrijf echt nodig is. Wil je requirements omzetten naar een scherpe briefing en een website die conversie, vindbaarheid en beheer samenbrengt? Bespreek je website of online groeikansen met LYNX Media.