Stappenplan van projectopdracht tot Vraagspecificatie

Transcriptie

1 Stappenplan van projectopdracht tot Vraagspecificatie Systems Engineering voor RWS projecten Datum 1 januari 2011 Versie Stappenplan van Projectopdracht tot Vraagspecificatie Structureren project Vaststellen klantvraag Ontwikkelen systeem Uitwerken Vraagspecificatie P1 Analyseren projectopdracht K1 Analyseren problemen en definiëren doelstellingen S1 Vastleggen bestaande situatie S2 Bepalen verificatiestrategie S3 Gebruiken Basisspecificaties en RBAs Bepalen inkoopstrategie Bepalen contractbeheersingsstrategie P2 Beheren baselines K2 Analyseren stakeholders S4 Analyseren Specificeren systeem Bepalen aanbestedingsprocedure P3 Structureren werkpakketten en producten K3 Verzamelen klanteisen S7 Verifiëren S6 Ontwerpen V1 Bepalen oplossingsruimte Vraagspecificatie V2 Bepalen scope Vraagspecificatie P4 Structureren organisatie K4 Bepalen validatiestrategie S5 Structureren en alloceren V3 Opstellen Vraagspecificatie Opstellen projectplan K5 Opstellen klanteisen specificatie S8 Opstellen systeemspecificatie(s) V4 Borgen kwaliteit Vraagspecificatie P5 Beheren scope K6 Valideren S9 Beheren eisen V5 Beheren Vraagspecificatie I1 Bepalen inkoopstrategie ingenieursdiensten Inkopen Ingenieursdiensten I2 Bepalen WBS in het contract I3 Opstellen Vraagspecificatie ingenieursdiensten

2 Pagina 2 van 42

3 Stappenplan van projectopdracht tot Vraagspecificatie Systems Engineering voor RWS projecten Datum 1 januari 2011 Status Versie Dienst Infrastructuur Afdeling Ontwikkeling Infrastructuur - Gijs Schimmel - Vincent Kramer Wijzigingen Versie 1.1 tov versie Verbeterde opmaak - s laten terugkoppelingen zien Wijzigingen Versie Het stappenplan is beschouwd als een verzameling procesbeschrijvingen op het gebied van SE. In dit licht zijn verschillende activiteiten en processen anders geformuleerd. - Stap P2 is vervangen door Beheren Baseline; originele inhoud is verplaatst naar S5 - De beschrijvingen van de stappen S4, S5, S6 en S7 zijn geheel herzien. - De validatiestappen (onderaan het stappenplan) zijn herschreven. Deze stappen geven nu meer nadruk op het beheren van eisen en specificaties. - Relaties met de IPM-rollen en SE rolprofielen zijn in H6 opgenomen. Wijzigingen Versie (Procesbibliotheek) - Geen Wijzigingen Versie (versie is de procesbibliotheek) - Tekstuele fouten zijn hersteld.

4 Inhoud Inhoud 4 Inleiding 5 1. Structureren project 8 P1 Analyseren projectopdracht 9 P2 Beheren baselines 9 P3 Structureren werkpakketten en producten 10 P4 Structureren organisatie 11 P5 Beheren scope Vaststellen van de klantvraag 12 K1 Analyseren problemen en definiëren doelstellingen 13 K2 Analyseren stakeholders 13 K3 Verzamelen klanteisen 14 K4 Bepalen validatiestrategie 15 K5 Opstellen klanteisen specificatie 16 K6 Valideren Ontwikkelen van het systeem 18 S1 Vastleggen bestaande situatie 20 S2 Bepalen verificatiestrategie 20 S3 Gebruiken basisspecificaties en RBA s 21 S4 Analyseren 22 S5 Structureren en alloceren 24 S6 Ontwerpen 26 S7 Verifiëren 27 S8 Opstellen systeemspecificatie(s) 28 S9 Beheren eisen Uitwerken Vraagspecificatie 30 V1 Bepalen oplossingsruimte Vraagspecificatie 31 V2 Bepalen scope Vraagspecificatie 32 V3 Opstellen Vraagspecificatie 33 V4 Borgen kwaliteit Vraagspecificatie 34 V5 Beheren Vraagspecificatie Inkopen van ingenieursdiensten 36 I1 Bepalen inkoopstrategie ingenieursdiensten 36 I2 Bepalen WBS in het contract 37 I3 Opstellen Vraagspecificatie ingenieursdiensten Relaties van het Stappenplan 40 Pagina 4 van 42

5 Inleiding Het voorliggende document geeft activiteitenbeschrijvingen voor de generieke stappen die worden doorlopen binnen een project van Rijkswaterstaat bij het toepassen van Systems Engineering. De reikwijdte omvat elk mogelijk RWS-project in elke mogelijke projectfase, vanaf projectopdracht tot en met het uitwerken van de Vraagspecificatie. De activiteiten-beschrijvingen geven invulling aan de wijze waarop de processtappen uit de Leidraad voor Systems Engineering binnen de GWW-sector, versie 2.0 worden toegespitst op de projectprocessen en de projectorganisaties van Rijkswaterstaat. De activiteitenbeschrijvingen zijn afgeleid uit het generieke stappenplan Systems Engineering voor RWS-projecten (zie Figuur 1). In het schema wordt onderscheid gemaakt tussen de stappen ten behoeve van het structureren van het project, het vaststellen van de klantvraag, het ontwikkelen van het systeem, het uitwerken van de Vraagspecificatie en het inkopen van ingenieursdiensten. Aanleiding voor dit stappenplan en de activiteitenbeschrijvingen is de regelmatig terugkerende vraag vanuit projectorganisaties: Wat moet ik nú doen?, als het gaat om het toepassen van Systems Engineering binnen een project. We hebben daarom een generiek en overzichtelijk stappenplan gemaakt dat in elke projectomgeving, elke projectsituatie en elke projectfase toepasbaar is: van start planstudie tot aan contractvoorbereiding. Daarom ook activiteiten-beschrijvingen die los staan van projectcontext en die principes uit de Leidraad SE v2.0 vertalen naar projectactiviteiten. Dit stappenplan is onderdeel van de WerkWijzer Aanleg. Hoe dient u dit stappenplan en de activiteitenbeschrijvingen te gebruiken? Dit stappenplan beschrijft de stappen die doorlopen kunnen worden in een project. Het kan gezien worden als een blokkendoos met SE-blokken. Met deze blokken kunnen verschillende bouwwerken projectplannen- worden opgetrokken. In de verschillende projectplannen die er gemaakt kunnen worden, krijgen sommige blokken meer aandacht dan andere; sommige blokken worden meer dan een keer doorlopen en sommige worden niet gebruikt. Overigens beschrijft het stappenplan alleen stappen die gerelateerd zijn aan het vakgebied SE. Let erop dat er veel meer activiteiten nodig zijn om een heel project te draaien. Met werkwijzebeschrijvingen (WWB s), basisspecificaties en best practices die door Rijkswaterstaat zijn ontwikkeld, zijn het stappenplan en de activiteitenbeschrijvingen uit te werken tot projectspecifieke werkpakket-beschrijvingen. Figuur 1 - De hoofdstappen van het stappenplan van projectopdracht tot Vraagspecificatie. Pagina 5 van 42

6 Indien u nog niet de verdiepingscursus SE van Rijkswaterstaat heeft gevolgd, wordt aanbevolen om bij het toepassen van dit stappenplan op een project, advies in te winnen bij de SE-adviseurs van Rijkswaterstaat Dienst Infrastructuur, afdeling OI (vragenloket.se@rws.nl). Van projectopdracht tot Vraagspecificatie Conform de Leidraad SE v2.0 maakt het stappenplan onderscheid in drie verschillende typen specificaties: - Specificatie van de klantvraag (Klanteisen Specificatie) - Specificaties van het systeem (Systeemspecificaties) - Specificatie van de uitvraag in een contract (Vraagspecificatie) De drie typen specificaties, de activiteiten die nodig zijn om daartoe te komen en de samenhang er tussen, staan centraal in deze beschrijving van (SE-)activiteiten. Deze activiteiten zijn opgenomen in respectievelijk de stappen Vaststellen van de Klantvraag (het gele blok), Ontwikkelen van het Systeem (het blauwe blok) en Uitwerken van de Vraagspecificatie (het rode blok). Voorafgaand aan deze activiteiten is het structureren van de projectopdracht een noodzakelijke stap bij iedere start van een projectteam. De activiteiten die daartoe bijdragen zijn opgenomen in de stap Project structureren (het groene blok). Dwars door alle stappen heen loopt het inkopen van ingenieursdiensten. Van elke stap kan afgewogen worden om activiteiten uit te besteden aan ingenieursbureaus. De daarvoor benodigde activiteiten zijn opgenomen in de stap Inkopen ingenieursdiensten (de paarse balk). projectopdracht voor het stappenplan is de projectopdracht. Uitgangspunt is dat aan elk mogelijke projectsituatie een document ten grondslag ligt waarin de betreffende projectopdracht is omschreven. Vraagspecificatie Voor elk RWS-project geldt dat uiteindelijk een Vraagspecificatie wordt geproduceerd voor het uitbesteden van werkzaamheden aan een Opdrachtnemer. Daarmee houden de taken en verantwoordelijkheden van het projectteam van Rijkswaterstaat niet op, maar voor de scope van dit stappenplan wordt de Vraagspecificatie als resultaat beschouwd. Leeswijzer De activiteitenbeschrijvingen volgen de stappen uit het stappenplan. Daarbij is uitgewerkt wat het doel van elke stap is, welke inputs en outputs de stap heeft, welke activiteiten moeten worden uitgevoerd en welke hulpmiddelen beschikbaar zijn uit het stelsel van SE-hulpmiddelen van Rijkswaterstaat. Procesbibliotheek SE Strikt genomen is het hier gepresenteerde stappenplan een verzameling processen uit het vakgebied Systems Engineering, toegesneden op de RWS praktijk. Deze processen zijn ook in een digitale bibliotheek ondergebracht. Hiermee kun je zelf door de processen uit het stappenplan navigeren. Zo wordt de samenhang van het stappenplan op een interactieve manier duidelijk: Link naar de procesbibliotheek Systems Engineering Pagina 6 van 42

7 Pagina 7 van 42

8 1. Structureren project Met Systems Engineering benaderen wij onze projecten vanuit het Systeemdenken. De Leidraad SE zegt: - Een systeem is een samenwerkende combinatie van elementen bedoeld om, in uitvoering van een gespecificeerde functie, een bepaald doel te realiseren. - Systeemdenken is het grote plaatje bekijken: vanuit holistische visie beschouwen van complexe problemen en mogelijke oplossingen. Figuur 2 geeft een voorbeeld van de samenhang in systemen. Het toepassen van Systems Engineering in een project begint met het helder en gestructureerd vastleggen van de uitgangspunten. Er is altijd een projectopdracht aanwezig met een zekere projectscope. De vraag is hoe helder en gestructureerd deze zijn vastgelegd (P1). Bij het structureren van het project hoort verder het definieren en beheren van baselines (P2). Het beheren van baselines is een manier om ervoor te zorgen de producten binnen een project op elkaar afgestemd blijven. Om gestructureerd aan het werk te gaan, is het noodzakelijk om de projectactiviteiten en projectproducten gestructureerd en expliciet in beeld brengen. De tools uit Systems Engineering die we hierbij gebruiken zijn een Work Breakdown Structure, een Product Breakdown Structure (P3). Door middel van een Organisatie Breakdown Structure (P4) maken we vervolgens inzichtelijk hoe de verantwoordelijkheden en de werkpakketen zijn verdeeld over de projectleden. Deze uitwerkingen leveren input op voor het totale Projectplan. Figuur 2 - Samenhang systemen (uit Leidraad SE v2.0) Op basis van de stappen in het vervolg van het project dient de projectscope continu te worden beheerd en waar nodig bijgesteld (P5). Bijvoorbeeld op basis van onderhandelingen met een stakeholder. Het beheren van de scope is dus een specifiek gemaakte vorm van proces P2, beheren baselines. Pagina 8 van 42

9 P1 Analyseren projectopdracht P1 Het vaststellen van een duidelijke projectscope als uitgangspunt voor het project. - Projectopdracht - Brondocumentatie van het project - Analyseer de projectopdracht en de bron documentatie van het project. Zoek naar doelstellingen, randvoorwaarden, functies, raakvlakken etc. Stel de waarom-vraag aan de opdrachtgever als delen van de projectopdracht nog niet duidelijk zijn. Gebruik de overige bron documentatie om een zo compleet mogelijk beeld te krijgen. - Identificeer het systeem dat van het project wordt gevraagd (het System-of- Interest van de opdrachtgever). - Formuleer de projectscope beschrijving en vul het scopeformulier in. De projectscope is het totaal van producten en diensten dat in het kader van een project dient te worden geleverd (definitie Leidraad 2.0). - Format scopeformulier MIRT (Werkwijzer Aanleg 787) - Scopeformulier (met daarin de projectscope beschrijving) P2 Beheren baselines P2 Het totstandbrengen en onderhouden van de volledigheid van en de samenhang tussen de producten van een project. - Producten uit de Product Breakdown Structure (PBS) - Identificeer voor de inhoud van de baseline die producten van het project die een grote impact hebben op andere producten of op het projectresultaat. Gebruik daarbij de PBS. Voorbeelden kunnen zijn: de klant eisen specificatie, het (O)TB, het geometrische ontwerp, het areaal en de scope. - Stel vast hoe de baseline eruit gaat zien: vorm, vindplaats etc. - Stel vast hoe wijzigingen op de baseline worden verwerkt. In een lichte vorm worden de wijzigingen alvast verwerkt in de producten. Bij een nieuwe versie, worden de verschillen tussen de baselines onderzocht en de acties die daaruit volgen gedaan. In een zwaardere -en in veel gevallen betere- vorm wordt de baseline beheerd door een lijst met wijzigingsverzoeken aan te leggen en een verzoek-tot-wijzigingsprocedure in te richten. Deze zwaardere vorm is op zijn plaats voor het beheren van de scope van het project, zie ook stap P5. - Maak de baseline en maak de baseline bekend. - Nvt - Baselines Pagina 9 van 42

10 P3 Structureren werkpakketten en producten P3 Het definiëren en structureren van de werkpakketten en de daaruit volgende producten die noodzakelijk zijn om uitvoering te geven aan de projectopdracht. - Projectscope beschrijving - Benoem het hoofdprocessen en subprocessen die moeten leiden tot het beoogde projectresultaat ofwel het gerealiseerde systeem. Denk ook aan processen in andere volgende fasen van de levenscyclus. De input die nodig is voor de volgende fase moet door een proces in de huidige fase worden geleverd. Zie bijvoorbeeld de generieke faseringen voor de MIRT- en SNIPprojecten. - Structureer deze processen in een WBS (Work Breakdown Structure) tot een beheersbaar niveau waarop werkpakketten worden geschreven. Zie Figuur 3. - Benoem de hoofdproducten en subproducten die als output het resultaat van deze processen vormen. - Structureer deze producten in een PBS (Product Breakdown Structure) op het niveau van de outputs van de werkpakketten. Voor elke WBS en PBS geldt de 100% regel: alle werkpakketten en producten samen maken het werk. - Zorg ervoor dat elk product een output is van een werkpakket. - Leg relevante informatie bij de processen en producten vast in de werkpakketbeschrijvingen, zoals tijd, kosten, WP-verantwoordelijke, activiteiten, output, producteisen, risico s, raakvlakken met andere werkpakketten e.d. - Leg de werkpakketten vast in de projectplanning en koppel ze aan het risicodossier. - Werkwijzebeschrijving WWB Opzetten van een WBS (Werkwijzer Aanleg 852) - Werkwijzebeschrijving WWB Opstellen van een werkpakketbeschrijving (Werkwijzer Aanleg 853) - Werkwijzebeschrijving WWB-00029M Sjabloon werkpakketbeschrijving (Werkwijzer Aanleg 839) - Work Breakdown Structure (WBS) - Product Breakdown Structure (PBS) Figuur 3 - Work Breakdown Structure (uit Leidraad SE v2.0) Pagina 10 van 42

11 P4 Structureren organisatie P4 Het verdelen van taken en rollen over de organisatie om de werkpakketten uit te kunnen voeren. - Work Breakdown Structure (WBS) - Analyseer welke kennis en ervaring nodig is voor het project. Huur deze in of organiseer opleidingen om kennis op het vereiste peil te brengen. - Maak aan de hand van de WBS de verantwoordelijkheden inzichtelijk: wie voert welke werkpakketten uit. - Categoriseer de werkzaamheden naar de rollen van het IPM model en richt hierop de projectorganisatie in. - Schematiseer de projectorganisatie in een hiërarchische structuur, de OBS (Organisatie Breakdown Structure). - Werkwijzer Aanleg Deel 2 (voor indeling naar IPM-model); zie ook H6 van dit stappenplan. - Organisatie Breakdown Structure (OBS) P5 Beheren scope P5 Het beheren van de scope van het project zodat er altijd een adequate omschrijving is van het geheel van producten en diensten dat het project dient op te leveren. - Wijzigingsvoorstellen op projectscope beschrijving - Richt een verzoek-tot-wijzigings procedure in om voorgestelde wijzigingen in de projectscope te beheren (gebruik inzichten uit het vakgebied configuratiemanagement om baselines te maken en de procedures in te richten, zie bijvoorbeeld stap P2). - Beoordeel de wijzigingsvoorstellen op de projectscope op gevolgen voor tijd, geld en kwaliteit. - Keur significante scopewijzigingen goed binnen het IPM team en leg ze voor aan door de opdrachtgever om te laten accorderen. - nvt - Bijgewerkte projectscope beschrijving - Bijgewerkt scopeformulier Pagina 11 van 42

12 2. Vaststellen van de klantvraag Vanuit RWS-perspectief gezien kan worden gesteld dat een project succesvol is als aan onze Klantvraag wordt voldaan. De Leidraad SE zegt: - de klant is de verzameling van (betalende én niet-betalende) stakeholders; - de klantvraag is de verzameling van behoeften en randvoorwaarden van deze stakeholders. Systems Engineering is gericht op het optimaliseren van het systeem naar de klantvraag over de hele levenscyclus. Omdat tijdens de levenscyclus vele overdrachtsmomenten plaatsvinden, is het dus van wezenlijk belang om de klantvraag binnen een projectcontext expliciet in beeld te brengen en te beheren. Figuur 4 geeft deze overdrachtmomenten weer. Het vaststellen van de klantvraag begint met een goede probleemanalyse en definitie van de doelstellingen van het project (K1). Aan de hand van een omgevingsanalyse worden de relevante stakeholders gestructureerd in beeld gebracht (K2). Aan de hand daarvan worden de behoeften en randvoorwaarden van de stakeholders (binnen de context van het System of Interest) verzameld en uitgewerkt in klanteisen (K3). Van wezenlijk belang daarbij is om met die stakeholders ook afspraken te maken over de wijze waarop de invulling van de klanteisen wordt aangetoond, oftewel de validatiestrategie vast te leggen (K4). Dit alles is input voor de Klant Eisen Specificatie van het project (K5). Het vastleggen van klanteisen is geen eenmalige actie. De klanteisen specificatie kan worden bijgesteld doordat een klanteis veranderd of doordat resultaten uit de systeem ontwikkeling worden verwerkt. Het is daarbij van belang om te valideren of de eisen en oplossingen die zijn afgeleid van de klanteisen nog voldoen aan de behoeften van de klant (K6). Rijkswaterstaat werkt volgens het principe van Publieksgericht Netwerkmanagement. Figuur 4 Informatieoverdracht in levenscyclus (uit Leidraad SE v2.0) Pagina 12 van 42

13 K1 Analyseren problemen en definiëren doelstellingen K1 Het analyseren van het probleem van de opdrachtgever en het definiëren van de doelstellingen van het project. - Projectscope beschrijving - Brondocumentatie van het project - Bevraag de opdrachtgevers van het project (gebruik de waarom-vraag) en analyseer de reeds beschikbare brondocumentatie van het project; gebruik de informatie die is vastgelegd in de projectscope omschrijving. - Organiseer desgewenst een brainstormsessie binnen het projectteam, waar nodig mét stakeholders (overweeg dan om een zogenoemde Value Engineering Studie te doen), om tot een zo compleet mogelijke inventarisatie van gerelateerde problemen en kansen te komen. - Leg per probleem tenminste vast: de probleembeschrijving; vanuit welke bron het probleem is herleid; wie de probleemeigenaar is; waarom het een probleem is (situatie versus norm); wanneer het probleem is opgelost (maak dit meetbaar); of het probleem leidt tot een projectdoelstelling; kan het probleem ook als kans worden gezien. Zorg ervoor dat de relaties tussen doelstellingen van het project en de problemendefinities in twee richtingen traceerbaar zijn. - Bundel de probleembeschrijvingen in één document: het probleemdefinitie document. - Stel aan de hand van de behoeften die het project gaat invullen (zoals verwoord in de problemen), de doelstellingen van het project vast. Maak deze doelstellingen zo meetbaar mogelijk. Deze doelstellinen kunnen worden verwerkt in het projectplan. - Value Engineering studie (gefaciliteerd door VE specialisten) - Probleemdefinitie document - stellingen van het project K2 Analyseren stakeholders K2 Het vastleggen van alle relevante informatie over stakeholders. - Bron documentatie van het project - Projectscope beschrijving - Systeemspecificatie Pagina 13 van 42

14 K2 Analyseren stakeholders K2 - Benoem alle belanghebbenden/stakeholders en leg de informatie vast in een stakeholderoverzicht. Gebruik voor de stakeholderanalyse de beschikbare bron documentatie van het project, de projectscope beschrijving. Vaak zullen gaande het proces nieuwe stakeholders worden geïdentificeerd. Een gemeente wordt bijvoorbeeld een stakeholder als een van de mogelijke oplossingen binnen de gemeentegrenzen wordt gerealiseerd. In dit laatste geval wordt dus de systeemspecificatie gebruikt om de stakeholder analyse te verfijnen. - Zorg ervoor dat de relaties tussen doelstellingen van het project; de problemendefinities en klanteisen specificatie de in twee richtingen traceerbaar zijn. - Bepaal van elke stakeholder zijn belang en de aard van het belang, de invloedssfeer en het machtsmiddel. Het format van de klant eisen specificatie geeft hier richtlijnen en aanwijzingen voor. - Werkwijzebeschrijving WWB-0009 Bemachtigen van eisen (Werkwijzer Aanleg 846) - Sjabloon Klant Eisen Specificatie (Werkwijzer Aanleg 840) - Stakeholderoverzicht (onderdeel van de klant eisen specificatie) K3 Verzamelen klanteisen K3 Het objectief en herleidbaar vastleggen van klanteisen die het project beïnvloeden. - Brondocumentatie van het project - Gespreksverslagen van overleggen met stakeholders - Bestuurovereenkomsten etc. - Inventariseer de eisen en behoeften en randvoorwaarden van stakeholders op basis van bijvoorbeeld gespreksverslagen van overleggen met stakeholders, bestuursovereenkomsten en bestaande bron documentatie van het project. - Klanteisen zijn vaak ongestructureerd, oplossingsgericht, tegenstrijdig, multiinterpretabel, e.d. Dit is niet erg. Het gaat erom alle relevante input vanuit de stakeholders te verzamelen en vast te leggen. Deze vastgelegde klanteisen zijn vervolgens input van de systeemontwikkeling. De manier van vertalen van de klanteisen in systeemeisen is onderdeel van de onderhandelingen met de stakeholders. - Herformuleer klanteisen of wijs ze af aan de hand van de uitkomst van de analyse van de klanteisen in stap S4. - Werkwijzebeschrijving WWB-0009 Bemachtigen van eisen (Werkwijzer Aanleg 846) - Klanteisen (Toelichting: Figuur 5 geeft een voorbeeld van een klanteis; stap K5 geeft weer hoe de klanteisen in een database en een specificatie kunnen worden opgeslagen en weergegeven.) Pagina 14 van 42

15 Code Scheiden verkeersstromen Verwijzing naar D.001 Het scheiden van beroepsvaart en recreatievaart ten aanzien van de veiligheid. systeemeisen Ntb Eisinitiator District Status: Wel gehonoreerd; voorwaardelijke eis Datum status: Validatie: Toets op het ontwerp Bron: Leidraad Integrale Veiligheid Datum document: 2007 Toelichting op eis: Deze eis is een invulling van beleid. In de Nota Mobiliteit staat dat verkeersstromen op een vlotte en veilige manier moeten worden afgewikkeld. Figuur 5 Voorbeeld van een klanteis (Bron: Sjabloon Klant Eisen Specificatie (Werkwijzer Aanleg 840)) K4 Bepalen validatiestrategie K4 Het vaststellen van de wijze waarop wordt aangetoond aan de stakeholders (gevalideerd) dat het systeem voldoet aan de behoeften en randvoorwaarden. - Klanteisen - Stakeholderoverzicht - Maak bij het verzamelen van de klanteisen afspraken met de stakeholders over de wijze van aantonen. Dit dient te gebeuren in de planuitwerkingsfase, de contractvoorbereiding, tijdens de ontwerpfase of bijvoorbeeld na realisatie. Hoe ver de validatie van klanteisen gaat, kan afhangen van de macht, het belang en de invloed van de betreffende stakeholder (zoals opgenomen in het stakeholderoverzicht). - Beschrijf de stappen (strategie) die het project volgt om klanteisen te valideren. Bijvoorbeeld een communicatieplan beschrijft hoe de omgeving wordt benaderd. - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Validatiestrategie Figuur 6 - Specificeren klanteisen (uit Leidraad SE v2.0) Pagina 15 van 42

16 K5 Opstellen klanteisen specificatie K5 Het gestructureerd documenteren van de informatie rondom de klanteisen en het System of Interest. - Projectscope beschrijving - Probleemdefinitie document - stellingen van het project - Stakeholderoverzicht - Klanteisen - Validatiestrategie - Leg de input informatie gestructureerd vast in een document, genaamd de klanteisen specificatie (KES), als ijkpunt van de klantvraag. Zie Figuur 6. - Laat de KES vaststellen door de opdrachtgever en betrokken stakeholders en maak een baseline van de KES. Toelichting: Het ontwikkelen van het systeem (stappen S4, S5, S6 en S7) kan aanleiding zijn om de klanteisen te herzien of af te wijzen (stap K6). - Sjabloon Klant Eisen Specificatie (Werkwijzer Aanleg 840) - Startpakket Klanteisendatabase (Werkwijzer Aanleg 783) - Klanteisen specificatie K6 Valideren K6 Het aantonen dat het systeem voldoen aan de behoeften en randvoorwaarden van de stakeholders. - Klanteisen specificatie - Systeemeisen en Ontwerpen - Validatiestrategie - Valideer de klanteisen op de manier die is vastgelegd in de klanteisen specificatie; volg daarbij de strategie die geformuleerd is in de validatiestrategie. - Laat aan de klanten zien hoe de klanteisen zijn vertaald in systeemeisen, ontwerpen en hoe het systeen is gerealiseerd. - Pas klanteisen aan naar aanleiding van deze stap (stap K5). - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Validatierapport - Wijzigingen op de klanteisen specificatie - Wijzigingen op de projectscope beschrijving Pagina 16 van 42

17 Pagina 17 van 42

18 3. Ontwikkelen van het systeem Met Systems Engineering wordt de ontwikkeling van een systeem top-down doorlopen. Op verschillend detailniveau vindt een specificatieproces plaats met continu een iteratie plaats tussen de functies, eisen en ontwerp door een specificatie proces wat analyseren, structureren en alloceren en ontwerpen inhoudt. Op basis van de klanteisen wordt een eerste analyse uitgevoerd van het beschouwde systeem (het System of Interest) en worden ontwerpkeuzes gemaakt op het hoogste detailniveau. Denk bijvoorbeeld aan de keuze voor de ligging van een wegtracé of de keuze om een sluiscomplex uit te breiden. Ook het maken van deze keuzes op abstract niveau noemen we in de Leidraad SE v2.0 ontwerpen. Deze ontwerpkeuzes leiden weer tot afgeleide functionaliteiten die het systeem moet vervullen en nadere eisen en randvoorwaarden aan de verdere ontwikkeling van het systeem. Deze loop loopt door tot het niveau van een uitvoeringsgereed ontwerp is bereikt. De resultaten worden op specifieke detailniveaus vastgelegd in de specificaties van het systeem (Systeemspecificaties). De Leidraad SE v2.0 zegt: Elk detailniveau kent een specificatie van de oplossingsruimte als input en een specificatie van de oplossing als output. Deze output kent bepaalde marges die de nieuwe oplossingsruimte vormen, als input voor het volgende detailniveau. Binnen Rijkswaterstaat wordt de ontwikkelfase van een project gedeeltelijk doorlopen. Afhankelijk van de inkoopstrategie worden specificaties op een bepaald detailniveau op de markt gezet (zie H4). Elke eis dekt daarbij een risico af dat niet op een andere manier wordt afgedekt. Tot die tijd is het van belang de systeemontwikkeling al volgens de werkwijze van Systems Engineering te doorlopen. Daarbij worden diverse activiteiten uitbesteed aan ingenieursbureaus (zie H5). De mate waarin de activiteiten zoals beschreven in dit hoofdstuk door het projectteam van Rijkswaterstaat zelf worden uitgevoerd is dus sterk afhankelijk van de specifieke projectsituatie: de complexiteit, de besluitvormingsfase en inkoopstrategie van het project. Dit neemt niet weg dat betrokken projectteamleden van RWS moeten weten wat er bij komt kijken om volgens de principes van Systems Engineering een systeem te ontwikkelen. Voorbeeldprojecten tonen aan dat de werkwijze volgens Systems Engineering niet alleen noodzakelijk is met oog op marktbenadering om tot heldere specificaties te komen. Ook in de planstudiefase leidt het tot een beheerst proces en levert het waardevolle informatie op voor de onderbouwing van ontwerpkeuzes en de onderhandelingen met stakeholders. De SE-principes sluiten zeer goed aan op de eisen aan een zorgvuldig proces vanuit bijvoorbeeld de tracéwet. Figuur 7 Systeemontwikkeling: Detailniveaus specificeren (uit Leidraad SE v2.0) Pagina 18 van 42

19 De ontwikkelfase kenmerkt zich dus door een top-down aanpak en een iteratief specificatieproces (zie Figuur 7 en Figuur 8). In eerste instantie is het van belang om de bestaande situatie goed te beschrijven (S1). Dit vormt samen met de klanteisen de basis voor de systeemontwikkeling. Bij de start van de ontwikkelfase is het tevens van belang een goede verificatie- en validatiestrategie uit te denken (S2). Op welke momenten, op welke wijze en door welke functionarissen zal gaandeweg het project aangetoond worden dat de uitwerking van het systeem nog altijd voldoet aan de doelstellingen, klanteisen en de systeemeisen. Binnen Rijkswaterstaat zijn diverse standaarden uitgewerkt waar een projectteam goed gebruik van kan maken in de ontwikkelfase, zoals bijvoorbeeld basisspecificaties en Rijkswaterstaatbrede afspraken (RBA s) (S3). Figuur 8 - Iteratief specificatieproces (uit Leidraad SE v2.0) Het iteratieve specificatieproces begint met het analyseren van het systeem (S4). Hierbij kunnen diverse analyses plaatsvinden, zoals een eisenanalyse, functieanalyse, RAMS-analyse, e.d. De resultaten van deze analyses worden gestructureerd in beeld gebracht met eisen, functiebomen en objectenbomen, maar ook in risico s voor tijd, geld en kwaliteit. Eisen en functies worden vervolgens toegewezen (gealloceerd) aan de objecten door middel van kruistabellen (S5). Op basis van de toegewezen functies en eisen worden er voor specifieke objecten diverse afwegingen en ontwerpkeuzes gemaakt. Hiertoe worden diverse opties gegenereerd, haalbare varianten uitgewerkt en het ontwerp van de gekozen oplossing gemaakt. Een trade-off of scoringstabel draagt bij aan een zorgvuldige en transparante afweging (S6). Ontwerpkeuzes leiden weer tot afgeleide functies en eisen, waarmee de loop weer sluitend is. Tijdens dit iteratieve proces vindt continu ontwerpverificatie plaats om te checken of de resultaten nog voldoen aan de (bovenliggende) specificaties die als input voor het proces gelden. Dit wordt vastgelegd in een verificatietabel (S7). Merk op dat het specificatie proces in een notendop wordt doorlopen tijdens een Value Engineering studie. Het resultaat van dit proces wordt op verschillende detailniveaus vastgelegd in Systeemspecificaties (S8). Een systeemspecificatie bevat dus zowel eisen over benodigde functionaliteiten, eisen aan de prestaties van het systeem en oplossingsruimte aan de hand van gemaakte ontwerpkeuzes (de marges). Zodoende geeft het invulling aan de bovenliggende specificaties en beschrijft het de kaders (oplossingsruimte) en gevraagde kwaliteit voor het vervolg van de systeemontwikkeling. Systeemspecificaties markeren daarmee de overgang van het ene detailniveau naar het volgende detailniveau in de ontwikkelfase. De keuze van het detailniveau waarop een Systeemspecificatie wordt vastgesteld kan bijvoorbeeld bepaald worden door de benodigde nauwkeurigheid van informatie in de besluitvorming (bijvoorbeeld het niveau van Standpunt bepaling). De eisen in de systeemspecificaties moeten beheerd worden om de consistentie met de andere activiteiten van het project te borgen (S9). Pagina 19 van 42

20 S1 Vastleggen bestaande situatie S1 Het verkrijgen van inzicht in de bestaande situatie. - Projectscope beschrijving - Zorg ervoor dat de gegevens van de bestaande omgeving en het daarin liggende areaal bekend zijn. Gebruik bij het vastleggen van de bestaande situatie de projectscope omschrijving. Een volledige beschrijving van de bestaande situatie (nulsituatie) vormt een belangrijk onderdeel van de Systeem Specificatie en uiteindelijk de Vraagspecificatie. - Doe archiefonderzoek en vraag beschikbare gegevens op bij de beheerder. - Beoordeel de gegevens op compleetheid, nauwkeurigheid en actualiteit. - Verricht, waar nodig, aanvullende metingen en voer nulinspecties uit. - Stel een beschrijving van de nulsituatie op en maak inzichtelijk waar detailgegevens en tekeningen beschikbaar zijn. - nvt - Beschrijving van bestaande situatie S2 Bepalen verificatiestrategie S2 Het vaststellen van de wijze waarop wordt aangetoond (geverifieerd) dat het systeem voldoet aan de systeemeisen. - Klanteisen specificatie - Projectplanning - Stel vast hoe de verificatie van het systeem zal moeten verlopen ten opzichte van de planning van het project; gebruik informatie over de stakeholders en de klanteisen van de stakeholders die is vastgelegd in de klanteisen specificatie. - Bepaal wie de verificatiewerkzaamheden coördineert binnen de systeemontwikkeling; - Bepaal de beschikbare verificatiemethoden, typen criteria en de voor de beoordeling verantwoordelijke functionarissen; (zie ook Figuur 9); - Leg dit vast in een Verificatie managementplan voor het verifiëren van de Systeemspecificaties (die in deze fase opgesteld worden) en laat dit vaststellen door de projectmanager. - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Verificatie managementplan Pagina 20 van 42

21 Figuur 9 Het belang van gedegen verificatie & validatie (uit Leidraad SE v2.0) S3 Gebruiken basisspecificaties en RBA s S3 Het bevorderen van uniformiteit tussen, en efficiency in projecten door het gebruik van beschikbare standaarden. - System Breakdown Structure (SBS; ook wel objectenboom) - Projectscope beschrijving - Bepaal op basis van de System Breakdown Structure (SBS, identiek aan de objectenboom) welke basisspecificaties gebruikt dienen te worden om systeemeisen af te leiden; - Bepaal welke eisen voor de verschillende objecten gelden en maak op basis daarvan gebruik van eisformuleringen uit de basisspecificaties. - Herleid uit de projectscope en de objectenboom welke Rijkswaterstaat Brede Afspraken (RBA s) en normen en richtlijnen (N&R) er voor het project gelden. Neem de titels, documentnummers en versies hiervan op in een tabel of overzicht van bindende en informatieve documenten. Deze lijst vormt een paragraaf in de Vraagspecificatie; - Koppel de bindende en informatieve documenten in de Systeemspecificaties expliciet aan één of meerdere eisen, door vanuit de eisen ter verwijzen naar de documenten. Toelichting: arbitrage heeft uitgewezen dat van een Opdrachtnemer niet mag worden verwacht dat hij zelf bindende documenten aanvoert/verzint en van een Opdrachtnemer niet mag worden verwacht dat hij per eis zelf kan bepalen aan welke, en welk delen binnen, de bindende of informatieve documenten hij moet voldoen. - Werkwijzebeschrijving WWB-0010 Werken met basisspecificaties (Werkwijzer Aanleg 847); Toelichting Werken met Basisspecificaties (Presentatie) - Handreiking Normen + Richtlijnen - Basisspecificaties - Rijkswaterstaat Brede Afspraken (deze zijn verplicht) - Systeemeisen (in concept, namelijk uit de basisspecificaties) - Overzicht van van toepassing zijnde RBA s en Normen & Richtlijnen voor de Systeemspecificaties Pagina 21 van 42

22 S4 Analyseren S4 Het analyseren van de gevraagde eigenschappen van het systeem en het vertalen van deze eigenschappen in SMART systeemeisen. - Klanteisen specificatie - Bovenliggende systeemspecificaties (systeemeisen en ontwerpen) - Verificatie managementplan - Analyseer de klanteisen (zie ook Figuur 10): o Vertaal de klanteisen naar systeemeisen. o Prioriteer de eisen: Welke eisen zijn kritisch of kostenbepalend?. o Check de systeemeisen op onderlinge tegenstrijdigheden. o Check de systeemeisen op tegenstrijdigheden met andere projectdoelstellingen en uitgangspunten. o Stem de uitkomst (bijvoorbeeld bijstellingen / afwijzingen van klanteisen) van de vertaling en de checks af met de stakeholders. Zie ook stap K3 en K4. - Analyseer ook de specificaties van het bovenliggende systeemniveau. Analyseer het ontwerp dat gekozen is en formuleer systeemeisen op het lagere niveau. De kruistabel van het bovenliggende niveau geeft aan welke eisen meegenomen moeten worden op het onderliggende niveau. Merk op dat het analyseren van de eisen betekent dat het ontwerp of de allocatie mogelijk aangepast moeten worden. Stap S4, S5 en S6 worden daarom iteratief doorlopen. - Bepaal welke functies het systeem moet vervullen (of: wat het systeem moet kunnen doen) en vertaal deze functies in functionele eisen. Beschrijf ook de prestatie van de functie in de eis of onderliggende eisen. - Stel de vraag waar het systeem wordt gebruikt/geïnstalleerd: identificeer en formuleer raakvlakken. - Voer een RAMS analyse uit: o Bepaal wat de benodigde RAMS prestaties van het systeem zijn (voor elke functie). o Bepaal voor elke functie wanneer de functie faalt, met andere woorden wat de faaldefinitie is. o Bepaal welke RAMS eisen dienen te worden gesteld. - Op basis van de voorgaande activiteiten: stel meetbare eisen op voor de verdere uitwerking van het systeem. o Categoriseer de eisen in type: functioneel; aspect; raakvlak of proces. o Maak de eisen SMART. o Koppel relevante informatie aan de eis, zoals uniek nummer, bronverwijzing, en dergelijke. o o Leg de relaties (traceerbaarheid) tussen de eisen vast. Leg op basis van het Verificatie managementplan de noodzakelijke V&Vmethoden vast bij de eisen. - Werkwijzebeschrijving WWB Formuleren van eisen (Werkwijzer Aanleg 843) - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Leidraad RAMS (Werkwijzer Aanleg 502) - Systeemeisen - RAMS analyse - Raakvlakanalyse Pagina 22 van 42

23 Figuur 10 - Eisen analyse (uit Leidraad SE v2.0) Figuur 11 - System Breakdown Structure (uit Leidraad SE v2.0) Pagina 23 van 42

24 S5 Structureren en alloceren S5 Het structureren van het systeem en het alloceren van eisen, functies en hun prestaties aan objecten. - Systeemeisen - Ontwerpen - Bepaal aan de hand van de functionele eisen die zijn geformuleerd (S4), welke functies het systeem moet vervullen. Decomponeer functies in subfuncties, anders gezegd: ontwerp de functionele architectuur van het systeem. o Voor objecten waarvoor een basisspecificatie bestaat is de functionele o architectuur terug te vinden in de basisspecificatie. Voor andere systemen: modelleer de werking van het systeem in een stroomdiagram, bijvoorbeeld een Functional Flow Block Diagram of IDEF0 diagram. - Structureer de functies van een systeem in een functieboom (FBS). Deze functieboom gebruik je later om het contract te structureren. - Structureer de objecten waar het systeem uit moet bestaan in een objectenboom (SBS). N.B. In een SBS worden de objecten hiërarchisch gerangschikt. Als je een niveau afdaalt in de boom, kun je de relaties met de onderliggende objecten lezen als: bestaat uit. Vice versa, kun je de relatie van een object met zijn bovenliggend object lezen als is onderdeel van. Daarom staat Sluis boven de objecten Deur en Pompsysteem (en bestaat de Sluis daarnaast uit nog meer objecten). Voor een objectenboom geld de 100% regel: de onderliggende objecten vormen samen het bovenliggende object. - Structureer de raakvlakken door een contextdiagram op te stellen. - Koppel de functies aan object (anders gezegd: alloceer functies aan functievervullers). Bepaal bijvoorbeeld of een viaduct (het object) naast zijn gebruikelijke functie dragen weg ook de functie dragen geluidsscherm moet vervullen of dat er een nieuw object moet komen dat de functie dragen geluidsscherm moet vervullen. Maak met een kruistabel inzichtelijk welke functies door welke objecten worden vervuld. - Deel ook de overige eisen toe aan de objecten (bijvoorbeeld de raakvlakeisen van een systeem worden toebedeeld aan objecten). Bijvoorbeeld: een aspecteis over vormgeving wordt wel aan de behuizing gesteld, maar niet aan de inhoud van de behuizing. - Alloceer de RAMS eisen aan de functie waaraan een RAMS eis is gesteld. - Merk op dat het koppelen van functies en eisen aan objecten een iteratief proces is. Het ontwerpen van een oplossing (S6) geeft input aan de allocatie (S5) en vice versa. Een kruistabel kan ook beschouwd worden als de vertaling (anders gezegd mapping) van een logisch ontwerp (de eisen, functies, prestaties etc. op de verticale as) naar het fysieke ontwerp (wegen, kunstwerken, installaties etc. op de horizontale as). - Werkwijzebeschrijving WWB Maken van een functionele analyse (Werkwijzer Aanleg 849) - Werkwijzebeschrijving WWB-0023 Opstellen van een functieboom (Werkwijzer Aanleg 850) - System Breakdown Structure (SBS, ook wel objectenboom; zie Figuur 11) - Systeemcontextdiagram (zie Figuur 12) - Function Breakdown Structure (FBS) - Kruistabel (zie Figuur 13) Pagina 24 van 42

25 Figuur 12 Systeemcontextdiagram voor een navigatiesysteem (Tom Tom). Figuur 13 - Allocatie van systeemeisen aan de objecten van het systeem (uit Leidraad SE v2.0) Pagina 25 van 42

26 S6 Ontwerpen S6 Het ontwikkelen van het ontwerp van het systeem. - System Breakdown Structure (SBS) - Function Breakdown Structure (FBS) - Kruistabel - Systeemeisen - RAMS analyses - Genereer ontwerpen die overeenstemmen met de eisen en de allocatie van de eisen aan objecten. Wees ervan bewust dat stap S5 en S6 van elkaar afhankelijk zijn en dus iteratief doorlopen moeten worden. De volgende voorbeelden zijn ook ontwerpen: o Een prestatie-eis bij de functie hoogteverschil nemen is dat het hoogteverschil in 15 minuten genomen moet kunnen worden. Uit de functie-analyse blijkt dat de volgende functies geleverd moeten worden: innemen vaartuig, nivelleren waterniveau, uitlaten vaartuig. De prestatie wordt als volgt verdeeld over de verschillende functies: innemen vaartuig 6 o min., nivelleren water 5 min., uitlaten vaartuig 4 min. De eis aan de veiligheid van een systeem wordt ingevuld door een brandblusinstallatie én een procedure voor de bedienaar van het systeem. Beide vullen samen de eis in en beide zijn dus onderdeel van het ontwerp van het systeem waarin de RAMS eisen zijn verdeeld en aan de objecten zijn toegekend. - Reduceer het aantal opties door ze op haalbaarheid te verifiëren. - Leg vast welke criteria zullen worden gebruikt om de ontwerpen af te wegen. Voorbeelden van criteria zijn: de kosten, tijd, risico s, maar ook doorstroming, hinder tijdens de bouw, beschikbaarheid en dergelijke. - Werk de overgebleven opties uit tot haalbare varianten (met een titel), dusdanig dat onderlinge vergelijking op de criteria mogelijk is. - Vergelijk de varianten op basis van de mate waarin zij scoren op de eisen en de criteria, bijvoorbeeld door een trade-off tabel of scoringstabel. - Werk de gekozen variant (in een verkenning: de Voorkeursvariant) nader uit tot het ontwerp van het systeem, bijvoorbeeld m.b.v. een geometrisch model, en leg dit vast in ontwerptekeningen op het detailniveau waarop alle systeemeisen geverifieerd kunnen worden en dat past bij de besluitvormingsfase waarin het project zich bevindt. - Onderbouw de gemaakte keuzes in een ontwerprapportage. - Leg de marges die bij de ontwerpkeuzes van toepassing zijn vast in de nadere specificaties van het systeem. - nvt - Ontwerpen (Toelichting: ontwerpen met bijbehorende ontwerprapporten met daarin bijvoorbeeld de Trade Off- of scoringstabel (zie Figuur 15)). Pagina 26 van 42

27 Figuur 14 - Ontwerp en oplossingsruimte (uit Leidraad SE v2.0) Beoordelingscriteria Wegingsfactor Varianten Hoofdcriteria Subcriteria Variant 1 Gewogen score 1 Variant 2 Gewogen score 2 Criterium a Subcriterium a1 <a> <score> <a>*<score> <score> <a>*<score> Subcriterium a2 <b> Criterium b Subcriterium b1 <c> Subcriterium b2 <d> Subcriterium b3 <e> Totaal score Totaal is 100% <totaal score> <totaal score> Figuur 15 Trade-off tabel S7 Verifiëren S7 Het aantonen dat het systeem voldoet aan de systeemeisen. Zie Figuur Systeemeisen - Ontwerpen - Verificatie managementplan - Verifieer het ontwerp aan de systeemeisen op basis van het V&V-plan. Zie Figuur 16. Let erop dat de verificatiemethoden aan moeten sluiten bij de validatiemethoden (vooral niet tegenstrijdig zijn). - Leg per eis de verificaties vast, bijvoorbeeld in een tabel (ook: de verificatiematrix) en beschrijf daarbij tenminste; de eis; de methode; het criterium; de functionaris die de verificatie uitvoert; het resultaat / de gemeten waarde; de conclusie voor het ontwerp van het systeem of voor de systeemeisen. - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Verificatierapport ontwerp Pagina 27 van 42

28 Figuur 16 - Verificatie en validatie in V-model (uit Leidraad SE v2.0) S8 Opstellen systeemspecificatie(s) S8 Het vastleggen van de specificaties van het systeem ten behoeve van de verdere uitwerking van het ontwerp van het systeem. - Systeemeisen - Ontwerpen - System Breakdown Structure (SBS) (zie Figuur 11) - Systeemcontextdiagram (zie Figuur 12) - Function Breakdown Structure (FBS) - Kruistabel (zie Figuur 13) - Beschrijving van bestaande situatie - Voeg alle gegenereerde informatie uit het specificatieproces per object uit SBS gestructureerd en traceerbaar samen. - Bouw de systeemspecificatie(s) op conform het format voor systeemspecificaties. In de praktijk worden de eisen meestal beheerd in een eisen management programma. Uit dit programma wordt dan de systeemspecificatie gegenereerd. Zie de hulpmiddelen voor de verschillen tussen de typen specificatie (klanteisen, systeem- en Vraagspecificatie). - Leg zowel de objectbeschrijving, eisen én oplossingsruimte, verificatiemethoden, van toepassing zijnde documenten en overige relevante eisen vast in de systeemspecificaties. - Voeg relevante informatie per eis toe voor de traceerbaarheid (bron, bovenliggende eis, onderliggende eis). - Gebruik het sjabloon voor de systeemspecificatie om al deze informatie in een document samen te vatten. Pagina 28 van 42

29 S8 Opstellen systeemspecificatie(s) S8 - Werkwijzebeschrijving WWB-0001 Regels voor het opstellen van een specificatie (Werkwijzer Aanleg 841) - Werkwijzebeschrijving WWB-0002 Werken met eisen (Werkwijzer Aanleg 842) - Werkwijzebeschrijving WWB-0005 Formuleren van eisen (Werkwijzer Aanleg 843) - Werkwijzebeschrijving WWB-0008 Identificatie van eisen (titel en nummering) (Werkwijzer Aanleg 845) - Verschillen tussen de typen specificaties - Sjabloon systeemspecificatie - Systeemspecificatie(s) (Toelichting: de systeemspecificatie is zowel input voor het maken van een vraagspecificatie, als ook input voor het maken van planstudieproducten.) S9 Beheren eisen S9 Het beheren van de eisen in de verschillende soorten specificaties (klant eisen specificatie, systeem- en Vraagspecificatie) en checken of ze overeenstemmen met de producten van een project. - Klanteisen specificatie - Systeemspecificatie - Vraagspecificatie - Projectplan - Beheer de eisen in de verschillende specificaties door: o Elke eis uniek te maken o Afhankelijkheden tussen eisen traceerbaar te maken. Maak dus inzichtelijk welke systeemeis een bepaalde klanteis invult. Doe dit twee kanten op. Maak bijvoorbeeld ook inzichtelijk welke bovenliggende eisen worden ingevuld door een eis. o Versie beheer op de eisen toe te passen. - Ga na of de eisen die zijn geformuleerd overeenstemmen met de strategie van het project, zoals vastgelegd in bijvoorbeeld het projectplan, de validatiestrategie etc. - Ga na of de eisen in overeenstemming zijn met andere producten binnen het project, bijvoorbeeld de probleemanalyse en de doelstellingen van het project. Ga ook na of de eisen tussen de klanteisen, systeem en Vraagspecificaties consistent zijn. - Beschrijf welke acties ondernomen moeten worden om geconstateerde afwijkingen tussen eisen en andere producten van het project op te lossen. - Controleer de uitvoering van de hierboven genoemde acties. - nvt - Gewijzigde Systeemspecificatie - Gewijzigde Klanteisen specificatie Pagina 29 van 42

30 4. Uitwerken Vraagspecificatie UAV-GC: De Vraagspecificatie duidt de uitvraag van Opdrachtgever aan Opdrachtnemer. Het is daarmee onderdeel van een contract en bevat de Wat-eisen én de Hoe-eisen. Leidraad SE v2.0: De Vraagspecificatie is de output van het specificatieproces van Opdrachtgever en de input voor het specificatieproces van Opdrachtnemer. Het vormt de scheidslijn tussen de verantwoordelijkheden van Opdrachtgever en Opdrachtnemer. De Vraagspecificatie beschrijft de gevraagde kwaliteit en de ontwerpruimte. Als de systeemspecificatie het detailniveau en bijbehorende ontwerpruimte heeft bereikt waarmee het project de markt wil benaderen, dan wordt overgegaan tot het uitwerken van de Vraagspecificatie. Bepalend voor dit moment is de inkoopstrategie van het project, waarmee de scheidslijn en het koppelpunt tussen Opdrachtgever en Opdrachtnemer wordt gevormd (zie Figuur 17). Daarnaast zijn de te volgen aanbestedingsprocedure (met bijbehorende gunningscriteria) en de contractbeheersingstrategie van invloed op de inhoud en het niveau van de Vraagspecificatie. Figuur 17 - Scheidslijn tussen Opdrachtgever en Opdrachtnemer, weergegeven in het V- model (uit Leidraad SE v2.0) Oftewel, de in het kader van de marktbenadering uitgedachte inkoopstrategie, aanbestedingsprocedure en contractbeheersingstrategie bepalen de vorm, inhoud en niveau van de Vraagspecificatie. Op basis van de benodigde diepgang van eisen (V1) en de scope van het contract (V2) wordt als het ware een uitsnede van de Systeemspecificaties gemaakt. De Vraagspecificatie bepaalt daarmee de System of Interest van de Opdrachtnemer en deze zal bijna per definitie niet volledig overeenkomen met de System of Interest van de Opdrachtgever. Er zullen namelijk altijd onderdelen van het systeem door de Opdrachtgever zelf (b.v. grondaankopen) of door andere partijen (b.v. verlegging van zware gasleidingen) worden uitgevoerd. Voor het opstellen van de Vraagspecificaties zijn formats beschikbaar op het contractenbuffet van IMG. Op basis van de van toepassing zijnde systeemeisen wordt het format gevuld (V3). In het kader van de kwaliteitsborging is binnen Rijkswaterstaat een toetsprocedure ontwikkeld waarbij op verschillende momenten in het proces toetsen worden uitgevoerd volgens een vastgesteld toetskader en door gecertificeerde toetsers. (V4). Er wordt onderscheid gemaakt tussen een structuurtoets, een voortgangstoets en een eindtoets. Als check of de Vraagspecificatie een goede weergave geeft van de resultaten uit het voorliggende proces wordt gevalideerd of deze voldoet aan de ontwerpruimte en gevraagde kwaliteit uit de Systeemspecificaties. Pagina 30 van 42