Stap 3: Functionele wensen in kaart brengen

Waar het vastleggen van het doel vooral het creëren van een ‘globale visie, filosofie’ betreft op gebouwniveau en voor een aantal criteria zoals duurzaamheid, energie-efficiëntie, comfort, beleving,…, wordt bij het in kaart brengen van de functionele wensen een stuk verder ingezoomd. Er wordt beschreven WAT het gebouw dient aan te bieden aan de gebruikers, maar nog niet HOE dit moet gebeuren. Functioneel specificeren laat in het midden welke oplossing zal gebruikt worden, wat een grotere vrijheid laat voor innovatieve oplossingen.

Een eerste stap in het proces betreft het in kaart brengen van de specifieke van de verschillende types gebruikers van het gebouw. Het definiëren van zogenaamde ‘user persona’s’ – de karakterisering van de verschillende types gebruikers – kan helpen inzichtelijk te maken hoe deze het gebouw gebruiken (beschrijving van ‘user journeys’) en wat hun behoeften hierbij zijn. Inzicht krijgen in de manier van functioneren en de noden van al de mogelijke verschillende types gebruikers staat hierbij centraal.

Een logische vervolgstap is dat er wordt beschreven welke diensten het gebouw en haar systemen/installaties aan haar verschillende gebruikers moet bieden opdat het haar gebouw doel zou bereiken (en dus aan de behoeften van de verschillende types gebruikers tegemoet zou komen). Gebruik van technologieneutrale beschrijvingen is aan te raden. Het gaat hierbij immers niet over keuze voor technologie, wel over de keuze van zogenaamde ‘use cases’. Overleg met de verschillende types gebruikers zelf is hierbij de toe te passen techniek bij uitstek.

Een niet-limitatief overzicht van mogelijke (types) Smart Building toepassingen  is te vinden in hoofdstuk 2.4. Daarnaast kunnen ook ‘functiegebaseerde’ kaders (bv. SRI, BREEAM, WELL,…) inspireren bij het in kaart brengen van de functionele wensen, zelfs als er niet wordt toegewerkt naar een zekere score binnen een bepaald label of referentiekader. Er staan hierin namelijk een grote hoeveelheid functionele eisen verzameld. Meer informatie over dergelijke labels en referentiekaders is terug te vinden in hoofdstuk 6.

Binnen ISSO 115 wordt aan de lezer bijvoorbeeld specifieke begeleiding aangeboden bij het opstellen van een zogenaamd ‘programma van eisen’ voor gebouwautomatisering en gebouwbeheer. Onderstaand overzicht geeft een overzicht van de functionaliteiten voor gebouwbeheersystemen waarvan men vertrekt:

Specifiek voor facilitaire processen maakt ISSO 115 gebruik van volgende indeling:

Ook in de norm NBN EN 15221-4:2011 Facility Management – Deel 4: Taxonomie, classificatie en structuren in Facility Management is hierover heel wat interessante informatie terug te vinden.

Aanvullend zijn er nog tal van functionele wensen te definiëren die voornamelijk zullen te maken hebben met hoe de gebruikers het gebouw beleven. ‘User experience’ heeft de voorbije jaren heel wat aan belang gewonnen.

Het is belangrijk de geïdentificeerde wensen te blijven toetsen aan het budget, zeker gezien effectieve kostenplaatje stap voor stap duidelijker wordt (ook geldig voor ‘Stap 4: Technische eisen in kaart brengen’). Een methode om prioriteiten te stellen in de veelheid aan wensen van de bouwheer is de MoSCoW methode. Deze verplicht de bouwheer ertoe de wensen in te delen naar belangrijkheid:

• M: Must have: de functionele wens moet bij oplevering sowieso voldaan zijn om het project als geslaagd te kunnen beschouwen
• S: Should have: de functionele wens is belangrijk, maar niet noodzakelijk om het project als geslaagd te kunnen beschouwen
• C: Could have: de functionele wens is nuttig, maar dient slechts opgenomen te worden binnen het project als de nodige middelen (tijd, geld) nog beschikbaar zijn
• W: Won’t have: de functionele wens is momenteel te laag op de prioriteitenlijst om deze binnen het huidige project op te nemen (maar kan in de toekomst eventueel terug opgenomen worden)

Het overzicht van de functionele wensen, ingedeeld volgens de MoSCoW methode, dient naast het budget gelegd te worden en vervolgens dienen een aantal zaken beslist worden:

• Welke van de functionele wensen dienen tegen het einde van dit project volledig beschikbaar te zijn en dus in het kader van dit project ingevuld te worden? Er wordt nagegaan of alle ‘must haves’ binnen het beschikbare budget kunnen worden gepast en welke ‘should haves’ (en eventuele ‘could haves’) nog worden meegenomen.
• Welke van de functionele wensen dienen in het kader van dit project niet ingevuld te worden, maar dienen wel in beschouwing te worden genomen bij het in kaart brengen van de technische eisen? Dit moet er voor zorgen dat de mogelijkheid bestaat om zaken die vandaag nog niet functioneel geïmplementeerd worden in de toekomst wel relatief eenvoudig te integreren zijn.
• Welke van de functionele wensen vallen volledig buiten de doelstellingen? (‘out of scope’)

Ga naar volgende artikel: Stap 4: Technische eisen in kaart brengen
Keer terug naar de inhoudsopgave