PLCS Statement of Technical Requirements. Technical Requirements Product Life Cycle Support. Configuration Management, страница 17

Figure 2 – product_instance relationship

In figure 2, each diagram in the stack is a coherent network of information. For each physical instance of the engine (e.g. Engine with S.N. 003), it is possible to navigate through the relationships to identify requirements, design information and logistic information that are applicable for the specific engine.

This is true for all the specific engines that have been manufactured. In fact, there is a specific and unique set of data and relationships for each product_instance.

In this way, the effectivity of configuration, technical data and logistic tasks to product_instance is explicitly defined through relationships.

5.3  Product Concept

A product_concept is the idea of a product as conceived by the user. It will often correspond to the items supplied to the user (e.g. an item in the catalog of a supplier). The definition of  product_concept(s) is driven by user’s needs and by user defined usage scenario. It represents the idea of a product based on user viewpoint and NOT as it might be designed or manufactured.

The basic relationships of product_concept are described in figure 3.

Figure 3 – product_concept basic relationships

Some detailed information requirements are the followings:

1.  a product_concept is defined by a name, an identifier and a textual description;

2.  the product_concept identifier is the combination the user organization identifier and a unique identifier assigned by that organization. It is assumed that the user organization issues unique identifier within its domain;

3.  product_concept(s) may be classified, decomposed and aggregated. Class of product_concept should be defined[10];

4.  product_concept(s) may be versioned and may be subject to Configuration Change Control (configuration item);

5.  a product_concept may be related to different contexts or usage scenarios[11]. This relationship is a many-to-many since the same product_concept may have many usage scenarios and a usage scenario may apply to many different product_concept(s);

6.  a usage_scenario may be described by:

·  environment conditions (e.g. temperature, pressure, wind velocity);

·  user conditions (e.g. human capability and limitations, national laws and regulations);

·  support conditions (e.g. support resources, pipeline times);

·  mission phase (e.g. landing )

7.  simple conditions may be combined with AND, OR and XOR operators to define complex usage_scenario(s);

8.   usage_scenario(s) may be organized in classes. Most probable scenario and worst case scenario in peace-time and wartime employment are examples of usage_scenario classes.

5.4  Product Requirement

A product_concept in a specific usage_scenario may be characterized by a set of required or expected product features, performance or behaviors identified by the user or derived by the user’s needs.

Figure 4 – product_requirement basic relationships

A product_requirement relates to one or more product_concept_usage_scenario association  and to zero, one or more product_design. This implies that a product_requirement instance may exist without a product_design but it could not exist without a product_concept and the associated usage_scenario[12].

Product requirements have a number of associations with organizations. A typical association is the one used to identify the organization defining the requirements.

Some specific data requirements could be the following:

1.  product_requirement(s) may be classified, decomposed and aggregated;

2.  a complex combination of product_requirement(s) with conditions may be specified by composing one or more product_requirement(s) that are related by conditions;