Handleiding van NEN2660-2 naar uitwisseling contractspecificaties

BIM Loket, in consultatie

Meer informatie over dit document
Laatste werkversie:
https://bimloket.github.io/contractspecificaties/
Geschiedenis:
Wijzigingsgeschiedenis
Redacteurs:
Elisabeth de Vries (BIM loket)
Rik (CROW)
Auteurs:
Bob Nonnekens (CROW)
Gebruikerscommissie CB-NL en ICDD (BIM loket)
Kernteam Provinciaal Contracten Buffet (CROW)
Feedback:
GitHub bimloket/contractspecificaties (wijzigingsverzoeken, nieuw issue, openstaande issues)
0 annotatie(s) met Hypothes.is

Samenvatting

De consultatieperiode is verlopen

Bekijk de werkversie op https://bimloket.github.io/contractspecificaties/

Dit document bevat een vertaling van het conceptuele model van NEN2660-2 - Regels voor informatiemodellering van de gebouwde omgeving naar tabellen die gebruikt kunnen worden voor uitwisseling van contractspecificaties (contractuele eisen). Het gaat specifiek om de UAV-GC contracten waarin eisen staan in de volgende documenten, die door elke opdrachtgever anders genoemd worden:

Status van dit document

Deze paragraaf beschrijft de status van dit document ten tijde van publicatie. Het is mogelijk dat er actuelere versies van dit document bestaan. Bekijk de lijst van BIM Loket technische standaarden op bimloket.nl en alle BIM Loket-publicaties via bimloket.nl.

Dit is een consultatieversie en is nog niet vastgesteld. Een publicatie als in consultatie impliceert geen onderschrijven door BIM Loket.

Belanghebbenden, geïnteresseerde partijen en anderen worden uitgenodigd dit document te reviewen en hun commentaar in te zenden vóór 1 november 2022. Zowel inhoudelijk als technisch commentaar als commentaar betreffende de implementeerbaarheid is welkom.

GitHub Issues wordt gebruikt voor de discussie van dit document. Eén issue per onderwerp vereenvoudigt de verwerking.

Reviewcommentaar mag ook achtergelaten worden als Hypothes.is annotaties. Gebruik het publieke kanaal voor je commentaar.

1. Inleiding

1.1 Context

Een contract is een de uitvraag of overeenkomst waarmee een asset manager zijn ontwerp-, bouw- of onderhoudswerk overeenkomt met een marktpartij. Bij het opstellen van een contract gaat grote aandacht uit naar het samenstellen van contractteksten, waarna deze teksten in pdf bestanden gepubliceerd worden. Dit leidt voor opdrachtnemers tot veel werk bij aanbestedingen, omdat de contractdocumenten allemaal moeten worden doorzocht op eisen, risico’s, uit te voeren werkzaamheden, enzovoorts. Bijvoorbeeld eisen aan het bouwwerk, eisen aan het werkproces van het project of eisen aan informatieleveringen. Als de eisen als data zouden worden aangeboden kunnen deze beter worden ingelezen in de projectbeheersingsomgevingen van opdrachtnemers. Ook zouden in meerdere projecten gebruikte eisen kunnen worden herkend en automatisch verwerkt in de planning van een project.

Onderdelen van een contract zijn:

1.2 Doel van dit document

Dit document heeft als doel om met gebruikers een eenvoudige uitwisselmethode vast te stellen voor contractspecificaties, met tabellen (in CSV), waarmee de meest gangbare applicaties voor eisenmanagement direct uit de voeten kunnen. Voor gebruikers die al verder zijn ontwikkeld op het gebied van interoperabiliteit wordt daarnaast ook uitwisseling in linked data mogelijk gemaakt.

Desgewenst kunnen gebruikers de contractspecificaties ook in andere talen uitwisselen, zoals XML, GML, Geopackage of als onderdeel van een VISI bericht. Dat is in dit document niet verder uitgewerkt.

1.3 Scope van dit document

Het gaat specifiek om de UAV-GC contracten waarin eisen staan (functionele specificaties) in de volgende documenten, die door elke opdrachtgever anders genoemd worden:

Daarnaast wordt een mogelijkheid geboden om de overige contractuele documenten uit te wisselen per paragraaftekst.

Het betreft hier een eerste, eenvoudige afspraak over uitwisseling van contractuele eisen, waarmee alle partijen met hun huidige applicaties uit de voeten kunnen. Het uitwisselen van het referentieontwerp of andere digitale bouwwerkinformatie is buiten scope van deze werkafspraak.

1.4 Informatiemodel

1.4.1 Bouwblokken

Het informatiemodel voor de contractspecificaties wordt zoveel mogelijk opgesteld met bouwblokken uit andere standaarden. De volgende linked data standaarden worden toegepast:

  1. Het conceptuele model van NEN2660-2 - Regels voor informatiemodellering van de gebouwde omgeving. Deze NEN-norm wordt gebruikt als primaire standaard en verwijst in zichzelf ook naar andere standaarden zoals SKOS, RDF-OWL en SHACL. Concepten in de contractspecificaties die hier niet in staan, maken onder meer gebruik van:
  2. Dublin Core (DC): een standaard voor het beschrijven van content op het internet. Doel van de Dublin Core is en was om een webdocument kernachtig, met een beperkte verzameling attributen, te beschrijven en op deze manier de metadata over zulke documenten beter uitwisselbaar te maken.

1.4.2 NEN2660-2

UML Schema van een deel van de NEN2660-2 voor toepassing op uitwisseling van contractuele eisen
Figuur 1 UML Schema van een deel van de NEN2660-2 voor toepassing op uitwisseling van contractuele eisen

1.5 Toepassing

1.5.1 Machine-leesbaarheid

De formats zijn zo ingericht, dat er geen dubbele informatie in staat, die zichzelf kan tegenspreken. Vanuit de eisen wordt bijvoorbeeld alleen verwezen naar de URI van het onderwerp, niet naar de naam. Dit heeft als nadeel, dat de formats moeilijker te controleren zijn door een mens. En als voordeel, dat informatie niet dubbel wordt uitgeleverd het het risico op onderlinge tegenstrijdigheden. Een deugdelijke implementatie kan dat voorkomen; als men echter geneigd is om de formats handmatig op te stellen bestaat dit risico. Omdat in de markt voldoende en toegankelijke applicaties beschikbaar zijn voor het opstellen van eisensets, is handmatig opstellen niet nodig. Als de leesbaarheid van de formats vergroot wordt, bestaat het risico dat eindgebruikers in de verleiding komen om last-minute aanpassen in de csv te doen, met kwaliteitsverlies tot gevolg.

1.5.2 Opstellen van tabellen

De tabellen kunnen het beste worden opgesteld in een applicatie die de gebruiker ondersteunt bij toepassing van het informatiemodel en het controleren van de volledigheid van de datasset. Bij het handmatig invullen van de tabellen bestaat een grote kans op fouten: dubbel gebruik van URI's, ontbrekende verplichte onderdelen, et cetera.

In een applicatie is het volgende wenselijk:

  • Zorg voor een eenvoudige menselijke controle op de tabellen, bijvoorbeeld door in de applicatie extra kolommen toe te voegen die wel de naam van het onderwerp laten zien. Een (juridische) controle door een mens kan op de uitgebreidere tabel plaatsvinden, waarbij de overbodige kolommen kunnen worden verwijderd voor uitwisseling. Daarmee wordt het ook mogelijk een daadwerkelijke uitgangscontrole uit te voeren als aanbestedende partij, zonder te moeten vertrouwen op de technische implementatie, wat voor veel eindgebruikers een black-box is.

  • Controleer of er in de eisteksten en andere tekstvelden geen codetekens worden gebruikt, die bij uitdraai naar linked data leiden tot interpretatie als code. Onder andere het gebruik van "aanhalingstekens" leidt tot foutmeldingen bij het gebruik van het ttl-formaat.

1.5.3 Inlezen van tabellen

De ontvanger van de tabellen kan deze inlezen in de eigen applicatie. Daarbij is het raadzaam om een controle te doen op de integriteit van de tabel: ontbreken van fouten zoals dubbel gebruik van URI's, ontbrekende verplichte onderdelen, et cetera.

Een ander veelvoorkomen euvel is het gebruik van leestekens en speciale in de teksten in de tabel, die bij uitwisseling worden aangezien voor code, bijvoorbeeld de overgang naar de volgende kolom, of het ontstaan van %#@# gekke tekens in de teksten omdat de ene applicatie uitgaat van html en de andere van platte tekst. Een visuele controle en handmatige aanpassing zal bij gebruik van CSV als uitwisselformaat altijd nodig zijn.

2. Doelen

Bij sommige projecten wordt onderscheid gemaakt tussen doelen en eisen. Dit komt door de werkwijze van functioneel specificeren. Bij het functioneel specificeren begin je met het vaststellen van de doelstellingen van het systeem. Vanuit die doelstellingen bedenk je welke functies het systeem nodig heeft. Daarna werk je specifieker uit hoe je de doelen wilt bereiken en welke eisen je wilt stellen.

Als je de doelen apart wilt uitwisselen van de andere eisen, dan kun je deze in een aparte tabel zetten. De kolommen van die tabel zijn hetzelfde als bij de eisentabel.

3. Eisen

Het eisenformat wordt gebruikt om de eisen te kunnen uitwisselen als data. Bij elke kolom is aangegeven wat de vertaling/binding is naar linked data standaarden, hoe vaak deze waarde ingevuld mag worden per eis ("kardinaliteit") en een beschrijving.

Een eis is een NEN2660:Requirement volgens NEN 2660.

3.1 Eisenformat

Het format wordt in 4 delen getoond in verband met de leesbaarheid van dit document. De laatste rij bevat een voorbeeld uitwerking.

EisURI EisCode EisNaam EisTekst EisToelichting EisheeftOnderwerp
In deze kolom staat de unieke identifier (URI) van de eis. In deze kolom staat de code of het nummer van de eis. In deze kolom staat de de naam oftewel de titel van de eis. In deze kolom staat de eistekst. In deze kolom staat de toelichting op de eis. In deze kolom staat de URI van het Onderwerp (subject) van de eis.
https://www.example.org/id/Voorbeeld-Eis1 EIS1099 Voorbeeldeis Dit is de tekst van de voorbeeldeis Dit is de toelichting van de voorbeeldeis, om achtergrond / doel en reden van de eis te kunnen verduidelijken https://www.example.org/id/Voorbeeld-Onderwerp1
EisURI EisCode EisNaam EisTekst EisToelichting EisheeftOnderwerp
In deze kolom staat de unieke identifier (URI) van de eis. In deze kolom staat de code of het nummer van de eis. In deze kolom staat de de naam oftewel de titel van de eis. In deze kolom staat de eistekst. In deze kolom staat de toelichting op de eis. In deze kolom staat de URI van het Onderwerp (subject) van de eis.
https://www.example.org/id/Voorbeeld-Eis1 EIS1099 Voorbeeldeis Dit is de tekst van de voorbeeldeis Dit is de toelichting van de voorbeeldeis, om achtergrond / doel en reden van de eis te kunnen verduidelijken https://www.example.org/id/Voorbeeld-Onderwerp1
VerificatieplanURI VerificatieplanMethode VerificatieplanFase VerificatieplanToelichting
In deze kolom staat de URI van een verificatieplan bij de eis. In deze kolom staat de verificatiemethode van het verificatieplan. In deze kolom staat de fase van het verificatieplan. In deze kolom staat de toelichting op de verificatiemethode bij de eis.
https://www.example.org/id/Voorbeeld-Verificatieplan1 https://data.crow.nl/contractspecificaties/id/Keuring https://data.crow.nl/contractspecificaties/id/Aanleg Een toelichting waarom een verificatiemethode wordt gevraagd bij de eis, of nadere invulling van de verificatiemethode
EisheeftDeel EisBron EisReferentiedocument
In deze kolom staat de URI van een onderliggende eis. In deze kolom staat de URI van een bron van de eis in een eisenbibliotheek of brondocument. In deze kolom staat de URI van een gerefereerd document waarin aanvullende eisen staan
https://www.example.org/id/Voorbeeld-Eis2 https://www.example.org/id/Voorbeeld-Document1 https://www.example.org/id/Voorbeeld-Document2
EisType EisStatus EisStatusOnderbouwing
In deze kolom staat het eistype. In deze kolom staat de status van de eis. In deze kolom staat een toelichting op de status van de eis.
https://data.crow.nl/contractspecificaties/id/Proceseis https://data.crow.nl/contractspecificaties/id/Vervallen Komt niet meer voor want ...

3.2 Details

3.2.1 EisURI

De URI is de unieke identifier voor de eis binnen het project.

Bij de eisen kan verwezen worden naar een eis in een eisenbibliotheek onder EisBron. Daar staat de URI van de eis uit de bibliotheek. Deze URI verwijst naar een openbaar gepubliceerde eis in een bibliotheek, bijvoorbeeld het Provinciaal Contracten Buffet.

De eis in het project moet een andere URI hebben dan de bron. Het is niet dezelfde eis, want deze wordt toegepast in (gekopieerd naar) een andere context.

URI; Voor het opstellen van URI's heeft de NEN 2660 een URI-strategie die je moet volgen.

Taalbinding Kardinaliteit Datatype
n.v.t. 1:1 xsd:anyURI
Noot

3.2.2 EisCode

De EisCode is een nummer van de eis in spreektaal, vaak een voor mensen herkenbare code of projectnummer. Deze meestal eenvoudige en soms logisch genummerde Code maakt het mogelijk om in een gesprek naar de eis te verwijzen, zonder de volledige URI te hoeven benoemen.

Taalbinding Kardinaliteit Datatype
skos:notation 1:1 xsd:string

3.2.3 EisNaam

De EisNaam wordt ook wel eens de titel van de eis genoemd, en geeft een voor mensen leesbare korte duiding van de inhoud van de eis.

De EisNaam hoeft niet uniek te zijn in het project, daarvoor heeft de eis een URI. Een unieke naam is voor de menselijke lezer vaak wel handig. Soms wordt de EisNaam in applicaties bijvoorbeeld gebruikt bij het visualiseren van de eisenboom. Unieke namen helpen in dat geval.

Taalbinding Kardinaliteit Datatype
skos:prefLabel 1:1 xsd:string

3.2.4 EisTekst

De EisTekst bevat de voor mensen leesbare inhoud van de eis. Op dit moment worden eisen in een contract meestal niet voorzien van een voor een systeem leesbare eis, zoals bijvoorbeeld een minimale waarde voor een attribuut van een object. Deze "dataficeringsslag" is buiten scope van dit document, omdat dit een verder gevorderd BIM niveau vraagt en dit document juist bedoelt is als opstap naar uitwisseling van data.

In de EisTekst kan verwezen worden naar een referentiedocument, waar aanvullende eisen in staan die gelden binnen het contract. De URI van dit document wordt dan opgenomen in de kolom Referentiedocument.

Taalbinding Kardinaliteit Datatype
rdf:value 1:1 xsd:string

3.2.5 EisToelichting

In deze kolom staat de toelichting op de eistekst

In contracten wordt dit gebruikt om nader te onderbouwen waarom deze eis gesteld wordt.

Taalbinding Kardinaliteit Datatype
skos:note 0:1 xsd:string

3.2.6 EisheeftOnderwerp

In deze kolom staat de URI van het Onderwerp van het verificatieplan bij de eis. Een eis kan aan meerdere Onderwerpen gesteld worden, er komen dan meerdere regels met dezelfde eis voor in de eisentabel.

Merk op, dat verwijzing naar de URI de tabel minder makkelijk leesbaar maakt voor de mens. Indien hier ook de naam van het concept zou worden toegevoegd, creëert dit dubbelingen met de onderwerpentabel en daarom mogelijk fouten. Daarom wordt alleen de URI gebruikt.

Taalbinding Kardinaliteit Datatype
cs:isVerificationOf 1:1 xsd:anyURI
cs:hasAsSubject 1:1 xsd:anyURI

Merk op, dat in de tabel een relatie niet benoemd is, omdat de "regel" de verbindende factor is: cs:hasAsSubject

3.2.7 VerificatieplanURI

De URI is de unieke identifier voor het verificatieplan binnen het project. Zie URI conform W3C.

Kardinaliteit: 1:1 ten opzichte van een verificatieplan Datatype:

Taalbinding Kardinaliteit Datatype
n.v.t. 1:1 xsd:anyURI
UML schema voor het informatiemodel voor het verificatieplan
Figuur 2 Het informatiemodel voor het verificatieplan.

3.2.8 VerificatieplanMethode

In deze kolom staat de methode waarmee de eis geverifieerd moet worden. Dit is een enumeratie. Een verificatiemethode is een eigenschap van een verificatieplan. De eigenschap heeft een enumeratie van de verschillende mogelijke methoden, dat wil zeggen dat de gebruiker een lijst kan opstellen met verificatiemethoden en een waarde uit deze lijst kan gebruiken.

Bij uitwisseling mag uitsluitend de onderstaande lijst gebruikt worden bij contractspecificaties, zonder zelf uitbreidingen te doen. Als elke opdrachtgever een eigen lijst met eistypen en aspecten gebruikt wordt het inrichten van standaard omgevingen voor de verwerking van contracteisen onnodig bemoeilijkt, waarbij bij elk project een aangepaste lijst moet worden gemaakt.

Classificatie volgens:

  1. NEN-EN-ISO 9000:2015 Kwaliteitsmanagementsystemen - Grondbeginselen en verklarende woordenlijst
  2. ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering
  3. Leidraad SE (V2 en 3)
Vaststellen
Activiteit om een of meer kenmerken en hun karakteristieke waarden te achterhalen
csw:Vaststellen
Bron: NEN-EN-ISO 9001:2015
Beoordelen
Vaststelling van de geschiktheid, toereikendheid of doeltreffendheid van een object voor het bereiken van vastgestelde doelstellingen
csw:Beoordelen
Bron: NEN-EN-ISO 9001:2015
Monitoren
Vaststellen van de status van een systeem, een proces, een product, een dienst of een activiteit. Bijvoorbeeld zettingen, monitoring van draaiuren t.b.v. optimale vervanging
csw:Monitoren
Bron: NEN-EN-ISO 9001:2015
Meten
Proces om een waarde vast te stellen. o.a. luchtsnelheidmetingen in tunnels, kalenderen van heipalen
csw:Meten
Bron: NEN-EN-ISO 9001:2015 en Leidraad SE v2
Keuren
Vaststelling van conformiteit met gespecificeerde eisen. Bijvoorbeeld keuring, ingangs- en uitgangscontrole
csw:Keuren
Bron: NEN-EN-ISO 9001:2015
Beproeven
Vaststellen volgens eisen voor een specifiek beoogd€ gebruik of toepassing
csw:Beproeven
Bron: NEN-EN-ISO 9001:2015
Evalueren
Beoordelen van de voortgang die behaald is met betrekking tot het bereiken van de doelen
csw:Evalueren
Bron: NEN-EN-ISO 9001:2015
Analyse
o.a. haalbaarheidsanalyse, kosten-batenanalyse
csw:Analyse
Bron: Leidraad SE v2
Berekening
o.a. sterkteberekeningen
csw:Berekening
Bron: Leidraad SE v2
Auditen
Audit van bestaande kwaliteitssystemen en -processen (o.a. Technical Inspection Services
csw:Auditen
Bron: Leidraad SE v2
Demonstratie
o.a. presentatie van de functionaliteiten van een bestaand systeem
csw:Demonstratie
Bron: Leidraad SE v2
Documentbeoordeling
o.a. documentinspecties, reviews, toetsen, ontwerpateliers
csw:Documentbeoordeling
Bron: Leidraad SE v2
Modellering
o.a. prestatiemodellen van beschikbaarheid, verkeersmodellen
csw:Modellering
Bron: Leidraad SE v2
Simulaties
o.a. dienstregelingsimulatie
csw:Simulaties
Bron: Leidraad SE v2
Referentie
o.a. gebruik van gecertificeerde producten
csw:Referentie
Bron: Leidraad SE v2
Testen
haalbaarheidstesten, FIT, FAT, SIT, SAT
csw:Testen
Bron: Leidraad SE v2
Factory Integration Test
o.a. hydraulische en mechanische installaties integraal testen
csw:FactoryIntegrationTest
Bron: Leidraad SE v2
Factory Acceptance Test
o.a. cameratesten in fabrieksopstelling
csw:FactoryAcceptanceTest
Bron: Leidraad SE v2
Site Integration Test
o.a. interactietesten tussen installatie- en besturingssystemen
csw:SiteIntegrationTest
Bron: Leidraad SE v2
Site Acceptance Test
o.a. calamiteitenoefeningen in bijzijn van hulpdiensten
csw:SiteAcceptanceTest
Bron: Leidraad SE v2
Schouw
o.a. visuele opname van projectlocatie
csw:Schouw
Bron: Leidraad SE v2
Inspectie (cs)
o.a. Arbo-inspecties, pompkelderinspecties
csw:Inspectie
Bron: Leidraad SE v2
Taalbinding Kardinaliteit Datatype
cs:verificationMethod 0:1 cs:VerificationMethodeType

3.2.9 VerificatieplanFase

In deze kolom staat de fase van het verificatieplan. Dit is een enumeratie. Hierbij worden de volgende fasen onderscheiden:

Conceptfase
Fase om (nieuwe) behoeften van stakeholders te inventariseren en mogelijkheden te beoordelen. De eerste klanteisen en oplossingsrichting worden hier bepaald. De conceptfase kan leiden tot het initiatief voor het ontwikkelen en realiseren van een systeem.
csw:Conceptfase
Ontwikkelfase
De fase om een systeem te specificeren dat voldoet aan de klanteisen. Aan het eind van de ontwikkelfase ligt er een (startklaar) ontwerp voor het gehele systeem.
csw:Ontwikkelfase
Realisatiefase
De fase om het systeem te vervaardigen en beproeven. Systeemelementen en deelsystemen worden geïntegreerd tot één geheel.
csw:Realisatiefase
Gebruiksfase
De gebruiksfase is de periode waarin het systeem wordt geëxploiteerd. Hier vinden de activiteiten plaats die nodig zijn om het systeem te gebruiken zoals beoogd.
csw:Gebruiksfase
Beheer- en onderhoudsfase
De periode waarin de ondersteunende activiteiten worden uitgevoerd, die noodzakelijk zijn om het systeem in werking te houden.
Sloopfase
De fase om een systeem met bijbehorende operationele diensten en functies buiten werking te stellen en te verwijderen.
csw:Sloopfase

Bron: Leidraad SE versie 2, Hoofdstuk 4

Taalbinding Kardinaliteit Datatype
cs:phase 0:1 cs:PhaseType

3.2.10 VerificatieplanToelichting

In deze kolom staat de toelichting op de verificatiemethode.

In contracten wordt dit gebruikt om nader toe te lichten waarom deze verificatiemethode gevraagd wordt.

Taalbinding Kardinaliteit Datatype
skos:note 0:1 xsd:string

3.2.11 EisheeftDeel

In deze kolom staat de URI van een onderliggende eis.

Hiermee kan een hiërarchie worden aangegeven van de eisenboom zoals gebruikelijk in contracten. Een eis kan meerdere onderliggende eisen hebben, er komen dan meerdere regels met dezelfde eis voor in de eisentabel.

Taalbinding Kardinaliteit Datatype
nen2660:hasPart 0:n xsd:anyURI

3.2.12 EisBron

De bron van de eis kan naar twee zaken verwijzen:

  1. De URI van de gebruikte eis uit een bibliotheek (indien deze niet gewijzigd is). Deze URI verwijst naar een openbaar gepubliceerde eis in een bibliotheek, bijvoorbeeld het Provinciaal Contracten Buffet. De eis in het project moet een andere URI hebben dan de bron. Het is niet dezelfde eis, want deze wordt toegepast in (gekopieerd naar) een andere context.
  2. De URI van een brondocument met herkomst van de eis. Deze URI verwijst naar een document in de documententabel.
Taalbinding Kardinaliteit Datatype
dct:source 0:n xsd:anyURI

3.2.13 EisReferentiedocument

Als in de eistekst wordt verwezen naar een referentiedocument, staat in deze kolom de URI van het gerefereerde document.

Instructie voor gebruik: omdat nog niet alle partijen in staat zijn om de data helemaal te verwerken, moet je het document wel in de eistekst noemen. De eistekst is leidend. Een ontvanger van de eisenset kan er ook niet van uit gaan, dat de opdrachtgever dit altijd in weet te vullen. Als in een eistekst naar een referentiedocument wordt verwezen, kan het zijn dat er geen relatie is gemaakt naar het referentiedocument.

Voorbeelden:

  • De eis verwijst naar een ontwerp of berekening die van toepassing is.
  • De eis verwijst naar een richtlijn, handleiding of norm die van toepassing is.

Deze URI verwijst naar een document in de documententabel.

Taalbinding Kardinaliteit Datatype
dct:references 0:n xsd:anyURI

3.2.14 EisType

In deze kolom staat het eistype. De aspecteisen zijn grotendeels overgenomen uit de Leidraad SE v3; de eistypen die aanduiden aan wat voor concept de eis is gesteld zijn aangepast aan de onderwerpen uit deze richtlijn. Dit is een enumeratie.

Bij uitwisseling mag je uitsluitend de onderstaande lijst gebruiken, zonder zelf uitbreidingen te doen. Als elke opdrachtgever een eigen lijst met eistypen en aspecten gebruikt wordt het inrichten van standaard omgevingen voor de verwerking van contracteisen onnodig bemoeilijkt, waarbij bij elk project een aangepaste lijst moet worden gemaakt.

Eistypen:

Informatie-eis
Verzameling van eisen die betrekking hebben op de te leveren informatieproducten
csw:Informatie-eis
Systeemeis
De beschrijving van het geheel aan samenhangende of elkaar beïvloedende eisen dat bijdraagt aan het tot standkomen en gebruiken danwel toepassen van het geintegreerde systeem.
csw:Systeemeis
Bron: Leidraad SE v3
Proceseis
De beschrijving van het gevraagde geheel van samenhangende of elkaar beïnvloedende activiteiten dat input omzet in output.
csw:Proceseis
Bron: Leidraad SE v3
Functie-eis
De beschrijving van de gevraagde beoogde werking en/of verrichting van een systeem.
csw:Functie-eis
Bron: Leidraad SE v3
Aspecteis: Betrouwbaarheid
De waarschijnlijkheid dat de vereiste functie wordt uitgevoerd onder gegeven omstandigheden gedurende een bepaald tijdsinterval.
csw:Aspecteis-Betrouwbaarheid
Bron: Leidraad SE v3
Aspecteis: Beschikbaarheid
De waarschijnlijkheid dat de vereiste functie op een willekeurig moment kan worden uitgevoerd onder gegeven omstandigheden.
csw:Aspecteis-Beschikbaarheid
Bron: Leidraad SE v3
Aspecteis: Onderhoudbaarheid
De waarschijnlijkheid dat de activiteiten voor onderhoud kunnen worden uitgevoerd binnen de hiervoor vastgestelde tijden, onder gegeven omstandigheden teneinde de vereiste functie te kunnen (blijven) uitvoeren.
csw:Aspecteis-Onderhoudbaarheid
Bron: Leidraad SE v3
Aspecteis: Veiligheid
De waarschijnlijkheid dat de vereiste functie en de daarvoor benodigde activiteiten zonder optredend letsel aan personen kan worden vervuld dan wel uitgevoerd en de waarschijnlijkheid dat de integriteit van de functie en de daaraan verbonden data en datastructuren gewaarborgd blijven van ongewenste beïnvloeding.
csw:Aspecteis-Veiligheid
Bron: Leidraad SE v3
Aspecteis: Gezondheid
De waarschijnlijkheid dat de vereiste functie en de daarvoor benodigde activiteiten zonder negatieve gezondheidsrisico's voor personen kan worden vervuld dan wel uitgevoerd.
csw:Aspecteis-Gezondheid
Bron: Leidraad SE v3
Aspecteis: Omgeving
De waarschijnlijkheid dat de vereiste functie en de daarvoor benodigde activiteiten zonder ongewenste risico's voor de omgeving kunnen wordenvervuld en/of gerealiseerd.
csw:Aspecteis-Omgeving
Bron: Leidraad SE v3
Aspecteis: Duurzaamheid
De waarschijnlijkheid dat de vereiste functie en de daarvoor benodigde activiteiten binnen de hieraan gestelde eisen en PPP (People/Planet/Profit)-doelstellingen kunnen worden gerealiseerd.
csw:Aspecteis-Duurzaamheid
Bron: Leidraad SE v3
Aspecteis: Vormgeving
De beschrijving van de gevraagde prestatie ten aanzien van het beeld en het materiaalgebruik met inachtneming van de omgevings- en de gezondheidseisen van het systeem en haar onderdelen.
csw:Aspecteis-Vormgeving
Bron: Leidraad SE v3
Aspecteis: Toekomstvastheid
De beschrijving van de gevraagde prestatie van een systeem ten aanzien van de vereiste levensduur van het systeem (als functie en als object) en haar onderdelen.
csw:Aspecteis-Toekomstvastheid
Bron: Leidraad SE v3
Aspecteis: Sloopbaarheid
De waarschijnlijkheid dat de vereiste functie aan het einde van de levensduur op beheerste wijze kan worden teruggebracht tot minimaal secundaire grondstoffen en met inachtneming van de overige RAMSHE-aspecten.
csw:Aspecteis-Sloopbaarheid
Bron: Leidraad SE v3
Taalbinding Kardinaliteit Datatype
nen2660:requirementTopicType 0:n cs:EisType

3.2.15 EisStatus

In deze kolom staat de status van de eis. Dit is een enumeratie. Voor contractspecificaties geldt dat de status één van deze twee zaken is: actueel of vervallen. Doel is om wijzigingen door een Nota van Inlichtingen of een contractuele wijziging in de eisenset te kunnen opnemen en met elkaar uit te wisselen.

Actueel
csw:Actueel
Vervallen
csw:Vervallen
Taalbinding Kardinaliteit Datatype
cs:status 1:1 cs:StatusType

3.2.16 EisStatusOnderbouwing

In deze kolom staat een toelichting op de status van de eis. Gebruikers willen de reden van vervallen toevoegen aan de eis, zodat de status onderbouwd is.

Taalbinding Kardinaliteit Datatype
cs:statusOnderbouwing 0:1 xsd:string
Noot

De "eigenaar" van een eis is vaak een interne rolhouder. In het contract gelden hiervoor de projectafspraken en kan de eigenaar vertegenwoordigd zijn door een andere rolhouder. Een eigenaar van een eis kan intern bijvoorbeeld de objectbeheerder zijn, maar in het contract is de technisch manager eerste aanspreekpunt voor de eis. Meestal wordt de eigenaar niet benoemd in de vraagspecificaties. Daarom is "eigenaarschap" niet opgenomen in de eisentabel.

4. Onderwerpen

De onderwerpentabel wordt gebruikt voor de onderwerpen van de eisen, bestaande uit de functies, objecttypen, werkzaamheden en informatieproducten. Op de eerste regel staan de kolomnamen. Op de tweede regel staat een korte toelichting; op de derde regel de vertaling / binding naar de NEN2660-2 en andere standaarden. Op de vierde regel staat aangegeven, hoeveel relaties er kunnen voorkomen in dit veld (multipliciteit). Als er meer dan één relatie voorkomt, komen er regels bij in de uitwisseling.

4.1 Onderwerpenformat

OnderwerpURI OnderwerpCode OnderwerpNaam OnderwerpType OnderwerpDefinitie OnderwerpheeftDeel
In deze kolom staat de unieke naam (URI) van het onderwerp. In deze kolom staat de code ofwel het nummer van het onderwerp. In deze kolom staat de naam van het onderwerp. In deze kolom staat het type van het onderwerp: Objecttype, Functie, Werkzaamheid of Informatieproduct. In deze kolom staat de definitie van het onderwerp. In deze kolom staat de URI van een onderliggend onderwerp.
https://www.example.org/id/Voorbeeld-Object1 OBJ-0109 Voorbeeld onderwerp InformationObject Onderwerp van een eis als voorbeeld in de documentatie https://www.example.org/id/Voorbeeld-Object2

4.2 Details onderwerpentabel

4.2.1 OnderwerpURI

De URI is de unieke identifier voor het onderwerp binnen het project ("Brug15"). Zie URI conform W3C.

Als de URI uit een ontologie ("Een brug") direct als onderwerp wordt gebruikt, suggereer je daarmee dat de projecteis altijd geldt voor dit onderwerp; dat hoeft echter niet zo te zijn. Vandaar dat hier altijd een project-URI wordt gebruikt; in een project stel je de projecteisen aan de instaties van het onderwerp waarvan het type gedefinieerd is in je ontologie ("objecttypenbibliotheek"). Gezien de eenvoud van dit uitwisselformaat, is geen verwijzing naar een ontologie opgenomen.

URI; Voor het opstellen van URI's heeft de NEN 2660-2 een URI-strategie die je moet volgen.

Taalbinding Kardinaliteit Datatype
n.v.t. 1:1 xsd:anyURI

Een URI maakt het meteen "linked data proof"

4.2.2 OnderwerpCode

De OnderwerpCode is een nummer van het onderwerp in spreektaal, vaak een voor mensen herkenbare code of projectnummer. Deze meestal eenvoudige en soms logisch genummerde Code maakt het mogelijk om in een gesprek naar het onderwerp te verwijzen, zonder de volledige URI te hoeven benoemen.

Taalbinding Kardinaliteit Datatype
skos:notation 1:1 xsd:string

4.2.3 OnderwerpNaam

De OnderwerpNaam is de voor mensen leesbare naam van het onderwerp. Deze naam hoeft niet uniek te zijn in het project, maar dat is natuurlijk wel handig.

Taalbinding Kardinaliteit Datatype
skos:prefLabel 1:1 xsd:string

4.2.4 OnderwerpType

Dit is een enumeratie. Het type van het onderwerp kan in het format uit een van deze vier concepten bestaan:

  1. FysiekObject
  2. Functie
  3. Werkzaamheid
  4. Informatieproduct
Taalbinding Kardinaliteit Datatype
rdfs:Class 1:1 xsd:anyURI
FysiekObject
De objecttypen en objecttypenboom ("decompositie") in het contract (Vraagspecificatie Eisendeel) zijn in NEN2660-2 een nen2660:PhysicalObject. Dit kan in de kolom Type worden ingevuld.
Functie
De functies in het contract (Vraagspecificatie Eisendeel) zijn ánders dan de werkzaamheden (Vraagspecificatie Procesdeel / ontwerp- en uitvoeringswerkzaamheden). De functies geven weer, welke diensten het "systeem" moet vervullen tijdens het gebruik; een voorbeeld is een weg, die als functie "het verkeer moet geleiden". De objecten in het contract zijn de functievervullers. De activiteiten zijn door mensen uit te voeren werkzaamheden tijdens het ontwerpen, bouwen, beheren en slopen van het object. In de NEN-2660 is een functie, bijvoorbeeld "Afwikkelen wegverkeer" ZOWEL een nen2660:Activity ALS een nen2660:FuntionalEntity.
Werkzaamheid
De werkzaamheden zijn door mensen uit te voeren activiteiten tijdens het ontwerpen, bouwen, beheren en slopen van het object. In de NEN2660 is een werkzaamheid, zoals "Opstellen Maandrapportage" een nen2660:Activity.
Informatieproduct
De informatieproducten in het contract staan vaak zowel in de Vraagspecificatie Procesdeel als in een separate Informatieleveringsspecificatie. Het betreft de gevraagde levering van 'documenten', dit kunnen alle bestandstypes zijn, ook datasets of geometrische bestanden. In de NEN2660 is een InformationObject onderscheiden. Binnen contractspecificaties wordt deze gespecialiseerd naar een cs:Document.Voorbeelden:
  • Informatieleveringsspecificatie:
    • Een rapport over het ontwerp van een weg
    • Een sterkteberekening van een kunstwerk
    • Een 3D model van een gebouw
    • Een linked dataset met attributen van een voetpad
  • Procesdeel:
    • Een V&G plan
    • Een voortgangsrapportage

4.2.5 OnderwerpDefinitie

De definitie van het onderwerp is een vrij tekstveld die het onderwerp definieert.

Taalbinding Kardinaliteit Datatype
skos:definition 0:1 xsd:string

4.2.6 OnderwerpheeftDeel

In deze kolom staat de URI van een onderliggend onderwerp. Hiermee kan een hiërarchie worden aangegeven zoals een objectenboom of functieboom zoals gebruikelijk in contracten. Een concept kan uit meerdere delen bestaan, er komen dan meerdere regels voor in de Onderwerpentabel.

Taalbinding Kardinaliteit Datatype
nen2660:hasPart 0:n xsd:anyURI
Noot

Net als bij de eisen, is de "eigenaar" van het onderwerp vaak een interne rolhouder. In het contract gelden hiervoor de projectafspraken en kan de eigenaar vertegenwoordigd zijn door een andere rolhouder. Een eigenaar kan intern bijvoorbeeld de objectbeheerder zijn, maar in het contract is de technisch manager eerste aanspreekpunt voor het object. Meestal wordt de eigenaar niet benoemd in de vraagspecificaties. Daarom is "eigenaarschap" niet opgenomen in de onderwerpentabel.

5. Documenten

Het documentenformat wordt gebruikt voor de definitie van de documenten. De volgende documenten worden opgenomen in de documententabel:

De vertaling / binding van documenten is naar cs:Document als specialisatie van nen2660:InformatieObject. Merk op: ook een eis wordt gezien als InformatieObject; maar deze wordt opgenomen in de Eisentabel. In de onderwerpentabel zijn te leveren documenten/datasets (informatieleveringen) óók InformatieObject. De informatieleveringen die gevráágd worden in het contract, staan niet in de Documententabel.

5.1 Documentenformat

Het format wordt in 2 delen getoond in verband met de leesbaarheid van dit document. De laatste rij bevat een voorbeeld uitwerking.

documentURI DocumentCode DocumentNaam DocumentVersie DocumentVersieDatum
In deze kolom staat de unieke naam (URI) van het document. In deze kolom staat de code ofwel het nummer van het document. In deze kolom staat de naam van het document. In deze kolom staat de versie van het document. In deze kolom staat de versiedatum van het document.
DocumentAuteur DocumentType DocumentSectie DocumentSectieNaam DocumentSectieTekst
In deze kolom staat de auteur van het document. In deze kolom staat het documenttype. In deze kolom staat de sectie URI In deze kolom staat de sectie naam. In deze kolom staat de sectie tekst.

5.2 Details documententabel

5.2.1 DocumentURI

De URI is de unieke identifier voor het document binnen het project.

URI; Voor het opstellen van URI's heeft de NEN 2660-2 een URI-strategie die je moet volgen.

Taalbinding Kardinaliteit Datatype
n.v.t. 1:1 xsd:anyURI

Een URI maakt het meteen "linked data proof"

5.2.2 DocumentCode

De DocumentCode is een nummer van het onderwerp in spreektaal, vaak een voor mensen herkenbare code of projectnummer. Deze meestal eenvoudige en soms logisch genummerde Code maakt het mogelijk om in een gesprek naar hetdocument te verwijzen, zonder de volledige URI te hoeven benoemen.

Taalbinding Kardinaliteit Datatype
skos:notation 1:1 xsd:string

5.2.3 DocumentNaam

De DocumentNaam is de voor mensen leesbare naam van het document. Deze naam hoeft niet uniek te zijn in het project, maar dat is natuurlijk wel handig.

Taalbinding Kardinaliteit Datatype
skos:prefLabel 1:1 xsd:string

5.2.4 DocumentVersie

In deze kolom staat de versie van het document.

Taalbinding Kardinaliteit Datatype
cs:versie 0:1 xsd:string

5.2.5 DocumentVersieDatum

In deze kolom staat de versiedatum van het document.

Taalbinding Kardinaliteit Datatype
cs:versieDatum 0:1 xsd:date

5.2.6 DocumentAuteur

In deze kolom staat de auteur van het document.

Taalbinding Kardinaliteit Datatype
dct:creator 0:n xsd:string

5.2.7 DocumentType

In deze kolom staat het documenttype. Voor documenttypen is nog geen nationale afspraak gemaakt.

Taalbinding Kardinaliteit Datatype
cs:documentType 0:1 xsd:string

5.2.8 DocumentSectie

In deze kolom staat de documentsectie. Deze kan gebruikt worden om een document verder op te delen. Middels de 'heeft deel' relatie kunnen net zoveel secties aan een document toegevoegd worden als er nodig zijn.

Taalbinding Kardinaliteit Datatype
nen2660:hasPart 0:n (t.o.v. Document) xsd:anyURI

5.2.9 DocumentSectieNaam

De DocumentSectieNaam is de voor mensen leesbare naam van het onderwerp. Deze naam hoeft niet uniek te zijn in het project, maar dat is natuurlijk wel handig.

Taalbinding Kardinaliteit Datatype
skos:prefLabel 1:1 (t.o.v. DocumentSectie) xsd:string

5.2.10 DocumentSectieTekst

In deze kolom staat de paragraaftekst.

Taalbinding Kardinaliteit Datatype
rdf:value 0:1 (t.o.v. DocumentSectie) xsd:string

6. Conformiteit

Naast onderdelen die als niet normatief gemarkeerd zijn, zijn ook alle diagrammen, voorbeelden, en noten in dit document niet normatief. Verder is alles in dit document normatief.

7. Lijst met figuren

A. Index

A.1 Termen gedefinieerd door deze specificatie

A.2 Termen gedefinieerd door referentie

B. Glossary

Dit onderdeel is niet normatief.

NEN-2660: Regels voor informatiemodellering van de gebouwde omgeving.

W3C: World Wide Web Consortium, internationale organisatie voor de standaardisatie van het het web.

OTL: Object Type Library (en) of Objecttypenbibliotheek (nl). Term die in de bouwsector gebruikt wordt en een specialisatie is van een Ontologie.

Unique Name Assumption (UNA): de aanname dat een ding maar één naam (id) heeft en dat verschillende namen dus verwijzen naar verschillende dingen in de werkelijkheid.

UML: Unified Modeling Language [uml]

RDF: Resource Description Framework. Zie [rdf11-primer].

RDFS: RDF Schema, taal waarin je een Linked Data ontologie kan uitdrukken [rdf-schema].

SKOS: Simple Knowledge Organization System. Zie [skos-primer]

OWL: Web Ontology Language [owl2-overview], bevat uitgebreidere mogelijkheden dan RDFS om een Linked Data ontologie uit te drukken.

SHACL: Shapes Constraints Language [shacl], een taal om RDF data te valideren tegen een set regels.

Ontologie: Een kennismodel van een specifiek kennisdomein in de werkelijkheid. Bevat een set regels, die gebruikt kunnen worden om extra kennis af te leiden uit gelinkte data. Met behulp van zo'n model kunnen computers begrijpen wat de data betekent en redeneren over data.

Contract: de uitvraag of overeenkomst waarmee een asset manager zijn ontwerp-, bouw- of onderhoudswerk overeenkomt met een marktpartij.

C. Referenties

C.1 Informatieve referenties

[owl2-overview]
OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/
[rdf-schema]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[rdf11-primer]
RDF 1.1 Primer. Guus Schreiber; Yves Raimond. W3C. 24 June 2014. W3C Working Group Note. URL: https://www.w3.org/TR/rdf11-primer/
[shacl]
Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/
[skos-primer]
SKOS Simple Knowledge Organization System Primer. Antoine Isaac; Ed Summers. W3C. 18 August 2009. W3C Working Group Note. URL: https://www.w3.org/TR/skos-primer/
[uml]
OMG Unified Modeling Language. Open Management Group. OMG. 1 March 2015. Normative. URL: http://www.omg.org/spec/UML/