You are on page 1of 22

Chapter 5 is the second of four chapters in the systems analysis phase of the SDLC.

This chapter discusses data and process modeling techniques that analysts use to
show how the system transforms data into useful information. The deliverable, or end
product, of data and process modeling is a logical model that will support business
operations and meet user needs.

INTRODUCTION
During the requirements modeling process described in Chapter 4, you used fact-finding
techniques to investigate the current system and identify user requirements. Now, in
Chapters 5 and 6 you will use that information to develop a logical model of the
proposed system and document the system requirements. A logical model shows what
the system must do, regardless of how it will be implemented physically. Later, in the
systems design phase, you build a physical model that describes how the system will be
constructed. Data and process modeling involves three main tools: data flow diagrams,
a data dictionary, and process descriptions.

OVERVIEW OF DATA AND PROCESS MODELING TOOLS


System analysts use many graphical techniques to describe an information system.
One popular method is to draw a set of data flow diagram (DFD) uses various symbols
to show how the system transforms input data into useful information.

DATA FLOW DIAGRAMS


A data flow diagram (DFD) show how data moves through an information system
but does not show program logic or processing steps.
A set of DFDs provides a logical model that shows what the system does and not
how it does it.
A data flow diagram (DFD) illustrates how data is processed by a system in terms of
inputs and outputs. As its name indicates its focus is on the flow of information, where
data comes from, where it goes and how it gets stored.
https://www.smartdraw.com/data-flow-diagram/
An example of a data flow diagram of an online order system

DFD Symbols
DFD use four basic symbols that represent processes, data flows, data stores,
and entities.
There are two different versions of DFD symbols namely: Gane and Sarson
Symbol Set and Yourdon and Coad Symbol Set.

Data Flow Diagrams Notations

1. Gane and Sarson type DFDs- are common for visualizing information systems.
The processes are squares with rounded corners.
2. Yourdon and Coad type DFDs- are usually used for system analysis and
design. The processes are depicted as circles.

https://www.smartdraw.com/data-flow-diagram/
Process symbols
a process receives input data and procedure output that has a different content,
form, or both.
Process can be very simple or quite complex.
Processes contain business logic, also called business rules, that transform
the data and produce the required results.
It can be referred as a black box, because the inputs, the outputs, and the
general functions of the process are known, but the underlying details and logic
of the problems are hidden.
An example of a black box is a network router. An observer can see cables that carry
data into and out of the router, but the routers internal operations are not revealed
only the results are apparent.
DATA FLOW SYMBOL
A data flow is a path for data to move from one part of the information
system to another. It represents one or more data items.
The symbol for a data flow is a line with a single or double arrow-head.
THREE DATA FLOW AND PROCESS COMBINATIONS THAT YOU MUST AVOID:

1. Spontaneous Generation- The APPLY INSURANCE PREMIUM process, for


instance, produces output, but has no input data flow. Because it has no input,
the process is called spontaneous generation process.
2. Black Hole- CALCULATE GROSS PAY is called a black hole process, which is a
process that has input, but produces no output.
3. Gray Hole- A gray hole is a process that has at least one input and one output,
but the input obviously is insufficient to generate the output shown. For example,
a date of birth input is not sufficient to produce a final grade output in the
CALCULATE GRADE process.
https://books.google.com.ph/books?
id=tdUWAAAAQBAJ&pg=PA183&lpg=PA183&dq=Incorrect+combinations+of+data+flow
+and+process+symbols&source=bl&ots=5sjIezuHsv&sig=4AisIv_dGRwf7e7cmndZ5kQ
zWlc&hl=en&sa=X&ved=0ahUKEwiuh7fAmbPTAhWJOo8KHaPbB08Q6AEIMzAC

DATA STORE SYMBOL


A data store is used in a DFD to represent data that the system stores because
one or more processes need to use the data at a later time.
A data store is a repository for persistently storing collections of data, such as a
database, a file system or a directory.
http://whatis.techtarget.com/definition/data-store

ENTITY SYMBOL
The symbol for an entity is a rectangle, which may be shaded to make it look
three-dimensional
A DFD shows only external entities that provide data to the system or receive
output from the system.
DFD entities are also called terminators because they are data origins or final
destinations.
System analysts call an entity that supplies data to the system a source, and an
entity that receives data from the system a sink.
CREATING A SET OF DFDs
To learn how to construct DFDs, we will use two information systems.
Grading system: use by instructor to assign final grades based on the scores that
students received during the term.
Order system: uses by the company to enter orders and apply payments against
a customers balance.

GUIDELINES for drawing DFDs:


Draw the context diagram so that it fits on one page.
Use the name of the information system as the process name in the context
diagram.
Use unique names within each set of symbols.
Do not cross lines.
Provide a unique name and reference number for each process.
Obtain as much user input and feedback as possible.
Step 1: Draw a Context Diagram
Context diagram
Process 0

Example: Context diagram DFD for a grading system


Example: Context diagram for an order system

Step 2: Draw a Diagram 0 DFD


If same data flows in both directions, you can use a double-headed arrow
Diagram 0 is an exploded view of process 0
Parent diagram
Child diagram
Functional primitive

Example: Diagram 0 for grading system


Example: Diagram 0 for
order system

Step 3: Draw the Lower-Level Diagrams


Must use leveling and balancing techniques
Leveling examples
Exploding
Partitioning
Decomposing
Balancing
Ensures that the input and output data flows of the parent DFD are
maintained on the child DFD

DATA DICTIONARY

Key questions:

What do individual data flows actually represent?

How does the client know what a Data Flow name means?

How do analysts and clients know they are talking about the same data flowing
around an organization?

A data dictionary provides the answers.

Creating a data dictionary

A data dictionary is created to define the contents of each data flow, each data store,
each process to avoid ambiguity or confusion about what particular data is collected and
stored.

Data elements (or attributes) are the simplest entry in the data dictionary, for example
state (NSW, WA, VIC, QLD, SA, TAS) or quantity (number ordered). These elements
cannot be further simplified. A collection of related elements are called data
structures and these appear within either data flows or data stores. A data structure
can be simple like address or complex like order form. Address has a number of data
elements (address line 1, address line 2, suburb, state, postcode). Order form could
contain at least 10 structures as well as perhaps 50 elements.

All these structures (collections of elements) and elements are organized alphabetically
in a document called the data dictionary. There is only one entry for each name used.
For each data element, data flow or data store similar information is documented.

It is suggested that you include

the name of the item

description or purpose

data type, (alphabetical, numeric, decimal)

data length (number of characters including spaces, or decimal points)


mandatory characters

display (0 or 2 decimal places)

examples and often statements about where each data element appears within
the data modelling diagrams (e.g. which processes, data stores, data flows)

There are over 20 data elements

date

shop assistant code

name of business

ABN No.

address

phone number

docket number

time

purchase

description

cost

quality

total

subtotal

GST

inclusive total

payment method
amount paid

change

An extract from a data dictionary for a fast food outlet system appears below.

Data dictionary extract for fast food outlet

Data flows customer details and pizza order

Customer details = title + given name + family name

Type Length Description Example


Title Character 5 Form of address
Mr, Ms, Mrs

Given name Character 15 First name Jane, Michael


Family name Character 20 Surname Smith, Wu

Customer address = street + suburb + state + post code

Type Length Description Example


Street Character 30 Number, name, type of street reference
Boronia Ave

Suburb Character 20 Locality within a city Unley


State Character 3 NT
Abbreviation for Australian states of
territories

Postcode Numerical 4 4 digit code for Australia 7258

Phone

Type Length Description Example


Character 10 STD number, space, local number
Home phone 07 2457 8934

Mobile phone Character 12 0438 345 987


mobile code + mobile number
Pizza order = pizza quantity + pizza size + pizza type + pizza price + pizza total

Type Length Description Example


Pizza quantity Numerical 2 Number ordered
7

Pizza size Character 5 sml, med, lge


Size of tray

Pizza type Character 20 Pizza contents description Mexican


Pizza price Numerical 5/2 Cost of one pizza $7.50
Pizza total Numerical 7/2 Cost of order $18.95
Driver's name Character 30 First + second name Sam Jones
Counter staff name Character 30 First +second name Lucy Brankic

https://www.dlsweb.rmit.edu.au/toolbox/knowmang/content/gathering_data/sad/dfds/ddi
ct.htm

(INTERNET)
Data Dictionary
Data dictionary is a method for analyzing the data flows and data stores of data-
oriented systems.
The data dictionary is a reference work of data about data (metadata).
It identifies, coordinates, and confirms what a specific data term means to different
people in the organization.

Reasons for Using a Data Dictionary


The data dictionary may be used for the following reasons:
Provide documentation.
Provide documentation.
Eliminate redundancy.
Validate the data flow diagram.
Provide a starting point for developing screens and reports.
To develop the logic for DFD processes.

The Repository
A data repository is a large collection of project information.
It includes:
Information about system data.
Procedural logic.
Screen and report design.
Relationships between entries.
Project requirements and deliverables.
Project management information.

Data Dictionary Contents


Data dictionaries contain:
Data flow.
Data structures.
Elements.
Data stores

Defining Data Flow


Each data flow should be defined with descriptive information and its composite
structure or elements.
Include the following information:
ID - identification number.
Label, the text that should appear on the diagram.
A general description of the data flow.
The source of the data flow
This could be an external entity, a process, or a data flow coming from a data
store.
The destination of the data flow
Type of data flow, either:
A record entering or leaving a file.
Containing a report, form, or screen.
Internal - used between processes.
The name of the data structure or elements
The volume per unit time
This could be records per day or any other unit of time.
An area for further comments and notations about the data flow

Defining Data Structures


Data structures are a group of smaller structures and elements.
An algebraic notation is used to
An algebraic notation is used to represent the data structure.
Repeating Groups in Data Structures
A repeating group may be:
A sub-form.
A screen or form table
A program table, matrix, or array.
There may be one repeating element or several within the group.
The repeating group may have:
Conditions.
A fixed number of repetitions
Upper and lower limits for the number of repetitions.

Defining Elements
Data elements should be defined with descriptive information, length and type of data
information, validation criteria, of data information, validation criteria, and default values.
Each element should be defined once in the data dictionary.
Attributes of each element are:
Element ID. This is an optional entry that allows the analyst to build automated
data dictionary entries.
The name of the element, descriptive and unique
It should be what the element is commonly called in most programs or by the
major user of the element.
Consistency is desirable

Data Store Definition


The Data Store ID
The Data Store Name, descriptive and unique
An Alias for the file
A short description of the data store
The file type, either manual or computerized
If the file is computerized, the file format designates whether the file is a database file
or the format of a traditional flat file.
The maximum and average number of records on the file
The growth per year
This helps the analyst to predict the amount of disk space required.
The data set name specifies the table or file name, if known.
In the initial design stages, this may be left blank.
The data structure should use a name found in the data dictionary.
http://www.tamut.edu/academics/dreavis/V2/Classes/362/Slides/Ch08.pdf

(BOOK)
A data dictionary, or data repository, is a central storehouse of information about the
systems data. The main purpose of a data dictionary is to describe, document and
organize facts about the:

data flows,
data stores,
processes, and
external entities.

In most cases, description of these components requires definitions and descriptions of


data structures and
data elements.

A data element, or data item or field, is the smallest piece of data that has meaning
within an information system. Examples are, SS#, CustID, LastName, etc.

Data elements are combined into records or data structures.

A record is a meaningful combination of related data elements that is included in a data


flow or retained in a data store. For example, a customer record contains data
elements such as CustID, LastName, FirstName, SS#, TelNumber, etc.

In addition to providing documentation and eliminating redundancy, the data dictionary


may be used to:

1. Validate the data-flow diagram for completeness and accuracy.


2. Providing a starting point for developing screens and reports.
3. Determine the contents of data stored in files.
4. Develop the logic for processes.

Documenting the Data Elements

Each data structure or record contains one or more data elements. Each data element
needs to be described.
You must document every data element in the data dictionary.

The following attributes are described in the data dictionary:


Data element name or label - The data elements standard name, which should be
meaningful to users
Alias Any name(s) other than the standard element name.
Type and Length Type refers to whether the data element contains numeric,
alphabetic, or character values. Length is the maximum number of characters for an
alphabetic or the maximum number of digits for numeric data.
Default value is the values for the data element if a value is not entered for it.
Acceptable values Specification of the data elements domain, which is the set of
values permitted for the data element
Source The specification for the origination point for the data elements values.
Security Identification for the individual or department that ha access or update
privileges for each data element.
Responsible user(s) Identification of the user(s) responsible for entering and
changing values for the data element
Description and comments This part of the documentation allows you to enter
additional notes.

Documenting the Data Flows


The typical attributes are as follows:
Data flow name or label The data flow name as it appears on the DFDs
Description Describes the data flow and its purpose.
Alternate name(s) Aliases for the DFD data flow name(s)
Origin The DFD beginning, or source, for the data flow; the origin can be a process, a
data store, or an entity.
Destination The DFD ending point(s) for the data flow; the destination can be a
process, a data store, or an entity.
Record Each data flow represents a group of related data element called a record or
data structure.
Volume and frequency Describes the expected number of occurrences for the data
flow per unit of time
Documenting the Data Stores
Typical characteristics of a data store are as follows:
Data store name or label The data store name as it appears on the DFDs
Description Describes the data store and its purpose.
Alternate name(s) Aliases for the DFD data store name(s)
Attributes Standard DFD names that enter or leave the data store.
Volume and frequency Describes the estimated number of records in the data store
and how frequently they are updated.
Documenting the Processes
The following are the typical characteristics of a process:
Process name or label The process name as it appears on the DFDs
Description A brief statement of the processs purpose.
Process number - A reference number that identifies the process and indicates
relationships among various levels in the system
Process Description This section includes the input and output data flows.

Documenting the Entities


Typical characteristics of an entity include the following:

Entity name The entity name as it appears on the DFDs


Description Describes the entity and its purpose.
Alternate name(s) Any aliases for the entity name
Input data flows The standard DFD name for the input data flows to the entity
Output data flows The standard DFD names for the data flows leaving the entity

Documenting the Records

A record is a data structure that contains a set of related data elements that are stored
and processed together.
Typical characteristics of a record include the following:

Record or data structure name The record name as it appears in the related data
flow and data store entries in the data dictionary
Definition or description A brief definition of the record
Alternate name(s) Any aliases for the record name
Attributes A list of all the data elements included in the record.

LOGICAL VERSUS PHYSICAL MODELS


While structured analysis tools are used to develop a logical model for a new
information system, such tools also can be used no develop physical models of an
information system. A physical model shows how the systems requirements are
implemented. During the systems design phase, you create a physical model of the new
information system that follows from the logical model and involves operational tasks
and techniques.
Sequence of Models
What is the relationship between logical and physical models? Think back to the
beginning of the systems analysis phase when you were trying to understand the
existing system. Rather than starting with a logical model, you first studied the physical
operations of the existing system to understand how the current tasks were carried out.
Many systems analysts create a physical model of the current system and then develop
a logical model of the current system before tackling a logical model of the new system.
Performing that extra step allows them to understand the current system better.
Four-Model Approach
Many analysts follow a four-model approach, which means that they develop a
physical model of the current system, a logical model of the current system, a logical
model of the new system, and a physical model of the new system. The major benefit of
the four-model approach is that it gives you a clear picture of current system functions
before you make any modifications or improvements. That is important because
mistakes made early in systems development will affect later SDLC phases and can
result in unhappy users and additional costs. Taking additional steps to avoid these
potentially costly mistakes can prove to be well worth the effort. Another advantage is
that the requirements of a new information system often are quite similar to those of the
current information system, especially where the proposal is based on new computer
technology rather than a large number of new requirements. Adapting the current
system logical model to the new system logical model in these cases is a
straightforward process.

The only disadvantage of the four-model approach is the added time and cost needed
to develop a logical and physical model of the current system. Most projects have very
tight schedules that might not allow time to create the current system models.
Additionally, users and managers want to see progress on the new system they are
much less concerned about documenting the current system. As a systems analyst, you
must stress the importance of careful documentation and resist the pressure to hurry
the development process at the risk of creating serious problems later.

CHAPTER SUMMARY
During data and process modeling, a systems analyst develops graphical models to
show how the system transforms data into useful information. The end product of data
and process modeling is a logical model that will support business operations and meet
user needs. Data and process modeling involves three main tools: data flow diagrams,
a data dictionary, and process descriptions.
Dam flow diagrams (DFDs) graphically show the movement and transformation of data
in the information system. DFDs use four symbols: The process symbol transforms
data; the data flow symbol shows data movement; the data store symbol shows data at
rest; and the external entity symbol represents someone or something connected to the
information system. Various rules and techniques are used to name, number, arrange,
and annotate the set of DFDs to make them consistent and understandable.
A set of DFDs is like a pyramid with the context diagram at the top. The context diagram
represents the information systems scope and its external connections but not its
internal workings. Diagram 0 displays the information systems major processes, data
stores, and data flows and is the exploded version of the context diagrams process
symbol, which represents the entire information system. Lower-level DFDs show
additional detail of the information system through the leveling technique of numbering
and partitioning. Leveling continues until you reach the functional primitive processes,
which are not decomposed further and are documented with process descriptions. All
diagrams must be balanced to ensure their consistency and accuracy.
The data dictionary is the central documentation tool for structured analysis. All data
dementia, data flows, data stores, processes, entities, and records are documented m
the data dictionary Consolidating documentation in one location allows you to verify the
information system 1: accuracy and consistency more easily and generate a variety of
useful reports.
Each functional primitive process is documented using structured English, decision
tables and decision trees. Structured English uses a subset of standard English that
defines each process with combinations of the basic building blocks of sequence,
selection, and iteration. You also can document the logic by using decision tables or
decision trees.
Structured analysis tools can be used to develop a logical model during one systems
analysis phase, and a physical model during the systems design phase. Many analysts
use a four-model approach, which involves a physical model of the current system, a
logical model of the current system, a logical model of the new system, and a physical
model of the new system.

You might also like