81

UNIT 5

SYSTEM ANALYSIS
Learning Objectives
After having read this unit, you will be able to

define system analysis;

understand the aim and process of system analysis;

describe the strategies to determine information requirements;

understand structured system analysis tools.

Structure
5.1. Introduction
5.2. Requirement Determination
5.3. Strategies for Requirement Determination
5.4. Structured Analysis Tools
5.5. Summary
5.6. Review Questions

5.1. Introduction
System analysis may be understood as a process of collecting and interpreting
facts, identifying problems and using the information to recommend
improvements in the system. In other words, system analysis means
identification, understanding and examining the system for achieving predetermined goals/objectives of the system. System analysis is carried out with
the following two objectives.

82
i)

to know how a system currently operates, and

ii)

to identify the users requirements in the proposed system.

Basically, system analysis is a detailed study of all important business aspects

under consideration and the existing system, and thus, the study becomes a
basis for the proposed system (may be a modified or an altogether new
system). System analysis is regarded as a logical process. The emphasis in this
phase, is on investigation to know how the system is currently operating and to
determine what must be done solve the problem.
The system analysis phase is very important in the total development efforts of
a system. The user may be aware of the problem but may not know how to
solve it. During system analysis, the developer (system designer) works with
the user to develop a logical model of the system. A system analyst, because of
his technical background, may move too quickly to program design to make
the system prematurely physical, which is not desirable and may affect the
ultimate success of the system. In order to avoid this, the system analyst must
involve the user at this stage to get complete information about the system.
This can be achieved if a logical model of a system is developed on the basis
of a detailed study. Such a study (analysis) should be done by using various
modern tools and techniques, such as data flow diagrams, data dictionary and
rough descriptions of the relevant algorithms. The final product of the system
analysis is a set of system requirements of a proposed information system. The
following pages will discuss determination of system requirements and system
analysis tools.

5.2. Requirement Determination

Requirement determination, which is also termed as a part of software
requirement specification (SRS) is the starting point of the system
development activity. This activity is considered as the most difficult and also
the most error-prone activity because of the communication gap between the
user and the developer. This may be because the user usually does not
understand software and the developer often does not understand the users

83
problem and application area. The requirement determination is a means of
translating the ideas given by the user, into a formal document, and thus to
bridge the communication gap. A good SRS provides the following benefits.
i)

It bridges the communication gap between the user and the above
developer by acting as a basis of agreement between the two parties.

ii)

It reduces the development cost by overcoming errors and

misunderstandings early in the development.

iii)

It becomes a basis of reference for validation of the final product and

thus acts as a benchmark.

Requirement determination consists of three activities, namely requirement

anticipation,

requirement

investigation

and

requirement

specification.

Requirement anticipation activities include the past experience of the analysis,

which influence the study. They may foresee the likelihood of certain
problems or features and requirements for a new system. Thus, the
background of the analysis to know what to ask or which aspects to investigate
can be useful in the system investigation. Requirement investigation is at the
centre of system analysis. In this, the existing system is studied and
documented for further analysis. Various methods like fact-finding techniques
are used for the purpose. In the requirement specification activities, the data
produced during the fact-finding investigation is analysed to determine
requirement specification, which is the description of the features for a
proposed system.
Requirement determination, infact, is to learn and collect the information
about
i)

the basic process,

ii)

the data which is used or produced during that process,

iii)

the various constraints in terms of time and the volume of work, and

iv)

the performance controls used in the system.

84
Let us discuss these activities in more detail.

5.2.1. Understand the Process

Process understanding can be acquired, if the information is collected
regarding
i)

the purpose of the business activity,

ii)

the steps, which and where they are performed,

iii)

the persons performing them, and

iv)

the frequency, time and user of the resulting information.

5.2.2. Identify Data Used and Information Generated

Next to process understanding, an information analyst should find out what
data is used to perform each activity. For example, in an inventory system, the
buyer may require data describing the quantity of an item, supplier name, item
cost and demand for the item. To know when to place an order, the buyer
would also like to get the information regarding lead time. The information
generated in business transactions is also required to be gathered; as such
information may be used by managers in many decision-making activities. For
example, data about inventory system also provides information about
warehousing, sales and cash flow decisions.

5.2.3. Determine Frequency, Timing and Volume

Information should also be collected to know how often the activity is
repeated and the volume of items to be handled. Similarly, timing does affect
the way analysts evaluate certain steps in carrying out an activity. In other
words, timing, frequency and volume of activities are important facts to
collect.

85

5.2.4. Know the Performance Controls

System controls enable analysts to understand how business functions can be
maintained in an acceptable manner.
During system investigation, information is gathered mainly from personnel
and written documents from within the organizations environment, which
includes financial reports, personnel documents and various other types of
documents like transaction documents, manuals, etc. To get information about
the external environment, the sources include vendors, various government
and private agencies, newspapers and journals, etc.
It must be understood that the personal managerial attributes of the individual
manager and the organizational environment in which decisions are made
affect the information requirements for the proposed system. the personal
attributes may be a mangers knowledge of information systems, managerial
style,

his

perception

of information

needs,

whereas

organizational

environment factors may include nature of the company, level of management

and structure of the organization.
As already mentioned, system analysis consists of two main activities.
i)

Studying the business operations to understand the existing system.

ii)

To make an analysis of the information gathered to determine

information requirements of the manager in the proposed system.

In order to study the business operations of the organization and thus to know
the existing system and information requirements for the new system, an
information analyst collects the information and then makes an analysis of the
collected information by using certain analysis tools.

5.3. Strategies for Requirement Determination

In order to collect information so as to study the existing system and to
determine information requirement, there are different strategies, which could
be used for the purpose. These strategies are discussed below.

86

5.3.1. Interview
The interview is a face-to-face method used for collecting the required data. In
this method, a person (the interviewer) asks questions from the other person
being interviewed. The interview may be formal or informal and the questions
asked may be structured or unstructured. The interview is the oldest and the
most often used device for gathering information about an existing system.
The respondents are generally current users of the existing system or potential
users of the proposed system. Although it is one of the preferred techniques,
interviewing is not always the best source of application data. Because of the
time required for interviewing and the inability of the users to explain the
system in detail, other methods are also used to gather information.
However, this method is helpful for gathering information from individuals
who so not communicate effectively in writing or who may not have the time
to answer questionnaires. Interviews allow analysts to discover areas of
misunderstanding, unrealistic expectations and even indication of resistance to
the proposed system.
The analyst must plan the interviews and must know clearly in advance
regarding the following issues.
i)

Whom to interview?

ii)

When to interview?

iii)

What to ask?

iv)

Where to hold the interview?

v)

How to begin the interview?

vi)

How to conclude the interview?

Interviewing is regarded as an art it is important that analysts must be trained

in the art of successful interviewing. This is also important because of the fact
that the success of an interview depends on the skill of the interviewer and on
his or her preparation for the interview.

87

5.3.2. Questionnaire
A questionnaire is a term for almost any tool that has questions to which
individuals respond. The use of questionnaires allows analysts to collect
information about various aspects of a system form a large number of persons.
The questionnaire may contain structured or unstructured questions. The use
of a standardized questionnaire may give more reliable data than other factfinding techniques. Also the wide distribution ensures greater anonymity for
respondents, which can lead to more honest responses. The questionnaire
survey also helps in saving time as compared to interviews. However, this
method does not allow analysts to observe the expressions or reactions of
respondents as are possible during interviewing and also, it is difficult to
design exhaustive questionnaires. The analyst should know the advantages and
disadvantages of structured as well as unstructured questionnaires.
Questionnaires must be tested and modified as per the background and
experience of the respondents.

5.3.3. Record Review

Record review is also known as review of documentation. Its main purpose is
to establish quantitative information regarding volumes, frequencies, trends,
ratios, etc. In record review, analysts examine information that has been
recorded about the system and its users. Records/documents may include
written policy manuals, regulations and standard operating procedures used by
the organization as a guide for managers and other employees. Procedures,
manuals and forms are useful sources for the analyst to study the existing
system. The main limitation of this approach is that the documentation on the
existing system may not be complete and up-to-date. It may be noted here that
there are two different views regarding the study of the existing system. One
view, which favors the study of the existing system, is that through study of
the existing system, is that through study of the existing system, one learns
about its shortcomings and may use this knowledge to avoid committing the
same mistakes again. Whereas the view which is against such a study, argues
that it inhibits the generation of new ideas and may bias the developer towards

88
the same logic which is contained in the old system. It is difficult to comment
upon the two views. However, both the views seem valid. It can only be
suggested here that an information analyst should study the existing system, if
any, to know more about the whole of the system.

5.3.4. Observation
Another information gathering tool used in system studies is observation. It is
the process of recognizing and noticing people, objects and occurrences to
obtain information. Observation allows analysts to get information, which is
difficult to obtain by any other fact-finding method. This approach is most
useful when analysts need to actually observe the way documents are handled,
processes are carried out and whether specified steps are actually followed. As
an observer, the analyst follows a set of rules. While making observations,
he/she is more likely to listen than talk. The exercise is time-consuming and
costly. Also the observer may not be able to get all the required information
especially about some intricacies of the system. Nowadays, electronic
observation-gathering tools because of their speed and efficiency.
The analysts usually use a combination of all these approaches to study an
existing system, as any one approach may not be sufficient for eliciting
information requirement of the system.
The fact-finding techniques which have been discussed above represent only
one aspect of system analysis. Various tools for organizing the details
collected are discussed as follows.

5.4. Structured Analysis Tools

Structured analysis tools help the system analyst to document the system
specification of a system to be built. The main tools which are used for the
purpose are given below.
i)

Data Flow Diagram (DFD)

ii)

Data Dictionary

89
iii)

Structured English

iv)

Decision Trees

v)

Decision Tables

5.4.1. Data Flow Diagram (DFD)

Data Flow Diagram (DFD) is a graphical representation of the logical flow of
data. It helps in expressing the systems requirements in a simple and
understandable form.
It is also known as a bubble chart. Its aim is to clarify the system requirements
and identify major transformations that will become programs in system
design. It decomposes the requirement specifications down to the lowest level
of details.
A DFD consists of a series of bubbles joined by lines representing data flow in
the system.
There are four main symbols used in DFD, which are depicted below.
i) Square : It represents source/ destination of system data.

ii ) Arrow: It identifies data flow; it is a pipeline through which the data

flows.

iii) Circle/ Bubble: It represents a process that transforms incoming data flow
into outgoing data flow. A process can be represented by a circle or an oval
bubble.

90

iv) Open Rectangle: It represents a data store

A number of rules are to be followed in drawing a DFD:

i)

Processes should be named and numbered. Name should represent the

process.

ii)

The direction of flow is from top to bottom and from left to right.

iii)

When a process is exploded into lower levels, they are numbered

properly, e.g. the process obtained from the explosion of process
number 5, should be numbered as 5.1, 5.2, etc.

iv)

The name of data stores, sources and destinations are written in capital
letters. Process and data flow names have the first letter capitalized.

A DFD should have no more than 10-12 processes, as having even 12 will
make a DFD complex and difficult to understand.
A DFD shows the minimum contents of a data store. Each data store should
contain all the elements that flow in and out of it.
DFD is very effective, when the required design is not clear and the user and
the analyst require some symbolic representation for communication.
The main disadvantage of DFD is that a large number of iterations are often
required to arrive at an accurate and complete solution.

91
For example, consider the case of a payroll system to prepare salary
statements for each employee of an organization. Data flow for such a system
can be represented, as shown in Figure 5-1.
Employee

Employee
Data
Payroll
Processin
g

Salary Statement

Accounts Department

Updated data
Figure 5-1 A DFD for payroll Processing: Macro View

Employee File

Sink

Employee Data

Accou
nts
Depart
ment

Employ
ee

Employees
Gross Salary
Gross
Salary
Processin
g

Net
Salary
Computat
-ion

Salary
Statement

Source
Deductions

Various Deductions

Updated Data

Updated Data on
Employee

Figure 5-2 A DFD for Payroll Processing: Exploded View

Employees data originate from accounts departments (source), gets processed,

salary statements are received by employees (sink) and updated data on

92
employees (e.g. total tax deducted, provident fund contribution, etc.) is stored
in an intermediate file (data store), which is required for processing in the
subsequent months.
A DFD displays data flow in a top-down approach. To draw a DFD, start with
a macro DFD (overview) and then explode it into micro DFDs. Figure 5-2
illustrates the method.
While exploding a DFD into lower levels, continuity and linkage is maintained
between a DFD and its member DFDs. This is achieved by numbering each
circle (processing step) by adopting the numbering system, e.g. 1,2,3,, each
further numbered as 1.1,1.2, 1.3, ., and still further numbered as 1.1.1, 1.1.2,
. Figure 5.3 illustrates the point.

Processin
g1
1.2.1

1.1

1.2
1.2.2

Figure 5-3 Explosion of DFD

5.4.2. Data Dictionary

A data dictionary is a structured repository of data, about data. In other words,
it is a set of precise and accurate definitions of all DFDs, data elements and
data structures.
It supports documentation in a better way. It also improves communication
between the user and analyst as it provides precise and consistent definitions
for various data elements, terms and procedures. It can also serve as a

93
common database for programmers and can also be used for control purposes.
Most databases have data dictionary as a desirable feature.
There are mainly three items of data present in a data dictionary.
i)

Data Element: It is the smallest unit of data and cannot be

decomposed further.

ii)

Data Structure: It is a group of data elements handled as a unit. A

data structure contains a number of data elements as its fields.

iii)

Data Flows and Data Stores: Data flows are nothing but data
structures in motion, whereas data stores are data structures at rest. In
other words, data stores are locations where data structures are
temporarily stored. Data dictionary is an integral part of the structured
specifications.

The following rules are followed in constructing a data dictionary.

i)

The terms used to describe data structures are always in capital letters.

ii)

Multiple word names are hyphenated.

iii)

Assigned names should be straight-forward and user-oriented.

iv)

There should be names for every data flow, data store, data structure
and data element.

v)

Consistency checks should be performed.

vi)

Identification numbers of the processes and their names should be

mentioned in the data dictionary.

vii)

Aliases must be discouraged.

Various symbols which are used in the data dictionary are explained in Table
5-1.

94
Table 5-1
Symbols used in Data Dictionary
Symbol
=
+
Option 1

Meaning
Is equivalent to
Add
Only one of the options is used at a given time

Option 2
:
:
Max

Iteration of the component

{Component}

Min = lowest possible number of iterations.

min
{component}
* Comment*
An Example:

Max = highest possible number of iterations.

Component is an optional one
Words within asterisks are comments.

VENDOR INVOICE
= INVOICE-NUMBER + VENDOR-NAME +
TOTAL-INVOICE-AMOUNT + INVOICE-DUE-DATE
+ (SHIPPING-DATA)
30

{ITEM-DETAIL-LINE}
1

* One extra copy may be kept *

Data dictionary and DFD are correlated and data should be present in a
specification. However, a DD does not provide functional details and thus is
not very acceptable among non-technical users.

5.4.3. Decision Tree and Structured English

The logic of the process, which may not be very clear through DD, can easily
be represented using a graphic representation, which looks like the branches of
a tree, called decision tree. A decision tree has as many branches as there are
logical alternatives. It is easy to construct, read and update. For example, a
policy can be shown through a decision tree (see Figure 5-4).
Type of Customer

Size of Order

Discount

Dealer

6 or more

35%

95
Less than 6
Discount
Policy

Educational
Institution or
Individual

50 or more
20 49
6 -19
Less than 6
Figure 5-4 A Decision Tree An Example

Nil
30%
20%
15%
Nil

The example illustrates the following discount policy.

Computer dealers get a trade discount of 35 per cent if the order size is 6 or
more PCs, whereas for orders from educational institutions and individuals, 15
per cent discount is allowed on orders of 16 19 PCs, per PC type; 20 per cent
on orders for 20 - 49 PCs; 30 per cent on orders for 50 PCs or more, per PC
type.
Alternatively, the logic can be represented by using Structured English. It uses
logical construction and imperative sentences designed to carry out
instructions for actions. Decisions are made through If-THEN-ELSE
statements.
Structured English can be made compact by using terms defined in the data
dictionary. However, its sentences should be clear, concise and precise in
wording and meaning. For example, the process ORDER may have the data
element ORDER-SIZE, which defines the following values.
MINIMUM

5 OR LESS Personal Computers, per PC type

SMALL

6 TO 19 PCs

MEDIUM

20 TO 49 PCs

LARGE

50 OR MORE PCs

DISCOUNT-POLICY
Add up the number of PCs per PC type
If order is from a dealer
And if ORDER-SIZE IS SMALL OR MEDIUM OR LARGE
THEN: Discount is 35%
ELSE (ORDER-SIZE IS MINIMUM}
So: no discount is allowed
ELSE {ORDER is from educational institution or individual customers}
SO IF ORDER-SIZE IS LARGE

96
Discount is 30%
ELSE IF ORDER-SIZE IS MEDIUM
Discount is 20%
ELSE IF ORDER-SIZE IS SMALL
Discount is 15%
ELSE (ORDER-SIZE IS MINIMUM)
So: no discount is allowed.

Figure 5-5 Structured English An Example

Using these values, structured English would read as shown in Figure 5-5.
Decision trees can be used to verify logic in problems that involve few
complex decisions, resulting in a limited number of actions. However, its
biggest limitation is the lack of information due to its structure.

5.4.4. Decision Table

Decision table is a matrix of rows and columns that shows conditions and
actions. Decision rules state the procedure to be followed when certain
conditions exist.
Decision tables are best-suited for dealing with complex branching routines,
e.g. inventory control, etc.
A decision table consists of four sections.
A condition stub at the upper left, a condition entry at the upper right, an
action stub at the lower left, and an action entry at the lower right (see Figure
5-6).
Condition Stub Condition Entry
Action Stub
Action Entry
Stub
Entry
Figure 5-6 A Decision Table
Questions are listed in the condition stub and the action stub outlines the
action to be taken to meet each condition.

97
The condition entry part contains the answers to questions asked in the
condition stub and the action entry part indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.
In constructing a decision table, the following rules are observed.
i)

A decision should be given a name to be written at the top left of the

table.

ii)

The logic should be independent of the sequence in which the

condition rules were written, but the actions take place in the order in
which the events occur.

iii)

Consistent and standardized language should be used.

iv)

Duplication of terms should be avoided to the maximum extent.

A decision table of the earlier problem is constructed in Figure 5-7

Is the customer a dealer?

1
Y

Condition Entry
2
3
4
5
Y
N
N
N

6
N

Is the order size 6 PCs or more?

Condition Stub

Is the customer educational institution or

individual?
Is the order size 50 or more PCs?
Is the order size 20 to 49 PCs?
Is the order size 6 to 19 PCs?
Action Stub
Allow 35% discount
Allow 30% discount
Allow 20% discount
Allow 15% discount
Figure 5-7 Decision Table An Example.

Action Entry
X
X
X
X

5.5. Summary
System analysis is a detailed study of all important business aspects under
consideration and the existing system, and thus, the study becomes a basis for

98
the proposed system. The final product of the system analysis is a set of
system requirements of a proposed information system.

Requirement

determination consists of three activities, namely requirement anticipation,

requirement investigation and requirement specification. Requirement
anticipation activities include the past experience of the analysis, which
influence the study. Requirement investigation is at the centre of system
analysis. In this, the existing system is studied and documented for further
analysis. In the requirement specification activities, the data produced during
the fact-finding investigation is analysed to determine requirement
specification, which is the description of the features for a proposed system.

5.6. Review Questions

1) What is meant by system analysis? Discuss its main objectives.
2) Discuss and illustrate the main strategies for eliciting information
about the users requirements. Which strategy would you like to select?
Why?
3) What is structured analysis? Briefly discuss the tools used in structured
analysis.
4) Describe, with the help of a suitable example, the concept and
procedure used in constructing DFDs.
5) Elaborate the symbols used in constructing DFDs. Give basic rules for
constructing a DFD.
6) Discuss a decision tree and a decision table. Are decision trees and data
flow diagrams related? Discuss.