Functional architecture, or equivalently functional analysis, intends to precisely describe the different functions of a system and their relative interactions1. The core motivation of functional architecture is to start understanding and specifying in detail the system, but only in terms of behaviors – that is, in other terms, to understand and specify what the system does – and not concrete structure, that is, its functional nature … as we would have easily guessed!
It is indeed important to have first a functional description of a system, and not to immediately dig into the technique, if we want to be able to rationally manage trade-offs between different options2. Functional architecture is indeed usually independent of the technological choices3 at least at some level of abstraction, which means that functionally reasoning – of course at the good level of abstraction4 – on a system allows us to reason at the same time on many different constructional options that we will be able to compare and to evaluate later (for more details, see Chapter 9 which is dedicated to trade-off analyses). We must indeed understand that skipping functional analysis by directly going to technical design is usually a very bad practice, even if widespread in engineering organizations, since it just means that we are making a very strong design choice without even being conscious of that choice. As a consequence, we will just be glued in that choice, without being able to move to radically different options that might be more adapted.
We must also stress that functional architecture is absolutely fundamental to capturing emergence and transversal behaviors that can only be modeled using its tools. By definition, all emergent behaviors can indeed not be captured by constructional architecture since they are functional properties of an integrated system (we refer to section 1.2 for more details). We must hence use functional architecture to describe and model such properties. As an immediate consequence, functional architecture is a key tool to structure transversal collaboration in an engineering organization whose purpose is indeed to efficiently manage the emergent transversal behaviors of a system.
Last, but not least, functional architecture also allows us to organize a system in functionally decoupled – as much as possible – sub-systems. This is very important if we want to avoid too many impacts when there is a change in a system design5. As already pointed out previously, this idea gives rise to layered functional architectures where each functional layer is strictly functionally segregated from the other ones by fixed standard functional interfaces that are managed in configuration. This architectural functional segregation/decoupling principle provides huge flexibility: in an ideal world, we will indeed be able to change a function in one layer without any impact on the other layers, as soon as the functional interfaces between layers are respected. We refer to the concrete examples of systems organized according to such a principle that are provided in the example section of Introduction and in the functional architecture subsection of section 3.2.
For any system S, functional architecture has five core types of deliverables:
These different types of deliverables are presented more in detail below.
Let S be a system. The functional requirement architecture diagram of S is then a hierarchical exhaustive representation of all functional requirements of S, a functional requirement R1 being under another functional requirement R2 in this hierarchy if and only if we can logically deduce R1 from R29. In this last situation, we say then more precisely that R2 refines into R1, which explains why we speak of a functional requirement refinement hierarchy10.
Figure 6.1 illustrates here a (partial) functional requirement architecture diagram for an electronic toothbrush, a functional requirement being – classically and similarly to a need – represented here by a 2-part box, whose first top part is a short name summarizing the functional requirement scope and whose second bottom part is the functional requirement statement, the refinement relations, on which relies the functional requirement hierarchy, being – also classically – represented by arrows.
Note that the same issue, already pointed out for the need requirement architecture diagram, also takes place with the functional requirement architecture diagram: organizing a functional requirement refinement hierarchy is indeed always difficult since we shall avoid having too many first level functional requirements, but of course also too many levels of refinements, if we want to be able to efficiently use such a view. The 7x7x7 rule (see the first part of section 4.2) is again a precious tool to handle this real difficulty. As a consequence, a typical “good” functional requirement architecture diagram associated with a system shall have no more than seven high-level functional requirements, each of them refined in around seven medium-level functional requirements, finally also refining in the same way into seven low-level functional requirements. Note again that the number 7 shall just be taken as an order of magnitude. Obtaining up to 10–12 high-level functional requirements in a functional requirement architecture diagram could of course work: however, we must not go further without analyzing whether this number is justified. Finally, we shall not hesitate to construct as many additional functional requirement architecture diagrams as necessary, for refining such an analysis as soon as all relevant functional requirements are not derived and/or captured.
Let S be again a system. The functional mode diagram of S is then a representation of:
The standard representations of the temporal relations between functional modes introduced above are given – mutatis mutandis – by Table 5.1, if we now interpret C and D as functional modes.
The above Figure 6.2 provides in particular an illustrative functional mode diagram associated with an electronic toothbrush, taking here the standard representation of functional modes and of their temporal relationships that we introduced, when events – that induce functional mode transitions – are modeled by arrows labeled with the name of the relevant event. Note also that the initial (respectively, termination) events in each functional mode do not respect this rule since they are conventionally modeled by small black circles (respectively, by white circles containing a black circle).
It is finally important to understand that the functional mode diagram is key since it models – from a functional perspective – time. Following the intuition that we developed at the end of the second paragraph of section 5.2, we could say that the next diagrams – that is, the functional breakdown and interaction diagrams – are modeling the “functional space” in which functions are evolving. Since space and time are always required to specify any functional behavior (that takes place “functionally somewhere” at a certain time), these two diagrams are completely complementary.
Let S be a system. The functional breakdown diagram associated with S is then a hierarchical representation of the functions of S, a set F1, F2, …, FN of functions being under another function G in this hierarchy if G is the result of the integration – in the meaning of Definition 1.512 – of the functions F1, …, FN13 (F1, …., FN are then classically called “sub-functions” of G). The functional interaction diagrams associated with S are then just the different representations – there is one functional interaction diagram per integration relationship involved in the functional breakdown diagram – of each such integration relationship that exists between the different functions appearing in the hierarchy modeled by the functional breakdown diagram.
Figure 6.3 above now provides an illustrative partial example of the functional breakdown diagram for an electronic toothbrush, where the integration relationships on which this hierarchy relies are – quite classically – represented by squared arrows.
We also give an example of a functional interaction diagram for an electronic toothbrush that can be found in Figure 6.4. In this example, we modeled the integration relationship existing between the global function of the toothbrush and its first “sub-functions” (using the formalism of a classical “activity diagram” in the UML or SysML meaning; see Booch et al. (2004) or Friedenthal et al. (2012)). Note also that external interfaces are here – quite classically – represented by white squares at the border of the external oval that is representing the integrated function (here the global function of an electronic toothbrush).
The functional breakdown of a system S modeled by the functional breakdown diagram is also classically called the functional breakdown structure (FBS) of S. Similarly to the mission breakdown structure that we introduced in the last chapter, it gives the exhaustive dictionary of the functions of the system and thus has a key role in guaranteeing a common understanding on the functional scope of a system, which is mandatory for an efficient transversal collaboration between the different actors and stakeholders of a system development project.
We must, however, be aware of the readability of such a view. All the recommendations based on the 7x7x7 rule that we previously gave for the stakeholder and need architecture diagrams of course also apply – mutatis mutandis – to efficiently model the functional breakdown structure of a system.
Last, but not least, we refer to Figure 1.9 in Chapter 1 for a concrete functional interaction diagram associated with an aircraft: it represents how all first-level sub-functions may be integrated to obtain the high-level global function of an aircraft. Other examples of concrete functional interaction diagrams may also be found in the example section of Introduction.
Let S again be a system and q(S) a functional mode of S. A functional scenario diagram associated with S and q(S) is then a dynamic representation of the interactions that are taking place between the functions of S, and possibly the environment, during the period of time which is modeled by q(S).
The below Figure 6.5 shows an example of functional scenario diagram, associated with the “active” functional mode of an electrical toothbrush. We refer to the suitable paragraph of section 3.4.2 for the fundamentals of the semantics of this representation. However, we are obliged to introduce richer semantics with respect to the one that was introduced in section 3.4.2. The below diagram indeed expresses that, as far as the electronic toothbrush is in an active mode (which was modeled by the big box with “loop” on its top left and the “[active mode]” indication14 in its top middle), it shall do in parallel (which was modeled by the big box with “par” on its top left), that is, at the same time, three types of operations (that are separated by dashed lines in the “par” big box): the first one being brushing force management, the second one being brushing data management and the third one being energy management. For the sake of completeness, we shall also know that there exists an “alt” (for alternative) box which allows us to express “if then otherwise” situations15.
A functional scenario diagram provides the explicit “algorithm” which is underlying to the functional behavior of the system in a given functional mode. This is key to finally understanding what – at least functionally – happens during a given functional mode. The enriched semantics that we introduced indeed allows us to express any distributed algorithmic property of a system16.
Let S be a system. The functional flow diagram associated with S is a consolidated description of all the functional flows associated with S and of:
Hence, it plays the role of the functional “data model”17 of the system. Note that we also may split this diagram into two diagrams, each of them covering the two above points.
Figure 6.6 below shows an example of (partial) functional flow diagram, associated with an electrical toothbrush. Its syntax exactly follows the same principles as the operational flow diagram (see the last section of Chapter 5).
As already stated, the functional flow diagram defines the functional flow or object model of a given system. It is completely “dual” to the functional breakdown, interaction or scenario diagrams since it focuses on flows and not on the functions of the system that are producing these flows.
We must thus again emphasize that such a diagram is of high importance since it rationally describes in a consolidated and organized way all inputs and all outputs of the functions of a given system. Hence, it gives the functional “dictionary” of the system, that is, the list of all objects that are functionally manipulated by the system. This dictionary is of high value for ensuring a common vision between all project actors involved in the architecting process: these actors shall normally – in an ideal world – only use the terms of that dictionary when discussing a functional object. We may easily understand that such a principle allows us to avoid any ambiguity between the different project actors. It is thus again key for ensuring a good collaboration between these actors.