Chapter 1

Key Ideas
Many failed systems were abandoned

because analysts tried to build wonderful

systems without understanding the
organization.
The primarily goal is to create value for the
organization.

Key Ideas
The systems analyst is a key person

analyzing the business, identifying

opportunities for improvement, and
designing information systems to
implement these ideas.
It is important to understand and develop
through practice the skills needed to
successfully design and implement new
information systems.
3

Project Phases
Planning (Why build the system? How should

the team go about building it?)

Analysis (Who uses system, what will it do,
where and when will the system be used?)
Design (How will the system work?)
Implementation (System delivery)

Planning
Identifying business value
Analyze feasibility
Develop work plan
Staff the project
Control and direct project

Analysis
Analysis strategy
Gathering business requirements
Requirements definition use cases
Process modeling
Data modeling

Design
Design selection
Architecture design
Interface design
Data storage design
Program design

Implementation
Construction
Program building
Program and system testing

Installation
Conversion strategy
Training plan
Support plan

Processes and
Deliverables
Process
Planning

Analysis
Design
Implementation

Product
System Request
Feasibility Analysis
Workplan
System Proposal
System
Specification
New System and
Maintenance Plan
10

11

12

Pros
Identifies systems
requirements long
before programming
begins
Minimizes changes to
requirements as
project progresses

Cons
Design must be
specified on paper
before programming
begins
Long time between
system proposal and
delivery of new
system

13

14

Pros

Cons

Reduces Schedule
Time

Still Uses Paper

Documents

Less Chance of
Rework

Sub-projects May Be
Difficult to Integrate

15

Incorporate special techniques and tools:

CASE tools
JAD sessions
Fourth generation/visualization programming
languages
Code generators

16

Phased development
A series of versions developed sequentially
Prototyping
System prototyping

Throw-away prototyping
Design prototyping

17

Insert Figure 1-4 here

18

Pros
Users Get a System
To Use Quickly
Users Can Identify
Additional Needs
For Later Versions

Cons

Users Work with a

System that is
Intentionally
Incomplete

19

20

Pros

Cons

Users Interact with

Prototype Very Quickly

Tendency to do
Superficial Analysis

Users Can Identify

Needed Changes
And Refine Real
Requirements

Initial Design
Decisions May
Be Poor

21

22

Pros
Risks are Minimized

Cons
May Take Longer
Than Prototyping

Important Issues are

Understood Before the
Real System is Built

23

24

Pros
Fast Delivery of Results

Works Well in Projects

With Undefined or
Changing Requirements

Cons
Requires Discipline
Works Best in
Small Projects
Requires Much
User Input

25

Object-Oriented
Approach

26

Criteria for Selecting the Appropriate

Methodology
Clear user requirements
Familiarity with technology
Complexity of system
Reliability of system
Time schedule
Schedule visibility

27

Basic Step to develop an Object Oriented

Systems
Identifying business value
Analyze feasibility
Develop workplan
Staff the project
Control and direct project
Requirements determination
Functional modeling
Structural modeling
Behavioral modeling
Moving on to design
28

Chapter 2

29

Key Ideas
An opportunity to create business value from

using information technology initiates a

project.
Feasibility analysis helps determine whether
or not to proceed with the IS project.
Projects are selected based on business needs
and project risks.

30

Key Ideas
The project sponsor is a key person who

identifies business value to be gained from

using information technology.
The approval committee reviews system
requests from groups throughout the
organization and selects projects for the
benefit of the business.

31

IDENTIFYING PROJECTS
WITH BUSINESS VALUE

32

How Do Projects Begin?

Business needs should drive projects.
Project sponsor recognizes business need for

new system and desires to see it

implemented.
Business needs determine the systems
functionality (what it will do).
The projects business value should be clear.

System Request
A document describing business reasons for

project and systems expected value.

Lists projects key elements
Project sponsor
Business need
Business requirements
Business value
Special issues or constraints

System Request
Examples

Project sponsor VP of Marketing

Business need Reach new customers and

improve service to existing customers

Business requirements Provide web-based
shopping capability
Business value - $750,000 in new customer
sales; $1.8M in existing customer sales
Special issues or constraints System must
be operational by holiday shopping season

Preliminary Project
Acceptance

System request is reviewed by approval

committee
Based on information provided, project merits
are assessed.
Worthy projects are accepted and undergo
additional investigation the feasibility
analysis.

Feasibility Analysis
Detailed business case for the project
Technical feasibility
Economic feasibility
Organizational feasibility
Compiled into a feasibility study
Feasibility is reassessed throughout the project

37

Technical Feasibility: Can We Build

It?
Users and analysts familiarity with the

business application area

Familiarity with technology
Have we used it before? How new is it?

Project size
Number of people, time, and features
Compatibility with existing systems

Economic Feasibility: Should We

Build It?
Identify costs and benefits
Assign values to costs and benefits
Determine cash flow
Assess financial viability
Net present value (NPV)
Return on investment (ROI)
Break even point(BEP)

Costs

Benefits

Tangible

*
*
*

*
*
*

Intangible

*
*
*

*
*
*

40

Assign Cost and Benefit

Values

Difficult, but essential to estimate

Work with people who are most familiar with

the area to develop estimates

Intangibles should also be quantified
If intangibles cannot be quantified, list and
include as part of supporting material

Strategic alignment
How well do the project goals align with
business objectives?
Stakeholder analysis
Project champion(s)
Organizational management
System users
Organizational
Feasibility: If we build it, will they
come?

Project Selection
Approval committee works from the system
request and the feasibility study
Project portfolio how does the project fit

within the entire portfolio of projects?

Trade-offs must be made to select projects
that will form a balanced project portfolio
Viable projects may be rejected or deferred
because of project portfolio issues.

Chapter 3

44

Key Definitions
Project management is the process of

planning and controlling the development

of a system within a specified timeframe at
a minimum cost with the right functionality.
A project manager has the primary
responsibility for managing the hundreds
of tasks and roles that need to be carefully
coordinated.

45

Four Key Steps in Managing

Projects
Identifying project size
Creating and managing the workplan
Staffing the project
Coordinating and controlling project activities

46

47

Ti
m
Pr
oj
ec
t

Cos

Modifying one element

requires adjusting the
others

Project Size
ject
Pro

Project Management
involves
making trade-offs

48

Project Estimation
The process of assigning projected values for

time and effort

Sources of estimates

Methodology in use
Actual previous projects
Experienced developers

Estimates begin as a range and become more

specific as the project progresses

49

Planning
Industry
Standard
For Web
Applications

Time
Required
in Person
Months

Analysis

15%

Design

20%

5.33

9.33

Implementation

35%

30

50

Converting Function Points to Lines of Code

Language

LOC ratio

C
COBOL
JAVA
C++
Turbo Pascal
Visual Basic
PowerBuilder
HTML
Packages
(e.g., Access, Excel)

130
110
55
50
50
30
15
15
10-40

Source: Capers Jones, Software Productivity Research

51

52

Work Plan Information

Example

Name of task
Start date
Completion date
Person assigned
Deliverable(s)
Completion status
Priority
Resources needed
Estimated time
Actual time

Perform economic feasibility

Jan 05, 2003
Jan 19, 2003
Mary Smith, sponsor
Cost-benefit analysis
Open
High
Spreadsheet
16 hours
14.5 hours

53

Identifying Tasks
Methodology
Using standard list of tasks

Top-down approach
Identify highest level tasks
Break them into increasingly smaller units
Organize into work breakdown structure

54

Project Workplan
List of all tasks in the work breakdown

structure, plus
Duration of task
Current task status
Task dependencies
Key milestone dates

55

Tracking Project Tasks

Gantt Chart
Bar chart format
Useful to monitor project status at any point in
time
PERT Chart
Flowchart format
Illustrate task dependencies and critical path

56

Task

Week
2

10

11

12

Go to Library
Go to Bookstore
Select and Purchase Book
Skim Book
Write Phase One
Read Book Carefully
Write Phase Two

57

13

Go to Library
4 weeks
Go to Bookstore
4 weeks

Select and
purchase book
1 week

Skim book
3 weeks

Write Phase One

2 weeks
Write Phase Two
3 weeks

Read book carefully

3 weeks

58

59

Staffing Attributes
Staffing levels will change over a projects

lifetime
Adding staff may add more overhead than
additional labor
Using teams of 8-10 reporting in a hierarchical
structure can reduce complexity

60

61

62

Planning

Analysis

Upper CASE

Design

Implementation

Lower CASE

Integrated CASE (I-CASE)

63

Diagrams

Screen
Designs

CASE Repository

Procedural
Logic

Metadata

64

Standards
Examples
Formal rules for naming files
Forms indicating goals reached
Programming guidelines

65

Documentation
Project binder
Table of contents
Continual updating

66

Managing Risk
Risk assessment
Actions to reduce risk
Revised assessment

67

Classic Mistakes
Overly optimistic schedule
Failing to monitor schedule
Failing to update schedule
Adding people to a late project

68

Chapter 4

69

Key Definitions
The As-Is system is the current system and

may or may not be computerized

The To-Be system is the new system that is
based on updated requirements
The System Proposal is the key deliverable
from the Analysis Phase

70

Key Ideas
The goal of the analysis phase is to truly

understand the requirements of the new system

and develop a system that addresses them -- or
decide a new system isnt needed.
The System Proposal is presented to the approval
committee via a system walk-through.
Systems analysis incorporates initial systems
design.
Requirements determination is the single most
critical step of the entire SDLC.
71

What is a Requirement?
A statement of what the system must do
A statement of characteristics the system

must have
Focus is on business user needs during
analysis phase
Requirements will change over time as project
moves from analysis to design to
implementation

72

Requirement Types
Functional Requirements
A process the system hast to perform
Information the system must contain

Nonfunctional Requirements
Behavioral properties the system must have
Operational
Performance
Security
Cultural

and political
73

Documenting
Requirements

Requirements definition report

Text document listing requirements in outline
form
Priorities may be included
Key purpose is to define the project scope:

what is and is not to be included.

74

Basic Steps of Determining

Requirements
Understand the As-Is system
Identify improvement opportunities
Develop the To-Be system concept
Techniques vary in amount of change
Business Process Automation (BPA) small change
Business Process Improvement (BPI) - moderate change
Business Process Reengineering (BPR) significant

change

Additional information gathering techniques are

needed as well

75

Chapter 5

76

Key Ideas
Functional models describe business

processes and the interaction of an

information system with its environment.
Two types of models are used to describe
functional models: Activity Diagrams and
Usecase Diagrams
Activity diagrams support the logical
modeling of business processes and
workflows.
Usecase Diagrams are used to describe the
basic functions of the information system.
77

Elements of an Activity
Diagram
Actions/Activities
Object Nodes
Object Flows
Control Nodes
Control Flows
Swimlanes

78

Activity Diagram

79

What are Use-Case

Descriptions?
Describe basic functions of the system

What the user can do

How the system responds
Use cases are building blocks for continued
design activities.

80

How Are Use-Cases

Created?
Two steps:

Write text-based case descriptions

Translate descriptions into diagrams

Describes one and only one function, but

may have multiple paths.

Developed working with users for content.

81

Types of Use-Cases
Overview versus detail
Essential versus real

82

Use Case Name:

ID:

Primary Actor:

Use Case Type:

Importance Level:

Stakeholders and Interests:

Brief Description:
Trigger:
Relationships: (Association, Include, Extend, Generalization)
Normal Flow of Events:
Subflows:
Alternate/Exceptional Flows:

83

84

85

Chapter 6

86

Key Definitions
Data model
A formal way of representing the data that are

used and created by a business system

Shows the people, places and things about
which data is captured and the relationships
among them.

Logical data model

shows the organization of data without

indicating how it is stored, created, or

manipulated.
87

Key Definitions
Physical data model
shows how the data will actually be stored in
databases or files.
Normalization is the process analysts use to

validate data models.

Data models should balance with process
models

88

89

What Is an ERD?
A picture showing the information created,

stored, and used by a business system.

Entities generally represent similar kinds of
information
Lines drawn between entities show
relationships among the data
High level business rules are also shown

90

Using the ERD to Show Business

Rules
Business rules are constraints that are

followed when the system is in operation.

ERD symbols can show when one instance of
an entity must exist for an instance of another
to exist
A doctor must exist before appointments the

doctor can be made

91

ERD symbols can show when one instance

of an entity can be related to only one or

many instances of another entity
One doctor can have many patients; each

patient may have only one primary doctor

ERD symbols show when the existence of

an entity instance is optional for a related

entity instance
A patient may or may not have insurance

coverage

92

93

Entity
A person, place, event, or thing about

which data is collected

Must be multiple occurrences to be an
entity
Example: If a firm has only one warehouse, the

warehouse is not an entity. However, if the firm

has several warehouses, the warehouse could
be an entity if the firm wants to store data
about each warehouse instance.

94

95

Attributes
Information captured about an entity
Only those used by the organization should be

included in the model

Attribute names are nouns
Sometimes entity name is added at the
beginning of the attribute name for clarity

96

Identifiers
One or more attributes can serve as the

entity identifier, uniquely identifying each

entity instance
Concatenated identifier consists of several
attributes
An identifier may be artificial, such as
creating an ID number
Identifiers may not be developed until the
Design Phase
97

98

Relationships
Associations between entities
The first entity in the relationship is the

parent entity; the second entity in the

relationship is the child entity
Relationships should have active verb names
Relationships go in both directions

99

Cardinality
refers to the number of times instances in one
entity can be related to instances in another
entity
One

instance in an entity refers to one and only

one instance in the related entity (1:1)
One instance in an entity refers to one or more
instances in the related entity (1:N)
One or more instances in an entity refer to one or
more instances in the related entity (M:N)

100

Modality
Refers to whether or not an instance of a child

entity can exist without a related instance in

the parent entity
Not

Null means that an instance in the related

entity must exist for an instance in another entity
to be valid
Null means that no instance in the related entity is
necessary for an instance in another entity to be
valid

101

102

ERD Basics
Drawing the ERD is an iterative process of

trial and revision

ERDs can become quite complex

103

Steps in Building ERDs

Identify the entities
Add appropriate attributes for each entity
Draw the relationships that connect

associated entities

104

Identify the Entities

Identify major categories of information
If available, check the process models for data

stores, external entities, and data flows

Check the major inputs and outputs from the
use cases

Verify that there is more than one instance

of the entity that occurs in the system

105

Add Appropriate
Attributes

Identify attributes of the entity that are relevant

to the system under development

Check the process model repository entries for

details on data flows and data stores

Check the data requirements of the requirements
definition
Interview knowledgeable users
Perform document analysis on existing forms and
reports

Select the entitys identifier

106

Draw the Relationships

Start with an entity and identify all entities

with which it shares relationships

Describe the relationship with the
appropriate verb phrase
Determine the cardinality and modality by
discussing the business rules with
knowledgeable users

107

ERD Building Tips

Only include entities with more than one

instance of information
Dont include entities associated with
implementation of the system (they will be
added later)

108

109

Best practices rather than rules

Entities should have many occurrences
Avoid unnecessary attributes
Clearly label all components
Apply correct cardinality and modality
Break attributes into lowest level needed
Labels should reflect common business terms
Assumptions should be clearly stated

110

Technique used to validate data

models
Series of rules applied to logical
data model to improve its
organization
Three normalization rules are
common
111

112

Chapter 7

113

Key Ideas
A structural or conceptual model describes

the structure of the data that supports the

business processes in an organization..
The structure of data used in the system is
represented through class diagrams, and
object diagrams.

114

Purpose of Structural
Models

Reduce the semantic gap between the

real world and the world of software

Create a vocabulary for analysts and users
Represent things, ideas, and concepts of
importance in the application domain

115

Classes
Templates for creating instances or

objects
Concrete
Abstract
Typical examples:
Application domain, user interface, data
structure, file structure, operating
environment, document, and
multimedia classes
116

Attributes
Units of information relevant to the

description of the class

Only attributes important to the task should
be included

117

Operations
Action that instances/objects can take
Focus on relevant problem-specific operations

(at this point)

118

Relationships
Generalization
Enables inheritance of attributes and operations

Aggregation
Relates parts to wholes

Association
Miscellaneous relationships between classes

119

120

121

Class Diagram Syntax

A CLASS

Class 1
-attribute
+operation ()

AN ATTRIBUTE
AN OPERATION
AN ASSOCIATION

Attribute name/
derived attribute name
operation name ()
1..*
0..1
______verb phrase____
122

More on Attributes
Derived attributes
/age, for example can be calculated from birth
date and current date
Visibility
Public
Protected
Private

123

More on Operations
Constructor
Creates object

Query
Makes information about state available

Update
Changes values of some or all attributes

124

More on Relationships
Class can be related to itself (role)
Multiplicity
Exactly one, zero or more, one or more, zero or

one, specified range, multiple disjoint ranges

Association class

125

Simplifying Class
Diagrams

The view mechanism shows a subset of

information
Packages show aggregations of classes (or
any elements in UML)

126

127

Object Identification
Textual analysis of use-case information
Nouns suggest classes
Verbs suggest operations

Creates a rough first cut

Common object list
Incidents
Roles

128

Patterns
Useful groupings of classes that recur in

various situations
Transactions
Transaction class
Transaction line item class
Item class
Location class
Participant class

129

Chapter 8

130

Key Ideas
Behavioral models describe the internal

dynamic aspects of an information system

that supports business processes in an
organization
Key UML behavioral models are: sequence
diagrams, collaboration diagrams, and
statechart diagrams

131

Purpose of Behavioral
Models
To depict the internal view of business

processes
To show the effects of varied processes on the
system

132

Interaction Diagram
Components
Objects
Operations
Messages

133

Sequence Diagrams
Illustrate the objects that participate in a use-

case
Show the messages that pass between
objects for a particular use-case

134

135

AN ACTOR

AN OBJECT

anObject:aClass

A LIFELINE
A FOCUS OF CONTROL
A MESSAGE
OBJECT DESTRUCTION

aMessage()
x
136

Determine the context of the sequence

diagram
Identify the participating objects
Set the lifeline for each object
Add messages
Place the focus of control on each objects
lifeline
Validate the sequence diagram
137

Essentially an object diagram that shows

message passing relationships instead of

aggregation or generalization associations.
Emphasize the flow of messages among
objects, rather than timing and ordering of
messages

138

139

Chapter 9

140

Key Definitions
The navigation mechanism provides the way for

users to tell the system what to do

The input mechanism defines the way the system
captures information
The output mechanism defines the way the
system provides information to users or other
systems

141

Key Definitions
The graphical user interface (GUI) is the most

common type of interfaces most students are

likely to use personally and for developing
systems.

142

143

Basic Principles
Assume users
Have not read the manual
Have not attended training
Do not have external help readily at hand

All controls should be clear and

understandable and placed in an intuitive

location on the screen.

144

Basic Principles
Prevent mistakes
Limit choices
Never display commands that cant be used (or
gray them out)
Confirm actions that are difficult or impossible
to undo
Simplify recover from mistakes
Use consistent grammar order

145

Types of Navigation
Control
Languages

Command language
Natural language

Menus
Generally aim at broad shallow menu
Consider using hot keys

Direct Manipulation
Used with icons to start programs
Used to shape and size objects
May not be intuitive for all commands
146

147

148

149

Types of Menus
Menu bar
Drop-down menu
Pop-up menu
Tab menu
Toolbar
Image map

When
Would You
Use Each of
These Menu
Types?

150

Message Tips
Should be clear, concise, and complete
Should be grammatically correct and free of

jargon and abbreviations (unless they are the

users)
Avoid negatives and humor

151

Types of Messages
Error message
Confirmation message
Acknowledgment message
Delay message
Help message

When
Would You
Use Each of
These
Message
Types?

152

153

154

Basic Principles
The goal is to simply and easily capture

accurate information for the system

Reflect the nature of the inputs
Find ways to simplify their collection

155

Online versus Batch

Processing

Online processing immediately records the

transaction in the appropriate database

Batch processing collects inputs over time and
enters them into the system at one time in a
batch
Batch processing simplifies data communications
and other processes, but means that inventory
and other reports are not accurate in real time

156

Capture Data at the

Source
Reduces duplicate work
Reduces processing time

Decreases cost
Decreases probability of error

157

Source Data Automation

Can be obtained by using the following

technologies:
bar code readers
optical character recognition
magnetic stripe readers
smart cards

How can internet be used for source

data automation?

158

Minimize Keystrokes
Never ask for information that can be

obtained in another way

List selection is more efficient than entering
information
Use default values where possible

159

Types of Inputs
Data items linked to fields
Text
Numbers
Selection boxes

160

161

Types of Boxes
Check box
Radio button
On-screen list box
Drop-down list box
Combo box
Slider

When
Would You
Use Each of
These
Box
Types?

162

Types of Validation
Completeness check
Format check
Range check
Check digit check
Consistency check
Database checks

When
Would You
Use Each of
These
Validation
Methods?

163

164

Basic Principles
Understand report usage
Reference or cover-to-cover?
Frequency?
Real-time or batch reports?
Manage information load
All needed information, no more

Minimize bias

165

Types of Reports
Detail reports
Summary report
Turnaround document
Graphs

When
Would You
Use Each of
These
Report
Types?

166

Electronic

Versus Paper

167