This is the foundation page for the Functional Domain.

My Standard Caution About Abstractions applies to this page.

Introduction

When presented with an operational task to be accomplished, End Users often lean toward using tools that they’ve used before¹.  As with any bias, yielding to that temptation might turn out OK…or it might be catastrophic, or anywhere in between.

A cluster of legacy System Engineering techniques were developed² to counteract such tendencies³.  These techniques seek to mitigate biased preferences by abstractly differentiating what a system does⁴ from what that system is⁵.  This page, which is the foundational page for all Functional Domain pages in this site, deals with the core concept of those techniques: the essential characteristics of a “function”.

Aside

By dividing the problem into different abstract aspects, we enable a “cross-indexing” of perspectives on that problem⁶.  However…please see my Standard Caution About Abstractions.

The cross-indexing enables focused attention from an array of Engineering specialties that would otherwise be difficult to achieve⁷.  Each such specialty can integrate the entire system both horizontally and vertically with respect to their area of expertise.  That integration, being executed by a non-advocate is⁸ not biased either for or against the design’s competency.  This idea lies close to the heart of the notion that System Engineering is most easily understood as a collection of methods to mitigate cognitive bias during development.

It should be noted (however) that “functionality” is not a recognized Engineering specialty.  Functionality, which is generally traceable to a specific operational task, objective or circumstance, is often unique to each End Item being developed.  That makes Functions (and related Performance) the particular province of the System Engineers themselves⁹.

To re-state, we further differentiate between what a system does (“function”), what the End User does to¹⁰ it (“operating procedure“), and what the End User achieves with¹¹ it (“operational objectives”)¹².  Although all three of the terms refer to actions that change state, they indicate significant differences of interest.  Here, the primary interest is in the first of these terms.

Engineering in the functional domain was considered so fundamental in legacy System Engineering that legacy practices often used the concept as the primary framework for organizing information about the system’s characteristics during development.  See, for example, the establishment of a Functional Baseline and a Functionally Allocated Baseline, leading to PDR.

Aside

The type of problem we’re trying to address here is as if I needed to drive a screw…but knew only how to use a hammer.  I’d like to know how well the hammer would work with that screw before I paid for any tools and materiel, and should think the whole operation through before spending any money.  I should compare what the hammer does (function: apply a linear impact load, tangential at the point of impact) to what the screw needs done to it (procedure: apply torque under continuous axial load) in order to accomplish its own functions (advance axially to apply an axial clamping load parallel to the thread axis).

In all cases (of course) we’d like to provide existing tools to the End User that are suited for the task at hand, provided that we can establish their suitability with a reasonable amount of time and effort¹³.  Therefore, we apply a single framework to the specification of functions¹⁴ and to the description of existing equipment¹⁵.  When synthesizing, we use functionality as the basic framework for our description of the desired system’s capabilities.  When analyzing, we can use functionality as an element of the Rosetta Stone to compare the characteristics of existing widgets to those of a desired capability.

Aside

Because it would simplify and standardize the definition of Functions, any given developmental organization might benefit from a standardized set of functions within any given product line.  That, however, might not be easy to create, and it would almost certainly decrease the portability of the Engineers involved¹⁶.  It is, however, absolutely the basis for the concept of “standard parts” such as logic chips, fasteners, connectors, power supplies, general purpose computers, planes, trains, and automobiles, and…well, you get the picture¹⁷.

We conduct a special type of analysis when we assess a “problem” to identify changes of state that might could be met (in whole or in part) by technology.  In this context, the word “problem” usually refers to a set of operations, or a set of operational objectives.  It includes the situation where we’re trying to break a conceptual design into smaller pieces for detailed development.  This situation often contains significant synthesis, but can be highly analytical when we’re trying to understand the unavoidable implications of a selected technology¹⁸.

That second type of analysis can be difficult to execute with disciplined restraint: it is often impossible to explicate all of the functionality without also implying concomitant restrictions and limitations on the design solution.  The desire to have the Functional Analysis appear complete at the time of original specification¹⁹ overwhelms many practioners.  Such limits are acceptable only when this type of analysis is executed in iteration with selection of the design solution, and the functional analysis often remains “incomplete” until a design approach has been selected²⁰.

Aside

The preceding discussion might be interpreted to mean that Functions are more important than other characteristics.  That is not correct.  Historically, they were designated for “special” attention because they’re one of the primary (abstract) topics that differentiate between projects that share a common subset of technical developmental skills.  Most (but not all) of the other characteristic types can be dealt with by recognized specialists who’s body of knowledge is generally recognized as being portable from one project to the next.  That doesn’t make those other characteristics less critical.

Foundation

To begin with, the following definitions are stipulated:

System: the dingus; the thing we’re working on, which might be simple or might be complex.  The utility of the two basic definitions of “system” (see the link) depends on whether we’re doing pure synthesis, pure analysis, or a bit of both.

Analysis: the process of examining a thing by identifying its constituent parts and describing the relationships between them.  Definition 2 of “system” lends itself more easily to analysis than it does to synthesis.

Synthesis: the process of constituting a thing (which might, or might not, be concrete) from individual parts and imposing relationships between them.  Definition 1 of “system” lends itself more easily to synthesis than to analysis.

Function: A means to impose a system state.

The “system function domain” refers to a data set.  The set is comprised of elements that are the system’s functions²¹; each element is represented by a compound data structure comprised of nomenclature (the “name” of the function) and a vector of parameters²² that are affected by that function (again, a set of “names”).  In many situations, values for those parameters will be stated; the ranges may (or may not) entail restrictions on their correlation.

Aside

There is a relationship between concrete reality (on the one hand) and the abstraction of a function set (on the other hand).  Because one is abstract and the other is real, they can reasonably diverge.  Too much divergence, however, leads to nonsense.

When we’re analyzing an existing dingus, we’d do well to comprehensively identify the actual functions of that widget: that is, to match concrete reality rather than follow an abstract perception.  Later, we might want to assess suitability for said dingus by means of that characterization.  We may also want to carefully segregate those characteristics that were intended by the original developer of the dingus from those that were not so intended, which can form an important liability issue when re-using parts.  See also Selected Item Drawing, Altered Item Drawing and Part III of the CI Development Cycle.

When we’re analyzing a problem, we’ll usually specify a required set of functions, which constitute a different kind of abstraction.  This means that the eventual concrete design might have functionality beyond that which was formally specified.  This problem doesn’t occur very often in software²³, but can present significant issues in the development of hardware that might be difficult to foresee when doing the initial Functional Analysis (see, for example, Verification by Surprise).  The specified functional description, usually expressed in the form of Performance Requirements, can (therefore) be a subset of the eventual reality.

When we’re synthesizing a design²⁴, we’ll develop an intended set of functions²⁵.  The abstract design intent, as noted above, might be broader than that which is required.  We may later discover other things that the design will do, or can be done with it²⁶.  I often refer to this situation as “unintended functionality”.  Unintended functionality, which is concrete, can be very useful.  It can also be highly problematic, due to the potential for unplanned external interactions.  That is, unintended functionality will not have had any horizontal integration with the rest of the system until we assemble and test the components in each other’s context.  These issues are far more likely to occur in hardware than in software²⁷.

If we take the union of all parameters used to describe the system’s state, we can also compose a domain that is separate from (but clearly related to) that of the system functions, provided that we ensure orthogonality of the unified set of parameters .  The “parameters domain” allows us to measure the state of the system being analyzed: each state being defined as a particular combination of values.

Aside

The above discussion of a “parameters domain” suggests that a given parameters might be affected by more than just one function.  This is completely permissible: the functions of a system might not be independent in the sense of simplistic linear algebra, particularly when there’s hardware involved.  Forming the auxiliary domain allows us to directly investigate the orthogonality of the parameters themselves, outside the context of our ability to control their values.  Among other things, that investigation allows System Engineers to assess the potential for internal contradiction in their Performance Requirements.

Expression

Whether executing analysis or synthesis, we want to produce data that define the sequence of the system’s functions as they change (or maintain) values of the system’s state vector.  Figure 1 shows a few of the available techniques for storage and presentation.  Although a diagram of some kind is usually the preferred method of documentation, no particular form or format is advocated here: any method is acceptable provided it definitively controls the relationship between functions, their associated parameters, and their sequencing.  I frequently use an extended version of the legacy “Functional Flow Block Diagram” (FFBD), shown in Figure 1(a).

I attach no prejudice to the use of executable models to store and express functions.  In fact, I strongly support that notion, and have frequently built models accordingly.  Few environments (however) explicitly and directly support the concepts articulated herein: the concepts here are less demanding than (for example) multi-disciplinary physics or the bureaucratic administration of requirements and, therefore, less profitable.  Being less profitable, few software aids and tools exist in their support.

Basic Identification of Functions

A myriad of formative techniques exist to identify and describe functions.  Many arguments can²⁸ follow.  Because I’m not very interested in the arguments,  I’ve highlighted only a few, just to provide some idea of the thought processes involved.

Analysis of Essential Functionality

In this mode, we identify the implications of changes desired in a system’s state, without regard to the (eventual) responsive design characteristics.  The desired changes might, for example, be generated by constraints due to known physics, mandatory doctrine or logic, or the characteristics of mandatorily interfacing systems; they are (in any case) explicitly outside the control of the system’s technical designers.  These issues constitute part of the “problem” that is handed to the design team²⁹.

We don’t immediately and comprehensively deal with feasibility during this process because once we’ve analyzed beyond the sequencing of system states mandated by those constraints, we’ve “plunged” too far into the functional decomposition of the (as-yet undefined) system.  Plunging inherently makes assumptions about design solutions that implicitly constrain subsequent design activities.

Although plunging is deprecated here, it is difficult to resist.  Sometimes it is even difficult to recognize.  For that reason, I believe that this type of analysis is best performed by disciplined System Engineers that are embedded within the design team, in order to mitigate the opportunity for bias by either the Designers or by the System Engineers.

I’ve included an example of analyzing essential functionality here.

Functional Analysis of Existing Systems

In my experience, two sets of circumstances require us to describe the characteristics of existing items: 1) evaluation of agnostic designs and 2) test troubleshooting.  In both cases, the objective is to identify and establish the changes of state effected by an item, but they proceed from significantly different initial conditions.

Evaluation of Agnostic Designs

We often want to know whether an existing design will satisfy a given set of requirements.  By definition, since the design predates the subject requirement set, it is “agnostic” with respect to that (usually new) set.  The task is to characterize the item, which might (or might not) involve substantiating test, to determine the degree of such satisfaction.

Although I used a fancy-pants name, this is actually the most commonplace mode; so mundane, in fact, that I won’t waste time with concrete examples.  We use it every time we call a standard library when writing code, a standard fastener in a structure, or a standard connector in a wire harness.  We also use it when we incorporate commercially available things like pumps, power supplies, and standard chipsets.  We just don’t usually draw any form of FFBD when we do that kind of thing.

Troubleshooting

Troubleshooting of a failed test usually involves discovery (by whatever means) of what a Unit Under Test (UUT) will do, given that it did not do what it was supposed to.  This mode is distinct from the others for two fundamental reasons: 1) we don’t always know what to measure (or observe) and 2) we don’t always know that any “functions” even exist in the failed unit.  The resolution of both will often require iteration, exploratory testing, exploratory analysis of the data produced during test and (frequently) significant innovation and persistence .

To the best of my knowledge, no single algorithmic concept can cover the resolution of all test failures.  An example best serves to describe the basic concept of describing aberrant function.  A different example illustrates the notion of dealing with the existential question, which can be a much tougher situation to deal with.

Functional Synthesis

“Synthesis” suggests that the developer is working from a “clean sheet of paper”, having few constraints on the selection of candidate constituents and the imposition of relationships between them.  In most practical cases (however), System Engineers use functional synthesis during functional decomposition, which usually occurs in some particular technical context.  An example thereof can be found in the decomposition section of the air compressor example.

 

Footnotes

1.   Because when all we have is a hammer, everything looks like a nail.[↩]
2.   or, more credibly, evolved.[↩]
3. We want to make sure the tool fits the task before all the money is spent and all the time is wasted.[↩]
4. or should do[↩]
5. or should be[↩]
6. As opposed to the purely manufacturing hierarchy associated with the assignment of Part Numbers.[↩]
7.   Never mind how it would be audited![↩]
8.   Again, in theory.[↩]
9.   Many developmental organizations will define standardized parts of the system called “Subsystems”, assigning them to technically focused “Systems Engineers” or “Subsystem Engineers”.[↩]
10. or, sometimes, for [↩]
11. or by the use of[↩]
12.   In the context of this structure, we could consider that the achievement of the desired operational state follows from use of the system.  But perhaps I wax pedantic.[↩]
13.   The most reasonable developmental project is the one that needs develop nothing new.[↩]
14. usually a synthesis activity[↩]
15. a purely analysis activity[↩]
16.   Such portability being much beloved by non-technical management.[↩]
17.   I hope.[↩]
18.   rather than postulating alternative approaches[↩]
19.   That is, to show all of the functionality that will eventually exist…and show it during requirement development, at the start of the project.[↩]
20.   Which drives many System Engineers crazy.[↩]
21.   Which is itself a class of topic. [↩]
22.   Or, alternatively, a vector-valued parameter[↩]
23.   Except when doing things like re-using large code fragments, or dealing with a mess of global variables.[↩]
24.   Which might, or might not, be in response to a set of requirements.[↩]
25.   Not to be confused with a required set.[↩]
26. or sometimes to it[↩]
27.   At least, as long as global variables and other shared memory concepts are carefully managed.[↩]
28.   And have.[↩]
29.   Which might, or might not, include the System Engineers doing the analysis.[↩]