Introduction to Systems Engineering Fundamentals

The word “system” is used in all areas of human activity and at all levels but what do people mean when they use the word “system” and is there some part of the meaning that is common to all applications? These and similar questions, all relating to the use of the word “system” in everyday language, need to be given careful consideration if we are to achieve a clear understanding of the underlying system concept itself before specialising to the engineering context.

Everyday usage.

Some examples of the use of the word system in everyday usage are education system, transport system, solar system, telephone system, Dewey decimal system, weapons system, ecological system, space system, and so on; there is almost no end to the uses of the word “system” that come to mind. From the above examples, we see that the word “system” always refers to a particular object, its reference, and when we use the word by itself, the reference is always implied by the context in which we use it. And, in a general way, the use of the word “system” characterises its reference as something that consists of many parts or elements, but with no further restriction on the nature of these elements; they may be physical entities, such as hardware, software, tasks, and activities, or abstract activities, such as ideas or concepts. But the references fall into two main groups:

The elements form a system by virtue of having certain features or characteristics in common, such as the periodic system (elements are atoms) and the Dewey decimal system (elements are books). The meaning of the word is that the system provides an ordering, or taxonomy, of its elements; it provides a systematic view of its elements.

The elements form a system by virtue of their interactions through the exchange of energy, matter, or information, or any combination of these. Outside of their interactions the elements may or may not have anything in common. Examples of systems in this group are the Solar System and the Public Health System, and a very general, but formal definition is the following (Aslaksen 2004):
- A system consists of three related sets:
  - a set of elements;
  - a set of internal interactions between the elements; and
  - a set of external interactions between one or more elements and the external world; i.e. interactions that can be observed from outside the system.

The systems in the first group are, of course, all man-made, as the characteristics that identify a system or subsystem are a matter of human perception. The systems in the second group fall into two subgroups; those that occur in Nature, and those that are man-made. Clearly, the solar system belongs to the former, and the public health system to the latter. This distinction is of importance to systems engineering, for while systems engineers can learn from studying systems occurring in Nature, the systems engineering processes are concerned only with systems in the latter subgroup. And these systems have a common property, that of a defined purpose. The nature of the purpose can vary widely, from self-realisation to interstellar exploration, but for the systems of interest in the context of systems engineering, the purpose can usually be expressed as satisfying a need by providing a service, where “service” should be understood in a generalised sense, to include not only “true” services such as e.g. financial services, communications services, and security services, but also the provision of products. The distinction between the service and the system, as the engineers’ solution to providing the service, is central to systems engineering, as will be developed in Part 3.

This view of a system in the context of engineering has been present throughout the development of systems engineering; two examples are:

“A system is an array of components designed to accomplish a particular objective according to plan.” (Johnson, Kast, and Rosenzweig, 1963).

“A system is defined as a set of concepts and/or elements used to satisfy a need or requirement.” (Miles, 1973).

The INCOSE Handbook defines a system as “An interacting combination of elements to accomplish a defined objective. These include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements.” (INCOSE 2008).

As a stand-alone concept.

The forgoing section considered the use of the word “system” in everyday language, where it always references a particular object. However, it is also important to take a step back and ask: What is the nature of “system” as a stand-alone concept? How does it fit into a philosophical framework into which all manifestations of human activity must fit in some way? It is straight-forward to demonstrate that “systems” is not a class of objects, nor is “system” a property of objects (Aslaksen 2004), and we get closer to answering our question if we observe that the system concept is a mode of description, so that rather than being a property of a thing, it is a property of a description of a thing; that is, a system is what Frege would call a second-level concept (Frege ), It is the description of an aspect of an object in terms of a set of interacting elements. The object can, in principle, be anything; a physical object, a body of work, an idea, an enterprise. The aspect taken should support what needs to be described, such as what the object consists of, what it does or how it behaves, what it costs, or its reliability. Consequently, there can be many systems associated with a given object. And, of course, the aspect need not be described as a system; rather, it can be described as a single entity (or black box). The aspect, be it behavior or cost, remains the same.

Why do we need to apply the system concept in engineering?

The short answer to this question is: To improve the probability of a successful outcome of complex projects. A more complete answer requires an understanding of complexity, in particular, the understanding that complexity is relative to human mental capability; what is complex to a human may not be complex to a computer, and vice versa. The mind can manipulate objects that are characterised by more than one parameter as entities; that is, it is able to consider the parameters simultaneously rather than sequentially, as a computer normally does.

But there is a limitation to this ability; as the complexity of an object increases and the number of parameters exceeds a certain number, the mind finds it rapidly more difficult to consider the object as an entity, and automatically starts to partition the parameters into smaller groups and to process them as separate objects. The most immediate evidence of this is language; in order to express something complex, such as a story, we use a limited set of vowels that can be combined to form words, the words are subdivided into groups (nouns, verbs, predicates, etc.) and combined to form sentences, and the whole story is a string of sentences. However, the elements need to interact, and in the case of language the interaction takes place in the mind of the listener and is determined by the sequence of the vowels, words, and sentences.

Another example of partitioning is found in organisations, in particular in the partitioning of military forces into a hierarchical structure. And a further example of using the system approach is provided by structured programming. The partitioning of a program into modules is so that it is easier for the human to understand and thereby be able to verify, test, and maintain. To the computer it would make no difference (except perhaps with regard to memory requirements) if the program was just one long unstructured file.

The converse of this subdivision of complex entities is the aggregation of simple, or low information content entities, so-called chunking, as was first described in the seminal paper by (Miller 1956), where he demonstrated that the number of chunks of information that can be retained in short-term (or immediate) memory is about seven, irrespective of the number of bits of information in each chunk, as determined by the dimensionality of the stimuli (limited to the experimental data available), and he attributed this to a process of encoding, a learning process through repetition that relies on long-term memory. In the context of engineering, we might call the chunks “objects” or “elements”, and the encoding “information hiding”.

The picture of the dual processes of chunking and partitioning, as illustrated in Fig. 2.1, will provide an important conceptual foundation for examining the process of engineering in terms of the two dual processes of top-down and bottom up design, in Part 3.

Figure 2.1 The dual processes of chunking and partitioning (Aslaksen TBP).

References

Johnson, R.A., F.W. Kast, and J.E. Rosenzweig, The Theory and Management of Systems, McGraw-Hill, 1963.

Miles, R.F. (ed.), System Concepts, Wiley, 1973.

Ryan, A., Emergence is coupled to scope, not level, Complexity, xx, (2007). A condensed version appeared in Insight, the newsletter of INCOSE, vol.11, no.1, January 2008, pp. 23,24.

Frege, G., On Concept and Object, Vierteljahrsschrift für wissenschaftliche Philosophie, 16 (1892), pp. 192-205.

Aslaksen, E.W., The System Concept and Its Application to Engineering, to be published.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.