This document contains the archived versions of the technical documentation of COINS, earlier found on COINSWeb and COINSwiki
Baseline: Documentation/description of a product in a defined phase of development. A baseline can be frozen and serve as a stable basis for next development phases.
Building Information Modeling (BIM): Is the process of generating and managing building data during its life cycle. The process produces the Building Information Model (also abbreviated BIM), which encompasses functional and physical characteristics, building geometry, spatial relationships, geographic information, and quantities and properties of building parts. The Building Information Model forms the basis for specification, verification, construction, procurement, logistics, implementation, quality assurance, etc.
Building Part: A physical part of a building. A building part can be a assembly of other building parts. A building part is also referred to as an object.
CBIM: COINS Building Information Model (CBIM) is a building information model that complies with the COINS-standard.
CBIM schema: The schema that specifies the structure of a CBIM.
CBIS: COINS-compatible Building Information System.
CEM: COINS Engineering Method (CEM) is a collection of agreements with respect to the handling of building information. CEM is a part of the COINS-standard.
COINS-standard: A collection of agreements with respect to the structure of building information and the handling of building information which serves as a backbone for integration of the building process.
COINS-Reference framework: An add-on to the COINS-standard on the purpose of serving a certain application domain. A framework may have significance in national, organizational or project level.
COINS-implementation guideline: Guidelines which are additionally to the COINS-standard and are prepared to serve IT-implementation and to support interoperability between IT-systems.
Requirement: Description of a desired property of a function, product or service.
Function: A task, action, or activity that must be performed to achieve a desired outcome.
Function fulfiller: A building part or space that fulfills one of more functions.
Functional analysis: The purpose of this system engineering process activity is to transform the functional, performance, interface and other requirements that were identified through requirements analysis into a coherent description of system functions that can be used to guide the Design Synthesis activity that follows.
Functional requirement.: The necessary task, action, or activity that must be accomplished.
Status: A building information model is populated by many information objects. Through the established status, the meaning is determined of a given information object for the establishment of a building. The status is determined by three characteristics that occur each information item, namely: Release Status, Baseline Status and Validity Status.
Systems Engineering: A collection of related methods for a controlled inter-disciplinary approach to the development of systems and products using a life cycle approach which is focused to a reach a solution that meets the customer requirements.
Stage: A building part goes through a product life cycle, from design to demolition. Where a building component is in the life-cycle is determined by the Stage (is also called life-cycle stage).
Validation: The effort during which the technical data product is tested for technical adequacy, accuracy, and compliance with the provisions of the specifications and other contractual requirements. Validation is accomplished by comparing the data product with the actual systems or equipment for which the data product was prepared.
Verification: Demonstrate through research and provision of objective evidence that specified requirements have been met. [EN-ISO 9000:2005].
Verification Method: A method to verify or demonstrate that a design or realized building part meets each of the the requirement that are established and recorded during requirements analysis and functional allocation activities. (If it cannot be verified, it cannot be a legitimate requirement.)
Verification Matrix: A matrix in which the link is established between the requirements, the function full-filler and verification method.
Verification Note: The verification note is an overview of verifications, tests and inspections throughout the project. Where appropriate selections can be made by a building part or stage.
Verification Plan: A plan setting out how and when the verification of a part should be executed. The core of the plan concerns the verification method.
Verification Report: The registration of a separate verifications. If necessary reference is made to a supporting document.
Version: A given information object can appear more than once in a building information system. The various instances are distinguished by a version number.
Virtual Building: COINS-compatible Building Information System.
Request Specification: The agreement as such identified in the contract document, which is prepared by or on behalf of the client, under which the contractor has prepared and submitted his offer. [UAVGC 2005].
Request Specification Part I: Contract Document in which the requirements to the (partial) product are expressed (the WHAT-requirements). Request Specification Part II. Contract Document in which the demands on the work to be performed (= Statement of Work) are expressed (the HOW-requirements).
Window of Authorization: Authorization specification that is linked with a specific transaction request to enable model change management.