Systems Engineering

Systems Engineering is an important guiding modelling principle underlying the COINS Systematics core schema. This influence is expressed in various ways and will be discussed in the following sections.

Inhoud

Layering

Layering is an organizing principle to collect information objects with their related neighboring pieces of information and on a corresponding level of detail. Point of departure is always a function fulfiller. The top node of a decomposition tree of function fulfillers resides normally in the first layer: layer 0. The child function function fulfillers are located in the following layer, i.e. the number of parent function fulfiller plus one, etc.
Neighboring objects of a function fulfiller are for example the function(s) that must be fulfilled. Those function(s) should lie in the same layer. Similarly, a requirement (partly) describing a function lies in the same layer or the performance (partly) describing a function fulfiller.
Not all object classes follow this principle, for example a document may be referred to by objects in different layers. The Document class is therefore layer independent. As a result layering is only meaningful for classes that are closely related to systems engineer: Connection, Function, FunctionFulfiller, Performance, Requirement, Terminal and Verification.

As a rule all objects in the same layer represent the total building at a specific level of detail. For this reason all layers should always be specified completely even if certain branches typically need more decomposition layers then others. In that case the shorter branches must be extended until the occupied layer with the highest number. For the same reason a branch can never skip a layer.

To assign an information object to a certain layer its layerIndex attribute should be specified. Since this property has CbimObject as its domain type virtually all COINS classes may specify a layer index. As observed above only systems engineering classes may use this attribute value meaningfully. This leads to the following rules:

Above rules force the information objects in this instance diagram to specify the same layer index value.
Above rules force the information objects in this instance diagram to specify the same layer index value.
  • the parent or child object properties only allow domain and range objects that have adjacent layerIndex values.
The last rule forces the information objects in this instance diagram to specify adjacent layer index values.
The last rule forces the information objects in this instance diagram to specify adjacent layer index values.

Baselines

Baselines form another organizing principle, which often (but not necessarily) coincides with one or more layers. Where layers are not information objects themselves (only an integer attribute value) a baseline is a class with explicit links to the participating information objects of that particular baseline.
An information object can only form part of one baseline.

A baseline has a baselineStatus property of type boolean, which determines the status open ( = true) or closed ( = false).
An open baseline is open for changes (addition, deletion, updating), while a closed baseline is not. COINS compatible software should protect information objects in a closed baseline from unintentional changes. Only users of a recognized authorization level should be allowed to unlock the baseline (temporarily) and make the necessary modifications.

Warning message of the COINS Navigator.
Warning message of the COINS Navigator.

Requirements and Performances

Functional Requirements specify the function that contains them, i.e. a functional requirement belongs to exactly one function. Performances characterize the function fulfiller that contains them, i.e. a performance belongs to exactly one function fulfiller. The COINS systematics only supports a textual (human interpretable) specification of requirements and performances. As a result it is not possible to verify automatically requirements with the corresponding performances. The reference framework "Functional Specification" extends the Requirement and Performance classes with associated PropertyTypes and quantitative PropertyValue restrictions and actual values. These extensions support in principle the automatic checking of requirements and performances.

A function is characterized by a set of (functional) requirements, while a function fulfiller is characterized by a set of performances.
A function is characterized by a set of (functional) requirements, while a function fulfiller is characterized by a set of performances.

Verifications

A verification asserts explicitly the conformance of a function fulfiller to a specific requirement. This assertion is the outcome of formal test procedure performed by a designated person at a certain date.
A verification will generally be associated to a certain baseline, which offers the opportunity to specify several verifications at various stages during the life cycle.

Verifications panel in the COINS Navigator.
Verifications panel in the COINS Navigator.
Afkomstig van CoinsWiki NL, de Vrije Encyclopedie. "http://www.coinsweb.nl/wiki/index.php/Systems_Engineering"
Personal tools