Chapter 5

Systems Analysis

McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Objectives
• Define systems analysis and relate it to the scope
definition, problem analysis, requirements analysis,
logical design, and decision analysis phases.
• Describe a number of systems analysis approaches for
solving business system problems.
• Describe scope definition, problem analysis, requirements
analysis, logical design, and decision analysis phases in
terms of information system building blocks.
• Define system requirements and differentiate between functional
and nonfunctional requirements.
 What is Systems Analysis ?
Systems analysis – sebuah teknik pemecahan masalah yg
menguraikan suatu sistem menjadi bagian-bagian komponen dg
tujuan mempelajari seberapa baik bagian-bagian komponen
tersebut bekerja dan berinteraksi untuk meraih tujuannya

Systems design – teknik pemecahan masalah yg saling

melengkapi (dg analisis sistem) yg merangkai kembali bagian2
komponen menjadi sebuah sistem yg lengkap— harapannya,
sistem yg diperbaiki. Hal ini melibatkan penambahan,
penghapusan dan perubahan bagian2 relatif pd sistem
aslinya/awalnya.

Information systems analysis – fase-fase pengembangan

dalam proyek pengembangan SI yg difokuskan pd masalah dan
persyaratan2 bisnis, terpisah dr teknologi apapun yg dapat atau
akan digunakan utk mengimplementasikan solusi pd masalah tsb.

5-3
 Context of Systems Analysis

5-4
 Model-Driven Analysis Methods

Model-driven analysis – pendekatan

pemecahan masalah yang menekankan
gambar model sistem bergambar untuk
mendokumentasikan dan memvalidasi baik
yang ada dan / atau sistem yang diusulkan.
Pada akhirnya, model sistem menjadi ‘cetak
biru’ untuk merancang dan membangun sistem
diperbaiki.
Model – representasi dari realitas atau visi.
Karena "sebuah gambar bermakna ribuan
kata," kebanyakan model menggunakan
5-5 gambar untuk mewakili realitas atau visi.
 Model-Driven Approaches
• Traditional Approaches
• Structured Analysis
• Focuses on the flow of data through processes
• Key model: data flow diagram
• Information Engineering
• Focuses on structure of stored data
• Key model: entity relationship diagram
• Object-Oriented Approach
• integrates data and process concerns into objects
• Object – the encapsulation of the data (called properties) that
describes a discrete person, object, place, event, or thing, with
all the processes (called methods) that are allowed to use or
update the data and properties. The only way to access or
update the object’s data is to use the object’s predefined
processes.
• Unified Modeling Language (UML)
5-6
 A Simple Process Model

5-7
 A Simple Data Model

5-8
 A Simple Object Model

5-9
 Accelerated Systems Analysis
Accelerated systems analysis
menekankan pendekatan pembangunan
prototipe untuk lebih cepat
mengidentifikasi kebutuhan bisnis dan
pengguna untuk sistem yang baru.

prototype – a small-scale, incomplete,

but working sample of a desired system.
• Accelerated systems analysis approaches
• Discovery Prototyping
• Rapid Architected Analysis
5-10
 Discovery Prototyping

Discovery prototyping – teknik yang

digunakan untuk mengidentifikasi kebutuhan
bisnis pengguna 'dengan dasar reaksi mereka
terhadap implementasi kebutuhan quick and
dirty

5-11
 Requirements Discovery

Requirements discovery – proses, yang

digunakan oleh analis sistem untuk
mengidentifikasi atau mengekstrak
masalah sistem dan kebutuhan solusi dari
komunitas user.

5-12
 Requirements Discovery
Methods
• Fact-finding – the process of collecting information
about system problems, opportunities, solution
requirements, and priorities.
• Sampling existing documentation, reports, forms, databases, etc
• Research of relevant literature
• Observation of the current system
• Questionnaires and surveys
• Interviews
• Joint requirements planning (JRP) –use of facilitated
workshops to bring together all of the system owners,
users, and analysts, and some systems designer and
builders to jointly perform systems analysis. .

5-13
 Business Process Redesign

Business process redesign (BPR) –

penerapan metode analisis sistem
untuk tujuan mengubah dan
memperbaiki proses bisnis dasar
organisasi secara dramatis, dan
independen dari teknologi informasi.

5-14
 Agile Methods
Agile method – integrasi dari berbagai
pendekatan analisis sistem dan desain untuk
aplikasi yang dianggap pantas untuk masalah
yang dipecahkan dan sistem yang sedang
dikembangkan.

5-15
 FAST:framework for the
application of system Thinking
• Metode hipotesis yang digunakan
untuk mendokumentasikan proses
pengembangan sistem (tahap
analisis)

5-16
 FAST:framework for the application of
system Thinking Systems Analysis
Phases
• Scope Definition Phase
• Is the project worth looking at?

• Problem Analysis Phase

• Is a new system worth building?

• Requirements Analysis Phase

• What do the users need and want from the new system?

• Logical Design Phase

• What must the new system do?

• Decision Analysis Phase

• What is the best solution?
5-17
 Context of Scope Definition
Phase

5-18
 Tasks for the Scope Definition
Phase

5-19
 Key Terms for Scope Definition
Phase
Steering body – a committee of executive business and
system managers that studies and prioritizes competing
project proposals to determine which projects will return
the most value to the organization and thus should be
approved for continues systems development.
• Also called a steering committee.

Project charter – the final deliverable for the preliminary

investigation phase. A project charter defines the project
scope, plan, methodology, standards, and so on.
• Preliminary master plan includes preliminary schedule and
resource assignments (also called a baseline plan).
• Detailed plan and schedule for completing the next phase of the
project.
5-20
 Sample Request for System
Services

5-21
 Sample Problem Statements

5-22
 Context of Problem Analysis
Phase

5-23
 Tasks of the Problem Analysis
Phase

5-24
 Key Terms of the
Problem Analysis Phase
Cause-and-effect analysis – teknik dimana
permasalahan dipelajari untuk menentukan sebab
akibat

Context Diagram – model bergambar yang

menunjukkan bagaimana sistem berinteraksi
dengan dunia di sekitarnya dan secara umum
menentukan masukan sistem dan keluaran.

5-25
 Sample Cause-and-Effect Analysis

5-26
 Sample Context Diagram

5-27
 Key Terms of the
Problem Analysis Phase (cont.)
Objective – a measure of success. It is something that you
expect to achieve, if given sufficient resources.
• Reduce the number of uncollectible customer accounts by 50 percent
within the next year.
• Increase by 25 percent the number of loan applications that can be
processed during an eight-hour shift.
• Decrease by 50 percent the time required to reschedule a production
lot when a workstation malfunctions.

Constraint – something that will limit your flexibility in

defining a solution to your objectives. Essentially, constraints
cannot be changed.
• The new system must be operational by April 15.
• The new system cannot cost more than $350,000.
• The new system must be web-enabled.
• The new system must bill customers every 15 days.
5-28
 Context of Requirements
Analysis Phase

5-29
 Requirements Analysis Phase Tasks

5-30
 Key Terms of
Requirements Analysis Phase
Functional requirement – a description
of activities and services a system must
provide.
• inputs, outputs, processes, stored data

Nonfunctional requirement – a
description of other features,
characteristics, and constraints that
define a satisfactory system.
• Performance, ease of learning and use, budgets,
deadlines, documentation, security, internal
auditing controls
5-31
Masalah yg mungkin terjadi

• Sulit mengantisipasi efek dari sistem baru

terhadap organisasi
• Beda user, beda pula requirement dan
prioritasnya – terpengaruh cara atau gaya kerja
• End-user sistem, dan organisasi yang
membiayai sistem berbeda requirement
• Prototype sering dibutuhkan untuk menjelaskan
requirement
• Masalah perbedaan bahasa alami

32
Definitions and specifications
User requir ement definition

1. The softw are m ust pr ovide a means of representing and

1. accessin g e xtern al files cr ea ted b y oth er tools .

Sy stem requir ements specification

1.1 The user should be pr ovided with facilities to d efine the type of
1.2 external files .
1.2 Each e xtern al file type ma y have an associa ted tool w hich ma y be
1.2 applied to the file .
1.3 Each e xtern al file type ma y be r epr esented as a sp ecific icon on
1.2 the user’ s disp la y.
1.4 Facilities should be pr o vided f or the icon r epresenting an
1.2 extern al file type to be defined b y the user .
1.5 Wh en a user selects an ico n r epr esenting an e xtern al file , the
1.2 effect of that selection is to apply th e too l asso ciated with th e typ e of
1.2 the ex ternal file to the file represented b y the selected icon .
Functional or Non Functional ?
• Contoh dalam kasus peminjaman buku di
perpustakaan:
• Pengguna bisa mencari semua informasi tentang
buku atau bisa memilih salah satu dari informasi
tentang buku
• Semua peminjam memiliki pengenal yang unik
• Sistem mampu mencatat transaksi peminjaman,
pengembalian dan denda secara lengkap
• Hari libur bisa di-set sejak awal, dan bisa
menerima perubahan dengan otoritas khusus ·
• Proses tidak boleh lebih dari 5 menit

34
 Context of Logical Design
Phase of Systems Analysis

5-35
 Tasks for Logical Design Phase

5-36
 Tasks for Decision Analysis Phase

5-37
 Key Terms of Decision Analysis
Phase
• Technical feasibility – Is the solution technically
practical? Does our staff have the technical expertise to
design and build this solution?

• Operational feasibility – Will the solution fulfill the

users’ requirements? To what degree? How will the
solution change the users’ work environment? How do
users feel about such a solution?

• Economic feasibility – Is the solution cost-effective?

• Schedule feasibility – Can the solution be designed

and implemented within an acceptable time period?
5-38
 Candidate Systems Matrix

5-39
 Candidate Systems Matrix
(cont.)

5-40
 Feasibility Matrix

5-41
Cost-Benefit Analysis
Techniques
Costs:
• Development costs are one time costs that will not recur
after the project has been completed.
• Operating costs are costs that tend to recur throughout
the lifetime of the system. Such costs can be classified
as:
• Fixed costs — occur at regular intervals but at
relatively fixed rates.
• Variable costs — occur in proportion to some usage
factor.
Benefits:
• Tangible benefits are those that can be easily quantified.
• Intangible benefits are those benefits believed to be
Costs for a Proposed Systems Solution
Three Popular Techniques to Assess
Economic Feasibility

• Payback Analysis
• Return On Investment
• Net Present Value
The Time Value of Money is a concept that should be
applied to each technique. The time value of money
recognizes that a dollar today is worth more than a dollar
one year from now.
Payback Analysis
Payback analysis – a technique for
determining if and when an investment will
pay for itself.

Payback period – the period of time that

will lapse before accrued benefits overtake
accrued and continuing costs.
Present Value Formula
Present value – the current value of a
dollar at any time in the future.

PVn = 1/(1 + i)n

Where n is the number of years and i is the discount

rate.

Discount rate – a percentage similar to interest

rates that you earn on your savings.
In most cases the discount rate for a business is the
opportunity cost of being able to invest money in
Payback Analysis for a Project
 Return-on-Investment Analysis
(ROI)
Return-on-Investment (ROA) analysis – a
technique that compares the lifetime profitability of
alternative solutions.
The ROI for a solution or project is a
percentage rate that measures the
relationship between the amount the business
gets back from an investment and the amount
invested.
Lifetime ROI = (estimated lifetime benefits –
estimated lifetime costs) / estimated
lifetime costs
Net Present Value (NPV)
Analysis
Net present value – an analysis technique that
compares the annual discounted costs and
benefits of alternative solutions.
 FACT-FINDING TECHNIQUES
FOR REQUIREMENTS
DISCOVERY

5-50
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
 Introduction to Requirements
Discovery
Requirements discovery – the process
and techniques used by systems analysts
to identify or extract system problems and
solution requirements from the user
community.

System requirement – something that

the information system must do or a
property that it must have. Also called a
business requirement.
6-52
 Results of Incorrect
Requirements
• Sistem dapat menggunakan biaya lebih dari yang
diproyeksikan.
• Sistem ini dapat disampaikan lebih dari yang dijanjikan.
• Sistem mungkin tidak memenuhi harapan para pengguna
dan mereka mungkin tidak menggunakannya.
• Setelah di produksi, biaya pemeliharaan dan meningkatkan
sistem mungkin terlalu tinggi.
• Sistem ini tidak dapat diandalkan dan rentan terhadap
kesalahan dan gangguan
• Reputasi staf TI ini ternoda sebagai kegagalan akan
dianggap sebagai kesalahan oleh tim.

6-53
 Criteria for System
Requirements
• Consistent – not conflicting or ambiguous.
• Complete – describe all possible system
inputs and responses.
• Feasible – can be satisfied based on the
available resources and constraints.
• Required – truly needed and fulfill the purpose
of the system.
• Accurate – stated correctly.
• Traceable – directly map to functions and
features of system.
• Verifiable – defined so can be demonstrated
6-54 during testing.
 Requirements Discovery
• Given an understand of problems, the systems
analyst can start to define requirements.

Fact-finding – the formal process of using

research, meetings, interviews, questionnaires,
sampling, and other techniques to collect
information about system problems,
requirements, and preferences. It is also called
information gathering or data collection.

6-55
 Seven Fact-Finding Methods

• Sampling of existing documentation,

forms, and databases.
• Research and site visits.
• Observation of the work environment.
• Questionnaires.
• Interviews.
• Prototyping.
• Joint requirements planning (JRP).
6-56
 Observation
Advantages Disadvantages
• Data gathered can be • People may perform
very reliable differently when being
• Can see exactly what is observed
being done in complex • Work observed may
tasks not be representative of
• Relatively inexpensive normal conditions
compared with other • Timing can be
techniques inconvenient
• Can do work • Interruptions
measurements • Some tasks not always
performed the same
way
• May observe wrong
6-57 way of doing things
 Questionnaires
Advantages Disadvantages
• Often can be answered • Return rate is often low
quickly • No guarantee that an
• People can complete at individual will answer
their convenience all questions
• Relatively inexpensive • No opportunity to
way to gather data from reword or explain
a large number misunderstood
• Allow for anonymity questions
• Responses can be • Cannot observe body
tabulated quickly language
• Difficult to prepare
6-58
 Interviews
Advantages Disadvantages
• Give analyst opportunity • Time-consuming
to motivate interviewee • Success highly
to respond freely and dependent on analyst's
openly human relations skills
• Allow analyst to probe • May be impractical due
for more feedback to location of
• Permit analyst to adapt interviewees
or reword questions for
each individual
• Can observe nonverbal
communication
6-59