1. NASA
Systems
Engineering
Handbook
SP-610S
June 1995

2. NASA Systems Engineering Handbook Page ii
Foreword from a systems perspective, starting at mission needs and
conceptual studies through operations and disposal.
In an attempt to demonstrate the potential
While it would be impossible to thank all of the
dangers of relying on purely ''cookbook" logical
people directly involved, it is essential to note the efforts of
thinking, the mathematician/philosopher Carl Hempel Dr. Robert Shishko of the Jet Propulsion Laboratory. Bob
posed a paradox. If we want to prove the hypothesis was largely responsible for ensuring the completion of this
“AII ravens are black," we can look for many ravens effort. His technical expertise and nonstop determination
and determine if they all meet our criteria. Hempel were critical factors to ensure the success of this project.
suggested changing the hy –pothesis to its logical
contrapositive (a rewording with identical meaning) Mihaly Csikzenthmihali defined an optimal
would be easier. The new hypothesis becomes: "All experience as one where there is "a sense of exhilaration, a
deep sense of enjoyment that is long cherished and
nonblack things are nonravens." This transformation,
becomes a landmark in memory of what life should be like." I
supported by the laws of logical thinking, makes it am not quite sure if the experience which produced this hand
much easier to test, but unfortunately is ridiculous. –book can be described exactly this way, yet the sentiment
Hempel's raven paradox points out the importance of seems reasonably close.
common sense and proper background exploration,
even to subjects as intricate as systems engineering. —Dr. Edward J. Hoffman
Program Manager, NASA Headquarters
In 1989, when the initial work on the NASA Systems Spring 199
Engineering Handbook was started, there were many
who were concerned about the dangers of a
document that purported to teach a generic NASA
approach to systems engineering. Like Hempel's
raven, there were concerns over the potential of
producing a "cookbook" which of fered the illusion of
logic while ignoring experience and common sense.
From the tremendous response to the initial
(September 1992) draft of the handbook (in terms of
both requests for copies and praise for the product), it
seems early concerns were largely unfounded and
that there is a strong need for this handbook.
The document you are holding represents what
was deemed best in the original draft and updates
information necessary in light of recommendations and
changes within NASA. This handbook represents some of
the best thinking from across NASA. Many experts
influenced its outcome, and consideration was given to each
idea and criticism. It truly represents a NASA-wide product
and one which furnishes a good overview of NASA systems
engineering.
The handbook is intended to be an educational
guide written from a NASA perspective. Individuals who take
systems engineering courses are the primary audience for
this work. Working professionals who require a guidebook to
NASA systems engineering represent a secondary
audience.
It was discovered during the review of the draft
document that interest in this work goes far beyond NASA.
Requests for translating this work have come from
international sources, and we have been told that the draft
hand book is being used in university courses on the subject.
All of this may help explain why copies of the original draft
handbook have been in short supply.
The main purposes of the NASA Systems
Engineering Handbook are to provide: 1) useful information
to system engineers and project managers, 2) a generic
description of NASA systems engineering which can be
supported by
center-specific documents, 3) a common language and
perspective of the systems engineering process, and 4) a
reference work which is consistent with NMI 7120.4/NHB
7120.5. The handbook approaches systems engineering

3. NASA Systems Engineering Handbook Page iii
Foreword to the September 1992 Draft As such, this present document is to be
considered a next-to-final draft. Your comments,
When NASA began to sponsor agency – corrections and suggestions are welcomed, valued
wide classes in systems engineering, it was to a and appreciated. Please send your remarks directly to
doubting audience. Top management was quick to Robert Shishko, NASA Systems
express concern. As a former Deputy Administrator Engineering Working Group. NASA/Jet Propulsion
stated "How can you teach an agency-wide systems Laboratory, California Institute of Technology,
engineering class when we cannot even agree on 4800 Oak Grove Drive, Pasadena, CA
how to define it?" Good question, and one I must 91109-8099.
admit caused us considerable concern at that time. —Francis T. Hoban
The same doubt continued up until the publication of Program Manager, NASA Headquarters
this handbook.
The initial systems engineering education
conference was held in January 1989 at the Johnson
Space Center. A number of representatives from
other Centers at tended this meeting and it was
decided then that we needed to form a working group
to support the development of appropriate and
tailored systems engineering courses. At this meeting
the representatives from Marshal1 Space Flight
Center (MSFC) expressed a strong desire to docu
ment their own historic systems engineering process
before any more of the key players left the Center.
Other Centers also expressed a desire, if not as
urgent as MSFC, to document their processes.
It was thought that the best way to reflect the
totality of the NASA systems engineering process and
to aid in developing the needed training was to
prepare a top level (Level 0) document that would
contain a broad definition of systems engineering, a
broad process outline, and typi cal tools and
procedures. In general, we wanted a top level
overview of NASA systems engineering. To this
document would be appended each Center's unique
systems engineering manual. The group was well
aware of the diversity each Center may have, but
agreed that this approach would be quite acceptable.
The next step and the most difficult in this
arduous process was to find someone to head this
yet-to-be-formed working group. Fortunately for
NASA, Donna [Pivirotto] Shirley of the Jet Propulsion
Laboratory stepped up to the challenge. Today,
through her efforts, those of the working group, and
the skilled and dedicated authors, we have a unique
and possibly a historic document.
During the development of the manual we
decided to put in much more than may be appropriate
for a Level 0 document with the idea that we could
always refine the document later. It was more
important to capture the knowledge when we could in
order to better position our selves for later
dissemination. If there is any criticism, it may be the
level of detail contained in the manual, but this detail
is necessary for young engineers. The present
document does appear to serve as a good
instructional guide, although it does go well beyond its
original intent.

5. NASA Systems Engineering Handbook Page 5
Preface JSC-49040. The SEPIT project life cycle is
intentionally consistent with that in NMI 7120.4/NHB
This handbook was written to bring the 7120.5 (Management of Major System Programs and
fundamental concepts and techniques of systems Projects), but provides more detail on its systems
engineering to NASA personnel in a way that engineering aspects.
recognizes the nature of NASA systems and the
NASA environment. The authors readily acknowledge This handbook consists of five core
that this goal will not be easily realized. One reason is chapters: (1) systems engineering's intellectual
that not everyone agrees on what systems process, (2) the NASA project life cycle, (3)
engineering is, nor on how to do it. There are management issues in systems engineering, (4)
legitimate differences of opinion on basic definitions, systems analysis and modeling issues, and (5)
content, and techniques. Systems engineering itself is engineering specialty integration. These core
a broad subject, with many different aspects. This chapters are supplemented by appendices, which can
initial handbook does not (and cannot) cover all of be expanded to accommodate any number of
them. templates and examples to illustrate topics in the core
chapters. The handbook makes extensive use of
The content and style of this handbook show sidebars to define, refine, illustrate, and extend
a teaching orientation. This handbook was meant to concepts in the core chapters without diverting the
accompany formal NASA training courses on systems reader from the main argument. There are no
engineering, not to be a stand-alone, comprehensive footnotes; sidebars are used instead. The structure of
view of NASA systems engineering. Systems the handbook also allows for additional sections and
engineering, in the authors' opinions, cannot be chapters to be added at a later date.
learned simply by starting at a well-defined beginning Finally, the handbook should be considered only a
and proceeding seamlessly from one topic to another. starting point. Both NASA as a systems engineering
Rather, it is a field that draws from many engineering organization, and systems engineering as a discipline,
disciplines and other intellectual domains. The are undergoing rapid evolution. Over the next five
boundaries are not always clear, and there are many years, many changes will no doubt occur, and some
interesting intellectual offshoots. Consequently, this are already in progress. NASA, for instance, is
handbook was designed to be a top-level overview of moving toward implementation of the standards in the
systems engineering as a discipline; brevity of International Standards Organization (ISO) 9000
exposition and the provision of pointers to other books family, which will affect many aspects of systems
and documents for details were considered important engineering. In systems engineering as a discipline,
guidelines. efforts are underway to merge existing systems
engineering standards into a common American
The material for this handbook was drawn National Standard on the Engineering of Systems,
from many different sources, including field center and then ultimately into an international standard.
systems engineering handbooks, NASA management These factors should be kept in mind when using this
instructions (NMls) and NASA handbooks (NHBs), handbook
field center briefings on systems engineering
processes, non-NASA systems engineering textbooks
and guides, and three independent systems
engineering courses taught to NASA audiences. The
handbook uses this material to provide only top-level
information and suggestions for good systems
engineering practices; it is not intended in any way to
be a directive.
By design, the handbook covers some topics
that are also taught in Project Management/Program
Control (PM/PC) courses, reflecting the unavoidable
connectedness
of these three domains. The material on the NASA
project life cycle is drawn from the work of the NASA-
wide Systems Engineering Working Group (SEWG),
which met periodically in 1991 and 1992, and its
successor, the Systems Engineering Process
Improvement Task (SEPIT) team, which met in 1993
And 1994. This handbook's project life cycle is
identical to that promulgated in the SEPIT report,
NASA Systems
Engineering Process for Programs and Projects,

6. NASA Systems Engineering Handbook Page 6
Acknowledgements Mr. Don Woodruff, NASA/Marshall Space Flight
This work was conducted under the overall direction Center
of Mr. Frank Hoban, and then Dr. Ed Hoffman, NASA
Headquarters/Code FT, under the NASA Pro- Other Sources:
gram/Project Management Initiative (PPMI). Dr. Mr. Dave Austin, NASA Headquarters/Code DSS
Shahid Habib, NASA Headquarters/Code QW, Mr. Phillip R. Barela, NASA/Jet Propulsion Laboratory
provided additional financial support to the NASA- Mr. J.W. Bott, NASA/Jet Propulsion Laboratory
wide Systems Engineering Working Group and Dr. Steven L. Cornford, NASA/Jet Propulsion
Systems Engineering Process Improvement Task Laboratory
team. Many individuals, both in and out of NASA, Ms. Sandra Dawson, NASA/Jet Propulsion Laboratory
contributed material, reviewed various drafts, or Dr. James W. Doane, NASA/Jet Propulsion
otherwise provided valuable input to this handbook. Laboratory
Unfortunately, the lists below cannot include everyone Mr. William Edminston, NASA/Jet Propulsion
who shared their ideas and experience. Laboratory
Mr. Charles C. Gonzales, NASA/Jet Propulsion
Principal Contributors: Laboratory
Dr. Robert Shishko, NASA/Jet Propulsion Laboratory Dr. Jairus Hihn, NASA/Jet Propulsion Laboratory
Mr. Robert G. Chamberlain, P.E., NASA/Jet Dr. Ed Jorgenson, NASA/Jet Propulsion Laboratory
Propulsion Laboratory Mr. Richard V. Morris, NASA/Jet Propulsion
Laboratory
Other Contributors: Mr. Tom Weber, Rockwell International/Space
Mr. Robert Aster, NASA/Jet Propulsion Laboratory Systems
Ms. Beth Bain, Lockheed Missiles and Space
Company Reviewers:
Mr. Guy Beutelschies, NASA/Jet Propulsion Mr. Robert C. Baumann, NASA/Goddard Space Flight
Laboratory Center
Dr. Vincent Bilardo, NASA/Ames Research Center Mr. Chris Carl, NASA/Jet Propulsion Laboratory
Ms. Renee I. Cox, NASA/Marshall Space Flight Dr. David S.C. Chu, Assistant Secretary of
Center Defense/Pro-gram
Dr. Kevin Forsberg, Center for Systems Management Analysis and Evaluation
Dr. Walter E. Hammond, Sverdrup Techology, Inc. Mr. M.J. Cork, NASA/Jet Propulsion Laboratory
Mr. Patrick McDuffee, NASA/Marshall Space Flight Mr. James R. French, JRF Engineering Services
Center Mr. John L. Gasery, Jr., NASA/Stennis Space Center
Mr. Harold Mooz, Center for Systems Management Mr. Frederick D. Gregory, NASA Headquarters/Code
Ms. Mary Beth Murrill, NASA/Jet Propulsion Q
Laboratory Mr. Don Hedgepeth, NASA/Langley Research Center
Dr. Les Pieniazek Lockheed Engineering and Mr. Jim Hines, Rockwell International/Space Systems
ScienceS Mr. Keith L. Hudkins, NASA Headquarters/Code MZ
Co. Mr. Lou Polaski, Center for Systems Management Dr. Jerry Lake, Defense Systems Management
Mr. Neil Rainwater, NASA/Marshall Space Flight College
Center Mr. T.J. Lee, NASA/Marshall Space Flight Center
Mr. Tom Rowell, NASA/Marshall Space Flight Center Mr. Jim Lloyd, NASA Headquarters/Code QS
Ms. Donna Shirley, NASA/Jet Propulsion Laboratory Mr. Woody Lovelace, NASA/Langley Research
Mr. Mark Sluka, Lockheed Engineering and Sciences Center
Co. Mr. Ron Wade, Center for Systems Management Dr. Brian Mar, Department of Civil Engineering,
SEPIT team members (not already mentioned): University
Mr. Randy Fleming, Lockheed Missiles and Space of Washington
Co. Dr. Ralph F. Miles, Jr., Center for Safety and System
Dr. Frank Fogle, NASA/Marshall Space Flight Center Management, University of Southern California
Mr. Tony Fragomeni, NASA/Goddard Space Flight Dr. Richard A. Montgomery, Montgomery and
Center Dr. Shahid Habib, NASA Headquarters/Code Associates
QW Mr. Bernard G. Morais, Synergistic Applications, Inc.
Mr. Henning Krome, NASA/Marshall Space Flight Mr. Ron Moyer, NASA Headquarters/Code QW
Center Mr. Rudy Naranjo, NASA Headquarters/Code MZ
Mr. Ray Lugo, NASA/Kennedy Space Center Mr. Raymond L. Nieder, NASA/Johnson Space
Mr. William C. Morgan, NASA/Johnson Space Center Center
Dr. Mike Ryschkewitsch, NASA/Goddard Space Flight Mr. James E. Pearson, United Technologies
Center Research
Mr. Gerry Sadler, NASA/Lewis Research Center Center
Mr. Dick Smart, Sverdrup Technology, Inc. Mr. Leo Perez, NASA Headquarters/Code QP
Dr. James Wade, NASA/Johnson Space Center Mr. David Pine, NASA Headquarters/Code B
Mr. Milam Walters, NASA/Langley Research Center

7. NASA Systems Engineering Handbook Page 7
Mr. Glen D. Ritter, NASA/Marshall Space Flight
Center
Dr. Arnold Ruskin, NASA/Jet Propulsion
Laboratory and University of California at
Los Angeles
Mr. John G. Shirlaw, Massachusetts Institute of
Technology
Mr. Richard E. Snyder, NASAlLangley Research
Center
Mr. Don Sova, NASA Headquarters/Code AE
Mr. Marvin A. Stibich, USAF/Aeronautical Systems
Center
Mr. Lanny Taliaferro, NASAtMarshall Space Flight
Center
Editorial and graphics support:
Mr. Stephen Brewster, NASA/Jet Propulsion
Laboratory
Mr. Randy Cassingham, NASA/Jet Propulsion
Laboratory
Mr. John Matlock, NASA/Jet Propulsion Laboratory
—Dr. Robert Shishko
Task Manager, NASA/Jet Propulsion Laboratory

8. NASA Systems Engineering Handbook Page 1
1 Introduction The subject matter of systems engineering is
1.1 Purpose very broad. The coverage in this handbook is limited
to general concepts and generic descriptions of
This handbook is intended to provide processes, tools, and techniques. It provides
information on systems engineering that will be useful information on good systems engineering practices,
to NASA sys-tem engineers, especially new ones. Its and pitfalls to avoid.
primary objective is to provide a generic description of There are many textbooks that can be consulted for
systems engineering as it should be applied in-depth tutorials.
throughout NASA. Field centers' handbooks are
encouraged to provide center-specific details of This handbook describes systems
implementation. engineering as it should be applied to the
development of major NASA systems. Systems
For NASA system engineers to choose to engineering deals both with the system being
keep a copy of this handbook at their elbows, it must developed (the product system) and the system that
provide answers that cannot be easily found does the developing (the producing system).
elsewhere. Conse-quently, it provides NASA-relevant Consequently, the handbook's scope properly
perspectives and NASA-particular data. NASA includes systems engineering functions regardless of
management instructions (NMIs) are referenced when whether they are performed by an in-house systems
applicable. engineering organization, a program/project office, or
a system contractor.
This handbook's secondary objective is to
serve as a useful companion to all of the various While many of the producing system's
courses in systems engineering that are being offered design features may be implied by the nature of the
under NASA's auspices. tools and techniques of systems engineering, it does
not follow that institutional procedures for their
application must be uniform from one NASA field
1.2 Scope and Depth center to another.
Selected Systems Engineering Reading
See the Bibliography for full reference data and further reading suggestions.
Fundamentals of Systems Engineering
Systems Engineering and Analysis (2nd ed.), B.S. Blanchard and W.J. Fabrycky
Systems Engineering, Andrew P. Sage
An Introduction to Systems Engineering, J.E. Armstrong and Andrew P. Sage
Management Issues in Systems Engineering
Systems Engineering, EIA/IS-632
IEEE Trial-Use Standard for application and Management of the Systems Engineering Process, IEEE Std 1220-
1994
Systems Engineering Management Guide, Defense Systems Management College
System Engineering Management, B.S. Blanchard
Systems Engineering Methods, Harold Chestnut
Systems Concepts, Ralph Miles, Jr. (editor)
Successful Systems Engineering for Engineers and Managers, Norman B. Reilly
Systems Analysis and Modeling
Systems Engineering Tools, Harold Chestnut
Systems Analysis for Engineers and Managers, R. de Neufville and J.H. Stafford
Cost Considerations in Systems Analysis, Gene H. Fisher
Space Systems Design and Operations
Space Vehicle Design, Michael D. Griffin and James R. French
Space Mission Analysis and Design (2nd ed.), Wiley J. Larson and James R. Wertz (editors)
D i fG h S ft B ij N A l

9. NASA Systems Engineering Handbook Page 2
2 Fundamentals of Systems Engineering The NASA management instruction for the
acquisition of “major" systems (NMI 7120.4) defines a
2.1 Systems, Supersystems, and program as “a related series of undertakings that
continue over a period of time (normally years), which
Subsystems are designed to pursue, or are in support of, a
focused scientific or technical goal, and which are
A system is a set of interrelated components which characterized by: design, development, and
interact with one another in an organized fashion operations of systems." Programs are managed by
toward a common purpose. The components of a NASA Headquarters, and may encompass several
system may be quite diverse, consisting of persons, projects.
organizations, procedures, software, equipment, end In the NASA context, a project encompasses
'or facilities. The purpose of a system may be as the design, development, and operation of one or
humble as distributing electrical power within a more sys-tems, and is generally managed by a NASA
spacecraft or as grand as exploring the surface of field center.
Mars. Headquarters' management concerns
include not only the engineering of the systems, but
Every system exists in the context of a all of the other activities required to achieve the
broader supersystem, i.e., a collection of related desired end. These other activities include explaining
systems. It is in that context that the system must be the value of programs and projects to Congress and
enlisting international cooperation. The term mission
A Hierarchical System Terminology is often used for a program project's purpose; its
connotations of fervor make it particu-larly suitable for
The following hierarchical sequence of terms for such political activities, where the emo-tional content
suc-cessively finer resolution was adopted by the of the term is a desirable factor. In everyday
NASA –wide Systems Engineering Working conversation, the terms "project," "mission," and
Group (SEWG) and its successor, the Systems "system" are often used interchangeably; while
Engineering Process Im-provement Task (SEPIT) imprecise, this rarely causes difficulty.
team:
System The Technical Sophistication Required to do
Segment Systems Engineering Depends on the Project
Element
Subsystem • The system's goals may be simple and easy to
Assembly identify and measure—or they may be technically
Subassembly complicated, requiring a great deal of insight
Part about the environment or technology within or with
which the system must operate.
Particular projects may need a different sequence
of layers— an instrument may not need as many • The system may have a single goal—or multiple
layers, while a broad initiative may need to goals. There are techniques available for
distinguish more layers. Projects should establish determining the relative values of multiple goals
judged. Thus, managers in the supersystem set — but sometimes goals are truly incommensurate
system policies, establish system objectives, and unquantifiable.
determine system constraints, and define what costs
are relevant. They often have oversight authority over • The system may have users representing
system design and operations decisions. factions with conflicting objectives. When there
are conflicting objectives, negotiated
Most NASA systems are sufficiently complex compromises will be required.
that their components are subsystems, which must
function in a coordinated way for the system to • Alternative system design concepts may be
accomplish its goals. From the point of view of abundant—or they may require creative genius to
systems engineering, each subsystem is a system in develop.
its own right—that is, policies, requirements,
objectives, and which costs are relevant are
• A "back-of-the-envelope" computation may be
established at the next level up in the hierarchy.
satisfactory for prediction of how well the
Spacecraft systems often have such subsystems as
alternative design concepts would do in
propulsion, attitude control telecommunications, and
achievement of the goals—or credibility may
power. In a large project, the subsystems are likely to
depend upon construction and testing of hardware
be called "systems". The word system is also used
or software models.
within NASA generically, as defined in the first
paragraph above. In this handbook, system" is
generally used in its generic form.

10. NASA Systems Engineering Handbook Page 3
2.2 Definition of Systems Engineering system must provide the most effectiveness for the
resources expended or, equivalently, it must be the
Systems engineering is a robust approach to the least expensive for the effectiveness it provides. This
design, creation, and operation of systems. In simple condition is a weak one because there are usually
terms, the approach consists of identification and many designs that meet the condition. Think of each
quantification of system goals, creation of alternative possible design as a point in the tradeoff space
system design concepts, performance of design Cost
trades, selection and implementation of the best
The cost of a system is the foregone value of the
Systems Engineering per ElA/IS-632
re-sources needed to design, build, and operate it.
Be-cause resources come in many forms— work
Systems engineering is "an interdisciplinary approach
encompassing the entire technical effort to evolve and
per-formed by NASA personnel and contractors,
verify an integrated and life-cycle balanced set of sys- materials, energy, and the use of facilities and
tem people, product, and process solutions that satisfy equipment such as wind tunnels, factories, offices,
customer needs. Systems engineering encompasses (a) and computers—it is of en convenient to express
the technical efforts related to the development, these values in common terms by using monetary
manufacturing, verification, deployment, operations, units (such as dollars).
support) disposal of, and user training for, system prod-
ucts and processes; (b) the definition and management Effectiveness
of the system configuration; (c) the translation of the
system definition into work breakdown structures; and
The effectiveness of a system is a quantitative
(d) development of information for management deci-
sion making." measure of the degree to which the system's
purpose is achieved. Effectiveness measures are
usually very dependent upon system
design, verification that the design is properly built
performance. For example, launch vehicle
and integrated, and post-implementation assessment
effectiveness depends on the probability of
of how well the system meets (or met) the goals. The
successfully injecting a payload onto a usable
approach is usually applied repeatedly and
trajectory. The associated system performance
recursively, with several increases in the resolution of
attributes include the mass that can be put into a
the system baselines (which contain requirements,
specified nominal orbit, the trade between injected
design details, verification procedures and standards,
mass and launch velocity, and launch availability.
cost and performance estimates, and so on).
Cost-Effectiveness
Systems engineering is performed in concert
with system management. A major part of the system The cost-effectiveness of a system combines both
engineer's role is to provide information that the the cost and the effectiveness of the system in the
system manager can use to make the right decisions. context of its objectives. While it may be
This includes identification of alternative design necessary to measure either or both of those in
concepts and characterization of those concepts in
ways that will help the system managers first discover between effectiveness and cost. A graph plotting the
their preferences, then be able to apply them astutely. maximum achievable effectiveness of designs
An important aspect of this role is the creation of available with current technology as a function of cost
system models that facilitate assessment of the would in general yield a curved line such as the one
alternatives in various dimensions such as cost, shown in Figure 1. (In the figure, all the dimensions of
performance, and risk. effectiveness are represented by the ordinate and all
the dimensions of cost by the abscissa.) In other
Application of this approach includes words, the curved line represents the envelope of the
performance of some delegated management duties, currently available technology in terms of cost -
such as maintaining control of the developing effectiveness.
configuration and overseeing the integration of Points above the line cannot be achieved
subsystems. with currently available technology e that is, they do
not represent feasible designs. (Some of those points
2.3 Objective of Systems Engineering may be feasible in the future when further
technological advances have been made.) Points
inside the envelope are feasible, but are dominated
The objective of systems engineering is to
by designs whose combined cost and effectiveness
see to it that the system is designed, built, and
lie on the envelope. Designs represented by points on
operated so that it accomplishes its purpose in the
the envelope are called cost-effective (or efficient or
most cost-effective way possible, considering
non-dominated) solutions.
performance, cost, schedule, and risk.
Design trade studies, an important part of
the systems engineering process, often attempt to
A cost-effective system must provide a particular kind
find designs that provide a better combination of the
of balance between effectiveness and cost: the

11. NASA Systems Engineering Handbook Page 4
various dimensions of cost and effectiveness. When likely point, as is shown for design concept A in the
the starting point for a design trade study is inside the figure. Distributions resulting from designs which have
envelope, there are alternatives that reduce costs little uncertainty are dense and highly compact, as is
without decreasing any aspect of effectiveness. or shown for concept B. Distributions associated with
increase some aspect of effectiveness with risky designs may have significant probabilities of
producing highly undesirable outcomes, as is
suggested by the presence of an additional low
effectiveness/high cost cloud for concept C. (Of
course, the envelope of such clouds cannot be a
sharp line such as is shown in the figures, but must
itself be rather fuzzy. The line can now be thought of
as representing the envelope at some fixed
confidence level -- that is, a probability of x of
achieving that effectiveness.)
Both effectiveness and cost may require
several descriptors. Even the Echo balloons obtained
scientific data on the electromagnetic environment
and atmospheric drag, in addition to their primary
mission as communications satellites. Furthermore,
Echo was the first satellite visible to the naked eye, an
unquantified -- but not unrecognized —aspect of its
Figure 1 -- The Enveloping Surface of Non-dominated
effectiveness. Costs, the expenditure of limited
Designs.
resources, may be measured in the several
dimensions of funding, personnel, use of facilities,
out decreasing others and without increasing costs.
and so on. Schedule may appear as an attribute of
Then, the system manager's or system engineer's
effectiveness or cost, or as a constraint. Sputnik, for
decision is easy. Other than in the sizing of
example, drew much of its effectiveness from the fact
subsystems, such "win-win" design trades are
that it was a "first"; a mission to Mars that misses its
uncommon, but by no means rare. When the
launch window has to wait about two years for
alternatives in a design trade study, however, require
another opportunity—a clear schedule constraint.
trading cost for effectiveness, or even one dimension
Risk results from uncertainties in realized
of effectiveness for another at the same cost, the
effectiveness, costs, timeliness, and budgets.
decisions become harder.
Sometimes, the systems that provide the
highest ratio of effectiveness to cost are the most
desirable. However, this ratio is likely to be
meaningless or—worse—misleading. To be useful
and meaningful, that ratio must be uniquely
determined and independent of the system cost.
Further, there must be but a single measure of
effectiveness and a single measure of cost. If the
numerical values of those metrics are obscured by
probability distributions, the ratios become uncertain
as well; then any usefulness the simple, single ratio of
two numbers might have had disappears.
In some contexts, it is appropriate to seek
the most effectiveness possible within a fixed budget;
in other contexts, it is more appropriate to seek the
least cost possible with specified effectiveness. In
these cases, there is the question of what level of
Figure 2--Estimates of Outcomes to be Obtained from
effectiveness to specify or of what level of costs to fix.
Several Design Concepts Including Uncertainty.
In practice, these may be mandated in the form of
performance or cost requirements; it then becomes
The process of finding the most cost-
appropriate to ask whether a slight relaxation of
effective design is further complicated by uncertainty,
requirements could produce a significantly cheaper
which is shown in Figure 2 as a modification of Figure
sys-tem or whether a few more resources could
1. Exactly what outcomes will be realized by a
produce a significantly more effective system.
particular system design cannot be known in advance
Usually, the system manager must choose
with certainty, so the projected cost and effectiveness
among designs that differ in terms of numerous
of a design are better described by a probability
attributes. A variety of methods have been developed
distribution than by a point. This distribution can be
that can be used to help managers uncover their
thought of as a cloud which is thickest at the most
preferences between attributes and to quantify their
likely value and thinner farther away from the most

12. NASA Systems Engineering Handbook Page 5
The System Engineer's Dilemma analytic methods. These specialty engineering areas
typically include reliability, maintainability, logistics,
At each cost-effective solution: test, production, transportation, human factors, quality
• To reduce cost at constant risk, performance assurance, and safety engineering. Specialty
must be reduced. engineers contribute throughout the systems
• To reduce risk at constant cost, performance engineering process; part of the system engineer's job
must be reduced. is to see that these functions are coherently
• To reduce cost at constant performance, higher integrated into the project at the right times and that
risks must be accepted. they address the relevant issues. One of the
objectives for Chapter 6 is to develop an
• To reduce risk at constant performance, higher
understanding of how these specialty engineers
costs must be accepted.
contribute to the objective of systems engineering.
In both systems analysis and systems
In this context, time in the schedule is often a
engineering, the amounts and kinds of resources to
critical resource, so that schedule behaves like a
be made available for the creation of the system are
kind
assumed to be among the decisions to be made.
f t
subjective assessments of relative value. When this Systems engineering concentrates on the creation of
can be done, trades between attributes can be hardware and software architectures and on the
assessed quantitatively. Often, however, the development and management of the interfaces
attributes seem to be truly incommensurate; between subsystems, while relying on systems
managers must make their decisions in spite of this analysis to construct the mathematical models and
multiplicity. analyze the data to evaluate alternative designs and
to perform the actual design trade studies. Systems
2.4 Disciplines Related to Systems analysis often requires the use of tools from
Engineering operations research, economics, or other decision
sciences, and systems analysis curricula generally
The definition of systems engineering given include extensive study of such topics as probability,
in Section 2.2 could apply to the design task facing a statistics, decision theory, queueing theory, game
bridge designer, a radio engineer, or even a theory, linear and non-linear programming, and so on.
committee chair. The systems engineering process In practice, many system engineers' academic
can be a part of all of these. It cannot be the whole of background is richer in the engineering disciplines
the job—the bridge designer must know the than in the decision sciences. As a consequence, the
properties of concrete and steel, the radio engineer system engineer is often a consumer of systems
must apply Maxwell's equations, and a committee analysis products, rather than a producer of them.
chair must understand the personalities of the One of the major objectives for Chapter 5 is to
members of the committee. In fact, the optimization of develop an understanding and appreciation of the
systems requires collaboration with experts in a state of that art.
variety of disciplines, some of which are compared to Operations research and operations
systems engineering in the remainder of this section. engineering confine their attention to systems whose
The role of systems engineering differs from components are assumed to be more or less
that of system management in that engineering is an immutable. That is, it is assumed that the resources
analytical, advisory and planning function, while with which the system operates cannot be changed,
management is the decision-making function. Very but that the way in which they are used is amenable
often, the distinction is irrelevant, as the same to optimization. Operations research techniques often
individuals may perform both roles. When no factors provide powerful tools for the optimization of system
enter the decision-making process other than those designs.
that are covered by the analyses, system Within NASA, terms such as mission
management may delegate some of the management analysis and engineering are often used to describe
responsibility to the systems engineering function. all study and design efforts that relate to
Systems engineering differs from what might determination of what the project's mission should be
be called design engineering in that systems and how it should be carried out. Sometimes the
engineering deals with the relationships of the thing scope is limited to the study of future projects.
being designed to its supersystem (environment) and Sometimes the charters of organizations with such
subsystems, rather than with the internal details of names include monitoring the capabilities of systems,
how it is to accomplish its objectives. The systems ensuring that important considerations have not been
viewpoint is broad, rather than deep: it encompasses overlooked, and overseeing trades between major
the system functionally from end to end and systems— thereby encompassing operations
temporally from conception to disposal. research, systems analysis, and systems engineering
System engineers must also rely on activities.
contributions from the specialty engineering Total quality management (TQM) is the
disciplines, in addition to the traditional design application of systems engineering to the work
disciplines, for functional expertise and specialized environment. That is, part of the total quality

13. NASA Systems Engineering Handbook Page 6
management paradigm is the realization that an
operating organization is a particular kind of system
and should be engineered as one. A variety of
specialized tools have been developed for this
application area; many of them can be recognized as
established systems engineering tools, but with
different names. The injunction to focus on the
satisfaction of customer needs, for example, is even
expressed in similar terms. The use of statistical
process control is akin to the use of technical
performance and earned value measurements.
Another method, qualify function deployment (QFD),
is a technique of requirements analysis often used in
systems engineering.
The systems approach is common to all of
these related fields. Essential to the systems
approach is the recognition that a system exists, that
it is embedded in a supersystem on which it has an
impact, that it may contain subsystems, and that the
system's objectives must be understood preferably
explicitly identified.
2.5 The Doctrine of Successive Refinement
The realization of a system over its life cycle
integration of lower-level elements is a part of the
results from a succession of decisions among
systems engineering process. In fact, there is always
alternative courses of action. If the alternatives are
a danger that the top-down process cannot keep up
precisely enough defined and thoroughly enough
with the bottom-up process.
understood to be well differentiated in the cost-
There is often an early need to resolve the
effectiveness space, then the system manager can
issues (such as the system architecture) enough so
make choices among them with confidence.
that the system can be modeled with sufficient realism
The systems engineering process can be
to do reliable trade studies.
thought of as the pursuit of definition and
When resources are expended toward the
understanding of design alternatives to support those
implementation of one of several design options, the
decisions, coupled with the overseeing of their
resources required to complete the implementation of
implementation. To obtain assessments that are crisp
that design decrease (of course), while there is
enough to facilitate good decisions, it is often
usually little or no change in the resources that would
necessary to delve more deeply into the space of
be required by unselected alternatives. Selected
possible designs than has yet been done, as is
alternatives thereby become even more attractive
illustrated in Figure 3.
than those that were not selected.
It should be realized, however, that this
Consequently, it is reasonable to expect the
spiral represents neither the project life cycle, which
system to be defined with increasingly better
encompasses the system from inception through
resolution as time passes. This tendency is formalized
disposal, nor the product development process by
at some point (in Phase B) by defining a baseline
which the system design is developed and
system definition. Usually, the goals, objectives, and
implemented, which occurs in Phases C and D (see
constraints are baselined as the requirements portion
Chapter 3) of the project life cycle. Rather, as the
of the baseline. The entire baseline is then subjected
intellectual process of systems engineering, it is
to configuration control in an attempt to ensure that
inevitably reflected in both of them.
successive changes are indeed improvements.
As the system is realized, its particulars
become clearer—but also harder to change. As stated
Figure 3—The Doctrine of Successive Refinement
above, the purpose of systems engineering is to make
sure that the development process happens in a way
that leads to the most cost-effective final system. The
Figure 3 is really a double helix—each
basic idea is that before those decisions that are hard
create concepts step at the level of design
to undo are made, the alternatives should be carefully
engineering initiates a ca-pabilities definition spiral
assessed.
moving in the opposite direction. The concepts can
The systems engineering process is applied
never be created from whole cloth. Rather, they result
again and again as the system is developed. As the
from the synthesis of potential capabilities offered by
system is realized, the issues addressed evolve and
the continually changing state of technology. This
the particulars of the activity change.
process of design concept development by the

14. NASA Systems Engineering Handbook Page 7
As an Example of the Process of Successive but its first cause. It could be argued that recognition
Refinement, Consider the Choice of Altitude for a of the need or opportunity for a new system is an
Space Station such as Alpha entrepreneurial activity, rather than an engineering
one.
• The first issue is selection of the general The end result of this step is the discovery
location. Alternatives include Earth orbit, one of and delineation of the system's goals, which generally
the Earth-Moon Lagrange points, or a solar orbit. express the desires and requirements of the eventual
At the current state of technology, cost and risk users of the system. In the NASA context, the
considerations made selection of Earth orbit an system's goals should also represent the long term
easy choice for Alpha. • Having chosen Earth interests of the taxpaying public.
orbit, it is necessary to select an orbit region.
Alternatives include low Earth orbit (LEO), high Identify and Quantify Goals. Before it is possible to
Earth orbit and geosynchronous orbit; orbital compare the cost-effectiveness of alternative system
inclination and eccentricity must also be chosen. design concepts, the mission to be performed by the
One of many criteria considered in choosing LEO system must be delineated. The goals that are
for Alpha was the design complexity associated developed should cover all relevant aspects of
with passage through the Van Allen radiation effectiveness, cost, schedule, and risk, and should be
belts. traceable to the goals of the supersystem. To make it
• System design choices proceed to the selection easier to choose among alternatives, the goals should
of an altitude maintenance strategy—rules that be stated in quantifiable, verifiable terms, insofar as
implicitly determine when, where, and why to re- that is possible and meaningful to do.
boost, such as "maintain altitude such that there It is also desirable to assess the constraints
are always at least TBD days to reentry," "collision that may apply. Some constraints are imposed by the
avoidance maneuvers shall always increase the state of technology at the time of creating or
altitude," "reboost only after resupply flights that modifying system design concepts. Others may
have brought fuel," "rotate the crew every TBD appear to be inviolate, but can be changed by higher
days." levels of management. The assumptions and other
• A next step is to write altitude specifications. relevant information that underlie constraints should
These choices might consist of replacing the always be recorded so that it is possible to estimate
TBDs (values to be determined) in the altitude the benefits that could be obtained from their
strategy with explicit numbers. relaxation.
• Monthly operations plans are eventually part of At each turn of the spiral, higher-level goals
the complete system design. These would include are analyzed. The analysis should identify the
scheduled reboost burns based on predictions of subordinate enabling goals in a way that makes them
the accumulated effect of drag and the details of traceable to the next higher level. As the systems
on-board microgravity experiments. engineering process continues, these are
documented as functional requirements (what must
• Actual firing decisions are based on determinations of be done to achieve the next-higher-level goals) and
the orbit which results from the momentum actually
added by previous firings, the atmospheric density
as performance requirements (quantitative
variations actually encountered, and so on. descriptions of how well the functional requirements
must be done). A clear operations concept often helps
Note that decisions at every step require that to focus the require-ments analysis so that both
the capabilities offered by available technology be functional and performance requirements are
considered—often at levels of design that are more ultimately related to the original need or opportunity.
detailed than seems necessary at first In later turns of the spiral, further elaborations may
become documented as detailed functional and
Most of the major system decisions (goals, performance specifications.
architecture, acceptable life-cycle cost, etc.) are made
during the early phases of the project, so the turns of Create Alternative Design Concepts. Once it is
the spiral (that is, the successive refinements) do not under-stood what the system is to accomplish, it is
correspond precisely to the phases of the system life possible to devise a variety of ways that those goals
cycle. Much of the system architecture can be ''seen" can be met. Sometimes, that comes about as a
even at the outset, so the turns of the spiral do not consequence of considering alternative functional
correspond exactly to development of the allocations and integrating available subsystem
architectural hierarchy, either. Rather, they design options. Ideally, as wide a range of plausible
correspond to the successively greater resolution by alternatives as is consistent with the design
which the system is defined. organization's charter should be defined, keeping in
Each of the steps in the systems engineering mind the current stage in the process of successive
process is discussed below. refinement. When the bottom-up process is operating,
a problem for the system engineer is that the
Recognize Need/Opportunity. This step is shown in designers tend to become fond of the designs they
Figure 3 only once, as it is not really part of the spiral create, so they lose their objectivity; the system

15. NASA Systems Engineering Handbook Page 8
engineer often must stay an "outsider" so that there is associated with the continually improving resolution
more objectivity. reduces the spread between upper and lower bounds
On the first turn of the spiral in Figure 3, the as the process proceeds.
sub-ject is often general approaches or strategies,
sometimes architectural concepts. On the next, it is Select Concept. Selection among the alternative
likely to be functional design, then detailed design, design concepts is a task for the system manager,
and so on. who must take into account the subjective factors that
The reason for avoiding a premature focus the system engineer was unable to quantify, in
on a single design is to permit discovery of the truly addition to the estimates of how well the alternatives
best design. Part of the system engineer's job is to meet the quantified goals (and any effectiveness,
ensure that the design concepts to be compared take cost, schedule, risk, or other constraints).
into account all interface requirements. "Did you When it is possible, it is usually well worth
include the cabling?" is a characteristic question. the trouble to develop a mathematical expression,
When possible, each design concept should be called an objective function, that expresses the values
described in terms of controllable design parameters of combinations of possible outcomes as a single
so that each represents as wide a class of designs as measure of cost-effectiveness, as is illustrated in
is reasonable. In doing so, the system engineer Figure 4, even if both cost and effectiveness must be
should keep in mind that the potentials for change described by more than one measure. When
may include organizational structure, schedules, achievement of the goals can be quantitatively
procedures, and any of the other things that make up expressed by such an objective function, designs can
a system. When possible, constraints should also be be compared in terms of their value. Risks associated
described by parameters. with design concepts can cause these evaluations to
Owen Morris, former Manager of the Apollo be somewhat nebulous (because they are uncertain
Spacecraft Program and Manager of Space Shuttle and are best described by probability distributions). In
Systems and Engineering, has pointed out that it is this illustration, the risks are relatively high for design
often useful to define design reference missions concept A. There is little risk in either effectiveness or
which stress all of the system's capabilities to a cost for concept B. while the risk of an expensive
significant extent and which al1 designs will have to failure is high for concept C, as is shown by
be able to accomplish. The purpose of such missions
is to keep the design space open. Consequently, it
can be very dangerous to write them into the system
specifications, as they can have just the opposite
effect.
Do Trade Studies. Trade studies begin with an
assess-ment of how well each of the design
alternatives meets the system goals (effectiveness,
cost, schedule, and risk, both quantified and
otherwise). The ability to perform these studies is
enhanced by the development of system models that
relate the design parameters to those assessments—
but it does not depend upon them.
Controlled modification and development of design
concepts, together with such system models, often
permits the use of formal optimization techniques to
find regions of the design space that warrant further
investigation— those that are closer to the optimum Figure 4—A Quantitative Objective Function, De"
surface indicated in Figure 1. pendent on Life-Cycle Cost and All Aspects of
Whether system models are used or not, the Effec-tiveness.
design concepts are developed, modified,
reassessed, and compared against competing the cloud of probability near the x axis with a high cost
alternatives in a closed-loop process that seeks the and essentially no effectiveness. Schedule factors
best choices for further development. System and may affect the effectiveness values, the cost values,
subsystem sizes are often determined during the and the risk distributions.
trade studies. The end result is the determination of The mission success criteria for systems
bounds on the relative cost-effectivenesses of the differ significantly. In some cases, effectiveness goals
design alternatives, measured in terms of the may be much more important than all others. Other
quantified system goals. (Only bounds, rather than projects may demand low costs, have an immutable
final values, are possible because determination of schedule, or require minimization of some kinds of
the final details of the design is intentionally deferred. risks. Rarely (if ever) is it possible to produce a
The bounds, in turn, may be derived from the combined quantitative measure that relates all of the
probability density functions.) Increasing detail important factors, even if it is expressed as a vector

16. NASA Systems Engineering Handbook Page 9
with several components. Even when that can be often desirable. The accounting system should follow
done, it is essential that the underlying factors and (not lead) the system architecture. In terms of
relationships be thoroughly revealed to and breadth, partitioning should be done essentially all at
understood by the system manager. The system once. As with system design choices, alternative parti
manager must weigh the importance of the -tioning plans should be considered and compared
unquantifiable factors along with the quantitative data before implementation.
provided by the system engineer. If a requirements-driven design paradigm is used for
Technical reviews of the data and analyses tile development of the system architecture, it must be
are an important part of the decision support applied with care, for the use of "shells" creates a
packages prepared for the system manager. The tendency for the requirements to be treated as
decisions that are made are generally entered into the inviolable con straints rather than as agents of the
configuration management system as changes to (or objectives. A goal, ob -jective or desire should never
elaborations of) the system baseline. The supporting be made a requirement until its costs. are understood
trade studies are archived for future use. An essential and the buyer is willing to pay for it. The capability to
feature of the systems engineering process is that compute the effects of lower -level decisions on the
trade studies are performed before decisions are quantified goals should be maintained throughout the
made. They can then be baselined with much more partitioning process. That is, there should be a goals
confidence. flowdown embedded in the requirements allocation
At this point in the systems engineering process.
process, there is a logical branch point. For those The process continues with creation of a
issues for which the process of successive refinement variety of alternative design concepts at the next level
has proceeded far of resolution, construction of models that permit
prediction of how well those alternatives will satisfy
Simple Interfaces are Preferred
the quantified goals, and so on. It is imperative that
According to Morris, NASA's former Acting
plans for subsequent integration be laid throughout
Administrator George Low, in a 1971 paper titled
the partitioning. Integration plans include verification
"What Made Apollo a Success," noted that only
and validation activities as a matter of course.
100 wires were needed to link the Apollo
spacecraft to the Saturn launch vehicle. He
Implement the Selected Design Decisions. When
emphasized the point that a single person could
the process of successive refinement has proceeded
fully understand the interface and cope with all the
far enough, the next step is to reverse the partitioning
enough, the next step is to implement the decisions at process. When applied to the system architecture,
that level of resolution (that is, unwind the recursive this "unwinding" of the process is called system
process). For those issues that are still insufficiently integration. Conceptual system integration takes
resolved, the next step is to refine the development place in all phases of the project life cycle. That is,
further. when a design approach has been selected, the
approach is verified by "unwinding the process" to test
Increase the Resolution of the Design. One of the whether the concept at each physical level meets the
first issues to be addressed is how the system should expectations and requirements. Physical integration is
be subdivided into subsystems. (Once that has been accomplished during Phase D. At the finer levels of
done, the focus changes and the subsystems become resolution, pieces must be tested, assembled and/or
systems -- from the point of view of a system integrated, and tested again. The system engineer's
engineer. The partitioning process stops when the role includes the performance of the delegated
subsystems are simple enough to be managed management du ties, such as configuration control
holistically.) As noted by Morris, "the divi- be and overseeing the integration, verification, and
managed holistically.) As noted by Morris, "the validation process.
division of program activities to minimize the number The purpose of verification of subsystem
and complexity of interfaces has a strong influence on integration is to ensure that the subsystems conform
the overall program cost and the ability of the program to what was designed and interface with each other
to meet schedules." as expected in all re spects that are important:
Charles Leising and Arnold Ruskin have mechanical connections, effects on center of mass
(separately) pointed out that partitioning is more art and products of inertia, electromagnetic interference,
than science, but that there are guidelines available: connector impedance and voltage, power con
To make interfaces clean and simple, similar sumption, data flow, and so on. Validation consists of
functions, designs and tech nologies should be ensuring that the interfaced subsystems achieve their
grouped. Each portion of work should be verifiable. intended results. While validation is even more
Pieces should map conveniently onto the important than verification, it is usually much more
organizational structure. Some of the functions that difficult to accomplish.
are needed throughout the design (such as electrical
power) or throughout the organization (such as Perform the Mission. Eventually, the system is
purchasing) can be centralized. Standardization—of called upon to meet the need or seize the opportunity
such things as parts lists or reporting formats—is for which it was designed and built.

17. NASA Systems Engineering Handbook Page 10
The system engineer continues to perform a
variety of supporting functions, depending on the
nature and duration of the mission. On a large project
such as Space Station Alpha, some of these
continuing functions include the validation of system
effectiveness at the operational site, overseeing the
maintenance of configuration and logistics
documentation, overseeing sustaining engineering
activities, compiling development and operations
"lessons reamed" documents, and, with the help of
the specialty engineering disciplines, identifying
product improvement opportunities. On smaller
systems, such as a Spacelab payload, only the last
two may be needed.

18. NASA Systems Engineering Handbook Page 11
3 The Project Life Cycle for Major in government. In general, the engineering
NASA Systems development life cycle is dependent on the technical
nature of what's being developed, and the project life
cycle may need to be tailored accordingly. Barry W.
One of the fundamental concepts used
Boehm described how several contemporary software
within NASA for the management of major systems is
development processes work; in some of these
the pro-gram/ project life cycle, which consists of a
processes, the development and construction
categorization of everything that should be done to
activities proceed in parallel, so that attempting to
accomplish a project into distinct phases, separated
separate the associated phases on a time line is
by control gates. Phase boundaries are defined so
undesirable. Boehm describes a spiral, which reflects
that they provide more-or-less natural points for
the doctrine of successive refinement depicted in
go/no-go decisions. Decisions to proceed may be
Figure 3, but Boehm's spiral describes the software
qualified by liens that must be removed within a
product development process in particular. His
reasonable time. A project that fails to pass a control
discussion applies as well to the development of
gate and has enough resources may be allowed to
hardware products as it does to software. Other
“go back to the drawing board"—or it may be
exam-ples of alternative processes are the rapid
terminated.
prototyping and rapid development approaches.
All systems start with the recognition of a
Selection of a product development process paradigm
need or the discovery of an opportunity and proceed
must be a case-dependent decision, based on the
through various stages of development to a final
system engineer's judgment and experience.
disposition. While the most dramatic impacts of the
Sometimes, it is appropriate to perform some
analysis and optimization activities associated with
long-lead-time activities ahead of the time they would
systems engineering are obtained in the early stages,
nominally be done. Long-lead-time activities might
decisions that affect millions of dollars of value or cost
consist of technology developments, prototype
continue to be amenable to the systems approach
construction and testing, or even fabrication of difficult
even as the end of the system lifetime approaches.
components. Doing things out of their usual sequence
Decomposing the project life cycle into
increases risk in that those activities could wind up
phases or-ganizes the entire process into more
having been either unnecessary or improperly
manageable pieces. The project life cycle should
specified. On the other hand, overall risk can
provide managers with incremental visibility into the
sometimes be reduced by removal of such activities
progress being made at points in time that fit with the
from the critical path.
management and budgetary environments. NASA
Figure 5 (foldout, next page) details the
documents governing the acquisition of major
resulting management and major systems
systems (NMI 7120.4 and NHB 7120.5) define the
engineering products and control gates that
phases of the project life cycle as:
characterize the phases in NMI 7120.4 and NHB
7120.5. Sections 3.1 to 3.6 contain narrative
• Pre-Phase A—Advanced Studies ("find a suitable
descriptions of the purposes, major activities,
project")
products, and control gates of the NASA project life
• Phase A—Preliminary Analysis ("make sure the
cycle phases. Section 3.7 provides a more
project is worthwhile")
concentrated discussion of the role of systems
• Phase B—Definition ("define the project and engineering in the process. Section 3.8 describes the
establish a preliminary design") NASA budget cycle within which program/project
• Phase C—Design ("complete the system design") managers and system engineers must operate.
Phase D — Development ("build, integrate, and
verify the system, and prepare for operations") 3.1 Pre-Phase A—Advanced Studies
• Phase E—Operations ("operate the system and
dispose of it properly"). The purpose of this activity, which is usually per-
formed more or less continually by "Advanced
Phase A efforts are conducted by NASA field Projects" groups, is to uncover, invent, create,
cen-ters; such efforts may rely, however, on pre- concoct and/or devise a broad spectrum of ideas and
Phase A in-house and contracted advanced studies. alternatives for missions from which new projects
The majority of Phase B efforts are normally (programs) can be selected. Typically, this activity
accomplished by industry under NASA contract, but consists of loosely structured ex-aminations of new
NASA field centers typically conduct parallel in-house ideas, usually without central control and mostly
studies in order to validate the contracted effort and oriented toward small studies. Its major product is a
remain an informed buyer. NASA usually chooses to stream of suggested projects, based on the
contract with industry for Phases C and D, and often identification of needs and the discovery of
does so for Phase E. Phase C is nominally combined opportunities that are potentially consistent with
with Phase D, but when large production quantities NASA's mission. capabilities, priorities, and
are planned, these are treated separately. resources.
Alternatives to the project phases described
above can easily be found in industry and elsewhere

19. NASA Systems Engineering Handbook Page 12
Pre-Phase A—Advanced Studies
system before seeking significant funding. According
to NHB 7120.5, the major products of this phase are a
Purpose: To produce a broad spectrum of ideas formal Mission Needs Statement (MNS) and one or
and alternatives for missions from which new pro- more credible, feasible designs and operations
grams/ projects can be selected. concepts. John Hodge describes this phase as "a
Major Activities and their Products: Identify structured version of the previous phase."
missions consistent with charter Identify and Phase A—Preliminary Analysis
involve users
Perform preliminary evaluations of possible Purpose: To determine the feasibility and
missions Prepare program/project proposals, desirability of a suggested new major system and
which include: its compatibility with NASA's strategic plans.
• Mission justification and objectives Major Activities and their Products:
• Possible operations concepts Prepare Mission Needs Statement
• Possible system architectures Develop top-level requirements
• Cost, schedule, and risk estimates. Develop corresponding evaluation criteria/metrics
Develop master plans for existing program areas Identify alternative operations and logistics
Information Baselined: concepts
(nothing) Identify project constraints and system boundaries
Control Gates: Consider alternative design concepts, including:
Mission Concept Review feasibility and risk studies, cost and schedule
Informal proposal reviews estimates, and advanced technology
requirements
In the NASA environment, demands for new Demonstrate that credible, feasible design(s) exist
systems derive from several sources. A major one is Acquire systems engineering tools and models
the opportunity to solve terrestrial problems that may Initiate environmental impact studies
be ad-dressed by putting instruments and other Prepare Project Definition Plan for Phase B
devices into space. Two examples are weather Information Baselined:
prediction and communications by satellite. General (nothing)
improvements in technology for use in space will Control Gates:
continue to open new possibilities. Such opportunities Mission Definition Review
are rapidly perceived as needs once the magnitude of Preliminary Non-Advocate Review
their value is understood. Preliminary Program/Project Approval Review
Technological progress makes possible
missions that were previously impossible. Manned
trips to the moon and the taking of high resolution In Phase A, a larger team, often associated
pictures of planets and other objects in the universe with an ad hoc program or project office, readdresses
illustrate past responses to this kind of opportunity. the mission concept to ensure that the project
New opportunities will continue to become available justification and practicality are sufficient to warrant a
as our technological capabilities grow. place in NASA's budget. The team's effort focuses on
Scientific progress also generates needs for analyzing mission requirements and establishing a
NASA systems. As our understanding of the universe mission architecture. Activities become formal, and
around us continues to grow, we are able to ask new the emphasis shifts toward establishing optimality
and more precise questions. The ability to answer rather than feasibility. The effort addresses more
these questions often depends upon the changing depth and considers many alternatives. Goals and
state of technology. objectives are solidified, and the project develops
Advanced studies may extend for several more definition in the system requirements, top-level
years, and may be a sequence of papers that are only system architecture, and operations concept.
loosely connected. These studies typically focus on Conceptual designs are developed and exhibit more
establishing mission goals and formulating top-level engineering detail than in advanced studies.
system requirements and operations concepts. Technical risks are identified in more detail and
Conceptual designs are often offered to demonstrate technology development needs become focused.
feasibility and support programmatic estimates. The The Mission Needs Statement is not shown
emphasis is on establishing feasibility and desirability in the sidebar as being baselined, as it is not under
rather than optimality. Analyses and designs are configuration control by the project. It may be under
accordingly limited in both depth and number of configuration control at the program level, as may the
options. program requirements documents and the Preliminary
Program Plan.
3.2 Phase A—Preliminary Analysis
The purpose of this phase is to further examine the
feasibility and desirability of a suggested new major

21. NASA Systems Engineering Handbook Page 14
seek out more cost-effective designs. (Trade studies
should precede—rather than follow—system design
Figure 6 – Overruns are Very Likely if Phases A decisions. Chamberlain, Fox, and Duquette describe
and B are Underfunded.
Phase B -- Definition
Purpose: To define the project in enough detail to
establish an initial baseline capable of meeting
mission needs.
Major Activities and their Products:
Prepare a Systems Engineering Management
Plan
Prepare a Risk Management Plan
Initiate configuration management
Prepare engineering specialty program plans
Develop system-level cost-effectiveness model
Restate mission needs as functional requirements
Identify science payloads
Establish the initial system requirements and
verification requirements matrix
Perform and archive trade studies
Select a baseline design solution and a concept of
operations
3.3 Phase B -- Definition Define internal and external interface
requirements
The purpose of this phase is to establish an (Repeat the process of successive refinement to
initial project baseline, which (according to NHB get "design-to" specifications and drawings,
7120.5) includes "a formal flowdown of the project- verifications plans, and interface documents to
level performance requirements to a complete set of lower levels as appropriate)
system and subsystem design specifications for both Define the work breakdown structure
flight and ground elements" and "corresponding Define verification approach end policies
preliminary designs." The technical requirements Identify integrated logistics support requirements
should be sufficiently detailed to establish firm Establish technical resource estimates and firm
schedule and cost estimates for the project. life-cy-cle cost estimates
Develop statement(s) of work
A Credible, Feasible Design Initiate advanced technology developments
Revise and publish a Project Plan
A feasible system design is one that can be Reaffirm the Mission Needs Statement
implemented as designed and can then Prepare a Program Commitment Agreement
accomplish the system's goals within the Information Baselined:
constraints imposed by the fiscal and operating System requirements and verification
environment. To be credible, a design must not requirements matrix
depend on the occurrence of unforeseen System architecture and work breakdown
breakthroughs in the state of the art. While a structure
credible design may assume likely improvements Concept of operations
in the state of the art, it is nonetheless riskier than “Design-to” specifications at all levels
Actually, "the" Phase B baseline consists of Project plans, including schedule, resources,
a collection of evolving baselines covering technical acquisition strategies and risk management
and business aspects of the project: system (and a decentralized process for ensuring that such trades
subsystem) requirements and specifications, designs, lead efficiently to an optimum system design.) Major
verification and operations plans, and so on in the products to this point include an accepted "functional"
technical portion of the baseline, and schedules, cost baseline and preliminary "design-to" baseline for the
projections, and management plans in the business system and its major end items. The effort also
portion. Establishment of baselines implies the produces various engineering and management plans
implementation of configuration management to prepare for managing the project's downstream
procedures. (See Section 4.7.) processes, such as verification and operations, and
Early in Phase B, the effort focuses on for implementing engineering specialty programs.
allocating functions to particular items of hardware, Along the way to these products, projects
software, personnel, etc. System functional and are subjected to a Non-Advocate Review, or NAR.
performance requirements along with architectures This activity seeks to assess the state of project
and designs become firm as system trades and definition in terms of its clarity of objectives and the
subsystem trades iterate back and forth in the effort to thoroughness of technical and management plans,