Figure 2 offers an opportunity to distinguish functions from purposes using Bertalanffy’s definition of system. Consider the relations Rb found among the elements Zbj in the reduction of Yb, and the relations Ry found among the elements Y. in the expansion of Yb. The functions of the elements Zbj serve purposes inherent in Yb, and the function of Yb serves a purpose inherent in X. The question to consider is whether the function of Yb and the purposes inherent in Yb are identical. Systems analysis answers no, except by coincidence, because the function of Yb is among those properties that Yb has in virtue of relations Ry rather than any alternative R'y, while the purposes inherent in Yb are among those properties that Yb has in virtue of relations Rb rather than any alternative R'zb. The function of Yb and the purposes inherent in Yb are both at the same hierarchical level, i.e., they are both in Yb, but they are determined by distinct relations Ry and Rb at adjacent hierarchical levels, and therefore they are not identical, though they may correspond to one another.
An important difference between design as implemented in systems engineering and as rationalized in systems analysis is in the peripheral role of the concept of function in the former, and its central role in the latter. The difference stems from the difference in relationship between the engineer and his system on the one hand, and the analyst and the object of her inquiry on the other.
The engineer works from concrete customer needs, and is concerned to transform these needs into verifiable requirements at the system and subsystem levels. To the engineer, functional analysis is only a means to requirements, which latter are quantifiable, testable, and verifiable. Once functional requirements are set, they are specific to elements, and compliance can be judged independently.
The analyst works from a concrete system, and is concerned with developing information, knowledge, and understanding. For the analyst, her objectives are descriptive, relative, and functional rather than imperative, absolute, and normative. Functional descriptions are interdependent and relational, and are developed jointly for ensembles of elements.
The relevance of the distinction is illustrated by failure analysis of a system. If the external inputs to the system all conform to specifications, but some external outputs of the system are nonconforming, then the system is a suitable object for failure analysis, in which the analyst, either the designer of the system or a systems analyst, attempts to analyze the failure, attributing failure either to an element of the system or to the system as a whole.
For the design engineer, any element whose output is not in specification while its inputs are all within specifications is nonconforming, regardless of function. Specifications on a system or an element are contingent on inputs, so that an element with nonconforming outputs may be excused if an input is nonconforming. The performance of each element is evaluated against its specifications in isolation. It is possible for all elements of a failing system to be excused on the basis of nonconforming inputs from other elements, e.g., in any case with nonconforming feedback, in which case the failure must be attributed to the system as a whole.
This requirements focus of the design engineer is in sharp contrast to the functional analysis of the systems analyst, who has no prior way of discriminating whether an element has a nonconforming input, or is failing to perform as it should in the context of its input, unless functional ascriptions can be made to the elements and rational requirements inferred from the functions and available means. The systems analyst only makes progress via comprehension of the function of the elements. To the systems analyst, functional description, rather than quantitative specification, is fundamental to analysis of design.
As summarized by Gharajedaghi (1999, 112-113), the design approach to systems analysis iteratively examines structure, function, and process to develop understanding in terms of design. Iteration is necessary because, in the systems approach, process and structure co-produce function in the context of environment. Inquiry then becomes necessarily iterative because structure, function, and process are each co-produced by the others, as well as co-producing each other, so that developing a new understanding of each modifies the understanding of the others in a converging sequence of mutual dependence.
The producer/product relationship is Singer’s framework for explanation in the world of complex objects without sufficient causation. In Singer’s framework, producers are necessary but not sufficient for their products, in the manner of acorns being necessary but not sufficient for oak trees. Singer (1924; 1959) uses the producer/product relationship to develop a pragmatic theory of choice, purpose, and free will, and extends the relationship in various ways to account for reproducers, co-producers, potential producers, and other analogues for biological and ecological classes (Flower, 1942; Pennypacker, 1942). Systems analysis uses the same framework for developing an objective theory of function and purpose. Function is a joint product of structure and process in the context of a purpose inherent in the essential characteristics of a comprising system.
The key challenge satisfied by the producer/product model of the relationship between structure and function is explaining how a given structure can have multiple functions in the same environment, as is often observed in systems behavior. The answer offered is that a single structure in a single environment can result in multiple functions through multiple processes.
The theory of design presented here defines function in terms of rationalized interlocking producer/product relations among structure, function, and process, so that having a design entails having elements with functions. This design paradigm of systems analysis differs from currently prevalent etiological, welfare, and dispositional analyses of functional ascriptions (McLaughlin, 2001).
In systems analysis, no etiological conclusion is warranted about a system with manifest design, nor is any conclusion warranted regarding whether it, or anything related to it, benefits from its functionality, or even whether the object exhibiting design has the ability to work in the manner implicit in its design. Design in systems analysis is only an objective model for an inquirer developing understanding,
i.e., answers to “why?” questions, to complement knowledge and information, i.e., answers to “how?” and “what?” questions.
Systems analysis differs from classical internal teleology on the one hand, and subjective Cummins (1975) functional ascriptions on the other, in attempting an objective analysis of functional characteristics: following Singer (1924; 1959), systems analysis equates functional characteristics of a system with observable behaviors and capacities, and wields rationality and economy as razors for reducing understanding to inter-subjective propositions.