Een functioneel ontwerp is een ontwerp waar in staat beschreven hoe de applicatie eruit komt te zien. Dit ontwerp moet zodanig geschreven worden dat de klant dit document begrijpt. Wat daarmee bedoeld wordt is dat het ontwerp niet te technisch moet zijn. Het technische gedeelte kan je ontwerpen in een technisch ontwerp, deze is meer voor andere ontwikkelaars bedoeld. In deze blogpost gaan we het hebben over het functioneel ontwerp, ook wel FO genoemd.

Een functioneel ontwerp bestaat uit verschillende onderdelen. Ik ga het in deze blogpost hebben over de onderwerpen die ik geleerd heb op school. Dit zijn: eisen en wensen, relevante schema’s, interfaces. Dit zijn die drie onderwerpen die ik het belangrijkste vindt in een FO. Je kan hier nog veel meer inzetten zoals: use-case model, sequence diagram, gegevens in- en uitvoer, etc. Deze zal ik een in andere blogpost bespreken, mits deze komt.

Een FO is dus een document waar deze verschillende onderwerpen in besproken worden. Het doel van een FO is het in kaart brengen van de gewenste applicatie('s). Samen met de klant ga je bespreken hoe hij of zij de applicatie graag wil hebben. Hier maak je een FO van en deze laat je door de klant goedkeuren. Als de klant het FO goedgekeurd heeft weet jij precies wat je moet gaan maken, er zijn dan afspraken gemaakt hoe de applicatie er uit komt te zien en wat deze qua functionaliteit allemaal heeft.

Eisen en wensen

De eisen en wensen wil zeggen de eisen die de klant aan zijn applicatie stelt en de wensen die hij in zijn applicatie wil hebben (prioriteiten stellen).

De eisen en wensen kan je het best in kaart brengen door middel van een MoSCoW ontwerp.

• Must have (dit zijn punten die de applicatie MOET hebben, zonder deze punten kan de applicatie niet goedgekeurd worden voor gebruik/innamen)
• Should have (dit zijn punten die erin moet komen maar als ze er niet in zitten kan de applicatie nog wel in gebruik genomen worden)
• Could have (dit zijn punten die er alleen in hoeven te komen als alle must's en should's erin zitten en er tijd over is)
• Won't have (dit zijn punten die nu niet aanbod komen, maar in een vervolgproject wel interessant kunnen zijn)

Zoals je kan zien hebben de letters 'o' geen betekenis. Deze zitten erin om de afkorting makkelijker te onthouden.

Een project wordt als faalt gezien als niet alle must have's in de applicatie zitten (wat al bij de beschrijving stond).

Relevante schema's

Een relevant schema, ook wel stroomdiagram (flowchart in het Engels) genoemd, is een schets van de processen. Je maakt een schets hoe je van A naar B komt met de bijbehorende zijpaden. Neem als voorbeeld inloggen; het is niet alleen op een knopje drukken en inloggen maar. Er zit een heel proces achter. Deze schets je in een flowchart. Hier een voorbeeld (gemaakt in Microsoft Visio 2013).

Dit is een klein voorbeeld van een inlog proces, deze kan nog uitgebreider natuurlijk. De rechthoek met de ronden hoeken wil het begin/einde van het proces aanduiden, het vierkant/rechthoek wil een proces/handelingen aanduiden en de ruit wil een beslissingen van het proces/handeling aanduiden. Een applicatie heeft heel veel verschillende processen. Daarom moet je ook alleen de belangrijke processen beschrijven. Ik zou ook nooit in een FO een flowchart maken van een inlog proces. Dit spreekt bijna altijd wel voor zichzelf en is niet belangrijk voor de klant.

Interfaces

Bij het onderwerp interfaces maak je ruwe schetsen van de GUI (Grafische gebruikersomgeving). Zo krijgt de klant een idee van hoe zijn applicatie en ongeveer komt uit te zien. Wijk daarom nooit af van de schetsen die je gemaakt hebt met je applicatie zonder dit te overleggen met de klant. Dit kan anders voor problemen en teleurstellingen bij klanten veroorzaken.

Voor interface schetsen gebruik ik meestal het programma Balsamiq Mockups. Deze schetsen komen er dan ongeveer zo uit te zien.

Dit is een schets van een C# applicatie. Je kan natuurlijk ook voor bijvoorbeeld webapplicatie ‘s schetsen maken. Het besten is om je schets zo uitgebreid mogelijk te maken. Ook niet van een pagina, maar van meerdere pagina's.

Conclusie

Een FO is voor bijna elke project onmisbaar. Het brengt de applicatie goed in kaart en je geeft de klant al een voorproefje van de applicatie. Ook kan de klant meteen zeggen of hij/zij dingen anders wilt. Zorg dus pas dat je begint met bouwen van de applicatie als het FO goedgekeurd is door de klant. Dit zorgt er voor dat je geen overbodig werk doet en dus sneller en effectiever te werk gaat!

Extra

Ik heb een klein FO van een boekingsapplicatie die ik ooit voor een schooltoets moest maken als bijlage toegevoegd. Deze is niet heel uitgebreid, maar kan toch als goed voorbeeld gebruikt worden.