Unity University System Analysis and design

_________________________________________________________________________________________________________________________________________________________________________________________________________

Chapter Six
Structuring System Requirements: Process Modeling
During requirement structuring you study the requirements and structure them according to their
interrelationships, eliminating the redundancies. There are three primary activities performed during
requirement structuring.
1. Process Modeling
2. Logic Modeling
3. Conceptual Data Modeling

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 with in 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 1.

-4-
Department of Computer Science
 Unity University System Analysis and design
_________________________________________________________________________________________________________________________________________________________________________________________________________

Data flow 1

Data Flow
Interface 1 Source/Sink

Data Store 1 Data Store

Figure 1 data flow diagramming symbols

developed by Gane & Sarson

Process
Process 1

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”. For sample example, refer to the reference books.

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.
For sample example, refer to the reference books.

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.

-5-
Department of Computer Science
 Unity University System Analysis and design
_________________________________________________________________________________________________________________________________________________________________________________________________________

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
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. For sample example, refer to the reference books.

Balancing DFDs

-6-
Department of Computer Science
 Unity University System Analysis and design
_________________________________________________________________________________________________________________________________________________________________________________________________________

The conservation of inputs and outputs to a data flow diagram process when that process is decomposed
to a lower level.

Chapter Seven
Structuring System Requirements: 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
Starting with the processes depicted 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.

-7-
Department of Computer Science
 Unity University System Analysis and design
_________________________________________________________________________________________________________________________________________________________________________________________________________

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
END IF
END DO

Refer to your reference books for more examples.

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 th 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 Employee Type S H S H S H
Stubs
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

Description Refer to your reference book on page 177

Figure 2 complete decision table for payroll system example
In constructing a decision tables, you may actually follow a set of basic procedures, as follows:

-8-
Department of Computer Science
 Unity University System Analysis and design
_________________________________________________________________________________________________________________________________________________________________________________________________________

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.

Chapter Eight
Structuring System Requirements: Data Modeling
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 3.

Basic Symbols

Entity Relationship Identifier Attribute Multivalued Associative

attribute entity

Relationship degree

Unary Binary

Ternary

Relationship Cardinality

-9-
Department of Computer Science
 Unity University System Analysis and design
_________________________________________________________________________________________________________________________________________________________________________________________________________

Mandatory 1 cardinality

Mandatory many (M) cardinality (1, 2, …, many)

n (n is a number for an upper limit, if one exists)

Optional 0 or 1 cardinality

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

n

Figure 3 entity-relationship diagram notations: basic symbols, relationship degrees, and

relationship cardinality. 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 of 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
 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 - 10 -
Department of Computer Science
 Unity University System Analysis and design
_________________________________________________________________________________________________________________________________________________________________________________________________________

Multivalued Attribute
An attribute that may take on more than one value for each entity instance. Suppose that Dep_Name
(dependant name) is one of the attributes of EMPLOYEE. If each employee can have more that one
dependent, Dep_Name is a multivalued attribute.
Relationship
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.
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 relation ship 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 CERTIFICATE COURSE

- 11 -
Department of Computer Science
 Unity University System Analysis and design
_________________________________________________________________________________________________________________________________________________________________________________________________________

For more examples refer to your reference book.

3. Selecting the Best Alternative 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 -
Department of Computer Science