Principles of Systems Engineering

By Neil G. Siegel

Principles of Systems Engineering is a practical, step-by-step guide to the creation of complex engineered systems.

This is a companion book to the same author's Engineering Project Management textbook. This book is based on many years of research, and decades of actual, hands-on experience in successfully performing and leading complex engineering projects.

The book introduces what the author calls the systems method, and then goes stage-by-stage through the details of the systems engineering process. Many examples and tips from real projects are used to illustrate the processes and techniques described.

Neil G. Siegel, Ph.D., spent many years as the lead designer &/or manager of a number of successful engineering projects, including projects of unusual technical difficulty, and at the largest scales. After retiring as sector Vice-President & Chief Technology officer of the Northrop Grumman Corporation, he is at present the IBM Professor of Engineering Management at the University of Southern California. He is a member of the National Academy of Engineering and the National Academy of Inventors, and a fellow of 4 engineering societies, among many other honors and awards. More information is available at neilsiegel.usc.edu.

• Language: English
• Publisher: BookBaby
• Release date: Dec 31, 2022
• ISBN: 9781667881515

Book preview

1. About systems engineering

1.1 Introduction

In this book, we are going to discuss something called systems engineering. I am going to try to convince you of several things:

•That systems engineering is important for the world, and therefore needs to be done well, and those who do it well can derive significant satisfaction from that achievement

•That there is an established methodology and approach to performing good systems engineering, and that it can be explained and taught

•That systems engineering is a particular discipline within a larger field called engineering, and that it is possible to learn the specific role of systems within engineering

•Because of the above – together with the fact that systems engineers are in general paid very well –systems engineering is in fact a great career choice

My first assertion, above, was that systems engineering is important for the world. Let’s examine that for a moment.

In your opinion, what is the most important human accomplishment of the last 2,000 years? Think about it for a moment, and fix something in your mind, before you turn the page.

When I ask this question on the first day of my systems engineering courses, I get lots of really good and interesting answers. Obviously, this is a matter of opinion, and we can all have an opinion. But here is my answer:

The most important human accomplishment of the last 2,000 years is the doubling of the average length of human life

What the archeologists and other scientists who study these matters tell is that that for hundreds of thousands of years, the human life-span averaged around 35 years . . . until around 125 years ago . . . when the average human life-span started increasing . . . and recently the average human life-span has reached more than 70 years.

To depict this improvement, I created the following graph (Figure 1-1) from data made public by the World Health Organization:

Figure 1-1. Human life span through the ages.

In fact, in many parts of the world, the typical human life-span is now more than 80 years.

Obviously, living to 70 or 80, rather than just to 35, is viewed by most people as a very good thing, indeed!

But what caused this doubling of human life-expectancy? This question has been studied by the United States National Academies¹ . Apparently, engineering projects deserve most of the credit, due to the following types of large-scale societal systems that have been created by such projects:

•Water treatment and delivery

•Sewage treatment and transport

•Motor-powered tractors

•Motorized transport and delivery

•Large-scale electricity generation and delivery

•Affordable, mass-scale refrigeration

•Canning and other mass-scale food storage / preservation techniques

•. . . and so forth

And underlying all of these is the ability to generate, on a suitably-large scale, the mechanical power (which can take the form of electricity, petroleum, natural gas, hydro-electric generation, etc.) that enable all of those large-scale societal systems listed above.

The U.S. National Academy has estimated that these sorts of engineering products are responsible for about 80% of the addition to human life expectancy; the rest is mostly due to modern medicine².

And all of these important societal systems were created by engineering projects, and to succeed, those types of projects today and in the future will require systems engineering.

Ergo: If you want to change the world for the better, become a systems engineer!

1.2 Definition of systems engineering

Systems engineering is a phrase with two words. We can examine those words one at a time.

Engineering is a discipline that uses knowledge from science and other fields, together with many other skills, in order to create a practical effect. This effect might take the form of a device or a service that has some beneficial effect for a set of intended users, and for society as a whole.

Example: Engineering has been able to design automobiles that produce much less pollution per mile driven than earlier automobiles. That benefits the actual users (e.g., the owners and drivers of those automobiles), because one of the ways in which the engineers achieved that lower level of pollution was to increase the fuel-efficiency of those automobiles, which decreases the cost of driving. But society as a whole also benefits, even those who don’t drive that particular automobile (and even those who don’t drive any automobile!), because that decreased amount of pollution improves air quality in the entire operating region of that automobile.

In ordinary conversation, the terms engineering and science are often used almost interchangeably. This is not correct! Science seeks to study and understand the world; it asks questions about the underlying mechanisms and principles, and its goal is to make reliable and verifiable quantitative predictions about the behavior of natural phenomena. The focus in science is not on creating a practical effect, but instead is on creating the knowledge that allows those reliable and verifiable quantitative predictions. One can create good science that is never used to create a practical effect. Of course, some science is used (mostly by engineers!) to create a practical effect, but that is not the goal of the scientist³.

Engineering, on the other hand, is not aimed at such knowledge for knowledge’s sake; such knowledge may be important, but discovering it is a job for scientists, not for engineers and engineering projects. We engineers, instead, keep our focus on achieving those practical results.

An engineering project, however, is not a science project⁴; it is important for you to understand the difference between science and engineering. Look at figure 1-2, below.

Figure 1-2. Science and engineering have different objectives.

Our engineering projects must be feasible, else we will not create that practical benefit. Therefore, we may well have to consult with scientists in order to make sure that we are not promising more than we can feasibly deliver. But sometimes, we engineers create something that works, but for which there is not yet a complete scientific explanation; the steam engine, the antibiotic, and the transistor are all examples of this. When the scientists see the practical device that has been so created, they might be motivated to go and figure out the underlying phenomena; for example, the operation of actual steam engines motivated people to go out and work out what became known as the laws of thermodynamics, e.g., the scientific explanation of why the steam engine worked. Sometimes the science precedes the practical application, but just as often, the practical application precedes the science.

A presentation by an Englishman named Chris Wise (who, at the time, was a professor at University College, London) that I attended in 2013 got me thinking about what one might call "the tao of engineering"; tao is a Chinese word meaning approximately way or path. I believe that the path to successful engineering encompasses much more than what some people might narrowly define as engineering. I have adapted what Professor Wise said to arrive at the following depiction (see Figure 1-3, below).

As you can see in this figure, I take an expansive view of what is needed to be a good engineer. As engineers we must base our work on facts, measurement, and rigor; we must actually achieve a practical result in the real world. This leads us to pay attention to math and science. But in my experience, that is not enough to succeed; we must also exercise judgement about what our product should be, create a compelling vision of what it could be, and use craftsmanship and artisanship to build it well. And every engineering activity requires the collaboration of multiple people – in fact, often very large teams of people. So, factors like who will do the engineering with you, and how you motivate, train, and coordinate all of those people are also essential aspects of good engineering. Because of this, I think of engineering as being 50% technique and 50% social.

OK, we now know have some understanding of the word engineering. What about our other word, systems?

Figure 1-3. The tao of engineering.

We have describing engineering, above, as a discipline whose purpose is to create a benefit to humans and society by creating products and services that provide a positive, practical benefit.

Engineering is a vast field, and it has therefore divided itself into a set of specialties. These include:

•Aerospace engineering / Astronautics

•Biomedical engineering

•Civil engineering

•Chemical engineering

•Computer Science

•Electrical engineering

•Energy / Petroleum engineering / Nuclear engineering

•Environmental engineering

•Human factors engineering

•Industrial engineering

•Mechanical engineering

•Systems engineering (finally!)

•. . . and more

What is role of the systems engineer among all of these specialties? Being a long-time musician, I think of it as akin to that of an orchestra conductor. In a symphony orchestra, each instrument and each instrumentalist have a specified part to play, but there are lots of options about how their individual efforts are to be blended together to form the final product. These options include tempo, relative volume of the different instruments, particular emphases and stresses, places where perhaps there ought to be some particular collaboration or blending of sounds (and there are many others) . . . and none of these are definitively determined by the composer! Rather, they are left to the interpretation of the musicians, who collaboration is facilitated and guided (but not necessarily dictated) by the conductor.

Similarly, in our engineering project, where we are trying to create that product or service that will provide some specific benefit, we have choices about how best to combine the efforts of each specialist: what portions of the product will be implemented via mechanical devices, what portions via electrical devices, what portions via software, and so on. It is the role of systems engineering – and the systems engineer – to facilitate (but not necessarily dictate) these decisions.

Let us now be a little more rigorous about this word, system.

The Oxford English Dictionary (1933) provides the following definition of the word system: A set or assemblage of things connected, associated, or interdependent, so as to form a complex unity . . . rarely applied to a simple or small assemblage . . .

One of the founders of the field of systems engineering as a formal discipline, Dr. Simon Ramo, provided this definition⁵: Systems engineering is a discipline that concentrates on the design and application of the whole, as distinct from the parts. It involves looking at a problem in its entirety, taking into account all the facets and all the variables and relating the social to the technical aspect.

That is to say, we aim for an awareness and optimization of the whole, through an understanding of how the parts within that whole could ideally interrelate.

Here is another way of looking at it: A system is created because we desire to obtain something called emergent behavior. What is this emergent behavior?

Eberhart Rechtin⁶ defined emergent behavior in the context of such a system as follows: The whole (of a system) is greater in some sense than the sum of the parts, that is, the system has properties beyond those of the parts. Indeed, the purpose of building the system is to gain those properties⁷.

Rechtin therefore defines a system as "a set of different elements so connected or related as to perform a unique function not performable by the elements alone⁸".

A system, therefore, is built so as to obtain these properties beyond those of the parts, which I like to call the 1+1=3 effect. The entire system is greater than the sum of its parts.

Here is a simple example of such emergent behavior:

•A cart provides very good thermodynamic efficiency; you can move a total amount of weight that is much larger by using a cart than you can by carrying items in your arms. And you can do so over a much longer distance, and for a much longer period of time.

•A cart consists essentially of wheels, axle(s), and a box with a handle. The increase in thermodynamic efficiency provided by a cart is not , however, inherent in any of these parts; this increase does not come from the parts. Instead, this increase emerges when those parts are combined in just the correct fashion.

It is not the design of the parts that provides the benefit (the emergent behavior); instead, it is the design of how these parts interact. You can in fact build a pretty effective cart out of fairly mediocre parts.

This is what we are trying to do when we build a system: get that 1+1 = 3 effect, in exactly the areas that we select.

Notice that the Oxford Dictionary definition cited above refers to complexity and large scale; this is an indication that it may not be simple to obtain the emergent behavior that we want. But we make the effort (and incur the associated expense!) because such it turns out that such systems can provide significant benefits to society.

Think again about the example we discussed above, about the doubling of human life expectancy in the last 100 to 125 years. This increase in human life-span was not the direct intent of any of the systems cited in the above list; the direct intent was to provide potable water, to deal with sewage on a consistent and reliable basis, and so forth. In fact, the increase in human life-span was a behavior that emerged from these systems, and is not really inherent in any of them!

But note something else, too: that such emergent behavior can be negative, as well as positive. For example, the increase in human life-span, while hugely beneficial when considered from the point of view of each single person who benefits from it, has also resulted in a gigantic increase in the human population of the Earth (from about 1 billion to 7 billion in just those same 125 years). That increase is not necessarily a problem, but from this increase in population have arisen a large number of real problems: potential food shortages, increases in pollution, and many others.

When we design such systems, we must aim at something that I call the 2-part design goal: we must (1) identify the positive emergent behaviors that we want to achieve, but we must also (2) predict the potential negative emergent behaviors that our system might create, and either prevent those adverse behaviors from emerging, or provide some other mechanism to mitigate their negative effects.

We will be saying a lot more about this 2-part design goal later in the book. Doing this well is the center-piece, in my experience, of good systems engineering.

In short, we aim to achieve the benefits of emergent behavior when we design and build systems for society, but we also strive to minimize the unintended adverse consequences that can be caused by potential negative emergent behaviors.

Our track-record is pretty good, but the expectations of society for our profession are very high (Figure 1-5):

Figure 1-5. The expectations of society on engineering are very high.

Having defined the words systems and engineering, we now can put them together: systems engineering is the discipline that provides the method and processes by which we can create systems to meet the needs of society.

We aspire to do this work:

•Predictably (on schedule and within cost, while providing all of the promised capabilities)

•Safely

•Correctly

•Repeatably

•Without creating significant adverse side-effects

•. . . and so forth

1.3 The motivation for systems engineering

Let’s talk about why the world needs systems engineering. To start with, consider these:

•Society needs the types of systems we have been discussing, and systems engineering helps us create them effectively

•Many systems involve expenditures of public funds, and systems engineering helps us to spend such public funds responsibly

These both essentially state that systems engineering helps us do a better job at building the complex systems that society needs. Let’s consider that in more detail: in fact, systems engineering has been shown to make a big contribution towards consistently achieving better outcomes when we try to develop such systems.

•In terms of the cost-to-market of the development effort: systems engineering, on average, reduces the cost to get our systems built and deployed

•In terms of time-to-market of the development effort: systems engineering, on average, reduces the amount of time that it takes to get our systems built and deployed

•In terms of fewer failed efforts to develop systems: systems engineering, on average, increases the chance that our project will reach a successful outcome

•In terms of the life-cycle cost of the capability: systems engineering, on average, reduces the cost to operate our systems over their entire life-time of operational use

•In terms of the quality, effectiveness, and safety of the resulting system: the use of systems engineering, on average, results in higher-quality systems

How does systems engineering actually contribute to these beneficial effects? Here is an example:

•In the next chapter (2), we will introduce what I call the systems method . This consists of a series of life-cycle stages for our systems, from their initial conceptualization, through their development and manufacture, through their operation and maintenance, and finally, to their retirement and disposal.

•Of course, since we are only human, there are likely to be errors introduced into the design and construction of our system. What the data from thousands of completed projects show is that it is far less expensive to find and fix a problem in one of the earlier life-cycle stages than in one of the latter life-cycle stages ⁹.

This effect of being less expensive to fix a problem earlier in the system life-cycle than later is very large; the data in fact show that it can literally cost 1,000 times more to fix a problem if it is not discovered until after the system is deployed, than if that same problem were discovered during one of the early life-cycle stages.

So, there is strong financial benefit if we can find (and fix) these inevitable errors earlier in the system life-cycle, rather than later. Well, it turns out that the methodology and tools of systems engineering are quite effective at helping us find and fix such problems in those early life-cycle stages, where the cost of finding-and-fixing is so much less.

In the list above, I mentioned that using good systems engineering results in having fewer failed efforts to develop systems. It turns out that developing the sort of large, complex societal systems that we are talking about – a new billing and payment system for a hospital chain, a new air-traffic control system, a new system for controlling the operation of a manufacturing plant, and so forth – is hard. Not surprisingly, many of these attempts to develop such systems actually fail. Some sources report that more than 80% of projects intended to develop such system fail. 80%! Clearly, making use of any technique that can reduce such a high rate of failure is a good idea.

These failures can be caused by any of several causes:

•Over the course of the system’s development, the estimate for the final cost keeps increasing, and finally reaches an estimated level that cannot be afforded, so the project is cancelled.

•Over the course of the system’s development, the estimate for the date by which the project will be completed keeps getting later and later, and finally confidence that the project can realistically be completed is lost, so the project is cancelled.

•Over the course of the system’s development, it becomes apparent that the system is not going to be able to perform as promised; the shortfall might be in functionality, in capacity, in reliability, or in any of several other measures. If such a shortfall materially decreases the rationale for creating a new system, the project may be cancelled.

•The use of the system may result in some sort of unintended adverse consequence(s). For example, that new computerized billing and payment system for the hospital chain may turn out to have cybersecurity defects, enabling the theft of private patient information, or enabling fraud in billing. If these unintended adverse consequences are material enough, the project may be cancelled.

•Sometimes, the intended users of the new system (e.g., the doctors at those hospitals, etc.) just don’t like the new system, and will refuse to use it. This can lead to the cancellation of the project.

We will learn over the course of this semester that systems engineering is capable of reducing the likelihood of all of these potential problems, and many others, as well.

And good systems engineering can help us find a problem that has not been noticed before, and help us create a solution to that problem. We will discuss several examples (case studies) of this sort over the course of this book, but here is a preview of one of these, just to get you thinking about the power of systems engineering to solve problems.

Consider a scenario:

•You have some symptom; you therefore go to doctor #1, describe your symptom, get some sort of test, the doctor makes a diagnosis, and she then writes you a prescription for an appropriate drug

•Soon thereafter, you have a different symptom; you therefore go to doctor #2, describe your new symptom, get some sort of test, the doctor makes a diagnosis, and she then writes you a prescription for an appropriate drug

•You now are taking two different prescription drugs at the same time; each is appropriate for their individual diagnosis

•But . . . when doctor #2 prescribed the 2nd medicine, she may not have known about first symptom, and the resulting prescription for the 1st medicine. What if those two medicines can have an adverse reaction with each other?

In 1980, 100,000 people died every year in the United States alone due to such adverse drug interactions. Many more were made seriously ill. This is clearly an example of those unintended adverse consequences that we spoke of before.

In 1981, when I first learned of this problem, the data to demonstrate the existence of the problem was known only to a few specialists in public health, and they believed that the problem was not correctable . . . so they didn’t even try to get the problem corrected. I found that most physicians (and most patients) had never even heard of the problem¹⁰!

Using systems engineering, a solution was created¹¹, and now the problem is of a far smaller magnitude than it was in 1980. This is a major systems engineering success story: using systems engineering, we recognized a significant problem that was largely overlooked (and was deemed uncorrectable by those few who knew about it), and then we were able to correct the unintended adverse consequences, which in this case was causing a very large number of unnecessary deaths and injuries every year. And this problem will remain corrected forever; the initial implementations are all obsolete and retired, but the problem is now recognized, and a solution will always be provided in future systems.

Here's another little case study:

•Imagine that you have been asked to design a data center : a collection of computers, disk drives, digital communications, and software. The data center will receive, store, and process information for a large enterprise.

•This equipment is expensive, so you focus your attention on finding a design that minimizes the cost of this equipment.

•But are you solving the correct problem ? It turns out that, very often, people do not identify the correct problem, and naturally, the design solution that they create is not well-suited for the situation.

In the case of a data center, consider the implications of the following diagram (Figure 1-6), which depicts the relative costs of the various elements of cost for a typical data center. The diagram starts with the information technology equipment, that is, those computers, disk drives, digital communications, and software that we mentioned above. But there is a larger element of cost, depicted in the next-larger box: the building itself, and its heating, ventilation, and air conditioning equipment (HVAC); for many data centers, especially those in urban areas where the cost of land and construction is high, the building is likely to cost more than the information technology equipment! The diagram finally depicts a still-larger element of cost: the cost of operating and maintaining the information technology equipment and the building (including the HVAC) for the useful life-time of our data center, which is likely to be something on the order of 20 to 30 years. This cost for operations and maintenance – especially the cost of the electricity – is likely to be the largest cost of all!

In fact, as a general rule-of-thumb, you can expect that fully 80% of the total life-cycle cost of a system is incurred after it is built and deployed; that is, during the operations and maintenance activity.

Figure 1-6. Relative magnitudes of the cost elements of a data center.

This is very counter-intuitive to many people, so let’s go over it again:

•The Information Technology equipment (those computers, disk drives, digital communications equipment, and software) are in fact expensive, but in most data centers, the cost of the building itself, and its associated HVAC (heating, ventilation, and air conditioning) is more! It turns out that Information Technology equipment generates a lot of waste heat, and so the demands on the air conditioning, in particular, are very severe: we need to buy high-capacity (and therefore, expensive) air conditioning equipment for our data center.

•But that’s not likely to be the most expensive element of the data center. The data center will be used for many years – as we said, a design life-time of 20 to 30 years is pretty typical – and therefore, the building and its equipment must be operated 24 hours a day, 7 days a week, for that entire period of time. This means that our data center will be using lots of electricity ¹²! We also have to maintain the equipment in operating condition for that entire 20- to 30-year period.

Obviously, we do not want to design a data center that is cheap to build, but outrageously expensive to operate; that will end up costing – over the entire life-time of the data center – a lot more money than an alternative design that has lower operating costs, even if it has higher costs for the original acquisition of the equipment.

Thinking along these lines can open up new and better design alternatives. It might be fun to place the data center in Hawaii (many of our employees would be glad to live there!), but the ambient air temperature in Hawaii is pretty high, so the amount of work that the air conditioning must perform in order to keep the air down to the temperature we want is more than in a location where the ambient air temperature is less. Air conditioning also is used to remove moisture from the air, and the ambient air in Hawaii is relatively high in moisture compared to other locations, so again, we are creating more work for our air conditioning, which implies we will be using more electricity.

If in contrast, we placed the data center in a location that has a much lower average ambient temperature (such as rural Montana), there would be less work for our air conditioning to perform, which would save electricity.

Of course, we need to compare the availability of power in various locations, the cost of a unit of electricity in those various locations, the cost of the land, the ability to hire people with suitable qualifications at each candidate location, and so forth. But the ambient outdoor temperature alone is a very significant driver of the total life-cycle cost for our data center!

We want to create a design that minimizes the total cost over the projected useful life-time of the data center, including the initial construction of the building, the original fit-out of the information processing equipment, and the cost of operating / maintaining the data center over the entire projected useful life-time. This is called the life-cycle cost, and the correct problem we ought to be trying to solve is creating a design that minimizes this life-cycle cost of the data center, rather than a design that minimizes the initial acquisition cost of the data center’s information-technology equipment.

You will find that it is common for a team to be trying to solve the wrong problem; in this case, trying to minimize the purchase price of the information-technology equipment, rather than trying to minimize the total life-cycle cost of the data center. We are going to show you how, by using systems engineering, we have a better chance of identifying the correct problem upon which we ought to be working.

1.4 The life-cycle stages of systems engineering

In the preceding pages, I made reference to the existence of a life-cycle for systems engineering. This consists of a series of stages through which the activity to create a new system typically progresses.

The activity to create a new system is called a project¹³. There is an entire discipline of how effectively to create and manage such projects; this discipline is called engineering project management. There is a significant over-lap between systems engineering and engineering project management, as is depicted in this figure (Figure 1-7):

Figure 1-7. Systems engineering and engineering project management.

As you can see, there are some skills that are used in both systems engineering and engineering project management, and there are also skills that are unique to each. In this book, of course, we are going to focus on those skills needed for systems engineering, but we will at times make reference to the skills needed to perform engineering project management, because they are at times so closely intertwined.

Notice that one of those skills needed for both systems engineering and engineering project management is an understanding of the system life-cycle and its stages. Let’s turn our attention to that.

The figure below (Figure 1-8) depicts the version of the system life-cycle stages that we will use in this book; we will describe each stage in chapter 2, and then go stage-by-stage in detail in chapters 3 through 11:

Figure 1-8. The system life-cycle stages.

There are many other versions of this chart, but they vary only in detail; their general lay-out is always the same:

•We start by focusing on determining what the system needs to do, and how well it needs to do it (the need and the idea; requirements)

•We continue by focusing on determining how the system will accomplish those requirements (design). A key aspect of design is that we always break the system into a hierarchy of nested parts or components ¹⁴.

•We then continue to build those components (implementation)

•Having built the components, we now have in essence a disassembled system. The next stage, therefore, is to start a structured process of assembly, combining small numbers of our components into mid-sized assemblies, and slowly building up larger and larger assemblies, until we eventually have assembled the entire system (integration).

•We now have to verify that the system performs in accordance with the requirements (testing)

•This process gets us one copy of our system. Sometimes, that is all we are creating ¹⁵. But most of the time, we will be needing more than one. Sometimes, we know in advance exactly how many we are going to build. Other times, we don’t know this in advance; we build them, and try to sell them. If the demand is large, we will build a lot of them. This process is called production.

•Once we have built our system (in whatever numbers), and tested it, we are ready to place it into operation. This might be as simple as shipping it to a customer, and letting them unpack it, and place it into operation. But for most of the complex systems that we will be considering in this book, this process is far more complex (deployment; use in actual mission operations). For example, a satellite has to be launched into orbit, checked out on orbit, and so forth.

•Every system needs some sort of diagnostics and preventative maintenance, and when something goes wrong, needs repairs. To accomplish this, one needs parts, diagnostic tools, and trained personnel. This is called logistics.

•Every system reaches a point where it is no longer relevant, no longer effective, or it is no longer cost-effective to keep in operating condition. That system then needs to be retired and disposed of. As we will see, this can be a very complex and expensive process, and we call it phase-out and disposal.

Much of this book will be taken up with going stage-by-stage through the blocks in this Figure (1-8). We will explain the process for each in detail, describe the tools that we have available, describe the representations and methodologies that we can use, and describe how we determine whether we did that stage correctly or not.

1.5 A brief history of the field

People have been building products and societal infrastructure for a long time; large-scale irrigation systems, for example, have been in use for at least 4,000 years¹⁶.

But in recent years, most especially since the beginning of the industrial revolution about 150 years ago, the complexity of such societal systems has significantly increased, especially in terms of how such systems interact with each other.

We have also become much more aware of the potential (as we said above) for unplanned adverse effects. For example, people have for thousands of years cleared forest land in order to create land that can be farmed. In the past, this at times led to disastrous consequences; for example, massive erosion of top soil that left the land useless for agriculture; such unplanned adverse effects have literally killed off some societies.

The expectations of society are higher now than in the past, even than in the recent past; society expects that engineers can provide them benefits while at the same time minimizing or managing such unplanned adverse effects. This expectation created the conditions for the formal invention of the field of systems engineering. The organization, methods, and processes of systems engineering provide such an improvement over the essentially ad-hoc approaches of the past that we can consider the introduction of formal systems engineering as an important event in the history of engineering.

In mathematics, we often strive to create a solution that in some formal sense is truly optimal; it can be proved that such solutions are the best available for that class of problem. Like the problem 2+2 = ?, such problems have a single correct answer, and one can create methods and forms to reach such a correct (and best) answer. These are called closed form problems.

But the types of problems and situations that are amenable to such formal solutions is highly constrained; compared to situations in the real world, the situations where such techniques work are narrow and simplistic.

As the industrial revolution started to allow society to get far more complex, people therefore started to look for analysis methods that could deal with the complexity of the real world.

In the early 20th century, the discipline called operations research started to create a framework for systematic thinking about complex problems that were not amenable to closed-form optimization. Operations research had some particular successes during World War II, and this success attracted attention.

The generally-recognized formulation of systems engineering as a separate and specific discipline lies with Dr. Simon Ramo and Dr. Dean Wooldridge, who were asked in the early 1950’s by the U.S. Air Force to create an intercontinental ballistic missile for the United States. They actually were featured on the cover of Time Magazine in 1957 for this work; see Figure 1-9, below.

Figure 1-9. Dr. Wooldridge and Dr. Ramo on the cover of Time Magazine.

The intercontinental ballistic missile program was believed to represent a level of complexity exceeding previous developments. Initial efforts to develop such a missile had failed.

Ramo and Wooldridge, when they were asked to undertake the problem, started by re-thinking how the quest for a solution ought to be approached. They formulated the beginnings of a method that recognized the existence of emergent behavior, both as something desirable, but also as something potentially damaging. Since – as in our example of the cart – the emergent behavior derives from the system as a whole, and not exclusively from the characteristics of its parts, they created an approach that would take into account (and analyze) the behavior of the system as a whole, and not focus exclusively on the behavior of the parts. This was different; up to that time, designers tended to focus on the behavior and capabilities of the key parts, rather than the system as a whole.

They used the term systems engineering to describe this approach to designing, developing, managing, and integrating complex systems.

They also recognized that the complexity of the problem, and all of the applicable constraints imposed on the potential solution, meant that there may not be an optimal solution at all, in the mathematical sense of optimal. Instead, they had to seek for a design that was feasible, one that would achieve a reasonable portion of the requirements, and achieve a reasonable balance between competing factors. An example might be to balance performance and cost.

This was a real change:

•Analyzing the system as a whole , in addition to analyzing the behavior of the parts

•Accepting that we are striving for feasibility and balance , rather than some sort of optimal solution

They found, in the case of the intercontinental ballistic missile, that such thinking opened up the possibility to consider designs that were radically different than those tried before, and this opening up of the trade space turned out to be a vital element in their eventual success. We are going to talk a lot later in the book about what this opening of the trade space means, and how you accomplish it.

And eventually, Dr. Ramo literally wrote the book on the subject (Figure 1-10).

Figure 1-10. Dr. Ramo wrote the book on systems engineering.

By the way, I worked for the company that Ramo and Wooldridge founded. It was originally called Guided Missile Research and Development; after the launch of Sputnik, they re-named it Space Technology Laboratories. They had received funding to start the company from an older company called Thompson Auto Products, and in the early 1960’s, their company merged with that company to form Thompson Ramo Wooldridge (usually known by its initials as TRW). TRW was acquired by Northrop Grumman in 2002.

Dr. Ramo and Dr. Woodridge were both retired by the time I joined the company in 1977, but Dr. Ramo periodically would drop by to learn what was going on, and I occasionally met with him. In 2011, I was named to receive the IEEE Simon Ramo medal, the most-prestigious prize in the field of systems engineering. Dr. Ramo, being a kind person, called me to congratulate me. I suggested that we meet for a photograph (Figure 1-11):

Figure 1-11. Dr. Ramo on the occasion of my being named to receive the Ramo Medal in Systems Engineering in 2011.

Dr. Ramo was 97 years old at the time (and he lived to be 103!).

1.6 Being an effective systems engineer

Over the course of this book, we will discuss in detail how to be an effective systems engineer. But there are several key themes that I wish to preview here:

•We of course must have the relevant technical skills in system engineering, but we also require significant social skills. This is because every engineering project worth doing involves a team, and often, a large team, so the aspect of guiding the team so that it can become effective as a collaborative enterprise is a vital aspect of effective systems engineering. There is a type of emergent behavior that arises from an effective team; the team can be more effective than the sum of the individuals that comprise the team.

•The focus of effective systems engineering is always on achieving a practical benefit for a set of users and for society. I have found that in order to realize this benefit, a systems engineer must have a fairly deep understanding of how those users (and the other stakeholders) define value; that is, what matters to them. It is not enough for us to have strong technical skills! Note that in my experience, since most of our customers are not engineers, what they value is often very different than what we engineers might expect them to value. We therefore need to make an explicit effort to learn about them, their mission, how they operate, and what they value.

These two items have an interesting implication; they both state that in addition to possessing strong technical skills in systems engineering, to be effective, we also have to acquire and exercise two additional types of skills:

•Social skills / people-oriented skills (providing motivation, achieving alignment across a team, identifying and resolving conflict, and so forth). This is so important that it gets an entire segment to itself in my systems engineering course ¹⁷.

•Knowledge of our customer, their missions, and their value system. In this context, the term customer has a broad meaning, including the people who will actually operate our system once it is complete, but also including others who have a stake in the outcome of our project to build the system (stakeholders): those who are paying for the system, those who are buying the system (these buyers are seldom the actual users), those who regulate the system, and many others. This topic, too gets an entire segment to itself in my systems engineering course ¹⁸.

And here is a list that previews some of types of technical skills in systems engineering itself that we need to acquire:

1. We need to learn how to define the requirements for our system. We will discover (in chapter 3 ) that there are things that we need to do and to achieve as a part of this activity, but there is also a list of things that we need to avoid.

2. In many of the life-cycle stages (see Figure 1-8 , above) that we will use in systems engineering, we are going to create and work through a set of hierarchies : a top-down approach for some things; and a bottom-up approach for others. So, we have