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.
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:
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).
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.
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.
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.