Systems Analysis, Design & Modelling

Mike Majham
Email: mikemajham5050@gmail.com

PART ONE: PLANNING PHASE

Lecture 1B:
The Systems Analyst and IS’s Development
Slide 1
Objectives
✓ Describe the Information Systems Development
Life Cycle (SDLC).
✓ Explain how organizations identify IS
development projects.
✓ Explain the importance of linking the
information system to business needs.
✓ Be able to create a system request.
✓ Describe technical, economic, and
organizational feasibility assessment.
✓ Be able to perform a feasibility analysis.

Slide 2
THE SYSTEMS DEVELOPMENT
LIFE CYCLE (SDLC)

The Overall Process of Systems

Development

Slide 3
SDLC
The systems development life
cycle (SDLC) is the process of
determining how an information
system (IS) can support
business needs, designing the
system, building it, and
delivering it to users.

Slide 4
How Do Systems Get
Built?

Slide 5
Major Attributes of the
Lifecycle
Project
A sequence of activities that
must be completed on time,
within budget, and according
to specification.

Slide 6
Major Attributes of the
Lifecycle
The project
Moves systematically through phases
where each phase has a standard set
of outputs
Produces project deliverables
Uses deliverables in implementation
Results in actual information system
Uses gradual refinement

Slide 7
4 Main Project Phases
Planning
Why build the system?
Analysis
What, when, where will the system be?
Design
How will the system work?
Implementation
System construction & delivery
Slide 8
Planning
Identifying business value (is it
worth doing?)
Analyze feasibility (is it
possible?)
Develop work plan (when?)
Staff the project (who?)
Control and direct project
Slide 9
Planning
Planning – an organization’s total IS
needs are identified, analyzed,prioritized,
and arranged. It has two steps:
Project initiation, the system’s business
value to the organization is identified—how
will it lower costs or increase revenues?
Project management, the project manager
creates a work plan, staffs the project, and
puts techniques in place to help the project
team control and direct the project through
the entire SDLC.
Slide 10
Analysis
Analysis (what do we want?
Who will use the system?)
Information gathering
Process modelling (what
happens?)
Data modelling (… and to
what?)
Slide 11
Analysis
Analysis – system
requirements are studied and
structured.
The analysis phase answers the
questions of who will use the
system, what the system will
do, and where and when it will
be used.
Slide 12
Analysis
This phase has three steps:
Analysis strategy is developed to
guide the project team’s efforts.
Requirements gathering (e.g.,
through interviews, group
workshops, or questionnaires).

Slide 13
Analysis
System proposal
Presented to the project sponsor
and other key decision makers
(e.g., members of the approval
committee) who will decide whether
the project should continue to move
forward.

Slide 14
Design
The design phase decides how the
system will operate in terms of the
hardware, software, and network
infrastructure that will be in place;
the user interface, forms, and
reports that will be used; and the
specific programs, databases, and
files that will be needed.

Slide 15
Design
Design strategy must be determined.
Architectural design for the system that
describes the hardware, software, and
network infrastructure that will be used.
Interface design (HCI) specifies how the
users will move through the system
Database and file design specifications
are developed.
Program design (what will the program
do?)
Slide 16
Implementation
The final phase in the SDLC is the
implementation phase, during which
the system is actually built (or
purchased)
This phase has three steps:
System construction, the system
is built and tested to ensure that it
performs as designed.
Slide 17
Implementation
Installation, is the process by
which the old system is turned off
and the new one is turned on.
Support plan, usually includes a
formal or informal post-
implementation review, as well as a
systematic way for identifying
major and minor changes needed
for the system.
Slide 18
Processes and
Deliverables
Process Product

Planning Project Plan

Analysis System Proposal

Design System
Specification

Implementation New System and

Maintenance Plan

Slide 19
PROJECT IDENTIFICATION
AND INITIATION
How do Projects Get Started?

Slide 20
Where do project ideas
come from?
A project is identified when
someone in the organization
identifies a business need to build a
system.
Examples of business needs include
supporting a new marketing
campaign, reaching out to a new
type of customer, or improving
interactions with suppliers.
Slide 21
Where do project ideas
come from?
Sometimes, needs arise from
some kind of “pain” within the
organization, such as a drop in
market share, poor customer
service levels, unacceptable
product defect rates, or
increased competition.

Slide 22
Where do project ideas
come from?
New business initiatives and
strategies may be created and a
system to support them is
required, or a merger or
acquisition may require systems
to be integrated.

Slide 23
Where do project ideas
come from?
Today, many new information
system projects grow out of
Business Process Management
(BPM) initiatives.

Slide 24
What is BPM?
BPM is a methodology used by
organizations to continuously
improve end-to-end business
processes.
Business process management can
be applied to internal organizational
processes and to processes
spanning multiple business
partners.
Slide 25
What is BPM?
Benefits include:
Enhanced process agility, giving the
organization the ability to adapt more
rapidly and effectively to a changing
business environment;
Improved process alignment with
industry “best practices”; and
Increased process efficiencies as costs
are identified and eliminated from
process workflows.
Slide 26
What is BPM?
Four-step continuous cycle:
1. Defining and mapping the steps in a
business process,
2. Creating ways to improve on steps in
the process that add value,
3. Finding ways to eliminate or consolidate
steps in the process that don’t add
value,
4. Creating or adjusting electronic
workflows to match the improved
process maps.
Slide 27
BPM Identifies Business
Needs
Business Process Automation
“Create or adjust electronic workflows to
match the improved process maps”
Business Process Improvement
Study the business processes
Create new, redesigned processes to improve the
process workflows,and/or
Utilize new technologies enabling new process
structures
Business Process Reengineering
Total overhaul of work processes
Slide 28
Do We Have a Project
Yet?
Strong business need leads to a
person or group stepping up as the
Project Sponsor
Driving force behind project
Specifies overall business requirements
Determines business value
Formally requests a project via the
System Request

Slide 29
THE SYSTEMS REQUEST

The Business Reasons for the New System

Slide 30
System Request
A system request is a document
that describes the business reasons
for building a system and the value
that the system is expected to
provide.
The project sponsor usually
completes this form as part of a
formal system project selection
process within the organization.
Slide 31
System Request
Describes business reasons for project
Defines system’s expected value
Force the sponsor to formalize his/her
ideas
Provide a framework for collecting
initial project information
Standardize information to be used by
steering (approval) committee
Lists project’s key elements
Slide 32
Elements of System Request

Slide 33
Slide 34
Estimating Business Value
Identify sources:
increased sales;
increased costs;
reduced headcount;
lower turnover…
Assign values as initial
estimates
Slide 35
Estimating Business Value

Slide 36
FEASIBILITY ANALYSIS

Is This Project Really Worth Doing …

Can We Do This Project …
Will Organization Accept This If We Go Ahead …

Slide 37
Feasibility Analysis
Detailed business case for the
project
Technical feasibility
Economic feasibility
Organizational feasibility
Compiled into a feasibility study
Critically important to reassess
feasibility throughout the project
Slide 38
Technical Feasibility:
Can We Build It?
Sources of Technical Risk:
Users’ and analysts’ lack of familiarity
with the business application area
Lack of familiarity with technology
 Have we used it before? How new is it?
Project size
 Number of people, time frame, distinct
features
Compatibility with existing systems
 Degree of integration required
Slide 39
Economic Feasibility:
Should We Build It?
Identify costs and benefits
Assign values to costs and benefits
Determine cash flow
Assess financial viability
Return on investment
Break even point
Net present value
lide 40
Costs and Benefits
Include development and
operational costs
Consider tangible and intangible
benefits

Slide 41
Slide 42
Cost-Benefit Analysis
Discounted cash flow method
preferred
NPV preferred

Slide 43
Slide 44
Organizational Feasibility:
If We Build It, Will They Come?
Strategic alignment
Are project goals aligned with business
strategy?
Evaluate effect on various stakeholders
Strong and influential project
champion?
Strong and widespread organizational
management support?
Receptive / resistant system users?
Slide 45
Organizational Feasibility:
If We Build It, Will They Come?
Strategic alignment
Close alignment with strategy increases the
likelihood of success
Stakeholder groups can be influenced
Presentations describing and promoting
benefits
Emphasizing personal benefits as well as
organizational benefits
Prototypes help prove the system concept
Real user involvement throughout project
Slide 46
Feasibility Assessment:
Summing It Up
All projects have feasibility risks
Our goal is to know the risks we
face and the significance of those
risks
Project Sponsor, Project Manager,
and other team members need
thisawareness
Once risks are known, steps can
be taken to mitigate the risks
Slide 47
Feasibility Assessment:
Summing It Up
For example, if unfamiliar with a
new technology
Provide enough budget for training
Provide enough budget to hire
consultants with expertise
Allow more schedule time to move up
the learning curve
Use a methodology that incorporates
experimentation
Slide 48
Feasibility Assessment:
Summing It Up
Essential to continuously review and
revise the feasibility assessment
How well are we managing the
risks we previously identified?
Are adjustments needed?
 Risk is being managed

 Risk is not well managed and

needs further attention

Slide 49
Feasibility Assessment:
Summing It Up
Are there any new risks that
have appeared?
If so, what are the actions needed
to address those risks?
Budgetary and schedule effect?

Slide 50