LESSON 2 THE ANALYSIS PROCESS

Learning Objectives:

After studying this lesson, the student should be able to:

Define the boundaries and scope of the system study.

Estimate and plan project requirements.
Use the modeling tools.
Determine the problems of the existing system and list of the requirements for
the proposed system.

Keywords and Phrases

LEARNER
Current System Investigation

Data Structure

Data Flow

Problems/Requirements List

Introduction

When a computer system is introduced into an organization in most cases it is

to support the work already done by that organization, albeit with modification or
enhancements. Although the workings of the future system may differ substantially
from those of the current system, the information held and the major functions often
remain relatively unchanged. This analysis of the existing system provides a firm
basis for the design of the future system.

16 | P a g e
THE ANALYSIS PROCESS

REASONS FOR PERFORMING A CURRENT SYSTEM INVESTIGATION

1. To understand the scope of the project.

2. To increase confidence.

The users who may not have any idea of what a computer system can give
them know the current system in great detail. It is the development teams task
to specify the job that must be done and how that job can best be supported by
a computer system. Documenting the current system is a means of reassuring
the users that the analysts understand the nature of the problem fully and are
competent to carry the work forward into the design of the required system. The
analysts become confident that they understand the business of the system.

In order to be able to design and justify the new system, several aspects of
the system are investigated,

1. Operations and data

2. Problems inherent in the current system
3. Boundaries of the system
4. Cost and volumes

An accurate boundary around the area of investigation is needed to avoid

needless effort on areas that lie outside the boundaries or more importantly, to
ensure that all of the areas inside the boundaries are investigated. The boundary
of the current system investigation should be explicitly stated and argued with all
those concerned.

THE CURRENT SYSTEM

The different types of current system may be classified under the
following:

Fully clerical

17 | P a g e
 The new system might be required to either:

Replace a system currently using manual procedures and paper files. An

example of this might be a personnel system, which is implemented
entirely on card indexes. The new computer system would require
monitoring the levels of stock and to control recording of stock.

Or

Monitor a system that will remain in place. An example of this might be a

system that monitors stock in a warehouse. The stock will continue to be
bought and distributed in the same way, but the new system would be
required to monitor the levels of stock and to control recording of stock.

Although the requirements of these two types of system will be different,

the investigation of their current system follows the same pattern. All the
information currently held on currently monitored and all the procedures
are modeled using the standard analysis & Design Techniques.

18 | P a g e
 Partly computerized

The new system may be required to replace an existing computer

system because it:

Does not meet the users requirements;

Has reached the end of its maintained life;
Requires major enhancements.

An example of this might be where a payroll system is already

computerized and the corresponding personnel system is clerical. A
new requirement to computerize the personnel records might prompt
the requirement for a fully integrated personnel and payroll system,
even though the payroll is already implemented as a computer system.
The computer system forms only a part of the current system
modeled. The clerical procedures surrounding the system will also
form a part of the investigation, although the user will set the practice
boundaries.

No apparent current system

Sometimes a completely new requirement will arise, for example when

new legislation is introduced on an organization moves into a new business
area. It may appear, in these cases, that there is no current system to
investigate. However, if a similar system already exists within the
organization, it might be useful to perform a brief investigation on this system
to establish areas of commonality of both information and procedures.

2.1 INITIATE ANALYSIS

19 | P a g e
 Throughout this stage, the development team must find out about the
system by a number of fact-finding techniques designed values in this
module.
The information collected is expressed as: a set of detailed DFDs
(Data Flow Diagrams) requesting the current system, a logical Data
Structure/class diagram of the current systems data, and the initial
Problems Requirements list for the project. Also, information about the
project, especially volumetric and costs is gathered during the analysis of
the current system. This is used later for cost justification and sizing of
the new system.

Initiate Analysis
Use case diagrams / Initial DFDs / Class Diagram
DFDs

Investigate Investigate
Current System Initial Probs. System Data
List Rqmts. Structure

Probs.
Rqmts.
Problem/
Requirement
Develop Problem
Requirements Current/Class
Current Diagram
List
Physical
DFDs/UML
Diagram Problem/
Lists Requirement

Review Results
Of Investigation

This figure shows the five steps of the analysis of system operations and current
problems of the existing system.

1. Initiate Analysis
The first step of the project may be thought of or two separate, but relative
parts:
a. General project set-up.

20 | P a g e
 b. Initiation of analysis.

Current project set up

Here, the following documents are produced:
1. Terms of reference

An illustration:
Terms of Reference

1. To design a computer system to support the vehicle

rental, driver administration, customer records, and
invoicing areas of MELCAR Ltd.
2. To investigate ways of improving the efficiency of the
operations of the company in the more specified in 1.
3. To investigate extending the system to include the
administration of one-way hires and the
reacceptance of non-registered customers.
4. The system will not be required to replace the
existing staff but the increased efficiency will be
expected to increase the income from customers with
less wastage of resources in the use of agency
drivers.
5. The team of the contract senior systems analyst and
a junior analyst are required to use structure System
Analysis and Design Methodology for the analysis
and design of the system. They will report back to
the MELCAR finance director. The team should
report back with their proposals for a new system
within two months of starting the study.

It is important that some set of contract should be agreed between the users
and the developers. This is often the first formal statement by the users of what they
want and then forms the basis for the subsequent work.
This module uses modeling tools in investigating and designing the required
system. The first discussion is a traditional methodology wherein some companies
are still comfortably using. Another is a tool which is being supported by object
oriented software developers is the Unified Modeling Language (UML). To
facilitate understanding of the readers a full discussion of the previous tools will be
discussed first. A divider is used to further separate the different school of thoughts
in using system analysis and design.

21 | P a g e
Modeling Tools for Structure System Analysis and Design

2.2 INVESTIGATING THE CURRENT SYSTEMS

Objective: To represent the workings of the current systems using Data Flow
Diagrams and to define with the users.

Approach: The Data Flow Diagram is a working-point of the analyst and

users. The use of a diagrammatic model gives a precise and concise
representation of the current system that can be used as the basis for further
analysis and design. The diagram uses the language of the current system
so that, for example, a Registration Form C-1 that is used will appear on the
DFD, as a Registration Form C-1.

The users of the system and the analysts do the development of the
Data Flow Diagram jointly. Typically, the Analysts would start the Data Flow
diagram after listening to a description of the current system given by its
users.

Then would follow a number of further discussions in which the users

would work closely with the analyst to refine the diagrams until they represent the
current system accurately.

And the users are so closely involved with the development of the Data
Flow Diagram; it follows that they must understand the notation and this purpose.
This may require some training.

STARTING THE DATA FLOW DIAGRAM

This module starts the discussion on the different conventions of

constructing DFDs and will use the SSADM technique based from C. Ashworth and
M. Goodland book. The authors find the method easier to understand aside from
having user-friendly diagrams.
We will however, build the MELCAR existing system DFDs after
discussing with you the how tos in drawing your DFD.
The Data Flow Diagram is a modeling tool that allows us to picture a
system as a network of functional processes, connected to one another by
pipelines and holding tasks of data. In the computer structure and in your
conversation with other system analyst and user, you may use any of the following
terms as synonyms for the data flow diagram:

DFD
Process Model

22 | P a g e
 Work Flow Diagram
Function model
a picture of whats going on here

The components of DFD

The figure below shows a typical DFD for a small system.

Before we examine the details, notice several things:

It hardly needs to be explained at all; one can simply look at the

diagram and understand it. The notation is simple and unobtrusive
and is a sense, intuitively obvious. This is particularly important
when we remember who is supposed to be looking at this figure
not the systems analyst but the user! Of the user needs an
encyclopedia in order to read and understand the model of his
system, he or she probably wont bother to do either.

The diagram fits easily onto one page. This means two things: (1)
someone can looks at the diagram without being overwhelmed, and
(2) the system that is being modeled by the diagram is not very
complex.

Example figures:

A. One version of a DFD (Yourdon style)

Invalid
CUSTOMERS
Orders
WAREHOUSE
Order ORDERS
shipping books
Details details
orders
customer name,
customer address
1. 2.
RECIVE SHIP
billing ORDER BOOKS
information
CUSTOMER
RRRS books
INVOICES
customer name,
customer address Invoices,
statements
Customer name,
Invoice details Payments,
COLLECT Inquiries
PAYMENTS CUSTOMERS
23 | P a g e
 In this example, the following symbols or notations are used.

Bubble or circle denotes a process

Data flow

Data Store

Source or destination

It is no big deal if you prefer using this. Take note however that the next

example will
THEbeCOMPONENTS
the methodology used in this module:
External Source/Recipients (external entities)

An external source/recipient, often referred to as an external

entity, is whatever or whoever donates information to or reclines
information from the system. All information represented within a
system must have been obtained initially from an external
source/recipient. An external source/recipient is represented on a Data
Flow Diagram as an oral (or language) containing the name and an
identifier. The convention is that the identifier is a lower- case letter:

A
custome
PROCESS r

24 | P a g e
 A process transforms or manipulates data within the system.
Processes are represented by rectangles on a Data Flow Diagram.
Each process box contains the name of the process, an identifier, and
possibly a location.
The process name is an imperative statement: do this or do that.
It describes the processing performed on the data received by the
process. For example, a process may be named Register new
customer, but may not be named manager or Registration
Section.
Process identifier numerical.
In the current physical Data Flow Diagram, the location of the
process is place at the top of the box. This might be a physical
location, but is more often used to denote the staff responsible for
performing the process.

Identifier Manager
Locatio
n Register New
Customer

Name

DATA STORE

A data store is where information is held for a time within

the system. An open-ended box as shown represents a data store on
a Data Flow Diagram:
D1 CUSTOMER
DETAILS

25 | P a g e
 In the Current Physical Data Flow Diagram, the data stores
represent real world stores of information such as compute files, card
indexes, ledgers, etc. If the Data Flow diagram contains both
computer-based data stores and clerical data stores, it maybe helpful
to distinguish them by their identifiers, e.g. using M for the clerical
data stores and c for the computer data stores. This is to avoid
confusion when similarly name files are stored both clerically and on
the computer system.

DATA FLOW

A data flow represents a package of information flowing

between objects on the Data Flow Diagram. A data flow represented
by a line and an arrow to denote the direction of the flow of information.
It is labeled with the name or details of the information represented by
the data flow.

Customer name Manager

Register
A
New
customer
Customer

Customer name

D1 Customer Details

RULES GOVERNING DATA FLOW DIAGRAMMING (HOFFER, 93)

Process:

A. No process can have only outputs. It is making data from nothing

(a miracle). If an object has only output, then it must be a source.
B. No process can have only inputs (a black hole). If an object has
only inputs, then it must be a sink.
C. A process has a verb phrase level.

Data Store:

D. Data cannot move directly from one data store to another data
store to another data store. A process must move data.

26 | P a g e
 E. Data cannot move directly from an outside source to a data store.
Data must be moved by a process, which receives data from the
source and places the data into the data store.
F. Data cannot move directly to an outside sink from a data store. A
process must move data.
G. A data store has a noun phrase label.

Source/Sink:

H. Data cannot move directly from a source to a sink. A process

must move it if the data are of many concerns to our system.
Otherwise, the data flow is not shown on the DFD.
I. A source/ sink has a noun phrase level.
J. A data flow has only, direction of flow between symbols. It may
flow in both directions between a process and a data store to show
a lread before an update. Two separate arrows usually indicate
the latter, however, since these happen at different times.
K. A fork in a data flow means that exactly the same data goes from a
common location to two or more different processes, data stores,
or sources/sinks (this usually indicates different copies of the same
data going to different location).
L. A join in a data flow means that exactly the same data comes from
any of 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.
There must be at least one other process which handles the data
flow, produce some other data flow, and returns the original data
flow to the beginning process.
N. A data flow to a data store means update (delete or change).

O. A data flow from a data store means retrieve or use.

P. A data flow has a noun phrase label. More than one data flow
noun phrase can appear on a single arrow as long all of the flows
to the same arrow moved together as one package.

Rule Incorrect Correct

A.

B.

27 | P a g e
 D.

E.

F.

H.

J.

K. A
B A

L. A

28 | P a g e
 M. A
B

Construction of Data Flow Diagrams (ASHWORTH, 90)

The top-level Logical Data Flow Diagram of a sample banking system is

shown in the following. Here, the main activities are the registration of new
customers, the recording of deposits or withdrawals, and the closing of accounts.
New customers are registered and accounts are closed by the bank manager
represented here as an external source/recipient. When an account is closed, the
customer is notified by the system. The customer makes cash deposits into the
account, and the employer pays in salary cheques. The bank clerk performs a
balance check before allowing a withdrawal by the customer at the bank counter.

B
MANAGER

Account No. 1 D2 BANK

REGISTER Account No. ACCOUNT
NEW
CUSTOMER
D
A clerk
A CUSTOMER DETAILS
CUSTOMER D1 2
CUSTOME 1 RECORD
R BANK DETAILS DEPOSITS
CUSTOME D WITHDRAWAL
R 2 A

B
A
B M Employe
MANAGER 3
e
CLOSE FILES

A EA
CLOSE Customer Employ
FILES Customer ee
29 | P a g e
Figure 1
Some general principles about Data Flow Diagrams are demonstrated by
this figure.
External source recipients

For the Logical and Required Data Flow Diagram only, the external
source/recipient is the last to be able to alter the information. For example, when a
customer makes a deposit at the bank counter, the clerk simply inputs information
received from the customer without changing it in any way so it is the customer that
is shown as an external source/recipient. For withdrawals, the clerk validates the
request for the withdrawal, possibly changing it before input, so it is the clerk that is
shown as the external source/recipient. Similarly, for outgoing flows, the external
source/recipient is the first that actually uses the information. The customer is
notified of the closure of his or her account. Although a bank clerk may put the
notification letter into the post, it is the customer that is the external source/recipient
as he or she is the first person to use the information.
Process numbering

Although the processes are numbered sequentially, this does not imply that
they are executed in any particular sequence. Data Flow Diagrams do not imply
sequence. Processes 1, 2 and 3 could be renumbered in another sequence and
remain meaningful. Even where a process-to-process data flow exists, this need not
imply that the second process must wait for the first to end before it is able to begin.

Duplication of data stores and external source/recipient

It has been necessary to duplicate certain external source/recipients and data

stores to avoid overcomplicating the diagram with crossing lines. To denote that a
particular data store has been duplicated in the diagram, an extra vertical line is
placed at the left side of the box, as demonstrated in figure by Data Store D2, Bank
Accounts. An oblique bar to one side of the oval could denote duplicated external
source/recipients, although this is not normal practice and is not demonstrated here.
Where objects are duplicated, it is easy to make mistakes in rewriting the
names of the objects wherever they occur. Therefore, it is important to ensure that
the identifiers are present to be able to reconcile different occurrences of the same
objects.

Topology of the diagram

To make the diagram more readable, the external source/recipients have

been arranged around the edges of the diagram, and the data stores placed towards
the center of the diagram. This is good practice rather than a particular rule. For

30 | P a g e
clarity, no more than 12 processes should be shown on a single Data Flow Diagram.
It is important to remember that one of the main purposes of a diagram is to act as a
means of communication, so legibility and clarity are as important as the technical
content of a diagram.

Levels of Data Flow Diagrams

Each process on a Data Flow Diagram may be broken down into several
processes, which are shown on another Data Flow Diagram. This is described as
decomposing the Data Flow Diagrams. The Data Flow Diagram, which is a result of
this decomposition, is one level below the Data Flow Diagram containing the original
process.
The Data Flow Diagram that describes the entire system within a single
diagram is the top level or context Data Flow Diagram. The Data Flow Diagrams
that are expansions of processes at the top level are 'level 8' Data Flow Diagrams
(see Fig. 2). Levels below this are called level 1, level 2, etc. Processes that are
not further decomposed are bottom-level processes. Processes from the top-level
Data Flow Diagram may be broken down to a number of levels if they are complex
or may not be broken down at all if they are relatively simple. Thus, it is possible to
have bottom-level processes appearing at all levels of the Data Flow Diagrams.
Although not formally documented as part of SAD, it is useful to denote which are
bottom-level processes on the Data Flow Diagrams.

a
1

1.1 1.2

a
1.4

Figure 2

If a process is decomposed, the identifier of the higher-leveled process

prefixes the identifiers of the lower-level processes. For example, if Process 5 if
decomposed, the lower-level processes will be identified as 5.1, 5.2 etc. Similarly, if
Process 5.1 is subsequently decomposed the lower-level process will be 5.1.1,
5.1.2, and so on.

31 | P a g e
 d
RECORD DEPOSITS AND WITHDRAWALS cler
k
A
CUSTOMER 2.1
2.2 Amount of requested
Amount RECORD CHECK
DEPOSIT RECORD
WITHDRAWAL D2
Amount of deposit Amount requested Bank
Accounts
D2 BANK ACCOUNTS Balance of account

2.3 Amount of deposit

ACCEPT
PAY
Amount of selling point
DEPOSIT
The second level Data Flow Diagram of Process 3 is shown in Figure. The
frame surrounding the lower-level Data Flow Diagram denotes the boundary
employe of the
higher-level process. The identifier of the higher-level process and the
e name of the
process are put at the top of the frame. Note that all of the flows to and from the
higher-level box have been either duplicated or broken down into several flows at
the lower level. If new data flows are identified at the lower level, which cross the
frame, these should be reflected at the higher level so that consistency between the
levels is maintained.

THE ANALYST AT WORK:

Note: Refer to Appendix for MEL Cars case:

After reading MELCARs case let us assume the facts were gathered from
some of the techniques specified in this module. The initial Data Flow Diagrams are
arrived at by:

1. Listing the manager documents and their sources and recipients. In

addition to actual documents in this list, manager information flows of
other kinds are listed. e. g. information communicates dialogues. The list
compiled for the MELCAR system is:

Booking Sheet
Invoice
Customer Payment
Booking Request
Driver Request and Confirmation

32 | P a g e
 Customer List
Driver Instructions
New Vehicle Documents

Obviously, these are not the full set of information flows within the system, but
they are the major ones needed to start the Data Flow Diagrams.

Drawing the documentation flows. Each source or recipient is represented as an

oval in a diagram with the documents represented as flows between him and her. A
source of recipient might be:

A section within the relevant area of the organizations;

An office in another part of the organizations;
An outside organization or person;
A computer system.

The relevant sources and recipients for the Yorkies system are initially identified
as being:

Local Office Reception Staff

Local Office Booking Staff
Local Depot Staff
Local Office Driver Administration
Head Office
Vehicle Fleet Maintenance
Customers
Drivers
drivers
Driver Agencies
agencie
s
These sources and recipients are scattered over a page, and each of the
main documents listed before are matched to the relevant sources and recipients.
The resulting diagram is shown in the four different copies of the Booking Sheet are
separated to show which copies are usedLocal
in which areas of the organization.
driver
Local admin
office
reception

Driver
Driver request
Instruction
Local Local
Local request Booking Depot
Staff staff

customer
s
Head
33 | P a g e Office
Vehicle
Fleet
Maintenanc
 invoice

payment

Agreeing the system boundary

The diagram produced is shown to the users for comments or its accuracy
and to check that nothing is left out. The boundaries of the investigation may be
denoted on this diagram, showing which areas should be included in the
investigation and which should be considered as external to the system. In figure the
sources and recipients that are obviously going to be system are the Customers and
Driver Agencies, as they belong to external organizations. Also the users decide
that the activities of the Driver Administration Section should be included, but not the
activities of the Drivers themselves, making the drivers external, but Driver
Administration internal. Although an important part of the organization, it is also
decided that the Vehicle Fleet Maintenance should be excluded from the system, as
this is a large but self-contained section of the organization. The resulting system
boundary is drawn onto the diagram as shown in figure 5.

drivers
Driver agencie
Driver request s
Instruction

Local request Local

driver
Local admin
office
reception
34 | P a g e
 Local Local
Booking Depot
Staff staff

customer
s invoice
Head
payment Office
Vehicle
Fleet
Maintenance
FIGURE 5

In some projects this definition of system boundary will have been completed
in an earlier stage, perhaps as part of an information systems strategy or by a
feasibility study.
Sending or receiving of the major documents within the system boundary are
presented as processes, forming the basis of the top-level Data Flow Diagram.
Where these documents are held within files or other means of storage, data stores
are added to the diagram. For example, demonstrate how the Booking Request
form sent in by the Customers to Local Office Reception and Local Office Booking
Staff is now represented as being received by an Identifying processes; within the
system. The activities relating to the process, Received Booking Request,
performed by the Reception Staff. The process passes the Booking Request to
another process, Fill Bookings, performed by the Booking Staff. The Booking
Request are transformed into Booking Sheets by this process, and these Booking
Sheets are put into the Booking Sheets Files, represented here as a data store.
Note that the section responsible for performing the process is indicated as the top
of each process box. This emphasizes the physical mapping of current system
functions within the Data Flow Diagrams.

LOCAL OFFICE
D
LOCAL RECEPTION
2
OFFICE
DRIVER
RECEPTION
BOOKING LOCAL
LOCAL BOOKING
REQUEST BOOKING
STAFFSTAFF

FILL OUT
BOOKING
35 | P a g e SHEET

D
1
 CUSTOMER BOOKING REQUEST

BOOKING REQUEST

CUSTOMER

BOOKING SHEETS

BOOKING SHEETS
FILE
Figure 6

Physical Resource Flows

This might be an appropriate way of developing the Data Flow Diagrams if the
current system consists principally of flows of goods. A Physical Resources Flow
Diagram concentrates on following the movement of the physical object interest.
This flow of goods is represented by broad arrows. The progress of the goods is
shown from when they arrive within the boundaries of the system, through the
various points at which something is done to them or recorded about them
(represented as processes), to their exit from the system.
A diagram that could be used to model the purchasing, rental, and sales of
vehicles of the MELCAR system is shown (this area is actually outside the system
boundary in the case study). In this case, the physical resources are vehicles. This
shows how the vehicles are tracked from their purchase, through to their eventual
sale. BUY CHECK
vendor
VEHICLES VEHICLES

Vehicles DEPOT

OK VEHICLES VEHICL VEHICLES

VEHICLES
RENT OUT
VEHICLES

VEHICLE CUSTOMER

SERVICE RECEIVE
VEHICLE BACK
RENTED
VEHICLES

36 | P a g e
SELL
VEHICLE BUYER


VEHICLES
RET. VEHICLES

VEHICLES VEHICLE SOLD

Figure 7

The reason for representing the physical flows is that information will normally
flow around the same paths. For example, the vehicle documents will accompany a
vehicle when it is bought and sold, and the Booking Sheets will initiate a rental, and
be sent when a rental is terminated, as shown in Fig. 7. In this way, the information
flows and processes of the current system are determined.

VEHICLES
BUY CHECK
vendor
VEHICLES VEHICLES VEHICLES
vehicle DOCS.
docs.
DOCS.

OK VEHICLES
DEPOT VHIC VEHICLES

VEHICLES

RENT OUT VEHICLES

VEHICLE CUSTOME
R
BOOKING SHEET
RECEIVE

SERVICE
BACK
VEHICLE
RENTED
VEHICLES
VEHICLES
RET. VEHICLES

VEHICLES DOCUMENTS
SELL VEH. DOCUMENTS
VEHICLE BUYER

37 | P a g e
 VEHICLES VEHICLE

FIGURE 8

Organization structure

Often, the simplest way to develop a top-level Data Flow Diagram is to use
the current organization structure for defining the processes. This approach starts
from the point of view of the processes that are performed in the organization, rather
than the information that is flowing around the system. When dealing with large
systems, which have many significant documents and information flows; the physical
document flow approach may lead to very complicated diagrams. By looking at the
relevant functions of different areas of the organization, a simpler initial picture may
be formed, with the detail added later.

Managing Director

Local Office Marketing and Vehicle Fleet

Administration Finance Director Management

Marketing/ Accounts Accounts General Ledger

Pricing Receivable Payable Budgeting

Head Office Invoicing Customer Payroll Running

Bookings Records Costs

Maintenance
Purchase/
Sa
les

Local
Offices

Local Office Manager

Reception Booking Driver Depot

Administration Staff

FIGURE 9

38 | P a g e
 The organization structure of the MELCAR system is shown in Fig. Here, the
user has decided which of the areas of the organization should be included in the
investigation, as shown in italics. The main function of the Local Office Bookings
becomes a top-level process on the Data Flow Diagram. By a similar procedure, the
main functions of the other areas of the organization are represented as processes,
as shown in Fig.10.
LOCAL RECEPTION 4 LOCAL DRIVER ADMIN

RECEIVE FIND AND

BOOKING NOTIFY
REQUEST DRIVERS

LOCAL BOOKING DEPOT STAFF

FILL RECORD
BOOKING VEHICLE
SHEET DEPARTURE/RETURN

HO/LOCAL ADMIN HO ACCOUNTS

ADMINISTER INVOICE AND

LOCAL MAINTAIN
UNFILLED CUSTOMER
BOOKING RECORDS

FIGURE 10
The information flows between these processes, and between the processes
and external source/recipients, together with the stores of information are determined
and added to the diagram to give the top-level Data Flow Diagram shown in Fig. This
is the top-level diagram that would have been derived whichever approach had been
taken. LOCAL
RECEPTION e
RECEIVE B
PAYROLL
BOOKING DRIVER
REQUESTS AGENC
Y

c
D3 DRIVER DRVER
a 4 LOCAL DRIVER S
INSTRUCTIONS
CUSTOME
Booking ADMINDriver
R
Request Instructions
FIND AND NOTIFY
Driver house
LOCAL Agency Days
BOOKING DRIVERS
Booking Request
FILL BLOCKING
SHEET
D2 BOOKING REQUESTS 4
Booking Request Driver
d Availability
Booking Sheet Driver FLEET
(Copy 1) Request MAINTCE Driver
HOT Availability
LOCAL ADMIN
ADMINISTER Booking Sheet Driver Driver
LOCAL (Courses2-4) Hours Name
UNFILLED
BOOKINGS DEPOT STAFF
D1 BOOKING Vehicle
SHEETS FILE
RECORDOut of
VEHICLE
Service
DEPARTURE AND
Booking Sheet
RETURN New Vehicle
Driver Hours (Courses 2-4) Documents

39 | P a g e 6 NO ACCOUNTS

a
INVOICE AND MAINTAIN
CUSTOMER RECORDS
CUSTOME
 And Mileage

Customer Booking Sheet

Lists (Copy 4) Booking Sheet
(Copy 2 completed)

FIGURE 11

Simplifying complex diagrams

The top-level Data Flow Diagram produced by the approaches above might
become very complex and confused. It is important that the top-level Data Flow
Diagram is easily understood, as this is a very useful overview of the whole area of
investigation, to be used for discussions with users and managers.
As an initial help, if system boundaries and the scope of the system become
unclear, it may be useful to draw a context diagram. This is where the system is
represented as a single process. This is useful in ensuring that the boundaries are
correct and well understood. A context diagram for the MELCAR system is shown in
Fig.12 although trivial in this instance, this type of diagram could be very useful for
very large projects.

DRIVERS/
Instructions AGENCIE
S
Driver Availability
MELCAR
Booking Request
Booking Sheet
(Copy 1 and 2) Bookings
CUSTOME
R
Invoice Invoicing
Drivers Vehicle out of service

New Vehicle
Documents
FLEET
MAINTCE

FIGURE 12

40 | P a g e
 If the top-level Data Flow Diagram is still unclear, then it should be simplified until
the overall diagram is intelligible. This simplification may be done in one of three
ways (or a combination if appropriate):

1. Combine some of the process boxes, until there are a maximum of 12 boxes on
one diagram. The processes that are combined can be split again at a level 2
Data Flow Diagram.
2. Combine data stores at level 1 only, showing them individually at lower levels.
This might be done if a number of data stores are holding very similar
information: in clerical systems, it is often necessary to hold the same information
filed under different headings. The identifiers of the new data stores are Dn,
where n is a number, and when they are broken down at lower levels, the
identifiers of the lower-level data stores are Dna, where n is the same number
as the top-level data store and a is an alpha character, as demonstrated in figure.

D1a Central customer

D1 customers list
D1b Local customers
FIGURE 13 list
3. Combine external source/ recipients at the level 1 only, showing them individually
at lower levels. In a system dealing with a large number of different departments
of the same overall organization, the name of the organization could be used at
the top level, with a breakdown of the departments at a lower level. The
composite external sources/ recipient is denoted in the conventional way at the
top level with an alpha character. The same alpha character and a number
denote the individual external source/ recipients at lower levels. See for an
example

A1
A Treasury
Government
Department
A2
Home
Office

FIGURE 14
This tidying up of a the top-level data flow diagram is shown schematically in
figure. The fianal diagram is less cluttered and much more readable than the initial
diagram.

41 | P a g e
FIGURE 15
Decomposition to lower levels

To describe fully the current system in the form of Data Flow Diagrams, it is
necessary to expand most of the top level Data Flow Diagram process boxes to a
second level, or possibly to a third or fourth. As a general guideline, processes are
decomposed if:
There are more than eight data flows in to or out of the process;
The process name is complex or very general, e. g. Record Customer
Information, 4Send Invoices
FIND AND andNOTIFY
Receive Payment or Maintain
DRIVER
Customer Information.
driver instructions driver inst
At the bottom level, each process should have a4.2
4.4 brief specific name and have
between two and eight data flows surrounding it.
FILE BOOKING NOTIFY DRIVER
driver name driver
SHEETS
Data flows between lower level& processes
driver required address and other objects should be
reflected back up to the top level so that data flows at all levels are shown in
summary at the top level. 4.1The level Data Flow Diagram of process 4 driver of the
inst
MELCAR 4.3
driver Data Flow Diagram demonstrates this. It may be seen that all flows
driver FIND DRIVER
crossing the boundary (shown as a frame) of the lower-level Data Flow Diagram are
availability FIND AGENCY
shown as flows to and from the process box at the higher NAMESlevel. agency
driver name
driver name availability
suitable driver agency name
availability availability availability
D4 UNIVERSITY
D1 Booking REGISTRAR
sheets driver time
availability
42 | P a g e driver hours/ 4.4 driver/agency time
agency time availability
RECORD DRIVER
payroll AGENCY TIME
 dr

FIGURE 16

If a data store is used by only one top-level process, then it is said to be

internal to that process. To avoid confusing the level 0 Data Flow Diagram, internal
data stores are shown inside the frame of the level 1 Data Flow Diagram and their
identifiers reflect the identifier of the top-level process. In figure, the data store D4/1
is internal to process 4 so appears only at the second level. If other internal data
stores were shown, they would be identified as D4/2, D4/3, and so on.

If the system is too complex to describe adequately in several levels of the

Data Flow Diagram, then Elementary Function Descriptions are used to describe the
bottom-level processes. These are brief narrative descriptions of the process, which
often case-refer to existing current system documentation.
As we have seen in this section the Data Flow Diagram is a simple but
powerful tool for modelling the functions in a system. Unfortunately, many systems
analyst and designers think that dataflow diagram are all they need to know about
structured analysis, he is likely to remark, Oh yeah, I learned about all diagramsit
is often the only thing that a system analyst remembers after reading a book or
taking a course on structured analysis! On the other hand, it is dangerous situation:
without the additional modelling tools presented in this module, the dataflow
diagrams are worthless.
So dont put the module down yet! Theres more to learn.

Reading Assignment:

Link:

43 | P a g e
 E-Journals/E-Books
PUP website: infotrac.galegroup.com/itweb/pup
Password: powersearch

Exercises/Written Assignment:

CASE 2

General Description of the Case

Sunny College system is a small, four-year educational institution, which is

organized by academic department. A department may offer more than one major
(e.g. CIS department might offer majors in computer science and information
resource management). Only one department, however, offers each major. A
faculty member may not be assigned to more than one department. Students can
have more than one major, but most have only one. Each student has a faculty
member as an advisor for his or her major; a student with more than one major has
a faculty advisor for each one. The faculty member may or may not be assigned to
the department offering the major.
For a given semester, each section of each course is assigned a four-digit
schedule code together with a section letter. For a different semester, the schedule
codes will be entirely different. The schedule codes are listed in the time schedule,
and students use them to indicate the section in which they wish to enroll.
After the enrollment process has been completed for a given semester, each faculty
member receives a class list for each section he or she is teaching. In addition t
listing the students who are in that particular section, the class list provides space to
indicate the grade each student has earned in the course. At the end of the term,
the faculty member will place the students grades on this list and will return a copy
of the list to the records office, where the grades will be entered into a computer as
permanent records. The grades will appear on the students transcript that is
generated by the computer upon request.

Report Requirements

A class list must be generated as described above.

Report cards must be produced at the end of a semester. They should include
information not only for the details of the courses taken in the current semester
but also for the current semester totals and cumulative totals. Since each card
will be mailed to a students permanent address, it contains a block for the
information.
A course report list needs to be produced occasionally for each course, the code and
name of the department offering the course, the course number, the description
of the course, and the number of credits. Prerequisite courses should be
included in terms of their course number and the department name.

44 | P a g e
A time schedule lists all sections of all courses to be offered during a given
semester. Id addition to course-related information such as course#, sec#, time,
place, faculty, etc, it includes the date the semester begins, the date the
semester ends, the date the final begins, the date the final ends, and the last
date for withdrawing a course.
Registration request forms are used to request classes for the following semester.
Students indicate the sections for which they wish to register by writing the
sections schedule codes. For each of these sections, they may also enter a
code for an alternate section.

When a student completes registration, a students schedule for a given semester is

generated for him or her. In addition to course-related information, this form
includes other student-related information such as id#, name, addresses. The
total number of credits and the semester code need to be also included.
Complete information about a student has to be produced in a report format,
including his or her major (s) and all grades received to date, together with a
summary.
A faculty information report lists all faculty by department and contains each faculty
members information found in the FACULTY relation (see below), along with the
code number and description of the major in which the faculty member is
advising each one and the code number and description of the department in
which this major is housed. The department need not be the one to which the
faculty member is assigned.

Transaction Requirements

In addition to being able to add, change, and delete any of the entities
mentioned in the report requirements, the update requirements include the following:
When a student attempts to register for a section of a course, determine whether he
or she has received credit for all prerequisites to the course. A student can be
enrolled only when this condition is satisfied, and the number of students
currently enrolled in the section is less than the maximum enrollment.
Section information, including grades assigned by the section, is retained for two
semesters following the end of the semester, at which time the information is
removed from the database. Note that grades assigned to students are retained
by course, not by section.
Use a DFD to represent this system.

EXERCISES

1. Give a brief description of a data flow diagram? What is the difference between

a DFD and a flowchart?

45 | P a g e
2. List at least 3 synonyms for DFD.

3. What can DFDs be used for besides modeling information systems?

4. What are the four major components of a DFD?

5. Is there any significance to the choice of a rectangle for a process? Would it be

better to use a triangle or a hexagon? Why or why not?

6. What is wrong with the following process?

7. What is wrong with the following process?

8. What is wrong with the following process?

IF X>3
60 00
QUARK 7
CUSTOMER
RECORD
9. What is wrong with the following process?

APPLES

10. What is wrong with the following process?

STUFF

11. Why would a systems analyst draw a DFD with a process consisting of the name

of a person or organizational group?

12. Are flows on a DFD restricted to just showing the movement of information?

Could they show the movement of anything else?

13. What is wrong with this DFD?

46 | P a g e
14. What is wrong with this DFD?

15. How can the same chunk of data have different meanings in a DFD? Draw an

example of such situation.

16. What is the significance of the following DFD?

X X
COMPUTE
STUFF
18. Is there any limit to the number of inputs and outputs that a process can have in

a DFD? What would your reaction be if you saw a process with 100 inputs and

100 outputs?

19. What is wrong with the following DFD?

A B

20. What is wrong with the following DFDs?

X Y

21. What is wrong with the following DFDs?

Y b a

47 | P a g e
 21. What is wrong with the following DFD?

a
c
b

22. What is wrong with the following DFD?

a a c

b COMPUTE
FLURP
FACTOR
23. Give a description of a dialogue flow.

24. Is the following DFD valid? Is there any other way to draw it?
Y
x
Make y
y

25. Is the following DFD valid? Is there any other way to draw it?

26. Under what circumstances would you expect to see duplicate copies of an output

flow from a process?

27. Why do DFDs avoid showing procedural details?

28. In the diagram below, how many x and how many y elements are required to

produce one z output?

z
y

29. What does a store show in a DFD?

48 | P a g e
30. What is the convention for naming stores in a DFD?

31. What are alternative names for a store? Is it acceptable to use the term fits?

Why or why not?

32. What names are commonly used to describe packets of information in a store?

33. What are the four common reasons for showing implementation stores in a DFD?

34. Do you think implementation stores should be allowed in a DFD? Why or why

not?

35. What is the meaning of an unlabeled flow into or out of a store?

36. Is there any limit to the number of flows into or out of a store? If so, state what

the limit is.

37. What is wrong with the following DFDs?

a.

b.

c.

d.

49 | P a g e
 e.

38. What are the four possible interpretations of a dataflow from a store into a

process?

39. Does the following DFD make sense? Why or why not?

customer record

a customer

customer address

40. Give an example of a situation where a process might extract portions of more

than one record from a store in a single logical access.

41. Give an example of a situation where a process might extract more than one

packet of information from a store in a single logical access.

42. Can you tell from looking only at the diagrams whether the following DFDs are

correct?

50 | P a g e
a.

b.

inventory data

customers

c.

x
43. What happens to a store after data have moved from the store, along a flow, to a

process? Is this true of all types of systems or just information systems?

44. What are the three possible interpretations of a flow into a store?

45. How do we show packets of data being deleted from a store?

46. What is wrong with the following DFD?

Missile trajectory

47. What is the purpose of showing a terminator on a DFD?

48. How should the systems analyst identify the terminators?

49. What do the flows between terminators and processes represent?

50. What is wrong with the following DFDs?

a. CUSTOMER
ORDER
SYSTEM

51 | P a g e

CUSTOME
ORDER
R SYSTEM
 b.

c.
COMPUTE COMPUTE
TAXES NET PAY

d. JOHN

SYSTEM

FRED

51. Is the system analyst allowed to change the contents or organization of a

termination or part of her project? What if she feels strongly that it should be

changed?

52. Why should a process not show the name of the person currently performing that

function?

53. What is a good guideline for naming the processes in a DFD?

54. Give five examples of process names that you would not like to see in a DFD.

55. How can you tell whether the name chosen for a process is likely to be

meaningful?

52 | P a g e
56. What is the misinterpretation that a user is likely to make of process numbers in a

DFD?

57. How can you tell whether a DFD is likely to be too complex for the user to

comprehend?

58. How rigidly enforced should the complexity guideline be? Should any exceptions

be allowed? Why or why not?

59. Why is it often necessary to redraw a DFD many times?

60. What are the major issues that determine whether a DFD is esthetically

pleasing? Do you think that these issues can be expressed as standards?

61. Do your colleagues prefer bubbles or rectangles for processes? Which do you

prefer?

62. Do you think the dataflow between processes should be shown as curved lines

or straight lines? Can you think of any advantage or disadvantage of either

approach? Is it an important issue?

63. What is an infinite sink? Why should it be considered an error in a typical DFD?

64. What are spontaneous generation processes/rectangles in a DFD? Why should

they be avoided in a typical DFD?

65. Why are unlabeled flows and processes dangerous?

66. What are read-only stores and write-only stores typically an error in a DFD?

67. Why are leveled DFDs important in a system model?

68. How many levels of DFD should the systems analyst expect to see in atypical

large system? Can you suggest an upper limit on the number of levels in a

DFD?

53 | P a g e
69. In a leveled DFD:

(a) What would we call the children processes below process 2.3?

(b) What would be the figure name of the figure in which process 2.3

appears?

(c) How many higher-level figures are there above the figure in which

process 2.3 appear? What are they called?

70. Is it necessary for all parts of a system to be partitioned to the same level of

detail? Why or why not?

71. Suppose someone showed you a DFD in which process 1 was partitioned into 2

lower levels, and process 2 was partitioned into 17 lower levels. What would

your reaction be? What recommendations, if any, would you make?

72. What does balancing mean, in the context of this chapter? How can you tell

whether a DFD is balanced?

73. What is the guideline for showing stores at different levels of a DFD?

74. What is a local store? What are the guidelines for showing a local store in a

leveled DFD?

References/Bibliography

Ashworth, Caroline; Goodland Mike; SSADM; A Practical Approach; Copyright

1990, McGraw Hill Book Co. (UK) Ltd.

Calderon, Jose F, Expectacion C. Gonzales, Measurement and Evaluation, Manila:

National Bookstore Inc., 1993, p46

54 | P a g e
Calmorin, Laurentina P., Educational Research Measurement and Evaluation, 2 nd
Edition, Manila: National Bookstore Inc. 1994, pp 66-67

Date, Chris, An Introduction to Database Systems, Vols. I and II. Fourth Edition.
Addison-Wesley, Reading, MA, 1987.

Dierkes, Meinoff;Antal, Ariane; Child John; Nonaka Ikujiro (eds.), Handbook of

Organizational Learning and Knowledge, Oxford University Press, 2001

Hawryskiewycz, IT Introduction to Systems Analysis and Design Second Edition;

Copyright

Hoffer, J. A, George J.F Valacieh, J.S, Modern Systems Analysis and Design
Copyright 1996 by the Benjamin/Cumming Publishing Co. Inc.

Kendall, Kenneth E; Kendall Julie E, 2nd Ed. Systems Analysis and Design Copyright
1992 by Prentice Hall Inc.

Maisbith, John, Aburdeen, Patrick; The Skills of the New Information Society,
McRoval & Co. Ltd., Greater London House

Martin E. Modell, A Professionals Guide to Systems Analysis. Second Edition.

United States of America, 2003

McLeod, Raymond Jr.; Management Information Systems 6th ed. Copyright

1995 by MacMillan Publishing Company

S.L. Pfleeger, Software Engineering Theory and Practice. Second Edition. Prentice
Hall. Upper Saddle River, NJ, 2001.

Silver, Gerald A; Silver, Myrna L.; Systems Analysis and Design; Copyright
1989 by Addison-Wesley Publishing Company, Inc.

55 | P a g e
56 | P a g e