Requirements

• • 3.1 Introduction
  • 3.2 Supported use cases
  • 3.3 CB-NL Functional Requirements
  • 3.4 CB-NL Non-Functional Requirements
  • 3.5 CB-NL technical capabilities

3.1 Introduction

The requirements are split in two categories: functional requirements and non-functional requirements. Functional requirements describe how the CB-NL should behave. They are based on use cases. Non-functional requirements determine how the CB-NL should qualitatively operate.

3.2 Supported use cases

CB-NL supports currently the following use cases:

1. The use of CB-NL artefacts as a means for "transport" of information
2. CB-NL is a source for computer aided object reference and description
3. Other computer aided object reference sources can build upon the CB-NL  

3.3 CB-NL Functional Requirements

• CB-NL describes objects that are common in the Construction Sector
• The scope of the objects in CB-NL covers the whole life span and supply-chain ‘matrix’ and involved ‘ disciplines’ of a construction artifact or “ structure”, from the programming phase (dealing with requirements), via the design and construction phase to the actual operational and maintenance phase. In other words: the total Asset Management and Asset Usage management (like ‘ traffic management’).
• The context of the objects in CB-NL covers all construction-related domains: Buildings (residential, utilities), civil infrastructures, including installation plants and environmental (in the interpretation of the ‘surroundings’) objects.
• CB-NL will only cover information structures as determined by laws and regulations or that are common and relevant for multiple organizations in the construction sector as a whole. Sub-domains (like UNETO-VNI/2BA for installations, RIONED for sewerage, or BouwConnect for supplied products) can have their own extensions. That is, these sub-domains can be mapped to CB-NL, but are not part of CB-NL.
• The level of detail of CB-NL is such that only single objects are listed in CB-NL, not composite terms. Example: Term = “Beam” will be stored in CB-NL. “Concrete Beam” will not be part of CB-NL although both "Concrete" and "Beam" can be.
• CB-NL is a taxonomy (class-subclass tree) of objects that are discriminated from each other by one or more mandatory relation properties with their values. These properties and their values are inherited from the super- to the sub class
• Each term has one unique ID, one semantic definition, one or more potentially multi-lingual labels and zero or more descriptions
• The list of discriminating relation properties is finite
• CB-NL contains rules that enforce consistency of the meaning of the content
• The CB-NL objects have a unique, persistent and meaningful ID (URI)
• All CB-NL objects can be instantiated
• The URI of a concept in CB-NL is the single point of reference for external sources when a reference to a term must be made
• The concepts in CB-NL are documented with metadata that describe things like the original source of the term, the version, status, rights holder ..

3.4 CB-NL Non-Functional Requirements

• CB-NL will be, just like this guide, a fully open standard that can be accessed and used by anybody free of charge. Development and maintenance cost will not be covered by having people to pay for the usage taking away any obstacle for acceptance and usage and thereby maximize the critical mass.
• CB-NL itself is based on W3C standards that support distributed knowledge modelling
• The CB-NL will as much as possible (re)use terms used in existing national and international information standards (like information modeling languages, access mechanisms but also guidelines or even information structures. Example: INSPIRE, QUDT
• Existing information structures like ontologies, dictionaries, libraries, classifications etc. are taken as starting point for the list of terms used in the CB-NL taxonomy.
• The use of CB-NL should not in any way limit flexibility
• CB-NL will not be a static information structure. It will be a ‘living’ thing where classes, properties etc. are changed and created all the time. Different versions of CB-NL will be published as releases. Older releases will remain available for use.
• CB-NL will be developed step-wise where partial results can be utilized and in each step a cost-benefit analysis will be performed.
• Only the maintainer of CB-NL has authority to change CB-NL content. This maintainer will be appointed by the Bouw Informatieraad.
• CB-NL will be developed in such way that maintenance costs are minimal

3.5 CB-NL technical capabilities

In order to facilitate the use cases the CB-NL has the following high level technical capabilities:

1. CB-NL entities have unique HTTP identifiers for reference (they have a unique URL)
2. CB-NL objects are described with necessary conditions, i.e. if an instance is a member of this class, then it has the conditions (property restrictions) described in that class
3. CB-NL supports multiple inheritance, i.e. objects inherit properties and their values from every parent above.
4. CB-NL supports instantiation: when an instance of an object is created it is known to which class it belongs. As a consequence of rule 3 the instance has the necessary condition of the class it has been created with and the properties with their values of all of its superclasses