See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/290995828

Systems Analysis: Its Proper Utilization in Systems Engineering Education and

Practice

Conference Paper · June 2015

CITATIONS READS

2 2,825

1 author:

Wolt Fabrycky
Virginia Tech (Virginia Polytechnic Institute and State University)
16 PUBLICATIONS 1,973 CITATIONS

SEE PROFILE

All content following this page was uploaded by Wolt Fabrycky on 18 January 2016.

The user has requested enhancement of the downloaded file.

From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

Systems Analysis: Its Proper Utilization Within

Systems Engineering Education and Practice
Wolter J. Fabrycky, Lawrence Professor Emeritus at Virginia Tech
and Chairman, Academic Applications International, Inc.

I. Introduction and Prerequisites

From its modest beginnings more than a half-century ago, Systems Engineering (SE) is now
gaining international recognition as an effective technologically based interdisciplinary process
for bringing human-made systems into being, and for improving systems already in being.1
However, the main focus of this paper is Systems Analysis (SA) as a necessary part of SE,
specifically its proper utilization within systems engineering education and practice.

Systems engineering concentrates on the engineering of human-made systems and on systems

analysis. In the first case, emphasis is on the process of bringing systems into being, beginning
with the identification of a need or a deficiency and extending through requirements determination,
functional analysis and allocation, design synthesis and evaluation, design validation, deployment,
operation and support, sustainment, and phase-out and disposal. In the second case, focus is on the
improvement of systems already in being. By adopting and utilizing the iterative process of
analysis, evaluation, modification, and feedback, most systems now in existence can be improved
in to their operational effectiveness, product quality, affordability, sustainability, and stakeholder
satisfaction. Extensive coverage of both of these cases is found in Systems Engineering and
Analysis, 5/e, 2011.2

Systems engineering may be defined and/or described herein as the technologically based
interdisciplinary process for bringing human-made systems and their products (desired entities)
into being. While the main focus is nominally on the entities themselves, systems engineering
offers private and public enterprises an improved strategy. Systems engineering is inherently
oriented to considering “the end before the beginning” and concentrates on what the entities are
intended to do before determining what the entities are, with form following function. Systems
analysis is necessary but not sufficient in the process of bringing systems into being.

Instead of offering systems or system elements and products per se, systems engineering focuses
on designing, delivering, and sustaining functionality, a capability, or a solution. This strategic
thinking is now being considered by forward-looking organizations in both the private and public
sectors. It is applicable to most types of technical systems, encompassing the human activity
domains of communication, defense, education, healthcare, manufacturing, transportation, and
others. The advancement and promulgation of this emerging strategy through systems engineering
education is a primary aim of this paper.

The focus is on subject matter commonly available within most schools and colleges of
engineering. Related areas of Systems Analysis; Engineering Economics (EE), Operations
Research (OR), and Management Science (MS) are addressed and synthesized. Educational benefit
from integrating known academic areas, overlaid with a Design Dependent Parameter (DDP)
paradigm, should be of value to graduates destined for professional engineering practice.

1
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

Although sometimes incorrectly called systems engineering, SA is demonstrated to be necessary

but not sufficient for teaching and practicing SE. The system design (or synthesis) process leads
and sets the pace. Stumbling through the system design space with an evaluation ‘compass’ helps
converge system design in the face of multiple criteria. Making value for society relies on
converging the design to achieve the desired outcome of “Quicker, Better, and Cheaper”. The SE
process, with SA properly embedded, has implications for teaching, research, and professional
practice, with guidance for guiding engineering capstone design projects.

Advancing the ASEE 2015 theme “Making Value for Society” requires systems thinking more
than ever before. Instead of offering systems or system elements per se, SA properly utilized within
SE in this new century should facilitate the discovery of emergent system properties that provide
desired functionality, capability, and improved operations.

As a more complete introduction, the reader is encouraged to consider the 2010 ASEE paper
entitled Systems Engineering: Its Emerging Academic and Professional Attributes.3

II. Utilizing Systems Analysis Within SE

System design is the prime mover for systems engineering, with system design evaluation being
its compass. System design requires integration and iteration, invoking a process that coordinates
synthesis, analysis, and evaluation over the system life cycle as illustrated in Figure 1. Analysis
acting alone is not sufficient. It is analysis that drives the design decision evaluation process.

Figure 1. Synthesis, Analysis, and Evaluation Within SE

Consider Figure 2 (left side) regarding the evolution of a decision evaluation capability. Begin
with operations and focus on the scientific management thereof. Operations are continuously being
researched and an extensive body of systematic knowledge has accumulated, herein called
Management Science (MS). MS properly utilized enables the practice of scientific management of
the operations researched. This is a knowledge generation, knowledge accumulation, knowledge
utilization process for industrial operations that originated more than a century ago.4

Next, consider the right side of Figure 2 depicting the application of analysis within design and
operations. The first two entries are decision model formulations applicable to operations in
general, specifically for systems analysis. The third entry is explicitly for procurement and

2
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

inventory operations with recognition of source dependent parameters, enabling better source
selection decisions. Herein is the evolved mathematical basis and decision model background for
systems engineering and systems analysis.

Figure 2. Evolution of the General Design Evaluation Function

Design Dependent Parameters (DDP’s) began to appear in the fourth entry of Figure 2 (right).
These parameters (producibility, reliability, maintainability, supportability, sustainability,
disposability, and others) make possible the evaluation of synthesized system designs. Design
dependent parameters are the inner workings of the compass that helps converge systems design
in the face of multiple criteria.

The DDP paradigm can now be indirectly traced to the classic Introduction to Operations
Research, by Churchman, Ackoff, and Arnoff, 1957.5 In that year and with that OR book, it was
your author’s good fortune to study the subject when a M.S. student at Arkansas. But neither the
book authors, the professor, nor yours truly could perceive what the generic mathematical
construct stated in Chapter 1 could become for the unknown field of systems engineering.

The mathematical construct referenced in this classic book was E = f (xi, yj), with the explanation
that it was the general form of OR models. It was stated that E represents the effectiveness of the

3
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

system under study, xi the variables of the system which are subject to control, and yj those
‘variables’ (implying parameters) not subject to control.

That was all of it. The construct did not appear anywhere else in the book. Nor was it explained as
the basic mathematical form behind any specific category of OR models. But, all models presented
identified uncontrollables as those factors not taken to be decision or policy variables. These
uncontrollable externalities included such factors as capacity, demand, economic indices, unit
costs, and others. Since only operations, not design, was the implied application domain, this
approach was somewhat useful. But, design variables and the Design Dependent Parameters of
reliability, maintainability, producibility, disposability, and others were not mentioned or even
recognized. An index search of modern OR books by yours truly failed to reveal citations that
would embrace DDP’s, much less parameters in general.

With the publication of Applied Operations Research and Management Science by Fabrycky,
Ghare, and Torgersen (Prentice Hall, 1984) a comprehensive mapping of Churchman, et. al. on
most of the categories of OR/MS models became available.6 Although limited to the domain of
operations, this textbook made explicit the role of parameters for the designation of certain
uncontrollables for application in evaluating alternatives. This book was focused exclusively on
the improvement of operations, mostly through optimization. The domain of design and design
dependent parameters still had not been recognized.

It was not until the advent of USAF Project RAMCAD during 1986-88, with TRW and Virginia
Tech as partners, that the need to rigorously evaluate design alternatives was specified as a
deliverable. During the conduct of this research, system parameters were partitioned formally into
design dependent and design independent subsets. The result was a Design Evaluation Function of
the form E = f (X; Yd, Yi), shown last in Figure 2.

Although too late for the First Edition in 1981, all subsequent editions of Systems Engineering and
Analysis by Blanchard and Fabrycky incorporated the DDP concept for system design evaluation.2
Also, an added notion was adopted demonstrating that equivalence must be employed within each
alternative; equivalence utilizing both money flow modeling and optimization modeling across
design variables. Equivalence in this advanced context was shown to be essential for a valid and
fair comparison of mutually exclusive alternatives.

III. The Design Dependent Parameter Paradigm

Each domain of engineering has its own customized analysis methodology for evaluation, and that
is celebrated. But this paper emphasizes the importance of Design Dependent Parameters (DDP’s
- operational outcomes beyond functionality inherent in the design that matter to stakeholders) that
occur within all domains of engineering.

DDP’s are controllable along with design variables during the process of bringing systems and
their products (human-made entities) into being. They are partitioned from Design Independent
Parameters (DIP’s - externalities not controllable during design). This focus is most effective when
based on design for the product life cycle, recognizing the concurrent life-cycle factors of
production, support, phase-out; and disposal as is illustrated conceptually in Figure 3.

4
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

Figure 3. Evaluation in Systems Design and Operations

This innovative DDP paradigm originated and was promulgated based on the congruence of
monetary time value and the time line known as the system life cycle. It is the money time value
(MTV) principle from engineering economics (EE) and optimization (OPT) inherent in OR that
jointly produces an advanced version of ‘equivalence’. Equivalence takes on an expanded
meaning. The expansion establishes a fair basis for comparing mutually exclusive system design
alternatives for each instance of the DDP’s predicted from design alternatives.

Two related areas of Systems Analysis, Engineering Economics (EE) and Operations Research
(OR), are referenced as prime examples. The EE/OR analysis connection is enabled by a Design
Evaluation Function (DEF) derived over the system life-cycle. This function is central to deriving
life-cycle cost from predicted design dependent parameter values that emanate from design
iteration. Feeding mutually exclusive system design alternatives (first made equivalent) to a
Design Evaluation Display (DED) is explained in Section VII.

IV. A Morphology for Systems Engineering

Organization, humankind’s most important innovation, is the time-tested means for bringing
human-made entities into being. Instead of offering systems or system elements per se, SA
properly utilized within SE facilitates the discovery of emergent system properties that provide
desired functionality, capability, or an improved solution. An integration of process (synthesis)
5
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

and evaluation (analysis) is presented that invokes iterating synthesis, analysis, and evaluation over
the system life cycle.7, 8

Figure 4 provides a high-level schematic of the systems engineering process from a product
realization perspective. It is a morphology for linking applied research and the technologies (Block
0) to customer needs (Block 1). It also provides a structure for visualizing the technological
activities of synthesis and analysis. Each of these activities is summarized in the following
paragraphs, with reference to relevant blocks within the morphology. It is essential that the
technological activities of synthesis, analysis, and evaluation of Figure 1 be integrated and applied
iteratively and continuously, utilizing the 10 blocks as presented next.

Figure 4. A Morphology for the Engineering of Systems

Synthesis. To design is to synthesize, project, and propose what might be for a specific set of
customer requirements, often expressed in functional terms (Block 2). Synthesis is the creative
process of putting known things together into new and more useful combinations. Meeting a need
in compliance with customer requirements is the objective of design synthesis.

The primary elements enabling design synthesis are the design team (Block 3) supported by
traditional and computer-based tools for design synthesis (Block 4). Design synthesis is best
accomplished by combining top-down and bottom-up activities (Block 5). Existing and newly
developed components, parts, and subsystems are integrated to generate candidate system designs
for analysis and evaluation.

6
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

Analysis. Analysis of candidate system or product designs is a necessary but not sufficient
ingredient in system design evaluation. It involves the functions of estimation and prediction of
design-dependent parameter (DDP) values (Block 6) and the forecasting of design-independent
parameter (DIP) values from information found in physical and economic databases (Block 7).

Systems analysis and operations research provides a step on the way to system design evaluation,
but adaptation of the models and techniques to the domain of design is required. The adaptation
explicitly recognizes DDPs and incorporates the mandate of customer requirements.

Evaluation. Each candidate design (or design alternative) should be evaluated against other
candidates and checked for compliance with all customers’ requirements. Evaluation of each
candidate in Block 8 is accomplished after receiving DDP values for the candidate from Block 6.
It is the specific values for DDPs that differentiate (or instance) candidate designs.

Design-independent parameter (DIP) values determined in Block 6 are externalities. They apply
across all designs being presented for evaluation. Each candidate is made equivalent in Block 8
before being presented to the customer for design decision. (Block 9). It is in Block 9 that the best
candidate is sought. The preferred choice is subjective and should be made by the customer.

V. Qualitative Discussion of the Morphology

This section presents a discussion of the functions accomplished by each block in the system
design morphology of Figure 4. The discussion will be at a greater level of detail than the
description of synthesis, analysis, and evaluation considered above.

The Technologies (Block 0). Technologies are the product of applied research as indicated in
Block 0. They evolve from the activities of engineering research and development and are
available to be considered for incorporation into candidate system designs. As a driving force,
technologies are the most potent ingredient for advancing the capabilities of systems, products,
structures, and services.

It is the responsibility of the designer/producer or contractor to propose and help the customer
understand what might be for each technological choice. Those producers able to articulate and
deliver appropriate technological solutions on time and within budget will attain and retain a
competitive edge procurement competitions and/or in the global marketplace.

The Customer (Block 1). The purpose of system design is to satisfy customer (and stakeholder)
needs and expectations. This must be with the full realization that the success of a particular design
is ultimately determined by the customer, identified in Block 1.

During the design process, all functions to be provided and all requirements to be satisfied should
be determined from the perspective of the customer, or the customer’s representative. Stakeholder
and any other special interests should also be included in the “voice of the customer” in a way that
reflects all needs and concerns. Included among these must be ecological and human impacts.
Arrow A represents the elicitation of customer needs, desired functionality, and requirements.
Need, Functions, and Requirements (Block 2). The purpose of this block is to gather and specify

7
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

the behavior of the product or system in functional terms. A market study identifies a need, an
opportunity, or a deficiency. From the need comes a definition of the basic requirements, often in
functional terms. Requirements are the input for design and operational criteria, and criteria are
the basis for the evaluation of candidate system and product configurations.

At this point, the product or system should be defined by its function, not its form. Arrow A
indicates customer inputs that define need, functionality, and operational requirements. Arrows B
and C depict the translation and transfer of this information to the design process.

The Design Team (Block 3). The design team should be organized to incorporate in-depth
technical expertise, as well as the broader systems view and thinking. Included must be expertise
in each of the product life-cycle phases and elements contained within the requirements.

Balanced consideration should be present for each phase of the design. Included would be the
satisfaction of intended purpose, followed by producibility, reliability, maintainability,
sustainability disposability, environmental compliance, and others. Arrow B depicts requirements
and design criteria being imposed on the design team and Arrow D indicate the teams contributed
synthesis effort where need, functions, and requirements are the overarching consideration (Arrow
C).

Design Synthesis (Block 4). To design is to project and propose what might be. Design synthesis
is a creative activity that relies on the knowledge of experts about the state of the art as well as the
state of technology. From this knowledge, a number of feasible design alternatives are fashioned
and presented for analysis. Depending upon the phase of the product life cycle, the synthesis can
be in conceptual, preliminary, or in detailed form.

The candidate design is driven by both a top-down functional decomposition and a bottom-up
combinatorial approach utilizing available system elements through Block 5. Arrow E represents
a blending of these approaches. Adequate definition of each design alternative must be obtained
to allow for life-cycle analysis in view of the requirements. Arrow F highlights this definition
process as it pertains to the passing of candidate design alternatives to design analysis in Block 6.

Alternatives should be presented for analysis even though there is little likelihood that they will
prove to be feasible. It is better to consider many alternatives than to overlook one that may be
very good. Alternatives not considered cannot be adopted, no matter how desirable they may have
proven to be. Good advice for impatient students.

Top Down and Bottom Up (Block 5). Traditional engineering design methodology is based on a
bottom-up approach. Starting with a set of defined elements, designers synthesize the product by
finding the most appropriate combination of elements. The bottom-up process is iterative with the
number of iterations determined by the creativity and skill of the design team, as well as by the
complexity of the system design.

But, a top-down approach to design is inherent within the systems engineering process. Starting
with requirements for the external behavior of any component of the system (in terms of the
function provided by that component), that behavior is then decomposed. These decomposed

8
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

functional behaviors are then described in more detail and made specific through an analysis
process. Then, the appropriateness of the choice of functional components is verified by
synthesizing the original entity.

Most systems and products are realized through a combination of the top-down and bottom-up
approaches, with the best mix being largely a matter of judgment and experience. Arrow F
represents the output of candidate designs made ready for analysis.

Estimation and Prediction (Block 6). Cost and effectiveness measures are generated during
estimation and prediction, using models and database information, to obtain design-dependent
parameter (DDP) values for each design alternative (Block 6). These models and simulations are
based on physical laws, assumptions, and empirical data.

The DDP values provide the basis for comparing system designs against input criteria to determine
the relative merit of each candidate. Arrow H represents input from the available databases and
from relevant studies.

Physical and Economic Databases (Block 7). Block 7 provides a resource for the design process,
rather than being an actual step in the process flow. At this point, design-independent parameter
(DIP) values are determined and provided to the activity of design evaluation, as represented by
Arrow I.

There exists a body of knowledge and information that engineers, economists, and technologists
rely on to perform the tasks of analysis and evaluation. This knowledge consists of physical laws,
empirical data, price information, economic forecasts, and other studies and models.

Block 7 also includes descriptions of existing system components, parts, and subsystems. It is
important to use existing databases in doing analysis and synthesis to avoid duplication of effort.
This body of knowledge and experience can be utilized both formally and informally in performing
needed studies, as well as in supporting the decisions yet to follow.

Design Evaluation (Block 8). Design evaluation is an essential activity within system and product
design and the systems engineering process. It should be embedded appropriately within the
process and then pursued continuously as product design and development progresses.

Life-cycle cost is one basis for comparing alternative designs that otherwise meet minimum
requirements specified under performance criteria. The life-cycle cost of each alternative is
determined based on the activity of estimation and prediction just completed. Arrow J indicates
the passing of the evaluated candidates to the decision process. The selection of preferred
alternative(s) can only be made after the life-cycle cost analysis is completed and after
effectiveness measures are defined and applied.

Design Decision (Block 9). Given the variety of customer needs and perceptions as collected in
Block 2, choosing a preferred alternative is not just the simple task of picking the least expensive
design. Input criteria, derived from customer and product requirements, are represented by Arrow
K and by the DDP values and life-cycle costs indicated by Arrow J. The customer or decision

9
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

maker must now trade off life-cycle cost against effectiveness criteria subjectively. The result is
the identification of one or more preferred alternatives that can be used to take the design process
to the next level of detail. Alternatives must ultimately be judged by the customer. Accordingly,
Arrow L depicts the passing of evaluated candidate designs to the customer for review and
decision.

Alternatives that are found to be unacceptable in performance terms can be either discarded or
reworked with new alternatives sought. Alternatives that meet all, or the most important,
performance criteria can then be evaluated based on estimations and predictions of DDP values.
This should be accompanied by an assessment of risk.

Within the context of synthesis, analysis, and evaluation is the opportunity to implement systems
engineering over the life cycle in measured ways that can help ensure its effectiveness in
professional practice. It is a morphology for linking applied research and technologies (Block 0)
to customer needs (Block 1). It also provides a structure for visualizing the technological activities
of synthesis, analysis, and evaluation. Each of these activities is summarized in the paragraphs that
follow, with reference to relevant blocks within the morphology.

VI. Economic Models for System Evaluation

Two broad categories of analytical models are central to formulating a Design Evaluation Function
for evaluating mutually exclusive design alternative. These are Money Flow Modeling and
Economic Optimization Modeling.9

Money Flow Modeling. Money flow modeling is central to the field of Engineering Economics
(EE). Engineering economics has always been associated with time; the time value of money,
receipts and disbursements over time, etc. The central “model” in engineering economics is the
money flow diagram, depicting estimates of income and outlay over time. Accordingly, EE and
the product or system life cycle are on the same “dimension”.

Algebraic expressions for the Present Equivalent (PE), Annual Equivalent (AE), and the Future
Equivalent (FE), as well as expressions for the Internal Rate of return and the Payback Period are
well known in EE. A general economic equivalence function subsuming each of these equivalence
approaches is given in Figure 5.

Symbols in the Equivalence Function are defined as follows:

Ft = positive or negative money flow at the end of year t

t = 0, 1, 2, . . . , n
i = annual rate of interest
n = number of years

There is nothing new here except recognition that EE and life-cycle mapping, as in Figure 3, have
much in common. System thinking at a higher level is the key consideration.

10
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

To Determine Cost Equivalence

Over the System and Product Life-Cycle
Utilize the Economic Equivalence Function
PE, AE, or, FE = f (Ft, i, n)

Figure 5. Equivalence Function for Money Flow Analysis

The Present Equivalent, Annual Equivalent, or Future Equivalent amounts are consistent bases for
the evaluation of a single alternative, or for the comparison of mutually exclusive alternatives.
These bases for comparison are actually decision numbers, not budgetary amounts.

A disadvantage of money flow modeling is that design dependent parameters are implicit, as are
design variables. These are made explicit by economic optimization modeling presented next.

Economic Optimization Modeling. Design evaluation in terms of life-cycle cost and system
effectiveness can be facilitated by adopting the Design Dependent Parameter approach. This
approach is a mathematical way to link design actions with operational outcomes. It utilizes a
Design Evaluation Function (DEF) illustrated in Figure 6 (also see Figure 2).

To Optimize Within Each Alternative

Mathematically Link Design and Operations
Utilizing the Design Optimization Function
Equivalent LCC = f (X; Yd, Yi)

Figure 6. Equivalence Function for Economic Optimization

The following definitions of terms apply to the DEF in Figure 6:

E = a life-cycle complete evaluation measure such as equivalent life-cycle cost

(PE, AE, or FE)
X = design variables (e.g., number of deployed units, membrane thickness,
retirement age, repair channels, rated thrust, pier spacing, etc.)
Yd = design dependent parameters (e.g., weight, reliability, design life, capacity,
producibility, maintainability, supportability, etc.)
Yi = design independent parameters (e.g., energy cost, cost of money, labor
rates, material cost per unit, shortage cost penalty, etc.)

The Design Evaluation Function must be linked to all phases of the system life cycle. This function,
incorporating both design dependent and design independent parameters, facilitates design
optimization. It provides the basis for a clarification of the true difference between alternatives (a
design-based choice) and optimization (an analysis-based choice).

11
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

VII. Choosing the Preferred Alternative

The Decision Evaluation Display (DED) method of making decisions is presented (and preferred
for choosing from among mutually exclusive design alternatives and/or candidate systems). Some
decision makers consider ranking, elimination, weighting, rating, and similar selection rules to be
impediments to the effective application of insight, intuition, and judgment. An alternative is to
put the emphasis on visually displaying and communicating only the differences upon which a
decision depends, leaving the remaining path to a decision to the decision maker.

Figure 7. The Decision Evaluation Display for Multiple Criteria

The DED shown in Figure 7 is based on the premise that differences between alternatives and the
degree of compliance with multiple criteria are all that most decision makers need or desire.
Experienced decision makers possess an inherent and acquired ability to process information
needed to trade off competing criteria. Accordingly, the decision evaluation display is
recommended as a means for simultaneously exhibiting the differences that multiple alternatives
create in the face of multiple criteria. Component parts of the DED are explained below:

1) Alternatives (A1, A2, A3). Two or more alternatives appear as vertical lines in the field of the
decision evaluation display.
2) Equivalent Life-Cycle Cost. The horizontal axis represents present equivalent, annual
equivalent, or future equivalent cost. Specific cost values are indicated on the axis for each

12
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

alternative displayed, with cost increasing from left to right. In this way, equivalent economic
differences between alternatives are made visible.
3) Functional criteria (F). Functions individually, or all together and represented by a derived
index, appear at the far left of the vertical axes.
4) Other criteria (C1, C2, C3). Other vertical axes represent one or more criteria, usually
noneconomic in nature. Each axis has its own scale, depending upon the nature of the factor
represented.
5) Other criteria thresholds. Horizontal lines emanating from all vertical axes represent
threshold or limiting values for functional and noneconomic criteria (less than, equal to, or
greater than).
6) Predicted and/or estimated values. Anticipated outcomes for each alternative (based on
prediction and/or estimation) are entered in circles placed above, on, or below the thresholds.
In this way, differences between desired and anticipated outcomes for each alternative are
made visible.

Equivalent cost (or profit) from Figure 5, or from Figure 6, or from a DEF combining both, is
shown on the horizontal axis of Figure 7, as an objective measure. The aim in decision making is
to select the mutually exclusive alternative with the lowest equivalent cost (or maximum
equivalent profit) that adequately satisfies the other criteria.

Multiple criteria considerations arise in life-cycle cost analyses during design when both economic
and non-economic factors are present in the evaluation. Accordingly, design evaluation in terms
of life-cycle cost and system effectiveness is an area in need of attention by the producer and
customer acting together. In this situation, a Design Evaluation Display, simultaneously exhibiting
both cost and effectiveness measures can be quite helpful.

Requirement thresholds are shown on the display. These are useful to the decision-maker in
assessing the degree to which each alternative meets functional and other criteria. This approach
is recommended for most applications, because subjective evaluation by the customer and
producer can be directly accommodated in a visible way. Trade-offs become visible and can be
subjectively considered

VIII. Summary and Conclusions

Legions of academicians and practicing professionals are continuing to develop and apply
powerful tools for analysis, experimentation, modeling, simulation, animation, etc. to the domain
of operations. These individuals represent the fields of industrial engineering, engineering
management, operations research, management science, systems management, and others. Too
often the well- intended efforts of these individuals are mistakenly called "systems engineering".
These important domains and professional fields are necessary but not sufficient.

Some important areas in need of consideration for improvement in systems engineering education
and professional practice are:

1) Systems analysis is necessary but not sufficient for SE, and this finding should be imparted
in the teaching of each area, with full recognition of the potential value of their integration.

13
From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

2) Design dependent parameters are the key to linking system design to the world being modified
by design and all impacted people.
3) A DDP based design evaluation function, traceable to OR, should better guide the teaching of
design space exploration within the functional domain, backed by equivalence based on life-
cycle economics and design optimization, now imparted by separate courses.
4) When driven by synthesis and the prediction and/or estimation of DDP values, and the
incorporation of optimization across design variables, design evaluation will likely become
the key to continuous operational improvement through system design.
5) Design impacts on the natural world, including humans, should be incorporated in academic
course work (including undergraduate capstone projects) and the project or thesis research
required for a graduate SE degree.
6) Graduate study in SE should focus on preparing candidates for service as engineering
interdisciplinarians, who think always about “the end before the beginning”.
7)) The overarching goal should be to promulgate systems thinking focused on the human - made
world; that is, the world emerging from system design by humans.10

Entirely too much engineering time and talent is being expended addressing operational
deficiencies plaguing the human-made world. Operational problem mitigation will always be
needed, but the dramatic payoff for humankind lies in operational problem avoidance through
system thinking, as recommended for addressing pervasive grand challenges.11

REFERENCES

1) Panitz, B., Senior Editor, Training Technology’s Maestros, American Society for Engineering
Education, ASEE PRISM, November, 1997.
2) Blanchard, B. S. and W. J. Fabrycky, Systems Engineering and Analysis, Fifth (30th Anniversary)
Edition, Pearson Education - Prentice Hall, 2011.
3) Fabrycky, W. J., Systems Engineering: Its Emerging Academic and Professional Attributes,
Proceedings, ASEE Annual Conference and Exposition, Louisville, KY, June 21, 2010.
4) Emerson, H. P. and C. E. Naehring, Origins of Industrial Engineering, Industrial Engineering and
Management Press, Institute of Industrial Engineers, 1988.
5) Churchman, C. W., R. L. Ackoff, and E. L. Arnoff, Introduction to Operations Research, John Wiley,
1957.
6) Fabrycky, W. J., P. M. Ghare, and P. E. Torgersen, Applied Operations Research and Management
Science, Prentice Hall, 1984.
7) Fabrycky, W. J., "Designing for the Life Cycle," Mechanical Engineering, Vol. 109, No. 1, January
1987.
8) Fabrycky, W. J. and B. S. Blanchard, "Life-Cycle Design," Chapter 24 in Design Management: A
Handbook of Issues and Methods, Edited by Mark Oakley, Basil Blackwell, Ltd., Oxford, UK, 1990.
9) Fabrycky, W. J., “Evaluation in Systems Engineering”, Article E1.28.04.05 in the UNESCO
Encyclopedia of Life Support Systems, EOLSS Publishers Co. Ltd., 2003.
10) Fabrycky, W. J., “Thinking About Systems Thinking”, Proceedings, Third International Conference
on Complex System Design and Management (CSDM), Paris, France, December, 2012.
11) Educating the Engineer of 2020, National Academy of Engineering, Washington, DC: National
Academy Press, 2005.

14
 From the Proceedings, ASEE Annual Conference and Exposition, Seattle, WA, June 15, 2015

Biography

Wolter J. Fabrycky, Lawrence Professor Emeritus of Industrial and Systems Engineering at

Virginia Tech and Chairman, Academic Applications International, Inc. Registered Professional
Engineer in Arkansas (1960) and Virginia (1965). Ph.D. in Engineering, Oklahoma State
University (1962); M.S. in Industrial Engineering, University of Arkansas (1958); B.S. in
Industrial Engineering, Wichita State University (1957). Taught at Arkansas (1957-60) and
Oklahoma State (1962-65) and then joined Virginia Tech in 1965. Served as Founding Chairman
of Systems Engineering, Associate Dean of Engineering, and then as University Dean of Research
over a period of 12 years. Received the Lohmann Medal from Oklahoma State for Outstanding
Contributions to ISE Education and Research (1992) and the Armitage Medal for Outstanding
Contributions to Logistics Engineering Literature (2004). Received the Holtzman Distinguished
Educator Award from the Institute of Industrial Engineers (1990) and the Pioneer Award from the
International Council on Systems Engineering (2000). Founder (2005) and President of the Omega
Alpha Association: the Systems Engineering Honor Society and President of Alpha Pi Mu: the
Industrial Engineering Honor Society (2010-12). Elected to the rank of Fellow in the American
Association for the Advancement of Science (1980), the American Society for Engineering
Education (2007), the Institute of Industrial Engineers (1978), and the International Council on
Systems Engineering (1999). Served or serving on the Boards of ABET, APM, ASEE, IIE,
INCOSE, and OAA. Co-author of six Prentice Hall textbooks and Editor of the Pearson Prentice
Hall International Series in Industrial and Systems Engineering.

15

View publication stats