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

3.  classes of requirement may be defined. Some product requirement classes may be:

·  constraint definitions (e.g. budget constrains, human limitations);

·  functional requirements ( e.g. to provide an output voltage of 24 Volts plus-minus 0.5V);

·  operation requirements (to work ceaselessly for 2500 hours in usage_scenario n.2). Includes also mobility, mission frequency and duration;

·  support requirements[13] (to be repaired on site within 48 hours );

·  physical requirements (not more than 5 Kilos);

4.  change of a product_requirement should be addressed by configuration change control entities such as change request, implementation directive and applied solution ( see paragraph 6.7.1.1 );

5.  associations between a predecessor product_requirement and a successor product_requirement should be maintained. This association states that the successor requirement is created by modifying the predecessor requirement;

6.  product_requirement(s) may be described by using STEP IRs constructs such as property definition, property representation  and measure schema;

5.5  Product Design

The product_design  object has a number of relationships with the other views of the ‘product’ (see para. 6.1 and figure 5).

Figure 5 – product_design relationships

The product_design may consist of functional design, physical design and support design. These three components are related each other, making it possible, for example, to derive the product_physical_design instances that are involved in a function or the product_support_design instances applicable for a particular physical design.

5.5.1  Product Functional Design

The product functional domain describes what activities are performed, within a system, in one or more usage scenario, to fulfill a requirement.

The diagram in figure 6 describes the basic relationships:

Figure 6 – product_functional_design basic relationships

A function could provide a service, process materials or change the state of the system environment. Functions form a hierarchy, with the top level being the function of the product_concept itself and the bottom level being individual actions.

For example if ‘Electric Generator’ is the product_concept, the functional hierarchy top level would be ‘Produce Electric Power’ with such sub-functions like ‘Provide Fuel to the Combustion Chamber’ which in turn could be decomposed into ‘Store Fuel’, ‘Supply Fuel’ and ‘Inject Fuel’. The functional analysis is useful to identify the physical products that need to be designed to perform the activities (e.g. in our case: the fuel tank, the fuel ducts and the injectors.)

In the above example only mechanical functions are involved. In other cases we may have functional hierarchies that include a set of interacting sub-functions some of which could be mechanical, some information processing and some hybrid (both). The function ‘Track Target’, for example, may be an abstraction of the functions ‘Identify Target’, ‘Obtain Current Position’ and ‘Maintain Course’. The realization of these functions may involve diverse technologies such as radio communications, radar tracking, interaction with a GPS satellite and computing equipment to calculate a course.

Functional design is not achieved solely by hierarchical decomposition of top-level function. In addition to hierarchical relationship functions may interact in many other ways. For instance, a function could be activated based on the result of a previous function. In this case a chain of functions is defined. In the above example the function ‘Obtain Current Position’ cannot be activated until the function ‘Identify Target’ has been completed.