Vereistenbeheer 101: je stapsgewijze handleiding

Het is vrijdagavond en je staat op het punt pizza te bestellen. Je hebt de telefoon in de ene hand en een lijst met verzoeken van je vrienden in de andere. Maar eerst moet je ieders voorkeuren sorteren en beslissen welk soort pizza je moet bestellen. Pepperoni? Kaas? Vegetarisch?

Pizza bestellen begint griezelig veel te lijken op het beheren van vereisten voor je nieuwste productlancering. Net als in de bovenstaande situatie draait vereistenbeheer om het luisteren naar je belanghebbenden en het begrijpen hoe je het beste aan hun behoeften kunt voldoen. 

Wat is vereistenbeheer?

Vereistenbeheer is een manier om ervoor te zorgen dat de uiteindelijke projectresultaten voldoen aan de behoeften van klanten en interne belanghebbenden. In dit geval is een vereiste iets dat belanghebbenden nodig hebben of willen van je product. Belanghebbenden kunnen intern zijn (zoals cross-functional partners) of extern (zoals klanten of cliënten). 

Vereistenbeheer wordt meestal gebruikt door ontwikkelingsteams die werken aan softwareproducten en -functies, maar kan ook meer in het algemeen worden toegepast op projectbeheer. Een vereiste kan bijvoorbeeld een functie zijn waarmee klanten je product met succes kunnen gebruiken, of een aspect van je product dat cross-functional partners helpt hun bedrijfsdoelen te bereiken. 

Voordat je aan een product begint te werken, moet je het eens worden over de exacte vereisten, zodat je ervoor kunt zorgen dat je belanghebbenden geeft wat ze nodig hebben. Vereistenbeheer helpt je vereisten te documenteren en te prioriteren, wijzigingen bij te houden en afgestemd te blijven met belanghebbenden gedurende de hele levenscyclus van het project. Het helpt je ook om veranderende vereisten te beheren en ervoor te zorgen dat je project binnen het bereik blijft. 

Wat is een vereiste? 

Een vereiste is een component die je moet implementeren om een functie of product te voltooien. Met andere woorden, het is iets dat je product moet hebben of doen om aan de behoeften van je belanghebbenden te voldoen. Softwareproducten kunnen honderden vereisten hebben. Maar ongeacht hoeveel vereisten je product heeft, ze moeten allemaal: 

• Noodzakelijk: je hebt deze vereiste nodig om je bedrijfs- of productdoelen te bereiken. 

• Specifiek: de vereiste is gedetailleerd en heeft een duidelijk doel. 

• Begrijpelijk: de vereiste is duidelijk geschreven en gemakkelijk te begrijpen. 

• Nauwkeurig: de vereiste heeft voldoende nauwkeurige informatie over de uitdaging of behoefte die deze vereiste aanpakt. Dat betekent dat je niet alleen moet beschrijven wat er moet gebeuren, maar ook moet verduidelijken waarom de vereiste belangrijk is. 

• Haalbaar: je moet de vereiste onderzoeken om er zeker van te zijn dat je deze kunt implementeren met je huidige technologiestack en code-infrastructuur.

• Testbaar: je moet de vereiste kunnen testen door middel van gebruikerstests, A/B-tests of een andere methode. 

Hier is een voorbeeld. Stel je voor dat je een app maakt en een van je vereisten is dat de hele app moet worden vertaald in het Engels, Chinees, Japans en Frans, omdat deze talen overeenkomen met je belangrijkste bedrijfsmarkten.

• Deze vereiste is noodzakelijk om je app te lanceren in de belangrijkste markten van je bedrijf en om bedrijfsdoelstellingen te bereiken. 

• Het is specifiek omdat je aangeeft welke talen je nodig hebt en dat de hele app moet worden vertaald. 

• Het is begrijpelijk omdat het niet ingaat op technische details, maar eerder is geschreven op een manier die je teamleden en cross-functional belanghebbenden kunnen begrijpen. 

• Het is nauwkeurig omdat je duidelijk hebt uiteengezet waarom de vereiste belangrijk is - omdat Engels, Chinees, Japans en Frans aansluiten bij de primaire markten van je bedrijf. 

• Het is haalbaar omdat je al prototypes en testcases in andere talen hebt gebouwd, dus je weet dat lokalisatie mogelijk is en zal presteren zoals verwacht. 

• Het is testbaar omdat je een systeem hebt om de nauwkeurigheid van elke vertaalde versie te testen en te bevestigen. 

Waarom is vereistenbeheer belangrijk? 

Om een geweldig product te maken, heb je vereistenbeheer nodig. Dit is waarom: 

• Verzend de juiste functies. Het vereistenbeheerproces helpt te definiëren wat je gebruikers nodig hebben door te begrijpen hoe ze met het product omgaan. Dit helpt je om je deliverables in de eerste plaats af te stemmen op de essentiële behoeften van je klanten. 

• Afstemmen op bedrijfsdoelen. Zorg er bij het documenteren en prioriteren van vereisten voor dat ze allemaal aansluiten bij je overkoepelende bedrijfsdoelen. Een vereiste om je app bijvoorbeeld in 12 talen te vertalen, ondersteunt een bedrijfsdoel om uit te breiden naar internationale markten. Als een vereiste de bedrijfsdoelen niet ondersteunt, betekent dit waarschijnlijk dat je ergens anders middelen moet investeren - of een heel goede reden moet hebben waarom de vereiste belangrijk is. 

• Scope creep voorkomen. Gedefinieerde vereisten functioneren als een projectbereik - ze stellen grenzen en bepalen precies naar welke doelen en deliverables je toe werkt. Het vooraf definiëren van vereisten helpt je potentiële obstakels te identificeren en terug te dringen wanneer belanghebbenden proberen extra vereisten toe te voegen.

• Vermijd obstakels. Het maken van een product is complex - er is softwareontwikkeling, ontwerp en testen - om nog maar te zwijgen van complexe codestacks en engineering-systemen. Vereistenbeheer helpt je bij het plannen van de ontwikkeling van een product binnen de beperkingen van je codestack en bij het bijhouden van wat je moet bereiken in elke fase van het productontwikkelingsproces.

Wie is verantwoordelijk voor het vereistenbeheer? 

De persoon die verantwoordelijk is voor het vereistenbeheer hangt af van je individuele project of Team. Dat gezegd hebbende, beheren producteigenaren of productmanagers meestal vereisten voor ontwikkelingsteams. Deze twee rollen zijn vergelijkbaar, behalve dat producteigenaren een standaardrol zijn in Scrum-teams, terwijl productmanagers een meer universele rol zijn, ongeacht of je team een Agile-methodologie gebruikt. Als je aan een meer algemeen project werkt in plaats van een product te ontwikkelen, is de projectmanager verantwoordelijk voor het vereistenbeheer. 

Vereistenbeheer vereist cross-functional samenwerking tussen je team en projectbelanghebbenden. Je moet feedback van belanghebbenden verzamelen, met hen samenwerken om elke vereiste te begrijpen en je team helpen bij het plannen hoe aan elke behoefte kan worden voldaan. Dat betekent dat de persoon die de vereisten voor je project beheert, sterke samenwerkingsvaardigheden moet hebben en moet uitblinken in cross-functional communicatie, omdat hij of zij centraal staat in het geheel.

Wat zijn de verschillende soorten vereisten? 

Er zijn drie hoofdtypen vereisten: bedrijfsvereisten, gebruikersvereisten en systeemvereisten. Het is belangrijk om de verschillende soorten vereisten te definiëren voordat het werk begint, omdat dit vaak de belanghebbenden bepaalt waarmee je moet samenwerken. 

Hier is een overzicht van de verschillende soorten vereisten: 

Bedrijfsvereisten

Bedrijfsvereisten zijn de overkoepelende bedrijfsdoelen of statistieken die je product dient. Ze zijn niet noodzakelijkerwijs iets wat het product moet doen, maar eerder dingen die je bedrijf moet doen om zowel interne als externe belanghebbenden tevreden te stellen. 

Stel je bijvoorbeeld voor dat je voor een online retailbedrijf werkt en je verkoopteam een inhoudbeheersysteem gebruikt om productpagina's op je website te maken en bij te werken. Om de toenemende inventaris te verwerken, verbetert je productteam de zoekfunctionaliteit binnen je CMS.

Het project van je productteam voldoet aan de volgende bedrijfsvereiste: schaal de productvoorraad met 50% in het eerste kwartaal. Om vereisten zoals deze in één georganiseerd formaat vast te leggen, kun je een document met bedrijfsvereisten gebruiken.

Gebruikersvereisten

Gebruikersvereisten bepalen wat gebruikers van je product nodig hebben en hoe ze ermee omgaan. Ze beschrijven een pijnpunt of een actie die de klant wil bereiken, plus hoe het product dat pijnpunt moet verlichten of de klant moet helpen de gewenste actie te bereiken.  

Agile teams formatteren gebruikersvereisten meestal als gebruikersverhalen, wat informele uitleg is van een softwarefunctie, geschreven vanuit het perspectief van een eindgebruiker. Gebruikersverhalen volgen meestal de indeling: "Als [persona] wil ik [softwaredoel], zodat [resultaat]." 

Laten we teruggaan naar het CMS-voorbeeld dat we hierboven hebben geschetst. Hier is een voorbeeld van een gebruikersverhaal geschreven vanuit het perspectief van de eindgebruiker - in dit geval een verkoopmedewerker die het CMS gebruikt om zijn taken uit te voeren. 

"Als verkoopmedewerker wil ik gemakkelijk specifieke productvermeldingen in ons CMS kunnen zoeken en vinden, zodat ik onze groeiende online inventaris kan bijwerken en beheren." 

Systeemvereisten

Systeemvereisten bepalen wat het product zal doen. Bekijk het zo: terwijl gebruikersvereisten het 'waarom' en 'wat' van productfuncties schetsen vanuit het perspectief van een gebruiker, definiëren systeemvereisten het 'hoe' van het bouwen van die functie vanuit het perspectief van het engineeringteam. 

Systeemvereisten worden vaak onderverdeeld in functionele vereisten en niet-functionele vereisten. Functionele vereisten bepalen wat het product zal doen, terwijl niet-functionele vereisten bepalen hoe goed het product zijn functies uitvoert. Dat betekent dat niet-functionele vereisten meestal te maken hebben met beveiliging, prestaties en betrouwbaarheid. 

Een engineeringteam kan bijvoorbeeld de bovenstaande CMS-gebruikersvereiste opsplitsen in systeemvereisten: 

Functionele vereisten

• Elke productvermelding slaat de volgende informatie op: producttype, aanmaakdatum, auteur, URL en publicatiestatus.

• Nieuwe producten kunnen niet worden gemaakt tenzij auteurs een producttype selecteren in een vervolgkeuzemenu. 

• De zoekbalk bevat een optie om de volgende extra filters toe te passen: producttype, aanmaakdatum, auteur, URL en publicatiestatus. 

• Er kunnen meerdere filters tegelijk worden geselecteerd. 

Niet-functionele vereisten

• Zoekresultaten worden in minder dan vijf seconden geretourneerd. 

• Zoekresultaten zijn 100% nauwkeurig. 

7 stappen van het vereistenbeheerproces

Vereistenbeheer hoeft niet overweldigend te zijn. Als je een gestandaardiseerd proces voor je team maakt, kun je elke keer dezelfde stappen volgen in plaats van je zorgen te maken over welke belanghebbenden je wanneer moet betrekken. 

Om je op weg te helpen, hebben we het proces vereenvoudigd tot zeven stappen. Als je eenmaal dingen hebt uitgeprobeerd en hebt geleerd wat voor je team werkt, kun je je vereistenbeheerproces dienovereenkomstig aanpassen. 

Stap 1: Ontwikkel een vereistenbeheerplan

Begin je project door een vereistenbeheerplan (RMP) te maken. Dit plan is je routekaart voor het omgaan met vereisten gedurende de levenscyclus van het project. Definieer in je RMP:

• Wie is er betrokken bij het verzamelen van vereisten?

• Hoe ga je vereisten verzamelen en documenteren?

• Wat is je proces voor het bijhouden van wijzigingen in vereisten?

• Hoe ga je het succes van het project verzekeren door het af te stemmen op de doelen?

Een goed RMP helpt je projectteam georganiseerd en afgestemd te blijven gedurende de hele ontwikkelingslevenscyclus.

Stap 2: Elicitatie en definitie van vereisten

Elicitatie omvat het verzamelen en definiëren van je projectvereisten. Het is een essentiële stap waarbij je contact legt met belanghebbenden en klanten om hun end-to-end behoeften te begrijpen.

Vereisten uitlokking

• Betrek belanghebbenden: ontmoet ze persoonlijk of communiceer asynchroon met belanghebbenden. Introduceer het product, de functie of het initiatief dat je maakt en vraag wat ze nodig hebben om klanten te helpen of hun bedrijfsdoelen te bereiken.

• Verzamel vereisten van eindgebruikers: voer indien mogelijk gebruikerstests uit. Raadpleeg in ieder geval je ontwikkelingsteam voor inzichten.

• Beheer verwachtingen: leg uit dat niet alle gevraagde vereisten noodzakelijkerwijs zullen worden geïmplementeerd. Verduidelijk dat dit een fase is waarin informatie wordt verzameld.

Definitie van vereisten

Het definiëren van je vereisten helpt bij het schetsen van alle componenten die je ontwikkelingsteam moet volbrengen om het initiatief of product te voltooien. 

• Schrijf duidelijke, specifieke vereisten op basis van verzamelde informatie.

• Maak use-cases om te laten zien hoe gebruikers met het eindproduct zullen omgaan.

• Zorg ervoor dat elke vereiste één specifieke behoefte of functie beschrijft.

Je kunt ook gebruikersverhalen maken voor elke vereiste om te verwoorden wat gebruikers nodig hebben en hoe ze zullen omgaan met je product of functie.

Vervolgens kun je die gebruikersvereisten opsplitsen in meer specifieke systeemvereisten. Het kan zijn dat je gaandeweg aanvullende informatie van belanghebbenden moet verzamelen om ervoor te zorgen dat je genoeg context hebt om elke vereiste te voltooien.

Onthoud dat je in deze fase van de workflow voor vereistenbeheer potentiële behoeften en vereisten verzamelt. Je team zal de belangrijkste prioriteren en selecteren om later in het vereistenbeheerproces na te streven.

Stap 3: Analyse en validatie van vereisten

Nu is het tijd om al die feedback te sorteren en te beslissen welke vereisten overeenkomen met je product- en bedrijfsdoelen. Uiteindelijk moet elke vereiste bijdragen aan een overkoepelend bedrijfsdoel, zoals het verhogen van de omzet, het uitbreiden naar nieuwe markten of het verbeteren van de klanttevredenheid. 

Validatie van vereisten omvat:

• Controleren of alle technische vereisten noodzakelijk en haalbaar zijn en niet met elkaar in tegenspraak zijn.

• Bevestigen dat de technische vereisten in overeenstemming zijn met de projectdoelen.

Valideer vervolgens de vereisten met belanghebbenden. Dit betekent controleren of de vereisten echt de end-to-end behoeften van belanghebbenden weerspiegelen.

Stap 4: Stel de basislijn voor vereisten vast

Zodra de vereisten zijn gevalideerd, stel je een basislijn vast. Documentatie in deze fase geeft een momentopname van alle goedgekeurde vereisten en biedt:

• Een startpunt voor je oplossing voor vereistenbeheer

• Een referentie voor toekomstige besluitvorming en het meten van veranderingen

Er is niet één vaste manier om vereisten te documenteren en bij te houden. Je productteam heeft in het verleden mogelijk een software requirements specification (SRS), product requirements document (PRD) of requirements traceability matrix (RTM) gebruikt. 

Maar om ervoor te zorgen dat je team realtime inzicht heeft in al je projectvereisten, kun je het beste een pojectbeheertool zoals Asana gebruiken. Dat betekent geen verouderde spreadsheets meer voor auditvereisten - in plaats daarvan kunnen zowel je team als belanghebbenden de meest actuele beschrijvingen van elke vereiste zien. Je kunt ook de status van elke vereiste bijhouden terwijl je aan je project werkt en zelfs automatiseringen instellen om belanghebbenden te waarschuwen wanneer er vooruitgang wordt geboekt.  

Je kunt Asana ook integreren met meer gespecialiseerde apps en tools voor vereistenbeheer zoals Jira en GitHub. Dit is vooral handig als je werkt met belanghebbenden die geen toestemming hebben om toegang te krijgen tot ontwikkelaarstools. 

Stap 5: Prioritering en Afhankelijkheden in kaart brengen

Nu je je reeks vereisten hebt opgeschreven, werk je samen met je team om prioriteiten te stellen en te plannen hoe je ze aanpakt. Met deze prioritering kun je de belangrijkste taken eerst aanpakken, vooral als ze andere taken blokkeren.

Identificeer in deze stap hoe vereisten zich tot elkaar verhouden. Dit proces, vaak traceerbaarheid genoemd, omvat:

• Gerelateerde vereisten koppelen

• Het koppelen van vereisten aan andere projectelementen zoals ontwerpdocumenten en testcases

Als je team Agile gebruikt, voeg je de vereisten toe aan je Product-backlog en organiseer je vervolgens een sprintplanningssessie om te beslissen welke taken je in je volgende sprint opneemt. Als je niet in sprints werkt, is dat prima - je kunt een projecttijdlijn maken om te bepalen wanneer elke vereiste moet worden voltooid en of er afhankelijkheden zijn. 

Stap 6: Wijzigingsbeheer, versiebeheer en impactanalyse

Vereistenbeheer gaat niet alleen over het plannen van vereisten voordat je project van start gaat, het gaat ook over het navigeren door veranderende vereisten in de loop van je project. Dat betekent dat je moet plannen hoe je extra taken kunt opnemen die van invloed zijn op je projectbereik. 

Naarmate je project vordert, kunnen de vereisten veranderen. Beheer deze wijzigingen door:

1. Een proces op te zetten voor het indienen en beoordelen van wijzigingsverzoeken

2. Te analyseren hoe elke voorgestelde wijziging andere vereisten en projectelementen kan beïnvloeden

3. Je basislijn bij te werken als wijzigingen worden goedgekeurd

Gebruik je afhankelijkhedenkaart om een impactanalyse uit te voeren. Dit helpt je de volledige impact van wijzigingen te begrijpen voordat je besluit ze te implementeren.

Een andere optie is om een wijzigingscontroleproces te maken. Dit biedt belanghebbenden een manier om nieuwe vereisten in te dienen die van invloed zijn op je projectbereik, en het bepaalt wie die aanvragen moet goedkeuren of weigeren.

Een goed gedefinieerd wijzigingsbeheerproces helpt je te begrijpen hoe je vereisten effectief kunt beheren terwijl je wijzigingen bijhoudt. 

Stap 7: Systeemverificatie en -validatie

Controleer in de laatste stap of je eindproduct aan alle technische vereisten voldoet:

• Verificatie: test elke functie om er zeker van te zijn dat deze werkt zoals gespecificeerd in de vereisten.

• Validatie: controleer met belanghebbenden of het product aan hun behoeften en verwachtingen voldoet.

Deze stap helpt je om eventuele problemen op te sporen voordat je het product afrondt, waardoor de behoefte aan kostbare herbewerking later wordt verminderd.

Overweeg tijdens dit proces het gebruik van vereistenbeheersoftware zoals Asana. Het kan dienen als een single source of truth, waarmee je vereisten kunt beheren, wijzigingen kunt bijhouden en rapporten en dashboards kunt genereren voor beter projectoverzicht.

Tools om vereistenbeheer te stroomlijnen

Vereistenbeheer heeft veel bewegende delen, maar het hoeft niet oncontroleerbaar te zijn. Met de juiste tools kun je een herhaalbaar proces opzetten dat precies uiteenzet met wie je moet praten, wanneer je het moet doen en hoe je vereisten kunt documenteren en organiseren gedurende de hele levenscyclus van het project. 

Als je vereisten bijhoudt in Asana, kun je een gestandaardiseerd sjabloon maken om je te helpen de vereisten voor elk project te beheren. Dat betekent dat je, in plaats van het proces elke keer opnieuw te starten, een vooraf gedefinieerde workflow kunt hergebruiken - en je kunt er zeker van zijn dat je geen kritieke onderdelen vergeet. 

Veelgestelde vragen: vereistenbeheer

Wat wordt er bedoeld met vereistenbeheer? Vereistenbeheer is het proces van het definiëren, bijhouden en controleren van projectvereisten gedurende de hele ontwikkelingslevenscyclus. Het zorgt ervoor dat alle belanghebbenden de projectbehoeften begrijpen en ermee akkoord gaan.

Wat is een vereistenbeheerplan? Een vereistenbeheerplan geeft aan hoe vereisten tijdens een project worden verzameld, bijgehouden en beheerd. Het dient als een gids voor het omgaan met wijzigingen, documentatie en communicatie.

Wat zijn de belangrijkste functies van het vereistenbeheerproces? De belangrijkste functies van het vereistenbeheerproces zijn het verzamelen van vereisten, het analyseren en valideren ervan, het bijhouden van wijzigingen en het waarborgen dat het eindproduct voldoet aan de overeengekomen vereisten.

Hoe ziet een goede vereiste eruit? Een goede vereiste is duidelijk, specifiek en meetbaar. Het moet gemakkelijk te begrijpen, testbaar en afgestemd zijn op de algemene Doelstellingen van het project.