1

Introduction To
System Analysis and
Design
 2
What Is An Information System?

 An information system is a collection of

interrelated components that collect, process and
store, and provide as output the information
needed to complete a business task.
 3
Examples of Information
Systems

• Course registration system

• Online order system
• Online banking system
 4
What Is System Analysis About?

• Understanding the goals and strategies of the

business.
• Defining the information requirements that
support those goals and strategies.
• It is not about programming.
 5
System Analysis vs. System
Design
 System Analysis:
 Investigationof the problem and
requirement rather than solution.

 System Design:
 A conceptual solution that fulfills the
requirements, rather than implementation.
 6
System Analyst

 A business professional who uses

analysis and design techniques to solve
business problems using information
technology.
 7
The Role of a System Analyst

• Business knowledge.
• Business problem solver.
• Help translate business requirements
into IT projects.
Traditional System Development8
Life Cycle (SDLC)
 Traditional System Development life 9
Cycle (SDLC)

• Project planning – initiate, ensure feasibility, plan schedule,

obtain approval for project
• Analysis – understand business needs and processing
requirements
• Design – define solution system based on requirements and
analysis decisions
• Implementation – construct, test, train users, and install new
system
• Support – keep system running and improve it
 1 - 10

 Each of the phases include a set of

steps, which rely on techniques that
produce specific deliverables that
provide understanding about the
project.
 1 - 11

 To Understand the SDLC:

 Each phase consists of steps that lead to
specific deliverables
 The system evolves through gradual refinement
 1 - 12

Planning
 This phase is the fundamental process of
understanding why an information system should
be built.
 The Planning phase will also determine how the
project team will go about building the information
system.
 The Planning phase is composed of two planning
steps.
 1 - 13

Planning
1. During project initiation, the system’s
business value to the organization is
identified (How will it lower costs or increase
revenues?) as well as the feasibility of the
project from different point of views

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 - 14

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.
 This phase has three analysis steps.
 1 - 15

Analysis

1. Analysis strategy: This is developed to

guide the projects team’s efforts. This
includes an analysis of the current 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 - 16

Analysis
 The system proposal is the initial
deliverable that describes what business
requirements the new system should
meet.
 The deliverable from this phase is both an
analysis and a high-level initial design for
the new system.
 1 - 17

Design
 In this phases it is decided 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 - 18

Design

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.
UI Design
 1 - 19

Implementation
During this phase, the system is
either developed or purchased (in
the case of packaged software).
This phase is usually the longest
and most expensive part of the
process.
The phase has three steps.
 1 - 20

Implementation
 System Construction: The
system is built and tested to make
sure it performs as designed.
 Installation: Prepare to support
the installed system.
 Support Plan: Includes a post-
implementation review.
Category I of the System Development
Methodology: 1 - 21

Structured Design

 Structured design methodologies

adopt a formal step-by-step approach
to the SDLC that moves logically from
one phase to the next.

 This design methodology introduces

the use of formal modeling or
diagramming techniques to describe
business processes (process models)
and data (data models).
 Category I of the System Development 1 - 22

Methodology: Waterfall Development

 With waterfall development- based methodologies, the

analysts and users proceed sequentially from one phase
to the next.
 The two key advantages of waterfall development-based
methodologies are:

- The system requirements are identified long before

programming begins.
- Changes to the requirements are minimized as the
project proceeds.
 Waterfall 1 - 23

Development
 The two key disadvantages of waterfall
development-based methodologies are:
- The design must be completely
specified before programming begins.
- A long time elapses between the
completion of the system proposal in
the analysis phase and the delivery of
the system.
Waterfall Development-based
1 - 24

Methodology
 1 - 25

Parallel Development
 This methodology attempts to
address the long time interval
between the analysis phase
and the delivery of the system.
 Additional work:
Project division
Integration at the end.
 1 - 26

A general analysis/design for the entire system is performed and then the project is divided into a series of distinct subprojects.
 Rapid Application 1 - 27

Development (RAD)
 RAD-based methodologies adjust the
SDLC phases to get some part of
system developed quickly and into the
hands of the users.
 Most RAD-based methodologies
recommend that analysts use special
techniques and computer tools to speed
up the analysis, design, and
implementation phases, such as CASE
(computer-aided software engineering)
tools.
 RAD: Phased 1 - 28

Development
 This methodology breaks the overall system
into a series of versions that are developed
sequentially.
 The team categorizes the requirements into a
series of versions, then the most important and
fundamental requirements are bundled into the
first version of the system.
 The analysis phase then leads into design and
implementation; however, only with the set of
requirements identified for version 1.
 As each version is completed, the team begins
work on a new version.
Phased Development-based Methodology
1 - 29
 RAD 1 - 30

One possible problem with

RAD-based methodologies
is managing user
expectations.
 1 - 31

RAD: Prototyping
 Prototyping-based methodologies perform
the analysis, design and implementation
phases concurrently.
 All three phases are performed repeatedly
in a cycle until the system is completed.
 A prototype is a smaller version of the
system with a minimal amount of features.
 1 - 32
Prototyping-based
Methodology
 1 - 33

RAD: Prototyping
 Advantage: Provides a system for the
users to interact with, even if it is not
initially ready for use. The user can give
feedback.
 Disadvantages:
 Manage user expectations.
 Forget some important points since we are
prototyping (opposite of careful design)
 1 - 34
Agile Development

 This category focuses on streamlining

the SDLC by eliminating much of the
modeling and documentation overhead
and the time spent on those tasks.
 Projects emphasize simple, iterative
application development.
 This category uses extreme
programming, which is described next.
 Extreme 1 - 35

Programming (XP)
Extreme Programming
(XP) was founded on four
core values:
 Communication
 Simplicity
 Feedback
 Courage
 Extreme 1 - 36

Programming (XP)
Key principles of XP include:
 Continuous testing
 Simple coding
 Close interaction with the end users to build systems
very quickly
 1 - 37

An Extreme Programming-based Methodology

 1 - 38

Selecting the Appropriate Development Methodology

 Selecting a methodology is not simple,

as no one methodology is always best.
 Many organizations have their own
standards.
 The next figure summarizes some
important methodology selection
criteria.
 1 - 39

Selection criteria
 Clarity of requirements
 Familiarity with technology
 System complexity
 System reliability
 Short time schedule
 Schedule visibility
 Others
 Clarity of User
1 - 40

Requirements
RAD methodologies of
prototyping is usually more
appropriate when user
requirements are unclear as
they provide prototypes for
users to interact with early in
the SDLC.
Familiarity with
1 - 41

Technology
If the system is designed
without some familiarity
with the base technology,
risks increase because the
tools may not be capable
of doing what is needed.
 1 - 42

System Complexity

 Complex systems require careful

and detailed analysis and design.
 Project teams who follow phased
development-based methodologies
tend to devote less attention to the
analysis of the complete problem
domain than they might if they
were using other methodologies.
 1 - 43

System Reliability

 Systemreliability is usually an
important factor in system
development.
 1 - 44

Short Time Schedules

 RAD-based methodologies are well

suited for projects with short time
schedules as they increase speed.
 Waterfall-based methodologies are
the worst choice when time is
essential as they do not allow for
easy schedule changes.
 1 - 45

Schedule Visibility

 RAD-based methodologies
move many of the critical
design decisions earlier in the
project; consequently, this helps
project managers recognize
and address risk factors and
keep expectations high.
Selecting a 1 - 46

Methodology
 47
Two Approaches to System Development

 Traditional (Structured) approach

 Also called structured system development
 Structured analysis and design technique (SADT)
 Includes information engineering (IE)

 Object-oriented approach
 Also called OOA, OOD, and OOP
 Views information system as collection of interacting objects
that work together to accomplish tasks
 Object-Oriented 48

Approach
• Completely different approach to information systems
• Views information system as collection of interacting objects
that work together to accomplish tasks

 Objects – things in computer system that can respond to messages

 Conceptually, no processes, programs, data entities, or files are defined –
just objects

• OO languages: Java, C++, C# .NET, VB .NET

 Unified Modeling 49


Language (UML)
UML (Unified Modeling Language) is a graphical
language that is suit-able to express software or system
requirements, architecture, and design.
 UML used for both database and software modeling
 UML modeling also supports multiple views of the
same system.
 UML diagrams
50
Can be categorized as the fallowing:
 Structural diagrams:
Show the building blocks of your system—features that don’t
change with time.
Ex: Class diagram
 Behavioral diagrams:
Show how your system responds to requests or otherwise evolves
over time.
Ex: Use case diagram
 Interaction diagrams:
Is a type of behavioral diagram.
To depict the exchange of messages within a collaboration (a group
of cooperating objects).
Ex: Sequence diagram & Collaboration diagram
 51
UML Diagrams
 Another way of categorizing UML diagram:

1. Static diagrams
 to show the static features of the system. (no change)
2. Dynamic diagrams
 to show how your system evolves over time.
3. Functional diagrams:
 to show the details of behaviors and algorithms.
Object-oriented analysis (OOA) 52
 Trying to figure out what the users and customers
of a software effort want the System to do.
 Builds a “real-world” model from requirements
 client interviews, domain knowledge, real-
world experience collected in use cases and
other simple notations
 OOA models address three aspects of the system
(its objects)
 class structure and relationships
 sequencing of interactions and events
 data transformations and computations