An Introduction to Systems Engineering

1
 Overview

• Systems Engineering has emerged as a distinct

professional discipline in direct response to the
increasing complexity of new development projects.

• We will review some of the reasons for the

emergence of this discipline and discuss the tools
and methodologies that have been established as a
means for dealing with increasing system complexity.

2
 Outline

• What is Systems Engineering?

• Emergence of the Discipline
• Role of the Systems Engineer
• The SE Process, Methodologies, and tools
• Setting standards
• SE, the ultimate solution?
• References

3
 What is Systems Engineering?

• It is not fundamental mathematics or strict laboratory

science
• It is a mix of HR, project management, business,
rational decomposition, trade studies, requirements
traceability, integration, testing, verification and
validation, operations, and end of life cycle disposal of
systems
• Standardizes the flow-down and traceability of
specifications for complex products from customer
requirements through production, operation , and
disposal

4
 What is Systems Engineering?
• Systems Engineering is an interdisciplinary approach and
means to enable the realization of successful systems.
• It focuses on defining customer needs and required
functionality early in the development cycle, documenting
requirements, then proceeding with design synthesis and
system validation while considering the complete problem:
 Operations
 Performance
 Test
 Manufacturing
 Cost & Schedule
 Training & Support
 Disposal

5
 What is Systems Engineering?

• Systems Engineering integrates all of the disciplines

and specialty groups into a team effort forming a
structured development process that proceeds from
concept to production to operation.
• Systems Engineering considers both the business
and the technical needs of all customers with the goal
of providing a quality product that meets the user
needs

6
 Emergence of Systems Engineering
Issues
• “The Mythical Man-month”, written by Fred Brooks, who was
the first manager of the OS/360 development team at IBM in
the 1960's:
– People seem to think that people and time are interchangeable and
substitutable resources in projects
– Face it, the addition of people to a late project will only make it later
– In computer systems, the issue of decomposition and system
management reared its ugly head with optimistic programmers
saying "This time it will surely run," or " I just found the last bug."
– The false assumption is that things will take as long as they “ought to
take” and things will work as planned.
– Nothing works out as planned the first time - Systems Engineering
attempts to mitigate this issue

7
 The Role of the System Engineer

• Any engineer acts as a systems engineer when

responsible for the design and implementation of a total
system.
• The difference with “traditional engineering” lies
primarily in the greater emphasis on defining goals, the
creative generation of alternative designs, the
evaluation of alternative designs, and the coordination
and control of the diverse tasks that are necessary to
create a complex system.
• The role of Systems Engineer is one of Manager that
utilizes a structured value delivery process

8
 The Systems Engineering Process
• The major steps in the completion of a typical systems engineering project are the
following: (1) problem statement; (2) identification of objectives; (3) generation of
alternatives; (4) analysis of these alternatives; (5) selection of one of them; (6)
creation of the system, and, finally, (7) operation.

• Some examples of Systems Engineering Process activities are:

• Defining needs, operational concept, and requirements
• Functional analysis, decomposition, and allocation
• System modeling, systems analysis, and tradeoff studies
• Requirements allocation, traceability, and control
• Prototyping, Integration, and Verification
• System Engineering Product and Process control
• Configuration and Data Management
• Risk Management approaches
• Engineering technical reviews and their purposes

9
Systems Engineering Methodologies

10
Systems Engineering Methodologies

11
 Managing Requirements
• Decomposition techniques create “chunks” that can
be handled by design teams and eventually individual
designers
DECOM
DECOMP

TION
RATI
INTEGRA ON
POSITION
OSITION

INTEG

12
13
 System Engineering Process
• The system engineering process begins with a world view; the business or
product domain is examined to ensure that the proper business or
technology context can be established
• The world view is refined to focus on a specific domain of interest
• Within a specific domain, the need for targeted system elements is
analyzed
• Finally, the analysis, design, and construction of a targeted system element
are initiated
• At the world view level, a very broad context is established
• At the bottom level, detailed technical activities are conducted by the
relevant engineering discipline (e.g., software engineering)

"Always design a thing by considering it in its next larger context –

a chair in a room, a room in a house, a house in an environment,
and environment in a city plan" 14
System Engineering Hierarchy

World
View

Domain
View

Element
View

Component
View

15
 System Modeling
(at each view level)

• Defines the processes (e.g., domain classes in OO terminology)

that serve the needs of the view under consideration
• Represents the behavior of the processes and the assumptions
on which the behavior is based
• Explicitly defines intra-level and inter-level input that form links
between entities in the model
• Represents all linkages (including output) that will enable the
engineer to better understand the view
• May result in models that call for one of the following
– Completely automated solution
– A semi-automated solution
– A non-automated (i.e., manual) approach

16
 Two Different Forms

• Software engineering occurs as a consequence of system

engineering
• System engineering may take on two different forms depending
on the application domain
– “Business process” engineering – conducted when the context of
the work focuses on a business enterprise
– Product engineering – conducted when the context of the work
focuses on a product that is to be built
• Both forms bring order to the development of computer-based
systems
• Both forms work to allocate a role for computer software and to
establish the links that tie software to other elements of a
computer-based system

17
“Business Process” Engineering
 Business Process Engineering
• “Business process” engineering defines architectures that will enable a
business to use information effectively
• It involves the specification of the appropriate computing architecture
and the development of the software architecture for the organization's
computing resources
• Three different architectures must be analyzed and designed within
the context of business objectives and goals
– The data architecture provides a framework for the information needs of a
business (e.g., ERD)
– The application architecture encompasses those elements of a system that
transform objects within the data architecture for some business purpose
– The technology infrastructure provides the foundation for the data and
application architectures
• It includes the hardware and software that are used to support the applications
and data

19
Product Engineering
 Product Engineering
• Product engineering translates the customer's desire for a set of defined capabilities
into a working product
• It achieves this goal by establishing a product architecture and a support infrastructure
– Product architecture components consist of people, hardware, software, and data
– Support infrastructure includes the technology required to tie the components
together and the information to support the components
• Requirements engineering elicits the requirements from the customer and allocates
function and behavior to each of the four components
• System component engineering happens next as a set of concurrent activities that
address each of the components separately
– Each component takes a domain-specific view but maintains communication with
the other domains
– The actual activities of the engineering discipline takes on an element view
• Analysis modeling allocates requirements into function, data, and behavior
• Design modeling maps the analysis model into data/class, architectural, interface, and
component design

21
 Product Engineering Hierarchy
Product Requirements
Engineering
System
Human Hardware Software Database Component
EngineeringEngineeringEngineeringEngineering Engineering

Data and Analysis

Function Behavior
Classes Modeling

Data/Class Architectural Interface Component Design

Design Design Design Design Modeling

Construction

22
 Who Sets the SE Standards?
• Depends on your
customer (MIL-
STD, IEEE STD,
Ad Hoc)
• Individual private
programs can be
managed in an
ad-hoc manner
• Government or
large corporate
contracts may
require Mil spec
or other spec to
ensure process
compliance
• INCOSE
ESD.83 23
 Tools

• Functional "thread" analysis involving use of stimulus-

condition-response threads for specifications,
development, testing, and reviews
• N-squared charts, QFD, Timeline analysis, and
Functional Flow Diagrams
• Activity Network Diagrams and professional quality
project and task schedules
• Object-oriented methodologies and distributed
networked IPDT’s

ESD.83 24
 Using Systems Engineering
Methodologies

• Some People think of SE tools and methodologies as

solution providers - plug in a bunch of “stuff” and get
THE answer, design, schedule, cost estimate, etc…
this is wrong.
• Systems Engineering provides a means for
discretizing systems problems into chunks that can
be solved, managed, and implemented - the
scheduling, costs, and interdisciplinary issues are
identified, but continuously change and emerge

ESD.83 25
Is Systems Engineering the Solution to
all of the World’s Systems Problem?

NO...
... but it does help manage some of them

ESD.83 26