Gellish Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Requirements Modeling ======
====== 1. Requirements for kinds of things ======

This section deals with the expression of requirements that are applicable for kinds of things.
The specification of requirements about individual things are discussed in the section about [[product_modeling|product modeling]] and [[modeling_of_activities_and_processes|process modeling]]. The specification of such requirements for individual things include designs of particular individual objects. For example, requirements for a new facility or for a typical individual object, from which multiple materialized exemplars can be derived. Such designs are treated in Gellish as imaginary individual objects that are specified in the same way as materialized real world individual objects, although they have deemed characteristics as opposed to observed and measured characteristics.

**Requirements for kinds of things** are requirements that are applicable for any individual thing that is of that kind within a particular validity context. Requirements for kinds of things are typically defined in standards and in best practice guides. Designs for individual things often include components that are specified by references to standardized requirements for kinds of things and to general requirements in national and international standards or in company specific standards. The modeling of this kinds of requirements is described in this section.

Examples of requirements that are covered by this section are:
  * Requirements that are expressed by a company that particular kinds of information (data and documents) is required when certain kinds of components are delivered to that company.
  * Requirements that are expressed in international standards that particular kinds of objects shall be compliant with certain requirements when the standard is adopted by a company.
  * Requirements that specify which information shall be provided when companies offer or deliver the components of particular kinds as mentioned in their product catalogs.

Requirements about kinds of things are expressions of what shall be the case for things of a specified kind according to a particular party or (adopted) standard. Such a party or standard is called the 'validity context' for the requirement. The validity context is expressed in a separate column of the Gellish expression format table. \\

Requirements about a kind of thing are indirectly applicable for all individual things that are classified by that kind of thing. Therefore the requirements are suitable for use in computer-aided design of individual things and the requirements are also suitable for use in computer-aided verification of designs. For example, requirements for centrifugal compressors expresses requirements that any centrifugal compressor shall satisfy in the validity context where the requirements are (contractually) applicable.

Requirements may also express the kinds of information that shall be delivered as a description of a delivered product and its operation and maintenance.

Extensive guidance on the expression of requirements is provided in the book Semantic Information Modeling Methodology. That book also includes guidance on how requirements can be used for supporting the creation of designs of individual objects and how those requirements can be used for verifying delivered designs of individual objects or of delivered information about real fabricated and installed objects. The latter implies that requirements can be used for verification of the completeness and quality of Integrated Information Models.

====== 2. What is a Requirements Model? ======
A collection of expressions that express requirements for things of a particular kind is called a Requirements Model. In other words, the requirements in a Requirements Model are applicable for each individual thing that is classified by the kind of thing for which the model is made. Requirements Models can be about large or small assemblies or for components. For example, a requirements model can include requirements for a complete kind of process plant, a kind of building, a kind of road, a kind of ship or a kind of airplane, and they can be requirements for a kind of system, a kind of compressor, or for a kind of heat exchanger, or even for a kind of bearing, a kind of impeller, nut or bolt or any other kind of component. The requirements may also be about kinds of processes or kinds of activities in which the kinds of objects are involved. For example, it may include requirements about the operation or maintenance of things of the specified kind and it may include how a particular type of test should be performed or how commissioning or start-up procedures should be executed. \\

Traditionally requirements about a kind of object are recorded in documents, first in paper documents, later in electronic documents.
Requirements can nowadays be expressed in the form of computer interpretable expressions. Usually requirements for complex assemblies are typically hybrid in the sense that the computer interpretable expressions include also relations with documents and (multi-media) files in various textual or graphical formats. Thus requirements may consist of a data part and a documents part. The data part consists of requirements that are expressed as relations between kinds of things, including kinds of components and kinds of aspects. Each requirement may be specified to be applicable only in a particular context. All kinds that are used in expressions of requirements shall have a definition in the Gellish Dictionary or shall be added to it as part of the specification. The documents part of the model consists of requirements that are contained in files, typically in textual of graphical form, whereas references to those files shall be expressed as relations between a kind of thing and documents that express the requirements. \\
Expressions of requirements are very similar to expressions of possibilities (knowledge), whereas requirements use relations that are denoted by phrases that strat with <shall have…> or <shall be…>, whereas possibilities are denoted by phrases that start with <can have...> or <can be...>. For example, requirements about a compressor can be expressed as follows: \\
^Name of left hand object^Name of kind of relation^Name of right hand object^applicability context^
| vessel | shall have as aspect a | length between tangent lines|Company A|
| compressor | shall be compliant with | API 617 standard|Company A|

Each requirement is expressed as a relation between concepts, whereas those concepts (kinds of things) shall be defined in and shall be selected from the dictionary. \\

Requirements can be used on their own or in combination with knowledge models about possibilities either as a guide for designing components according to the knowledge and the requirements or as for guiding (partly automated) verification of the completeness and quality of designs or of information about delivered products.

====== 3. Computer Augmented Design and Automated verification ======

There is a strong benefit when requirements as well as designs are delivered as expressions in Gellish, because then it becomes possible to use computer aided support in verifying whether the designs are compliant with the requirements. When also the information about delivered products is expressed in Gellish the benefits become ever stronger, because then the information about the delivered products can be automatically verified against the design of the individual as well as against the requirements for the kinds. 

This is enabled by the fact that the Gellish language contains realization relations that specify which relation kinds of facts shall be present to satisfy an expression of a requirement. For example, a relation of the type <shall have as aspect a> is an expression of a requirement that can be satisfied by a relation of the type <has as aspect>. Such realization relations are expressed as relations between kinds of relations. For example, the requirement that a 'vessel <have as aspect a> length between tangent lines' is an expression that <can be fulfilled by a> assertion that is expressed as 'V-1205 <has as aspect> L1', whereas L1 is a particular length between the tangent lines of V-1205. This example illustrates that in general a <shall have as aspect a> relation <can be fulfilled by a> <has as aspect> relation.

This knowledge is expressed in Gellish as follows: \\
^UID of left hand object^Name of left hand object^UID of idea^UID of kind of relation^Name of kind of relation^UID of right hand object^Name of right hand object^
| 4956 | shall have as aspect a | 1554139 | 5165 | can be fulfilled by a | 1727 | has as aspect|

With such knowledge it is possible that knowledge-aided design software assists in the design process or during a verification process as follows: \\
Assume that a vessel is designed, called V-1205, then from the above specification of a requirement for a vessel it becomes possible that computer software can conclude that V-1205 shall have a length between tangent lines, expressed in millimeters. So the software can verify the existence of such a value and if not, it can ask for that value. This means that the above requirement can be fulfilled for example by the following specification: \\
^Name of left hand object^Name of kind of relation^Name of right hand object^UoM^
| V-1205 | has as aspect | L1 |
| L1 | is classified as a | length between tangent lines |
| L1 | has on scale a value equal to | 3100 | mm|

The Gellish specification of individual objects can thus be verified by computer software against the Gellish expression of the requirements.

**//Continue with//** [[:Standard Specification Models|Modeling of product types]]
Gellish Wiki

User Tools

Site Tools

Page Tools
