CHAPTER V

SYSTEM ANALYSIS
5.1. Determining System Requirement
System analysis is the study of a business problem for the purpose of recommending improvements
and specifying the business requirements for the solution. Systems analysis is the part of the systems
development life cycle in which you determine how a current information system in an organization
functions. Then you assess what users would like to see in a new system. There are three parts to
system analysis: determining requirements, structuring requirements, and selecting the best
alternative design strategy.
During requirement determination, you and other analysts gather information on what the system should do
from as many sources as possible. Such sources include users of the current system, reports, forms, and
procedures.
The characteristics of a good systems analyst in determining the requirements are:
 Impertinence: You should question about each and every aspects involved in the system.
 Impartiality: The role of a SA is to find the best solution to a business problem or
opportunity. Not to justify the purchase of new hardware or to insist some requirements. The
issues raised by all parties must be considered and to find the best organizational solution.
 Relaxing of Constraints: Assume that anything is possible and eliminate the infeasible and
traditions. Traditions are different from rules and policies; it may be good but as the
organization and its environments changes, the traditions not to be appreciated.
 Attention to details: Every fact must fit with every other fact. One element out of place
means that the ultimate system will fail at some time.
 Reframing: Analysis is, in part, a creative process; the organization must be viewed in new
ways. Not to jump to this conclusion that “I worked on a system like that once - this new
system must work the same way as the one I built before”.
Deliverables and Outcomes
The primary deliverables from requirement determination are the types of information gathered
during the determination process. The deliverables summarized in table 1 contain the information
you need for systems analysis.

Types of Deliverables Specific Deliverables

Information collected from conversations with users

1 Interview transcripts
Questionnaire responses
Notes from observations
 Table 5.1deliverables for requirements determination
 Traditional Methods for Determining requirements
 The traditional way of requirement determination includes interviews, questionnaires, and
direct observation.
These traditional methods of collecting system requirements are listed in table 5.2.
Traditional Activities Involved
Method Interview individuals informed about the operation and issue of the current
Interviews with System and needs for the systems in future organizational activities.
individuals
Survey people via questionnaire to discover issues and requirements.
Questionnaire
Observe workers at selected times to see how data are handled and what
On job observation information people need to do their jobs.

Study business documents to discover reported issues, policies, rules, and

Business directions as well as concrete examples of the use of data and information
documents in the organization.
Table 5.2 traditional methods of collecting system requirements
Modern Methods for determining requirements
In addition to the traditional methods of system requirement determination, there are additional techniques to
collect information about the current system, the organizational area requesting the new system, and what the
new system should be like. These techniques can support effective information collection and structuring while
reducing the amount of time required for analysis.
Joint Application Design (JAD)

2
The primary purpose of using JAD in the analysis phase is to collect systems requirements simultaneously from
the key people involved with the system. The result is an intense and structured, but highly effective process.
Having all the people together in one place at one time allows analysts to see the areas of agreement and the
areas of conflict. The following is the list of typical JAD participants:
1. JAD Session Leader: the JAD leader organizes and runs the JAD.
2. User: the key users of the system under consideration are vital participants in JAD.
3. Managers: managers of the work groups who use the system in question provide insight into new
organizational directions, motivations for and organizational impacts of systems, and support for
requirements during the JAD.
4. Sponsor: due to its expense, someone a relatively high level in the company such as a vice president or chief
executive officer must sponsor a JAD.
5. System analysts: members of the system analysis team attend the JAD although their actual participation
may be limited.
6. Scribe: the scribe takes notes during the JAD session, usually on a personal computer or laptop.
7. IS staff: beside system analysts, other IS staff such as programmers, database analysts, IS planners, and data
center personnel may attend the session.

Figure-5.1 A typical room layout for a JAD session

Prototyping
To establish requirements for prototyping, you will still have to interview users and collect documentations.
Prototyping however allows you quickly to convert basic requirements into a working, though limited version
of the desired information system. The user then views and tests the prototype. You may redesign the

3
 prototype to incorporate the suggested changes by the user. Once modified, users would again view and test the
prototype. Once again, you would incorporate their suggestion for change. Through such a repetitive process,
the chances are good that you will be able to better capture a systems requirement. The goal with using
prototyping to support requirements determination is to develop concrete specification for the ultimate system,
not to build the ultimate system.
5.2. Structuring System Requirements
During requirement structuring you study the requirements and structure them according to their
interrelationships, eliminating the redundancy. There are three primary activities performed during requirement
structuring.
1. Process modeling
2. Logic modeling
3. Conceptual Data Modeling
1. Process modeling
It involves graphically representing the process, or actions, that capture, manipulate, store, and distribute data
between a system and its environment among components with in a system. A common form of a process
model is a Data Flow Diagram (DFD).
A Data Flow Diagram is a graphic that illustrates the movement of data between external entities and the
process and data stores within a system.
Modeling System Process
The analysis team begins the process of structuring requirements with an abundance of information gathered
during requirements determination. In structured analysis, the primary deliverables from process modeling are a
set of coherent, interrelated data flow diagrams. Deliverables of the process modeling are:
- Context DFD
- DFDs of current physical system
- DFDs of new logical system
- Through description of each DFD component
First, a context DFD shows the scope of the system, indicating which elements are inside and outside the
system. Second data flow diagrams of the current system specify which people and technologies are used in
which process to move and transform data, accepting inputs, and producing outputs. Third technology
independent or new logical DFD shows the data flow structure and functional requirements of the new system.
Finally, entries for all of the objects included in all diagrams are included in the project dictionary or CASE
repository.

Data Flow Diagramming Methods

DFDs are versatile diagramming tools with only four symbols. Data flow diagrams can represent both physical
and logical information systems. The four symbols in the DFD represent data flows, data stores, processes, and
sources/sinks (external entities). The symbols used in data flow diagrams are illustrated in fig 5.1.

Data flow 1

Interface 1
4
 Data Flow Source/Sink

Data Store 1 Data Store

Process 1 Process
Figure5.2 data flow diagramming symbols developed by Gane & Sarson
A Data Flow is data that are in motion and moving as a unit from one place in a system to another.
A Data Store is a data at rest. A data store may represent one of many different physical locations for data
including a file folder, one or more computer-based file(s), or a notebook.
A Process is the work or action performed on data so that they are transformed, stored or distributed.
A Source/Sink is the origin and/or destination of the data. Sources/Sinks are sometimes referred to as external
entities because they are outside the system. A source/Sink might contain the following:
 Another organization or organizational unit that sends data to or receives information from the
system you are analyzing.
 A person inside or outside the business unit supported by the system you are analyzing and who
interacts with the system.
 Another information system with which the system you are analyzing exchanges information.
Developing DFDs
First, the boundary or scope of the system, and the systems interrelation ship to its environment is represented
by data flow diagram called a context diagram. Context Diagram a DFD of the scope of an organizational
system that shows the system boundaries, external entities that interact with the system and the major
information flows between the entities the system. All context diagrams have only process labeled “0”.
Second, a context diagram is a DFD that provides a general overview of a system. Other DFDs can used to
focus on the details of a context diagram. A Level-0 diagram is an example of such a DFD. A level-0 diagram
represents the primary individual processes in the system at the highest possible level of detail.
Data Flow Diagramming Rules
You must follow a set of rules when drawing data flow diagrams. These rules listed below, allow you to
evaluate DFDs for correctness.
Rules governing Data Flow Diagramming
Process
A. No process can have only outputs. It is making data from nothing (a miracle). If an object has only outputs,
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 label.
Data Source

5
D. Data cannot move directly from one data source to another data store. Data must be moved by a process.
E. Data cannot move directly from an outside source to a data store. Data must moved by a process that
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. Data must be moved by a process.
G. A data store has a noun phrase label.
Source/Sink
H. Data cannot move directly from a source to a sink. They must be moved by a process if the data are of any
concern to our system. Otherwise, the data flow is not shown on the DFD.
I. A source/Sink has a noun phrase label.
Data Flow
J. A data flow has only one direction of flow between symbols. It may flow in both direction between a
process and a data store to show a read before an update. The latter is usually indicated; however, by two
separate arrows because these happen at different times.
K. A fork in a data flow means that exactly the same data go 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 locations).
L. A join in a data flow means that exactly the same data come 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
that handles the data flow, produces some other data flow, and returns the original data flow to the
beginning process.
N. A data 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 as all of the flows on the same arrow move together as one package.
Decomposition of DFDs
Decomposition is a repetitive process of breaking the descriptions or perspective of a system down into finer
and finer detail.
Level-n diagram: a DFD that is the result of n-nested decompositions of a series of sub process from a process
on a level-0 diagram.
Balancing DFDs
The conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a
lower level.
2. Logic modeling
Although data flow diagrams are very good for identifying process, they do not show the logic inside the
process. Logic modeling involves representing the internal structure and functionality of the processes
represented on data flow diagrams. There are two methods used most commonly modeling system process.
1. Structured English
2. Decision Tables
1) Modeling Logic with Structured English

6
Starting with the processes depict in the various sets of data flow diagram you and others on the analysis team
have produced, you must now begin to study and document the logic of each process. Structured English: is a
modified form of English that is used to specify the contents of process boxes in DFD. It uses a subset of
English vocabulary to express information system process procedures. Structured English uses strong verbs
such as read, write, print, sort, move, merge, add, subtract, multiply, and divide. Unlike regular English,
structured English does not use adjectives or adverbs.
The whole point of using structured English is to represent process in a short hand manner that is relatively easy
for users and programmers to read and understand. It is possible to use structured English to represent all three
processes typical to structured programming: sequence, conditional statements, and repetitive.
Example
Conditional statements can be represented with a structure like the following.
BEGIN IF
IF Quantity-in-stock is less than Minimum-order-quantity
THEN GENERATE new order
ELSE DO nothing
END IF
A case statement might be represented as:
READ Quantity-in-stock
SELECT CASE
CASE 1 (Quantity-in-stock greater than Minimum-order-quantity)
DO nothing
CASE 2 (Quantity-in-stock equals Minimum-order-quantity)
DO nothing
CASE 3 (Quantity-in-stock less than Minimum-order-quantity)
GENERATE new order
CASE 4 (Stock out)
INITIATE emergency reorder routine
END CASE
Repetition can take the form of Do-until loops or Do-While loops.
A Do-Until loop might be represented as follows:
DO
READ Inventory records
BEGIN IF
IF Quantity-in-stock is less than Minimum-order-quantity
THEN GENERATE new order
ELSE DO nothing
END IF
UNTIL End-of-file
A Do-While loop might be represented as follows:
READ Inventory records
WHILE NOT End-of-file DO
BEGIN IF
IF Quantity-in-stock is less than Minimum-order-quantity
THEN GENRATE new order
ELSE DO nothing

7
 END IF
END DO
2) Modeling Logic with Decision Tables
If several different conditions are involved, and combinations of these conditions dictate which of several
actions should be taken, then structured English may not be adequate for representing the logic behind such a
complicated choice. A Decision Table is a diagram of process logic where the logic is reasonably complicated.
All of the possible choices and the conditions the choices depend on are represented in tabular form.

Example Rules
Conditions/Courses of Action 1 2 3 4 5 6 Condition
Stubs Employee Type S H S H S H
Hours Worked <40 <40 40 40 >40 >40

Pay Base Salary X X X

Action
Calculate Hourly Wage X X X
Stubs
Calculate Overtime X
Produce Absence Report X

Figure 5.3 complete decision table for payroll system example

In constructing a decision tables, you may actually follow a set of basic procedures, as follows:
1. Name the conditions and the values each condition can assume.
2. Name all possible actions that can occur.
3. List all possible rules.
4. Define the actions for each rule.
5. Simplify the decision table.
3. Conceptual Data Modeling
A conceptual data modeling is a representation of organizational data. Or it is a detailed model that shows the
overall structure of organizational data while being independent of any database management system or other
implementation considerations. The purpose of a conceptual data model is to show as many rules about the
meaning and interrelationships among data as possible.
Entity-Relationship (E-R) data models are commonly used diagrams that show how data are organized in an
information system. The main goal of conceptual data modeling is to create accurate E-R diagrams.
Introduction to Entity-Relationship Modeling
Entity-relation diagram (E-R diagram) is a detailed logical and graphical representation of the entities,
associations, and data elements for an organization or business area. The basic entity -relationship modeling
notation uses three main constructs: data entities, relationships, and their associated attributes. The notation for
E-R diagrams appears in Figure 5.3.

8
Basic Symbols

Entity Relationship Identifier Attribute Multi valued attribute Associative entity

Relationship degree

Unary Binary

Relationship Cardinality Ternary

Mandatory 1 cardinality Mandatory many (M) cardinality (1, 2… many) (n is a number

for an upper limit, if one exists)

Optional 0 or 1 cardinality Optional zero-many cardinality (0,1,2, …, many)

Figure 5.4 entity-relationship diagram notations: basic symbols, relationship degrees, and
relationship cardinality.
N.B. A rectangle represents and entity and, and a diamond represents the relationship between
two or more entities.
Entities
An entity is a person, place, object, event or concept in the user environment about which the
organization wishes to maintain data. Some examples of entity are:
 Person: EMPLOYEE, STUDENT, PATIENT
 Place: STATE, REGION COUNTRY, BRANCH
 Object: MACHINE, BUILDING, AUTOMOBILE, PRODUCT
 Event: SALE, REGISTRATION, RENEWAL
 Concept: ACCOUNT, COURSE, WORK CENTER
Attributes
A named property or characteristics of an entity that is interest to the organization. Following are some
typical entity types and associated attributes:
 STUDENT: Student_ID, Student_Name, Address, Phone_Number, Major
 AUTOMOBILE: Vehicle_ID, Color, Weight, Horsepower

9
 EMPLOYEE: Employee_ID, Employee_Name, Address, Skill
Candidate Keys: An attribute (or combination of attributes) that uniquely identifies each instance of an
entity type. For example a candidate key for STUDENT entity type might be Student_ID.
Identifiers: A candidate key that has been selected as the unique, identifying characteristics for an entity
type. Identifiers should be selected carefully because they are critical for the integrity of data. For each
entity the name of the identifier is underlined on an E-R diagram. The following diagram shows the
representation for a STUDENT entity type using E-R notation.

Name Address

Student_ID Phone Number

STUDENT

Multivalued Attribute
An attribute may take on more than one value for each entity instance. Suppose that Dep t_Name
(Dependant name) is one of the attributes of EMPLOYEE. If each employee can have more than one
dependent, Dep_Name is a multivalued attribute.
Relationship: Is an association between instances of one or more entity types that is of interest to the
organization. An association usually means that an event has occurred or that some natural linkage exists
between entity instances. For this reason relationships are labeled with verb phrase.
Conceptual Data Modeling and the E-R Diagram
The goal of conceptual data model is to capture as much of the meaning of data as possible. The more
details (or what some systems analysts call business rule) about data that we can model, the better the
system we can design and build.
Degree of a Relationship
The degree of a relationship is the number of entity types that participate in that relationship. The three
most common relationships in E-R diagrams are unary (degree one), binary (degree two), and ternary
(degree three).
Unary Relationship: - Also called a recursive relationship; a unary relationship is a relationship
between the instances of one entity type.

10
Binary Relationship: - A binary relationship is a relationship between instances of two entity
types and is the most common type of relationship encountered in data modeling.
Ternary Relationship: - A ternary relationship is a simultaneous relationship among
instances of three entity types.
Cardinality in Relationship
Suppose that two entity types, A and B, are connected by a relationship. The cardinality of a
relationship is the number of instances of entity B that can (or must) be associated with each instance of
entity A.
Minimum and Maximum Cardinalities the minimum cardinality of a relationship is the minimum
number of instances of entity B that may associated with each instance of entity A. when the minimum
cardinality of a relationship is zero, then we say entity B is an optional participant in the relationship.
When the minimum cardinality of a relationship is one, then we say that entity B is a mandatory
participant in the relationship. The maximum cardinality is the maximum number of instances.

Associative Entities
An entity type that associates the instances of one or more entity types and contains attributes that are
peculiar to the relationship between those entity instances. The following figure illustrates an example of
an Associative entity.
Date_Completed

EMPLOYEE CERTIFICAT COURSE

E

11
Figure 5.5 associate entity
5.3 Selecting the Best design Strategy
Selecting the best alternative system involves at least two basic steps: (1) generating a comprehensive set of
alternative design strategies and (2) selecting the one that is most likely to result in the desired information
system, given all of the organizational, economic, and technical constraints that limit what can be done.
A system design strategy represents a particular approach to developing the system. It includes statements on
the system’s functionality, hardware and system software platform, and method for acquisition.
The primary deliverables from generating alternative design strategies and selecting the best one are:
1) At least three substantively different system design strategies for building the replacement information
system.
2) A design strategy judged most likely to lead to the most desirable information system.
3) A Baseline Project Plan for turning the most likely design strategy into a working information system.
Note
The requirements and constraints of the replacement system raise many issues that analysts must consider when
they develop alternative design strategies. Issues of functionality help determine software and hard ware
selection, implementation, organizational limitations such as available funding levels, and whether the system
should be developed and run in-house.

12