CMGT 580Introduction to Systems Engineering ManagementClass .docx

CMGT 580
Introduction to Systems Engineering Management
Class 5
Chapter 6 Needs Analysis
Reminder where Needs Analysis fits in process
“there is a feasible approach to fulfilling the need at an
affordable cost and within an acceptable level of risk”
Concept Development Stage – Needs Analysis
Originating a new system
Needs-driven example: 1960's new laws for automobiles (fuel
economy, safety, pollution control)
Technology-driven new systems (space, computers)
External events (new threats, shift in customer demand,
economics)
Since there‘s no preceding phase the inputs come from other
sources
Applying the Systems Engineering Method
The focus of attention in this phase is on the system operational

objectives and goes no deeper than the subsystem level.”
More detail on next charts
Systems Engineering Method applied to the Needs Analysis
Phase
Requirements analysis -- Operations analysis
Clarifying requirements
Functional definition -- Functional analysis
Translating requirements into functions
Allocating requirements
Define interfaces
Physical definition -- Feasibility definition
Develop alternative designs
Perform trade-offs to select a preferred approach

Develop detail for the selected design
Design validation -- Needs validation
Model system environment
Verification
Operations Analysis
Detailed identification of perceived deficiencies in current
systems
Obsolescence is a prevalent driving force for new systems
The output of this activity is operational objectives for new
system
Functional Analysis
This is an extension of operational studies
Establish if there's a possible technical approach to a system

It's not necessary to visualize a best configuration
Feasibility Definition
Feasibility addresses functional design, physical
implementation, cost, external constraints and interactions
No attempt is made to optimize the design
Feasibility can be difficult in technology-driven systems
Needs Validation
Examine the validity of the results of the previous steps
Use an operational effectiveness analysis tool (model) based on
a set of scenarios
These simulations are evaluated based on criteria called
Measures of Effectiveness

This effectiveness analysis determines if a system concept is
feasible and satisfies the operational objectives
MOE and MOP Metrics
Measures of Effectiveness (MOE) – indicates the degree to
which the whole system achieves its objectives under specified
conditions
Measures of Performance (MOP) – quantitative metric of the
whole system’s characteristics or performance of a particular
attribute, typically a level of physical performance
Development of Operational Requirements (CONOPS)
Operational distribution or deployment: Where will the system
be utilized?
Mission profile or scenario: What must the system do to
accomplish its objective?
Performance and related parameters: What are the critical
system parameters to accomplish mission?
Utilization environments: What are the different environments
that the various system components will be utilized in?
Effectiveness requirements: Given what the system will
perform, what level of effectiveness or efficiency must it
operate at?
Operational Life Cycle: What does the user anticipate will be
the useful life for this system?
Environment: What environment will the system be expected to

operate in an effective manner?
System Operational Requirements
System operational requirements are the output of the needs
analysis phase
“it is essential that these requirements be clear, complete,
consistent, and feasible of accomplishment”
Not stated in terms of implementation nor biased toward a
particular conceptual approach
All requirements should be measurable (testable)
Types of Requirements
INCREASING
DETAIL
Customer / User Requirements
Statement of fact and assumptions that define the expectations
of the system in terms of objectives, environment, constraints,
and MOEs.
Functional Requirements

The necessary task, action or activity that must be accomplished
Performance Requirements
The extent to which a function must be executed; generally
measured in terms of quantity, quality, coverage, timeliness or
readiness.
Design Requirements
The "build-to," "code to," and "buy to" requirements for
products and "how to execute" requirements for processes
expressed in technical data packages & technical manuals.
Types of Requirements
Derived Requirements: additional requirements, inferred from
context & user needs, not always specified by customer: but
needed to make system work in the real world
Statutory and Regulatory
Certification
Design Considerations

Interfaces
Allocated Requirement: the portion of the system requirement
assigned to a subsystem.
Example: 100 kg system with two subsystems
Subsystem 1 allocated req’t 70 kg
Subsystem 2 allocated req’t 30 kg
Requirements Goals
Complete - covers all areas
Understandable - not open to interpretation
Partitioned - useful work break down structure
Maintainable - can be re-written
Communicable - everyone can agree

Usable - designers understand what is to be done
Definitive - thoroughly answers ‘what’ to do
Abstract - shows what, not how
Verification of Requirements
Inspection: Examination of items to determine whether they
conform to specified requirements.
Analysis: Using established technical or math models,
simulations & procedures to provide evidence that stated req’ts
were met.
Demonstration: Actual operation of an item to provide evidence
that the required functions were accomplished under specific
scenarios.
Test: Application of scientific principles and procedures to
determine the properties or functional capabilities of items.

Homework 5 due Feb 21
Reply posts due Feb 24
6.6 Assume that you have a business in garden care equipment
and are planning to develop one or two models of lawn tractors
to serve suburban homeowners. Consider the needs of the
majority of such potential customers and write at least six
operational requirements that express these needs. Remember
the qualities of good requirements as you do so.
Coming up - Class 6 Feb 25
Read Chapter 7
Homework 6 Problem 7.9.a,b,d due Feb 28
SYSTEMS ENGINEERING
PRINCIPLES AND
PRACTICE
SECOND EDITION
Alexander Kossiakoff
William N. Sweet
Samuel J. Seymour
Steven M. Biemer

A JOHN WILEY & SONS, INC. PUBLICATION
ffirs02.indd iiiffirs02.indd iii 2/8/2011 11:05:45
AM2/8/2011 11:05:45 AM
ffirs04.indd viffirs04.indd vi 2/8/2011 11:05:47
AM2/8/2011 11:05:47 AM
SYSTEMS
ENGINEERING
PRINCIPLES AND
PRACTICE
ffirs.indd iffirs.indd i 2/8/2011 11:05:44 AM2/8/2011
11:05:44 AM
WILEY SERIES IN SYSTEMS ENGINEERING
AND MANAGEMENT
Andrew P. Sage, Editor
A complete list of the titles in this series appears at the end of
this volume.
ffirs01.indd iiffirs01.indd ii 2/8/2011 11:05:44 AM2/8/2011
11:05:44 AM

SYSTEMS ENGINEERING
PRINCIPLES AND
PRACTICE
SECOND EDITION
William N. Sweet
Samuel J. Seymour
Steven M. Biemer
A JOHN WILEY & SONS, INC. PUBLICATION
ffirs02.indd iiiffirs02.indd iii 2/8/2011 11:05:45
AM2/8/2011 11:05:45 AM
Copyright © 2011 by John Wiley & Sons, Inc. All rights
reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a
retrieval system, or transmitted in any form or
by any means, electronic, mechanical, photocopying, recording,
scanning, or otherwise, except as
permitted under Section 107 or 108 of the 1976 United States
Copyright Act, without either the prior
written permission of the Publisher, or authorization through
payment of the appropriate per-copy fee
to the Copyright Clearance Center, Inc., 222 Rosewood Drive,
Danvers, MA 01923, (978) 750-8400,
fax (978) 750-4470, or on the web at www.copyright.com.

Requests to the Publisher for permission
should be addressed to the Permissions Department, John Wiley
& Sons, Inc., 111 River Street, Hoboken,
NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at
http://www.wiley.com/go/permission.
Limit of Liability/Disclaimer of Warranty: While the publisher
and author have used their best efforts in
preparing this book, they make no representations or warranties
with respect to the accuracy or
completeness of the contents of this book and specifi cally
disclaim any implied warranties of
merchantability or fi tness for a particular purpose. No warranty
may be created or extended by sales
representatives or written sales materials. The advice and
strategies contained herein may not be suitable
for your situation. You should consult with a professional where
appropriate. Neither the publisher nor
author shall be liable for any loss of profi t or any other
commercial damages, including but not limited to
special, incidental, consequential, or other damages.
For general information on our other products and services or
for technical support, please contact our
Customer Care Department within the United States at (800)
762-2974, outside the United States at
(317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic
formats. Some content that appears in print may
not be available in electronic formats. For more information
about Wiley products, visit our web site at
www.wiley.com.
Library of Congress Cataloging-in-Publication Data:

Systems engineering : principles and practice/Alexander
Kossiakoff ... [et al.].—2nd ed.
p. cm.—(Wiley series in systems engineering and
management; 67)
Rev. ed. of: Systems engineering: principles and
practices/Alexander
Kossiakoff, William N. Sweet. 2003.
ISBN 978-0-470-40548-2 (hardback)
1. Systems engineering. I. Kossiakoff, Alexander, 1945– II.
Title.
TA168.K68 2010
620.001′171–dc22
2010036856
Printed in the United States of America
oBook ISBN: 9781118001028
ePDF ISBN: 9781118001011
ePub ISBN: 9781118009031
10 9 8 7 6 5 4 3 2 1
ffirs03.indd ivffirs03.indd iv 2/8/2011 11:05:46
AM2/8/2011 11:05:46 AM
To Alexander Kossiakoff,
who never took “ no ” for an answer and refused to believe
that anything was
impossible. He was an extraordinary problem solver, instructor,
mentor, and
friend.

Samuel J. Seymour
Steven M. Biemer
ffirs04.indd vffirs04.indd v 2/8/2011 11:05:47 AM2/8/2011
11:05:47 AM
ffirs04.indd viffirs04.indd vi 2/8/2011 11:05:47
AM2/8/2011 11:05:47 AM
LIST OF ILLUSTRATIONS xiii
LIST OF TABLES xvii
PREFACE TO THE SECOND EDITION xix
PREFACE TO THE FIRST EDITION xxiii
PART I FOUNDATIONS OF SYSTEMS ENGINEERING 1
1 SYSTEMS ENGINEERING AND THE WORLD OF
MODERN
SYSTEMS 3
1.1 What Is Systems Engineering? 3
1.2 Origins of Systems Engineering 5
1.3 Examples of Systems Requiring Systems Engineering 10
1.4 Systems Engineering as a Profession 12

1.5 Systems Engineer Career Development Model 18
1.6 The Power of Systems Engineering 21
1.7 Summary 23
Problems 25
Further Reading 26
2 SYSTEMS ENGINEERING LANDSCAPE 27
2.1 Systems Engineering Viewpoint 27
2.2 Perspectives of Systems Engineering 32
2.3 Systems Domains 34
2.4 Systems Engineering Fields 35
2.5 Systems Engineerng Approaches 36
2.6 Systems Engineering Activities and Products 37
2.7 Summary 38
Problems 39
Further Reading 40
CONTENTS
vii
ftoc.indd viiftoc.indd vii 2/8/2011 11:05:50 AM2/8/2011
11:05:50 AM

viii CONTENTS
3 STRUCTURE OF COMPLEX SYSTEMS 41
3.1 System Building Blocks and Interfaces 41
3.2 Hierarchy of Complex Systems 42
3.3 System Building Blocks 45
3.4 The System Environment 51
3.5 Interfaces and Interactions 58
3.6 Complexity in Modern Systems 60
3.7 Summary 64
Problems 66
Further Reading 67
4 THE SYSTEM DEVELOPMENT PROCESS 69
4.1 Systems Engineering through the System Life Cycle 69
4.2 System Life Cycle 70
4.3 Evolutionary Characteristics of the Development Process 82
4.4 The Systems Engineering Method 87
4.5 Testing throughout System Development 103
4.6 Summary 106

Problems 108
Further Reading 109
5 SYSTEMS ENGINEERING MANAGEMENT 111
5.1 Managing System Development and Risks 111
5.2 WBS 113
5.3 SEMP 117
5.4 Risk Management 120
5.5 Organization of Systems Engineering 128
5.6 Summary 132
Problems 133
Further Reading 134
PART II CONCEPT DEVELOPMENT STAGE 137
6 NEEDS ANALYSIS 139
6.1 Originating a New System 139
6.2 Operations Analysis 146
6.3 Functional Analysis 151
6.4 Feasibility Defi nition 153
ftoc.indd viiiftoc.indd viii 2/8/2011 11:05:50 AM2/8/2011
11:05:50 AM

CONTENTS ix
6.5 Needs Validation 155
6.6 System Operational Requirements 158
6.7 Summary 162
Problems 163
Further Reading 164
7 CONCEPT EXPLORATION 165
7.1 Developing the System Requirements 165
7.2 Operational Requirements Analysis 170
7.3 Performance Requirements Formulation 178
7.4 Implementation of Concept Exploration 185
7.5 Performance Requirements Validation 189
7.6 Summary 191
Problems 193
Further Reading 194
8 CONCEPT DEFINITION 197
8.1 Selecting the System Concept 197
8.2 Performance Requirements Analysis 201
8.3 Functional Analysis and Formulation 206

8.4 Functional Allocation 212
8.5 Concept Selection 214
8.6 Concept Validation 217
8.7 System Development Planning 219
8.8 Systems Architecting 222
8.9 System Modeling Languages: Unifi ed Modeling Language
(UML) and Systems Modeling Language (SysML) 228
8.10 Model-Based Systems Engineering (MBSE) 243
8.11 System Functional Specifi cations 246
8.12 Summary 247
Problems 250
Further Reading 252
9 DECISION ANALYSIS AND SUPPORT 255
9.1 Decision Making 256
9.2 Modeling throughout System Development 262
9.3 Modeling for Decisions 263
9.4 Simulation 272
ftoc.indd ixftoc.indd ix 2/8/2011 11:05:50 AM2/8/2011
11:05:50 AM

x CONTENTS
9.5 Trade-Off Analysis 282
9.6 Review of Probability 295
9.7 Evaluation Methods 299
9.8 Summary 308
Problems 311
Further Reading 312
PART III ENGINEERING DEVELOPMENT STAGE 315
10 ADVANCED DEVELOPMENT 317
10.1 Reducing Program Risks 317
10.2 Requirements Analysis 322
10.3 Functional Analysis and Design 327
10.4 Prototype Development as a Risk Mitigation Technique
333
10.5 Development Testing 340
10.6 Risk Reduction 349
10.7 Summary 350
Problems 352

Further Reading 354
11 SOFTWARE SYSTEMS ENGINEERING 355
11.1 Coping with Complexity and Abstraction 356
11.2 Nature of Software Development 360
11.3 Software Development Life Cycle Models 365
11.4 Software Concept Development: Analysis and Design 373
11.5 Software Engineering Development: Coding and Unit Test
385
11.6 Software Integration and Test 393
11.7 Software Engineering Management 396
11.8 Summary 402
Problems 405
Further Reading 406
12 ENGINEERING DESIGN 409
12.1 Implementing the System Building Blocks 409
12.2 Requirements Analysis 414
12.3 Functional Analysis and Design 416
12.4 Component Design 419
12.5 Design Validation 432
ftoc.indd xftoc.indd x 2/8/2011 11:05:50 AM2/8/2011

11:05:50 AM
CONTENTS xi
12.6 CM 436
12.7 Summary 439
Problems 441
Further Reading 442
13 INTEGRATION AND EVALUATION 443
13.1 Integrating, Testing, and Evaluating the Total System 443
13.2 Test Planning and Preparation 450
13.3 System Integration 455
13.4 Developmental System Testing 462
13.5 Operational Test and Evaluation 467
13.6 Summary 475
Problems 478
Further Reading 478
PART IV POSTDEVELOPMENT STAGE 481
14 PRODUCTION 483
14.1 Systems Engineering in the Factory 483

14.2 Engineering for Production 485
14.3 Transition from Development to Production 489
14.4 Production Operations 492
14.5 Acquiring a Production Knowledge Base 497
14.6 Summary 500
Problems 502
Further Reading 503
15 OPERATIONS AND SUPPORT 505
15.1 Installing, Maintaining, and Upgrading the System 505
15.2 Installation and Test 507
15.3 In-Service Support 512
15.4 Major System Upgrades: Modernization 516
15.5 Operational Factors in System Development 520
15.6 Summary 522
Problems 523
Further Reading 524
INDEX 525
ftoc.indd xiftoc.indd xi 2/8/2011 11:05:50 AM2/8/2011
11:05:50 AM

ftoc.indd xiiftoc.indd xii 2/8/2011 11:05:50 AM2/8/2011
11:05:50 AM
xiii
1.1 Career opportunities and growth 14
1.2a Technical orientation phase diagram 16
1.2b Technical orientation population density distribution
16
1.3a Systems engineering (SE) career elements derived from
quality work
experiences 19
1.3b Components of employer development of systems
engineers 19
1.4 “ T ” model for systems engineer career development
20
2.1a Performance versus cost 29
2.1b Performance/cost versus cost 29
2.2 The ideal missile design from the viewpoint of various
specialists 31
2.3 The dimensions of design, systems engineering, and
project planning
and control 32
2.4 Systems engineering domains 34
2.5 Examples of systems engineering fi elds 35
2.6 Examples of systems engineering approaches 36
2.7 Life cycle systems engineering view 37
3.1 Knowledge domains of systems engineer and design
specialist 45
3.2 Context diagram 53

3.3 Context diagram for an automobile 54
3.4 Environments of a passenger airliner 56
3.5 Functional interactions and physical interfaces 59
3.6 Pyramid of system hierarchy 63
4.1 DoD system life cycle model 71
4.2 System life cycle model 72
4.3 Principal stages in system life cycle 75
4.4 Concept development phases of system life cycle 76
4.5 Engineering development phases in system life cycle 78
4.6 Principal participants in a typical aerospace system
development 86
4.7 DoD MIL - STD499B 90
4.8 IEEE - 1220 systems engineering process 90
4.9 EIA - 632 systems engineering process 91
LIST OF ILLUSTRATIONS
fbetw01.indd xiiifbetw01.indd xiii 2/9/2011 6:29:47
PM2/9/2011 6:29:47 PM
xiv LIST OF ILLUSTRATIONS
4.10 ISO - 15288 Systems engineering process 92
4.11 Systems engineering method top - level fl ow diagram
92
4.12 Systems engineering method fl ow diagram 94
4.13 Spiral model of the defense system life cycle 104
5.1 Systems engineering as a part of project management
112
5.2 Place of SEMP in program management plans 118
5.3 Variation of program risk and effort throughout system
development 121
5.4 Example of a risk mitigation waterfall chart 122
5.5 An example of a risk cube display 124

6.1 Needs analysis phase in the system life cycle 140
6.2 Needs analysis phase fl ow diagram 147
6.3 Objectives tree structure 150
6.4 Example objectives tree for an automobile 151
6.5 Analysis pyramid 156
7.1 Concept exploration phase in system life cycle 166
7.2 Concept exploration phase fl ow diagram 170
7.3 Simple requirements development process 171
7.4 Triumvirate of conceptual design 175
7.5 Hierarchy of scenarios 177
7.6 Function category versus functional media 181
8.1 Concept defi nition phase in system life cycle 198
8.2 Concept defi nition phase fl ow diagram 202
8.3 IDEF0 functional model structure 208
8.4 Functional block diagram of a standard coffeemaker 210
8.5 Traditional view of architecture 223
8.6 DODAF version 2.0 viewpoints 227
8.7 UML models 229
8.8 Use case diagram 231
8.9 UML activity diagram 233
8.10 UML sequence diagram 234
8.11 Example of a class association 235
8.12 Example of a class generalization association 236
8.13 Class diagram of the library check - out system 237
8.14 SysML models 237
8.15 SysML requirements diagram 238
8.16 SysML block defi nition 240
8.17 SysML block associations 241
8.18a SysML functional hierarchy tree 242
8.18b SysML activity diagram 242
8.19 Baker ’ s MDSD subprocesses 244
8.20 Baker ’ s information model for MDSD 244
9.1 Basic decision - making process 256
9.2 Traditional hierarchical block diagram 265
9.3 Context diagram of a passenger aircraft 266
9.4 Air defense functional fl ow block diagram 267

fbetw01.indd xivfbetw01.indd xiv 2/9/2011 6:29:47
PM2/9/2011 6:29:47 PM
LIST OF ILLUSTRATIONS xv
9.5 System effectiveness simulation 275
9.6 Hardware - in - the - loop simulation 277
9.7 Virtual reality simulation 280
9.8 Candidate utility functions 289
9.9 Criteria profi le 290
9.10 Union of two events 297
9.11 Conditional events 297
9.12 AHP example 300
9.13 AHP results 301
9.14 Decision tree example 302
9.15 Decision path 302
9.16 Decision tree solved 303
9.17 Utility function 304
9.18 Decision tree solved with a utility function 304
9.19 Example of cost - effectiveness integration 305
9.20 QFD house of quality 307
10.1 Advanced development phase in system life cycle 318
10.2 Advanced development phase fl ow diagram 321
10.3 Test and evaluation process of a system element 345
11.1 IEEE software systems engineering process 357
11.2 Software hierarchy 359
11.3 Notional 3 - tier architecture 359
11.4 Classical waterfall software development cycle 367
11.5 Software incremental model 369
11.6 Spiral model 370
11.7 State transition diagram in concurrent development
model 371
11.8 User needs, software requirements and specifi cations

376
11.9 Software generation process 376
11.10 Principles of modular partitioning 379
11.11 Functional fl ow block diagram example 381
11.12 Data fl ow diagram: library checkout 381
11.13 Robustness diagram: library checkout 384
12.1 Engineering design phase in system life cycle 410
12.2 Engineering design phase in relation to integration and
evaluation 411
12.3 Engineering design phase fl ow diagram 413
13.1 Integration and evaluation phase in system life cycle
445
13.2 Integration and evaluation phase in relation to
engineering design 445
13.3 System test and evaluation team 446
13.4 System element test confi guration 456
13.5 Subsystems test confi guration 459
13.6a Operation of a passenger airliner 469
13.6b Operational testing of an airliner 469
13.7 Test realism versus cost 471
14.1 Production phase in system life cycle 484
14.2 Production phase overlap with adjacent phases 485
fbetw01.indd xvfbetw01.indd xv 2/9/2011 6:29:47
PM2/9/2011 6:29:47 PM
xvi LIST OF ILLUSTRATIONS
14.3 Production operation system 494
15.1 Operations and support phase in system life cycle 506
15.2 System operations history 507
15.3 Non - disruptive installation via simulation 510
15.4 Non - disruptive installation via a duplicate system 511

fbetw01.indd xvifbetw01.indd xvi 2/9/2011 6:29:47
PM2/9/2011 6:29:47 PM
xvii
1.1 Examples of Engineered Complex Systems: Signal and
Data Systems 11
1.2 Examples of Engineered Complex Systems: Material and
Energy
Systems 11
2.1 Comparison of Systems Perspectives 33
2.2 Systems Engineering Activities and Documents 38
3.1 System Design Hierarchy 43
3.2 System Functional Elements 47
3.3 Component Design Elements 49
3.4 Examples of Interface Elements 60
4.1 Evolution of System Materialization through the System
Life Cycle 84
4.2 Evolution of System Representation 88
4.3 Systems Engineering Method over Life Cycle 102
5.1 System Product WBS Partial Breakdown Structure 114
5.2 Risk Likelihood 125
5.3 Risk Criticality 125
5.4 Sample Risk Plan Worksheet 128
6.1 Status of System Materialization at the Needs Analysis
Phase 143
7.1 Status of System Materialization of the Concept
Exploration Phase 168
8.1 Status of System Materialization of Concept Defi nition
Phase 200
8.2 Use Case Example — “ Check - out Book ” 232
9.1 Decision Framework 259
9.2 Simon’s Decision Process 261

9.3 Weighted Sum Integration of Selection Criteria 288
9.4 Weighted Sum of Actual Measurement 289
9.5 Weighted Sum of Utility Scores 290
9.6 Trade-Off Matrix Example 293
10.1 Status of System Materialization at the Advanced
Development Phase 320
10.2 Development of New Components 326
10.3 Selected Critical Characteristics of System Functional
Elements 329
10.4 Some Examples of Special Materials 335
11.1 Software Types 361
LIST OF TABLES
fbetw02.indd xviifbetw02.indd xvii 2/9/2011 6:29:55
PM2/9/2011 6:29:55 PM
xviii LIST OF TABLES
11.2 Categories of Software - Dominated Systems 362
11.3 Differences between Hardware and Software 364
11.4 Systems Engineering Life Cycle and the Waterfall Model
368
11.5 Commonly Used Computer Languages 387
11.6 Some Special - Purpose Computer Languages 388
11.7 Characteristics of Prototypes 390
11.8 Comparison of Computer Interface Modes 391
11.9 Capability Levels 398
11.10 Maturity Levels 399
12.1 Status of System Materialization at the Engineering
Design Phase 412
12.2 Confi guration Baselines 437
13.1 Status of System Materialization at the Integration and
Evaluation

Phase 448
13.2 System Integration and Evaluation Process 449
13.3 Parallels between System Development and Test and
Evaluation
(T & E) Planning 451
fbetw02.indd xviiifbetw02.indd xviii 2/9/2011 6:29:55
PM2/9/2011 6:29:55 PM
xix
It is an incredible honor and privilege to follow in the
footsteps of an individual who
had a profound infl uence on the course of history and the fi eld
of systems engineering.
Since publication of the fi rst edition of this book, the fi eld of
systems engineering has
seen signifi cant advances, including a signifi cant increase in
recognition of the disci-
pline, as measured by the number of conferences, symposia,
journals, articles, and
books available on this crucial subject. Clearly, the fi eld has
reached a high level of
maturity and is destined for continued growth. Unfortunately,
the fi eld has also seen
some sorrowful losses, including one of the original authors,
Alexander Kossiakoff,
who passed away just 2 years after the publication of the book.
His vision, innovation,
excitement, and perseverance were contagious to all who
worked with him and he is
missed by the community. Fortunately, his vision remains and
continues to be the

driving force behind this book. It is with great pride that we
dedicate this second edition
to the enduring legacy of Alexander Ivanovitch Kossiakoff.
ALEXANDER KOSSIAKOFF, 1914 – 2005
Alexander Kossiakoff, known to so many as “ Kossy, ” gave
shape and direction to the
Johns Hopkins University Applied Physics Laboratory as its
director from 1969 to
1980. His work helped defend our nation, enhance the
capabilities of our military,
pushed technology in new and exciting directions, and bring
successive new genera-
tions to an understanding of the unique challenges and
opportunities of systems engi-
neering. In 1980, recognizing the need to improve the training
and education of technical
professionals, he started the master of science degree program
at Johns Hopkins
University in Technical Management and later expanded it to
Systems Engineering,
one of the fi rst programs of its kind.
Today, the systems engineering program he founded is the
largest part - time gradu-
ate program in the United States, with students enrolled from
around the world in
classroom, distance, and organizational partnership venues; it
continues to evolve as
the fi eld expands and teaching venues embrace new
technologies, setting the standard
for graduate programs in systems engineering. The fi rst edition
of the book is the foun-
dational systems engineering textbook for colleges and
universities worldwide.

PREFACE TO THE SECOND
EDITION
fpref01.indd xixfpref01.indd xix 2/8/2011 3:49:23
PM2/8/2011 3:49:23 PM
xx PREFACE TO THE SECOND EDITION
OBJECTIVES OF THE SECOND EDITION
Traditional engineering disciplines do not provide the training,
education, and experi-
ence necessary to ensure the successful development of a large,
complex system
program from inception to operational use. The advocacy of the
systems engineering
viewpoint and the goal for the practitioners to think like a
systems engineer are still
the major premises of this book.
This second edition of Systems Engineering Principles and
Practice continues to
be intended as a graduate - level textbook for courses
introducing the fi eld and practice
of systems engineering. We continue the tradition of utilizing
models to assist students
in grasping abstract concepts presented in the book. The fi ve
basic models of the fi rst
edition are retained, with only minor refi nements to refl ect
current thinking. Additionally,
the emphasis on application and practice is retained throughout
and focuses on students
pursuing their educational careers in parallel with their

professional careers. Detailed
mathematics and other technical fi elds are not explored in
depth, providing the greatest
range of students who may benefi t, nor are traditional
engineering disciplines provided
in detail, which would violate the book ’ s intended scope.
The updates and additions to the fi rst edition revolve around
the changes occurring
in the fi eld of systems engineering since the original
publication. Special attention was
made in the following areas :
• The Systems Engineer ’ s Career. An expanded
discussion is presented on
the career of the systems engineer. In recent years, systems
engineering
has been recognized by many companies and organizations as a
separate fi eld,
and the position of “ systems engineer ” has been formalized.
Therefore, we
present a model of the systems engineer ’ s career to help guide
prospective
professionals.
• The Systems Engineering Landscape. The only new
chapter introduced in the
second edition is titled by the same name and reinforces the
concept of the
systems engineering viewpoint. Expanded discussions of the
implications of this
viewpoint have been offered.
• System Boundaries. Supplemental material has been
introduced defi ning and
expanding our discussion on the concept of the system

boundary. Through the
use of the book in graduate - level education, the authors
recognized an inherent
misunderstanding of this concept — students in general have
been unable to rec-
ognize the boundary between the system and its environment.
This area has been
strengthened throughout the book.
• System Complexity. Signifi cant research in the area
of system complexity is now
available and has been addressed. Concepts such as system of
systems engineer-
ing, complex systems management, and enterprise systems
engineering are intro-
duced to the student as a hierarchy of complexity, of which
systems engineering
forms the foundation.
• Systems Architecting. Since the original publication,
the fi eld of systems archi-
tecting has expanded signifi cantly, and the tools, techniques,
and practices of this
fpref01.indd xxfpref01.indd xx 2/8/2011 3:49:23
PM2/8/2011 3:49:23 PM
PREFACE TO THE SECOND EDITION xxi
fi eld have been incorporated into the concept exploration and
defi nition chapters.
New models and frameworks for both traditional structured
analysis and object -
oriented analysis techniques are described and examples are

provided, including
an expanded description of the Unifi ed Modeling Language and
the Systems
Modeling Language. Finally, the extension of these new
methodologies, model -
based systems engineering, is introduced.
• Decision Making and Support. The chapter on systems
engineering decision
tools has been updated and expanded to introduce the systems
engineering
student to the variety of decisions required in this fi eld, and the
modern pro-
cesses, tools, and techniques that are available for use. The
chapter has also been
moved from the original special topics part of the book.
• Software Systems Engineering. The chapter on
software systems engineering has
been extensively revised to incorporate modern software
engineering techniques,
principles, and concepts. Descriptions of modern software
development life
cycle models, such as the agile development model, have been
expanded to
refl ect current practices. Moreover, the section on capability
maturity models has
been updated to refl ect the current integrated model. This
chapter has also been
moved out of the special topics part and introduced as a full
partner of advanced
development and engineering design.
In addition to the topics mentioned above, the chapter
summaries have been refor-
matted for easier understanding, and the lists of problems and

references have been
updated and expanded. Lastly, feedback, opinions, and
recommendations from graduate
students have been incorporated where the wording or
presentation was awkward or
unclear.
CONTENT DESCRIPTION
This book continues to be used to support the core courses of
the Johns Hopkins
University Master of Science in Systems Engineering program
and is now a primary
textbook used throughout the United States and in several other
countries. Many pro-
grams have transitioned to online or distance instruction; the
second edition was written
with distance teaching in mind, and offers additional examples.
The length of the book has grown, with the updates and new
material refl ecting
the expansion of the fi eld itself.
The second edition now has four parts:
• Part I . The Foundation of Systems Engineering,
consisting of Chapters 1 – 5 ,
describes the origins and structure of modern systems, the
current fi eld of systems
engineering, the structured development process of complex
systems, and the
organization of system development projects.
• Part II . Concept Development, consisting of Chapters
6 – 9 , describes the early
stages of the system life cycle in which a need for a new system

is demonstrated,
fpref01.indd xxifpref01.indd xxi 2/8/2011 3:49:23
PM2/8/2011 3:49:23 PM
xxii PREFACE TO THE SECOND EDITION
its requirements identifi ed, alternative implementations
developed, and key
program and technical decisions made.
• Part III . Engineering Development, consisting of
Chapters 10 – 13 , describes the
later stages of the system life cycle, in which the system
building blocks are
engineered (to include both software and hardware subsystems)
and the total
system is integrated and evaluated in an operational
environment.
• Part IV . Postdevelopment, consisting of Chapters 14
and 15 , describes the roles
of systems in the production, operation, and support phases of
the system life
cycle and what domain knowledge of these phases a systems
engineer should
acquire.
Each chapter contains a summary, homework problems, and
bibliography.
ACKNOWLEDGMENTS
The authors of the second edition gratefully acknowledge the

family of Dr. Kossiakoff
and Mr. William Sweet for their encouragement and support of
a second edition to the
original book. As with the fi rst edition, the authors gratefully
acknowledge the many
contributions made by the present and past faculties of the
Johns Hopkins University
Systems Engineering graduate program. Their sharp insight and
recommendations on
improvements to the fi rst edition have been invaluable in
framing this publication.
Particular thanks are due to E. A. Smyth for his insightful
review of the manuscript.
Finally, we are exceedingly grateful to our families — Judy
Seymour and Michele
and August Biemer — for their encouragement, patience, and
unfailing support, even
when they were continually asked to sacrifi ce, and the end
never seemed to be
within reach.
Much of the work in preparing this book was supported as part
of the educational
mission of the Johns Hopkins University Applied Physics
Laboratory.
Samuel J. Seymour
Steven M. Biemer
2010
fpref01.indd xxiifpref01.indd xxii 2/8/2011 3:49:23
PM2/8/2011 3:49:23 PM

xxiii
Learning how to be a successful systems engineer is entirely
different from learning
how to excel at a traditional engineering discipline. It requires
developing the ability
to think in a special way, to acquire the “ systems engineering
viewpoint, ” and to make
the central objective the system as a whole and the success of
its mission. The systems
engineer faces three directions: the system user ’ s needs and
concerns, the project man-
ager ’ s fi nancial and schedule constraints, and the capabilities
and ambitions of the
engineering specialists who have to develop and build the
elements of the system. This
requires learning enough of the language and basic principles of
each of the three
constituencies to understand their requirements and to negotiate
balanced solutions
acceptable to all. The role of interdisciplinary leadership is the
key contribution and
principal challenge of systems engineering and it is absolutely
indispensable to the
successful development of modern complex systems.
1.1 OBJECTIVES
Systems Engineering Principles and Practice is a textbook
designed to help students
learn to think like systems engineers. Students seeking to learn
systems engineering
after mastering a traditional engineering discipline often fi nd
the subject highly abstract

and ambiguous. To help make systems engineering more
tangible and easier to grasp,
the book provides several models: (1) a hierarchical model of
complex systems, showing
them to be composed of a set of commonly occurring building
blocks or components;
(2) a system life cycle model derived from existing models but
more explicitly related
to evolving engineering activities and participants; (3) a model
of the steps in the
systems engineering method and their iterative application to
each phase of the life
cycle; (4) a concept of “ materialization ” that represents the
stepwise evolution of an
abstract concept to an engineered, integrated, and validated
system; and (5) repeated
references to the specifi c responsibilities of systems engineers
as they evolve during
the system life cycle and to the scope of what a systems
engineer must know to perform
these effectively. The book ’ s signifi cantly different approach
is intended to complement
the several excellent existing textbooks that concentrate on the
quantitative and analyti-
cal aspects of systems engineering.
PREFACE TO THE FIRST EDITION
fpref02.indd xxiiifpref02.indd xxiii 2/8/2011 3:49:24
PM2/8/2011 3:49:24 PM
xxiv PREFACE TO THE FIRST EDITION
Particular attention is devoted to systems engineers as

professionals, their respon-
sibilities as part of a major system development project, and the
knowledge, skills, and
mind - set they must acquire to be successful. The book stresses
that they must be inno-
vative and resourceful, as well as systematic and disciplined. It
describes the special
functions and responsibilities of systems engineers in
comparison with those of system
analysts, design specialists, test engineers, project managers,
and other members of the
system development team. While the book describes the
necessary processes that
systems engineers must know and execute, it stresses the
leadership, problem - solving,
and innovative skills necessary for success.
The function of systems engineering as defi ned here is to “
guide the engineering
of complex systems. ” To learn how to be a good guide requires
years of practice and
the help and advice of a more experienced guide who knows “
the way. ” The purpose
of this book is to provide a signifi cant measure of such help
and advice through the
organized collective experience of the authors and other
contributors.
This book is intended for graduate engineers or scientists who
aspire to or are
already engaged in careers in systems engineering, project
management, or engineering
management. Its main audience is expected to be engineers
educated in a single disci-
pline, either hardware or software, who wish to broaden their
knowledge so as to deal

with systems problems. It is written with a minimum of
mathematics and specialized
jargon so that it should also be useful to managers of technical
projects or organizations,
as well as to senior undergraduates.
1.2 ORIGIN AND CONTENTS
The main portion of the book has been used for the past 5 years
to support the fi ve core
courses of the Johns Hopkins University Master of Science in
Systems Engineering
program and is thoroughly class tested. It has also been used
successfully as a text for
distance course offerings. In addition, the book is well suited to
support short courses
and in - house training.
The book consists of 14 chapters grouped into fi ve parts :
• Part I . The Foundations of Systems Engineering,
consisting of Chapters 1 – 4 ,
describes the origin and structure of modern systems, the
stepwise development
process of complex systems, and the organization of system
development
projects.
• Part II . Concept Development, consisting of Chapters
5 – 7 , describes the fi rst
stage of the system life cycle in which a need for a new system
is demonstrated,
its requirements are developed, and a specifi c preferred
implementation concept
is selected.

• Part III . Engineering Development, consisting of
Chapters 8 – 10 , describes the
second stage of the system life cycle, in which the system
building blocks are
engineered and the total system is integrated and evaluated in
an operational
environment.
fpref02.indd xxivfpref02.indd xxiv 2/8/2011 3:49:24
PM2/8/2011 3:49:24 PM
PREFACE TO THE FIRST EDITION xxv
• Part IV . Postdevelopment, consisting of Chapters 11
and 12 , describes the role
of systems engineering in the production, operation, and support
phases of the
system life cycle, and what domain knowledge of these phases
in the system life
cycle a systems engineer should acquire.
• Part V . Special Topics consists of Chapters 13 and
14 . Chapter 13 describes the
pervasive role of software throughout system development, and
Chapter 14
addresses the application of modeling, simulation, and trade -
off analysis as
systems engineering decision tools.
Each chapter also contains a summary, homework problems,
and a bibliography.
A glossary of important terms is also included. The chapter
summaries are formatted
to facilitate their use in lecture viewgraphs.

ACKNOWLEDGMENTS
The authors gratefully acknowledge the many contributions
made by the present and
past faculties of the Johns Hopkins University Systems
Engineering Masters program.
Particular thanks are due to S. M. Biemer, J. B. Chism, R. S.
Grossman, D. C. Mitchell,
J. W. Schneider, R. M. Schulmeyer, T. P. Sleight, G. D. Smith,
R. J. Thompson, and S.
P. Yanek, for their astute criticism of passages that may have
been dear to our hearts
but are in need of repairs.
An even larger debt is owed to Ben E. Amster, who was one of
the originators and
the initial faculty of the Johns Hopkins University Systems
Engineering program.
Though not directly involved in the original writing, he
enhanced the text and diagrams
by adding many of his own insights and fi ne - tuned the entire
text for meaning and
clarity, applying his 30 years ’ experience as a systems
engineer to great advantage.
We especially want to thank H. J. Gravagna for her outstanding
expertise and
inexhaustible patience in typing and editing the innumerable
rewrites of the drafts of
the manuscript. These were issued to successive classes of
systems engineering students
as the book evolved over the past 3 years. It was she who kept
the focus on the fi nal
product and provided invaluable assistance with the production
of this work.

Finally, we are eternally grateful to our wives, Arabelle and
Kathleen, for their
encouragement, patience, and unfailing support, especially
when the written words
came hard and the end seemed beyond our reach.
Much of the work in preparing this book was supported as part
of the educational
mission of the Johns Hopkins Applied Physics Laboratory.
William N. Sweet
2002
fpref02.indd xxvfpref02.indd xxv 2/8/2011 3:49:24
PM2/8/2011 3:49:24 PM
fpref02.indd xxvifpref02.indd xxvi 2/8/2011 3:49:24
PM2/8/2011 3:49:24 PM
1
Part I provides a multidimensional framework that
interrelates the basic principles of
systems engineering, and helps to organize the areas of
knowledge that are required to
master this subject. The dimensions of this framework include
1. a hierarchical model of the structure of complex systems;

2. a set of commonly occurring functional and physical
system building blocks;
3. a systems engineering life cycle, integrating the features
of the U.S Department
of Defense, ISO/IEC, IEEE, and NSPE models;
4. four basic steps of the systems engineering method that
are iterated during each
phase of the life cycle;
5. three capabilities differentiating project management,
design specialization, and
systems engineering;
6. three different technical orientations of a scientist, a
mathematician, and an
engineer and how they combine in the orientation of a systems
engineer; and
7. a concept of “ materialization ” that measures the
degree of transformation of a
system element from a requirement to a fully implemented part
of a real system.
PART I
FOUNDATIONS OF SYSTEMS
ENGINEERING
Systems Engineering Principles and Practice, Second Edition.
Alexander Kossiakoff, William N. Sweet,
Samuel J. Seymour, and Steven M. Biemer
© 2011 by John Wiley & Sons, Inc. Published 2011 by John

Wiley & Sons, Inc.
p01.indd 1p01.indd 1 2/9/2011 4:16:37 PM2/9/2011
4:16:37 PM
2 FOUNDATIONS OF SYSTEMS ENGINEERING
Chapter 1 describes the origins and characteristics of modern
complex systems and
systems engineering as a profession.
Chapter 2 defi nes the “ systems engineering viewpoint ” and
how it differs from the
viewpoints of technical specialists and project managers. This
concept of a systems
viewpoint is expanded to describe the domain, fi elds, and
approaches of the systems
engineering discipline.
Chapter 3 develops the hierarchical model of a complex
system and the key build-
ing blocks from which it is constituted. This framework is used
to defi ne the breadth
and depth of the knowledge domain of systems engineers in
terms of the system
hierarchy.
Chapter 4 derives the concept of the systems engineering life
cycle, which sets the
framework for the evolution of a complex system from a
perceived need to operation
and disposal. This framework is systematically applied
throughout Parts II – IV of the
book, each part addressing the key responsibilities of systems

engineering in the cor-
responding phase of the life cycle.
Finally, Chapter 5 describes the key parts that systems
engineering plays in the
management of system development projects. It defi nes the
basic organization and
the planning documents of a system development project, with a
major emphasis on
the management of program risks.
p01.indd 2p01.indd 2 2/9/2011 4:16:37 PM2/9/2011
4:16:37 PM
3
1.1 WHAT IS SYSTEMS ENGINEERING?
There are many ways in which to defi ne systems engineering.
For the purposes of this
book, we will use the following defi nition:
The function of systems engineering is to guide the
engineering of complex systems .
The words in this defi nition are used in their conventional
meanings, as described
further below.
To guide is defi ned as “ to lead, manage, or direct, usually
based on the superior
experience in pursuing a given course ” and “ to show the way.
” This characterization

emphasizes the process of selecting the path for others to follow
from among many
possible courses — a primary function of systems engineering.
A dictionary defi nition
of engineering is “ the application of scientifi c principles to
practical ends; as the design,
construction and operation of effi cient and economical
structures, equipment, and
systems. ” In this defi nition, the terms “ effi cient ” and “
economical ” are particular con-
tributions of good systems engineering.
The word “ system, ” as is the case with most common
English words, has a
very broad meaning. A frequently used defi nition of a system is
“ a set of interrelated
1
SYSTEMS ENGINEERING
AND THE WORLD OF
MODERN SYSTEMS
Wiley & Sons, Inc.
c01.indd 3c01.indd 3 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
4 SYSTEMS ENGINEERING AND THE WORLD OF MODERN
SYSTEMS

components working together toward some common
objective. ” This defi nition implies
a multiplicity of interacting parts that collectively perform a
signifi cant function. The
term complex restricts this defi nition to systems in which the
elements are diverse and
have intricate relationships with one another. Thus, a home
appliance such as a washing
machine would not be considered suffi ciently diverse and
complex to require systems
engineering, even though it may have some modern automated
attachments. On the
other hand, the context of an engineered system excludes such
complex systems as
living organisms and ecosystems. The restriction of the term “
system ” to one that is
complex and engineered makes it more clearly applicable to the
function of systems
engineering as it is commonly understood. Examples of systems
requiring systems
engineering for their development are listed in a subsequent
section.
The above defi nitions of “ systems engineering ” and “
system ” are not represented
as being unique or superior to those used in other textbooks,
each of which defi nes
them somewhat differently. In order to avoid any potential
misunderstanding, the
meaning of these terms as used in this book is defi ned at the
very outset, before going
on to the more important subjects of the responsibilities,
problems, activities, and tools
of systems engineering.

Systems Engineering and Traditional Engineering Disciplines
From the above defi nition, it can be seen that systems
engineering differs from mechani-
cal, electrical, and other engineering disciplines in several
important ways:
1. Systems engineering is focused on the system as a whole;
it emphasizes its total
operation. It looks at the system from the outside, that is, at its
interactions with
other systems and the environment, as well as from the inside. It
is concerned
not only with the engineering design of the system but also with
external factors,
which can signifi cantly constrain the design. These include the
identifi cation of
customer needs, the system operational environment, interfacing
systems, logis-
tics support requirements, the capabilities of operating
personnel, and such other
factors as must be correctly refl ected in system requirements
documents and
accommodated in the system design.
2. While the primary purpose of systems engineering is to
guide, this does not
mean that systems engineers do not themselves play a key role
in system design.
On the contrary, they are responsible for leading the formative
(concept devel-
opment) stage of a new system development, which culminates
in the functional
design of the system refl ecting the needs of the user. Important
design decisions
at this stage cannot be based entirely on quantitative

knowledge, as they are for
the traditional engineering disciplines, but rather must often
rely on qualitative
judgments balancing a variety of incommensurate quantities and
utilizing expe-
rience in a variety of disciplines, especially when dealing with
new
technology.
3. Systems engineering bridges the traditional engineering
disciplines. The diver-
sity of the elements in a complex system requires different
engineering disci-
c01.indd 4c01.indd 4 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
ORIGINS OF SYSTEMS ENGINEERING 5
plines to be involved in their design and development. For the
system to perform
correctly, each system element must function properly in
combination with one
or more other system elements. Implementation of these
interrelated functions
is dependent on a complex set of physical and functional
interactions between
separately designed elements. Thus, the various elements cannot
be engineered
independently of one another and then simply assembled to
produce a working
system. Rather, systems engineers must guide and coordinate
the design of each
individual element as necessary to assure that the interactions

and interfaces
between system elements are compatible and mutually
supporting. Such coor-
dination is especially important when individual system
elements are designed,
tested, and supplied by different organizations.
Systems Engineering and Project Management
The engineering of a new complex system usually begins with
an exploratory stage in
which a new system concept is evolved to meet a recognized
need or to exploit a tech-
nological opportunity. When the decision is made to engineer
the new concept into an
operational system, the resulting effort is inherently a major
enterprise, which typically
requires many people, with diverse skills, to devote years of
effort to bring the system
from concept to operational use.
The magnitude and complexity of the effort to engineer a new
system requires
a dedicated team to lead and coordinate its execution. Such an
enterprise is called
a “ project ” and is directed by a project manager aided by a
staff. Systems engineering
is an inherent part of project management — the part that is
concerned with guiding
the engineering effort itself — setting its objectives, guiding its
execution, evaluating
its results, and prescribing necessary corrective actions to keep
it on course. The man-
agement of the planning and control aspects of the project fi
scal, contractual, and
customer relations is supported by systems engineering but is

usually not considered
to be part of the systems engineering function. This subject is
described in more detail
in Chapter 5 .
Recognition of the importance of systems engineering by every
participant in a
system development project is essential for its effective
implementation. To accomplish
this, it is often useful to formally assign the leader of the
systems engineering team to
a recognized position of technical responsibility and authority
within the project.
1.2 ORIGINS OF SYSTEMS ENGINEERING
No particular date can be associated with the origins of systems
engineering. Systems
engineering principles have been practiced at some level since
the building of the pyra-
mids and probably before. (The Bible records that Noah ’ s Ark
was built to a system
specifi cation.)
The recognition of systems engineering as a distinct activity is
often associated
with the effects of World War II, and especially the 1950s and
1960s when a number
of textbooks were published that fi rst identifi ed systems
engineering as a distinct
c01.indd 5c01.indd 5 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM

SYSTEMS
discipline and defi ned its place in the engineering of systems.
More generally, the
recognition of systems engineering as a unique activity evolved
as a necessary corollary
to the rapid growth of technology, and its application to major
military and commercial
operations during the second half of the twentieth century.
The global confl agration of World War II provided a
tremendous spur to the
advancement of technology in order to gain a military advantage
for one side or the
other. The development of high - performance aircraft, military
radar, the proximity fuse,
the German VI and V2 missiles, and especially the atomic bomb
required revolutionary
advances in the application of energy, materials, and
information. These systems were
complex, combining multiple technical disciplines, and their
development posed engi-
neering challenges signifi cantly beyond those that had been
presented by their more
conventional predecessors. Moreover, the compressed
development time schedules
imposed by wartime imperatives necessitated a level of
organization and effi ciency that
required new approaches in program planning, technical
coordination, and engineering
management. Systems engineering, as we know it today,
developed to meet these
challenges.
During the Cold War of the 1950s, 1960s, and 1970s, military

requirements con-
tinued to drive the growth of technology in jet propulsion,
control systems, and materi-
als. However, another development, that of solid - state
electronics, has had perhaps a
more profound effect on technological growth. This, to a large
extent, made possible
the still evolving “ information age, ” in which computing,
networks, and communica-
tions are extending the power and reach of systems far beyond
their previous limits.
Particularly signifi cant in this connection is the development of
the digital computer
and the associated software technology driving it, which
increasingly is leading to the
replacement of human control of systems by automation.
Computer control is qualita-
tively increasing the complexity of systems and is a particularly
important concern of
systems engineering.
The relation of modern systems engineering to its origins can
be best understood
in terms of three basic factors:
1. Advancing Technology, which provide opportunities
for increasing system
capabilities, but introduces development risks that require
systems engineering
management; nowhere is this more evident than in the world of
automation.
Technology advances in human – system interfaces, robotics,
and software make
this particular area one of the fastest growing technologies
affecting system
design.

2. Competition, whose various forms require seeking
superior (and more
advanced) system solutions through the use of system - level
trade - offs among
alternative approaches.
3. Specialization, which requires the partitioning of the
system into building
blocks corresponding to specifi c product types that can be
designed and built
by specialists, and strict management of their interfaces and
interactions.
These factors are discussed in the following paragraphs.
c01.indd 6c01.indd 6 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
Advancing Technology: Risks
The explosive growth of technology in the latter half of the
twentieth century and
into this century has been the single largest factor in the
emergence of systems engi-
neering as an essential ingredient in the engineering of complex
systems. Advancing
technology has not only greatly extended the capabilities of
earlier systems, such as
aircraft, telecommunications, and power plants, but has also
created entirely new
systems such as those based on jet propulsion, satellite

communications and navigation,
and a host of computer - based systems for manufacturing, fi
nance, transportation,
entertainment, health care, and other products and services.
Advances in technology
have not only affected the nature of products but have also
fundamentally changed
the way they are engineered, produced, and operated. These are
particularly important
in early phases of system development, as described in
Conceptual Exploration, in
Chapter 7 .
Modern technology has had a profound effect on the very
approach to engineering.
Traditionally, engineering applies known principles to practical
ends. Innovation,
however, produces new materials, devices, and processes,
whose characteristics are not
yet fully measured or understood. The application of these to
the engineering of new
systems thus increases the risk of encountering unexpected
properties and effects that
might impact system performance and might require costly
changes and program
delays.
However, failure to apply the latest technology to system
development also carries
risks. These are the risks of producing an inferior system, one
that could become pre-
maturely obsolete. If a competitor succeeds in overcoming such
problems as may be
encountered in using advanced technology, the competing
approach is likely to be
superior. The successful entrepreneurial organization will thus

assume carefully selected
technological risks and surmount them by skillful design,
systems engineering, and
program management.
The systems engineering approach to the early application of
new technology is
embodied in the practice of “ risk management. ” Risk
management is a process of
dealing with calculated risks through a process of analysis,
development, test, and
engineering oversight. It is described more fully in Chapters 5
and 9 .
Dealing with risks is one of the essential tasks of systems
engineering, requiring
a broad knowledge of the total system and its critical elements.
In particular, systems
engineering is central to the decision of how to achieve the best
balance of risks, that
is, which system elements should best take advantage of new
technology and which
should be based on proven components, and how the risks
incurred should be reduced
by development and testing.
The development of the digital computer and software
technology noted earlier
deserves special mention. This development has led to an
enormous increase in the
automation of a wide array of control functions for use in
factories, offi ces, hospitals,
and throughout society. Automation, most of it being concerned
with information pro-
cessing hardware and software, and its sister technology,
autonomy, which adds in

capability of command and control, is the fastest growing and
most powerful single
infl uence on the engineering of modern systems.
c01.indd 7c01.indd 7 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
SYSTEMS
The increase in automation has had an enormous impact on
people who operate
systems, decreasing their number but often requiring higher
skills and therefore special
training. Human – machine interfaces and other people – system
interactions are particu-
lar concerns of systems engineering.
Software continues to be a growing engineering medium whose
power and versatil-
ity has resulted in its use in preference to hardware for the
implementation of a growing
fraction of system functions. Thus, the performance of modern
systems increasingly
depends on the proper design and maintenance of software
components. As a result,
more and more of the systems engineering effort has had to be
directed to the control
of software design and its application.
Competition: Trade - offs
Competitive pressures on the system development process
occur at several different

levels. In the case of defense systems, a primary drive comes
from the increasing mili-
tary capabilities of potential adversaries, which correspondingly
decrease the effective-
ness of systems designed to defeat them. Such pressures
eventually force a development
program to redress the military balance with a new and more
capable system or a major
upgrade of an existing one.
Another source of competition comes with the use of
competitive contracting for
the development of new system capabilities. Throughout the
competitive period, which
may last through the initial engineering of a new system, each
contractor seeks to devise
the most cost - effective program to provide a superior product.
In developing a commercial product, there are nearly always
other companies that
compete in the same market. In this case, the objective is to
develop a new market or
to obtain an increased market share by producing a superior
product ahead of the com-
petition, with an edge that will maintain a lead for a number of
years. The above
approaches nearly always apply the most recent technology in
an effort to gain a com-
petitive advantage.
Securing the large sums of money needed to fund the
development of a new
complex system also involves competition on quite a different
level. In particular, both
government agencies and industrial companies have many more
calls on their resources

than they can accommodate and hence must carefully weigh the
relative payoff of
proposed programs. This is a primary reason for requiring a
phased approach in new
system development efforts, through the requirement for justifi
cation and formal
approval to proceed with the increasingly expensive later
phases. The results of each
phase of a major development must convince decision makers
that the end objectives
are highly likely to be attained within the projected cost and
schedule.
On a still different basis, the competition among the essential
characteristics of
the system is always a major consideration in its development.
For example, there is
always competition between performance, cost, and schedule,
and it is impossible to
optimize all three at once. Many programs have failed by
striving to achieve levels
of performance that proved unaffordable. Similarly, the various
performance parame-
ters of a vehicle, such as speed and range, are not independent
of one another; the
effi ciency of most vehicles, and hence their operating range,
decreases at higher speeds.
c01.indd 8c01.indd 8 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
Thus, it is necessary to examine alternatives in which these

characteristics are allowed
to vary and to select the combination that best balances their
values for the benefi t of
the user.
All of the forms of competition exert pressure on the system
development process
to produce the best performing, most affordable system, in the
least possible time. The
process of selecting the most desirable approach requires the
examination of numerous
potential alternatives and the exercise of a breadth of technical
knowledge and judgment
that only experienced systems engineers possess. This is often
referred to as “ trade - off
analysis ” and forms one of the basic practices of systems
engineering.
Specialization: Interfaces
A complex system that performs a number of different
functions must of necessity be
confi gured in such a way that each major function is embodied
in a separate component
capable of being specifi ed, developed, built, and tested as an
individual entity. Such a
subdivision takes advantage of the expertise of organizations
specializing in particular
types of products, and hence is capable of engineering and
producing components of
the highest quality at the lowest cost. Chapter 3 describes the
kind of functional and
physical building blocks that make up most modern systems.
The immensity and diversity of engineering knowledge, which
is still growing, has

made it necessary to divide the education and practice of
engineering into a number of
specialties, such as mechanical, electrical, aeronautical, and so
on. To acquire the neces-
sary depth of knowledge in any one of these fi elds, further
specialization is needed,
into such subfi elds as robotics, digital design, and fl uid
dynamics. Thus, engineering
specialization is a predominant condition in the fi eld of
engineering and manufacturing
and must be recognized as a basic condition in the system
development process.
Each engineering specialty has developed a set of specialized
tools and facilities
to aid in the design and manufacture of its associated products.
Large and small com-
panies have organized around one or several engineering groups
to develop and manu-
facture devices to meet the needs of the commercial market or
of the system - oriented
industry. The development of interchangeable parts and
automated assembly has been
one of the triumphs of the U.S. industry.
The convenience of subdividing complex systems into
individual building blocks
has a price: that of integrating these disparate parts into an effi
cient, smoothly operating
system. Integration means that each building block fi ts
perfectly with its neighbors and
with the external environment with which it comes into contact.
The “ fi t ” must be not
only physical but also functional; that is, its design will both
affect the design charac-
teristics and behavior of other elements, and will be affected by

them, to produce the
exact response that the overall system is required to make to
inputs from its environ-
ment. The physical fi t is accomplished at intercomponent
boundaries called interfaces .
The functional relationships are called interactions .
The task of analyzing, specifying, and validating the
component interfaces with
each other and with the external environment is beyond the
expertise of the individual
design specialists and is the province of the systems engineer.
Chapter 3 discusses
further the importance and nature of this responsibility.
c01.indd 9c01.indd 9 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
MODERN SYSTEMS
A direct consequence of the subdivision of systems into their
building blocks is
the concept of modularity. Modularity is a measure of the
degree of mutual indepen-
dence of the individual system components. An essential goal of
systems engineering
is to achieve a high degree of modularity to make interfaces and
interactions as simple
as possible for effi cient manufacture, system integration, test,
operational maintenance,
reliability, and ease of in - service upgrading. The process of
subdividing a system into
modular building blocks is called “ functional allocation ” and

is another basic tool of
1.3 EXAMPLES OF SYSTEMS REQUIRING SYSTEMS
ENGINEERING
As noted at the beginning of this chapter, the generic defi
nition of a system as a set of
interrelated components working together as an integrated
whole to achieve some
common objective would fi t most familiar home appliances. A
washing machine con-
sists of a main clothes tub, an electric motor, an agitator, a
pump, a timer, an inner
spinning tub, and various valves, sensors, and controls. It
performs a sequence of timed
operations and auxiliary functions based on a schedule and
operation mode set by the
operator. A refrigerator, microwave oven, dishwasher, vacuum
cleaner, and radio all
perform a number of useful operations in a systematic manner.
However, these appli-
ances involve only one or two engineering disciplines, and their
design is based on
well - established technology. Thus, they fail the criterion of
being complex , and we
would not consider the development of a new washer or
refrigerator to involve much
systems engineering as we understand the term, although it
would certainly require a
high order of reliability and cost engineering. Of course, home
appliances increasingly
include clever automatic devices that use newly available
microchips, but these are
usually self - contained add - ons and are not necessary to the
main function of the

appliance.
Since the development of new modern systems is strongly
driven by technological
change, we shall add one more characteristic to a system
requiring systems engineering,
namely, that some of its key elements use advanced technology.
The characteristics of
a system whose development, test, and application require the
practice of systems
engineering are that the system
• is an engineered product and hence satisfi es a specifi ed
need,
• consists of diverse components that have intricate
relationships with one another
and hence is multidisciplinary and relatively complex, and
• uses advanced technology in ways that are central to the
performance of its
primary functions and hence involves development risk and
often a relatively
high cost.
Henceforth, references in this text to an engineered or
complex system (or in the
proper context, just system ) will mean the type that has the
three attributes noted above,
that is, is an engineered product, contains diverse components,
and uses advanced
technology. These attributes are, of course, in addition to the
generic defi nition stated
c01.indd 10c01.indd 10 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM

EXAMPLES OF SYSTEMS REQUIRING SYSTEMS
ENGINEERING 11
earlier and serve to identify the systems of concern to the
systems engineer as those
that require system design, development, integration, test, and
evaluation. In Chapter
2 , we explore the full spectrum of systems complexity and why
the systems engineering
landscape presents a challenge for systems engineers.
Examples of Complex Engineered Systems
To illustrate the types of systems that fi t within the above defi
nition, Tables 1.1 and 1.2
list 10 modern systems and their principal inputs, processes, and
outputs.
TA B L E 1.1. Examples of Engineered Complex Systems:
Signal and Data Systems
System Inputs Process Outputs
Weather satellite Images • Data storage
• Transmission
Encoded images
Terminal air traffi c
control system
Aircraft beacon
responses

• Identifi cation
• Tracking
• Identity
• Air tracks
• Communications
Track location system Cargo routing
requests
• Map tracing
• Communication
• Routing information
• Delivered cargo
Airline reservation
system
Travel requests Data management • Reservations
• Tickets
Clinical information
system
• Patient ID
• Test records
• Diagnosis
Information
management
• Patient status
• History
• Treatment

TA B L E 1.2. Examples of Engineered Complex Systems:
Material and Energy Systems
System Inputs Process Outputs
Passenger aircraft • Passengers
• Fuel
• Combustion
• Thrust
• Lift
Transported
passengers
Modern harvester
combine
• Grain fi eld
• Fuel
• Cutting
• Threshing
Harvested grain
Oil refi nery • Crude oil
• Catalysts
• Energy
• Cracking
• Separation
• Blending
• Gasoline

• Oil products
• Chemicals
Auto assembly plant • Auto parts
• Energy
• Manipulation
• Joining
• Finishing
Assembled auto
Electric power plant • Fuel
• Air
• Power generation
• Regulation
• Electric AC power
• Waste products
c01.indd 11c01.indd 11 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
MODERN SYSTEMS
It has been noted that a system consists of a multiplicity of
elements, some of
which may well themselves be complex and deserve to be
considered a system in their
own right. For example, a telephone - switching substation can
well be considered as a
system, with the telephone network considered as a “ system of

systems. ” Such issues
will be discussed more fully in Chapters 2 and 4 , to the
extent necessary for the under-
standing of systems engineering.
Example: A Modern Automobile. A more simple and
familiar system, which
still meets the criteria for an engineered system, is a fully
equipped passenger automo-
bile. It can be considered as a lower limit to more complex
vehicular systems. It is
made up of a large number of diverse components requiring the
combination of several
different disciplines. To operate properly, the components must
work together accu-
rately and effi ciently. Whereas the operating principles of
automobiles are well estab-
lished, modern autos must be designed to operate effi ciently
while at the same time
maintaining very close control of engine emissions, which
requires sophisticated
sensors and computer - controlled mechanisms for injecting fuel
and air. Antilock brakes
are another example of a fi nely tuned automatic automobile
subsystem. Advanced
materials and computer technology are used to an increasing
degree in passenger pro-
tection, cruise control, automated navigation and autonomous
driving and parking. The
stringent requirements on cost, reliability, performance,
comfort, safety, and a dozen
other parameters present a number of substantive systems
engineering problems.
Accordingly, an automobile meets the defi nition established
earlier for a system requir-
ing the application of systems engineering, and hence can serve

as a useful example.
An automobile is also an example of a large class of systems
that require active
interaction (control) by a human operator. To some degree, all
systems require such
interaction, but in this case, continuous control is required. In a
very real sense, the
operator (driver) functions as an integral part of the overall
automobile system, serving
as the steering feedback element that detects and corrects
deviations of the car ’ s path
on the road. The design must therefore address as a critical
constraint the inherent
sensing and reaction capabilities of the operator, in addition to
a range of associated
human – machine interfaces such as the design and placement of
controls and displays,
seat position, and so on. Also, while the passengers may not
function as integral ele-
ments of the auto steering system, their associated interfaces
(e.g., weight, seating and
viewing comfort, and safety) must be carefully addressed as
part of the design process.
Nevertheless, since automobiles are developed and delivered
without the human
element, for purposes of systems engineering, they may be
addressed as systems in
their own right.
1.4 SYSTEMS ENGINEERING AS A PROFESSION
With the increasing prevalence of complex systems in modern
society, and the essential
role of systems engineering in the development of systems,
systems engineering as a

profession has become widely recognized. Its primary
recognition has come in compa-
nies specializing in the development of large systems. A number
of these have estab-
c01.indd 12c01.indd 12 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
SYSTEMS ENGINEERING AS A PROFESSION 13
lished departments of systems engineering and have classifi ed
those engaging in the
process as systems engineers. In addition, global challenges in
health care, communica-
tions, environment, and many other complex areas require
engineering systems methods
to develop viable solutions.
To date, the slowness of recognition of systems engineering as
a career is the fact
that it does not correspond to the traditional academic
engineering disciplines.
Engineering disciplines are built on quantitative relationships,
obeying established
physical laws, and measured properties of materials, energy, or
information. Systems
engineering, on the other hand, deals mainly with problems for
which there is incom-
plete knowledge, whose variables do not obey known equations,
and where a balance
must be made among confl icting objectives involving
incommensurate attributes. The
absence of a quantitative knowledge base previously inhibited
the establishment of

systems engineering as a unique discipline.
Despite those obstacles, the recognized need for systems
engineering in industry
and government has spurred the establishment of a number of
academic programs
offering master ’ s degrees and doctoral degrees in systems
engineering. An increasing
number of universities are offering undergraduate degrees in
systems engineering as
well.
The recognition of systems engineering as a profession has led
to the formation of
a professional society, the International Council on Systems
Engineering (INCOSE),
one of whose primary objectives is the promotion of systems
engineering, and the
recognition of systems engineering as a professional career.
Career Choices
Systems engineers are highly sought after because their skills
complement those in
other fi elds and often serve as the “ glue ” to bring new ideas
to fruition. However, career
choices and the related educational needs for those choices is
complex, especially when
the role and responsibilities of a systems engineer is poorly
understood.
Four potential career directions are shown in Figure 1.1 : fi
nancial, management,
technical, and systems engineering. There are varying degrees
of overlap between them
despite the symmetry shown in the fi gure. The systems

engineer focuses on the whole
system product, leading and working with many diverse
technical team members, fol-
lowing the systems engineering development cycle, conducting
studies of alternatives,
and managing the system interfaces. The systems engineer
generally matures in the
fi eld after a technical undergraduate degree with work
experience and a master of
science degree in systems engineering, with an increasing
responsibility of successively
larger projects, eventually serving as the chief or lead systems
engineer for a major
systems, or systems - of - systems development. Note the
overlap and need to understand
the content and roles of the technical specialists and to
coordinate with the program
manager (PM).
The project manager or PM, often with a technical or business
background, is
responsible for interfacing with the customer and for defi ning
the work, developing
the plans, monitoring and controlling the project progress, and
delivering the fi nished
output to the customer. The PM often learns from on the job
training (OJT) with
c01.indd 13c01.indd 13 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
MODERN SYSTEMS

projects of increasing size and importance, enhancing the
toolset available with a master
of science degree in technical/program management. While not
exclusively true,
the chief executive offi cer (CEO) frequently originates from
the ranks of the organiza-
tion ’ s PMs.
The fi nancial or business career path that ultimately could lead
to a chief
fi nancial offi cer (CFO) position usually includes business
undergraduate and master of
business administration (MBA) degrees. Individuals progress
through their careers with
various horizontal and vertical moves, often with specialization
in the fi eld. There is
an overlap in skill and knowledge with the PM in areas of
contract and fi nance
management.
Many early careers start with a technical undergraduate degree
in engineering,
science or information technology. The technical specialist
makes contributions as part
of a team in the area of their primary knowledge, honing skills
and experience to
develop and test individual components or algorithms that are
part of a larger system.
Contributions are made project to project over time, and
recognition is gained from
innovative, timely, and quality workmanship. Technical
specialists need to continue to
learn about their fi eld and to stay current in order to be
employable compared to the
next generation of college graduates. Often advanced degrees
(MS and PhDs) are

acquired to enhance knowledge, capability, and recognition, and
job responsibilities
can lead to positions such as lead engineer, lead scientist, or
chief technology offi cer
(CTO) in an organization. The broader minded or experienced
specialist often considers
a career in systems engineering.
Figure 1.1. Career opportunities and growth.
CFO
CFO
MBA
BSOne must keep fresh in the Developing fiscal skills and tools
CTO
BS MS OJT
Financial
technical field to avoid obsolescence through horizontal and
lateral transitions
Program
manager
Systems
Technical
management
Technical
specialty

Interfacing with the customer
PhD MS BS Focus on
BS
MS
engineering
and managing WBS, budgets
and schedules
Increasing technical specialty whole systems
product
OJT Increasing
technical and
program
responsibility
Chief or lead systems engineer
Leading multidisciplinary teams
and developing diverse products
Copyright 2008 S.J. Seymour
c01.indd 14c01.indd 14 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM

Orientation of Technical Professionals
The special relationship of systems engineers with respect to
technical disciplines can
be better understood when it is realized that technical people
not only engage in widely
different professional specialties, but their intellectual
objectives, interests, and atti-
tudes, which represent their technical orientations, can also be
widely divergent. The
typical scientist is dedicated to understanding the nature and
behavior of the physical
world. The scientist asks the questions “ Why? ” and “ How?
” The mathematician is
usually primarily concerned with deriving the logical
consequences of a set of assump-
tions, which may be quite unrelated to the real world. The
mathematician develops the
proposition “ If A, then B. ” Usually, the engineer is mainly
concerned with creating a
useful product. The engineer exclaims “ Voila! ”
These orientations are quite different from one another, which
accounts for why
technical specialists are focused on their own aspects of science
and technology.
However, in most professionals, those orientations are not
absolute; in many cases, the
scientist may need some engineering to construct an apparatus,
and the engineer may
need some mathematics to solve a control problem. So, in the
general case, the orienta-
tion of a technical professional might be modeled by a sum of
three orthogonal vectors,
each representing the extent of the individual ’ s orientation

being in science, mathemat-
ics, or engineering.
To represent the above model, it is convenient to use a diagram
designed to show
the composition of a mixture of three components. Figure 1.2 a
is such a diagram in
which the components are science, mathematics, and
engineering. A point at each vertex
represents a mixture with 100% of the corresponding
component. The composition of
the mixture marked by the small triangle in the fi gure is
obtained by fi nding the per-
centage of each component by projecting a line parallel to the
baseline opposite each
vertex to the scale radiating from the vertex. This process gives
intercepts of 70%
science, 20% mathematics, and 10% engineering for the
orientation marked by the
triangle.
Because the curricula of technical disciplines tend to be
concentrated in specialized
subjects, most students graduate with limited general
knowledge. In Figure 1.2 b, the
circles representing the orientation of individual graduates are
seen to be concentrated
in the corners, refl ecting their high degree of specialization.
The tendency of professional people to polarize into diverse
specialties and inter-
ests tends to be accentuated after graduation, as they seek to
become recognized in their
respective fi elds. Most technical people resist becoming
generalists for fear they will
lose or fail to achieve positions of professional leadership and

the accompanying rec-
ognition. This specialization of professionals inhibits technical
communication between
them; the language barrier is bad enough, but the differences in
basic objectives and
methods of thought are even more serious. The solution of
complex interdisciplinary
problems has had to depend on the relatively rare individuals
who, for one reason or
another, after establishing themselves in their principal
profession, have become inter-
ested and involved in solving system problems and have learned
to work jointly with
specialists in various other fi elds.
c01.indd 15c01.indd 15 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
MODERN SYSTEMS
Figure 1.2. (a) Technical orientation phase diagram. (b)
Technical orientation population
density distribution.
(a)
(b)
c01.indd 16c01.indd 16 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM

The occasional evolution of technical specialists into systems
engineers is symbol-
ized in Figure 1.2 b by the arrows directed from the vertices
toward the center. The
small black triangle corresponds to such an evolved individual
whose orientation is
30% science, 50% engineering, and 20% mathematics, a balance
that would be effective
in the type of problem solving with which a systems engineer is
typically involved. It
is the few individuals who evolve into systems engineers or
system architects who
become the technical leaders of system development programs.
The Challenge of Systems Engineering
An inhibiting factor in becoming a professional systems
engineer is that it represents
a deviation from a chosen established discipline to a more
diverse, complicated profes-
sional practice. It requires the investment of time and effort to
gain experience and an
extensive broadening of the engineering base, as well as
learning communication and
management skills, a much different orientation from the
individual ’ s original profes-
sional choice.
For the above reasons, an engineer considering a career in
systems engineering
may come to the conclusion that the road is diffi cult. It is clear
that a great deal must
be learned; that the educational experience in a traditional
engineering discipline is

necessary; and that there are few tools and few quantitative
relationships to help make
decisions. Instead, the issues are ambiguous and abstract,
defying defi nitive solutions.
There may appear to be little opportunity for individual
accomplishment and even less
for individual recognition. For a systems engineer, success is
measured by the accom-
plishment of the development team, not necessarily the system
team leader.
What Then Is the Attraction of Systems Engineering?
The answer may lie in the challenges of systems engineering
rather than its direct
rewards. Systems engineers deal with the most important issues
in the system develop-
ment process. They design the overall system architecture and
the technical approach
and lead others in designing the components. They prioritize the
system requirements
in conjunction with the customer to ensure that the different
system attributes are
appropriately weighted when balancing the various technical
efforts. They decide which
risks are worth undertaking and which are not, and how the
former should be hedged
to ensure program success.
It is the systems engineers who map out the course of the
development program
that prescribes the type and timing of tests and simulations to
be performed along the
way. They are the ultimate authorities on how the system
performance and system
affordability goals may be achieved at the same time.

When unanticipated problems arise in the development
program, as they always
do, it is the systems engineers who decide how they may be
solved. They determine
whether an entirely new approach to the problem is necessary,
whether more intense
effort will accomplish the purpose, whether an entirely different
part of the system can
c01.indd 17c01.indd 17 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
MODERN SYSTEMS
be modifi ed to compensate for the problem, or whether the
requirement at issue can
best be scaled back to relieve the problem.
Systems engineers derive their ability to guide the system
development not from
their position in the organization but from their superior
knowledge of the system as a
whole, its operational objectives, how all its parts work
together, and all the technical
factors that go into its development, as well as from their
proven experience in steering
complex programs through a maze of diffi culties to a
successful conclusion.
Attributes and Motivations of Systems Engineers
In order to identify candidates for systems engineering careers,

it is useful to examine
the characteristics that may be useful to distinguish people with
a talent for systems
engineering from those who are not likely to be interested or
successful in that disci-
pline. Those likely to become talented systems engineers would
be expected to have
done well in mathematics and science in college.
A systems engineer will be required to work in a
multidisciplinary environment
and to grasp the essentials of related disciplines. It is here that
an aptitude for science
and engineering helps a great deal because it makes it much
easier and less threatening
for individuals to learn the essentials of new disciplines. It is
not so much that they
require in depth knowledge of higher mathematics, but rather,
those who have a limited
mathematical background tend to lack confi dence in their
ability to grasp subjects that
inherently contain mathematical concepts.
A systems engineer should have a creative bent and must like
to solve practical
problems. An interest in the job should be greater than an
interest in career advance-
ment. Systems engineering is more of a challenge than a quick
way to the top.
The following characteristics are commonly found in successful
systems engineers.
They
1. enjoy learning new things and solving problems,

2. like challenges,
3. are skeptical of unproven assertions,
4. are open - minded to new ideas,
5. have a solid background in science and engineering,
6. have demonstrated technical achievement in a specialty
area,
7. are knowledgeable in several engineering areas,
8. pick up new ideas and information quickly, and
9. have good interpersonal and communication skills.
1.5 SYSTEMS ENGINEER CAREER DEVELOPMENT
MODEL
When one has the characteristics noted above and is attracted
to become a systems
engineer, there are four more elements that need to be present in
the work environment.
As shown in Figure 1.3 a, one should seek assignments to
problems and tasks that are
c01.indd 18c01.indd 18 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
SYSTEMS ENGINEER CAREER DEVELOPMENT MODEL 19
very challenging and are likely to expand technical domain
knowledge and creative

juices. Whatever the work assignment, understanding the
context of the work and
understanding the big picture is also essential. Systems
engineers are expected to
manage many activities at the same time, being able to have
broad perspectives but
able to delve deeply into to many subjects at once. This ability
to multiplex is one that
takes time to develop. Finally, the systems engineer should not
be intimidated by
complex problems since this is the expected work environment.
It is clear these ele-
ments are not part of an educational program and must be
gained through extended
professional work experience. This becomes the foundation for
the systems engineering
career growth model.
Employers seeking to develop systems engineers to
competitively address more
challenging problems should provide key staff with relevant
systems engineering
work experience, activities that require mature systems
thinking, and opportunities
for systems engineering education and training. In Figure 1.3 b,
it can be seen that
the experience can be achieved not only with challenging
problems but also with
Figure 1.3. (a) Systems engineering (SE) career elements
derived from quality work experi-
ences. (b) Components of employer development of systems
engineers.
(a)

(b)
c01.indd 19c01.indd 19 2/8/2011 11:04:29 AM2/8/2011
11:04:29 AM
MODERN SYSTEMS
Figure 1.4. “ T ” model for systems engineer career
development. CE, chemical engineering;
ME, mechanical engineering; EE, electrical engineering; AE,
aeronautical engineering; App
Math, applied mathematics.
Domain Breadth
Systems Program Lead
S stems
Program Lead
E
xp
e
ri
e
n
ce
M

e
n
to
ri
n
g
y
Engineering
Leader (>20 years)
Large Project Lead
Senior
Systems
Engineer (13–20 years)
Small Project Lead
Systems
Engineer (9–12 years)
DSci
PhD
Team
Participant (5–8 years)
MS
u
ca

tio
n
Technical
Contributor (1–4 years)O
p
e
ra
tio
n
a
l a
n
d
F
ie
ld
T
e
c
h
n
ic
a
l
D

e
p
th
CE ME EE AE
App
Math
…BS
Educational Disciplines
E
d
u
experienced mentors and real, practical exercises. While using
systems thinking to
explore complex problem domains, staff should be encouraged
to think creatively and
out of the box. Often, technically trained people rigidly follow
the same processes and
tired ineffective solutions. Using lessons learned from past
programs and case studies
creates opportunities for improvements. Formal training and use
of systems engineering
tools further enhance employee preparation for tackling
complex issues.
Interests, attributes, and training, along with an appropriate
environment, provide
the opportunity for individuals to mature into successful
systems engineers. The com-
bination of these factors is captured in the “ T ” model for
systems engineer career devel-

opment illustrated in Figure 1.4 . In the vertical, from bottom
to top is the time progression
in a professional ’ s career path. After completion of a technical
undergraduate degree,
shown along the bottom of the chart, an individual generally
enters professional life as
a technical contributor to a larger effort. The effort is part of a
project or program that
falls in a particular domain such as aerodynamics, biomedicine,
combat systems, infor-
mation systems, or space exploration. Within a domain, there
are several technical
competencies that are fundamental for systems to operate or to
be developed.
The T is formed by snapshots during a professional ’ s career
that illustrates in the
horizontal part of the T the technical competencies at the time
that were learned and
used to meet the responsibilities assigned at that point in their
career. After an initial
c01.indd 20c01.indd 20 2/8/2011 11:04:30 AM2/8/2011
11:04:30 AM
THE POWER OF SYSTEMS ENGINEERING 21
experience in one or two technical domains as technical
contributor, one progresses to
increasing responsibilities in a team setting and eventually to
leading small technical
groups. After eight or more years, the professional has acquired
both suffi cient technical
depth and technical domain depth to be considered a systems

engineer. Additional
assignments lead to project and program systems engineering
leadership and eventually
to being the senior systems engineer for a major development
program that exercises
the full range of the technical competencies for the domain.
In parallel with broadening and deepening technical experience
and competencies,
the successful career path is augmented by assignments that
involve operational fi eld
experiences, advanced education and training, and a strong
mentoring program. In order
to obtain a good understanding of the environment where the
system under development
will operate and to obtain fi rsthand knowledge of the system
requirements, it is essential
for the early systems engineer professional to visit the “ fi eld
site ” and operational loca-
tion. This approach is important to continue throughout one ’ s
career. A wide variety of
systems engineering educational opportunities are available in
both classroom and
online formats. As in most engineering disciplines where the
student is not planning
on an academic career, the master of science is the terminal
degree. Courses are usually
a combination of systems engineering and domain or
concentration centric focused with
a thesis or capstone project for the students to demonstrate their
knowledge and skills
on a practical systems problem. Large commercial companies
also provide training in
systems engineering and systems architecting with examples
and tools that are specifi c
to their organization and products. Finally, the pairing of a

young professional with an
experienced systems engineer will enhance the learning process.
1.6 THE POWER OF SYSTEMS ENGINEERING
If power is measured by authority over people or money, then
systems engineers would
appear to have little power as members of the system
development team. However, if
power is measured by the infl uence over the design of the
system and its major char-
acteristics, and over the success or failure of the system
development, then systems
engineers can be more powerful than project managers. The
sources of this power come
from their knowledge, skills, and attitude. Each of these is
discussed in the following
paragraphs.
The Power of Multidisciplinary Knowledge
A major system development project is a veritable “ Tower of
Babel. ” There are literally
dozens of specialists in different disciplines whose collective
efforts are necessary to
develop and produce a successful new system. Each group of
specialists has its own
language, making up for the imprecision of the English
language with a rich set of
acronyms, which convey a very specifi c meaning but are
unintelligible to those outside
the specialty. The languages, in turn, are backed up by
knowledge bases, which the
specialists use to ply their trade. These knowledge bases contain
descriptions of the
different materials peculiar to each discipline, as well as bodies

of relationships, many
c01.indd 21c01.indd 21 2/8/2011 11:04:30 AM2/8/2011
11:04:30 AM
MODERN SYSTEMS
of them expressed in mathematical terms, that enable the
specialists to compute various
characteristics of their components on the basis of design
assumptions. These knowl-
edge bases are also foreign to those outside the discipline.
Such a collection of multi - tongued participants could never
succeed in collectively
developing a new system by themselves, just as the citizens of
Babylon could never
build their tower. It is the systems engineers who provide the
linkages that enable these
disparate groups to function as a team. The systems engineers
accomplish this feat
through the power of multidisciplinary knowledge. This means
that they are suffi ciently
literate in the different disciplines involved in their system that
they can understand the
languages of the specialists, appreciate their problems, and are
able to interpret the
necessary communications for their collective endeavor. Thus,
they are in the same
position as a linguist in the midst of a multinational conference,
with people speaking
in their native tongues. Through the ability to understand
different languages comes

the capability to obtain cooperative effort from people who
would otherwise never be
able to achieve a common objective. This capability enables
systems engineers to
operate as leaders and troubleshooters, solving problems that no
one else is capable of
solving. It truly amounts to a power that gives systems
engineers a central and decisive
role to play in the development of a system.
It is important to note that the depth of interdisciplinary
knowledge, which is
required to interact effectively with specialists in a given fi eld,
is a very small fraction
of the depth necessary to work effectively in that fi eld. The
number of new acronyms
that one has to learn in a given technical area is nearer to a
dozen of the more frequently
used ones than to a hundred. It also turns out that once one gets
past the differences in
semantics, there are many common principles in different
disciplines and many similar
relationships. For instance, the equation used in
communications, connecting signal,
noise, antenna gain, receiver sensitivity, and other factors, is
directly analogous to a
similar relationship in acoustics.
These facts mean that a systems engineer does not need to
spend a lifetime becom-
ing expert in associated disciplines, but rather can accumulate a
working knowledge of
related fi elds through selected readings, and more particularly,
discussion with col-
leagues knowledgeable in each fi eld. The important thing is to
know which principles,

relationships, acronyms, and the like are important at the system
level and which are
details. The power of multidisciplinary knowledge is so great
that, to a systems engi-
neer, the effort required to accumulate it is well worth the
learning time.
The Power of Approximate Calculation
The practice of systems engineering requires another talent
besides multidisciplinary
knowledge. The ability to carry out “ back of the envelope ”
calculations to obtain a
“ sanity check ” on the result of a complex calculation or test
is of inestimable value to
the systems engineer. In a few cases, this can be done
intuitively on the basis of past
experience, but more frequently, it is necessary to make a rough
estimate to ensure that
a gross omission or error has not been committed. Most
successful systems engineers
have the ability, using fi rst principles, to apply basic
relationships, such as the com-
munications equation or other simple calculation, to derive an
order of magnitude result
c01.indd 22c01.indd 22 2/8/2011 11:04:30 AM2/8/2011
11:04:30 AM
SUMMARY 23
to serve as a check. This is particularly important if the results
of the calculation or
experiment turn out very differently from what had been

originally expected.
When the sanity check does not confi rm the results of a
simulation or experiment,
it is appropriate to go back to make a careful examination of the
assumptions and
conditions on which the latter were based. As a matter of
general experience, more
often than not, such examinations reveal an error in the
conditions or assumptions under
which the simulation or experiment was conducted.
The Power of Skeptical Positive Thinking
The above seemingly contradictory title is meant to capture an
important characteristic
of successful systems engineering. The skeptical part is
important to temper the tradi-
tional optimism of the design specialist regarding the
probability of success of a chosen
design approach. It is the driving force for the insistence of
validation of the approach
selected at the earliest possible opportunity.
The other dimension of skepticism, which is directly related to
the characteristic
of positive thinking, refers to the reaction in the face of failure
or apparent failure of a
selected technique or design approach. Many design specialists
who encounter an
unexpected failure are plunged into despair. The systems
engineer, on the other hand,
cannot afford the luxury of hand wringing but must have, fi rst
of all, a healthy skepti-
cism of the conditions under which the unexpected failure
occurred. Often, it is found

that these conditions did not properly test the system. When the
test conditions are
shown to be valid, the systems engineer must set about fi nding
ways to circumvent the
cause of failure. The conventional answer that the failure must
require a new start along
a different path, which in turn will lead to major delays and
increases in program cost,
is simply not acceptable unless heroic efforts to fi nd an
alternative solution do not
succeed. This is where the power of multidisciplinary
knowledge permits the systems
engineer to look for alternative solutions in other parts of the
system, which may take
the stress off the particular component whose design proved to
be faulty.
The characteristic of positive thinking is absolutely necessary
in both the systems
engineer and the project manager so that they are able to
generate and sustain the
confi dence of the customer and of company management, as
well as the members of
the design team. Without the “ can - do ” attitude, the esprit de
corps and productivity of
the project organization is bound to suffer.
1.7 SUMMARY
What Is Systems Engineering?
The function of systems engineering is to guide the engineering
of complex systems.
And a system is defi ned as a set of interrelated components
working together toward
a common objective. Furthermore, a complex engineered system

(as defi ned in this
book) is (1) composed of a multiplicity of intricately
interrelated diverse elements and
(2) requires systems engineering to lead its development.
c01.indd 23c01.indd 23 2/8/2011 11:04:30 AM2/8/2011
11:04:30 AM
MODERN SYSTEMS
Systems engineering differs from traditional disciplines in that
(1) it is focused on
the system as a whole; (2) it is concerned with customer needs
and operational environ-
ment; (3) it leads system conceptual design; and (4) it bridges
traditional engineering
disciplines and gaps between specialties. Moreover, systems
engineering is an integral
part of project management in that it plans and guides the
engineering effort.
Origins of Systems Engineering
Modern systems engineering originated because advancing
technology brought risks
and complexity with the growth of automation; competition
required expert risk taking;
and specialization required bridging disciplines and interfaces.
Examples of Systems Requiring Systems Engineering
Examples of engineered complex systems include

• weather satellites,
• terminal air traffi c control,
• truck location systems,
• airline navigation systems,
• clinical information systems,
• passenger aircraft,
• modern harvester combines,
• oil refi neries,
• auto assembly plants, and
• electric power plants.
Systems Engineering as a Profession
Systems engineering is now recognized as a profession and has
an increasing role in
government and industry. In fact, numerous graduate (and some
undergraduate) degree
programs are now available across the country. And a formal,
recognized organization
exists for systems engineering professionals: the INCOSE.
Technical professionals have specifi c technical orientations —
technical graduates
tend to be highly specialized. Only a few become interested in
interdisciplinary
problems — it is these individuals who often become systems
engineers.

Systems Engineer Career Development Model
The systems engineering profession is diffi cult but rewarding.
A career in systems
engineering typically features technical satisfaction — fi nding
the solution of abstract
and ambiguous problems — and recognition in the form of a
pivotal program role.
Consequently, a successful systems engineer has the following
traits and attributes:
c01.indd 24c01.indd 24 2/8/2011 11:04:30 AM2/8/2011
11:04:30 AM
PROBLEMS 25
• a good problem solver and should welcome challenges;
• well grounded technically, with broad interests;
• analytical and systematic, but also creative; and
• a superior communicator, with leadership skills.
The “ T ” model represents the proper convergence of
experience, education, men-
toring, and technical depth necessary to become a successful
and infl uential systems
engineer.
The Power of Systems Engineering
Overall, systems engineering is a powerful discipline, requiring

a multidisciplinary
knowledge, integrating diverse system elements. Systems
engineers need to possess the
ability to perform approximate calculations of complex
phenomena, thereby providing
sanity checks. And fi nally, they must have skeptical positive
thinking as a prerequisite
to prudent risk taking.
PROBLEMS
1.1 Write a paragraph explaining what is meant by the
statement “ Systems engi-
neering is focused on the system as a whole. ” State what
characteristics of a
system you think this statement implies and how they apply to
systems
engineering.
1.2 Discuss the difference between engineered complex
systems and complex
systems that are not engineered. Give three examples of the
latter. Can you
think of systems engineering principles that can also be applied
to nonengi-
neered complex systems?
1.3 For each of the following areas, list and explain how at
least two major tech-
nological advances/breakthroughs occurring since 1990 have
radically changed
them. In each case, explain how the change was effected in
(a) transportation,
(b) communication,
(c) fi nancial management,
(d) manufacturing,

(e) distribution and sales,
(f) entertainment, and
(g) medical care.
1.4 What characteristics of an airplane would you attribute
to the system as a
whole rather than to a collection of its parts? Explain why.
1.5 List four pros and cons (two of each) of incorporating
some of the latest tech-
nology into the development of a new complex system. Give a
specifi c example
of each.
c01.indd 25c01.indd 25 2/8/2011 11:04:30 AM2/8/2011
11:04:30 AM
MODERN SYSTEMS
1.6 What is meant by the term “ modularity? ” What
characteristics does a modular
system possess? Give a specifi c example of a modular system
and identify the
modules.
1.7 The section Orientation of Technical Professionals uses
three components to
describe this characteristic: science, mathematics, and
engineering. Using this
model, describe what you think your orientation is in terms of x
% science, y %
mathematics, and z % engineering. Note that your “ orientation
” does not

measure your knowledge or expertise, but rather your interest
and method of
thought. Consider your relative interest in discovering new
truths, fi nding new
relationships, or building new things and making them work.
Also, try to
remember what your orientation was when you graduated from
college, and
explain how and why it has changed.
1.8 Systems engineers have been described as being an
advocate for the whole
system. Given this statement, which stakeholders should the
systems engineer
advocate the most? Obviously, there are many stakeholders and
the systems
engineer must be concerned with most, if not all, of them.
Therefore, rank your
answer in priority order — which stakeholder is the most
important to the
systems engineer; which is second; which is third?
FURTHER READING
B. Blanchard . Systems Engineering Management , Third
Edition . John Wiley & Sons , 2004 .
B. Blanchard and W. Fabrycky . Systems Engineering
and Analysis , Fourth Edition . Prentice Hall ,
2006 , Chapter 1.
W. P. Chase . Management of System Engineering . John
Wiley , 1974 , Chapter 1.
H. Chesnut . System Engineering Methods . John Wiley ,
1967 .

H. Eisner . Essentials of Project and Systems Engineering
Management , Second Edition . Wiley ,
2002 , Chapter 1.
C. D. Flagle , W. H. Huggins , and R. R. Roy .
Operations Research and Systems Engineering .
Johns Hopkins Press , 1960 , Part I.
A. D. A. Hall . Methodology for Systems Engineering .
Van Nostrand , 1962 , Chapters 1 – 3; Systems
Engineering Handbook . International Council on Systems
Engineering , A Guide for System
Life Cycle Processes and Activities , Version 3.2, July 2010 .
E. Rechtin . Systems Architecting: Creating and Building
Complex Systems . Prentice Hall , 1991 ,
Chapters 1 and 11.
E. Rechtin and M. W. Maier . The Art of Systems
Architecting . CRC Press , 1997 .
A. P. Sage . Systems Engineering . McGraw Hill , 1992 ,
Chapter 1.
A. P. Sage and J. E. Armstrong , Jr. Introduction to
Systems Engineering . Wiley , 2000 ,
Chapter 1.
R. Stevens , P. Brook , K. Jackson , and S. Arnold
. Systems Engineering, Coping with Complexity .
Prentice Hall , 1988 .

c01.indd 26c01.indd 26 2/8/2011 11:04:30 AM2/8/2011
11:04:30 AM
27
2.1 SYSTEMS ENGINEERING VIEWPOINT
The origins of the systems engineering section in Chapter 1
described how the emer-
gence of complex systems and the prevailing conditions of
advancing technology,
competitive pressures, and specialization of engineering
disciplines and organizations
required the development of a new profession: systems
engineering. This profession
did not, until much later, bring with it a new academic
discipline, but rather, it was
initially fi lled by engineers and scientists who acquired
through experience the ability
to lead successfully complex system development programs. To
do so, they had to
acquire a greater breadth of technical knowledge and, more
importantly, to develop a
different way of thinking about engineering, which has been
called “ the systems engi-
neering viewpoint. ”
The essence of the systems engineering viewpoint is exactly
what it implies —
making the central objective the system as a whole and the
success of its mission. This,
in turn, means the subordination of individual goals and

attributes in favor of those of
the overall system. The systems engineer is always the advocate
of the total system in
any contest with a subordinate objective.
2
SYSTEMS ENGINEERING
LANDSCAPE
Wiley & Sons, Inc.
c02.indd 27c02.indd 27 2/8/2011 11:04:31 AM2/8/2011
11:04:31 AM
28 SYSTEMS ENGINEERING LANDSCAPE
Successful Systems
The principal focus of systems engineering, from the very start
of a system develop-
ment, is the success of the system — in meeting its
requirements and development
objectives, its successful operation in the fi eld, and a long,
useful operating life. The
systems engineering viewpoint encompasses all of these
objectives. It seeks to look
beyond the obvious and the immediate, to understand the user ’
s problems, and the
environmental conditions that the system will be subjected to

during its operation. It
aims at the establishment of a technical approach that will both
facilitate the system ’ s
operational maintenance and accommodate the eventual
upgrading that will likely be
required at some point in the future. It attempts to anticipate
developmental problems
and to resolve them as early as possible in the development
cycle; where this is not
practicable, it establishes contingency plans for later
implementation as required.
Successful system development requires the use of a consistent,
well - understood
systems engineering approach within the organization, which
involves the exercise of
systematic and disciplined direction, with extensive planning,
analysis, reviews, and
documentation. Just as important, however, is a side of systems
engineering that is often
overlooked, namely, innovation. For a new complex system to
compete successfully in
a climate of rapid technological change and to retain its edge
for many years of useful
life, its key components must use some of the latest
technological advances. These will
inevitably introduce risks, some known and others as yet
unknown, which in turn will
entail a signifi cant development effort to bring each new
design approach to maturity
and later to validate the use of these designs in system
components. Selecting the most
promising technological approaches, assessing the associated
risks, rejecting those for
which the risks outweigh the potential payoff, planning critical
experiments, and decid-

ing on potential fallbacks are all primary responsibilities of
systems engineering. Thus,
the systems engineering viewpoint includes a combination of
risk taking and risk
mitigation.
The “ Best ” System
In characterizing the systems engineering viewpoint, two oft -
stated maxims are “ the
best is the enemy of the good enough ” and “ systems
engineering is the art of the good
enough. ” These statements may be misleading if they are
interpreted to imply that
systems engineering means settling for second best. On the
contrary, systems engineer-
ing does seek the best possible system, which, however, is often
not the one that pro-
vides the best performance. The seeming inconsistency comes
from what is referred to
by best. The popular maxims use the terms “ best ” and “ good
enough ” to refer to system
performance, whereas systems engineering views performance
as only one of several
critical attributes; equally important ones are affordability,
timely availability to the
user, ease of maintenance, and adherence to an agreed - upon
development completion
schedule. Thus, the systems engineer seeks the best balance of
the critical system
attributes from the standpoint of the success of the development
program and of the
value of the system to the user.
The interdependence of performance and cost can be
understood in terms of the

law of diminishing returns. Assuming a particular technical
approach to the achieve-
c02.indd 28c02.indd 28 2/8/2011 11:04:31 AM2/8/2011
11:04:31 AM
SYSTEMS ENGINEERING VIEWPOINT 29
ment of a given performance attribute of a system under
development, Figure 2.1 a is
a plot of a typical variation in the level of performance of a
hypothetical system com-
ponent as a function of the cost of the expended development
effort. The upper hori-
zontal line represents the theoretical limit in performance
inherent in the selected
technical approach. A more sophisticated approach might
produce a higher limit, but
at a higher cost. The dashed horizontal lines represent the
minimum acceptable and
desirable performance levels.
The curve of Figure 2.1 a originates at C 0 , which represents
the cost of just achiev-
ing any signifi cant performance. The slope is steep at fi rst,
becoming less steep as the
performance asymptotically approaches the theoretical limit.
This decreasing slope,
Figure 2.1. (a) Performance versus cost. (b)
Performance/cost versus cost.
80

90
100
Desired
60
70
Minimum Acceptable
30
40
50
P
e
rf
o
rm
a
n
ce
10
20
0
Cost
C0

3
Minimum Acceptable Performance
Desired Performance
2
1
P
e
rf
o
rm
a
n
ce
/
C
o
st
0
Cost
C0
(a)
(b)

c02.indd 29c02.indd 29 2/8/2011 11:04:31 AM2/8/2011
11:04:31 AM
which is a measure of the incremental gain in performance with
an increment of added
cost, illustrates the law of diminishing returns that applies to
virtually all developmental
activities.
An example of the above general principle is the development
of an automobile
with a higher maximum speed. A direct approach to such a
change would be to use an
engine that generates greater power. Such an engine would
normally be larger, weigh
more, and use gas less effi ciently. Also, an increase in speed
will result in greater air
drag, which would require a disproportionately large increase in
engine power to over-
come. If it was required to maintain fuel economy and to retain
vehicle size and weight
as nearly as possible, it would be necessary to consider using or
developing a more
advanced engine, improving body streamlining, using special
lightweight materials, and
otherwise seeking to offset the undesirable side effects of
increasing vehicle speed. All
of the above factors would escalate the cost of the modifi ed
automobile, with the incre-
mental costs increasing as the ultimate limits of the several
technical approaches are

approached. It is obvious, therefore, that a balance must be
struck well short of the
ultimate limit of any performance attribute.
An approach to establishing such a balance is illustrated in
Figure 2.1 b. This fi gure
plots performance divided by cost against cost (i.e., y / x vs. x
from Fig. 2.1 a). This
performance - to - cost ratio is equivalent to the concept of cost
- effectiveness. It is seen
that this curve has a maximum, beyond which the gain in
effectiveness diminishes. This
shows that the performance of the best overall system is likely
to be close to that where
the performance/cost ratio peaks, provided this point is signifi
cantly above the minimum
acceptable performance.
A Balanced System
One of the dictionary defi nitions of the word “ balance ” that
is especially appropriate
to system design is “ a harmonious or satisfying arrangement or
proportion of parts or
elements, as in a design or a composition. ” An essential
function of systems engineering
is to bring about a balance among the various components of the
system, which, it was
noted earlier, are designed by engineering specialists, each
intent on optimizing the
characteristics of a particular component. This is often a
daunting task, as illustrated in
Figure 2.2 . The fi gure is an artist ’ s conception of what a
guided missile might look like
if it were designed by a specialist in one or another guided
missile component technol-

ogy. While the cartoons may seem fanciful, they refl ect a basic
truth, that is, that design
specialists will seek to optimize the particular aspect of a
system that they best under-
stand and appreciate. In general, it is to be expected that, while
the design specialist
does understand that the system is a group of components that
in combination provide
a specifi c set of capabilities, during system development, the
specialist ’ s attention is
necessarily focused on those issues that most directly affect his
or her own area of
technical expertise and assigned responsibilities.
Conversely, the systems engineer must always focus on the
system as a whole,
while addressing design specialty issues only in so far as they
may affect overall system
performance, developmental risk, cost, or long - term system
viability. In short, it is the
responsibility of the systems engineer to guide the development
so that each of the
c02.indd 30c02.indd 30 2/8/2011 11:04:31 AM2/8/2011
11:04:31 AM
SYSTEMS ENGINEERING VIEWPOINT 31
components receives the proper balance of attention and
resources while achieving the
capabilities that are optimal for the best overall system
behavior. This often involves
serving as an “ honest technical broker ” who guides the
establishment of technical

design compromises in order to achieve a workable interface
between key system
elements.
A Balanced Viewpoint
A system view thus connotes a focus on balance, ensuring that
no system attribute is
allowed to grow at the expense of an equally important or more
important attribute, for
example, greater performance at the expense of acceptable cost,
high speed at the
expense of adequate range, or high throughput at the expense of
excessive errors. Since
virtually all critical attributes are interdependent, a proper
balance must be struck in
essentially all system design decisions. These characteristics are
typically incommen-
surable, as in the above examples, so that the judgment of how
they should be balanced
must come from a deep understanding of how the system works.
It is such judgment
that systems engineers have to exercise every day, and they
must be able to think at a
level that encompasses all of the system characteristics.
The viewpoint of the systems engineer calls for a different
combination of skills
and areas of knowledge than those of a design specialist or a
manager. Figure 2.3 is
Figure 2.2. The ideal missile design from the viewpoint of
various specialists.
FEE
L

FEEL
Aerodynamics
Structures
Controls Analysis
Guidance
Production
Propulsion
c02.indd 31c02.indd 31 2/8/2011 11:04:31 AM2/8/2011
11:04:31 AM
intended to illustrate the general nature of these differences.
Using the three dimensions
to represent technical depth, technical breadth, and management
depth, respectively, it
is seen that the design specialist may have limited managerial
skills but has a deep
understanding in one or a few related areas of technology.
Similarly, a project manager
needs to have little depth in any particular technical discipline
but must have consider-
able breadth and capability to manage people and technical
effort. A systems engineer,
on the other hand, requires signifi cant capabilities in all three
components, representing

the balance needed to span the needs of a total system effort. In
that sense, the systems
engineer operates in more dimensions than do his or her
coworkers.
2.2 PERSPECTIVES OF SYSTEMS ENGINEERING
While the fi eld of systems engineering has matured rapidly in
the past few decades,
there will continue to exist a variety of differing perspectives as
more is learned about
the potential and the utility of systems approaches to solve the
increasing complex
problems around the world. The growth of systems engineering
is evidenced in the
number of academic programs and graduates in the area. Some
surveys note that
systems engineering is a favored and potentially excellent
career path. Employers in
all sectors, private and government, seek experienced systems
engineering candidates.
Experts in workforce development look for ways to encourage
more secondary school
Figure 2.3. The dimensions of design, systems
engineering, and project planning and control.
Project planning
and control
Management
expertise
Technical breadth
Technical

depth
Systems engineering
Component design
c02.indd 32c02.indd 32 2/8/2011 11:04:31 AM2/8/2011
11:04:31 AM
PERSPECTIVES OF SYSTEMS ENGINEERING 33
and college students to pursue degrees in science, technology,
engineering, and math-
ematics (STEM). With experience and additional knowledge,
these students would
mature into capable systems engineers.
Since it often requires professional experience in addition to
education to tackle
the most complex and challenging problems, developing a
systems mindset — to “ think
like a systems engineer ” — is a high priority at any stage of
life. A perspective that
relates a progression in the maturity of thinking includes
concepts of systems thinking,
systems engineering, and engineering systems (see Table 2.1 )
An approach to under-
standing the environment, process, and policies of a systems
problem requires one to
use systems thinking. This approach to a problem examines the
domain and scope of
the problem and defi nes it in quantitative terms. One looks at
the parameters that help
defi ne the problem and then, through research and surveys,

develops observations about
the environment the problem exists in and fi nally generates
options that could address
the problem. This approach would be appropriate for use in
secondary schools to have
young students gain an appreciation of the “ big picture ” as
they learn fundamental
science and engineering skills.
The systems engineering approach discussed in this book and
introduced in Chapter
1 focuses on the products and solutions of a problem, with the
intent to develop or
build a system to address the problem. The approach tends to be
more technical, seeking
from potential future users and developers of the solution
system, what are the top level
needs, requirements, and concepts of operations, before
conducting a functional and
physical design, development of design specifi cations,
production, and testing of a
system solution for the problem. Attention is given to the
subsystem interfaces and the
need for viable and tangible results. The approach and practical
end could be applied
to many degrees of complexity, but there is an expectation of a
successful fi eld opera-
tion of a product. The proven reliability of the systems
engineering approach for product
development is evident in many commercial and military
sectors.
A broader and robust perspective to systems approaches to
solve very extensive
complex engineering problems by integrating engineering,
management, and social

science approaches using advanced modeling methodologies is
termed “ engineering
TA B L E 2.1. Comparison of Systems Perspectives
Systems thinking Systems engineering Engineering
systems
Focus on process Focus on whole product Focus on both
process and
product
Consideration of issues Solve complex technical
problems
Solve complex interdisciplinary
technical, social, and
management issues
Evaluation of multiple
factors and infl uences
Develop and test tangible
system solutions
Infl uence policy, processes and
use systems engineering to
develop system solutions
Inclusion of patterns
relationships, and
common understanding
Need to meet requirements,
measure outcomes and
solve problems

Integrate human and technical
domain dynamics and
approaches
c02.indd 33c02.indd 33 2/8/2011 11:04:31 AM2/8/2011
11:04:31 AM
systems. ” The intent is to tackle some of society ’ s grandest
challenges with signifi cant
global impact by investigating ways in which engineering
systems behave and interact
with one another including social, economic, and environmental
factors. This approach
encompasses engineering, social science, and management
processes without the
implied rigidity of systems engineering. Hence, applications to
critical infrastructure,
health care, energy, environment, information security, and
other global issues are likely
areas of attention.
Much like the proverbial blind men examining the elephant, the
fi eld of systems
engineering can be considered in terms of various domains and
application areas where
it is applied. Based on the background of the individuals and on
the needs of the systems
problems to be solved, the systems environment can be
discussed in terms of the fi elds
and technologies that are used in the solution sets. Another
perspective can be taken

from the methodologies and approaches taken to solve problems
and to develop complex
systems. In any mature discipline, there exist for systems
engineering a number of
processes, standards, guidelines, and software tools to organize
and enhance the effec-
tiveness of the systems engineering professional. The
International Council of Systems
Engineering maintains current information and reviews in these
areas. These perspec-
tives will be discussed in the following sections.
2.3 SYSTEMS DOMAINS
With a broad view of system development, it can be seen that
the traditional approach
to systems now encompasses a growing domain breadth. And
much like a Rubik ’ s
Cube, the domain faces are now completely integrated into the
systems engineer ’ s
perspective of the “ big (but complex) picture. ” The systems
domain faces shown in
Figure 2.4 include not only the engineering, technical, and
management domains but
Figure 2.4. Systems engineering domains.
Management
Engineering
Political/Legal
Sy
ste
m

s
En
gin
ee
rin
g
Technical
Social
Human
c02.indd 34c02.indd 34 2/8/2011 11:04:31 AM2/8/2011
11:04:31 AM
SYSTEMS ENGINEERING FIELDS 35
also social, political/legal, and human domains. These latter
softer dimensions require
additional attention and research to fully understand their
impact and utility in system
development, especially as we move to areas at the enterprise
and global family of
systems levels of complexity.
Particularly interesting domains are those that involve scale,
such as nano - and
microsystems, or systems that operate (often autonomously) in
extreme environments,
such as deep undersea or outer space. Much like physical laws

change with scale, does
the systems engineering approach need to change? Should
systems engineering prac-
tices evolve to address the needs for submersibles, planetary
explorers, or intravascular
robotic systems?
2.4 SYSTEMS ENGINEERING FIELDS
Since systems engineering has a strong connection bridging the
traditional engineering
disciplines like electrical, mechanical, aerodynamic, and civil
engineering among
others, it should be expected that engineering specialists look at
systems engineering
with a perspective more strongly from their engineering
discipline. Similarly, since
systems engineering is a guide to design of systems often
exercised in the context of a
project or program, then functional, project, and senior
managers will consider the
management elements of planning and control to be key aspects
of system development.
The management support functions that are vital to systems
engineering success such
as quality management, human resource management, and fi
nancial management can
all claim an integral role and perspective to the system
development.
These perceptions are illustrated in Figure 2.5 , and additional
fi elds that represent
a few of the traditional areas associated with systems
engineering methods and practices
are also shown. An example is the area of operations research
whose view of systems

engineering includes provision of a structure that will lead to a
quantitative analysis of
Figure 2.5. Examples of systems engineering fi elds.
Management
Systems
Engineering
Project Management
Modeling and
Simulation
Control Systems
c02.indd 35c02.indd 35 2/8/2011 11:04:32 AM2/8/2011
11:04:32 AM
alternatives and optimal decisions. The design of systems also
has a contingency of
professionals who focus on the structures and architectures. In
diverse areas such as
manufacturing to autonomous systems, another interpretation of
systems engineering
comes from engineers who develop control systems, who lean
heavily on the systems
engineering principles that focus on management of interfaces
and feedback systems.
Finally, the overlap of elements of modeling and simulation

with systems engineering
provides a perspective that is integral to a cost - effective
examination of systems options
to meet the requirements and needs of the users. As systems
engineering matures, there
will be an increasing number of perspectives from varying fi
elds that adopt it as their
own.
2.5 SYSTEMS ENGINEERNG APPROACHES
Systems engineering can also be viewed in terms of the
depictions of the sequence of
processes and methodologies used in the execution of the
design, development, integra-
tion, and testing of a system (see Figure 2.6 for examples).
Early graphics were linear
Figure 2.6. Examples of systems engineering approaches.
Regional
Architecture(s)
Life Cycle Processes
Feasibility
Study/Concept
Exploration
Operations
and
Maintenance
Changes

and
Upgrades
Retirement/
Replacement
Concept of
Operations
System Validation Plan
System Validation Plan
(System Acceptance)
Unit/Device
Test Plan
Subsustem
Verfication Plan
(Subsystem Acceptance)
D
ecom
position and D
efinition
In
te
gr
at
io

n
an
d
R
ec
om
po
si
tio
n
System
Validation
System
Requirements
System
Verification and
Deployment
High-Level
Design
Subsystem
Verification
Detailed
Design

Unit/Device
Testing
Document/Approval
Time Line
Software/Hardware
Development
Field Installation
Implementation
Development Processes
Concept Engineering
Deficiencies Specifications Specifications
Documentation
Development
Development
Postdevelopment
Technological Defined System Production Installed Operational
Opportunities
Concept System

System
Operation and
Operational System Functional Production
Maintenance
Previous
Phase
Objectives
Requirements
Analysis
(Problem Definition)
Requirements
Functional
Definition
(Functional Analysis
and Allocation)
Functions
Physical
Definition
(Synthesis, Physical
Analysis and Allocation)

Design
Validation
(Verification,
System
Model
Evaluation)
Next
Phase
Validated
System
Model
Need
c02.indd 36c02.indd 36 2/8/2011 11:04:32 AM2/8/2011
11:04:32 AM
SYSTEMS ENGINEERING ACTIVITIES AND PRODUCTS 37
in the process fl ow with sequences of steps that are often
iterative to show the logical
means to achieve consistency and viability. Small variations are
shown in the waterfall
charts that provide added means to illustrate interfaces and
broader interactions. Many

of the steps that are repeated and dependent on each other lead
to the spiral or loop
conceptual diagrams. The popular systems engineering “ V ”
diagram provides a view
of life cycle development with explicit relationships shown
between requirements and
systems defi nition and the developed and validated product.
A broader perspective shown in Figure 2.7 provides a full life
cycle view and
includes the management activities in each phase of
development. This perspective
illustrates the close relationship between management planning
and control and the
systems engineering process.
2.6 SYSTEMS ENGINEERING ACTIVITIES AND
PRODUCTS
Sometimes followed as a road map, the life cycle development
of a system can be
associated with a number of systems engineering and project
management products or
outputs that are listed in Table 2.2 . The variety and breadth of
these products refl ect
Figure 2.7. Life cycle systems engineering view. PERT,
Program Evaluation and Review
Technique; PDR, Preliminary Design Review; CDR, Critical
Design Review.
Users–Operators
Market Pull
Pricing/Estimating
Contracting

Organizational Structures
Project Manager Attributes
Authorities
Customer
Requirements
Market Assessment
• Proposal
• Statement of Work
• Product Definition
Discussions
Collaboration
Form Project Office
Start Work
Win !
• Concept
• New Product Idea
• Technology Push
Preliminary System/
Product Concept
Definition
Functional/System
Block Diagram
Brainstorming
War Rooms Work

Breakdown
Structure
(WBS)
Risk
Assessment
Plan
Needs Analysis
Budget and Schedules
(PERT and Gantt Charts)Concept and
Program Definition
Planning
Systems
Integration and
Verification
• Task Work Orders
• Work Authorizations
Develop Prototype
Specs
Design
Production Quantities
Verification
System Test and

Evaluation
Evaluate Prototype
(“Beta Tests”)
• Linear Responsibility Charts
• Critical path Analysis
PDR
Subsystem
Fabrication
CDR
Direction, Monitor, Control
Quality
Management
( ) p y
Design/Technology Validation/Engineering
DevelopmentProduction/Manufacturing
Config.
Manage.
Field Test and
Evaluation
Operations and
Maintenance
T/E and Operational Support

Delivery
Install/
Acceptance
• Project Closeout
• Follow-on?
Logistics
Warehousing
Sales
System Use
Concept Exploration
c02.indd 37c02.indd 37 2/8/2011 11:04:32 AM2/8/2011
11:04:32 AM
the challenges early professionals have in understanding the full
utility of engaging in
systems engineering. Throughout this book, these products will
be introduced and
discussed in some detail to help guide the systems engineer in
product development.
2.7 SUMMARY
Systems Engineering Viewpoint
The systems engineering viewpoint is focused on producing a

successful system that
meets requirements and development objectives, is successful in
its operation in the
fi eld, and achieves its desired operating life. In order to
achieve this defi nition of
success, the systems engineer must balance superior
performance with affordability and
schedule constraints. In fact, many aspects of systems
engineering involve achieving a
balance among confl icting objectives. For example, the systems
engineering typically
must apply new technology to the development of a new system
while managing the
inherent risks that new technology poses.
Throughout the development period, the systems engineer
focuses his or her per-
spective on the total system, making decisions based on the
impacts and capabilities
of the system as a whole. Often, this is accomplished by
bridging multiple disciplines
and components to ensure a total solution. Specialized design is
one dimensional in
that it has great technical depth, but little technical breadth and
little management
expertise. Planning and control is two dimensional: it has great
management expertise,
but moderate technical breadth and small technical depth. But
systems engineering is
three dimensional: it has great technical breadth, as well as
moderate technical depth
and management expertise.
Perspectives of Systems Engineering
A spectrum of views exist in understanding systems

engineering, from a general
systems thinking approach to problems, to the developmental
process approach for
systems engineering, to the broad perspective of engineering
systems.
TA B L E 2.2. Systems Engineering Activities and
Documents
Context diagrams Opportunity assessments Prototype
integration
Problem defi nition Candidate concepts Prototype test and
evaluation
User/owner identifi cation Risk analysis/management plan
Production/operations plan
User needs Systems functions Operational tests
Concept of operations Physical allocation Verifi cation
and validation
Scenarios Component interfaces Field
support/maintenance
Use cases Traceability System/product effectiveness
Requirements Trade studies Upgrade/revise
Technology readiness Component development & test
Disposal/reuse
c02.indd 38c02.indd 38 2/8/2011 11:04:32 AM2/8/2011
11:04:32 AM
PROBLEMS 39
Systems Domains
The engineering systems view encompasses not only traditional
engineering

disciplines but also technical and management domains and
social, political/legal,
and human domains. Scales at the extremes are of particular
interest due to their
complexity.
Systems Engineering Fields
Systems engineering encompasses or overlaps with many
related fi elds including engi-
neering, management, operations analysis, architectures,
modeling and simulation, and
many more.
Systems Engineering Approaches
As the fi eld of systems engineering matures and is used for
many applications, several
process models have been developed including the linear, V,
spiral, and waterfall
models.
Systems Engineering Activities and Products
A full systems life cycle view illustrated the close relationship
with management
process and leads to a large, diverse set of activities and
products.
PROBLEMS
2.1 Figure 2.1 illustrates the law of diminishing returns
in seeking the optimum
system (or component) performance and hence the need to
balance the perfor-
mance against the cost. Give examples of two pairs of

characteristics other
than performance versus cost where optimizing one frequently
competes with
the other, and briefl y explain why they do.
2.2 Explain the advantages and disadvantages of
introducing system concepts to
secondary students in order to encourage them to pursue STEM
careers.
2.3 Select a very large complex system of system example
and explain how the
engineering systems approach could provide useful solutions
that would have
wide acceptance across many communities.
2.4 Referring to Figure 2.5 , identify and justify other
disciplines that overlap with
systems engineering and give examples how those disciplines
contribute to
solving complex systems problems.
2.5 Discuss the use of different systems engineering process
models in terms of
their optimal use for various system developments. Is one model
signifi cantly
better than another?
c02.indd 39c02.indd 39 2/8/2011 11:04:32 AM2/8/2011
11:04:32 AM
FURTHER READING

B. Blanchard . Systems Engineering Management , Third
Edition . John Wiley & Sons , 2004 .
H. Eisner . Essentials of Project and Systems Engineering
Management , Second Edition . John
Wiley & Sons , 2002 .
c02.indd 40c02.indd 40 2/8/2011 11:04:32 AM2/8/2011
11:04:32 AM
41
3.1 SYSTEM BUILDING BLOCKS AND INTERFACES
The need for a systems engineer to attain a broad knowledge of
the several interacting
disciplines involved in the development of a complex system
raises the question of how
deep that understanding needs to be. Clearly, it cannot be as
deep as the knowledge
possessed by the specialists in these areas. Yet it must be suffi
cient to recognize such
factors as program risks, technological performance limits, and
interfacing require-
ments, and to make trade - off analyses among design
alternatives.
Obviously, the answers depend on specifi c cases. However, it
is possible to provide
an important insight by examining the structural hierarchy of
modern systems. Such an

examination reveals the existence of identifi able types of the
building blocks that make
up the large majority of systems and represent the lower
working level of technical
understanding that the systems engineer must have in order to
do the job. This is the
level at which technical trade - offs affecting system
capabilities must be worked out and
at which interface confl icts must be resolved in order to
achieve a balanced design
across the entire system. The nature of these building blocks in
their context as funda-
mental system elements and their interfaces and interactions are
discussed in the
ensuing sections.
3
STRUCTURE OF
COMPLEX SYSTEMS
Wiley & Sons, Inc.
c03.indd 41c03.indd 41 2/8/2011 11:04:33 AM2/8/2011
11:04:33 AM
42 STRUCTURE OF COMPLEX SYSTEMS
3.2 HIERARCHY OF COMPLEX SYSTEMS

In order to understand the scope of systems engineering and
what a systems engineer
must learn to carry out the responsibilities involved in guiding
the engineering of a
complex system, it is necessary to defi ne the general scope and
structure of that system.
Yet, the defi nition of a “ system ” is inherently applicable to
different levels of aggrega-
tion of complex interacting elements. For example, a telephone
substation, with its
distributed lines to the area that it serves, can be properly called
a system. Hotel and
offi ce building switchboards, with their local lines, may be
called “ subsystems, ” and
the telephone instruments may be called “ components ” of the
system. At the same time,
the substation may be regarded as a subsystem of the city
telephone system and that,
in turn, to be a subsystem of the national telephone system.
In another example, a commercial airliner certainly qualifi es
to be called a system,
with its airframe, engines, controls, and so on, being
subsystems. The airliner may also
be called a subsystem of the air transportation system, which
consists of the air terminal,
air traffi c control, and other elements of the infrastructure in
which the airliner operates.
Thus, it is often said that every system is a subsystem of a
higher - level system, and
every subsystem may itself be regarded as a system.
The above relationships have given rise to terms such as “
supersystems ” to refer
to overarching systems like the wide - area telephone system
and the air transportation

system. In networked military systems, the term “ system of
systems ” (SoS) has been
coined to describe integrated distributed sensor and weapon
systems. This nomenclature
has migrated to the commercial world as well; however, the use
and defi nition of the
term varies by area and specialty.
Model of a Complex System
While learning the fundamentals of systems engineering, this
ambiguity of the scope
of a system may be confusing to some students. Therefore, for
the purpose of illustrat-
ing the typical scope of a systems engineer ’ s responsibilities,
it is useful to create a
more specifi c model of a typical system. As will be described
later, the technique of
modeling is one of the basic tools of systems engineering,
especially in circumstances
where unambiguous and quantitative facts are not readily
available. In the present
instance, this technique will be used to construct a model of a
typical complex system
in terms of its constituent parts. The purpose of this model is to
defi ne a relatively
simple and readily understood system architecture, which can
serve as a point of refer-
ence for discussing the process of developing a new system and
the role of systems
engineering throughout the process. While the scope of this
model does not extend to
that of supersystems or an SoS, it is representative of the
majority of systems that are
developed by an integrated acquisition process, such as a new
aircraft or a terminal air

traffi c control system.
By their nature, complex systems have a hierarchical structure
in that they consist
of a number of major interacting elements, generally called
subsystems , which them-
selves are composed of more simple functional entities, and so
on down to primitive
elements such as gears, transformers, or light bulbs, usually
referred to as parts .
c03.indd 42c03.indd 42 2/8/2011 11:04:33 AM2/8/2011
11:04:33 AM
HIERARCHY OF COMPLEX SYSTEMS 43
Commonly used terminology for the various architectural levels
in the structure of
systems is confi ned to the generic system and subsystem
designation for the uppermost
levels and parts for the lowest.
For reasons that will become evident later in this section, the
system model as
defi ned in this book will utilize two additional intermediate
levels, which will be called
components and subcomponents . While some models use one
or two more intermediate
levels in their representation of systems, these fi ve have proven
to be suffi cient for the
intended purpose.
Defi nition of System Levels. Table 3.1 illustrates the
above characterization

of the hierarchical structure of the system model. In this table,
four representative
system types employing advanced technology are listed
horizontally, and successive
levels of subdivisions within each system are arranged
vertically.
In describing the various levels in the system hierarchy
depicted in the fi gure, it
was noted previously that the term system as commonly used
does not correspond to a
specifi c level of aggregation or complexity, it being understood
that systems may serve
as parts of more complex aggregates or supersystems, and
subsystems may themselves
be thought of as systems. For the purpose of the ensuing
discussion, this ambiguity will
be avoided by limiting the use of the term system to those
entities that
1. possess the properties of an engineered system and
2. perform a signifi cant useful service with only the aid of
human operators
and standard infrastructures (e.g., power grid, highways, fueling
stations, and
TA B L E 3.1. System Design Hierarchy
Systems
Communications
systems
Information
systems

Material processing
systems
Aerospace systems
Subsystems
Signal networks Databases Material preparation Engines
Components
Signal
receivers
Data displays Database
programs
Power transfer Material
reactors
Thrust
generators
Subcomponents
Signal
amplifi ers
Cathode ray
tubes
Library
utilities
Gear trains Reactive

valves
Rocket
nozzles
Parts
Transformer LED Algorithms Gears Couplings Seals
c03.indd 43c03.indd 43 2/8/2011 11:04:33 AM2/8/2011
11:04:33 AM
communication lines). According to the above conditions, a
passenger aircraft
would fi t the defi nition of a system, as would a personal
computer with its
normal peripherals of input and output keyboard, display, and
so on.
The fi rst subordinate level in the system hierarchy defi ned in
Table 3.1 is appro-
priately called a subsystem and has the conventional
connotation of being a major
portion of the system that performs a closely related subset of
the overall system func-
tions. Each subsystem may in itself be quite complex, having
many of the properties
of a system except the ability to perform a useful function in the
absence of its com-
panion subsystems. Each subsystem typically involves several
technical disciplines
(e.g., electronic and mechanical).

The term component is commonly used to refer to a range of
mostly lower - level
entities, but in this book, the term component will be reserved
to refer to the middle
level of system elements described above. Components will
often be found to corre-
spond to confi guration items (CIs) in government system
acquisition notation.
The level below the component building blocks is composed of
entities, referred
to as subcomponents, which perform elementary functions and
are composed of several
parts. The lowest level, composed of parts, represents elements
that perform no signifi -
cant function except in combination with other parts. The great
majority of parts come
in standard sizes and types and can usually be obtained
commercially.
Domains of the Systems Engineer and Design Specialist
From the above discussion, the hierarchical structure of
engineered systems can be used
to defi ne the respective knowledge domains of both the systems
engineer and the design
specialist. The intermediate system components occupy a
central position in the system
development process, representing elements that are, for the
most part, products fi tting
within the domain of industrial design specialists, who can
adapt them to a particular
application based on a given set of specifi cations. The proper
specifi cation of compo-
nents, especially to defi ne performance and to ensure

compatible interfaces, is the
particular task of systems engineering. This means that the
systems engineer ’ s knowl-
edge must extend to the understanding of the key characteristics
of components from
which the system may be constituted, largely through dialogue
and interaction with the
design specialists, so that he or she may select the most
appropriate types and specify
their performance and interfaces with other components.
The respective knowledge domains of the systems engineer and
the design special-
ist are shown in Figure 3.1 using the system hierarchy defi ned
above. It shows that the
systems engineer ’ s knowledge needs to extend from the
highest level, the system and
its environment, down through the middle level of primary
system building blocks or
components. At the same time, the design specialist ’ s
knowledge needs to extend from
the lowest level of parts up through the components level, at
which point their two
knowledge domains “ overlap. ” This is the level at which the
systems engineer and the
design specialist must communicate effectively, identify and
discuss technical prob-
lems, and negotiate workable solutions that will not jeopardize
either the system design
process or the capabilities of the system as a whole.
c03.indd 44c03.indd 44 2/8/2011 11:04:33 AM2/8/2011
11:04:33 AM

SYSTEM BUILDING BLOCKS 45
The horizontal boundaries of these domains are deliberately
shown as continuity
lines in the fi gure to indicate that they should be extended as
necessary to refl ect the
composition of the particular system. When a subcomponent or
part happens to be
critical to the system ’ s operation (e.g., the ill - fated seal in
the space shuttle Challenger ’ s
booster rocket), the systems engineer should be prepared to
learn enough about its
behavior to identify its potential impact on the system as a
whole. This is frequently
the case in high - performance mechanical and
thermomechanical devices, such as tur-
bines and compressors. Conversely, when the specifi ed
function of a particular compo-
nent imposes unusual demands on its design, the design
specialist should call on the
systems engineer to reexamine the system - level assumptions
underlying this particular
requirement.
3.3 SYSTEM BUILDING BLOCKS
Using this system model provides systems engineers with a
simple method of partition-
ing a system along a functional and physical dimension:
understanding the functional
aspects of the system, then partitioning the system into a
physical hierarchy. Each
dimensional description of the system can then be decomposed
into elements. Below
is the description of these two categories of building blocks and
a recommended set of

elements used in defi ning the components of each.
Figure 3.1. Knowledge domains of the systems engineer
and the design specialist.
Systems
Systems
engineer …
Subsystems
Components
Signals Data Materials Energy …
Electro-
optical
Software Electromechanical Mechanical Thermomechanical
Subcomponents
Electronic …
Parts
Design
specialist …
c03.indd 45c03.indd 45 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM

Functional Building Blocks: Functional Elements
The three basic entities that constitute the media on which
systems operate are
1. Information: the content of all knowledge and
communication,
2. Material: the substance of all physical objects, and
3. Energy: energizes the operation and movement of all
active system
components.
Because all system functions involve a purposeful alteration in
some characteristic
of one or more of these entities, the latter constitutes a natural
basis for classifying the
principal system functional units. Since information elements
are more than twice as
populous as the material and energy entities among system
functions, it is convenient
to subdivide them into two classes: (1) elements dealing with
propagating information
(e.g., radio signals), to be referred to as signal elements , and
(2) those dealing with
stationary information (e.g., computer programs), to be referred
to as data elements .
The former class is primarily associated with sensing and
communications and the latter
with analysis and decision processes. This results in a total of
four classes of system
functional elements:

1. Signal Elements, which sense and communicate
information;
2. Data Elements, which interpret, organize, and
manipulate information;
3. Material Elements, which provide structure and
transformation of materials;
and
4. Energy Elements, which provide energy and motive
power.
To provide a context for acquainting the student with signifi
cant design knowledge
peculiar to each of the four broad classes of functional
elements, a set of generic func-
tional elements has been defi ned that represents the majority of
important types for
each class.
To make the selected elements self - consistent and
representative, three criteria may
be used to ensure that each element is neither trivially simple
nor inordinately complex
and has wide application:
1. Signifi cance. Each functional element must perform a
distinct and signifi cant
function, typically involving several elementary functions.
2. Singularity. Each functional element should fall
largely within the technical
scope of a single engineering discipline.
3. Commonality. The function performed by each element

can be found in a wide
variety of system types.
In confi guring the individual functional elements, it is noted
that regardless of their
primary function and classifi cation, their physical embodiments
are necessarily built of
material usually controlled by external information and powered
by electricity or some
c03.indd 46c03.indd 46 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM
other source of energy. Thus, a television set, whose main
function is to process infor-
mation in the form of a radio frequency signal into information
in the form of a TV
picture and sound, is built of materials, powered by electricity,
and controlled by user -
generated information inputs. Accordingly, it should be
expected that most elements in
all classes would have information and energy inputs in addition
to their principal
processing inputs and outputs.
The above process converges on a set of 23 functional
elements, fi ve or six in each
class. These are listed in the middle column of Table 3.2 . The
function of the class as
a whole is shown in the left column, and typical applications
that might embody the
individual elements are listed in the right column. It should be

noted that the above
classifi cation is not meant to be absolute, but is established
solely to provide a system-
atic and logical framework for discussing the properties of
systems at the levels of
importance to systems engineers.
Fundamentally, the functional design of any system may be
defi ned by conceptu-
ally combining and interconnecting the identifi ed functional
elements along with
perhaps one or two very specialized elements that might
perform a unique function in
certain system applications so as to logically derive the desired
system capabilities from
TA B L E 3.2. System Functional Elements
Class function Element function Applications
Signal — generate, transmit,
distribute, and receive signals used
in passive or active sensing and in
communications
Input signal
Transmit signal
Transduce signal
Receive signal
Process signal
Output signal
TV camera
FM radio transmitter
Radar antenna
Radio receiver

Image processor
Data — analyze, interpret, organize,
query, and/or convert data and
information into forms desired by
the user or other systems
Input data
Process data
Control data
Control processing
Store data
Output data
Display data
Keyboard
Computer CPU
Operating system
Word processor
Printer
Material — provide system structural
support or enclosure, or transform
the shape, composition, or location
of material substances
Support material
Store material
React material
Form material
Join material
Control position
Airframe
Shipping container
Autoclave

Milling machine
Welding machine
Servo actuator
Energy — provide and convert energy
or propulsive power to the system
Generate thrust
Generate torque
Generate electricity
Control temperature
Control motion
Turbojet engine
Reciprocating engine
Solar cell array
Refrigerator
Auto transmission
c03.indd 47c03.indd 47 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM
the available system inputs. In effect, the system inputs are
transformed and processed
through the interconnected functions to provide the desired
system outputs.
Physical Building Blocks: Components
System physical building blocks are the physical embodiments
of the functional ele-
ments consisting of hardware and software. Consequently, they

have the same distin-
guishing characteristics of signifi cance, singularity, and
commonality and are at the
same level in the system hierarchy, generally one level below a
typical subsystem and
two levels above a part. They will be referred to as component
elements or simply as
components.
The classes into which the component building blocks have
been categorized are
based on the different design disciplines and technologies that
they represent. In total,
31 different component types were identifi ed and grouped into
six categories, as shown
in Table 3.3 . The table lists the category, component name,
and the functional element(s)
with which it is associated. As in the case of functional
elements, the component names
are indicative of their primary function but, in this case,
represent things rather than
processes. Many of these represent devices that are in
widespread use.
The systems engineer ’ s concern with the implementation of
the functional elements
within components is related to a different set of factors than
those associated with the
initial functional design itself. Here, the predominant issues are
reliability, form and fi t,
compatibility with the operational environment, maintainability,
producibility, testabil-
ity, safety, and cost, along with the requirement that product
design does not violate
the integrity of the functional design. The depth of the systems
engineer ’ s understanding

of the design of individual components needs to extend to the
place where the system -
level signifi cance of these factors may be understood, and any
risks, confl icts, and other
potential problems addressed.
The required extent and nature of such knowledge varies
widely according to the
type of system and its constitution. A systems engineer dealing
with an information
system can expect to concentrate largely on the details of the
software and user aspects
of the system while considering mainly the external aspects of
the hardware compo-
nents, which are usually standard (always paying special
attention to component inter-
faces). At another extreme, an aerospace system such as an
airplane consists of a
complex and typically nonstandard assemblage of hardware and
software operating in
a highly dynamic and often adverse environment. Accordingly,
an aerospace systems
engineer needs to be knowledgeable about the design of system
components to a con-
siderably more detailed level so as to be aware of the
potentially critical design features
before they create reliability, producibility, or other problems
during the product engi-
neering, test, and operational stages.
Common Building Blocks
An important and generally unrecognized observation resulting
from an examination
of the hierarchical structure of a large variety of systems is the
existence of an inter-

mediate level of elements of types that recur in a variety of
systems. Devices such as
c03.indd 48c03.indd 48 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM
signal receivers, data displays, torque generators, containers,
and numerous others
perform signifi cant functions used in many systems. Such
elements typically constitute
product lines of commercial organizations, which may confi
gure them for the open
market or customize them to specifi cations to fi t a complex
system. In Table 3.1 , the
above elements are situated at the third or middle level and are
referred to by the generic
name component.
The existence of a distinctive set of middle - level system
building blocks can be
seen as a natural result of the conditions discussed in Chapter 1
for the origin of
complex systems, namely, (1) advancing technology, (2)
competition, and (3) special-
ization. Technological advances are generally made at basic
levels, such as the develop-
ment of semiconductors, composite materials, light - emitting
devices, graphic user
TA B L E 3.3. Component Design Elements
Category Component Functional element(s)

Electronic Receiver
Transmitter
Data processor
Signal processor
Communications processors
Special electronic equipment
Receive signal
Transmit signal
Process data
Process signal
Process signal/data
Various
Electro - optical Optical sensing device
Optical storage device
Display device
High - energy optics device
Optical power generator
Input signal
Store data
Output signal/data
Form material
Electromechanical Inertial instrument
Electric generator
Data storage device
Transducer
Data input/output device
Input data
Store data

Transduce signal
Input/output data
Mechanical Framework
Container
Material processing machine
Material reactor
Power transfer device
Support material
Store material
Form/join material
React material
Control motion
Thermomechanical Rotary engine
Jet engine
Heating unit
Cooling unit
Special energy source
Generate torque
Generate thrust
Control temperature
Control temperature
Software Operating system
Application
Support software
Firmware
Control system
Control processing
Control processing
Control system

c03.indd 49c03.indd 49 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM
interfaces, and so on. The fact of specialization tends to apply
such advances primarily
to devices that can be designed and manufactured by people and
organizations special-
ized in certain types of products. Competition, which drives
technology advances, also
favors specialization in a variety of specifi c product lines. A
predictable result is the
proliferation of advanced and versatile products that can fi nd a
large market (and hence
achieve a low cost) in a variety of system applications. The
current emphasis in defense
system development on adapting commercial off - the - shelf
(COTS) components, wher-
ever practicable, attempts to capitalize on economies of scale
found in the commercial
component market.
Referring back to Table 3.1 , it is noted that as one moves up
through the hierarchy
of system element levels, the functions performed by those in
the middle or component
level are the fi rst that provide a signifi cant functional
capability, as well as being found
in a variety of different systems. For this reason, the types of
elements identifi ed as
components in the fi gure were identifi ed as basic system
building blocks. Effective

systems engineering therefore requires a fundamental
understanding of both the func-
tional and physical attributes of these ubiquitous system
constituents. To provide a
framework for gaining an elementary knowledge base of system
building blocks, a set
of models has been defi ned to represent commonly occurring
system components. This
section is devoted to the derivation, classifi cation,
interrelationships, and common
examples of the defi ned system building blocks.
Applications of System Building Blocks
The system building block model described above may be
useful in several ways:
1. The categorization of functional elements into the four
classes of signal, data,
material, and energy elements can help suggest what kind of
actions may be
appropriate to achieve required operational outcomes.
2. Identifying the classes of functions that need to be
performed by the system
may help group the appropriate functional elements into
subsystems and thus
may facilitate functional partitioning and defi nition.
3. Identifying the individual functional building blocks may
help defi ne the nature
of the interfaces within and between subsystems.
4. The interrelation between the functional elements and the
corresponding one or
more physical implementations can help visualize the physical

architecture of
the system.
5. The commonly occurring examples of the system building
blocks may suggest
the kinds of technology appropriate to their implementation,
including possible
alternatives.
6. For those specialized in software and unfamiliar with
hardware technology, the
relatively simple framework of four classes of functional
elements and six
classes of physical components should provide an easily
understood organiza-
tion of hardware domain knowledge.
c03.indd 50c03.indd 50 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM
THE SYSTEM ENVIRONMENT 51
3.4 THE SYSTEM ENVIRONMENT
The system environment may be broadly defi ned as everything
outside of the system
that interacts with the system. The interactions of the system
with its environment form
the main substance of system requirements. Accordingly, it is
important at the outset
of system development to identify and specify in detail all of
the ways in which the
system and its environment interact. It is the particular
responsibility of the systems

engineer to understand not only what these interactions are but
also their physical basis,
to make sure that the system requirements accurately refl ect the
full range of operating
conditions.
System Boundaries
To identify the environment in which a new system operates, it
is necessary to identify
the system ’ s boundaries precisely, that is, to defi ne what is
inside the system and what
is outside. Since we are treating systems engineering in the
context of a system devel-
opment project, the totality of the system will be taken as that
of the product to be
developed.
Although defi ning the system boundary seems almost trivial at
fi rst glance, in
practice, it is very diffi cult to identify what is part of the
system and what is part of the
environment. Many systems have failed due to miscalculations
and assumptions about
what is internal and what is external. Moreover, different
organizations tend to defi ne
boundaries differently, even with similar systems.
Fortunately, several criteria are available to assist in
determining whether an entity
should be defi ned as part of a system:
• Developmental Control. Does the system developer
have control over the enti-
ty ’ s development? Can the developer infl uence the
requirements of the entity,

or are requirements defi ned outside of the developer ’ s sphere
of infl uence?
Is funding part of the developer ’ s budget, or is it controlled by
another
organization?
• Operational Control. Once fi elded, will the entity be
under the operational
control of the organization that controls the system? Will the
tasks and missions
performed by the entity be directed by the owner of the system?
Will another
organization have operational control at times?
• Functional Allocation. In the functional defi nition of
the system, is the systems
engineer “ allowed ” to allocate functions to the entity?
• Unity of Purpose. Is the entity dedicated to the system
’ s success? Once fi elded,
can the entity be removed without objection by another entity?
Systems engineers have made mistakes by defi ning entities as
part of the system
when, in fact, the span of control (as understood by the above
criteria) was indeed
small. And typically, either during development or operations,
the entity was not avail-
able to perform its assigned functions or tasks.
c03.indd 51c03.indd 51 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM

One of the basic choices required early is to determine whether
human users or
operators of a system are considered part of the system or are
external entities. In a
majority of cases, the user or operator should be considered
external to the system. The
system developer and owner rarely have suffi cient control over
operators to justify their
inclusion in the system. When operators are considered external
to the system, the
systems engineer and the developer will focus on the operator
interface, which is critical
to complex systems.
From another perspective, most systems cannot operate without
the active partici-
pation of human operators exercising decision and control
functions. In a functional
sense, the operators may well be considered to be integral parts
of the system. However,
to the systems engineer, the operators constitute elements of the
system environment
and impose interface requirements that the system must be
engineered to accommodate.
Accordingly, in our defi nition, the operators will be considered
to be external to the
system.
As noted earlier, many, if not most, complex systems can be
considered as parts
of larger systems. An automobile operates on a network of roads
and is supported by
an infrastructure of service stations. However, these are not
changed to suit a new
automobile. A spacecraft must be launched from a complex

gantry, which performs the
fueling and fl ight preparation functions. The gantry, however,
is usually a part of the
launch complex and not a part of the spacecraft ’ s
development. In the same manner,
the electrical power grid is a standard source of electricity,
which a data processing
system may utilize. Thus, the supersystems identifi ed in the
above examples need not
be considered in the engineering process as part of the system
being developed but as
an essential element in its operational environment, and to the
extent required to assure
that all interfacing requirements are correctly and adequately
defi ned.
Systems engineers must also become involved in interface
decisions affecting
designs both of their own and of an interfacing system. In the
example of a spacecraft
launched from a gantry, some changes to the information
handling and perhaps other
functions of the gantry may well be required. In such instances,
the defi nition of
common interfaces and any associated design issues would need
to be worked out with
engineers responsible for the launch complex.
System Boundaries: The Context Diagram
An important communications tool available to the systems
engineer is the context
diagram. This tool effectively displays the external entities and
their interactions with
the system and instantly allows the reader to identify those
external entities. Figure 3.2

shows a generic context diagram. This type of diagram is known
as a black box diagram
in that the system is represented by a single geographic fi gure
in the center, without
any detail. Internal composition or functionality is hidden from
the reader. The diagram
consists of three components:
1. External Entities. These constitute all entities in which
the system will interact.
Many of these entities can be considered as sources for inputs
into the system
and destinations of outputs from the system.
c03.indd 52c03.indd 52 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM
2. Interactions. These represent the interactions between
the external entities and
the system and are represented by arrows. Arrowheads represent
the direction
or fl ow of a particular interaction. While double - headed
arrows are allowed,
single - headed arrows communicate clearer information to the
reader. Thus, the
engineer should be careful when using two - directional
interactions — make sure
the meanings of your interactions are clear. Regardless, each
interaction (arrow)
is labeled to identify what is being passed across the interface.
The diagram depicts the common types of interactions that a

context diagram typi-
cally contains. In an actual context diagram, these interactions
would be labeled with
the specifi c interactions, not the notional words used above.
The labels need to be suf-
fi ciently detailed to communicate meaning, but abstract enough
to fi t into the diagram.
Thus, words such as “ data ” or “ communications ” are to be
avoided in the actual
diagram since they convey little meaning.
3. The System. This is the single geographic fi gure
mentioned already. Typically,
this is an oval, circle, or rectangle in the middle of the fi gure
with only the name
of the system within. No other information should be present.
We can categorize what can be passed across these external
interfaces by utilizing
our defi nitions of the four basic elements above. Using these
elements and adding one
additional element, we can form fi ve categories:
• data,
• signals,
• materials,
• energy, and
• activities.
Figure 3.2. Context diagram.
External

Entity
External
Entity
Activity
Materials
Data
Data
The System
External
Materials
Entity
Activity Data
External External
Energy Data Signals
Entity Entity
c03.indd 53c03.indd 53 2/8/2011 11:04:34 AM2/8/2011
11:04:34 AM
Thus, a system interacts with its environment (and specifi
cally, the external enti-
ties) by accepting and providing either one of the fi rst four

elements or by performing
an activity that infl uences the system or the environment in
some manner.
Constructing a diagram such as the system context diagram can
be invaluable in
communicating the boundary of the system. The picture clearly
and easily identifi es
the external interfaces needed and provides a short description
of what is being passed
into and out of the system — providing a good pictorial of the
system ’ s inputs and
outputs.
Figure 3.3 provides a simple example using a typical
automobile as the system.
Although the system is rather simple, it nicely illustrates all fi
ve types of interfaces.
Four external entities are identifi ed: users (to include the driver
and passengers), the
maintainer (which could be a user, but, because of his
specialized interactions with the
system, is listed separately), an energy source, and the
environment. Most systems will
interact with these four external entity types. Of course, many
other entities may interact
with a system as well.
The user provides a multitude of inputs to the system,
including various commands
and controls as well as actions, such as steering and braking.
Materials are also passed
to the system: cargo. In return, several outputs are passed from
the automobile back to
the user, including various status indications on the state of the
system. Additionally,

an activity is performed: entertainment, representing the various
forms of entertainment
available in today ’ s automobile. Finally, cargo is returned to
the users when desired.
Other entities also interact with the system. The maintainer
must provide a request
for diagnostics data, typically in the form of signals passed to
the auto via an interface.
Diagnostics data are returned along with the exchange of parts.
Figure 3.3. Context diagram for an automobile.
• Status of Auto. States
Users Maintainer
• Entertainment
• Temperature-Controlled Air
• Cargo
• Steering
• Braking
• Parts
• Request Signals
• Acceleration
• Light Commands
• Window Commands
• Diagnostics Data
• Worn-Out parts
Automobile• Horn Activation
• Security Commands

• Temperature Controls
• Entertainment Controls • Support
• Cargo
•
• Resistance
• Weather
Energy
Source
Environment
Gasoline • Heat
• Siren
• Exhaust•
• Light
c03.indd 54c03.indd 54 2/8/2011 11:04:35 AM2/8/2011
11:04:35 AM
The last two external entities represent somewhat specialized
entities: an energy
source and the ubiquitous environment. In the automobile case,
the energy source
provides gasoline to the automobile. This energy source can be
one of many types: a
gasoline pump at a station or a small container with a simple
nozzle. The environment
requires some special consideration, if for no other reason than
it includes everything

not specifi cally contained in the other external entities. So, in
some respects, the envi-
ronment entity represents “ other. ” In our example, the
automobile will generate heat
and exhaust in its typical operation. Additionally, a siren and
light from various light
bulbs, horns, and signals will also radiate from the auto. The
environment is also a
source of many inputs, such as physical support, air resistance,
and weather.
It takes some thought to identify the inputs, outputs, and
activities that are part of
the system – environment interaction. The creator of this
diagram could have really gone
“ overboard ” and specifi ed temperature, pressure, light,
humidity, and a number of other
factors in this interaction. This brings up an interesting
question: what do we include
in listing the interactions between the system and the external
entity? For that matter,
how do we know whether an external entity should be included
in our diagram?
Fortunately, there is a simple answer to this: if the interaction is
important for the design
of the system, then it should be included.
In our automobile case, physical support is important for our
design and will infl u-
ence the type of transmission, steering, and tires. So we include
“ support ” in our
diagram. Temperature, humidity, pressure, and so on, will be a
factor, but we are not
sure about their importance to design, so we group these
characteristics under “ weather. ”
This does not mean that the automobile will be designed for all

environmental condi-
tions, only that we are not considering all conditions in our
design. We should have an
idea of the environmental conditions from the requirements, and
therefore, we can
determine whether they should be in our context diagram.
Output from the system to the environment also depends on
whether it will infl u-
ence the design. The automobile will in fact output many things
into the environment:
heat, smells, texture, colors … and especially carbon dioxide
as part of the exhaust!
But which of these infl uence our design? Four will be major
infl uences: heat, noise
from the siren, exhaust, and light. Therefore, we include only
those for now and omit
the others. We can always go back and update the context
diagram (in fact, we should,
as we progress through both the systems engineering process
and the system develop-
ment life cycle).
The system context diagram is a very simple yet powerful tool
to identify, evaluate,
and communicate the boundaries of our system. Therefore, it
becomes the fi rst tool we
introduce in this book. More will follow that will eventually
provide the systems engi-
neer with the collection needed to adequately develop his
system.
Types of Environmental Interactions
To understand the nature of the interactions of a system with
its surroundings, it is

convenient to distinguish between primary and secondary
interactions. The former
involves elements that interact with the system ’ s primary
functions, that is, represent
functional inputs, outputs, and controls; the latter relates to
elements that interact with
c03.indd 55c03.indd 55 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM
the system in an indirect nonfunctional manner, such as
physical supports, ambient
temperature, and so on. Thus, the functional interactions of a
system with its environ-
ment include its inputs and outputs and human control
interfaces. Operational mainte-
nance may be considered a quasi - functional interface. Threats
to the system are those
entities that deny or disrupt the system ’ s ability to perform its
activities. The physical
environment includes support systems, system housing, and
shipping, handling, and
storage. Each of these is briefl y described below.
Inputs and Outputs. The primary purpose of most systems is
to operate on
external stimuli and/or materials in such a manner as to process
these inputs in a useful
way. For a passenger aircraft, the materials are the passengers,
their luggage, and fuel,
and the aircraft ’ s function is to transport the passengers and
their belongings to a distant

destination rapidly, safely, and comfortably. Figure 3.4
illustrates some of the large
Figure 3.4. Environments of a passenger airliner. ILS,
instrument landing system.
Flight Com
mands
Beacon Interrogation
Flight Environment
Landing Environment
People and Payload
Interface
Maintenance Environment
Support Environment
TurbulenceRain
ILS Beacon
Power
Fuel
Shock and Vibration
Passengers
Luggage
Winds

c03.indd 56c03.indd 56 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM
variety of interactions that a complex system has with its
operating environment for
the case of a passenger aircraft.
System Operators. As noted previously, virtually all
systems, including auto-
mated systems, do not operate autonomously but are controlled
to some degree by
human operators in performing their function. For the purposes
of defi ning the systems
engineer ’ s task, the operator is part of the system ’ s
environment. The interface between
the operator and the system (human – machine interface) is one
of the most critical of all
because of the intimate relationship between the control
exercised by the operator and
the performance of the system. It is also one of the most
complex to defi ne and test.
Operational Maintenance. The requirements for system
readiness and opera-
tional reliability relate directly to the manner in which it is to
be maintained during its
operating life. This requires that the system be designed to
provide access for monitor-
ing, testing, and repair requirements that are frequently not
obvious at the outset, but
nevertheless must be addressed early in the development

process. Thus, it is necessary
to recognize and explicitly provide for the maintenance
environment.
Threats. This class of external entities can be man - made or
natural. Clearly,
weather could be considered a threat to a system exposed to the
elements. For example,
when engineering naval systems, the salt water environment
becomes a corrosive
element that must be taken into consideration. Threats can also
be man - made. For
example, a major threat to an automatic teller machine (ATM)
would be the thief, whose
goal might be access to the stored cash. System threats need to
be identifi ed early to
design countermeasures into the system.
Support Systems. Support systems are that part of the
infrastructure on which
the system depends for carrying out its mission. As illustrated
in Figure 3.4 , the airport,
the air traffi c control system, and their associated facilities
constitute the infrastructure
in which an individual aircraft operates, but which is also
available to other aircraft.
These are parts of the SoS represented by the air transportation
system, but for an
airplane, they represent standard available resources with which
it rousts interface
harmoniously.
Two examples of common support systems that have been
mentioned previously
are the electric power grids, which distribute usable electric
power throughout the civi-

lized world, and the network of automobile fi lling stations and
their suppliers. In build-
ing a new airplane, automobile, or other systems, it is necessary
to provide interfaces
that are compatible with and capable of utilizing these support
facilities.
System Housing. Most stationary systems are installed in an
operating site,
which itself imposes compatibility constraints on the system. In
some cases, the instal-
lation site provides protection for the system from the elements,
such as variations in
temperature, humidity, and other external factors. In other
cases, such as installations
on board ship, these platforms provide the system ’ s
mechanical mounting but, other-
wise, may expose the system to the elements, as well as subject
it to shock, vibration,
and other rigors.
c03.indd 57c03.indd 57 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM
Shipping and Handling Environment. Many systems require
transport from
the manufacturing site to the operating site, which imposes
special conditions for which
the system must be designed. Typical of these are extreme
temperatures, humidity,
shock, and vibration, which are sometimes more stressful than
those characteristic of

the operating environment. It may be noted that the impact of
the latter categories of
environmental interactions is addressed mainly in the
engineering development stage.
3.5 INTERFACES AND INTERACTIONS
Interfaces: External and Internal
The previous section described the different ways in which a
system interacts with its
environment, including other systems. These interactions all
occur at various boundar-
ies of the system. Such boundaries are called the system ’ s
external interfaces . Their
defi nition and control are a particular responsibility of the
systems engineer because
they require knowledge of both the system and its environment.
Proper interface control
is crucial for successful system operation.
A major theme of systems engineering is accordingly the
management of inter-
faces. This involves
1. identifi cation and description of interfaces as part of
system concept defi nition
and
2. coordination and control of interfaces to maintain system
integrity during engi-
neering development, production, and subsequent system
enhancements.
Inside the system, the boundaries between individual
components constitute the

system ’ s internal interfaces . Here, again, the defi nition of
internal interfaces is the
concern of the systems engineer because they fall between the
responsibility boundaries
of engineers concerned with the individual components.
Accordingly, their defi nition
and implementation must often include consideration of design
trade - offs that impact
on the design of both components.
Interactions
Interactions between two individual elements of the system are
effected through the
interface connecting the two. Thus, the interface between a car
driver ’ s hands and the
steering wheel enables the driver to guide (interact with) the car
by transmitting a force
that turns the steering wheel and thereby the car ’ s wheels. The
interfaces between the
tires of the car and the road both propel and steer the car by
transmitting driving trac-
tion to the road, and also help cushion the car body from the
roughness of the road
surface.
The above examples illustrate how functional interactions
(guiding or propelling
the car) are effected by physical interactions (turning the
steering wheel or the drive
wheels) that fl ow across (physical) interfaces. Figure 3.5
illustrates the similar relations
c03.indd 58c03.indd 58 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM

INTERFACES AND INTERACTIONS 59
between physical interfaces involved in steering an air vehicle
and the resulting func-
tional interactions.
An important and sometimes less than adequately addressed
external system inter-
action occurs during system maintenance. This activity
necessarily requires access to
a number of vital system functions for testing purposes. Such
access calls for the provi-
sion of special test points of the system, which can be sampled
externally with a
minimum of manipulation. In some complex systems, an
extensive set of built - in tests
(BITs) is incorporated, which may be exercised while the
system is in its operational
status. The defi nition of such interfaces is also the concern of
the systems engineer.
Interface Elements
To systematize the identifi cation of external and internal
interfaces, it is convenient to
distinguish three different types:
1. connectors, which facilitate the transmission of
electricity, fl uid, force, and so
on, between components;
2. isolators, which inhibit such interactions; and
3. converters, which alter the form of the interaction

medium. These interfaces are
embodied in component parts or subcomponents, which can be
thought of as
interface elements.
Table 3.4 lists a number of common examples of interface
elements of each of the
three types, for each of four interaction media: electrical,
mechanical, hydraulic, and
human. The table brings out several points worthy of note:
Figure 3.5. Functional interactions and physical
interfaces.
Aileron
Aileron
Drive motor
Radio-controlled air vehicle
Receiver/decoder
Controller/encoder
Transmitter Antenna
Power
amp
Aileron
deflection
Aileron
deflection

command
Aileron deflection = 3 deg. per deg. of stick motion
Function
Functional interaction
Physicl interfaces
Move
Aileron
c03.indd 59c03.indd 59 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM
1. The function of making or breaking a connection between
two components (i.e.,
enabling or disabling an interaction between them) must be
considered as an
important design feature, often involved in system control.
2. The function of connecting nonadjacent system
components by cables, pipes,
levers, and so on, is often not part of a particular system
component. Despite
their inactive nature, such conducting elements must be given
special attention
at the system level to ensure that their interfaces are correctly
confi gured.
3. The relative simplicity of interface elements belies their

critical role in ensuring
system performance and reliability. Experience has shown that a
large fraction
of system failures occurs at interfaces. Assuring interface
compatibility and
reliability is a particular responsibility of the systems engineer.
3.6 COMPLEXITY IN MODERN SYSTEMS
Earlier in the chapter, we described the system hierarchy —
how systems are subdivided
into subsystems, then components, subcomponents, and fi nally,
parts (see Table 3.1 ).
And as modern systems grow in complexity, the number,
diversity, and complexity of
these lower - level subsystems, components, and parts increase.
Furthermore, the interac-
tions between these entities also increase in complexity.
Systems engineering princi-
ples, and their applied practices, are designed to deal with this
complexity.
Increasingly, a single system may be, or become, a part of a
larger entity. While
there are many terms currently in use today to describe this
supersystem concept, the
term SoS seems to be accepted by a wide variety of
organizations. Other terms are
found in the literature — some meaning the same thing, some
having different
connotations.
This section provides a basic introduction to the engineering of
entities that are
considered “ above, ” or more complex, than single systems:
SoSs and enterprises.

S o S
For our purposes, we will use two defi nitions to describe what
is meant by an SoS.
Both come from the U.S. Department of Defense (DoD). The fi
rst is the simplest:
TA B L E 3.4. Examples of Interface Elements
Type Electrical Mechanical Hydraulic Human –
machine
Interaction
medium
Current Force Fluid Information
Connectors Cable switch Joint coupling Pipe valve
Display control panel
Isolator RF shield
insulator
Shock mount
bearing
Seal Cover window
Converter Antenna A/D
converter
Gear train
piston
Reducing
valve pump

Keyboard
c03.indd 60c03.indd 60 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM
COMPLEXITY IN MODERN SYSTEMS 61
A set or arrangement of systems that results when independent
and useful systems are
integrated into a larger system that delivers unique capabilities
In essence, anytime a set of independently useful systems is
integrated together to
provide an enhanced capability beyond that of the sum of the
individual systems ’ capa-
bilities, we have an SoS. Of course, the level of integration
could vary signifi cantly. At
one end of the spectrum, an SoS could be completely integrated
from the earliest
development phases, where the individual systems, while able to
operate independently,
are almost exclusively designed for the SoS. At the other end of
the spectrum, multiple
systems could be loosely joined for a limited purpose and time
span to perform a needed
mission, with no more than an agreement of the owners of each
system. Thus, a method
to capture this range of integration is necessary to fully describe
the different nuances
of SoSs.
The U.S. DoD produced a systems engineering guide in 2008
specifi cally for SoS

environments and captured this spectrum using four categories.
The categories are
presented in the order of how tightly coupled the component
systems are — from loosely
to tightly.
• Virtual. Virtual SoSs lack a central management
authority and a centrally agreed -
upon purpose for the SoS. Large - scale behavior emerges —
and may be desirable —
but this type of SoS must rely upon relatively invisible
mechanisms to maintain
it.
• Collaborative. In collaborative SoSs, the component
systems interact more or
less voluntarily to fulfi ll agreed - upon central purposes.
Standards are adopted,
but there is no central authority to enforce them. The central
players collectively
decide how to provide or deny service, thereby providing some
means of enforc-
ing and maintaining standards.
• Acknowledged. Acknowledged SoSs have recognized
objectives, a designated
manager, and resources for an SoS; however, the constituent
systems retain
their independent ownership, objectives, funding, development
and sustainment
approaches. Changes in the systems are based on collaboration
between the SoS
and the system.
• Directed. Directed SoSs are those in which the
integrated SoS is built and

managed to fulfi ll specifi c purposes. It is centrally managed
during long - term
operation to continue to fulfi ll those purposes as well as any
new ones the system
owners might wish to address. The component systems maintain
an ability to
operate independently, but their normal operational mode is
subordinated to the
central managed purpose.
Although one could argue that the last category, the directed
SoS, is closer to a
single, complex system than an SoS, the defi nitions capture the
range of situations that
exist today when systems are integrated together to perform a
function, or exhibit a
capability, that is greater than any one system.
As the reader might surmise, engineering and architecting an
SoS can be different
than engineering and architecting a single system, especially for
the two middle
c03.indd 61c03.indd 61 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM
categories. System of systems engineering (SoSE) can be
different because of the
unique attributes of an SoS.
Maier fi rst introduced a formal discussion of SoSs by
identifying their character-

istics in 1998. Since then, several publications have refi ned
these characteristics;
however, they have remained remarkably stable over time. Sage
and Cuppan summa-
rized these characteristics:
1. Operational Independence of the Individual System.
An SoS is composed of
systems that are independent and useful in their own right. If an
SoS is disas-
sembled into its associated component systems, these
component systems are
capable of independently performing useful operations
independently of one
another.
2. Managerial Independence of the Individual System.
The component systems in
an SoS not only can operate independently, but they also
generally do operate
independently to achieve an intended purpose. Often, they are
individually
acquired and integrated, and they maintain a continuing
operational existence
and serve purposes that may be independent of those served by
the SoS.
3. Geographic Distribution. The geographic dispersion of
component systems is
often large. Often, these systems can readily exchange only
information and
knowledge with one another.
4. Emergent Behavior. The SoS performs functions and
carries out purposes that
are not necessarily associated with any component system.

These behaviors are
emergent properties of the entire SoS and not the behavior of
any component
system.
5. Evolutionary Development. The development of an
SoS is generally evolution-
ary over time. Components of structure, function, and purpose
are added,
removed, and modifi ed as experience with the system grows
and evolves over
time. Thus, an SoS is usually never fully formed or complete.
These characteristics have since been refi ned to include
additional characteristics.
Although these refi nements have not changed the basic
characteristics, they did add
two important features:
6. Self - organization. An SoS will have a dynamic
organizational structure that is
able to respond to changes in the environment and to changes in
goals and
objectives for the SoS.
7. Adaptation. Similar to a dynamic organization, the very
structure of the SoS
will be dynamic and respond to external changes and
perceptions of the
environment.
Engineering an SoS that falls into either the collaborative or
acknowledged cate-
gory must deal with the seven core attributes of SoS. Therefore,
the basic tools that we
have in systems engineering may not be suffi cient. Additional

methods, tools, and
practices have been developed (and are continuing to be
developed) to enable the
engineer to develop these complex structures.
c03.indd 62c03.indd 62 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM
COMPLEXITY IN MODERN SYSTEMS 63
Some of these tools come from other branches of mathematics
and engineering, such
as complexity theory. Attributes such as emergent behavior, self
- organization, and adap-
tation have been examined within this fi eld, and various tools
and methods have been
developed to represent the inherent uncertainty these attributes
bring. The challenge is
to keep the mathematics simple enough for application to
Other areas that are being examined to support SoSE include
social engineering,
human behavior dynamics, and chaotic systems (chaos theory).
These areas continue
to be appropriate for further research.
Enterprise Systems Engineering
SoSE, by its nature, increases the complexity of developing
single systems. However,
it does not represent the highest level of complexity. In fact,
just as Table 3.1 presented
a hierarchy with the system at the apex, we can expand this

hierarchy, and go beyond
SoSs, to an enterprise. Figure 3.6 depicts this hierarchy.
Above an SoS lies the enterprise, which typically consists of
multiple SoSs within
its structure. Furthermore, an enterprise may consist of a varied
collection of system
types, not all of which are physical. For instance, an enterprise
includes human or social
systems that must be integrated with physical systems.
Formally, an enterprise is “ anything that consists of people,
processes, technology,
systems, and other resources across organizations and locations
interacting with each
other and their environment to achieve a common mission or
goal. ” The level of inter-
action between these entities varies, just as component systems
within an SoS. And
many entities fi t into this defi nition. Almost all midsize to
large organizations would
satisfy this defi nition. In fact, suborganizations of some large
corporations would them-
selves be defi ned as an enterprise.
Government agencies and departments would also fi t into this
defi nition. And
fi nally, large social and physical structures, such as cities or
nations, satisfy the
defi nition.
Figure 3.6. Pyramid of system hierarchy.
Enterprise
Systems

Systems of Systems
Subsystem
Components
c03.indd 63c03.indd 63 2/8/2011 11:04:36 AM2/8/2011
11:04:36 AM
The source of complexity in enterprise systems engineering is
primarily the inte-
gration of a diversity of systems and processes. The enterprise
typically includes the
following components that must be integrated together under the
inherent uncertainty
of today ’ s enterprise:
• business strategy and strategic planning,
• business processes,
• enterprise services,
• governance,
• technical processes,
• people management and interactions,
• knowledge management,

• information technology infrastructure and investment,
• facility and equipment management,
• supplies management, and
• data and information management.
Enterprise systems engineering refers to the application of
systems engineering
principles and practices to engineering systems that are part of
an enterprise. Developing
the individual component systems of the enterprise is known by
this term. Another
broader term has also emerged: enterprise engineering. This
term, with the “ systems ”
omitted, typically refers to the architecting, development,
implementation, and opera-
tion of the enterprise as a whole. Some have used the terms
interchangeably; however,
the two terms refer to different levels of abstraction.
The reason that enterprise systems engineering is deemed more
complex than SoSE
is that many of the components of an enterprise involve one or
more SoSs. Therefore,
the enterprise could be considered an integration of multiple
SoSs.
Just as new tools and techniques are being developed for SoSE
applications,
so too are tools, methods, and techniques being developed for
this relatively young
fi eld.
3.7 SUMMARY

System Building Blocks and Interfaces
The need for a systems engineer to attain a broad knowledge of
the several interacting
disciplines involved in the development of a complex system
raises the question of how
deep that understanding needs to be.
Hierarchy of Complex Systems
Complex systems may be represented by a hierarchical
structure in that they are com-
posed of subsystems, components, subcomponents, and parts.
c03.indd 64c03.indd 64 2/8/2011 11:04:37 AM2/8/2011
11:04:37 AM
SUMMARY 65
The domain of the systems engineer extends down through the
component level
and extends across several categories. In contrast, the domain of
the design specialist
extends from the part level up through the component level, but
typically within a single
technology area or discipline.
System Building Blocks
System building blocks are at the level of components and are
the basic building blocks
of all engineered systems characterized by both functional and
physical attributes.

These building blocks are characterized by performing a distinct
and signifi cant func-
tion and are singular — they are within the scope of a single
engineering discipline.
Functional elements are functional equivalents of components
and are categorized
into four classes by operating medium:
• signal elements, which sense and communicate
information;
• data elements, which interpret, organize, and manipulate
information;
• material elements, which provide structure and process
material; and
• energy elements, which provide energy or power.
Components are the physical embodiment of functional
elements, which are cat-
egorized into six classes by materials of construction:
• electronic,
• electro - optical,
• electromechanical,
• mechanical,
• thermomechanical, and
• software.

System building block models can be useful in identifying
actions capable of
achieving operational outcomes, facilitating functional
partitioning and defi nition, iden-
tifying subsystem and component interfaces, and visualizing the
physical architecture
of the system.
The System Environment
The system environment, that is, everything outside the system
that interacts with it,
includes (1) system operators (part of system function but
outside the delivered system);
(2) maintenance, housing, and support systems; (3) shipping,
storage, and handling; (4)
weather and other physical environments; and (5) threats.
Interfaces and Interactions
Interfaces are a critical systems engineering concern, which
effect interactions between
components and can be classifi ed into three categories:
connect, isolate, or convert
c03.indd 65c03.indd 65 2/8/2011 11:04:37 AM2/8/2011
11:04:37 AM
interactions. They require identifi cation, specifi cation,
coordination, and control.
Moreover, test interfaces typically are provided for integration
and maintenance.

Complexity in Modern Systems
Each system is always part of a larger entity. At times, this
larger entity can be classi-
fi ed as a separate system in itself (beyond simply an
environment, or “ nature ” ). These
situations are referred to as “ SoSs. ” They tend to exhibit
seven distinct characteristics:
operational independence of the individual system, managerial
independence of the
individual system, geographic distribution, emergent behavior,
evolutionary develop-
ment, self - organization, and adaptation.
Enterprise systems engineering is similar in complexity but
focuses on an organi-
zational entity. Since an enterprise involves social systems as
well as technical systems,
the complexity tends to become unpredictable.
PROBLEMS
3.1 Referring to Table 3.1 , list a similar hierarchy
consisting of a typical subsys-
tem, component, subcomponent, and part for (1) a terminal air
traffi c control
system, (2) a personal computer system, (3) an automobile, and
(4) an electric
power plant. For each system, you need only to name one
example at each
level.
3.2 Give three key activities of a systems engineer that
require technical knowl-
edge down to the component level. Under what circumstances

should the
systems engineer need to probe into the subcomponent level for
a particular
system component?
3.3 Referring to Figure 3.1 , describe in terms of levels in
the system hierarchy
the knowledge domain of a design specialist. In designing or
adapting a
component for a new system, what typical characteristics of the
overall
system and of other components must the design specialist
understand?
Illustrate by an example.
3.4 The last column of Table 3.2 lists examples of the
applications of the 23
functional elements. List one other example of an application
than the one
listed for three elements in each of the four classes of elements.
3.5 Referring to Figure 3.4 , for each of the environments
and interfaces illus-
trated, (1) list the principal interactions between the
environment and the
aircraft, (2) the nature of each interaction, and (3) describe how
each affects
the system design.
3.6 For a passenger automobile, partition the principal parts
into four subsystems
and their components. (Do not include auxiliary functions such
as environ-
mental or entertainment.) For the subsystems, group together
components
concerned with each primary function. For defi ning the

components, use the
principles of signifi cance (performs an important function),
singularity
c03.indd 66c03.indd 66 2/8/2011 11:04:37 AM2/8/2011
11:04:37 AM
FURTHER READING 67
(largely falls within a simple discipline), and commonality
(found in a variety
of system types). Indicate where you may have doubts. Draw a
block diagram
relating the subsystems and components to the system and to
each other.
3.7 In the cases selected in answering Problem 3.5, list the
specifi c component
interfaces that are involved in the above interactions.
3.8 Draw a context diagram for a standard coffeemaker.
Make sure to identify
all of the external entities and label all of the interactions.
3.9 Draw a context diagram for a standard washing
machine. Make sure to iden-
tify all of the external entities and label all of the interactions.
3.10 In a context diagram, “ maintainer ” is typically an
external entity, providing
both activities (i.e., “ maintenance ” ) and materials (e.g., spare
parts) to the
system, and the system providing diagnostic data back to the
maintainer.

Describe the nature of the maintainer interfaces and what
interactions could
be done by the user.
3.11 List the test interfaces and BIT indicators in your
automobile that are avail-
able to the user (do not include those only available to a
mechanic).
FURTHER READING
D. Buede . The Engineering Design of Systems: Models
and Methods , Second Edition , John Wiley
& Sons , 2009 .
Department of Defense . Systems Engineering Guide for
Systems of Systems . DUSD (A & T) and
OSD (AT & L) , 2008 .
M. Jamshidi , ed. System of Systems Engineering:
Innovations for the 21st Century . John Wiley
& Sons , 2008 .
M. Jamshidi , ed. Systems of Systems Engineering:
Principles and Applications . CRC Press , 2008 .
M. Maier and E. Rechtin . The Art of Systems
Architecting . CRC Press , 2009 .
A. Sage and S. Biemer . Processes for system family
architecting, design and integration . IEEE
Systems Journal , 2007 , 1 ( 1 ), 5 – 16 .
A. Sage and C. Cuppan . On the systems engineering
and management of systems of systems and
federations of systems . Information Knowledge Systems

Management , 2001 , 2 ( 4 ), 325 – 345 .
c03.indd 67c03.indd 67 2/8/2011 11:04:37 AM2/8/2011
11:04:37 AM
c03.indd 68c03.indd 68 2/8/2011 11:04:37 AM2/8/2011
11:04:37 AM
69
4.1 SYSTEMS ENGINEERING THROUGH THE SYSTEM
LIFE CYCLE
As was described in Chapter 1 , modern engineered systems
come into being in response
to societal needs or because of new opportunities offered by
advancing technology, or
both. The evolution of a particular new system from the time
when a need for it is
recognized and a feasible technical approach is identifi ed,
through its development and
introduction into operational use, is a complex effort, which
will be referred to as the
system development process . This chapter is devoted to
describing the basic system
development process and how systems engineering is applied at
each step of this
process.
A typical major system development exhibits the following

characteristics:
• It is a complex effort.
• It meets an important user need.
• It usually requires several years to complete.
• It is made up of many interrelated tasks.
4
THE SYSTEM
DEVELOPMENT PROCESS
Wiley & Sons, Inc.
c04.indd 69c04.indd 69 2/8/2011 11:04:39 AM2/8/2011
11:04:39 AM
70 THE SYSTEM DEVELOPMENT PROCESS
• It involves several different disciplines.
• It is usually performed by several organizations.
• It has a specifi c schedule and budget.
The development and introduction into the use of a complex
system inherently

requires increasingly large commitments of resources as it
progresses from concept
through engineering, production, and operational use. Further,
the introduction of new
technology inevitably involves risks, which must be identifi ed
and resolved as early as
possible. These factors require that the system development be
conducted in a step - by -
step manner, in which the success of each step is demonstrated,
and the basis for the
next one validated, before a decision is made to proceed to the
next step.
4.2 SYSTEM LIFE CYCLE
The term “ system life cycle ” is commonly used to refer to
the stepwise evolution of
a new system from concept through development and on to
production, operation, and
ultimate disposal. As the type of work evolves from analysis in
the early conceptual
phases to engineering development and testing, to production
and operational use,
the role of systems engineering changes accordingly. As noted
previously, the organiza-
tion of this book is designed to follow the structure of the
system life cycle, so as to
more clearly relate systems engineering functions to their roles
in specifi c periods
during the life of the system. This chapter presents an overview
of the system develop-
ment process to create a context for the more detailed
discussion of each step in the
later chapters.
Development of a Systems Engineering Life Cycle Model

for This Book
System life cycle models have evolved signifi cantly over the
past two decades.
Furthermore, the number of models has grown as additional
unique and custom applica-
tions were explored. Additionally, software engineering has
spawned a signifi cant
number of development models that have been adopted by the
systems community. The
end result is that there is no single life cycle model that (1) is
accepted worldwide and
(2) fi ts every possible situation. Various standards
organizations, government agencies,
and engineering communities have published their particular
models or frameworks
that can be used to construct a model. Therefore, adopting one
model to serve as an
appropriate framework for this book was simply not prudent.
Fortunately, all life cycle models subdivide the system life into
a set of basic steps
that separate major decision milestones. Therefore, the
derivation of a life cycle model
to serve as an appropriate framework for this book had to meet
two primary objectives.
First, the steps in the life cycle had to correspond to the
progressive transitions in the
principal systems engineering activities. Second, these steps had
to be capable of being
mapped into the principal life cycle models in use by the
systems engineering com-
munity. The derived model will be referred to as the “ systems
engineering life cycle, ”
c04.indd 70c04.indd 70 2/8/2011 11:04:39 AM2/8/2011

11:04:39 AM
SYSTEM LIFE CYCLE 71
and will be based on three different sources: the Department of
Defense (DoD)
Acquisition Management model (DoD 5000.2), the International
model ISO/IEC 15288,
and the National Society of Professional Engineers (NSPE)
model.
D o D Acquisition Management Model. In the second
half of the twentieth
century, the United States was in the forefront of developing
large - scale complex mili-
tary systems such as warships, airplanes, tanks, and command
and control systems. To
manage the risks in the application of advanced technology, and
to minimize costly
technical or management failures, the DoD has evolved
comprehensive system acquisi-
tion guidelines, which are contained in the DoD 5000 series of
directives. The fall 2008
version of the DoD life cycle model, which refl ects the
acquisition guidelines, is dis-
played in Figure 4.1 . It consists of fi ve phases: material
solution analysis, technology
development, engineering and manufacturing development,
production and deploy-
ment, and operations and support. The two activities of user
need determination and
technology opportunities and resources are considered to be part
of the process but are
not included in the formal portion of the acquisition cycle.

The DoD model is tailored toward managing large, complex
system development
efforts where reviews and decisions are needed at key events
throughout the life cycle.
The major reviews are referred to as milestones and are given
letter designations: A,
B, and C. Each of the three major milestones is defi ned with
respect to entry and exit
conditions. For example, at milestone A, a requirements
document needs to be approved
by a military oversight committee before a program will be
allowed to transition to the
next phase. In addition to milestones, the process contains four
additional decision
points: material development decision (MDD), preliminary
design review (PDR),
Figure 4.1. DoD system life cycle model.
User needs
Technology opportunities and resources
• The material development decision precedes
entry into any phase of the acquisition
management system
• Entrance criteria met before entering phase
• Evolutionary acquisition or single step to
full capability
A B C
(Program
initiation)
Material

solution
analysis
Technology
development
Presystems acquisition
, decision point , milestone review , decision point if PDR is not
conducted before milestone B
PDR, preliminary design review
CDR, critical design review
LRIP, low-rate initial production
FRP, full-rate production
IOT and E, initial operational test and evaluation
IOC, initial operational capability
FOC, full operational capability
Systems acquisition Sustainment
Engineering and
manufacturing
development
Production and
deployment
Operations and
support
Material
development
decision
Post-

PDR A
Post-
CDR A
LRIP/IOT and E
FRP
decision
review
IOC FOC
c04.indd 71c04.indd 71 2/8/2011 11:04:39 AM2/8/2011
11:04:39 AM
critical design review (CDR) and full - rate production (FRP)
decision review. Therefore,
DoD management is able to review and decide on the future of
the program at up to
seven major points within the life cycle.
International ISO / IEC 15288 Model. In 2002, the
International Organization
for Standardization (ISO) and the International Electrotechnical
Commission (IEC)
issued the result of several years of effort: a systems
engineering standard designated
ISO/IEC 15288, Systems Engineering — System Life Cycle
Processes . The basic model
is divided into six stages and 25 primary processes. The
processes are intended to

represent a menu of activities that may need to be accomplished
within the basic stages.
The ISO standard purposely does not align the stages and
processes. The six basic
stages are concept, development, production, utilization,
support, and retirement.
Professional Engineering Model. The NSPE model is
tailored to the develop-
ment of commercial systems. This model is mainly directed to
the development of new
products, usually resulting from technological advances ( “
technology driven ” ). Thus,
the NSPE model provides a useful alternative view to the DoD
model of how a typical
system life cycle may be divided into phases. The NSPE life
cycle is partitioned into
six stages: conceptual, technical feasibility, development,
commercial validation and
production preparation, full - scale production, and product
support.
Systems Engineering Life Cycle Model. In structuring a life
cycle model that
corresponded to signifi cant transitions in systems engineering
activities throughout the
system ’ s active life, it was found most desirable to subdivide
the life cycle into three
broad stages and to partition these into eight distinct phases.
This structure is shown in
Figure 4.2 and will be discussed below. The names of these
subdivisions were chosen
Figure 4.2. System life cycle model.
Concept

Development
Engineering
Development
Postdevelopment
Needs
Analysis
Advanced
Development
Production
Concept
Exploration
Engineering
Design
Operations and
Support
Concept
Definition
Integration

and Evaluation
c04.indd 72c04.indd 72 2/8/2011 11:04:40 AM2/8/2011
11:04:40 AM
to refl ect the primary activities occurring in each part of the
process. Inevitably, some
of these names are the same or similar to the names of
corresponding parts of one or
more of the existing life cycles.
Software Life Cycle Models. The system life cycle stages
and their constituent
phases represented by the above models apply to the majority of
complex systems,
including those containing signifi cant software functionality at
the component level.
However, software - intensive systems, in which software
performs virtually all the
functionality, as in modern fi nancial systems, airline
reservation systems, the World
Wide Web, and other information systems, generally follow life
cycles similar in form
but often involving iteration and prototyping. Chapter 11
describes the differences
between software and hardware, discusses the activities
involved in the principal
stages of software system development, and contains a section
dealing with examples
of software system life cycles representing software - intensive

systems. However, with
that exception, the systems engineering life cycle model, as will
be discussed in
Chapters 5 through 15 , provides a natural framework for
describing the evolution of
systems engineering activity throughout the active life of all
engineered complex
systems.
Systems Engineering Life Cycle Stages
As described above, and illustrated in Figure 4.2 , the systems
life cycle model consists
of three stages, the fi rst two encompassing the developmental
part of the life cycle, and
the third the postdevelopment period. These stages mark the
more basic transitions in
the system life cycle, as well as the changes in the type and
scope of effort involved
in systems engineering. In this book, these stages will be
referred to as (1) The concept
development stage, which is the initial stage of the formulation
and defi nition of a
system concept perceived to best satisfy a valid need; (2) the
engineering development
stage, which covers the translation of the system concept into a
validated physical
system design meeting the operational, cost, and schedule
requirements; and (3) the
postdevelopment stage, which includes the production,
deployment, operation, and
support of the system throughout its useful life. The names for
the individual stages
are intended to correspond generally to the principal type of
activity characteristic of
these stages.

The concept development stage, as the name implies, embodies
the analysis and
planning that is necessary to establish the need for a new
system, the feasibility of its
realization, and the specifi c system architecture perceived to
best satisfy the user needs.
Systems engineering plays the lead role in translating the
operational needs into a
technically and economically feasible system concept. Maier
and Rechtin (2009) call
this process “ systems architecting, ” using the analogy of the
building architect translat-
ing a client ’ s needs into plans and specifi cations that a
builder can bid on and build
from. The level of effort during this stage is generally much
smaller than in subsequent
stages. This stage corresponds to the DoD activities of material
solution analysis and
technology development.
c04.indd 73c04.indd 73 2/8/2011 11:04:40 AM2/8/2011
11:04:40 AM
The principal objectives of the concept development stage are
1. to establish that there is a valid need (and market) for a
new system that is
technically and economically feasible;
2. to explore potential system concepts and formulate and
validate a set of system

performance requirements;
3. to select the most attractive system concept, defi ne its
functional characteristics,
and develop a detailed plan for the subsequent stages of
engineering, produc-
tion, and operational deployment of the system; and
4. to develop any new technology called for by the selected
system concept and
to validate its capability to meet requirements.
The engineering development stage corresponds to the process
of engineering the
system to perform the functions specifi ed in the system
concept, in a physical embodi-
ment that can be produced economically and maintained and
operated successfully in
its operational environment. Systems engineering is primarily
concerned with guiding
the engineering development and design, defi ning and
managing interfaces, developing
test plans, and determining how discrepancies in system
performance uncovered during
test and evaluation (T & E) should best be rectifi ed. The main
bulk of the engineering
effort is carried out during this stage. The engineering
development stage corresponds
to the DoD activities of engineering and manufacturing
development and is a part of
production and deployment.
The principal objectives of the engineering development stage
are
1. to perform the engineering development of a prototype

system satisfying the
requirements of performance, reliability, maintainability, and
safety; and
2. to engineer the system for economical production and use
and to demonstrate
its operational suitability.
The postdevelopment stage consists of activities beyond the
system development
period but still requires signifi cant support from systems
engineering, especially when
unanticipated problems requiring urgent resolution are
encountered. Also, continuing
advances in technology often require in - service system
upgrading, which may be just
as dependent on systems engineering as the concept and
stages. This stage corresponds to a part of the DoD production
and deployment phase
and all of the operations and support phase.
The postdevelopment stage of a new system begins after the
system successfully
undergoes its operational T & E, sometimes referred to as
acceptance testing , and is
released for production and subsequent operational use. While
the basic development
has been completed, systems engineering continues to play an
important supporting
role in this effort.
The relations among the principal stages in the system life
cycle are illustrated in
the form of a fl owchart in Figure 4.3 . The fi gure shows the
principal inputs and outputs

of each of the stages. The legends above the blocks relate to the
fl ow of information
c04.indd 74c04.indd 74 2/8/2011 11:04:40 AM2/8/2011
11:04:40 AM
in the form of requirements, specifi cations, and documentation,
beginning with opera-
tional needs. The inputs and outputs below the blocks represent
the stepwise evolution
of the design representations of an engineered system from the
concept to the opera-
tional system. It is seen that both the documentation and design
representations become
increasingly complete and specifi c as the life cycle progresses.
The later section entitled
“ System Materialization ” is devoted to a discussion of the
factors involved in this
process.
Example: Development Stages of a New Commercial Aircraft.
To illus-
trate the application of this life cycle model, consider the
evolution of a new passenger
aircraft. The concept development stage would include the
recognition of a market for
a new aircraft, the exploration of possible confi gurations, such
as number, size, and
location of engines, body dimensions, wing platform, and so on,
leading to the selection
of the optimum confi guration from the standpoint of production
cost, overall effi ciency,

passenger comfort, and other operational objectives. The above
decisions would be
based largely on analyses, simulations, and functional designs,
which collectively
would constitute justifi cations for selecting the chosen
approach.
The engineering development stage of the aircraft life cycle
begins with the accep-
tance of the proposed system concept and a decision by the
aircraft company to proceed
with its engineering. The engineering effort would be directed
to validating the use of
any unproven technology, implementing the system functional
design into hardware
and software components, and demonstrating that the
engineered system meets the user
needs. This would involve building prototype components,
integrating them into an
operating system and evaluating it in a realistic operational
environment. The postde-
velopment stage includes the acquisition of production tooling
and test equipment,
production of the new aircraft, customizing it to fi t
requirements of different customers,
supporting regular operations, fi xing any faults discovered
during use, and periodically
overhauling or replacing engines, landing gear, and other highly
stressed components.
Systems engineering plays a limited but vital supporting and
problem - solving role
during this stage.
Figure 4.3. Principal stages in a system life cycle.
Operational

Deficiencies
System Functional
Specifications
System Production
Specifications
Operations and
Maintenance
Documentation
Concept
Development
Engineering
Development
Postdevelopment
Technological
Opportunities
Defined System
Concept(s)
Production
System
Installed
Operational

System
c04.indd 75c04.indd 75 2/8/2011 11:04:40 AM2/8/2011
11:04:40 AM
Concept Development Phases
While the three stages described above constitute the dominant
subdivisions of the
system life cycle, each of these stages contains recognizable
subdivisions with charac-
teristically different objectives and activities. In the case of
large programs, formal
decision points also mark most of these subdivisions, similar to
those marking the
transition between stages. Furthermore, the roles of systems
engineering tend to differ
signifi cantly among these intermediate subdivisions. Hence, to
understand how the
evolution of the system life cycle relates to the systems
engineering process, it is useful
to develop a model of its structure down to this second level of
subdivision.
The concept development stage of the systems engineering life
cycle encompasses
three phases: needs analysis , concept exploration , and
concept defi nition . Figure 4.4
shows these phases, their principal activities and inputs and
outputs in a format analo-
gous to Figure 4.3 .

Needs Analysis Phase. The needs analysis phase defi nes
the need for a new
system. It addresses the questions “ Is there a valid need for a
new system? ” and “ Is
there a practical approach to satisfying such a need? ” These
questions require a critical
examination of the degree to which current and perceived future
needs cannot be satis-
fi ed by a physical or operational modifi cation of available
means, as well as whether
or not available technology is likely to support the increased
capability desired. In many
cases, the beginning of the life of a new system evolves from a
continuing analysis of
operational needs, or an innovative product development,
without a sharply identifi ed
beginning.
The output of this phase is a description of the capabilities and
operational effec-
tiveness needed in the new system. In many ways, this
description is the fi rst iteration
of the system itself, albeit a very basic conceptual model of the
system. The reader
Figure 4.4. Concept development phases of a system life
cycle.
Operational
Deficiencies
System Operational
Effectiveness
System Performance
Requirements

System Functional
Specifications
Needs Analysis Concept Exploration Concept Definition
System Studies
Technology Assessment
Requirements Analysis
Concept Synthesis
Analysis of Alternatives
Functional Architecture
Operational Analysis Feasibility Experiments Physical
Architecture
Technological
Opportunities
System Capabilities Candidate System
Concepts
Defined System
Concept(s)
c04.indd 76c04.indd 76 2/8/2011 11:04:40 AM2/8/2011
11:04:40 AM
should take note of how the “ system ” evolves from this very

beginning phase through-
out its life cycle. Although we would not yet call this
description a set of requirements,
they certainly are the forerunner of what will be defi ned as offi
cial requirements.
Some communities refer to this early description as an initial
capability description.
Several classes of tools and practices exist to support the
development of the
system capabilities and effectiveness description. Most fall into
two categories of
mathematics, known as operational analysis and operations
research. However, technol-
ogy assessments and experimentation are an integral part of this
phase and will be used
in conjunction with mathematical techniques.
Concept Exploration Phase. This phase examines potential
system concepts
in answering the questions “ What performance is required of
the new system to meet
the perceived need? ” and “ Is there at least one feasible
approach to achieving such
performance at an affordable cost? ” Positive answers to these
questions set a valid and
achievable goal for a new system project prior to expending a
major effort on its
development.
The output of this phase includes our fi rst “ offi cial ” set of
requirements, typically
known as system performance requirements. What we mean by
offi cial is that a con-
tractor or agency can be measured against this set of required
capabilities and perfor-

mance. In addition to an initial set of requirements, this phase
produces a set of
candidate system concepts. Note the plural — more than one
alternative is important to
explore and understand the range of possibilities in satisfying
the need.
A variety of tools and techniques are available in this phase
and range from process
methods (e.g., requirements analysis) to mathematically based
(e.g., decision support
methods) to expert judgment (e.g., brainstorming). Initially, the
number of concepts
can be quite large from some of these techniques; however, the
set quickly reduces to
a manageable set of alternatives. It is important to understand
and “ prove ” the feasibility
of the fi nal set of concepts that will become the input of the
next phase.
Concept Defi nition Phase. The concept defi nition phase
selects the preferred
concept. It answers the question “ What are the key
characteristics of a system concept
that would achieve the most benefi cial balance between
capability, operational life, and
cost? ” To answer this question, a number of alternative
concepts must be considered,
and their relative performance, operational utility, development
risk, and cost must be
compared. Given a satisfactory answer to this question, a
decision to commit major
resources to the development of the new system can be made.
The output is really two perspectives on the same system: a set
of functional

specifi cations that describe what the system must do, and how
well, and a selected
system concept. The latter can be in two forms. If the
complexity of the system is rather
low, a simple concept description is suffi cient to communicate
the overall design strat-
egy for the development effort to come. However, if the
complexity is high, a simple
concept description is insuffi cient and a more comprehensive
system architecture is
needed to communicate the various perspectives of the system.
Regardless of the depth
of description, the concept needs to be described in several
ways, primarily from a
c04.indd 77c04.indd 77 2/8/2011 11:04:40 AM2/8/2011
11:04:40 AM
functional perspective and from a physical perspective. Further
perspectives may very
well be needed if complexity is particularly high.
The tools and techniques available fall into two categories:
analysis of alternatives
(a particular method pioneered by the DoD, but fully part of
operations research), and
systems architecting (pioneered by Ebbert Rechtin in the early
1990s).
As noted previously, in commercial projects (NSPE model), the
fi rst two phases
are often considered as a single preproject effort. This is

sometimes referred to as a
“ feasibility study ” and its results constitute a basis for
making a decision as to whether
or not to invest in a concept defi nition effort. In the defense
acquisition life cycle, the
second and third phases are combined, but the part
corresponding to the second phase
is performed by the government, resulting in a set of system
performance requirements,
while that corresponding to the third can be conducted by a
government – contractor
team or performed by several contractors competing to meet the
above requirements.
In any case, before reaching the engineering development
stage, only a fractional
investment has usually been made in the development of a
particular system, although
some years and considerable effort may have been spent in
developing a fi rm under-
standing of the operational environment and in exploring
relevant technology at the
subsystem level. The ensuing stages are where the bulk of the
investment will be
required.
Engineering Development Phases
Figure 4.5 shows the activities, inputs, and outputs of the
constituent phases of the
engineering development stage of the system life cycle in the
same format as used in
Figure 4.3 . These are referred to as advanced development ,
engineering design , and
integration and evaluation .

Advanced Development Phase. The success of the
stage of a system project is critically dependent on the
soundness of the foundation laid
Figure 4.5. Engineering development phases in a system
life cycle.
System Design
Specifications
Test and Evaluation
Plan
System Production
Specifications
System Functional
Specifications
Advanced
Engineering Design
Integration and
Development
Risk Management
Subsystem Definition
Component Engineering
Component Test
Evaluation
System Integration

System Test
Component Specs
Specialty Engineering
Operational Evaluation
Validated Development
Model
Engineered
Components
Production
System
Defined System
Concept(s)
c04.indd 78c04.indd 78 2/8/2011 11:04:40 AM2/8/2011
11:04:40 AM
during the concept development stage. However, since the
conceptual effort is largely
analytical in nature and carried out with limited resources,
signifi cant unknowns invari-
ably remain that are yet to be fully defi ned and resolved. It is
essential that these
“ unknown unknowns ” be exposed and addressed early in the
engineering stage. In par-
ticular, every effort must be made to minimize the number of as
yet undisclosed problems

prior to translating the functional design and associated system
requirements into engi-
neering specifi cations for the individual system hardware and
software elements.
The advanced development phase has two primary purposes: (1)
the identifi cation
and reduction of development risks and (2) the development of
system design specifi ca-
tions. The advanced development phase is especially important
when the system
concept involves advanced technology not previously used in a
similar application, or
where the required performance stresses the system components
beyond proven limits.
It is devoted to designing and demonstrating the undeveloped
parts of the system, to
proving the practicality of meeting their requirements, and to
laying the basis for con-
verting the functional system requirements into system specifi
cations and component
design requirements. Systems engineering is central to the
decisions of what needs to
be validated and how, and to the interpretation of the results.
This phase corresponds to the defense acquisition phase called
“ engineering and
manufacturing development, ” once referred to as “
demonstration and validation. ”
When the risks of using unproven technology are large, this
phase is often contracted
separately, with contracts for the remaining engineering phase
contingent on its
success.
Matching the purpose of this phase, the two primary outputs

are the design speci-
fi cations and a validated development model. The specifi
cations are a refi nement and
evolution of the earlier function specifi cations. The
development model is the fi nal
outcome of a very comprehensive risk management task —
where those unknowns
mentioned above have been identifi ed and resolved. This is
what we mean when we
use the adjective “ validated. ” The systems engineer needs to
be convinced that this
system can be designed and manufactured before transitioning
from this phase.
Therefore, all risks at this phase must be rated as manageable
before proceeding.
Modern risk management tools and techniques are essential to
reduce and ulti-
mately to mitigate risks inherent in the program. As these risks
are managed, the level
of defi nition continues to migrate down, from the system to the
subsystem. Furthermore,
a set of specifi cations for the next level of decomposition, at
the component level,
occurs. In all of these cases, both experimental models and
simulations are often
employed at this stage to validate component and subsystem
design concepts at
minimum cost.
Engineering Design Phase. The detailed engineering design
of the system is
performed during this phase. Because of the scale of this effort,
it is usually punctuated
by formal design reviews. An important function of these
reviews is to provide an

opportunity for the customer or user to obtain an early view of
the product, to monitor
its cost and schedule, and to provide valuable feedback to the
system developer.
While issues of reliability, producibility, maintainability, and
other “ ilities ”
have been considered in previous phases, they are of paramount
importance in the
c04.indd 79c04.indd 79 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
engineering design phase. These types of issues are typically
known as “ specialty
engineering. ” Since the product consists of a set of
components capable of being inte-
grated and tested as a system, the systems engineer is
responsible for ensuring that the
engineering design of the individual components faithfully
implements the functional
and compatibility requirements, and for managing the
engineering change process to
maintain interface and confi guration control.
The tasks of this phase deals with converting the component
specifi cations into a
set of component designs. Of course, testing these components
is essential to occur
immediately after design, or in some cases, concurrently with
design. One additional
task is performed during this phase: the refi nement of the

system T & E plan. We use
the term refi nement to distinguish between the initiation and
continuation. The T & E
plan is initially developed much earlier in the life cycle. At this
phase, the T & E plan
is largely fi nished, using the knowledge gained from the
previous phases.
The two primary outputs are the T & E plan and an engineered
prototype. The pro-
totype can take many forms and should not be thought of in the
same way as we think
of a software prototype. This phase may produce a prototype
that is virtual, physical,
or a hybrid, depending on the program. For example, if the
system is an ocean - going
cargo vessel, the prototype at this stage may be a hybrid of
virtual and physical mock -
ups. A full - scale prototype of a cargo ship may not be
possible or prudent at this phase.
On the other hand, if the system is a washing machine, a full -
scale prototype may be
totally appropriate.
Modern computer - aided design tools are available as design
engineers perform
their trade. System models and simulations are also updated as
designs are fi nalized
and tested.
Integration and Evaluation Phase. The process of
integrating the engineered
components of a complex system into a functioning whole, and
evaluating the system ’ s
operation in a realistic environment, is nominally part of the
engineering design process

because there is no formal break in the development program at
this point. However,
there is a basic difference between the role and responsibility of
systems engineering
during the engineering design of the system elements and that
during the integration
and evaluation process. Since this book is focused on the
functions of systems engineer-
ing, the system integration and evaluation process is treated as a
separate phase in the
system life cycle.
It is important to realize that the fi rst time a new system can
be assembled and
evaluated as an operating unit is after all its components are
fully engineered and built.
It is at this stage that all the component interfaces must fi t and
component interactions
must be compatible with the functional requirements. While
there may have been prior
tests at the subsystem level or at the level of a development
prototype, the integrity of
the total design cannot be validated prior to this point.
It should also be noted that the system integration and
evaluation process often
requires the design and construction of complex facilities to
closely simulate opera-
tional stimuli and constraints and to measure the system ’ s
responses. Some of these
facilities may be adapted from developmental equipment, but
the magnitude of the task
should not be underestimated.
c04.indd 80c04.indd 80 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM

The outputs of this phase are twofold: (1) the specifi cations to
guide the manufac-
turing of the system, typically called the system production
specifi cations (sometimes
referred to as the production baseline), and (2) the production
system itself. The latter
includes everything necessary to manufacture and assemble the
system and may include
a prototype system.
Modern integration techniques and T & E tools, methods,
facilities, and principles
are available to assist and enable the engineers in these tasks.
Of course, before full -
scale production can occur, the fi nal production system needs
to be verifi ed and vali-
dated through an evaluation within the operational environment
or a suffi cient surrogate
for the operational environment.
Postdevelopment Phases
Production Phase. The production phase is the fi rst of the
two phases compris-
ing the postdevelopment stage, which are exactly parallel to the
defense acquisition
phases of “ production and deployment ” and “ operations and
support. ”
No matter how effectively the system design has been
engineered for production,

problems inevitably arise during the production process. There
are always unexpected
disruptions beyond the control of project management, for
example, a strike at a ven-
dor ’ s plant, unanticipated tooling diffi culties, bugs in critical
software programs, or an
unexpected failure in a factory integration test. Such situations
threaten costly disrup-
tions in the production schedule that require prompt and
decisive remedial action.
Systems engineers are often the only persons qualifi ed to
diagnose the source of the
problem and to fi nd an effective solution. Often a systems
engineer can devise a “ work -
around ” that solves the problem for a minimal cost. This
means that an experienced
cadre of systems engineers intimately familiar with the system
design and operation
needs to be available to support the production effort. Where
specialty engineering
assistance may be required, the systems engineers are often best
qualifi ed to decide
who should be called in and when.
Operations and Support Phase. In the operations and support
phase, there is
an even more critical need for systems engineering support. The
system operators and
maintenance personnel are likely to be only partially trained in
the fi ner details of
system operation and upkeep. While specially trained fi eld
engineers generally provide
support, they must be able to call on experienced systems
engineers in case they
encounter problems beyond their own experience.

Proper planning for the operational phase includes provision of
a logistic support
system and training programs for operators and maintenance
personnel. This planning
should have major participation from systems engineering.
There are always unantici-
pated problems that arise after the system becomes operational
that must be recognized
and included in the logistic and training systems. Very often,
the instrumentation
required for training and maintenance is itself a major
component of the system to be
delivered.
Most complex systems have lifetimes of many years, during
which they undergo
a number of minor and major upgrades. These upgrades are
driven by evolution in the
c04.indd 81c04.indd 81 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
system mission, as well as by advances in technology that offer
opportunities to
improve operation, reliability, or economy. Computer - based
systems are especially
subject to periodic upgrades, whose cumulative magnitude may
well exceed the initial
system development. While the magnitude of an individual
system upgrade is a fraction
of that required to develop a new system, it usually entails a
great many complex deci-

sions requiring the application of systems engineering. Such an
enterprise can be
extremely complex, especially in the conceptual stage of the
upgrade effort. Anyone
that has undergone a signifi cant home alteration, such as the
addition of one bedroom
and bath, will appreciate the unexpected diffi culty of deciding
just how this can be
accomplished in such a way as to retain the character of the
original structure and yet
realize the full benefi ts of the added portion, as well as be
performed for an affordable
price.
4.3 EVOLUTIONARY CHARACTERISTICS OF
THE DEVELOPMENT PROCESS
The nature of the system development process can be better
understood by considering
certain characteristics that evolve during the life cycle. Four of
these are described in
the paragraphs below. The section The Predecessor System
discusses the contributions
of an existing system on the development of a new system that
is to replace it. The
section System Materialization describes a model of how a
system evolves from
concept to an engineered product. The section The Participants
describes the composi-
tion of the system development team and how it changes during
the life cycle. The
section System Requirements and Specifi cations describes how
the defi nition of the
system evolves in terms of system requirements and specifi
cations as the development
progresses.

The Predecessor System
The process of engineering a new system may be described
without regard to its resem-
blance to current systems meeting the same or similar needs.
The entire concept and
all of its elements are often represented as starting with a blank
slate, a situation that
is virtually never encountered in practice.
In the majority of cases, when new technology is used to
achieve radical changes
in such operations as transportation, banking, or armed combat,
there exist predecessor
systems. In a new system, the changes are typically confi ned to
a few subsystems, while
the existing overall system architecture and other subsystems
remain substantially
unchanged. Even the introduction of automation usually changes
the mechanics but not
the substance of the process. Thus, with the exception of such
breakthroughs as the
fi rst generation of nuclear systems or of spacecraft, a new
system development can
expect to have a predecessor system that can serve as a point of
departure.
A predecessor system will impact the development of a new
system in three ways:
1. The defi ciencies of the predecessor system are usually
recognized, often being
the driving force for the new development. This focuses
attention on the most

c04.indd 82c04.indd 82 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
EVOLUTIONARY CHARACTERISTICS OF THE
DEVELOPMENT PROCESS 83
important performance capabilities and features that must be
provided by the
new system.
2. If the defi ciencies are not so serious as to make the
current system worthless,
its overall concept and functional architecture may constitute
the best starting
point for exploring alternatives.
3. To the extent that substantial portions of the current
system perform their func-
tion satisfactorily and are not rendered obsolete by recent
technology, great cost
savings (and risk reduction) may be achieved by utilizing them
with minimum
change.
Given the above, the average system development will almost
always be a hybrid, in
that it will combine new and undemonstrated components and
subsystems with previ-
ously engineered and fully proven ones. It is a particular
responsibility of systems
engineering to ensure that the decisions as to which predecessor
elements to use, which
to reengineer, which to replace by new ones, and how these are
to be interfaced are

made through careful weighing of performance, cost, schedule,
and other essential
criteria.
System Materialization
The steps in the development of a new system can be thought
of as an orderly progres-
sive “ materialization ” of the system from an abstract need to
an assemblage of actual
components cooperating to perform a set of complex functions
to fulfi ll that need. To
illustrate this process, Table 4.1 traces the growth of
materialization throughout the
phases of the project life cycle. The rows of the table represent
the levels of system
subdivision, from the system itself at the top to the part level at
the bottom. The columns
are successive phases of the system life cycle. The entries are
the primary activities at
each system level and phase, and their degree of
materialization. The shaded areas
indicate the focus of the principal effort in each phase.
It is seen that each successive phase defi nes (materializes) the
next lower level of
system subdivision until every part has been fully defi ned.
Examining each row from
left to right, say, at the component level, it is also seen that the
process of defi nition
starts with visualization (selecting the general type of system
element), then proceeds
to defi ning its functions (functional design, what it must do),
and then to its implemen-
tation (detailed design, how it will do it).

The above progression holds true through the engineering
design phase, where the
components of the system are fully “ materialized ” as fi
nished system building blocks.
In the integration and evaluation phase, the materialization
process takes place in a
distinctly different way, namely, in terms of the materialization
of an integrated and
validated operational system from its individual building
blocks. These differences are
discussed further in Chapter 13 .
It is important to note from Table 4.1 that while the detailed
design of the system
is not completed until near the end of its development, its
general characteristics must
be visualized very early in the process. This can be understood
from the fact that the
selection of the specifi c system concept requires a realistic
estimate of the cost to
c04.indd 83c04.indd 83 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
TA B L E 4.1. Evolution of System Materialization through
the System Life Cycle
Level
Phase
Concept development Engineering development
Needs analysis Concept exploration Concept defi nition

Advanced
development
Engineering
design
Integration and
evaluation
System Defi ne system
capabilities and
effectiveness
Identify, explore, and
synthesize concepts
Defi ne selected
concept with
specifi cations
Validate concept Test and evaluate
Subsystem Defi ne requirements
and ensure feasibility
Defi ne functional and
physical architecture
Validate subsystems Integrate and test
Component Allocate functions to
components
Defi ne specifi cations Design and test Integrate and test

Subcomponent Visualize Allocate functions
to subcomponents
Design
Part Make or buy
8
4
c0
4
.in
d
d
8
4
c0
4
.in
d
d
8
4
2
/8
/2
0
1

1
1
1
:0
4
:4
1
A
M
2
/8
/2
0
1
1
1
1
:0
4
:4
1
A
M
EVOLUTIONARY CHARACTERISTICS OF THE

DEVELOPMENT PROCESS 85
develop and produce it, which in turn requires a visualization of
its general physical
implementation as well as its functionality. In fact, it is
essential to have at least a
general vision of the physical embodiment of the system
functions during even the
earliest investigations of technical feasibility. It is of course
true that these early visu-
alizations of the system will differ in many respects from its fi
nal materialization, but
not so far as to invalidate conclusions about its practicality.
The role of systems architecting fulfi lls this visualization
requirement by providing
visual perspectives into the system concept early in the life
cycle. As a system project
progresses through its life cycle, the products of the
architecture are decomposed to
ever - lower levels.
At any point in the cycle, the current state of system defi nition
can be thought of
as the current system model. Thus, during the concept
development stage, the system
model includes only the system functional model that is made
up entirely of descriptive
material, diagrams, tables of parameters, and so on, in
combination with any simula-
tions that are used to examine the relationships between system
- level performance and
specifi c features and capabilities of individual system
elements. Then, during the engi-
neering development stage, this model is augmented by the
gradual addition of hard-

ware and software designs for the individual subsystems and
components, leading
fi nally to a completed engineering model. The model is then
further extended to a
production model as the engineering design is transformed into
producible hardware
designs, detailed software defi nition, production tooling, and
so on. At every stage of
the process, the current system model necessarily includes
models of all externally
imposed interfaces as well as the internal system interfaces.
The Participants
A large project involves not only dozens or hundreds of people
but also several different
organizational entities. The ultimate user may or may not be an
active participant in
the project but plays a vital part in the system ’ s origin and in
its operational life. The
two most common situations are when (1) the government
serves as the system acquisi-
tion agent and user, with a commercial prime contractor
supported by subcontractors
as the system developer and producer, and (2) a commercial
company serves as the
acquisition manager, system developer, and producer. Other
commercial companies or
the general public may be the users. The principal participants
in each phase of the
project are also different. Therefore, one of the main functions
of systems engineering
is to provide the continuity between successive participating
levels in the hierarchy and
successive development phases and their participants through
both formal documenta-

tion and informal communications.
A typical distribution of participants in an aerospace system
development is shown
in Figure 4.6 . The height of the columns represents the
relative number of engineering
personnel involved. The entries are the predominant types of
personnel in each phase.
It is seen that, in general, participation varies from phase to
phase, with systems engi-
neering providing the main continuity.
The principal participants in the early phases are analysts and
architects (system
and operations/market). The concept defi nition phase is usually
carried out by an
c04.indd 85c04.indd 85 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
expedited team effort, representing all elements necessary to
select and document the
most cost - effective system concept for meeting the stated
requirements.
The advanced development phase usually marks the initial
involvement of the
system design team that will carry the project through the
engineering stage and on
into production. It is led by systems engineering, with support
from the design and test
engineers engaged in the development of components and

subsystems requiring
development.
The engineering design phase further augments the effort with
a major contribution
from specialty engineering (reliability, maintainability, etc.), as
well as test and produc-
tion engineering. For software, this phase involves designers, as
well as coders, to the
extent that prototyping is employed.
The integration and evaluation phase relies heavily on test
engineering with guid-
ance from systems engineering and support from design
engineers and engineering
specialists.
System Requirements and Specifi cations
Just as the system design gradually materializes during the
successive steps of system
development, so the successive forms of system requirements
and specifi cations become
more and more specifi c and detailed. These start with a set of
operational requirements
and end with a complete set of production specifi cations,
operation, maintenance, and
Figure 4.6. Principal participants in a typical aerospace
system development.
Test Eng
100
Sys Anal – System Analysts
Sys Arch – System Architects

Sys Eng – Systems Engineers
Test Eng
Test Eng
75
Integ Eng
Integ Eng
Des Eng – Design Engineers (incl. specialty)
Integ Eng – Integration Engineers
Test Eng – Test Engineers
Des Eng
Des EngDes Eng
50
Integ Eng
Sys Eng
Sys Eng
Sys Eng
Des Eng
25
Sys Arch
S A l S A l

Sys Arch
Sys Arch
S A h Sys Arch
Sys Eng
Sys Eng Sys Eng
Sys Anal Sys nal ys nal Sys rch Sys Arch Sys
Needs
Analysis
Concept
Exploration
Concept
Definition
Advanced
Development
Engineering
Design
Integration
and
Evaluation
0
Concept Development Engineering Development

R
e
la
tiv
e
R
e
so
u
rc
e
L
e
ve
l
c04.indd 86c04.indd 86 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
THE SYSTEMS ENGINEERING METHOD 87
training manuals and all other information needed to replicate,
operate, maintain, and
repair the system. Thus, each phase can be thought of as
producing a more detailed
description of the system: what it does, how it works, and how
it is built.

Since the above documents collectively determine both the
course of the develop-
ment effort and the form and capabilities of the system as fi
nally delivered, oversight
of their defi nition and preparation is a primary responsibility of
This effort must, however, be closely coordinated with the
associated design specialists
and other involved organizations.
The evolution of system requirements and specifi cations is
shown in the fi rst row
of Table 4.2 as a function of the phases in the system life
cycle. It should be emphasized
that each successive set of documents does not replace the
versions defi ned during the
previous phases but rather supplements them. This produces an
accumulation rather
than a succession of system requirements and other documents.
These are “ living docu-
ments, ” which are periodically revised and updated.
The necessity for an aggregation of formal requirements and
specifi cations devel-
oped during successive phases of the system development can
be better understood by
recalling the discussion of “ Participants ” and Figure 4.6 . In
particular, not only are there
many different groups engaged in the development process, but
many, if not most, of
the key participants change from one phase to the next. This
makes it essential that a
complete and up - to - date description exists that defi nes what
the system must do and
also, to the extent previously defi ned, how it must do it.

The system description documents not only lay the basis for the
next phase of
system design but they also specify how the results of the effort
are to be tested in order
to validate compliance with the requirements. They provide the
information base
needed for devising both the production tools and the tools to be
used for inspecting
and testing the product of the forthcoming phase.
The representations of system characteristics also evolve
during the development
process, as indicated in the second row of Table 4.2 . Most of
these will be recognized
as architecture views and conventional engineering design and
software diagrams and
models. Their purpose is to supplement textual descriptions of
successive stages of
system materialization by more readily understandable visual
forms. This is especially
important in defi ning interfaces and interactions among system
elements designed by
different organizations.
4.4 THE SYSTEMS ENGINEERING METHOD
In the preceding sections, the engineering of a complex system
was seen to be divisible
into a series of steps or phases. Beginning with the identifi
cation of an opportunity to
achieve a major extension of an important operational capability
by a feasible techno-
logical approach, each succeeding phase adds a further level of
detailed defi nition
(materialization) of the system, until a fully engineered model

is achieved that proves
to meet all essential operational requirements reliably and at an
affordable cost. While
many of the problems addressed in a given phase are peculiar to
that state of system
defi nition, the systems engineering principles that are
employed, and the relations
c04.indd 87c04.indd 87 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
TA B L E 4.2. Evolution of System Representation
Concept development Engineering development
Needs analysis
Concept
exploration Concept defi nition
Advanced
development Engineering design
Integration
and evaluation
Documents System capabilities
and effectiveness
System
performance
requirements

System functional
requirements
System design
specifi cations
Design documents Test plans and
evaluation
reports
System
models
Operational
diagrams, mission
simulations
System diagrams,
high - level system
simulations
Architecture
products and
views, simulations,
mock - ups
Architecture
products and
views, detailed
simulations,
breadboards
Architecture drawings
and schematics,
engineered components,
computer - aided design

(CAD) products
Test setups,
simulators,
facilities, and
test articles
8
8
c0
4
.in
d
d
8
8
c0
4
.in
d
d
8
8
2
/8
/2
0
1

1
1
1
:0
4
:4
1
A
M
2
/8
/2
0
1
1
1
1
:0
4
:4
1
A
M

among them, are fundamentally similar from one phase to the
next. This fact, and its
importance in understanding the system development process,
has been generally rec-
ognized; the set of activities that tends to repeat from one phase
to the next has been
referred to in various publications on systems engineering as the
“ systems engineering
process, ” or the “ systems engineering approach, ” and is the
subject of the sections
below. In this book, this iterative set of activities will be
referred to as the “ systems
engineering method. ”
The reason for selecting the word “ method ” in place of the
more widely used
“ process ” or “ approach ” is that it is more defi nitive and
less ambiguous. The word
method is more specifi c than process, having the connotation of
an orderly and logical
process. Furthermore, the term systems engineering process is
sometimes used to apply
to the total system development. Method is also more
appropriate than approach, which
connotes an attitude rather than a process. With all this said, the
use of a more common
terminology is perfectly acceptable.
Survey of Existing Systems Engineering Methods and
Processes
The fi rst organization to codify a formal systems engineering
process was the U.S. DoD,
captured in the military standard, MIL - STD - 498. Although
the process evolved through

several iterations, the last formal standard to exist (before being
discontinued) was
MIL - STD - 499B. This process is depicted in Figure 4.7 and
contains four major activi-
ties: requirements analysis, functional analysis and allocation,
synthesis, and systems
analysis and control. The component tasks are presented within
each activity.
While this military standard is no longer in force, it is still
used as a guide by many
organizations and is the foundation for understanding the basics
of today ’ s systems
engineering processes.
Three relevant commercial standards describe a systems
engineering process:
IEEE - 1220, the EIA - STD - 632, and the ISO - IEC - IEEE -
STD - 15288. As these three
processes are presented, notice that each commercial standard
blends aspects of a
systems engineering process with the life cycle model describe
above. The order that
we present these three methods is important — they are
presented in order of the level
of convergence with the life cycle model of system
development. And in fact, the mili-
tary standard discussed above could be placed fi rst in the
sequence. In other words,
MIL - STD - 499B is the most divergent from the life cycle
model. In contrast, ISO - 15288
could easily be thought of as a life cycle model for system
development.
Figure 4.8 presents the IEEE - 1220 process. The main control
activity is located in

the middle of the graph. The general fl ow of activities is then
clockwise, starting from
the bottom left, beginning with “ process inputs ” and ending
with “ process outputs. ”
This process could also be thought of as an expansion of the
military standard — the
four basic activities are present, with a verifi cation or
validation step in between.
Figure 4.9 presents the EIA - 632 process. Actually, the EIA -
632 standard presents
a collection of 13 processes that are linked together. One can
easily recognize the itera-
tive and circular nature of these linkages. Although the general
fl ow is top – down, the
processes are repeated multiple times throughout the system life
cycle.
c04.indd 89c04.indd 89 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
Figure 4.7. DoD MIL - STD499B.
Process Input
Systems Analysis
and Control
Process Output
Requirements Analysis
•Analyze Missions and Environments

•Identify Functional Requirements
•Define/Refine Performance and
Design Constraint Requirements
Functional Analysis/Allocation
•Decompose to Lower-Level Functions
•Allocate Performance and Other Limiting
Requirements to All Functional Levels
•Define/Refine Functional Interfaces (Internal/External)
•Define/Refine/Integrate Functional Architecture
Synthesis
•Transform Architectures (Functional to Physical)
•Define Alternative System Concepts,
Configuration Items, and System Elements
•Define/Refine Physical Interfaces (Internal/External)
•Define/Alternative Product and Process
Solution
s
Verification
Figure 4.8. IEEE - 1220 systems engineering process.
Requirements
Validation

Requirements
Analysis
Systems Analysis
and Control
Design
Verification
Synthesis
Functional
(Performance)
Verification
Functional
(Performance)
Analysis
Process
Inputs
Process

Outputs
c04.indd 90c04.indd 90 2/8/2011 11:04:41 AM2/8/2011
11:04:41 AM
Figure 4.9. EIA - 632 systems engineering process.
Technical Management
Assessment
Process
Planning
Process
Control
Process
Acquisition and Supply
Supply Process
Acquisition Process

Requirements
Outcomes
and
Feedback
Plans,
Directives,
and Status
System Design
Requirements Definition Process

CMGT 580Introduction to Systems Engineering ManagementClass .docx

More Related Content

Similar to CMGT 580Introduction to Systems Engineering ManagementClass .docx (20)

More from mary772 (20)

Recently uploaded (20)

CMGT 580Introduction to Systems Engineering ManagementClass .docx