Wat is het beheren van requirements?
Beheren van requirements betekent het op een gestructureerde manier vastleggen, beheren en onderhouden van requirements gedurende de hele levenscyclus van een project. Dit houdt in dat alle requirements een versie krijgen, een prioriteit toegekend krijgen en traceerbaar zijn naar de bijbehorende ontwerp- of implementatieonderdelen. Het doel is om overzicht te houden, consistentie te bewaken en flexibel om te gaan met veranderingen.
Casus
Stel je werkt aan een systeem voor een onderwijsinstelling waarin studenten zich kunnen inschrijven voor vakken. De requirements zijn verzameld in gesprekken met docenten, studenten en beheerders. Om ervoor te zorgen dat bij wijzigingen iedereen weet wat de impact is, worden de requirements opgeslagen in een requirements management tool. Elk requirement krijgt een unieke ID, een prioriteit (hoog, midden, laag), een versie (v1.0, v1.1, …) en wordt gekoppeld aan gerelateerde use cases, testgevallen en codeonderdelen.
Hoe zit het beheren van requirements in elkaar?
Een goed beheerde set requirements voldoet aan drie eigenschappen:
-
Versiebeheer:
Elk requirement wordt voorzien van een versienummer. Dit maakt het mogelijk om wijzigingen te volgen en te begrijpen waarom aanpassingen zijn gedaan. -
Prioritering:
Requirements worden geclassificeerd op basis van hun belang of urgentie. Een veelgebruikte methode is MoSCoW (Must, Should, Could, Won’t), maar ook numerieke ranking of releaseplanning komt voor. -
Traceerbaarheid:
Elk requirement is herleidbaar tot een oorsprong (bijvoorbeeld een stakeholderwens) en wordt gekoppeld aan onderdelen van het ontwerp, de implementatie en testgevallen. Dit maakt impactanalyse mogelijk bij veranderingen.
Voor het beheren wordt gebruikgemaakt van tooling zoals Jira, Azure DevOps of specifieke requirements management tools (bv. Jama, RequisitePro). Bij kleinere projecten kan een spreadsheet of eenvoudige backlogstructuur ook voldoen, mits goed onderhouden.
Hoe gebruik je het beheren van requirements?
Beheren van requirements wordt toegepast zodra de eerste versie van de requirements verzameld is. Tijdens het analyseren en specificeren worden de eigenschappen (versie, prioriteit, traceerbaarheid) vastgelegd. Tijdens het hele project moet deze structuur onderhouden worden.
Belangrijke toepassingen:
- Ondersteunt impactanalyse bij veranderingen.
- Zorgt voor consistentie tussen ontwerp, implementatie en testen.
- Vergemakkelijkt overdracht naar nieuwe teamleden.
- Stimuleert gestructureerde samenwerking tussen teamleden.
Casus
In een scrumproject wordt na iedere sprintreview geëvalueerd of nieuwe inzichten leiden tot aanpassing van requirements. Door gebruik te maken van versiebeheer en traceerbaarheid weet het team precies welke testgevallen en code moeten worden aangepast.
SCRUM
In SCRUM worden requirements beheerd via de Product Backlog. Deze backlog is dynamisch en groeit en verandert gedurende het project. Requirements worden vastgelegd als backlog items, meestal in de vorm van user stories, en krijgen een prioriteit die bepaald wordt door de Product Owner. Tijdens Backlog Refinement worden deze items verder uitgewerkt, gespecificeerd en voorbereid voor opname in een sprint.
Het beheren van requirements gebeurt binnen SCRUM iteratief: requirements worden op het juiste moment voorzien van extra details, acceptatiecriteria, en technische context. Dit maakt het proces flexibel en afgestemd op actuele inzichten.
SSDLC
Binnen de Secure Software Development Life Cycle (SSDLC) is het beheren van requirements een continue activiteit. Omdat veiligheid centraal staat, moeten requirements niet alleen functioneel maar ook op het gebied van security goed traceerbaar en beheersbaar zijn. Bij elke fase (van ontwerp tot testen) worden requirements getoetst op volledigheid en consistentie. Versiebeheer speelt een grote rol bij audits en compliance. Het beheren gebeurt doorgaans met gespecialiseerde tools die koppelingen naar ontwerp, test en risicoanalyse mogelijk maken. Requirements worden vaak al vroeg geclassificeerd als functioneel of niet-functioneel (zoals beveiligingseisen) en in detail vastgelegd voordat de bouw start.
Omgaan met grotere requirements
Voor grotere requirements – ook wel epics genoemd – is het gebruikelijk om deze op te splitsen in kleinere, uitvoerbare items. Deze worden vervolgens afzonderlijk beheerd, geprioriteerd en ingepland. Tijdens dit proces blijven de relaties met de oorspronkelijke epic behouden via hiërarchische structuur in tools zoals Jira of Azure DevOps.
Belangrijke aspecten bij het beheren van grotere requirements zijn:
- het bijhouden van de samenhang tussen de kleinere items en het grotere geheel
- het toevoegen van versiebeheer op het niveau van stories of epics als functionaliteiten evolueren
- en het zorgen voor traceerbaarheid naar ontwerpbeslissingen en testgevallen
Door in sprints iteratief te werken en tijdens elke sprintreview feedback te verzamelen, ontstaat een proces waarbij requirements continu geëvalueerd en geoptimaliseerd worden. Het beheren gebeurt dus niet eenmalig, maar is verweven met de dagelijkse praktijk van het team.
Deze aanpak maakt het mogelijk om zowel kleine als omvangrijke requirements beheersbaar te houden, afgestemd op de veranderende context en wensen van de stakeholders.
Volgende stap: Uitleg werking systeem