Professional Documents
Culture Documents
Third Edition: Structuring System Requirements: Process Modeling
Third Edition: Structuring System Requirements: Process Modeling
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
Copyright 2006 Prentice-Hall, Inc.
Learning Objectives (continued)
5.3
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
Process Modeling (continued)
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
Copyright 2006 Prentice-Hall, Inc.
Process Modeling (continued)
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
Copyright 2006 Prentice-Hall, Inc.
5.8
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
Data-Flow Diagramming
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
Copyright 2006 Prentice-Hall, Inc.
Data-Flow Diagramming
Mechanics (continued)
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
Copyright 2006 Prentice-Hall, Inc.
Data-Flow Diagramming
Mechanics (continued)
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
Copyright 2006 Prentice-Hall, Inc.
5.13
Copyright 2006 Prentice-Hall, Inc.
5.14
Copyright 2006 Prentice-Hall, Inc.
Data-Flow Diagramming
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
Copyright 2006 Prentice-Hall, Inc.
Developing DFDs: An
Example
Hoosier Burger’s Automated Food
Ordering System
Context Diagram (Figure 5-4) contains
no data stores
5.16
Copyright 2006 Prentice-Hall, Inc.
5.17
Copyright 2006 Prentice-Hall, Inc.
Developing DFDs: An
Example (continued)
Next step is to expand the context
diagram to show the breakdown of
processes (Figure 5-5)
5.20
Copyright 2006 Prentice-Hall, Inc.
Data-Flow Diagramming Rules
(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
Copyright 2006 Prentice-Hall, Inc.
Data-Flow Diagramming Rules
(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
Copyright 2006 Prentice-Hall, Inc.
Data-Flow Diagramming Rules
(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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
Balancing DFDs
We can split a data flow into separate
data flows on a lower level diagram
5.28
Copyright 2006 Prentice-Hall, Inc.
Balancing DFDs
Four Additional Advanced Rules
5.29
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
Guidelines for Drawing DFDs
(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
Copyright 2006 Prentice-Hall, Inc.
Guidelines for Drawing DFDs
(continued)
5. Primitive DFDs
Lowest logical level of decomposition
Decision has to be made when to stop
decomposition
5.32
Copyright 2006 Prentice-Hall, Inc.
Guidelines for Drawing DFDs
(continued)
5.33
Copyright 2006 Prentice-Hall, Inc.
Guidelines for Drawing DFDs
(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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
5.41
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
5.45
Copyright 2006 Prentice-Hall, Inc.
5.46
Copyright 2006 Prentice-Hall, Inc.
Process Modeling for
Electronic Commerce Application
5.47
Copyright 2006 Prentice-Hall, Inc.
5.48
Copyright 2006 Prentice-Hall, Inc.
Summary
Data-flow Diagrams (DFD)
Symbols
Rules for creating
Decomposition
Balancing
DFDs for Analysis
DFDs for Business Process
Reengineering (BPR)
5.49
Copyright 2006 Prentice-Hall, Inc.
Summary (continued)
Logic Modeling
Structured English
Decision Tables
Internet Development Process Modeling
5.50
Copyright 2006 Prentice-Hall, Inc.
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
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?
Deposit
Bank
6
DATA FLOW DIAGRAMS
• A data flow diagram consists of four basic
elements:
– Data sources and destinations
– Data flows
– Transformation processes
– 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
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.
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?
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
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
Bank
Human
Resources
Management
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
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
What Prepare Employee/ Update
reports Payroll file Gen.
information Ledger
comes into Payroll tax
Payroll disb. voucher
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
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
What Prepare Employee/ Update
reports Payroll file Gen.
information is Ledger
produced by Payroll tax
Payroll disb. voucher
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
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
How do the Prepare Employee/ Update
reports Payroll file Gen.
sources and Ledger
destinations Payroll tax
Payroll disb. voucher
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
New employee Time paychecks
Human form cards
Resources
1.0
Employee Update 2.0 Payroll
empl. Pay
Change check
Payroll Employ- Bank
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
Payroll disb. voucher
numbered
report
sequentially. 4.0 General
Ledger
Pay
Tax report
Manage- taxes
& payment
ment Govt.
Agencies
24
DATA FLOW DIAGRAMS
Depart-
ments Employees
Employee
New employee Time paychecks
Human form cards
Resources
1.0
Update 2.0
Employee Pay Payroll
empl.
Change check
form
Payroll Employ- Bank
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
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.
33
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 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
35
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.
36
DATA FLOW DIAGRAMS
37
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
Prepare Employee/ Update
reports Payroll file Gen.
Ledger
Payroll tax
Payroll disb. voucher
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)
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
2.5
Types of Attributes
A single-valued attribute is a one which has one
(single) value for a particular entity.
Example: Age, BirthDate
2.6
Types of Attributes
A stored attribute is a one whose value is
explicitly stored in the database.
e.g. name, birth-date.
2.7
Keys
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
2.9
Relationship Degree
Binary Relationships
2.10
Ternary Relationships
PART
2.11
Binary
Recursive Relationships
EMPLOYEE Supervises
PERSON Marry
2.12
Cardinality Ratio
2.13
1:N
N 1 COMPANY
EMPLOYEE WORKS-FOR
2.14
1:1
1 1 MANAGER
DEPARTMENT HAS
2.15
M:N
M N PROJECT
EMPLOYEE WORKS-ON
2.16
Participation Constraints
2.17
Total participation
N 1
EMPLOYEE WORKS-FOR DEPARTMENT
Total participation.
2.18
Partial participation
1 N
PERSON Buys CAR
2.19
Total & Partial participation
1 1
PROFESSOR Manages DEPARTMENT
N 1
EMPLOYEE Works-for DEPARTMENT
Start-Date
2.21
A weak entity type is an entity which
does not have any key attributes
1
identifying relationship
Dependents
Fname
N Sex
Dependent
Birthdate
Relationship
2.22
Weak Entity Types
2.23
Relationships
Works_in
Employees Departments
Manages
2.24
Role of an Entity Set (1)
m takes n
Student Course
1 is_TA_of 1
2.25
Role of an Entity Set (2)
is_married_to supervises
N 1 1 m
wife husband supervisor supervisee
Person Employee
2.26
Attribute of Relationship
m n
Student takes Course
grade
2.27
Cardinality Constraint (1)
2.28
Cardinality Constraint (2)
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
Cardinality Constraint (3)
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)
(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
An Example Database
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
An Example Database
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.
DEPARTMENT
2.36
ER diagram for the company
database
A department controls a number of projects, each of which has a unique
name, unique number, and single location
PROJECT
2.37
ER diagram for the company
database
We store each employee’s name, social security number, address, salary, sex,
and birth date.
Sex
EMPLOYEE Salary
BDate
2.38
ER diagram for the company
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
ER diagram for the company
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
ER diagram for the company
database
An employee is assigned to one department.
(1,1) (1,N)
EMPLOYEE WOKES-FOR DEPARTMENT
2.41
ER diagram for the company
database
A department controls a number of projects
(0,N) (1,1)
DEPARTMENT CONTROLS PROJECT
2.42
ER diagram for the company
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
ER diagram for the company
database
We keep track of the direct supervisor of each
employee
EMPLOYEE
(0,N) (0,1)
supervisor supervisee
SUPERVISION
2.44
ER diagram for the company
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
Systems Analysis and Design
Third Edition
Joseph S. Valacich
Joey F. George
Jeffrey A. Hoffer
Chapter 8
Designing the Human Interface
8.1
Copyright 2006 Prentice-Hall, Inc.
Designing Forms and Reports
8.2
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
8.6
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
General Formatting Guidelines for
Forms and Reports (continued)
8.8
Copyright 2006 Prentice-Hall, Inc.
General Formatting Guidelines for
Forms and Reports (continued)
8.9
Copyright 2006 Prentice-Hall, Inc.
8.10
Copyright 2006 Prentice-Hall, Inc.
8.11
Copyright 2006 Prentice-Hall, Inc.
Designing Interfaces and
Dialogues
8.12
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
Designing Layouts
8.15
Copyright 2006 Prentice-Hall, Inc.
Controlling Data Input
8.16
Copyright 2006 Prentice-Hall, Inc.
8.17
Copyright 2006 Prentice-Hall, Inc.
8.18
Copyright 2006 Prentice-Hall, Inc.
Providing Feedback
1. Status Information
2. Prompting Cues
8.19
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
8.22
Copyright 2006 Prentice-Hall, Inc.
Designing Databases
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, …)
2.3
Example: Binary 1:1 relationship
1 1
Department manage Manager
This This is better
2.4
Binary 1:N relationship
t1 r1 r2 s1
1 N
T R S
e1 r1 r1 e2
M N
E1 R E2
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
2.8
n-ary relationship R, n > 2,
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
2.12
An Example (2)
2.13
Transform Recursive Relationship
(1)
Create a shadow entity set and transform the recursive
relationship into a binary relationship
2.14
Transform Recursive Relationship
(2)
Courses m
Courses prereq
m n
n
Course#
prereq Courses
Title
Courses(Course#, Title)
Prereq(Course#, Prereq-Course#)
2.15
Transform Recursive Relationship
(3)
Name Name
SSN SSN
Age Age
Persons (0,1)
Persons mar_to
(0,1) (0,1)
(0,1)
married_to
Persons
2.16
Transform Recursive Relationship
(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
Systems Analysis and Design
Third Edition
Joseph S. Valacich
Joey F. George
Jeffrey A. Hoffer
Chapter 10
Systems Implementation and
Operation
10.1
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
The Processes of Documenting the
System, Training Users, and
Supporting Users
Two audiences for documentation
10.4
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
10.6
Copyright 2006 Prentice-Hall, Inc.
The Process of Maintaining
Information Systems (continued)
10.7
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
Software Application Testing
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
Copyright 2006 Prentice-Hall, Inc.
Software Application Testing
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
Copyright 2006 Prentice-Hall, Inc.
Software Application Testing
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
Copyright 2006 Prentice-Hall, Inc.
Software Application Testing
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
10.17
Copyright 2006 Prentice-Hall, Inc.
Planning Installation
Considerations
Data conversion
Error correction
Loading from current system
Planned system shutdown
Business cycle of organization
10.18
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
Supporting Information System
Users
Support is extremely important to users
Most organizations provide support by
two means:
Information center
Help desk
10.22
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.
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
Copyright 2006 Prentice-Hall, Inc.