System Analysis and

Design:

Dr. Murtala Aminu Ibrahim

 System Analysis
Systems Analysis defines the problems to be
solved and provides the architecture of the
proposed system.
System a set of things working together as parts
of a mechanism or an interconnecting network;
to form a coherent whole.
Analysis is defined as the procedure by which we
break down an intellectual or substantial whole
into parts.
System Analysis
n System analysis is an explicit formal inquiry
carried out to help a decision maker identify a
better course of action and make a better decision
than he might otherwise have made.
n Systems analysis is a problem-solving technique
that decomposes a system into its component
pieces for the purpose of studying how well those
component parts work and interact to accomplish
their purpose.
System Analysis
n This is a process used in the design of new
systems. Systems analysis follows stages of
investigation, design and implementation.
n Each stage should involve close
consultation with potential users, in the
various functional areas of the organization,
to ensure that their information and
operational requirements are met.
 THE SYSTEMS ANALYST
n The systems analyst plays a key role in IS development
projects.
n The systems analyst works closely with all managers and
team members so that the team develops the right system
in an effective way.
n Systems analysts must understand how to apply
technology in order to solve problems.
n 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.
Systems Analyst Skills

nTechnical – Must understand the

technical environment, technical
foundation, and technical solution.
nBusiness – Must understand how
IT can be applied to business
situations.
nAnalytical – Must be problem
solvers.
 (cont’d)

n Interpersonal – Need to communicate

effectively.
n Management – Need to manage people
and to manage pressure and risks.
n Ethical - Must deal fairly, honestly, and
ethically with other project members,
managers, and systems users.
When to use system analysis and design

nTo develop new system

nTo improve existing system
nTo correct problem in existing
system
nOutside group may mandate change
nCompetition can lead to change
Reasons for Good Systems

nImproved service
nBetter performance
nMore information
nStronger controls
nReduced cost
To Develop a System
n Scope Definition
Is the project worth looking at?
n Problem Analysis
Is a new system worth building?
n Requirements Analysis
What do the users need and want from the new system?
n Logical Design
What must the new system do?
n Decision Analysis
What is the best solution?
 SWOT Analysis for System
Possible IT Strengths
- Excellent Web design staff
- Low systems analyst turnover
- Recently upgraded network
Possible IT Opportunities
- Well-position for expansion
- Can be first with new software
- High potential for B2B growth
Possible IT Weaknesses
- Still using several legacy systems
- Budget increase was turned down
- Documentation needs updating
Possible IT Threats
- Aggressive new Web competition
- Impact of new government rules
- Other firms offer better benefits
System Analysis Techniques
Logical data modeling
This is the process of identifying, modeling and documenting the
data requirements of the system being designed. The data are
separated into entities (parts) (things about business needs)
and relationships (the associations between the parts).
Data Flow Modeling
This is the process of identifying, modeling and documenting how
data moves around an information system. Data Flow
Modeling examines processes (activities that transform data
from one form to another), data stores (the holding areas for
data), external entities (what sends data into a system or
receives data from a system), and data flows (routes by which
data can flow).
Entity Behavior Modeling
This is the process of identifying, modeling and documenting the
events that affect each entity and the sequence in which these
events occur.
Factors that affect systems projects

n Internal Factors n External Factors

n Strategic plan n Technology
n Top managers
n Supplier
n User requests
n Customers
n Information
technology n Technology
department n Competitors
n Existing systems
n The economy
n Government
 Systems Development Life Cycle

n 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.
n 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.
 Systems Development Life Cycle (SDLC)

n The SDLC in system analysis and

design aims to produce a high quality
system that meets or exceeds customer
expectations, reaches completion
within time and cost estimates, works
effectively and efficiently in the
current and planned Information
Technology infrastructure, and is
inexpensive to maintain and cost-
effective to enhance.
SDLC Participants
Systems Development Life Cycle (SDLC)
 Systems Development Life Cycle

Planning

Support and Analysis

Maintenance

Implementation Design

The SDLC is composed of five fundamental phases:

Systems Development Life Cycle
Phase 1. Planning
nThis 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.
Planning
ØReview project requests
ØPrioritize project requests
ØAllocate resources
ØIdentify project development team
ØIdentifying business value
ØAnalyze feasibility
ØDevelop work plan
ØStaff the project
ØControl and direct project
Why should we build this system?
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.
 Systems Development Life Cycle
Phase 2. Analysis
Ø Conduct preliminary investigation.
Ø Determine exact nature of problem or improvement and whether it is
worth pursuing.
Ø Findings are presented in feasibility report (feasibility study)
Ø Perform detailed analysis activities:
Ø Study current system
Ø Determine user requirements
Ø Recommend solution
Ø Analysis strategy
Ø Gathering business requirements
Ø Requirements definition
Ø Process modeling
Ø Data modeling
What should the system do for us?
Where and when will it be used?
Analysis
n 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.
n During this phase the project team
investigates any current system(s),
identifies improvement opportunities, and
develops a concept for the new system.
 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.
Systems Development Life Cycle
Phase 3. Design
nThe 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.
Design
Ø Assesses feasibility of each alternative solution
Ø How system will be developed
Ø Recommends the most feasible solution
Ø Design selection
Ø Architecture design
Ø Interface design
Ø Data storage design
Ø Program design
How will we build the system?
 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.
Systems Development Life Cycle
Phase 4. Implementation
nDuring the implementation phase,
the system is either developed or
purchased (in the case of packaged
software) and installed.
nThis phase is usually the longest
and most expensive part of the
process.
Implementation
Ø Construction
ü Program building - Develop programs
ü Install and test new system
ü Program and system testing
Ø Installation
ü Conversion strategy
ü Training plan
ü Convert to new system
ü Support plan

Build the system!

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 post-
implementation review as well as a
systematic way for identifying
changes needed for the system.
 Systems Development Life Cycle
Phase 5. Support and Maintenance

ØConduct post-implementation
system review
ØIdentify errors and
enhancements
ØMonitor system performance
Putting the SDLC Together
n Each phase consists of steps that lead to
specific deliverables
n The system evolves through gradual
refinement
n Once the system is implemented, it may go
back into a planning phase for its next
revision, a follow-on system, or
maintenance releases
Processes and Deliverables
Process Product

Planning Project Plan

Analysis System Proposal

Design System
Specification

Implementation New System and

Maintenance Plan
 Systems Development Life Cycle
Strengths Weaknesses
n Control. n Increased development time.
n Monitor large projects. n Increased development cost.
n Detailed steps. n Systems must be defined up
n Evaluate costs and front.
completion targets.
n Rigidity.
n Documentation.
n Hard to estimate costs,
n Well defined user input.
project overruns.
n Ease of maintenance.
n User input is sometimes
n Development and design
limited.
standards.
n Tolerates changes in MIS
staffing.
System Analysis Methodologies
n A methodology is a formalized approach of
developing a business system. SDLC provides the
guidelines for the steps or activities that need to be
performed to design and develop a systems; it
does not prescribe the method of performing the
phases or activities.
n A methodology provides a sequential approach of
traversing the activities or tasks of designing and
developing a system. There can be multiple
methodologies of developing a system; however,
there is only one systems development life cycle.
 Structured Design

Methodologies adopt a formal step-by-step approach to the SDLC that

moves logically from one phase to the next. Thess methodologies can
be divided into several types as described in the following:
n Structured Design
n Waterfall Development
n Parallel Development
n Rapid Application Development
n Phased
n Prototyping
n Throwaway Prototyping
n Agile Development
n extreme Programming
Structured Design 1

Waterfall Development
Waterfall
n A sequence of stages in which the output of each stage
becomes the input for the next.
n In the waterfall model, it is possible to rework earlier
stages in the light of experience gained at a later stage.
Each stage is signed off and the next stage is proceeded
with. However the end user is rarely involved in the
development stage, even though they may well be
involved in signing off.
n It is therefore critical that the analysts and the
programmers understand the end-users’ requirements.
n This can be quite difficult with the waterfall model.
Waterfall Benefits
n Misunderstandings are detected at early stages
n Identifies systems requirements long before
programming begins
n The user will notice any missing functions,
incomplete or inconsistent requirements.
n Minimizes changes to requirements as project
progresses.
n Can be built quickly to demonstrate systems
n It can be used for training before the system is
finished
Waterfall Shortcoming
n Design must be specified on paper before
programming begins
n Long time between system proposal and delivery of
new system
n The waterfall model has disadvantages, which can be
overcome using Prototyping, in which a model of the
system is developed in partnership with the end-user.
n The features are worked out with the end user using a
prototype, and the end user can have a considerable
input into the development of a project.
Structured Design 2

Parallel Development
 Parallel Development
n The parallel development methodology
attempts to address the problem of long
delays between the analysis phase and the
delivery of the system. Instead of doing
the design and analysis in sequence, it
performs a general design of the whole
system and then divides the project into a
series of distinct subprojects that can be
designed and implemented in parallel.
Parallel Development
This methodology attempts to address the long time interval
between the analysis phase and the delivery of the system.
n General design
n Divide project into subprojects that are designed and
implemented in parallel
n Final integration
Benefits
n Reduces Schedule Time
n Less Chance of rework
Shortcoming
n Still uses paper documents
n Sub-projects May Be Difficult to Integrate
 Rapid Application Development (RAD)
Utilizes prototyping to delay producing system design
until after user requirements are clear
n Phased development
Ø A series of versions developed sequentially

n Prototyping
Ø System prototyping

n Throw-away prototyping
Ø Design prototyping
Rapid Application Development 1

Phased Development
Phased Development
n The phased development methodology breaks the overall
system into a series of versions that are developed
sequentially. The analysis phase identifies the overall
system concept, and the project team, users, and system
sponsors then categorize the requirements into a series of
versions.

n The most important and fundamental requirements are

bundled into the first version of the system. The analysis
phase then leads into design and implementation, but only
with the set of requirements identified for version 1.
Phased Development
n Once version 1 is implemented, work
begins on version 2 and follows the steps,
and so on. Any additional requirement
identified during testing of the older version
is implemented in the next version.

n Phased development has the advantage of

quickly getting a useful system into the
hands of the users.
Rapid Application Development 2

System Prototyping
System Prototyping
n The prototyping methodology performs the
analysis, design, and implementation phases
concurrently, and all three phases are performed
repeatedly in a cycle until the system is completed.
n In this case, the users of the system are an active
participant of the system development process.
With the basic requirements from the users, a
quick analysis and design of the system is
performed, and a prototype of the system
containing main features of the requirements, are
developed.
System Prototyping
n The prototype is handed to the users for testing and
to provide comments; which are then reanalyzed
and redesigned, and a second prototype is
developed. The process continues in a cycle until
the users and developers agree to a final system.

n Prototyping methodology gives a system quickly to

the users’ hands, which they can visualize from the
very beginning instead of waiting at the end of the
system development.
System Prototyping

nA small-scale, incomplete, but

working sample of a desired
system.
nWorking model of proposed
system
nBuilding a scaled-down working
version of the system
 System Prototyping
Benefits
n Users are involved in design, they interact
with prototype very quickly
n Users can identify needed changes and refine
real requirements, it captures requirements in
concrete form
Shortcoming
n Tendency to do superficial analysis
n Initial design decisions may be poor
Rapid Application Development 3

Throwaway Prototyping
Throwaway Prototyping
n With 'throw-away' prototyping a small part of
the system is developed and then given to the
end user to try out and evaluate. The user
provides feedback which can quickly be
incorporated into the development of the main
system.
n The prototype is then discarded or thrown away.
The objective of throw-away prototyping is to
ensure that the system requirements are
validated and that they are clearly understood.
Throwaway Prototyping
n The throw-away prototype is NOT
considered part of the final system. It
is simply there to aid understanding
and reduce the risk of poorly defined
requirements. The full system is
being developed alongside the
prototypes and incorporates the
changes needed.
Throwaway Prototyping

Benefits
nRisks are minimized
nImportant issues are understood
before the real system is built
Shortcoming
nMay take longer than prototyping
Agile method

nThe integration of various

approaches of systems
analysis and design for
applications as deemed
appropriate to the problem
being solved and the system
being developed.
Agile Development

Extreme Programming
Agile
Benefits
n Fast delivery of results
n Works well in projects with undefined or
changing requirements
Shortcoming
n Requires discipline
n Works best in small projects
n Requires much user input
Selecting the Appropriate Methodology

nClear user requirements

nFamiliarity with technology
nComplexity of system
nReliability of system
nTime schedule
nSchedule visibility
 Selecting the Right Methodology
Usefulness Waterfall Parallel Phased Prototyping Throwaway Extreme
Prototyping Programming
for
Unclear user Poor Poor Good Excellent Excellent Excellent
requirements
Unfamiliar Poor Poor Good Poor Excellent Poor
technology
Complex Good Good Good Poor Excellent Poor
systems
Reliable Good Good Good Poor Excellent Good
systems
Short time Poor Good Excell Excellent Good Excellent
schedule ent

Schedule Poor Poor Excell Excellent Good Good

visibility ent
Systems Development Life Cycle
Feasibility Study
Measure of how suitable Operational
system development will feasibility

be to the company
The
four Schedule
Technical
(Time)
feasibility feasibility feasibility
tests

Economic
feasibility
(cost-
benefit
analysis)
FEASIBILITY ANALYSIS

nFeasibility analysis guides the

organization in determining
whether to proceed with the system
development.
nFeasibility analysis also identifies
the important risks associated with
the project that must be managed if
the project is approved.
 (cont’d)
n 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:
n Technical feasibility
n Economic feasibility
n Organizational feasibility
n 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.
Technical Feasibility

nTechnical feasibility is the extent

to which the system can be
successfully designed, developed,
and installed by the project team.
nIt is, in essence, a technical risk
analysis that strives to answer the
question: “Can we build it?”
(cont’d)
n Risks can endanger the successful
completion of a project. The following
aspects should be considered:
n Users’ and analysts’ should be familiar with the
application.
n Familiarity with the technology
n Project size
n Compatibility of the new system with the
technology that already exists
Economic Feasibility

nEconomic feasibility analysis is

also called a cost-benefit analysis,
that identifies the costs and
benefits associated with the
system.
nThis attempts to answer the
question: “Should we build the
system?”
Cash Flow Analysis and Measures

nIS projects involve an initial

investment that produces a steam
of benefits over time, along with
some on-going support costs.
n Cash flows, both inflows and
outflows, are estimated over some
future period.
Simple cash flow projection
Common methods for evaluating a
project’s worth
n Return on Investment (ROI)
ROI=(Total Benefits – Total Costs)/Total
Costs
n Break-Even Point (BEP)
 Discounted cash flow technique
n Discounted case flows are used to compare
the present value of all cash inflows and
outflows for the project in the today’s dollar
terms.

n Net present value (NPV): the difference

between the total PV of the benefits and the
total PV of the costs.
Discounted cash flow projection
 Steps to conduct an Economic
Feasibility Analysis
1. Identify Costs and Benefits
2. Assign Values to Costs and Benefits
3. Determine Cash Flow
4. Assess Project’s Economic Value
- ROI
- BEP
- NPV
Identify Costs and Benefits

nThe costs and benefits and be

broken down in to four categories:
nDevelopment costs
nOperational costs
nTangible benefits
nIntangible benefits
Organizational Feasibility
n 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.
n 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.
n In essence, an organizational feasibility analysis is
to answer the question “If we build it, will they
come?”
 (cont’d)
n 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.
n A second way to assess the organizational feasibility
is to conduct stakeholder analysis.
n A stakeholder is a person, group, or organization that
can affect a new system
- Project champion
- System users
- Organizational management
- Other stakeholders
n A broad range of skills is required, including
n Technical
n Business
n Analytical
n Interpersonal
n Management
n ethical
Thank you