Modeling of Functions and Activities/Processes

Various design methods advocate to specify requirements in terms of functions, without immediately specifying technical solutions. This is also the approach of Systems Engineering (ISO 15288). However, there is often unclarity about what a ‘function’ is. It appears that there are at least two definitions of function.

Two definitions of function

A study about functions (see: A Taxonomy of Functions in Gellish English, by dr. ir. Andries van Renssen et al, International Conference on Engineering Design, Paris 2007) showed that the term function has more than one meaning. This is illustrated by Figure 1 which shows a relation between an occurrence (a process or activity) and a physical object that is involved as its performer or as its enabler. 

 Figure 1, A physical object as performer or enabler of an occurrence (activity or process).

The physical object in Figure 1 has a role in the <is performer of> relation as a ‘performer’, whereas the occurrence has a role as ‘being performed’. These two roles are both denoted as ‘function’ in actual discussions as follows:

  1. When we talk about the function of the physical object, then we mean its performer role (or its enabler role) in this relation. Its function is: being performer (or enabler) of the occurrence. The supertype of performer and enabler role is usually called ‘mechanism’ role (IDEF0).
  2. When we talk about the function that is performed, then we talk about the ‘being performed’ role of the occurrence. Its function is: being performed by the physical object.

The confusion is often increased, because we usually mean a role player when we refer to a role in a relation. For example, if we talk about a chairman (a role), then we mean a person that has a role as chairman in a relation to an organisation or meeting.In Gellish all these concepts are clearly distinguished and have different identifiers.
We will use the term function primarily as in Systems Engineering, where it is normally used to refer to an occurrence that is intended to be performed (although the ISO 15288 standard on Systems Engineering does not contain a definition of function).

Activity decomposition

Functional modeling is basically modeling of processes and activities. However we should keep in mind that an occurrence (process or activity) is by definition an interaction between physical objects. So, we know on beforehand that there are always physical objects involved, although we might not specify what kind of physical objects they are. For example, there is at least one physical object that has a role as being subject to the process or activity. The kind of physical object that has a role as subject is typically explicitly specified. Functional modeling is therefore the principle that activities or processes are specified and decomposed and that the physical object that has a role as subject is classified and that its properties are specified in detail. Those properties form the boundary conditions of the process that is required.

Furthermore, by definition there is always a physical object that has a role as mechanism (enabler or performer). However, the kind of physical object that has a role as performer or enabler is only classified at a generic level and not yet at a specific level. Such a classification of performers at a high level, should not limit the choice of a technical solution. For example, a performer might get a UID already and might be classified initially as a solid item or as a system. Then it is possible to link additional requirements to that performer, without saying what detailed kind of thing it is.

Example 1:

It may be specified that the function (process) ‘transport of people’ shall be performed. So, the requirement implies that there shall be an individual process T1 that is classified as transport of people. This is specified as follows:

TP1            is classified as a             transport of people

 It should be note that there is a physical object that is subject in this process: the group of people that should be transported:

TP1           has as subject                 GP1
GP1           is classified as a              collection of people

Functional specification requires that the subject physical object is specified in detail, because it forms the boundary conditions for the requirement. It also requires that the activity or process is decomposed as is illustrated in the next example.

Example 2:

Similar to the first example, it may be specified that the function (process) ‘fire fighting’ shall be performed.             

FF1            is classified as a             fire fighting

The subject of that occurrence is a fire. The identification of one or more cases of fire is important, because we have to specify the materials that are expected to burn and what the sizes of the potential fires are.             

FF1            has as subject                Fire-A

As long as the fire fighting medium is not chosen we know little about the kind of performer. In a pure functional specification this might remain implicit. However, in this kind of cases it is allowed to classify the performer as a ‘fire fighting system’, without reducing the possible technical solutions. This is done as follows:             

FF1            is performed by              S1
S1             is classified as a             fire fighting system

The fire fighting process can be decomposed into component processes. For example, one o the component processes is ‘supply of fire fighting medium’. This is specified as follows:            

SM1          is a part of                     FF1
SM1          is classified as                supply of fire fighting medium

During further design the medium will be chosen. Assume that water is chosen as the medium. Then we can specify:

SM1          has as subject                W1
W1            is classified as               water

This can be followed by a specification of the flow rate of the water:            

W1            has as aspect                              FR1
FR1           is classified as a                          volume flow rate
FR1           has on scale a value equal to        10                     dm3/s

It is still not specified what the nature is of the performer of the water supply. A functional specification will leave that open.