Naming Convention

The name of a notation is usually written within the symbol. The name of a notation is usually written within
the symbol. Choose brief verb phrases for processes and noun phrases for data flows. An
active verb (verify, compute, extract, create, retrieve, store, determine, etc.)

It is important that the name should say only what is necessary. Do not describe the representation of the
data, its recording medium, or its type; or how the transforms are implemented - say only what processing
is to be done.

Hints on names on DFDs

Data Flows
Name the data + adjective(s)
Say what is known about it (e.g. valid account number)

Processes
The name is a command: verb + nouns (e.g. validate account number) or verb + object/object phrase

Do not use ‘and’, ‘or’, ‘then’, ‘if’, ‘repeat’, or any other words that specify control flow.

Data Stores
Show only net flow in/out/both (i.e. indicate whether it is read-only, write-only, or updated).

Example:

DEFINING DATA FLOW DIAGRAMS (DFDs) When it comes to conveying how information data flows
through systems (and how that data is transformed in the process), data flow diagrams (DFDs) are the
method of choice over technical descriptions for three principal reasons.

1
 1. DFDs are easier to understand by technical and nontechnical audiences
2. DFDs can provide a high-level system overview, complete with boundaries and connections to other
systems
3. DFDs can provide a detailed representation of system components1

DFDs help system designers and others during initial analysis stages visualize a current system or one that
may be necessary to meet new requirements. Systems analysts prefer working with DFDs, particularly when
they require a clear understanding of the boundary between existing systems and postulated systems.
DFDs represent the following:

1. External devices sending and receiving data

2. Processes that change that data
3. Data flows themselves
4. Data storage locations

The hierarchical DFD typically consists of a top-level diagram (Level 0) underlain by cascading lower level
diagrams (Level 1, Level 2…) that represent different parts of the system.

Flowcharts and Pseudocode

Years ago, programmers used a combination of flowcharts and pseudocode (a combination of English and
the programming language being written) to design programs. Pseudocode can actually be simpler to
read than corresponding flowcharts, as Figure 1 illustrates.

Entity-Relationship Diagrams (ERDs)

Entity-Relationship Diagrams (ERDs) are another way of showing information flow for a process. An ERD
shows what data is being used in the process or program, and how the files are related. The E-R (entity
relationship) data model views the real world as a set of basic objects (entities) and relationships among
these objects. It is intended primarily for the database design process by allowing for the specification of
2
an enterprise scheme. This enterprise scheme represents the overall logical structure of the database. ERDs
do not show any program functions, nor data flow. An ERD is shown in Figure 2.

Data Flow Diagrams Data flow diagrams have replaced flowcharts and pseudocode as the tool of choice
for showing program design. A DFD illustrates those functions that must be performed in a program as well
as the data that the functions will need. A DFD is illustrated in Figure 3.

Defining DFD Components

DFDs consist of four basic components that illustrate how data flows in a system: entity, process, data store,
and data flow. Entity An entity is the source or destination of data. The source in a DFD represents these
entities that are outside the context of the system. Entities either provide data to the system (referred to as
a source) or receive data from it (referred to as a sink). Entities are often represented as rectangles (a
diagonal line across the right-hand corner means that this entity is represented somewhere else in the DFD).
Entities are also referred to as agents, terminators, or source/sink.
3
Process
The process is the manipulation or work that transforms data, performing computations, making decisions
(logic flow), or directing data flows based on business rules. In other words, a process receives input and
generates some output. Process names (simple verbs and dataflow names, such as “Submit Payment” or
“Get Invoice”) usually describe the transformation, which can be performed by people or machines.
Processes can be drawn as circles or a segmented rectangle on a DFD, and include a process name and
process number.

Data Store
A data store is where a process stores data between processes for later retrieval by that same process or
another one. Files and tables are considered data stores. Data store names (plural) are simple but
meaningful, such as “customers,” “orders,” and “products.” Data stores are usually drawn as a rectangle
with the right-hand side missing and labeled by the name of the data storage area it represents, though
different notations do exist.

Data Flow
Data flow is the movement of data between the entity, the process, and the data store. Data flow portrays
the interface between the components of the DFD. The flow of data in a DFD is named to reflect the nature
of the data used (these names should also be unique within a specific DFD). Data flow is represented by an
arrow, where the arrow is annotated with the data name. These DFD components are illustrated in Figure
4.

Adjective
Noun
A word or phrase naming an attribute, added to or grammatically related to a noun to modify or describe
it. The simplest definition of an adjective is that it is a word that describes or clarifies a noun. Adjectives
describe nouns by giving some information about an object’s size, shape, age, color, origin or material.

4
5
6
7
Systems Analysis
1. What is process modeling?
2. How to use data flow diagram (DFD) and data dictionary for process modeling?
3. What is logic modeling?
4. How to use structured English, decision tables, and decision trees for logic modeling?
5. What is a systems proposal and its role in systems analysis?

Analysis II -- Requirements structuring

To organize information gathered during requirements determination into a meaningful representation of
process, data, and logic views of the information systems

Process modeling
To represent the functions/processes which capture, manipulate, store, and distribute data between a
system and its environment and between components within a system, i.e., what are involved in converting
data into information?

Data flow diagram

A technique for graphically depicting, at levels of increasing detail, the transformation of data into
information by processes
Gane & Darson’s 4 symbols (Figure 9.1)

1. Data flow -- data moves from one place of the system to another
2. Data store -- data at rest
3. Process -- work/actions performed on data
4. External entity -- origin/destination of the data

8
Steps in developing DFDs (Figure 9.2)
1. List business activities to identify processes, external entities, data flows, and data stores
2. Create a context diagram
3. Create the next level diagram
4. Create child diagrams
5. Check for errors
6. Develop a physical DFD

An example: UK bookstore cap and gown order processing

Step 1: A list of business activities
1. Students place orders by filling out a form.
2. Order department receives orders by mail, fax, or personal delivery.
3. Order department processes orders by verifying that all order information is accurate and
that the item ordered is currently available in stock.
4. Information from valid orders is used to update the student and item master records.
5. Valid orders are forwarded to the shipping department to be filled.
6. A receipt is produced notifying the student the status of his/her order.

Step 2: Context diagram

Step 3: Level-0 diagram

9
Step 4: Level-1 diagram

10
Step 5: Check for error (Figures 9.5 and 9.6)
DFD rules

Internal consistency rules

Elements Rules
DFD At least one process
No more than 9 processes
Context Contains only one process numbered 0
diagram At least one input from an external entity and one output to an external entity
External Appears only on the context diagram
entity Connected to a process
Labeled with noun phrase
Process At least one input data flow and one output data flow
Inputs to process are different from outputs of that process
Labeled with verb phrase
Data flow Has only one flow direction
No split
No loop
Labeled with noun phrase
Data store An interface between two processes
Labeled with noun phrase

Hierarchical consistency rules

Elements Rules
DFD A parent diagram must exist unless it is a context diagram
Process Decompose to either another diagram or a primitive process specification
Numbered with respect to its parent
Data flow An input (output) data flow on a parent diagram must appear on a child diagram
as input (output)
An input (output) data flow on a child diagram must appear on a parent diagram
as input (output)
Data store Decompose to either a file definition or a record definition

Step 6: Develop a physical DFD

Logical vs Physical DFDs (Figure 9.8)
Features Logical Physical
Model How the business operates How the system will be implemented
Process Business activities Programs, program modules, manual procedures
Data store Collections of data Physical files and databases, manual files
Type of data Permanent data collections Master files, transaction files
store
System controls Business controls Controls for data validation, record status, system
security

11
12
Data dictionary
A documentation and reference of the metadata: data on
1. Data flow (Figure 10.3)
2. Data structure (Figure 10.5)
3. Data elements (Figure 10.7)
4. Data stores (Figure 10.12)

To promote understanding of the data of the system by collecting, coordinating, and confirming what a
specific data term means to different people in the organization.

Data types Specific description

Data flow • Source
• Destination
• Type (File, Screen, Report, Form, Internal)
• Data structure
• Volume
Data structure • = is composed of
• + and
• {} repetitive elements
either/or
• [ ]
optional
• ( )
Data element • Alias
• Length
• Type (alphabetic, alphanumeric, date, numeric)
• Input/ Output format
• Default
• Base/Derived
• Continuous/Discrete
• Validation criteria
Data store • File type
• File format
• Record size
• Number of records
• Growth rate
• Primary key
• Secondary keys

13
Data flow description example:

14
Logic modeling
To represent the internal structure and functionality of the processes represented on DFDs, i.e., how do
data be converted to information?

Structured English
o relies on action verbs and noun phrases without adjectives or adverbs to specify 3 typical logic in
structured programming: sequence, selection, and repetition
o sequence: sequential order of the statements
o selection: IF_THEN_ELSE; SELECT_CASE
o repetition: DO_UNTIL; DO_WHILE

Cap & gown ordering systems example

Process 3.1 Validate Student Status
MATCH Student_Information with Student_Record using student’s Last_Name and First_Name
BEGIN IF
IF Student_Not_Found
THEN RETURN Student_Not_Found
ELSE
IF graduation_date is not equal to May, 2001
THEN RETURN Student_Invalid_Status
END_IF
RETURN Valid_Student

Process 3.2 Validate Order Item

MATCH Order_Item_Information with Available_Item_Record based on Item_Description
BEGIN IF
IF the Order_Item_Quantity is greater than the Available_Item_Quantity
THEN RETURN Insufficient_Quantity
END_IF
RETURN Valid_Order

Decision tables
All possible choices and conditions the choices depend on are represented in tabular form: condition,
actions, and rules
Conditions and Actions Rules
Conditions Condition alternatives
Actions Action Entries

Maximum number of rules in the table =

n: number of conditions
Ci: number of alternatives for condition i

15
 Rules
Conditions and Actions 1 2 3 4
Under $50 Y Y N N
Pays by check with 2 forms of ID Y N Y N
Uses credit card N Y N Y
Ring up sales X
Decline sales X
Call supervisor for approval X
Call bank for credit authorization X

Cap & gown ordering system example:

Process 3. Validate Order
Conditions/Actions Rules
Student found Y - N -
Graduate in May Y N - -
Item in stock Y - - N
Accept order X
Reject order X X X

16
Decision trees (Figure 11.22)

A decision or choice situation is depicted as a connected series of nodes (decision points) and branches
(decision alternatives)

17
Cap & gown ordering system example

When to use what?

Condition Recommendation
Many repetitious actions Structured English
Communication to end users is important Structured English
Complex combinations of conditions, actions and rules Decision tables
Checking for redundancies, contradictions, possibilities Decision tables
The sequence of conditions and actions is critical Decision tree
Not every condition is relevant to every action Decision tree

18