In deze blog leggen we uit hoe je een requirementsdocument op kunt stellen door middel van use-cases.
De grootste uitdaging bij innovatieve webapplicaties is om het gehele traject voorspelbaar te maken. Je klant wil weten waar hij aan toe is op het gebied van planning en kosten en intern wil je organisatie vooraf zo goed mogelijk weten welke resources beschikbaar moeten zijn om een project tot een succesvol einde te brengen. De eerste stap die je moet nemen om het project voorspelbaar te maken is om het met je klant eens te worden wat de omvang (scope) van het project is. Een requirementsdocument is hierbij een nuttig hulpmiddel. In dit requirementsdocument schrijf je, in voor alle betrokken partijen begrijpelijke taal, de eisen en wensen waaraan het opgeleverde product moet gaan voldoen.
Als projectmanager van een omvangrijk project heb je het misschien wel eens meegemaakt dat de gerealiseerde functionaliteit niet helemaal voldeed aan wat de klant verwacht had of dat de het budget achteraf niet toereikend bleek. Dit heeft allemaal te maken met het beheren van verwachtingen; de visie die je klant heeft moet overeenkomen met de invulling die je projectteam in gedachten heeft. Je klant wil graag vooraf weten welke functionaliteit er in het eindresultaat opgeleverd wordt en wat het benodigde budget gaat zijn. Het requirementsdocument helpt alle partijen om de verwachtingen vooraf op een lijn te krijgen.
Er zijn verschillende manieren om een requirementsdocument te schrijven. De methode die ik in dit artikel belicht is de use-case methode. Een use-case is het beschrijven van het gedrag van een systeem. Je beschrijft dus het gewenste resultaat eventueel aangevuld met een scenario dat de stappen richting het resultaat beschrijft.
Tip 1: Breng een duidelijke structuur aan in je requirementsdocument
De requirements van een webapplicatie zijn, voor iemand die niet thuis is in de ontwikkeling van webapplicaties, vaak complex. Zorg ervoor dat je klant zijn weg kan vinden in het document. Maak een duidelijke inhoudsopgave en zorg dat elk onderdeel binnen je requirementsdocument een vaste structuur heeft. De gewenste functionaliteit van de applicatie kun beschrijven door middel van use cases.
“De use-case beschrijft wie met het betreffende systeem wat kan doen.” Bron https://nl.wikipedia.org/wiki/Use_case
Een use-case heeft binnen een requirementsdocument altijd een vaste structuur.
De onderdelen van de use-case kunnen afhankelijk van de situatie verschillend zijn. Er zijn wellicht use-cases die geen scenario behoeven, bijvoorbeeld een use-case met maar een stap. In sommige gevallen is het ook wenselijk om nog aanvullende technische achtergrondinformatie te geven, bijvoorbeeld bij use-cases met technische randvoorwaarden zoals een synchronisatie met een ERP-systeem. Het is zaak dat de use-case dusdanig geformuleerd is dat jij en je klant begrijpen wat er beschreven wordt.
Tip 2: Houd je use-cases kort
Wanneer er in de omschrijvingen van je use-cases termen als ‘en’/’of’ voorkomen is dit vaak een teken dat je meerdere functionaliteiten in een use-cases probeert te omschrijven. Bijvoorbeeld “Een klant in de webshop moet binnen de webshopcategorieën kunnen filteren op prijs en kunnen sorteren op prijs.” Technisch gezien zijn dit twee volledig verschillende functionaliteiten. Splits ze dan op in afzonderlijke use-cases.
Tip 3: Gebruik heldere taal
Het requirementsdocument schrijf je primair voor je klant. Je klant moet begrijpen wat de functionaliteit, die je omschrijft in het requirementsdocument, inhoudt. Zorg er voor dat je geen subjectieve termen gebruikt zoals bijvoorbeeld ‘eenvoudig’ en ‘gebruiksvriendelijk’. Dit laat teveel open voor interpretatie. Een voorbeeld waar ik tegenaan ben gelopen is: “De beheerders van het systeem moeten eenvoudig orders kunnen afhandelen”, elke gebruiker heeft een ander beeld bij eenvoudig. Probeer in dit geval te omschrijven hoe een ‘eenvoudig’ orderproces er uit ziet.
Gebruik zo min mogelijk technische termen. Indien je technische termen gebruikt, neem ze dan op in een verklarende woordenlijst. Het vermijden van technische termen voorkomt ook dat je in de requirementsfase de oplossing van een probleem reeds probeert te omschrijven.
Wees consistent in je woordgebruik om de noodzaak van verschillende requirements te omschrijven. Bijvoorbeeld “Onderdeel X moet Y kunnen doen”, “Onderdeel X zou Y moeten kunnen doen”, “Het is wenselijk dat onderdeel X Y kan doen.” zijn drie verschillende formuleringen die een nuanceverschil in prioritering hebben. Zorg ervoor dat je dit consequent in je omschrijvingen doorvoert.
Tip 4: Prioriteer je use-cases
Zorg voor een duidelijke prioritering van je use-cases. Je kunt hierin onderscheid maken tussen:
- “Must have”, dit is functionaliteit die noodzakelijk is voor de correcte werking van de applicatie;
- “Should have”, dit is functionaliteit die niet strikt noodzakelijk is voor de correcte werking van je applicatie, maar wellicht wel van belang voor een significant deel van de toekomstige gebruikers. Deze functionaliteit kan in een later stadium toegevoegd worden;
- “Could have”, dit is functionaliteit die niet noodzakelijk is, maar wel meerwaarde aan een aantal toekomstige gebruikers kan leveren;
- “Won’t have”, dit is functionaliteit die wellicht in de toekomst van waarde kan zijn voor een deel van de gebruikers, maar in deze fase nog niet relevant is.
De prioriteiten van de functionaliteit bepaal je samen met je opdrachtgever. De opdrachtgever kan namelijk het beste de impact bepalen die de functionaliteit op zijn business heeft. In de praktijk heb ik vaak gezien dat prioriteiten verschuiven wanneer er een prijskaartje aan gehangen wordt 😉
Tip 5: Zorg voor toetsbare requirements
Zorg ervoor dat je use-cases dusdanig geformuleerd zijn dat ze toetsbaar zijn. Dit voorkomt misverstanden over de te implementeren functionaliteit. Doordat de requirements toetsbaar zijn wordt je requirementsdocument tevens de checklist voor de oplevering van de webapplicatie. In bijvoorbeeld een use-case van een checkout in een webshop kun je de volgende omschrijving tegenkomen: “De klant selecteert een betaalmethode en rekent de bestelling af”, deze omschrijving laat te veel open voor interpretatie. Een betere formulering zou zijn: “De klant maakt bij de betaalmethoden de keuze uit iDeal, MisterCash of creditcard en wordt vervolgens doorgestuurd naar het portaal van de betaalprovider om daar de betaling van zijn bestelling verder af te handelen.”
Tip 6: Schrijf haalbare requirements
De use-cases in je requirementsdocument dienen het doel om de implementatie van een applicatie zo voorspelbaar mogelijk te maken. Alle requirements moeten dan ook passen in in de planning, het budget en aanvaardbare risico’s van de klant en het project.
Algemene tips
Als afsluiting nog enkele algemene tips:
- Je requirementsdocument schrijf je primair voor je klant. Zorg ervoor dat je klant het document begrijpt.
- Je requirementsdocument kan ook de basis zijn voor een offerteaanvraag bij andere partijen. Zorg er dus voor dat de beschreven functionaliteit zo algemeen mogelijk beschreven is en niet gericht op de voor jou meest gangbare oplossing.
- Laat je klant het requirementsdocument officieel goedkeuren voordat je met de implementatie begint.
- Wanneer je voorafgaande aan het requirementsdocument aan je klant een prijsindicatie voor de uitvoering hebt gegeven, toets deze na goedkeuring van het requirementsdocument.
- Wanneer tijdens het implementatietraject van de webapplicatie extra functionaliteit vereist zijn die niet in het requirementsdocument omschreven zijn, dan is het waarschijnlijk dat je hiermee geen rekening hebt gehouden in je oorspronkelijke prijsindicatie. Overleg met je klant hoe je hiermee om wilt gaan.
