Het belang van een goede functionele analyse
Voordat je aannemer aan je huis begint, ga je eerst langs een architect. Waarom eigenlijk? Aannemers bouwen toch ook zonder architect een rechte muur? Maar een architect ontwerpt de bijbel van je bouw: de blauwdruk.
Dat is bij een software-oplossing niet anders. UX-designers en developers werken het best als er een blauwdruk van het project is omschreven. In IT-taal noemen we dat een ‘functionele analyse.’
Vaak weten bedrijven in vage lijnen welk resultaat ze willen. Maar bevatten welke complexiteit en reikwijdte dat resultaat met zich meebrengt, is van een andere orde.
Het resultaat? De uiteindelijke oplossing laat te wensen over. Bovendien vreet het zo onnodig veel tijd of budget. Door te weinig input van gebruikers of continu veranderende eisen van stakeholders stranden veel IT-projecten in niemandsland.
Terwijl je dit alles kan vermijden.
Wil je dat het resultaat een succes wordt? Laat dan ook een functionele analyse opstellen. Een functioneel analist onderzoekt eerst jouw huidige situatie. Daarna analyseert zij jouw gewenste resultaat. Met Epics, Use Cases en User Storiers - waarover later meer - giet ze alles in een gestructureerd document. Deze kleine moeite vooraf zorgt voor minder inspanningen later. Want:
Onmisbaar dus voor ontwikkelaars én klanten, die zo met hun neuzen in dezelfde richting werken.
Een goede analyse begint dus steeds bij het verzamelen van input. Met onder andere briefings, brainstormsessies, workshops en verschillende soorten (diepte)interviews kan een analyst samen met de klant de reikwijdte omlijnen en requirements beschrijven.
In deze fase is het belangrijk om voldoende stakeholders aan bod te laten komen. De requirements van het project kunnen wel eens verschillen naargelang de stakeholder en gebruiker in kwestie. Vervolgens beschrijft de functioneel analist zowel de functionele en niet-functionele requirements.
De functionele requirements bepalen wat het nieuwe systeem al dan niet moet kunnen. De niet-functionele beschrijven hoe het dat doet.
Zonder niet-functionele requirements krijg je een systeem dat mogelijks werkt, maar de gebruikerservaring laat dan mogelijk wat te wensen over. Een simpel maar goed voorbeeld is het klikken op een knop op een website. Functioneel gezien wil je gewoon dat een nieuwe pagina opent. Maar je wilt ook dat de pagina snel laadt. Duurt dit te lang, dan haak je af. Dit is de niet-functionele requirement.
Het doel van een functionele analyse is een leidraad zijn naar het uiteindelijke resultaat en tegelijkertijd een checklist zijn van alle to-do's. Een droge lijst van alle stakeholders en requirements vormt op zich dus nog geen goede analyse.
Een functioneel analist werkt de requirements verder uit totdat veronderstellingen en verschillende interpretaties geen schijn van kans maken. Om dit op een efficiënte manier te doen, gebruikt hij epics, user stories en use cases binnen een agile framework.
Een epic is een verzameling van een gote hoeveelheid kleinere opdrachten die opgedeeld worden in verschillende specifieke taken. Deze taken of user stories zijn gewoonlijk beknopt geschreven met maar net genoeg informatie om de developer te laten begrijpen wat de software moet doen. Bijvoorbeeld: Een gebruiker surft naar de website en wisselt van taal via de language switcher.
Use cases daarentegen beschrijven het volledige gedrag van de user en de gewenste functionaliteiten en geven zo een duidelijker antwoord op vragen als wie, wat en hoe. Dat kan soms zo ver gaan dat zelfs de bewegingen met de muis beschreven wordt.
Een goede onderzoeksfase, met aandacht voor gebruikers en stakeholders, vormt samen met een gedetailleerde beschrijving van alle requirements en functionaliteiten dus de ruggengraat van elke functionele analyse.
Zoals steeds geldt: goed begonnen is half gewonnen. Wil je het project vanaf de eerste keer laten slagen? Dan geven we je volgende doorslaggevende tip. Laat een functioneel analist vanaf het begin deelnemen aan alle gesprekken. Het zal alles ontwikkelen enkel maar makkelijker maken.