Systems Analysis and Design

Chapter1: The Systems Analyst and

Information Systems Development

Dr. Rania Ramadan

Roberta Roth, Alan Dennis, and Barbara Haley Wixom

1-0
 ELE337 Systems Analysis and Design -
Course Information
• Course Description:
• Approaches to system development, Investigating System Requirements,
Modeling Systems Requirements, The Traditional Approach to
Requirements (DFD) , Context diagram, Data Dictionary, The Object-
oriented approach to requirements (UML), Use Case Diagram, Activity
Diagram, Sequence Diagram, State Diagram, Class diagram , Design the
application architecture, Design the user interface, Design the Database,
Design the system control, Deployment Environment, Three-layer
architecture, Internet and web-based application architecture.

• Book: Systems Analysis and Design, 7th edition

• Authors: Alan Dennis, Barbara Haley Wixom, Roberta M. Roth

• Total grade: 150

• Final Exam: 75
• Lab Exam (Project): 25
• Semester work including Mid-term Exam : 50
1-1
Chapter 1 Outline

• The systems analyst.

• The Systems Development Life Cycle (SDLC).

• Information system project identification and initiation.

• Feasibility analysis.

1-2
 INTRODUCTION
• 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.

• The key person in the SDLC is the systems analyst,

who analyzes the business situation, identifies the
opportunities for improvements, and designs an IS
to implement the improvements.

1-3
 THE SYSTEMS ANALYST
• The systems analyst plays a key role in IS development
projects.
• systems analyst works closely with all project team
members so that the team develops the right system in
an effective way.
• Systems analysts must understand how to apply
technology to solve problems.
• Systems analysts may serve as change agents who
identify organizational improvement needed, design
systems to implement those changes, and train and
motivate others to use the systems.
1-4
Systems Analyst Skills

• Technical – Must understand the technical environment,

technical foundation, and technical solution.
• Business – Must understand how IT can be applied to
business situations.
• Analytical – Must be problem solvers.

• Interpersonal – Need to communicate effectively.

• Management – Need to manage people and to manage

pressure and risks.

• Ethical - Must deal fairly, honestly, and ethically with other

project members, managers, and systems users.
1-5
Systems Analyst Roles

• System analyst - Focuses on the IS issues surrounding the

system.
• Business analyst - Focuses on the business issues
surrounding the system.
• Infrastructure analyst - Focuses on technical issues
• Change management analyst - Focuses on the people and
management issues surrounding the system installation.
• Project manager - Ensures that the project is completed on
time and within budget, and that the system delivers the
expected vale to the organization.
• Requirements Analyst- Focus on eliciting the requirements
from the stakeholders associated with the new system.

1-6
Career Paths for Systems Analysts

1-7
 THE SYSTEMS DEVELOPMENT LIFE CYCLE
(SDLC)

Each of the phases is composed of steps, which rely on techniques

that produce deliverables (specific documents that explain various
elements of the system).

1-8
Planning

• This phase is the fundamental process of understanding

why an information system should be built, and
determining how the project team will go about building
it.

1-9
The planning phase has two steps:

1. During project initiation, the system’s business value to

the organization is identified (How will it lower costs
or increase revenues?).

2. During 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.

1-10
Analysis

• 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.

• During this phase the project team investigates any

current system(s), identifies improvement opportunities,
and develops a concept for the new system.

1-11
 The analysis phase has three steps:
1. Analysis strategy: This is developed to guide the projects
team’s efforts. This includes a study of the current
system and its problems, and envisioning ways to design
a new system.

2. Requirements gathering: The analysis of this information

leads to the development of a concept for a new system.
This concept is used to build a set of analysis models.

3. System proposal: The proposal is presented to the project

sponsor and other key individuals who decide whether
the project should continue to move forward.

1-12
Design

• The design phase decides how the system will operate, in

terms of the hardware, software, and network
infrastructure; the user interface, forms, and reports that
will be used; and the specific programs, databases, and
files that will be needed.

1-13
The design phase has four steps:

1. Design Strategy: This clarifies whether the system will

be developed by the company or outside the
company.
2. Architecture Design: This describes the hardware,
software, and network infrastructure that will be
used.
3. Database and File Specifications: These documents
define what and where the data will be stored.
4. Program Design: Defines what programs need to be
written and what they will do.

1-14
Implementation

• During the implementation phase, the system is either

developed or purchased (in the case of packaged
software) and installed.

• This phase is usually the longest and most expensive part

of the process.

1-15
The implementation phase has three steps:

1. System Construction: The system is built and

tested to make sure it performs as designed.
2. Installation: The old system is turned off and
the new one is turned on.
3. Support Plan: Includes a formal or informal
post-implementation review as well as a
systematic way for identifying changes needed
for the system.

1-16
PROJECT IDENTIFICATION AND INITIATION

• A project is identified when someone in the

organization identifies a business need to build a
system.

• A need may surface when an organization

identifies unique and competitive ways of using IT.

• To leverage the capabilities of emerging

technologies such as cloud computing, RFID,
Web 2.0

1-17
Business Process Management (BPM)

• Nowadays many new IS projects grow out of

BPM.

• BPM is a methodology used by organizations to

continuously improve end-to-end business
processes.

1-18
BPM Process

• Defining and mapping the steps in a business process.

• Creating ways to improve on the steps in the process that

add value

• Finding ways to eliminate or consolidate steps in the

process that do not add value

• Creating and adjusting electronic workflows to match the

improved process maps.

1-19
 BPM Process
• Business process automation (BPA) – technology
components are used to complement or substitute manual
process.

• Business process improvement (BPI) – creating

new, re-designed processes to improve the workflows,
and/or utilizing new technologies enabling new process
structures.

• Business process reengineering (BPR) – changing

the fundamental way in which the organization operate.

1-20
Project sponsor

• The project sponsor is a person (or group) who has

an interest in the system’s success
• The project sponsor will work throughout the SDLC
to make sure that the project is moving in the right
direction from the perspective of the business.
• The project sponsor serves as the primary point of
contact for the project team.
• The size or scope of the project determines the
kind of sponsor that is involved.

1-21
Project sponsor

• The project sponsor has the insights needed to determine

the business value that will be gained from the system.

• Tangible value can be quantified and measured easily

(reduction in operating costs).

• An intangible value results from an intuitive belief that the

system provides important, but hard-to-measure benefits
to the organization.

1-22
 System Request
• The document that describes the business reasons
for building a system and the value that system is
expected to provide.

• The project sponsor usually completes this form as

part of a formal system selection process within
the organization.

• Business need presents reasons prompting the

project.

1-23
System Request

• The business requirements of the project refer to

the business capabilities that the system will
need to have.

• The business value describes the benefits that

the organization should expect from the system.

• Special issues are included on the document as

a catchall category for other information that
should be considered in assessing the project.

1-24
System Request

• The completed system request is submitted to

the approval committee for consideration.

• The committee reviews the system request and

makes an initial determination of whether to
investigate the proposed project or not.

• If so, the next step is to conduct a feasibility

analysis.

1-25
Elements of the system request form.

1-26
FEASIBILITY ANALYSIS

• Feasibility analysis guides the organization in

determining whether to proceed with a project.

• Feasibility analysis also identifies the important

risks associated with the project that must be
managed if the project is approved.

1-27
 FEASIBILITY ANALYSIS
• As with the system request, each organization has
its own process and format for the feasibility
analysis, but most include techniques to assess
three areas:
• Technical feasibility
• Economic feasibility
• Organizational feasibility
• The results of evaluating these three feasibility
factors are combined into a feasibility study
deliverable that is submitted to the approval
committee at the end of project initiation.

1-28
Feasibility analysis assessment factors

1-29
Technical Feasibility

• Technical feasibility is the extent to which the

system can be successfully designed,
developed, and installed by the IT group.

• It is, in essence, a technical risk analysis that

strives to answer the question: “Can we build it?”

1-30
Technical Feasibility

• Risks can endanger the successful completion of

a project. The following aspects should be
considered:
• Users’ and analysts’ should be familiar with the
application.
• Familiarity with the technology
• Project size
• Compatibility of the new system with the technology
that already exists

1-31
Economic Feasibility

• Economic feasibility analysis is also called a

cost-benefit analysis, that identifies the costs
and benefits associated with the system.

• This attempts to answer the question: “Should

we build the system?”

1-32
Economic Feasibility -
Cash Flow Analysis and Measures

• IT projects involve an initial investment that

produces a steam of benefits over time, along
with some on-going support costs.

• Cash flows, both inflows and outflows, are

estimated over some future period.

1-33
Economic Feasibility -
Simple cash flow projection

1-34
Economic Feasibility –
Common methods for evaluating a project’s worth

• Return on Investment (ROI)

• is a calculation that measures the average rate of

return earned on the money invested in the project.

• ROI=(Total Benefits – Total Costs)/Total Costs

• A high ROI suggests that the project’s benefits far

outweigh the project’s cost, although exactly what
constitutes a “high” ROI is unclear.

1-35
Economic Feasibility –
Common methods for evaluating a project’s worth

• Break-Even Point (BEP)

• the number of years it takes a firm to recover its original

investment in the project from net cash flows.

1-36
Economic Feasibility –
Common methods for evaluating a project’s worth

• Return on Investment (ROI)

• Break-Even Point (BEP)

1-37
Economic Feasibility –
Problems

• Return on Investment (ROI) & Break-Even Point (BEP) all

share the weakness of not recognizing the time value of
money.

• In these analyses, the timing of cash flows is ignored.

• A dollar in Year 3 of the project is considered to be exactly

equivalent to a dollar received in Year 1.

1-38
 Economic Feasibility –
Discounted cash flow technique
• Discounted cash flows are used to compare the
present value of all cash inflows and outflows for
the project in the today’s dollar terms.

• Where n is the year in which the cash flow occurs

• The rate of return represents the minimum rate of return an investor
expects to receive for taking on the risk of the investment. It reflects
the time value of money and the riskiness of the projected cash flows.

• Net present value (NPV): the difference between

the total PV of the benefits and the total PV of the
costs.
1-39
Economic Feasibility –
Discounted cash flow technique

1-40
Economic Feasibility –
Steps to conduct an economic feasibility analysis

1-41
Economic Feasibility –
Identify Costs and Benefits
• The costs and benefits and be broken down into
four categories:

1-42
Economic Feasibility –
Assign Values to Costs and Benefits
• Once the types of costs and benefits have been identified, the
systems analysts needs to assign specific dollar values to
them.

© Copyright 2011 John Wiley & Sons, Inc. 1-43

Economic Feasibility –
Determine Cash Flow

• A formal cost-benefit analysis usually contains costs and

benefits over a selected number or years to show cash
flow over time.

- Determine ROI

- Determine BEP

- Determine NPV

1-44
Economic Feasibility –
Determine Cash Flow

1-45
Organizational Feasibility

• Organizational feasibility of the system is how well

the system ultimately will be accepted by its users
and incorporated into the ongoing operations of the
organization.
• There are many organizational factors that can have
an impact on the project, and seasoned developers
know that organizational feasibility can be the most
difficult feasibility dimension to assess.
• In essence, an organizational feasibility analysis is to
answer the question “If we build it, will they come?”

1-46
 Organizational Feasibility
• One way to assess the organizational feasibility is
to understand how well the goals of the project
align with the business objectives and
organizational strategies.
• A second way to assess the organizational
feasibility is to conduct stakeholder analysis.
• A stakeholder is a person, group, or organization
that can affect a new system
- Project champion
- System users
- Organizational management
- Other stakeholders
1-47
 SUMMARY
• The Systems Analyst is the key person in the development of
information systems.
• The Systems Development Lifecycle consists of four stages:
Planning, Analysis, Design, and Implementation.
• Project Identification and Initiation recognize a business
need that can be satisfied through the use of information
technology.
• System Request describes the business value for an
information system.
• A Feasibility Analysis is used to provide more detail about
the risks associated with the proposed system.

1-48