Ik mis in dit document hoe om gegaan moet worden met afbeeldingen bij eisen. Het komt voor dat bij eisen figuren zitten waar aannemer aan moet voldoen. Hoe wordt deze data gedeeld?

Wordt hier bijvoorbeeld informatief, bindend etc. bedoelt?

Volgens de definitie van de NEN2660 zijn dit activiteiten die iets doen met objecten, zoals ik dat interpreteer zijn dat activiteiten zoals, storten beton, aanbrengen asfalt etc. Maar niet processen zoals risicomanagement, opstellen voortgangsrapportages. Deze missen we dan wel. Of zien we dit ook als "Werkzaamheid"?

Deze lijst is niet limitatief, proces ontbreekt.

Dit zijn de life cycle stages. Deze handleiding gaat met name over de uitwisseling tussen OG en ON. Verificaties van ON gaat over projectfases, niet life cycle fases.

Ik mis hier nog: Ontwerprandvoorwaarde (kan ook gezien worden als systeemeis..) Aspect Uitvoering (Uitvoeringsgerelateerde eisen) Aspect Milieuhygiëne (dit is anders dan bv duurzaamheid) Externe raakvlakeis Interne raakvlakeis

Ter bevestiging, deze lijst is niet in beton gegoten. Diverse organisaties gebruiken andere faseringen. Bijvoorbeeld initiatief, ontwikkeling, contract, ontwerp, realisatie etc.

De FIT, DAT, SIT en SAT staat dubbel. Dit is allemaal "Testen". De methode blijft Testen. Welke test dit is is een nadere specificatie en dient opgenomen te worden in de omschrijving van het verificatieplan.

Ik ben toch wel benieuwd wat hier wordt bedoelt met verificatieplan. Het daadwerkelijke verificatieplan voor bijvoorbeeld de uitvoering is niet de bedoeling. Onderliggende structuur is niet gegeven bij aannemers. Het komt vaker voor dat er een verificatievoorschrift wordt opgesteld op de relatie tussen eis en onderwerp. Vervolgens kan een verificatieplan vaker (afhankelijk van fase en geografie) aangetoond worden. (het is een te lang verhaal)

In contracten waar installaties zoals bijvoorbeeld tunnelinstallaties in de scope zitten worden soms codes voorgeschreven in eisteksten. Dit bijt met deze regel. Ter discussie: hoe dient om te gaan te worden met programmeringscodes van software in eis specificaties?

Wellicht verstandig om hier een maximaal aantal characters op te nemen voor het veld eistekst. Met name bij processpecificaties wilt een stakeholder soms lange teksten opnemen wat niet ten goede komt voor de verificatie en beheersing. Wel geloof ik dat dit een opvoeding is van de sector. Voorstel van maximaal aantal tekens is 2000.

Ik mis het meta veld Eis initiator. Bij contract specificaties is het vaak zo dat andere stakeholders ook eisen inbrengen. Opdrachtgever kan een provincie zijn echter kan aanvullende eisen opnemen van bijvoorbeeld een waterschap, energie maatschappij etc. Het is dan wenselijk om te weten wie de initiator is (Stakeholder/Organisator, geen namen)

Wordt hier met verificatieplan bedoelt: Voorgeschreven verificatie methode? Zo ja dan dit duidelijk opnemen in de omschrijving.

Volgens mij is Eistitel de meest gangbare term binnen de sector zoals je ook in de omschrijving schrijft. Voorstel om dit aan te passen naar Eistitel.