Introduction to Systems Engineering Fundamentals

by SEBoK Authors

This article forms part of the Systems Fundamentals knowledge area (KA). It provides various perspectives on systems, including definitions, scope, and context.

This article provides a guide to some of the basic concepts of systems developed by systems science and discusses how these relate to the definitions to be found in systems engineering (SE) literature. The concept of an engineered system is introduced as the system context of critical relevance to SE.

Overview

In this KA we will define some terms and ideas which are foundational to the understanding and practice of Systems Engineering. In particular, a number of views of system are explored, these are summarized below and described in more detail with links to relevant references in the rest of this article.

• The simplest definition of system is any set of related things for which there is sufficient coherence between the things to make viewing them as a whole useful. As we consider more complex situations in which the parts of a system can also be viewed as systems we can identify useful concepts to aid our understanding which apply to many systems, independent of what they are made up of. This allows the creation of system theories, models and approaches useful to anyone trying to understand, create or use collections of related things.
• Many of these common system ideas relate to complex networks or hierarchies of related system elements. A System Context describes a set of system views associated with a particular system of interest (SoI). Context views allow us to focus on the SoI but not lose sight of its broader, holistic relationships and influences. Context can be used for many kinds of system but is particularly useful for scoping problems, and enabling the creation of solutions to them, combining people and technology and operating in the natural world. These are often referred to as socio-technical system contexts.
• Systems Engineering is one of the disciplines interested is socio-technical system across their whole life. This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider context and how developed solutions are used, sustained and disposed of. We define an Engineered System as a socio-technical context describing a SoI which is the focus of a Systems Engineering life cycle.

A General View of Systems

The idea of a system whole can be found in both Western and Eastern philosophy. Many philosophers have considered notions of holism; that ideas, people or things must be considered in relation to the things around them to be fully understood (M’Pherson 1974).

One influential systems science definition of a system comes from general system theory (GST):

"A System is a set of elements in interaction." (Bertalanffy 1968)

The parts of a system may be conceptual organizations of ideas in symbolic form or real objects. GST considers abstract systems to contain only conceptual elements and concrete systems to contain at least two elements that are real objects, e.g. people, information, software and physical artifacts, etc.

Similar ideas of wholeness can be found in systems engineering literature. For example:

We believe that the essence of a system is 'togetherness', the drawing together of various parts and the relationships they form in order to produce a new whole… (Boardman and Sauser 2008).

The cohesive interactions between a set of parts suggest a system boundary and defines what membership of the system means. For closed systems all aspects of the system exist within this boundary. This idea is useful for abstract systems and for some theoretical system descriptions.

The boundary of an open systems defines elements and relationships which can be considered part of the system and those which describe the interactions across the boundary between elements and elements in the environment . The relationships between the elements of an open system can be understood as a combination of the systems structure and behavior. The structure of a system describes a set of system elements and the allowable relationships between them. System behavior refers to the effects or outcomes produced when an instance of the system interacts with its environment. System wholes often entities exhibit emergence, behavior which is meaningful only when attributed to the whole, not to its parts (Checkland 1999). An allowable configuration of the relationships between elements is referred to as a system state. A stable system is one which returns to its original, or another stable, state following a disturbance in the environment.

The identification of a system and its boundary is ultimately the choice of the observer. This may be through observation and classification of sets of elements as systems, through an abstract conceptualisation of one or more possible boundaries and relationships in a given situation, or a mixture of this concrete and conceptual thinking. This underlines the fact that any particular identification of a system is a human construct used to help make better sense of a set of things and to share that understanding with others if needed.

Many natural, social and man made things can be better understood by viewing them as open systems. One of the reasons we find the idea of systems useful is that it is possible to identify shared concepts which apply to many system views. These recurring concepts or isomorphies (ref) can give useful insights into many situations, independently of the kinds of elements a particular system is made up of. The ideas of structure, behavior, emergence and state are examples of such concepts.The identification of these shared system ideas is the basis for Systems Thinking and their use in developing theories and approaches in a wide range of fields of study the system sciences.

Systems Engineering (SE), and a number of other Related Disciplines use systems concepts, patterns and models in the creation of useful outcomes or things. The concept of a network of open systems created, sustained and used to achieve a purpose within one or more environments is a powerful model that can be used to understand many complex real world situations and provide a basis for effective problem solving within them.

Systems and System Elements

Bertalanffy (1968) divided open systems into nine real world types ranging from static structures and control mechanisms to socio-cultural systems. Other similar classification systems are discussed in the article Types of Systems.

The following is a simple classification of system elements:

• Natural system elements, objects or concepts which exist outside of any practical human control. Examples: the real number system, the solar system, planetary atmosphere circulation systems.
• Social system elements, either abstract human types or social constructs, or concrete individuals or social groups.
• Technological System elements, man-made artifacts or constructs; including physical hardware, software and information.

While the above distinctions can be made as a general abstract classification, in reality there are no hard and fast boundaries between these types of systems: e.g., social systems are operated by, developed by, and also contain natural systems and social systems depend on technical systems to fully realize their purpose. Systems which contain technical and either human or natural elements, are often called socio-technical systems. The behavior of such systems is determined both by the nature of the technical elements and by their ability to integrate with or deal with the variability of the natural and social systems around them.

Many of the original ideas upon which GST, and other branches of system study, are based come from the study of systems in the natural and social sciences. Many natural and social systems are initially formed as simple structures through the inherent cohesion among a set of elements. Once formed, they will tend to stay in this structure, as well as combine and evolve further into more complex stable states to exploit this cohesion in order to sustain themselves in the face of threats or environmental pressures. Such complex systems may exhibit specialization of elements, with elements taking on roles which contribute to the system purpose, but loosing any separate identify outside of the system. Such roles might include management of resources, defense, self-regulation or problem solving and control. Natural and social systems can be understood through an understanding of this wholeness, cohesion and specialization. They can also be guided towards the development of behaviors which not only enhance their basic survival, but also fulfill other goals or benefit to them or the systems around them. In The Architecture of Complexity (Simon 1962) has shown that natural or social systems which evolve via a series of stable “hierarchical intermediate forms” will be more successful and resilient to environmental change.

Thus, it is often true that the environment in which a particular system sits and the elements of that system can themselves be considered as open systems. It can be useful to consider collections of related elements as both a system and a part of one or more other systems. For example, a “holon” or system element was defined by Koestler as something which exists simultaneously a whole and as a part (Koestler 1967). At some point, the nature of the relationships between elements within and across boundaries in a hierarchy of systems may lead to complex structures and emergent behaviors which are difficult to understand or predict. Such complexity can often best be dealt with not only by looking for more detail, but also by considering the wider open system relationships.

Figure 1: General description of System Context (SEBoK Original)

A system context describes all of the external elements which interact across the boundary of a particular System of Interest (SoI) and a sufficient view of the elements within its boundary, to allow the SoI to be fully understood as part of a wider systems whole. To fully understand this we also need to identify the environment in which the SoI and wider system sit and the systems in the environment which influence them.

Many man-made systems are often designed as networks and hierarchies of related system elements to achieve desirable behaviors and the kinds of the resilience seen in natural systems. While such systems can be deliberately created to take advantage of system properties such as holism and stability, they must also consider system challenges such as complexity and emergence. A set of context views for a SoI over its life can help enable this understanding.

Engineered Systems and Systems Engineering

Systems engineering literature, standards and guides generally refer to “the system” to characterize a socio-technical system with a defined purpose as the focus of SE, e.g.

• “A system is a value-delivering object” (Dori 2002).
• “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 International Council on Systems Engineering Handbook (INCOSE) (INCOSE 2012) generalizes this idea, defining 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." While these definition covers the socio-technical systems created by SE we should also consider the natural or social problem situation in which these system sits, the social systems which developed, sustained and used them, and the commercial or public enterprises in which these all sit as systems (Martin 2004).

Hence, while many SE authors talk about systems and systems ideas they are often based on a particular world view which related to engineered artifacts. It would also be useful to take a broader view of the context in which these artifacts sit, and to consider through life relationships as part of that context. To help promote this the SEBoK will try to be more precise with its use of the word system, and distinguish between general systems principles and the specific systems created by SE. The term socio-technical system is used by many in the systems community and may have meanings outside of that relevant to SE. Hence, we will define an engineered system as a system context in which a socio-technical system forms the primary focus or system of interest (soi) , considered across the whole of its life cycle , from initial problem formulation through to its final safe removal from use (INCOSE 2012).

Open systems are a useful way to understand many complex situations. Traditional engineering disciplines have become very good at building up detailed models and design practices to deal with the complexity of tightly integrated collections of elements within a technology domain and it is possible to model the seemingly random integration of lots of similar elements using statistical approaches. Systems Engineering makes use of both these aspects of system complexity, as discussed in the Complexity article in Part 2. It also has a focus on the complexity of relatively small numbers of elements taken from a range of design disciplines together with people who may not always be experienced or have detailed training in their use. Such engineered systems may be deployed in uncertain or changing environments and be used to help people achieve a number of loosely defined outcomes. For these systems relatively small changes in the internal working of their elements, or in how those elements are combined, may lead to the emergence of complex or un-expected outcomes. It can be difficult to predict and design for all such outcomes during an engineered systems creation, or to respond to them during its use. Iterative life cycle approaches which explore the complexity and emergence over a number of cycles of development and use are needed to deal with this aspect of complexity.

Life Cycle and Engineered System Context

An engineered system life cycle context describes the context of a SoI such that the necessary understanding can be reached and the right systems engineering decisions can be made across the life of that SoI. This will require a number of different views of the context across a life cycle, both to identify all external influence on the SoI and to guide and constraint the systems engineering of the elements of the SoI. The kinds of views which can be used to represent a SoI context over its life and how those views can be combined into models is discussed in Systems Approach to Modelling, The activities which use those models are described conceptually in the Systems Approach to Engineered Systems Knowledge Area in part 2 and related to more formal SE life cycle processes in part 3.

To set the foundations of this in Part 2 a general description of life cycle context is given below. This will include some specializations of engineered system contexts to provide a link between systems principles and concepts and engineering and business life cycle practice. To define a general life cycle context we must first define some types of life cycle

Figure 1: Life Cycle Terminology

In the above figure the capability needed to enable an enterprise to achieve its goals is delivered by the synchronized use of services. Those services are provided by service system which are created, sustained and deployed by one or more organisations . A service system is composed from people, technology, information, and access to related services and other necessary resources. Some of these resources are provided by enabling services and the technological elements may be developed and supplied as product systems. An enterprise system describes a collection of related capabilities and associated services which together enable the achievement of the overall purpose of an enterprise as a government, business or societal entity. Measurement and review of enterprise goals may define needs for change which require an organisation to acquire or modify, and integrate the elements needed to evolve its service systems. The specialized terminology above is described briefly in the associated glossary definitions and expanded in related articles in Part 2.

The figure below gives a general view of the full context for any potential specialist application of a SE life cycle.

Figure 2: General Life Cycle Context

In this view a service system related directly to a capability need sets the overall boundary. This need establishes the problem situation or opportunity which encapsulates the specific starting point of any life cycle. Within this are the related and enabling services and products and people needed to fully deliver the solution to that need. The environment includes any people, organisations, rules or conditions which influence or constrain the service system. This complete solution sets the context for any specific SE life cycle outputs. The SoI for a particular SE life cycle may be defined at any level of this general context. This can include technology focused elements embedded within one or more products, integrated technology products used directly to help provide a service, focused enabling services supporting multiple service systems or service systems created and sustained to directly deliver capability.

All SE life cycle should be based on some representation of this general context view, what will vary is which parts of the environment which must be considered, which parts of the context form the fixed specification of the problem, which parts may be changed by negotiation with related organisations and enterprises and which within the SoI boundary and under the design and integration authority of the life cycle directly. The concept of a System of Systems context also part of the SE knowledge. In terms of the general description above this would apply to any life cycle context in which elements within the SoI have independent life cycle relationships. This concept could apply to any of the life cycle contexts above and will add additional activities to the SE needed within them.

A real SE life cycle typically combines different aspects of these specialized views into a unique problem and solution context which must be identified by that life cycle as part of its SE activities. More details of these different specialized life cycle contexts are given in part 2 and how these apply to SE practice is expanded in Part 4.

A good example of a general description of the above is given by Ring (ref), who defines the overall context as the Problem Suppression System, and describes a cycle by which an enterprise will explore its current needs, use these to identify one or more life cycle interventions, relevant organisations then conduct and deliver those life cycles, integrate their outputs into the PSS, the enterprise can then review the results in the environment and begin the cycle again. This general systems approach is described in part 2 and used as a focus to identify areas of foundational knowledge. The current practices of SE described in the rest of the SEBoK make reference to these foundations as appropriate.

References

Works Cited

Bertalanffy, L. von. 1968. General System Theory: Foundations, Development, Applications, rev. ed. New York: Braziller.

Boardman, J. and B. Sauser. 2008. Systems Thinking: Coping with 21st Century Problems. Boca Raton, FL, USA: Taylor & Francis.

Checkland, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: Wiley and Sons, Inc.

Dori, D. 2002. Object-Process Methodology – A Holistic Systems Paradigm. Verlag, Berlin, Heidelberg, New York: Springer.

Hitchins, D. 2009. “What Are the General Principles Applicable to Systems?” INCOSE Insight, 12(4): 59-63.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

Johnson, R.A., F.W. Kast, and J.E. Rosenzweig. 1963. The Theory and Management of Systems. New York, NY, USA: McGraw-Hill Book Company.

Koestler, A. 1990. The Ghost in the Machine, 1990 reprint ed. Penguin Group.

Martin, J, 2004. "The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems". Proceedings of the 14th Annual International Council on Systems Engineering International Symposium, 20-24 June, 2004, Toulouse, France.

Miles, R.F. (ed). 1973. System Concepts. New York, NY, USA: Wiley and Sons, Inc.

M’Pherson, P.K. 1974. "A perspective on systems science and systems philosophy". Futures. 6(3):219-39.

Simon, H.A. 1962. "The Architecture of Complexity." Proceedings of the American Philosophical Society. 106(6) (Dec. 12, 1962): 467-482.

Primary References

Bertalanffy, L., von. 1968. General System Theory: Foundations, Development, Applications, rev. ed. New York, NY, USA: Braziller.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

Additional References

Hybertson, Duane. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Boca Raton, FL, USA: CRC Press.

Hubka, Vladimir, and W. E. Eder. 1988. Theory of Technical Systems: A Total Concept Theory for Engineering Design. Berlin: Springer-Verlag.

Laszlo, E., ed. 1972. The Relevance of General Systems Theory: Papers Presented to Ludwig von Bertalanffy on His Seventieth Birthday. New York, NY, USA: George Brazillier.

---

< Previous Article | Parent Article | Next Article >SEBoK v. 1.9.1, released 12 October 2018