Functioneel ontwerp

Functioneel ontwerp

In een functioneel ontwerp worden requirements vertaald naar oplossingen. Requirements vertellen wat het systeem moet doen, het functioneel ontwerp geeft aan hoe het systeem dit moet doen.

Publiek & detailniveau
Het functioneel ontwerp vormt vaak de schakel tussen de vraagkant (klant) en de aanbodkant (leverancier). De klant wil weten wat hij geleverd krijgt hoe zijn systeem eruit komt te zien. De leverancier wil weten wat hij moet realiseren. Deze twee kanten samenvoegen kan lastig zijn. Voor wat betreft het klantgedeelte boek ik doorgaans goede resultaten met use cases of user stories. Indien goed toegepast kunnen deze technieken heel expliciet maken voor de klant wat er gerealiseerd gaat worden. Voor de leverancier is vaak een extra detaillering nodig, zeker als er complexe berekeningen of verwerkingen aan de orde zijn. In dit geval gebruik ik graag technieken zoals sequence diagrams, data flow diagrams of state machine diagrams om de nodige duidelijkheid verschaffen.

Waterval of agile
De aanpak tot het maken van een functioneel ontwerp hangt sterk af van de toegepaste softwareontwikkelmethodiek. Bij gebruik van een traditioneel watervalmodel wordt het functioneel ontwerp volledig afgerond en geaccordeerd voordat aan de softwarebouw wordt begonnen. Zeker bij grote projecten kan dit tot problemen leiden: het duurt lang voordat een klant iets bruikbaars krijgt opgeleverd, het risico bestaat dat de klantomstandigheden alweer veranderd zijn tegen die tijd.
In een agile omgeving worden niet meteen alle details uitgewerkt maar wordt gefocust op die onderdelen die de meeste waarde toevoegen voor de klant en deze worden werkend opgeleverd. Dit vereist een iteratieve aanpak, het functioneel ontwerp wordt continu uitgebreid en herzien. Het voordeel ten opzicht van de traditionele watervalaanpak is dat klanten snel werkbare onderdelen krijgen opgeleverd en dat snel valt bij te sturen. Het nadeel is dat op voorhand weinig over de totale kosten valt te zeggen, zeker met onervaren scrum teams.
De keuze van één van beide aanpakken hangt af van de specifieke omstandigheden. Met beide aanpakken kan ik goed uit de voeten.

Activiteiten & producten

  • Requirements management
  • Use cases
  • Data Flow Diagram
  • Functioneel ontwerp
  • Objectmodel
  • Gegevensmodel