Systems Engineering Demystified E-Book

Jon Holt

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 595

Veröffentlichungsjahr: 2021

Beschreibung

Systems engineering helps us to understand, specify, and develop complex systems, and is applied across a wide set of disciplines. As systems and their associated problems become increasingly complex in this evermore connected world, the need for more rigorous, demonstrable, and repeatable techniques also increases.
Written by Professor Jon Holt – an internationally recognized systems engineering expert – this book provides a blend of technical and business aspects you need to understand in order to develop successful systems. You'll start with systems engineering basics and understand the complexity, communication, and different stakeholders' views of the system. The book then covers essential aspects of model-based systems engineering, systems, life cycles, and processes, along with techniques to develop systems. Moving on, you'll explore system models and visualization techniques, focusing on the SysML, and discover how solutions can be defined by developing effective system design, verification, and validation techniques. The book concludes by taking you through key management processes and systems engineering best practices and guidelines.
By the end of this systems engineering book, you'll be able to confidently apply modern model-based systems engineering techniques to your own systems and projects.

Leseprobe

Systems Engineering Demystified

A practitioner's handbook for developing complex systems using a model-based approach

Jon Holt

BIRMINGHAM—MUMBAI

Systems Engineering Demystified

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Aaron Lazar

Publishing Product Manager: Alok Dhuri

Senior Editor: Storm Mann

Content Development Editor: Tiksha Lad

Technical Editor: Gaurav Gala

Copy Editor: Safis Editing

Language Support Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Shankar Kalbhor

First published: January 2021

Production reference: 1270121

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-83898-580-6

www.packt.com

For Min Dejlide Skildpadde.

– Jon Holt

Packt.com

Subscribe to our online digital library for full access to over 7,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.

Why subscribe?

Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionalsImprove your learning with Skill Plans built especially for youGet a free eBook or video every monthFully searchable for easy access to vital informationCopy and paste, print, and bookmark content

Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.

At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.

Contributors

About the author

Jon Holt is an internationally-recognized expert in the field of model-based systems engineering. He is an international award-winning author and public speaker and has authored 17 books on systems engineering, including a children's STEM book.

Jon currently works for Scarecrow Consultants, holds a Chair in systems engineering at Cranfield University, and is a Fellow of both the IET and the BCS. He is currently the technical director of INCOSE UK and, in 2015, was identified as one of the 25 most-influential systems engineers in the last 25 years by INCOSE.

He is also actively involved in the promotion of STEM where he uses magic, mind-reading, and occasional escapology to promote systems engineering at various festivals.

About the reviewers

Dr Mike Rodd obtained his BSc (Eng), MSc, and PhD from the University of Cape Town. After acquiring some industrial experience, he was appointed professor at the University of the Witwatersrand and then at the University of Wales, Swansea.

His research focuses on industrial applications of real-time distributed computer systems, including the theoretical fundamentals, industrial networking, use of AI techniques, system specification, and machine vision. He has produced 12 books and over 100 papers and has supervised 45 PhD candidates. He was awarded a senior doctorate from the University of Wales.

He has served as an external examiner for many UK and international universities, and as honorary professor at the Universities of Cardiff, Warwick, Penn State, and Cranfield.

Simon Perry holds BSc degrees from both the University of Leeds and the Open University. Since gaining his mathematics degree in 1986, he has spent over 30 years working in all aspects of software and systems engineering. Since 2014, he has been a director and principal consultant for Scarecrow Consultants. He often speaks at systems engineering conferences and is the author of 11 books on systems engineering and related topics. Such public-speaking events, book writing, and the delivery and facilitation of courses and workshops have given Simon great experience in communicating technical concepts to non-domain experts and non-technical audiences.

Packt is searching for authors like you

If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.

Table of Contents

Preface

Section 1: Introduction to Systems Engineering

Chapter 1: Introduction to Systems Engineering

A brief history of systems engineering

Defining systems engineering

Defining a system

Characteristics of a system

Defining systems engineering

The need for systems engineering

Complexity

The complexity of constraints

Communication

Understanding

The implementation of systems engineering

Summary

Questions

References

Chapter 2: Model-Based Systems Engineering

An introduction to MBSE

Abstracting the system

Visualizing the model

Defining the approach

Grouping the MBSE concepts

Implementing the notation

Showing compliance

Using MBSE

The evolution of MBSE

Stage 1 – document-based systems engineering

Stage 2 – document-centric systems engineering

Stage 3 – model-enhanced systems engineering

Stage 4 – model-centric systems engineering

Stage 5 – MBSE

Cross-cutting concerns

Modeling with MBSE

The need for modeling

Defining the model

Two aspects of the model

When and where to model

The spoken language – the Systems Modeling Language (SysML)

What SysML is (and what it is not)

The SysML diagrams

Example structural modeling

Example behavioral modeling

The domain-specific language – the ontology

Understanding the ontology – the cornerstone of MBSE

Visualizing the ontology

Summary

Self-assessment tasks

References

Section 2: Systems Engineering Concepts

Chapter 3: Systems and Interfaces

Defining systems

Demonstrating consistency between the ontology and system hierarchy

Defining the system hierarchy

Defining interaction relationships

Describing interfaces

Identifying interfaces

Defining interfaces

Modeling interfaces

Modeling behavioral views for interfaces

Defining the framework

Defining the viewpoints in the framework

Defining the framework context view

Defining the ontology definition view

Defining the viewpoint relationship view

Defining the viewpoint context view

Defining the viewpoint definition view

Defining the ruleset definition view

Summary

Self-assessment tasks

References

Chapter 4: Life Cycles

Defining life cycles

Defining life cycle concepts

Defining life cycle models

Defining a linear life cycle model

Defining an iterative life cycle model

Defining an incremental life cycle model

Interacting life cycles and life cycle models

Identifying interactions between life cycles

Defining the behavior of interactions

Defining the framework

Defining the viewpoints in the framework

Defining the framework context view

Defining the ontology definition view

Defining the viewpoint relationship view

Defining the viewpoint context view

Defining the viewpoint definition view

Defining the ruleset definition view

Summary

Self-assessment tasks

References

Chapter 5: Systems Engineering Processes

Understanding process fundamentals

Defining process properties

Defining process types

Process concepts

Process modeling

Defining the process context

Defining the process library

Defining the process stakeholders

Defining the process artifacts

Defining the process behavior

Defining a sequence of processes

Modeling standards using process modeling

Identifying systems engineering standards

Modeling ISO 15288

Demonstrating compliance with ISO 15288

Defining the framework

Defining the viewpoints in the framework

Defining the framework context view

Defining the ontology definition view

Defining the viewpoint relationship view

Defining the viewpoint context view

Defining the viewpoint definition view

Defining the ruleset definition view

Summary

Self-assessment tasks

References

Section 3: Systems Engineering Techniques

Chapter 6: Needs and Requirements

Introducing needs and requirements

Defining needs

Visualizing needs using different SysML diagrams

Visualizing source elements

Visualizing need descriptions

Visualizing the context definition

Visualizing contexts

Visualizing scenarios

Life cycle and processes

Defining the framework

Defining the viewpoints in the framework

Defining the Framework Context View

Defining the Ontology Definition View

Defining the Viewpoint Relationship View

Defining the Viewpoint Context View

Defining the Viewpoint Definition View

Defining the Ruleset Definition View

Summary

Self-assessment tasks

References

Chapter 7: Modeling the Design

Defining designs

Architectural design

Detailed design

Defining logical model elements

Defining functional model elements

Defining physical elements

Defining system behavior

Complying with best-practice processes

Complying with the ISO 15288 architecture definition process

Complying with the ISO 15288 design definition process

Defining the framework

Defining the viewpoints in the framework

Defining the framework context view

Defining the ontology definition view

Defining the viewpoint relationship view

Defining the viewpoint context view

Defining the viewpoint definition view

Defining the ruleset definition view

Summary

Self-assessment tasks

References

Chapter 8: Verification and Validation

Defining testing concepts

Modeling verification and validation

Modeling the testing context

Modeling the testing setup

Modeling the testing configuration

Using existing views for testing

Complying with best-practice processes

Complying with the ISO 15288 Verification Process

Complying with the ISO 15288 Validation Process

Defining the framework

Defining the viewpoints in the framework

Defining the framework context view

Defining the ontology definition view

Defining the viewpoint relationship view

Defining the viewpoint context view

Defining the viewpoint definition view

Defining the Ruleset Definition View

Summary

Self-assessment tasks

References

Chapter 9: Methodologies

Introducing methodologies

Introducing SAFe

Defining the SAFe concepts

Defining the SAFe core concepts

Deploying SAFe

Summarizing the SAFe method

Introducing OOSEM

Defining OOSEM concepts

Defining the OOSEM approach

Summarizing the OOSEM method

Methodologies and MBSE

Methodologies and approach

Methodologies and goals

Methodologies and visualization

Methodologies and implementation

Methodologies and compliance

Summary

Self-assessment tasks

References

Chapter 10: Systems Engineering Management

Introducing management

The project planning process

Applying modeling to the activate the project activity

Applying modeling to the define the project activity

Applying modeling to the plan project and technical management activity

Summary of the project planning process

The decision management process

Applying modeling to the prepare for decisions activity

Applying modeling to the analyze the decision information activity

Applying modeling to the make and manage decisions activity

Summary of the decision management process

The project assessment and control process

Applying modeling to the plan for project assessment and control activity

Applying modeling to the assess the project activity

Applying modeling to the control the project activity

Summary of the project assessment and control process

The risk management process

Applying modeling to the plan risk management activity

Applying modeling to the analyze risks activity

Applying modeling to the manage the risk profile activity

Applying modeling to the monitor risks activity

Applying modeling to the treat risks activity

Summary of the risk management process

The information management process

Applying modeling to the prepare for information management activity

Applying modeling to the perform information management activity

Summary of the information management process

The configuration management process

Applying modeling to the plan configuration management activity

Applying modeling to the perform configuration identification activity

Applying modeling to the perform configuration change management activity

Applying modeling to the perform configuration status accounting activity

Applying modeling to the perform configuration evaluation activity

Applying modeling to the perform release control activity

Summary of the configuration management process

The measurement process

Applying modeling to the prepare for measurement activity

Applying modeling to the perform measurement activity

Summary of the measurement process

The quality assurance process

Applying modeling to the prepare for quality assurance activity

Applying modeling to the perform product or service evaluations activity

Applying modeling to the perform process evaluations activity

Applying modeling to the treat incidents and problems activity

Applying modeling to the manage quality assurance records and reports activity

Summary of the quality assurance process

Summary

Self-assessment tasks

Section 4: Next steps

Chapter 11: Best Practices

Introducing key standards

ISO 15288 – Systems and software engineering life cycle processes

Other standards

Introducing key guidelines

The INCOSE Competency Framework

Other guidelines

Organizations

Summary

Other Books You May Enjoy

Preface

Systems engineering allows us to develop successful systems while managing complexity. This brings together all aspects of systems engineering in a concise, clear, and consistent way.

This book is a comprehensive introduction for those who are new to systems engineering as well as experienced practitioners. Complete with examples and self-assessment questions, this easy-to-follow guide will teach you all the concepts and techniques required for modern systems engineering.

It provides you with an overview of systems engineering and describes why we need such an approach in our complex world. It covers the essential aspects of model-based systems engineering, systems, life cycles, and processes, along with techniques to realize systems engineering successfully.

By the end of the book, you will be in a position to start applying a systems engineering approach in your organization.

Who this book is for

This book is aimed at aspiring systems engineers, systems managers, systems modelers, and anyone with an interest in systems engineering or modeling.

The book is also suitable for those who are complete newcomers to systems engineering. However, experienced systems engineers may also benefit from reading this book.

What this book covers

Chapter 1, Introduction to Systems Engineering, provides a brief history of systems engineering, then provides an overview of exactly what we mean by systems engineering and what differentiates it from other disciplines of engineering. The real-world, pragmatic need for systems engineering is explored by considering the increased complexity of today's systems, the need for effective and efficient communication, and the need for a clear, context-based understanding of different stakeholders' views of our systems. The practical issues with implementing systems engineering successfully in an organization are also discussed.

Chapter 2, Model-Based Systems Engineering, introduces the most effective and efficient way to realize systems engineering in the form of Model-Based Systems Engineering (MBSE). MBSE allows systems engineers to understand systems by developing a model to represent the single source of truth and how to use this as the basis for all systems engineering activities.

The system and its model are discussed, along with the importance of a framework that provides the blueprint for the model and various visualization techniques, such as SysML. This is then expanded to include tools and best practices to ensure that the model is as effective as possible.

Chapter 3, Systems and Interfaces, describes exactly what we mean by a system and the different types of systems that exist, including systems of systems. The structure of systems and their system elements – subsystems, assemblies, and components – are discussed as well as how they are arranged in hierarchies. The importance of understanding the relationships between these system elements is explained and how this impacts the system behavior. Behavioral concepts such as states, modes, and interactions are then defined. The key concept of the interfaces that connect a system together and to other systems is explained and the requirements for such interfaces are defined.

Chapter 4, Life Cycles, introduces the concept of life cycles and how they control the evolution of a system. Different types of life cycles are introduced and the importance of understanding the potentially complex relationships between them is stressed. The basic construct of a life cycle, the stage, is introduced and an example system life cycle based on best practice is defined. The behavior of life cycles is then described by considering life cycle models and some of the different types of execution of models. The international best practice model of ISO 15288 and its processes are used as a reference for these life cycle stages.

Chapter 5, Systems Engineering Processes, introduces the concepts of processes and their related elements, such as activities, artifacts, stakeholders, and resources. The importance of effective processes that define the overall approach to systems engineering is emphasized. The four different categorizations of processes are introduced and then a description of each of these four categories and their associated processes is provided. The international best practice model of ISO 15288 and its processes are used as a reference for these processes.

Chapter 6, Needs and Requirements, explains the importance of needs along with different types, specifically requirements. The whole area of stakeholder needs identification and analysis is described, along with the views necessary to understand the different aspects of needs. Describing needs using text is introduced, and then how to define contexts that may be used for the basis of use cases, as well as how these use cases may be validated by describing scenarios. There is then a discussion of how needs fit into the systems life cycle, which processes are relevant, and how to comply with them.

Chapter 7, Modeling the Design, discusses how solutions may be defined by developing effective designs. Various levels of abstraction of design are discussed, such as architectural design and detailed design. Also, different aspects of design, such as logical, functional, and physical designs, are introduced and the relationships between them are defined. There is then a discussion of how design fits into the systems life cycle, which processes are relevant, and how to comply with them.

Chapter 8, Verification and Validation, introduces how the system may be demonstrated to be fit for purpose by introducing the concepts of verification (the system works) and validation (the system does what it is supposed to do). A number of techniques are introduced and described that show how verification and validation may be applied at different levels of abstraction of the system and an overview of other techniques that may be used is provided. There is then a discussion of how verification and validation fit into the systems life cycle, which processes are relevant, and how to comply with them.

Chapter 9, Methodologies, describes some of the most widely used methodologies for systems engineering that are used in modern industry. Some of these use specific techniques while others are variations on the standard life cycle model. Each is described at a high level, examples are given, and a summary of the methodology's effective use is provided. There is then a discussion of how methodologies fit into the systems life cycle, which processes are relevant, and how to comply with them.

Chapter 10, Systems Engineering Management, provides an overview of some of the key management processes and associated techniques that need to be considered and how they can be implemented. The relationship between management techniques and technical techniques is also discussed. There is then a discussion of how design fits into the systems life cycle, which processes are relevant, and how to comply with them.

Chapter 11, Best Practices, is a short chapter that provides a set of information that can be used to continue systems engineering in your own organizations. This includes modern standards and other best practice sources, such as guidelines and also a list of organizations who actively promote systems engineering and provide valuable resources.

To get the most out of this book

This book assumes no prior knowledge of systems engineering or modeling and, therefore is suitable for beginners in the field.

Download the color images

We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781838985806_ColorImages.pdf.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.

Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Reviews

Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!

For more information about Packt, please visit packt.com.

Section 1: Introduction to Systems Engineering

In this section, we will understand what Systems Engineering is and why there is a growing need for such an approach with today's increasingly complex systems.

This section has the following chapters:

Chapter 1, Introduction to Systems EngineeringChapter 2, Model-Based Systems Engineering

Chapter 1: Introduction to Systems Engineering

This chapter focuses on the background of systems engineering, considering the history of the subject and why it is needed. This chapter will also provide an understanding of the main concepts associated with systems engineering and the terminology that will be adopted throughout this book, thus aiding our understanding of the topic as we progress. To do this, we will look at the following topics:

A brief history of systems engineeringDefining systems engineeringThe need for systems engineering

A brief history of systems engineering

It may be argued that systems engineering has been being 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 been observing 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 20th 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, that 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), 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.

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 that will then be used consistently throughout this book. Wherever possible and appropriate, the terminology adopted will be based on international best practices, such as 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 that will be the one that is used 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 the 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. System of interest refers to a system that is under development, whereas 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, that it is the stakeholder roles that Jon plays that are considered.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 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 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 an 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 of type integer and may not have a unit associated with it.Name, which may be of type character or 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 day (an integer between 1 and 31), month (an integer between 1 and 12), year (an integer ranging from 0000 upwards), 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, or is it 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 to 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 is described about 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 it 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 1,000 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 that 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, providing 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 and implementation 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) (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 108), 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 & 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

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, 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 providing, of course, it has been identified in the first instance.Accidental complexity is not natural and is introduced by inefficiencies in the peoples, 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 that 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 that 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 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; only 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 on 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 component, 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 the nature of these system elements.

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 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 standards and legislation 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 of 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 that exhibits 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 complex. 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 cites 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, that did not occur with an older vehicle. The modern car is also taking 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 that 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 that is naturally exhibited.

Now consider a modern electric car. The motor on 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 towards 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 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 at 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 will include 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.