Vereisten verzamelen: complete gids & sjabloon
Het verzamelen van vereisten is een proces waarmee je verwachtingen met belanghebbenden kunt vaststellen en beheren, scope-uitbreiding kunt voorkomen en onduidelijkheid over wat je project daadwerkelijk oplevert kunt verminderen.
Hoe meer documentatie over vereisten je hebt, hoe minder ruimte er is voor fouten en aannames. Controles en tegenwichten bevorderen het gezamenlijke begrip van het project binnen je team en helpen de verwachtingen van je klant ten aanzien van het eindproduct te beheren.
Wat is het verzamelen van vereisten in projectmanagement?
Het verzamelen van vereisten is het proces waarbij wordt vastgesteld wat de projectsponsors en belangrijkste belanghebbenden van het project nodig hebben. Projectmanagers proberen vast te stellen waar om wordt gevraagd en welke details daarbij horen.
Create a Free Account to Read More
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Deze verzoeken worden de lijst met vereisten voor het project. De mate waarin aan de vereisten wordt voldaan, bepaalt of de onderneming al dan niet als een geslaagd project wordt beschouwd.
Projectmanagers gebruiken vereistedocumenten en hulpmiddelen voor vereistenbeheer om gedurende het project de volgende soorten vereisten bij te houden:
- Functionele vereisten
- Technische vereisten
- Niet-functionele vereisten
- Systeemvereisten
Waarom is het verzamelen van vereisten belangrijk?
Het verzamelen van vereisten is om de volgende redenen belangrijk (net als het documenteren van die vereisten):
- Het dient als referentiepunt om de ontwikkeling van een project, de verschillende onderdelen ervan en de implementatie ervan te documenteren
- Het dient als blauwdruk waarmee de belanghebbenden van het project beter kunnen begrijpen wat ze van het project kunnen verwachten (het wat, waar, wanneer en waarom van het project).
- Het vermindert de ruimte voor fouten en onduidelijkheid, omdat vereisten duidelijk worden gedocumenteerd en goedgekeurd voordat het werk begint.
- Het biedt gedurende de productie en kwaliteitscontrole van het project controles en tegenwichten, zodat projectmanagers en teamleden ernaar kunnen teruggrijpen wanneer er twijfel bestaat over hoe ze verder moeten gaan.
Naast het beschrijven 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 specificatie van softwarevereisten
Hier is een voorbeeld van een vereistenspecificatie voor een e-commerceproject:
- Wat: PayPal-integratie
- Waar: Afrekenen
- Wanneer: Binnen stap 3 van 4 in de afrekenervaring (na het webformulier voor het verzendadres, vóór de bevestiging)
- Waarom: Een bestaande integratie (bijvoorbeeld PayPal) is in dit geval een betere oplossing dan een robuuste, aangepaste integratie voor een betaaldienst, 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
- Internationaal verzenden, naar Alaska of naar 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 vereistenbeheer houdt rechtstreeks verband met je vermogen als projectmanager om elk grijs gebied met betrekking tot klantverwachtingen te beperken.
In de overgrote meerderheid van de gevallen staat een klant er positief tegenover als je scope-uitbreiding beperkt, zolang je daarmee hun budget beschermt; als je de klant voldoende uitlegt waarom een functie wel of niet wordt aangepakt en vervolgens de logica achter die aanpak binnen de vereisten documenteert, is de kans veel groter dat je klant samenwerkingsgericht is.
De kans is groter dat ze hun goedkeuring geven en later, wanneer ze gebruikersacceptatietests (UAT) uitvoeren, zullen ze al een voorsprong hebben bij het begrijpen van het "waarom" achter de oplossing van je team.
Proces voor het verzamelen van vereisten in 6 stappen
Hoewel het verzamelen van vereisten moet beginnen zodra een samenwerking start en gedurende je volledige projectlevenscyclus moet doorgaan, is het nooit te vroeg om vereisten te verzamelen en te documenteren. Begin er gisteren mee.
Dit zijn de stappen voor het verzamelen van vereisten.
1. Maak aantekeningen
Maak in elke vergadering waaraan je deelneemt—of die nu intern met je projectteam of extern met je klant plaatsvindt—altijd aantekeningen. Ga er nooit van uit dat iemand anders dat doet.
Op het moment zelf kan het eenvoudig lijken 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 hebt van die gesprekken om op terug te kijken.
Bekijk hier enkele van mijn aanbevolen werkwijzen voor het maken van aantekeningen over vereisten:
- Voordat je naar je vergadering gaat, bereid je document met aantekeningen voor zodat het je agenda weerspiegelt. Zo wordt het eenvoudiger om actiepunten en aandachtspunten 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 door te nemen, te verwerken wat er is besproken, actiepunten te prioriteren en uitdagingen/waarschuwingssignalen of behoeften aan verduidelijking of aanvullende vergaderingen vast te stellen.
- Stuur je aantekeningen naar je interne projectteam. Laat hen controleren en verifiëren welke actiepunten, waarschuwingssignalen enzovoort je hebt vastgesteld.
- Nadat het team zijn goedkeuring heeft gegeven, stuur je je aantekeningen naar je klant.
- Gebruik ten slotte je aantekeningen als referentie om voor elk actiepunt taken te maken. Voeg nieuwe informatie toe aan je documentatie van de vereisten en plan eventuele benodigde vergaderingen voor verdere verkenning of bespreking.
2. Neem de creatieve vereisten door
Laat beslissingen over ontwerp en vormgeving niet over aan afzonderlijke teamleden: leg creatieve vereisten 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 alleen uit lettertypen en merkkleuren bestaat.
Verzamel creatieve middelen, zoals merklogo's of merklettertypen, en upload ze naar een gedeelde omgeving (zoals software voor digitaal middelenbeheer) zodat het hele team toegang en inzicht heeft.
3. Schrijf het document met de vereisten
Wanneer je aan de documentatie begint, moet je onthouden: je eerste poging om vereisten te documenteren zal het moeilijkst zijn. Waarom? Omdat je geen eerder document hebt dat je kunt gebruiken (oftewel KOPIËREN-PLAKKEN). Gelukkig bevat dit artikel een sjabloon voor vereisten documentatie dat als basis kan dienen.
Zoals in dit sjabloon wordt weergegeven, deel ik mijn documentatie van de vereisten op in vier onderdelen:
- Annotatie: Bevat de nummers van je geannoteerde ontwerp. Als je pagina-ontwerp 8 elementen bevat, heb je 8 annotaties en bevat je annotatiekolom 8 rijen
- Element: Bevat de titels van de elementen, zoals die bij elke annotatie horen
- Functionele vereiste: Bevat een definitie (de uitgeschreven vereisten) voor elk element
- Beheer-/CMS-functionaliteit: Definieer alle beheer- en/of CMS-functionaliteit die verband houdt met het bijbehorende 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 ervoor te zorgen dat je de implementatie goed begrijpt.
Laat het team indien mogelijk je documentatie met vereisten vóór de vergadering beoordelen, zodat ze voorbereid naar de vergadering kunnen komen met hun vragen en/of feedback. Gebruik de vergadering om eventuele vragen of feedback over de vereisten te bespreken.
Breng eventuele noodzakelijke 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 zijn definitieve goedkeuring van de documentatie met vereisten heeft gegeven, sla je het document op als pdf om ervoor te zorgen dat het voor de volgende stap, het uitwerken van taken, in de definitieve vorm blijft.
5. Werk de taken uit
Lever de pdf-versie van de documentatie met vereisten aan je ontwikkelteam. Idealiter werken je ontwikkelaars of de ontwikkelleider de taken voor de ontwikkeling uit.
Hoewel sommige organisaties werken volgens een proces waarbij projectmanagers alle taken uitwerken, geef ik er de voorkeur aan ontwikkelaars hun eigen taken te laten uitwerken; de paar uur die dit hun kost, zijn het waard.
Je kunt je team nog steeds nuttige richtlijnen geven bij het uitwerken van hun ontwikkeltaken 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 indien nodig bij. Zie voor meer informatie over het ramen van projecten deze complete handleiding voor projectramingen.
6. Houd een externe beoordeling
Het is tijd om de documentatie met vereisten aan je klant te presenteren. Lever deze aan 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 jou een vorm van zekerheid om “ik zei het toch” te kunnen zeggen (maar dan veel welsprekender) wanneer scope-uitbreiding binnen het project onvermijdelijk de kop opsteekt.
Breng je klant op de hoogte. 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. Informeer 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, zodat formeel is vastgelegd dat de ontwikkeling kan beginnen.
Technieken voor het verzamelen van vereisten
Hier zijn enkele technieken 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 uitproberen:
- Stuur hun een vragenlijst over wat ze in het project zouden willen zien
- Houd een brainstormsessie
- Houd een focusgroep
Verwijder geen informatie uit het document, maar categoriseer deze als wat wel en niet is opgenomen—zo voorkom je later aannames bij de klant.
Je kunt je documentatie met vereisten die nog WIP (werk in uitvoering) is erbij pakken en aangeven waar die informatie is vastgelegd, waarom deze mogelijk niet is opgenomen, welke redenering achter die beslissing zit en op welke datum dit is vastgelegd, zodat alles traceerbaar is.
2. Gebruik sjablonen
Zodra je een paar documenten met vereisten hebt opgesteld, begin je ze te benutten en te sjabloneren voor toekomstig gebruik in andere projecten. Vooral als je je specifiek richt op e-commerce- of leerapplicatieprojecten, zul je merken dat bepaalde functionaliteitspatronen naar voren komen. Bepaal waar je onderdelen opnieuw kunt gebruiken.
3. Samenwerken maakt dromen werkelijkheid
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 van 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 daarin hun deel van de vereisten. Neem de tijd om met je team van ontwikkelaars te gaan zitten en de oplossingen te leren kennen die 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 vergroot je inhoudelijke expertise, die je dagelijkse werk rechtstreeks verbetert.
5. Houd je klant op de hoogte
Zorg zowel voor een intern document met vereisten als voor een document met vereisten in uitvoering dat met de klant wordt gedeeld. In het interne document hoef je je minder zorgen te maken over het opnemen van transparantere aantekeningen.
Als je niet met gevoelige informatie werkt, kun je deze gedeelde ruimte creëren via een Google-document, met ingeschakelde rechten voor de klant om opmerkingen te plaatsen. Als je wel met gevoelige informatie werkt, deel dan wekelijks een versie van het document met vereisten 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 dat je ervan uitgaat 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. Vraag jezelf bij elke annotatie vijf keer “Waarom?” af om ervoor te zorgen dat elke vereiste grondig is uitgewerkt.
Door jezelf bij elke vereiste vijf keer “Waarom?” af te vragen, word je uitgedaagd om echt na te denken over de logica achter elk element en elke functionaliteit van elk paginatype. Het zal je misschien verbazen hoeveel jij leert (of beseft dat je moet leren).
3 deskundige tips voor het schrijven van een document met projectvereisten
1. Schrijf vereisten voor algemene elementen afzonderlijk
Om herhaling te voorkomen, behandel je alle algemene elementen in een sectie “Algemene elementen” van je documentatie met vereisten. Dit geldt voor algemene elementen zoals de items in je hoofdnavigatiemenu, alles binnen je algemene koptekst en alles binnen je voettekst.
Nadat je vereisten voor deze algemene elementen hebt geschreven, hoef je ze niet op de andere pagina's opnieuw te annoteren; annoteer alleen elementen die specifiek zijn voor die pagina's.
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 vooral zien bij veelvoorkomende pagina-elementen zoals prominente afbeeldingen/banners, kopteksten of pictogrammen voor “teruggaan”—naast een groot aantal herhaalde functionaliteiten op verschillende paginatypen (niet te verwarren met algemene 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 beheerders- en/of CMS-functionaliteit buiten beschouwing te laten. Als je een oplossing implementeert die beheerders- en/of CMS-functionaliteit biedt, zorg er dan voor dat je dit als een afzonderlijke kolom in je vereisten opneemt. Voorbeeld hieronder:
Sjabloon voor een document met vereisten [Downloaden]
De details van het verzamelen van je vereisten 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 projectvereistendocument dat de functionaliteit, locatie, het ontwerp enzovoort van een functie beschrijft. Hier is ons sjabloon voor projectvereistendocumenten (je moet lid zijn om er toegang toe te krijgen):
Werk sneller met meer dan 100 premium sjablonen
Word DPM-lid om toegang te krijgen tot eindeloos veel door experts gemaakte sjablonen waarmee je sneller en efficiënter kunt werken.
