PART II:

TOOLS OF THE
SYSTEMS ANALYST
by: SILVER AND SILVER
 Chapter 4
The Tools of the Analyst
Learning Objectives:

To be able to…

1. Discuss the value of system modeling technique.

2. Describe the advantages of design diagrams.
3. Contrast traditional and structured systems analysis tools and
give examples of each.

4. Read and understand various traditional and structured design

diagrams

5. Read and understand structured English and pseudocode.

 Introduction
Analysts use a variety of system design diagrams to
plan, describe, troubleshoot, or document a system.
These design tools include Gantt charts, decision trees,
decision tables, flowcharts, data dictionaries, data flow
diagrams, HIPO charts and Warnier-Orr diagrams, and
others that follow the data flow through a system. As
systems expand in size and complexity, analysts find a
growing need for these tools.
 System Modeling
A System Model is a representation of an in-
place or proposed system that describes the data
flow throughout the structure.
The model describes the points where data or
information enters a system and the places where it
will be processed, as well as the actions taken and
the points where data will be output.
 Types of Modeling
• Function Modeling

• Architectural Modeling

• Business Process Modeling Notation

 Design Diagrams
A design diagram is a graphic or visual
representation of a structure.
Design Diagrams include data flow diagrams,
structured charts, decision trees, and other items.
Advantages of Design Diagrams
1. Serve as communications tool
2. Serve as a planning tool
3. Provide an overview of a system
4. Define roles
5. Demonstrate relationships
6. Promote logical procedures
7. Facilitate troubleshooting
8. Document a system
 Traditional Design Tools
 Gantt charts
 System Flowcharts
 Decision Trees
 Decision Tables
 GANTT CHART
 History
 Uses
 Example
 History of Gantt Chart

• First Gantt Chart 1890’s ; Karol Adamiecki.

• 1917 ; Henry Gantt was devised his own

version of the chart.

• Originally Gantt chart were prepared

laboriously by hand; each time a project
changed it was necessary to amend or redraw
the chart and this limited their usefulness.
 The Gantt Chart
Gantt Charts are useful tools for analyzing and planning more
complex projects. They:
 Help you to plan out the tasks that need to be completed
 Give you a basis for scheduling when these tasks will be carried out
 Allow you to plan the allocation of resources needed to complete
the project, and
 Help you to work out the critical path for a project where you must
complete it by a particular date.
 When a project is under way, Gantt Charts help you to monitor
whether the project is on schedule. If it is not, it allows you to
pinpoint the remedial action necessary to put it back on schedule.
 Gantt Chart Example

2005 Pearson Prentice Hall Kendall & Kendall

3-
Example 2
 DECISION
TREES
 Definition
 Decision Tree Symbols
 Steps in making a Decision Tree
 Example
 Decision Trees
 Decision Trees are excellent tools for helping you to choose
between several courses of action. They provide a highly
effective structure within which you can lay out options and
investigate the possible outcomes of choosing those options.
They also help you to form a balanced picture of the risks
and rewards associated with each possible course of action.
 Drawing a Decision Tree
 You start a Decision Tree with a decision that you need to make. Draw a small square to
represent this towards the left of a large piece of paper.

 From this box draw out lines towards the right for each possible solution, and write that
solution along the line. Keep the lines apart as far as possible so that you can expand
your thoughts.

 At the end of each line, consider the results. If the result of taking that decision is
uncertain, draw a small circle. If the result is another decision that you need to make,
draw another square. Squares represent decisions, and circles represent uncertain
outcomes. Write the decision or factor above the square or circle. If you have completed
the solution at the end of the line, just leave it blank.

 Starting from the new decision squares on your diagram, draw out lines representing the
options that you could select. From the circles draw lines representing possible
outcomes. Again make a brief note on the line saying what it means. Keep on doing this
until you have drawn out as many of the possible outcomes and decisions as you can see
leading on from the original decisions.
 Once you have done this, review your tree diagram.
Challenge each square and circle to see if there are any
solutions or outcomes you have not considered. If there are,
draw them in. If necessary, redraft your tree if parts of it are
too congested or untidy. You should now have a good
understanding of the range of possible outcomes of your
decisions.
 Decision Trees Symbols
Shape Name Meaning

Decision node Indicates a decision to

be made

Shows multiple
Chance node uncertain outcomes

Each branch indicates

Alternative branches a possible outcome or
action

Shows a choice that

Rejected alternative was not selected

Indicates a final
Endpoint node outcome
Format of a Decision Tree
Example of a Decision Tree
DECISION TABLES
 Decision Tables
 Decision tables are composed of rows and columns. Each
row corresponds to a single rule, with the columns defining
the conditions and actions of the rules
Parts of a Decision Table

Condition Condition
Stub Entry

Action Action
Stub Entry
Sample Decision Table
Sample Decision Table
FLOWCHARTS
 Flowcharts
 A flowchart is a graphic representation of the steps in the
solution of a problem, in which symbols represent
operations, data flow, hardware, and the system plan.
Flowcharts can document either business systems or
computer programs
 Types of Flowcharts
 System Flowchart diagrams illustrate the movement of data
in an organization. They show the sequence of steps through
which information moves, including related personnel,
workstations, forms, records, processing, and associated
activities
 Program Flowcharts show the sequence of steps performed
in a computer program .
 System flowcharts document the overall system, while
Program flowcharts deal with the information flow through
the computer.
FLOWCHART SYMBOLS
STRUCTURED DESIGN
TOOLS
 Structured Design Tools
 Structured design tools emphasize the visual or graphic
nature of a problem. They break systems down into
elements known as modules.

 A module is one component of a system.

DATA DICTIONARY
 Data Dictionary
 A data dictionary is a composite collection of specifications
about the nature of data and information. It is a repository of
descriptions of the form, style, and content of data, as well as
of the methods that will be used to process and report it.
DATA FLOW DIAGRAMS
 Data Flow Diagram (DFD)
 A data flow diagram is a graphic illustration that shows the
flow of data and logic within a system.
 DFDs are one of the main methods available for analyzing
data-oriented systems.
 DFDs emphasize the logic underlying the system.
 The systems analysts can put together a graphical
representation of data movement through the organization.
 Data Flow Diagrams
 DFDs are one of the main methods available for analyzing
data-oriented systems.
 DFDs emphasize the logic underlying the system.
 The systems analysts can put together a graphical
representation of data movement through the organization.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Advantages of the Data Flow
Diagram Approach
Four advantages over narrative explanations of data
movement:
 Freedom from committing to the technical implementation too
early.
 Understanding of the interrelationships of systems and
subsystems.
 Communicating current system knowledge to users.
 Analysis of the proposed system.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Basic Symbols
Four basic symbols are:
 A double square for an external entity--a source or destination
of data.
 An arrow for movement of data from one point to another.
 A rectangle with rounded corners for the occurrence of
transforming process.
 An open-ended rectangle for a data store.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Basic Symbols

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Other DFD Symbols

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 External Entities
 Represent people or organizations outside of the system
being studied
 Shows the initial source and final recipient of data and
information.
 The initial source of data from the external entities may
sometimes be called a trigger.
 Should be named with a noun, describing that entity

Customer

© 2005 Pearson Prentice Hall

Kendall & Kendall
7-
 External Entities (Continued)
 External entities may be:
 A person, such as CUSTOMER or STUDENT.
 A company or organization, such as BANK or SUPPLIER.
 Another department within the company, such as ORDER
FULFILLMENT.
 Another system or subsystem, such as the INVENTORY
CONTROL SYSTEM.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Processes
 Represent either:
 A whole system
 A subsystem
 Work being done, an activity
 Names should be in the form verb-adjective-noun
 The exception is a process that represents an entire system or
subsystem.
1 2
Add New Customer
Customer Inquiry
Subsystem

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Data Flow
Data flow shows the data about a person, place, or
thing that moves through the system.
Names should be a noun that describes the data
moving through the system.
Arrowhead indicates the flow direction.
Use double headed-arrows only when a process is
reading data and updating the data on the same table
or file.

Customer Record New Customer

© 2005 Pearson Prentice Hall Kendall & Kendall
7-
 Developing Data Flow Diagrams
Use the following guidelines:
Create the context level diagram, including all external
entities and the major data flow to or from them.
Create Diagram 0 by analyzing the major activities within
the context process.
Include the external entities and major data stores.
Create a child diagram for each complex process on
Diagram 0.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Creating Data Flow Diagrams
Detailed data flow diagrams may be developed by:
 Making a list of business activities.
 Analyzing what happens to an input data flow from an external
entity.
 Analyzing what is necessary to create an output data flow to an
external entity.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Creating Data Flow Diagrams
Detailed data flow diagrams may be developed by (continue):
 Examining the data flow to or from a data store.
 Analyzing a well-defined process for data requirements and the
nature of the information produced.
 Noting and investigating unclear areas.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Data Flow Diagram Levels
 Data flow diagrams are built in layers.
 The top level is the Context level.
 Each process may explode to a lower level.
 The lower level diagram number is the same as the parent
process number.
 Processes that do not create a child diagram are called
primitive.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 DFD Levels
 Level 0 -- Context Level Diagram
 Level 1 -- Diagram 0
 Level 2 -- Child Diagram

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Context-Level Data Flow
Diagram
 It contains only one process, representing the entire system.
 The process is given the number zero.
 All external entities are shown on the context diagram as
well as major data flow to and from them.
 The diagram does not contain any data stores.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Context-Level Data Flow
Diagram

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Diagram 0
 Diagram 0 is the explosion of the context level diagram.
 It should include up to 7 or 9 processes.
 Any more will result in a cluttered diagram.
 Processes are numbered with an integer.
 The major data stores and all external entities are included
on Diagram 0.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Diagram 0

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Child Diagrams
Each process on diagram zero may be exploded to
create a child diagram.
Each process on a lower-level diagram may be
exploded to create another child diagram.
These diagrams found below Diagram 0 are given
the same number as the parent process.
Process 3 would explode to Diagram 3.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Child Diagrams (Continued)
 Each process is numbered with the parent diagram number, a
period, and a unique child diagram number.
 Examples are:
 3.2 on Diagram 3, the child of process 3.
 5.2.7 on Diagram 5.2, child of process 5.2.
 On Diagram 3, the processes would be numbered 3.1, 3.2, 3.3
and so on.

3.2 5.2.7
Edit Calculate
Customer Customer
Discount
© 2005 Pearson Prentice Hall Kendall & Kendall
7-
 Child Diagrams (Continued)
 External entities are usually not shown on the child diagrams
below Diagram 0.
 If the parent process has data flow connecting to a data store,
the child diagram may include the data store as well.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Child Diagrams (Continued)
 A lower-level diagram may contain data stores not shown on
the parent process, such as:
 A file containing a table of information (such as a tax table).
 A file linking two processes on the child diagram.
 Minor data flow, such as an error line, may be included on a
child diagram.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Child Diagrams (Continued)
 An interface data flow is data that are input or output from
a child diagram that matches the parent diagram data flow.
 Processes that do not create a child diagram are called
primitive processes.
 Logic is written for these processes.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Child Diagram

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Data Flow Diagram Errors
 The following conditions are errors that occur when drawing
a data flow diagram:
 A process with only input data flow or only output data flow
from it.

1 2
Add Add
New New
Customer Customer

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Data Flow Diagram Errors
(Continued)
 Data stores or external entities are connected directly to
each other, in any combination.

Customer D1 Customer

Vendor D2 Vendor Master

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Data Flow Diagram Errors
(Continued)
 Incorrectly labeling data flow or objects
 Examples are:
Labels omitted from data flow or objects.
Data flow labeled with a verb.
Processes labeled with a noun.

 Too many processes on a data flow diagram.

 Nine is the suggested maximum.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Data Flow Diagram Errors
(Continued)
 Omitting data flow from the diagram
 Unbalanced decomposition between a parent process and a
child diagram
 The data flow in and out of a parent process must be present on
the child diagram.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Logical Data Flow Diagrams
 Logical data flow diagrams show how the business operates.
 They have processes that would exist regardless of the type
of system implemented.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Data Flow Diagram Progression
The progression of creating data flow diagrams is:
 Create a logical DFD of the current system.
 Next add all the data and processes not in the current system
that must be present in the new system.
 Finally derive the physical data flow diagram for the new
system.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Data Flow
Diagram
Progression

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Advantages of Logical Data Flow
Diagrams
Advantages of logical DFDs are:
 Better communication with users.
 More stable systems, since the design is based on a business
framework.
 Increased understanding of the business by analysts.
 The system will have increased flexibility and be easier to
maintain.
 Elimination of redundancy.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Physical Data Flow Diagrams
Physical data flow diagrams show how the system
operates or how the new system will be
implemented.

Physical data flow diagrams include:

Clarifying which processes are manual and which are
automated.
Describing processes in greater detail.
Sequencing processes in the order they must be executed.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Physical Data Flow Diagrams
Physical data flow diagrams include (continued):
 Temporary data stores and transaction files.
 Specifying actual document and file names.
 Controls to ensure accuracy and completeness.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 CRUD
 Physical data flow diagrams include processes for adding,
reading, changing, and deleting records.
 CRUD is an acronym for Create, Read, Update, Delete.
 A CRUD matrix shows which programs or processes add,
read, update, or delete master file records.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Transaction Files
 Master or transaction database tables or files are used to link
all processes that operate at different times.
 They are required to store the data from the process that
creates the data to the process that uses the data.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Triggers and Events
 An input flow from an external entity is sometimes called a
trigger, since it starts activities.
 Events cause the system to do something.
 An approach used to create a data flow fragment is to
analyze events, which are summarized in an event table.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Event Tables
 An event table is used to create a data flow diagram by
analyzing each event and the data used and produced by the
event.
 Every row in an event table represents a unique activity and
is used to create one process on the data flow diagram.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Use Case and Data Flow
Diagrams
 A use case is another approach used to develop a data flow
diagram.
 A use case is used to create a data flow diagram by
providing a framework for obtaining processes, input,
output, and data stores required for user activities.
 A use case shows the steps performed to accomplish a task.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Use Case
The major sections of a use case are:
Use case name.
Description.
Trigger.
Trigger type.
Input name and source.
Output name and destination.
Steps performed.
Information required for each step.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Partitioning
 Partitioning is the process of analyzing a data flow diagram
and deriving a series of manual procedures and computer
programs.
 A dashed line is drawn around a group of processes that are
included in each computer program or manual procedure.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Reasons for Partitioning
 The reasons for partitioning a data flow diagram into separate
computer programs are:
 Different user groups should have different programs.
 Processes that execute at different times must be in separate
programs.
 Processes may be separated into different programs for security.
 Similar tasks may be included in the same program.
 Several batch processes may be included in the same program for
efficiency.
 Several processes may be included in the same program or job
stream for consistency of data.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Partitioning Web Sites
Web sites are partitioned into pages.
To improve speed of processing
For easier Web page maintenance
To view different pages when reading different data
for security, separating pages using a secure connection from
those that do not

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
 Communicating Using
Data Flow Diagrams
Data flow diagrams can be used for several different purposes:
 Unexploded data flow diagrams are useful to identify
information requirements.
 Meaningful labels should be used for good communication.

© 2005 Pearson Prentice Hall Kendall & Kendall

7-
HIPO
 Hierarchy plus Input-Process-
Output (HIPO)
 HIPO (pronounced hi-poe) Diagrams were developed by IBM
Corp. in an attempt to provide programmers with better
structured tools for dealing with systems.
 These diagrams enable analysts to define procedures and
operations in a hierarchical manner, correlating input,
processing, and output steps with the integrated whole
expressed in the visual table of contents.
 HIPO diagrams consist of three distinct types:
• Visual table of contents (VTOC)
• IPO overview diagram
• IPO detail diagram
 Visual Table of Contents
(VTOC)

The level of detail increases from the top to the bottom of the figure, from the
general to the specific. This is called top-down development.
Each module in the visual table of contents is described in greater
detail in an overview diagram, which includes the module's inputs,
processing, and outputs. The reference number assigned to the
overview diagram shows where the module fits into the overall
structure of the system as depicted in the visual table of contents. If
the module passes control to a lower-level module in the hierarchy
for some specific processing operation, that operation is also given
a reference number. An overview diagram for the payroll
processing module (2.1), ''Calculate Each Employee's Pay,'' is
shown in the Figure below.
IPO Diagram
WARNIER/ORR DIAGRAM
 Warnier/Orr Diagram
 A Warnier/Orr diagram (also known as a logical
construction of a program/system) is a kind of hierarchical
flowchart that allow the description of the organization of
data and procedures.
 Initially developed in France by Jean-Dominique Warnier
and in the United States by Kenneth Orr.
 This method aids the design of program structures by
identifying the output and processing results and then
working backwards to determine the steps and combinations
of input needed to produce them. The simple graphic method
used in Warnier/Orr diagrams makes the levels in the system
evident and the movement of the data between them vivid.
 Using Warnier/Orr diagrams
To develop a Warnier/Orr diagram, the analyst works
backwards, starting with systems output and using
output oriented analysis. On paper, the development
moves from right to left. First, the intended output or
results of the processing are defined. At the next level,
shown by inclusion with a bracket, the steps needed to
produce the output are defined. Each step in turn is
further defined. Additional brackets group the processes
required to produce the result on the next level.
 Constructs in Warnier/Orr
diagrams
There are four basic constructs used on
Warnier/Orr diagrams: hierarchy, sequence,
repetition, and alternation. There are also two
slightly more advanced concepts that are
occasionally needed: concurrency and
recursion.
 Hierarchy
 Hierarchy is the most fundamental of all of the Warnier/Orr
constructs. It is simply a nested group of sets and subsets
shown as a set of nested brackets. Each bracket on the
diagram (depending on how you represent it, the character is
usually more like a brace "{" than a bracket "[", but we call
them "brackets") represents one level of hierarchy. The
hierarchy or structure that is represented on the diagram can
show the organization of data or processing. However, both
data and processing are never shown on the same diagram.
 Sequence
Sequence is the simplest structure to show on a
Warnier/Orr diagram. Within one level of hierarchy,
the features listed are shown in the order in which they
occur. In other words, the step listed first is the first
that will be executed (if the diagram reflects a
process), while the step listed last is the last that will
be executed. Similarly with data, the data field listed
first is the first that is encountered when looking at the
data, the data field listed last is the final one
encountered.
 Repetition
Repetition is the representation of a classic "loop" in
programming terms. It occurs whenever the same set of data
occurs over and over again (for a data structure) or whenever the
same group of actions is to occur over and over again (for a
processing structure). Repetition is indicated by placing a set of
numbers inside parentheses beneath the repeating set.

Typically there are two numbers listed in the parentheses,

representing the fewest and the most number of times the set will
repeat. By convention the first letter of the repeating set is the
letter chosen to represent the maximum.
 Alternation
Alternation, or selection, is the traditional "decision" process
whereby a determination is made to execute one process or
another. The Exclusive OR symbol (the plus sign inside the
circle) indicates that the sets immediately above and below it
are mutually exclusive (if one is present the other is not). This
diagram indicates that an Employee is either Management or
Non-Management, one Employee cannot be both. It is also
permissible to use a "negation bar" above an alternative in a
manner similar to engineering notation. The bar is read by
simply using the word "not".

Alternatives do not have to be binary as in the previous

examples, but may be many-way alternatives.
 Concurrency
Concurrency is one of the two advanced constructs used
in the methodology. It is used whenever sequence is
unimportant. For instance, years and weeks operate
concurrently (or at the same time) within our calendar.
The concurrency operator is rarely used in program
design (since most languages do not support true
concurrent processing anyway), but does come into play
when resolving logical and physical data structure
clashes.
 Recursion
Recursion is the least used of the constructs. It is used
to indicate that a set contains an earlier or a less
ordered version of itself. In the classic "bill of
materials" problem components contain parts and
other sub-components. Sub-components also contain
sub-sub-components, and so on. The doubled bracket
indicates that the set is recursive. Data structures that
are truly recursive are rather rare.
 Structured vs. Unstructured
Design Tools
 Structured tools emphasize the logical flow of information
rather than physical manipulation.
 Unstructured or Traditional Design Tools describe systems
in terms of written narratives or sequential diagrams that
emphasize sequence and physical handling rather than the
logical flow throughout a system.