Third Edition: Structuring System Requirements: Process Modeling

Essentials of
Systems Analysis and Design

Third Edition
Joseph S. Valacich
Joey F. George
Jeffrey A. Hoffer
Chapter 5
Structuring System Requirements:
Process Modeling
5.1
Copyright 2006 Prentice-Hall, Inc.
Learning Objectives
Understand the logical modeling of
processes through studying data-flow
diagrams
How to draw data-flow diagrams using
rules and guidelines
How to decompose data-flow diagrams
into lower-level diagrams
Balancing of data-flow diagrams
5.2
Learning Objectives (continued)
Discuss the use of data-flow diagrams

as analysis tools
Represent processing logic using
Structured English and decision tables
5.3
Process Modeling
Graphically represents the processes
that capture, manipulate, store and
distribute data between a system and its
environment and among system
components
Data-flow Diagrams (DFD)
 Graphically illustrate movement of data
between external entities and the
processes and data stores within a system
5.4
Process Modeling (continued)
Modeling a System’s Process
 Utilize information gathered during
requirements determination
 Structure of the data is also modeled in
addition to the processes
Deliverables and Outcomes
 Set of coherent, interrelated data-flow
diagrams
5.5
Deliverables and Outcomes (continued)
 Context data-flow diagram (DFD)
 Scope of system
 DFDs of current system
 Enable analysts to understand current system
 DFDs of new logical system
 Technology independent
 Show data flows, structure and functional
requirements of new system
5.6
Deliverables and Outcomes (continued)
 Project dictionary and CASE repository
Data-flow Diagramming Mechanics
 Four symbols are used
 See Figure 5-2
 Developed by Gane and Sarson
5.7
5.8
Data-Flow Diagramming
Mechanics
Data Flow
 Depicts data that are in motion and moving
as a unit from one place to another in the
system
 Drawn as an arrow
 Select a meaningful name to represent the
data
5.9
Mechanics (continued)
Data Store
 Depicts data at rest
 May represent data in
 File folder
 Computer-based file
 Notebook
 Drawn as a rectangle with the right vertical line
missing
 Label includes name of the store as well as the
number
5.10
Process
 Depicts work or actions performed on data
so that they are transformed, stored, or
distributed
 Drawn as a rectangle with rounded corners
 Number of process as well as name are
recorded
5.11
Source/Sink
 Depicts the origin and/or destination of the
data
 Sometimes referred to as an external entity
 Drawn as a square symbol
 Name states what the external agent is
 Because they are external, many
characteristics are not of interest to us
5.12
5.13
5.14
Definitions
Context Diagram
 A data-flow diagram (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 and the system
Level-O Diagram
 A data-flow diagram (DFD) that represents a
system’s major processes, data flows, and data
stores at a higher level
5.15
Developing DFDs: An
Example
Hoosier Burger’s Automated Food
Ordering System
Context Diagram (Figure 5-4) contains
no data stores
5.16
5.17
Developing DFDs: An
Example (continued)
Next step is to expand the context
diagram to show the breakdown of
processes (Figure 5-5)

5.19
Data-Flow Diagramming Rules
Basic rules that apply to all DFDs:

 Inputs to a process are always different
than outputs
 Objects always have a unique name
 In order to keep the diagram uncluttered, you
can repeat data stores and data flows on a
diagram
5.20
(continued)
Process Data Store
A. No process can D. Data cannot be moved
have only outputs from one store to
another
(a miracle)
E. Data cannot move from
B. No process can an outside source to a
have only inputs data store
(black hole) F. Data cannot move
directly from a data
C. A process has a store to a data sink
verb phrase label
G. Data store has a noun
phrase label
5.21
(continued)
Source/Sink Data Flow
H. Data cannot move J. A data flow has only one
directly from a direction of flow
between symbols
source to a sink
K. A fork means that
I. A source/sink has a exactly the same data
noun phrase label go from a common
location to two or more
processes, data stores,
or sources/sinks
5.22
(continued)
Data Flow (Continued)
L. A join means that exactly the same data come
from any 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
N. A data flow to a data store means update
O. A data flow from a data store means retrieve or
use
P. A data flow has a noun phrase label
5.23
Decomposition of DFDs
Functional Decomposition
 Act of going from one single system to many
component processes
 Repetitive procedure
 Lowest level is called a primitive DFD
Level-n Diagrams
 A DFD that is the result of n nested
decompositions of a series of subprocesses from
a process on a level-0 diagram
5.24
Balancing DFDs
When decomposing a DFD, you must
conserve inputs to and outputs from a
process at the next level of decomposition
 This is called balancing
Example: Hoosier Burgers
 In Figure 5-4, notice that there is one input to the
system, the customer order
 Three outputs:
 Customer receipt
 Food order
 Management reports
5.25
Balancing DFDs (continued)
Example (Continued)
 Notice Figure 5-5. We have the same
inputs and outputs
 No new inputs or outputs have been
introduced
 We can say that the context diagram and
level-0 DFD are balanced
5.26
Balancing DFDs
An Unbalanced Example
 In context diagram,
we have one input to
the system, A and
one output, B
 Level-0 diagram has
one additional data
flow, C
 These DFDs are not
balanced
5.27
Balancing DFDs
We can split a data flow into separate
data flows on a lower level diagram
5.28
Balancing DFDs
Four Additional Advanced Rules
5.29
Guidelines for Drawing DFDs
1. Completeness
 DFD must include all components
necessary for system
 Each component must be fully described
in the project dictionary or CASE
repository
2. Consistency
 The extent to which information contained
on one level of a set of nested DFDs is
also included on other levels
5.30
(continued)
3. Timing
 Time is not represented well on DFDs
 Best to draw DFDs as if the system has
never started and will never stop.
4. Iterative Development
 Analyst should expect to redraw diagram
several times before reaching the closest
approximation to the system being
modeled
5.31
(continued)
5. Primitive DFDs
 Lowest logical level of decomposition
 Decision has to be made when to stop
decomposition
5.32
(continued)
Rules for stopping decomposition:

 When each process has been reduced to a
single decision, calculation or database
operation
 When each data store represents data
about a single entity
 When the system user does not care to
see any more detail
5.33
(continued)
Rules for stopping decomposition:
(continued)
 When every data flow does not need to be split
further to show that data are handled in various
ways
 When you believe that you have shown each
business form or transaction, online display and
report as a single data flow
 When you believe that there is a separate process
for each choice on all lowest-level menu options
5.34
Using DFDs as Analysis Tools
Gap Analysis
 The process of discovering discrepancies
between two or more sets of data-flow
diagrams or discrepancies within a single
DFD
Inefficiencies in a system can often be
identified through DFDs
5.35
Using DFDs in Business
Process Reengineering
Example: IBM Credit
Credit approval
process is required
six days before
Business Process
Reengineering (see
Fig 5-12)
5.36
Using DFDs in Business Process
Reengineering (continued)
After Business
Reprocess
Engineering, IBM
was able to process
100 times the
number of
transactions in the
same amount of
time
5.37
Logic Modeling
Data-flow diagrams do not show the
logic inside the processes
Logic modeling involves representing
internal structure and functionality of
processes depicted on a DFD
Two methods:
 Structured English
 Decision Tables
5.38
Modeling Logic with
Structured English
Modified form of English used to specify
the logic of information processes
Uses a subset of English
 Action verbs
 Noun phrases
 No adjectives or adverbs
No specific standards
5.39
Modeling Logic with
Structured English (continued)
Similar to programming language
 If conditions
 Case statements
Figure 5-15 shows structured English
representation for Hoosier Burger
5.40
5.41
Modeling Logic with
Decision Tables
A matrix representation of the logic of a
decision
Specifies the possible conditions and
the resulting actions
Best used for complicated decision logic
5.42
Modeling Logic with
Decision Tables (continued)
Consists of three parts:
 Condition stubs
 Lists condition relevant to decision
 Action stubs
 Actions that result for a given set of conditions
 Rules
 Specify which actions are to be followed for a
given set of conditions
5.43
Modeling Logic with
Decision Tables (continued)
Indifferent Condition
 Condition whose value does not affect which
action is taken for two or more rules
Standard procedure for creating decision
tables:
 Name the conditions and values each condition
can assume
 Name all possible actions that can occur
 List all possible rules
 Define the actions for each rule (See Figure 5-18)
 Simplify the decision table (See Figure 5-19)
5.44
5.45
5.46
Process Modeling for
Electronic Commerce Application
Process modeling for electronic

commerce projects is no different than
other projects
See Pine Valley Furniture example;
Table 5-4
5.47
5.48
Summary
Data-flow Diagrams (DFD)
 Symbols
 Rules for creating
 Decomposition
 Balancing
DFDs for Analysis
DFDs for Business Process
Reengineering (BPR)
5.49
Summary (continued)
Logic Modeling
 Structured English
 Decision Tables
Internet Development Process Modeling
5.50
Data Flow Diagram
1
DATA FLOW DIAGRAMS
• A data flow diagram (DFD) graphically
describes the flow of data within an
organization. It is used to:
– Document existing systems
– Plan and design new systems
• There is no black-and-white approach to
developing a DFD.
2
DATA FLOW DIAGRAMS
• Example of a data flow
diagram of the customer
payment process. Accounts
Receivable
Customer Remittance Receivables

payment 1.0 2.0
data Information Credit
Customer Process Update
Payment A/R Manager
Deposit
Bank
3
DATA FLOW DIAGRAMS
• A data flow diagram consists of four basic
elements:
– Data sources and destinations
– Data flows
– Transformation processes
– Data stores
4
DATA FLOW DIAGRAMS
• Data sources and destinations
– Appear as squares
– Represent organizations or individuals that send or
receive data used or produced by the system
• An item can be both a source and a destination
5
DATA FLOW DIAGRAMS
• Data sources and
destinations are marked
in red. Accounts
• Can you tell which are Receivable
sources and which are
destinations?

payment 1.0 2.0
Payment A/R Manager
Deposit
Bank
6
DATA FLOW DIAGRAMS
elements:
– Data flows
– Data stores
7
DATA FLOW DIAGRAMS
• Data flows
– Appear as arrows
– Represent the flow of data between sources and
destinations, processes, and data stores
8
DATA FLOW DIAGRAMS
• Data flows are shown in red.
• Does it appear that a data
flow can be two-way? Accounts
Receivable

payment 1.0 2.0
Payment A/R Manager
Deposit
• Data flows should always be
labeled.
Bank • The exception is a data flow
moving into or out of a data store.
9
DATA FLOW DIAGRAMS
• If two data elements flow together, then the use
of one data flow line is appropriate.
Cash Rec’t & Remittance Slip Process

Customer
Payment
• If the data elements do not always flow together,

then multiple lines will be needed.
Customer Inquiry
Process
Customer Customer Payment Payment 10
DATA FLOW DIAGRAMS
elements:
– Data flows
– Data stores
11
DATA FLOW DIAGRAMS
• Processes
– Appear as circles
– Represent the transformation of data
12
DATA FLOW DIAGRAMS
• The transformation processes are
shown in red.
• Every process must have at least
Accounts
one data inflow and at least one
Receivable
data outflow. Why?

payment 1.0 2.0
Payment A/R Manager
Deposit
Bank
13
DATA FLOW DIAGRAMS
• Data stores
– Appear as two horizontal lines
– Represent a temporary or permanent repository of
data
14
DATA FLOW DIAGRAMS
• The data store is shown in red.
• Notice that the inflows and
outflows to the data store are Accounts
not labeled. Receivable

payment 1.0 2.0
Payment A/R Manager
Deposit
Bank
15
DATA FLOW DIAGRAMS
• Data dictionary:
– Data flows and data stores are typically
collections of data elements.
– EXAMPLE: A data flow labeled student
information might contain elements such as
student name, date of birth, ID number,
address, phone number, and major.
– The data dictionary contains a description of
all data elements, data stores, and data flows
in a system.
16
DATA FLOW DIAGRAMS
• Subdividing the DFD:
– Few systems can be fully diagrammed on one
sheet of paper, and users have needs for
differing levels of detail.
– Consequently, DFDs are subdivided into
successively lower levels to provide
increasing amounts of detail.
17
DATA FLOW DIAGRAMS
• The highest level of DFD is called a
context diagram.
– It provides a summary-level view of the
system.
– It depicts a data processing system and the
external entities that are:
• Sources of its input
• Destinations of its output
18
DATA FLOW DIAGRAMS
• This is the context diagram for the
payroll processing system
Govt.
Depart- Agencies
ments
Payroll Employee checks

Employees
Processing
System
Bank
Human
Resources
Management
• What information comes into • What information is produced by

this process, and from where? this process, and where does it go?
19
DATA FLOW DIAGRAMS
Depart-
ments Employees
Employee
New employee Time paychecks
Human form cards
Resources
1.0
Update 2.0
Employee Payroll
empl. Pay
Change check
Payroll Employ- Bank
form
file ees
Payroll
Disburse-
3.0 5.0
ment data
This diagram Prepare Employee/ Update
reports Payroll file Gen.
shows the Ledger
next level of Payroll tax
Payroll disb. voucher
detail for the
report
context 4.0 General
Pay Ledger
diagram in Tax report
Manage- taxes
the previous ment
& payment
Govt.
Figure Agencies
20
DATA FLOW DIAGRAMS
Depart-
ments Employees
Employee
Human form cards
Resources
1.0
Update 2.0
Employee Payroll
empl. Pay
Change check
form
file ees
Payroll
Disburse-
3.0 5.0
ment data
What Prepare Employee/ Update
information Ledger
comes into Payroll tax
these
report
processes 4.0 General
Pay Ledger
and from Tax report
Manage- taxes
where? ment
& payment
Govt.
Agencies
21
DATA FLOW DIAGRAMS
Depart-
ments Employees
Employee
Human form cards
Resources
1.0
Update 2.0
Employee Payroll
empl. Pay
Change check
form
file ees
Payroll
Disburse-
3.0 5.0
ment data
What Prepare Employee/ Update
information is Ledger
produced by Payroll tax
these
report
processes, 4.0 General
Pay Ledger
and where Tax report
Manage- taxes
does it go? ment
& payment
Govt.
Agencies
22
DATA FLOW DIAGRAMS
Depart-
ments Employees
Employee
Human form cards
Resources
1.0
Update 2.0
Employee Payroll
empl. Pay
Change check
form
file ees
Payroll
Disburse-
3.0 5.0
ment data
How do the Prepare Employee/ Update
sources and Ledger
destinations Payroll tax
differ from
report
the context 4.0 General
Pay Ledger
diagram? Tax report
Manage- taxes
& payment
ment Govt.
Agencies
23
DATA FLOW DIAGRAMS
Depart-
ments Employees
Employee
Human form cards
Resources
1.0
Employee Update 2.0 Payroll
empl. Pay
Change check
form
file ees
Payroll
Disburse-
3.0 ment data 5.0
Notice that Prepare Employee/
Update
reports Payroll file
each process Gen.
Ledger
in the DFD is Payroll tax
numbered
report
sequentially. 4.0 General
Ledger
Pay
Tax report
Manage- taxes
& payment
ment Govt.
Agencies
24
DATA FLOW DIAGRAMS
Depart-
ments Employees
Employee
Human form cards
Resources
1.0
Update 2.0
Employee Pay Payroll
empl.
Change check
form
file ees
Suppose we Payroll
exploded Process 3.0
Disburse-
ment data 5.0
2.0 (pay Prepare Employee/ Update
employees) in the reports Payroll file Gen.
next level. The Ledger
Payroll tax
sub-processes disb. voucher
Payroll
would be report
General
numbered 2.1, 2.2, 4.0
Pay Ledger
2.3, etc. Tax report
Manage- taxes
& payment
ment Govt.
Agencies
25
DATA FLOW DIAGRAMS
• We’re going to go into a partial example of
how the first level of detail was created.
• But before we do, let’s step through some
guidelines on how to create a DFD.
26
DATA FLOW DIAGRAMS
• RULE 1: Understand the system. Observe the
flow of information and interview people involved
to gain that understanding.
• RULE 2: Ignore control processes and control
actions (e.g., error corrections). Only very
critical error paths should be included.
• RULE 3: Determine the system boundaries—
where it starts and stops.
• RULE 4: Draw the context diagram first, and
then draw successively greater levels of detail.
27
DATA FLOW DIAGRAMS
• RULE 5: Identify and label all data flows. The
only ones that do not have to be labeled are
those that go into or come out of data stores.
• RULE 6: Data flows that always flow together
should be grouped together. Those that do not
flow together should be shown on separate
lines.
• RULE 7: Show a process (circle) wherever a
data flow is converted from one form to another.
Likewise, every process should have at least
one incoming data flow and at least one
outgoing data flow. 28
DATA FLOW DIAGRAMS
• RULE 8: Transformation processes that are
logically related or occur simultaneously can be
grouped in one bubble.
• RULE 9: Number each process sequentially. A
process labeled 5.0 would be exploded at the
next level into processes numbered 5.1, 5.2, etc.
A process labeled 5.2 would be exploded into
5.2.1, 5.2.2, etc.
• RULE 10: Process names should include action
verbs, such as update, prepare, etc.
• RULE 11: Identify and label all data stores,
whether temporary or permanent.
29
DATA FLOW DIAGRAMS
• RULE 12: Identify and label all sources and
destinations. An entity can be both a source and
destination. You may wish to include such items twice
on the diagram, if needed, to avoid excessive or crossing
lines.
• RULE 13: As much as possible, organize the flow from
top to bottom and left to right.
• RULE 14: You’re not likely to get it beautiful the first
time, so plan to go through several iterations of
refinements.
• RULE 15: On the final copy, lines should not cross. On
each page, include:
– The name of the DFD
– The date prepared
– The preparer’s name
30
DATA FLOW DIAGRAMS
• Now that we’ve been through the guidelines for
developing DFDs, let’s go back to the example
at the beginning of this presentation and see if
we can re-create a part of it.
• You may wish to create a table with the following
headings to organize your information:
– Data Inputs
– Processes
– Data Outputs
31
DATA FLOW DIAGRAMS
Data Inputs Processes Data Outputs
32
DATA FLOW DIAGRAMS
• The first paragraph of the narrative for the payroll
process reads as follows:
– When employees are hired, they complete a new employee
form. When a change to an employee’s payroll status
occurs, such as a raise or a change in the number of
exemptions, human resources completes an employee
change form. A copy of these forms is sent to payroll.
These forms are used to create or update the records in the
employee/payroll file and are then stored in the file.
The portion marked in red relates to activities that go on

outside the boundaries of the payroll system. Consequently,
these activities will not be included on the DFD.
33
DATA FLOW DIAGRAMS
The portion marked in red suggests two data flows coming into
the payroll process (new employee forms and employee
change forms). The source of the inflows is the human
resources department.
34
DATA FLOW DIAGRAMS

New employee forms and
employee change forms
(from H.R. Dept.)
35
DATA FLOW DIAGRAMS
The sentence marked in red suggests a process (update

employee records) with the data outflow going to a data store
(the employee/payroll file).
36
DATA FLOW DIAGRAMS

New employee forms and Update records (read from Updated employee/
employee change forms file and record) payroll file
(from H.R. Dept.)
37
DATA FLOW DIAGRAMS
Depart-
ments Employees
Employee
Human form cards
Resources
1.0
Update 2.0
Employee Payroll
empl. Pay
Change check
form
file ees
Payroll
Disburse-
3.0 5.0
ment data
Prepare Employee/ Update
Ledger
Payroll tax
report
4.0 General
Pay Ledger
taxes Tax report
Manage- & payment
ment Govt.
Agencies
38
 
Chapter 6
Structuring System Requirements:
Conceptual Data Modeling
Entity-Relationship Diagram
 2.1 
 Entity Relationship Model (ER) 
 ER model was proposed by Peter Chen in

1976
 ER model has become the standard tool for

conceptual schema design
 ER model consists of three basic constructs:

entities, attributes and relationships.
 2.2 
 
Entity and Entity Set
 Two types of entities:
 Strong entity: can exist independently (or
can uniquely identify itself)
 Weak entity: existence depends on the
existence of other (strong) entity or
entities
 Examples:
 An employee is a strong entity but the
dependents of the employee could be
weak entities
 An account in a bank is a strong entity but
a transaction could be a week entity
 2.3 
 Attributes 
 An entity has a set of attributes that describes it.

 Attributes are properties used to describe an entity.
Person(SSN, Name, Address, Job-description, Salary).
 An entity will have a value for each of its attributes
(999-010-201, John Smith, ‘20 Alebany Rd, Cardiff, UK’, ‘Manager’, 2500)
 The properties of an entity set are called attributes of

the entity set.
Students: SSN, Name, Address, GPA, Status, ...
Books: Title, ISBN, Authors, Publisher, Year, ...
 For a given application, only a limited number of

attributes of an entity set are of interest
 2.4 
 Types of Attributes 
 Simple (or atomic) attribute is a one which

cannot be divided into smaller parts.
 Examples: SSN, GPA, Salary.
 Composite attribute is an attribute which can

be divided into smaller subparts, these subparts
represent more basic attributes with
independent meanings of their own.
 Examples: Name: First_Name,
Middle_Name, Last_Name
 Address: Street_Address, City, State, Zip
code
 2.5 
 
Types of Attributes
 A single-valued attribute is a one which has one
(single) value for a particular entity.
 Example: Age, BirthDate
 A multi-valued attribute is a one which may

have one or more values for the same entity.
 College Degrees for Person: 0, 1, 2, 3, …
 Color for a Car: 1, 2, …..
 Authors of Books
 Phone Number
 2.6 
 
Types of Attributes
 A stored attribute is a one whose value is
explicitly stored in the database.
 e.g. name, birth-date.
 Derived-attributes: whose values are

computed from other attributes.
 Age from Birthdate
 Annual Salary from Monthly Salary
 NoOfEmployees ==> Count number of
employees in the Employee table.
 2.7 
 Keys 
 Key attribute is an attribute whose values are

distinct (unique) for a given entity type.
 Keys may be
 simple: one attribute (SSN), or
 composite: a set of attributes whose values
together uniquely identify an entity type
 Name(first name, father name, grandfather name, family name)
 2.8 
 Relationship Types 
 A relationship type is represented as diamond-

shaped box which is connected by straight lines
 2.9 
 Relationship Degree 
Degree of a relationship type is the number

of participating entity types: binary
relationships, ternary relationships, ….
EMPLOYEE WORKS-FOR COMPANY
Binary Relationships
 2.10 
 Ternary Relationships 
SUPPLIER SUPPLY PROJECT
PART
 2.11 
 Binary 
Recursive Relationships
EMPLOYEE Supervises
PERSON Marry
 2.12 
 Cardinality Ratio 
 Specifies the number of relationship

instances that an entity can participate in
 Common cardinality ratios for binary

relationship types are 1:1, 1:N, and M:N.
 2.13 
 1:N 
N 1 COMPANY
EMPLOYEE WORKS-FOR
An employee works for one company,

and a company has many employees
working for it.
 2.14 
 1:1 
1 1 MANAGER
DEPARTMENT HAS
A department has one manager and a

manager manages one department.
 2.15 
 M:N 
M N PROJECT
EMPLOYEE WORKS-ON
An employee works on many projects,

and a project has many employees
working on it.
 2.16 
 Participation Constraints 
 Specifies whether the existence of an

entity depends on its being related to
another entity via the relationship type.
 There is total and partial participation.
 2.17 
 Total participation 
N 1
EMPLOYEE WORKS-FOR DEPARTMENT
Total participation.
Every employee must be related to a department

via WORKS-FOR relationship. A department
must have at least one employee.
 2.18 
 Partial participation 
1 N
PERSON Buys CAR
A person may buy a car and car

may be bought by a person
 2.19 
 Total & Partial participation 
1 1
PROFESSOR Manages DEPARTMENT
A professor may manage a department

(partial participation), but a department
must be managed by a professor (total
participation).
 2.20 
 Attributes of Relationship Types 
N 1
EMPLOYEE Works-for DEPARTMENT
Start-Date
We may keep a start date attribute to record for each

employee the date he/she started work for a certain
department.
 2.21 
 A weak entity type is an entity which 
does not have any key attributes
Employee Works-for Department
1
identifying relationship
Dependents
Fname
N Sex
Dependent
Birthdate
Relationship
 2.22 
 Weak Entity Types 
• A weak entity type always has a total

participation with its identifying entity type
• A Weak entity type has a partial key, i.e. this
key is enough to identify its extension within
the scope of its identifying entity type
• In the previous example, the first name is
enough to identify kids within a single family,
but is not enough to identify entities as stand
alone entities (two families may use identical
names for their kids)
 2.23 
 Relationships 
 Several relationships may exist among the

same set of entity sets.
Works_in
Employees Departments
Manages
 2.24 
 Role of an Entity Set (1) 
Definition: The role of an entity set in a relationship is the

function it performs in the relationship.
Case 1: Role can be determined from properly chosen
names.
m takes n
Student Course
1 is_TA_of 1
 2.25 
 Role of an Entity Set (2) 
Case 2: Roles need to be explicitly given.
is_married_to supervises
N 1 1 m
wife husband supervisor supervisee
Person Employee
 2.26 
 Attribute of Relationship 
Where to keep the grade information?
m n
Student takes Course
grade
 2.27 
 Cardinality Constraint (1) 
 One in ER model means zero or one

 Many in ER model means zero or more
 Cardinality constraints make them more precise
(1, 5) (5, 60)

Student takes Course
 2.28 
 General format:
 0  min_card  max_card
 Interpretation:
 Each entity in E may involve between
min_card and max_card relationships in R.
(min_card, max_card)
E R
 2.29 
 Definition:
 If every entity in E involves at least one
relationship in R (i.e., min_card >= 1), E is
said to have total participation in R
 If min_card = 0, E is said to have partial
participation in R
 2.30 
 
Cardinality Constraint (4)
Employees has a partial participation.

Departments has a total participation.
(0, 1) (1,1)
Employee manages Department
 2.31 
 An Example Database Application 
Company Database
 2.32 
 An Example Database 
Application
 The Company database keeps track of a
company’s
 Employees, Departments, Projects
 The following are the requirements and
specifications
 The company is organized into departments.
 Each department has a:
 unique name, unique number
 particular employee who manages the
department
 We keep track of the start date when that
employee began managing the department
 A department may have several locations
 2.33 
Application
 A department controls a number of projects,
each of which has a
 unique name, unique number, and single
location
 We store each employee’s
 name, social security number, address,
salary, sex, and birth date.
 An employee is assigned to one department but
may work on several projects, which are not
necessarily controlled by the same department
 We keep track of the number of hours per week
that an employee works on each project
 We keep track of the direct supervisor of each
employee
 2.34 
Application
 We want to keep track of the dependents of
each employee for insurance purposes.
 We keep each dependent’s first name, sex, birth
date, and relationship to the employee
 2.35 
 ER diagram for the company 
database
Each department has a unique name, a unique number, particular employee
who manages the department. A department may have several locations.
Name Number Locations
DEPARTMENT
 2.36 
database
A department controls a number of projects, each of which has a unique
name, unique number, and single location
Name Number Location
PROJECT
 2.37 
database
We store each employee’s name, social security number, address, salary, sex,
and birth date.
Name SSN Address
Sex
EMPLOYEE Salary
BDate
 2.38 
database
We want to keep track of the dependents of each employee for insurance
purposes. We keep each dependent’s first name, sex, birth date, and
relationship to the employee
Fname Relationship
Sex
BDate
DEPENDENT
 2.39 
database
Each department has a particular employee who manages the department
We keep track of the start date when that employee began managing the
department
(0,1) (1,1)
EMPLOYEE MANAGES DEPARTMENT
StartDate
 2.40 
database
An employee is assigned to one department.
(1,1) (1,N)
EMPLOYEE WOKES-FOR DEPARTMENT
 2.41 
database
A department controls a number of projects
(0,N) (1,1)
DEPARTMENT CONTROLS PROJECT
 2.42 
database
An employee is assigned to one department but may work on several
projects, which are not necessarily controlled by the same department. We
keep track of the number of hours per week that an employee works on each
project
(0,N) (1,N)
EMPLOYEE WORKS_ON PROJECT
Hours
 2.43 
database
We keep track of the direct supervisor of each
employee
EMPLOYEE
(0,N) (0,1)
supervisor supervisee
SUPERVISION
 2.44 
database
We want to keep track of the dependents of each
employee for insurance purposes.
(0,N) (1,1)
EMPLOYEE HAS DEPENDENT
 2.45 
Essentials of
Third Edition
Joseph S. Valacich
Joey F. George
Jeffrey A. Hoffer
Chapter 8
Designing the Human Interface
8.1
Designing Forms and Reports
System inputs and outputs are produced at

the end of the analysis phase
 Precise appearance was not defined during this
phase
Forms and reports are integrally related to
DFD and E-R diagrams
8.2
Designing Forms and Reports
Key Concepts
Form
 A business document that contains some predefined
data and may include some areas where additional
data are to be filled in
 An instance of a form is typically based on one
database record
Report
 A business document that contains only predefined
data
 Typically contains data from many database records
or transactions
8.3
The Process of Designing
Forms and Reports
User Focused Activity
Follows a Prototyping Approach
Requirements Determination:
 Who will use the form or report?
 What is the purpose of the form or report?
 When is the report needed or used?
 Where does the form or report need to be
delivered and used?
 How many people need to use or view the form or
report?
8.4
The Process of Designing Forms
and Reports (continued)
Prototyping
 Initial prototype is designed from
requirements
 Users review prototype design and either
accept the design or request changes
 If changes are requested, the construction-
evaluation-request cycle is repeated until
the design is accepted
8.5
8.6
General Formatting Guidelines for
Forms and Reports (continued)
Displaying Text
 Display text in mixed upper and lower case and
use conventional punctuation
 Use double spacing if space permits. If not, place
a blank line between paragraphs
 Left-justify text and leave a ragged right margin
 Use abbreviations and acronyms only when they
are widely understood by users and are
significantly shorter than the full text
8.7
Displaying Tables and Lists

 Labels
 All columns and rows should have meaningful
labels
 Labels should be separated from other
information by using highlighting
 Redisplay labels when the data extend beyond
a single screen or page
8.8
Displaying tables and lists (continued)

 Formatting numeric, textual, and alphanumeric
data
 Right-justify numeric data and align columns by decimal
points or other delimiter
 Left-justify textual data. Use short line length, usually 30
to 40 characters per line
 Break long sequences of alphanumeric data into small
groups of three to four characters each
8.9
8.10
8.11
Designing Interfaces and
Dialogues
Focus on how information is provided to

and captured from users
Dialogues are analogous to a
conversation between two people
A good human-computer interface
provides a unifying structure for finding,
viewing, and invoking the different
components of a system
8.12
The Process of Designing
Interfaces and Dialogues
User-focused Activity
Parallels Form and Report Design
Process
Employs Prototyping Methodology
 Collect information
 Construct prototype
 Assess usability
 Make refinements
8.13
Designing Interfaces
Designing Layouts
 Standard formats similar to paper-based
forms and reports should be used
 Screen navigation on data entry screens
should be left-to-right, top-to-bottom as on
paper forms
8.14
Designing Layouts
Flexibility and consistency are primary

design goals
 Users should be able to move freely
between fields
 Data should not be permanently saved
until the user explicitly requests this
 Each key and command should be
assigned to one function
8.15
Controlling Data Input
One objective of interface design is to reduce

data-entry errors
Role of systems analyst is to anticipate user
errors and design features into the system’s
interfaces to avoid, detect, and correct data-
entry mistakes
8.16
8.17
8.18
Providing Feedback
1. Status Information
2. Prompting Cues
3. Error and Warning Messages
8.19
Designing Dialogues
Dialogue
 Sequence in which information is displayed to
and obtained from a user
Primary design guideline is consistency in
sequence of actions, keystrokes, and
terminology
Three step process:
1. Design the dialogue sequence
2. Build a prototype
3. Assess usability
8.20
Designing the Dialogue
Sequence
Define the sequence
Have a clear understanding of the user, task,
technological, and environmental characteristics
Dialogue Diagram
 A formal method for designing and representing
human-computer dialogues using box and line
diagrams
 Consists of a box with three sections
1. Top: Unique display reference number used by other
displays for referencing dialogue
2. Middle: Contains the name or description of the display
3. Bottom: Contains display reference numbers that can
be accessed from the current display
8.21
8.22
 
Designing Databases
(Mapping E-RD to Tables)
Chapter 9
 2.1 
 Binary 1:1 relationship

r1
1 1 T t1
s1 S R
 Either choose S and place the primary key of
T as a foreign key in S.
FK
S(s1, …,t1 , r1 )
T(t1, …)
 2.2 
 Binary 1:1 relationship

r1
1 1
s1 S R T t1
 Or choose T and place the primary key of S as
a foreign key in T.
FK
T(t1, …,s1 ,r1 )
S(s1, …)
* It is always better to choose the entity with total participation
 2.3 
 Example: Binary 1:1 relationship 
Dname location Date No Name
1 1
Department manage Manager
This This is better
Department (Dname, location)

Manager (No, Name, Dname, date)
OR
Department (Dname, location, no, date)
Manager (No, Name)
 2.4 
 
Binary 1:N relationship
t1 r1 r2 s1
1 N
T R S
S(s1, …, t1, r1, r2)

T(t1, …)
We place the FK in the entity which has cardinality 1
T(t1, ……, s1, r1, r2)

S(s1, …)
 2.5 
 
Binary M:N relationship
e1 r1 r1 e2
M N
E1 R E2
Create a new relation R to represent R

E1(e1, …..) e1 is FK in R references E1 and
E2(e2, …..) e2 is FK in R references E2
R(e1, e2, r1, r2) Both form a PK for R
 2.6 
 
Multi-valued attributes
e1 K
E1
E1(K, …………)
K is a FK in R references E1
R(K, e1) and
K and e1 form a PK for R
 2.7 
 
Multi-valued attributes
SSN Phone
Employee (SSN, ………) Employee

Phone (SSN, Phone#)
Another solution, but above is better
Employee (SSN, … , phone1, phone2, phone3)
 2.8 
 
n-ary relationship R, n > 2,
For each n-ary relationship R, n > 2,

create a new relation to represent R.
The primary key of R will be the
primary keys of all entity types that
participate in R
 2.9 
 
n-ary relationship R, n > 2,
e1
e2 e3
E1
E2 R E3
r1
E1(e1, …) E2(e2, …)
E3(e3, …) R(e1, e2, e3, r1)
 2.10 
 
Weak Entity Type
e1 e2 e3
E(e1, e2, e3, …)
E W(e1, w1, w2,w4, w5)
e1 is a FK in W references E and
both w1 and e1 form a PK of W
r w4
w5
w1 w3
w2 W
 2.11 
 An Example (1) 
1 m
Professor advises Student
SSN Name Rank SSN Name GPA
 2.12 
 An Example (2) 
Two relations are sufficient:

Professors Students
SSN Name Rank SSN Name GPA PSSN
123 Jack Prof. 456 John 3.4 123
234 Ann Prof. 567 Carl 3.2 123
345 Bob Prof. 678 Ken 3.5 345
 2.13 
 Transform Recursive Relationship 
(1)
 Create a shadow entity set and transform the recursive
relationship into a binary relationship
 Apply the rules for transforming binary relationships
 After the transformation, remove one redundant

relation, or if there is no redundant relation, remove
the relation with fewer attributes
 2.14 
(2)
Course# Title Course# Title
Courses m
Courses prereq
m n
n
Course#
prereq Courses
Title
Courses(Course#, Title)
Prereq(Course#, Prereq-Course#)
 2.15 
(3)
Name Name
SSN SSN
Age Age
Persons (0,1)
Persons mar_to
(0,1) (0,1)
(0,1)
married_to
Persons
Persons(SSN, Name, Age, Spouse_SSN)
 2.16 
(4)
Name Name
SSN SSN
Age Age
Persons 1
Persons mo_of
1 m
mother child m
mother_of
Persons
Persons(SSN, Name, Age, Mother_SSN)
 2.17 
Essentials of
Third Edition
Joseph S. Valacich
Joey F. George
Jeffrey A. Hoffer
Chapter 10
Systems Implementation and
Operation
10.1
System Implementation and
Operation
Seven major activities
 Coding
 Testing
 Installation
 Documentation
 Training
 Support
 Maintenance
Purpose
 To convert final physical system specifications into working
and reliable software
 To document work that has been done
 To provide help for current and future users
10.2
The Processes of Coding,
Testing and Installation
Coding
 Physical design specifications are turned into
working computer code
Testing
 Tests are performed using various strategies
 Testing can be performed in parallel with coding
Installation
 Process during which the current system is
replaced by the new system
10.3
The Processes of Documenting the
System, Training Users, and
Supporting Users
Two audiences for documentation
The information systems personnel

who will maintain the system
throughout its productive life
The people who will use the system as

part of their daily lives
10.4
The Process of Maintaining
Information Systems
Process of returning to the beginning of
the SDLC and repeating development
steps focusing on system change until
the change is implemented
Four major activities:
1. Obtaining maintenance requests
2. Transforming requests into changes
3. Designing changes
4. Implementing changes
10.5
10.6
The Process of Maintaining
Information Systems (continued)
Deliverables and Outcomes

 Development of a new version of the
software, new versions of all design
documents and training materials created
or modified during the maintenance effort
10.7
Software Application Testing
A test plan is developed during the analysis
phase
During the design phase, a unit test plan and
a system test plan are developed
The actual testing is done during
implementation
10.8
Types of Testing
Inspection
 A testing technique in which participants examine
program code for predictable language-specific
errors
Walkthrough
 A peer group review of any product created during
the systems development process; also called a
structured walkthrough
Desk Checking
 A testing technique in which the program code is
sequentially executed manually by the reviewer
10.9
Types of Testing (continued)
Unit Testing
 Each module is tested alone in an attempt to
discover any errors in its code, also called module
testing
Integration Testing
 The process of bringing together all of the
modules that a program comprises for testing
purposes.
10.10
Types of Testing (continued)
System Testing
 The bringing together of all the programs that a
system comprises for testing purposes. Programs are
typically integrated in a top-down, incremental fashion
Stub Testing
 A technique used in testing, especially where
modules are written and tested in a top-down fashion,
where a few lines of code are used to substitute for
subordinate modules
 The purpose of the testing is confirming that the
system satisfies requirements
10.11
The Testing Process
Test Case
 A specific scenario of transactions, queries or
navigation paths that represent a typical, critical
or abnormal use of the system
 Test cases and results should be thoroughly
documented so they can be repeated for each
revision of an application
10.12
Software Application Testing:
Acceptance Testing by Users
The process whereby actual users test a completed
information system, the end result of which is the
users’ acceptance of it
Alpha Testing
 User testing of a completed information system using
simulated data
 Recovery testing
 Forces the software (or environment) to fail in order to verify
that recovery is properly performed
 Security testing
 Verifies that protection mechanisms built into the system will
protect it from improper penetration
 Stress testing
 Tries to break the system
10.13
Software Application Testing:
Acceptance Testing by Users (continued)
Alpha Testing (continued)
 Performance testing
 Determines how the system performs on the
range of possible environments in which it may
be used
Beta Testing
 User testing of a completed information
system using real data in the real user
environment
10.14
Installation
The organizational process of changing over
from the current information system to a new
one
Four approaches
 Direct Installation
 Changing over from the old information system to a new
one by turning off the old system when the new one is
turned on
 Parallel Installation
 Running the old information system and the new one at
the same time until management decides the old system
can be turned off
10.15
Installation (continued)
 Single location installation
 Trying out an information system at one site
and using the experience to decide if and how
the new system should be deployed throughout
the organization
 Phased Installation
 Changing from the old information system to
the new one incrementally, starting with one or
a few functional components and then
gradually extending the installation to cover the
whole new system
10.16
10.17
Planning Installation
Considerations
 Data conversion
 Error correction
 Loading from current system
 Planned system shutdown
 Business cycle of organization
10.18
Documenting the System
System Documentation
 Detailed information about a system’s design
specifications, its internal workings, and its
functionality
 Internal documentation
 System documentation that is part of the program source
code or is generated at compile time
 External documentation
 System documentation that includes the outcome of
structured diagramming techniques such as data-flow
and entity-relationship diagrams
10.19
Documenting the System
(continued)
User Documentation
 Written, or other visual information, about
an application system, how it works, and
how to use it
Preparing User Documentation
 Traditional source has been information
systems department
 Application-oriented documentation is now
often supplied by vendors and users
themselves
10.20
Training Information System
Users (continued)
Training Methods
 Resident expert
 Computer-aided instruction
 Formal courses
 Software help components
 Tutorials
 Interactive training manuals
 External sources, such as vendors
10.21
Supporting Information System
Users
Support is extremely important to users
Most organizations provide support by
two means:
 Information center
 Help desk
10.22
Why Implementation Sometimes
Fails
Two conditions necessary for a
successful implementation
 Management support of the system under
development
 Involvement of users in the development
process
10.23
Project Closedown
Evaluate team
 Reassign members to other projects
Notify all affected parties that the
development project is ending and that you
are switching to operation and maintenance
mode
Conduct post project reviews
Close out customer contract
 Formal signoff
10.24
Conducting System Maintenance:
Types of Maintenance
Corrective maintenance
 Changes made to a system to repair flaws in its design,
coding, or implementation
Adaptive maintenance
 Changes made to a system to evolve its functionality to
changing business needs or technologies
Perfective maintenance
 Changes made to a system to add new features or to
improve performance
Preventive maintenance
 Changes made to a system to avoid possible future
problems
10.25
Conducting System Maintenance
Measures of Effectiveness
Number of Failures
Time between Each Failure
Mean Time between Failures (MTBF)
 A measurement of error occurrences that
can be tracked over time to indicate the
quality of a system
10.26

Third Edition: Structuring System Requirements: Process Modeling

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Third Edition: Structuring System Requirements: Process Modeling

Uploaded by

Copyright:

Available Formats

Essentials of

Systems Analysis and Design

Discuss the use of data-flow diagrams

Copyright 2006 Prentice-Hall, Inc.

Basic rules that apply to all DFDs:

Rules for stopping decomposition:

Process modeling for electronic

Customer Remittance Receivables

Customer Remittance Receivables

Customer Remittance Receivables

Cash Rec’t & Remittance Slip Process

• If the data elements do not always flow together,

Customer Remittance Receivables

Customer Remittance Receivables

Payroll Employee checks

• What information comes into • What information is produced by

Data Inputs Processes Data Outputs

The portion marked in red relates to activities that go on

Data Inputs Processes Data Outputs

The sentence marked in red suggests a process (update

Data Inputs Processes Data Outputs

 ER model was proposed by Peter Chen in

 ER model has become the standard tool for

 ER model consists of three basic constructs:

 An entity has a set of attributes that describes it.

 The properties of an entity set are called attributes of

 For a given application, only a limited number of

 Simple (or atomic) attribute is a one which

 Composite attribute is an attribute which can

 A multi-valued attribute is a one which may

 Derived-attributes: whose values are

 Key attribute is an attribute whose values are

 A relationship type is represented as diamond-

Degree of a relationship type is the number

EMPLOYEE WORKS-FOR COMPANY

SUPPLIER SUPPLY PROJECT

 Specifies the number of relationship

 Common cardinality ratios for binary

An employee works for one company,

A department has one manager and a

An employee works on many projects,

 Specifies whether the existence of an

 There is total and partial participation.

Every employee must be related to a department

A person may buy a car and car

A professor may manage a department

We may keep a start date attribute to record for each

Employee Works-for Department

• A weak entity type always has a total

 Several relationships may exist among the

Definition: The role of an entity set in a relationship is the

Case 2: Roles need to be explicitly given.

Where to keep the grade information?

 One in ER model means zero or one

(1, 5) (5, 60)

Employees has a partial participation.

Name Number Locations

Name Number Location

Name SSN Address

System inputs and outputs are produced at

Displaying Tables and Lists

Displaying tables and lists (continued)

Focus on how information is provided to