Defining systems engineering

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.