Structured Analysis
Infsy 570
Dr. R. Ocker
What is structured analysis?





It focuses on specifying what the
system or application is required to do.
Elements of structured analysis
. Graphical description
. Data Flow Diagrams
. Data Dictionary: definitions of
elements in the system
What is structured Design?


Focus on the development of
software specifications
Three primary modules in SDLC
(1) Analysis
(2) Design
(3) Implementation

various phases within each module
Systems Analysis
A. Objectives of System Analysis

determine if current system is in trouble

determine appropriate alternatives

make recommendation
To establish in detail what the
system is to do







objectives
costs
benefits
implementation process
organizational changes required
defines who the USERS are
Their input and output
Phase 1 Identify problems,
opportunities, and objectives




analyst looks at what is occurring in the
business
look for problems and opportunities
People involved:
users, analysts, systems managers
Phase 1







Activities include:
interviewing user management
summarizing knowledge obtained
estimating scope of project
documenting results
Output of this phase:
feasibility study (report) containing a
problem definition and summarizing the
objectives
Feasibility Study: The Basic
Tasks





Problem Orientation
. Define the problem
. Establish system objectives
. Identify the users
. Establish functional scope
Feasibility Study

Alternative Specification
–
–
–
–
Propose options
Cost-Benefit analysis
Assess project risk
Recommend
Feasibility Study




Technical
Do we have the capability to develop
the
system?
Does the necessary technology exist?
Does the proposed system have the
right:
– response time, interface,

Can the system be expanded?
Feasibility Study





Economic
Is there an economic payoff?
cost of hardware/software/ other
benefits in terms of reduced costs
opportunity costs
Phase 2 Determining Requirements
Phase 3 Analyzing System Needs

goal - determine the requirements of the
new system -- must obtain a consensus
from the user community on the ideal
information system
Requirements
Analyst must understand:
a. the CURRENT SYSTEM
b. what information users need to
perform their jobs
c. why and how current system is no
longer effective
 analyst derives new system
requirements from an analysis and
synthesis of a,b,& c

Requirements

People involved in this phase:

analysts, users - operations managers
and workers
Major steps in determining
requirements for new system
1. Requirements capture and
analysis



The process of deriving system
requirements
accomplished through observation of
existing systems, discussions with
potential users and task analysis.
very time consuming step
Analyst needs to know details of
current system functions





who - the people who are involved
what - the business activity
where - the environment in which the
work occurs
when - the timing of the activity
how - how the current procedures are
performed
2. Requirements definition




document containing an abstract
description of:
- user functions the new system is
expected to provide
- constraints under which the system
must operate.
only specifies the external behavior of
the system - does not cover any
implementation considerations.
2. Requirements definition

written without using any specialized
notations so that it is understandable by
non-systems
professionals
(e.g.,
potential users, system procurers).

becomes the focus for much of the work
involved in developing system
requirements.
3. Requirements specification



document that details the functions that
the system is to include - sometimes
called a functional specification
written using a formal systems
specification language
more precise than the requirements
definition - for use by the technical staff
3. Requirements specification

creation of this document might be
carried out in parallel with some highlevel design (this may be essential) as
the design and requirements activities
influence each other as they develop.
Tools used to determine
requirements

sampling and investigating hard data,
interviewing, questionnaires,
observation, and prototyping
CASE tools


DFD - data flow diagram - used to chart
the input, processes, and output of the
business's functions in a structured
graphical form
data dictionary - developed from the
DFDs; lists all of the data items used in
the system along with their
specifications
Analysts use CASE tools to



1. Increase productivity - draw and
modify diagrams easily
2. Improve analyst-user communication
- same - draw and modify diagrams
easily
CASE tools integrate activities within
the SDLC
types of CASE


1. Upper CASE - used by analysts to
create and modify system design
2. Lower CASE - used to generate
computer source code
Using Data Flow Diagrams





structured approach - take a top-down
approach to system development
system is defined first at a general level overview
successive refinement occurs until the bottom
(primitive) levels are defined.
primitive level - point where specifications can
be translated into lines of code
So...system is decomposed into small
modules that perform simple tasks
Structured Development

the systematic and integrated use of
tools and techniques to aid the analysis
and design of information systems

structured methodologies use one or
more tools to define information flow
and processes.
Structured Development
definition is from top to bottom in
increasing levels of detail.
1.major flows and processes identified
2.these are exploded into subprocesses
3.subprocesses are exploded into more
detail.
 this process can continue to the
primitive level, where programming
begins directly from the exploded

Structured terms






data elements - lowest level of information on
which a process can act
i.e. DB attributes/record fields - e.g. unit price
data stores - places where data are stored;
e.g. files; microfiche, filing cabinets
data flows - represent movement of data in a
system; consist of data input and data output
e.g. forms, reports, invoices, letters
show movement of data about a physical
“thing”
Structured terms

process specifications - definitions of
how processes work

data dictionary - document containing
definitions of all system data; includes
data elements, data structures, data
stores, data flows, and process
specifications
Tools
I.





Hierarchy Chart
graphic tool to represent all the tasks or
processes in a system
groups them into hierarchical levels
one-to-many relationship between
upper and lower levels of the chart
node has single parent and >=0 children
nodes
all sibling nodes have same level of
detail
I.



Hierarchy Chart
functional primitives - bottommost
nodes; get translated into programming
code
control modules - any node above the
functional primitives
topmost node - always single node, ties
whole system together
II. Data Flow Diagrams


DFDs - graphic representation of the
flow of data through a system;
can be physical DFDs or logical DFDs
Logical DFDs






shows sources and sinks (destinations) of
data
identifies and names the logical functions
(processes) of the system
identifies and names the groups of data
elements that connect one process to another
identifies the data stores
each function broken down into more detailed
DFD (levels)
descriptions of processes, flows, stores,
elements recorded in data dictionary
Logical DFDs

All of the above documentation
comprises a logical functional
specification for an existing or new
system.
 a detailed statement of what the system
does/is to do
 free from physical considerations of how it
will be implemented
DFD components (Gane &
Sarson Methodology)

contains combinations of only four
symbols
1. External entities





also called sources or sinks
people or groups of people who interact with
the current system but are not internal to the
system;
outside of boundary of our system
square is symbol for an external entity
to identity an external entity - place a unique,
lower-case alphabetic character in upper-lefthand corner of square. Then give entity a
single, descriptive noun as a name.
2. Processes





processes=functions
actions performed on data flowing
through the system
rounded rectangle - symbol for process
each process is identified by a number
corresponding to the level of the
process on the hierarchy chart.
each process is named with a simple
verb-object pair, i.e. enter transaction
3. Data Stores



repository for data
can be as simple as an in/out box or as
complex as a database
open-ended rectangle - symbol of a
data store; open end on right side
3. Data Stores

identified by upper-case alphabetic
character and a digit:
– each data store within the same system
has the same alphabetic characters with
different digits.





when a process stores data
data flow arrow goes into data store
when process accesses data
data flow arrow goes into process
avoid crossed data flow lines by
repeating the data stores on the DFD as
needed
4. Data flows




represents the movement of data
through the system
data often moves through the system as
a form or a report
solid line with arrowhead - symbol for a
data flow
each data flow must be identified with a
descriptive name
5. Exploding DFDs into levels


diagrams move from general to specific
similar to levels in a menu-driven
system; top-level node is analogous to
the main menu
Context-level


highest level in a DFD
lays out sources and sinks and a single
process representing the entire system
Diagram 0. first-level explosion


contains all the options on the main
menu
a leveled set of DFDs has a 1-to-1
correspondence with the levels on the
hierarchy chart
Developing DFDs





Diagram 0 - explosion of context
diagram
may include from 3 to 9 processes
ignore exception handling processes for
the first 2-3 levels of a DFD
each process numbered with an integer
includes major data stores and all
external entities
Creating child diagrams




each process on diagram 0 can be
exploded to create a more detailed child
diagram
parent - process on diagram 0 that is
exploded
child - resulting diagram
vertical balancing - a child diagram
cannot produce output or receive input
that the parent process does not also
produce or receive
Creating child diagrams



all data flow in or out of the parent
process must be shown flowing in or out
of the child diagram
child diagram given the same number
as its parent process in Diagram 0 (e.g.,
process 3 would explode to diagram 3)
processes on the child diagram are
numbered using the parent process
number, a decimal point, and a unique
number for each child process
Creating child diagrams




external entities - not shown on child
diagrams below Diagram 0
child diagram may include data stores
not shown on the parent process
processes may or may not be exploded,
depending on level of complexity
primitive process - when a process is
shown at its lowest level of detail,
cannot be exploded any further
Some general rules
1.a DFD level should contain from 3-9
processes
2.data flows should not split into two or
more different flows
3.all data flows must EITHER originate or
terminate at a process
4.processes need to have at least one
input data flow and one output data flow
Some general rules
5.
each child diagram should have the
same input and output data flow as the
parent process
6. avoid crossing data flow lines by
repeating data stores and external
entities
7. do not show exception handling
processes until the lower levels of the
DFD
Physical DFDs vs. Logical DFDs



physical DFDs - contain both what
processes are in the system and how
the processes operate; show movement
of things
allow us to understand how the current
system works
can be restrictive in the design process
logical DFDs


contains only the minimal data that flow
through the system, independent of any
devices, persons, forms, or specific
physical implementations;
implementation-free