Requirements vaststellen in 5 stappen

Voor we een SaaS oplossing selecteren moeten we eerst bepalen wat we eigenlijk voor software nodig hebben. Daarom beginnen we met het vaststellen van de requirements. Maar hoe doen we dat eigenlijk? Deze 5 overzichtelijke stappen lijken een eenvoudige aanpak, maar vergis je niet, de omvang kan complex en overweldigend zijn. Het ‘Vaststellen van requirements’ bevat de volgende activiteiten:

Activiteiten vaststellen requirements

1. Verzamel bestaande informatie.
2. Breng structuur aan.
3. Verzamel nieuwe informatie & leg vast.
4. Check op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid.
5. Evalueer & maak definitief.

Deze activiteiten vallen doorgaans in het takenpakket van een informatieanalist.

Activiteit 1: Verzamel bestaande informatie

Een deel van de informatie die we nodig hebben is aanwezig in het projectplan:

• Lijst met projectaannames.
• Doelstelling en resultaat.
• Afbakening / scope in het projectplan.
• Communicatieplan.

We halen één of meerdere business requirements uit bovenstaande informatie. Deze verifiëren we namelijk nogmaals bij opdrachtgever en management. Vullen deze aan of delen ze op in meerdere business requirements als dat mogelijk is.
In de loop van deze activiteit is het ook mogelijk dat er user requirements worden neergelegd die niet naar een business requirement zijn te herleiden. Dan is het wenselijk om te bespreken of we de business requirements moeten aanvullen. Deze activiteit is dus van belang om consistentie van de requirements te bereiken.

Activiteit 2: Breng structuur aan in de requirements

Om straks een helder overzicht te hebben en te houden van de verzamelde requirements is het eveneens van belang om ze goed te documenteren. Daarom zorgen we ervoor dat we de eisen van de business, user en system gescheiden opslaan.
We leggen minimaal onderstaande gegevens vast:

• Volgnummer van de requirement.
• Soort requirement (business, user, software).
• Categorie (functioneel – niet functioneel).
• Datum, versie, auteur.
• Bron (dit kunnen meerdere belanghebbende betreffen).
• Moment (Moment in het project waarin de eis is geformuleerd).
• Beschrijving requirement.
• Prioriteit (eis, wens).
• Verwijzing naar het volgnummer van de betrokken business requirement.
• Verwijzing naar het volgnummer van de betrokken user requirement.

De belanghebbenden van dit project zijn gedefinieerd in het communicatieplan. Daar maken we gebruik van. We verzamelen deze groep en documenteren ze bovendien apart in een document ‘Stakeholders’ waarbij we de volgende rubrieken minimaal opnemen:

• Naam, afdeling, telefoonnummer.
• Soort belanghebbende (gebruiker, super gebruikers, beheerder, beslisser, materiedeskundige).

Activiteit 3: Verzamel nieuwe informatie & vaststellen

De informatie die in het projectplan is opgenomen is voldoende om een begin te maken aan de business requirements, dit is vaak niet specifiek genoeg, vul deze als mogelijk verder aan.
Dan zijn de user & software requirements aan de beurt. Deels kunnen we deze uit de lijst met projectaannames halen, maar verdere specificering is in deze fase heel belangrijk.

Vaststellen requirements, hoe gaan we te werk?

Er zijn afhankelijk van de projectomvang een aantal methode om deze informatie boven tafel te krijgen.

• Analyseer het proces dat met de software (SaaS of on premise) moet worden ondersteund.
• Wat doet de huidige software? D.w.z. de software pakket(ten) en SaaS toepassing(en) die we moeten vervangen.
• Interview de gebruikers, beheerders (zowel functioneel als technisch) en de systeem/proces eigenaar.
• Interview ook de overige belanghebbende.
• Gebruik bijvoorbeeld e-mail om bepaalde vragen breed uit te zetten.
• Organiseer een requirementsworkshop.
• Tenslotte, informeer en ga langs bij zusterorganisaties die voor hetzelfde doel een oplossing/systeem hebben draaien.

Voor elke requirement moeten we bovendien kunnen vaststellen dat deze specifiek, meetbaar en ondubbelzinnig is. Denk aan de condities die vervuld moeten zijn om aan te tonen dat de eis is gehaald. Zorg dat de de eisen zo zijn beschreven dat iedereen er dezelfde betekenis aan geeft. Voor elke requirement moeten we namelijk weten welke waarde de klant/business er aan toekent om vast te stellen waar hij zonder kan en welke absoluut noodzakelijk zijn.

Use cases

Soms kan het verhelderend zijn om requirements schematisch weer te geven. Hiervoor kunnen we gebruik maken van use cases. Het is ook een manier om het overzicht te bewaren.

Activiteit 4: Check op consistentie, volledigheid, juistheid, prioriteit en haalbaarheid

We valideren onze verzamelde requirements regelmatig. Daarbij kunnen we de volgende vragen stellen.

• Is deze eis te herleiden naar een business requirement? Zo nee, dan is dit geen eis, of moet er een business requirement worden toegevoegd.
• Is de eis (of zijn de eisen) juist en volledig? Dit kunnen we bijvoorbeeld onderzoeken door andere belanghebbende te bevragen over dit onderwerp.
• Wat is de prioriteit van deze requirement? Is er sprake van een harde eis of een wens?
• Is de eis haalbaar. Dit kunnen we zowel vanuit een technisch- of financieel oogpunt benaderen.

Afhankelijk van de uitkomst kan het zijn dat we sommige eisen laten vervallen of aanpassen.
Er bestaan tevens checklists die we kunnen gebruiken voor specifieke requirements. Zie hiervoor deze links.

Activiteit 5: Evalueer het vaststellen van de requirements

In het projectplan staat wie zijn aangesteld om de requirements te beoordelen. Verspreid de concept documenten dus onder de reviewers en iedereen die betrokken is geweest bij het verzamelen van de requirements. Men krijgt ruim de tijd voor de beoordeling en verzamel later de opmerkingen en vragen. Zorg dus dat deze allemaal zorgvuldig worden bekeken en voer eventuele wijzigingen door. Communiceer de aanpassing en maak vervolgens de documenten definitief. Zo ronden we het vaststellen van de requirements af.

Discussieer mee op LinkedIn.