This part deals with the specification of standard requirements that are generally applicable for kinds of things.

The specification of requirements about individual things are given in the Gellish Modeling Method, part 4 – Creation of Facility Information Models. 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 copies 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.

Requirements for kinds of things are requirements that are generally applicable for any individual thing that is of that kind. Requirements for kinds of things are typically defined in standards and in best practice guides. Usually a design for an individual thing includes 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 Requirements Modeling part of the Gellish Modeling Method (part 3).

Examples of requirements that are covered by this part 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 types of components in their product catalogs.

In the Gellish Modeling Method, requirements are arranged in Requirements Models. Requirements Models can be applicable for large or small assemblies or for components. For example, they 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, they might specify how a particular type of test should be performed or how a commissioning or start-up procedure should be executed.
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, a Requirements Model for centrifugal compressors expresses requirements that any centrifugal compressor shall satisfy when the Requirements Model is (contractually) applicable.

Requirements Models may also include a specification of the kind of information that shall be delivered as a description of a delivered product and its operation and maintenance.

Extensive guidance on the creation of Requirements Models is provided in the document Gellish Modeling Methodology, Part 3B - Specification of Requirements and Verification of Deliverables. That document also includes guidance on how those requirements models can be used to support the creation of designs of individual objects and how those requirements models can be used to verify delivered designs of individual objects. The latter implies that requirements models can be used to verify the completeness and quality of a Facility Information Model or Building Information Model (BIM).

Traditionally requirements about a kind of object are recorded in documents, first in paper documents, later in electronic documents.

The Gellish Modeling Method describes how requirements can be expressed in the form of a computer interpretable model. Typically there are a number of requirements applicable for a particular kind of object. Such collections of requirements are integrated in Requirements Models for those kinds of objects. This means that a Requirements Model is a model of a collection of facts about a kind of thing for which such facts are required to be the case. 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.

A Requirements Model may consist of a data part and a documents part. The data part consists of requirements that are expressed as relations between a kind of thing and the kinds of components and kinds of aspects that it (and its components) shall have. Those requirements may be specified to be applicable only in a context. The kinds of things in the model shall exist and shall have a definition in the used (Gellish) Dictionary. The documents part of the model consists of requirements that are expressed as relations between a kind of thing and documents that express requirements in textual form.
Expressions of requirements use relations of the form of <shall have…> or <shall be…> relations. For example, a requirements model about a compressor consists of a number of requirements. For example:

The example shows that each requirement is expressed as a relation between concepts in the dictionary or in the document repository. The requirements are thus expressed as relations between kinds of things, whereas those kinds of things are selected from the defined concepts in a Gellish Dictionary. Therefore, a dictionary is an integral part of a collection of requirements models.
So, a Requirements Model is the integration of a set of data and documents that model and describes the requirements about an object and/or operation or maintenance, whereas each requirement is expressed as a <shall have…> or <shall be…> relation between kinds of things concept (a class) that is defined in the Gellish English Dictionary or as a <shall be…> relation between a kind of thing and a document in a document repository.

A requirements model can be implemented in various ways. The essence is that the model can be used either as a guide to design a component according to the requirements or as a guide for (partly automated) verification of the completeness and quality of a design.

Especially when the design of individual objects is also specified in Gellish product models. Furthermore, there is a strong advantage to specify that designs shall be delivered as a Gellish product models, because then it becomes possible to use computer aided support to verify whether the design is compliant with the requirements.

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 a fact that expresses 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 relation types. For example, the requirement that a vessel<shall have as aspect a> length between tangent lines is a fact (expressed as a relation) that <can be fulfilled by a> fact that is expressed by the relation 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.

In the Gellish Database table of the Gellish English Dictionary this knowledge is expressed as follows:

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:

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