Systems Approach to Problems

• Understand and define the problem before attempting to solve it as a system

• Identify the system boundaries, inputs and outputs to a system
• Decompose the system to lower levels (subsystems) with more detail
• Understand the functions that the systems perform to convert inputs to outputs
• Identify and rank all possible solutions prior to selecting an answer
• Looking for hybrid solutions to add to the set of alternatives
• Select a solution, capture the analysis and formulate the subsequent problem or
implementation of the solution
What is a system?

• Basic Principles:
• Everything is connected to everything else
• You cannot eliminate the observer
• Most truths are relative
• Most views are complementary
• Defining Systems
• Elements of a system description
• Example systems
• Purposefulness, openness, hardness, …
• Describing systems
• Choosing a boundary
• Describing behaviour
 Basic Systems Theory Concept

• The “systems” approach is basic for systems engineering. That’s

why it is called “Systems” Engineering not “System Engineering”.

• Systems Concept traced back to the 1800s are

• The whole is more than the sum of its parts
• The whole determines the nature of the parts
• The parts cannot be understood if considered in isolation from the whole
• The parts dynamically interrelated or interdependent
Inter-disciplinary involvement

Software Electronic Mechanical

engineering engineering engineering

Structural ATC systems User interface

engineering engineering design

Civil Electrical
Architecture
engineering engineering
3 Holy Disciplines of Systems Engineering

Systems approach to problems require the use of 3 Holy Disciplines.

Discipline of Uncertainty Reduction

• Reducing vagueness and uncertainty in a requirement to the point at which
definitive specification can be written (Requirements Analysis)
Discipline of Wholeness
• Decomposing a system into its related and interconnected parts and
defining what each system part should do (Functional Analysis/Allocation)
Discipline of Synthesis
• Choosing the best solution that creates optimal wholeness from parts
(Design Synthesis)
 What Systems Engineering includes?

• Integrates all the disciplines and specialty groups into a team effort
forming a structured development process that proceeds from
concept to production to operation.
• Structured technical management and control process used in the
design, development, production and operation of large-scale
complex systems.
• Interdisciplinary approach and means to enable the realization of
successful systems.
• Defining customer needs and required functionality early in the
development cycle, documenting requirements, then proceeding
with design synthesis and system validation.
• 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.
 Main Principles of Systems Engineering

Another paradox of Systems Engineering is that there is no perfect or unique

SE process, but there are common elements – the fundamentals of Systems
Engineering

"Good" Requirements Interface Control

Functions Before Design Baseline Control

Fundamentals
Traceability of Requirements,
of
Top Down Approach Design, and Verification
Systems
Engineering Process

Allocation of Requirements Trade Studies and Optimal

Decision Making

Logical Disciplined Balanced Design

Sequence of Events
Systems Development Activities and Milestones

System Design
Review
Preliminary Design Critical Design
System Requirements Review Review
Review Code Reviews
Unit Tests
Requirements Analysis

System Design System Acceptance

Hardware and Software Tests
Design
Hardware and Software
Development
System integration
Full Operational
and Test Capability (FOC)
Installation, Transition
and Training
Sustaining Engineering
Functional/Physical
Software
Configuration Audits
Specification
Review
Initial Operational
Capability (IOC)

Anticipate effects of commitment Monitor validity and accuracy

The Vee Chart
Pre-Phase A: Concept Studies Phase D(4): SAITL
Domain of Systems Engineering Mission-Level Objectives + System Demonstration
multiple R/A/C concepts + and Validation
Mission Validation Plan

Phase A: Concept Development Phase D(3): SAITL

Single System-level R/A/C Integrate Subsystems and
+ Trade Studies + System Verify System Performance
Verification Plan

Phase B: Preliminary Design Phase D(2): SAITL

Subsystem-level R/A/C Integrate Components and
+ Interfacing + complete technology Verify Subsystem Performance
+ Subsystems Verification Plan

Phase C(1): Final Design and Fabrication Phase D(1): SAITL

Domain of Engineering

Final Detailed Design Verify Component Performance

Phase C(2): Final Design and Fabrication

Design

Fabric hardware and software

The 11 SE Functions
Input: Mission Other SE Functions:
Objectives (Starts Pre- • Interfaces
Phase A) Validate and Verify
•Mission Environment
•Resource Budgets
Derived •Risk Management
Architecture
Requirements /Design •Configuration Management
•Reviews

Validate and Verify Validate and Verify

Concept
of
Operations

Output: Proceed to
next Phase, ending at
Operations (Phase E)
 Systems Engineer’s Responsibilities

Activities Contract Deliverable Items

• Analyze and specify system • Operational Concept

requirements • Systems Engineering Management Plan
• Define system operational concept • System and segment specifications
• Define system external interfaces • Software Requirements Specifications
• Define system and subsystem • Subsystem Requirements Specifications
architecture •
–
Trade Study Reports
Allocate performance requirements
–
• Systems Requirements Review (SRR)
Model system performance
• • System Design Review (SDR)
Perform design trade studies
• • System Design Description (SDD)
Develop system and subsystem design
• • Software Specification Review (SSR)
Define system test requirements
• • Preliminary Design Review (PDR)
Manage system technical baseline
• • Plans (training, test, deployment)
Support design/development and I&T
• • Performance requirements allocation
Orchestrate specialty engineering
support • User manuals
• Integrate technical discipline processes • Other data deliverable items
• Ensure system acceptability/usability
 Systems Engineering Interfaces

Status,Plans, Issues Specifications, Test Guidance

Integration
Program Test Plans, Procedures, Problems
Direction & Test
Manager
Engineering
SOWs, Technical Status
Support Requests, Review Materials Subcontract
Management
Specifications, Architecture
Assessments of Engineering Changes
Software Configuration
Designs, Estimates, Specification Inputs Change Requests, Reports
Engineering Control

Systems
Engineering
Technical Direction Standards, Specifications
Product
Subcontractors Technical Responses Reviews, Audits Assurance

Specifications, Architecture Product Requirements Product

Hardware
Development
Engineering Designs, Estimates, Specification Inputs Data, Manuals, Products
Labs

Bid Strategy Coordination Requirements, Schedule

Logistics
Marketing
Bid Strategy, Check & Balance Integrated Logistics Plans Support
System Behaviour
Behavior is perceived by the an external observer (usually user or external
entity).

Behaviour

Functionality ..... What functions the system performs

+
Time-Related
Performance ..... How Well the functions should
perform

Since behavior is defined by both functionality and performance, always define the
functionality with associated performance criteria !
 Life Cycle Functions
Disposal ensures that the Training achieves and maintains Verification (Test) evaluates
disposal of decommissioned, the knowledge and skill levels progress and effectiveness of
destroyed, or irreparable system necessary to efficiently and evolving system products and
components meets all applicable effectively perform operations processes, and measures
regulations and directives. and support functions. specification compliance.

Concept
Development is Support
the user function includes the
and includes activities
activities necessary to
necessary to provide
satisfy defined operations
operational support,
objectives and maintenance,
tasks in different logistics, and
environments. material
management.

Manufacturing/Production/
Development includes the Deployment (Distribution) includes the Construction includes the
activities required to activities necessary to initially deliver, fabrication of engineering test
evolve the system from transport, receive, process, assemble, models, low rate initial and full-rate
customer needs to product install, checkout, train, operate, house, production of systems and end
or process solutions. store, or field the system to achieve full items, or the construction of large
operational capability. or unique systems or subsystems.
Definition of Stakeholder
• The stakeholders include all the people, organizations and institutions that
are a part of the system environment because the system provides some
benefit to them and they have an interest in the system. This includes end
users, operators, bill payers, owners, regulatory agencies, victims,
sponsors, maintainers, architects, managers, customers, etc.

• Example: Definition of Stakeholder for Boeing 777

– Users: passengers that fly on the airplane
– Operators: fight crews and mechanics
– Bill payers: airline companies
– Owners: stockholders of these companies
– Regulators: FAA
– Victims: people living near the airports and competing manufactures
– Sponsor: corporate headquarters

A stakeholder is anyone who can drive a stake through your heart

if you forget their pet project.
Success Ratio of IT Projects

RESULT: Requirements Analysis and Management is very IMPORTANT

for the success of IT Projects!
 Our “System Definition”

• Simple Definition
• A system is a construct or collection of interrelated elements,
attributes and relationships that together produce outputs not
obtainable by the elements alone.
• The outputs include system level qualities, properties,
characteristics, functions, behavior and performance.
System

Products
Input System
Elements Output

People Processes
Multiple System Views

User’s Vision:
What needs the system fulfills / How the system is used
Operational
f1
f2
f3
Phase 1 Phase 2 Phase 3
Mission Timeline

User, Function Analysist and

Architect’s Shared Vision

Functional Physical
System
Capabilities

F1 F2 F3
Reqts Reqts Reqts

Function Analysist’s Vision: Architect’s Vision:

What the system does What the system contains
 Multiple System Views, cont

• Systems Engineering requires iteration through complementary views.

– Operational View
• The operational view focuses on how the system will serve its users.
• It can be thought of as the way the user views the system.
• The operational view is the key to establishing operating requirements for the
system.
• The operating requirements define how well and under what conditions the system
must operate.
– Functional View
• The functional view focuses on what the system does; what it must do to produce
the required operational behaviour.
• The functional view shows inputs, outputs, states and transformation rules.
– Physical View
• Also known as the architectural view, focuses on what the system contains (e.g.,
how it is constructed; how many people are included within it).
 Multiple System Views, cont
• All three views are needed for a complete understanding of the system.

Operational Functional Physical

f1
System
f2 Capabilities

f3
Phase 1 Phase 2 Phase 3 F1 F2 F3
Mission Timeline Reqts Reqts Reqts

Operational View Functional View Physical view

Requirements about Requirements about inputs, outputs, Requirements about the
sequences of functions interfaces and software. The hardware, software,
and operating procedures. functional view also provides connections, packaging etc.,
information about the numbers and that will be required.
• Sequential kinds of personnel required. • Buildable
imperatives • What has to be done and implementation
• Parallel possibilities when • Physical partitioning
• Maximum cohesion within
functional groups
• Minimum communication
between functional groups
Elements of the System Technical Baseline:
Operational Need Statement
•The problem the system is to solve
Operational Concept Document
•Constraints and preconditions
Requirements
•What is to be done, how well and under what conditions
Requirements Rationale
•Why these requirements and none other
Design Description
•How will the requirements be met
Design Rationale
•Why this design and none other
External Interfaces
•What is expected to cross the system boundary from its environment
Internal Interfaces
•What is expected to pass between subsystems inside the boundary
Trade Studies
•Why this product and none other
 Exercise: Message Processing System (MPS)

Operational Need Description

• A Message Processing System will be developed to support a joint operation of the
USA and UK military. The system is to be used on a remote island in the eastern
Atlantic ocean to process communication traffic (messages) originating at USA and UK
military facilities on the remote island and surrounding islands. Messages are also
received from the Global Military Communications System (GMCS) for distribution to
the local military units. Because of security considerations, MPS must provide a
capability to encrypt/decrypt messages.
• The messages originating locally are reviewed by analysts who determine the security
classification of the messages and select which messages are to be forwarded to the
USA and UK via GMCS. All local messages are to be stored on the MPS system for
subsequent retrieval, display and printing by the analysts, as needed. On-line storage
is required for 60 days of messages. Messages over 60 days old are archived to tape
storage.
• The messages received from the global system are distributed to the local units via the
local Inter-island Communication System (IICS).
• The MPS must provide an analyst training capability which can be used during normal
operations without disturbing message processing.
 Exercise: Operation Need Description (Continued)

• There are three sources of locally generated messages:

1. Messages received from analysts with on-line access to the MPS system.

2. Messages received from analysts via a local inter-island communication

network which has an interface to the MPS system.

3. Messages stored on 3 1/2” diskettes which are delivered by courier twice a

day.

• MPS must be operational on a continuous basis, 24 hours per day, unless

temporarily shut-down by specific operator intervention.

HW1: System level Operational, Functional and Physical View of MPS Sytem
can be derived from Operational Need Description.
 System Effectiveness
System Effectiveness depends on
• Reliability :
Will the system be up over the time interval required--is a back up needed?
• Availability:
Will the system be available when it is needed?
• Performance:
Will the system perform its mission with a high probability of successfully performing as
required?

S y s te m E ffe c tiv e n e s s
P ro b a b ility o f s u c c e s s w ith fa ilu re
a n d fa ilu re re co v e ry

R e lia b ility A v a ila b ility P e rfo rm a n c e

S ys te m s w ith S u p p o rta b ility P ro b a b ility o f su c c e ss
re d u n d a n cy M a in ta in a b ility w ith o u t fa ilu re

System Effectiveness = RAP

• R = Probability (System is “up” over time interval)
• A = Probability (System can be committed to the mission at point in
time)
• P = Probability (Mission success when system is “up”)