Het proces van het verzamelen en analyseren van vereisten is een systematische identificatie, organisatie en documentatie van de zakelijke behoeften van de klant voor verder gebruik in IT-systemen of bedrijfsprocessen. De belangrijkste stappen zijn:
Identificatie van vereistenbronnen: interviews met klanten, werkgroepen, documentanalyse en huidige processen.
Verzameling van vereisten: gebruik van technische sessies (workshop), enquêtes, observaties, prototyping. Het is belangrijk om de betrokkenheid van alle stakeholders te waarborgen.
Analyse en categorisatie: identificatie van tegenstrijdigheden, dubbele taken, classificatie van vereisten in business/functionele/ niet-functionele.
Documentatie: formalisatie in de vorm van SRS (Specification Requirement Specification), user stories of scenario's.
Validatie en afstemming: het houden van reviews met de klant, aanbrengen van correcties, goedkeuring van de definitieve versie van de vereisten.
Belangrijke kenmerken:
Diepgaand begrip van bedrijfsprocessen is nodig voor een juiste interpretatie van de wensen van de klant.
Continue communicatie: vereistenverzameling is een iteratief proces, gerelateerd aan wijzigingen in de loop van het project.
Vereisten artefacten (diagrammen, modellen, specificaties) zijn cruciaal voor het verdere werk van het team.
Kan men zich beperken tot slechts één (bijvoorbeeld zakelijke of functionele) type vereisten?
Nee, de business analist moet alle types vereisten dekken: zakelijke, gebruikers-, functionele en niet-functionele. Anders loopt u het risico een product te krijgen dat niet voldoet aan de verwachtingen van alle stakeholders.
Is het altijd voldoende om slechts één sessie voor de vereistenverzameling te houden?
Nee, in de praktijk zijn er veel vereisten die geleidelijk en iteratief worden verduidelijkt. Gewoonlijk worden er meerdere sessies gehouden om alles correct te verzamelen en overeen te komen.
Kan men goedgekeurde vereisten wijzigen zonder formele procedures?
Nee, elke wijziging moet het change management proces doorlopen, anders ontstaat er chaos, inconsistenties en misverstanden tussen teams.
Bij de ontwikkeling van een analytische module voor een bank is in het begin slechts één workshop gehouden. Later bleek dat de functionaliteit de eisen van de afdeling informatiebeveiliging niet in acht nam, en het product moest aanzienlijk worden herzien, wat tijd en budget kostte.