CHA PTER

FOUNDATIONS OF
SYSTEMS
ENGINEERING
JOSEPH P.
ELM CIHAN
DAGLI

WHAT IS SYSTEMS ENGINEERING

Before discussing the field of Systems Engineering, we must first understand what a system is. The International
Council on Systems Engineering (INCOSE) defines a system as:

[A]n integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements
Include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and
other sup- port elements.’

The Defense Acquisition University of the US Departsent of Defense defines a system as:

[A]n integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective

ISO/IEC/IEEE Std 15288:2015 defines a system as:

[C] ombination of interacting elements organized to achieve one or more stated purposes'

Some factors common to all of these definitions are:

• Elements—a system is composed of multiple elements. Those elements could be components, processes,
people, and so on.
• Integrated or interacting—A system is more than a collection of elements. Those elements are intercon-
nected and interacting.
• Purpose—A system serves a stated purpose or strives to achieve a stated goal.

In short, a system is a purposeful WHOLE consisting of interacting PARTS, characterized by a system bound-
ary, and providing a defined functionality. Systems principles are found in many domains—Social Systems (Eco-
nomic Systems, Government Systems), Biological Systems (Circulatory System, Respiratory System. Endocrine
System), Natural Systems (Climate and Weather, Ecological Systems, Astronomical Systems), and Manufactured
Systems (Aircraft, Automobiles, Computers, Power Distribution).

' INCOSE System Englneerlng Handbook, v4.0.

’Systeriu Englnecririg f•undoine›itoß, Defense Acquisltiort University Press.
’ ISO/IEC/IEEE 15288:2015.

1325
1326 5Y5TkM5 ENLINL L hIIN\

Planning

Technical Breadth
Engineering Design

System Engineering

FIGURE 67.1 Depth and breadth of expertise.

A complex Manufactured System, may include many smaller systems and involve many technical disciplines.
For example, a ship may include systems such as structures, propulsion, hydraulics, electrical power, controls,
radar, navigation, computers, communications, and so on. The development of a ship involves engineerin8 disci-
plines such as Mechanical Engineering (for structures and fluid dynamics), Metallurgical Engineering, Electrical
Engineering (for power, radar, and communications) Manufacturing Engineering, Software Engineering, InduS-
trial Engineering, and others. We count on the engineers in thèse disciplines to have the requisite depth of exper-
tise within their disciplines. But what about the activities that do not fit into a specific discipline? What about
interdisciplinary activities such as Requirements Development and Management? Can we expect our Mechanical
Engineering staff to develop and allocate the mechanical and structural requirements, as well as the
electrofliC8Rd sofHvare requirements?
In developing the optimum design, alternate solutions will need to be considered and evaluated. These trade
studies will routinely cross disciplinary boundaries, requiring multidisciplinary knowledge. Even the development
of the system and software architectures will require multidisciplinary knowledge and experience. Thèse are just
a few of the activities that do not fit cleanly into one of the engineering disciplines.
To address these challenges, we need someone with multidisciplinary knowledge needed t0 pull
activities together. Someone who maintains a global system-wide perspective that encompasses the entire life
cycle
of the product. Someone who possesses multidisciplinary technical knowledge that enables him to
address the interdisciplinary activities. Someone who employs fact-based decision-making techniques, and
managtt
multiple threads of the system design simultaneously. Someone who is a Systems Engineer.
The Systems Engineer is often trained in another engineering discipline (e.g., electrical, mechaniC8l, Clvil), and
typically has at least 10 years of system development experience. Most Systems Engineers start wi contributions
in their chosen discipline, but then expand with experience to include oversight of other disciplines. ThrougÎlottt
ct
their career they exhibit the ability to maintain a system-wide perspective. They also usually have some proje
management skills and experience. And they may have specific System Engineering education and
Systems Engineering (SE) is a disciplined approach to address the complexity and time pressures of system
development. As defned by INCOSE:

It
Systems engineering is an Interdisciplinary approach arld means to enable the realization of successful S}'St
focuses on defining customer needs and required functionality early in the development cycle, docurnenting requir£-
ments, and then proceedin g with design synthesis and system validation while considering the complete
operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. sz considère
both the business and the technical needs of all customers With the goal of providing a quality product that meets
tb* user needs.’

‘ INCOSE System Engineering Handbook, v4.0.

 FOUNDATIONSOF SYSTEMS ENGINEERING 1327

24'
2096

48) (n = 49) . (n = 51)

Total Systems Engineering Capability (SEC)
Gamma = 0.49 p-value < 0.001

FIGURE 67.2 Project performance versus applied SE.

As noted in this definition, it is an interdisciplinary approach, coordinating the efforts of all of the disciplines
supporting system development. It also focuses on the complete problem, addressing the needs of all stakehold-
ers, and addressing all aspects of the system lifecycle, from inception through disposal.

THE VALUE OF SYSTEMS ENGINEERING

SE addresses the Ml life cycle of a system. As such, it is a forward-looking activity. During the earliest phases of
concept development and design, it considers the implication of design decisions on the system production, sys-
tem operation, system maintenance, and even system disposal at the end of its utility. Studies [3} have shown that
the earlier a design defect is identified, the easier (and less expensive) it is to correct. Consider the inadvertent
introduction of a defect during system concept development. Correcting it during the concept development will
require both time and resources. However, if it is not detected until the system design phase, correcting it may
require three to six times the time and resources. If it is not detected until the system development phase, correct-
ing it may require 20— 100 times the time and resources. And if it is not detected until system production and test,
correcting it may require 500— 1000 times the time and resources. These studies show the importance of early
defect detection and correction. As SE looks ahead to future phases of the system lifecycle. it facilitates the detec-
tion of defects earlier in the system life cycle.
In a study [4] of over 150 projects, research has shown that projects that employ more (and better) SE, deliver
better project pedormance—satisfying schedules, budgets, and performance specifications. The three columns
of the Pigure 67.2 represent three categories of project—those that exercised fewer SE activities (Lower Systems
Engi- neering Capability [SEC)). those that exercised moderate levels of SE activities (Middle SEC), and those
that exercised more SE activities (Higher SEC).
• For those projects with Lower SEC, 52?6 delivered a lower level of project performance, as measured by satisfac-
tion of schedule, budget, and pedormance requirements. Only 1696 of these projects delivered a higher level
of project performance.
• For those projects with Moderate SEC, the percentage of projects delivering lower project performance decreased
to 29%, and the percentage delivering higher project performance increased to 2496.
• For those projects with Higher SEC, the percentage of projects delivering lower project performance decreased
to 2096, and the percentage delivering higher project performance increased to 5696.
This clearly shows a positive relationship between the performance of SE activities and project performance.
When the degree of challenge posed by the project, due to factors such as system complexity, project size, and oth-
ers, was also considered, the relationship between SE capability and project performance became even stronger for
the more challenging projects.
THE SYSTEM LIFE CYCLE
The System Life Cycle is the time-phased activity sequence describing system-related activities over the entire lift
of the system. It provides a framework to fulfill the stakeholders needs efficiently. A system life cycle sparty t§t
existence of the system; from Conceptualization to Development to Production to Utilisation to Retirernent.lt
‹o»- sists of (l) a fiusiness aspect—the business case for the system, ensuring that investments result in
aweptabJ returns, (2) a Budget aspect—ensuring that the investments in the system are maiiaged, and (3) a
Technical ast«t— ensuring that the system provides the expected capabilities.
In a generic sense, the system life cycle consists of the following stages:

• Exploratory The project identifies stakeholders' needs and explores ideas and technologies.
Research
• Concept The project develops/refines stakeholders' requirements, explores feasible concepts,
pro- poses viable solutions, assesses technology and risks, selects a concept, and
generates cost and schedule projections.
• Development The project analyzes and refines system requirements, develops the system architecture,
and builds/verifies/validates system prototypes.
• Production
The project produces systems, and inspects and verifies them.
• Utilisation
The user operates the system in the intended environment to satisfy their needs.
• Support
Coincident with the Utilization stage, the users maintain the system to provide contin-
ued operation.
• Revirement
The users remove system froin service and dispose of it responsibly.

Variations of these stages are found in different industries and disciplines. For example, the system life cycle
defined in ISO/IEC/IEEE- 15288 (6] is shown here.

Ùtll ÎZ£ttlOR
Concept stage Development Production Retirement
Support

Transition between the stages of the life cycle are controlled by Decision Gates. Decision Gates are t}rpiCüll\
implemented as reviens (e.g.. SRR-System Requirements Review, PDR-Preliminary Design Review, CDR-Critical
Design Review), and often serve as contractual milestones. Decision Gates are designed to «dd«@ three
questions.
• Does the project deliverable still satisfy the business case?
• Is the project affordable?
• Can it provide the desired capabilities when needed?
The primary objectives of Decision Gates are to: (l) ensure that the elaboration of business and techniCdl
basC‘ lines are acceptable and willlead to satisfactory verification and validation, (2) ensure that the next SUR is
achiev- able and the risk of proceeding is acceptable, (3) continue to foster buyer and seller teamwork, and (4)
SynchroflN project activities.

O PLE SYSTE S AND S STE S OF SYSTE S

As noted earlier, a system is an integrated collection of elements—elements that could be components. processe*.
people, and so on. But what if these elements are systems in and of themselves? Then we have a sy of system
•>
(VOS).
Consider the Air Transport System, as shown in Figure 67.3, It is an integrated set of elements iRC Udin

• Ticketing systems
• Air traffic control systems
 FOUNDATIONS OF SYSTEMS ENGINEERING 1329

Air Transport
Syetem

CO£I(I’
OI
system

Fue
distribution
system
Aircafi Sytem
Airframe Li(c support
system system

Propulsion
system
AJr Crew

Flight control Navigation system

system

Glob si io g Display
system receiver system syste

FIGURE 67.3 System of systems example.

(Source: Ref. 8.)

• Aircraft system
• Airport systems
• Fuel distribution systems
With many of its elements being systems themselves, the Air Transport System is clearly an SoS.
But many of these subsystems may also be systems themselves. The Aircraft System is comprised of subsystems
including an airframe system, propulsion systems, flight control systems, navigation systems, and others. Further the
navigation system is also composed of subsystems such as GPS receivers, displays, user entry devices, and so on.
Critical characteristics of SoS include:

• Operational independence of constituent systems

• Managerial independence of constituent systems
• Geographic distribution
• Emergent behavior
• Evolutionary development processes
This creates a number of challenges for the development and operation of SoS. A question that often arises is
“Who is in charge?" Each constituent system is managed by an independent "owner” to meet needs of independent
stakeholders. Those concerned with the SoS often have no overall authority and/or funding. Thus, they must pur-
sue their objectives through negotiation and management by influence. When the needs of the SoS conflict with
those of the primary mission for a constituent system, the system owners may be unable or unwilling to adapt to
needs of the SoS mission. In addition, as the constituent systems evolve to suit primary mission needs, such evolu-
tion may compromise the SoS mission.
Despite these challenges, the value of SoS is significant. Through the integration of existing systems, new capa-
bilities can emerge—capabilities that make overcoming the challenges worthwhile.
Section“What Is Systems Engineering“
1. SEBoK. Foundations of Systems Engineering. https://www.sebokwiki.org/wiki/Foundations_of_Systems_Engineering
2. International Council on Systems Engineering (INCOSE), Systems Engineering Handbook: A Guide for System Li
Processes and Activities, 4th ed., John Wiley & Sons, Hoboken, NJ, 201S.

Section“The Value of Systems Engineering”

3. Defense Acquisition University, Committed Life Cycle Cost Against Time, Defense Acquisition University, Fort Belvoir, yg
3.1., 1993.
4. Elm, J., and D. Goldenson, ”The Business Case for Systems Engineering Study.- Results of the Systems Engineering
Effective- ness Study,’ Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2012.
5. SEBoK, ‘Economic Value of Systems Engineering”. https://www.sebokwiki.org/wiki/Economic_Value_of_Systemi
_Engineering

Section“The System Life Cycle”

6. ISO/IEC/IEEE, ISO/IEC/IEEE 15288:2015, “Systems and Software Engineering - System Life Cycle Processes,
International Organization for Standardization, Geneva, Switzerland, 2015.
7. SEBoK, “Life Cycle Models”. https:/fwww.sebo1ctviki.org/wiki/Life_Cycle_Models

Section“Complex Systems and Systems of Systems”

8. Dahmann, J., ‘System of Systems Pain Points,’ International Council on Systems Engineering (INCOSE). Las <tg^s. .
used with permission, 2014.
9. SEBoK, ‘Systems of Systems (SoS)”. https://wvrw.sebo1o.vikLorg/wiki/Systems_of_Systems_(SoS)

General

10. SEBoK Editorial Board, The Guide Io the Systems Engineering Body ofKnowledge (SEBoK), v. 2.2, R.J. Cloudier (Editor in
Chie0, The Trustees of the Stevens Institute of Technology, Hoboken, NJ, 2020. www.seboRviki.org (accessed Sept. 01, 2020).
BKMSE is managed and maintained by the Stevens Institute of Technology Systems Engineering Research Center, the
InternatioflZi
Council on Systems Engineering, and the Institute of Electrical and Electronics Engineers Computer Society.
11. International Council on Systems Engineering (INCOSE), S,ystems Engineering Handbooks A Guide for System Life Cycle
Prt›resses and Activities; 4th ed., John Wiley & Sons, Hoboken, NJ,20I5.
12. ISO/lECfIEEE, ISO/IEC/IEEE 15288:2015, ”Systems and Software Engineering - System Life Cycle Processes ’
Internation£ Organization for Standardization, Geneva, Switzerland, 2015.

REFERENCES
13. Dahmann, J., System of Systems Pain Points, International Council on Systems Engineering (INCOSE), Las Vegas, Used
with permission, 2014.
14. Defense Acquisition University, Commited Li Cycft Cost A,goinst Time, Defense Acquisition Univgrsiy, Fort Belvoir,VAi
3.1., 1993.
Elm, J., D. Goldenson, The Business Case for Systems Engineering Study: Results of the Systems Engineering EffectiVeflt
15. Study, Software Engineering Institute, Carnegie Mellon University, 2012.
16. International Council on Systems Engineering (INCOSE), Systems Engineering Handbook: A tsuide fo* System LifRCy:!!
Processes and Activities, 4th ed., John Wiley 8t SOflS, Hoboken, NJ, 2015.
17. International Council on Systems Engineering (INCOSE). 2015. Systems Engineering Handbook; A coid• for SJ
Cycle Processes and Activitiesi POurth Edition, Hoboken NJ. John
Wiley & Sons.
 FOUNDATIONOSF SYSTEMS ENGINEERING 1331

18. ISOf IECf IEEE, lSOfIEC/IEEE 15288:2015, Systems and software engineering—System life cycle processes,
International Organization for Standardization, Geneva, Switzerland, 2015.
19. ISO/IECfIEEE. 2015. ISOf IECf IEEE 15288:2015; Systems and software engineering-System life cycle processes. Geneva,
Switzerland. International Organization for Standardization
20. SEBoK Editorial Board, The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 2.2, R.J. Cloutler (Editor
ln Chief}, The Trustees of the Stevens Institute of Technology, Hoboken, NJ, 2020, Accessed September 01, 2020.
www. sebokwiki.org. BKCASE is managed and maintained by the Stevens Institute of Technology Systems Engineering
Research Center, the International Councd on Systems Engineering, and the Institute of Electrical and Eectronics
Engineers Com- puter Society.
21. SEBoK. Economic Value of Systems Engineering. https:/fwww.sebo1cvtki.org/wiki/Economic_Value_of_Systems_Engineering.
22. SEBoK. Foundations of Systems Engineering. https:ffwww.sebokwiki.org/wlkifFoundations_of_Systems_Englneering
23. SEBoK. Life Cycle Models. https:/fwww.sebokwiki.org/wiki/Life_Cycle_Models
24. SEBoK. Systems of Systems (SoS). hnps:f/www.sebokwiki.org/wiki/Systems_ofqSystems_(SoS)
 CH A PTE R

THE SYSTEMS
ENGINEERING PROCESSES
GARRY J.
ROEDLER GEOFF
DRAPER GREGORY S.
PARNELL
LOUIS E. PAPE
CIHAN DAGLI
EDWARD P. YAKABOVICZ
CHRIS SCHREIBER

The set of Systems Engineering Processes highlighted in this handbook are identified and defined in the following
key references:
• ISO/IEC/IEEE 15288, System life-cycle processes
• INCOSE Systems Engineering Handbook
• Guide to the Systems Engineering Body of Knowledge (SEBoK)
• IEEE 15288.1/ISO/IEC 24748.7, Application of Systems Engineering for Defense Programs
• SAE 1001 Integrated Project Processes for Engineering a System
The processes are important to understand for those performing systems engineering (SE) activities through
the life cycle of a system. The processes are intended to be able to be applied throughout the stages of the life cycle
and can be applied iteratively, recursively, and concurrently.
The processes are ohea grouped into the following groupings that are characterized by focus of the collective
set of processes within the group. The groups are:

• Agreement Processes
• Organizational Project Enabling Processes
• Technical Management Processes
• Technical Processes
Each group is further defined in later sections. Figure 68.1 shows the full set of groups and processes.
 Processes in ISO/IEC/IEEE 15288:2015
›. ..* TECHNICAL ORGANIZATIONAL
TIICtINICAL PROCESSES l MANAGEMENT PROJECT-
PROCESSES ENABLING
PROCESSES

.. '. I ntegrai lori | Project Planning

!. ProJcct Assessment & : ‘ ‘ Infrastructure

Portfollo
Manognrnent Manegem¢nt

Human Reiourcei
Validation i Rlsk Management

ConfiguraUon
Operntloii
Management

I nforniatlon Knowledge
Management

Measurement

TAILORING PI?OCESS

FIGURE 68.1 Processes in ISO/IEC/IEEE J 5288:2015, System life-cycle processes.

TECHNICAL PROCESSES

Purpose

The Technical Processes are used to define the requirements for the system, to transform the requirements into
an effective product, to permit consistent reproduction of the product where necessary, to use the product tO
providt the required services, to sustain the provision of those services and to dispose of the product when it
is retired
from service (ISO/IEC/IEEE 15288:201 S).
Description

The systems en8ineering technical processes described in this handbook are derived frOlTl } O/IEC
15288:2015 and the Systems Engineering Body of Knowledge (SEBoK) (see Fig. 68.2):
• Business or Mission Analysis process
• Stakeholder Needs and Requirements Definition process
• System Requirements Definition process
• Architecture Definition process
• Design Definition process
• System Analysis process
• Implementation process
• Integration process
• Verification process
• Transition process
• Validation process
 THE SYSTEMS ENGINEERING PROCESSES 1335

Legend: fSO/I£C/I£££ 15288 Process EBO optc oJ h A

Business or Mission Analysis Disposal and Retirement

Business or Misiioti Annlysis Process• Disposal Process

System Architecture Stakeholder Needs & Requirements ñfninfennnce Proccu

Logical Architecture Model S o e Nee nn Aeqi/moments teUp
De i io Pro s System Validation
Development mp
QP s MoJern on
Physical Architecture hfodel System Requirements
Development System Reqyu-ements Deji niiion
Process•

Architecture Dcfinition Process •

System Integration Operation of the
fntegreiion Pmcess System
Operation Process

Implementation System Deployment

Itnplenieittation Process T ii P

System Design System Analysis

D i De P s ys e lysis Process •

FIGURE 68.2 ISO/IEC/IEEE 15288:2015 Process Areas.

• Operation process
• Maintenance process
• Disposal process
These technical processes are often grouped into categories according to major product life-cycle stages, as
described in SEBoK Knowledge Areas:
• Concept Definition
• System Definition
• System Realization
• System Deployment and Use
The technical processes are applied to a system of interest in a planned and organized manner from inception
to retirement according to a defined life-cycle model.

Typical Products or Outcomes. Refer to the products and outcomes from the individual technical processes.

Business or Mission Analysis

Purpose. The purpose is to define the business or mission problem or opportunity, characterize the solution
space, and determine potential solutions class(es) (ISO/IEC/IEEE 15288). The business or mission analysis is the
link between enterprise strategy and new stakeholder requirements.
Oescription. Business or Mission AnalysiS is an assessment of the enterprise strategy, business/mission,
vision, strategy, opportunity or problem, and gaps to identify a potential business or mission need.
The Business or Mission Analysis initiates the life cycle of the system of interest (SOI) by:
• Defining the problem or opportunity space
• Identifying the major enterprise stakeholders (funders. developers, customers, users, maintainers, and so on)
• Identifying the environmental conditions and constraints that bound the solution space
• Developing the preliminary system life cycle concepts for acquisition, operations, deployment, support, and
retirement
• Developing the business or mission requirements and validation criteria for the system