Similarly, the ends served by the functions of the elements, i.e., the purposes of the system, are among those properties of the whole system that are essential to the system. For instance, if a function of the heart in the cardiovascular system is to pump blood, and circulation of blood is the purpose served by that function, then this entails that circulation of blood is an emergent property of the cardiovascular system, that the heart is an element of that system, and that the heart does not pump blood apart from its belonging to the cardiovascular system.
Functions and purposes are separated by one hierarchical layer in a nested system-of-systems, but purposes at one level are not the same as functions at the next, except by coincidence. So, for instance, that a function of the heart is to pump blood, and that circulation of blood is a purpose of the cardiovascular system, does not entail that pumping blood is a purpose of the heart (i.e., an end served by functions of the heart chambers or cardiac valves), nor does it entail that circulating blood is a function of the cardiovascular system in the human organism, although both hypotheses are, in practice, reliable starting points for iterative analysis.
“Design” as a verb is a rational or economic act of requirements transformation. In systems engineering, requirements are transformed through many stages: from user requirements to system operational requirements through conceptual design, from system operational requirements to element functional requirements through preliminary design, and from element functional requirements to production requirements (specifications, schematics etc.) through detailed design. This process, the concatenation of conceptual design, preliminary design, and detailed design, is shown below in figure 1 (adapted from Blanchard and Fabrycky (1981), MIL-STD-499B (1994), and IEEE Std 1220 (1998)).
The process of engineering design develops efficient applications of resources to satisfy needs. The economic or rational aspect of design, combined with inherent functional allocation in design, distinguishes designs from other arrangements of parts for a collective purpose by a technologically relativistic analogue to Weinberg’s criterion of elegance, the economy of means to an end so that nothing is invoked other than what is functionally justified (Weinberg, 1992, 135).
 |
| Fig. 1 Design process in systems engineering |
The outputs of engineering design are product and production specifications in sufficient detail to eliminate interpretation, variation, or artistic inspiration in the production process. Design results in detailed procedures for processes, detailed algorithms for software, and detailed blueprints for manufacture, without addressing those aspects of production that can be accepted by the engineer as known technique or established art (Aristotelian technikos).
Requirements transformation in design is inherently risky: requirements interpreted from one perspective to another cannot be analytically guaranteed to close, e.g., having the elements each meeting their functional requirements in preliminary design does not logically guarantee that the system will meet its operational requirements, etc. This is because requirements transformations are both hierarchical and interpretive: the requirements at each level are expressed in terms natural to the perspective of that level. User needs are expressed in the user’s terms with the user’s measures of effectiveness, system operational requirements are expressed at the system level, element functional requirements are expressed in discipline-specific functional terms (e.g., electrical, mechanical, control), schematics are expressed in manufacturing and materials terms, etc.
In keeping with the definition of designing as an inherently rational or economic activity, “design” as a noun is the rationale, i.e., cognitive analytic basis, for the requirements transformations inherent or implicit in, expressed or embodied in, or imputed to the structural, functional, and process relationships between the system, its environment, and its parts or elements.
“Design” as a noun is not the outcome of “design” as a verb; schematics and specifications are not designs but rather the fagades of design, i.e., the interface from design to production, a summary of design sufficient for production. That there is more to a design than is captured in schematics and specifications is evident when designs are protected as proprietary, or delivered from a vendor to a customer in cases of contracting design, or archived for future use. What is included in an archived design, or in a design delivered under a standard contract, or is protected as proprietary when safeguarding designs, includes performance analyses, trade studies, and the development of those alternative system concepts that were evaluated but not, in the end, chosen for production (DAU 2000). In any of these cases what is included in the object called a “design” is the entire rationale for the requirements transformations specified in the design process.
Complementing the distinction between the noun “design” and the products of the activity called “design” is the distinction between comprehending the design of something, e.g., the human heart, and inferring the prior occurrence of an act of design; to acknowledge the design of something is only to judge that the relationships between elements and their capabilities at successive hierarchical levels of nested systems are rational or economical. The rationality of design is an analytical rationality rather than an etiological rationality.
This description of design and designing applies equally to problems of designing simple and complex systems, with the principal distinction being that for systems requiring a great deal of novelty and innovation the process may be nested: what appears to be an element of a system in the design process outlined above may be an un-designed system in its own right, so that specifying its element-level requirements in preliminary design of the super-system may be identical to specifying its operational level requirements in conceptual design of the subsystem.
Design in systems methodology is the combination of two interactive loops, one addressing the relationship of the design object to its environment, the other addressing the relationship of the design object to its parts. In systems engineering, the two loops are called preliminary design and detailed design, while in systems analysis they are called expansion and reduction. Viewed from the perspective of an arbitrary element Yb, a functionally specified constituent of a system X, preliminary design of X and expansion of Yb both determine the function of Yb as a contribution to the comprising whole X, while detailed design of X and reduction of Yb determine the
structure of Y. and how it works.
b
The relationship between the systems engineering design of X and the systems analysis of one of its elements Yb is illustrated in figure 2 above for a system X consisting of elements Yi, each of which in turn consists of sub-elements Z... In figure 2, the nesting can continue indefinitely in both directions: X can be an element of some other larger comprising super-system W, and each Z.. can in turn be an object of either design or analysis, so that the preliminary design of X may also be part of the detailed design of W, and the detailed design of X may comprise the preliminary designs of the Y. and the conceptual designs of the Z...