Wiki source code of Requirements

Last modified by Linda van den Brink on 2014/09/18 10:17
Content · Comments (0) · Attachments (0) · History · Information
Hide line numbers
 1: {{toc start="1" depth="4" numbered="false" scope="page"/}}
 2: 
 3: == 3.1 Introduction ==
 4: 
 5: 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.
 6: 
 7: == 3.2 Supported use cases ==
 8: 
 9: CB-NL supports currently the following use cases:
10: 
11: 1. The use of CB-NL artefacts as a means for "transport" of information
12: 1. CB-NL is a source for computer aided object reference and description
13: 1. Other computer aided object reference sources can build upon the CB-NL  
14: 
15: == 3.3 CB-NL Functional Requirements ==
16: 
17: * CB-NL describes objects that are common in the Construction Sector
18: * 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’).
19: * 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.
20: * 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.
21: * 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.
22: * 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
23: * Each term has one unique ID, one semantic definition, one or more potentially multi-lingual labels and zero or more descriptions
24: * The list of discriminating relation properties is finite
25: * CB-NL contains rules that enforce consistency of the meaning of the content
26: * The CB-NL objects have a unique, persistent and meaningful ID (URI)
27: * All CB-NL objects can be instantiated
28: * 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
29: * The concepts in CB-NL are documented with metadata that describe things like the original source of the term, the version, status, rights holder ..
30: 
31: == 3.4 CB-NL Non-Functional Requirements ==
32: 
33: * 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.
34: * CB-NL itself is based on W3C standards that support distributed knowledge modelling
35: * 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
36: * 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.
37: * The use of CB-NL should not in any way limit flexibility
38: * 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.
39: * CB-NL will be developed step-wise where partial results can be utilized and in each step a cost-benefit analysis will be performed.
40: * Only the maintainer of CB-NL has authority to change CB-NL content. This maintainer will be appointed by the Bouw Informatieraad.
41: * CB-NL will be developed in such way that maintenance costs are minimal
42: 
43: == 3.5 CB-NL technical capabilities ==
44: 
45: In order to facilitate the use cases the CB-NL has the following high level technical capabilities:
46: 
47: 1. CB-NL entities have unique HTTP identifiers for reference (they have a unique URL)
48: 1. 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
49: 1. CB-NL supports multiple inheritance, i.e. objects inherit properties and their values from every parent above.
50: 1. 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