1 Introduction

1.1 OVERVIEW
When Bob bought his new 2000 Cadillac Sedan DeVille DTS (Figure 1.1), one of
the rst things he wanted to do was upgrade the factory sound system. He took it to
Kenney’s Allston shop, Sound in Motion, and selected a new head (radio) and asked
Derek Kenney to install it in the new car. When Kenney completed the removal of the
factory radio and installed the new head, the new system sounded great. However, he
soon discovered that pulling out the original radio resulted in the car’s air condition-
ing, alarm, and computer diagnostics systems to stop working. The only way Kenney
could get the new head to work without disabling the A/C, alarm, and computer
diagnostics was to install the old radio in the trunk. “The guy actually has two radios
in his car, one he listens to and one to keep the car working,” Kenney said.*
What happened? When the A/C engineers were designing their system for this
vehicle, they needed a little more processing power and noticed the radio had excess
capacity in its electronic control unit (ECU). Rather than adding another ECU for the
A/C, they used the excess capacity of the radio, thus tightly coupling the radio with
the A/C. The same approach was used when the computer diagnostics engineers
needed a bit more capacity for the alarm system. The result? Four unique subsys-
tems, that have no relationship to one another, became tightly coupled. Whether that
was to save a few cents in production costs or not, it represented a lack of a systems
view—someone not watching each of the parts in the context of the whole. In the
end, the old radio ended up in the trunk just to keep the car running properly.
Systems engineering is an engineering approach that provides an understand-
ing of the interaction of individual parts that operate in concert with one another to
accomplish a task or purpose (Figure 1.2). Today the title of systems engineer is used
within a number of different professions, ranging from computer systems adminis-
trators to engineers who design spacecraft. While these professions have many dif-
ferences, they share a goal of looking at a system as a whole.
The impact of these different applications of the term system is that it makes it
dif cult to arrive at a single accepted de nition for systems engineering, but there are
some commonalities among the descriptions. A very minimalistic approach to sys-
tems engineering is “good engineering with special areas of emphasis” (Blanchard and
Fabrycky 1998, 23). Here “good” means viewing a system as a whole from a top-down
approach and addressing all phases of the system life cycle. Those areas would include
a strong effort on the initial de nition of system requirements, system validation, and
taking an interdisciplinary approach to ensure all aspects of design are addressed.

* Adapted from a story by Keith Reed, Boston Globe staff, August 23, 2004, http://www.boston.
com/business/technology/articles/2004/08/23/to_installers_of_ car_stereos_auto_systems_sound_
shy?mode=PF.

1
2 Systems Engineering Simplified

FIGURE 1.1 A 2000 Cadillac Sedan DeVille DTS. (From http://en.wikipedia.org/wiki/

Cadillac_de_Ville_series#mediaviewer/File:Cadillac_Deville_--_10-30-2009.jpg.)

F2

F1

Piston
area A1 Piston
area A2

Pressurized
hydraulic fluid
F2
F1

Mechanical analogy

FIGURE 1.2 A simple hydraulic system. (From http://en.wikipedia.org/wiki/Hydraulic_

drive_system#mediaviewer/File:Hydraulic_Force_Torque_275px.png.)

The International Council on Systems Engineering (INCOSE) states that systems

engineering is “an interdisciplinary approach and means to enable the realization of
successful systems. It focuses on de ning customer needs and required functional-
ity early in the development cycle, documenting requirements, and then proceed-
ing with design synthesis and system validation while considering the complete
Introduction 3

problem: operations, cost and schedule, performance, training and support, test,
manufacturing, and disposal. Systems engineering considers both the business and
the technical needs of all customers with the goal of providing a quality product that
meets the user needs” (INCOSE 2010).
Systems engineers come from many different engineering or technical back-
grounds. Some started as electrical engineers, some as mechanical engineers, or
any number of backgrounds. Some of the best systems engineers we have met have
an educational background in astrophysics. These individuals are excellent systems
engineers because of their ability to imagine how planets and stellar objects work in
concert with one another. Systems engineers are problem solvers who are skilled in
identifying the true problem or challenge before they ever begin trying to solve it.
Once the root problem or challenge has been identi ed and understood, systems
engineers use proven processes, analysis techniques, and management technology
to describe the problem, develop an architecture and design, build the solution,
then make sure they built the right system and that it solves the original problem.
This process is known as the system development life cycle. There are also a num-
ber of different descriptions of the system life cycle, but they all begin with the
conception of a new system, or a reason to engineer or modify an existing system.
The life cycle proceeds through the gathering of requirements, architecture and
design, production, utilization and support, and nally retirement and disposal.
Throughout the life cycle, systems engineering considers the whole system as well
as its elements.

1.2 DISCUSSION OF COMMON TERMINOLOGY

As in any other eld, words and de nitions are important. This section is meant to
provide a straightforward discussion on some of the terms that will be used through-
out this handbook.

System: Sometimes we ask, “Who is buried in Grant’s tomb?” Of course

it is Grant. Well, systems engineering is the understanding of systems.
So what is a system? This question is harder to answer than it rst
appears. Why? When thinking about systems, virtually anything might
be considered a system, depending on the inquisitor’s perspective and
background. Consequently, there are varying de nitions. In order to pro-
vide a well-rounded view, the following de nitions are provided. These
descriptions are by no means a de nitive set, as the number of authoritative
attempts is vast.
De nition 1: A system is an assemblage or combination of elements or
parts forming a complex or unitary whole, such as a river system or a
transportation system; any assemblage or set of correlated members,
such as a system of currency; an ordered and comprehensive assem-
blage of facts, principles, or doctrines in a particular eld of knowl-
edge or thought, such as a system of philosophy; a coordinated body of
methods or a complex scheme or plan of procedure, such as a system
of organization and management; any regular or special method of plan
4 Systems Engineering Simplified

of procedure, such as a system of marking, numbering, or measuring

(Blanchard and Fabrycky 1998).
De nition 2: An interacting combination of elements viewed in relation to
function (INCOSE 2010).
De nition 3: An integrated composite of people, products, and processes that
provide a capability to satisfy a stated need or objective (Mil-Std 499B).
De nition 4: A set of interrelated components that interact with one another
in an organized fashion toward a common purpose (NASA 2007).
De nition 5: A construct or collection of different elements that together
produce results not obtainable by the elements alone (INCOSE 2006).

If we were to create an aggregation of these de nitions, we might think

of a system as:

A system is a set of interrelated parts that work together to accomplish a

common purpose or mission.

Based on these de nitions, we are also going to adopt the principle

that a system must have a mission that it can complete without the aid of
another system.
This assumption has nothing to do with the complexity of the system,
but rather, can the system perform the intended mission independently?
Although the concept of a system touches many elds, we will focus on
systems that are engineered. For instance, using this de nition, a bicycle is
considered a system (Figure 1.3)—it is a set of interrelated parts that work
to transport a rider to a destination. In this case, the mission is to transport
the rider. As you will nd later in this book, the rider is both part of the
system and a stakeholder of the system.
System of interest (SoI): In order to easily apply the systems engineering
principles outlined in this monograph at all levels throughout a system
(e.g., subsystem level, module level, component level), the systems engi-
neering community has introduced the notion of system of interest.
This concept allows a systems engineer to think of any part of any system
as a system of its own. If one treats that part as a black box, and considers
all the interfaces as external interfaces, you can then apply these systems
engineering principles to that black box.
System of systems (SoS): Now that we have considered a system, let’s think
about what happens when there are a number of systems working together.
Examples might be the individual airplanes moving people across the skies
between destinations. This is often called a system of systems (SoS). There
are two different mainstream viewpoints on SoS (Baldwin et al. 2011).
On one hand, a SoS may be simply a matter of perspective where every sys-
tem can be considered part of a larger system (Ackoff 1981). In this case, there
is nothing exceptional about a SoS other than its scope. On the other hand,
Introduction 5

FIGURE 1.3 The bicycle is a system. (Courtesy of PRESENTERMEDIA.)

a SoS may be a distinct entity with a unique set of characteristics and traits.
Although both views have their merits, it is prudent for the systems engi-
neer to understand the unique characteristics and traits. For the sake of this
discussion, we will consider a SoS as fundamentally a system, as its name
suggests, that exists as a composite system whose diverse constituent sys-
tems are independent, dynamically connected, and contribute to a unique
overall goal of the system as a whole. More time will be spent on this type
of system and the challenges it imposes in Chapter 8.
System life cycle: The term life cycle refers to the entire spectrum of activi-
ties for a given system, starting with identi cation of a need and extending
through design and development, production and construction, operational
use, sustainment of support and system retirement, and eventually, disposal.
Different systems may have different life cycles according to the nature,
purpose, use, and prevailing circumstances of the system. In every case,
each stage of a life cycle has a distinct purpose and contribution to the
system as a whole (ISO-15288 2008). The systems engineer must consider
6 Systems Engineering Simplified

every stage when planning and executing the various activities throughout
the system’s life cycle.
Requirement: A requirement is any expectation, desire, or need based on a true
or perceived de ciency. The system must satisfy this expectation, desire, or
need to be considered a good system. Requirements might address what the
system does (transport a passenger from point a to point b), basic operating
characteristics (attain a maximum speed of 100 miles per hour), safety (pro-
vide a passive restraint for each passenger), and reliability (require regular
oil changes at a frequency exceeding 3000 miles), as well as many others.
In Chapter 5, we will discuss at length stakeholder requirements and system
requirements. While these terms have their own meanings, the underlying
intention remains: they are necessary or essential conditions for a system to
accomplish its mission.
Stakeholder: A stakeholder is any individual, another system, or even an
organization (such as a government agency) with a legitimate interest in the
system (INCOSE 2010). Normally we think of the stakeholders as the peo-
ple who will be using the system, such as the user of a kiosk (Figure 1.4).

FIGURE 1.4 A stakeholder of a kiosk-based system. (Courtesy of PRESENTERMEDIA.)

Introduction 7

However, stakeholders can also be an organization or individual who

has an interest in the outcome of the engineering of a system (EIA-632
1999). Although project personnel often use the term stakeholder to refer
to those not directly involved with the engineering of a system, it does
include the project manager, systems engineers, and other developers, as
well as the end users, system operators, sales personnel, and management.
If the system requires certi cation or governance by a government agency,
that agency is also a stakeholder. Of course, there are many instances
where all stakeholders are not included in the engineering of a system,
but involvement in the engineering of a system is different than interest
in it. To demonstrate this point, you may not have been asked about the
design of a new cell phone, but you are a stakeholder once you own one
of the phones.
Subsystem: A subsystem is the name given to a part of the system that is a
signi cant part of the system hierarchy when there are two or more levels
in the system hierarchy (Blanchard and Fabrycky 1998). Within a rail trans-
portation system, the trains and signaling system would be two examples
of subsystems, although in different contexts these subsystems may be con-
sidered systems. Continuing our bicycle example, the derailleur on a multi-
speed bike may be considered a subsystem (Figure 1.5).

FIGURE 1.5 A derailleur on a bicycle may be a subsystem. (From http://en.wikipedia.

org/wiki/Derailleur_gears#mediaviewer/File:Campagnolo_Super_Record_rear_derail-
leur_1983.jpg.)
8 Systems Engineering Simplified

Component: A component is a subset of a system that has been allocated

certain functions and requirements of the system (Buede 2000). One of the
individual gears seen in Figure 1.5 would be considered a component of
the bicycle system.

1.3 THE CASE FOR SYSTEMS ENGINEERING

As we established earlier, systems engineering is focused on viewing a system
as a whole—a holistic view. Systems engineers are trained to take a methodical
approach to understanding a system—from cradle to grave. This approach includes
considering how the system will be built, how the system will be supported once
it is in the customer’s hands, and how it will be disposed of when the customer is
done with it.
An example that demonstrates the importance of systems engineering is the
Sprint spacecraft, which was designed to make very short ights in space. When
the spaceship was rst envisioned, no one expected that it would be necessary to
change the spacecraft batteries in orbit. Therefore, there was no need to consider
rechargeable batteries, and the designers created a support requirement for the pur-
chase of additional batteries to support testing. Based on the requirements, recharge-
able batteries seemed to be an extravagance. Instead, lithium ion (Li) batteries were
used, as they met the requirement for the battery life. However, due to the volatility
of Li batteries, the battery compartment was designed with over 100 screws to secure
the battery pack.
A problem arose that extended the planned testing phase. Because of the longer
test phase, the Li batteries needed to be replaced countless times. Each time they had
to be replaced, all 100 screws had to be removed and then reinstalled, thus adding yet
more time to the test phase. The Li battery packs were very expensive, build-to-order
items, and the project quickly burned through the entire life cycle inventory of bat-
teries during the test phase.
The Defense Acquisition University studied this problem in the early 1990s and
produced the graph shown in Figure 1.6. It shows a number of items of concern to the
systems engineer. First, it shows that roughly 70% of the cost to develop a system is
committed during the concept phase. What this means is that engineering decisions
made during the development of the system concept, the system requirements, and
the system architecting steps will drive 70% of the nal cost to produce the entire
system. By the time the nal design is complete, but before development begins, 85%
of the costs will be committed.
Second, this graph shows that mistakes made during the concept phase (and not
xed during that phase) will cost three to six times more to x in the design phase.
If a mistake is not found until production and test, it will cost 500 to 1000 times more
money to x than if it were found in the phase it was generated. The longer a problem
goes uncorrected, the worse the problem will become. Therefore, reducing the risk
associated with new systems or modi cations to complex systems continues to be a
primary goal of the systems engineer.
Introduction 9

Committed Life Cycle Cost against Time

(From Defense Acquisition University 1993)

Cumulative Percentage Life Cycle Cost 100% Committed Costs

95%
90% 85%

80% 50–1000X
70%
cts
70% D e fe
ct Operations
tra 20–100X
60% o Ex through
st t Prod/Test
50% Co Disposal
3–6X
40%
30% 100%
Develop
20% Design 50%
10% Concept
15% 20%
8%
0%
Time

FIGURE 1.6 Seventy percent of the product costs are allocated in the rst 10% of the proj-
ect life cycle. (From Defense Acquisition University, 1993.)

1.4 A BRIEF HISTORY OF SYSTEMS ENGINEERING

While some will say that systems engineering is a new engineering discipline, that
is actually incorrect. Although systems engineering is relatively newer than classical
engineering, such as mechanical and civil, it has existed as a discipline since before
World War II. For example, Arthur Hall wrote an early textbook* published in 1962
detailing the practice of systems engineering at that time. He noted in the preface that
“the growing recognition of the need for systems engineering over the past decade
has been attended by the need for philosophical foundations.” He stated that his book
was intended “to increase awareness and understanding of systems engineering as a
process, and to sharpen de nitions and approaches to the main recurring problems
of the process-problem de nition, goal setting, systems synthesis, systems analysis
and choice among alternative systems.”
Hall published a composite view of the systems engineering process, as it was
de ned in 1962. Prior to Hall’s book, an AIEE fellow, E.W. Engstrom, published a
paper in the journal Electrical Engineering.† It was titled “Systems Engineering—
A Growing Concept.” Engstrom was an engineer at the Radio Corporation of America
(RCA). In his 1957 paper, Engstrom stated, “The task of adapting our increasingly
complex devices and techniques to the requirements and limitations of the people
who must use them has presented modern engineering with its greatest challenge.

* A.D. Hall, A Methodology for Systems Engineering, Princeton, NJ: Van Nostrand, 1962, p. 139.
† E.W. Engstrom, Systems Engineering—A Growing Concept, Elec. Eng. 76(2), 113–116, 1957.
10 Systems Engineering Simplified

To meet this challenge, we have come to rely increasingly during recent years upon the
comprehensive and logical concept known as systems engineering.”
According to Hall, AT&T Bell Labs began a 3-year graduate degree program in
systems engineering in conjunction with MIT in 1948. In 1950, MIT offered its rst
course in systems engineering. The goal of this program was to provide consistency
in transmission designs.
In November 1950, an article appeared in the Proceedings of the Royal Society B.
The article, written by Mervin J. Kelly, was titled “The Bell Telephone Laboratories—
An Example of an Institute of Creative Technology.” This paper was presented in the
form of a lecture delivered on March 23, 1950, and published later that year. In this
article, Kelly stated that approximately 10% of their scienti c and technical staff was
allocated to systems engineering (p. 426). He goes on to state:

Its staff members must supply a proper blending of competence and background in
each of the three areas that it contacts: research and fundamental development, speci c
systems and facilities development, and operations. It is, therefore, largely made up of
men drawn from these areas who have exhibited unusual talents in analysis and the
objectivity so essential to their appraisal responsibility.

The last example we will present is the Jet Propulsion Laboratory (JPL) in
California. Engineers at JPL were responsible for the development of the Army
Corporal sounding rocket in 1945. The lack of engineering process consistency
resulted in a lack of reliability in their systems. Therefore, they began a process to
transition their approach from a research mindset to an engineering methodology.
Their rst methods were based on “tribal knowledge,” or rather, a standardization of
their then currently accepted domain knowledge.
So, we return to the claim introduced in the beginning of this section that systems
engineering is not a new discipline. It has been in practice at least since 1945, which
represents over 60 years of experience and use. Systems engineering is hardly a
young discipline.

1.5 SYSTEM EXAMPLES

What makes up a system? What are the rules that enable something to be referenced
as a system? Consider the items in Figure 1.7. Any of these might be considered a
system. While some are more complex than others, they can all be considered a sys-
tem, by de nition. They have interrelated parts working together toward their own
goal or mission. Some may argue that a desktop stapler is not a system because it is
not complex enough. However, what is complex to one person may not be complex
to someone else.
As we discussed earlier in this chapter, there are as many de nitions as there
are opinions to answer the question of what a system is. And, we stated that a
system must have a mission that it can complete without the aid of another system.
So, let us look at an example. The Boeing 747 is a system (Figure 1.8). It has many
complex parts, including the jet engine (Figure 1.9). Some would say the engine
is a system, too. However, if one were to remove that engine and place it on the
Introduction 11

(a)

Upper spray bar

Water inlet pipe
Floatation switch Drain pipe
Water inlet valve Heating element
Filter basket Lower spray bar

Wash/drain valve
Detergent dispenser Pump
Tank
Rinse aid dispenser

Door latch Controls

(b)

(c)

FIGURE 1.7 Very different systems. (a) Clip art; (b) from www.shutterstock.com 161660264;
(c) from http://en.wikipedia.org/wiki/Excavator#mediaviewer/File:Kettenbagger_CAT_325C_
LN.jpeg (creative commons (cc) license).
12 Systems Engineering Simplified

FIGURE 1.8 The Boeing 747, rst operated by Pan Am. (From http://en.wikipedia.org/wiki/
Boeing_747#mediaviewer/File:Pan_Am_Boeing_747_at_Zurich_Airport_in_May_1985.jpg.)

FIGURE 1.9 Pratt and Whitney engine used on the Boeing 747. (From http://en.wikipedia.
org/wiki/Pratt_%26_Whitney_PW4000#mediaviewer/File:Aircraft_part_-_engine_
01b.JPG.)

runway, could that engine perform the mission for which it was designed, that is,
provide forward thrust to a Boeing 747? No. The fuel for the engine is in the air-
plane wing. The power to start that jet engine is on the aircraft. Yet, the aircraft
can take off, y somewhere else, and land without the aid of another system. Yes,
that means the pilot is part of the system (Figure 1.10). Now, there are other rules
Introduction 13

FIGURE 1.10 The pilot is part of the system. (Courtesy of PRESENTERMEDIA.)

and regulations that state that pilots need to le a ight plan with the FAA, need
clearance from the tower, etc. However, the pilot could choose to ignore those
requirements and y the aircraft. The jet engine on the tarmac cannot propel the
aircraft until it is attached to the wing. Therefore, the jet engine is a subsystem of
the aircraft—albeit a very complex and sophisticated subsystem. In Chapter 4 we
address why systems engineering is still critical to all aspects of the system and
its constituent parts.

1.6 SUMMARY
This chapter has presented a number of de nitions and concepts. These ideas may
seem confusing, but consider the following quote from Russell Ackoff (1981). He is
a leader in systems thinking and describes a system as

a whole that cannot be divided into independent parts without losing its essential char-
acteristics as a whole. It follows from this de nition that, a system’s essential de ning
properties are the product of the interactions of its parts, not the actions of the parts
considered separately. Therefore, when a system is taken apart, or its parts are consid-
ered independently of each other, the system loses its essential properties. Furthermore,
when performance of each part taken separately is improved, the performance of the
system as a whole may not be, and usually isn’t.
14 Systems Engineering Simplified

Mind mapping is a diagrammatic approach to thinking about a concept. Figure 1.11

represents one perspective on the practice of systems engineering developed by a team
of systems engineers during a lunch-and-learn. That concept is placed in the center, and
then limbs are drawn off that “trunk” to describe the major limbs, or thoughts about the
main concept.
Applying the same mind mapping approach, Figure 1.12 represents a mind map
of the concepts relating to a system. While we have not discussed each of these
concepts, they are important to the practicing systems engineer. What is clear from
this chapter is that the de nition of a system, and therefore the practice of systems

Objective Definitions
Scientific Rationale Best Practices
Simple
Metrics
Complicated
Constraints System
Complex
Requirements Problem/Needs
Chaotic
Scope
Reliable
Modeling Processes Systems Engineering
Decompose System Interoperable
Simulation
Maintainable
Integration Outcomes
Secure
Validation & Verification
Safe
Holistic
Efficient
Top-Down Perspectives
Bottom-Up

FIGURE 1.11 Mind map representing one perspective of the practice of systems engineering.

Parts
Purpose
Components
Explicit Objective
Subsystems
Elements Results
Boundaries Goals
Needs
Inputs
Interfaces Implicit Effects
Outputs
Balanced Solution
Rational
Actions Cost
Emergent
Time
Limits
Functions Systems Constraints Quality
Simple
Stakeholders
Complicated Behavior
Rules
Complex
Dynamic
Safe Direct
Connections Static
Secure
Indirect
Failures Relationships
Performance Dependencies
Trustworthy Reliable
Collaborations
Maturity
Environment
Operational

FIGURE 1.12 Mind map of the concept of systems.

Introduction 15

A system is a set of interrelated A “system” is a construct or collection

components which interact with one of different elements that together
another in an organized fashion produce results not obtainable by the
toward a common purpose. e elements alone. e elements, or parts,
components of a system may be quite can include people, hardware,
diverse, consisting of persons, software, facilities, policies, and
organizations, procedures, software, documents; that is, all things required
equipments, or facilities. e purpose to produce system-level results. e
of a system may be as humble as results include system-level qualities,
distributing electrical power within a properties, characteristics, functions,
spacecraft or as grand as exploring behavior, and performance. e value
the surface of Mars. added by the system as a whole,
beyond that contributed independently
by the parts, is primarily created by
NASA Systems Engineering the relationship among the parts; that
Handbook, SP-610S, June 1995 is, how they are interconnected.

NASA Systems Engineering

Handbook, SP-2007-6015, Revl,
December 2007 (Quoting Rechtin,
Systems Architecting of
Organizations: Why Eagles Can’t
Swim)

FIGURE 1.13 Evolving de nitions of a system as de ned by NASA, separated by 12 years.

(Courtesy of NASA.)

engineering, continues to evolve. The two quotes shown in Figure 1.13 show that
the de nition and understanding of systems engineering continue to evolve as
our systems become more complex. These quotes are from two different versions
of the NASA Systems Engineering Handbooks published over a 12-year period
(1995–2007).
 2 The System Life Cycle

Here systems engineering is focused on addressing why a system is needed, what the
system must do, and then how the system will accomplish the tasks over the entire
system life cycle from conception to disposal (Figure 2.1). Therefore, understand-
ing the system life cycle is important for systems engineers since many times only
the design phase is addressed in introductory engineering material. Being able to
implement a solution across the system life cycle is what forces systems engineers
to understand other areas of study, such as management, manufacturing, marketing,
sales, and customer support, since these areas all intersect with the system in the
life cycle. Figure 2.2 shows the system life cycle that most systems will go through.
While some systems may go through a phase of the cycle at a different rate than
another system, the phases remain the same. It is also important to point out that
while Figure 2.2 shows clear breaks between the phases, it almost never happens
this way in real life. In reality a systems engineer must be able to break a system
down into subsystems, components, or some other elements and move each piece of
the system through the process while also moving the whole system through the life
cycle. Taking this dual view of both the pieces and the whole is arguably one of the
most important skills of a systems engineer.
So how does this life cycle look in real life? We will use a dishwasher to show the
ow through a top-level life cycle (Figure 2.3). You may ask why it is important for
the systems engineer to consider the entire life cycle. While many engineers are only
trained in their speci c area of expertise (e.g., electrical, mechanical, manufactur-
ing, etc.), there needs to be someone to consider the entire system despite its stage
of development. For example, an electrical engineer is concerned with the power
system of a dishwasher. The machine has to work with household current and not
electrocute anyone. The systems engineer has to ensure the machine will meet the
customer needs, which may include being environmentally friendly. Think about
Figure 2.3 and consider the different hats the systems engineer must wear when
having discussions with the other members of the product team. An example of
questions the systems engineer needs to consider and address with speci c domain
engineers follows:

1. Environmental engineer: Is the dishwasher environmentally friendly?

2. Human factors engineer: Is the dishwasher easy to use?
3. Software engineer: Does the software control the dishwasher properly?
4. Fluid engineer: Does the dishwasher use the proper hose connectors?
5. Electrical engineer: Does the dishwasher support both the 60-Hz standard
used in the United States and the 50-Hz standard used in the rest of the world?
6. Safety engineer: Does the dishwasher sanitize the dishes to a safe bacterial
level without violating the other needs?

17
18 Systems Engineering Simplified

FIGURE 2.1 Cyclical. (Courtesy of PRESENTERMEDIA.)

Utilization, Disposal &

Conception Design Production Maintenance,
& Support Retirement

FIGURE 2.2 System life cycle.

Need more Customer replaces

energy & Company sets off Manufacturing Customer buys dishwasher and
water efficient to create best produces new and utilizes new disposes through a
dishwasher design dishwasher design dishwasher recycling program

FIGURE 2.3 Dishwasher life cycle.

You get the idea. While the development team should include many types of folks
trained in speci c areas, there must be a leader responsible for life cycle-driven deci-
sions and pressing forward. This person is usually a systems engineer. Therefore,
it is important for the systems engineer to understand the whole life cycle and not
just the design part (Figure 2.4). Just because the engineer is classically taught and
trained to design the very best product, it is not always the best engineered product
that sells. Balancing all aspects of the system is a trait of a successfully engineered
system.
The rest of this chapter will look at each of the life cycle phases in detail. We will
use the Vee chart to make the discussion more relevant.
The System Life Cycle 19

FIGURE 2.4 The systems engineer must be aware of other engineering discipline issues.
(Courtesy of PRESENTERMEDIA.)

2.1 MANAGING SYSTEM DEVELOPMENT—THE VEE MODEL

While there are different systems engineering methods, they appear to be different
avors of the same process. They can be “generalized as State the problem, Investigate
alternatives, Model the system, Integrate, Launch the system, Assess performance,
and Re-evaluate” (Bahill and Gissing 1998). Stating the problem addresses the why,
such as why a system is needed. Investigating alternatives and early modeling of the
system address the what, as in what the system must do. The process continues with
how the system will do what it must do, and then loops back to ensure the what and
why were properly addressed.
The Vee model (Figure 2.5) represents the basic process for developing a system.
On the left side of the Vee is the design and build phases of product development.
The right side of the Vee represents the integration, veri cation, and validation of
the parts into a complete system. The black dotted line in the middle of the Vee
model is approximately where the line of responsibility is divided between systems
engineering and those tasks handled by other engineering disciplines (i.e., electrical,
mechanical, software, etc.). For any Vee, the phases on the right side match up with
the appropriate level of requirements on the left side to ensure they are veri ed and
validated.
The Vee model can be used on projects of differing complexity and can be iter-
ated by moving back up or down the Vee as needed. Actually, separate Vee models
20 Systems Engineering Simplified

Concept of
Operations & System

Deco
Stakeholder Demonstration
Requirements & Validation Systems

mpo
Engineering

iltu
Domain

en b
io n
s it
ion

grat

e
System

as b
System
Defi

Architecture &

Inte
Integration &
Requirements

at h
Verification
ne w

e wh
hat

lidat
to

Component Component
bu i l

va
Design Integration &

and
Test
d

rif y,
Component
Engineering

e, ve
Procure,
Domain

grat
Fabricate, &
Assemble Parts
Inte

FIGURE 2.5 The systems engineering Vee model.

can be applied to each phase of the overall Vee model. For example, in the concept
of operations and stakeholder requirements phase, there may be an entire Vee
model to design, implement, and validate the concept of operations and stakeholder
requirements.
In the next few sections the roles and responsibilities at each step of the Vee
model will be discussed along with the description of each step.

2.1.1 CONCEPTS AND STAKEHOLDER REQUIREMENTS

Systems engineering commences when a need is identi ed in the form of a new or
improved capability, or to provide a missing capability. First, the systems engineer
identi es all the stakeholders associated with the need and capability. Then the sys-
tems engineer can work with the appropriate stakeholders to de ne the true need and
not unjusti ed wants. This need will form the basis for an initial concept. The con-
ception phase of the system life cycle (Figure 2.6) is the time from the initial concepts
or identi cation of a need to the time formal design begins.
This phase includes concept de nition, concept selection, proof of concept, and
documenting what the stakeholder wants (customer/stakeholder requirements).
The main goals during this phase should be to understand what the stakeholders
really want, and the opportunities and risks of moving forward to the design phase.
The system conception phase can be the hardest phase for many because it may
require the systems engineer to be a visionary and make predictions for months or
years down the path. Systems engineers can nd it easy to get stuck in this phase
and not want to move on until the risk of moving forward is viewed to be very
minor. It becomes important during the conception phase to understand what you
do not know and to make sure what you do know holds true for the system. A quote
The System Life Cycle 21

Concept of
Operations & System

Deco
Stakeholder Demonstration
Requirements & Validation Systems

mpo
Engineering

t
buil
Domain

io n
sit

been
ion

grat
System
System
Architecture &

ha s
Defi

Inte
Integration &
Requirements Verification

ha t
ne w

ate w
hat

alid
to

Component Component
bu i l

Integration &

nd v
Design
Test
d

ify, a
Component

r
Engineering

e, ve
Procure,
Domain

grat
Fabricate, &
Assemble Parts
Inte

FIGURE 2.6 The rst phase of the Vee.

by Mark Twain to remember during the conception phase is “It ain’t what you don’t
know that gets you into trouble. It’s what you know for sure that just ain’t so.” Many
times early in the conception phase engineers will believe that a risk has been elimi-
nated because they believe they have gured out the issue in every detail. Yet when
design begins, the system behaves very differently as soon as an unexpected variable
is changed or put into play. The systems engineer must do a good job of understand-
ing what is known and what is not known and be careful of making assumptions that
just are not true.
Starting at this early phase, the systems engineer is responsible for knowing the
technical opportunities and risks of moving forward. He or she must always be on
the lookout for new risks—things that would be bad if they were to occur during
the development of the product. The systems engineer documents these risks and
opportunities so they can be considered, and hopefully xed or exploited, as soon
as possible. One thing to remember, at every phase, is that the systems engineer is
expected to interface with the management team and ensure the proposed system
continues to address the real problem or need (Figure 2.7).
Upon completion of identifying and documenting the need or opportunity, the
systems engineer develops an initial system concept. The nancial stakeholders
may require a proof of concept (maybe a prototype or model) before authorizing the
project to begin in earnest.
Once the proof of concept is complete, or at least understood, work on a con-
cept of operations (CONOPS) should begin. The CONOPS is usually a set of
scenarios or use cases that demonstrate how the completed system will be used.
It may be as simple as a single-page description, a storyboard, or an elaborate
simulation. The CONOPS should include scenarios from all phases of the life
cycle and answer the questions “How will the system be used?” and “Who will
22 Systems Engineering Simplified

FIGURE 2.7 Man with telescope. (Courtesy of PRESENTERMEDIA.)

use the system when?” However, the CONOPS does not describe how to develop
the system or how it works. Once the systems engineer understands how the cus-
tomer wants to use the system, then he or she can start writing the stakeholder
requirements.
Continuing with the dishwasher example, the systems engineer identi es the
operator, the service person, the house where the system will reside, the nancers
and managers of this project, and the developers of this system, as well as any
regulatory agencies that must approve the system for household use. The operator
wants to clean dishes, service the dishwasher, and install/uninstall the dishwasher.
Figure 2.8 shows how this can be drawn using the Systems Modeling Language
(SysML). This particular concept of operations (shown using a use case diagram)
illustrates the actors of the system and demonstrates the concept of maintaining
the dishwasher once it has been installed in a customer’s home. The actors in this
case are the operator (homeowner), service person, and the house itself. The house
is an actor because it is also a system that provides something to the dishwasher
system, namely, water, power, drainage, and mechanical support. The operator and
house actors are involved with the actions of cleaning dishes, which include load-
ing and unloading dishes. The service person interacts with the operator and plays
a role with the actions of service, and installing and uninstalling the dishwasher.
While this is a simplistic concept of operation, it is important to start identifying
these types of interactions and what the system must do. The systems engineer uses
these higher-level details to identify and describe the necessary lower-level interac-
tions to continue developing the dishwasher.
The System Life Cycle 23

bdd System Use Cases [Dishwasher Use Cases]

Dishwasher

Clean Dishes

Operator House

«include» «include»

Load Dishes Unload Dishes

Service
Dishwasher

Service Person
Install/Uninstall
Dishwasher

FIGURE 2.8 Dishwasher operational concept (use case).

The requirements are elicited usually through the stakeholders (management,

marketing, end users, maintainers, homebuilders, etc.). A very brief sampling of
those stakeholder requirements from the example can be seen below. The stake-
holder requirements express what the actors and stakeholders deem the system
must accomplish to be successful (functions) and how well each function should
be accomplished (performance). These requirements may include the natural and
induced environments in which the system will operate and any known constraints.

1. The dishwasher must be energy ef cient.

2. It must connect to the standard water and power connections.
3. It should be easy to understand and have easy operator controls.
4. It needs to wash and dry kitchen items.
5. It must have different colored fronts to match different kitchen decors.
6. It must be quiet during operation.
7. It must be programmable so it can be run at some time in the future.
8. It should be easy to service.
9. It should hold the dishes, pots, pans, and utensils from a normal-sized meal.
24 Systems Engineering Simplified

Note the stakeholder requirements are usually very high level like the ones above.
However, a stakeholder requirement can be as explicit as using a speci c capacitor or
screw if for some reason the stakeholder will not be satis ed with any other option.
These types of low-level stakeholder requirements are often driven by compatibility,
historical supplier issues/solutions, or many other legitimate reasons and should be
vetted to ensure they are truly requirements. But the systems engineer needs to stay
alert for wants of the stakeholder rather than true requirements. If the stakeholder
asks for a super uous capacitor, the systems engineer must negotiate for what is best
overall. Adding an unnecessary feature can be done, but at an additional cost.
While the stakeholder may ask for too much, he or she may also ask for too little.
The stakeholder requirements may imply more than they state. For example, require-
ment 4 states the system needs to wash and dry kitchen items. The systems engineer
should determine that these kitchen items will be soiled by food, which may include
grease, fat, and even possibly mold—we have all found that forgotten piece of cake
in the back of our refrigerator. By requiring the system to wash the dishes, the stake-
holder is really saying the dishes will go in dirty but must come out dry and sanitized
so they can be used again safely.
Once the stakeholder requirements seem adequate, system requirements can
be developed. While stakeholder requirements specify what the system must do,
system requirements specify how the system shall accomplish those stakeholder
requirements.

2.1.2 SYSTEM REQUIREMENTS

During the system architecture and requirements phase (Figure 2.9), the stake-
holder requirements are analyzed, rewritten, and decomposed into well-formed
system requirements. Through in-depth discussions and analysis of all stakeholder
requirements, the systems engineer converts the stakeholder language into the

Concept of
Operations & System
Deco

Stakeholder Demonstration
Requirements & Validation Systems
m po

Engineering
iltu

Domain
en b
n
sitio

ratio

be

System
n

System
Defi

Architecture &
has
Inte

Integration &
Requirements
Verification
ne w

hat
ate w
hat
to b

alid

Component Component
uild

Integration &
v

Design
and

Test
rify,

Component
Engineering
e, ve

Procure,
Domain
grat

Fabricate, &
Assemble Parts
Inte

FIGURE 2.9 The second phase of the Vee.

The System Life Cycle 25

system speci cation. At this level, requirements are categorized (e.g., functional,
physical, performance, interface). Some of these requirements can move forward as
written, while others are broken into more detailed requirements.
When writing a system requirement, it should be written as a well-formed require-
ment statement. That means it is in the following form:

Subject + Verb + Modi er

A properly structured system requirement will de ne the system of interest, the

word shall (or in some places must), and then the description of what the system of
interest shall accomplish. Let us note here that the stakeholder requirements will
not usually be documented in this formal-looking format, but instead, they will be
captured in the customer’s voice. It is the systems engineer’s job to translate them
from the customer’s voice to formal system requirements. Examples of system
requirements for the dishwasher include:

• The dishwasher (subject) shall connect (verb) to a hot water supply (modi-
er). (Input)
• The dishwasher shall accept detergent. (Input)
• The dishwasher shall display an operational status indication. (Output)
• The dishwasher shall provide wastewater for disposal. (Output)
• The dishwasher shall accept a water temperature setting during mainte-
nance operation. (Maintenance)
• The dishwasher shall output a diagnostic status during installation/mainte-
nance operations. (Maintenance)
• The dishwasher shall t into a rough opening of 35 7/16 in. (90 cm) height.
(Installation)
• The dishwasher shall t into a rough opening of 23 5/8 in. (60 cm) width.
(Installation)
• The dishwasher shall t into a rough opening of 22 7/16 in. (57 cm) depth.
(Installation)
• The dishwasher shall be electrically grounded in compliance with the
National Electrical Code, latest edition of ANSI/NFPA 70, in the United
States or the Canadian Electrical Code, Part I, CSA Standard C22, in
Canada or the local National Electrical Code. (Installation)
• The dishwasher water shall obtain a temperature of at least 140°F. (Operation)
• The dishwasher shall clean dirty articles in 40 minutes or less. (Operation)

All system requirements must be considered (Figure 2.10). A recommended

approach is to consider all types of inputs and outputs for the system using an input/out-
put matrix. A partial set of dishwasher input/output requirements is shown in Table 2.1.
The result of this effort is an approved, well-de ned, controlled, and measured
collection of baseline requirements and veri cation methods for a product, as well as
a description of how the system will be used (concept of operations). We will explore
the veri cation and validation of requirements in greater detail in Chapter 5, but for
now suf ce it to say that there needs to be a way to ensure every requirement is met.
26 Systems Engineering Simplified

req Dishwasher Spec [Dishwasher Requirements]

Dishwasher E
Specification
E

Interface E Functional E Performance E Physical E Specialty E

Requirements Requirements Requirements Requirements Requirements

Electrical E Wash E Cleanliness E Size E

Cost E
Power

E Capacity E
Dry E Power Reliability E
Water Input E Efficiency

Aesthetics E E
Safety
Drainage E Noise Level E

Breakage E
Cycle Time E
User E
Interface Hazards E

FIGURE 2.10 Example system requirements speci cation outline.

TABLE 2.1
Input/Output Matrix Example for Dishwasher
Inputs Outputs
Intended Unintended Desired Undesired
Water Clean and High-pressure, rusty, Gravity ow of Over ow or
nominal pressure dirty water dirty water under ow
Electrical Nominal voltage Surge voltages Normal current Electric shock
Dishes Dirty kitchen Non-dishwasher- Sanitized Broken dishes
items and safe kitchen items kitchen items
utensils
Detergent Dishwasher Laundry or Rinsed items Suds, soapy lm,
detergent nondishwasher soap and spots
Environmental Normal Room Noise, vibrations,
household air temperature, highly humid air
dehumidi ed air

The requirements process is iterative, looping in reaction to design maturity, complex-

ity, and change. The process is closed loop since the requirements are not satis ed
or complete until the necessary veri cation methodologies are successfully executed
against the design solution(s). A tracking method is a requirements veri cation trace-
ability matrix (RVTM), which provides traceability from the requirement to the veri -
cation method in order to guarantee the requirement set is complete. The requirements
The System Life Cycle 27

allocation matrix should also provide traceability from the requirement to the system
component so it can be quickly identi ed where in the system each requirement is
being implemented. The RVTM also documents the associated veri cation method
for each requirement; we will talk more about veri cation methods in Section 5.6.

2.1.3 SYSTEM ARCHITECTURE

Since many organizations struggle with the concept of architecture, we have broken
it out into its own section. Yet we are continuing the discussion of the system archi-
tecture and requirements phase. In an attempt to avoid confusion, we will draw on
the work performed by a building architect to explain this concept. When a new
building is to be designed, the owners of the new building (stakeholders) meet with
the architect. They discuss the location of the building, the size of the building, the
number of oors the building is to have, the use of the building, and what kind of
building style the owner prefers (modern, art deco, gothic, etc.). All of these details
are what systems engineers call stakeholder requirements, as discussed in the con-
cept of operations and stakeholder requirements phase. From those requirements, the
architect begins the creation process, and the artifacts of that work are the architec-
tural drawings. These drawings may depict what the building might look like, loca-
tion plans, site plans, oor plans, and even some initial structural plans (Figure 2.11).
These plans are shared with the new building owner, and changes are made.

Typical Civil Architecture Plans

Presentation Drawings
 e sales pitch
Survey Drawings
 Location
 Drainage
Site Plan
Record Drawings
 As-built drawings - final versus sales pitch
Working Drawings
 Foundation plan
 Framing plan
 Floor plans
 Sections and interior elevations
 Schedules for windows and doors Two-point perspective
 Assembly drawings
 Component drawings
– Windows, closets, cabinets, etc.
Floor Plans
 Other trades: plumbing, electrical, etc.

FIGURE 2.11 Typical artifacts created during the building architecting process. (Site plan
from http://en.wikipedia.org/wiki/Architectural_drawing#mediaviewer/File:400_N_LSD_
site_plan.jpg. Floor plan from http://en.wikipedia.org/wiki/Architectural_plan#mediaviewer/
File:Sample_Floorplan.jpg. Building model from http://en.wikipedia.org/wiki/Architectural_
model#mediaviewer/File:Architectural_model_condo_highrise.jpg. Two-point perspective
from http://en.wikipedia.org/wiki/Architectural_drawing#mediaviewer/File:Dercy_House_
drawing-room1777.jpg.)
28 Systems Engineering Simplified

If one pauses to consider that a building is a system, these plans represent the system
architecture.
A typical top-level system architecture diagram may be a SysML block diagram
representing the major subsystems of that system of interest. Other diagrams might
show how the major parts interface with one another, how the system interfaces
with its operational environment, and any other pertinent details of the system in
its intended environment. The system architecting process begins by performing a
functional analysis of the stakeholder requirements, which is discussed in greater
detail in the next section. The functional analysis establishes the required functional
behavior of the system. While there are a number of important tasks that a sys-
tem architect should perform, Table 2.2 lists many of the signi cant tasks. While
performing these tasks, the system architect will create a number of diagrams and
models. A good starting point for those diagrams and models is shown in Table 2.3.
The system architecture and requirements phase demonstrates why systems engi-
neering is an iterative process. To develop a good system architecture, the systems
engineer must understand the system requirements. However, as the architecture is
developed, more detailed system requirements will be discovered and others will be

TABLE 2.2
Typical System Architecting Activities
• De ne a consistent logical architecture—capture the major logical elements and the
interaction between them.
• Partition system requirements and allocate them to system elements and subsystems
with associated performance requirements.
• Evaluate alternative design solutions using trade studies.
• De ne the system integration strategy and plan (to include human system integration).
• Establish and maintain the traceability between requirements and system elements.
• De ne veri cation and validation criteria for the system elements.

TABLE 2.3
Selected Artifacts Created during the Architecture Process
• De ne a consistent logical architecture—capture the logical sequencing and interaction of system
functions or logical elements.
• Partition system requirements and allocate them to system elements and subsystems with
associated performance requirements—evaluate off-the-shelf solutions that already exist.
• Evaluate alternative design solutions using trade studies.
• Identify interfaces and interactions between system elements (including human elements of the
system) and with external and enabling systems.
• De ne the system integration strategy and plan (to include human system integration).
• Document and maintain the architectural design and relevant decisions made to reach agreement
on the baseline design.
• Establish and maintain the traceability between requirements and system elements.
• De ne veri cation and validation criteria for the system elements.
The System Life Cycle 29

challenged to the real necessity. Therefore, these two tasks are usually done in short,
iterative, re ning cycles. It is not unusual for a systems engineer to be asked to add
capability to an existing system. For instance, a manufacturer of heavy equipment
may have a highly successful backhoe product, but it would be even better if the
backhoe could also be tted with a ditch-digging accessory. For the simplest exten-
sions to an existing system, the systems engineer may treat the existing system as a
black box, and then simply worry about how the new capability will interface with
the existing black box. As the complexity of the additional capabilities increases,
more advanced methods must be employed.

2.1.3.1 Functional Architecture

As the system progresses down the Vee’s left side of the system life cycle (see
Figure 2.9), the systems engineer determines what functions the system must per-
form. A function can be described as a discrete action (or series of actions) that
is necessary to accomplish a speci c objective or task. This function may be per-
formed by one or more parts of the system and may be grouped logically by time,
control, data, etc. The functional architecture therefore describes how a system is
organized by what the system does. Of course, two different systems engineers may
organize their functional architectures differently with similar yet different terms for
the functions. In any case, this architecture de nes what the system must do—the
capabilities or services it will provide and the tasks it will perform. It also provides a
description of the message/message type of communications between the functions,
as well as the data that are passed between functions.
The functional architecture is created as the systems engineer analyzes the
requirements and creates functions that might satisfy each requirement, or satisfy a
collection of requirements. This functional analysis includes:

• A list of the core functions and function performance requirements that

must be met in order to adequately accomplish the operation, support, test,
and production requirements of the system, i.e., life cycle of the system
• A method for analyzing performance requirements and dividing them into
discrete tasks or activities

While performing functional analysis and decomposition, the functions may be

grouped by logical groupings, time ordering, data ow, control ow, or some other
criterion. There are a number of tools and diagrams useful during functional analy-
sis, but they are beyond the scope of this booklet. However, we will list a few so that
you can look them up later if you desire. A partial list of tools and diagrams include
the following (Figure 2.12):

• IDEF0 diagram
• Functional ow block diagram (FFBD)
• N2 diagrams
• Timeline analysis
• Tree diagrams
• SysML (such as activity diagrams, sequence diagrams)
30 Systems Engineering Simplified

FIGURE 2.12 Engineer design. (From http://www.PresenterMedia.com/help.html.)

One common usage for functional decomposition is the IDEF0 (pronounced

I-DEF-zero). IDEF0 is a compound acronym (ICAM De nition for Function
Modeling, where ICAM is an acronym for integrated computer-aided manufacturing)
associated with manufacturing functions. It offers a functional modeling language
for the analysis, development, reengineering, and integration of information systems;
business processes; or software engineering analysis (DAU 2001). In IDEF0, inputs
always enter a function from the left, outputs always exit to the right, enablers enter
from the bottom, and triggers enter from the top (Figure 2.13). The function in the
box represents some transformation.
For the dishwasher, the top-level function may be to “clean dirty kitchen items.”
This single function shown in Figure 2.14 can now be broken into smaller subfunc-
tions (decomposed). If the main purpose, or function, of a dishwasher is to clean
dirty kitchen items, then the dishwasher is the resource, or enabler, for the function.
As we said, the enablers are represented by an arrow entering the function from
the bottom. Required inputs, represented by arrows entering from the left, are dirty
kitchen items, water, soap, etc. Examples of what this function outputs include clean
kitchen items, dirty water, and heat. Finally, commands are the trigger that initiate
this function, and therefore come in from the top.
Using the IDEF0, the next task is to determine what collection of subfunctions
could satisfy this function. The totality of these subfunctions must encompass all
that is implied by the level above, in this case, “clean dirty kitchen items.” To com-
plete Figure 2.15, the systems engineer must identify the necessary inputs, outputs,
resources, and triggers that would allow the subfunctions to work with one another
to satisfy the system mission.
The System Life Cycle 31

Constraints &
Triggers

Function
Inputs (Described as a Outputs
verb-noun pair)

Resources

FIGURE 2.13 The IDEF0 diagram.

Operator
controls

Dirty kitchen Clean kitchen

items items
Clean dirty Waste water
Water
kitchen items Heat
Cleaning Status
agent Mechanical
force

Dishwasher

FIGURE 2.14 Top-level function for a dishwasher.

A nal note: When working on the functional (or logical, as it is sometimes

called) architecture, try not to represent functions with physical names. For instance,
do not talk about a valve; instead, maybe call it a uid control device. Physical names
will cause confusion when you transition from the logical architecture to the physical
architecture, which will have physical names.

2.1.3.2 Physical Architecture

The physical system architecture is a collection of graphical depictions of the system
of interest under consideration. The physical architecture de nes the partitioning of
the system resources (hardware and software) needed to perform the functions.
It should also show the interconnections between other systems, and between the
subsystems. There should be a diagram representing the functional architecture allo-
cated to the physical entities, since every item performs some function for the system.
32 Systems Engineering Simplified

Hold kitchen
items

Control
dishwasher

Wash
kitchen
items

Dry kitchen
items

Support
dishwasher
maintenance

FIGURE 2.15 Example of possible dishwasher subfunctions.

2.1.4 COMPONENT DESIGN

The component design phase begins when formal requirements have been developed
and the system architecture is de ned (Figure 2.16). From the physical architecture,
the subsystems have been identi ed, and the system requirements have been allo-
cated to those subsystems. Formal requirements are the source of system veri cation,
which will be discussed later. While system veri cation to requirements is de nitely
warranted, this phase may or may not include system validation. Nonetheless, this
phase is usually long, and it is the main phase for all the traditional engineering
disciplines. Component design ends when the system is ready for production.
During the component design phase the systems engineer will be expected to
support the entire engineering team. He or she should continue to be the visionary for
the overall system during the ongoing engineering process. Consequently, the design
phase requires the systems engineer to work closely with and respect all engineering
disciplines on the design team. In addition, the systems engineer will be required
to make interface decisions and to resolve trade-offs between different subsystems
of the overall system (Figure 2.17). As always, the systems engineer should remain
cautious of becoming arrogant regarding the system, but instead rely on the whole
team of engineers. Working together and listening to each other, the entire team can
make sure the decisions, risk, and opportunities that were determined in the concep-
tion phase are holding true.
A recurring theme, the systems engineer should ensure the system design is not
straying from the original system concept and architecture. Many times during the
system design the system concept is, for lack of better words, “thrown out the win-
dow.” Unfortunately, many systems fail because they do not meet the original needs
The System Life Cycle 33

Concept of
Operations & System

Deco
Stakeholder Demonstration
Requirements & Validation Systems

mpo
Engineering

iltu
Domain

en b
ion
s it
ion

g rat

e
System

as b
System
Defi

Architecture &

Inte
Integration &
Requirements

at h
Verification
ne w

e wh
hat

lidat
to

Component Component
bu i l

va
Design Integration &

and
Test
d

rif y,
Component
Engineering

e, ve
Procure,
Domain

grat
Fabricate, &
Assemble Parts
Inte

FIGURE 2.16 Third phase of the Vee.

System/
Communication Component
Subsystem
is Key Team
Team

FIGURE 2.17 Communication is key.

of the stakeholders. Validation attempts to prevent this failure, and we will discuss
validation later in this chapter and more thoroughly in Section 5.7.

2.1.5 PROCURE, FABRICATE, AND ASSEMBLE PARTS

The procure, fabricate, and assemble parts phase occurs partly in parallel with
component design. As the design is developed, the thought of how the part is going
to be procured, fabricated, and assembled should be part of the design discussions.
It would be useless to design a part that cannot be procured, fabricated, or assembled
into the system or that is so expensive it does not meet the cost goals of the product.
Many engineers have the attitude that anything can be done, which has some truth
to it, but that attitude must be managed within the stakeholder requirements.
At the end of the procure, fabricate, and assemble parts step, the components
should be ready for integration with other parts and ready for the veri cation process.

2.1.6 COMPONENT INTEGRATION AND TEST

The component integration and test phase begins once the components have been
fabricated and assembled (Figure 2.18). Components are integrated with one another
until the complete system is assembled.
34 Systems Engineering Simplified

Concept of
Operations & System

D e co
Stakeholder Demonstration
Requirements & Validation Systems

mpo
Engineering

il t
u
Domain

en b
n
sitio

ratio

be
System

n
System
Defi

g
Architecture &

has
Inte
Integration &
Requirements
Verification
ne w

hat
te w
hat

lida
to

Component Component
bu i l

a
Integration &

nd v
Design
Test
d

a
rify,
Component
Engineering

e, ve
Procure,
Domain

grat
Fabricate, &
Assemble Parts

Inte

FIGURE 2.18 Fifth phase of the Vee.

Integration Part 3 = Subsystem 1

In
te
gr
at
Integration Part 2 = New Part Y e

New Part X

Component 3 Integration Step 1 = New Part X

Component 4
New Part Y Component 1 Component 2
Component 5

FIGURE 2.19 Example integration plan.

Prior to this step, an integration plan should be developed to describe when and
how each component will be integrated. There should also be a veri cation plan to
test the components as they are integrated with one another. A good integration plan
calls for testing during integration and not just the integration of all the components
at once before beginning the veri cation process (Figure 2.19). It is often very dif-
cult to determine the source of issues once component integration is complete.

2.1.7 SYSTEM INTEGRATION AND VERIFICATION

In any systems engineering effort, there are system physical components (such as
hardware items, software items, constituent systems within a system of systems, or
the human systems that interact with the system) and functional/logical components
The System Life Cycle 35

Concept of
Operations & System

Deco
Stakeholder Demonstration
Requirements & Validation Systems

mpo
Engineering

iltu
Domain

en b
io n
siti
on

grat

e
System

as b
System
Defi

Architecture &

Inte
Integration &
Requirements

at h
Verification
ne w

e wh
hat

lidat
to

Component Component
bu i

va
Design Integration &
ld

and
Test

rif y,
Component
Engineering

e, ve
Procure,
Domain
grat
Fabricate, &
Assemble Parts Inte

FIGURE 2.20 Sixth phase of the Vee.

(such as algorithms and system processes, operator processes, or business processes).

Both sets of components must work together for the entire system to succeed. System
integration and veri cation is the phase that emphasizes the assembly of parts into a
system that meets the system requirements (Figure 2.20). System integration uni es
the system physical components and the functional/logical components into a whole
(Figure 2.21). It ensures that the hardware, software, and human system components
interact to achieve the system purpose and satisfy the customer’s need.
Veri cation con rms the system of interest and its elements meet the speci ed
system requirements. In other words, it asks the question: Was the system built right?
The validation step will then answer the question if the right system was built.

2.1.8 SYSTEM DEMONSTRATION AND VALIDATION

Validation con rms the completed system in its intended environment satis es or
will satisfy the stakeholders’ needs. It determines a system does everything it should
and nothing it should not do. In other words, it asks the question: Did we build the
right system?
Although represented only on the right side of the Vee model (Figure 2.22), there
are two important periods of time when validation should be performed. Product
validation con rms the completed system meets its intended purpose. Early valida-
tion ensures the stakeholder requirements and concept of operations meet the needs
of the stakeholder. Often the stakeholders express what they want rather than what
they need. Even more likely, the stakeholders are not able to effectively communi-
cate what they need. Early validation mitigates this problem and attempts to ensure
the true need is captured.
36 Systems Engineering Simplified

Integration Step C = System

In
te
gr
at
Subsystem e
1 Integration Step B

Subsystem
2 Subsystem Integration Step A
3
Subsystem
3
Subsystem Subsystem 1 Subsystem 2
Subsystem 4
4

FIGURE 2.21 System integration example.

Concept of
Operations & System
Deco

Stakeholder Demonstration
Requirements & Validation Systems
mpo

Engineering
iltu

Domain
en b
io n
s it
ion

grat

System
as b

System
Defi

Architecture &
Inte

Integration &
Requirements
h

Verification
ne w

hat
ate w
hat
to b

alid

Component Component
uild

Integration &
v

Design
and

Test
rif y,

Component
Engineering
e, ve

Procure,
Domain
grat

Fabricate, &
Assemble Parts
Inte

FIGURE 2.22 Seventh phase of the Vee.

2.2 SYSTEM PRODUCTION

There are a few additional phases after the system has gone through the Vee model
of design and build. The system production phase begins once the system has been
validated and handed off to manufacturing for production of the product. The sys-
tems engineering responsibility during this phase is a support and oversight role.
The systems engineer should have worked with manufacturing during the design
to guarantee the product is designed for manufacturability. During manufacturing,
The System Life Cycle 37

the systems engineer should continue to make sure the product is manufactured as
desired and ensure that liberties on changing the product (i.e., part changes, etc.)
are not taken by the manufacturing team. The systems engineer should also be a
reviewer of any production test plans. Keeping the systems engineer in the loop
during this time can avoid issues that arise from the nal product not meeting its
intentions.

2.3 SYSTEM UTILIZATION AND SUPPORT

The system utilization phase begins once the production level product is elded
to the end user. Usually by this phase the systems engineer becomes a monitor
of the product. During this phase eld engineers and sales representatives are the
closest people to the product. The systems engineer should be seen as a shepherd
of the product and kept in the loop since he or she will have invaluable knowledge of
the product, allowing him or her to be helpful in the debugging of any system issues.
Also keeping the systems engineer linked to the product in the eld can be invalu-
able in learning lessons for the next generation of the product.
During this phase is when the true validation of the product can happen since the
system will have its rst real chance to meet its need. While validation is attempted
during design to decrease the risk of product failure, the most complete validation
can only be done when the manufactured nal product is elded with end users. This
nal validation is the ultimate stamp if the right system was built. Accordingly, the
systems engineer should be involved in any feedback from the end user.
Once the product has been in the eld and utilized, the engineering support for
the system will decrease, but the systems engineer should stay involved in issues as
they are found. During this support role the systems engineer could have invaluable
solutions and knowledge to support eld engineers, sales, and customers.

2.4 SYSTEM RETIREMENT AND DISPOSAL

The system retirement and disposal phase begins when the system is ultimately
taken out of service until the time the system is properly disposed. The systems
engineer still serves a support role and helps assure the system is properly retired and
disposed. A good system design should have included plans for disposal and retire-
ment, and the systems engineer should be available to answer any questions related
to these plans, such as the intent and process of the disposal. If the system is part of
another system, the retirement might require speci c processes to avoid impacting
the other system, and the systems engineer should be available to answer questions
on how the retirement was designed.
 3 Other Systems
Engineering
Development Models

The Vee development model has been used to discuss the various general tasks
performed by systems engineers. It is now time to address a few of the other
development models that are in use today. The rst one that will be discussed is
the spiral model, which was created for software development in the late 1980s but
is currently widely used in system development. The second one is a more recently
developed model that uses an agile process.

3.1 SPIRAL MODEL

The spiral model is an iterative process that was rst developed for software
development. The iterative nature of the process makes it ideal for large system devel-
opment. The process starts in the center of the determine objectives, alternatives, and
constraints quadrant of the spiral in Figure 3.1, and then moves clockwise and out-
ward. There are four main phases of each cycle through the process: (1) determine
objectives, alternatives, and constraints; (2) evaluate alternatives—identify and
resolve risks; (3) develop and verify next level project; and (4) plan next phase. One
of the bene ts of the spiral model is that before the start of a new cycle there is a
review and commitment to move forward.
The spiral model (Figure 3.1) incorporates the waterfall model, which is an
older, sequential design process. The waterfall model has fallen out of favor since
it assumes every phase is fully complete and correct before moving on. Even under
ideal conditions, new information may become available between the initial systems
concept and producing it. Therefore, the various system models now incorporate
iterations, although in different ways. The spiral model is an iterative process that
also adds risk analysis, prototyping, and planning. It is also better for larger system
development since pieces (subsystem, component, etc.) of the system that are higher
risk can be developed earlier in the process and then assessed before moving forward
to the next iteration.

3.2 AGILE MODEL FOR SYSTEMS ENGINEERING

The agile model known as scrum is shown in Figure 3.2. The model is performed
in an iterative nature with feedback from the stakeholders after an iteration of the
process model. One of the main properties with the agile method is the concept of

39
40 Systems Engineering Simplified

Cumulative cost
1. Determine Progress 2. Identify and
objective resolve risks

Operational
Review Requirements
plan Prototype 1 Prototype 2 prototype
Concept of Concept of
operation requirements
Detailed
Draft
Requirements design

Development Verification Code

plan & Validation

Integration
Test plan Verification
& Validation
Test
Implementation
4. Plan the Release
next iteration 3. Development
and Test

FIGURE 3.1 Spiral development model. (From http://commons.wikimedia.org/wiki/

File:Spiral_model_%28Boehm,_1988%29.svg.)

Product Backlog Daily

Storyboarding Meetings

Sprint Backlog Sprint review

meeting
Sprint
Release

Feedback

Stakeholders

FIGURE 3.2 Agile scrum process.

sprints, which are set time limits usually in the time frame of a few weeks. This idea
of setting time limits and pushing through the process helps to assure the progression
of the system development, which in other models can become stalled.
The rst step in the agile scrum model is storyboarding. The idea of storyboard-
ing is similar to use case development, but the storyboard is usually more visual
Other Systems Engineering Development Models 41

1-Rinse dishes 2-Load dishwasher 3-Add soap

5-Empty
4-Run dishwasher dishwasher

FIGURE 3.3 Storyboard showing how to use a dishwasher.

(versus the textual nature of use cases). Keeping with our example of a dishwashing
machine, an example of storyboarding is shown in Figure 3.3. From the example,
one can see how a system will be utilized over time. Like use cases and operational
concepts, there will be more than one storyboard for a system, but each sprint cycle
of the process may focus on only one storyboard.
The second step is the product backlog, which is similar to the requirements
elicitation discussed in Chapter 2. The system requirements are developed in this
step. Then a portion of the requirements or product backlog is selected for the sprint
cycle, which is called the sprint backlog. Once chosen, the sprint begins. The sprint
is the design cycle and contains daily meetings to discuss the current status of the
sprint. At the end of the sprint, there is a review of only the nished work (or release)
with the stakeholders. Feedback from the stakeholders is incorporated back into
the product backlog, and the process repeats until all the product backlog has been
addressed.
There are many other systems engineering development models in use today.
Although we have only discussed a few of them, we hope these examples give an
idea of why different ones are needed depending on the situation. We encourage
the reader to nd out what development model is in use where he or she works or is
interested in working.