It may be argued that Systems Engineering has been employed ever since mankind started building and developing complex systems. It could also be said that the pyramids in ancient Egypt are examples of complex systems, along with simple stone structures, such as henges, which may actually form part of a larger astrological system. Furthermore, mankind has observed complex systems such as the Solar System since the ancient Greeks first observed the motion of the planets and created the model of the geocentric universe.

In more recent times, the term Systems Engineering may be traced back to the early part of the 20^th century in Bell Laboratories in the USA (Fagen, 1978). Examples of Systems Engineering may be observed in the Second World War, and the first attempt to teach Systems Engineering is claimed to have been in 1950 at MIT (Hall, 1962).

The 1960s saw the formulation of the field of study known as systems theory, which was first postulated by Ludwig von Bertalanffy (Bertalanffy, 1968) as “general systems theory.”

The main tenet of systems theory is that it is a conceptual framework based on the principle that the component parts of a system can best be understood in the context of the relationships with each other and with other systems, rather than in isolation (Wilkinson, 2011). This is essential for all Systems Engineering as it means that elements in a System, or the systems themselves, are never considered by themselves but in relation to other elements or systems.

As systems became more complex, the need for a new approach to developing systems became more prevalent. Throughout the latter part of the 20th century, this need grew until it reached the point, in 1990, at which the National Council on Systems Engineering (NCOSE) was founded in the USA. Since then, this organization has evolved into the International Council on Systems Engineering (INCOSE), founded in 1995, which is the world’s foremost authority on Systems Engineering and has over 70 chapters throughout the world.

Today, as the Complexity of the world that we live in and the systems that are being developed are increasing at an ever-expanding rate, there is an increased need for approaches that are rigorous and robust and can cope with these high levels of Complexity. Systems Engineering is such an approach.

When considering Systems Engineering as a topic, it is important to understand exactly what is meant by the key terms that are being used. One aspect of all engineering (and all other professions, for that matter) that will emerge from this book very quickly is that there is seldom a single, definitive definition for any term. This creates a potential problem as communication, as will be discussed later in this chapter, is key to successful Systems Engineering.

In order to address this potential problem, this chapter will introduce, discuss, and define specific concepts and their associated terminology that will be used throughout the book. This will enable a Domain-Specific Language to be built up, which will then be used consistently throughout this book. Wherever possible and appropriate, the terminology adopted will be based on international best practices, including standards such as ISO 15288 (ISO, 2015), to ensure the provenance of the information presented here.

Defining a System

The first concept that will be discussed is that of a System. A System will be defined in different ways by different people, depending on the nature of the System. So, first of all, some types of Systems will be identified to illustrate some of the typical types of Systems that may be encountered in Systems Engineering.

There are many different classifications, or taxonomies, of Systems and one of the more widely accepted classifications is the one defined by Peter Checkland (Checkland, 1999), which is illustrated in the following diagram:

Figure 1.1: Checkland’s five types of System

The diagram in Figure 1.1 shows Checkland’s five types of generic Systems, which are as follows:

• Natural Systems, which represent open Systems whose characteristics are beyond the control of humans. Such Systems include weather systems, nature, the environment, time, and so on.
• Designed Physical Systems, which represent what most people would immediately think of when considering a System, such as smartphones, tablets, helicopters, cars, trains, planes, spaceships, boats, TVs, cameras, bridges, computer games, satellites, and even domestic appliances. The list is almost endless. The Systems will typically consist of physical artifacts that represent the real-world manifestation of the System.
• Designed Abstract Systems, which represent Systems that have no physical artifacts but that are used by people to understand or explain an idea or concept. Examples of such Systems include models, equations, thought experiments, and so on.
• Human Activity Systems, which are people-based Systems that can be seen or observed in the real world. These Systems will typically consist of different sets of people interacting to achieve a common goal or purpose. Examples of such Systems include a political system, social groups, people-based services, and so on.
• Transcendental Systems, which are Systems that go beyond our current understanding. Examples of such systems include deities, unknown problems, and Numberwang.

This is a good set of classifications, which we will use as a reference in this book. These classifications are a good way to think about different types of Systems, but the important point to understand here is that we can apply Systems Engineering to all five of these different categories of Systems.

Also, it should be kept in mind that it is possible to have systems that actually fit into more than one of these categories. Imagine, for example, a transport system that would have to take into account vehicles (Designed Physical Systems), operating models (Designed Abstract Systems), the environment (a Natural System), and a governing political system (a Human Activity System). In real life, the Complexity of Systems is such that it is typical, rather than unusual, to encounter examples of these Systems that can fit into multiple categories.

Characteristics of a System

The five different broad types of Systems have been introduced, but there is also a common set of characteristics that may be associated with all of these types of systems. These characteristics allow the Systems to be understood and developed. Let’s explore these in the following sections.

System elements – characterizing System structure

Any system will have its own natural structure and may be thought of as a set of interacting System Elements, as shown in the following diagram:

Figure 1.2: Basic structure of a System – System Elements

The diagram in Figure 1.2 shows that a System is made up of a set of system elements and that there are two types of Systems: a System of Interest and an Enabling System. A System of Interest refers to a System that is under development, whereas an Enabling System refers to any System that has an interest in, or interacts with, a System of Interest.

One point to note here is that the structure of the System is actually more complex than this, as a System Element itself may be broken down into lower-level System Elements, which will lead to a System hierarchy of several levels being identified for a specific System. For the purposes of this initial discussion, the number of levels will be kept low in order to keep the explanations simple. Later in this book, when Systems are discussed in more detail, examples of hierarchies that span multiple levels will be considered.

The next key point for discussion here is that System Elements interact with other System Elements. This is a key concept in understanding true Systems and applying Systems Engineering. When considering any System, or System Element, it is important to understand that they will interact with other System Elements, rather than existing in isolation. In Systems Engineering, everything is connected to something else and so understanding the relationships between System Elements, which form the basis of the interactions between them, is just as important as understanding the System Elements themselves.

The interactions between System Elements also allow interfaces to be identified and defined between them. Understanding interfaces between System Elements is crucial to be able to specify and define all types of Systems. As part of understanding interfaces, it is also necessary to understand the information or the material (anything that is not information) that flows across the interfaces.

System structures and interfaces will be discussed in far more detail in Chapter 3, Systems and Interfaces.

Stakeholders – characterizing who or what has an interest in the system

One of the key aspects of a System that it is essential to understand as part of any Systems Engineering endeavor is the Stakeholders that are associated with the System, as shown in the following diagram:

Figure 1.3: Defining who or what has an interest in the System – Stakeholders

The diagram in Figure 1.3 shows that a Stakeholder has an interest in the System. Understanding Stakeholders is key to successful Systems Engineering, and the definition of a Stakeholder is the role of any person, organization, or thing that has an interest in the System.

There are a number of subtleties associated with understanding Stakeholders:

• When considering Stakeholders, it is the role of the Stakeholder that is of interest, not the name of the person, organization, or thing that is associated with it. For example, consider a person, named Jon, who owns a car.

The person, Jon, is not a Stakeholder associated with the car; rather, the Stakeholder is the role that Jon plays when interacting with the car. So, in this example, Jon will play a number of Stakeholder roles, such as owner, driver, passenger, sponsor, maintainer, and so on. Each of these Stakeholder roles will view the System of the car in different ways. It is important, therefore, that rather than thinking about Jon, the person, we should consider the Stakeholder roles that Jon plays.

• Stakeholders are not necessarily people and can be many other things, such as organizations or just about anything. For example, when considering the System of the car, the Stakeholder role of the owner could be taken on by the person, Jon, but it may be a company car that is owned by a business, in which case it is the organization that takes on the Stakeholder role, rather than the person. Equally, the law has an interest in the car, which means that the law is also a Stakeholder.
• There is not a one-to-one correlation between Stakeholders and the person, organization, or thing that takes on the role. For example, it has already been shown that a single person, Jon, may take on multiple Stakeholder roles but, equally, it is possible for many people to take on the same Stakeholder role. Consider the passengers that travel in the vehicle along with the driver. In this situation, we may have several people all taking on the same Stakeholder role of passenger.
• Stakeholders lie outside the Boundary of the system, as do Enabling Systems. With the definition of a Stakeholder being anything that has an interest in the System, then it follows that an Enabling System is actually just a special type of Stakeholder, as the basic definition is the same.

Identifying Stakeholders is an essential part of Systems Engineering as Stakeholders will each look at the same system in different ways, depending on the Stakeholder role that they play. This leads to the important concept of Context, which will be discussed in more detail later in this chapter.

Attributes – characterizing system properties

It is possible to describe the high-level properties of any given system by identifying a set of Attributes, as shown in the following diagram:

Figure 1.4: Describing properties of a System – Attributes

The diagram in Figure 1.4 shows that Attributes describe a System. Attributes are shown here as relating to the concept of the System but, bearing in mind that a System comprises a number of System Elements, these Attributes may also apply to the System Elements.

These Attributes will typically be represented as nouns that may take on a number of different values and be of a specific, pre-defined type, and may also have specific units. Examples of simple types of Attributes could be as follows:

• Dimensions, such as length, width, and height, which would be typed as real numbers and may have units of millimeters associated with them.
• Weight, which would be typed as a real number and have the unit of kilograms associated with it.
• Element number, which may be an integer and may not have a unit associated with it.
• Name, which may be a character/text and may not have a unit associated with it.

Attributes may also take on more complex types, for example:

• Timestamp, which may be a set of simple types brought together to provide a more complex type. In this case, the timestamp may be a combination of the day (an integer between 1 and 31), month (an integer between 1 and 12), year (an integer ranging from 0,000 upward), hour (an integer between 1 and 24), minute (an integer between 0 and 59), and second (an integer between 0 and 59).
• Data structures, which may represent an entire audio or video file that complies with a specific protocol, such as MP3, MP4, and so on.

The full set of possible Attributes is almost limitless, so the list provided here is intended to provide food for thought rather than be any sort of comprehensive list.

Boundaries – defining the scope of a System

Each System will have at least one Boundary associated with it, which helps to explain the scope of the System, as shown in the following diagram:

Figure 1.5: Defining the scope of a System – Boundary

The diagram in Figure 1.5 shows that the Boundary defines the scope of the System.

There are many types of Boundary that may exist, including the following:

• Physical Boundary: This may be some sort of enclosure that surrounds the System and separates it from the outside world. This could be a cabinet that houses a number of System Elements, such as the body of a car, a barrier that surrounds a piece of land, a wall and doors that define a room, and so on.
• Conceptual Boundary: This is a non-Physical Boundary that can be imagined but not necessarily observed. An example of this is the Boundary between a car and the GPS satellite that it interacts with. In this case, where is the Boundary of the System considered to be? Is it the transmitter and receiver in the car, the transmitter and receiver on the satellite, the waves that are transmitted, or the protocols that are used as part of the transmission?
• Stakeholder Boundary: Different Stakeholders may look at the same System in different ways and, therefore, where they perceive the Boundary of the system to be may change depending on the Stakeholder. Consider again two different Stakeholders for a car. A passenger may consider the Boundary of the car as being the physical body, or the shell of the car, whereas the maintainer of the car may also consider the Conceptual Boundary of the link between the car and the satellite as the Boundary.

The Boundary of a System allows a number of key aspects of the System to be understood:

• What is inside the Boundary: It is important to understand which System Elements are considered to be inside the Boundary of the System and which are considered to be outside the Boundary of the System. System Elements that are considered inside the Boundary of the System will help to define exactly what the scope of the System is.
• What is outside the Boundary: In the same way that understanding what is inside the Boundary is important, in terms of System Elements, it is also important to understand what lies outside the Boundary of the System. Things that exist outside the Boundary of the System are considered to be either Stakeholders or Enabling Systems, or as was discussed previously, both.
• Where key interfaces exist: Every time an interaction occurs across the Boundary of a System, it identifies an interface to that System. Identifying interfaces is an important part of Systems Engineering, and a Boundary can be used to identify all interfaces between a System and the outside world.

Bearing in mind these discussion points, defining the Boundary of a given System may not be as simple as it first appears, as different Stakeholders may identify different Boundaries. This is not necessarily a problem, but it is important to bear this in mind and ensure that no conflicts occur because of these differences.

Needs – the purpose of the System

Each System must have a purpose, and this purpose is expressed by defining a set of Needs, as shown in the following diagram:

Figure 1.6: Defining the purpose of the System – Needs

The diagram in Figure 1.6 shows that Needs describe the purpose of the System. A Need describes the concept of something that shows the purpose of the System. The diagram also shows that there are different types of Needs, three of which are listed here:

• Requirement: A Requirement represents a statement of something that is desirable for the System to do. These are often related to the desired specific functionality of the System. For example, a Requirement for a car may be that the driver must be able to slow the car down using the brake pedal, the car must have seat belts, or the car must travel at a top speed of at least 100 miles per hour.
• Feature: A Feature represents a higher-level Need of the System that does not necessarily relate to a specific function, but may relate to a collection of functions. An example of a Feature may be that the car must have adaptive cruise control, the car must self-park, or the car must have crash prevention capabilities.
• Goal: A Goal is a very high-level Need that represents a Need of the overall System. An example of this may be to transport a driver and three passengers over a distance of 300 miles on a single charge.

It should be stressed here that there are many different terms used for all aspects of Needs, which differ vastly from organization to organization and from industry to industry. For example, the term “capability” is often used in the aerospace and defense industries, whereas the term “Feature” is more typically used in transport industries, such as automotive and rail. In a way, it does not matter which terminology is adopted, provided that it is adopted consistently.

Constraints – limiting the realization of the System

All Systems will be limited in some way in terms of how they can be realized, and these limitations are referred to as Constraints, as shown in the following diagram:

Figure 1.7: Defining limitations on the realization of the System – Constraints

The diagram in Figure 1.7 shows that Constraints limit the realization of the System. All Systems will have Constraints associated with them that will limit how the System may be realized, and these are often grouped into a number of categories, examples of which are as follows:

• Quality Constraints: In almost all Systems, there will be Constraints that relate to best practice sources, such as standards. It is typical for a number of standards to be identified that the development approach used to deliver the System must comply with. These standards will typically relate to the development processes used to describe the overall Systems Engineering approach. For example, a standard that is often used for cars in the automotive industry is ISO 26262.
• Implementation Constraints: These Constraints will limit the way that the System can be built. This may limit the materials that are used; for example, a car may be limited to being made out of aluminum rather than steel.
• Environmental Constraints: All Systems must be deployed somewhere and many Systems will be defined in a natural environment, which may lead to certain Constraints coming into play. For example, a car may be limited in its emissions in order to minimize the impact on the environment.
• Safety Constraints: Almost all Systems will have Constraints placed on them that ensure that the System can operate in a safe manner, particularly if things go wrong. For example, a car may be required to have functions in place that will protect the driver and passengers in the event of a crash.

The preceding list provides a broad set of categories for different types of Constraints, but it is by no means exhaustive.

It should also be kept in mind that these Constraints can be complex themselves and actually belong to more than one of these categories. For example, a car may have a limitation that all of the materials used must be recyclable, which could place it in both the Environmental Constraints and Implementation Constraints categories.

It should also be pointed out that some of these Constraints lend themselves to different stages of the system life cycle. The system life cycle is an important concept that will be discussed in more detail later in this book.

Constraints are also often described as special types of Needs as they are often represented as being related to specific Needs rather than directly to the System itself. This will be discussed in more detail in Chapter 6, Needs and Requirements, which focuses specifically on Needs.

Summary of System concepts

All of the concepts that have been introduced and discussed in this section may now be brought together to provide an overview of how they relate to the concept of a System:

Figure 1.8: Summary of the key concepts associated with a System

The diagram here shows a summary of the key concepts associated with Systems that will be used throughout this book. It is important that these are all well understood as they will all be used from this point forward.

Defining Systems Engineering

There are many definitions of the term Systems Engineering, and there are various publications that discuss many of these and compare and contrast them (Holt and Perry, 2019, and INCOSE, 2018). For the purposes of this book, the main definition that will be used is taken from ISO 15288 (ISO, 2015), which, in turn, is used in the INCOSE Systems Engineering Handbook (INCOSE, 2016), which defines Systems Engineering as:

“The realization of successful systems.”

This is shown pictorially in the following diagram:

Figure 1.9: Basic definition of Systems Engineering

The diagram in Figure 1.9 shows the basic definition of Systems Engineering. This diagram may seem trivial, but it will enable the general term to be related to all of the other concepts that are discussed consequently in this chapter.

This is a simple but effective definition of the term, but there are a few factors that must be kept in mind when reading this description:

• Systems Engineering is a multidisciplinary approach that takes into account all areas of engineering, including mechanical, electrical, civil, software, and so on. Crucially, however, it should also be recognized that Systems Engineering is not just limited to engineering disciplines, but includes many other diverse areas, such as management, mathematics, physics, psychology, and just about any other area!
• Systems Engineering is applied across the entire life cycle of a System and is not restricted to any single stage. This means that Systems Engineering is considered right from the point in time that the very first idea for the System is conceived until the System is ultimately retired. Even when working on a single stage, it is important that all stages of the life cycle are considered.
• Systems Engineering does not remove the need for intelligence, as systems engineers must never blindly follow instructions, and requires a healthy dose of common sense in order to be effective.

With these considerations in mind, the initial definition may be expanded upon to be redefined as (Holt and Perry, 2007):

Systems Engineering is a multi-disciplinary, common-sense approach that enables the realization of successful systems.

Now the definitions have been established, it is necessary to understand why Systems Engineering is needed in the first instance.

The need for Systems Engineering is actually very simple. In real life, it is very easy for things to go wrong. Projects overrun, airplanes fall out of the sky, the environment is damaged, people are hurt or killed, software and IT bring organizations to their knees, and whole societies are crippled by non-joined-up government and management, all of which are the result of system failures at one level or another.

Since it is so easy for things to go wrong, it is important to understand why. Fundamentally, there are three main causes for such System failures, which are as follows:

• Complexity, where Complexity is not identified and, therefore, cannot be managed or controlled.
• Communication, where communication fails or is ambiguous.
• Understanding, where different points of view are not taken into account, and assumptions are made.

The problem is actually worse than this as these three main causes feed into one another, so unmanaged Complexity will lead to communication failure and a lack of understanding, communication failure will lead to Complexity and a lack of understanding, and a lack of understanding will lead to increased Complexity and communication problems (Holt, 2001).

These three causes are often referred to as the “Three Evils of Systems Engineering” and each will be discussed in more detail in the following sections.

Complexity

Complexity exists in every system and may be thought of as being one of two types, as shown in the following diagram:

Figure 1.10: Types of Complexity

The diagram in Figure 1.10 shows that Systems manifest Complexity. There are two main types of Complexity:

• Essential Complexity is the natural Complexity that is inherent in the system. The term “Essential” is used here as it refers to Complexity that manifests in the essence of the System. It is not possible to lower the Essential Complexity of a System, but it is possible to manage and control this Complexity, provided, of course, that it has been identified in the first instance.
• Accidental Complexity is not natural and is introduced by inefficiencies in the people, processes, and tools that are employed to implement Systems Engineering, which will be discussed later in this chapter. Accidental Complexity can certainly be lowered, and this forms a natural part of Systems Engineering.

Complexity manifests itself in the relationships between things, whether these are between the System Elements that make up the System or between Systems themselves. There are many subtleties to Complexity, which will be discussed in more detail in the following sections.

An example…

In order to illustrate and, therefore, understand how Complexity has changed and evolved over the last few decades, a simple example of a System will be introduced, which will be used throughout this book to explain the various concepts and techniques that will be used as part of the overall approach to Systems Engineering.

For this example, the System that will be considered is a motor car, so now consider two such cars: one that was developed and built 50 years ago, around 1970, and one that was developed and built in the modern age, around 2020.

Consider the basic Need for the System. The purpose of any car is to transport a number of people from point A to point B. The user interface of the car is, basically, a steering wheel, gear stick, and three pedals (accelerator, brake, and clutch pedals).

This basic Need, or purpose, of a car has not really changed over the last 50 years, but the point of discussion here is that the complexity of the car has changed in four different ways, which will be discussed in turn in the following sections.

The Complexity of the System Elements

In order to illustrate how the Complexity of the System Elements has changed over the last 50 years, each of the cars will be discussed separately and then compared and contrasted:

Figure 1.11: Basic breakdown of a car

The diagram in Figure 1.11 shows a simple example System of a car. There are four System Elements at the next level down that make up the car, which are as follows:

• The Body, which includes lower-level System Elements such as wings, doors, mirrors, and so on.
• The Chassis, which includes lower-level System Elements, such as brakes, wheels, suspension, and so on.
• The Interior, which includes lower-level System Elements such as seats, dashboard, controls, and so on.
• The Drive Train, which includes lower-level System Elements such as the motor and the gearing.

The System Elements that make up the 50-year-old car are entirely mechanical and electrical in nature. On top of this, almost all of the System Elements will be mechanical; very few of them will be electrical.

Electrical System Elements will be limited to the lights, indicators, fan, wipers, and starter motor, and that is really the extent of the electrical System Elements. The mechanical elements, however, will make up all of the other System Elements that relate to the Body, Chassis, Drive Train, and Interior. The vast majority of the System Elements, therefore, are mechanical with only a handful of them being electrical. This means that almost all of the interfaces between the System Elements will be mechanical in nature, with only a few being electrical or electro-mechanical.

In order to build this car, it is largely a matter of integrating self-contained System Elements that have well-defined interfaces. Also, any electrical connections will require quite simple point-to-point wiring.

Now consider the modern car. There are two new major types of System Elements that now exist that did not exist at all on the 50-year-old car, which are electronic and software-based System Elements. The vast majority of System Elements in a modern car will fall into one of these two categories. Electronic System Elements will include the following:

• Controllers (such as light controllers, indicator controllers, and so on)
• Sensors (such as temperature, pressure, rotation, and so on)
• Actuators (such as levers, small gears, motors, and so on)
• Display elements (such as dashboard lights, audio alerts, and so on)

All modern cars contain a vast amount of software and, in every case, this software will be split across multiple nodes across the whole vehicle. On top of the software itself, the software must be connected to its associated electronic components, which will, in turn, lead to the need for communication buses, such as Controller Area Networks (CANs), which will themselves use communication protocols.

In order to build the modern car, it is no longer a matter of simply integrating System Elements because the interfaces between the elements are now far more complex and will involve subtle changes in voltage and current levels, data transfer, communication protocols, and complex wiring.

The complexity of the System Elements that make up the car has, therefore, greatly increased between the two vehicles. Indeed, not only has it increased in terms of the number of System Elements but also in their nature.

The Complexity of Constraints

It has already been stated that the basic Need for a car has not really changed at a high level in the last 50 years. The basic Need is to transport people from point A to point B. In the past, the emphasis of most cars was to make them go as quickly as possible with little regard for anything else. One of the major things that has changed over the last 50 years is not necessarily the basic needs, but the Constraints that are now imposed on those Needs:

Figure 1.12: Simple Constraints

The diagram in Figure 1.12 shows a simple Need that is named Develop car, and there are two main Constraints associated with this, which are Be safe and Be fast. This diagram here represents, at a very high level, the basic Needs and Constraints associated with the 50-year-old car.

The number of Constraints associated with the older car is very small compared to that of the modern car, which is shown in the following diagram:

Figure 1.13: Complex constraints

The diagram in Figure 1.13 shows the Constraints associated with the modern car. The first thing to notice when comparing the two sets of Constraints is that the number of Constraints themselves has increased dramatically. There are new sets of Constraints that simply did not exist in the older car; for example, Be secure is now an issue that was not really a main consideration previously. Likewise, there is a whole set of new Constraints associated with Provide a positive driving experience. This increase in the number of Constraints will lead to an increased number of relationships between the basic Needs and Constraints, which will naturally lead to an increase in the Complexity of the Needs and Constraints.

It is not just the increase in the number of Constraints that leads to an increase in Complexity but also the Complexity of individual Constraints has increased. There are a number of Constraints now that are related to best-practice models, such as Comply with standards and Comply with legislation. This is interesting from a Complexity point of view as these Constraints will also relate directly to other Constraints. Consider Be safe, which was previously seen as a standalone Constraint. In the modern vehicle, this Constraint will also have both of the compliance Constraints associated with it. Since there are far more legislation and standards in place now that apply to cars that did not exist 50 years ago, the Complexity of individual Constraints has increased, along with the increase in dependencies between Constraints.

The Complexity of a System of Systems

Another area where the car has increased in Complexity over the last 50 years occurs when a higher-level System of Systems is considered. A System of Systems is not just a collection of interacting Systems; it is a collection of interacting Systems exhibiting some behavior that is not exhibited by any of its Constituent Systems. Therefore, it can be argued that a fleet of vehicles is not a System of Systems, as it is simply a collection of Systems that does little more than make the overall System slightly more complicated. A true higher-level System of Systems may be the transport network that a car forms part of. The overall transport System of Systems exhibits a number of behaviors, such as ensuring an efficient journey from end to end, keeping traffic moving when accidents occur, and providing seamless links with smart cities and other transport systems, such as rail.

A modern car is now truly part of a System of Systems as the vehicle itself interacts with other Systems, such as smart cities, smart roads, the cloud, satellites, and so on, which did not occur with an older vehicle. The modern car also takes over some of the skills that were previously the sole domain of the driver, such as parking, maintaining constant speeds, identifying potential dangers, and so on.

The Complexity of the car System has therefore increased due to the fact that the car is now truly part of a wider System of Systems.

Complexity shift

The final aspect of increased Complexity that will be discussed does not necessarily manifest as an increase in the same type of Complexity but, rather, represents a shift in Complexity due to increases in other aspects of Complexity.

Consider again the older car and its motor. The motor in the 50-year-old car is an internal combustion engine, which mainly comprises mechanical System Elements with a handful of electrical System Elements. The internal combustion engine may be considered to have quite a high level of mechanical Complexity, which is naturally exhibited.

Now consider a modern electric car. The motor in the modern electric car is an electric motor that has a single moving part, that of the motor shaft. The mechanical Complexity of the modern car is practically non-existent when compared with the older car. The Complexity of the modern car lives mainly in the software that monitors the rest of the car and controls the electric motor. There is no software whatsoever in the older car.

The older car, therefore, has high mechanical Complexity and zero software Complexity. The modern car has very low mechanical Complexity and very high software Complexity.

The Complexity in the modern car has therefore shifted in nature – in this case, away from mechanical Complexity and toward software Complexity.

Bringing it all together

It can be seen that the Complexity of a typical System has increased dramatically over the last few decades. In the example we have used, the car increases in Complexity for four different reasons, which have been discussed.

This increase in Complexity does not apply just to automotive systems but to any and all types of Systems. In reality, these four types of increased Complexity will actually have interdependencies, which, in turn, will also increase the overall Complexity. For example, the increase in the Complexity of the System Elements will also lead to a complexity shift and, potentially, an increase in the System of Systems Complexity, which, in turn, will lead to an increase in the number of Constraints.

Identifying Complexity

The key to managing Complexity is identifying where the Complexity lives in a System. This is a topic that will be followed up throughout the book, particularly when artifacts and models are discussed.

The next section discusses the problems associated with communication, which, alongside Complexity and understanding, is one of the Three Evils of Systems Engineering.

Communication

Communication is key to successful Systems Engineering. It has already been discussed that Systems Engineering naturally brings together people from multiple and disparate backgrounds, which will lead to an increase in potential communication problems. Poorly-specified information, Language, and protocols lead to ambiguity, which will lead to poor or inefficient communication.

Communication can exist at many levels, such as the following:

• Between people: The obvious form of communication is between people. People interacting with other people is key to any successful project and is a matter that is more complex than it first appears, as will be discussed in this section.
• Between and within organizations: A successful business relies on different organizations or organizational units within the same company being able to communicate effectively. The media for these communications may be through documents, agreements, contracts, and so on but the same communication problems will occur.
• Between and within Systems and System Elements: It is essential that the Systems that are relied upon for our business and projects can also communicate effectively. This includes IT systems, other technical systems, and service-based systems, to name but a few.

When thinking about communication, another way to think about it is that communication must be effective and efficient between all Stakeholders, whether they are represented by people, organizations, or things (such as Systems). When considering communication in the world of Systems Engineering, it is inter-Stakeholder communication that is being addressed.

These communication problems are further compounded by the fact that communication can also exist between these different types, such as between people and Systems, people and organizations, and so on.

Defining common Languages

One of the main solutions that is vaunted for improving communication is to get all parties to “speak a common Language.” This is an obvious solution and an important one, but speaking a common Language is actually more complex than it may at first appear.

When considering a common Language, there are actually two types of Language that must be defined, as shown in the following diagram:

Figure 1.14: Aspects of the common Language

The diagram in Figure 1.14 shows that Stakeholders communicate using a Language, so it is essential that this Language is as clear and unambiguous as possible. This Language, however, has two aspects: Spoken Language and Domain-Specific Language.

The first aspect that will be considered is that of the Spoken Language, which provides a basic mechanism for communication. An example of Spoken Language is the fact that this book is written in the English Language. In order to understand the information in this book, it is essential that the reader can speak English. Clearly, there are many more spoken Languages than the English Language, but the decision that has been made for this book (or System) was to select English as the chosen Spoken Language. This is clearly an obvious decision that needs to be made, but just because everyone reading this book speaks English does not mean that there will be no ambiguity or misunderstandings. This is because the second aspect of Language that needs to be considered is Domain-Specific Language.

Domain-Specific Language defines the specific concepts and terminology that will be used for a given application or domain. For example, consider the word “function.” The word “function” is a common English Language word but a word that will actually take on different meanings, depending on which Stakeholder is reading it.

It is essential that the Domain-Specific Language is defined, as it forms the cornerstone for successful Systems Engineering. This chapter actually defines the Domain-Specific Language for Systems Engineering that is used throughout this book. Each diagram in this chapter contributes toward defining the full set of concepts and the associated terminology that is used for Systems Engineering in this book.

Languages for Systems Engineering

When it comes to Languages that can be used for Systems Engineering, both the Spoken Language and the Domain-Specific Language must be defined:

• In terms of the Spoken Language, there are several standard Languages that can be adopted that are used throughout the industry across the world, such as the Unified Modeling Language, Systems Modeling Language, and Business Process Modeling Notation, among others. For the purposes of this book, the Spoken Language that has been selected is the Systems Modeling Language (SysML), which will be discussed in more detail in Chapter 2, Model-Based Systems Engineering.
• In terms of the Domain-Specific Language, this will be different for every organization. A generic Domain-Specific Language for Systems Engineering is defined in this chapter and used throughout this book, and may be used as a basis for readers to use in a Language that fits their specific business.

Both types of Language must be defined for successful Systems Engineering.

The next section discusses the problems associated with understanding, which, alongside complexity and communication, is one of the Three Evils of Systems Engineering.

Understanding

It is essential that all Stakeholders share an understanding of the System; however, different Stakeholders will perceive the System in different ways due to their different backgrounds and knowledge, which creates a potentially large problem. This problem may be addressed by considering the concept of “Context.” In order to understand the concept of Context, consider a set of generic Stakeholders, as shown in the following diagram:

Figure 1.15: Generic set of Stakeholders

The diagram in Figure 1.15 shows a generic set of Stakeholders associated with the car System.

There are three broad categories of Stakeholder, which are as follows:

• Customer, which represents the set of roles that will ultimately benefit from the System that is being developed. The diagram here shows that Customer has two types, which are User, such as the Driver of the vehicle, and Operator, such as the Maintainer of the vehicle.
• External, which represents the set of roles that have an interest in the System that will limit or restrict the system in some way. The diagram here shows that there is a single type of External Stakeholder, which is Standard.
• Supplier, which represents the set of roles that are interested in developing and delivering the Systems, such as Engineer.

The identification of Stakeholders is an essential part of Systems Engineering, as it is this complete set of Stakeholders whose expectations need to be understood and managed, rather than just the end user of the System.

When considering the complete set of Stakeholders, it should be kept in mind that different Stakeholders may look at the same System and perceive different Needs or, as in almost all Systems, they may look at the same Need and interpret it in a different way, depending on their point of view. When something is interpreted in a different way from a different point of view, this is referred to as a “Context.”

The concept of Context is one of the single most important aspects of representing a System that must be understood for successful Systems Engineering, yet is one that is often overlooked or ignored altogether.

In order to illustrate this crucial concept of Context, imagine that there is a statement of Need associated with a System, which is the System must be safe. At first glance, this may seem like a straightforward statement with little or no room for ambiguity, but the actual meaning of this statement will be different for each of the different Stakeholders. For example, from the point of view of the Driver, this statement may be interpreted as the car must have seatbelts, airbags, driver-assist technology, and so on. From the point of view of the Maintainer, this statement may mean that the Drive Train must be developed in such a way that the battery can be turned off to ensure that no parts of the car are live when maintaining the vehicle. From the point of view of the Standard Stakeholder, there may be several safety aspects, such as meeting specific requirements for crash impact. Finally, from the point of view of the Engineer, the system may have to satisfy a number of scenarios relating to the safety case for the vehicle.

The point here is that there are multiple interpretations for the same set of Needs. In order to manage the expectations of all Stakeholders, it is important that all of these different points of view, or Contexts, can be understood.

Now that the Three Evils of Systems Engineering have been discussed, it is time to consider the implementation of Systems Engineering

The implementation of Systems Engineering

In order to implement Systems Engineering successfully, there are three aspects of implementation that must be considered, which are shown in the following diagram:

Figure 1.16: The classic systems engineering mantra – People, Process, and Tools

The diagram in Figure 1.16 shows three main concepts: People, Process, and Tools. These are referred to as the Systems Engineering Mantra (Holt and Perry, 2019).

These three concepts are very important, but it is the relationships between them that provide a true understanding of what information is being conveyed. It is important that these People enable the overall Process, as the competencies associated with the People are worth nothing if they do not enable the overall approach. Also, the overall approach must drive the choice of Tools, rather than the Tools affecting the Process.

These concepts are expanded upon in the following diagram:

Figure 1.17: Expanded concepts of People, Process, and Tools

The diagram in Figure 1.17 shows the expanded concepts that were first introduced in Figure 1.16. By considering each of the main concepts in turn, it is possible to enhance the original descriptions:

• People: It is the Competence of the people that is of interest, rather than the presence of the people themselves. It is essential that people have the appropriate sets of knowledge and skills and the attitude that is required to do the task at hand effectively and efficiently. It is also important not to confuse the concept of People with that of Stakeholders. As was discussed previously, People may hold any number of Stakeholder roles and it is the Competence associated with these roles that may be thought of as the ability of the individual.
• Process: It is the overall approach that is being followed, rather than just a set of individual processes. The term Process here may be thought of as the overall ability of the organization or organizational unit to carry out a specific task.
• Tools: The set of software, resources, or, in fact, anything that is intended to allow People to carry out their Process in a more effective or efficient manner. Such Tools may include software design and modeling tools, management tools, pen and paper, standards, notation, and so on.

Overall, it is important that there is a balance between People, Process, and Tools to enable successful Systems Engineering.

This chapter introduced the main concepts and terminology associated with Systems Engineering, which may be thought of as the Domain-Specific Language that will be used throughout this book. This domain-specific Language is captured in all of the diagrams in this chapter. It is important to understand this Domain-Specific Language, so these diagrams must be well understood and the following points considered:

• Each diagram is made up of a series of boxes with words in them that are joined together by lines.
• The main concepts for Systems Engineering are captured in the boxes and the lines between the boxes.
• The terminology for Systems Engineering is what is written inside the boxes and on the lines.

The relevance of these diagrams will be discussed further in the next chapter, in which models and modeling are introduced.

After reading the chapter, you should be able to answer the following questions:

1. Which definition of Systems Engineering works best for you?
2. How do Spoken Language and Domain-Specific Language match the concepts and terminology used in your organization?
3. Can you redefine the terms in each of the diagrams in this chapter to suit your own organization?
4. Can you identify any areas of ambiguity with these concepts in your organization?
5. Can you identify one key System that you work with and some of its characteristics?

• (Wilkinson, 2011) Wilkinson L.A. (2011) Systems Theory. In: Goldstein S., Naglieri J.A. (eds) Encyclopedia of Child Behavior and Development. Springer, Boston, MA.
• (Bertalanffy, 1968) von Bertalanffy, L. 1968. General system theory: Foundations, development, applications. Revised ed. New York, NY: Braziller.
• (Holt, 2001) Holt J., UML for Systems Engineering. 1st edition. Stevenage, UK: IEE; 2001.
• (Holt and Perry, 2019) Holt J., Perry S. SysML for Systems Engineering – a model-based approach, Third edition. Stevenage, UK: IET; 2008.
• (Checkland, 1999) Checkland, P. B. 1999. Systems Thinking, Systems Practice. Chichester, UK: John Wiley & Sons.
• (ISO, 2015) ISO/IEC. ISO/IEC 15288:2015 Systems and Software Engineering – System Life Cycle Processes. 1st edn. International Organisation for Standardisation; 2015.
• (Holt and Perry, 2008) Holt J., Perry S. SysML for Systems Engineering. Stevenage, UK: IET; 2008.
• (INCOSE, 2016) INCOSE. Systems Engineering Handbook – A Guide for System Life Cycle Processes and Activities. Version 4. INCOSE; 2016.

Learn more on Discord

To join the Discord community for this book – where you can share feedback, ask questions to the author, and learn about new releases – follow the QR code below:

https://packt.link/xjBEI