Je doel is om aan je klanten een product af te leveren dat volledig aan hun wensen voldoet. Daarom is het belangrijk om de requirements vast te leggen, zodat alle teamleden op dezelfde lijn zitten en naar hetzelfde eindresultaat toewerken. Doe dit aan het begin van het project om onverwachte kosten te vermijden. Het zijn veelal de niet-functionele requierements die het kostenplaatje de hoogte in drijven, maar te weinig van deze requirements leidt tot een slechte user experience. Daarom leggen we uit wat precies het verschil is, en hoe je goede requirements opstelt.
Wat is een functionele requirement?
De functionele requirements definiëren het basissysteem, en bepalen dus wat het systeem wel en niet zal doen. Het gaat hier over hoe het systeem reageert op input, wat in de praktijk vaak neerkomt op ‘als… dan…’ situaties, zoals berekeningen, het invoeren van gegevens en business processen. Functionele requirements zorgen er dus voor dat het systeem doet wat het moet doen. Ze niet uitvoeren, zou ervoor zorgen dat het systeem niet werkt. De focus ligt hier op wat de gebruiker wilt bereiken.
Wat is een niet-functionele requirement?
Terwijl functionele requirements bepalen wát het systeem doet, leggen de niet-functionele vast hóé ze dat doen. Deze laatste zijn dan niet-functioneel omdat ze geen invloed hebben op wat het systeem wel of niet kan uitvoeren. Zonder niet-functionele requirements krijg je een systeem dat werkt, maar het zal niet werken op de manier waarop de gebruiker dat wilt. Dit heeft dus alles te maken met gebruiksvriendelijkheid. Het gaat om de producteigenschappen en om de verwachtingen van de gebruiker. Een goed voorbeeld is het klikken op een knop op een website. Functioneel gezien is de enige eis dat er zich een nieuwe pagina opent. Aan de niet-functionele kant is het belangrijk dat deze pagina snel genoeg laadt. Duurt dit te lang, dan duikt de user experience de dieperik in.
Hoe bepaal je de requirements?
Het is een goed idee om de stakeholders bij elkaar te roepen voor een brainstorm, maar nodig zeker ook leden van de doelgroep uit. Als stakeholders niet de toekomstige gebruikers zijn, zullen ze niet zo goed weten wat de gebruikersnoden zijn. Om de niet-functionele requirements te definiëren ben je dus veelal afhankelijk van je doelpubliek.
Tijdens de brainstorm kan je vier soorten functionele requirements overlopen. De eerste groep zijn de business requirements. Hier gaat het om het hoofddoel, zoals bijvoorbeeld een online catalogus, een webshop of een nieuw product. Dit omvat ook de work flow, en afstemmen wie de goedkeuringen geeft. Daarnaast heb je de administratieve functies voor routineklussen die het systeem zal uitvoeren, zoals verslaggeving. Vervolgens moet je de user requirements vastleggen. Dit zijn zaken die de gebruiker moet kunnen uitvoeren in het systeem, zoals bijvoorbeeld een online aankoop doen. Tot slot bekijk je de requirements van het systeem zelf. Je bepaalt de specificaties in verband met hardware en software, en wat de acties en reacties zijn van het systeem.
Vervolgens is het de beurt aan de niet-functionele requirements, en ook deze kan je in groepen onderverdelen. De eerste soort gaat om gebruiksvriendelijkheid. Hier ligt de focus op het ontwerp van de interface. Is alles goed leesbaar? Zijn de knoppen groot genoeg? Vervolgens gaat het om de beschikbaarheid van het systeem. Moet dat 24/7 zijn? Een derde groep requirements draait om het schaalbaar maken van het systeem. Moet er ruimte voorzien worden om te groeien? Denk hierbij ook aan fysieke ruimte als het gaat om hardware. Een volgende groep focust op prestatievermogen, de snelheid van het systeem dus. Ook de technische ondersteuning van het systeem is iets waar je over moet nadenken. Gaat dat binnenshuis gebeuren, of moet er toegang vanop afstand voorzien worden voor eventuele externe ondersteuning? Tot slot is ook de beveiliging een belangrijk punt. Zowel de fysieke installatie als de online gegevens moeten voldoende beschermd zijn.
Het requirements specification document
Dit is een veelgebruikte manier om de requirements op te lijsten. Je begint met het doel en een kort overzicht van het project om de requirements context te geven, alsook mogelijke beperkingen en veronderstellingen. Requirements zijn narratief natuurlijk, maar het helpt om ze ook visueel weer te geven. Ook collega’s die minder technisch aangelegd zijn, moeten de requirements goed kunnen begrijpen.
Verder zijn er nog drie manieren om je requirements te ondersteunen. De eerste is een work breakdown strusture (WBS) opstellen. Hierin deel je het proces op door de requirements op te splitsen in de kleinst mogelijke elementen, met een duidelijke takenlijst als gevolg. Ook nuttig is het schrijven van user stories. Hierin beschrijf je hoe het systeem werkt vanuit het standpunt van de gebruiker, rekening houdend met de wensen van deze specifieke gebruiker. Een laatste ondersteunende methode is het uitdenken van een use case. Dit lijst stap per stap op wat een gebruiker moet doen om een bepaald doel te bereiken, zoals bijvoorbeeld een online bestelling plaatsen.
Voorbeelden van functionele en niet-functionele requirements
Natuurlijk bestaan er ook grijze zones, maar aan de hand van deze voorbeelden wordt het verschil tussen functioneel en niet-functioneel snel duidelijk. Voorbeelden van functionele requirements zijn een automatische back-up van de database om de 24u, het automatisch uitprinten van de bestellijst om de 4u, dagelijkse probleemrapportering op een vast tijdstip, en dat alleen managers toegang hebben tot klantgegevens. Anderszijds zijn niet-functionele requirements het naleven van GDPR-normen, profielgegevens in drie klikken kunnen bereiken, pagina’s in 4 seconden laden, 3 miljoen gebruikers accomoderen, de achtergrondkleur…
In de praktijk staat er vaak een niet-functionele tegenover een functionele requirement. Denk hierbij aan het wat en hoe van het hele gebeuren. Bijvoorbeeld, een welkomstmail sturen bij het creëren van een nieuw account is functioneel, terwijl het verzenden van die mail binnen de 10 minuten niet-functioneel is. Een andere functionele requirement is dat na een afgeronde bestelling de printer het verzendadres uitprint. Daartegenover staan de niet-functionele requirements over de afmetingen van het label en op welk papier het geprint wordt.
Best practices
In welke vorm dan ook, requirements moeten makkelijk begrijpbaar en duidelijk zijn. Ze neerschrijven in dagdagelijkse taal is dan ook een goed begin. Geef ook de voorkeur aan actieve woordvormen. Ervoor zorgen dat er zich in elke zin een agent bevindt, maakt het korter en daadkrachtiger. Wees ook kordaat in je formuleringen. Gebruik ‘moeten’ in plaats van ‘zou moeten’, zodat er geen discussie mogelijk is. Een ander voorbeeld is om niet simpelweg te noteren dat een pagina ‘snel’ moet laden, maar plak er effectief een aantal seconden op. Verder is het belangrijk om consistent te zijn in terminologie. Gebruik dus altijd dezelfde benaming voor processen, fases, onderdelen…
Een tweede aspect waar je op moet letten, is dat het mogelijk moet zijn om requirements te testen. Hiervoor is het belangrijk dat je requirements slechts één eis bevatten. Dat maakt het overzichtelijker tijdens de testfase.
Ten derde is het van belang om elk mogelijk scenario op te nemen in je requirements. Dat houdt ook in wat het systeem niet zal doen. Blijf wel focussen op de eigenschappen die cruciaal zijn voor de gebruiker. Te veel requirements leidt tot een hogere kost, minder impact en een opgeblazen product. Gebruiksvriendelijkheid blijft belangrijk. Een goede maatstaf is om na te gaan of een requirement bijdraagt aan een van de vooropgestelde projectdoelen.
Een vierde aandachtspunt is om het totaalbeeld in de gaten te houden tijdens de brainstorm. Probeer te begrijpen waar de requirements van stakeholders en leden van de doelgroep vandaan komen en hoe ze linken met de doelen. Wat proberen zij te bereiken? Het kan zijn dat ze een oplossing aanreiken voor een probleem, maar het kan nuttiger zijn om eerst het probleem te delen met de groep. Zo kunnen er meerdere oplossingen voorgesteld worden tijdens de brainstorm, om dan samen tot het beste resultaat te komen. Houd ook bij welke requirement van wie kwam. Je begrijpt dat je ook met de autoriteit van je collega’s moet rekening houden. Een verzoek van je projectmanager kan je niet zomaar negeren natuurlijk. Zorg er tot slot voor dat je definitieve requirements haalbaar zijn en dat ze mekaar niet tegenspreken. Onthoud, niet-functionele requirements zijn ook belangrijk. Een website die er 30 seconden over doet om te laden kan aan alle functionele requirements voldoen, maar is toch niet bruikbaar.
Bron: www.qracorp.com
Zin in meer?
Wil je graag een grondige kennis van functionele analyse opbouwen? Ervoor zorgen dat requirements niet langer geheimen hebben voor jou? En ook meteen in de praktijk aan de slag gaan? Dan is de opleiding Functionele analyse zeker iets voor jou!
