Functioneel ontwerp

ICTscripters maakt gebruik van cookies. Door het gebruiken en browsen naar onze site gaat je automatisch akkoord met het gebruik van cookies. Klik hier voor meer informatie

  • 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.
    Bestanden
    Met vriendelijke groet,

    Dees Oomens

    9,382x gelezen

Reacties 2

  • WES -

    hmm

  • MJorritsma -

    Het voorbeeld dat je geeft is wellicht voldoende voor een schoolopdracht, maar ik zou dat zeker niet als houvast gebruiken bij een klant. Ten eerste ga je al grandioos de mist in door de inleiding voor de inhoudsopgave te plaatsen (straalt geen professionaliteit uit). Daarnaast ga je er in dit document vanuit dat de persoon die het leest volledig op de hoogte is van het begrip FO, wat in de realiteit waarschijnlijk niet zo is. Over de blog zelf: leuke toevoeging en voor veel mensen erg nuttig om te gebruiken. Als toevoeging op deze blog nog een handig artikel met tips: ises.nl/10-tips-voor-het-maken-van-een-functioneel-ontwerp