Information Systems Best Notes

Information Systems
Analysis and Design

Myriam Lewkowicz
Outline
1. Information Systems: the big picture

2. Information Systems for competitive advantage
3. Organizational Information Systems
4. Entreprise-Wide Information Systems
5. Information Systems Development & Acquisition
6. Managing the Information Systems Project
7. Systems Planning
8. Determining System Requirements
9. Structuring System Requirements: Process Modeling
10.Structuring System Requirements: Conceptual Data Modeling
11.Object Oriented Analysis and Design
12.Designing the Human Interface
13.Systems Implementation and Operation
myriam.lewkowicz@utt.fr
Chapter 1
Information Systems:
The Big Picture
Chapter 1 Objectives
Understand the term information systems (IS)

Understand IS components:
Technology, people, organizations
Understand
Understand
Understand
failure
Understand
IS career opportunities
types of information systems
IS and organizational success or
the future of IS management
Information Systems Defined
Combinations of hardware, software,

and telecommunications networks that
people build and use to collect, create,
and distribute useful data in
organizations
Key Elements of Information

Systems
Data
Data: raw material, unformatted

information
Information: processed data
(meaningful)
Knowledge: understanding relationships
between pieces of information
Wisdom: knowledge accumulated and
applied
Knowledge as a Business Resource
Knowledge Worker
A well-educated professional who creates,
modifies, or synthesizes knowledge in ones
profession
Knowledge Society
Also called digital society, new economy
Working with brains instead of hands
The importance of education
Digital divide
Technology and Information Systems
Computer-Based Information Systems

One type of technology
Technology any mechanical and/or electrical means
to supplement, extend, or replace human activity
Information Technology (IT) machine technology
controlled by or using information
The goal of IS is to provide useful data to users

IS can be local or global, organizational or enterprisewide
IS Managerial Personnel
CIO
IS director
Account Executive
Info Center Manager
Development Manager
Project Manager
Maintenance Manager
Systems Manager
IS planning Manager
Operations Manager
Programming Manager
Systems Programming
Manager
Manager of Emerging
Technologies
Telecommunications
Manager
Network Manager
Database Administrator
Auditing or Computer
Security Manager
Quality Assurance
Manager
Webmaster
10
Integrating Skills and Knowledge
Technology
hardware, software, networking
Business
business, management, social,
communications
Systems
Integration, development methods, critical
thinking, problem solving
11
Hot Skills in IS Workers
Office / E-mail
Languages
Applications
RDBS Administration
Development Tools
Internetworking
Operating Systems
LAN Administration
Networking
12
IS Within the Firm
Traditionally a love/hate relationship

Techies vs. mere users (us vs. them)
Poor service, lousy attitudes
Now: progress toward better customer

service
Better relationships within the company
Cooperation, not rivalry
13
The Spread of Technology in

Organizations
Technology infiltrates business units

Dual role for IS workers:
Work with IS technical group
Work with business unit (marketing, finance,
etc.)
14
The Spread of Technology in

Organizations
Benefits of centralized IS function

Coordinated planning
Consistent management
Systems compatibility and connectivity
15
Questions
1. Define and understand the term

information systems (IS)
2. Explain the technology, people, and
organizational components of an
information system.
16
Chapter 2
Information Systems for Competitive
Advantage
Chapter 2 Objectives
Understand the IS in automation,

organizational learning, and strategic
support
Understand IS for strategic
organizational success
Understand the need for making an IS
business case
Understand technological innovations to
improve competitive advantage
18
Why Use Information Systems?
Automating: doing things faster

Organizational learning: doing things
better
Supporting Strategy: doing things
smarter
19
Automating:
Doing Things Faster
Technology is used to automate a

manual process
Doing things faster, better, cheaper
Greater accuracy and consistency
Loan application example

Manual processing
Technology-supported process
Completely automated
20
Organizational Learning:
Doing Things Better
Going beyond automation

Involves learning to improve the day-to-day activities
within the process
Looking at patterns and trends
Organizational Learning
Using acquired knowledge and insights to improve
organizational behavior
Total Quality Management (TQM)

Monitoring an organization to improve quality of
operations, products, and services
21
Supporting Strategy:
Doing Things Smarter
Strategic Planning
Create a vision: setting the direction
Create a standard: performance targets
Create a strategy: reaching the goal
22
Question
Now, it should be fairly obvious why an IS

professional should be able to make a
business case for a given system. Why,
however, is it just as important for non-IS
professionals? How are they involved in this
process? What is their role in information
systems planning?
23
Chapter 3
Organizational
Information Systems
Chapter Objectives
Understand characteristics of operational,

managerial, and executive information
systems
Understand characteristics of transaction
processing systems, management information
systems, and executive information systems
Understand characteristics of information
systems that span organizational boundaries
25
Decision-Making Levels of an
Organization
26
Decision-Making Levels of an
Organization
Executive level (top)

Long-term decisions
Unstructured decisions
Managerial level (middle)

Decisions covering weeks and months
Semistructured decisions
Operational level (bottom)

Day-to-day decisions
Structured decisions
27
General Types of Information

Systems
Transaction Processing Systems (TPSs)

Transactions
Used at Operational level of the
organization
Goal: to automate repetitive information
processing activities
Increase speed
Increase accuracy
Greater efficiency
28

Systems
Data input
Manual data entry
Semiautomated data entry
Fully automated data entry
Examples:
Payroll
Sales and ordering
Inventory
Purchasing, receiving, shipping
Accounts payable and receivable
29

Systems
Management Information Systems

(MISs)
Two Types:
Management of IS in organizations
Specific information systems for mid-level
managers
Used at managerial level of the organization
30

Systems

Types of reports:
Scheduled report
Key-indicator report
Exception report
Drill-down report
Ad hoc report
31

Systems

(MISs)
Examples:
Sales forecasting
Financial management and forecasting
Manufacturing planning and scheduling
Inventory management and planning
Advertising and product pricing
32

Systems
Executive Information Systems (EISs)

Used at executive level of the organization
Highly aggregated form
Data types
Soft data news and nonanalytical data
Hard data facts and numbers
33

Systems
Executive Information Systems (EISs)

Examples:
Executive-level decision making
Long-range and strategic planning
Monitoring internal and external events
Crisis management
Staffing and labor relations
34
1.35
35
Information Systems that Span Organizational

Boundaries
36
Information Systems that

Span Organizational Boundaries
Decision Support Systems (DSSs)

Designed to support organizational decision
making
What-if analysis
Example of a DSS tool: Microsoft Excel
Text and graphs
Models for each of the functional areas

Accounting, finance, personnel, etc.
37

Expert Systems (ESs)

Mimics human expertise by manipulating
knowledge
Rules (If-then)
Inferencing
38

Office Automation Systems (OASs)

Examples:
Communicating and scheduling
Document preparation
Analyzing data
Consolidating information
39

Collaboration Technologies
Virtual teams
Videoconferencing
Groupware
Electronic Meeting Systems (EMSs)
40

Functional Area Information Systems

Geared toward specific areas in the
company:
Human Resources
Benefits
Marketing
41
42

Global Information Systems

International IS
Transnational IS
Multinational IS
Global IS
43
Chapter 4
Enterprise-Wide
Information Systems
Chapter Objectives
Understand how information technology

supports business activities
Understand enterprise systems and how
they evolved
Understand software applications that
are internally or externally focused
Understand how to implement
enterprise systems
45
Enterprise Systems
Enterprise systems
Also known as enterprise-wide information
systems
Information systems that allow companies
to integrate information across operations
on a company-wide basis
46
Before an entreprise system
47
With an entreprise sytem
48
Types of Enterprise Systems
Packaged applications
Custom applications
Stand-alone applications
49
Enterprise Resource Planning

Integrated applications
ERP systems
Baan
Oracle
PeopleSoft
SAP
50
ERP Implementation
Modules
Customizations
Best practices
Business process reengineering (BPR)
51
Customer Relationship Management

(CRM)
Sales Force Automation (SFA)
New opportunities for competitive
advantage
Examples:
MGM
American Airlines
Marriott International
52
CRM system
53
Supply Chain Management (SCM)

Supply chain the producers of supplies
that a company uses
Supply network
What if supply chain does not collaborate?
Two objectives of upstream information flow:
Accelerate product development
Reduce costs associated with suppliers
54
Supply chain management
55
The Formula for Enterprise System

Success
Secure executive sponsorship

Get help from outside experts
Thoroughly train users
Take a multidisciplinary approach to
implementation
56
Questions
1.
2.
3.
List the different classes of information systems

described in this chapter. How do they differ from
each other?
Of the information systems listed in the chapter, how
many do you have experience with? What systems
would you like to work with? What types of systems
do you encounter at the university you are attending?
Consider an organization that you are familiar with,
perhaps the one in which you work or one with which
you have done business. Describe the type of
information systems that organization uses and
whether or not they are useful or up-to-date. List
specific examples for updating or installing
information systems that improve productivity or
efficiency.
57
Chapter 5
Information Systems
Development & Acquisition
Chapter Objectives
Understand the process of IS management

Understand the system development life cycle
(SDLC)
Understand alternative approaches to system
development
Understand in-house system development
Understand external acquisition, outsourcing,
and end-user development
59
The Need for Structured Systems

Development
Systems analysis and design the

process of designing, building, and
maintaining information systems
Systems analyst
Blending technical and managerial expertise
60

Development
Evolution of IS development
From art to a discipline
Standardized development methods
Software engineering
61

Development
Options for Obtaining Information

Systems
Build your own
Buy a prepackaged system
Outsource development to a 3rd party
End user development
62

Development
Information Systems Development in

Action
Breaking large complex problems into
manageable pieces
Decomposing large, complex problems
63

Development
System Construction Process

1. Identify a large IT problem to solve
2. Break the large problem into several
smaller, more manageable pieces
3. Translate each piece (small problem)
into computer programs
4. Piece together each program into an
overall comprehensive IS that solves the
problem
64

Development
The Role of Users in the Systems

Development Process
Knowledgeable of needs
Effective partnership
65
Information Systems Analysis and

Design
Systems Analyst performs analysis and

design based upon:
Understanding of organizations objectives,
structure and processes
Knowledge of how to exploit information
technology for advantage
66
Systems Analysis and Design: Core

Concepts
Major goal: to improve organizational

systems by developing or acquiring
software and training employees in its
use
Application software, or a system,
supports organizational functions or
processes
67
Systems Analysis and Design: Core

Concepts
System: Turns data into information and

includes:
Hardware and system software
Documentation and training materials
Job roles associated with the system
Controls to prevent theft or fraud
The people who use the software to perform their
jobs
68
69
Software Engineering Process
A process used to create an information

system
Consists of:
Methodologies
A sequence of step-by-step approaches that help
develop the information system
Techniques
Processes that the analyst follows to ensure thorough,
complete and comprehensive analysis and design
Tools
Computer programs that aid in applying techniques
70
71
System
A system is an interrelated set of

business procedures used within one
business unit working together for a
purpose
A system has nine characteristics
A system exists within an environment
A boundary separates a system from its
environment
72
Characteristics of a System
Components
Interrelated Components
Boundary
Purpose
Environment
Interfaces
Constraints
Input
Output
73
74
Important System Concepts
Decomposition
The process of breaking down a system into
smaller components
Allows the systems analyst to:
Break a system into small, manageable
subsystems
Focus on one area at a time
Concentrate on component pertinent to one
group of users
Build different components at independent times
75
76
Important System Concepts
Modularity
Process of dividing a system into modules of
a relatively uniform size
Modules simplify system design
Coupling
Subsystems that are dependent upon each
other are coupled
Cohesion
Extent to which a subsystem performs a
single function
77
A Modern Approach to Systems

Analysis and Design
Systems Integration
Allows hardware and software from different
vendors to work together
Enables procedural language systems to
work with visual programming systems
Visual programming environment uses
client/server model
78
Data and Processes
Three key components of an information

system
Data
Data Flows
Processing Logic
Data vs. Information

Data
Raw facts
Information
Derived from data
Organized in a manner that humans can
understand
79
Data and Processes
Data
Understanding the source and use of data is key to good
system design
Various techniques are used to describe data and the
relationship amongst data
Data Flows
Groups of data that move and flow through the system
Include description of sources and destination for each
data flow
Processing Logic
Describe steps that transform data and events that trigger
the steps
80
81
Approaches to Systems Development
Process-Oriented Approach
Focus is on flow, use and transformation of
data in an information system
Involves creating graphical representations
such as data flow diagrams and charts
Data are tracked from sources, through
intermediate steps and to final destinations
Natural structure of data is not specified
Disadvantage: data files are tied to specific
applications
82
Approaches to Systems Development

(2)
Data-Oriented Approach
Depicts ideal organization of data,
independent of where and how data are
used
Data model describes kinds of data and
business relationships among the data
Business rules depict how organization
captures and processes the data
83
84
Databases and Application

Independence
Database
Shared collection of logically related data
Organized to facilitate capture, storage and retrieval
by multiple users
Centrally managed
Designed around subjects
Customers
Suppliers
Application Independence
Separation of data and definition of data from
applications
85
Role of the Systems Analyst
Study problems and needs of an organization

Determine best approach to improving
organization through use of:
People
Methods
Information technology
Help system users and managers define their

requirements for new or enhanced systems
86
Role of the Systems Analyst
Assess options for system

implementation
In-house development
Outsourced development
Outsourced development and operation
Commercial application
For in-house projects, work on a team of

analysts and developers
87
Skills of a Successful Systems

Analyst
Analytical
Understanding of organizations
Problem-solving skills
System thinking
Ability to see organizations and information systems as
systems
Technical
Understanding of potential and limitations of technology
Managerial
Ability to manage projects, resources, risk and change
Interpersonal
Effective written and oral communication skills
88
Systems Development Life Cycle
System Development Methodology

Standard process followed in an
organization
Consists of:
Analysis
Design
Implementation
Maintenance
89
Series of steps used to manage the

phases of development for an
information system
Consists of four phases:
Planning and Selection
Analysis
Design
Implementation and Operation
90
Phases are not necessarily sequential

Each phase has a specific outcome and
deliverable
Individual companies use customized
life cycle
91
Phases of the Systems Development

Life Cycle
Systems Planning and Selection

Two Main Activities
Identification of need
Investigation and determination of scope
Systems Analysis
Study of current procedures and information systems
Determine requirements
Generate alternative designs
Compare alternatives
Recommend best alternative
92
System Design
Logical Design
Concentrates on business aspects of the system
Physical Design
Technical specifications
Implementation and Operation

Implementation
Hardware and software installation
Programming
User Training
Documentation
Operation
System changed to reflect changing conditions
System obsolescence
93
94
Alternative approaches
Prototyping
Building a scaled-down working version of the system
Advantages:
Users are involved in design
Captures requirements in concrete form
Rapid Application Development (RAD)

Utilizes prototyping to delay producing system design until
after user requirements are clear
Joint Application Design (JAD)

Users, Managers and Analysts work together for several
days
System requirements are reviewed
Structured meetings
95
96
Summary
Information systems analysis and

design
Process of developing and maintaining an
information system
Modern approach to systems analysis

Process-Oriented
Data-Oriented
97
Summary
Systems Development Life Cycle (SDLC)

Systems
Systems
Systems
Systems
Planning and Selection

Analysis
Design
Implementation
Alternatives to Systems Development Life

Cycle
Prototyping
Rapid Application Development (RAD)
98
Questions
1.
2.
3.
4.
5.
6.
In what way are organizations systems?

List and explain the different phases in the systems
development life cycle.
Why is it important to use systems analysis and
design methodologies when building a system? Why
not just build the system in whatever way seems to
be quick and easy? What value is provided by using
an engineering approach?
Explain the traditional application-based approach to
systems development. How is this different from the
data-based approach?
What is prototyping?
What is JAD? What is Participatory Design?
99
Chapter 6
Managing the Information Systems Project
Learning Objectives
Discuss skills required to be an effective

project manager
Describe skills and activities of a project
manager during project initiation,
planning, execution and closedown
Explain Gantt Charts and Network
Diagrams
Review commercial project
management software packages
101
Case of Pine Valley Furniture
Manufacturing Company
Product: Wood Furniture
Market: U.S.
Organized into functional areas
Manufacturing
Sales
Three independent computer systems were

converted to a database in 1990s
102
103
Managing the Information Systems

Project
Focus of project management

To ensure that information system projects
meet customer expectations
Delivered in a timely manner
Meet constraints and requirements
104
Managing the Information Systems

Project
Project Manager
Systems Analyst responsible for
Project initiation
Planning
Execution
Closing down
Requires diverse set of skills

Management
Leadership
Technical
Conflict management
Customer relations
105
106
Project Management Process
Project
Planned undertaking of related activities to reach
an objective that has a beginning and an end
Four Phases
1.
2.
3.
4.
Initiation
Planning
Execution
Closing down
107
Initiating the Project
1.
2.
3.
4.
5.
Establish project initiation team

Establish relationship with customer
Establish project initiation plan
Establish management procedures
Establish project management
environment and workbook
108
Planning the Project
1. Describe project scope, alternatives

and feasibility
Scope and Feasibility
Understand the project
What problem is addressed
What results are to be achieved
Measures of success
Completion criteria
109
2.
Divide the project into manageable tasks
3.
4.
Estimate resources and create a resource

plan
Develop a preliminary schedule
5.
Work breakdown structure

Gantt chart
Utilize Gantt Charts and Network Diagrams
Develop a communication plan

Outline communication processes among
customers, team members and management
Types of reports
Frequency of reports
110
111
6.
Determine project standards and procedures

Specify how deliverables are tested and produced
7.
Identify and assess risk

Identify sources of risk
Estimate consequences of risk
8.
9.
Create a preliminary budget

Develop a statement of work
Describe what the project will deliver
10. Set a baseline project plan

Estimate of projects tasks and resources
112
Executing the Project
1.
Execute baseline project plan

Acquire and assign resources
Train new team members
Keep project on schedule
2.
Monitor project progress

Adjust resources, budget and/or activities
3.
Manage changes to baseline project plan

Slipped completion dates
Changes in personnel
New activities
4.
5.
Maintain project workbook

Communicate project status
113
Closing Down the Project
1.
Termination
Types of termination
Natural
Requirements have been met
Unnatural
Project stopped
Documentation
Personnel Appraisal
2.
Conduct post-project reviews

Determine strengths and weaknesses of:
Project deliverables
Project management process
Development process
3.
Close customer contract
114
Representing and Scheduling Project

Plans
Gantt Charts
Useful for depicting simple projects or
parts of large projects
Show start and completion dates for
individual tasks
Network Diagrams
Show order of activities
115
116
117
Summary
Skills of an effective project manager

Activities of project manager
Initiation
Planning
Execution
Closedown
Gantt Charts and Network Diagrams

Commercial PM Software
118
Questions
1. List and describe the common skills and activities of a

project manager. Which skill do you think is most
important? Why?
2. Describe the activities performed by the project
manager during project initiation.
manager during project planning.
manager during project execution.
119
Chapter 7
Systems Planning
Learning Objectives
Discuss the content of and need for a

Statement of Work and Baseline Project
Plan
Describe a structured walkthrough
121
First documents
Baseline Project Plan (BPP) : internal document

Scope
Benefits
Costs
Risks
Resources
Statement of Work (SOW) : Outlines objectives

and constraints of the project to the customer
Describes deliverables
Outlines work needed to be performed
122
123
Building the Baseline Project Plan
Objectives
Assures that customer and development group have
a complete understanding of the proposed system
and requirements
Provides sponsoring organization with a clear idea of
scope, benefits and duration of project
Four Sections
Introduction
System Description
Feasibility Assessment
Management Issues
124
Introduction
Brief overview
Recommended course of action
Project scope defined
Units affected
Interaction with other systems
Range of system capabilities
125
System Description
Outline of possible alternative solutions
Narrative format
Feasibility Assessment
Project costs and benefits
Technical difficulties
High-level project schedule
126
Management Issues
Outlines concerns that management may
have about the project
Team composition
Communication plan
Project standards and procedures
127
128
Reviewing the Baseline Project Plan
Objectives
Assure conformity to organizational
standards
All parties agree to continue with project
129
Reviewing the Baseline Project Plan
Walkthrough
Peer group review
Participants
Coordinator
Presenter
User
Secretary
Standards Bearer
Maintenance Oracle
Activities
Walkthrough review form
Individuals polled
Walkthrough action list
Advantages
Assures that review occurs during project
130
131
132
Summary
Baseline Project Plan (BPP)

Created during project initiation and planning
Contains:
Introduction
High-Level description of system
Outline of feasibility
Overview of Management Issues
Statement of Work (SOW)

Describes what project will deliver
Lists all work to be performed
133
Questions
1. What is contained in a Baseline Project

Plan? Are the content and format of
all baseline plans the same? Why or
why not?
2. Describe the structured walkthrough
process. What roles need to be
performed during a walkthrough?
134
Chapter 8
Determining System Requirements
Learning Objectives
Describe options for designing and

conducting interviews
Discuss planning an interview
Discuss using questionnaires to
determine system requirements
Explain advantages and disadvantages
of observing workers and analyzing
business documents to determine
requirements
136
Learning Objectives
Learn about Joint Application Design

(JAD) and Prototyping
Discuss appropriate methods to elicit
system requests
Examine requirements determination
for Internet applications
137
Activities in Requirement Gathering
1.0
1.0
Identify
Identifythe
theright
right
Stakeholders
Stakeholders&&
Artefacts
Artefacts
0.0
0.0
Outline
Outlineinformation
information
to
tobe
besought
sought
2.0
2.0
Use
Usemost
mostappropriate
appropriate
investigation
investigationtechniques
techniques
4.0
4.0
Document
Documentthe
the
requirements
requirements
3.0
3.0
Determine
Determineduration
duration
Objective: determine the functions

& information that must be provided
by the information system
138
Performing Requirements
Determination
Gather information on what the system

should do from many sources
Users
Reports
Forms
Procedures
139
Performing Requirements
Determination
Characteristics for gathering requirements

Impertinence
Question everything
Impartiality
Find the best organizational solution
Relaxation of constraints
Attention to detail
Reframing
View the organization in new ways
140
Deliverables and Outcomes
Types of deliverables:
Information collected from users
Existing documents and files
Computer-based information
Understanding of organizational components
Business objective
Information needs
Rules of data processing
Key events
141
142
Traditional Methods for Determining

Requirements
143

Requirements
Interviewing and Listening

Gather facts, opinions and speculations
Observe body language and emotions
Guidelines
Plan
Checklist
Appointment
Be neutral
Listen
Seek a diverse view
Interview Questions
Open-Ended
No prespecified answers
Close-Ended
Respondent is asked to choose from a set of specified responses
144
145
146
147

Requirements
Administering Questionnaires
More cost-effective than interviews
Choosing respondents
Should be representative of all users
Types of samples
Convenient
Random sample
Purposeful sample
Stratified sample
Design
Mostly closed-ended questions
Can be administered over the phone, in person or over
the Internet or company intranet
148

Requirements
Questionnaires Vs. Interviews

Interviews cost more but yield more information
Questionnaires are more cost-effective
149
150

Requirements
Directly Observing Users

Serves as a good method to supplement
interviews
Often difficult to obtain unbiased data
People often work differently when being
observed
151
Analyzing Procedures and Other

Documents
Types of information to be discovered:

Problems with existing system
Opportunity to meet new need
Organizational direction
Names of key individuals
Values of organization
Special information processing circumstances
Rules for processing data
152
153
Modern Methods for Determining

Requirements

Brings together key users, managers and systems
analysts
Purpose: collect system requirements simultaneously
from key people
Conducted off-site
Prototyping
Repetitive process
Rudimentary version of system is built
Replaces or augments SDLC
Goal: to develop concrete specifications for ultimate
system
154
Participants
Session Leader
Users
Managers
Sponsor
Systems Analysts
Scribe
IS Staff
End Result
Documentation detailing existing system
Features of proposed system
155
156
Prototyping
Quickly converts requirements to working

version of system
Once the user sees requirements converted to
system, will ask for modifications or will
generate additional requests
Most useful when:
User requests are not clear
Few users are involved in the system
Designs are complex and require concrete form
History of communication problems between
analysts and users
Tools are readily available to build prototype
157
Prototyping
Drawbacks
Tendency to avoid formal documentation
Difficult to adapt to more general user
audience
Sharing data with other systems is often not
considered
Systems Development Life Cycle (SDLC)
checks are often bypassed
158
Summary
Interviews
Open-ended and close-ended questions
Preparation is key
Questionnaires
Must be carefully designed
Can contain close-ended as well as openended questions
159
Summary
Other means of gathering requirements

Observing workers
Analyzing business documents

Prototyping
160
Questions (1)
1. Describe systems analysis and the major activities that occur

during this phase of the systems development life cycle.
2. What are some useful character traits for an analyst involved
in requirements determination?
3. Describe four traditional techniques for collecting information
during analysis. When might one be better than another?
4. What are the general guidelines for conducting interviews?
5. What are the general guidelines for designing questionnaires?
6. Compare collecting information by interview and by
questionnaire. Describe a hypothetical situation in which
each of these methods would be an effective way to collect
information system requirements.
161
Questions (2)
7. What are the general guidelines for collecting

data through observing workers?
8. What are the general guidelines for collecting
data through analyzing documents?
9. Describe how prototyping can be used during
requirements determination. How is it better
or worse than traditional methods?
162
Chapter 9
Structuring System Requirements:
Process Modeling
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
164
Learning Objectives
Discuss the use of data flow diagrams

as analysis tools
Discuss process modeling for Internet
Applications
165
Process Modeling
Graphically represent 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
166
Process Modeling
Modeling a systems process

Utilize information gathered during
requirements determination
Structure of the data is also modeled in
addition to the processes

Set of coherent, interrelated data flow
diagrams
167
Process Modeling
Deliverables and outcomes (continued)

Context data flow diagram (DFD)
Scope of system
DFDs of current system

Enables analysts to understand current system
DFDs of new logical system

Technology independent
Show data flows, structure and functional
requirements of new system
168
169
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
170
Data Store
Depicts data at rest
May represent data in:
File folder
Computer-based file
Notebook
Drawn as a rectangle with the right hand vertical line

missing
Label includes name of the store as well as the
number
171
Process
Depicts work or action 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
172
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
173
174
175
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 diagrams (DFD) that represents a
systems major processes, data flows and data stores
at a higher level
176
Developing DFDs: An Example
Hoosier Burgers automated food

ordering system
Context Diagram contains no data
stores
177
178
Developing DFDs: An Example
Next step is to expand the context

diagram to show the breakdown of
processes
179
180
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
181
Process
Data Store
A. No process can have

only outputs (a
miracle)
B. No process can have
only inputs (black
hole)
C. A process has a verb
phrase label
D. Data cannot be moved

from one store to
another
E. Data cannot move from
an outside source to a
data store
F. Data cannot move
directly from a data
store to a data sink
G. Data store has a noun
phrase label
182
Source/Sink
Data Flow
H. Data cannot move

I.
directly from a
source to a sink
A source/sink has a
noun phrase label
J. A data flow has only

one direction of flow
between symbols
K. A fork means that
exactly the same data
go from a common
location to two or more
processes, data stores
or sources/sinks
183
Data Flow (Continued)

L. A join means that exactly the same data come from
M.
N.
O.
P.
any two or more different processes, data stores or

sources/sinks to a common location
A data flow cannot go directly back to the same
process it leaves
A data flow to a data store means update
A data flow from a data store means retrieve or use
A data flow has a noun phrase label
184
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 level0 diagram
185
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
186
Balancing DFDs
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
187
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
188
Balancing DFDs
We can split a data flow into separate

data flows on a lower-level diagram
189
Balancing DFDs:
Four Additional Advanced Rules
190
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
191
Guidelines for Drawing DFDs
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.
Primitive DFDs
Lowest logical level of decomposition
Decision has to be made when to stop
decomposition
192
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
193
Using DFDs in Business Process

Reengineering
Example: IBM Credit

Credit approval
process required six
days before Business
Process
Reengineering (see
Fig 5-12)
194
Using DFDs in Business Process

Reengineering
After Business
Reprocess
Engineering, IBM was
able to process 100
times the number of
transactions in the
same amount of time
195
Summary
Data flow diagrams (DFD)

Symbols
Rules for creating
Decomposition
Balancing
DFDs for Analysis

DFDs for Business Process
Reengineering (BPR)
196
Questions
1. What is a data flow diagram? Why do

systems analysts use data flow diagrams?
2. What is decomposition? What is balancing?
How can you determine if DFDs are not
balanced?
3. Explain the convention for naming different
levels of data flow diagrams.
4. How can data flow diagrams be used as
analysis tools?
197
Chapter 10
Structuring System Requirements:
Conceptual Data Modeling
Learning Objectives
Define key data-modeling terms

Conceptual data model
Entity-Relationship (E-R) diagram
Entity type
Entity instance
Attribute
Candidate key
Multivalued attributes
Relationship
Degree
Cardinality
Associative entity
199
Learning Objectives
Ask the right kinds of questions to determine

data requirements for an IS
Learn to draw entity-relationship diagrams
(ERD)
Review the role of conceptual data modeling in
overall design and analysis of an information
system
Discuss relationships and associative entities
Discuss relationship between data modeling
and process modeling
200
Representation of organizational data

Purpose is to show rules about the meaning and
interrelationships among data
Entity-Relationship (E-R) diagrams are commonly used
to show how data are organized
Main goal of conceptual data modeling is to create
accurate E-R diagrams
Methods such as interviewing, questionnaires and JAD
are used to collect information
Consistency must be maintained between process flow,
decision logic and data modeling descriptions
201
Process of Conceptual Data Modeling
First step is to develop a data model for the

system being replaced
Next, a new conceptual data model is built
that includes all the requirements of the new
system
In the design stage, the conceptual data model
is translated into a physical design
Project repository links all design and data
modeling steps performed during SDLC
202
Primary deliverable is the entity-relationship

diagram
There may be as many as 4 E-R diagrams
produced and analyzed during conceptual data
modeling
Covers just data needed in the projects application
E-R diagram for system being replaced
An E-R diagram for the whole database from which
the new applications data are extracted
An E-R diagram for the whole database from which
data for the application system being replaced are
drawn
203
204
Second deliverable is a set of entries about

data objects to be stored in repository or
project dictionary
Repository links data, process and logic models of an
information system
Data elements that are included in the DFD must
appear in the data model and conversely
Each data store in a process model must relate to
business objects represented in the data model
205
Gathering Information for

Two perspectives
Top-down
Data model is derived from an intimate
understanding of the business
Bottom-up
Data model is derived by reviewing specifications
and business documents
206
Introduction to Entity-Relationship
(E-R) Modeling
Notation uses three main constructs

Data entities
Relationships
Attributes
Entity-Relationship (E-R) Diagram

A detailed, logical and graphical
representation of the entities, associations
and data elements for an organization or
business
207
Entity-Relationship (E-R) Modeling

Key Terms
Entity
A person, place, object, event or concept in the user
environment about which the organization wishes to
maintain data
Represented by a rectangle in E-R diagrams
Entity Type
A collection of entities that share common properties
or characteristics
Attribute
A named property or characteristic of an entity that
is of interest to an organization
208
209

Key Terms
Candidate keys and identifiers

Each entity type must have an attribute or
set of attributes that distinguishes one
instance from other instances of the same
type
Candidate key
Attribute (or combination of attributes) that
uniquely identifies each instance of an entity type
210

Key Terms
Identifier
A candidate key that has been selected as
the unique identifying characteristic for an
entity type
Selection rules for an identifier
Choose a candidate key that will not change its
value
Choose a candidate key that will never be null
Avoid using intelligent keys
Consider substituting single value surrogate keys
for large composite keys
211

Key Terms
Multivalued Attribute
An attribute that may take on more than
one value for each entity instance
Represented on E-R Diagram in two ways:
Double-lined ellipse
Weak entity
212

Key Terms
Relationship
An association between the instances of one
or more entity types that is of interest to the
organization
Association indicates that an event has
occurred or that there is a natural link
between entity types
Relationships are always labeled with verb
phrases
213
Conceptual Data Modeling and the ER Diagram
Goal
Capture as much of the meaning of the data
as possible
Result
A better design that is easier to maintain
214
Degree of Relationship
Degree
Number of entity types that participate in a
relationship
Three cases
Unary
A relationship between the instances of one entity type
Binary
A relationship between the instances of two entity
types
Ternary
A simultaneous relationship among the instances of
three entity types
Not the same as three binary relationships
215
216
Cardinality
The number of instances of entity B that can

be associated with each instance of entity A
Minimum Cardinality
The minimum number of instances of entity B that
may be associated with each instance of entity A
Maximum Cardinality
The maximum number of instances of entity B that
may be associated with each instance of entity A
217
Electronic Commerce Development:

Conceptual Data Model
Conceptual data modeling for Internet

applications is no different than the
processed followed for other types of
applications
Pine Valley Furniture WebStore
Four entity types defined
Customer
Inventory
Order
Shopping cart
218
219
220
ER diagram for Pine Valley furniture
222
Summary
Process of conceptual data modeling

Deliverables
Gathering information
Entity-Relationship Modeling
Entities
Attributes
Candidate keys and identifiers
Multivalued attributes
Degree of relationship
223
Summary
Cardinality
Associative entities
Conceptual data modeling and Internet
development
224
Questions
1. List the four types of E-R diagrams produced and analyzed

during conceptual data modeling.
2. What elements of a data flow diagram should be analyzed as
part of data modeling?
3. What is the degree of a relationship? Give an example of
each of the relationship degrees illustrated in this chapter.
4. Explain why a ternary relationship is not the same as three
binary relationships.
5. Which of the following types of relationships can have
attributes associated with them: one-to-one, one-to-many,
many-to-many?
6. Give an example of a ternary relationship (different from any
example in this chapter.)
225
Chapter 11
Object-Oriented Analysis and Design
Learning Objectives
Discuss the concepts and principles

underlying the object-oriented approach
Learn to develop requirements models
using use-case diagrams
Learn to develop requirements models
using state and sequence diagrams
Learn to use class diagrams to develop
object models of the problem domain
227
The Object-Oriented Modeling

Approach
Benefits
1.
2.
3.
4.
5.
The ability to tackle more challenging problem

domains
Improved communication among users, analysts,
designers and programmers
Reusability of analysis, design and programming
results
Increased consistency among the models
developed during object-oriented analysis, design,
and programming
Explicit representation of commonality among
system components
228
The Object-Oriented Modeling

Approach
Object-Oriented systems development

life cycle:
Process of progressively developing
representation of a system component
(or object) through the phases of
analysis, design and implementation
The model is abstract in the early
stages
As the model evolves, it becomes more
and more detailed
229
The Object-Oriented Systems

Development Life Cycle
Analysis Phase
Model of the real-world application is developed
showing its important properties
Model specifies the functional behavior of the
system independent of implementation details
Design Phase
Analysis model is refined and adapted to the
environment
Implementation Phase
Design is implemented using a programming
language or database management system
230
The Object-Oriented Systems

Development Life Cycle
Unified Modeling Language (UML)

A notation that allows the modeler to
specify, visualize and construct the artifacts
of software systems, as well as business
models
Techniques and notations
Use cases
Sequence diagrams
Activity diagrams
Class diagrams
State diagrams
231
An architecture-based vision
Functional
Functional needs
needs
Major
Major classes
classes
coding
coding
Logical
Logical View
View
Components
Components View
View
Use
Use Case
Case View
View
Process
Process View
View
Deployment
Deployment View
View
Servers
Servers and
and
network
network organization
organization
System
System performances
performances
232
1
Statecharts Diagrams
Dynamic modelling,
focusing on an object.
Activities done in each
state correspond to
operations
Collaboration diagram
Dynamic modelling,
focusing on spatial
relationships between
objects
Class Diagrams
Static modelling
Systems structure
Objects Diagrams
Static modelling
Context
Use Cases diagrams

Functional modelling
Sequence Diagrams
Dynamic modelling of
scenarios
Activity Diagrams
Dynamic modelling,
focusing on an activity
233
Use-Case Modeling
Applied to analyze functional requirements of

the system
Performed during the analysis phase to help
developers understand functional
requirements of the system without regard for
implementation details
Use Case
A complete sequence of related actions initiated by
an actor
Actor
An external entity that interacts with the system
234
Use-Case Modeling
Use cases are always initiated by an

actor
Use cases represent complete
functionality of the system
Use cases may participate in
relationships with other use-cases
Use cases may also use other use cases
235
Use cases diagram
Use cases diagrams describe what a system does from

the standpoint of an external observer. The emphasis is
on what a system does rather than how.
Use cases diagrams are closely connected to scenarios.
A scenario is an example of what happens when
someone interacts with the system.
Here is a scenario for a medical clinic:
1. A patient calls the clinic to make an appointment for a yearly
checkup.
2. The receptionist finds the nearest empty time slot in the
appointment book
3. and schedules the appointment for that time slot
A use case is a summary of scenarios for a single task

or goal. An actor is who or what initiates the events
involved in that task. Actors are simply roles that people
or objects play
236
A use case and his actor
237
A use case diagram
238
239
Explanation
A system boundary rectangle separates the clinic system from the

external actors.
A use case generalization shows that one use case is simply a special
kind of another. Pay Bill is a parent use case and Bill Insurance is the
child. A child can be substituted for its parent whenever necessary.
Generalization appears as a line with a triangular arrow head toward
the parent use case.
Include relationships factor use cases into additional ones. Includes are
especially helpful when the same use case can be factored out of two
different use cases. Both Make Appointment and Request Medication
include Check Patient Record as a subtask. In the diagram, include
notation is a dotted line beginning at base use case ending with an
arrows pointing to the include use case. The dotted line is labeled
<<include>>.
An extend relationship indicates that one use case is a variation of
another. Extend notation is a dotted line, labeled <<extend>>, and
with an arrow toward the base case. The extension point, which
determines when the extended case is appropriate, is written inside
the base case.
240
241
Use case diagrams are helpful in three

areas
Determining features (requirements). New use

cases often generate new requirements as the
system is analyzed and the design takes
shape.
Communicating with clients. Their notational
simplicity makes use case diagrams a good
way for developers to communicate with
clients.
Generating test cases. The collection of
scenarios for a use case may suggest a suite of
test cases for those scenarios.
242
Use case example
Online HR system
244
245
Update Benefits description
246
Dynamic Modeling:
Sequence Diagrams
Sequence Diagram
A depiction of the interaction among objects during
certain periods of time
Activation
The time period during which an object performs an
operation
Messages
Means by which objects communicate with each other
247
248
249
Explanation
The Reservation window sends a makeReservation() message

to a HotelChain. The HotelChain then sends a
makeReservation() message to a Hotel. If the Hotel has
available rooms, then it makes a Reservation and a
Confirmation.
Each vertical dotted line is a lifeline, representing the time that
an object exists. Each arrow is a message call. An arrow goes
from the sender to the top of the activation bar of the
message on the receiver's lifeline. The activation bar represents
the duration of execution of the message.
In our diagram, the Hotel issues a self call to determine if a
room is available. If so, then the Hotel creates a Reservation
and a Confirmation. The asterisk on the self call means
iteration (to make sure there is available room for each day of
the stay in the hotel). The expression in square brackets, [ ], is a
condition.
The diagram has a clarifying note, which is text inside a dogeared rectangle. Notes can be put into any kind of UML diagram.
250
Collaboration diagrams are also interaction

diagrams. They convey the same information as
sequence diagrams, but they focus on object roles
instead of the times that messages are sent. In a
sequence diagram, object roles are the vertices and
messages are the connecting links.
The object-role rectangles are labeled with either class
or object names (or both). Class names are preceded by
colons ( : ).
Each message in a collaboration diagram has a
sequence number. The top-level message is
numbered 1. Messages at the same level (sent during
the same call) have the same decimal prefix but suffixes
of 1, 2, etc. according to when they occur.
251
252
Activity diagram
An activity diagram is essentially a fancy flowchart.

Activity diagrams and statechart diagrams are related
While a statechart diagram focuses attention on an object
undergoing a process (or on a process as an object), an
activity diagram focuses on the flow of activities involved
in a single process. The activity diagram shows the how
those activities depend on one another.
For our example, we used the following process.

"Withdraw money from a bank account through an ATM."
The three involved classes (people, etc.) of the activity are
Customer, ATM, and Bank. The process begins at the black
start circle at the top and ends at the concentric
white/black stop circles at the bottom. The activities are
rounded rectangles.
253
254
Class diagrams
A Class diagram gives an overview of a

system by showing its classes and the
relationships among them.
Class diagrams are static: they display
what interacts but not what happens
when they do interact
255
Class notations
256
Class stereotypes
257
Example
The following class diagram models a

customer order from a retail catalog.
The central class is the Order.
Associated with it are the Customer making
the purchase and the Payment.
A Payment is one of three kinds: Cash, Check, or
Credit.
The order contains OrderDetails (line items), each
with its associated Item.
258
259
Representing Associations
Association
A relationship between object classes
Degree may be unary, binary, ternary or higher
Depicted as a solid line between participating
classes
Association Role
The end of an association where it connects to a
class
Each role has multiplicity, which indicates how
many objects participate in a given association
relationship
260
261
Representing Generalization
Generalization
Abstraction of common features among multiple
classes, as well as their relationships, into a more
general class
Subclass
A class that has been generalized
Superclass
A class that is composed of several generalized
subclasses
262
Representing Generalization
Discriminator
Shows which property of an object class is being

abstracted by a generalization relationship
Inheritance
A property that a subclass inherits the features from

its superclass
Abstract Class
A class that has no direct instances, but whose

descendents may have direct instances
Concrete Class
A class that can have direct instances
263
264
265
Representing Aggregation
Aggregation
A part-of relationship between a component
object and an aggregate object
Example: Personal computer
Composed of CPU, Monitor, Keyboard, etc
266
Composition and Aggregation
Associations in which an object is part of a

whole are aggregations.
Composition is a strong association in which
the part can belong to only one whole
The part cannot exist without the whole. Composition
is denoted by a filled diamond at the whole end.
The following diagram shows that a BoxOffice

belongs to exactly one MovieTheater.
Destroy the MovieTheater and the BoxOffice
goes away!
The collection of Movies is not so closely bound to
the MovieTheater.
267
268
Dependencies and constraints
A dependency is a relation between two

classes in which a change in one may force
changes in the other. Dependencies are drawn
as dotted lines.
In the class diagram below, Co_op depends on
Company. If you decide to modify Company, you
may have to change Co_op too.
A constraint is a condition that every

implementation of the design must satisfy.
Constraints are written in curly braces { }.
The constraint on our diagram indicates that a
Section can be part of a CourseSchedule only if it
is not canceled.
269
270
Packages
To simplify complex class diagrams, you can

group classes into packages.
A package is a collection of logically related
UML elements.
Packages appear as rectangles with small tabs at the
top.
The package name is on the tab or inside the
rectangle.
The dotted arrows are dependencies: One package
depends on another if changes in the other could
possibly force changes in the first.
271
272
Object diagrams
Object diagrams show instances instead

of classes. They are useful for
explaining small pieces with
complicated relationships, especially
recursive relationships.
This small class diagram shows that a
university Department can contain lots
of other Departments.
273
274
Object Modeling
Object Diagrams
Object Diagram
also called an instance diagram
Object is represented as a rectangle with two
compartments
Operation
A function or service that is provided by all the
instances of a class
Encapsulation
The technique of hiding the internal
implementation details of an object from its
external view
275
Objects notations
276
277
Statecharts diagram
Objects have behaviors and state. The state of an object

depends on its current activity or condition. A statechart
diagram shows the possible states of the object and the
transitions that cause a change in state.
State
A condition during the life of an object during which it satisfies
some conditions, performs some actions or waits for some events
Shown as a rectangle with rounded corners
State Transition
The changes in the attribute of an object or in the links an object
has with other objects
Shown as a solid arrow
Diagrammed with a guard condition and action
Event
Something that takes place at a certain point in time
278
Example
Our example diagram models the login part of

an online banking system.
Logging in consists of entering a valid social security
number and personal id number, then submitting the
information for validation.
Logging in can be factored into four non-overlapping
states: Getting SSN, Getting PIN, Validating, and
Rejecting.
From each state comes a complete set of transitions
that determine the subsequent state.
279
280
Explanation
Our diagram has two self-transition, one on

Getting SSN and another on Getting PIN.
The initial state (black circle) is a dummy to
start the action. Final states are also dummy
states that terminate the action.
The action that occurs as a result of an event
or condition is expressed in the form /action.
While in its Validating state, the object does
not wait for an outside event to trigger a
transition. Instead, it performs an activity. The
result of that activity determines its
subsequent state.
281
282
Moving to Design
Start with existing set of analysis model

Progressively add technical details
Design model must be more detailed than
analysis model
Component Diagram
A diagram that shows the software components or
modules and their dependencies
Deployment Diagram
A diagram that shows how the software components,
process and objects are deployed into the physical
architecture of the system
283
Component and deployment diagrams
A component is a code module. Component

diagrams are physical analogs of class diagram.
Deployment diagrams show the physical
configurations of software and hardware.
The following deployment diagram shows the
relationships among software and hardware
components involved in real estate transactions.
The physical hardware is made up of nodes.
Each component belongs on a node.
Components are shown as rectangles with two
tabs at the upper left.
284
285
Summary
Object-Oriented modeling approach

Benefits
Unified Modeling Language
Use cases
Class diagrams
State diagrams
Sequence diagrams
Use-case modeling
286
Summary
Object Modeling: Class Diagrams

Associations
Generalizations
Aggregation
Dynamic Modeling: State Diagrams

Dynamic Modeling: Sequence
Diagrams
Moving to Design
287
Chapter 12
Designing the Human Interface
Learning Objectives
Explain the process of designing forms and

reports and the deliverables for their creation
Discuss general guidelines for formatting text,
tables and lists
Learn how to effectively format text, tables
and lists
Explain the process of designing interfaces and
dialogues and the deliverables for their
creation
289
Learning Objectives
Discuss the general guidelines for interface

design including:
Layout and design
Structuring data entry fields
Providing feedback
System help
Discuss the design of human-computer

dialogues and the use of dialogue
diagramming
Explain interface design guidelines unique to
the design of Internet-based electronic
commerce systems
290
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
291
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
A passive document for reading or viewing data
Typically contains data from many database records
or transactions
292
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?
293
The Process of Designing Forms and

Reports
Prototyping
Initial prototype is designed from
requirements
Users review prototype design and either
accept the design or request changes
If changes are requested, the constructionevaluation-request cycle is repeated until
the design is accepted
294
Design specifications are major

deliverable and contain three sections
1. Narrative
2. Screen Design
3. Testing and usability assessment
295
General Formatting Guidelines for

Forms and Reports
Highlighting
Use sparingly to draw user to or away from
certain information
Blinking and audible tones should only be
used to highlight critical information
requiring users immediate attention
Methods should be consistently selected
and used based upon level of importance of
emphasized information
296
297
298
General Formatting Guidelines for Forms

and Reports
Displaying Text
Display text in mixed upper- and lowercase 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
Do not hyphenate words between lines
Use abbreviations and acronyms only when they are
widely understood by users and are significantly
shorter than the full text
299
General Formatting Guidelines for

Forms and Reports
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
300

and Reports
Displaying tables and lists (continued)

Formatting columns, rows and text
Sort in a meaningful order
Place a blank line between every 5 rows in long columns
Similar information displayed in multiple columns should
be sorted vertically
Columns should have at least two spaces between them
Allow white space on printed reports for user to write
notes
Use a single typeface, except for emphasis
Use same family of typefaces within and across displays
and reports
Avoid overly fancy fonts
301

and Reports
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
302
303
304
305
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
306
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
307
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
308
Structuring Data Entry
Entry
Never require data that are already online or

that can be computed
Defaults
Always provide default values when

appropriate
Units
Make clear the type of data units requested

for entry
Replacement
Use character replacement when appropriate
Captioning
Always place a caption adjacent to fields
Format
Provide formatting examples
Justify
Automatically justify data entries
Help
Provide context-sensitive help when

appropriate
309
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 systems
interfaces to avoid, detect, and correct data
entry mistakes
Table 8-9 describes types of data entry errors
Table 8-10 lists techniques used by system
designers to detect errors
310
311
312
Providing Feedback
1.
Status Information
Keeps users informed of what is going on in system
Displaying status information is especially important
if the operation takes longer than a second or two
2.
Prompting Cues
Best to keep as specific as possible
3.
Error and Warning Messages

Messages should be specific and free of error codes
and jargon
User should be guided toward a result rather than
scolded
Use terms familiar to user
Be consistent in format and placement of messages
313
Providing Help
Place yourself in users place when designing

help
Guidelines
Simplicity
Help messages should be short and to the point
Organization
Information in help messages should be easily
absorbed by users
Demonstrate
It is useful to explicitly show users how to perform an
operation
314
Providing Help
Context-Sensitive Help
Enables user to get field-specific help
Users should always be returned to

where they were when requesting help
315
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 dialogue sequence
2. Build a prototype
3. Assess usability
316
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
Top: Unique display reference number used by other
displays for referencing dialogue
Middle: Contains the name or description of the display
Bottom: Contains display reference numbers that can
be accessed from the current display
317
318
Designing Dialogues:
Building Prototypes and Assessing
Usability
Often optional activities

Task is simplified by using graphical design
environment
319
320
Web-based Application:
Designing Interfaces and Dialogues for Pine Valley
Furnitures Webstore
General Guidelines
Several factors have contributed to poor
design of Web interfaces
Webs single click-to-act method of loading
static hypertext documents
Limited capabilities of most Web-browsers to
support finely grained user interactivity
Limited agreed-upon standards for encoding Web
content and control mechanisms
Lack of maturity in Web scripting and
programming languages
321
Designing the Human Interface at Pine Valley
Furniture
Design Guidelines
Navigation via cookie crumbs
A technique that uses a series of tabs on a Web
page to show users where they are and where
they have been in the site
Tabs are hyperlinks to allow users to move
backward easily within the site
Two important purposes
Allows users to navigate to a point previously
visited
Shows users where they have been and how far
they have gone from point of entry into site
322
Design Guidelines
Lightweight Graphics
The use of small images to allow a Web
page to be displayed more quickly
Forms and Data Integrity

All forms that record information should be
clearly labeled and provide room for input
Clear examples of input should be provided
to reduce data errors
Site must clearly designate which fields are
required, which are optional and which have
a range of values
323
Summary
Designing Forms and Reports

General guidelines for designing forms
and reports
Formatting text, tables and lists
Design guidelines for interfaces
Layout design
Structuring data entry fields
Providing feedback
Designing help
324
Questions
1. To which initial questions must the

analyst gain answers in order to build
an initial prototype of a system
output?
2. Describe the process of designing
interfaces and dialogues. What
deliverables are produced from this
process? Are these deliverables the
same for all types of system projects?
Why or why not?
325
Chapter 13
Systems Implementation and Operation
Learning Objectives
Describe the process of coding, testing and converting

an organizational information system
Discuss four installation strategies
Direct
Parallel
Single location
Phased installation
Describe the deliverables for documenting the system

and for training and supporting the users
Compare the many modes available for organizational
system training, including self-training and electronic
performance support systems
327
Learning Objectives
Discuss the issues of providing support

to end users
Discuss system implementation failure
Explain four types of maintenance
Describe several factors that influence
the cost of maintaining an information
system
328
System Implementation and

Maintenance
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
329
The Process 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
330
Deliverables
331
The Process 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
332
Deliverables
Documentation
System documentation
User documentation
User training plan

Classes
Tutorials
User training modules

Training materials
Computer-based training aids
User support plan

Help desk
On-line help
Bulletin boards and other support mechanisms
333
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.
2.
3.
4.
Obtaining maintenance requests

Transforming requests into changes
Designing changes
Implementing changes
334
335
Deliverables
Development of a new version of the

software, new versions of all design
documents and training materials
created or modified during the
maintenance effort
336
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
Test plans provide improved communication
among all parties involved in testing
Serve as checklists
337
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
338
Types of Testing
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. Modules are typically integrated in a
top-down, incremental fashion
339
Types of Testing
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
340
The Testing Process
1. The purpose of the testing is confirming

that the system satisfies requirements
2. Testing must be planned
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
341
342
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
343
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
Performance testing
Determines how the system performs on the range of
possible environments in which it may be used
344
Beta Testing
User testing of a completed information
system using real data in the real user
environment
345
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
346
Installation
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
347
348
Planning Installation
Considerations
Data conversion
Error correction
Loading from current system
Planned system shutdown

Business cycle of organization
349
Documenting the System
System documentation
Detailed information about a systems
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
350
Documenting the System
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
351
Training Information System Users
Potential training topics

Use of the system
General computer concepts
Information system concepts
Organizational concepts
System management
System installation
352
Training methods
Resident expert
Computer-aided instruction
Formal courses
Software help components
Tutorials
Interactive training manuals
External sources, such as vendors
353
354
Electronic performance support system

(EPSS)
Component of a software package or
application in which training and
educational information is embedded
355
Supporting Information System

Users
Support is extremely important to users

J.D. Power and Associates survey found user
support to be number one criterion
contributing to user satisfaction with
personal computing
Most organizations provide support by

two means
Information center
Help desk
356
Supporting Information System Users:

Information Center
An organizational unit whose mission is to support users in

exploiting information technology
Staff might perform the following tasks
Install new hardware or software and set up user accounts
Consult with users writing programs in fourth-generation
languages
Extract data from organizational databases onto personal
computers
Answer basic on-demand questions
Provide a demonstration site for viewing hardware and
software
Work with users to submit system change requests
357
Supporting Information System Users:

Help Desk
A single point of contact for all user

inquiries and problems about a particular
information system or for all users in a
particular department
358
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
359
Why Implementation Sometimes Fails
Insights about implementation process

Risk
Commitment to the project
Commitment to change
Extent of project definition and planning
Realistic user expectations
Implementation success factors

Extent to which system is used
Users satisfaction with system
360
Project Close Down
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
361
Conducting System 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
362
Conducting System Maintenance:

The Cost of Maintenance
Many organizations allocate eighty

percent of information systems budget to
maintenance
Factors that influence system
maintainability
Latent defects
Number of customers for a given system
Quality of system documentation
Maintenance personnel
Tools
Well-structured programs
363
Conducting System Maintenance:

Measures of Effectiveness
Number of failures
Time between each failure
Type of failure
Mean time between failures (MTBF)
A measurement of error occurrences
that can be tracked over time to
indicate the quality of a system
364
Controlling Maintenance Requests
Determine type of request

Error
Adaptation
Enhancement
Figure 10-9 shows a flowchart for a

request procedure
365
366
Configuration Management
The process of assuring that only authorized

changes are made to the system
Baseline modules
Software modules that have been tested,
documented, and approved to be included in the
most recently created version of a system
System librarian
A person responsible for controlling the checking out
and checking in of baseline modules when a system
is being developed or maintained
Build routines
Guidelines that list the instructions to construct an
executable system from the baseline source code
367
Summary
Process of coding, testing and

converting an organizational
information system
Four installation strategies
Direct
Parallel
Single location
Phased installation
368
Summary
Documentation
System
User
User training
Providing support for end users
Systems implementation failures
369
Summary
Maintenance
Corrective
Adaptive
Perfective
Preventive
Cost of maintenance
Measuring effectiveness of
maintenance
370
Summary
Controlling maintenance requests

Configuration management
Internet development
371

Information Systems Best Notes

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Information Systems Best Notes

Transféré par

Droits d'auteur :

Formats disponibles

Information Systems

Analysis and Design

1. Information Systems: the big picture

Understand the term information systems (IS)

Information Systems Defined

Combinations of hardware, software,

Key Elements of Information

Data: raw material, unformatted

Knowledge as a Business Resource

Technology and Information Systems

Computer-Based Information Systems

The goal of IS is to provide useful data to users

Integrating Skills and Knowledge

Hot Skills in IS Workers

IS Within the Firm

Traditionally a love/hate relationship

Now: progress toward better customer

The Spread of Technology in

Technology infiltrates business units

The Spread of Technology in

Benefits of centralized IS function

1. Define and understand the term

Understand the IS in automation,

Why Use Information Systems?

Automating: doing things faster

Technology is used to automate a

Loan application example

Going beyond automation

Total Quality Management (TQM)

Now, it should be fairly obvious why an IS

Understand characteristics of operational,

Executive level (top)

Managerial level (middle)

Operational level (bottom)

General Types of Information

Transaction Processing Systems (TPSs)

General Types of Information

General Types of Information

Management Information Systems

Used at managerial level of the organization

General Types of Information

Management Information Systems

General Types of Information

Management Information Systems

General Types of Information

Executive Information Systems (EISs)

General Types of Information

Executive Information Systems (EISs)

Information Systems that Span Organizational

Information Systems that

Decision Support Systems (DSSs)

Models for each of the functional areas

Information Systems that

Expert Systems (ESs)

Information Systems that

Office Automation Systems (OASs)

Information Systems that

Information Systems that

Functional Area Information Systems

Information Systems that

Global Information Systems

Understand how information technology

Before an entreprise system

With an entreprise sytem