Functioneel Ontwerp

September 2022 | Door Petrus Dispa

Waarom beginnen met een Functioneel Ontwerp?

Het plezier, de bevrediging en alle ander opbrengsten van een geslaagd project staan in schril contrast tot projecten die niet lukken. Ook zelf zijn we door schade en schande wijzer geworden. Waarom falen IT-projecten zo vaak? Over tijd, over budget en misschien nog erger: er wordt helemaal niet geleverd wat werd verwacht of was afgesproken. Er is in elk geval; één duidelijke oorzaak aan te wijzen. En toen we daar na onderzoek achter kwamen, waren we eerlijk gezegd nogal verbaasd.


Een idee vraagt om een plan. Logisch toch?

Stel je een projecten voor in de vliegtuigindustrie, de bouw of productie van een nieuw model auto. Ja, zelfs het klaarmaken van een recept in een restaurant, alles begint met een idee en daarna een plan. Een idee kan een droom zijn, een blinkend eindresultaat. Maar een plan begint bij de basis (de waarom). Het vliegtuig moet kunnen vliegen, het gebouw mag niet instorten, de auto moet kunnen rijden en remmen en het gerecht moet smaken. Basisvoorwaarden die worden aangevuld met een enorme hoeveelheid bijkomende eisen. Maar voor elk project geldt dat deze beschreven zijn en vertaald naar nodige grondstoffen. Dat kunnen zijn menskracht, materiaal, en ander middelen. Logisch toch? Maar let op.





Wat is het grootste probleem bij IT-projecten?

IT-projecten lijken die logische weg te volgen. Er is een idee, prachtig blinkend en glimmend en alles werkt. Tenminste in het idee. Op zich niets mis mee. Maar dan komt het. Hier wordt de logische weg vaak verlaten en wordt alle aandacht gegeven aan hoe dat eindproduct eruit moet zien. De lak van de auto, de gevel van het gebouw of opmaak van het bord. Oftewel de look en feel van het eindproduct. Het is de (ongeduldige) eis van de eindgebruiker die hier om vraagt.


En dat wordt het uitgangspunt. Dat moet als eerste gebouwd en ook nog goed functioneren. En de uitvoerende IT partij gaat hier vaak in mee. En waar leidt dat toe? Inderdaad, tot een moeizaam project. Maar beginnen met het bouwen van de look en feel is slechts één van de gevolgen voor het echte probleem bij IT-projecten. Het grootste probleem - en daarmee het grootste risico voor falen - is dat de betrokken partijen, business en IT, elkaar niet kunnen verstaan.


De stakeholders van het IT-project

Bij een IT-project gaat het meestal over een vragende - en de uitvoerende partij. Laten we zeggen de Business met een behoefte of idee. En aan de ander kant de IT met de kennis hoe deze om te zetten in een digitaal systeem. En daarmee is het hele verhaal eigenlijk verteld. En ook de exacte reden waarom IT vaak misgaat. Je hebt de realiteit van alledag waarin je met woorden duidelijk kan maken wat je wilt. En je hebt die vaak ondoorgrondelijke wereld van nullen en enen.


Waarin door slim code schrijven een eigen realiteit wordt opgebouwd. Wat gaat er dan mis? Nou, business denkt dat het gaat om de muisklikken en het comfort dat de gebruiker moet hebben. En dat is waar. Maar IT weet dat het alleen goed gaat werken als in die digitale werkelijkheid de informatie op een juiste manier beschikbaar is. En dat deze data bewerkt kan worden. Dat is dus ook een waarheid. En die twee moeten bij elkaar gebracht worden. Het goede nieuws is dat er een oplossing voor handen is.


Wat is de beste start voor een IT-project?

Wat is het belangrijkste moment voor een groot project? Dat is de eerste stap, de nul sprint of hoe je het ook wil noemen. Maar het gaat om die eerste stap waarmee het idee wordt omgezet in een plan. En die stap betekent een ontwerp maken. En dan bedoel ik een Functioneel ontwerp. De eerste vormgeving van het te bouwen IT-systeem.


Daarin wordt beschreven waarom het systeem gebouwd moet worden. En wat er van dat systeem verwacht wordt. Alles wat daarna komt kan leunen op deze stap. Maar alleen als de betrokken partijen het eens zijn over dit functionele ontwerp. Ze moeten elkaar verstaan, begrijpen en het eens worden. Dit kan alleen op basis van informatie die voor beide partijen begrijpelijk is. Precies wat een Functioneel ontwerp kan doen.





Wat is een goed Functioneel ontwerp voor IT-ontwikkeling?

Een goed Functioneel Ontwerp zorgt voor het vertalen van een idee naar een eerste ontwerp. In dat ontwerp wordt de behoefte van de business, dat is de gebruikerskant, vertaald naar eisen aan het te bouwen systeem. Maar dat niet alleen. Het ontwerp vertelt ook hoe het systeem voor de eindgebruikers moet gaan functioneren. Dus hoe zij het kunnen gebruiken.


En het ontwerp wordt echt waardevol als deze vereisten zo worden weergegeven dat het voor developers ondubbelzinnig duidelijk is wat zij moeten ontwikkelen. En dat kan alleen als ook de relatie tussen de functionaliteiten en de bijhorende data duidelijk wordt gemaakt. Oftewel het Functioneel ontwerp is de stap tussen taal en digitaal.


De onderdelen van een Functioneel ontwerp voor IT

Het Functioneel Ontwerp kan bestaan uit summiere opsommingen van vereisten tot en met zeer gedetailleerde beschrijvingen van alle functionaliteiten. De vormen waarin deze informatie wordt aangeboden verschilt sterk. Veel voorkomend zijn:

  • Requirements (Wat moet het systeem kunnen);

  • User Stories (Hoe moet dat voor de gebruiker(s) werken);

  • Processchema’s en andere ‘page flows’.

Wij vinden dat er ook altijd een opzet moet zijn over de data stromen. Functionaliteit is immers altijd bedoeld om iets met informatie te doen. Maar het meest belangrijk is dat het functionele ontwerp zorgt voor inzicht en overzicht. Dat wil zeggen hoe alle onderdelen van het ontwerp zich tot elkaar verhouden? En hoe kunnen de betrokken partijen zien of ze elkaar begrepen hebben? Wat zijn dan de meest bekende onderdelen van het functioneel ontwerp om dit te bereiken? In elk geval de zogenoemde Requirements en User Stories.


Wat is een Requirement?

Requirements beschrijven het gewenste gedrag van een systeem. Ze vertegenwoordigen de vraag of behoefte van één of alle eindgebruikers waaraan een systeem moet voldoen. Het kan een kwalitatieve of functionele vereiste zijn. Kwalitatieve requirements worden ook wel informele of non-functionele requirements genoemd. Ze beschrijven aan welke voorschriften (compliance), contracten of bijvoorbeeld wet- en regelgeving het systeem moet voldoen. Functionele vereisten gaan over de manier waarop het systeem moet werken om het gewenste resultaat te bereiken.



Wat is een User Story?

Een user story beschrijft in de taal van de gebruiker(s) kort wat een onderdeel van het systeem moet kunnen. En waarom dat geldt voor dit onderdeel. Het gaat dan in elk geval om het gebruik door één eindgebruiker. Het totaal aan user stories beschrijft dan de gewenste functionaliteiten voor alle eindgebruikers. Een goede user story beschrijft de gewenste functionaliteit en het resultaat daarvan met een duidelijk begin- en eindpunt.


User Stories zijn feitelijk de vertaling van de requirements, maar dan vanuit het perspectief van de eindgebruiker. En het kan ook andersom: de user stories kunnen gebruikt worden om de requirements van het systeem te helpen formuleren. Dan wordt de korte beschrijving van de User Story gebruikt voor het uitvragen van details. Dit is een methode die bij Scrum wordt toegepast.


Waarom een ontwerp in IT en waar moet je op letten?

Met een goed Functioneel Ontwerp als start, kunnen de opdrachtgever en opdrachtnemer vooraf overeenstemming krijgen over inhoud en omvang van het project. Bij een IT-project wil je zoveel mogelijk (ook als je in sprints werkt) vooraf weten of en hoe een idee voldoet aan de vraag. En of en hoe dit te realiseren is.


Herstellen wat al gebouwd is, kost altijd meer geld, tijd en frustratie. Daarom is het belangrijkste om op te letten bij een Functioneel Ontwerp dat deze exact weergeeft wat de vereisten aan een te bouwen systeem zijn. En daarmee ondubbelzinnig vertelt welke functionaliteiten vertaald moeten worden voor technische realisatie.


Waarvoor gebruik je een Functioneel Ontwerp bij IT-projecten?

Het Functionele ontwerp wordt gebruikt voor hele nieuw te bouwen systemen of applicaties. Maar ook voor het aanpassen of door ontwikkelen van al bestaande systemen. En bijvoorbeeld voor koppelingen (API’s) of voor het vastleggen van de eerste contouren van een idee. Je ziet, het kan van kleinere projecten tot hele grote gebruikt worden.


Want voor elk project geldt dat de vraag vanuit de business goed begrepen moet worden door de bouwers. Je gebruikt het functionele ontwerp altijd om de communicatie tussen business en IT te faciliteren. En dat betekent dat het voor beide partijen controleerbaar moet zijn of ze elkaar hebben verstaan. Je zoekt voor het maken van een functioneel ontwerp dus naar de middelen die dat kunnen.




Zijn er tools voor het maken van het Functioneel Ontwerp voor IT-projecten?

Voor het Functioneel ontwerp worden vaak verschillende tools gebruikt. Dit is zo gegroeid omdat er veel soorten informatie nodig zijn om helder te krijgen wat business wil en IT moet bouwen. Denk aan teksten, afbeeldingen, proces schema’s et cetera. Juist het overzichtelijk maken van de samenhang is dan vaak de grote uitdaging. En je kunt je voorstellen dat informatie bijvoorbeeld opgeslagen in mails, Word documenten, Excel sheets en diagram tools het werken niet makkelijker of leuker maakt.


Het is dan ook niet voor niets dat de informatie in een IT-project lastig te managen is. Er wordt steeds meer gebruikt gemaakt van projectmanagement tools die een soort van coördinerende rol hebben voor alle informatiestromen. Maar dat is dan al in de fase van uitvoer. Het functionele ontwerp is juist bedoeld om voordat die fase begint overeenstemming te hebben over inhoud en omvang van het project.


Is het Functioneel Ontwerp bij IT onderdeel van projectmanagement?

Projectmanagement zou altijd moeten beginnen met planning. En een planning kan alleen gemaakt worden als bekend is wat er moet gebeuren. Het Functioneel ontwerp beschrijft nauwkeurig waarom er - en wat er gerealiseerd moet worden. Dus het functionele ontwerp is het best op zijn plek in de nul-fase. Hoe kun je een project goed managen als niet duidelijk is wat het resultaat van het project moet zijn.


Ook als je in kleinere etappes werkt, of sprints, dan moet duidelijk zijn wat die etappes moeten opleveren om ze tot een goed einde te brengen. Het functionele ontwerp is de beste voorbereiding voor elk project en dus de beste start van goed projectmanagement. Als het project één keer start, kunnen de onderdelen van het functionele ontwerp worden gerealiseerd. En dit kan beter en sneller als duidelijk is wat er verwacht wordt van het project.


Meer informatie over functioneel ontwerpen? Neem contact op met Petrus Dispa via petrus@appcourt.com