Tools of Structured Analysis

Data Flow Diagram

Data Dictionary
Structured English
Decision Tables
Decision Trees
 Process Modeling
Graphically represent the processes that
capture, manipulate, store and distribute
data between a system and its environment
and among system components
Data flow diagrams (DFD)
Graphically illustrate movement of data
between external entities and the processes and
data stores within a system
 Process Modeling
Modeling a systems process
Utilize information gathered during
requirements determination
Structure of the data is also modeled in addition
to the processes
Deliverables and Outcomes
Set of coherent, interrelated data flow diagrams
 Process Modeling
Deliverables and outcomes (continued)
Context data flow diagram (DFD)
Scope of system
DFDs of current system
Enables analysts to understand current system
DFDs of new logical system
Technology independent
Show data flows, structure and functional
requirements of new system
 Process Modeling
Deliverables and outcomes (continued)
Project dictionary and CASE repository
Data flow diagramming mechanics
Four symbols are used
See Figure 5-2
Developed by Gane and Sarson
Dept. of Computer Applications
GJIMT, Mohali.
 Data Flow Diagramming
Mechanics
Data Flow
Depicts data that are in motion and moving as a
unit from one place to another in the system
Drawn as an arrow
Select a meaningful name to represent the data
 Data Flow Diagramming
Mechanics
Data Store
Depicts data at rest
May represent data in:
File folder
Computer-based file
Notebook
Drawn as a rectangle with the right hand vertical line
missing
Label includes name of the store as well as the number
 Data Flow Diagramming
Mechanics
Process
Depicts work or action performed on data so
that they are transformed, stored or distributed
Drawn as a rectangle with rounded corners
Number of process as well as name are
recorded
 Data Flow Diagramming
Mechanics
Source/Sink
Depicts the origin and/or destination of the data
Sometimes referred to as an external entity
Drawn as a square symbol
Name states what the external agent is
Because they are external, many characteristics
are not of interest to us
Data Flow Diagramming Definitions
Context Diagram-
Top-level view of IS
A data flow diagram (DFD) of the scope of an organizational system
that shows the system boundaries, external entities that interact with
the system and the major information flows between the entities and
the system
Example: Order system that a company uses to enter orders and apply
payments against a customers balance
Level-O Diagram
Shows the systems major processes, data flows, and data stores at a
high level of abstraction
When the Context Diagram is expanded into DFD level-0, all the
connections that flow into and out of process 0 needs to be retained
 Developing DFDs: An Example
Hoosier Burgers automated food ordering
system
Context Diagram (Figure 5-4) contains no
data stores
 Developing DFDs: An Example
Next step is to expand the context diagram
to show the breakdown of processes (Figure
5-5)
 Data Flow Diagramming Rules
Basic rules that apply to all DFDs
Inputs to a process are always different than
outputs
Objects always have a unique name
In order to keep the diagram uncluttered, you can
repeat data stores and data flows on a diagram
 Data Flow Diagramming Rules
Process Data Store
No process can have Data cannot be moved
only outputs (a from one store to another
miracle) Data cannot move from an
outside source to a data
No process can have store
only inputs (black Data cannot move directly
hole) from a data store to a data
sink
A process has a verb
Data store has a noun
phrase label
phrase label
 Data Flow Diagramming Rules
Source/Sink Data Flow
Data cannot move A data flow has only
directly from a source one direction of flow
to a sink between symbols
A source/sink has a A fork means that
noun phrase label exactly the same data
go from a common
location to two or
more processes, data
stores or sources/sinks
 Data Flow Diagramming Rules
Data Flow (Continued)
L. A join means that exactly the same data come from
any two or more different processes, data stores or
sources/sinks to a common location
M. A data flow cannot go directly back to the same
process it leaves
N. A data flow to a data store means update
O. A data flow from a data store means retrieve or use
P. A data flow has a noun phrase label
 Decomposition of DFDs
Functional decomposition
An iterative process of breaking a system description down
into finer and finer detail
Uses a series of increasingly detailed DFDs to describe an
IS
Act of going from one single system to many component
processes
Repetitive procedure
Lowest level is called a primitive DFD
Level-N Diagrams
A DFD that is the result of n nested decompositions of a
series of subprocesses from a process on a level-0 diagram
 Balancing DFDs
When decomposing a DFD, you must conserve
inputs to and outputs from a process at the next
level of decomposition
This is called balancing
Example: Hoosier Burgers
In Figure 5-4, notice that there is one input to the
system, the customer order
Three outputs:
Customer receipt
Food order
Management reports
 Balancing DFDs
Example (Continued)
Notice Figure 5-5. We have the same inputs
and outputs
No new inputs or outputs have been introduced
We can say that the context diagram and level-0
DFD are balanced
 Balancing DFDs:
An Unbalanced Example
In context diagram, we
have one input to the
system, A and one
output, B
Level-0 diagram has
one additional data
flow, C
These DFDs are not
balanced
 Balancing DFDs
We can split a data flow into separate data
flows on a lower-level diagram
 Guidelines for Drawing DFDs
1. Completeness
DFD must include all components necessary
for system
Each component must be fully described in
the project dictionary or CASE repository
2. Consistency
The extent to which information contained on
one level of a set of nested DFDs is also
included on other levels
 Guidelines for Drawing DFDs
3. Timing
Time is not represented well on DFDs
Best to draw DFDs as if the system has never
started and will never stop
4. Iterative Development
Analyst should expect to redraw diagram
several times before reaching the closest
approximation to the system being modeled
 Guidelines for Drawing DFDs
5. Primitive DFDs
Lowest logical level of decomposition
Decision has to be made when to stop
decomposition
 Guidelines for Drawing DFDs
Rules for stopping decomposition
When each process has been reduced to a single
decision, calculation or database operation
When each data store represents data about a
single entity
When the system user does not care to see any
more detail
 Guidelines for Drawing DFDs
Rules for stopping decomposition (continued)
When every data flow does not need to be split further
to show that data are handled in various ways
When you believe that you have shown each business
form or transaction, online display and report as a
single data flow
When you believe that there is a separate process for
each choice on all lowest-level menu options
 Using DFDs as Analysis Tools
Gap Analysis
The process of discovering discrepancies
between two or more sets of data flow diagrams
or discrepancies within a single DFD
Inefficiencies in a system can often be
identified through DFDs
Using DFDs in Business Process Reengineering
Example: IBM Credit
Credit approval process required six days before Business Process Reengineering (see Fig 5-12)
Using DFDs in Business Process
Reengineering

After Business
Reprocess
Engineering, IBM was
able to process 100
times the number of
transactions in the
same amount of time
Data Dictionary
A data dictionary is a catalog a repository of the
elements in a system. As the name suggests, these
elements center around data and the way they are
structured to meet the user requirements and organization
needs. In a data dictionary, you will find a list of all the
elements composing the data flowing through a system.
The major elements are data flows, data stores and
processes. The data dictionary stores details and
descriptions of these elements.
DD is an integral part of system specifications, since
without it, DFDs are just pictures with no details.
Analyst uses data dictionary for five
important reasons:

1. To manage the details in large systems.

2. To communicate a common meaning for all
system elements.
3. To document the features of the system.
4. To facilitate analysis of the details in order to
evaluate characteristics and determine where
system changes should be made.
5. To locate errors and omissions in the system.
 Logic Modeling
Data flow diagrams do not show the logic
inside the processes
Logic modeling involves representing
internal structure and functionality of
processes depicted on a DFD
Two methods
Structured English
Decision Tables
 Modeling Logic with Structured
English
Modified form of English used to specify
the logic of information processes
Uses a subset of English
Action verbs
Noun phrases
No adjectives or adverbs
No specific standards
 Modeling Logic with Structured
English
Similar to programming language
If conditions
Case statements
Figure 5-15 shows Structured English
representation for Hoosier Burger
 Modeling Logic with
Decision Tables
A matrix representation of the logic of a
decision
Specifies the possible conditions and the
resulting actions
Best used for complicated decision logic
 Modeling Logic with
Decision Tables
Consists of three parts
Condition stubs
Lists condition relevant to decision
Action stubs
Actions that result for a given set of conditions
Rules
Specify which actions are to be followed for a given
set of conditions
 Modeling Logic with
Decision Tables
Indifferent Condition
Condition whose value does not affect which action is
taken for two or more rules
Standard procedure for creating decision tables
Name the condition and values each condition can
assume
Name all possible actions that can occur
List all rules
Define the actions for each rule (See Figure 5-18)
Simplify the table (See Figure 5-19)
Decision Tree
Software requirements specification (SRS)
A software requirements specification (SRS) is a description of a
software system to be developed, laying out functional and non-
functional requirements , and may include a set of use cases that
describe interactions the users will have with the software.

Software requirements specification establishes the basis for an

agreement between customers and contractors or suppliers (in market-
driven projects, these roles may be played by the marketing and
development divisions) on what the software product is to do as well
as what it is not expected to do.

Software requirements specification permits a rigorous assessment of

requirements before design can begin and reduces later redesign. It
should also provide a realistic basis for estimating product costs,
risks, and schedules.[1]