Het Functioneel ontwerp
De blauwdruk van maatwerk in de praktijk
Bij het implementeren van een technische oplossing doorlopen wij met u enkele verschillende fases om het project tot een succesvol einde te brengen. Het functioneel ontwerp is een analyse van uw wensen en eisen. De bedoeling hiervan is het uitzoeken wat de mogelijke opties en oplossingen zijn, zodat u in een vroege status van het project een duidelijkere zicht heeft op het eindproduct wat wij gaan realiseren en wij een duidelijker beeld hebben van uw probleem/wens.
A year from now you may wish you had started today.
Karen Lamb
Business goals en context analyse
De eerste stap van het functionele ontwerp bestaat uit het definiëren van de business goals en een context analyse. Met de business goals schrijven wij in korte zinnen uit wat uw doel of wens is van dit product. Wat u precies wil bereiken. Zo is het voor iedereen duidelijk wat de verwachtingen zijn.
Uit een context analyse komt naar voren wie en wat er van invloed is op uw systeem. De omgeving word in kaart gebracht en verdeeld in “domeinen” (systemen/omgevingen en externe applicaties) en 'actoren' (gebruikers/ beheerders/ klanten).
Deze analyse is belangrijk omdat vanuit het gedefinieerde business goal en de domeinen en actoren de functionaliteit word uitgewerkt. Een domein bakent het functionele gebied af waarin een actor actief kan zijn. Een actor representeert een rol of functie in de omgeving van het systeem die invoer geeft of uitvoer ontvangt.
Waar u hierbij op kunt letten is of wij alle type gebruikers (actoren) juist hebben gedefinieerd en of wij uw systeem in de juiste domeinen hebben
onderverdeeld.
Userstories
De tweede stap is vaststellen van de userstories. In de vorige stap is al reeds uitgezocht wat de wens is en welke actoren hieraan meewerken. Maar hoe de actors precies een business goal bereiken is nog onbekend. Om dit te achterhalen stellen wij een lijst van userstories op.
Een userstory toont een functionaliteit voor een actor voor een bepaald doel. Hierin worden dus de functionaliteiten benoemd, wat het systeem precies moet kunnen en welke resultaat het de gebruiker moet bieden. Een userstory wordt over het algemeen geschreven in de vorm van “Als een … wil ik ... zodat ik ...”.
Waar u met name op moet letten is of u alle opties en handelingen die u wilt aanbieden aan de gebruikers van uw systeem terug ziet.
Scenarios & acceptatie criteria
Als derde en laatste stap binnen het functionele ontwerp gaan wij kijken wat de acceptatie criteria en de scenarios zijn van de reeds eerder gedefinieerde userstories. Nadat wij hebben vastgesteld wat een actor moet kunnen doen via de userstory, gaan wij vervolgens uitzoeken hoe de actor dit gaat doen. Per userstory werken wij dan alle mogelijke scenarios uit. Dit is een lijst van achtereenvolgende interacties tussen de actor en het systeem.
Daarnaast houden wij in zo'n scenario ook rekenening met de gewenste acceptatie criteria. Dit zijn de randvoorwaarden of spelregels die van belang zijn bij een userstory. Bijvoorbeeld bij een userstory over bestellen de regel "Gebruiker mag maximaal 3 x per dag bestellen".
Deze gehele stap herhaalt zich iedere iteratie weer voor de applicatie. Elke iteratie bekijken we met u de lijst of alle scenarios en criteria nog kloppen of dat er aanpassingen nodig zijn omdat uw wensen zijn verschoven.
Het bepalen van de scenarios en criteria is niet eenvoudig en soms zijn nog niet alle fijne details voor u bekend. Met behulp van screenshots en demo's proberen wij verschillende mogelijkheden duidelijk te maken.