Systems Analysis and Design Chapter- 4: Part- II

Chapter 4: Systems Analysis

- Structuring Systems Requirements
 Process Modeling ( DFD Diagrams)
 Conceptual Data Modeling ( ER Diagrams)

************

The information gathered during the requirements gathering process needs to be

organized into a form that is a meaningful representation of the existing system and of the
requirements for the new system.
This is done by producing models of the processing elements and data transformations
and then of the structure of the data. This entire process is called structuring requirements
There are two stages in the structuring process
 Process modeling
 Conceptual data modeling

Process modeling involves graphically representing the processes, or actions that

capture, manipulate, store and distribute data between a system and its environment and
among the components within a system.
A common form of a process model is a data flow diagram (DFD). DFD is a graphic
that illustrates the movement of data between external entities and the processes and data
stores within a system.

Conceptual Data Modeling involves representing the data in a system or organization,

to show the overall structure of the data. A data model should be independent of any
DBMS and of other implementation considerations.
Entity-Relationship diagram(ER) data models are commonly used diagrams that show
how data is organized in a system.

Data Flow Diagrams

 The DFD is an excellent communication tool for analysts to model processes and
functional requirements. One of the primary tools of the structured analysis efforts
of the 1970's it was developed and enhanced by the likes of Yourdon,
McMenamin, Palmer, Gane and Sarson. It is still considered one of the best
modeling techniques for eliciting and representing the processing requirements of
a system

Data Flow diagramming mechanics

 DFD’s are versatile programming tools. With only four symbols, it can represent
both physical and logical information systems.

Lecture Note, Department of Information Systems Page 1 of 17

Systems Analysis and Design Chapter- 4: Part- II

Data flow

 The directional movement of data to and from external entities, the process and
data stores. If it flows into a data store, means a write, update, delete, etc. Flows
out of data stores, mean read, query, display, select types of transaction.
 Symbol: Solid line with arrow. Each data flow is identified with a descriptive
name that represents the information on the data flow.
Example:
Registration data

Process

 It is a work or actions performed on data so that they are transformed, stored, or

distributed. When modeling the data processing of a system, it doesn’t matter
whether process is performed manually or by a computer.
 Depending on the level of the diagram it may represent the whole system as in a
Context (level 0) diagram or a business area, process (activity), function, etc. in
lower levels.
 Symbol: Circle or a Rounded Rectangle.
Example:
2.0
Update
Students
detail

Data Store

 A repository of information. In the physical model, this represents a file, table.

 Symbol: Two parallel lines or open ended rectangle
Ex.
D1: Student Master

External Entity

 It is a source/sink (the origin and /or destination of the data).

 A person or group which interacts with the system. Something outside the system.
eg. Customer, supplier, government agency, accounting dept, etc. usually external
to the business or system but may be internal
 Data must be originated outside a system from one or more sources, and the
system must produce information to one or more sinks.
 Symbol: rectangular box which may be shaded.
Ex.
Customer

Lecture Note, Department of Information Systems Page 2 of 17

Systems Analysis and Design Chapter- 4: Part- II

Developing DFD’s

 The DFD for Hoosier burger food ordering system - An example

 A context diagram is a DFD that provides a general overview of a system, other
DFD’s can be used to focus the details of a context diagram.
 This context diagram contains only one process, no data stores, four data flows,
and three external entities. The single process labeled “0” represents the entire
system.
 All context diagrams have only one process labeled “0”. No data stores appear on
a context diagram, since the data stores of the system are conceptually inside the
one process.

Figure-1: Context diagram (Level-0) for Hoosier burger automated system

 After drawing the context diagram, the next step is to analyze the processes are
represented by the single process. There are four main processes are identified,
the processes represent the major functions of the system, the major functions are
o Capturing data from different sources (process 1)
o Maintaining data stores (process 2 and 3)
o Producing and distributing data to different sinks (process 4)
o High level descriptions of data transformation operations (process 1)
 The flow from first process 1. are 1) the food order is transmitted to the kitchen,
2) the customer order is transformed into a list of goods sold, 3) the customer
order is transformed into inventory data, and 4) the process generates a receipt for
the customer.
 Two of the data flows generated by the process, receive and transform customer
food order, go to external entities, not to concern about what happens outside of
our system..

Lecture Note, Department of Information Systems Page 3 of 17

Systems Analysis and Design Chapter- 4: Part- II

Figure-2: Level 1- diagram of Hoosier Burgers food ordering system

 The data labeled Goods Sold go to process 2, update Goods Sold file. The output
for this process is labeled Formatted Goods Sold Data. The output updates a data
store labeled Goods Sold File. Daily Goods Sold amounts are then used as input
to process 4, Produce Management reports. Similarly the data flow generated by
process 1 called Inventory Data, serves as input for process 3, Update Inventory
File. The Daily Inventory Depletion amounts are then used as input to process 4.
 The DFD hides the physical characteristics of the system it describes. Process 1
and 3 are coupled to each other, since the data flow from process 1 must be
readily accepted by process 3.
 Process 2 and 4 are decoupled by placing a buffer, a data store.

Lecture Note, Department of Information Systems Page 4 of 17

Systems Analysis and Design Chapter- 4: Part- II

Data Flow Diagramming Rules

Process

A. No process can have only outputs. It is making data from nothing. If an object
has only outputs, then it must be a source.
Incorrect Diagram Correct Diagram

B. No process can have only inputs. If an object has only inputs, then it must be a
sink

C. A process has a verb phrase label

Data Store

D. Data cannot move directly from one data source to another data source. Data
must be moved by a process

E. Data cannot move directly from an outside source to a data store. Data must
be 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.

External Entity (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.

Lecture Note, Department of Information Systems Page 5 of 17

Systems Analysis and Design Chapter- 4: Part- II

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 directions 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.

A A
B A

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

A A

B A

M. A data flow cannot go directly back to 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.
A

A B

N. A data flow to a data store means update (delete or change)

O. A data flow from a data store means retrieve of 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.

Lecture Note, Department of Information Systems Page 6 of 17

Systems Analysis and Design Chapter- 4: Part- II

Decomposition of DFD’s

The act of going from a single system to more component processes is called
decomposition
The functional decomposition is a repetitive process of breaking the system into
finer and finer detail.
Each of the processes (or subsystem) is also candidate for decomposition. Each
process may consist of several sub processes. Each sub process may also be
broken down into smaller units.
Decomposition continues until no sub process can logically be broken down any
further. The lowest level of DFD is called primitive DFD.
The first process in the figure-2 can be decomposed into four different outputs. 1)
Receive a customer order, 2) transform the entered order into a printed receipt for
the customer, 3) transform the order into a form meaningful to the kitchens
system 4) transform the order into goods sold data, and 5) transform the order into
inventory data.
The decomposition of Process 1 is given below

Figure-3: Decomposition of Process 1 (Level-2)

The context and level-0 diagram will show the sources and sinks. No sources or
sinks are represented in figure-3. We can decompose processes 2, 3, or 4 in a
similar manner. In general, a level-n diagram is a DFD that is generated is form n
nested decompositions from a level-0 diagram.
As a rule of thumb, no DFD should have more than about seven processes in it.

Lecture Note, Department of Information Systems Page 7 of 17

Systems Analysis and Design Chapter- 4: Part- II

The labels for the processes and numbering rules for clear communication,
process names should be clear and concise, it may begin with an action verb, such
as receive, calculate, transform, generate or produce.
Process 4 can be further decomposed into level-1, level-2 as given below.

Figure-4 : level-1 and level-2 DFDs of Process 4.0

Balancing DFDs

The conservation of inputs and outputs to a data flow diagram process when that
process is decomposed to a lower level.
For Ex. Process 1, which appears in a level-0 diagram, must have the same inputs
and outputs when decomposed into a level-1 diagram is called balancing.
The principle of balancing and goal of keeping a DFD as simple as possible lead
to four additional, advanced rules for drawing DFDs.
o A composite data flow on one level can be split into component data
flows at the next level, but no new data can be added and all data in the
composite must be accounted for in one or more sub flows.
o The input to a process must be sufficient to produce the outputs from the
process. Thus all outputs can be produced, and all data in inputs move
somewhere, either to another process or to a data store outside the process
or on a more detailed DFD showing a decomposition of that process.
o At the lowest level of DFDs, new data flows may be added to represent
data that are transmitted under exceptional conditions; these data flows
typically represent error messages or confirmation notices.

Lecture Note, Department of Information Systems Page 8 of 17

Systems Analysis and Design Chapter- 4: Part- II

o To avoid having data flow lines cross each other, you may repeat data
store or entities on a DFD. Use an additional symbol, like a double line on
the middle vertical line of a data store symbol, or a diagonal line in a
corner of a entity square, to indicate a repeated symbol.

Additional guidelines for drawing DFDs

 Completeness: It refers to whether the DFDs include all the components

necessary for the system you are modeling. If the DFD contains data flows that do
no lead anywhere, or data store, processes, or external entities that are not
connected to anything else, that DFD is not complete.
 Consistency: It refers to whether or not the depiction of the system shown at one
level of a DFD is compatible with the depictions of the system shown at other
level. A gross violation of consistency would be a level-1 diagram with no level-0
diagram. Another example of inconsistency would be a data flow that appears on
higher level DFD but not on lower levels.
 Timing considerations: On a given DFD, there is no indication of whether a data
flow occurs at what time and there is also no indication of when a system would
run. When you draw DFDs, then draw them as if the system you are modeling has
never started and will never stop.
 The iterative nature of drawing DFDs: Iterative development recognizes that
requirements determination and requirements structuring are interaction, not
sequential, sub phases of the analysis phase of the SDLC. One rule of thumb is
that it should take you about three revisions for each DFD.
 Drawing primitive DFDs: The lowest level DFD is the primitive DFD, one rule
is to stop drawing when the lowest logical level is reached. It is not easy to know
what the lowest level is, hence few concrete rules for when to stop decomposing
are
o When you have reduced each process to a single decision or calculation or
to a single database operation such as retrieve, update, create or delete.
o When each data store represents data about a single entity, such as
customer, employee, product, or order
o When every data flow does not need to be split further to show that
different data are handled in various ways
o When there is a separate process for each choice on all lowest-level menu
options.

Using Data flow diagramming in the analysis process

 Gap Analysis: The process of discovering discrepancies between two or more

sets of data flow diagrams or discrepancies within a single DFD.
 DFD can be used for gap analysis. Once DFD is completed, it is examined for
problems like redundant data flows, data that are captured but not used by the
system, and data are updated identically in more than one location.
^^^^^

Lecture Note, Department of Information Systems Page 9 of 17

Systems Analysis and Design Chapter- 4: Part- II

Conceptual Data Modeling (E-R Diagram)

An entity-relationship model, a graphical representation of entities and their relationships

to each other, describes the organization of data within databases or information systems.
An entity is a piece of data—an object or concept about which data is stored. A
relationship is how the data is shared between entities.
ER diagram expresses the overall logical structure of a database graphically.
There are three types of relationships between entities:
 One-to-one: one instance of an entity (A) is associated with one other instance of
another entity (B). For example, in a database of employees, each employee name
(A) is associated with only one social security number (B).
 One-to-many: one instance of an entity (A) is associated with zero, one or many
instances of another entity (B), but for one instance of entity B there is only one
instance of entity A. For example, for a company with all employees working in
one building, the building name (A) is associated with many different employees
(B), but those employees all share the same singular association with entity A.
 Many-to-many: one instance of an entity (A) is associated with one, zero or
many instances of another entity (B), and one instance of entity B is associated
with one, zero or many instances of entity A. For example, for a company in
which all of its employees work on multiple projects, each instance of an
employee (A) is associated with many instances of a project (B), and at the same
time, each instance of a project (B) has multiple employees (A) associated with it.

Developing Entity Relationship Diagrams (ERDs)

£ Entity Relationship Diagrams are a major data modeling tool and will help
organize the data in your project into entities and define the relationships between
the entities.
£ This process has proved to enable the analyst to produce a good database structure
so that the data can be stored and retrieved in a most efficient manner.

INFORMATION
Entity
£ A data entity is anything real or abstract about which we want to store data.
£ Entity types fall into five classes: roles, events, locations, tangible things or
concepts. E.g. employee, payment, campus, book. Specific examples of an entity
are called instances. E.g. the employee John Jones, Mary Smith's payment, etc.
Relationship
£ A data relationship is a natural association that exists between one or more
entities. E.g. Employees process payments.
£ Cardinality defines the number of occurrences of one entity for a single
occurrence of the related entity. E.g. an employee may process many payments
but might not process any payments depending on the nature of her job.
Attribute

Lecture Note, Department of Information Systems Page 10 of 17

Systems Analysis and Design Chapter- 4: Part- II

£ A data attribute is a characteristic common to all or most instances of a particular

entity. Synonyms include property, data element, and field. E.g. Name, address,
Employee Number, pay rate are all attributes of the entity employee.
£ An attribute or combination of attributes that uniquely identifies one and only one
instance of an entity is called a primary key or identifier. E.g. Employee Number
is a primary key for Employee.

Identify the roles, events, locations, tangible things or concepts about

1. Identify Entities
which the end-users want to store data.
Find the natural associations between pairs of entities using a
2. Find Relationships
relationship matrix.
Put entities in rectangles and relationships on line segments
3. Draw Rough ERD
connecting the entities.
Determine the number of occurrences of one entity for a single
4. Fill in Cardinality
occurrence of the related entity.
Identify the data attribute(s) that uniquely identify one and only one
5. Define Primary Keys
occurrence of each entity.
6. Draw Key-Based Eliminate Many-to-Many relationships and include primary and
ERD foreign keys in each entity.
Name the information details (fields) which are essential to the
7. Identify Attributes
system under development.
8. Map Attributes For each attribute, match it with exactly one entity that it describes.
9. Draw fully attributed Adjust the ERD from step 6 to account for entities or relationships
ERD discovered in step 8.
Does the final Entity Relationship Diagram accurately depict the
10. Check Results
system data?

AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY

(One way of doing it)

Lecture Note, Department of Information Systems Page 11 of 17

Systems Analysis and Design Chapter- 4: Part- II

A SIMPLE EXAMPLE
A company has several departments. Each department has a supervisor and at least one
employee. Employees must be assigned to at least one, but possibly more departments. At
least one employee is assigned to a project, but an employee may be on vacation and not
assigned to any projects. The important data fields are the names of the departments,
projects, supervisors and employees, as well as the supervisor and employee number and
a unique project number.
1. Identify Entities
The entities in this system are Department, Employee, Supervisor and Project. One is
tempted to make Company an entity, but it is a false entity because it has only one
instance in this problem. True entities must have more than one instance.
2. Find Relationships
We construct the following Entity Relationship Matrix:

Department Employee Supervisor Project

Department is assigned run by
Employee belongs to works on
Supervisor Runs
Project uses

3. Draw Rough ERD

We connect the entities whenever a relationship is shown in the entity Relationship
Matrix.

4. Fill in Cardinality
From the description of the problem we see that:
£ Each department has exactly one supervisor.
£ A supervisor is in charge of one and only one department.
£ Each department is assigned at least one employee.
£ Each employee works for at least one department.
£ Each project has at least one employee working on it.
£ An employee is assigned to 0 or more projects.

Lecture Note, Department of Information Systems Page 12 of 17

Systems Analysis and Design Chapter- 4: Part- II

5. Define Primary Keys

The primary keys are Department Name, Supervisor Number, Employee Number, Project
Number.

6. Draw Key-Based ERD

There are two many-to-many relationships in the rough ERD above, between Department
and Employee and between Employee and Project. Thus we need the associative entities
Department-Employee and Employee-Project. The primary key for Department-
Employee is the concatenated key Department Name and Employee Number. The
primary key for Employee-Project is the concatenated key Employee Number and Project
Number.

Lecture Note, Department of Information Systems Page 13 of 17

Systems Analysis and Design Chapter- 4: Part- II

7. Identify Attributes
The only attributes indicated are the names of the departments, projects, supervisors and
employees, as well as the supervisor and employee NUMBER and a unique project
number.

8. Map Attributes

Attribute Entity Attribute Entity

Department Department Supervisor Supervisor
Name Number
Employee Employee Supervisor Name Supervisor
Number
Employee Employee Project Name Project
Name
Project Number Project

Lecture Note, Department of Information Systems Page 14 of 17

Systems Analysis and Design Chapter- 4: Part- II

9. Draw Fully Attributed ERD

10. Check Results

The final ERD appears to model the data in this system well.

FURTHER DISCUSSION:

Step 1: Identify Entities

A data entity is anything real or abstract about which we want to store data. Entity types
fall into five classes: roles, events, locations, tangible things, or concepts. The best way to
identify entities is to ask the system owners and users to identify things about which they
would like to capture, store and produce information. Another source for identifying
entities is to study the forms, files, and reports generated by the current system. E.g. a
student registration form would refer to Student (a role), but also Course (an event),
Instructor (a role), Advisor (a role), Room (a location), etc.

Step 2: Find Relationships

There are natural associations between pairs of entities. Listing the entities down the left
column and across the top of a table, we can form a relationship matrix by filling in an

Lecture Note, Department of Information Systems Page 15 of 17

Systems Analysis and Design Chapter- 4: Part- II

active verb at the intersection of two entities which are related. Each row and column
should have at least one relationship listed or else the entity associated with that row or
column does not interact with the rest of the system. In this case, you should question
whether it makes sense to include that entity in the system.
. A student is enrolled in one or more courses
Subject verb objects

Step 3: Draw Rough ERD

Using rectangles for entities and lines for relationships, we can draw an Entity
Relationship Diagram (ERD).

Step 4: Fill in Cardinality

At each end of each connector joining rectangles, we need to place a symbol indicating
the minimum and maximum number of instances of the adjacent rectangle there are for
one instance of the rectangle at the other end of the relationship line. The placement of
these numbers is often confusing. The first symbol is either 0 to indicate that it is possible
for no instances of the entity joining the connector to be related to a given instance of the
entity on the other side of the relationship, 1 if at least one instance is necessary or it is
omitted if more than one instance is required. For example, more than one student must
be enrolled in a course for it to run, but it is possible for no students to have a particular
instructor (if they are on leave).

The second symbol gives the maximum number of instances of the entity joining the
connector for each instance of the entity on the other side of the relationship. If there is
only one such instance, this symbol is 1. If more than 1, the symbol is a crows foot
opening towards the rectangle.

If you read it like a sentence, the first entity is the subject, the relationship is the verb, the
cardinality after the relationship tells how many direct objects (second entity) there are.

I.e. A student is enrolled in one or more courses

Subject verb objects

Step 5: Define Primary Keys

For each entity we must find a unique primary key so that instances of that entity can be
distinguished from one another. Often a single field or property is a primary key (e.g. a
Student ID). Other times the identifier is a set of fields or attributes (e.g. a course needs a
department identifier, a course number, and often a section number; a Room needs a
Building Name and a Room Number). When the entity is written with all its attributes,
the primary key is underlined.

Step 6: Draw Key-Based ERD

Looking at the Rough Draft ERD, we may see some relationships which are non-specific
or many-to-many. I.e., there are crow’s feet on both ends of the relationship line. Such
relationships spell trouble later when we try to implement the related entities as data
stores or data files, since each record will need an indefinite number of fields to maintain
the many-to-many relationship.

Lecture Note, Department of Information Systems Page 16 of 17

Systems Analysis and Design Chapter- 4: Part- II

Fortunately, by introducing an extra entity, called an associative entity for each many-to-
many relationship, we can solve this problem. The new associative entity's name will be
the hyphenation of the names of the two originating entities. It will have a concatenated
key consisting of the keys of these two entities. It will have a 1-1 relationship with each
of its parent entities and each parent will have the same relationship with the associative
entity that they had with each other before we introduced the associative entity. The
original relationship between the parents will be deleted from the diagram.

The key-based ERD has no many-to-many relationships and each entity has its primary
and foreign keys listed below the entity name in its rectangle.

Step 7: Identify Attributes

A data attribute is a characteristic common to all or most instances of a particular entity.
In this step we try to identify and name all the attributes essential to the system we are
studying without trying to match them to particular entities. The best way to do this is to
study the forms, files and reports currently kept by the users of the system and circle each
data item on the paper copy. Cross out those which will not be transferred to the new
system, extraneous items such as signatures, and constant information which is the same
for all instances of the form (e.g. your company name and address). The remaining
circled items should represent the attributes you need. You should always verify these
with your system users. (Sometimes forms or reports are out of date.)

Step 8: Map Attributes

For each attribute we need to match it with exactly one entity. Often it seems like an
attribute should go with more than one entity (e.g. Name). In this case you need to add a
modifier to the attribute name to make it unique (e.g. Customer Name, Employee Name,
etc.) or determine which entity an attribute "best' describes. If you have attributes left
over without corresponding entities, you may have missed an entity and its corresponding
relationships. Identify these missed entities and add them to the relationship matrix now.

Step 9: Draw Fully-Attributed ERD

If you introduced new entities and attributes in step 8, you need to redraw the entity
relationship diagram. When you do so, try to rearrange it so no lines cross by putting the
entities with the most relationships in the middle. If you use a tool like Systems
Architect, redrawing the diagram is relatively easy.
Even if you have no new entities to add to the Key-Based ERD, you still need to add the
attributes to the Non-Key Data section of each rectangle. Adding these attributes
automatically puts them in the repository, so when we use the entity to design the new
system, all its attributes will be available.
Step 10: Check Results
Look at your diagram from the point of view of a system owner or user. Is
everything clear? Check through the Cardinality pairs. Also, look over the list of
attributes associated with each entity to see if anything has been omitted.

Lecture Note, Department of Information Systems Page 17 of 17