Handreiking Functioneel Specificeren

Ministerie van Verkeer en Waterstaat
opq
Handreiking
Functioneel Specificeren
26 september 2005
Ministerie van Verkeer en Waterstaat
opq
Handreiking
Functioneel Specificeren
26 september 2005
........................................................................................
Colofon
Uitgegeven door: ExpertiseCentrum Opdrachtgeverschap
Informatie:
Telefoon:
Fax:
030-2858011
030-2858385
Uitgevoerd door:
Jeroen van Netten
ECO-Portaal
www.intranet.rws.nl/pog/gww
Datum:
26 september 2005
Status:
In ontwikkeling
Versienummer:
1.0
3
Handboek ECO-product Functioneel Specificeren
Inhoudsopgave
.......................................................................................
1.
Plaats van deze handreiking in IPM 7
2.
2.1
2.2
2.3
2.4
Inleiding 8
Rijkswaterstaat als professioneel opdrachtgever 8
Functioneel specificeren 8
Een handboek over Functioneel Specificeren 9
Doel en opzet van het handboek 10
3.
3.1
3.2
3.3
3.3.1.
3.3.2.
Functioneel specificeren: de theorie 11
Inleiding 11
Functioneel specificeren: opstellen van eisen 12
Typen eisen 14
Functionele eisen 14
Externe raakvlakkeneisen: eisen op het raakvlak
systeem/omgeving 15
Interne raakvlakeisen: eisen op raakvlakken tussen de
verschillende onderdelen van het systeem 15
Randvoorwaarden 15
Aspecteisen: eisen op specifieke gebieden, geldend voor het
totale systeem 15
Sturen met eisen gedurende de levensduur 16
Complexe systemen beheersen door te decomponeren 17
Decomponeren beheersen door structureren 18
Specificatieboom 18
Objectenboom 19
Het engineeringsproces 20
3.3.3.
3.3.4.
3.3.5.
3.4
3.5
3.6
3.6.1.
3.6.2.
3.7
4.
4.1
4.1.1.
4.1.2.
4.1.3.
4.2
4.3
4.3.1.
4.3.2.
4.4
4.4.1.
4.4.2.
4.4.3.
4.4.4.
4.5
4.6
4.7
4.8
4
Functioneel specificeren: de praktijk 21
De structuur van het project 21
Een project bestaat uit verschillende onderdelen: objecten 21
Hoe een project te decomponeren? 22
De objecten gerangschikt: de objectenboom 22
Structuur van het project en de eisen: de specificatieboom 24
Het formuleren van functionele eisen 25
Denken in functies 25
Van ‘verstopte’ wens naar concrete eis 26
Het structureren van eisen 29
Welke eis op welk niveau? 29
Ieder object zijn eigen specificatie 30
Welke eis in welk vakje: functie-eisen, raakvlakeisen,
aspecteisen en randvoorwaarden 33
Traceerbaar maken van eisen zorgt voor compleetheid 37
Check of ontwerp voldoet aan eisen: verificatiematrix 37
Verhouding eisen vs normen en richtlijnen 40
Strijdigheid van (niveau van) eisen: hoe hiermee om te gaan?
41
Enkele opmerkingen over de periode vóór het Tracébesluit 42
Handboek ECO-product Functioneel Specificeren
5.
Bijlage 1: Literatuurlijst 46
6.
Bijlage 2: Definities 47
7.
Bijlage 3: Functioneel specificeren in relatie tot de MITprocedure 50
8.
Bijlage 4: Format specificatie 52
Voorwoord 54
Inleiding 55
8.1
Definitie project 55
8.1.1. Objectdefinitie 55
8.1.2. Objectgrenzen 55
8.2
Beschrijving 55
8.2.1. Bestaande situatie 55
8.2.2. Gewenste situatie 55
8.3
Afbakening scope 55
8.4
Leeswijzer 55
8.4.1. Inleiding 55
8.4.2. Functionele eisen 55
8.4.3. Externe en interne raakvlakeisen 56
8.4.4. Randvoorwaarden 56
8.4.5. Aspecteisen 56
Van toepassing zijnde documenten 57
8.5
Bindende documenten 57
8.6
Informatieve documenten 57
Eisen 58
8.7
Functionele eisen 58
8.7.1. <functie x> 58
8.7.2. <functie y> 58
8.7.3. <functie z> 58
8.8
Externe raakvlakeisen 59
8.8.1. Raakvlak <object x> - <omgevingselement a> 59
8.8.2. Raakvlak <object x> - <omgevingselement b> 59
8.8.3. Raakvlak <object x> - <omgevingselement c> 59
8.9
Interne raakvlakeisen 60
8.9.1. Raakvlak <object x> - <object p> 60
8.9.2. Raakvlak <object x> - <object q> 60
8.9.3. Raakvlak <object x> - <object r> 60
8.10
Randvoorwaarden 61
8.11
Aspecteisen 61
8.11.1. Veiligheid 61
8.11.2. Beschikbaarheid & betrouwbaarheid 61
a)
Beschikbaarheid 61
b)
Levensduur 62
c)
Betrouwbaarheid 62
5
Handboek ECO-product Functioneel Specificeren
8.11.3. ormgeving 62
8.11.4. Milieuhygiëne 63
a)
Stof 63
b)
Geluid 63
c)
Trillingen 63
d)
8.11.5.
8.11.6.
8.11.7.
8.11.8.
Stank 64
Uitvoering 64
Onderhoud 64
Duurzaamheid 65
Sloop 65
Informatie over eisen 66
8.12
Brondocumenten 66
Bijlagen bij de eisen 67
Knelpunten/discussiepunten/opmerkingen 68
6
Handboek ECO-product Functioneel Specificeren
1. Plaats van deze handreiking in IPM
...............................................................................
Revisie
Datum
20 augustus 2004
25 augustus 2005
21 september 2005
7
Versie
1.0
1.1
1.2
Reden
Eerste uitgave
Eerste commentaar verwerkt.
Tweede commentaar verwerkt
Handboek ECO-product Functioneel Specificeren
Actor
ECO
ECO
ECO
2. Inleiding
...............................................................................
2.1
Rijkswaterstaat als professioneel opdrachtgever
Rijkswaterstaat hanteert voor aanleg en onderhoud en de uitvoerende
beheertaken het principe ‘Markt, tenzij’, en gaat projecten steeds eerder
op de markt zetten. In 2008 zullen voor tachtig procent van alle
werkzaamheden geïntegreerde contractvormen worden gebruikt. Bij
geïntegreerde contractvormen is sprake van een verschuiving van taken,
verantwoordelijkheden en risico’s tussen Rijkswaterstaat en de markt.
Om op efficiëntere wijze tot een gewenst eindresultaat te komen,
worden opdrachtnemers eerder in het proces betrokken. Marktpartijen
krijgen bij de uitvoering, waar mogelijk, een grotere vrijheid.
Rijkswaterstaat concentreert zich in toenemende mate op de ‘voorkant’
van het ontwerp- en uitvoeringsproces van zijn producten. Hiertoe is
Rijkswaterstaat als opdrachtgever duidelijk en outputgericht in zijn
vraagstelling, om uiteindelijk zeker te zijn dat het gewenste resultaat en
haalbaar is en gehaald wordt.
Deze verschuiving van de verhouding tussen Rijkswaterstaat en de markt
zorgt er voor, dat in veel gevallen de beheersing van de risico’s op een
andere manier geregeld moet worden. Rijkswaterstaat stuurt op prijs,
tijd en kwaliteit en timmert een ontwerp niet langer volledig dicht, maar
biedt ruimte aan de kennis en ervaring van de markt. Dit stimuleert
innovatie, klantgerichtheid in het gehele bouwproces en leidt al met al
tot een verbeterde prijs/kwaliteitsverhouding bij bouwwerken. Dit
betekent dat de vraagstelling richting de markt anders geformuleerd
moet worden dan voorheen. Functioneel specificeren is het middel om
hieraan invulling te geven.
Functioneel specificeren
Het vastleggen van de
gewenste prestatie van een
systeem in eisen, op basis
van de functie van het
systeem.
Functie
afwikkelen verkeer
130.000 voertuigen per
etmaal
afvoeren water
debiet 5.000 m3 per seconde
Systeem
weg
kanaal
2.2
Functioneel specificeren
Functioneel specificeren is het vastleggen van de gewenste prestatie van
een systeem in eisen, op basis van de functie van het systeem. Het
denken in termen van prestatie, functie en systeem is een fundamenteel
principe van functioneel specificeren. Een systeem wordt gespecificeerd,
ontworpen, gebouwd en onderhouden om een functie te vervullen. Het
vervullen van deze functie is de prestatie van het systeem. De eisen
worden geformuleerd op basis van de functie van het systeem, vandaar
de naam: Functioneel specificeren.
De eisen worden uit verschillende invalshoeken gesteld: vanuit de
omgeving, de opdrachtgever, de markt en de techniek.
Bij functioneel specificeren worden eisen minder gedetailleerd
gespecificeerd waarmee zoveel mogelijk vrijheid aan de opdrachtnemer
wordt gegeven. Dit betekent dat er niet meer eisen moeten worden
gesteld dan nodig of wenselijk is en dat geen impliciete ontwerpkeuzes
moeten worden meegenomen. Dit beperkt de mogelijkheden om
8
Handboek ECO-product Functioneel Specificeren
gebruik te maken van de kennis en het innoverend vermogen van de
markt. Anderzijds laat een te vage beschrijving van de vraag teveel
onzekerheid bestaan over het gewenste eindresultaat. Bij de uitvraag
bestaat er dus een spanningsveld tussen de vrijheid die geboden wordt
aan de markt en de beschrijving van het gewenste resultaat. Het
opstellen van een vraagspecificatie met behulp van functioneel
specificeren maakt onderdeel uit van het beheersbaar maken van dit
spanningsveld.
Functioneel specificeren betekent ook expliciet en van grof naar fijn
werken. Het gaat uit van een topdown benadering en sluit hierdoor
goed aan op de netwerkvisie van Rijkswaterstaat. Rijkswaterstaat
beheert en ontwikkelt de infrastructurele hoofdnetwerken. Goed beheer
betekent ervoor zorgen dat een netwerk in goede staat is en voldoet aan
veranderende behoeftes. De veranderende behoeftes laten zich vertalen
naar gewenste functies die verricht dienen te worden. Deze functies
kunnen op verschillende niveaus gezien worden. Van een niveau waarop
de functie een regio bereikbaar houden is, tot de functie van een afrit;
een onderliggend wegennet (deel van de regio) ontsluiten. Er is sprake
van een hiërarchische ordening van netwerken naar verkeer- en
vervoers-, dan wel watersystemen en verdere systeemonderdelen.
2.3
Een handboek over Functioneel Specificeren
Om ervoor te zorgen dat binnen Rijkswaterstaat op een eenduidige
wijze met functioneel specificeren wordt omgegaan is besloten de
gemeenschappelijke kennis te bundelen en in dit handboek samen te
brengen. Zo wordt standaardisatie bij projecten van Rijkswaterstaat
bevorderd. Hierdoor is kennisuitwisseling tussen projecten een stuk
eenvoudiger te realiseren en valt er sneller en efficiënter van elkaar te
leren.
Het handboek schetst het theoretisch kader van functioneel specificeren,
maar geeft ook antwoord op de vraag hoe functioneel specificeren
werkt in de praktijk. Zo wordt er ingegaan op de vraag hoe je
functionele eisen formuleert en structureert. Middelpunt vormen hierbij
de inhoudelijke functionele eisen van een project. Dit handboek gaat
dus niet in op eisen die gesteld kunnen worden aan het uiteindelijke
contract, het besluitvormingsproces, bepaalde beslisdocumenten, etc.
Naast dit handboek heeft ECO een aantal standaard basis specificaties
voor verschillende ‘objecten’, zoals wegen, bruggen, viaducten en
sluizen ontwikkeld. Deze eisensets zijn te vinden op de ECO-site.
9
Handboek ECO-product Functioneel Specificeren
2.4
Doel en opzet van het handboek
Dit handboek is vooral bedoeld voor projectmanagers, projectleiders en
medewerkers binnen infrastructuurprojecten van Rijkswaterstaat
waarvoor de tracéwet van toepassing is. Voor inkoop ligt de op de fase
na het Tracébesluit, waarbij het project als één of meerdere Design &
Construct contracten op de markt wordt gezet. In dit stadium zijn er al
veel eisen gesteld en is de contractvorm Design & Construct (zie
Ondernemingsplan RWS). Voor projecten waarbij de Tracéwet niet van
toepassing is, zal de nadruk liggen op de fase na het projectbesluit.
Daarnaast is het handboek ook van nut voor projectleiders en
medewerkers van infrastructuurprojecten die niet binnen
bovengenoemde categorie vallen, zoals natte infrastructuur en niet
tracéwet-plichtige droge infrastructuur.
Om aan alle doelgroepen tegemoet te komen bestaat dit Handboek uit
twee delen. De theorie van het functioneel specificeren staat centraal in
hoofdstuk 2. Hierin staat de vraag ‘wat is het?’ centraal. Vervolgens
komt in hoofdstuk 3 de praktijk aan de orde, waarbij de vraag: ‘hoe doe
je het?’ centraal staat.
10
Handboek ECO-product Functioneel Specificeren
3. Functioneel specificeren: de theorie
...............................................................................
3.1
Inleiding
In de volgende paragrafen wordt de theorie van het functioneel
specificeren uiteengezet. In essentie is de Rijkswaterstaatorganisatie al
gewend om op een dergelijke manier projecten te realiseren. Via
meerdere ontwerpslagen 1 wordt gekomen tot een oplossing die voldoet.
Functioneel specificeren is onderdeel van de methode Systems
Engineering (SE). Deze methode is in de jaren ‘60 ontwikkeld door NASA
en het Amerikaanse Ministerie van Defensie. Het is ontwikkeld door en
voor ingenieurs en wordt tegenwoordig toegepast in diverse industrieën.
Het heeft sinds haar ontstaan bewezen een robuuste methode te zijn.
Prorail is een aantal jaren geleden begonnen met de implementatie
ervan in haar organisatie en vandaar uit heeft
Rijkswaterstaat kennis gemaakt met functioneel specificeren volgens de
SE methode. Rijkswaterstaat past deze benadering toe in steeds meer
projecten.
In de basis is functioneel specificeren een zich steeds herhalend
ontwerpproces. De meerwaarde van de methodiek van het functioneel
specificeren zit in het beheersbaar maken van het proces, door
(complexe) systemen expliciet en traceerbaar te ontleden
(decomponeren) en te relateren aan de levenscyclus van het systeem
(life cycle). In onderstaande figuur wordt het principe geïllustreerd.
eisen
opties
varianten
ontwerp
groeiende objectenboom
groeiende eisenboom
Het onderstaande voorbeeld geeft aan dat het functioneel specificeren,
het opstellen van de eisen, hand in hand gaat met de uitwerking er van
in ontwerpoplossingen. Deze twee kunnen niet los van elkaar tot stand
komen.
1
In dit document worden de termen ontwerp en engineering als synoniem gebruikt.
11
Handboek ECO-product Functioneel Specificeren
Voorbeeld
Eisen
Oplossingen
Capaciteitsuitbreiding:
een plank over een sloot.
Eisen
Oplossingen
Een bepaald type brug. De keuze wordt gemaakt
op basis van eisen, kosten, planning
en risico’s.
Eisen
Oplossingen
Vanuit de eisen wordt gekozen voor een dek,
landhoofd en fundering etc. Het ontwerp is
weer een stap verder uitgewerkt.
Eisen
Oplossingen
Op dezelfde wijze als bij de bovenstaande fasen wordt
vanuit het voorgaande ontwerp een aantal eisen gesteld
aan de verdere onderdelen. De gehele trits van afwegingen
leidt uiteindelijk tot een
bouwgereed ontwerp.
3.2
Functioneel specificeren: opstellen van eisen
Het functioneel specificeren bestaat uit het opstellen van eisen. Iedere
eis in een specificatie dient de volgende eigenschappen te bezitten:
Eigenschap
enkelvoudig
traceerbaar
toetsbaar
indien gekwantificeerd,
voorzien van +/- marges
actueel
eenduidig
uniek
positief geformuleerd
12
Toelichting
één eis per eis
herleidbaar naar boven- en onderliggende
eisen ten behoeve van o.a. het
verificatietraject
er dient objectief bepaald te kunnen
worden of aan de eis wordt voldaan of niet
er dient aangegeven te worden binnen
welke marges een waarde, die bij de
verificatie bepaald wordt, moet vallen om
te voldoen aan de eis
passend bij de laatste projectbaseline
slechts voor één uitleg vatbaar
per onderwerp/aspect komt één eis voor
niet: “niet minder dan”, maar: “tenminste”
Handboek ECO-product Functioneel Specificeren
haalbaar
consistent
noodzakelijk
eisen die niet haalbaar zijn voegen niets toe
samenhangend en volledig
de eis dient toegevoegde waarde te
hebben; zonder die eis gaat er iets mis
oplossingsvrij
een eis dient vrij van (verwijzingen naar)
oplossingen te zijn
van een unieke identificatie t.b.v. identificatie en verwijzing / tracering
voorzien
Deze eigenschappen van eisen worden ook vaak samengevat onder het
begrip SMART.
•
•
•
•
•
Specifiek, helder, ondubbelzinnig, nauwkeurig, volledig;
Meetbaar, verifieerbaar;
Acceptabel voor de klant en opdrachtgever;
Realistisch, haalbaar;
Toleranties dienen aangegeven te zijn.
Deze eisen worden niet enkel door de opdrachtgever bepaald. Vanuit
verschillende andere invalshoeken (omgeving, markt, techniek) zullen
vele eisen verschillend van niveau en aard aan een systeem gesteld
worden.
Eis:
Eis:
Eis:
Eis:
Eis:
De snelweg A4 dient tussen Burgerveen en Leiden verbreed te
worden naar 2x3 rijstroken (Bron: MIT)
De Ecologische Hoofdstructuur dient te worden gehandhaafd.
(Bron: Vijfde Nota Ruimtelijke Ordening, Ministerie VROM)
De snelweg dient 20.000 personenauto-equivalenten per
tijdseenheid te kunnen afwikkelen tussen Burgerveen en Leiden.
(Bron: MIT)
Gedurende de realisatie dient te allen tijde ten minste 1 rijbaan
per rijrichting voor verkeer opengesteld te blijven.
(Bron: Provincie Zuid-Holland)
De grenswaarde NO2 135 mg/m3 voor het 98-percentiel van de
uurwaarden dient niet te worden overschreden.
(Bron: Afspraak met Ministerie LNV en VROM)
Het bovenstaande voorbeeld geeft aan dat de herkomst, het type en het
niveau van de eisen verschillend zijn.
13
Handboek ECO-product Functioneel Specificeren
3.3
Typen eisen
In eisen is vastgelegd wat het systeem moet kunnen, de functie. De
prestatie is het vervullen van deze functie. Betreft het een complex
project, dan deelt men het systeem op in onderdelen. Voor ieder van
deze onderdelen worden dan weer aparte, afgeleide eisen gesteld. Ieder
onderdeel vervult een eigen functie. Dit gebeurt op alle niveaus in het
systeem:
• een functie van een tunnelwand is het keren en weren van
grond en water;
• een functie van bout en moer is het verbinden van twee
onderdelen.
Voor ieder van deze zijn functionele eisen op te stellen. Het vervullen
van functies op een lager niveau moet leiden tot het vervullen van de
functie op hoger niveau en uiteindelijk tot het vervullen van de
gewenste systeemfunctie. Het identificeren van functies is een
tussenstap tussen het formuleren van een pakket aan eisen en de keuze
in oplossingen. Door bijvoorbeeld in functie “verbinden oevers” te
denken en hieraan eisen te koppelen wordt wel een nadere analyse van
de eisen uitgevoerd, maar nog niet naar de oplossing, bijvoorbeeld een
brug of een tunnel, gekeken.
Het functioneel specificeren bestaat uit het opstellen van eisen aan een
resultaat, vanuit een gewenste functie.
Om een complete definitie van een functie mogelijk te maken, wordt
gebruik gemaakt van vier soorten eisen.
− Functionele eisen; wat is de functie van het systeem of object?
− Interne en externe raakvlakeisen; hoe past het systeem in de
omgeving en in elkaar?
− Randvoorwaarden; extern dwingend opgelegd.
− Aspecteisen; waar dient verder rekening mee gehouden te worden?
3.3.1.
Functionele eisen
In de functionele eisen ligt vast:
wat het object dient te doen, c.q. wat de functies zijn die het object
dient te vervullen. Ook kunnen al functies vanuit het ontwerp op
hoger liggend niveau naar het betreffende object zijn gealloceerd.
wat de prestatie van de geïdentificeerde functies moet zijn, door
antwoord te geven op vragen als:
Wie? Wat? Waar? Wanneer? Hoeveel? Welke? etc.
Functies op lagere niveaus kunnen op twee manieren worden afgeleid.
Ten eerste door ze van de functie op het naast hogere niveau af te
leiden. De afleiding uit de functie volgt door de volgende vraag te
stellen: Wat is er nodig voor een goede functievervulling (bijvoorbeeld
goede verkeersdoorstroming: geleiding, regeling, incidentmanagement).
Een andere methode om afgeleide functies te identificeren is door te
redeneren vanuit de objectstructuur; te kijken naar het pakket aan
onderdelen dat binnen het systeem normaliter aanwezig is en daarbij
vast te stellen welke functies deze onderdelen vervullen.
14
Handboek ECO-product Functioneel Specificeren
3.3.2.
Externe raakvlakkeneisen: eisen op het raakvlak
systeem/omgeving
Bij infrastructuurprojecten dient het te ontwikkelen object te worden
ingepast in zijn omgeving. Het object snijdt of beïnvloedt fysiek
elementen in de omgeving. Vanuit de omgeving kunnen eisen aan het
object gesteld worden. Externe raakvlakkeneisen kunnen worden
geïdentificeerd door:
het vaststellen van de onderdelen in de omgeving die door het nieuw
te ontwikkelen object mogelijk wordt doorsneden
het vaststellen van de functies en eisen die vanuit beleid en/of
omgeving worden gesteld aan de objecten
het afleiden van eisen uit eventuele bovenliggende specificatie(s).
3.3.3.
Interne raakvlakeisen: eisen op raakvlakken tussen de
verschillende onderdelen van het systeem
Naast de raakvlakken uit de omgeving, de externe raakvlakken, kunnen
ook interne raakvlakken bestaan. Dit zijn raakvlakken binnen de grenzen
van het te ontwikkelen systeem. Deze ontstaan als het systeem wordt
opgedeeld in onderdelen (subsystemen, objecten, componenten en
elementen) en een specificatie wordt ontwikkeld voor een onderdeel.
Tussen de onderdelen zullen raakvlakken ontstaan, hier zullen eisen aan
gesteld worden.
3.3.4.
Randvoorwaarden
Randvoorwaarden zijn eisen die bij aanvang van een project al extern
worden opgelegd. Deze eisen kunnen op geen andere wijze worden
ondervangen dan door ze op te nemen als randvoorwaarden. Het kan
zijn dat deze eisen dusdanig duur of beperkend zijn dat het gewenst is
ze ter discussie te stellen bij de instantie die ze wil opleggen. De
randvoorwaarden worden wel benoemd in de specificaties, en worden
doorvertaald naar lager niveau onderdelen.
3.3.5.
Aspecteisen: eisen op specifieke gebieden, geldend
voor het totale systeem
Naast de functionele eisen en raakvlakeisen worden aspecteisen
geïdentificeerd. Deze beschrijven specifieke eigenschappen van het te
ontwikkelen systeem, die een indirecte bijdrage leveren aan de primaire
functie.
Aspect
Veiligheid
Toelichting
Eisen met betrekking tot veiligheid tijdens realisatie en veiligheid in de gebruiksfase van
gerealiseerde objecten, voor zowel de gebruiker als de omgeving
Beschikbaarheid &
Eisen met betrekking tot beschikbaarheid, levensduur en betrouwbaarheid van gerealiseerde
betrouwbaarheid
objecten
Vormgeving
Eisen met betrekking tot uiterlijke vormgeving van gerealiseerde objecten
Milieuhygiëne
Eisen aan stof, geluid, trillingen en stank tijdens de realisatie en gebruiksfase
Uitvoering
Eisen aan de uitvoering en aanpassing van nieuw te bouwen en bestaande objecten
Onderhoud
Eisen met betrekking tot benodigde instandhoudingvoorzieningen en relatie met
onderhoudsprocessen (onderhoudbaarheid)
Duurzaamheid
Eisen met betrekking tot aanpassing van gerealiseerde objecten aan toekomstverwachtingen
Sloop
Eisen met betrekking tot de sloop van te slopen objecten
15
Handboek ECO-product Functioneel Specificeren
3.4
Sturen met eisen gedurende de levensduur
De life cycle fasering die gebruikt wordt bij het functioneel specificeren
binnen Rijkswaterstaat maakt de rol die eisen spelen in een betreffende
fase 2 inzichtelijk. Hierdoor kan aan de hand van de eisen gestuurd
worden en dit garandeert, dat het gewenste systeem gerealiseerd wordt
conform de gewenste kwaliteit.
verifiëren
kiezen
keuren
inspecteren
evalueren
reduceren
FASE 1
eisen
FASE 2
opties
FASE 3
varianten
FASE 4
ontwerp
FASE 5
uitvoering
FASE 6
gebruik/
onderhoud
FASE 7
sloop/
upgrade
FASE 1 – eisen
Het opstellen van de specificatie met de eisen voor het betreffende
object.
FASE 2 – optie
Reductie van de verzameling van alle denkbare opties voor het object
naar alle haalbare opties, door eliminatie op basis van eisen.
FASE 3 – varianten
De haalbare opties worden uitgewerkt tot oplossingsvarianten voor het
object. Aan de hand van een afweging op basis van de eisen, kosten,
planning en risico wordt een keuze gemaakt uit deze varianten.
FASE 4 – ontwerp
Door verificatie wordt vastgesteld of de uitwerking van de gekozen
oplossingsvariant van het object voldoet aan de eisen.
FASE 5 – uitvoering
Het object wordt bij oplevering gekeurd. Er wordt vastgesteld of het
object, dat gebouwd is, voldoet aan de eisen.
FASE 6 – gebruik-/onderhoud
Tijdens het gebruik wordt geïnspecteerd of het object blijft voldoen aan
de eisen.
FASE 7 – sloop/upgrade
Het besluit tot upgrade of sloop van het object wordt genomen nadat is
geëvalueerd of het nog object voldoet aan de eisen.
2
Er bestaan vele faseringen, die ieder hun nut hebben. De gepresenteerde life cycle fasering is
bij iedere contractvorm en te gebruiken en onafhankelijk van de actor en onafhankelijk van de
indeling van de eigen organisatie. Daarmee is de fasering universeel.
16
Handboek ECO-product Functioneel Specificeren
Eisen worden op verschillende abstractieniveaus gesteld. Eisen worden
ook in alle fasen van de levensduur van een systeem gebruikt om:
• het aantal mogelijke opties te reduceren tot de haalbare
varianten; een variant te kiezen;
• het ontwerp te verifiëren;
• te keuren tijdens uitvoering;
• te inspecteren tijdens gebruik;
• te evalueren of het object nog in staat is de beoogde functie te
vervullen.
Sturen op kwaliteit door een terugkoppeling naar de eisen is gedurende
de gehele life cycle van een systeem mogelijk en noodzakelijk.
3.5
Complexe systemen beheersen door te decomponeren
Bij complexe systemen wordt eerst een ontwerp op een abstract niveau
gemaakt. Omdat er op een abstract niveau nog veel onzekerheden zijn,
zal Rijkswaterstaat een slag dieper gaan engineeren. In theorie kan men
na het vaststellen van het ontwerp overgaan tot realisatie en exploitatie
van het object. In de praktijk is deze keuze gebaseerd op een inschatting
van de risico’s. Deze moeten afdoende beheerst zijn, voordat de
overdracht van de activiteiten naar een opdrachtnemer plaatsvindt.
Indien het risico nog niet tot een aanvaardbaar niveau gereduceerd is,
moet gekozen worden voor een verdere uitwerking. Met andere
woorden indien de risico’s op niveau k niet voldoende te beheersen zijn;
dan volgt uitwerking op niveau k+1 3.
Wanneer decomponeren?
Alleen indien het systeem en de
relaties met de omgeving te
complex zijn om als een geheel te
beheersen. Dit wordt bepaald aan
de hand van de risico’s.
Niveau (k)
verifiëren
kiezen
reduceren
FASE 2
opties
FASE 1
eisen
traceren
FASE 3
varianten
decomponeren
afleiden
FASE 4
ontwerp
integreren
Niveau (k + 1)
evalueren
keuren
verifiëren
kiezen
inspecteren
reduceren
FASE 1
eisen
FASE 2
opties
FASE 3
varianten
3
FASE 4
ontwerp
FASE 5
uitvoering
FASE 6
gebruik/
onderhoud
FASE 7
sloop/
upgrade
Andere mogelijkheden tot risicobeheersing worden hier gemakshalve buiten beschouwing
gelaten.
17
Handboek ECO-product Functioneel Specificeren
3.6
Decomponeren beheersen door structureren
Een slag dieper engineeren betekent dat een systeem wordt opgedeeld.
Dit proces heet decomponeren. Een systeem wordt gedecomponeerd
naar verschillende subsystemen. Voor ieder van deze subsystemen wordt
weer een aparte specificatie geschreven, varianten ontwikkeld,
ontwerpen gemaakt etc. Deze subsystemen worden indien noodzakelijk
ook zelf weer gedecomponeerd. In deze hiërarchie onderscheidt men,
vanuit de netwerkbenadering van Rijkswaterstaat, de volgende niveaus:
1.
2.
3.
4.
Beleidsniveau
Beschrijving van de samenhang en functionaliteit van het
netwerk en de strategische visie.
Topniveau
Beschrijving van probleem, doel, randvoorwaarden en
systeemkeuze op corridorniveau.
Systeemniveau
Beschrijving van de bottleneck, het gekozen systeem dat de
functie levert zoals op Topniveau gedefinieerd.
Subsysteemniveau
Beschrijving van de belangrijkste onderdelen waaruit het
systeem is opgebouwd.
De topdown benadering brengt met zich mee dat het decomponeren
begint vanaf het hoogste niveau, redenerend vanuit een te leveren
prestatie, een uitoefening van een functie op netwerkniveau. Het
Tracébesluit wordt genomen op systeemniveau. Na subsysteemniveau
kan men, afhankelijk van de mate waarin risico’s beheerst zijn, verder
decomponeren naar object-, component of elementniveau. Ieder niveau
wordt gedefinieerd door de verzameling van objecten en de
daarbijbehorende life cycle producten op dat niveau.
Voor het gebruik bij functioneel specificeren worden twee
boomstructuren geïntroduceerd: de objectenboom, die het systeem
weergeeft in de objecten waaruit het is opgebouwd en de
specificatieboom, waarin de eisen, die gesteld worden aan de objecten,
op ieder niveau zijn weergegeven.
3.6.1.
Specificatieboom
Voor het structureren van
specificaties van objecten.
Specificatieboom
De specificatieboom geeft de samenhang tussen de specificaties weer,
gestructureerd naar de verschillende niveaus. De specificatieboom kan
derhalve gebruikt worden om de samenhang tussen de eisen op de
verschillende niveaus te bewaken. De specificaties vormen tezamen met
overige specificaties het Programma van Eisen.
18
Handboek ECO-product Functioneel Specificeren
3.6.2.
Objectenboom
Voor het structureren van fysieke
onderdelen van het systeem.
Engineeringproducten
Eisen worden gesteld aan objecten. Dat betekent dat alle eisen zijn
gekoppeld aan objecten. In de objectenboom wordt het totale systeem
(object 4) gerepresenteerd, aan de hand van een hiërarchische structuur
van alle objecten, hetzij permanent, hetzij tijdelijk (hulpwerken), hetzij te
slopen.
Alle engineeringproducten zijn gekoppeld aan objecten.
De Engineeringproducten zijn de
Abstractieniveau
producten die binnen
Beleid
Engineeringmanagement worden
Top
gemaakt, per object, per niveau:
1.
Specificatie
2.
Opties
3.
Varianten
4.
Ontwerp
Objectenboom
Systeem
Subsysteem
Functie
Hoofdwegennetwerk
Bereikbaarheid
en leefbaarheid
Verbinden
bestemmingen
Afwikkelen
wegverkeer
Weg
rijden
Autosnelweg
A1
Autosnelweg
A2
Autosnelweg
An
Bottleneck
1
A2
Randweg
Den Bosch
Bottleneck
3
Kruising
kruisen
Verkeersmanagementsysteem
Verzorgingsplaats
Omgeving
verzorgen
inpassen
regelen en
beheersen
Van ieder object wordt bepaald op welke functionele en fysieke
gebieden een raakvlak met andere objecten, binnen en buiten het
systeem, bestaat. Deze verbanden worden vastgelegd binnen de
specificaties van het betreffende object. De samenhang tussen objecten,
op een zelfde hiërarchisch niveau in het systeem, wordt beheerst door
interne raakvlakkenspecificaties.
Structureren van eisen en
objecten
Ieder object wordt beschreven met
behulp van engineeringproducten.
De specificaties van ieder object
worden gestructureerd met behulp
van de specificatieboom.
4
De term ‘object’ wordt zowel gebruikt als aanduiding voor een afzonderlijk onderdeel van de
boom als ter aanduiding van geaggregeerde delen en gehelen ((m.a.w. een object bestaat in
deze terminologie zelf weer uit een x-aantal objecten, enzovoort)
19
Handboek ECO-product Functioneel Specificeren
Programma van Eisen
Specificatieboom
Objectenboom
Specificaties
Topspecificatie
Topniveau
Systeemspecificatie
Systeemniveau
Subsysteemspecificaties
Interne raakvlakkenspecificaties
Subsysteemniveau
Objectspecificaties
Objectniveau
Componentspecificaties
Componentniveau
Specificatie object X
Eis 1: ...
Eis 2: ...
...
Eis n: ...
Niveau (k)
FASE 1
FASE 2
FASE 3
FASE 4
Niveau (k + 1)
FASE 1
FASE 2
FASE 3
FASE 4
FASE 5
FASE 6
FASE 7
Engineeringproces
3.7
Het engineeringsproces
Het engineeringproces bestaat uit het, per object, iteratief doorlopen
van de fasen 1 tot en met 4 op basis van een ontwerp op het
bovenliggend niveau. Vanuit het ontwerp (product uit fase 4) op het
bovenliggend niveau worden eisen afgeleid die gesteld worden aan één
of meerdere objecten op het beschouwde niveau. De eisen op dit
(lagere) niveau dienen getraceerd te kunnen worden naar de eisen, die
reeds gesteld waren op het hogere niveau. Vervolgens zullen op dit
niveau opties gereduceerd worden (fase 2) en varianten gekozen
worden (fase 3) waarna, na verificatie (fase 4), het ontwerp
geïntegreerd kan worden in het ontwerp op het hogere niveau.
De verzamelde eisen aan een object worden als specificatie op het
desbetreffende niveau in de specificatieboom geplaatst. De totale
verzameling specificaties vormt het Programma van Eisen. De totale
verzameling objecten vormt de objectenboom.
Het engineering- en lifecycleproces is onafhankelijk van de uitvoerende
partij, onafhankelijk van de technische inhoud en onafhankelijk van een
gekozen contractvorm en aanbestedingsprocedure. Deze
onafhankelijkheid gekoppeld aan een standaardisering maakt het
proces hanteerbaar voor zowel Rijkswaterstaat als marktpartijen.
Hierdoor wordt robuustheid en duurzaamheid gegarandeerd en draagt
het bij aan een meer efficiënte sturing op ontwerp, realisatie en
onderhoud.
20
Handboek ECO-product Functioneel Specificeren
4. Functioneel specificeren: de praktijk
...............................................................................
4.1
De structuur van het project
4.1.1.
Een project bestaat uit verschillende onderdelen:
objecten
Een infrastructuurproject bestaat vaak uit het realiseren van een aantal
fysieke onderdelen. Deze onderdelen kunnen zijn: een weglichaam, een
kunstwerk, geluidschermen, wegsignalering, etc. Gemakshalve worden
deze fysieke onderdelen ook wel elementen genoemd.
Indien met een groot project gestart wordt is vaak nog niet bekend uit
welke objecten het project samengesteld zal gaan worden: hoeveel
viaducten, bruggen etc. Op dat moment is er niet meer dan een
probleemstelling (bij infrastructurele projecten vaak een leefbaarheidsen/of bereikbaarheidsprobleem). In het beginstadium bevindt het
project zich op een hoog abstractieniveau waarin voornamelijk
nagedacht wordt over oplossingsrichtingen.
In een vervolgstadium, na het tracébesluit, wordt het ontwerp ontrafeld
in onderdelen. Dit ontrafelen wordt ook wel decomponeren genoemd.
Zo kan een weginfrastructuurproject worden gedecomponeerd in de
objecten weg, kunstwerken, verzorgingsplaats, verkeersbeheer en
omgeving. Dit decomponeren gebeurt alleen indien het systeem en de
relaties met de omgeving te complex zijn om als een geheel te
beheersen. Dit wordt bepaald aan de hand van de risico’s. De
decompositie van de opdrachtgever wordt verder doorgezet door de
opdrachtnemer. De overgang tussen de decompositie opdrachtgever en
voorzetting door de opdrachtnemer wordt de kartelrand genoemd.
Het decomponeren van het project wordt dus gedaan om het project
beheersbaar en overzichtelijk te houden. Vaak kent een
infrastructuurproject tal van onderdelen die een verschillende functie
hebben, waar verschillende mensen aan werken, waar verschillende
afspraken voor worden gemaakt etc. Door het project in logische
‘brokken’ op te knippen en hier bijvoorbeeld ook de projectorganisatie
op in te richten wordt er overzicht gecreëerd en wordt er voor gezorgd
dat iedereen over hetzelfde praat.
21
Handboek ECO-product Functioneel Specificeren
4.1.2.
Hoe een project te decomponeren?
Een project decomponeren in verschillende objecten dient zorgvuldig te
gebeuren. Enerzijds schept het decomponeren van het project voor een
betere beheersbaarheid, aan de andere kant leidt opdeling tot extra
raakvlakken tussen de objecten die op hun beurt weer beheerst moeten
worden. Hier geldt het credo: “Wie onnodig splijt krijgt spijt”. Doel is
derhalve een optimum te vinden in de opdeling van het project.
Aspecten die bij het decomponeren van een project in objecten
meegenomen dienen te worden zijn:
- De fysieke indeling van het voorliggend ontwerp: Uit welke
onderdelen bestaat het ontwerp?
- Functies: Verschillende onderdelen uit het object vervullen
verschillende functies. Zo is de voornaamste functie van een weg
het afwikkelen van verkeer en is de functie van een viaduct het
kruisen van twee wegen. Deze functies dienen elk te kunnen
worden toegewezen aan afzonderlijke objecten.
- Marktindeling: Om extra organisatorische raakvlakken te vermijden
is het zinvol om te kijken naar de manier waarop de markt is
georganiseerd, om hier zoveel mogelijk op aan te sluiten;
- Bouwwijze en volgorde: Objecten dienen zoveel mogelijk aan te
sluiten op de volgorde van bouwen of dienen los te kunnen worden
gebouwd. Een bepaalde volgordelijkheid in de uitvoering heeft vaak
ook een relatie met de keuze voor soorten en aantallen
contractvormen en het volgordelijk vervullen van de functies.
Onderstaand is een voorbeeld van een opsplitsing van een
weginfrastructuurproject weergegeven. Voor droge
infrastructuurprojecten zal dit een standaard indeling zijn. Bij natte
projecten en projecten waar ook gebiedsontwikkeling onderdeel in van
het project zal de indeling uiteraard anders zijn.
oplossen bereikbaarheidsen leefbaarheidsproblem en
topniveau
A4
Verbreed
systeem niveau
subsysteem niveau
Omgeving
W eg
Kruisingen
Verkeersbeheersing
Verzorgingsplaats
Voorbeeld opsplitsing project A4 Burgerveen – Leiden
4.1.3.
De objecten gerangschikt: de objectenboom
Om het overzicht te bewaren en de relaties tussen de verschillende
objecten inzichtelijk te maken worden deze weergegeven in een
boomstructuur. Deze structuur van objecten wordt een objectenboom
genoemd.
22
Handboek ECO-product Functioneel Specificeren
De objectenboom is hiërarchisch opgebouwd. Hierbij worden, vanuit de
netwerkbenadering van Rijkswaterstaat, de volgende niveaus
onderscheiden:
1. Beleidsniveau
Beschrijving van de samenhang en functionaliteit van het netwerk
en de strategische visie.
2. Topniveau
Beschrijving van probleem, doel, randvoorwaarden en
systeemkeuze op corridorniveau. De eisen op dit niveau staan gelijk
aan het niveau van de MIT-verkenningsfase
3. Systeemniveau
Beschrijving van de bottleneck, het gekozen systeem dat de functie
levert zoals op Topniveau gedefinieerd. De eisen op dit niveau
staan gelijk aan het niveau van de MIT-planstudiefase (begin,
midden of eind)
4. Subsysteemniveau
Beschrijving van de belangrijkste onderdelen waaruit het systeem is
opgebouwd. De eisen op dit niveau staan gelijk aan het niveau van
de MIT-realisatiefase (begin, midden of eind)
Voorafgaand aan het tracébesluit wordt het project tot op
systeemniveau gedefinieerd. In het geval dat het project als
Design&Construct project op de markt wordt gezet, wordt het project
na het tracébesluit door Rijkswaterstaat op subsysteemniveau
gedefinieerd en gedecomponeerd. Na het subsysteemniveau kunnen de
afzonderlijke objecten verder worden gedecomponeerd. Let hierbij wel
op behoud van het overzicht. Een objectenboom dient ter vergroting
van de overzichtelijkheid en beheersbaarheid van een project en niet
om een complexe kluwen van allerhande elementen genereren. Houd
het dus simpel als het simpel kan.
Onderstaand is een voorbeeld van een objectenboom bij een
infrastructuurproject weergegeven:
Abstractieniveau
Beleid
Top
Systeem
Subsysteem
Functie
Hoofdwegennetwerk
Bereikbaarheid
en leefbaarheid
Verbinden
bestemmingen
Autosnelweg
A1
Autosnelweg
A2
Autosnelweg
An
Bottleneck
1
A2
Randweg
Den Bosch
Bottleneck
3
Afwikkelen
wegverkeer
Weg
rijden
Kruising
kruisen
Verkeersmanagementsysteem
regelen en
beheersen
Voorbeeld objectenboom
23
Handboek ECO-product Functioneel Specificeren
Verzorgingsplaats
Omgeving
verzorgen
inpassen
In bovenstaand voorbeeld is op subsysteemniveau het object
“omgeving” apart benoemd. Dit object bevat onderdelen die niet direct
met het functioneren van het systeem van doen hebben, maar wel
onderdeel zijn van het project, zoals compenserende maatregelen
(natuur), te verleggen kabels en leidingen en dergelijke. Op beleidtop- en systeemniveau vallen de omgevingseisen onder de externe
raakvlakeisen.
Verkeerde manieren van opsplitsen:
- Geografische opsplitsing
- Splitsing in rijbanen
Splits functioneel!
4.2
Structuur van het project en de eisen: de
specificatieboom
Naast een onderverdeling van een project in objecten ontstaat ook een
onderverdeling in specificaties: de specificatieboom. Voor elk te
realiseren object wordt een ontwerp gemaakt. Dit betekent dat ook
voor elk te realiseren object eisen dienen te worden opgesteld waaraan
het te ontwerpen object dient te voldoen. Per object wordt daarom een
specificatie ontwikkeld. De verhouding tussen deze afzonderlijke
specificaties wordt inzichtelijk gemaakt door middel van een
specificatieboom. De specificatieboom en de specificaties vormen
samen het Programma van Eisen.
Programma van Eisen
Specificatieboom
Specificaties
Topspecificatie
Systeemspecificatie
Subsysteemspecificaties
Interne raakvlakkenspecificaties
Objectspecificaties
Componentspecificaties
Specificatie object X
Eis 1: ...
Eis 2: ...
...
Eis n: ...
Voorbeeld specificatieboom
In de specificatieboom zijn verschillende soorten eisen te
onderscheiden:
24
Handboek ECO-product Functioneel Specificeren
−
Functionele eisen per systeem en subsysteem
−
−
Randvoorwaarden: extern dwingend opgelegde eisen
Interne en externe raakvlakeisen; hoe past het systeem in de
omgeving en in elkaar?
Aspecteisen; waar dient “verder” rekening mee gehouden te
worden?
−
4.3
Het formuleren van functionele eisen
Als het project is opgedeeld in ‘hapklare brokken’ (middels een
objectenboom) en ook de meest geschikte indeling van de specificaties
is gekozen (de specificatieboom) is de volgende stap het correct
formuleren van de functionele eisen. Hierbij zijn de basis specificaties
een krachtig hulpmiddel.
4.3.1.
Denken in functies
Functioneel specificeren is onmogelijk zonder dat in functies wordt
gedacht. Zoals gezegd, neemt het denken in functies een zeer
belangrijke plaats in binnen functioneel specificeren. Alvorens
functionele eisen kunnen worden geformuleerd dient stil te worden
gestaan bij de functies die het project en de afzonderlijke objecten
binnen het project vervullen.
Door bijvoorbeeld in functie “verbinden oevers” te denken en hieraan
eisen te koppelen wordt wel een nadere analyse van de eisen
uitgevoerd, maar nog niet naar de oplossing, bijvoorbeeld een brug of
een tunnel, gekeken.
Bij het ontleden van functies binnen een project is het van belang een
onderscheid te onderkennen in de gelaagdheid van functies. Het
vervullen van functies op een lager niveau moet leiden tot het vervullen
van de functie op hoger niveau en uiteindelijk tot het vervullen van de
gewenste systeemfunctie, en andersom.
Als het goed is heeft het identificeren van verschillende functies als één
van de peilers gediend voor de opzet van de objectenboom. Het is
verstandig, alvorens over te gaan tot het opstellen van eisen nog eens
goed stil te staan bij de verschillende functies van het project. Dit kan
door middel van het uitvoeren van een functionele analyse, waarbij de
volgende stappen worden genomen:
- Begin op het hoogste niveau van de systeemstructuur met
functionele analyse;
- Bekijk welke basisfuncties uit hogerliggende ontwerpdocumenten
en eisenspecificaties naar voren komen. Indien nodig, formuleer de
basisfunctie zelf;
- Voer vervolgens een functionele analyse op systeemniveau (van
het systeem). Formuleer functies waarmee de bovenliggende
functie wordt vervuld. Ook kunnen nieuwe (neven-) functies
worden geïdentificeerd die voortkomen uit de externe raakvlakken
(wat moet het onderdeel doen met het raakvlak of input uit
omgeving) en gemaakte ontwerpbeslissingen.
25
Handboek ECO-product Functioneel Specificeren
faciliteren
vekeersdoorstrom ing
verkeer
scheiden van
om geving
geleiden
verkeer
geleiden
wegverkeer
geleiden
spoorverkeer
dragen
keren
locale wegen
ongelijkvloers
kruisen
verkeer
regelen
weren
regelen
spoorverkeer
regelen
wegverkeer
Indicatief voorbeeld van functieboom, als resultaat van een functionele analyse
4.3.2.
Van ‘verstopte’ wens naar concrete eis
De gewenste situatie is dat vanaf het begin van het project een
expliciet ontwerpproces is gevolgd, waarbij de eisen zijn vastgelegd,
alle mogelijke oplossingen zijn gegenereerd, hieruit keuzes zijn gemaakt
en vastgelegd, de definitieve keuze wordt uitgewerkt en geverifieerd
aan de eisen. Dit betekent voor de aanvang van de verkenningsfase
beginnen met functioneel specificeren. De nieuwe eisen uit het
ontwerpproces worden vastgelegd waarna het proces weer wordt
herhaald. Daarbij wordt geleidelijk invulling gegeven aan de eisen op
verschillende niveaus van de specificatieboom.
eisen
opties
varianten
ontwerp
groeiende objectenboom
groeiende eisenboom
Overzicht expliciet ontwerpproces
Helaas komt het echter vaak voor dat niet vanaf het begin van het
project een gestructureerde aanpak wordt gevolgd. Eisen worden niet
continu bijgehouden en een expliciet onderscheid in verschillende
niveaus wordt niet gemaakt. Men is tijdens het ontwikkelingsproces tot
het besef gekomen dat de gegeven eisen moeten worden
gestructureerd. Mocht deze situatie zijn opgetreden dan is zijn de
volgende stappen noodzakelijk voor “reparatie”.
26
Handboek ECO-product Functioneel Specificeren
De eerste stap die gevolgd dient te worden bij het formuleren van de
functionele eisen aan het project is het inventariseren van informatie
waaruit eisen kunnen worden geëxtraheerd:
Inventariseer welke actoren bij het project betrokken zijn en welke
eisen en wensen deze stellen;
Inventariseer aanwezige projectinformatie zoals hoger liggende
eisenspecificaties, onderzoeken en ontwerpdocumenten die reeds
aanwezig zijn;
Analyseer de projectinformatie om vast te stellen welke
ontwerpkeuzes vastliggen (bijvoorbeeld tracébesluit, keuze in
kunstwerk, vergunningen).
Analyseer de projectinformatie en destilleer hieruit de impliciet
aanwezige eisen. Relevante items zijn:
van toepassing zijnde eisen van hoger niveau die ofwel impliciet
of expliciet geformuleerd zijn;
randvoorwaarden opgelegd door reeds gekozen oplossingen;
tot het betreffende niveau gedetailleerde raakvlakeisen uit
omgeving e.d. en levenscycluseisen (onderhoudbaarheid,
uitvoerbaarheid, toekomstvastheid)
Vervolgens worden op basis van bovenstaande informatie eisen
geformuleerd. Dit kan gedaan worden aan de hand van een
eisenanalyse waarbij de volgende stappen worden opgenomen:
Begin op het hoogste niveau van de systeemstructuur met de eisen
analyse
Eisen worden afgeleid aan de hand van de functies die het systeem
vervult. Voor elke afgeleide functie worden functionele eisen
geïdentificeerd, zodat alle afgeleide eisen samen voldoen aan de
hoger liggende functie met functionele eis. Voor elke functie wordt
daarbij de vraag gesteld hoe goed de functie dient te worden
verricht. Voor bijvoorbeeld de functie ‘geleiden’ kunnen
capaciteits- en comforteisen worden gesteld.
Ook dienen eisen te worden geïdentificeerd voor de verschillende
aspecten.
Aangezien de specificaties vaak een contractdocument vormen, dienen
de eisen zo eenduidig mogelijk te zijn geformuleerd. Hierdoor worden
interpretatieverschillen voorkomen.
Eigenschap
enkelvoudig
traceerbaar
toetsbaar
indien gekwantificeerd,
voorzien van +/- marges
actueel
27
Toelichting
één eis per eis
herleidbaar naar boven- en onderliggende
eisen ten behoeve van o.a. het
verificatietraject
er dient objectief bepaald te kunnen
worden of aan de eis wordt voldaan of
niet
er dient aangegeven te worden binnen
welke marges een waarde, die bij de
verificatie bepaald wordt, moet vallen om
te voldoen aan de eis
passend bij de laatste projectbaseline
Handboek ECO-product Functioneel Specificeren
eenduidig
uniek
positief geformuleerd
slechts voor één uitleg vatbaar
per onderwerp/aspect komt één eis voor
niet: “niet minder dan”, maar:
“tenminste”
haalbaar
eisen die niet haalbaar zijn voegen niets
toe
consistent
samenhangend en volledig
noodzakelijk
de eis dient toegevoegde waarde te
hebben; zonder die eis gaat er iets mis
oplossingsvrij
een eis dient vrij van (verwijzingen naar)
oplossingen te zijn
van een unieke identificatie t.b.v. identificatie en verwijzing / tracering
voorzien
Deze eigenschappen van eisen worden ook vaak samengevat onder het
begrip SMART.
Specifiek, helder, ondubbelzinnig, nauwkeurig, volledig;
Meetbaar, verifieerbaar;
Acceptabel voor de klant en opdrachtgever;
Realistisch, haalbaar;
Toleranties dienen aangegeven te zijn.
-
Dit is al aan de orde geweest in paragraaf 2.2 van dit handboek.
Bij het opstellen van de specificaties dient mee te worden genomen dat
eisen geld kosten. Daarom moet altijd kritisch worden gekeken naar de
eisen en dienen de volgende vragen te worden gesteld:
- Wie stelt deze eis?
- Waarom?
- Wat miskomt mij als die eis niet wordt gesteld?
Goed en fout….
Goed: Gedurende de realisatie dient te allen tijde ten minste 1
rijbaan per rijrichting voor verkeer opengesteld te blijven.
Fout: Gedurende faseringsstap 4 moet ter plaatse van kilometer
46,1 de rechter rijbaan afgesloten worden om ruimte te bieden
aan de plaatsing van portaal 2 en het aanbrengen van de
detectielussen. De detectielussen moeten in de volgende richting
worden geslepen: linkerrijstrook, middenberm; rechterrijstrook,
buitenberm (ook indien geluidscherm aanwezig).
28
Handboek ECO-product Functioneel Specificeren
Tips & tricks
- Gebruik de term ‘dienen’ voor eisen, niet ‘zullen’ en zeker niet
een combinatie van beiden termen.
- Vermijd het gebruik van de volgende woorden:
voornaamwoorden als hij, zij, wie, etc, bijvoeglijk
naamwoorden en bijwoorden zoals tijdig, precies, ongeveer,
veel, weinig etc.
- Bij het formuleren van eisen kunnen vage eisen naar voren
komen of er wordt een conflict gesignaleerd met andere eisen
of over een bepaalde eis bestaat geen overeenstemming. Deze
moeten worden vastgelegd als aandachtspunten. Zet achter
deze eisen Nog Te Bepalen/Nog overeen te komen (NTB).
- Voorkom opsommingen met open einden (etc., e.d.). Geef aan
dat dingen nog nader moeten worden bepaald (NTB).
- Stel eisen nooit in je eentje op, zorg dat je resultaten spiegelt
bij collega’s.
4.4
Het structureren van eisen
Ten behoeve van de traceerbaarheid van eisen is het van belang ze op
de juiste plaats te zetten in lijn met de specificatieboom. Het is de
bedoeling dat in de toekomst iedere specificatiedocument een uniforme
heeft hebben. Daarnaast zijn er veerschillende soorten eisen te
onderscheiden.
4.4.1.
Welke eis op welk niveau?
Zoals reeds genoemd is de specificatieboom evenals de objectenboom
opgebouwd uit verschillende niveaus:
- beleidsniveau
- topniveau
- systeemniveau
- subsysteemniveau
Met het ‘vullen’ van de specificatieboom met eisen dient derhalve te
worden begonnen op beleidsniveau. Door middel van de eisenanalyse
zoals in de vorige paragraaf beschreven worden eisen afgeleid van
eisen op een hoger niveau. Op deze wijze worden de eisen op
topniveau, systeemniveau en subsysteemniveau ingevuld. Een Eis op
een lager niveau dient altijd zijn te herleiden uit een eis gesteld op een
hoger niveau. Uiteindelijk wordt voor ieder onderdeel van de
specificatieboom een specificatiedocument opgesteld. De kartelrand
bepaald wie daarvoor voor verantwoordelijk is RWS of de
opdrachtnemer.
29
Handboek ECO-product Functioneel Specificeren
Door onderscheid te maken in verschillende niveaus waarop eisen
gesteld worden, wordt men bewust van en kritisch op het feit dat eisen
op het juiste niveau zitten. Overigens is niet altijd goed het niveau van
een bepaalde eis te bepalen. Gezond verstand biedt hier vaak de
uitkomst. Het expliciet onderscheid maken tussen niveaus in eisen leidt
in ieder geval tot een kritische houding ten opzichte van de gestelde
detaileisen. De essentie van zo vroeg mogelijk beginnen met
functioneel specificeren is dat enkel een top-down benadering met
bottum-up reflectie de beste kans geeft op compleetheid.. Hiermee is
een hoop werk te voorkomen ten aanzien van het reconstrueren van
het PVE vlak voor start inkoopproces. Dit voorkomt dure en
inspannende retro-engineeringstrajecten.
Checklist:
- Dus beginnen bij de start van een verkenningstudie
- Zijn de eisen op het gewenste niveau gespecificeerd?
- Bevat de eisenspecificatie geen detaileisen en liggen geen lager
niveau ontwerpkeuzes aan een eis ten grondslag? Als een
eisenspecificatie voor een tunnel wordt geschreven, moet dit
geen eisen bevatten voor detailonderdelen. Hieraan ligt een
ontwerpkeuze ten grondslag. Indien er detaileisen worden
gesteld, zet deze dan in een apart hoofdstuk, liefst in een apart
document.
4.4.2.
Ieder object zijn eigen specificatie
In voorgaande paragrafen is uitgelegd hoe eisen worden opgebouwd
en welke niveaus van eisen er zijn te onderscheiden. Uiteindelijk
worden de eisen per niveau of object gebundeld in een specificatie. Een
specificatie is dus de bundeling van eisen op een bepaald niveau dan
wel voor een bepaald object. De volgende specificaties zijn vrijwel altijd
bij een weginfrastructuurproject te onderscheiden:
- Beleidspecificatie
- Topspecificatie
- Systeemspecificatie
- Subsysteemspecificaties voor de verschillende objecten zoals
kunstwerken, weg, omgeving etc.
Een specificatie kent een standaard opbouw. De inhoudsopgave ziet er
als volgt uit:
Hoofdstuk 1: Inleiding (kader)
Hoofdstuk 2: Van toepassing zijnde documenten
Hoofdstuk 3: Eisen
Hoofdstuk 4: Informatie over eisen
Voor de specificatie op beleidsniveau en topniveau wordt alleen
onderscheid gemaakt in eisen (doelstellingen) en randvoorwaarden.
30
Handboek ECO-product Functioneel Specificeren
Hoofdstuk 1: Inleiding
Gestart wordt met het scheppen van een kader voor het object waarop
de specificatie slaat. Dit houdt in dat ten eerste vastgesteld wordt wat
de scope van het project is en welke plaats betreffend object hierin
inneemt. Ten tweede wordt vastgesteld wat het object inhoudt. Door
dit scherp op het netvlies te krijgen, zijn ook beter de functies van het
te ontwikkelen object te formuleren.
Probeer een zo scherp mogelijk definitie te geven van het te
ontwikkelen object.
Stel zo scherp mogelijk vast wat de grenzen van het te ontwikkelen
object zijn.
Stel vast welke activiteiten wel en niet binnen het project vallen.
De inleiding kent de volgende paragraafindeling:
1.1
Definitie project
1.1.1 Objectdefinitie
1.1.2 Objectgrenzen
1.2
Beschrijving
1.2.1 Bestaande situatie
1.2.2 Gewenste situatie
1.3
Afbakening scope
1.4
Leeswijzer
Hoofdstuk 2: Van toepassing zijnde documenten
Hierbij wordt onderscheid gemaakt in bindende en informatieve
documenten. Bindende documenten zijn aanvullingen op de eisen die in
hoofdstuk 3 van een specificatie staan. Deze zijn, evenals de eisen,
documenten waaraan het ontwerp/product moet voldoen. Het betreft
hier veelal documenten waarin standaard normen en richtlijnen ten
aanzien van bijvoorbeeld het wegontwerp zijn opgenomen. Daarnaast
betreffen het documenten uit de vorige projectfase(n).
ID
B.1
Document
Nota Mobiliteit
Bron
Ministerie van VenW
Voorbeeld bindend document
Informatieve documenten dienen als extra informatie bij het formuleren
van eisen en het maken van het ontwerp, maar zijn niet verplicht om te
gebruiken. Men kan zich er niet op beroepen dat de eisen en het
ontwerp volgens deze documenten zijn opgesteld of ontworpen.
ID
I.1
Document
Kwaliteit functioneren hoofdwegennet
2003 (in concept)
Voorbeeld informatief document
31
Handboek ECO-product Functioneel Specificeren
Bron
RWS-DWW
Hoofdstuk 3: Eisen
De volgende paragrafen dienen in ieder geval in dit hoofdstuk voor te
komen:
3.1 Functionele eisen
3.2 externe raakvlakeisen
3.3 interne raakvlakeisen
3.4 Randvoorwaarden
3.5 Aspecteisen
Naast het formuleren van de eisen, dient aan elke eis aanvullende
informatie te worden toegevoegd voor de traceerbaarheid en
inzichtelijkheid waarmee een beter zicht op compleetheid wordt
verkregen. Dit betreft met name:
de bovenliggende eis: elke eis dient een bovenliggende eis te
hebben, zodat traceerbaar is waarom bepaalde eisen worden gesteld
tot aan de topniveau probleem en doelstellingen. Logischerwijs kan
op topniveau geen bovenliggende eis worden gegeven.
de onderliggende eis: op dezelfde manier als het weergeven van de
bovenliggende eis dient ook de onderliggende eis te worden
weergegeven. Hiermee ontstaat inzicht of betreffende eis nog
verder is uitgewerkt op een lager niveau.
de eisinitiator: per eis moet worden aangegeven welke actor de eis
stelt, zodat helder is met wie moet worden overlegd als een eis
veranderd (of wie wordt boos als niet wordt voldaan aan de eis)
de bron: in welk oorspronkelijk document is de eis gesteld
eventueel, een bijlage met toelichting op de eis in de vorm van
bijvoorbeeld een tekening.
• Eventueel eisen die gevolgen hebben voor het ontwerp doordat er
voorwaarden worden gesteld aan de uitvoering en/of het
onderhoud.
Onderstaand een voorbeeld van de opbouw van een eis:
ID
Afwikkelen verkeer, 2x3
2.01 De verbrede A4 dient te bestaan uit 2x3
Bovenliggende
Onderliggende Eisinitiator
eis
eis
topspec 1.01
topspec 3.01
RWS
rijstroken voor het doorstromend verkeer
Bron
Bijlage
Nota van
Nee
Inlichtingen
d.d.
9/6/03
Voorbeeld opbouw van een eis
32
Handboek ECO-product Functioneel Specificeren
Hoofdstuk 4: Informatie over eisen
Dit hoofdstuk betreft informatie voor de beheersing van het
specificatieproces.
4.1 Verificatiemethode
Hoe wordt aangetoond dat aan de eisen wordt voldaan.
Om de eisen uit de specificatie te kunnen toetsen is er
overeenstemming nodig over de verificatiemethode.
Traceerbaarheidsmatrix
Voorafgaande eisen, voortvloeiende eisen, cross referenties.
4.3 Brondocumenten
Een overzicht van alle brondocumenten waarnaar in het
specificatiedocument wordt verwezen.
ID
Br.1
Document
Ontwerp Tracébesluit A4
Bron
Rijkswaterstaat
Directie Z-Holland
Voorbeeld Brondocument
Nadat een concept specificatie is ontwikkeld dient een toets en review
te worden uitgevoerd. De toets beslaat de controle op de structuur de
van specificatie, de volledigheid van toegevoegde informatie en de
formulering van de eisen. De review wordt uitgevoerd door deskundige
en ervaren medewerkers om te beoordelen of de set van eisen
compleet is. Hierbij dient er voor gewaakt te worden dat men tijdens de
review vervalt in oude fouten. Het resultaat van de review dient niet te
zijn dat er uiteindelijk toch een ontwerp wordt beschreven in het
Programma van Eisen.
4.4.3.
Welke eis in welk vakje: functie-eisen, raakvlakeisen,
aspecteisen en randvoorwaarden
Bij het functioneel specificeren van een project staan de functionele
eisen centraal. Echter kan met slechts het opstellen van functionele
eisen alleen het project niet in zijn volledigheid worden afgedekt. Zoals
genoemd kennen bijvoorbeeld verschillende objecten onderlinge
raakvlakken (bijvoorbeeld tussen enerzijds een weg en anderzijds een
viaduct) Dergelijke raakvlakken worden beschreven in zogenaamde
interne raakvlakeisen. Daarnaast zijn er voor een aantal aspecten zoals
veiligheid, vormgeving en dergelijke eisen te stellen die los van de
primaire functie van het project en de objecten binnen het project
staan. Deze eisen worden beschreven in aspecteisen. Tenslotte zijn er
nog verschillende randvoorwaarden aan bepaalde oplossingsrichtingen
te stellen.
33
Handboek ECO-product Functioneel Specificeren
Door de verschillende soorten eisen te structureren en onder de goede
noemer te brengen ontstaat een gestructureerd, overzichtelijk en
traceerbaar overzicht van soorten eisen binnen het Programma van
Eisen en binnen de afzonderlijke specificaties. Kortom wordt er gebruik
gemaakt van vier soorten eisen om een complete definitie van een
functie mogelijk te maken:
−
Functionele eisen; wat is de functie van het systeem?
−
Interne en externe raakvlakeisen; hoe past het systeem in de
omgeving en in elkaar?
Aspecteisen; waar dient verder rekening mee gehouden te worden?
Randvoorwaarden; extern dwingend opgelegd.
−
−
Hiernavolgend worden deze vier soorten eisen nader toegelicht.
Functionele eisen
In de functionele eisen ligt vast:
Wat het systeem of object dient te doen, c.q. wat de functies zijn
die het object dient te vervullen. Functies zijn werkwoorden, zoals
dragen, inpassen, afwikkelen en beheersen.
Wat de prestatie van de geïdentificeerde functies is. Hierbij dient
antwoord te worden gegeven op vragen als:
- wie?
- wat?
- waar?
- wanneer?
- hoeveel?
- welke? etc.
Dit resulteert in een set van functionele eisen
Indien reeds gealloceerde functies met eisen zijn vastgesteld, kunnen
functies worden afgeleid door de volgende vraag te stellen: Wat is
er nodig voor een goede functie vervulling (bijvoorbeeld goede
verkeersdoorstroming: geleiding, regeling, incidentmanagement).
Een andere methode om afgeleide functies te identificeren is door
naar het pakket aan onderdelen te kijken dat binnen het systeem
normaliter aanwezig is en daarbij vast te stellen welke functies deze
onderdelen vervullen.
Indien aanwezig, vertaal de eisen van de hogerliggende
specificatie(s) door naar deze specificatie.
Ieder onderdeel vervult een eigen functie. Dit gebeurt op alle niveaus in
het systeem: een functie van een tunnelwand is het keren en weren van
grond en water; een functie van bout en moer is het verbinden van
twee onderdelen.
Voorbeeld van een functionele eis:
De ontbrekende schakel in het hoofdwegennet tussen x en y dient te
worden gerealiseerd om doorstroming op de A<x> te kunnen
garanderen (Vtraject = 0,5*Vmax)
34
Handboek ECO-product Functioneel Specificeren
Externe raakvlakeisen: eisen op het raakvlak systeem/omgeving
Bij infrastructuurprojecten dient het te ontwikkelen object te worden
ingepast in zijn omgeving. Het object snijdt of beïnvloedt fysiek
elementen in de omgeving. Er kunnen door externen eisen worden
gesteld in hoeverre de elementen uit de omgeving mogen worden
beïnvloed. Externe raakvlakeisen kunnen worden geïdentificeerd door:
het vaststellen van de onderdelen in de omgeving die door het
nieuw te ontwikkelen object mogelijk wordt doorsneden
het vaststellen van de functies en eisen die vanuit beleid en/of
omgeving worden gesteld aan de objecten
het doorvertalen van de eisen van de eventuele bovenliggende
specificatie(s).
Interne raakvlakeisen: eisen op raakvlakken tussen de verschillende
onderdelen van het systeem
Naast de raakvlakken uit de omgeving, de externe raakvlakken, kunnen
ook interne raakvlakken bestaan. Dit zijn raakvlakken binnen de
grenzen van het te ontwikkelen systeem. Deze ontstaan als het systeem
reeds is opgedeeld in onderdelen (subsystemen, objecten,
componenten en elementen) en een specificatie wordt ontwikkeld voor
een onderdeel. Tussen de onderdelen kunnen raakvlakken bestaan,
deze dienen te worden geïdentificeerd. Bijvoorbeeld het systeem
Verbreding A4 wordt opgesplitst in o.a. de subsystemen kunstwerken
en weg(lichaam). Tussen deze subsystemen kunnen (interne)
raakvlakken bestaan, bijvoorbeeld kunstwerk moet aansluiten op de
weg.
Het belangrijkste type raakvlakken is:
functie
vorm
ruimtelijk
Bij het decomponeren van een project worden interne raakvlakken
geïntroduceerd, bijvoorbeeld tussen het object weg en kunstwerk. Deze
onderdelen dienen uiteraard goed op elkaar aan te sluiten. Raakvlakken
kunnen worden beheerst door middel van raakvlakspecificaties. Hierin
worden de eisen gesteld aan raakvlakken tussen de verschillende
onderdelen. Daarbij dienen alleen de risicovolle raakvlakken te worden
gedefinieerd, om overbodige administratieve handelingen te
voorkomen.
Aspecteisen: eisen op specifieke gebieden die gelden voor het totale
systeem
Naast de functionele eisen en raakvlakeisen worden aspecteisen
geïdentificeerd. Deze beschrijven specifieke eigenschappen van het te
ontwikkelen systeem, die niet direct bijdragen aan de primaire functie.
35
Handboek ECO-product Functioneel Specificeren
Onderstaand is weergegeven voor welke aspecten eisen kunnen
worden gesteld:
Aspect
Veiligheid
Toelichting
Eisen met betrekking tot veiligheid tijdens realisatie en veiligheid in de gebruiksfase van
gerealiseerde objecten, voor zowel de gebruiker als de omgeving
Beschikbaarheid &
Eisen met betrekking tot beschikbaarheid, levensduur en betrouwbaarheid van gerealiseerde
betrouwbaarheid
objecten
Vormgeving
Eisen met betrekking tot uiterlijke vormgeving van gerealiseerde objecten
Milieuhygiëne
Eisen aan stof, geluid, trillingen en stank tijdens de realisatie en gebruiksfase
Uitvoering
Eisen aan de uitvoering en aanpassing van nieuw te bouwen en bestaande objecten
Onderhoud
Eisen met betrekking tot benodigde instandhoudingvoorzieningen en relatie met
onderhoudsprocessen (onderhoudbaarheid)
Duurzaamheid
Eisen met betrekking tot aanpassing van gerealiseerde objecten aan toekomstverwachtingen
Sloop
Eisen met betrekking tot de sloop van te slopen objecten
Gestreefd wordt om deze indeling voor alle te realiseren objecten te
hanteren. Voor bepaalde objecten zullen bepaalde categorieën niet van
toepassing zijn.
In bovenstaand schema staat het aspect ‘uitvoering’ genoemd. Onder
dit aspect worden alle functionele eisen met betrekking tot de
uitvoering genoemd, bijvoorbeeld ten aanzien van de
verkeersdoorstroming in de tijdelijke situatie. Waak er overigens voor
een volledige fasering van de bouw voor te schrijven. Het bedenken
van een slimme fasering binnen de door Rijkswaterstaat gestelde
voorwaarden vormt juist één van de uitdagingen die aan de markt
overgelaten dient te worden.
Randvoorwaarden
Randvoorwaarden zijn van buiten het te realiseren systeem opgelegde
voorwaarden die beperkingen voor de te ontwerpen oplossingen
vormen. Randvoorwaarden kunnen worden gezien als een expliciete
grens van de oplossingsruimte. Dit zijn eisen die vastliggen op een
niveau dat vanuit het project niet te beïnvloeden is. Voorbeelden van
randvoorwaarden zijn opgelegde oplossingen door bijvoorbeeld
waterschappen, gemeenten interne RWS diensten.
Feitelijk vormt deze categorie een soort depot voor eisen die intern of
door de omgeving zijn opgelegd maar eigenlijk op een te vroeg en te
gedetailleerd niveau worden ingebracht.
Voorbeeld:
De systeemkasten voor de wegsignaleringssystemen dienen met een
universele sleutel geopend kunnen worden.
Tips & tricks
- Minimaliseer de randvoorwaarden. Dit om te voorkomen dat
er onnodig vrijheidsbeperkingen in het ontwerp optreden.
- Niet ieder onderdeel (van bijvoorbeeld de aspecteisen) behoeft
per definitie te worden ingevuld. De indeling in verschillende
soorten eisen is bedoeld om structuur aan te brengen en dient
geen nieuwe vragen op te roepen. Gebruik derhalve bij de
indeling van eisen het gezonde verstand.
- Besteed voldoende aandacht aan de raakvlakken tussen
verschillende objecten, inclusief voorwaarden aan grenzen van
de objecten. Deze blijven vaak onterecht onderbelicht
36
Handboek ECO-product Functioneel Specificeren
4.4.4.
Traceerbaar maken van eisen zorgt voor compleetheid
Bij het verder uitwerken van eisen op een lager niveau dienen de eisen
traceerbaar doorvertaald te worden naar gedetailleerdere eisen. Ook
dient aan te worden gegeven door wie een eis is gesteld en waar dit
gedocumenteerd is. Door de traceerbaarheid wordt inzichtelijk gemaakt
waarom een eis wordt gesteld en wordt voorkomen dat overbodige
eisen worden gesteld. De ‘waarom’-vraag is een belangrijk hulpmiddel
om te voorkomen dat overbodige eisen worden gesteld. Hiervoor wordt
bij elke eis in elke specificatie aangegeven wat de bovenliggende eis is.
Hiermee wordt de kans op compleetheid vergroot. Daarnaast is snel
inzichtelijk wat de consequenties zijn van het wijzigen van eisen. Door
het traceerbaar maken van eisen wordt inzichtelijk hoe de
doelstellingen zich uiteindelijk hebben vertaald in gedetailleerdere
eisen.
De relaties tussen eisen kunnen worden aangegeven en bijgehouden in
een aparte traceerbaarheidsmatrix of in de specificaties waarbij achter
elke eis in kolommen wordt aangegeven wat de bovenliggende en
onderliggende eis is.
Voorbeeld traceerbaarheid eisen
topspecificatie
ID
Congestiekans
1.01 De congestiekans op de A4 Burgerveen-
Bovenliggende
Onderliggende
eis
eis
nvt
Leiden dient maximaal 2% te bedragen
systeemspec
2.01
systeemspecificatie
ID
Afwikkelen verkeer, 2x3
Bovenliggende Onderliggende
eis
2.01 De verbrede A4 dient te bestaan uit 2x3
eis
topspec 1.01
rijstroken voor het doorstromend verkeer
4.5
Check of ontwerp voldoet aan eisen: verificatiematrix
Om een zo helder mogelijk overzicht te krijgen van de scores van het
ontworpen en/of gerealiseerde object op de eisen wordt aanbevolen
een verificatiematrix op te stellen. In deze matrix wordt per eis
aangegeven hoe het ontworpen/gerealiseerde object op iedere eis
getoetst zal worden. Nadat het ontwerp is uitgewerkt tot het juiste
detailniveau of het object is gekeurd kan de matrix worden aangevuld
met het resultaat van de verificatie. Zowel de opdrachtgever als de
opdrachtnemer doen dit elk op hun eigen niveau. Het contract bepaald
hoe de opdrachtnemer dient om te gaan met verificatie.
In de verificatiematrix wordt voor elke eis aangegeven of het object
voldoet. In de matrix wordt het volgende aangegeven:
37
Handboek ECO-product Functioneel Specificeren
Eis:
Van toepassing zijnde eis met nummer en titel.
Verificatieniveau:
Hier kan worden aangegeven op welk niveau de verificatie
plaatsvindt of dat verificaties op verschillende niveaus worden
uitgevoerd. Er kan dan bijvoorbeeld worden aangegeven dat de
verificatie op systeemniveau wordt gedaan met een grove
berekeningsmethode, maar dat een uitgebreide analyse nog plaats
moet vinden op laag niveau doormiddel van geavanceerde
berekeningen.
Type verificatiemethode
De te onderscheiden verificatietypen zijn:
- Inspectie: visuele controle of het onderdeel voldoet aan de
gestelde eisen (na uitvoering/ tijdens uitvoering van onderdeel)
- Document inspectie: controle via onderzoek/raadpleging van
documenten (specificatiedocumenten, ontwerpdocumenten,
manuals,(test)rapportages, tekeningen etc)
- Meting: De werking van een systeem aantonen gebruik makend
van (meet en test)instrumenten en geverifieerde input om data
te verzamelen voor latere analyses.
- Analyse (of simulatie): bijvoorbeeld berekeningen en gebruik
van normen om aan te tonen dat wordt voldaan bepaalde
betrouwbaarheid.
- Referentie: de ervaringen die met het onderdeel bij andere
projecten is opgedaan, vormt het bewijs dat wordt voldaan aan
de gestelde eis. Bijvoorbeeld, door goede ervaringen bij andere
projecten met een bepaald voegprofiel heeft RWS vertrouwen
dat het profiel voldoet aan de eisen tav waterdichtheid
gedurende de gehele levensduur.
- Review: bijvoorbeeld door een aantal onafhankelijke experts een
beoordeling laten uitvoeren over een bepaald aspect
- Prototype: bijvoorbeeld, opstelling in Waterloopkundig
Laboratorium
Verificatiemethode
Hier wordt aangegeven hoe wordt aangetoond dat het ontwerp
voldoet aan de eisen. Bijvoorbeeld door het maken van
berekeningen met ESA Prima Win of door het bekijken van
tekeningen etc.
Verificatieresultaat:
Hier wordt achtereenvolgend aangegeven of aan de eis wordt
voldaan (ja/nee), wat de waarde of gekwantificeerd resultaat is en
in welk document staat dat wordt voldaan aan de eisen.
Met het verificatieresultaat worden ook niet gekwantificeerde eisen
gekwantificeerd en kunnen eisen traceerbaar door worden vertaald
naar onderliggende niveaus. Bijvoorbeeld: op systeemniveau werd
als eis geformuleerd minimale sloop woningen. Het ontwerp op
systeemniveau geeft aan dat het verificatieresultaat maximaal 80
woningen is. Dit kan worden meegenomen als eis op lager niveau.
38
Handboek ECO-product Functioneel Specificeren
Een verificatiematrix kan er als volgt uitzien:
eis
verificatie methode
eis
verificatie
verificatie resultaat
type
methode
voldoet
nummer, en
analyse,
..
ja
titel
equivalentie
waarde
rapport
waarde +
rapport xx
niveau
onzekerheidsmarges
inspectie
..
Geluidshinder,
systeem
analyse
Standaard-
ja
-
maximale
maximale
rekenmethode 2
geluidsbelastingen zijn
geluidsbelasting
v/h Reken- en
weergegeven op
Meevoor-
Akoestisch
onderzoeken
tekeningen xx
schriften
-
Verkeerslawaai
hogere waarden
voor woningen en
bestemmingen zijn
vastgesteld, zie bijlage
xx
Grenswaarde
systeem
analyse
NO2
emissiefactoren
ja
geen overschrijding
RIVM met
Milieuonderzoek
verkeersintensit
eiten
afwikkelen,
systeem
snelheid
analyse
ontwerpen
ja
-
volgens ROA
horizontale
boogstralen xx
-
maximale hellingen
-
…
lengteprofielen
dwarsprofiel
tekening xx
Aandachtspunten
- Omgang met risicovolle eisen bij geïntegreerde contracten
Bij geïntegreerde contracten ontstaan wel eens discussies met de
opdrachtnemer over de wijze waarop hij moet gaan aantonen dat hij
voldoet aan de eisen. Het is dan zinvol om voor discussievolle/
risicovolle eisen van tevoren in kaart te brengen op welke wijze de
eisen uit de specificatie worden aangetoond. Bij de inventarisatie
gaat het alleen om de verificatiemethode: verificatieniveau, type en
methode.
-
39
Omgang met uitgangspunten bij verificaties
Bij verificatiemethoden bestaan uitgangspunten die worden gebruikt
om een berekening te kunnen maken. Bijvoorbeeld voor
veiligheidsberekeningen wordt als uitgangspunt genomen dat
vluchtdeuren om de 100m komen. Deze uitgangspunten staan niet
in de verificatiematrix, maar bij de beschrijving van de verificaties
/verificatiedocument. Deze uitgangspunten zijn afgeleide eisen op
lager niveau. Deze moeten daarom bij de verificatierapporten
expliciet worden benoemd!
Handboek ECO-product Functioneel Specificeren
4.6
Verhouding eisen vs normen en richtlijnen
Veel ‘standaard’-eisen ten aanzien van bepaalde objecten zijn
opgenomen in voorschriften: standaard documenten waarin normen en
richtlijnen ten aanzien van een standaard object zijn opgenomen. Om
te voorkomen dat specificatiedocumenten dikke onoverzichtelijke
boekwerken worden dient in de specificatiedocumenten zoveel mogelijk
te worden verwezen naar deze normen en richtlijnen. Documenten
waarin de normen en richtlijnen staan weergegeven zijn opgenomen in
hoofdstuk 1 van de specificatie onder Van Toepassing Zijnde
Documenten.
Momenteel worden in het kader van het opstellen van een aantal
standaardspecificaties voor bepaalde objecten tevens de normen en
richtlijnen behorende bij deze objecten verzameld. Bij deze
inventarisatie is gebleken dat er veel verschillende sets van normen en
richtlijnen in omloop zijn en dat deze niet alle even geschikt zijn om te
hanteren bij het functioneel specificeren. Naast het vervaardigen van
een eenduidige lijst met normen en richtlijnen zullen in de nabije
toekomst tevens de normen en richtlijnen zelf worden vernieuwd.
Daarbij speelt ook de ontwikkeling van Europese standaarden;
Eurocodes.
Er zijn echter een aantal gevallen te onderscheiden waarin eisen uit
voorschriften worden opgenomen in de specificatie, in plaats van te
verwijzen naar de Van Toepassing Zijnde Documenten. Dit vindt plaats
wanneer:
- er meerdere interpretaties van voorschriften mogelijk zijn, en/of
- hierover waarschijnlijk veel discussie zal worden gevoerd, en/of
- het kritieke eisen zijn voor het project.
De eisen die expliciet zijn opgenomen in de specificatie gelden altijd
boven eisen die zijn opgenomen in voorschriften. Dus in geval van
strijdigheid tussen eisen in de specificatie en eisen in voorschriften dient
bij het ontwerpproces altijd de eis in de specificatie van toepassing te
worden verklaard, ook als deze eis strijdig is met een norm of richtlijn
uit de voorschriften.
Indien eisen in voorschriften sterk samenhangen en er veel eisen zijn,
worden deze niet opgenomen in specificatie
Overigens zijn op dit moment veel voorschriften waarin normen en
richtlijnen zijn opgenomen gebaseerd op het traditionele
bouwprocesmodel (het beschrijven van de oplossing). Betreffende
voorschriften dienen in de toekomst opnieuw, en dan functioneel, te
worden geredigeerd.
40
Handboek ECO-product Functioneel Specificeren
4.7
Strijdigheid van (niveau van) eisen: hoe hiermee om
te gaan?
Strijdigheid van niveau van eisen: top-down vs bottom-up
Bij functioneel specificeren dient uit te worden gegaan van de topdown benadering. Dit is niet voor niets. Door namelijk te denken vanuit
de basisfuncties of doelstelling van project en vervolgens top down
eisen af te leiden, kan voorkomen worden dat te snel detaileisen
worden gesteld of overbodige eisen worden meegenomen.
Ook wordt met de hantering van de top-down benadering inzichtelijk
waarom een bepaalde eis wordt gesteld (zie bovenliggende eis), en dat
een dergelijke eis niet zo maar ‘uit lucht kan vallen’. Daarnaast wordt
inzichtelijk hoe de doelstelling met hoofdeisen uiteindelijk zijn vertaald
in een pakket van geconcretiseerde eisen.
Het ideaalbeeld binnen een project is het opstellen van de functionele
specificaties volgens de top-down benadering. De praktijk is echter
weerbarstiger. Vanuit verschillende invalshoeken worden ‘bottom-up’
specifieke en gedetailleerde eisen gesteld ten aanzien van het project.
Dit kan door de omgeving worden gedaan (Waterschappen e.a.), maar
ook intern de projectorganisatie. Technische specialisten die detaileisen
stellen ten aanzien van een bepaald element. Hoe hier mee om te gaan
in het kader van functioneel specificeren?
Allereerst dient bij inbreng van elke detaileis, ongeacht van welke partij
deze afkomstig is een zeer kritische ‘waarom’-vraag te worden gesteld:
“om welke reden dient deze eis opgenomen te worden”. Hiermee
wordt inzicht verschaft in de functie van betreffende eis. Ook kan
hiermee een specifieke eis op functioneel niveau worden gebracht.
Een voorbeeld van een eis waarbij in ieder geval een zeer kritische
’waarom’-vraag bij dient te worden gesteld is de volgende (ontleend
aan de praktijk):
“De ondersabeling van de kolommen moet met een door de
opdrachtgever goed te keuren krimparme kunstharsmortel worden
aagebracht. Deze moet volledig onder de voetplaten van de kolommen
worden aangebracht met een gemiddelde hoogte van +/- 25
millimeter. Na doorharding van de krimparme kunstharsmortel,
moeten de stelbouten zo spoedig mogelijk worden verwijderd, de
gaten worden gevuld met elastische kit en de ankers worden
voorgespannen zodat het portaal cq. uithouder bedrijfsvaardig is
opgesteld.”
Bovenstaand relaas heeft meer weg van een gebruiksaanwijzig dan van
een functionele eis. Waarschijnlijk komt deze eis voort uit gebrek aan
vertrouwen in de opdrachtnemer.
41
Handboek ECO-product Functioneel Specificeren
De enige twee plausibele antwoorden op de ‘waarom’-vraag die leiden
tot het uiteindelijk opnemen van betreffende eis bevinden zich op de
volgende vlakken:
1. Risico’s
2. Extern draagvlak
ad1: Indien het niet opnemen van betreffende eis in de specificatie leidt
tot grote risico’s (die dienen te worden aangetoond) voor het project
dan dient deze eis te worden opgenomen. Dit kunnen uiteraard ook
externe risico’s zijn: Indien bij het kruisen van een waterweg geen eisen
worden gesteld aan het debiet van de waterweg wordt het risico
gelopen dat de kruising te smal wordt gedimensioneerd waardoor de
kans op overstroming bestaat.
ad2: Het betreft hier het verwerven van extern draagvlak met de
omgeving. Tijdens onderhandelingen met omgevingspartijen
(gemeenten, waterschappen e.d.) kunnen door betreffende partijen
gedetailleerde eisen worden gesteld ten aanzien van de eindsituatie of
de situatie tijdens de bouw. Deze kunnen vaak erg legitiem zijn, echter
dient er voor gewaakt te worden dat door het opnemen van dergelijke
detaileisen de vrijheden in het ontwerp drastisch worden beperkt. Het
verdient de aanbeveling deze door de omgeving ingebrachte detaileisen
tot een functioneel niveau terug te brengen waarbij uiteraard wel
gewaarborgd wordt dat zich in de tijdelijke- of eindsituatie geen door
de omgeving ongewenste situaties voordoen.
Functionele strijdigheid tussen eisen onderling
In bepaalde situaties kunnen zich functionele strijdigheden tussen eisen
onderling voordoen. Een voorbeeld hiervan is het behoud van bepaalde
gebouwen in de omgeving versus de dimensionering van een weg. Uit
het ontwerp moet blijken of aan beide eisen kan worden voldaan.
Indien dit niet het geval is dient één van de eisen te worden aangepast.
4.8
Enkele opmerkingen over de periode vóór het
Tracébesluit
In deze handreiking is de nadruk gelegd op het moment vanaf het
Tracébesluit. Voorafgaand aan het Tracébesluit is al een aantal
belangrijke stappen binnen het project gezet. Bijlage 3 geeft een
overzicht van de MIT-procedure en de stappen die daarin gezet
worden. Deze stappen hebben er vaak toe geleid dat een aantal zaken
zoals bepaalde afspraken met de omgeving al in het traject
voorafgaand aan Tracébesluit onomkeerbaar zijn vastgelegd. Dit kan
strijdig zijn met de achterliggende gedachte van Design & Construct,
namelijk maximale vrijheid in oplossingsrichtingen behouden voor
marktpartijen.
42
Handboek ECO-product Functioneel Specificeren
Het spanningsveld: vereist en benodigd versus maximale vrijheid
Ten behoeve van het nemen van beslissingen ten tijde van de
beslismomenten is informatie nodig die in besluitvormingsdocumenten
(verkenningsstudie, startnotitie, Trajectnota/MER,
(ontwerp)tracébesluit, convenanten, vergunningen) integraal
aangeboden wordt. De Tracéwet stelt een aantal eisen aan deze
documenten. Input voor de besluitvormingsdocumenten wordt
verkregen uit de engineeringsproducten.
Bij het Aanlegbesluit worden vanuit de Tracéwet een aantal eisen
gesteld die de vrijheidsgraden in het ontwerp drastisch beperken. Het
betreft hier onder meer de hardheid van de projectgrenzen. Op basis
van het Aanlegbesluit worden gronden onteigend. Dit vraagt om een
harde onderbouwing van het benodigde ruimtebeslag. Daarnaast is het
Aanlegbesluit een harde basis voor het bepalen van de geluidshinder en
de beperkende maatregelen die hiertoe dienen te worden getroffen.
Hierdoor is er na Aanlegbesluit weinig tot geen speelruimte meer over
qua alignement van de weg. Dit zorgt ervoor dat ten tijde van het
Aanlegbesluit op een aantal fronten de bewegingsruimte in het
ontwerp beperkt is.
Ook de intern voorgeschreven nauwkeurigheid van de kostenraming
met een marge van +/- 15% met een trefzekerheid van 70% (1σ) zorgt
ervoor dat er ten tijde van het Tracébesluit vaak een zeer ver
uitgewerkt ontwerp ligt. De kunst is om slechts de delen van het
ontwerp waarvoor dit juridisch benodigd is als hard te beschouwen
(alignement, ruimtebeslag) en de delen waar in de Tracéwet de vrijheid
wordt gelaten (kunstwerken, bouwfasering etc.) deze vrijheid ook
zoveel mogelijk te behouden. De markt moet immers juist voor die
onderdelen de vrijheid worden geboden om een creatieve oplossing te
ontwerpen die binnen de eisen valt.
Naast de voorwaarden gesteld vanuit de Tracéwet en eventuele overige
wetgeving kunnen ook nog andere factoren worden aangewezen die er
voor zorgen dat er op het moment van Tracébesluit een uitgewerkt
ontwerp ligt. Zo zijn er lopende het planstudieproces allerlei afspraken
met de omgeving gemaakt, onder andere om draagvlak te verwerven
voor het project. Met de omgeving (gemeenten, waterschappen,
bewonersgroepen etc.) zijn principe-oplossingen besproken en is
uitgebreid gediscussieerd over zaken als de afmeting van viaducten, de
hoogte van taluds en de vormgeving van geluidschermen. Deze
discussies hebben vaak geleid tot schriftelijke afspraken met de
omgeving omtrent de eindsituatie.
Daarnaast liggen in het tracébesluit de plangrenzen vast. De plangrens
van het tracébesluit is tevens de bestemmingsplangrens en vormt de
basis voor grondverwerving dan wel gerechtelijke onteigening.
43
Handboek ECO-product Functioneel Specificeren
Bovengenoemde zaken zorgen ervoor dat de vrijheidsgraden van het
geometrisch ontwerp drastisch worden ingeperkt. Dit terwijl het bij
geïntegreerde contractvormen als Design & Construct juist de kunst is
om zoveel mogelijk vrijheidsgraden te behouden om zodoende de
markt zoveel mogelijk de vrijheid te geven bij het ontwerp- en
uitvoeringsproces en zo creatieve en slimme oplossingen uit de markt te
genereren.
Hoe nu om te gaan met dit spanningsveld binnen een project? Dit is
lastig, maar wel één van de voornaamste bepalers van het succes van
een Design & Construct project. Het maximaliseren van de ontwerp- en
uitvoeringsvrijheid voor marktpartijen behoort bij deze projecten
prioriteit nummer één te hebben. Dit geldt zowel voor het proces
voorafgaand (trajectnota/MER, ontwerp tracébesluit) als na
tracébesluit.
Allereerst dient te allen tijde bij elke handeling in het proces een zeer
kritische ‘waarom’-vraag te worden gesteld. “Waarom leggen we
bepaalde zaken nu al vast?” Voor een aantal onderwerpen zal het
antwoord op deze vraag klip en klaar zijn. In deze gevallen zijn de
redenen om zaken vast te leggen vaak:
- risicobeheersing
- draagvlakverwerving
Echter voor een aantal onderwerpen zal de “waarom” vraag niet direct
tot een eenduidig en legitiem antwoord leiden. Met het onomkeerbaar
vastleggen van bepaalde oplossingen wordt de vrijheid van de markt
om in geval van Design & Construct een creatieve oplossing te
bedenken ingeperkt waardoor kansen voor bepaalde optimalisaties qua
kosten, hinder, levensduur etc. worden gemist. De optimalisaties na
tracébesluit bevinden zich voornamelijk op het vlak van uitvoering,
bouwmethode, vormgeving van de kunstwerken en fasering. Aangezien
het geometrisch ontwerp min of meer vastligt zijn de vrijheden qua
hoogteligging van een weg beperkt.
Voorbeeld
In de onderhandeling met de gemeente x vraagt de gemeente om inzicht te
verschaffen in de maatvoering van viaduct y. De gemeente staat een minimale
maatvoering (breedte + hoogte) voor vanwege de sociale veiligheid. Door
Rijkswaterstaat wordt een principe-oplossing ontworpen, om aan de gemeente
inzichtelijk te maken hoe hun wensen in principe kunnen worden vormgegeven.
De kunst is om deze principe-oplossing niet te laten evolueren tot dé oplossing,
waarmee opeens naast de maatvoering bijvoorbeeld ook de plaats van de
kolommen al vaststaat terwijl niemand daar om vroeg.
44
Handboek ECO-product Functioneel Specificeren
Een middel om bij projecten die in de vorm van Design & Construct op
de markt worden gezet de maximale vrijheid te garanderen is het
denken in functies in plaats van oplossingen. Een (water)weg heeft als
voornaamste functie het afwikkelen van verkeer, een viaduct heeft als
voornaamste functie het kruisen van verkeersstromen, een
geluidscherm heeft als voornaamste functie het reduceren van de
geluidsoverlast tot een bepaald niveau. Door in functies te denken
wordt de markt de vrijheid geboden een slimme oplossing te genereren
die voldoet aan de functionele vereisten.
Tips & tricks
- Stel bij elke handeling die zorgt voor vermindering van de
vrijheidsgraden in het ontwerp een zeer kritische WAAROM?vraag.
- Beoordeel bij elke beslissing in hoeverre de vrijheid van de
markt qua oplossing wordt ingeperkt. Zo ja, dan moeten hier
zwaarwegende redenen voor zijn.
- Zorg dat principe-oplossingen ook principe-oplossingen blijven
- Giet niet alles in oplossingen, maar denk juist in functies.
Principe-oplossingen dienen alleen maar om inzicht te krijgen
in de effecten van de functionele vereisten.
45
Handboek ECO-product Functioneel Specificeren
5. Bijlage 1: Literatuurlijst
...............................................................................
Callanish (2002) Expliciet werken: Programma van Eisen met Systems
Engineering. Rijkswaterstaat Directie Zuid-Holland, Projectbureau A4,
Leidschendam
Rijkswaterstaat DZH (2003) Systems Engineering: Ten behoeve van het
opstellen van het Programma van Eisen (concept). Rijkswaterstaat
Directie Zuid-Holland, Projectbureau A4, Leidschendam
Rijkswaterstaat, Verslag Studiemiddag Functioneel Specificeren 24 juni
2003
Werkgroep Inkoopproces (2002) Afwegingsmodel inkoopproces.
Rijkswaterstaat Hoofdkantoor, Den Haag
Ministerie van EZ, VROM en V&W (2003) Perspectief voor de bouw.
Ministerie van EZ, VROM en V&W, Den Haag
Rijkswaterstaat (2004) Ondernemingsplan: Doorpakken, wel degelijk
(concept). Rijkswaterstaat, Den Haag
Bouwdienst Rijkswaterstaat (2002) Handleiding specificeren eisen.
Bouwdienst Rijkswaterstaat, Utrecht
Rijkswaterstaat DZH (2002) Architectuurdocument
Aanbestedingsdossier Burgerveen – Leiden. Rijkswaterstaat Directie
Zuid-Holland, Projectbureau A4, Leidschendam
46
Handboek ECO-product Functioneel Specificeren
6. Bijlage 2: Definities
...............................................................................
Aspecteisen
Aspecteisen beschrijven eigenschappen van een systeem die niet direct
bijdragen aan zijn functie. Deze eisen zijn nodig om reeds
eigenschappen te beschrijven die het te ontwikkelen systeem moet
hebben om tot een overall niveau van kwaliteit of bevrediging van
klant te komen. Deze eisen worden in een later stadium op lager niveau
vertaald in(deel)functies en (deel)oplossingen. Aspecteisen hebben
betrekking op onder andere onderhoudbaarheid, uitvoerbaarheid
esthetica.
Configuratie (ISO10007)
De configuratie bestaat uit de functionele en materiële eigenschappen
van een product, zoals omschreven in technische documentatie en
gerealiseerd in het product.
Configuratiebeheersing
Wijzigingen beheer (zie Verzoek Tot Wijziging)
Eis
Een eis is een beschrijving van een oplossingsvrije deelprestatie, in de
vorm van een enkelvoudige, gebiedende zin. In iedere eis hoort het
woord ‘dient’ of ‘dienen’ te staan.
Functie
Een functie is een eigenschap(werking), die het systeem of deelsysteem
moet hebben om zijn prestatie te leveren. Functies zijn werkwoorden.
Functionele eisen
Functionele eisen beschrijven in kwalitatieve en kwantitatieve termen
wat het systeem of onderdeel en in welke omstandigheden moet doen.
Integreren
de optelling van de definitieve ontwerpen van de onderliggende
objecten op dusdanige wijze dat deze zijn in te passen in het definitief
ontwerp van het bovenliggende object. Bijvoorbeeld: De keuken van
een nieuw huis wordt ontworpen door een keukenleverancier, de
architect ontwerpt het totale huis. Past nu de keuken in het huis?
Object
Een object is een fysiek/tastbaar onderdeel van het (sub)systeem, dat
een oplossing is voor de gedefinieerde functie(s). Objecten zijn
zelfstandige naamwoorden.
Ontwerpen/engineering
Ontwerpen is het inhoudelijke en creatieve proces van specificeren,
definiëren, kiezen en uitwerken en verifiëren.
47
Handboek ECO-product Functioneel Specificeren
Programma van Eisen
Het programma van eisen is een gestructureerde verzameling van
specificaties, waarin de gewenste prestatie (kwaliteit) van het te maken
systeem in de vorm van eisen is vastgelegd.
Raakvlak
Er zijn interne en externe raakvlakken. Interne raakvlakken zijn de
inhoudelijke verbanden binnen het systeem. Externe raakvlakken zijn de
inhoudelijke verbanden met het systeem en zijn omgeving. Deze
raakvlakken worden vastgelegd in de vorm van raakvlak specificaties.
Een populaire beschrijving van een raakvlak is: “Daar waar het mis
gaat.” Bijvoorbeeld: In de keuken komt een op maat gemaakt
aanrechtblad van notenhout, geleverd door een timmerman, de
aanrechtkastjes zijn de standaard kastjes van de keukenleverancier. De
keukenleverancier en de timmerman leggen de eisen vast in de vorm
van een raakvlakspecificatie zodat het aanrechtblad past op de
keukenkastjes.
Randvoorwaarden
Randvoorwaarden zijn van buiten het (deel)systeem opgelegde
voorwaarden die beperkingen voor de te ontwerpen oplossingen
vormen. Randvoorwaarden kunnen worden gezien als een expliciete
grens van de oplossingsruimte. Dit zijn vaak eisen die vastliggen op een
niveau dat vanuit het project niet te beïnvloeden is. Voorbeelden van
randvoorwaarden zijn tijdrestricties, financiële voorwaarden, wetten,
beschikbare technologieën en inpassingseisen.
Specificatie
Een specificatie is een verzameling van eisen waarin voor een
samenhangend deel van functies de eisen zijn vastgelegd die de
prestatie (kwaliteit) van het systeem (of een deelsysteem daarvan)
beschrijven.
Systeem
Een systeem is een samenhangend geheel van functies welke op basis
van een klantbehoefte een prestatie moet leveren, in een omgeving,
gedurende zijn lifecycle.
Systems Engineering
De managementactiviteit die zorgdraagt voor de procesmatige
beheersing van het inhoudelijke ontwerpproces.
Toelichting
Technische documentatie die de configuratie omschrijft betreft zowel
de eisen in specificaties als het ontwerp zelf zoals vastgelegd in
tekeningen en configuratie bepalende ontwerprapporten.
Uitgangspunten
Veronderstellingen die men aanneemt om met het ontwerpproces te
kunnen beginnen. Gedurende het ontwerpproces moet worden
48
Handboek ECO-product Functioneel Specificeren
aangetoond dat de uitgangspunten juist zijn, of dat deze veranderd
moeten worden.
Valideren
Het valideren is een meer subjectieve toets van een
engineeringproduct. Vragen aan de opdrachtgever: “Is dit wat u
bedoelde?” Kan gaan in de vorm van een review met de
opdrachtgever.
Verifiëren
Het toetsen van een definitief ontwerp voor een bepaald object tegen
de eisen van de betreffende specificatie voor het object, middels vooraf
gedefinieerde verificatiemethodes.
Verificatiemethodes
Verschillende verificatiemethodes zijn: equivalentie, review, analyse
(berekening), praktijktest, prototypen, simulatie.
Verzoek Tot Wijziging
Een Verzoek Tot Wijziging is een verzoek of voorstel om een
‘bevroren’ 5 configuratie baseline te wijzigen volgens een gedefinieerd
proces.
Vraagspecificatie
De vraagspecificaties is het geheel aan eisen dat aan levens-cyclus
(delen) van product wordt gesteld.
Werkpakket
Set van samenhangende activiteiten voor een object met gedefinieerde
input en output. Met werkpakketten kan men het verband leggen
tussen inhoud, tijd en geld.
Work Breakdown Structure
Hiërarchie van werkpakketten die de activiteiten beschrijven die verricht
moeten worden voor de gedefinieerde objecten.
5
'Bevroren' betekent juist niet dat iets niet meer kan veranderen. Je bevriest iets om het,
beheerst, te kunnen veranderen.
49
Handboek ECO-product Functioneel Specificeren
7. Bijlage 3: Functioneel specificeren in relatie tot de
MIT-procedure
...............................................................................
De MIT-procedure
Een infrastructuurproject doorloopt een bepaalde cyclus. Deze loopt
van verkenning waar het probleem in de brede zin wordt verkend, via
planstudie waar verschillende oplossingsvarianten worden afgewogen,
naar de uiteindelijke realisatie van het project.
1) Intake-besluit
Verkenningsfase
Verkenningstudie
2) Opdracht tot uitvoeren
van planstudie
Planstudiefase
Startnotitie
Trajectnota/MER
(Ontwerp) Tracé Besluit
Standpuntbepaling
voorkeurstracé
3) Tracébesluit
4) Procedures rond
Realisatiefase
Convenanten
5) Uitvoeringsbesluit
Vergunningen
Realisatie
6) Oplevering
Deze fasering is ook weergegeven in de procedure van het
Meerjarenprogramma Infrastructuur en Transport, de zogenaamde
MIT-procedure. Voor regionale en lokale projecten geldt de MITprocedure alleen voor projecten die meer kosten dan 11,34 miljoen
euro; de zogenaamde GDU-grens, waarbij GDU staat voor gebundelde
doeluitkering. Projecten die minder kosten dan dit bedrag, dienen te
worden uitgevoerd door de verantwoordelijke bestuurders, die een
beroep kunnen doen op de GDU.
In de MIT-procedure worden naast de drie bovengenoemde fasen zes
beslismomenten binnen een infrastructuurproject gemarkeerd. Er is
geen automatische doorstroming van de ene naar de andere fase; bij
elk beslismoment vindt de afweging plaats of de MIT-procedure voor
het betreffende project moet worden doorgezet.
De procedure start met een intake-besluit, waarmee de Minister het
probleem voorlopig erkent. Dan volgt de fase van verkenning. Hierbij
50
Handboek ECO-product Functioneel Specificeren
wordt het probleem grondig onderzocht en worden
oplossingsrichtingen bepaald. De initiatiefnemers hiervoor kunnen
variëren van een regionale directie van Rijkswaterstaat tot een college
van burgemeester en wethouders. Aan het eind van de verkenning
moet duidelijk zijn wat de alternatieven zijn, of betrokkenheid van de
rijksoverheid noodzakelijk is en, zo ja, wie er nog meer bij de verdere
uitwerking betrokken is. Dan volgt het tweede beslismoment: wel of
geen opdracht tot het uitvoeren van een planstudie. Hiermee wordt het
probleem al dan niet definitief erkend. In principe is deze fase voor alle
verkeers- en vervoersprojecten gelijk.
De planstudie bestaat uit twee delen. In het eerste deel wordt
onderzocht wat er moet gebeuren om het verkeers- en
vervoersprobleem aan te pakken (de planvorming, het wat). Hierbij
wordt nadrukkelijk ook gekeken naar zaken als inpassing, milieu,
ruimtegebruik, verkeersveiligheid en economische effecten. Deze fase
wordt afgesloten met een tracé- of projectbesluit. In het tweede deel
van de planstudie wordt het project voorbereid voor de uitvoering (het
'hoe'). Bij regionale/lokale projecten wordt een planstudie uitgevoerd
door of in opdracht van de initiatiefnemer, de verantwoordelijke
bestuurders.
Bij projecten die een Tracéwetprocedure moeten doorlopen, is de
startnotitie het begin van de planvorming. Daarna volgt de trajectnota,
die samen met de inspraak en de adviezen over deze nota leidt tot het
standpunt van de Minister over het voorkeurstracé. Samen met de
Minister van Volkshuisvesting, Ruimtelijke Ordening en Milieubeheer
(VROM) wordt uiteindelijk een tracébesluit genomen (beslismoment
drie). In de regel moet hierbij een Milieueffectrapport (MER) worden
gemaakt. Wanneer een traject niet onder de Tracéwet valt, wordt bij
beslismoment drie gesproken over een projectbesluit. Of en wanneer
een project onder de Tracéwet valt, verschilt per vervoerwijze.
Als de technische en de procedurele voorbereiding zijn voltooid (wat
wordt aangeduid met 'procedures rond'), kan de planstudie worden
afgerond (beslismoment vier). Hierna kan de uitvoering ter hand
worden genomen. Of dat daadwerkelijk gebeurt, is afhankelijk van de
vraag of er geld beschikbaar is in het totale programma. Als dat niet het
geval is, wordt het project in de wacht gezet totdat de financiering
rond is. Bij een Tracéwetplichtig project moet maximaal tien jaar na het
nemen van het tracébesluit met de uitvoering begonnen zijn.
Pas als de financiering rond is, kan worden begonnen aan de
realisatiefase. Het begin van de uitvoering kenmerkt zich door het
uitvoeringsbesluit (beslismoment vijf). Bij railprojecten en regionale en
lokale infrastructuur is dit een besluit tot het afgeven van een
beschikking op de subsidieaanvraag. Bij beslismoment zes wordt het
project opgeleverd (hoofdwegen, hoofdvaarwegen) en wordt het
laatste deel van de subsidie uitgekeerd. Het project verdwijnt daarna uit
het MIT-projectenboek.
51
Handboek ECO-product Functioneel Specificeren
8. Bijlage 4: Format specificatie
...............................................................................
Project <naam>
<niveau>
Specificatie <object>
Datum:
Versie:
Opsteller:
Beheerder:
Status:
Bestand:
52
<ntb>
<ntb>
<ntb>
<ntb>
Concept
Handboek ECO-product Functioneel Specificeren
Inhoudsopgave
.......................
53
Handboek ECO-product Functioneel Specificeren
Voorwoord
...............................................................................
Het opstellen van het programma van eisen voor een lijninfrastructureel
project is complex. Dit wordt onder andere veroorzaakt door inpassing
van de weg in zijn omgeving en het uitgangspunt dat het programma
van eisen de ontwerpvrijheid zo min mogelijk moet beperken.
Bij dit project is gekozen om het programma van eisen op te stellen met
behulp van Systems Engineering (SE). SE is een manier van werken,
gericht op integrale projectbeheersing gedurende de gehele lifecycle
van een object, van ontwerp tot en met de gebruiks-/sloopfase.
FASE 1
eisen
FASE 4
ontwerp
Hogere abstractieniveaus
traceren
decomponeren
integreren
afleiden
evalueren
kiezen
inspecteren
keuren
verifiëren
reduceren
FASE 1
eisen
traceren
FASE 2
opties
decomponeren
FASE 3
varianten
FASE 4
ontwerp
afleiden
FASE 5
uitvoering
FASE 6
gebruik/
onderhoud
FASE 7
sloop/
upgrade
integreren
Lagere abstractieniveaus
FASE 1
eisen
FASE 4
ontwerp
Kenmerkend voor SE is dat het project/object opgeknipt wordt in een
aantal niveaus (top-, systeem-, subsysteem, object- en
componentniveau). De niveaus onderscheiden zich van elkaar door een
bepaalde diepgang, het abstractieniveau, zoals in de figuur hiernaast is
aangegeven. Per niveau wordt een vast aantal ontwerpstappen (fasen)
doorlopen (eisen, opties, varianten, ontwerp, eventueel ook uitvoering,
onderhoud en sloop/upgrade). Het voorliggende document vormt een
afgerond onderdeel van een dergelijke ontwerpstap op een bepaald
niveau. In onderstaand schema is de positie (grijstint) van het
document aangegeven in de grotere context.
<netwerk>
<corridor>
<systeem>
<subsysteem 1>
<subsysteem 2>
<subsysteem 3>
<object <object <object
<object <object <object
<object <object <object
1.1>
54
1.2>
1.3>
2.1>
2.2>
2.3>
Handboek ECO-product Functioneel Specificeren
3.1>
3.2>
3.3>
Inleiding
...............................................................................
8.1
Definitie project
8.1.1.
Objectdefinitie
8.1.2.
Objectgrenzen
8.2
Beschrijving
8.2.1.
Bestaande situatie
8.2.2.
Gewenste situatie
8.3
Onderdeel
Afbakening scope
Binnen scope
8.4
8.4.1.
Buiten scope
Leeswijzer
Inleiding
In deze paragraaf wordt toegelicht hoe de specificatie is opgesteld.
Kenmerkend voor deze specificatie is de indeling naar diverse soorten
eisen en de samenhang tussen de eisen. De eisen vallen uiteen in de
volgende typen eisen:
functionele eisen;
externe en interne raakvlakeisen;
randvoorwaarden;
aspecteisen.
8.4.2.
Functionele eisen
Functionele eisen geven eisen aan de functionele eigenschappen c.q. de
prestatie van <object> na realisatie.
55
Handboek ECO-product Functioneel Specificeren
8.4.3.
Externe en interne raakvlakeisen
Externe en interne raakvlakeisen zijn raakvlakken met andere en/of
toekomstige werkzaamheden. Het ontwerp dient te voldoen aan deze
eisen om werkzaamheden van derden niet te verstoren.
Externe raakvlakeisen: eisen op het raakvlak systeem/omgeving van
het project <naam>
Interne raakvlakeisen: eisen op raakvlakken tussen de verschillende
onderdelen van het systeem
8.4.4.
Randvoorwaarden
Randvoorwaarden zijn eisen die bij aanvang van een project al extern
worden opgelegd. Deze eisen kunnen op geen andere wijze worden
ondervangen dan door ze op te nemen als randvoorwaarden. Het kan
zijn dat deze eisen dusdanig duur of beperkend zijn dat het gewenst is
ze ter discussie te stellen bij de instantie die ze wil opleggen. De
randvoorwaarden worden wel benoemd in de specificaties en worden
doorvertaald naar lager niveau onderdelen.
8.4.5.
Aspecteisen
Naast de functionele eisen en raakvlakeisen worden aspecteisen
geïdentificeerd. Deze beschrijven specifieke eigenschappen van het te
ontwikkelen systeem, die geen directe bijdrage leveren aan de primaire
functie.
Aspect
Veiligheid
Toelichting
Eisen met betrekking tot veiligheid tijdens realisatie en veiligheid in de
gebruiksfase van gerealiseerde objecten, voor zowel de gebruiker als
de omgeving
Eisen met betrekking tot beschikbaarheid, levensduur en
betrouwbaarheid van gerealiseerde objecten
Eisen met betrekking tot uiterlijke vormgeving van gerealiseerde
objecten
Eisen aan stof, geluid, trillingen en stank tijdens de realisatie en
gebruiksfase
Eisen aan de uitvoering en aanpassing van nieuw te bouwen en
bestaande objecten
Eisen met betrekking tot benodigde instandhoudingvoorzieningen en
relatie met onderhoudsprocessen (onderhoudbaarheid)
Eisen met betrekking tot aanpassing van gerealiseerde objecten aan
toekomstverwachtingen
Eisen met betrekking tot de sloop van te slopen objecten
Beschikbaarheid &
betrouwbaarheid
Vormgeving
Milieuhygiëne
Uitvoering
Onderhoud
Duurzaamheid
Sloop
56
Handboek ECO-product Functioneel Specificeren
Van toepassing zijnde documenten
...............................................................................
8.5
Type
Code
Bindende documenten
Titel
Datum/
organisatie
Versie
8.6
Type
Code
Informatieve documenten
Titel
Datum/
Versie
57
Handboek ECO-product Functioneel Specificeren
organisatie
Eisen
...............................................................................
8.7
8.7.1.
Functionele eisen
<functie x>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.7.2.
<functie y>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.7.3.
<functie z>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
58
Handboek ECO-product Functioneel Specificeren
8.8
8.8.1.
Externe raakvlakeisen
Raakvlak <object x> - <omgevingselement a>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.8.2.
Raakvlak <object x> - <omgevingselement b>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.8.3.
Raakvlak <object x> - <omgevingselement c>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
59
Handboek ECO-product Functioneel Specificeren
8.9
8.9.1.
Interne raakvlakeisen
Raakvlak <object x> - <object p>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.9.2.
Raakvlak <object x> - <object q>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.9.3.
Raakvlak <object x> - <object r>
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
60
Handboek ECO-product Functioneel Specificeren
8.10 Randvoorwaarden
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.11 Aspecteisen
8.11.1.
Veiligheid
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.11.2.
Beschikbaarheid & betrouwbaarheid
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
a)
ID
Omschrijving
61
Beschikbaarheid
Handboek ECO-product Functioneel Specificeren
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
b)
Levensduur
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
c)
Betrouwbaarheid
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.11.3.
ormgeving
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
62
Handboek ECO-product Functioneel Specificeren
8.11.4.
Milieuhygiëne
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
a)
Stof
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
b)
Geluid
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
c)
Trillingen
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
63
Handboek ECO-product Functioneel Specificeren
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
d)
Stank
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.11.5.
Uitvoering
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.11.6.
Onderhoud
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
64
Handboek ECO-product Functioneel Specificeren
8.11.7.
Duurzaamheid
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
8.11.8.
Sloop
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
ID
Omschrijving
Bovenl. Eis
Onderl. eisen
Eisinitiator
Bron
65
Handboek ECO-product Functioneel Specificeren
Informatie over eisen
...............................................................................
8.12 Brondocumenten
Type
Code
/ ID
Titel
Datum/ organisatie
Versie
Beleidsnota’s op
rijksniveau
Beleidsnota’s op
provinciaal
niveau
Beleidsnota’s op
regionaal en
gemeentelijk
niveau
Hogerliggende
engineeringdocumenten
Overig
Besluitnota
66
Handboek ECO-product Functioneel Specificeren
Bijlagen bij de eisen
...............................................................................
67
Handboek ECO-product Functioneel Specificeren
Knelpunten/discussiepunten/opmerkingen
...............................................................................
68
Handboek ECO-product Functioneel Specificeren