Vereisten verzamelen: complete gids & sjabloon

Deze vragen vormen de lijst met vereisten voor het project. Op basis van de oplevering volgens de vereisten wordt bepaald of de onderneming al dan niet als een succesvol project wordt beschouwd. 

Projectmanagers gebruiken vereistedocumenten en tools voor vereistenbeheer om dit soort vereisten gedurende het project bij te houden:

• Functionele vereisten
• Technische vereisten
• Niet-functionele vereisten
• Systeemvereisten

Kanttekening:

Het verzamelen van vereisten is niet beperkt tot de periode vóór de productie. Documentatie van wijzigingsopdrachten, garantiedocumentatie enzovoort zijn nuttige vormen van doorlopende documentatie van vereisten die gedurende een project nieuwe vereisten aan het licht brengen—of zelfs na afloop van het project!

 

Zolang je met een klant werkt, blijft de documentatie groeien en zich voortdurend ontwikkelen.

Waarom is het verzamelen van vereisten belangrijk?

Het verzamelen van vereisten is om de volgende redenen belangrijk (net als het documenteren van die vereisten): 

1. Het dient als referentiepunt om de ontwikkeling van een project, de veranderende onderdelen en de implementatie ervan te documenteren 
2. Het dient als blauwdruk voor de belanghebbenden van het project om beter te begrijpen wat ze van het project kunnen verwachten (het wat, waar, wanneer en waarom van het project).
3. Het verkleint de ruimte voor fouten en onduidelijkheid, omdat vereisten duidelijk worden gedocumenteerd en overeengekomen voordat het werk begint.
4. Het biedt tijdens de uitvoering en kwaliteitscontrole van het project controles en waarborgen, zodat projectmanagers en teamleden ernaar kunnen teruggrijpen wanneer er twijfel bestaat over hoe ze verder moeten gaan.

Naast het uiteenzetten van wat ze kunnen verwachten, moet een effectieve planning voor vereistenbeheer ook beschrijven wat ze niet kunnen verwachten. Het opnemen van een sectie “Aannames” en/of “Uitsluitingen” is een verstandige aanpak om het risico van de gevreesde verbeelding van de klant uit te sluiten. 

Een voorbeeld van een softwarespecificatie met vereisten

Hier is een voorbeeld van een vereistespecificatie voor een e-commerceproject:

• Wat: PayPal-integratie
• Waar: Afrekenen
• Wanneer: Binnen stap 3 van 4 in het afrekenproces (na het webformulier voor het verzendadres, vóór de bevestiging)
• Waarom: Een bestaande integratie (bijv. PayPal) is in dit geval een betere oplossing dan een robuuste, op maat gemaakte integratie voor een betalingsdienst, omdat deze eenvoudig aan de bedrijfsvereisten voldoet.

• Aannames
  • Vast bedrag voor alle verzending en afhandeling
  • Alle verzendingen vinden plaats binnen de VS (Alaska en Hawaï niet inbegrepen)
  • Belastingen zijn niet van toepassing
• Uitsluitingen 
  • Aangepaste berekeningen van verzend- en afhandelingskosten
  • Internationale verzending en verzending naar Alaska of Hawaï
  • Belastingregels

Onthoud: hoe kleiner het verschil tussen de verwachtingen van de klant en de werkelijkheid van hun digitale product, hoe tevredener je klant zal zijn met het eindresultaat. De kwaliteit van je requirementsmanagement houdt rechtstreeks verband met je vermogen als projectmanager om elk grijs gebied met betrekking tot klantverwachtingen te verkleinen. 

In de overgrote meerderheid van de gevallen zal een klant er positief tegenover staan dat je scope creep beperkt als dat betekent dat je hun budget beschermt; als je de klant voldoende uitlegt waarom een functie wel of niet wordt aangepakt en vervolgens de redenering achter die aanpak binnen de requirements documenteert, is de kans veel groter dat je klant constructief meewerkt. 

De kans is groter dat ze hun goedkeuring geven en later, wanneer ze hun gebruikersacceptatietests (UAT) uitvoeren, hebben ze een voorsprong bij het begrijpen van het "waarom" achter de oplossing van je team.

Proces voor het verzamelen van requirements in 6 stappen

Hoewel het verzamelen van requirements moet beginnen zodra een samenwerking start en gedurende je volledige projectlevenscyclus moet doorgaan, is het nooit te vroeg om requirements te verzamelen en te documenteren. Begin er eigenlijk gisteren al mee.

Dit zijn de stappen voor het verzamelen van requirements.

1. Maak aantekeningen

Maak tijdens elke vergadering waarin je aanwezig bent—of die nu intern met je projectteam of extern met je klant plaatsvindt—altijd aantekeningen. Ga er nooit van uit dat iemand anders dit doet.

Op het moment zelf lijkt het misschien eenvoudig om ervan uit te gaan dat alles wat wordt besproken zal worden onthouden, maar 3 maanden en 15 vergaderingen later zullen je team en je klant je dankbaar zijn dat je een verslag van die gesprekken hebt om op terug te kijken.

Bekijk hier enkele van mijn aanbevolen procedures voor het maken van aantekeningen over requirements:

• Bereid voordat je naar je vergadering gaat je document met aantekeningen voor zodat het je agenda weerspiegelt. Zo wordt het eenvoudiger om actiepunten en gesprekspunten te ordenen. Op deze manier onthoud je wat nodig is en leg je gerelateerde informatie op een georganiseerde manier vast. 
• Plan na elke vergadering 15-30 minuten voor jezelf in om je aantekeningen te bekijken, te verwerken wat er is besproken, de actiepunten te prioriteren en uitdagingen/waarschuwingssignalen of de behoefte aan verduidelijking of extra vergaderingen vast te stellen.
• Stuur je aantekeningen naar je interne projectteam. Laat hen controleren en verifiëren wat je hebt aangemerkt als actiepunten, waarschuwingssignalen enzovoort. 
• Zodra het team je goedkeuring heeft gegeven, stuur je je aantekeningen naar je klant. 
• Gebruik ten slotte je aantekeningen als referentie om voor elk actiepunt taken aan te maken. Voeg nieuwe informatie toe aan je requirementsdocumentatie en plan de benodigde vergaderingen voor verdere verkenning of bespreking. 

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

2. Neem de creatieve requirements door

Laat beslissingen over ontwerp en styling niet over aan afzonderlijke teamleden: leg creatieve requirements waar mogelijk vast. Creatieve richtlijnen zijn van onschatbare waarde voor ontwikkelaars. Zorg er op zijn minst voor dat je een stijlgids bij de hand hebt—zelfs als die niet meer bevat dan lettertypen en merkkleuren.

Verzamel alle creatieve middelen, zoals merklogo's of merklettertypen, en upload ze naar een gedeelde omgeving (zoals software voor beheer van digitale middelen) zodat het hele team toegang en inzicht heeft.

3. Schrijf het requirementsdocument

Houd tijdens het documenteren het volgende in gedachten: je eerste poging om requirements te documenteren zal het moeilijkst zijn. Waarom? Omdat je geen eerder document hebt om te hergebruiken (oftewel KOPIËREN-PLAKKEN). Gelukkig bevat dit artikel een sjabloon voor requirementsdocumentatie dat als basis kan dienen.

Zoals in dit sjabloon wordt weergegeven, deel ik mijn requirementsdocumentatie op in vier onderdelen:

1. Annotatie: Bevat de nummers uit je geannoteerde ontwerp. Als je paginaontwerp 8 elementen bevat, heb je 8 annotaties en bevat je annotatiekolom 8 rijen
2. Element: Bevat elementtitels, zoals deze betrekking hebben op elke annotatie
3. Functionele vereiste: Bevat een definitie (de vereisten, volledig uitgeschreven) voor elk element
4. Beheerders-/CMS-functionaliteit: Definieer alle beheerders- en/of CMS-functionaliteit die verband houdt met het betreffende element

4. Houd een interne beoordeling

In dit deel van het proces voor het verzamelen van vereisten plan je nog een interne vergadering met je projectteam om je documentatie met vereisten te beoordelen. Dit is een laatste interne controle om er zeker van te zijn dat je de implementatie goed begrijpt.

Laat het team indien mogelijk je documentatie met vereisten vóór de vergadering beoordelen, zodat ze voorbereid met hun vragen en/of feedback kunnen komen. Gebruik de vergadering om eventuele vragen of feedback over de vereisten te bespreken.

Breng de nodige wijzigingen aan in de documentatie op basis van jullie interne bespreking. Stuur de herziene documentatie met vereisten tot slot opnieuw naar het team voor een laatste goedkeuring. Zodra het interne projectteam de documentatie met vereisten definitief heeft goedgekeurd, sla je het document op als pdf om ervoor te zorgen dat het in de definitieve staat blijft voor de volgende stap: het uitwerken van taken. 

5. Werk de taken uit

Verstrek de pdf-versie van de documentatie met vereisten aan je ontwikkelingsteam. Idealiter werken je ontwikkelaars of de ontwikkelingsleider de taken voor de ontwikkeling uit. 

Hoewel sommige organisaties werken volgens een proces waarbij projectmanagers alle taken uitwerken, geef ik er de voorkeur aan dat ontwikkelaars hun eigen taken uitwerken; de paar uur die dit kost, zijn het waard.

Je kunt je team nog steeds nuttige richtlijnen geven bij het uitwerken van hun ontwikkelingstaken en op te leveren resultaten. Na het uitwerken van de taken kun je een definitieve schatting van het aantal uren opstellen.

Vergelijk die prognose met de projectplanning die eerder met je klant is gecommuniceerd en stuur waar nodig bij. Zie voor meer informatie over het maken van projectramingen deze complete handleiding voor projectramingen.

6. Houd een externe beoordeling

Het is tijd om de documentatie met vereisten aan je klant te presenteren. Verstrek deze als pdf om ervoor te zorgen dat er geen wijzigingen worden aangebracht. Dit (1) laat zien dat je investeert in een goed begrip van de digitale oplossing door de klant en (2) biedt je een vorm van bescherming, zodat je kunt zeggen: “Ik zei het toch” (maar dan veel welbespraakter) wanneer de scope van het project onvermijdelijk begint uit te dijen.

Onderwijs je klant. Neem hen mee door deze waardevolle documentatie die je zo zorgvuldig voor hen hebt samengesteld. Onthoud: zij zijn de experts van hun bedrijf. Jij bent de expert op het gebied van de digitale oplossing die je hun aanbiedt. Zij betalen je voor deze oplossing. Onderwijs en versterk je klant. 

Zodra de klant heeft bevestigd dat hij de documentatie met vereisten begrijpt, is het tijd om formele goedkeuring te ontvangen. Stuur de ondertekende en goedgekeurde documentatie met vereisten naar je team en sla deze op een gedeelde locatie op, met behulp van software voor documentbeheer, zodat er formeel is vastgelegd dat de ontwikkeling kan beginnen.

Technieken voor het verzamelen van vereisten

Hier zijn enkele technieken die je helpen om ervoor te zorgen dat je het belangrijke werk voor het verzamelen van vereisten zo goed mogelijk uitvoert:

1. Begin meteen

De documentatie met vereisten moet beginnen zodra de gesprekken op gang komen, voordat je het exacte projectplan of de projectdoelen hebt vastgelegd. Leg alles vast wat je kunt en beperk het daarna tot de essentie. Hier zijn enkele strategieën die je met je klant kunt proberen:

• Stuur hun een vragenlijst over wat ze in het project willen zien
• Houd een brainstormsessie
• Houd een focusgroep

Verwijder geen informatie uit het document, maar categoriseer deze als wat wel en niet inbegrepen is—zo voorkom je later verkeerde aannames bij de klant.

Je kunt je documentatie met WIP-vereisten (werk in uitvoering) erbij pakken en aangeven waar die informatie is vastgelegd, waarom deze mogelijk niet is opgenomen, welke logica achter die beslissing zit en op welke datum dit is vastgelegd, zodat alles traceerbaar is.

2. Maak gebruik van sjablonen

Zodra je enkele vereistedocumenten hebt opgesteld, kun je deze gaan benutten en er sjablonen van maken voor toekomstig gebruik in andere projecten. Vooral als je je richt op e-commerce- of leerapplicatieprojecten, zul je functionaliteitspatronen zichtbaar zien worden. Bepaal waar je onderdelen opnieuw kunt gebruiken. 

3. Samenwerken maakt het verschil

Als er verschillende soorten teamleden aan een project werken, kunnen de vereisten voor elk expertisegebied worden opgesteld door de betreffende experts.

In veel gevallen is het gesprek over vereisten een kronkelend spoor van telefoongesprekken, verschillende afzonderlijke vergaderingen en gesprekken, enzovoort. Daarom is het van cruciaal belang dat je de documentatie over vereisten toewijst aan de betreffende teamleden terwijl je vereisten verzamelt en samenstelt.

4. Leg vereisten niet alleen vast—leer

Doe meer dan alleen aantekeningen maken. Verwacht meer dan dat medewerkers je een muur van tekst e-mailen met hun deel van de vereisten. Neem de tijd om met je team van ontwikkelaars te gaan zitten en leer welke oplossingen het team voor ogen heeft voor de implementatie. Bespreek waarom en hoe. Stel vragen.

Voordat je zegt: "Maar we hebben maar zoveel tijd op een dag—en hoe zit het met het budget?", moet je dit begrijpen: als een oplossing waaraan je werkt toepasbaar is op meer dan één project, hoeft deze extra tijd om inzicht te krijgen niet per se factureerbaar te zijn. Je breidt je vakinhoudelijke expertise uit, wat je dagelijkse werk rechtstreeks verbetert. 

5. Houd je klant op de hoogte

Zorg naast een intern vereistedocument ook voor een WIP-vereistedocument voor de klant. In het interne document hoef je je minder zorgen te maken over het opnemen van meer transparante aantekeningen.

Als je niet met gevoelige informatie werkt, kun je deze gedeelde ruimte creëren via een Google-document, waarbij de machtigingen zo zijn ingesteld dat de klant opmerkingen kan plaatsen. Als je wel met gevoelige informatie werkt, deel dan wekelijks een versie van het vereistedocument om de klant een momentopname te geven van wat er is vastgelegd.

6. Ga ervan uit dat je klant altijd meer wil weten

In plaats van het risico te lopen ervan uit te gaan dat je klant meer weet dan werkelijk het geval is (en daar later de gevolgen van te ondervinden), kun je ervan uitgaan dat je klant altijd meer wil weten. Stel jezelf bij elke annotatie vijf keer de vraag “Waarom?” om ervoor te zorgen dat elke vereiste grondig is uitgewerkt. 

Door jezelf bij elke vereiste vijf keer de vraag “Waarom?” te stellen, word je uitgedaagd om echt na te denken over de logica achter elk element en elke functionaliteit van elk paginatype. Je zult misschien verbaasd zijn over hoeveel jij leert (of beseft dat je moet leren).

3 tips van experts voor het schrijven van een projectvereistedocument

1. Schrijf vereisten voor globale elementen afzonderlijk

Om overbodigheid te voorkomen, behandel je alle globale elementen in een sectie “Globale elementen” van je vereistedocumentatie. Dit geldt voor globale elementen zoals de items in je hoofdnavigatiemenu, alles binnen je globale koptekst en alles binnen je voettekst. 

Nadat je vereisten voor deze globale elementen hebt geschreven, hoef je ze niet opnieuw op de andere pagina's te annoteren; annoteer alleen elementen die specifiek zijn voor die pagina's.

More Articles

• Tips voor het opbouwen van je Slack-profiel

2. Kopieer en plak identieke functionaliteit om consistentie te waarborgen

Dit is slechts een tip om in gedachten te houden voor je eigen gemoedsrust (en die van je klant). Je zult dit het vaakst zien bij veelvoorkomende pagina-elementen zoals grote introductie- of bannerafbeeldingen, kopteksten of pictogrammen voor “teruggaan”—een van de vele herhaalde functionaliteiten op verschillende paginatypen (niet te verwarren met globale elementen). 

3. Houd rekening met beheer en CMS (of het ontbreken daarvan)

Wanneer we zo gefocust zijn op de functionaliteit van elk pagina-element, is het gemakkelijk om administratieve en/of CMS-functionaliteit over het hoofd te zien. Als je een oplossing implementeert die administratieve en/of CMS-functionaliteit biedt, zorg er dan voor dat je dit als een afzonderlijke kolom opneemt in je vereisten. Hieronder vind je een voorbeeld:

Sjabloon voor vereistedocument [Downloaden]

De details van je vereistenbepaling hangen af van je relatie met de klant, de ervaring van je team en andere factoren.

Je hebt echter nog steeds de basisonderdelen nodig van een vereistedocument voor een project, waarin de functionaliteit, locatie, het ontwerp enzovoort van een functie worden gedefinieerd. Hier vind je ons sjabloon voor vereistedocumenten (je moet lid zijn om toegang te krijgen):

Versnel je werk met meer dan 100 premiumsjablonen

Word DPM-lid om toegang te krijgen tot eindeloze, door experts gemaakte sjablonen waarmee je sneller en efficiënter kunt werken.