Module G

Functional Analysis

CC04264377.ppt
Mod G

The Systems Engineering Process

Per INCOSE Systems Engineering Handbook

Process input
Customer needs/
objectives/
requirements
Missions
Measures of
effectiveness
Environments
Constraints
Technology base
Outputs from prior phase
Program decision
requirements
Requirements applied
through specifications
and standards

Requirements analysis
Analyze missions and environments
Identify functional requirements
Define/refine performance and design
constraint requirements

Control
loop

Requirements loop

Functional analysis/allocation
Decompose to lower-level functions
Allocate performance and other limiting requirements
to all functional levels
Define/refine functional levels
Define/refine functional interfaces (internal/external)
Define/refine/integrate functional architecture

Trade-off studies
Effectiveness analyses
Risk management
Configuration management
Interface management
Data management
Performance based
progress measurement
SEMS
TPM
Technical reviews

Design loop

Verification Loop

CC04264378.ppt
Mod G

System
analysis
and control
(balance)

Synthesis
Transform architectures (functional to physical)
Define alternative system concepts, configuration
items and system elements
Define/refine physical interfaces
(internal/external)
Select preferred product and process solutions

Process output
Phase dependent
Decision support data
System architecture
Specifications and baselines

Functional Analysis
A structured approach for describing how a system
might be used
Defines a functional architecture for which system
products and services can be designed
Performed to a depth needed to support synthesis
Identifies and arranges lower-level functions needed to
accomplish parent requirements
Arranges function in a traceable, logical sequence

CC04264379.ppt
Mod G

Functional Analysis (cont)

Includes all contractually specified usage modes
Includes functions necessary for the product or service
to operate properly
Used to analyze time-critical requirements
Involves iterations

Performance requirements identified in functional analysis

serve as design criteria for the system
CC04264380.ppt
Mod G

Functional Flow Decomposition

Number One tool for systems engineers
Understanding how products and services might be used
Discovering innovative solutions
Focusing attention away from what the product looks like
(stop designing)
Overcoming design road blocks

CC04264381.ppt
Mod G

Elements of Functional Analysis

Functional decomposition
Functional sequencing
Information/data flow
Interface definition

CC04264382.ppt
Mod G

How Products Might Be Used

Key word is used - not do
Do tends to evoke current (and limited)
functionality
Successful products often have uses not
anticipated by initial developers

CC04264383.ppt
Mod G

What Are Functions?

Functions describe how users use a product
or service
A functional statement begins with a verb and
follows with a direct object
Fly airplane
Surf internet
Enter password
Pay debts

CC04264384.ppt
Mod G

What Are Functions? (cont)

As one moves away from user-interface
level and into lower levels of detail,
functional descriptions become statements
about what the system does
Compute coordinates
Sense hydraulic pressure
Track target

CC04264385.ppt
Mod G

Functional Decomposition
Top-level functions at some common level
are identified
Top-level functions are composed of
lower-level functions that describe top-level
functions in more detail

CC04264386.ppt
Mod G

Functional Decomposition
Primary Steps
Brainstorm functions performed
Pick out the five to ten truly top level functions
and arrange in sequence (if appropriate)
Place the other functions below the
top-level functions

CC04264387.ppt
Mod G

Naming Functions
Function name should identify the action or transformation
accomplished by the function
Avoid the pitfalls of provide and accept functions
Functions are usually identified in the verb-noun syntax:
e.g., monitor status
Poor
Provide diagnostics
Provide utility power
Provide aircraft position
Accept pre-flight data
Accept status
Accept crew inputs

CC04264388.ppt
Mod G

Good
Perform bit
Control utility power distribution
Compute aircraft position
Store pre-flight data
Monitor system status
Interpret crew inputs

Functional Flow Block Diagrams

Car Example
Drive car
Accelerate car
Decelerate car
Turn car
Start car
Stop car

CC04264389.ppt
Mod G

Functional Flow Block Diagrams (cont)

Car Example
Drive car

Start
car

CC04264390.ppt
Mod G

Accelerate
car

Turn
car

Decelerate
car

Stop
car

Functional Flow Block Diagrams (cont)

Car Example
Drive car

Start
car

Accelerate
car

Place gearshift
in park

CC04264391.ppt
Mod G

Turn
car

Turn on
ignition

Decelerate
car

Select
drive

Stop
car

Functional Flow Block Diagrams (cont)

Car Example
Drive car

Start
car

Accelerate
car

Place gearshift
in park

Turn
car

Turn on
ignition

Decelerate
car

Select
drive
Select
reverse

CC04264392.ppt
Mod G

Stop
car

Functional Decomposition
Practical Approach
Post-it notes are very useful
Write functions on post-it notes
Insist on the verb-noun format
Let the team arrange post-it notes
5 to 9 top-level functions
Create additional top-level functions, if appropriate

CC04264393.ppt
Mod G

Functional Decomposition (cont)

Practical Approach
If there is contention about where a function belongs,
make a duplicate post-it note and put both places
There may be different decompositions depending upon
the context
Discourage premature allocation to physical architecture
When you get uncomfortable about further decomposition,
it is usually time for trade studies

CC04264394.ppt
Mod G

Other Uses of Functions

Operational concepts
All about how a system is used
Scenarios
Supply the contexts in which the functions
are performed

CC04264395.ppt
Mod G

Innovation via Reallocation

Traditional view
Detect
target

Track
target

Shoot
missile

Guide
missile

Illuminate
target

Guide
missile

Illuminate
target

A different view
Detect
target

CC04264396.ppt
Mod G

Track
target

Shoot
missile

Triad of an Evolving Concept

Joint development and evolution of:
Functional decomposition
Operational concept
Functional allocation

CC04264397.ppt
Mod G

Overcoming Design Roadblocks

Problem:
How to design a set of files used by operations analysts
to set up a simulation
Two alternate flows or scenarios
AB C D
AB D

EF G
E F G

The functional view changed the engineers view of the problem

CC04264398.ppt
Mod G

There Is No Right Way

Command centered view
Turn

Go straight

Accelerate

Decelerate

Increase
power

Ship center view

Deflect
rudder

Reverse
screws
Accelerate

Increase
power

Decrease
power

Turn on air
conditioning

Balance major components of the system at the top level functions

CC04264399.ppt
Mod G

Other Significant Benefits

Explaining why your design makes sense
Developing functional requirements
Controlling the level of detail
Helps with team building
And a caution:
Functional decomposition is a tool,
and tools have limitations

CC04264400.ppt
Mod G

Variations With Life-Cycle Phase

Pre-concept exploration - identify top-level functions
of your system and others with which your system
must work (no designs)
Concept exploration - develop and analyze benefits
of alternate functional decompositions and allocations
(multiple alternative design concepts)
Risk reduction and EMD - decompose and allocate
functions to lower levels of design (single design)

CC04264401.ppt
Mod G

An EMD Example for Electronics

Assumptions
Feasibility is established
Conceptual designs exist
Specifications exist
Task
Develop a system that meets
the specifications

CC04264402.ppt
Mod G

Electronics Functions
Functions transform a given set of inputs
into a set of outputs in the performance
of useful activity
Functions are enabled through the use of
hardware and software in the systems
physical architecture

CC04264403.ppt
Mod G

Scoping the System Design

Establish general information about the system
Extract general design requirements from the
specification
Summarize a written description of the system
(appropriate to the defined level of detail) in terms
that an outsider can understand
Application
Functionality
Interfaces
Behavior
CC04264404.ppt
Mod G

Scoping the System Design (cont)

Establish and summarize the main system
functions in a list
Identify a first pass functional hierarchy
Iterate the function list and hierarchy as the
design matures
Decompose to lower level functions
Allocate performance and other limiting
requirements to all functional levels

CC04264405.ppt
Mod G

Specification for a Collision Warning System

1.

General - A Collision Warning System (CWS) for service in an automobile shall provide the
driver with notifications of impending collision

2.

Operation - The CWS shall come on automatically with the application of vehicle power

2.1

Responsiveness - The CWS shall provide prompt alarm to the driver within a time sufficient
to avoid an accident when a closing probability of collision is detected. False alarms shall be
minimized

2.2

Hazard Warnings - Warning in the form of audio and visual indications shall be made
available to the driver when a hazardous condition is detected. The same warning indicators
shall be used a s indicators for build-in-testing

2.2.1 Audible Warning - The audible warning shall consist of a pulsing tone with a pulse
frequency proportional to the proximity from the hazard. A faster pulse rate shall indicate a
closer distance to the hazard
2.2.2 Visual Warning - The visual warning shall consist of a continuously displayed red lamp on
the instrument panel while the hazard exists
2.3

Fault Conditions - A fault in any part of the CWS shall be indicated on a front panel lamp

2.3.1 Fault Notification - The fault notification shall consist of a continuously displayed while lamp
on the instrument panel while the CWS fault exists
2.4

CC04264406.ppt
Mod G

Built-In-Testing - The CWS shall be capable of performing both Power-up Built-In-Test

(PBIT) as well as operator-initiated testing (OBIT) for the detection of CWS faults

CWS Functional Hierarchy

1 CWS functions

CC04264407.ppt
Mod G

1.1 Sense objects

1.2 Test unit

1.1.1 Detect objects

1.2.1 Initiate tests

1.1.2 Compute parameters

1.2.2 Compute status

1.1.3 Warn/caution driver

1.2.3 Advise driver

Scoping the System Design (cont)

Determine the location of the system under design in the
overall system
Establish the system in its environment
Describe the environmental systems (externals)
Write a general description of the interfaces between the
system and the environmental systems
Short description of the interface between each
environmental system and the system (1-4 lines of text)
General description of the major signals in each flow

CC04264408.ppt
Mod G

Define the System in Its Environment (SIE)

Draw the boundary of the system in its environment
Draw the external systems from which inputs are received
Draw the inputs from the external systems to the system under design
Draw the external system to which outputs are sent
Draw the output from the system under design to the external systems
Detailed descriptions should be updated incrementally throughout
development

External system 1

External system 1

External system N
CC04264409.ppt
Mod G

Major
inputs

System
under
design

Major
outputs

External system M

CWS in Its Environment

Objects

ECHO_RF

POWER_IND

Veh_Elect
SPEED_DATA

RF_PULSES

Collision
Warning
System

Objects

FAULT_LOG

Veh_Elect
VIS_WARN
AUD_WARN

Driver

CC04264410.ppt
Mod G

TEST_REQ

AVIS_CAUT
FAULT_NOTE

Driver

Design Data Descriptions for CWS

Collision Warning System (CWS) - The system under design; a physical unit to be installed into an
automobile to warn the driver of impending collision with objects
Objects - Any physical body (moving or stationary) that may be considered a harmful threat to the vehicle
and its passengers. Receivers RF_PULSES and emits ECHO_RF
Veh_Elect - Automobile electrical system. Provides an indication of applied power and vehicle speed
information; receives fault information from CWS for recording in a centralize diagnostic location
Driver - Consumer of CWS warning notifications. Makes test requests for initiated CWS built-in-testing
ECHO_RF - Radio frequency signals reflected from objects
POWER_IND - Signal to CWS that power has been applied to vehicle electrical system
SPEED_DATA - Continuous present speed of automobile
TEST_REQ - Test request signal from driver to CWS for initiating build-in-testing
RF_PULSES - Radio frequency pulses transmitted by CWS to the environment (specifically, objects)
FAULT_LOG - Record of faults detected and isolated by CWS built-in-testing
VIS_WARN - Visual warning to driver of impending collision with an object
AUD_WARN - Audible warning to driver of impending collision with an object (work in conjunction with
VIS_WARN)
VIS_CAUT - Visual caution to driver of potential impending collision with an object
FAULT_NOTE - Notification to driver of fault in CWS
CC04264411.ppt
Mod G

5 Minute Exercise
Identifying a System in Its Environment
Using the specification paragraph below, list the external environmental elements for
the System in Its Environment. Then draw their representative boxes (externals only)
along with simple data flows to and from the EWS. Label each box and data flow with
appropriate names.
1.0.1 The Early Warning System (EWS) shall receive signals from an external sensor. The
EWS shall examine the signals via a status processor and check if the calculated values are
within specified ranges stored in system memory. If the value of a processed signal is out of
range, the system shall issue a warning message on its operator terminal and post an
audible alarm at a central alarm facility. If the operator does not respond to this notice within
one minute, the system shall record the event on its removable mass storage cartridge, print
a fault message on a printing facility, and stop monitoring the particular signal.
Environmental Elements

CC04264412.ppt
Mod G

EWS

Structured Analysis and Design

Technique (SADT)
SADT provides a strong graphical representation of system
requirements coupled to a disciplined structured design technique
SADT can be used to
Define/refine interfaces (internal and external, functional
and physical)
Define/refine/integrate architectures (functional and physical)
Communicate system design information among analysts and users
Document the satisfaction of requirements
Review, approve, and control design documentation
SADT consists of two principal parts
Structured analysis - a graphical box-and-arrow diagramming
language
Design technique - the discipline of thought and action that must be
learned and practiced for the graphics to be used effectively
CC04264413.ppt
Mod G

Basic SADT Design Technique

Each diagram tells a story
Whenever certain data become available, boxes become active
and perform their functions
A box activation is a way in which a box can operate using some
of its inputs and controls to produce some of its outputs
Note: for any specific activation
At least one input must be used
At least one output (different from the input) must be produced

Decomposition means breaking a subject (box) into pieces

(several boxes in a diagram)
SADT provides an iterative and a hierarchical process

CC04264414.ppt
Mod G

Example of a SADT Functional Flow Diagram

Air traffic identification system
Take another snapshot of signal
Air
traffic

Detect
traffic

Detection flag

External
scan signal
characterization
data

Control
tower

Identified
traffic

CC04264415.ppt
Mod G

Info
transmissions
out

Identify
traffic
Report
info

Air
traffic

SADT: Information Flow Analysis

An information flow is a construct which can contain grouped
data items, events, conditions and other information flows, all
treated as a single entity
Every output to the environment must be produced by at least
one function
Every input from the environment enters into at least one of
the functions
Every output from a function must be produced by one of the
subsystem functions
Every input to the logical subsystem should enter into at least one
of the subsystem functions
The names of the inputs should differ from the names of the
outputs (unless there is a reason that they remain the same)
Every intermediate input (those not obtained from the environment)
to a function must be produced by one of the other functions
CC04264416.ppt
Mod G

SADT: Information Flow Analysis (cont)

The information can be used in two ways
(A) Elemental items can be grouped together into
an information flow
(B) Information flows can be broken down into more
detailed element items
Case A

or

Case B

Radar status
Comm status
Nav status

CC04264417.ppt
Mod G

Radar BIT commands

Equipment status

BIT commands

Comm BIT commands

Nav BIT commands

Hierarchical Decomposition of Flows

General
The quantity of variables flowing in the diagrams is often large
Variables must be grouped into meaningful information flows
Ease the load of data in the diagrams
Ease the readability of the diagrams and their understanding

Rule of thumb: where possible, all data uniquely flowing

between two modules should be grouped into a single
information flow

CC04264418.ppt
Mod G

Hierarchical Decomposition of Flows (cont)

Characterization of variable in a new system
Define the main logic flows between the system and its
environment using information flows
Identify the elements of the main logic flows
Define every flow as an information flow (requires writing a
description for each component)
List the contained elements in form for the information flow

Example: Built-in-test status contains

Module ID
Fault ID
Failed test numbers
CC04264419.ppt
Mod G

Hierarchical Decomposition of Flows (cont)

Draw the main flows from the external modules inward toward
the internal modules
If all the components of an information flow are connected
to a single module, draw the flow directly to this module
If the components of the information flow are connected to
a number of modules, draw a connector and connect to it
the corresponding component flows

CC04264420.ppt
Mod G

Hierarchical Decomposition of Flows (cont)

Draw the main flows from the external modules inward
toward the internal modules
If all the components of an information flow are
connected to a single module, draw the flow directly to
this module
If the components of the information flow are connected
to a number of modules, draw a connector and connect
to it the corresponding component flows

CC04264421.ppt
Mod G

Steps for Completing the Top-Level System

Functional Architecture
Use the system in its environment as a starting point
Draw and label the top-level system function boxes
Connect the function boxes to the relevant inputs and
outputs of the environment (and to each other, where
appropriate)

CC04264422.ppt
Mod G

CWS in Its Environment

Objects

ECHO_RF

POWER_IND

Veh_Elect
SPEED_DATA

Driver

CC04264423.ppt
Mod G

TEST_REQ

Sense objects

CWS
Top Level
Functions

Test units

RF_PULSES

VIS_WARN
AUD_WARN
VIS_CAUT

Objects

Veh_Elect

FAULT_LOG

Driver
VIS_WARN
AUD_WARN
AVIS_CAUT
FAULT_NOTE

CWS in Its Environment

Clarity and Simplicity Are Important

Objects

ECHO_RF

POWER_IND

Veh_Elect
SPEED_DATA

Driver

TEST_REQ

Sense objects

CWS
Top Level
Functions

RF_PULSES

VIS_WARN
AUD_WARN
VIS_CAUT

Driver

VIS_WARN
AUD_WARN
AVIS_CAUT
FAULT_NOTE

Test units

Veh_Elect
FAULT_LOG

CC04264424.ppt
Mod G

Objects

Steps for Completing the Detailed System

Functional Architecture (cont)
Collective experience and expertise is required to adequately
partition a functional design
Guidelines for finding the required depth of design:
Design simplicity should be maintained as much as possible
at any level of detail
Postpone design details to the lower levels
Perform the system design for only that level of detail required
to fully satisfy (and test, if computer-based simulation tool is
available) requirements
Use another design drawing, if necessary, to develop lower
level details of the design (e.g., another design drawing for
each subsystem)
CC04264425.ppt
Mod G

Steps for Completing the Detailed System

Functional Architecture (cont)
Create a diagram for each top-level system function
Include only the environmental elements relevant to the
particular function
Include any elements that use data from or produce data for
the top-level function
Include only the data/information flows used and produced by
the particular function
Connect the function together using SADT techniques, adding
appropriate labels to each data/information flow
Modify the function list and hierarchy of the lower-level
functions required to consume input an produce outputs of each
top-level system function
Iterate the above steps to fully define required system functionality
CC04264426.ppt
Mod G

CWS Detailed List of Functions

Sense Objects
Detect objects
Compute parameters
Warn/caution driver
Require pulse
Generate pulses
Detect echoes
Screen echoes
Detect closing
Warn driver
Caution driver

CC04264427.ppt
Mod G

Test Unit
Initiate tests
Compute status
Advise driver
Request pulse
Generate pulses
Detect echoes
Screen echoes
Detect closing
Warn driver
Caution driver
Detect test requirements
Generate tests
Scale signals
Sense fault
Indicate fault

CWS Sense-Object Function

Sense Object
POWER_IND

Request
pulse

PULSE_CMDS

Generate
pulse

Objects
SYNC

Veh_Elect
SPEED_DATA

DIG_SIGS

Objects

RF_PULSES

Detect
echoes

SYNC

DETECTIONS

Screen
echoes

CONFIRMATIONS

Detect
closing

Warn
driver

ECHO_RF

Driver
SYNC

OBJ_DATA

Reference_Table

CC04264428.ppt
Mod G

VIS_WARN
AUD_WARN

Caution
driver

VIS_CAUT

CWS Test-Unit Function

Test Unit
RF_PULSE
SYNC

TEST_CMD

Driver

Detect tests
request

SCALE_SEL

TEST_SEL

Invoke
tests

Generate
tests

Scale
signals

TS

PI
SPEED_DATA

Detect
echoes

SYNC

DETECTIONS

Screen
echoes
OBJ_DATA
Reference_Table

CC04264429.ppt
Mod G

Sense
fault

Detect
closing

Indicate
fault
Warn
driver
CONFIRMATIONS

SPEED_DATA

FAULT_LOG

Veh_Elect

FAULT

DIG_SIGS

Veh_Elect

STRF

SELF_TEST_RF

POWER_IND

STRF

Objects

SYNC

TS
TEST_REQ

Generate RF_PULSES
pulse

PULSE_CMDS

Request
pulse

PI

Caution
driver

FAULT_NOTE
VIS_WARN
AUD_WARN

Driver
VIS_CAUT

CWS - Description of Functions and

Data Flows
Request Pulse - Upon receiving POWER_IND signal from Veh_Elect it issues PULSE_CMDS to the
function Generate Pulses
Generate Pulses - Upon receiving specific pulse commands for the Request Pulse function, it broadcasts
RF_PULSES into the environment
Detect Echoes - Senses ECHO_RF energy in the environment. Upon the detection of signals, it
produces digital representation of the signals as DIG_SIGS
Screen Echoes - Filters potential objects (synchronized with the Generate Pulses function) from hack
ground noise. It produces confirmed DETECTIONS based on a comparison of DIG_SIGS (digital signals)
with OBJ_DATA (object data) in the Reference_Table data store
Detect Closing - Compares DETECTIONS to vehicles SPEED_DATA to resolve likelihood of collision.
Produces CONFIRMATIONS based on closure thresholds (object range vs. vehicle speed)
Warn Driver - Upon exceeding threshold for a warning from Detect Closing function, produces visual
warning (VIS_WARN) and audible warning (AUD_WARN) to Driver
Caution Driver - Upon falling within threshold range for a caution from Detect Closing function, produces
visual caution (VIS_CAUT) to Driver
Reference Table - Data store for object signatures used in the filtering of digitally encoded detections
from background noise and erroneous echo detections
CC04264430.ppt
Mod G

N2 Diagram
Maps interfaces between all
functions
Pinpoints areas where conflicts may
arise between functions

CC04264431.ppt
Mod G

N2 Diagram
Input
F1

F1

F2

F2

F2

F5

F3

F3

F6

Output

Output
F2

F1

F5

F4

F4

F3

F5

F5
F6

Input
Blank entry indicates no interface
CC04264432.ppt
Mod G

N2 Diagram for CWS Sense-Object Function

Request PULSE
pulse
CMDS

Simple in this case

Generate
pulse

Quickly becomes large and

complex
Detect
echoes

Not particularly good for

presentations

DIG
SIGS
Screen
echoes

Spread sheets work well

DET

Detect
closing

CONF

CONF

Warn
driver
Caution
driver
CC04264433.ppt
Mod G

Summary of Functional Analysis

Structured approach to describing how a system is used
and what is does
Function name should identify the action or transformation
accomplished by the function using verb-noun syntax
Functional analysis helps develop
Functional requirements
Functional allocations
Functional architecture

CC04264434.ppt
Mod G

Summary of Functional Analysis (cont)

Functional decomposition helps
Develop operational concepts
Develop functional sequences
Break design roadblocks
Develop innovative solutions
Explaining a design
Controlling the level of detail
Serves as a team-building activity
CC04264435.ppt
Mod G

Summary of Functional Analysis (cont)

Functional analysis tools
Tools are aids, not the process nor a
substitute for thinking
Modify the tool to fit your needs
Tools have limitation

CC04264436.ppt
Mod G