Stappenplan van Projectopdracht tot Vraagspecificatie

Transcriptie

1 Stappenplan van Projectopdracht tot Vraagspecificatie Procesbeschrijving systems engineering voor RWS projecten Datum 24 september 2014 Versie 1.4

2 Pagina 2 van 40 Stappenplan van projectopdracht tot Vraagspecificatie 24 september 2014

3 Stappenplan van Projectopdracht tot Vraagspecificatie beschrijvingen systems engineering voor RWS projecten Datum 24 september 2014 Status Versie 1.4 Rijkswaterstaat, Grote Projecten en Onderhoud Afdeling Advies Technisch Management Beheerder: Vincent Kramer Wijzigingen Versie Herziening Validatie (K4, K6) en Verificatie (S2, S7) doorgevoerd. - Inconsistenties tussen blokken tgv. vorige wijzigingen bijgewerkt. - Gebruik van de term stakeholder in plaats van belanghebbende. - Beperkte taalkundige redactie en correctie van diverse typefouten. - Verschuiving van tekstfragmenten en figuren i.v.m. logischere lijn. - Tabellen verschoven om veelvuldig lege bladzijden te voorkomen. Wijzigingen Versie Nieuwe organisatienamen doorgevoerd. - Links naar Werkwijzer Aanleg zijn hersteld. - Inhoudelijke teksten P2, P3 en P4 zijn verbeterd. - Verwijzing naar RBA - S3 is aangepast. Wijzigingen Versie Links Werkwijzer Aanleg zijn hersteld. - Startpakket Klanteisendatabase verwijderd. - Beheren baselines verplaatst van P2 naar P4, overige blokken verschoven. Wijzigingen Versie Herziening Vraagspecificatie deel 1 Eisendeel doorgevoerd; - WWB0045 Variantenanalyse, WWB0045M Sjabloon Variantenanalyse Nota toegevoegd; - Hulpmiddel WWB0025 Raakvlakkenbeheer toegevoegd; - Tekstuele fouten hersteld; - en output geconformeerd. 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 1.1 tov versie Verbeterde opmaak - s laten terugkoppelingen zien.

4 Pagina 4 van 40 Stappenplan van projectopdracht tot Vraagspecificatie 24 september 2014

5 Inhoudsopgave Inleiding 6 Leeswijzer 7 1. Structureren project 9 P1 Analyseren projectopdracht 10 P2 Structureren werkpakketten en producten 10 P3 Structureren organisatie 11 P4 Beheren baselines 12 P5 Beheren scope Vaststellen van de klantvraag 13 K1 Analyseren probleem- en projectdoelstellingen 14 K2 Analyseren stakeholders 15 K3 Verzamelen klanteisen 15 K4 Bepalen validatiestrategie 16 K5 Opstellen klanteisenspecificatie 17 K6 Valideren Ontwikkelen van het systeem 19 S1 Vastleggen bestaande situatie 21 S2 Bepalen verificatiestrategie 21 S3 Gebruiken basisspecificaties 22 S4 Analyseren 23 S5 Structureren en alloceren 24 S6 Ontwerpen 27 S7 Verifiëren 28 S8 Opstellen systeemspecificatie(s) 29 S9 Beheren eisen Uitwerken Vraagspecificatie 31 V1 Bepalen oplossingsruimte Vraagspecificatie 32 V2 Bepalen scope Vraagspecificatie 33 V3 Opstellen Vraagspecificatie 34 V4 Borgen kwaliteit Vraagspecificatie 34 V5 Beheren Vraagspecificatie Inkopen van Ingenieursdiensten 36 I1 Bepalen inkoopstrategie Ingenieursdiensten 37 I2 Bepalen WBS in het contract 37 I3 Opstellen Vraagspecificatie Ingenieursdiensten Relaties van het Stappenplan 39 Pagina 5 van 40

6 Inleiding Dit stappenplan beschrijft activiteiten voor de generieke stappen die worden doorlopen binnen projecten van RWS bij het toepassen van Systems Engineering. De reikwijdte omvat in principe elk mogelijk RWS-project in elke mogelijke projectfase, vanaf projectopdracht tot en met het uitwerken van de Vraagspecificatie. De activiteitenbeschrijvingen 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 RWS. Omdat de recente versie 3.0 van de Leidraad SE nog niet officieel binnen RWS is geïmplementeerd, wordt in dit document enkel verwezen naar de Leidraad SE v2.0. 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 en 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. Vanuit die vraag is een generiek stappenplan gemaakt dat in principe in elke projectomgeving, elke projectsituatie en elke projectfase toepasbaar is: van planuitwerking tot aan contractvoorbereiding. Het zijn activiteitenbeschrijvingen 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 van Rijkswaterstaat. Hoe dient u dit stappenplan en de activiteitenbeschrijvingen te gebruiken? Dit stappenplan beschrijft de te doorlopen stappen in een project en is te zien als een blokkendoos met SE-blokken. Met deze blokken kunnen verschillende projectteams producten realiseren. Afhankelijk van de complexiteit van het project, 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. Er zijn veel meer activiteiten nodig zijn om een heel project te realiseren. Met werkwijzebeschrijvingen (WWB s), basisspecificaties (BS) en best practices die door RWS zijn ontwikkeld, zijn het stappenplan en de activiteitenbeschrijvingen uit te werken tot projectspecifieke werkpakketbeschrijvingen. De hoofdstappen in het Stappenplan van projectopdracht tot Vraagspecificatie. Pagina 6 van 40

7 Van projectopdracht tot Vraagspecificatie Conform de Leidraad SE v2.0 maakt het stappenplan onderscheid in drie verschillende typen specificaties: - Specificatie van de klantvraag (klanteisenspecificatie) - 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, Ontwikkelen van het systeem en Uitwerken van de Vraagspecificatie. 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. leiden tot producten. Alle producten worden gerealiseerd door RWS collega s of dienen te worden uitbesteed. 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 op een zeker moment 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, echter voor de scope van dit stappenplan wordt de Vraagspecificatie als einddoel beschouwd. Minder geschikt voor E&C en prestatiecontracten Dit stappenplan is met name opgesteld voor projectteams die naar een D&C en een DBFM overeenkomst toe werken. Het stappenplan is ook te gebruiken voor teams die werken aan een E&C overeenkomst; de overeenkomst is dan echter anders opgebouwd. Voor het opstellen van een prestatiecontract is dit stappenplan minder geschikt. De juiste procesbeschrijvingen voor onderhoud ontbreken nog. 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 hulpmiddelen. 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 is door de processen uit het stappenplan navigeren. Zo wordt de samenhang van het stappenplan op een interactieve manier duidelijk: Link naar de processen van de bibliotheek Aanleg Indien u de cursus Stappenplan SE van Rijkswaterstaat wilt volgen over het gebruik en de toepassing van het stappenplan bij een project, kunt u advies in te winnen bij de adviseurs systeemontwikkeling van Rijkswaterstaat (vragenloket.se@rws.nl). Pagina 7 van 40

8 Pagina 8 van 40 Stappenplan van projectopdracht tot Vraagspecificatie 24 september 2014

9 1. Structureren project Met Systems Engineering benadert RWS de projecten vanuit het systeemdenken. De Leidraad SE v2.0 zegt hierover: - Een systeem is een samenwerkende combinatie van elementen bedoeld om, bij uitvoering van een gespecificeerde functie, een bepaald doel te realiseren. - Systeemdenken is het grote plaatje bekijken: vanuit een holistische visie beschouwen van complexe problemen en mogelijke oplossingen. Figuur 1 Voorbeeld van samenhang in systemen (uit Leidraad SE v2.0) 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 (stap P1). Om gestructureerd aan het werk te gaan, is het noodzakelijk om de projectactiviteiten en de projectproducten gestructureerd en expliciet in beeld te brengen. Hiervoor wordt achtereenvolgens gebruik gemaakt van een Work Breakdown Structure (WBS) en een Product Breakdown Structure (PBS) (stap P2). Met een Organisatie Breakdown Structure (OBS) wordt inzichtelijk gemaakt hoe de verantwoordelijkheden, de producten en de activiteiten zijn verdeeld over de projectleden. (stap P3) Bij het structureren van het project hoort verder het definiëren en beheren van baselines (stap P4). Het beheren van baselines is een manier om ervoor te zorgen de producten binnen een project op elkaar afgestemd blijven. Deze uitwerkingen (stappen P1,2,3,4) leveren input op voor het totale projectplan. Op basis van de stappen in het vervolg van het project dient de projectscope continu te worden beheerd en waar nodig bijgesteld (P5). Het beheren van de scope is dus een specifiek gemaakte vorm van proces P4: beheren baselines. Pagina 9 van 40

10 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 brondocumentatie 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 brondocumentatie 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 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 v2.0). - Format scopeformulier MIRT (Werkwijzer Aanleg 787) - Scopeformulier P2 Structureren werkpakketten en producten P2 Het definiëren en structureren van de werkpakketten en de daaruit volgende producten die noodzakelijk zijn om uitvoering te geven aan de projectopdracht. - Scopeformulier - Benoem de hoofdprocessen en subprocessen die moeten leiden tot het beoogde projectresultaat ofwel het te realiseren systeem. Denk ook aan processen in 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 fasering voor de MIRT projecten. - Structureer deze processen in een Work Breakdown Structure (WBS) tot een beheersbaar niveau waarop werkpakketten worden geschreven. Zie figuur 2. - Benoem de hoofdproducten en deelproducten die als output het resultaat van deze processen vormen. - Structureer de producten in een Product Breakdown Structure (PBS) op het niveau van de output van de werkpakketten. Voor elke WBS en PBS geldt de 100% regel: alle werkpakketten en producten samen maken het werk. - Zorg ervoor dat elk werkpakket één product als output heeft. - Leg relevante informatie bij de processen en producten vast in de werkpakketbeschrijvingen, zoals tijd, kosten, verantwoordelijkheden, activiteiten, input, output, producteisen, risico s, raakvlakken met andere werkpakketten e.d. - Werkpakketten vormen de input voor de projectplanning en zijn gekoppeld aan het risicodossier. Pagina 10 van 40

11 P2 Structureren werkpakketten en producten P2 - Werkwijzebeschrijving WWB-0028 Opzetten van een WBS (Werkwijzer Aanleg 852) - Werkwijzebeschrijving WWB-0029 Opstellen van een werkpakketbeschrijving (Werkwijzer Aanleg 853) - Werkwijzebeschrijving WWB-0029M Sjabloon werkpakketbeschrijving (Werkwijzer Aanleg 839) - Work Breakdown Structure (WBS) - Product Breakdown Structure (PBS) - Werkpakket Beschrijvingen Figuur 2 - Work Breakdown Structure (uit Leidraad SE v2.0) P3 Structureren organisatie P3 Het verdelen van taken en rollen over de projectorganisatie om de werkpakketten uit te kunnen voeren. - Work Breakdown Structure (WBS) - Werkpakket Beschrijvingen - Analyseer welke kennis en ervaring nodig is voor het project. Stel op basis hiervan het projectteam samen en/of organiseer opleidingen om kennis op het vereiste peil te brengen. - Maak aan de hand van de WBS de taken en rollen inzichtelijk: wie voert welke werkpakketten uit en wie is waarvoor verantwoordelijk. - 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 (voor indeling naar IPM-model); zie ook H6 van dit stappenplan. - Organisatie Breakdown Structure (OBS) Pagina 11 van 40

12 P4 Beheren baselines P4 Het tot stand brengen en onderhouden van de formeel bevroren status van een systeem of project als referentie voor verdere werkzaamheden. - 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. - E-learning module baselinebeheer - Baselines 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. - Actuele scopeformulier - Wijzigingsvoorstellen op scopeformulier - Richt een Verzoek-tot-Wijziging (VtW) -procedure in om voorgestelde wijzigingen in de projectscope te beheren (gebruik inzichten uit het vakgebied configuratiemanagement om baselines te definiëren en de procedures in te richten, zie bijvoorbeeld stap P2). - Beoordeel de wijzigingsvoorstellen op de projectscope op gevolgen voor tijd, geld en kwaliteit. - Stel significante scopewijzigingen vast binnen het IPM team. - Leg scopewijzigingen voor aan de opdrachtgever om te accorderen. - Nvt. - Bijgewerkt scopeformulier Pagina 12 van 40

13 2. Vaststellen van de klantvraag Vanuit RWS-perspectief gezien kan worden gesteld dat een project succesvol is als er zo goed mogelijk aan de klantvraag wordt voldaan. Fysieke omstandigheden, normen en richtlijnen, beschikbare tijd en budget begrenzen hierbij de oplossingsruimte. De klantvraag staat dus centraal. Onder klantvraag verstaan we de verzameling van behoeften, verwachtingen en wensen van alle betalende en niet-betalende stakeholders met betrekking tot de realisatie van het systeem. 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 van wezenlijk belang om de klantvraag binnen een projectcontext expliciet in beeld te brengen en te beheren. Figuur 3 geeft deze overdrachtsmomenten weer. Figuur 3 Informatieoverdracht in levenscyclus (uit Leidraad SE v2.0) 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 verwachtingen, behoeften, wensen 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 bijbehorende validatiemethodes vast te leggen (K4). Dit alles is input voor de Klant Eisen Specificatie (KES) van het project (K5), waarin tevens wordt vastgelegd welke klanteisen wel en welke niet gehonoreerd zijn (uit S4). Het vastleggen van klanteisen is geen eenmalige actie. De klanteisenspecificatie moet worden bijgesteld, zodra er nieuwe stakeholders in beeld komen, een klanteis verandert of resultaten uit de systeemontwikkeling dit noodzakelijk maken. Het is daarbij van belang om te valideren of de eisen en oplossingen die zijn afgeleid van de klanteisen nog invulling geven aan het beoogde gebruik van het systeem en de behoeften van de stakeholders en de daaruit volgende randvoorwaarden (K6). Pagina 13 van 40

14 Figuur 4 Het belang van gedegen verificatie en validatie (uit Leidraad SE v2.0) K1 Analyseren probleem- en projectdoelstellingen K1 Inzicht krijgen in het op te lossen probleem en bijbehorende projectdoelstellingen. - Scopeformulier - Brondocumentatie van het project - Bevraag de opdrachtgever van het project (gebruik de waarom-vraag) en analyseer het scopeformulier en meest dominante brondocumentatie van het project; - Baken het project af door het system of interest van het project te beschrijven en analyseer de omgeving. - Organiseer desgewenst een brainstormsessie binnen het projectteam, waar nodig mét stakeholders (overweeg dan om een zg. 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 (gewenste versus bestaande toestand); wanneer het probleem is opgelost (maak dit meetbaar); of er naast het probleem nog andere wensen zijn en welke kansen er voor het project bestaan. - Bundel de probleembeschrijvingen en doelstellingen in één document: het probleemdefinitie document. - Stel aan de hand van de behoeften die het project gaat invullen (zoals verwoord in de probleemdefinitie) de doelstellingen van het project vast. Maak deze doelstellingen zo meetbaar mogelijk. Deze doelstellingen kunnen worden verwerkt in het projectplan. - Zorg ervoor dat de relaties tussen de problemen en doelstellingen van het project in twee richtingen traceerbaar zijn. - Value Engineering studie (gefaciliteerd door VE specialisten) - Beschrijving system of interest - Probleemdefinitie document - stellingen van het project Pagina 14 van 40

15 K2 Analyseren stakeholders K2 Inzicht krijgen in de stakeholdersbelangen en de invloed van stakeholders op het project. - Brondocumentatie van het project - Scopeformulier - Beschrijving system of interest - Inventariseer op basis van de beschrijving system of interest alle stakeholders en leg de contactinformatie vast in een stakeholdersoverzicht. - Bepaal voor elke stakeholder zijn belang en de aard van het belang, de invloedssfeer en het machtsmiddel en leg deze vast in hetzelfde overzicht. Het sjabloon van de klanteisen specificatie geeft hier richtlijnen en aanwijzingen voor. - Gebruik voor de stakeholdersanalyse de beschikbare brondocumentatie van het project en de overlegverslagen met stakeholders. Vaak zullen gaandeweg het proces nieuwe stakeholders worden geïdentificeerd. Een gemeente wordt bijvoorbeeld een stakeholder als één van de mogelijke oplossingen binnen haar gemeentegrenzen wordt gerealiseerd. - Handreiking stakeholdersanalyse (Werkwijzer Aanleg 895) - Werkwijzebeschrijving WWB-0009 Bemachtigen van eisen (Werkwijzer Aanleg 846) - Sjabloon Klant Eisen Specificatie (Werkwijzer Aanleg 840) - Stakeholdersoverzicht K3 Verzamelen klanteisen K3 Het objectief en herleidbaar vastleggen van de klantvraag die het project beïnvloedt. - Stakeholdersoverzicht - Brondocumentatie van het project - Gespreksnotities en verslagen van overleggen met stakeholders - Bestuursovereenkomsten etc. - Validatiestrategie - Inventariseer de klantvraag (het geheel aan behoeften, verwachtingen, wensen en randvoorwaarden) van stakeholders op basis van bijvoorbeeld besprekingsverslagen, bestuursovereenkomsten en brondocumentatie van het project. - De klantvraag is 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 in een database. Deze vastgelegde klantvraag is later input voor het opstellen van de klanteisen specificatie in stap K5. - Vertaal de klantvraag naar concrete klanteisen volgens het format van figuur 5. NB: de manier van vertalen van de klantvraag in klanteisen is vaak onderdeel van de onderhandelingen met de stakeholders. - Maak bij het gesprek met de stakeholder afspraken over de wijze van aantonen dat aan de klanteisen wordt voldaan. Dit kan meerdere momenten betreffen, bijv. tijdens de planuitwerking, contractvoorbereiding, ontwerp, uitvoering en bij de oplevering of overdracht. Hoe ver dat aantonen dat aan de klanteisen wordt voldaan, hangt af van de macht, het belang en de invloed van betreffende stakeholder (zoals opgenomen in het Pagina 15 van 40

16 K3 Verzamelen klanteisen K3 stakeholdersoverzicht). - Leg conform de validatiestrategie (stap K4) bij elke eis de specifieke bewijsvoeringsmethode, het pass/fail-criterium en de beoordelaar vast voor de validatie in stap K6. - Zorg ervoor dat de relaties tussen doelstellingen van het project, de probleemdefinitie en de klanteisen specificatie in twee richtingen traceerbaar zijn. - Herformuleer eventueel de klanteisen of wijs eventueel klanteisen 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) - Verzameling klanteisen (beheerd in een klanteisen database) Code Scheiden verkeersstromen Verwijzing naar Eisinitiator systeemeisen D.001 Het scheiden van beroepsvaart en recreatievaart Ntb. District ten aanzien van de veiligheid. 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 klanteis (Bron: Sjabloon Klant Eisen Specificatie (WWA 840)) K4 Bepalen validatiestrategie K4 Het vaststellen van de wijze waarop wordt aangetoond dat het te ontwikkelen systeem voldoet aan de klanteisen die zijn afgeleid van het beoogd gebruik of de beoogde toepassing. - Klanteisenspecificatie - Baselines in projectfasering - Projectplanning - Stel vast hoe de validatie van het systeem zal verlopen ten opzichte van de baselines in de planning van het project. Dit kan meerdere fasen betreffen, bijvoorbeeld de planuitwerking, contractvoorbereiding, ontwerp, uitvoering en aansluitend de oplevering of overdracht. - Bepaal welke validatiemethoden geldig (valide) zijn en welke daarvan voorgeschreven worden. - Sluit hierbij aan op de afspraken die in stap K3 reeds met de stakeholders zijn gemaakt over de wijze van aantonen dat aan hun klanteisen wordt voldaan. - Stel een V&V-matrix of -tabel op met per eis de specifieke bewijsvoeringsmethode, het bijbehorende pass/fail -criterium en de beoordelaar. Vaak wordt de validatie in verschillende of zelfs meerdere projectfasen uitgevoerd. - Bepaal op welke baselines in de projectfasering gerapporteerd zal worden over de voortgang van de verificatie en validatie werkzaamheden. Pagina 16 van 40

17 K4 Bepalen validatiestrategie K4 - Leg de werkwijze met betrekking tot validatie vast in het V&V-managementplan. - Bespreek de voortgang van V&V regelmatig binnen het projectteam en met de opdrachtgever. - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Validatiestrategie (als onderdeel van het V&V-managementplan) Figuur 6 - Specificeren van de klanteisen (uit Leidraad SE v2.0) K5 Opstellen klanteisenspecificatie K5 Het gestructureerd documenteren van alle stakeholders met bijbehorende klanteisen en inzichtelijk maken welk deel daarvan gehonoreerd is door het project. - Scopeformulier - Probleemdefinitie document - stellingen van het project - Beschrijving system of interest - Stakeholdersoverzicht - Verzameling klanteisen - Validatiestrategie uit het V&V-managementplan - Bundel de output van de voorgaande stappen K1, K2, K3 en K4 in één document, genaamd de Klant Eisen Specificatie (KES), als ijkpunt van de klantvraag. Zie Figuur 6. - Laat het integraal project management (IPM)-team beslissen welke klanteneisen wel of niet gehonoreerd kunnen of mogen worden op basis van de van de projectscope en projectdoelstellingen. - Koppel dit naar terug de stakeholders. - Pas waar nodig in overleg met betreffende stakeholder de klanteisen aan naar aanleiding van het niet honoreren of naar aanleiding van uitkomst van de analyse van de klanteisen in stap S4. - Laat de betrokken stakeholders hun klanteisen en bijbehorende specifieke validatiemethoden in de KES accorderen. - Laat de KES vaststellen door de opdrachtgever. - Maak een baseline van de KES. Pagina 17 van 40

18 Toelichting: ook het ontwikkelen van het systeem (zie stappen S4, S5, S6 en S7) kan aanleiding geven om de klanteisen te heroverwegen en eventueel op onderdelen te herzien of af te wijzen (stap K3) Dit leidt dan tot aanpassing van de Klant Eisen Specificatie (stap K6). - Sjabloon Klant Eisen Specificatie (Werkwijzer Aanleg 840) - Klanteisenspecificatie K6 Valideren K6 Het bevestigen door de levering van objectief bewijs dat aan de eisen voor het specifiek beoogd gebruik of de specifiek beoogde toepassing is voldaan. - Klanteisenspecificatie - Systeemspecificatie - Validatiestrategie uit het V&V-managementplan - Scopeformulier - Laat aan de stakeholders zien hoe hun klanteisen zijn vertaald in systeemeisen en ontwerpen. - Toon aan dat het te ontwikkelen systeem of product voldoet aan de specifieke gebruiksof toepassingseisen, zoals verwoord in de klanteisenspecificatie. - Gebruik hierbij de validatiemethoden die bij de klanteisen zijn vastgelegd in stap K3 Verzamelen klanteneisen. - Verzamel per klanteneis het objectieve bewijs in de V&V-matrix of -tabel volgens stap K4 Validatiestrategie en breng het V&V dossier op orde. - Rapporteer per baseline over de voortgang van de validatie en voor welke eisen voor het beoogde gebruik of de beoogde toepassing er afwijkingen zijn geconstateerd. - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Actueel V&V-dossier - V&V-rapport per baseline Pagina 18 van 40

19 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, alloceren en ontwerpen inhoudt. Op basis van de klantvraag 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. Alle ontwerpkeuzes leiden weer tot afgeleide functionaliteiten die het systeem moet vervullen en tot nadere eisen, randvoorwaarden en ontwerpkeuzes voor de verdere ontwikkeling van het systeem. Deze loop gaat door tot het uitwerkingsniveau van een uitvoeringsgereed ontwerp is bereikt. De resultaten worden op de afgesproken detailniveaus vastgelegd in een of meerdere systeemspecificaties. Figuur 7- Iteratief specificatieproces (uit Leidraad SE v2.0) 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 vormt als input voor het volgende detailniveau. Binnen RWS wordt de ontwikkelfase van een project slechts gedeeltelijk doorlopen. Afhankelijk van de inkoopstrategie worden specificaties op een verschillend detailniveau uitgevraagd aan de markt (zie Hoofdstuk 4). 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 principes van Systems Engineering te doorlopen. De mate waarin activiteiten zoals beschreven in dit hoofdstuk door het projectteam van RWS zelf worden uitgevoerd is afhankelijk van de specifieke projectsituatie: de complexiteit, de besluitvorming en de inkoopstrategie van het project. Dit neemt niet weg dat betrokken projectteamleden moeten weten wat er bij komt kijken om volgens de principes van Systems Engineering een systeem volledig 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 planuitwerkingsfase leidt SE tot een beheerst proces en levert bovendien waardevolle informatie op voor de onderbouwing van ontwerpkeuzes en de onderhandelingen met stakeholders. De SE-principes sluiten zeer goed aan op de vereisten voor een zorgvuldig proces vanuit bijvoorbeeld de Tracéwet. Pagina 19 van 40

20 De ontwikkelfase kenmerkt zich 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 klantvraag 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 en K4). Hierin wordt uitgewerkt op welke momenten, op welke wijze en door welke functionarissen gaandeweg het project aangetoond zal worden dat de uitwerking van het systeem nog altijd voldoet aan de doelstellingen, klantvraag en de systeemeisen. Binnen RWS zijn standaarden uitgewerkt waar een projectteam gebruik van kan maken in de ontwikkelfase. De basisspecificaties zijn hier een voorbeeld van (S3). Figuur 8 Systeemontwikkeling: detailniveaus specificeren (uit Leidraad SE v2.0) Het iteratieve specificatieproces begint met het analyseren van het systeem (S4). Hier vinden diverse analyses plaats. De resultaten van deze analyses worden gestructureerd in beeld gebracht met eisen, functiebomen en objectenbomen en 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: voldoen de resultaten aan de (bovenliggende) specificaties? Dit wordt vastgelegd in een verificatietabel (S7). Het resultaat van dit iteratieve specificatieproces 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). Het geeft invulling aan de bovenliggende specificaties en beschrijft de kaders (oplossingsruimte) en gevraagde kwaliteit voor het vervolg van de systeemontwikkeling. Systeemspecificaties markeren dan ook de overgang van het ene detailniveau naar het volgende detailniveau in de ontwikkelfase. De keuze van het detailniveau waarop een systeemspecificatie wordt vastgesteld kan bepaald worden door de benodigde nauwkeurigheid van informatie in de besluitvorming. De eisen in de systeemspecificaties moeten beheerd worden om de consistentie met de andere activiteiten van het project te borgen (S9). Pagina 20 van 40

21 S1 Vastleggen bestaande situatie S1 Het verkrijgen van inzicht in de bestaande situatie. - Scopeformulier - 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 systeemspecificatie en uiteindelijk de vraagspecificatie. - Doe archiefonderzoek en vraag beschikbare gegevens op bij de beheerder. - Beoordeel de gegevens op compleetheid, nauwkeurigheid en actualiteit. - Voer nulinspecties uit en verricht, waar nodig, aanvullende metingen. - 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 dat het te ontwikkelen systeem voldoet aan de gespecificeerde eisen. - Systeemspecificatie - Baselines in projectfasering - Projectplanning - Stel vast hoe de verificatie van het systeem zal verlopen ten opzichte van de baselines in de planning van het project. Dit kan meerdere fasen betreffen, bijvoorbeeld de planuitwerking, contractvoorbereiding, ontwerp, uitvoering en aansluitende de oplevering of overdracht. - Bepaal welke verificatiemethoden geldig (valide) zijn en welke daarvan voorgeschreven worden. - Sluit hierbij aan op de validatiemethode van de klanteisen die in stap K3 reeds met de stakeholders zijn afgestemd en waar de betreffende systeemeisen van zijn afgeleid. - Stel een V&V-matrix of -tabel op met per eis de specifieke bewijsvoeringsmethode, het bijbehorende pass/fail -criterium en de beoordelaar. Vaak wordt de verificatie in verschillende of zelfs meerdere projectfasen uitgevoerd. - Bepaal op welke baselines in de projectfasering gerapporteerd zal worden over de voortgang van de verificatie en validatie werkzaamheden. - Leg de werkwijze met betrekking tot verificatie vast in het V&V-managementplan. - Bespreek de voortgang van V&V regelmatig binnen het projectteam en met de opdrachtgever. - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) Pagina 21 van 40

22 S2 Bepalen verificatiestrategie S2 - Verificatiestrategie (als onderdeel van het V&V-managementplan). Figuur 9 Het belang van gedegen verificatie en validatie (uit Leidraad SE v2.0) S3 Gebruiken basisspecificaties S3 Het bevorderen van uniformiteit tussen projecten en efficiency in projecten door het gebruik van beschikbare standaarden. - System Breakdown Structure (SBS; ook wel objectenboom) - Scopeformulier - Bepaal op basis van de System Breakdown Structure welke basisspecificaties gebruikt dienen te worden om systeemeisen af te leiden. - Bepaal welke eisen voor de verschillende objecten van de System Breakdown Structure gelden. Gebruik de eisformuleringen uit de basisspecificaties. - Verbind het Hoofdstuk 3 - Documenten waaraan gerefereerd wordt in de systeemspecificaties expliciet aan één of meerdere eisen, door vanuit de eisen expliciet te verwijzen naar deze documenten. - Werkwijzebeschrijving WWB-0010 Werken met basisspecificaties (WWA 847); - Gebruik van de basisspecificaties - Het stelsel van basisspecificaties - Generieke systeemeisen; - Overzicht van documenten waarnaar gerefereerd wordt voor de systeemspecificaties. Pagina 22 van 40

23 S4 Analyseren S4 Het analyseren van de gevraagde eigenschappen van het systeem en het vertalen van deze eigenschappen in SMART systeemeisen. - Klanteisenspecificatie - Bovenliggende systeemspecificaties (systeemeisen en ontwerpen) - Beschrijving bestaande situatie - Generieke systeemeisen uit de basisspecificaties - Verificatiestrategie - 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. - Stem de uitkomst (bijv. bijstellingen / afwijzingen van klanteisen) van de vertaling, de prioritering en de checks af met de stakeholders. Zie ook stap K3 en K5. - Analyseer de specificaties en het ontwerp dat gekozen is en formuleer systeemeisen op het lagere niveau. De kruistabel van het bovenliggende niveau geeft aan welke eisen uitgewerkt 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), beschrijf de functies en de prestatie van de functie in eisen of onderliggende eisen. - Stel de vraag waar het systeem wordt gebruikt of is geïnstalleerd: identificeer en formuleer raakvlakken. Gebruik voor complexe raakvlakken de beheersdocumenten conform WWB0025 Raakvlakkenbeheer. - 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 (de faaldefinitie). o Bepaal welke RAMS eisen dienen te worden gesteld. - Stel meetbare eisen op voor de verdere uitwerking van het systeem. o Categoriseer de eisen in type: functie, aspect, raakvlak of proces. o Maak de eisen SMART. o Koppel relevante informatie aan de eis, zoals uniek nummer, bronverwijzing e.d. o Leg de relaties (traceerbaarheid) tussen de eisen vast. - Leg conform de verificatiestrategie (stap S2) bij elke eis de specifieke bewijsvoeringsmethode, het pass/fail-criterium en de beoordelaar vast voor de verificatie in stap S7. - Werkwijzebeschrijving WWB Formuleren van eisen (Werkwijzer Aanleg 843) - Werkwijzebeschrijving WWB Raakvlakkenbeheer (Werkwijzer Aanleg 942) - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Leidraad RAMS (Werkwijzer Aanleg 502) - Systeemeisen - RAMS analyse - Raakvlakanalyse - Raakvlakkenbeheersdocument Pagina 23 van 40

24 Figuur 10 Analyse klanteneisen analyse (uit Leidraad SE v2.0) Figuur 11 - System Breakdown Structure (uit Leidraad SE v2.0) S5 Structureren en alloceren S5 Het structureren van het systeem door het alloceren van eisen, functies en hun prestaties aan objecten. - Systeemeisen - Raakvlakanalyse Pagina 24 van 40

25 S5 Structureren en alloceren S5 - Bepaal aan de hand van de functionele analyse (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 architectuur terug te vinden in de basisspecificatie. o 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. - Structureer de objecten waar het systeem uit moet bestaan in een objectenboom (SBS). Voor een objectenboom geldt de 100% regel: de onderliggende objecten vormen samen het bovenliggende object. Toelichting: 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 is de relatie van een object met zijn bovenliggend object te lezen als is onderdeel van. Daarom staat Sluis boven de objecten Deur en Pompsysteem (en bestaat de Sluis daarnaast uit nog meer objecten). - Koppel de functies aan objecten (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. - Structureer de raakvlakken tussen de omgeving en het System of Interest 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 alle overige eisen toe aan de objecten (bijvoorbeeld de raakvlakeisen van een systeem worden toebedeeld aan objecten). Bijvoorbeeld: een aspecteis over vormgeving wordt wel aan een gebouw gesteld, maar niet aan de inhoud van het gebouw. - 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 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 (WWA 849) - Werkwijzebeschrijving WWB Opstellen van een functieboom (WWA 850) - System Breakdown Structure (zie Figuur 11) - Systeemcontextdiagram (zie Figuur 12) - Function Breakdown Structure - Functie-allocatie overzicht (zie figuur 13) Pagina 25 van 40

26 Figuur 12 Systeemcontextdiagram voor een navigatiesysteem (Tom Tom). Figuur 13 - Allocatie van systeemeisen aan objecten (uit Leidraad SE v2.0) Pagina 26 van 40

27 S6 Ontwerpen S6 Het ontwikkelen van het ontwerp van het systeem. - System Breakdown Structure - Function Breakdown Structure - Functie-allocatie overzicht - Systeemeisen - RAMS analyses - Raakvlakkenbeheersdocument - 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. Toelichting: 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 deelfuncties geleverd moeten worden: innemen vaartuig, nivelleren waterniveau, uitlaten vaartuig. De prestatie wordt als volgt verdeeld over de verschillende functies: innemen vaartuig 6 min., nivelleren water 5 min., uitlaten vaartuig 4 min. o 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 ontwerpen door ze op haalbaarheid te verifiëren. - Leg vast welke criteria worden gebruikt om de ontwerpen af te wegen. Voorbeelden van criteria zijn: kosten, tijd, risico s, maar ook doorstroming, hinder tijdens de bouw, beschikbaarheid en dergelijke. - Werk de overgebleven ontwerpen 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. (zie Figuur 15) - Werk de gekozen variant nader uit tot het ontwerp van het systeem, bijvoorbeeld m.b.v. een geometrisch model. Leg dit vast in tekeningen van de variant op het detailniveau waarop alle systeemeisen geverifieerd kunnen worden en dat past bij de besluitvormingsfase waarin het project zich bevindt. - Leg de marges die bij de ontwerpkeuzes van toepassing zijn vast in de nadere specificaties van het systeem. - Onderbouw de gemaakte keuzes in een ontwerprapportage. - Werkwijzebeschrijving WWB-0045 Variantenanalyse (Werkwijzer Aanleg 903) - Werkwijzebeschrijving WWB-0045M Sjabloon Variantenanalyse Nota (WWA 904) - Systeemontwerp (toelichting: ontwerpen met bijbehorende ontwerprapporten met daarin bijvoorbeeld de Variantenanalyse Nota (zie Figuur 15). Pagina 27 van 40

28 Figuur 14 - Ontwerp en oplossingsruimte (uit Leidraad SE v2.0) Beoordelingscriteria Wegingsfactor Varianten Hoofdcriteria Subcriteria Variant 1 score 1 Gewogen Variant 2 score 2 Gewogen Criterium a Subcriterium a1 <a> <score> <a>*<score> <score> <a>*<score> Subcriterium a2 <b> Criterium b Subcriterium b1 <c> Subcriterium b2 <d> Totaal score Subcriterium b3 <e> Totaal is 100% <totaal score> <totaal score> Figuur 15 voorbeeld van een Trade-off tabel S7 Verifiëren S7 Het bevestigen door het leveren van objectief bewijs dat aan de gespecificeerde eisen is voldaan. - Systeemspecificatie - Verificatiestrategie uit het V&V-managementplan - Scopeformulier - Controleer of de systeemspecificatie compleet, actueel, consistent en duidelijk is, passend bij het uitwerkingsniveau behorende bij de betreffende baseline. - Toon aan dat het te ontwikkelen systeem voldoet aan de gespecificeerde eisen, zoals verwoord in de systeemspecificatie. - Gebruik hierbij de verificatiemethoden die bij de systeemeisen zijn vastgelegd in stap S4 Analyseren. - Verzamel per systeemeis het objectieve bewijs in de V&V-matrix of -tabel volgens stap S2 Verificatiestrategie en breng het V&V dossier op orde. - Rapporteer per baseline over de voortgang van de verificatie en voor welke eisen er afwijkingen zijn geconstateerd ten opzichte van de gespecificeerde eisen. - Werkwijzebeschrijving WWB-0044 Verifiëren en valideren (Werkwijzer Aanleg 854) - Actueel V&V-dossier - V&V-rapport per baseline Pagina 28 van 40

29 Figuur 16 - Verificatie en validatie in V-model (uit Leidraad SE v2.0) S8 Opstellen systeemspecificatie(s) S8 Het vastleggen van de specificatie(s) van het systeem ten behoeve van de verdere uitwerking van het ontwerp van het systeem. - Systeemeisen - Systeemontwerp - System Breakdown Structure - Systeemcontextdiagram - Function Breakdown Structure - Functie-allocatie overzicht - Beschrijving van bestaande situatie - Overzicht documenten waarnaar gerefereerd wordt voor de systeemspecificaties - Voeg alle gegenereerde informatie uit het specificatieproces per object uit System Breakdown Structure gestructureerd en traceerbaar samen. - Bouw de systeemspecificatie(s) op conform het sjabloon voor de systeemspecificatie. In de praktijk worden de eisen meestal beheerd in een eisenbeheer programma. Met dit programma wordt dan de systeemspecificatie gegenereerd. - Leg zowel de objectbeschrijving, eisen én oplossingsruimte, verificatiemethoden, documenten waaraan gerefereerd wordt en overige relevante gegevens 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. - 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) - Sjabloon systeemspecificatie (werkwijzer Aanleg 902) Pagina 29 van 40

30 S8 Opstellen systeemspecificatie(s) S8 - Systeemspecificatie(s) Toelichting: de systeemspecificatie is zowel input voor het maken van een Vraagspecificatie, als ook input voor het maken van planuitwerkingsproducten. S9 Beheren eisen S9 Het beheren van de eisen in de verschillende soorten specificaties (klanteisen specificatie, systeemspecificatie en Vraagspecificatie) en checken of ze overeenstemmen met de producten van het project. - Klanteisenspecificatie - Systeemspecificatie - Vraagspecificatie - Projectplan - Beheer de eisen in de verschillende specificaties door: o elke eis uniek te maken, o afhankelijkheden tussen eisen traceerbaar te maken, o inzichtelijk te maken hoe de klanteisen vertaald zijn in de systeemspecificatie, o relaties tussen de eisen in beeld te brengen, o versiebeheer 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, verificatiestrategie etc. - Ga na of de eisen in overeenstemming zijn met andere producten binnen het project, zoals de probleemanalyse en de doelstellingen van het project. - Ga na of de relaties tussen specificaties 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 klanteisenspecificatie - Gewijzigde systeemspecificatie - Gewijzigde Vraagspecificatie Pagina 30 van 40

31 4. Uitwerken Vraagspecificatie In de Leidraad SE v2.0 is de Vraagspecificatie gedefinieerd als de output van het specificatieproces van de Opdrachtgever en de input voor het specificatieproces van de 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). Figuur 17 - Scheidslijn Opdrachtgever - Opdrachtnemer (uit Leidraad SE v2.0) De in het kader van de marktbenadering uitgedachte inkoopstrategie, de aanbestedingsprocedure, de EMVI-criteria en de contractbeheersingsstrategie bepalen de vorm, inhoud en niveau van de Vraagspecificatie. Op basis van de geboden oplossingsruimte en bijbehorende diepgang van eisen in de Vraagspecificatie (stap V1) en de scope van het contract (stap V2) wordt de uitsnede van de systeemspecificatie gemaakt. De Vraagspecificatie bepaalt daarmee het System of Interest van de Opdrachtnemer en deze zal bijna nooit volledig overeenkomen met het 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 sjablonen beschikbaar op het contractenbuffet. Op basis van de van toepassing zijnde systeemeisen wordt het sjabloon gevuld (stap V3). NB bij D&C-contracten is er sprake van een Vraagspecificatie Eisendeel en een Procesdeel. Bij DBFM-contracten worden andere termen gebruikt en heten deze achtereenvolgens de specificatie en Managementspecificatie. In het kader van de kwaliteitsborging van het aanbestedingsdossier (KAd) is binnen RWS een zogenaamd KAd-adviestraject ingericht waarbij op drie momenten in het proces door gecertificeerde medewerkers adviezen worden gegeven en toetsen worden uitgevoerd volgens een vastgesteld advies- en toetskader SE. (stap V4). Pagina 31 van 40

32 Als controle 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 systeemspecificatie(s). Figuur 18 - Verificatie en validatie van aanbodspecificatie aan de Vraagspecificatie V1 Bepalen oplossingsruimte Vraagspecificatie V1 Het risico gestuurd afwegen van de oplossingsruimte. - Inkoopstrategie - Aanbestedingsprocedure (met inschrijvingsvereisten, EMVI-gunningscriteria, etc.) - Contractbeheersingsstrategie - Scopeverdeling - Risicodossier - Analyseer de oplossingsruimte die de markt geboden kan worden op basis van randvoorwaarden uit omgeving en juridische ruimte in lopende procedures. - Schat per object / specificatie de risico s in die kunnen optreden bij het geven van meer of minder oplossingsruimte en leg deze expliciet vast. - Bepaal per object/specificaties op basis van de risico s het benodigde detailniveau van de eisen. Werk daarbij top-down door de systeemeisen heen. - Beleid van RWS is om niet méér details voor te schrijven en uit te vragen aan de markt dan nodig. Daarom geldt dat eisen die dieper gaan dan gewenst vanuit het oogpunt van de oplossingsruimte, niet worden opgenomen in het contract. Voorwaarde daarbij is een beheersbaar contract. Alleen als risico s niet op een andere manier beheerst kunnen worden is het geaccepteerd om dieper liggende eisen op te nemen. Maak de koppeling met het risicodossier daarom expliciet. - Communiceer integraal binnen het project over de gekozen diepgang van de eisen. Dit is bijvoorbeeld van invloed op de onzekerheid in de raming of het detailniveau van het (O)TB-ontwerp. - nvt - Beschrijving oplossingsruimte - Gewijzigd risicodossier Pagina 32 van 40