User Tools

Site Tools


requirements_models

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
requirements_models [2017/11/15 11:15]
127.0.0.1 external edit
requirements_models [2018/11/03 00:01] (current)
andries [3. Computer Augmented Design and Automated verification]
Line 1: Line 1:
-====== Requirements ​Models ​====== +====== Requirements ​Modeling ​====== 
-====== 1. Requirements ​about kinds of things ======+====== 1. Requirements ​for kinds of things ======
  
-This part deals with the specification ​of standard ​requirements that are generally ​applicable 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.
  
-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 objectsFor 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 applicable ​for any individual ​thing that is of that kind within a particular ​validity contextRequirements ​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.
  
-**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 section ​are:
- +
-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 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 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.+  * Requirements that specify which information shall be provided when companies offer or deliver the components ​of particular kinds as mentioned ​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, ​kind of compressor, ​or for 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 particular type of test should be performed or how a commissioning or start-up procedure should be executed. \\ +Requirements ​about kinds of things are expressions ​of what shall be the case for things of specified ​kind according to particular party or (adopted) standard. Such 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, 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 ​specification of the kind of information ​that shall be delivered as a description ​of a delivered product ​and its operation and maintenance.+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.
  
-Extensive guidance on the creation ​of Requirements Models ​is provided in the document Gellish ​Modeling Methodology, [[http://​shop.gellish.net/​shop.html?​page=shop.browse&​category_id=2|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).+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? ====== ====== 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. 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|
  
-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. +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. \\
- +
-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: \\ +
-^Name of left hand object^Name of relation type^Name of right hand object^ +
-| vessel | shall have as aspect a | length between tangent lines| +
-| compressor | shall be compliant with | API 617 standard| +
- +
-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.+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. How to satisfy requirements ​======+====== 3. Computer Augmented Design and Automated verification ​======
  
-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 Gellish ​product models, because then it becomes possible to use computer aided support ​to verify ​whether the design is compliant with the requirements.+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 ​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.+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.
  
-In the Gellish Database table of the Gellish English Dictionary this knowledge is expressed as follows: \\ +This knowledge is expressed ​in Gellish ​as follows: \\ 
-^UID of left hand object^Name of left hand object^UID of fact^UID of relation ​type^Name of relation ​type^UID of right hand object^Name of right hand object^+^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| | 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: \\ 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:​ \\ 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 relation ​type^Name of right hand object^UoM^+^Name of left hand object^Name ​of kind of relation^Name of right hand object^UoM^
 | V-1205 | has as aspect | L1 | | V-1205 | has as aspect | L1 |
 | L1 | is classified as a | length between tangent lines | | L1 | is classified as a | length between tangent lines |
Line 56: Line 53:
 The Gellish specification of individual objects can thus be verified by computer software against the Gellish expression of the requirements. 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]]+**//​Continue with//** [[:Standard Specification Models|Modeling of product types]]
requirements_models.1510740946.txt.gz · Last modified: 2017/11/15 11:15 by 127.0.0.1