SYSTEM ANALYSIS AND DESIGN

INTRODUCTION
Building a software is similar with building a house…

But why do we need to build new IT systems?

Here are a few other examples of IT systems:
 Banks - customer record systems, systems for ATM machines, systems for approving or rejecting
mortgage applications
 Hospitals - pharmacy systems for keeping track of drugs and creating printed prescriptions,
appointment systems for outpatients
 Government - online tax payment system, online census information
 Supermarkets - stock control systems, payroll systems

A new IT system may be commissioned for a number of reasons:

- The current one is out of date and no longer doing its job effectively
- Technology might have moved on and new things are possible that couldn't be done with the
previous system
- A competitor has developed a new system or process and the organization needs something
similar in order to offer the same service to customers
- The organization has grown and the current system can't cope with the increased demands placed
on it. Perhaps the company had only a few customers to start with but now it needs to be able to
deal with hundreds of accounts.
- A new part of the company needs IT support e.g. a new customer service help desk.
- The company might want to improve the quality of a repetitive task. Doing the same thing over
and over is very tiring and tedious for a person. A robotic system may be able to help with this.
For instance the car industry makes heavy use of robots in their factories.

This reasons takes some changes. And change is risk. Managing any change that involves IT systems is
particularly risky!

A survey of over 14,000 organizations showed that where new IT systems were being developed (by OASIG
1995 study)
 80-90% of systems fail to meet performance goals
 80% of systems are late and over budget
 40% of systems fail or are abandoned
 Just 10-20% of businesses meet all their success criteria.

Only a small minority of the IT projects in the survey were successful.

As people have learnt from past mistakes, a model has been developed and refined over the years to try
and maximize the chances of a successful project.

This method / model is called the SYSTEMS LIFE CYCLE.

qR1st1nah 1
 SYSTEM ANALYSIS AND DESIGN
SYSTEM DEVELOPMENT LIFE CYCLE

The Systems Development Life Cycle

Building an information system using the SDLC follows a similar set of four fundamental phases:
- Planning - Design,
- Analysis - and Implementation

Each phase is itself composed of a series of steps, which rely on techniques that produce deliverables
(specific documents and files that explain various elements of the system).

PLANNING
The very first part of the SLC is to define the problem.

The system analyst must determine why a new system is required.

After all, if there isn't a problem to start with, why would an organization incur huge costs to develop a
new one?

In the definition stage the role of the analyst is to scope out the problem.

The analyst has a number of methods available to do this:

 Interviews with management to get their viewpoint
 Interviews with staff to understand the limitations of the current system

The planning 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.

It 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? Most ideas for new systems come from outside the IS area
(from the marketing department, accounting department, etc.) in the form of a system request.
A system request presents a brief summary of a business need, and it explains how a system that
supports the need will create business value. The IS department works together with the person
or department generating the request (called the project sponsor) to conduct a feasibility analysis.
The feasibility analysis examines key aspects of the proposed project:
 The technical feasibility (Can we build it?)
 The economic feasibility (Will it provide business value?)
 The organizational feasibility (If we build it, will it be used?)

qR1st1nah 2
 SYSTEM ANALYSIS AND DESIGN
Table1.0: Systems Development Life Cycle Phases
PHASE STEP TECHNIQUE DELIVERABLE
Planning Identify opportunity Project identification System request
Focus: Analyze feasibility Technical feasibility
Feasibility study
- Why build this system? Economic feasibility
- How to structure the Organizational feasibility
project? Develop work plan Time estimation Project plan
Primary outputs: Task identification — work plan
- System Request with Work breakdown structure
feasibility study PERT Chart
- Project plan Gantt Chart
Scope management
Staff project Project staffing — Staffing plan
Project charter
Control and direct project CASE repository — Standards list
Standards — Risk assessment
Documentation
Timeboxing
Risk management
Analysis Develop analysis strategy Business process automation System proposal
Focus: Business process
improvement
- Who, what, where, and
Business process
when for this system?
reengineering
Primary output: Determine business Interview — Requirements definition
- System proposal requirements JAD session
Questionnaire
Document analysis
Observation
Create use cases Use case analysis — Use cases
Model processes Data flow diagramming — Process models
Model data Entity relationship modeling — Data model
Normalization
Design Design physical system Design strategy Alternative matrix
Focus: System specification
- How will this system Design architecture Architecture design — Architecture report
work? Hardware & software selection — Hardware & software
specification
Primary output: Design interface Use scenario — Interface design
- System specification Interface structure
Interface standards
Interface prototype
Interface evaluation
Design programs Data flow diagramming — Physical process model
Program structure chart — Program design
Program specification
Design databases and files Data format selection — Database & file
Entity relationship modeling specification
Denormalization — Physical data model
Performance tuning
Size estimation
Implementation Construct system Programming Test plan
Focus: Software testing Programs
- delivery and support of Performance testing Documentation
completed system Migration plan
Primary output: Install system Conversion strategy selection — Conversion plan
- Installed System — Business contingency
plan
Training — Training plan
Maintain system Support selection Support plan
System maintenance Problem report
Project assessment Change request
Post-implementation Post-implementation audit Post-implementation audit
report

qR1st1nah 3
 SYSTEM ANALYSIS AND DESIGN
The system request and feasibility analysis are presented to an information systems approval
committee (sometimes called a steering committee), which decides whether the project should
be undertaken.

2. Once the project is approved, it enters project management. 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. The deliverable for project
management is a project plan that describes how the project team will go about developing the
system.

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 steps:

1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually
includes a study of the current system (called the as-is system) and its problems, and envisioning
ways to design a new system (called the to-be system).
2. The next step is requirements gathering (e.g., through interviews, group workshops, or
questionnaires). The analysis of this information—in conjunction with input from the project
sponsor and many other people—leads to the development of a concept for a new system. The
system concept is then used as a basis to develop a set of business analysis models that describes
how the business will operate if the new system were developed. The set typically includes models
that represent the data and processes necessary to support the underlying business process.
3. The analyses, system concept, and models are combined into a document called the system
proposal, which is 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. The system proposal is the initial deliverable that describes what business requirements
the new system should meet. Because it is really the first step in the design of the new system,
some experts argue that it is inappropriate to use the term analysis as the name for this phase;
some argue a better name would be analysis and initial design.

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. Although most of the strategic decisions about the
system are made in the development of the system concept during the analysis phase, the steps in the
design phase determine exactly how the system will operate.
The design phase has four steps:
1. The design strategy must be determined. This clarifies whether the system will be developed by
the company’s own programmers, whether its development will be outsourced to another firm
(usually a consulting firm), or whether the company will buy an existing software package.
2. This leads to the development of the basic architecture design for the system that describes the
hardware, software, and network infrastructure that will be used. In most cases, the system will

qR1st1nah 4
 SYSTEM ANALYSIS AND DESIGN
add to or change the infrastructure that already exists in the organization. The interface design
specifies how the users will move through the system (e.g., by navigation methods such as menus
and on-screen buttons) and the forms and reports that the system will use.
3. The database and file specifications are developed. These define exactly what data will be stored
and where they will be stored.
4. The analyst team develops the program design, which defines the programs that need to be
written and exactly what each program will do.

This collection of deliverables (architecture design, interface design, database and file specifications, and
program design) is the system specification that is used by the programming team for implementation. At
the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and
another decision is made by the project sponsor and approval committee about whether to terminate the
project or continue.

IMPLEMENTATION
The final phase in the SDLC is the implementation phase, during which the system is actually built (or
purchased, in the case of a packaged software design and installed). This is the phase that usually gets the
most attention, because for most systems it is the longest and most expensive single part of the
development process.

This phase has three steps:

1. System construction is the first step. The system is built and tested to ensure that it performs as
designed. Since the cost of fixing bugs can be immense, testing is one of the most critical steps in
implementation. Most organizations spend more time and attention on testing than on writing the
programs in the first place.
2. The system is installed. Installation is the process by which the old system is turned off and the new
one is turned on. There are several approaches that may be used to convert from the old to the new
system. One of the most important aspects of conversion is the training plan, used to teach users how to
use the new system and help manage the changes caused by the new system.
3. The analyst team establishes a support plan for the system. This 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.

qR1st1nah 5