CBAD2103 System Analysis and Design Capr14 (RS) (M) PDF

Faculty of Science and Technology
CBAD2103
System Analysis
and Design
Copyright © Open University Malaysia (OUM)

CBAD2103
SYSTEM ANALYSIS
AND DESIGN
Kamsuriah Ahmad
Maryati Mohd. Yusof
Zaihosnita Hood
Suhaila Zainuddin
Dr Shahrol Azman Mohd. Noah

Project Directors: Prof Dato’ Dr Mansor Fadzil
Assoc Prof Dr Norlia T. Goolamally
Open University Malaysia
Module Writers: Kamsuriah Ahmad

Maryati Mohd. Yusof
Zaihosnita Hood
Suhaila Zainuddin
Dr Shahrol Azman Mohd. Noah
Universiti Kebangsaan Malaysia
Translated & Revised: Mohd Zahari Awang
Moderator: Hazalina Hashim

Developed by: Centre for Instructional Design and Technology

First Edition, November 2008

Second Edition, April 2014 (rs)
Copyright © Open University Malaysia (OUM), April 2014, CBAD2103
All rights reserved. No part of this work may be reproduced in any form or by any means
without the written permission of the President, Open University Malaysia (OUM).

Table of Contents
Course Guide xi-xvi
Topic 1 Introduction to Information Systems 1

1.1 Modelling the Business Process 2
1.1.1 Business Profile, Model and Process 3
1.2 Information System Components 5
1.2.1 Hardware 6
1.2.2 Software 7
1.2.3 Data 8
1.2.4 Process 9
1.2.5 Human or People 9
1.3 Information System Categories 10
1.4 Users and Information 13
1.4.1 Top Managers 14
1.4.2 Middle Managers and Knowledge Workers 15
1.4.3 Supervisors and Team Leaders 15
1.4.4 Operational Employees 15
Summary 16
Key Terms 16
Topic 2 System Development Methodology 17

2.1 Methodology, Models, Tools and Techniques 18
2.1.1 Methodology 18
2.1.2 Models 19
2.1.3 Tools 21
2.1.4 Techniques 21
2.2 System Development Life Cycle 23
2.2.1 Phase 1: Initial Investigation 25
2.2.2 Phase 2: System Analysis 26
2.2.3 Phase 3: System Design 27
2.2.4 Phase 4: System Development and Implementation 28
2.2.5 Phase 5: System Support and Operation 28
2.3 Alternative Approaches to System Development 30
2.3.1 Waterfall Approach 30
2.3.2 Object-Oriented Analysis and Design Approach
(OOAD) 31
2.3.3 Rapid Application Development (RAD) 33
2.3.4 Agile Development 35

iv TABLE OF CONTENTS
2.4 Selecting the Appropriate Development Methodology 36

Summary 39
Key Terms 40
Topic 3 Managing a Project 41

3.1 Systems Analyst 42
3.2 Systems Analyst Roles 46
3.3 Project Management 48
3.3.1 Project 48
3.3.2 Project Management 50
3.4 System Request Factors 52
3.5 System Request Evaluation 53
3.5.1 Evaluation Committee 54
3.5.2 Feasibility Evaluation 54
3.6 Initial Investigation Phase 59
3.6.1 Initial Investigation Activities 59
Summary 65
Key Terms 66
Topic 4 Determination of System Requirements 67

4.1 Functional and Non-Functional Requirements 68
4.2 System Stakeholder 70
4.2.1 Users 72
4.2.2 System Owner 75
4.2.3 Technical Staff 75
4.3 Methods of Determining Requirements 76
4.3.1 Guidelines on Questions 77
4.3.2 Analysing Current Procedure and Documents 79
4.3.3 Interview 84
4.3.4 Questionnaires 91
4.3.5 Observation 95
4.3.6 Prototyping 95
4.3.7 Joint Application Design (JAD) 96
4.3.8 Business Process Re-engineering (BPR) 99
Summary 102
Key Terms 103

TABLE OF CONTENTS v
Topic 5 Process Modelling 104

5.1 Data Flow Diagram (DFD) 105
5.1.1 DFD Symbols 105
5.1.2 DFD Rules 109
5.1.3 Details of DFD 112
5.1.4 Guidelines on Drawing DFD 116
5.1.5 Example of DFD 118
5.2 Logical and Physical DFD 122
5.3 Documenting DFD Components 125
5.3.1 Process Description 125
5.3.2 Description of Data Flow 129
5.3.3 Description of Data Elements 130
5.3.4 Description of Data Store 131
Summary 131
Key Terms 132
Topic 6 System Design 133

6.1 Design Strategy 134
6.1.1 Custom Development 134
6.1.2 Application Package 135
6.1.3 Outsourcing 136
6.2 Choosing a Design Strategy 139
6.3 Developing a Design Plan 141
6.3.1 Alternatives Matrix 142
6.4 Moving from Logical to Physical Models 144
6.4.1 Physical Data Flow Diagram 144
Summary 146
Key Terms 146
Topic 7 Architecture Design 147

7.1 Architecture Design Elements 147
7.1.1 Architectural Components 148
7.2 Client-Server Architectures 149
7.2.1 Client-Server Tiers 150
7.3 Server-Based Architecture 153
7.4 Client-Based Architecture 154
7.5 Choosing the Architectures 155
7.6 Hardware and Software Specification 156
Summary 159
Key Terms 160

vi TABLE OF CONTENTS
Topic 8 User Interface Design 161

8.1 User Interface Design 161
8.2 Navigation Design 163
8.2.1 Principles 163
8.2.2 Types of Navigation Controls 164
8.3 Input Design 165
8.3.2 Types of Input 167
8.3.3 Screen Form 168
8.4 Output Design 170
8.4.2 Types of Output 171
8.4.3 Types of User Reports 175
Summary 176
Key Terms 177
Topic 9 System Development and Implementation 178

9.1 System Development and Implementation 179
9.1.1 Development Steps 180
9.2 Designing Programs 183
9.2.1 Structure Chart 184
9.2.2 Steps in Developing a Structure Chart 190
9.3 Testing 191
9.3.1 Unit Testing 192
9.3.2 Integration Testing 193
9.3.3 System Testing 193
9.4 Documentation 193
Summary 197
Key Terms 197
Topic 10 Transition to New System 198

10.1 Migration Plan 198
10.2 Installation 199
10.2.1 Direct Installation 200
10.2.2 Parallel Installation 201
10.2.3 Pilot Installation 202
10.2.4 Phase Installation 203
10.3 Training 204
10.3.1 Training Guide 206
10.3.2 Types of Training 207

TABLE OF CONTENTS vii
10.4 Data Conversion 209

10.5 Evaluation 211
Summary 214
Key Terms 215
Topic 11 System Support and Maintenance 216

11.1 System Support 217
11.2 System Maintenance 218
11.2.1 Corrective Maintenance 219
11.2.2 Adaptive Maintenance 220
11.2.3 Perfective Maintenance 220
11.2.4 Preventive Maintenance 221
11.3 Maintenance Requests 221
11.4 Maintenance Releases 223
11.5 System Obsolescence 224
11.6 Backup and Recovery 226
11.6.1 Backup Media 227
11.6.2 Backup Types 227
11.6.3 Retention Periods 227
Summary 228
Key Terms 229

TABLE OF CONTENTS

COURSE GUIDE

COURSE GUIDE DESCRIPTION
You must read this Course Guide carefully from the beginning to the end. It tells
you briefly what the course is about and how you can work your way through
the course material. It also suggests the amount of time you are likely to spend in
order to complete the course successfully. Please keep on referring to the Course
Guide as you go through the course material as it will help you to clarify
important study components or points that you might miss or overlook.
INTRODUCTION
CBAD2103 System Analysis and Design is one of the courses offered by the
Faculty of Information Technology and Multimedia Communication at Open
University Malaysia (OUM). This course is worth three credit hours and should
be covered over eight to 15 weeks.
COURSE AUDIENCE
This course is offered to all learners taking the Information Technology program.
This course introduces a systematic approaches or methodologies as a guideline
to analysing and designing a system. Learners in other specialisations too will
find this course interesting, because the field of systems analysis and design can
also be applied to various environments.
As an open and distance learner, you should be able to learn independently and
optimise the learning modes and environment available to you. Before you begin
this course, please ensure that you have the right course materials, understand
the course requirements, as well as know how the course is conducted.
STUDY SCHEDULE
It is a standard OUM practice that learners accumulate 40 study hours for every
credit hour. As such, for a three-credit hour course, you are expected to spend 120
study hours. Table 1 gives an estimation of how the 120 study hours could be
accumulated.

xii COURSE GUIDE
Table 1: Estimation of Time Accumulation of Study Hours
Study
Study Activities
Hours
Briefly go through the course content and participate in initial discussions 3
Study the module 60
Attend three to five tutorial sessions 10
Online participation 12
Revision 15
Assignment(s), Test(s) and Examination(s) 20
TOTAL STUDY HOURS 120
COURSE OUTCOMES
By the end of this course, you should be able to:
1. Explain the business process;
2. Identify information system components;
3. Describe system development methodology, tools and techniques;
4. Elaborate on system development life cycle;
5. Determine system requirement by fact-finding and process modelling; and
6. Summarise the system design, maintenance and support activities.
COURSE SYNOPSIS
This course is divided into 11 topics. The synopsis for each topic is presented
below:
Topic 1 describes the goal of systems analysis and design which is to improve
organisational systems. This topic addresses business modelling process,
information system components and categories. Types of users in information
systems are also explained.

COURSE GUIDE xiii
Topic 2 explains the methodology, model, tools and techniques that can be used
to develop information systems. Detailed explanations of system development
life cycle (SDLC) methodology with five main phases, each with certain objectives
and deliverables, are also presented. Finally, alternative approaches for system
development are discussed.
Topic 3 begins with discussion on the systems analystÊs role in managing a

system development project. This topic explains how a project begins, factors that
lead to information system request and how initial investigation is performed. At
the end of this topic, an investigation report is produced and presented to the
management, before moving into the next phase of development.
Topic 4 explains two of the most important skills in systems analysis which are
fact-finding, a function to identify system requirements, and business process
modelling based on the system requirements. In this topic, you will develop skills
in fact-finding and investigation. Finally a few methods of determining system
requirement are discussed.
Topic 5 focuses on the systemÊs process and its logical aspects. In this topic, you
will be briefed on process modelling – how information or facts that have been
obtained are arranged, manipulated and represented.
Topic 6 focuses on the system design phase. The initial part of the design phase
involves the logical diagrams of the analysis phase into the physical diagrams
that explain how the system will be built and all the documentation and
diagrams becoming the inputs to the steps of the design phase are discussed.
Topic 7 focuses on architecture design which involves four main functions: data
storage, data access logic, application logic and presentation logic. Depending on
the architecture, the four functions are performed on a server, on a client or
divided between the server and the client. This topic discusses server and client
characteristics and how each design alternative handles system functions.
Topic 8 describes user interface design in which the users interact. It includes the
screen displays that provide navigation through the system, the screens and
forms that capture data and the reports that the system produces (whether on
paper, on the Web or via some other media). This topic also introduces the basic
principles and processes of interface design and discusses how to design the
interface structure and standards.

xiv COURSE GUIDE
Topic 9 explains the development and implementation activities. Applications are

built through the development phase which has four components which are
design, coding, testing and documentation. Designing a program with structured
chart approach is presented in great detail in this topic. Finally this topic ends
with a detailed discussion of application testing and documentation.
Topic 10 revolves around activities involved in transitioning to a new system

which include installation, training and evaluation. The transition from the old
business processes and computer programs to the new business processes and
computer programs will be facilitated by ensuring that a number of business,
technical and people issues are addressed. This topic explains in detail a number
of ways to install the new system. The aspect of user training will be adequately
addressed in this topic because every new system requires some familiarisation
before it is fully accepted by users. This topic ends with data conversion issues
and system evaluation.
Topic 11 explains the system support and maintenance phase. Providing system
support means helping the users to use the system. Usually, this means providing
answers to questions and helping users understand how to perform a certain
function. System maintenance is the process of refining the system to make sure it
continues to meet business needs. Over a systemÊs lifetime, more money and
effort are devoted to system maintenance than to the initial development of the
system, simply because a system continues to change and evolve as it is used.
TEXT ARRANGEMENT GUIDE

Before you go through this module, it is important that you note the text
arrangement. Understanding the text arrangement will help you to organise your
study of this course in a more objective and effective way. Generally, the text
arrangement for each topic is as follows:
Learning Outcomes: This section refers to what you should achieve after you
have completely covered a topic. As you go through each topic, you should
frequently refer to these learning outcomes. By doing this, you can continuously
gauge your understanding of the topic.
Self-Check: This component of the module is inserted at strategic locations

throughout the module. It may be inserted after one sub-section or a few sub-
sections. It usually comes in the form of a question. When you come across this
component, try to reflect on what you have already learnt thus far. By attempting
to answer the question, you should be able to gauge how well you have

COURSE GUIDE xv
understood the sub-section(s). Most of the time, the answers to the questions can
be found directly from the module itself.
Activity: Like Self-Check, the Activity component is also placed at various locations
or junctures throughout the module. This component may require you to solve
questions, explore short case studies, or conduct an observation or research. It may
even require you to evaluate a given scenario. When you come across an Activity,
you should try to reflect on what you have gathered from the module and apply it
to real situations. You should, at the same time, engage yourself in higher order
thinking where you might be required to analyse, synthesise and evaluate instead
of only having to recall and define.
Summary: You will find this component at the end of each topic. This component
helps you to recap the whole topic. By going through the summary, you should
be able to gauge your knowledge retention level. Should you find points in the
summary that you do not fully understand, it would be a good idea for you to
revisit the details in the module.
Key Terms: This component can be found at the end of each topic. You should go
through this component to remind yourself of important terms or jargon used
throughout the module. Should you find terms here that you are not able to
explain, you should look for the terms in the module.
References: The References section is where a list of relevant and useful

textbooks, journals, articles, electronic contents or sources can be found. The list
can appear in a few locations such as in the Course Guide (at the References
section), at the end of every topic or at the back of the module. You are
encouraged to read or refer to the suggested sources to obtain the additional
information needed and to enhance your overall understanding of the course.
PRIOR KNOWLEDGE
Ideally, learners need to have basic knowledge of computer system and computer
programming before taking up this course.
ASSESSMENT METHOD
Please refer to myINSPIRE.

xvi COURSE GUIDE
REFERENCES
Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems analysis and design (5th
ed.). New York: John Wiley & Sons.
Hoffer, J. A., George, J. F., & Valacich, J. S. (2012). Systems analysis and design
(5th.). New Jersey: Prentice-Hall.
Kendall, K. E., & Kendall, J. E. (2011). Systems analysis and design (8th ed.). New
Jersey: Prentice Hall.
Mohamad, N. M., Safawi, A. R., & Kamarulariffin, A. J. (2001). Analisis & reka
bentuk sistem. Kuala Lumpur: McGraw Hill.
Satzinger, J. W., Jackson, R. B., & Burd S. D. (2002). Systems analysis and design
in a changing world (2nd ed.). Canada: Course Technology.
Shelly, G., & Rosenblatt, H. J. (2009). Systems analysis and design. New York:
Cengage Learning.
Whitten, J. L., Bentley L. D., & Dittman, K. C. (2001). Systems analysis and design
(5 th ed.). New York: McGraw-Hill.
TAN SRI DR ABDULLAH SANUSI (TSDAS) DIGITAL

LIBRARY
The TSDAS Digital Library has a wide range of print and online resources for the
use of its learners. This comprehensive digital library, which is accessible through
the OUM portal, provides access to more than 30 online databases comprising
e-journals, e-theses, e-books and more. Examples of databases available are
EBSCOhost, ProQuest, SpringerLink, Books24x7, InfoSci Books, Emerald
Management Plus and Ebrary Electronic Books. As an OUM learner, you are
encouraged to make full use of the resources available through this library.

Topic Introduction
1 to Information
Systems
LEARNING OUTCOMES
By the end of this topic, you should be able to:
1. Explain the importance of systems analysis and design and
information system;
2. Explain the business process modelling;
3. Identify five information system components;
4. Identify six main categories of information system; and
5. Differentiate four organisational levels in companies.
INTRODUCTION
Do you know that systems analysis and design is a step-by-step process for
developing high-quality information systems? The major goal of systems analysis
and design is to improve organisational systems. Often this process involves
developing or acquiring application software and training employees to use it.
Application software, also called a system, is designed to support a specific
organisational function or process, such as inventory management, payroll or
market analysis.
The goal of application software is to turn data into information. For example,
software developed for the inventory department at a bookstore may keep track
of the number of books in stock of the latest bestseller. Software for the payroll
department may keep track of the changing pay rates of employees. A variety of
off-the-shelf application software can be purchased, including WordPerfect,
Excel and PowerPoint.

2 TOPIC 1 INTRODUCTION TO INFORMATION SYSTEMS
However, off-the-shelf software may not fit the needs of a particular

organisation. Thus, the organisation must develop its own product.
Information system can be defined as a combination of information technology,

people and data. It supports business operations to increase productivity and
help managers make decisions. For example, information systems handle daily
business transactions, improve company productivity and help managers make
sound decisions. The information technology (IT) department team includes
systems analysts who plan, develop and maintain information systems. With
increasing demand for talented people, employment experts predict a shortage of
qualified applicants to fill IT positions.
1.1 MODELLING THE BUSINESS PROCESS

Many companies today use information as a basis to increase productivity,
produce quality products, provide quality services, create customer confidence
and make timely decisions.
As such, information technology has become the prime reason for the success
and failure of a company to compete in business.
This illustrates the impact of information technology on business operations

today. As a result, designing an information system of high quality is important
so that organisations can compete successfully in the global market.
Information systems experts need to understand the business operation of a

company before they can design a comprehensive system. Every business
situation is likely to be different. As an example, business transactions at a
supermarket, bank and hotel require information systems that are different and
unique.
A systems analyst applies a technique called business process modelling to

represent companyÊs operations and information requirements. A systems
analyst works in an information technology department. This person is
responsible for planning, analysing and implementing information systems.
ACTIVITY 1.1
In your opinion, what is the impact of information technology on the

operation of an educational institution like OUM?

TOPIC 1 INTRODUCTION TO INFORMATION SYSTEMS 3
1.1.1 Business Profile, Model and Process

In order to understand the operation of a certain company, a systems analyst
needs to develop a business profile and consider a number of business models.
There are two main responsibilities of the systems analyst as shown in the
following Figure 1.1.
Figure 1.1: General duties of a systems analyst
(a) Business Profile

A business profile is an overview of a companyÊs mission, functions,
organisation, products, services, customers, suppliers, competitors,
constraints and future direction. Although much of this information is
readily available, a systems analyst usually needs to do additional research
and fact-finding. A business profile is the starting point for the modelling
process.
(b) Business Models

A business process is a specific set of transactions, events and results that
can be described and documented. It is basically a way of doing business. A
business process model graphically displays one or more business
processes, such as handling an airline reservation, filling a product order or
updating a customer account. Figure 1.2 illustrates an example of a
business process which is for student registration.

Figure 1.2: Student registration's business process
The business process in Figure 1.2 has a beginning and an end, three sub-
processes and a result. When a company tries to simplify operations or tries to
decrease operational cost or increase value to customers, the company is said to
be involved in business process re-engineering (BPR).
SELF-CHECK 1.1
Explain the meaning of:

(a) Business profile;
(b) Business model; and
(c) Business process.
ACTIVITY 1.2
List the business process activities involved when you apply to study at
OUM (state the process, sub-process and result).

1.2 INFORMATION SYSTEM COMPONENTS

What does it mean by a system?
A system is a set of related components which can process input to produce

a certain output.
Every system requires a form of data input. For example, an ATM machine
accepts data when you enter the PIN number. A washing machine accepts data
when you select the start button; it processes the input and produces the
respective output.
In an information system, input data consists of facts and figures, which form the
systemÊs raw material. Information is data that has been usefully processed.
However, an information system does not only contain data and information.
There are also other elements in the system that are related and support one
another. The presence of these related elements makes information more useful
whereby it can be made available, processed, distributed, manipulated, saved
and so on. This combination gives rise to a system, which is orderly and as such
it is called an „information system‰.
The activity of converting data into information is called a process. An

information system contains five main components hardware, software, data,
process and human as shown in Figure 1.3.

Figure 1.3: Five components of an information system
1.2.1 Hardware
What does hardware mean?
Hardware is the physical embodiment of an information system. It is one of

the main elements which create the information system cycle.
Information system hardware refers to all types of hardware and the media used
for input, processing, managing, distributing and saving information that is used
in an organisation. Examples of hardware are the computers, networks,
communication equipment, scanners, digital drives and so on.
Basic hardware of a computer consists of four main elements as shown in Figure

1.4.
Figure 1.4: Four elements in the basic hardware of a computer

Table 1.1 describes in greater detail the functions and examples of computer
hardware.
Table 1.1: Functions of Basic Hardware of a Computer
Type of
Functions Examples
Hardware
Input Giving data input to the system. Keyboard, mouse, pointer, screen,
touch ball and scanner.
Processing Operating the computer system. Central processing unit and

memory.
Output Can display results or output Screen, microphone and printer.

which are generated from the
computer system.
Storage For storing data inside the Hard disk, floppy disk, CD-ROM
computer. and magnetic tape.
Computers can be turned into useful tools if you know how to exploit them. To
enable computers to function more effectively and to diversify their functions,
you need the communication network to connect several computers together.
The network provides the hardware support to enable communication to be

established among each other. The communication network includes modems,
hubs, cables and other devices.
1.2.2 Software
Software falls into two categories:
(a) System software which controls the computer and contains the operating
system and device drivers. It communicates with the hardware. It can also
modify data into a new form, prevent viruses and make copies.
(b) Application software which contains programs that can help users and
enable companies to perform business functions. Users can increase
productivity with application software such as spreadsheets, word
processing, ordering systems and accounts receivable.

1.2.3 Data
What does data refer to?
Data refers to the raw facts on anything or entities like student names,
courses and marks.
The raw data that has not yet been provided can be processed to become more
useful information. What does information mean?
Information is an organised, meaningful and useful interpretation of data

such as a companyÊs performance or a student's academic performance.
Information systems change data into information, which is useful and capable of
giving a certain meaning to its users.
Let us look at Figure 1.5 which shows an example of data and information
representation.
Figure 1.5: How data is transformed into information
Based on the example in Figure 1.6, we can understand that records inside every
attribute under the DATA item do not have any specific meaning. Every data or
record here is a raw fact. After going through processes such as addition,
ordering, combining, manipulating and so on, many kinds of information can be
produced. The information generated is not limited to a certain form. It can be
interpreted in many ways according to the needs and wills of customers.

1.2.4 Process
What can you say to describe process? Process or procedure explains the
activities carried out by users, managers and staff. Process is important for
supporting a certain business model and is available as written documents or as
reference materials online. Processes are the building blocks of an information
system because they represent actual day-to-day business operations. So what
can we say to simplify the meaning of process?
Process is a guide consisting of orderly steps, which need to be followed and

implemented in order to get a certain decision on a certain matter.
To build a successful information system, analysts must understand business

processes and document them carefully.
The procedure for using a certain matter is very wide and important to ensure
that it can be implemented with success. All the information system components
contain management and implementation procedures on their own, and they are
different from each other.
1.2.5 Human or People

Do you know that people who have an interest in an information system are
called stakeholders? Stakeholders include the management group responsible for
the system, the users (sometimes called end users) inside and outside the
company who will interact with the system and (IT) staff members, such as
systems analysts, programmers and network administrators who develop and
support the system.
Each stakeholder group has a vital interest in the information system, but most
experienced IT professionals agree that the success or failure of a system usually
depends on whether it meets the needs of its users. For that reason, it is essential
to understand user requirements and expectations throughout the development
process.

SELF-CHECK 1.2
1. Circle the words which are the main components of an information

system.
Hardware Software Network System

Users Purchaser Company Humanware
Process Data Information
2. Give two examples of data and information.
1.3 INFORMATION SYSTEM CATEGORIES

Normally there are several approaches to solve a certain problem. The same goes
for information system; there are several types of information systems which are
developed to overcome specific problems, besides trying to fulfil the user's
requests in general. In a large organisation, solving business problems such as
the management of staff salaries, processing of business data and others is
normally done with the use of large computers with internal and external
networks.
Every type of information system has a role to play. If you look at the functions
and the scope of usage, information systems can be divided into six main
categories as listed in Figure 1.6.
Figure 1.6: Six main categories of information system
To understand these six main categories of information systems, Table 1.2 gives
further explanation for each of them.

Table 1.2: Information System Categories
System
Explanation
Category
Transaction Better known as TPS and is one of the first systems to be automated.
Processing
System Can access and record information about all transactions related to
the organisation.
Transactions occur whenever there exist activities involving sales
order processing, accounts receivable, accounts payable, inventory
and ordering as well as payroll.
These transactions involve credit and debit in the companyÊs ledger
account.
The output from this transaction is the account statement, which is
used to generate financial reports.
TPS now uses the latest technology which applies the e-commerce
concept. This is a new challenge in the field of transaction processing
which is beginning to shift to the online transaction processing
system.
Management This system will take the information that has been extracted from
Information TPS and generate reports which are required by the management for
System planning and controlling a company's business.
This system is capable of fulfilling the needs of management in
acquiring the information that:
(a) Is brief and useful.
(b) Can be obtained and processed at the right time to make a
decision.
Executive A decision support system specifically used by the executive

Information management in making strategic decisions.
System
It is a tool that provides online access directly to the relevant
information, in a format that is useful and can be browsed.
Relevant information is timely, precise and useful in business
aspects, according to the interest of certain managers.
Useful format can be browsed easily; meaning that the system has
been specially built for the use of individuals who have little time to
spare, are less skilful in using the keyboard and less experienced
with computers.

This system can be easily surfed so that managers can identify

strategic issues and then explore information about those issues.
It is also an information system that combines the features of
information reporting system and decision support system. It
focuses on fulfilling the strategic information needs of the top
management.
Decision The main focus of this information system is for the effectiveness of
Support the manager in analysing the information and making a decision.
System
It is used for handling decisions that are not structured; decisions
which are made when an emergency occurs.
This system uses a database management system, query language,
financial modelling, electronic spreadsheet, statistical analysis
program, report generator or graphic software for supplying the
information needed.
Office Office automation is wider than word processing and form

Information processing.
System
This information system covers activities in the office, which can
improve workflow and communication among workers, whether
inside or outside the office.
The focus of this system is on the collection of information for
whoever needs it.
The functions of this system are word processing, e-mails, work
group programming, work group scheduling, facsimile processing,
e-document, imaging and management of work flow.
Expert System It is a program that produces a decision which is almost similar to

decisions made by an expert in a certain discipline.
This information system can imitate the way humans think and
consider in making a decision.
An expert system will combine the use of knowledge, facts and
techniques to make a decision.
An expert can always make a certain decision which is accurate as
well as ensure maximum benefit to all the people concerned.
Unfortunately, the sources of expert services are limited.
Realising the high value of knowledge and the expertise owned by
the expert, researchers have tried to transfer and save in computers
the knowledge and expertise owned by the experts.
Through this work, the expert system is made.

SELF-CHECK 1.3
List the six main categories of an information system.
ACTIVITY 1.3
For each of the following problems, suggest an appropriate information

system category:
Problem Information System Category
(a) Registration, rental and return of

videos by customers at a shop
which provides video rental
services.
(b) Determination of disease types

contracted by patients who come
to a clinic for treatment.
(c) Determining whether a staff is

qualified to be given a
scholarship for further study at a
higher level.
1.4 USERS AND INFORMATION

Corporate organisational structure has changed considerably in recent years. As
part of downsizing and business process reengineering, many companies have
reduced the number of management levels and delegated responsibility to
operational personnel. Although modern organisation charts tend to be flatter, an
organisational hierarchy still exists in most companies.
A typical organisational model identifies four organisational levels, as shown in

Figure 1.7.

Figure 1.7: Four organisational levels

Source: Adapted from Cashman (2012)
Within the functional areas, operational personnel report to supervisors and

team leaders. The next level includes middle managers and knowledge workers,
who, in turn, report to top managers. In a corporate structure, the top managers
report to a board of directors elected by the companyÊs shareholders.
Thus, a systems analyst must understand the companyÊs organisational model to

recognise who is responsible for specific processes and decisions and to be aware
of what information is required by whom.
1.4.1 Top Managers

Top managers develop long-range plans, called strategic plans, which define the
companyÊs overall mission and goals. To plot a future course, top managers ask
questions such as „how much should the company invest in information
technology?‰, „how much will Internet sales grow in the next five years?‰ or
„should the company build new factories or contract out the production
functions?‰
Strategic planning affects the companyÊs future survival and growth, including
long-term IT plans. Top managers focus on the overall business enterprise and
use IT to set the companyÊs course and direction. To develop a strategic plan, top
managers also need information from outside the company, such as economic
forecasts, technology trends, competitive threats and governmental issues.

1.4.2 Middle Managers and Knowledge Workers

Just below the top management level, most companies have a layer of middle
managers and knowledge workers. Middle managers provide direction,
necessary resources and performance feedback to supervisors and team leaders.
Since they are focusing on a somewhat shorter time frame, middle managers
need more detailed information than top managers, but somewhat less than
supervisors who oversee day-to-day operations. For example, a middle manager
might review a weekly sales summary for a three-state area, whereas a local sales
team leader would need a daily report on customer sales at a single location.
In addition to middle managers, every company has people called knowledge

workers. Knowledge workers include professional staff members such as
systems analysts, programmers, accountants, researchers, trainers and human
resource specialists. Knowledge workers also use business support systems,
knowledge management systems and user productivity systems. Knowledge
workers provide support for the organisationÊs basic functions. Just as a military
unit requires logistical support, a successful company needs knowledge workers
to carry out its mission.
1.4.3 Supervisors and Team Leaders

Supervisors, often called team leaders, oversee operational employees and carry
out day-to-day functions. They coordinate operational tasks and people, make
necessary decisions, and ensure that the right tools, materials and training are
available. Like other managers, supervisors and team leaders need decision
support information, knowledge management systems and user productivity
systems to carry out their responsibilities.
1.4.4 Operational Employees

Lastly, let us look at the fourth level which is operational employees. Operational
employees include users who rely on transaction processing systems to enter and
receive data they need to perform their jobs. In many companies, operational
users also need information to handle tasks and make decisions that were
assigned previously to supervisors. This trend, called empowerment, gives
employees more responsibility and accountability. Many companies find that
empowerment improves employee motivation and increases customer
satisfaction.

Systems analysis and design is a step-by-step process for developing high-

quality information systems. The major goal of systems analysis and design is
to improve organisational systems.
On the other hand, information system is a combination of information

technology, people and data. It is important to support business operations to
increase productivity as well as help managers to make decisions.
Business process modelling is a technique used by a systems analyst to

represent companyÊs operations and information requirements.
There are five information system components, namely human, process,

software, data and hardware.
Information system can be categorised into transaction processing system,

management information system, executive information system, decision
support system, office information system and expert system.
A typical organisational model identifies organisational levels into four

namely top managers, middle managers and knowledge workers,
supervisors and team leaders, and operational employees.
Business process modelling Information system components

Hardware Organisational levels
Information system categories Software

Topic System
2 Development
Methodology
LEARNING OUTCOMES
1. Define important terminologies in information systems such as
methodology, model, tools and techniques;
2. Describe five phases of the system development life cycle;
3. Identify four alternative approaches in system development; and
4. Determine how to select appropriate development methodology.
INTRODUCTION
After you have been exposed to the basics of systems analysis and design in
Topic 1, let us now study closely the system development methodology.
System development methodology is a standard process followed in an

organisation to conduct all the steps necessary to analyse, design, implement,
and maintain information systems. Organisations use a standard set of steps,
called system development methodology to develop and support their
information systems. Like many processes, the development of information
systems often follows a life cycle.
For example, a commercial product such as a Nike sneaker or a Honda car

follows a life cycle; it is created, tested and introduced to the market. Its sales
increase, peak and decline. Finally, the product is removed from the market and
is replaced with something else.

18 TOPIC 2 SYSTEM DEVELOPMENT METHODOLOGY
Many options exist for developing information systems, but the most common
methodology for system development in many organisations is system
development life cycle. However, it is important to know other alternative
development methodology available in order to maximise the development
process.
2.1 METHODOLOGY, MODELS, TOOLS AND

TECHNIQUES
In this subtopic, we will look at four important terminologies in information
systems, namely methodology, model, tools and techniques.
2.1.1 Methodology
Methodology in information system refers to system development methodology.
What does system development methodology mean?
System development methodology is a comprehensive plan to be followed,

which covers all the necessary activities in the systemÊs development life
cycle.
Methodologies include the model that needs to be followed, plus the tools and
techniques that need to be used. It is normally developed in-house; which is
developed by experts in the organisation, based on their knowledge and
experiences. Some methodologies are made outside; purchased and obtained
from other organisations, either from consulting firms or other suppliers. For
example, structured systems analysis and design method (SSADM), dynamic
system development method (DSPM) and system development life cycle (SDLC).
Methodologies are seen as written information in the form of books and other
documents by detailing every activity which needs to be implemented by system
developers. This includes documentation forms and reports that need to be
provided by the project team. There are also methodologies in a more shortened
form, which contains general instructions on what needs to be implemented. Do
you know that many methodologies today have been shaped from other
methodologies? This has been done after some adaptations to suit the needs of
the new system development.

TOPIC 2 SYSTEM DEVELOPMENT METHODOLOGY 19
2.1.2 Models
Firstly, what does a „model‰ mean?
A model is a graphical presentation which can represent a real situation or a

real world. The word „abstraction‰ is sometimes used only because a portion
of the real aspect would be used.
Models are easily used when you wish to share information on any matter.
Models in the development of information system have the same objectives.
As an example, try to imagine the model of a house. To enable you to see the
design aspect of the house, a housing developer would always build a small
model in three-dimensional view. For a two-storey house, the model must show
the physical building and also the floor shape of the house. The real world is the
terrace house which is going to be built later, based on the model.
You may be asking, in the development of information systems, what are the
models that can be used by the system developer?
Actually there are many models that can be used. Among them are
representations for the inputs, outputs, processes, data, objects and object
interactions, location, network and also devices involved. In addition, there are
process models, data models, object models and even the system development
models. Most of the models being used are in graphical form, and use symbols
and conventions that are generally acceptable and understood. These symbols
and conventions are known as graphs and charts.
You may draw a model that shows the process flow of a certain job by using the
flow chart. The texts, which you use in the flow charts, show the way to
understand it. Indeed, you can create many other models of information systems.
Figure 2.1 shows various models which can be used in system development.

Figure 2.1: Various models in system development
The following Figure 2.2 shows one model for managing development process
which is the Gantt chart.
Figure 2.2: Gantt chart

2.1.3 Tools
What can you say to define tools?
Tools refer to the supporting software that is used to create models or other
components that are needed in a certain project.
As an example, the software for drawing a diagram is considered a tool for

drawing the picture of certain diagrams and charts. Tools also include a database
application, which is used for collecting information for a certain project, such as
definitions of data flows or a list of written instructions about a certain process.
As for project management, there is specific software used for it, such as the
Microsoft Projects. It is a tool used for creating the model of a certain project and
also for creating related activities needed for implementation.
2.1.4 Techniques
Lastly, let us look at technique. What does it stand for?
Technique is a strategy which can be used for implementing a specific

system development activity.
The following Figure 2.3 lists a number of problems, which need to be considered
when building an information system.

Figure 2.3: Problems to be considered when developing an information system
The techniques and methods used to implement each of the above activities can
be obtained in the form of detailed instructions, and must be followed by every
individual involved in the information system development project.
Some examples of the techniques which are normally used in information

systems development are listed as follows:
(a) Project planning technique;

(b) Systems analysis technique;
(c) Systems design technique;
(d) Systems development and implementation technique; and
(e) Systems support technique.
After knowing the terms that are used in information systems development such
as methodology, models, tools and techniques, do you know their relationship to
each other?
Their relationship to each other can be explained in this definition:
Methodology is a collection of models, tools and techniques that are being

used for implementing activities inside all the phases of systems development.

These activities include completing various models and also producing

documents. For these to be possible, systems developers use special software
such as tools to support them in the implementation of activities. Figure 2.4
shows the relationship of components in the methodology.
Figure 2.4: Relationship between methodology components
ACTIVITY 2.1
1. What is the difference between:

(a) Model and tool.
(b) Technique and methodology.
2. List five techniques which can be used during systems development.
2.2 SYSTEM DEVELOPMENT LIFE CYCLE

After learning various aspects of information systems, now let us look at how an
information system is developed. An information system needs to be developed
specifically for a certain organisation. It is difficult to obtain a system in the
market which can fulfil the specific needs of a certain organisation. Thus, an
organised system development is greatly needed to avoid possible system
failure.
An information system built for a certain organisation normally includes various

functionalities, and this needs a detailed and systematic development plan.

Structured analysis uses a technique called „system development life cycle

(SDLC)‰ for planning and managing a system development process. SDLC is a
complete process for developing information systems, which begins with the
initial investigation phase and ends with the operations and support phase.
SDLC begins with a request for a new system or an upgrade of an existing

system to fulfil the needs of the business. In reality, the system development
process is a dynamic activity where changes normally happen at every phase,
after getting a comprehensive feedback mainly from users. The lifecycle
development methodology can be divided into five main phases. These phases
can overlap, where the subsequent phase can begin even while the preceding
phase is still continuing.
In general, all the five phases involved in the development of information

systems are shown in Figure 2.5.
Figure 2.5: Five phases of information system development
ACTIVITY 2.2
Based upon your own idea, try to produce a chart which can represent
phases in the development of an information system.
Now let us learn more about these five phases.

2.2.1 Phase 1: Initial Investigation

Do you know that initial investigation phase is sometimes referred to as planning
phase?
This phase is a fundamental process of understanding why an information

system should be built and determining how the project team will go about
building it.
It begins with a system request which presents a brief summary of a business

need and it explains how a system that supports the need will create business
value. Conventionally, this request involves a need for a new information system
or an improvement to an existing information system, which could not fulfil the
current business needs anymore. When managers and users develop new
strategic, tactical and operational plans, they include the need for information
systems to support their need for changes in business operations.
Therefore, the system request may come from the top management, the strategic
planning group, the head of department or staff of the information technology
department itself.
In this phase, it will identify the scope, the problem boundary and the strategy
for the new information system development plan. It is also a phase which will
determine whether or not a certain project will get the approval of the
management.
Feasibility evaluation or also known as feasibility analysis is the main activity in

this phase. The feasibility analysis examines key aspects of the proposed project
such as technical feasibility (can we build it?), economic feasibility (will it
provide business value?), organisational feasibility (if we build it, will it be
used?) and many other analyses.
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 or not.
The results of this initial investigation phase are:
(a) One report, which covers the business consideration; and

(b) Proposed actions, which need to be taken based on feasibility analysis.

2.2.2 Phase 2: 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:
(a) 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).
(b) The next step is requirements gathering or fact-finding process (such as

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.
(c) 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 (such as 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. It is important to remember,
however, that the deliverable from the analysis phase is both an analysis and a
high-level initial design for the new system.
The results of a system analysis are:
(a) System proposal; and

(b) Alternative plans and the costs involved.

2.2.3 Phase 3: System 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. They are:
(a) 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.
(b) 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 add to or change the
infrastructure that already exists in the organisation. The interface design
specifies how the users will move through the system (such as by
navigation methods such as menus and on-screen buttons) and the forms
and reports that the system will use.
(c) The database and file specifications are developed. These define exactly
what data will be stored and where they will be stored.
(d) 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 design specification that is
used by the programming team for implementation. At the end of the design
phase, the feasibility analysis and project plan are re-examined and revised, and
another decision is made by the project sponsor and approval committee about
whether to terminate the project or continue.

2.2.4 Phase 4: System Development and

Implementation
The objective of Phase 4 is to bring the system into reality, one that can function
with success and is documented as a complete information system, without
taking into consideration whether the system is to be developed in-house or
purchased in the market. 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.
In this phase, a new system is developed. Regardless of the methodology chosen,

the procedure is the same, that is to write the programs, to test, to document and
finally after the system has been successfully developed, it will be installed at the
user location. If the system is purchased in the market in the form of a package,
the system analyst needs to modify and re-configure the system.
The results of the fourth phase are:
(a) A system being produced, which can be used;
(b) Doing the last preparation including data preparation into a format, which
can be used by the new system, training of users and migrating to the new
system;
(c) Doing the system evaluation to ascertain that the new system can operate
with complete satisfaction; and
(d) Ensuring that the cost and benefits of the system produced are as
estimated.
2.2.5 Phase 5: System Support and Operation

The main objective of Phase 5 is to maximise returns on investment. A system
that is well designed will become a reliable system, easy to be updated and
measured. A design which can be measured can be expanded easily to
accommodate new requirements and even to add new branches to the business.
In this phase, the information technology staff will update and add value to the
new system. Updates will involve correction of errors, if any, and to make
changes that are appropriate with the environment at the location used, such as
including value-added tax for the tax rate. Meanwhile, activities to add value to

the system just developed can be things such as adding new features and
benefits.
System development is a process that occasionally changes. Even the business

process is often modified to take advantage of changes in information
technology. Therefore, the information system being developed certainly needs
to be updated after a long period of operation.
In the phases described above, you can understand why such phases need to be
implemented, the objectives that need to be achieved and the deliverables that
are required for each phase. In Table 2.1, the objectives and deliverables for each
phase are listed for comparison.
Table 2.1: Objectives and Output of the Phases in Information System Development
Phase Phase Name Objectives Deliverables

1. Initial Investigation To identify problems or Initial investigation
information requirements. report
2. System Analysis To study the current system System requirements

and to determine the new documentation or
system requirements. system proposal
3. System Design To design a new information System design
system. specifications
4. System Development To develop, acquire and test A complete

and Implementation new hardware and software. information system
To install and to adapt for the
users environment.
5. Support and To maintain and evaluate the An operational
Operation system information system
SELF-CHECK 2.1
1. What are the activities performed in Phase 1 (that is initial

investigation) and why is initial investigation a requirement?
2. List the things that must be done in the phases of system

development.

2.3 ALTERNATIVE APPROACHES TO SYSTEM

DEVELOPMENT
We have learnt that system development life cycle (SDLC) provides the
foundation for the processes used to develop an information system. However,
there are many different system development methodologies, and they vary in
terms of the progression that is followed through the phases of the SDLC.
Some methodologies are formal standards used by government agencies, while

others have been developed by consulting firms to sell to clients. Many
organisations have their own internal methodologies that have been refined over
the years, and they explain exactly how each phase of the SDLC is to be
performed in that company. Therefore, an analyst needs to be skilful in choosing
an approach to be adopted and be able to identify the strengths and weaknesses
of every approach. We will review four of the predominant methodologies that
have evolved over time, namely waterfall approach, object-oriented analysis and
design approach, rapid application development and agile development.
2.3.1 Waterfall Approach

Using the waterfall approach, analysts and users proceed sequentially from one
phase to the next (see Figure 2.6).
Figure 2.6: Waterfall development approach

Source: Adapted from Denis Wixom Roth (2012)

The key deliverables for each phase are typically voluminous (often, hundreds of
pages) and are presented to the approval committee and project sponsor for
approval as the project moves from phase to phase. Once the work produced in
one phase is approved, the phase ends and the next phase begin. As the project
progresses from phase to phase, it moves forward in the same manner as a
waterfall. While it is possible to go backward through the phases (such as from
design back to analysis), it is quite difficult (just imagine yourself as a salmon
trying to swim upstream in a waterfall!).
Waterfall development methodologies have the advantages of identifying

requirements long before programming begins and limiting changes to the
requirements as the project proceeds. The key disadvantages are that 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 system, and testing is treated almost as an afterthought in the
implementation phase. In addition, the deliverables are often a poor
communication mechanism, so important requirements may be overlooked in the
volumes of documentation.
If the project team misses an important requirement, expensive post-

implementation programming may be needed. Users may forget the original
purpose of the system, since so much time has elapsed between the original idea
and actual implementation. Also, in todayÊs dynamic business environment, a
system that met the existing environmental conditions during the analysis phase
may need considerable rework to match the environment when it is
implemented. This rework requires going back to the initial phase and making
needed changes through each of the subsequent phases in turn.
2.3.2 Object-Oriented Analysis and Design Approach

(OOAD)
Whereas structured analysis treats process and data as separate components,
object-oriented analysis and design (OOAD) combines data and the processes
(called methods) into a single item called objects. OOAD is an approach that is
intended to facilitate the development of systems that must change rapidly in
response to dynamic business environments. OOAD works well in situations in
which complicated information systems are undergoing continuous maintenance,
adaption and redesign.

System analysts use OOAD to model real-world business processes and

operations. The result is a set of software objects that represent actual people,
things, transactions and events. OOAD use industry standards for modelling
information systems, called the unified modelling language (UML).
Objects are persons, places or things that are relevant to the system we are
analysing. Each object can be viewed as an independent little machine with a
distinct role or responsibility. Each object is capable of receiving messages,
processing data and sending messages to other objects.
A class defines the set of shared attributes and behaviours found in each object in
the class. For example, records for students in a course section have similar
information stored for each student. The values may be different for each
student, but the type of information is the same.
What makes OOAD different from structured approach is the technique of

putting all of the objectÊs attributes and methods within one self-contained
structure, the class itself. This is a familiar occurrence in the real world. For
example, a packaged cake mix is analogous to a class since it has both the
ingredients as well as instructions on how to mix and bake the cake. Figure 2.7 is
an example of a class called RentalCar.
Figure 2.7: Examples of UML class

Source: Adapted from Kendall and Kendall (2008)
In UML, a class is drawn as a rectangle. The rectangle contains two other

important features; a list of attributes and series of methods. An attribute
describes some property that is possessed by all objects of the class. A method is
an action that can be requested from any object of the class. Methods are also
called operation.

Since this approach sees an information system as a collection of objects

interacting with each other, during the analysis phase, it identifies all the types of
objects that are useful to the system, and to show how objects are interrelated in
implementing a certain job.
Object-oriented analysis (OOA) looks at the problem domain, with the aim of
producing a conceptual model of the information that exists in the area being
analysed. Analysis models do not consider any implementation constraints that
might exist, such as concurrency, distribution, persistence or how the system is to
be built. Implementation constraints are dealt with during object-oriented design
(OOD). Analysis is done before the design.
The sources for the analysis can be a written requirements statement, a formal
vision document and interviews with stakeholders or other interested parties. A
system may be divided into multiple domains, representing different businesses,
technological or other areas of interest, each of which are analysed separately.
The result of object-oriented analysis is a description of what the system is
functionally required to do, in the form of a conceptual model. That will typically
be presented as a set of use cases and one or more UML class diagrams. It may
also include some kind of user interface mock-up.
Object-oriented design (OOD) transforms the conceptual model produced in

object-oriented analysis to take into account the constraints imposed by the
chosen architecture and any non-functional, technological or environmental
constraints, such as transaction throughput, response time, run-time platform,
development environment or programming language.
The concepts in the analysis model are mapped onto implementation classes and
interfaces. The result is a model of the solution domain, a detailed description of
how the system is to be built. Finally the goal of OOAD is to make system
elements more reusable, thus improving system quality and productivity of
systems analysis and design.
2.3.3 Rapid Application Development (RAD)

What is rapid application development?
Rapid application development (RAD) is a collection of methodologies that

emerged in response to the weaknesses of waterfall development and its
variations.

RAD incorporates special techniques and computer tools to speed up the

analysis, design and implementation phases in order to get some portion of the
system developed quickly and into the hands of the users for evaluation and
feedback.
It can be said that all system developers today try to speed up their information
system development processes and activities for their organisations. Among the
factors that influence a need for rapid system development are continuous needs
for new systems for use by their organisations and rapid changes in technology
and business environment. To finish a system development rapidly, it is required
to speed up the process. When a certain system is finished late, it will delay profit
returns and this certainly creates a loss for their company.
The RAD approach is used to speed up activities and processes found inside
every phase of system development, such as speeding up the analysis phase by
scheduling intensive meetings among the parties involved for the purpose of
information collection. In this way, decisions on a certain matter can be made
immediately and rapidly.
Iterative development is an approach that is combined with RAD, similar to the

Spiral Life Cycle Model. This model is capable of speeding up the acquisition
process up to the design and implementation phases.
Prototype system building during the analysis and design phases of SDLC can
also speed up the development process. However, prototyping is not always
done for RAD. The main objective of building prototypes is to increase the
understanding of system requirements.
Figure 2.8 shows the comparison between phases inside the traditional SDLC or
also known as Waterfall and the RAD life cycle.

Figure 2.8: Comparison between phases inside traditional SDLC and RAD life cycle
Some of the approaches used to implement rapid applications appear to be very

radical. These approaches include the creation of a working prototype directly
for the system to be developed. This enables users to try out the system and to
make relevant corrections and criticisms. Finally, the system would be applied to
a complete system, when system users feel satisfied with the capability of the
new system.
2.3.4 Agile Development

Lastly, let us look at agile development.
Agile development is a group of programming-centric methodologies that

focus on streamlining the SDLC.
Much of the modelling and documentation overheads are eliminated; instead,

face-to-face communication is preferred. A project emphasises simple, iterative
application development in which every iteration is a complete software project,
including planning, requirements analysis, design, coding, testing and
documentation. Cycles are kept short (one to four weeks), and the development
team focuses on adapting to the current business environment. There are several
popular approaches to agile development, including extreme programming (XP),

Scrum and dynamic systems development method (DSDM). Here, we briefly

describe extreme programming.
Extreme programming emphasises customer satisfaction and teamwork.

Communication, simplicity, feedback and courage are core values. Developers
communicate with customers and fellow programmers. Designs are kept simple
and clean. Early and frequent testing provides feedback and developers are able
to courageously respond to changing requirements and technology.
Project teams are kept small. An XP project begins with user stories that describe
what the system needs to do. Then, programmers code in small, simple modules
and test to meet those needs. Users are required to be available to clear up
questions and issues as they arise. Standards are very important to minimise
confusion, so XP teams use a common set of names, descriptions and coding
practices. XP projects deliver results sooner than even the RAD approaches and
they rarely get bogged down in gathering requirements for the system.
For small projects with highly motivated, cohesive, stable and experienced teams,
XP should work just fine. However, if the project is not small or the teams are not
cooperative, then the likelihood of success for the XP project is reduced. XP
requires a great deal of discipline to prevent projects from becoming unfocused
and chaotic.
Furthermore, it is recommended only for small groups of developers (not more

than 10) and it is not advised for mission-critical applications. Since little analysis
and design documentation are produced with XP, there is only code
documentation; therefore, maintenance of large systems developed using XP may
be impossible. Also, since mission-critical business information systems tend to
exist for a long time, the utility of XP as a business information system
development methodology is in doubt. Finally, the methodology requires
considerable on-site user input, something that is frequently difficult to obtain.
2.4 SELECTING THE APPROPRIATE

DEVELOPMENT METHODOLOGY
As explained in the previous subtopic, there are many methodologies. The first
challenge faced by project managers or systems analysts is to select which
methodology to use. Choosing a methodology is not simple, because no one
methodology is always best. Many organisations have standards and policies to
guide the choice of methodology. You will find that organisations range from
having one „approved‰ methodology to having several methodology options to
having no formal policies at all.

Many of the RAD and agile development methodologies require the use of new
tools and techniques that have a significant learning curve. Often, these tools and
techniques increase the complexity of the project and require extra time for
learning. Once they are adopted and the team becomes experienced, the tools
and techniques can significantly increase the speed in which the methodology
can deliver a final system.
So how do we choose the appropriate method? Following are the selection

criteria that can be used as a guideline:
(a) Clarity of User Requirements

When the user requirements for what the system should do are unclear, it
is difficult to understand them by talking about them and explaining them
with written reports. Users normally need to interact with technology to
really understand what the new system can do and how to best apply it to
their needs. System prototyping and throwaway prototyping are usually
more appropriate when user requirements are unclear, because they
provide prototypes for users to interact with early in the SDLC. Agile and
object-oriented development may also be appropriate if on-site user input
is available.
(b) Familiarity with Technology

When the system will use new technology with which the analysts and
programmers are not familiar (such as the first web development project
with Ajax), applying the new technology early in the methodology will
increase the chance of success.
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. Throwaway prototyping is particularly appropriate for
situations where there is a lack of familiarity with technology, because it
explicitly encourages the developers to create design prototypes for areas
with high risks. Iterative development is good as well, because
opportunities are created to investigate the technology in some depth
before the design is complete. While one might think that system
prototyping would also be appropriate, it is much less so because the early
prototypes that are built usually only scratch the surface of the new
technology. Typically, it is only after several prototypes and several months
that the developers discover weaknesses or problems in the new
technology.

(c) System Complexity

Complex systems require careful and detailed analysis and design.
Throwaway prototyping is particularly well suited to such detailed
analysis and design, but system prototyping is not. The waterfall
methodologies can handle complex systems, but without the ability to get
the system or prototypes into usersÊ hands early on, some key issues may
be overlooked. Although iterative development methodologies enable
users to interact with the system early in the process, we have observed
that project teams who follow these methodologies tend to devote less
attention to the analysis of the complete problem domain than they might if
they were using other methodologies.
(d) System Reliability

System reliability is usually an important factor in system development.
After all, who wants an unreliable system? However, reliability is just one
factor among several. For some applications, reliability is truly critical (such
as medical equipment, missile control systems), while for other
applications it is merely important (such as games, Internet video).
Throwaway prototyping is most appropriate when system reliability is a

high priority, because detailed analysis and design phases are combined
with the ability for the project team to test many different approaches
through design prototypes before completing the design. System
prototyping is generally not a good choice when reliability is critical, due to
the lack of careful analysis and design phases that are essential for
dependable systems.
(e) Short Time Schedules

Projects that have short time schedules are well suited for RAD
methodologies because those methodologies are designed to increase the
speed of development. Iterative development and system prototyping are
excellent choices when timelines are short because they best enable the
project team to adjust the functionality in the system on the basis of a
specific delivery date. If the project schedule starts to slip, it can be
readjusted by removal of the functionality from the version or prototype
under development. Waterfall-based methodologies are the worst choice
when time is a premium, because they do not allow for easy schedule
changes.

(f) Schedule Visibility

One of the greatest challenges in systems development is to know whether
a project is on schedule. This is particularly true of the waterfall-based
methodologies because design and implementation occur at the end of the
project. The RAD methodologies move many of the critical design
decisions to a position earlier in the project to help project managers
recognise and address risk factors and keep expectations in check.
It is important that before an information system is built, a detailed plan

should be done with the adoption of a certain methodology or technique.
Methodology is a comprehensive set of guidelines consisting of the models,

tool facilities and techniques which need to be followed in implementing
every activity inside the system development life cycle.
Model can be defined as a representation of certain parts taken from the real
world. It is also known to be abstract. It is used to represent inputs, outputs,
process, data, objects and their interactions, locations, the network and also
the devices involved.
Tool is the support software and hardware used to create models or other
components which are required in a certain project. It is used to simplify the
task of system development.
Technique is a collection of guidelines, which help the systems analyst to

implement and complete the system development job and activities.
System development life cycle (SDLC) is a complete development process for

a certain information system, which begins with the initial investigation
phase, analysis, design, development and implementation, and ends with the
support and operation phase. Every phase contains certain specific activities.
There are various approaches that can be used in the development of

information systems such as waterfall, object-oriented approach, rapid
application development and agile development.
Criteria in selecting the appropriate development methodology include

clarity of user requirements, familiarity with technology, system complexity,
system reliability, short time schedules and schedule visibility.

Agile development System design

Initial investigation System development and
implementation
Methodology
System development life cycle (SDLC)
Model
System support and operation
Object-oriented analysis and design
approach (OOAD) Techniques
Rapid application development (RAD) Tools
Selection criteria Waterfall approach
Systems analysis

Topic Managing a
3 Project
LEARNING OUTCOMES
1. Identify skills needed for a systems analyst;
2. Identify analyst roles;
3. Differentiate between a project and project management;
4. Explain system request factors;
5. Describe two steps in system request evaluation; and
6. Apply six steps in initial investigation.
INTRODUCTION
The systems analyst plays an important role in system development project.
Among the roles of a systems analyst is to cooperate with other individuals in the
organisation to evaluate system requirements.
A project is identified when someone in the organisation identifies a business

need to build a system. Business needs can surface when the organisation
identifies unique and competitive ways of using IT. Once the need for the system
and its business requirements have been defined, the approval committee will
authorise a systems analyst to prepare a more detailed business case. This is to
better understand the proposed information system project.
Feasibility analysis guides the organisation in determining whether to proceed

with the project. Feasibility analysis also identifies the important risks associated
with the project that must be managed if the project is approved. So let us start
learning all of these in this new topic.

42 TOPIC 3 MANAGING A PROJECT
3.1 SYSTEMS ANALYST

The systems analyst plays a key role in information systems development
projects. The 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 business problems.
In addition, systems analysts may serve as change agents; a person who serves as
a catalyst for change, develops a plan for change and works with others in
facilitating that change.
The systems analyst is responsible for following up on the latest developments

and the newest techniques in information technology so that he can update the
end-users and management on new technologies that are very useful to the
business. This kind of knowledge can be acquired through courses at colleges,
seminars, workshops and trainings. There are certain expert areas that should be
grasped by a system analyst. They are:
(a) Database management system centralised and distributed;

(b) Networking and telecommunications;
(c) Distributed program and client/server architecture;
(d) Object technology;
(e) Rapid application development technology;
(f) Graphical user interfaces; and
(g) The Internet.
Is your ambition to become a systems analyst? Try and look around the
advertisement spaces in the newspapers or websites. One example is shown in
Figure 3.1; a post of analyst offered to anyone interested and qualified.

TOPIC 3 MANAGING A PROJECT 43
Figure 3.1: Advertisement for a systems analyst in Jobstreet website

Source: http://www.jobstreet.com
There will always be a shortage of qualified workers to fill the posts in the field
of information technology. This will create a high demand for individuals with
expertise, knowledge and wide experience in the field of information technology
to fill these vacancies.
If you are interested in becoming a systems analyst, you certainly need to

understand the basic theories and the knowledge of information systems analysis
and design. To become a successful systems analyst, you should equip yourself
with all the knowledge and skills in this field.
There are four skills needed by a systems analyst as summarised in Table 3.1.

Table 3.1: Skills of a Systems Analyst
Skills Explanation
Knowledge of A systems analyst with credibility should:

Business and
Organisation Understand the fields of both business and programming.
Study business opportunities and problems.
Be able to change the business and determine business information

requirements for computer-based information system and
computer applications, which can be implemented by various
technical experts including computer programmers.
Understand in depth every process and operation in the

organisation. This is to ensure that the information system to be
developed would really support the organisation to achieve its
objectives effectively.
Be clear on the direction or the organisational aim.
Study carefully every process and operation in the organisation.
Skills in Solving A systems analyst should:

Problems
Be capable of solving problems related to the system.
Be skilled in computers and computer programming.
Develop the information system beyond program writing.
Be treated as a problem solver, and not as a computer

programmer, since the information system being developed is to
solve problems faced by an organisation.
What are the problems that need to be solved by a systems analyst?
Among the examples of problems that need to be solved by a
systems analyst are:
When a customer wishes to order goods either during day or

night the problem to be solved is how the system can receive
the order and process it without increasing costs.
When the management wishes to know the current financial

status of the company, including profit and loss incurred, cash-
flow and share market forecasts the problem to be solved is
how to collect, analyse and present all financial information
requested by the companyÊs management.

These are just some examples of problems that may be thought of by

the management of organisations. The systems analyst should have
the skills to search for suitable techniques to handle the problems
faced by these organisations.
The approach taken by an analyst in solving problems is depicted in
Figure 3.2.
Figure 3.2: Approach to problem solving
Skills in Inter- A systems analyst should:

personal
Communication Be able to communicate effectively because the systems analyst
always interacts with various layers of people such as the system
users, technicians, database administrators, network analysts,
supervisors and managers.
Possess inter-personal skills such as communication skill, skills

for interviewing and questionnaire designing, skills in writing
and presentation.

Knowledge and A systems analyst should:

Skills in
Information Know how to write programs since he is the main person to link
Technology between end-users and system developers.
Have wide experience in programming, besides being able to

design the system to be built. Two main activities inside the
system development life cycle are analysis and design. In these
two phases, the systems analyst will provide many development
models such as process and data models.
Be skilled in the use of utility software and CASE tools in

building various development models.
Have deep knowledge in technical fields such as knowledge of

computer types and networking technology. This is important
because most of the information systems implemented today are
inclined towards networking technology.
ACTIVITY 3.1
What is the relationship between system problem-solving and the system

development life cycle?
3.2 SYSTEMS ANALYST ROLES

To develop an effective information system does not just involve the systems
analyst and users. Many technology experts are also involved in the development
of information systems such as change management analyst, infrastructure
analyst, networking experts, business analyst, project manager and others.
As organisations and technology have become more complex, most large

organisations now build project teams that incorporate several analysts with
different, but complementary roles. In smaller organisations, one person may
play several of these roles. Here we briefly describe these roles and how they
contribute to a systems development project.
(a) The systems analystÊs role focuses on the IS issues surrounding the system.
This person develops ideas and suggestions for ways that IT can support
and improve business processes, helps design new business processes
supported by IT, designs the new information system and ensures that all

IS standards are maintained. The systems analyst will have significant

training and experience in analysis and design and in programming.
(b) The business analystÊs role focuses on the business issues surrounding the
system. This person helps to identify the business value that the system
will create, develops ideas for improving the business processes and helps
design new business processes and policies. The business analyst will have
business training and experience, plus knowledge of analysis and design.
(c) The requirements analystÊs role focuses on eliciting the requirements from
the stakeholders associated with the new system. As more organisations
recognise the critical role that complete and accurate requirements play in
the ultimate success of the system, this specialty has gradually evolved.
Requirements analysts understand the business well, are excellent
communicators and are highly skilled in an array of requirements
determination techniques (will be discussed in the next Topic 4).
(d) The infrastructure analystÊs role focuses on technical issues surrounding

the ways the system will interact with the organisationÊs technical
infrastructure (hardware, software, networks and databases). This person
ensures that the new information system conforms to organisational
standards and helps to identify infrastructure changes that will be needed
to support the system. The infrastructure analyst will have significant
training and experience in networking, database administration and
various hardware and software products. Over time, an experienced
infrastructure analyst may assume the role of software architect, who takes
a holistic view of the organisationÊs entire IT environment and guides
application design decisions within that context.
(e) The change management analystÊs role focuses on the people and
management issues surrounding the system installation. This person
ensures that adequate documentation and support are available to users,
provides user training on the new system, and develops strategies to
overcome resistance to change. The change management analyst will have
significant training and experience in organisational behaviour and specific
expertise in change management.
(f) The project managerÊs role is to ensure that the project is completed on time
and within budget and that the system delivers the expected value to the
organisation. The project manager is often a seasoned systems analyst who,
through training and experience, has acquired specialised project
management knowledge and skills.

The roles and the names used to describe them may vary from organisation to
organisation. In addition, there is no single typical career path through these
professional roles. Some people may enter the field as a more technically-
oriented programmer/analyst. Others may enter as a business-oriented
functional specialist with an interest in applying IT to solve business problems.
SELF-CHECK 3.1
1. What are the functions of a systems analyst when developing a

computer application?
2. The systems analyst is responsible to whom during the

development?
Now, let us study the functions of a systems analyst to manage a project.
3.3 PROJECT MANAGEMENT

The success of a certain project depends on the wisdom of the project manager. A
project manager needs to be wise in discharging his or her duties such as the
ability to schedule work for his or her group members and the ability to exploit
opportunities in the excesses and deficiencies found inside every element of the
project. The failure of a project manager to manage a project results in the failure
of the project.
3.3.1 Project
In your opinion, what do you understand by the term „project‰? Before we learn
further about how to manage a project, first of all, it is better to define what is
meant by the term „project‰ itself.
Project can be simply defined as work done to achieve a certain objective.
In general, a project contains a number of elements, which are time, budget and
objective as depicted in Figure 3.3.

Figure 3.3: Three basic components of a project
More specifically, we can define a project as a set of related activities which

require a certain time duration to be completed by using a pre-defined set of
resources.

need to build a system. Business needs can surface when the organisation
identifies unique and competitive ways of using IT. Many organisations keep an
eye on emerging technology, which is technology that is still being developed
and not yet viable for widespread business use. For example, if companies stay
abreast of technological advances such as cloud computing, RFID (radio
frequency identification) or Web 2.0, they can develop business strategies that
leverage the capabilities of these technologies and introduce them into the
marketplace as a first mover. Ideally, companies can take advantage of this first
mover position by making money and continuing to innovate while competitors
trail behind.
System projects are initiated by many different sources for many reasons. Some
of the projects suggested will survive various stages of evaluation to be worked
on by you (or you and your team); others will not and should not get that far.
Business people suggest system projects for two broad reasons:
(a) Because they experience problems that lend themselves to systems

solutions; and
(b) Because they recognise opportunities for improvement through upgrading,

altering, or installing new systems when they occur.

Both situations can arise as the organisation adapts to and copes with natural,
evolutionary change.
Projects come from many different sources and for many reasons. Not all projects
should be selected for further study. You must be clear in your mind about the
reasons for recommending a systems study on a project that seems to address a
problem or could bring about improvement.
3.3.2 Project Management

What is meant by project management?
Project management can be defined as the use of knowledge, skills, tools and
also certain techniques in activities of a certain project to fulfil a requirement
and to satisfy the wishes of the project stakeholders.
Project Management Institute (PMI) Inc. defines project management as "the

application of knowledge, skills, tools and techniques to a broad range of
activities in order to meet the requirements of a particular project".
The process of directing and controlling a project from start to finish may be
further divided into five basic phases: initiating, planning, executing, monitoring
and controlling, and closing down a project.
(a) Project initiation consists of processes performed to define a new project or

a new phase of an existing project by obtaining authorisation to start the
project or phase. Within the initiating processes, the initial scope is defined
and initial financial resources are committed. Stakeholders who will
interact and influence the overall outcome of the project are identified. The
key purpose of this phase is to align the stakeholdersÊ expectations with the
projectÊs purpose, give them visibility about the scope and objectives, and
show how their participation in the project and its associated phases can
ensure that their expectations are achieved. These processes help set the
vision of the project and what needs to be accomplished.
Once the project sponsor identifies a project that meets an important

business need, he can identify the business requirements and business
value of the system; time to formally initiate the project. In most
organisations, project initiation begins by preparing a system request.

(b) Project plan consists of processes performed to establish the total scope of
the effort, define and refine the objectives and develop the course of action
required to attain these objectives. The planning processes develop the
project management plan and the project documents that will be used to
carry out the project. The complex nature of project management may
require the use of repeated feedback loops for additional analysis. As more
project information or characteristics are gathered and understood,
additional planning will likely be required.
The key benefit of this phase is to delineate the strategy and tactics as well
as the course of action or path to successfully complete the project or phase.
When the planning is well managed, it is much easier to get stakeholder
buy-in and engagement. These processes express how this will be done,
setting the route to the desired objective.
(c) Project execution consists of processes performed to complete the work

defined in the project management plan to satisfy the project specifications.
This process group involves coordinating people and resources, managing
stakeholder expectations, as well as integrating and performing the
activities of the project in accordance with the project management plan. A
large portion of the projectÊs budget will be expended in performing the
executing phase.
(d) Project monitor and control consists of those processes required to:
(i) Track, review and orchestrate the progress and performance of the
project;
(ii) Identify any areas in which changes to the plan are required; and
(iii) Initiate the corresponding changes.
The key benefit of this phase is that project performance is measured and
analysed at regular intervals, appropriate events or exception conditions to
identify variances from the project management plan.
(e) Project closure consists of processes performed to conclude all activities

across all project management phases to formally complete the project,
phase or contractual obligations. This phase, when completed, verifies that
the defined processes are completed within all of the phases to close the
project or a project phase, as appropriate, and formally establishes that the
project or project phase is complete.

Similar to the phases contained in SDLC, every project phase can help a project
manager in managing and categorising project activities based on the objectives
to be achieved for each phase. He would continue with these until the installation
of an information system which could operate with complete satisfaction.
3.4 SYSTEM REQUEST FACTORS

A project is usually started following a request by users. A system request
usually proposes a revamp of an existing system, to correct mistakes contained
inside the current system or to completely develop a new information system.
Some factors that cause an organisation to develop or upgrade an information
system are given in Table 3.2.
Table 3.2: Factors that Cause an Organisation to

Develop or Upgrade an Information System
Factor Description
Failure of the The old system fails to perform satisfactorily, which cannot be
Old System tolerated. This failure could be due to old hardware or old software
with constraints to upgrade. Thus, it is time to change to a completely
new one.
Legal The government may introduce new tax rates or other laws. This
Requirements requires changes in the formulas for calculations, the number of
copies to be produced and to be sent, plus other requirements. Failure
to address these would result in penalties and other legal problems.
New The company needs to conform to newly established industry

Industry standards, such as ATM, bar-coding, online payments and so on.
Standards Failure to conform to the standard practices of the industry may
result in the company losing its linkages and competitiveness.
To Exploit The company wants to exploit the opportunity offered by new

New technologies present in the market. Examples could be Internet
Technology technology, mobile devices, physical tracking and many more. These
new technologies can improve performances several times or can cut
down on manpower costs a great deal, thus making its operations
more competitive.
To Improve Often system requests are made to improve or add additional services
Services for users and customers. Examples are to enable share investors to
check their account balances on the website, saving data about taxes,
or developing an online registration facility.

More The current system may not provide information required by the
Information organisation. For example, a customer ordering system may not
provide facilities for analysis and forecasting market trends.
However, to compete in the market and to address rapidity of the
sales cycles, managers need enough information to plan, design and
market products and services.
More Stable A system may need to add on new effective controls to ensure that
Control data is accurate and safe. Examples include passwords, various levels
of user access and encryption or data encoders. More sophisticated
controls are those like retina scanners to identify personnel. Poor
controls can result in mistakes in input data or invalid user access.
Controls inside the system should be effective and not overload
customers. If the system takes too long to process the data, this will
cause users or customers to get bored and think that the system is not
user friendly.
Reducing Operating cost of the existing system may be too expensive. It could
Operating incur a high updating cost due to technical problems, poor design or
Cost changing requirements in terms of the business direction. To
overcome this problem, the system may need to be upgraded by
incorporating new technology.
SELF-CHECK 3.2
Explain three factors which may be regarded as factors leading to

information system development.
3.5 SYSTEM REQUEST EVALUATION

In most organisations, information technology departments receive many system
requests that may exceed their duty loads. Many organisations assign the
responsibility of evaluating a system request to the managers and users. The
objective is to use the expertise of the manager in evaluating these requests.
In the evaluation of a system request, there are two steps that need to be done.
These steps are shown in Figure 3.4.

Figure 3.4: Evaluating system request
These two steps are further explained in the next following subtopics.
3.5.1 Evaluation Committee

In an organisation, only one individual is normally given the responsibility to
evaluate system requests. This usually occurs in small organisations where there
is only one person who possesses the required skills in information technology.
In such a case, the individual concerned needs to work closely with users and
managers in the organisation to ensure that business operational requirements
are considered as a whole.
In larger organisations, on the other hand, one committee needs to be formed in

order to bring together various skills and knowledge for evaluating system
requests. This committee normally consists of the information technology
director and various departmental managers.
3.5.2 Feasibility Evaluation

Evaluation of feasibility is a process normally carried out by many organisations
to evaluate the feasibility of a certain project. It aims to give the reasons or the
strong rationales why a certain information system needs to be developed. This
can be clarified briefly in Figure 3.5.

Figure 3.5: Evaluation of the feasibility
Usually, evaluation of feasibility involves a study of the proposed project outline

by taking into account a number of criteria and certain pressures. The criteria and
pressures depend on the organisation. An example of pressure is the effect of
time on a process flow, if the information system is used by the organisation.
In the context of information systems, evaluation of feasibility will help the

management to make a decision on whether or not to accept the proposal that
has been submitted based on the findings and analysis made in this evaluation.
There are several objectives that are identified in this evaluation. These are
shown in Figure 3.6.
Figure 3.6: Objectives of feasibility evaluation
Evaluation of feasibility is normally done in groups in which members are those

selected and who have the ability to achieve the objectives of the evaluation. At
the end of this process, the group is expected to produce a feasibility report as a
deliverable for the feasibility evaluation. The report contains a summary and
proposal from the group.
Feasibility study uses three main yardsticks to measure or to ensure the success
of the system to be developed, that is:
Operational feasibility;
Technical feasibility; and
Economic feasibility.

(a) Operational Feasibility

A system is said to have operational feasibility if the system can be used
after it has been developed. If users find it difficult to use the new system,
the system is said to be unable to fulfil the objectives set for its
development.
Operational feasibility tries to measure how far the solution proposed

can be used by the organisation.
In studying this problem, issues like performances, information, economy,

control, effectiveness and services will be addressed. Operational feasibility
depends on a number of things, such as:
(i) Whether the management supports the project. Whether users also
support the project.
(ii) Whether some of the workers will be retrenched.
(iii) Whether users will get involved in the system development right
from the beginning.
(iv) Whether the schedule for development is reasonable.
(v) Whether ethical issues need to be handled.
(b) Technical Feasibility
A system request is said to have the technical feasibility if the

organisation has the resources to develop or buy, and to operate the
system at user locations.
Evaluating for technical feasibility, in general, answers the following

question:
„Is the technology required by the new system obtainable from outside
parties or capable of being self-developed, and is it capable of being
introduced to the organisation with success?‰

During a study of technical feasibility, the systems analyst needs to think

about the following points:
(i) Whether the organisation has enough resources for hardware,

software and the network. If not, whether these resources can be
easily obtained.
(ii) Whether the proposed technology or solution is practical.
(iii) Whether the technology is available.
(iv) Whether the required technical skills are available.
(v) Whether the proposed system is capable of being expanded, and

capable of coping with organisational expansion.
(c) Economic Feasibility
Economic feasibility tries to answer the question of whether the system

to be introduced can be developed within budgetary constraints and
whether it can improve the organisationÊs economy by giving back in
the form of benefits.
To know the cost involved, an organisation normally emphasises the total

cost of ownership (TCO). This includes the cost of continuous support,
updating cost and also the development cost. To determine the TCO, the
analyst needs to determine the cost of the following items:
(i) People, including the information technology staff and users;

(ii) The hardware and tools;
(iii) The software that is built in-house and those bought from suppliers;
(iv) Formal and informal training;
(v) Licences and fees;
(vi) Consultation fees;
(vii) Facilitation cost; and
(viii) Opportunity cost of not developing the system or its postponement.

Besides the above listed costs, the analyst needs to look at the tangible
benefits and the intangible ones which may have some effect on the
organisation. The system evaluation committee will use these figures and
the estimated cost in deciding on whether or not to continue with the
project.
Tangible benefits are the benefits that can be measured in the form of
money, or those that can be easily quantified.
Tangible benefits can be produced out of a reduction in expenses and an

addition of the goods produced or both. Examples of factors leading to
tangible benefits are:
(i) A new scheduling system which can reduce time duration;

(ii) An online package tracing system which can improve the service and
reduce the need for clerical staff; and
(iii) An inventory control system which can reduce excessive inventory
and eliminate delay in taking out the product.
Intangible benefits are difficult to measure in monetary form, but this

category needs to be identified. They can be of strategic importance
that may override the numerical benefits.
Examples of the intangible benefits are:
(i) A user-friendly system that can improve job satisfaction of the staff;
(ii) A sales system which can supply information to help in making
decisions about the market;
(iii) A new website which can uplift the companyÊs image;
(iv) A system that provides competitive advantage in the marketplace;
and
(v) The cost of not having the proposed system.

SELF-CHECK 3.3
1. What is meant by the feasibility of a system?
2. What is the difference between tangible benefits and intangible

benefits?
Now let us study the tasks that need to be done by a systems analyst in dealing
with the initial investigation phase.
3.6 INITIAL INVESTIGATION PHASE

A systems analyst works on the initial investigation phase to study the system
request and to propose actions that need to be taken.
Initial investigation of the system can be defined as an initial study of a

certain project before making a decision on whether or not the project can be
continued.
Initial investigation is the process of studying the system request and preparing a
recommendation. The purpose of the initial investigation is to determine if the
systems request is worth pursuing into the analysis phase and to perform some
initial project management planning tasks. Initial investigation can also be
known as preliminary investigation.
An initial investigation for a project is very important for the management of an

organisation. The outcome of this study can help the management to make a
decision on whether to accept or to reject a proposed project.
3.6.1 Initial Investigation Activities

While working on the initial investigation, an analyst needs to follow a number
of steps to collect information, at the end of which he needs to produce a report
for presentation to the management. Now let us look at the steps to be followed
by a systems analyst in planning for the project to be undertaken.

Step 1: Understanding OrganisationÊs Problems and Opportunities

If the system request involves development of a new information system or only
some changes to the existing system, the systems analyst may need to:
(a) Develop a business profile to explain its business process and functions as
you have studied in Topic 1.
(b) Know how the change influences business operations and other information
systems.
Usually, changes in one system will influence other systems without you
realising it. When you analyse a system request, you need to ensure that the user
department and the business process involved are considered. In most cases, a
system request does not show the hidden problems, only the symptoms. For
example:
(a) You may receive a request to investigate the source of delays on a

mainframe processing. After the investigation, you understand that the
problem is due to the scheduling job, which is not smart enough and had
nothing to do with the hardware problem at all.
(b) A request to analyse a user complaint may be due to inadequate training

for the sales representatives and not due to the goods produced being
without quality.
Step 2: Determining Project Scope and Limitations

What is meant by project scope?
Determining the project scope means determining the project boundary as

completely as possible.
For example, a statement like the pay slip not being produced correctly is too
general as compared with a statement like overtime pay not being calculated
correctly for the staff in the Treasury Department. Sometimes, a project is
expanded without realising it. To overcome this problem, you need to determine
the project scope clearly. You may need to use a graphical model to illustrate the
system, the individuals involved and the business process. The project scope also
determines the boundary in the initial investigation. A systems analyst should
limit his or her focus on the problem and avoid using excessive time going over
budget specifications.

Besides determining the project scope, you need to identify the systemÊs
limitations. Limitations and needs are conditions for the system to achieve as per
the stated specification or the estimated systemÊs usefulness to be achieved.
Limitations can involve:
(a) Hardware;
(b) Software;
(c) Time;
(d) Policy;
(e) Law; and
(f) Cost.
A systemÊs limitations also determine the project scope. As an example, if the

system needs to operate using the existing hardware, this becomes the limitation
that influences a better solution. Other examples of the systemÊs limitations are as
follows:
(a) Order system must receive inputs from 15 departments outside the
location; and
(b) A new web portal must be operational on March 1.
Having identified the limitations, you also need to determine features of the
limitations. All limitations need to be identified as early as possible to avoid
future unforeseen problems. A clear definition of the project scope and
limitations can avoid differences in understanding, which may arise when the
manager thinks of the system having certain features, but in the end, he would
find that those features are not included in the system.
To avoid a certain project from expanding without being realised, you need to
understand two things; the project scope and project limitation.
SELF-CHECK 3.4
1. What is meant by the project scope?
2. What is meant by the project limitation?

Step 3: Doing Information Search

An information search consists of various techniques. Depending on the kind of
information desired, information searches may take a few hours, days or weeks.
As an example, to get the information for changing the format of a report or

input data on the screen you may need one telephone call or you may need to
send an electronic message to the user, but to get the information for producing a
new inventory system may involve a series of interviews. During the information
search, you may need to:
(a) Analyse an organisational chart;

(b) Execute an interview;
(c) Check existing documentation;
(d) Observe how the operation works; and
(e) Design questionnaires for users.
Step 4: Determining Project Feasibility

Until now, you have analysed the problems and benefits, determined the project
scope and its limitations, carried out information searches to seek the factors that
may influence a project and estimated the cost and benefits of the new system.
Now, you are ready to determine the feasibilities with respect to its operational,
technical and economic aspects. You have learnt about these in the previous
topic.
Step 5: Estimating Time and Cost in Order to Proceed with Development

To determine the estimated time and cost for the following development phases,
you need to consider the following issues:
(a) What information do you need to get? How to get the information? And
how to analyse it?
(b) What sources of information do you use? What are the problems faced in
getting the information?
(c) Do you need interviews? How many people do you need to interview?
How long do you need to interview and to summarise their responses?

(d) Do you need questionnaires? Who will be involved? How much time is
required to complete the questionnaires? How much time is required to
finish the questionnaires and to get the results?
(e) How much cost is involved to analyse the information obtained to provide
the report and also your proposal?
Besides estimating the time and cost for the next development phase, you also
need to estimate the time and cost for the entire project. This enables the manager
to understand the overall financial and scheduling implications. An accurate
estimate may not be known, but an estimate of time and cost may help, especially
when you forecast a good scenario as compared with a bad one.
Step 6: Presenting a Proposal to the Management

At this stage you have a number of alternatives. You may find that there is no
action to be taken, just that users may want additional training. To solve small
problems, you may take up a simple solution without performing any additional
analysis.
In other situations, you may propose a new information system development

and need to move on to the next phase of development, which is the analysis
phase.
The last step in this phase is to produce a report for management. This report
should contain an evaluation of the system request, estimated cost and benefits,
and your proposal. The completed report will then be presented to the
management. The content of the proposed report is shown in Table 3.3.

Table 3.3: Content of the Proposed Report
Item Content of the Item

Introduction This section will provide the general introduction for the report. It
contains summarised explanations on the system, names of
individuals involved in the initial planning and names of
individuals who ordered the investigation.
Summarised The summary explains the basis for the system request.
System Request
Planning Planning section contains the result of planning that has been made.
This includes an elaboration of project scope, limitations and the
systemÊs feasibility.
Proposal Proposal for the following actions with acceptable reasons and their
justification. The management will make a decision, but inputs
from the information technology department are required.
Time Duration This section will explain the cost required and the delivery of
and Cost system to user locations. Also included is the overall system
ownership cost during the time of its use.
Estimated Tangible and intangible benefits involved and also a table showing
Benefits when the costs are incurred.
Appendix All the appendices which can support the information supplied are
Recorded kept in this section.
SELF-CHECK 3.5
What is the objective of doing the initial investigation?

A systems analyst should have various skills and expertise to ensure that he
can supervise and deal with various individuals involved in the development
of an information system. Some of the skills are knowledge of business and
organisation, skills in solving problems and skills in inter-personal
communication.
Some of the roles of a systems analyst focus on the information system issues
and business issues surrounding the system, eliciting the requirements from
the stakeholders associated with the new system, and focus on the people and
management issues surrounding the system installation.

need to build a system. It comes from many different sources and for many
reasons.
On the other hand, project management can be defined as the use of

knowledge, skills, tools and also certain techniques in activities of a certain
project to fulfil a requirement and to satisfy the wishes of the project
stakeholders. It has five basic phases: initiating, planning, executing,
monitoring and controlling, and closing down a project.
Some of the system request factors are failure of the old system, legal
requirements, new industry standards and to improve services.
Two steps in system request evaluation are evaluation committee and

evaluating feasibility.
Initial investigation of the system can be defined as an initial study of a

certain project before making a decision on whether or not the project can be
continued. It has five steps that can be used as a guideline.

Expertise Skills
Initial investigation Systems analyst
Project System request evaluation
Project management System request factors
Roles

Topic Determination
4 of System
Requirements
LEARNING OUTCOMES
1. Differentiate between functional and non-functional requirements;
2. Identify three categories of stakeholders who get involved in the
investigation of system requirements;
3. Apply five basic questions during fact-finding work; and
4. Select suitable methods that can be used to determine requirements.
INTRODUCTION
Objectives and activities of the analysis and design phases have been briefly
described in the previous topics of this module. You also know in detail about
the roles and skills of the systems analyst. This topic will discuss the associated
skills and functions of a systems analyst. Two of the most important skills in
systems analysis are:
(a) Fact-finding to identify system requirements; and
(b) Business process modelling based on the system requirements.
In this topic, you will develop skills in fact-finding and investigation, while
process modelling will be explained in the next topic.

68 TOPIC 4 DETERMINATION OF SYSTEM REQUIREMENTS
In the activities of fact-finding and investigation, you will study the business
process and daily operations in depth. Actually, your objective is to gain the
same understanding as the users whom you have interviewed about how the
business operates. Why should you be an expert? It is because this is the only
way for you to ensure that the system satisfies business requirements. The
technical expertise that you have, together with the business knowledge that you
acquire constitutes a very valuable combination for organisational excellence.
These skills enable you to identify an intelligent method of achieving business
objectives in the use of information technology.
By becoming an expert in the problem domain, you also will gain usersÊ
confidence. Knowledge of your domain gives credibility to your proposal and
this can ensure that your proposal can fulfil usersÊ needs. If you can understand
usersÊ business operations, they will accept your proposal more openly.
Otherwise, your proposal will be rejected or questioned because users see you as
an outsider who does not understand their problems.
This topic focuses on system requirements. It elaborates on several techniques

that are used to study the business process and how to get information by using
the traditional and new methods. This topic also introduces business process
re-engineering (BPR) as a technique of changing the business in a radical manner.
4.1 FUNCTIONAL AND NON-FUNCTIONAL

REQUIREMENTS
System requirements cover all aspects of the new system based on the needs of
users and other stakeholders. Just look back on the determination of a systemÊs
scope one of the activities inside the planning stage. The analyst identifies
several capabilities of the system inside that activity.
What is the relationship between a systemÊs capability and the analysis phase? In
analysis, the analyst defines and explains the systemÊs capability in detail. In
other words, the analyst expands the general systemÊs capability into more
specific system requirements.
In general, system requirements can be divided into two categories; functional

requirements and non-functional requirements. The two main categories are
shown in Table 4.1. The latter category can be further divided into other sub-
categories, if appropriate to your project.

TOPIC 4 DETERMINATION OF SYSTEM REQUIREMENTS 69
Table 4.1: System Requirements
Functional Requirements Non-Functional Requirements
System requirements that are concerned System requirements that are concerned
with functions or process that needs to with anything else other than functions.
be performed by the system.
They constitute operational objectives
For example, if you develop an order that are related to hardware, software,
system, business functions that you will the environment and others.
include are:
Examples of the non-functional
(i) Record Customer Information; requirements are:
(ii) Accept Customer Order; (i) Ability to operate in the client-
server and Unix environment;
(iii) Verify Customer Order;
(ii) Ability to process online; and
(iv) Calculate Total Price;
(iii) Must have database on the
(v) Accept Payment; and
website and so on.
(vi) Generate Reports.
These requirements are often stated as
These functions will be included in the specific objectives that need to be
new Order System. achieved by the system.
The process to identify and explain
each business function requires a lot of
time and effort.
Functional requirements are proposed based on the procedures and rules used
by the organisation in performing its business.
(a) There are procedures that are well documented and easy to identify and to
explain. For example, „every customer must register before making an
order‰.
(b) There are procedures that are difficult to understand and difficult to be
met. For example, „the total price calculated needs to be deducted with
discounts for specific promotions‰.
This promotion is given by the salesperson who takes up orders for specific
situations, such as a small free item for a large purchase, or price reduction for
rounding up total payment for example, from RM102.70 to RM100. This may be
a procedure which needs to be included into the new system. It is not written
anywhere and its implementation in the new system will only happen if the
manager tells you.

Business rules are things that need to be taken into account inside the system
design and implementation. Otherwise, in the above case, you may design a new
system that allows a fixed discount only. On the other hand, if the rules are
noted, you can design a system that is more flexible and can handle several types
of discounts, besides the fixed discount in the transactions.
The two types of system requirements are required to be completely defined in

the new system. Both are identified during investigation of system requirements.
Functional requirements are often documented during building of the analysis
models, while the non-functional ones are often documented in the form of
narrative descriptions.
SELF-CHECK 4.1
1. What is meant by system requirements?
2. Fill in the table on the differences between functional requirements

and non-functional requirements.
Differences
Functional Requirements Non-Functional Requirements
4.2 SYSTEM STAKEHOLDER

You now know about the types of system requirements. Where can you get this
information? Most of the information on the functional requirements can be
obtained from several individuals, known as stakeholders.
Stakeholders refer to individuals who have interests in the information.

system.

In general, stakeholders can be classified into three categories as shown in Table

4.2.
Table 4.2: Three Categories of Stakeholders
Category Description
Users People who use the system daily.
Owners People who own and pay for the system.
Technical Staff People who ensure that the system operates in the organisational
computing environment.
You need to identify the stakeholders who can give you information on the
current system and the new system requirements. Then, ensure that important
individuals in each category can give you contributions as business experts in the
project. What will happen if the stakeholders are supposed to participate but do
not participate in the project? The risk is that, besides the incomplete analysis,
you may also produce a system that does not fulfil the entire needs of users.
Figure 4.1 below shows various types of stakeholders who are interested in the
new system.
Figure 4.1: Types of stakeholders

Source: Adapted from Satzinger et al (2002)

If you are a systems analyst, are you considered a stakeholder? Who are actually
qualified to become stakeholders?
4.2.1 Users
Users can be identified in two ways, which are, horizontal and vertical.
Information gathering horizontally means the analyst searches for information
according to departments, units or functions of the organisation. For example, an
order information system involves several departments in the firm such as
customer service, sales and accounts (see Figure 4.2).
Figure 4.2: Information search horizontally
Customers make orders through an employee at the customer service counter.

The employee records sales to calculate the profits and the particulars of sales are
entered into the firmÊs accounts for balancing. Information from each individual
in the related department needs to be taken to investigate the importance of
system and data flow between departments.
Information can also be searched vertically, that is, according to hierarchy and
management levels in every department. For example, you begin with the
highest post such as the President or the Chief Executive Officer. This is to be
followed by mid-level managers, such as the Vice-President and heads of
divisions. Next, you move down to the operational managers like the supervisors
or heads of units. Finally, you go further down to the support staff like the clerks
and technicians. This hierarchy is illustrated in Figure 4.3.

Figure 4.3: Information search vertically
There are several types of users who use the system such as business users,
information users, management users, executive users and external users (see
Figure 4.4). They need different kinds of information from the same system.
Figure 4.4: Five types of users
These five types of users are further described as follows:
(a) Business Users
Business users use the system for performing the daily operation
activities or functions of an organisation. These daily operations are
also known as transactions.
A transaction is a specific job that is done inside an organisation such as

„register customer information‰, „calculate total sales‰ and „generate
bills‰. System users give information about daily business operations and
how the system can support operations.

(b) Information Users
Information users are individuals who need current information from

the system. Information users can be present inside or outside the
organisation and they include customers.
Information users are normally allowed to see and access information, but
they are not allowed to change and enter information. Information users
help the analyst to know the information that is provided by the system
frequently such as daily, weekly, monthly and yearly, with displays in very
suitable formats.
(c) Management Users

The job of a manager is to ensure that daily business operations of the
organisation are executed efficiently and effectively.
Management users need information that is brief and detailed from the
system.
Managers help the analyst to get information about the types of reports
produced, graphic displays, visual data, total data stored, total transactions
supported by the system, system controls on errors and cheating and total
requests by users about the system.
(d) Executive Users
Executives are made up of managers at the top level. They prepare for
organisationÊs strategic plan for a duration of five, 10 or 20 years.
Executive users need information that is more compact and has more
coverage to help them evaluate the overall organisational performances
and the use of resources. They also need information on the organisationÊs
external environment, such as competitors, industry trends and
technological changes. This can be achieved by linking the system with
several other related systems.

(e) External Users

Access to the system by users who are present outside the organisation can
be made easily via the Internet. This makes it easy for external users like
customers and suppliers to interact, to give and get information from the
organisation quickly and cheaply.
4.2.2 System Owner

Besides fulfilling usersÊ requests, the project team also needs to take into account
the needs of the system owner the individual who provides the budget and
pays for the system. Most of the system owners consist of executives of the
company themselves.
There may be system owners outside the organisation, for example, an executive
from a partner company. The system owner is important in system development
because the project progress report needs to be presented to him, and must be
evaluated by him from time to time, to be endorsed by him, so that the project
can proceed to the following phase.
4.2.3 Technical Staff

The technical staff play a major role in system development. They bring in and
maintain all the technical aspects of the system, such as hardware, software,
network, services and user training. The project team can get the support staff
fully involved or can use their services only when required.
SELF-CHECK 4.2
1. What is meant by „stakeholders‰?
2. List and define the categories of stakeholders who are involved in

fact-finding.
Stakeholder Definition
(a)
(b)
(c)

4.3 METHODS OF DETERMINING

REQUIREMENTS
Determining requirements or also known as fact-finding is placed under system
analysis phase of SDLC. There are several techniques that can be used to achieve
this phase. By means of the structured approach, the analyst documents the
current system before it is used in determining the system requirements.
In the early stages when the structured approach was first put into practice, the
analyst needed to go through four processes, that is to:
(a) Identify physical processes of the current system;
(b) Identify logical processes of the current system, based on the physical
processes;
(c) Build logical processes of the new system; and
(d) Build physical processes of the new system, based on the logical processes.
This approach takes a long time and costs a lot, and hence is not practical to be
used in this information era. This approach can be modified to get a shortcut in
achieving the information system objectives. One of the ways is to re-design the
process to upgrade organisational effectiveness by the use of IT. This technique is
known as business process re-engineering (BPR) which will be further discussed
later in the final subtopic.
Today, the analyst uses an approach that is faster in reaching the current system
and determining the new system requirements. The focus of the analyst today is
to produce a logical model of the new system quickly. This is done by carefully
looking at the current system to understand the business requirements and not to
define the current systemÊs processes in details. Figure 4.5 shows the relationship
between fact-finding and model-building to determine requirements and to build
a new system model.

Figure 4.5: Relationship between fact-finding and model-building

Source: Adapted from Satzinger et al (2002)
The systems analyst builds logical models of the new system following the fact-
finding. The physical models are developed later in the design stage. Logical
models can be developed using various techniques.
4.3.1 Guidelines on Questions

The first step in a fact-finding activity is determining the needed information.
What are the questions to be asked? How to determine requirements? In general,
you need to get information that enables you to build a logical model of the new
system. Figure 4.6 shows the questions that can be asked in order to get the
information.
Figure 4.6: Questions for getting the information

There are many other questions that need to be asked, depending on the size and
scope of the system. However, as a guide, you need to answer five basic
questions during fact-finding work. These basic questions are shown in Figure
4.7.
Figure 4.7: Five basic questions during fact-finding work
To answer those questions, you also need to ask one additional question that is
important, which is „why‰? Examples of the questions that can be asked from
4W1H are shown in Figure 4.8.
Figure 4.8: Examples of questions

There are clear differences between questions that ask „what is being done‰ and
„what can and needs to be done‰. Certainly, the analyst needs to know current
situations beforehand in order to get the picture of what needs to be asked about
the new system requirements.
Table 4.3 shows a guide to the questions that can help you when conducting an
investigation.
Table 4.3: Guide to Questions that Need to be Asked During Fact-Finding
Current System Proposed System

What is performed? Why is it performed? What needs to be performed?
Where is it performed? Why is it done there? Where does it need to be
performed?
Who performed it? Why did he perform it? Who needs to perform it?
When is it done? Why is it done at that time? When does it need to be done?
How is it done? Why is it done like that? How does it need to be done?
Can you differentiate between the ordinary questions and those being used in
your investigation to produce a new system?
SELF-CHECK 4.3
List five types of questions with examples that can be asked in your
search for system requirements.
4.3.2 Analysing Current Procedure and Documents

This step is supposed to be the first step in the activity of fact-finding. To begin
this process, the analyst can request for several documents that are being used in
the current system from users and staff of the organisation. There are three forms
of the main documents that can be analysed work procedures, business forms
and reports (see Figure 4.9).

Figure 4.9: Documents to be analysed by the systems analyst
(a) Work Procedures
Work procedure explains the way a certain job is performed by an

individual or a group of individuals, together with data being used
and information being produced in the job.
Table 4.4 shows an example of the work procedure for preparing

examination timetable.
Table 4.4: Example of Work Procedure
B. PREPARATION FOR EXAMINATION TIMETABLE
Activity Responsibility
1. Distribute circular letter and forms for Deputy Academic Dean,
examination particulars for the course Asst. Academic Officer
offered at the faculty, at week No. 6.
2. Print and distribute drafts of examination Asst. Academic Officer,

timetable to the faculty, at week No.7. IT Officer
3. Update drafts of examination timetable in the Asst. Academic Officer,

computer and print the timetable, at week IT Officer
No.12.
4. Paste examination timetable on the facultyÊs FacultyÊs Assistant Registrar

notice board for students' and lecturersÊ
information, two weeks before examination
starts.
5. Observe and check feedback from lecturers FacultyÊs Assistant Registrar,

and students (if any) and inform the Lecturer,
Academic Section so that final changes can Asst. Academic Officer
be made. If there is no change, examination
timetable is considered final.

Besides giving information, work procedures can show weaknesses of the

current system. The results of analysis of several procedures can show:
(i) The presence of overlap in two or more jobs overlapping jobs need
to be removed before the system design begins. In other words, the
organisation may need to be re-designed before the information
system is developed in order to achieve maximum benefits.
(ii) Procedures that are supposed to be documented are not found.

Management needs to be informed of this in order to take the next
course of action.
(iii) Existing procedures may be obsolete and out-of-date. This can be

tracked during interviews with individuals related to the jobs.
(iv) Work procedures that are written may contradict the information
gathered from the interviews, questionnaires and observation.
Similar to other problems, this can be solved by referring to users and
the management.
The stated four problems actually show the differences between a „formal
system‰ and an „informal system‰.
Formal system is a system that is Informal system refers to the actual

identified by official documentation of way jobs are done in the organisation.
the organisation Informal systems exist because of the
work habit and individualÊs preference,
conflicts and other factors.
The two systems need to be understood to give a picture of the information

and other aspects that are required to change the current system to the new
one.
(b) Business Forms

Forms are another important type of documents for the systems analyst
(see Figure 4.10).

Figure 4.10: Example of a business form
Forms are used in many activities and transactions of the company such as
customer registration, product booking and product delivery. Forms are
important in understanding the system because they state clearly the data
flows coming in and going out of the system and the important data flows
for the systemÊs functions. Let us refer back to Figure 4.10 Book Order
Form. It contains several data items like Order Number, Customer Name,
Book Title, Customer Address, Product Particulars and Order Date.
Forms give important information about the way organisations operate.

With reference to Figure 4.10's form, we know that order number is made
up of a combination of alphabets and numbers. Customers are allowed to
pay in cash or cheque, and the total deposit is 10% of the price of the book
ordered. Handwritten forms show that the payment process and receipting
are done manually. Forms can also be generated from the system according
to monitor displays where data is entered by the staff.
You need to analyse two types of forms one blank form and one form
filled with real data. In Figure 4.10, an order form that has been filled
shows several weaknesses of the form that can be improved before being
used in the new system. Forms can be obtained by requesting from system
users or staff performing related jobs. Ensure that the form to be analysed
is still being used and contains valid data.
(c) Reports
System report is the third type of report that is of no less importance. As
the main output of a system, reports enable us to know which data is
important to produce the report.
Figure 4.11 shows an example of a report generated from a supermarket.
Figure 4.11: Example of a report
This report shows that:

(i) System needs to identify total sales according to product category.
(ii) Date at the top of the report may show that the report is generated
monthly.
Reports are analysed to determine the data required to be produced at

certain durations and which data is being manipulated for producing new
data fields.
If the current system is computerised, the required documents are those

that describe the information system being used how it is designed and
how it works. There are many documents that can be analysed, such as
flow charts, data dictionary, tables, user manuals, purchase agreements of
hardware and software, and CASE tools documentation. Most of the

information systems that have been built in-house do not have complete
documentation.
Business functions can be understood by analysing the above types of

documents. They can also be used to produce interview questions in detail.
Besides that, documents can serve as visual tools during interviews and
documentation work in group discussions. Discussions can focus on
objectives, usage, distribution and information content of the document.
Processes that involve the use of forms and the sharing of forms with
several processes can also be discussed.
SELF-CHECK 4.4
What is the difference between work procedures, business forms and

reports?
4.3.3 Interview
Interview is a very effective technique to understand the function and rules of
business (see Figure 4.12).
Figure 4.12: An interview
However, it takes a long time and uses an expensive resource. In this technique,
the analyst meets with users individually or in a group. The analyst will pose
questions to users about business operations and the current system.

Interviews will be conducted once or more times, depending on the stage of

information already obtained. Interviews will be carried out until all the
information required is understood and documented by the project team.
Thorough planning and preparation are required to conduct an effective

interview. The analyst needs to prepare for orderly steps before, during and after
interviews. Figure 4.13 shows an example of the item list that needs to be checked
in conducting an effective interview.
Figure 4.13: Example of item checklist for interviews
Now, let us try to understand the steps in conducting an interview. There are
three proposed steps in conducting an interview (see Figure 4.14).

Figure 4.14: Three steps in conducting an interview
(a) Preparation for Interview

In preparation for the assignment given by your lecturer, have you ever
been asked to interview someone? If yes, what preparations do you think
are required before an interview session is held?
The success of an interview depends on the preparation made. There are

four steps in the preparation for an interview:
(i) First step in the preparation for an interview is determining the

interview objectives. Objective refers to questions like, „what do you
want out of this interview?‰ Write the interview objectives clearly
and in good order so that you will not forget your objectives.
(ii) Second step is determining the stakeholders, whom you need to ask
for getting information. First and second steps are closely related
where suitable stakeholders need to be selected to achieve interview
objectives. Both steps are important because they determine the
subsequent process together with the final outcome of the interview.
(iii) Interviews involve two parties, who are the users and the project
team. It is better if at least two members are involved in each
interview session. This is because they can help each other during the
interview and they can compare the accuracy of the notes after
completing the interview.
(iv) However, the number of users to be interviewed needs to be limited

up to three persons only, because a large number of users will cause
the discussion to be lengthy and occasionally unproductive. Most of
the interviews are conducted with only one user at a time. Individual
interviews are often done in small and medium-sized projects.

(v) Third step is preparing questions in detail to be used during

interviews. Write all the questions and notes, guided by documents
that have been acquired before the interview. Questions need to be
clear, compact and complete. They also need to be related to the
interview objectives. There are two types of questions that can be
forwarded open questions and closed questions.
Open questions allow users to answer spontaneously in

whatever way that is suitable. Open questions are suitable if you
want to understand a complex process or to get an opinion,
attitude or proposals of the user.
Examples of the open questions are:
Why are you not satisfied with the report produced?
What are the features to be added to the new banking system?
Why do you perform this function in that way?
Closed questions limit the answers to shorter and limited set of

answers, or specific alternatives. Closed questions are asked if
you want information that is more specific, or when you want to
confirm facts.
Examples of closed questions are:
How many employees are there in the information system

department?
Is this report generated exactly on time?
Does this report contain accurate information?
Does this company contain its own website?

(iv) Fourth step is to make an appointment and to inform all those

involved in the interview, with regards to the time and suitable
location. Ensure that the location chosen is far from disturbances.
Every participant needs to know about the interview objectives, and
if possible, give them the questions and the materials that will be
discussed before the interview, so that they can prepare themselves
for it. The interview time can be beneficial if everyone knows what
needs to be asked and answered during the interview.
(b) Conducting Interviews

Various types of feeling may arise before interviews are done. However, in
many cases, users actually like and want to cooperate with the project team
because they want to upgrade the system, and to improve their work
quality. The project team needs to be good at playing its role and in
controlling the situation to make the interview a success. There are several
guidelines that can be followed, such as the ones shown in Table 4.5.
Table 4.5: Guidelines on Conducting Interviews
Guideline Explanation
You need to be Dress can give confidence and present a formal situation to
dressed formally the participants.
and be smart
It also creates first impressions of the image and the
personality of the project team.
You also need to Remember that stakeholders have many other important
arrive at the jobs.
interview location
precisely on time They do not have much time to wait for you.
Limit the interview If there is a lot of information that needs to be discussed

time; do not spend after a long interview, make an appointment for another
too long interview.
Organise for several If you are inundated with information given and the user
sessions of may be too tired to answer more questions, having several
interviews interview sessions will give you an opportunity to analyse
and document information and to request for explanations
on the sections concerned, in the following interviews.

Identify all Ask questions, like „how if‰ or „what if‰, wherever needed.
possibilities of
errors For example:
What happens if the report does not reach the
management?
What happens if the total payment is not confirmed?
What if the system is destroyed or broken into?
Business rules in detail and hidden may be uncovered via

these questions.
Record the notes The analyst needs to get overall information to understand
completely and completely the current situation and to avoid any
with details misunderstanding.
Information can be written by hand or recorded using a

tape recorder. Why not use a laptop computer? Besides
being easy to type and read, you can also edit your records
for references that would be more compact and orderly.
Compact and orderly notes can be the basis for building the
analysis models and guides for subsequent interviews.
Figure 4.15 shows an example of the agenda for an interview session. You can
use it to help in conducting a good interview. This agenda can be modified
according to your needs.

Figure 4.15: Example of the agenda for interview

(c) Interview Follow-up

A follow-up needs to be done immediately after each interview. The
information obtained needs to be understood and documented. Besides the
narrative descriptions, information is normally documented by building a
model of the business process. Check again the result of your interview
with other members of the project team and document the result within 24
hours of the interview. During this period, information remains fresh in the
mind, and any doubts can be solved easily.
There may be questions such as, „what happens if‰ that were asked but
were not answered by users. This question may refer to the policy that
needs to taken into account by the new system, but was not realised by the
management.
Finally, list down the new questions that were left out, or that further
clarified previous questions. These questions can be used for later
interviews.
SELF-CHECK 4.5
What needs to be done before you conduct an interview?
4.3.4 Questionnaires
An interview is a technique that is very effective in getting information and to
interact with related individuals. However, an interview is not practical if it
involves a large number of individuals because it takes a long time, costs a lot,
and only a limited number of questions can be asked. As such, a questionnaire is
the answer to address such problems. Questionnaires can be printed in large
volumes and can be distributed to respondents at a cost that is not too high per
individual.
Respondents will fill in the questionnaires distributed and return them to the
analyst. If the respondents are cooperative, the time taken to fill in the
questionnaire will be short. Questionnaires are suitable for collecting facts
outside the organisation (such as suppliers and customers) and for organisations
that have users at various geographical locations. Questionnaires are normally
done on paper, but today, an electronic form of questionnaires, such as e-mails
and websites are preferred because they are cheaper and faster.

Similar to the interviews, the first step in the questionnaire technique is to

determine the sample or the batch of individuals that represents the entire user
group. Figure 4.16 shows two aspects that need to be described about the
questionnaires.
Figure 4.16: Aspects of questionnaires
(a) Questionnaire Design

Questionnaires have two formats these are the free format and the fixed
format.
Free format consists of space and style that is more flexible for the
respondents to answer. Respondents will answer inside the space
provided, just below the free format question.
Examples of the free format questions are:
(i) What are the hardware and software that you have and how are they
used?
(ii) Do the hardware and software have problems (such as server being
down, network problems, software being attacked by virus or not
functioning)? If yes, explain the problems.
Such responses may be difficult to enter into a table for analysis.

Respondents too may not answer such questions. To get good responses to
the free format, use simple sentences and avoid words that create doubt
such as different respondents may interpret the word „suitable‰ differently.

Fixed format consists of questions that require respondents to choose

an answer from a limited choice. Respondents need to answer based on
the given alternatives only. This simplifies the answer to be collected
for entering into the table.
There are three types of questions in the fixed format these are multiple-
choice questions, rating questions and ranking questions (see Figure 4.17).
Figure 4.17: Fixed format questions
(i) Multiple Choice Questions

Respondents are given several alternative questions. There are
questions that allow respondents to choose one answer. There are
questions that allow respondents to answer in a free format if all the
alternative answers are not relevant to the question. Examples of
multiple-choice questions are:
Does the computer centre provide training for system users?
YES NO
Are you satisfied with information services given?
YES NO
If no, explain
why ____________________________________________

(ii) Rating Questions

Respondents register their opinions about a certain statement by
using the response alternatives provided. The ranking given needs to
be balanced from the number of responses that are positive and
negative. Examples of rating questions are:
(a) Automation of the customer booking system has improved

companyÊs profitability.
Strongly agree
Agree
Not sure
Disagree
Strongly disagree
(b) In one month, how often is the e-mail system attacked by viruses?
Very frequently
Frequently
Not sure
Rarely
Very rarely
(iii) Ranking Questions

Respondents are given several answers to be determined with value/
state according to experience or the respondentÊs choice. Examples of
ranking questions are:
(a) In one month, how many times do your customers send goods
that have been bought to be repaired? ______
(b) What is the percentage profit that you obtain from online
bookings as compared with telephone bookings? ______ %
(b) Follow-up Action

After getting responses from respondents, questionnaires are normally
evaluated and a questionnaire report is produced after the final date of
questionnaires delivery. This is important to enable analysis to be made
according to time that has been fixed.

4.3.5 Observation
Observation of the business process or the current system is another technique
that can be used in fact-finding. By personally looking at the working system in
operation, you can understand better the business process being executed and
you can see the system in a different perspective.
This technique also enables you to confirm information from the interviews
besides ensuring that the business process operates as stated. You may be
shocked to find that information from interviews and current documents are not
practised in the real work situation, when you do the observation.
Proposals made based on observation can increase the confidence of the

management. It also helps you to build good relationships with the staff that
work on the jobs.
Observation can cause operation to become smooth or otherwise. Research shows

that productivity increases when the staff realise that they are being observed.
On the contrary, operations may also become less smooth because the staff may
feel some tension during observation. It is better if you meet with the staff and
their supervisor to discuss your objectives of getting a better working
relationship. In certain situations, you may need to work with the staff to
understand a certain job through the experience that they have gained.
4.3.6 Prototyping
What is meant by prototype?
Prototype is an initial model of a complete system. It represents parts of the

entire system, and so is certainly not a complete system.
A prototype is normally used in the design phase. However, it is also used in

other phases of system development to test the usage and effectiveness of certain
proposals before a complete system is developed.
In the analysis phase, prototypes are used in searching for facts, requirement
analysis and identifying processes.

To determine basic system requirements, you still need to look into the current
documents and to interview users. Prototyping enables you to translate basic
requirements quickly into a small version of an information system. In other
words, requirements in conceptual form can be visualised in the physical form
through prototyping, which is through this mini system. This prototype can be
seen, used and evaluated by users.
Normally, users can see the advantages and disadvantages of the requirements
being presented inside a simple physical system. Users will give comments to be
improved by the analyst based on their experiences in using the prototypes. For
example, during the interview, the user may have said that he wanted all
information dealing with employees, such as their personal particulars, service
records, and loan lists to be placed on the same screen.
However, when he sees the screen being built containing too much information
which makes it difficult for him to read, he may propose that the employee
information be separated according to a certain category on different screens.
Each screen is linked easily via certain buttons. Users may then also realise
several requirements that were not thought of or were left out during the
interviews.
These changes made by users are later incorporated into design prototypes that
follow. After modification, users will see and test the prototype for the second
time. For this second time, you also will change the prototype according to the
user's request. This process will be repeated until users feel satisfied with the
prototype being produced. This process enables you to finally come to a better
version of the system requirements.
Prototypes can be built by using CASE tools and fourth generation programming
language (4GL) such as Visual Basic, Informix and Java.
4.3.7 Joint Application Design (JAD)

Firstly, let us get to know the definition for joint application design (JAD).
Joint application design (JAD) is a technique for determining system

requirements or system design rapidly that involves all the related
participants in a single session.

The period of a single session may last a few hours, few days or weeks,
depending on the number of issues that need to be discussed and the total
information that needs to be obtained.
JAD is a structured process that is participated by up to 10 or 20 users under the

direction of an experienced facilitator. The actual number of participants depends
on the objectives of a specific JAD session. The participants who may get
involved in this session are explained in Table 4.6.
Table 4.6: Participants of JAD Sessions
Participant Description
Facilitator An individual with experience and skills in the conduct of JAD
sessions. He determines the meeting agenda and provides guidance
on discussion, but does not participate in the participantsÊ discussion.
Users Several types of users who have been discussed before can participate
in JAD sessions according to their respective requirements. Normally,
the manager makes the decision on issues being discussed.
Technical Staff Besides handling the tools, hardware and software in JAD, they are
also required to explain the detailed aspects of the technical system.
System This includes the analyst and user experts. They help in discussions,
Development clarification, model building, documenting the results of discussions
Team and ensuring that system requirements are defined clearly. They also
ensure that JAD session objectives are met.
Most JAD sessions are held in rooms that are fully equipped with the necessary
tools and are separated from the participantsÊ workplace, so that discussions can
be take place without interruptions. Meeting room tables are arranged in a
U-shape so that participants can see each other (see Figure 4.18).

Figure 4.18: Meeting room for JAD

Source: Adapted from Dennis and Wixom (2002)
In the front section of the room, there is normally a whiteboard, screen or

projector to be used by the facilitator in conducting the session.
Electronic facilities have been used in JAD sessions to upgrade their

effectiveness. Participants are equipped with computer facilities that are linked
with the network to facilitate analysis, documentation and data sharing. CASE
tools can help to build models and displays visuals of the screen design and
reports.
SELF-CHECK 4.6
Explain the JAD technique and its benefits.

4.3.8 Business Process Re-engineering (BPR)

For your information, the techniques for determining requirements that have
been discussed so far are traditionally used in system development projects that
involve automation of existing processes.
The management of some organisations are looking for new ways to implement
current business processes. These new methods may be different from normal
practice, but the returns may be greater. For example, a reduction of manpower
in executing a certain job, or a better relationship with customers, make business
processes more effective and efficient. All these will bring greater profit to the
company.
This process of re-thinking and re-designing the business process to achieve a

dramatic improvement in terms of cost, quality and services is called „business
process re-engineering‰ or BPR (Hammer et al, 1993). For example, a credit
checking process that took six days before can now be reduced to only four
hours. BPR combines both the strategy of innovative creation and the strategy of
great improvement for business processes to make organisations stronger and
more competitive.
How to achieve this radical improvement? Certainly through information

technology! The use of information technology can correctly have a great impact
on the upgrading most of the business processes. Major successes in BPR have
been achieved by several large companies such as IBM, Proctor & Gamble, Ford
and CIGNA Corporation.
Two steps on how radical improvement can be achieved are shown in Figure
4.19.
Figure 4.19: Radical improvement in BPR

(a) Identifying Processes Needed in BPR

The process that needs to be changed must be understood beforehand.
Prior to that, you need to understand which process represents the key
business process of the organisation.
Key business process is a group of activities (that can be measured)

that produces certain outputs for the customers or for a certain market.
It focuses on products or services and customers of the organisation.
Activities of the key business process include design, building, delivery

and services for certain products or services.
The main tasks in BPR are to understand all activities in the key
business process and then to change the sequence or the structure of
activities in order to upgrade quality, speed and customer satisfaction
radically.
You can use the technique of requirement determination that has been
discussed before to identify and understand the key business process.
Interviews, observation, analysis of current documents and JAD can be
used to search and select the key business process.
After listing the key business process, identify the activities that can be
improved radically through BPR. Three questions can be asked to identify
activities that can be changed:
(i) What is the importance of the activity in producing products and

services?
(ii) If the activity is modified, does it make sense?
(iii) What are the weaknesses of the activity?
The answers to these questions can help you to determine the activities that
need changes. Activities that are considered important (but they have
weaknesses) can be changed these are the main candidates in BPR.

To identify the activities, you need to see:
(i) Whether there are information changes that are not supposed to be
among individuals;
(ii) Information that is recorded repeatedly or needs to be re-enlisted;
(iii) Excessive inventory checking or slow inventory movement; and
(iv) Works that need to be re-done or are too complex.
These activities can be modelled by using most of the tools and techniques
in data modelling, process modelling and others.
(b) Use of Information Technology

After the key business process and its activities have been identified,
information technology (IT) is applied to upgrade the business process in a
radical way. The power and capability of IT need to be known beforehand,
and later to think innovatively on how to change the way work done by
using IT. For example, distributed databases enable information to be
shared by individuals who are located in different places. This technology
can be used to shorten the time to generate reports for each branch of the
company in all states.
SELF-CHECK 4.7
Explain the technique of BPR.
ACTIVITY 4.1
Based on the idea about the processes in re-engineering, try to produce a

conceptual map that can give a picture of the processes that need to be
done.

System requirements are classified into two categories: functional

requirements and non-functional requirements.
Functional requirements consist of the basic business functions that need to

be there in the proposed system.
Non-functional requirements consist of the non-functional aspect of the new

system such as requirements of hardware, software, operating environment
and others.
To determine the requirements, the analyst needs to get the cooperation of a

group of individuals, called the stakeholders. These are individuals who have
interests in the new system. Stakeholders need to be identified for getting
help in determining the system requirements.
Stakeholders are categorised into users, owners and technical staff.
A critical question in determining system requirements is „what information

is needed?‰ As a guide, five basic questions that can be asked during fact-
finding are, what, where, when, who and how. For each question, you also
need to ask one additional question that is important, and this is why.
There are six main techniques that can be used to collect information i.e.
looking at current documents, interviews, questionnaires, observation, joint
application design (JAD) and business process re-engineering (BPR).
A prototype is an initial model that forms part of the real system. Prototypes
are built to test a certain idea. They will be built and tested again several
times until users are satisfied with the outcome.
Joint application design (JAD) is used to speed up the process of determining

system requirements. JAD is organised by getting all the related participants
to get involved in the same session, in which all issues and information are
discussed and agreed on together.
Business process re-engineering (BPR) is a technique that is more radical in

upgrading the business process. BPR re-defines and re-creates the business
process that can provide radical improvement in terms of cost, quality and
services to the organisation. IT plays an important role in changing the
business process in a radical way.

Business process re-engineering (BPR) Owners

Functional requirements Questionnaires
Interviews Questions
Joint application design (JAD) Stakeholders
Non-functional requirements Technical staff
Observation Users

Topic Process
5 Modelling
LEARNING OUTCOMES
1. Identify four data flow diagram (DFD) symbols and rules of using
them;
2. Differentiate notations of DFD;
3. Identify different levels of DFD and their consistencies;
4. Differentiate between logical DFD and physical DFD; and
5. Describe how to document DFD components using standard
descriptions for the processes, data flows, data sources and data
stores.
INTRODUCTION
Fact-finding techniques such as interviews, questionnaires and observation have
already been explained to you. In this new topic, you will be briefed on how the
information or facts that have been obtained are arranged, manipulated and
represented in the form of process models.
„Process modelling‰ is a formal way of explaining how a system operates. It

shows processes, activities, business functions and data flow among them.
Process models can be used to document current systems or proposed systems.
Although there are many process modelling techniques, this topic focuses on the
technique of a data flow diagram (DFD) only. DFD is a popular technique of
illustrating business processes and data flows. In this topic, we will explain the
definitions and symbols of DFD, followed by examples, rules, details and
balancing the DFD.

TOPIC 5 PROCESS MODELLING 105
5.1 DATA FLOW DIAGRAM (DFD)

The focus of data flow diagrams (DFD) is to model the „business process‰, even
though the name contains the word „data‰. Data modelling has been discussed
in the previous module on database. Do you still remember? Process modelling
or DFD construction is an important skill of the systems analyst.
DFD is categorised into two sections, which are logical and physical.
Logical DFD shows what processes are operating inside an organisation without
touching on how the processes are implemented. Physical DFD, on the other
hand, explains how the processes are actually implemented. Physical DFD must
be consistent with logical DFD.
For example, a logical DFD for the Airline Reservation System contains a ticket
booking process and a ticket issuing process. A physical DFD for this system
shows the way both processes are implemented, such as the ticket booking
process via the telephone and ticket printing from the computer system. Take
note that this topic emphasises on the logical DFD.
A logical system does not provide information on whether:
(a) A certain process is implemented manually or by the computer;

(b) Data is stored in paper files or on floppy discs; or
(c) Data is obtained via telephone or e-mail.
Why do you not need to know all these technical aspects? Well, the objective of a
logical diagram is to let you understand the processes needed for the business so
that you can define the system requirements correctly and think about the
process implementation in detail at a later stage. Process implementation will be
defined in detail in the design phase of SDLC by translating the logical models
into physical models.
5.1.1 DFD Symbols

DFD has four symbols to represent. They are:
(a) Process;
(b) Data flow;
(c) Data store; and
(d) External entity.
106 TOPIC 5 PROCESS MODELLING
DFD contains several different types of notations but each type has the same
objective and set of elements. This topic uses a popular DFD notation known as
Gane and Sarson. Another popular notation is Yourdon, which is also often used
by the analysts. Figure 5.1 shows the four DFD symbols that are used by both
notations.
Figure 5.1: DFD symbols from Gane and Sarson notation and Yourdon notation
Now let us learn more about the main components of DFD.
(a) Process
Process refers to an activity, function or task that is done to achieve

organisational objectives whether directly or indirectly. A process can
be manual or computerised.
Process has a name, which consists of a verb plus a noun, for example
Register Student and Generate Report. The noun needs to be short but
easily understood. In general, each process performs one activity.
Therefore, try to avoid using comma and „and‰ because they show a
process performing more than one activity.
Each process has input data to be processed, from which it will generate
output data. Output is different from input in terms of content and form or
both. For example, the „Calculate Pay‰ process requires „Employee No‰ as
input data and this will produce „Pay Slip‰ as output data. Another

process, called „Sort Marks‰ has „Mark List‰ as input data and „Sorted
Marks‰ as output data.
(b) Data Flow
Data flow consists of data that is moving or flowing as input to a

process or as output from a process.
Data flow inside DFD can represent something like Name, Matrix No and
Faculty. Data flow is labelled with a name that is made up of a noun or a
combination of a noun and an adjective, if required. Other examples of data
flows are Payment, Customer Order and Confirmed Order.
(c) Data Store
Data store is used to show data at rest. It is a situation in which data is

stored to be used by processes inside a system, when needed.
For example, a doctor stores all patient records to be referred to when a

patient comes to get a medical examination. The name of a data store is
chosen according to the information or data being represented. Therefore,
try to use a noun or a combination of a noun and an adjective, if required.
Examples of data stores are Student File, Customer File, Treatments,
Confirmed Orders, and Stock Database.
Data flow coming out of a data store shows that information is retrieved
from the data store, while data flow going in shows that information is
inputted (or record being added) into the data store. Data flowing in and
out can represent the same data.
Each data store must have at least one input data and one output data. If
there is no input data, then how can you output the data? If there is no
output data, then the data store does not function, because it is not being
used by the system.

(d) External Entity
External entity consists of individuals, institutions, units, departments,

organisations or information systems that are present outside the
system, but are interacting by giving input or getting output from the
system.
The word „external‰ means that entities are located outside the system, but
entities can be located inside or outside of the organisation. Confusion
often occurs when determining entities that are supposed to be external
entities.
Errors in assigning individuals or objects inside the system as external

entities are common. Individuals who execute the process inside the
system, like clerks who input data or workers who arrange inventory, are
internal entities. Internal entities are normally stated inside process
descriptions.
Examples of external entities are: Account Executive of the Account

Department who inputs employee data to the Human Resource System;
and Manager who receives reports from the Customer Order System.
External entities are labelled according to the names that represent them.
Other examples of external entity names are Doctor, Customer, University
and Student Information System. External entities show the boundaries of
the system and how the system interacts with the outside environment. For
example, suppliers who supply raw materials to the inventory system are
the external entities that provide input data to the system. Customers who
receive invoices and products are considered external entities that receive
output data from the system.
External entities play two roles as sources and as destinations. External

entities are called sources if they give input data to the system and they are
called destinations (or sinks) if they receive output data from the system.
The roles of external entities are summarised in Table 5.1.

Table 5.1: Roles of External Entities
External Entities
Source Destination (or sink)
To give input data to the system. To receive output data from the system.
Take note that external entity can become a source or a destination or both.
SELF-CHECK 5.1
Based on your understanding, try to explain the meaning of process,

data flow, data store and external entity.
ACTIVITY 5.1
Explain briefly what are represented by the following four symbols:
5.1.2 DFD Rules

There are several guidelines that need to be followed while drawing a DFD.
These guidelines need to be checked to ensure that the DFD drawn is correct. The
guidelines for all the four DFD symbols have been summarised as in Table 5.2
below.

Table 5.2: DFD Rules
DFD Symbol Description

Process Process cannot contain output only. Output cannot be produced
without input. This situation is known as a miracle.
Process cannot have input only. If input only, then what is

produced by the process? This situation is called a black hole.
Process needs to use suitable input to produce output. Is the

input „Account No‰ enough to process „Withdrawal Of Cash‰
to get „Cash‰ output? This is called a grey hole.
Data Store Data cannot flow from one data store to another data store
without going through a process.
Data store cannot be linked directly to an external entity via data

flow. There must be a process in between, to process data flows
from an external entity to data store and vice versa.
External Entity External entity cannot be linked directly to another external

entity via data flow. Data flow from one external entity needs to
be processed first and the output of this process can be linked to
another external entity.
Data Flow Data flow that links a process to a data store has only one
direction. Data flows are only allowed to have two directions
when a process is linked to a data store for showing data being
retrieved before being processed.
Data flow that has branches shows that data from the same
source flows to several processes, data stores, or external
entities. Normally, in this situation several copies of the same
data are sent to different locations.
Several data flows being combined show that data from different
sources flow into the same location.
Data flowing out cannot flow back to the process that produces
them. This data flow needs to go through another process first
before being sent back to the earlier process.
Figure 5.2 shows an illustration of the right and wrong ways of drawing DFD.

Figure 5.2: Right and wrong ways to draw DFD
Besides the rules stated in Table 5.2, there are three general guidelines that can be
used:
(a) Input to a Process is Different from Its Output

As stated previously, input and output to a process are different in terms of
form or content, or both. This is because a process aims to change input to
output not to merely transfer data without any change. What may
happen is that the same input goes in and then comes out of a process, but
the process also produces an additional output (a new data flow) as a result
of processing the input; this is fine.

(b) DFD Symbols Contain Unique Names

To avoid confusion and error, DFD symbols are named uniquely. If there
are two processes that share the same name, then how can you differentiate
between the two?
(c) Use a Unique Reference Number

Besides using a name, a process is also labelled with a unique reference
number.
SELF-CHECK 5.2
What do you understand by black hole, grey hole and miracle?
5.1.3 Details of DFD

As you know, DFD contains a number of business processes that are present
inside an information system. Each business process is linked via a data flow to
another process, external entity or data store. Each process can have other sub-
processes. Imagine how difficult and congested the DFD would be if all these
elements are placed inside one DFD. To simplify your drawing and to simplify
the usersÊ understanding of DFD, the diagram is divided into several levels,
beginning from DFD of the highest level to DFD of the lowest level.
The highest level of DFD is known as context diagram, which represents the
entire information system. DFD of lower levels show details of the business
process inside several series of DFD. Figure 5.3 shows a business process being
detailed into several DFD levels.

Figure 5.3: Detailing and linking DFD
The process inside the context diagram is labelled as process 0, to show that the
process represents the entire system. Detailing process 0 (the context diagram)
brings us to the building of DFD of the lower levels. The processes coming out of
the decomposed process 0 are labelled as Process 1, Process 2, Process 3 and so
on this is called Level-0 DFD.

Similarly, decomposing any process inside Level-0 DFD, for example from
Process 2 to become Processes 2.1, 2.2, 2.3 and so on would create Level-1 DFD.
Upon further decomposing any process inside Level-1 DFD, for example from
Process 2.2 to become Processes 2.2.1, 2.2.3 and so on would become Level-2
DFD. Indeed, the process can go on until the analyst feels that he has
decomposed and simplified enough for data flow diagramming.
(a) Context Diagram
Context diagram shows the boundary and scope of the system and
how the system interacts with the external environment. Context
means the context in which the system sits.
Every process model begins with a context diagram. A context diagram has
only one process, which is labelled as "information system" (see previous
Figure 5.3). This process is linked to several external entities via data flows.
How do you determine which entity to put in? By checking the system
requirements, you can know the external entities that serve as the sources
and destinations for the system. Data store is not shown in the context
diagram because data stores of the system are conceptually embedded
inside the one process.
(b) Level-0 Diagram

Similar to the context diagram, Level-0 DFD also shows the entire system
components in one diagram. The objective now is to show the main system
processes only. The processes are labelled as Process 1, 2, 3 and so on.
All the external entities, data flows and data stores that are related to the
processes are shown in this diagram. Every process model has only one
Level-0 DFD.
Besides the details, another important aspect in drawing DFD is

consistency.
Consistency means every input and output data flow at a higher level
of DFD is retained at the lower levels to ensure that the diagrams are
consistent and balanced.

Observe that, in the previous Figure 5.3, every data flow at a higher level is
present at a lower level.
On the other hand, Figure 5.4 shows DFD that is not consistent with the
addition of Source-2.
Figure 5.4: DFD that is not consistent

Source: Adapted from Hoffer et al (2002)
With this explanation, it is hoped that you have understood the concept of
DFD that is consistent and balanced.
(c) Lower Levels DFD

The processes inside Level-0 Diagram are further decomposed into sub-
processes of greater detail in the next level of DFD; Level-1 Diagram.
Processes in Level-1 Diagram are labelled with a kind of numbering, such
as for Process 1, it is now labelled as 1.1, 1.2, 1.3 and so on; while for
Process 2, it is labelled as 2.1, 2.2, 2.3 and so on; and similarly for Process 3,
4 and so on.
Where do we stop detailing the DFD? We will stop at a process that is

simple enough and cannot be decomposed into sub-processes anymore.
These simplest processes are called primitive functions, which will be used
by programmers to write the program codes. Examples of primitive
functions are Print Report, Record Booking and Calculate Bill.

No matter how complex and how many levels of DFD you draw, you need
to take into account the concepts of decomposition, balancing and
consistency that have been explained above, in order to ensure the
production of correct DFD.
SELF-CHECK 5.3
What do you mean by DFD that is consistent and balanced?
5.1.4 Guidelines on Drawing DFD

To model a process, in the first place, we need to understand the process concept.
A system is made up of several processes and each process again is made up of
other processes or sub-processes. This concept has been illustrated before.
Now, we will see further how a system is decomposed into processes and sub-
processes, together with the relationships among them. This is important in
helping you to determine what processes are to be modelled inside a DFD.
A system is decomposed into processes and a process is further decomposed

into sub-processes this process of decomposition continues until you reach
the very simple processes, known as primitive functions.
This process of decomposition aims to see a system as a whole, beginning with

an overall picture until the stage that is very simple. This process decomposition
can be treated as a guide in building DFD from the highest level (context
diagram) until DFD at the lowest level (primitive DFD). This technique of
splitting the process is known as „process decomposition‰. Decomposition
diagram shows a popular decomposition technique. It is also called a „hierarchy
chart‰. Figure 5.5 illustrates an example of a decomposition diagram.

Figure 5.5: Decomposition diagram
Besides the decomposition diagram, you can also list every business activity
related to the system. These activities can help you to identify processes, external
entities and data stores that need to be modelled in a DFD.
When you can define the relationships among the systemÊs processes and sub-
processes, you can then begin to draw the DFD. There are two approaches that
can be used by the analyst in drawing a DFD, that is:
(a) Top-down Approach

The context diagram is drawn first, followed by Level-0 Diagram, Level-1
Diagram, until you reach the primitive DFD diagrams.
(b) Bottom-up Approach

The primitive functions are identified first, a combination of these primitive
functions forms the lowest level DFD, called the primitive DFD. This is
followed by DFD at higher levels until you reach the context diagram.
Whichever approach you choose, you need to follow DFD rules that were
explained earlier. The DFD produced needs to be checked for validity by users of
the system.

ACTIVITY 5.2
Try to produce a context diagram following the top-down approach for

any system that you wish to develop.
5.1.5 Example of DFD

Now let us look at an example on how to draw DFD. Let us see an Order System
for a company, Suria Pewter Sdn Bhd, which receives bookings for pewter and
carvings via the telephone, catalogue or website. This Order System has a
business process as follows:
(a) A customer placing an order is recorded in a customer file and is then

given a unique customer number. This number is used in all transactions
related to the customer.
(b) The customer order is processed by confirming all the information given to
be correct and the product ordered by him is in stock.
(c) Orders that have been confirmed are sent to the factory.
(d) Prepare an invoice based on the order that has been confirmed.
(e) Customers who make payment in cash, cheque or credit card are receipted.
Order information is also used to provide monthly reports that are sent to
the companyÊs Accounts Department.
Let us learn more on these business processes in the next section.
(a) Context Diagram

Context diagram for this scenario is shown in Figure 5.6.

Figure 5.6: Context diagram for Suria PewterÊs Order System
Since the system deals with customers, data flows between customers and
the system are more than those for other external entities. The context
diagram is brief when you compare it with DFD of the lower levels. Can
you understand the Suria PewterÊs Ordering System by looking at its
context diagram?
(b) Level-0 DFD

To accurately draw a DFD, identify all the information needed for the
system. For example, for each process, you can ask the following questions:
(i) What inputs are needed?

(ii) What outputs are generated?
(iii) Is the information is stored?
(iv) What are the sources and destinations of the data?
A list of activities for the Order System can be detailed further by

determining all the related processes, inputs, outputs, sources and
destinations. The process components are listed in Table 5.3:

Table 5.3: Process Components of the Order System
Process Components of the Order System

Process Input Source Output Destination
1. Receive Customer Customer Order Customer,
Order Order Confirmation Factory
2. Register Customer Customer Customer Data Store
Customer Detail Record (Customer)
3. Prepare Product Factory Invoice Customer
Invoice Confirmation
4. Receive Payment Customer Data Receipt Customer
Payment Invoice Store
(Customer)
5. Generate Customer Data Store Monthly Accounts

Monthly Record (Customer) Report Department
Context diagram is now expanded into the Level-0 Diagram, which

contains the main processes of the Order System (see Figure 5.7).

Figure 5.7: Level-0 diagram for Order System
Observe that every major activity is modelled as one process. To translate

activity into process, it needs to be seen as a task that is implemented in the
system. How is the „Customer Makes Payment‰ activity being translated
into a process? This can be translated by looking at the roles of the system
in realising the activity. This activity really looks the same as the Receive
Payment process as seen from the system's point of view. Each process is
then analysed to determine the input data flows and output data flows as
well as the external entities and data stores concerned.
Observe that Level-0 Diagram is consistent with the context diagram,

because the expansion done is balanced. Every input data flow and output
data flow has been moved from the context diagram into the Level-0
Diagram. Processes in Level-0 Diagram are labelled as Process 1, 2, ⁄ 5
they do not have to be in sequential order. Besides that, all the external
entities are the same for both diagrams no addition and no reduction.

What do we have to do after drawing Level-0 Diagram? Apart from

checking the preciseness and consistency, we need to identify processes in
Level-0 Diagram that need to be expanded into Level-1 Diagram.
Let us now see what happens in Process 1 Receive Order. This process
can be decomposed into two sub-processes: Confirm Order and Prepare
Confirmation Notice. So the sub-processes are labelled as Process 1.1 and
Process 1.2. Existing external entities (Customer and Factory) and data
store (Product) are passed down from Level-0 Diagram into Level-1
Diagram. Similarly, existing data flows are passed down too.
However, there is an additional data flow (Order Status) in between

Processes 1.1 and 1.2 being added in as a result of the emergence of the two
new sub-processes. Let us refer to Figure 5.8 for details.
Figure 5.8: Level-1 diagram for „receive order‰ process (of order system)
5.2 LOGICAL AND PHYSICAL DFD

As described very much earlier, there are two types of DFD logical DFD and
physical DFD. A logical DFD explains business operations without touching on
how the operations are implemented. A logical DFD only shows what processes
and data are involved. A physical DFD, on the other hand, shows how the
system is implemented, by stating the individuals, the software and other
aspects. Table 5.4 shows the differences in characteristics between the logical and
physical DFD.

Table 5.4: Differences between Logical and Physical DFD
Characteristic Logical DFD Physical DFD

Model How the system How the system will be implemented.
operates
Process Data content Program, module of program and manual
procedure.
Data Store Data content Program, module of program and manual
procedure.
Data Flow Data flow content Format of the data flow content.
Which DFD needs to be drawn first? Well, there are actually four types of DFD
being used in structured system analysis and design current physical DFD,
current logical DFD, new logical DFD and new physical DFD. It was originally
argued that all the four types of DFD should be drawn in that order.
However, many experts today think and recommend that the focus should be on
the new logical system. If the analyst knows very little about the user's business,
then it is fine to create a set of current physical DFD just to get a good overview
of the current system (Hoffer et al, 2002).
So, once you have understood the system fairly well, with or without the DFD of
the current system, you should then focus on drawing the logical DFD for the
new system in great detail, during the analysis phase. This will enable you to
produce a complete set of the physical DFD of the new system, based on your
implementation plan, during the design phase.
Figure 5.9 shows an example of the logical and physical DFD for a Sale System of
a supermarket. Customer brings items to the cashier counter. The cost of each
item is checked and totalled. Payment is made to the cashier. Finally, the
customer is given the receipt. Logical DFD only shows what sales processes are
involved without clarifying how the processes are implemented. Through a
physical DFD, customers can know that processes are realised by checking the
UPC Code using the scanner and payment is received in the form of cash and
cheque.

Figure 5.9: Example of logical and physical DFD

Source: Adapted from Kendall and Kendal (2002)
SELF-CHECK 5.4
What are the differences between logical and physical DFD?
Differences
Logical DFD Physical DFD

5.3 DOCUMENTING DFD COMPONENTS

How do we document DFD components? Documenting components of DFD;
process, data flow and data store, are further explained by using several
techniques as described in the following subtopics.
5.3.1 Process Description

Process descriptions would document the primitive functions; the processes that
have been decomposed until the simplest form inside the DFD. Process
descriptions can be done in the following three ways:
(a) Structured English;

(b) Decision Table; and
(c) Decision Tree.
Each of these three ways describes the process by using algorithms, and the
choice depends on suitability ease of understanding, accuracy and clarity
provided.
(a) Structured English
Structured English explains the logical process by using simple

sentences in English language.
The language structure is simple and clear. It describes the process logic
precisely in sequence. Normally, structured English uses:
(i) Statements in the form of sequence, selection and repetition.
(ii) Indentation, which provides the structure so that it is easy to

understand.
Examples of the structured English are shown in Figure 5.10 and Figure
5.11. Observe that several keywords are written in small letters like If,
End, For, Else and others to explain the process logic.

Figure 5.10: Example of process description for „Order Confirmation‰

Source: Adapted from Shelly et al (2000)
Figure 5.11: Example of process description for „Receive Commission‰

(b) Decision Table
Decision table shows a logical structure consisting of a combination of

all process conditions and actions.
In certain situations, it provides the logic in a form that is shorter when

compared with structured English. A decision table is more suitable for
representing very complex logic. It is sometimes used to check the accuracy
of logic that is written in structured English.
Figure 5.12 shows a decision table for the „Order Confirmation‰ that is
equivalent to Figure 5.10. Based on the given structured English (Figure
5.10), we find that the condition for receiving an order is Credit Status
being OK, and the product is in stock. If both conditions are not fulfilled,
the order is rejected. All the conditions and actions are based on whether
the conditions are fulfilled, as shown in Figure 5.12.
Figure 5.12: Example of decision table for „Order Confirmation‰ process

Since every condition has two values (Yes or No), the number of rules is
doubled for each condition added. For example, one condition has two
rules, two conditions have four rules, four conditions have eight rules and
so on. As you can see in Figure 5.12, there are four rules because there are
two conditions.
The following steps can be adopted in building a decision table:
(i) Place all the process conditions in the first column at the left of the
table with one condition at each row.
(ii) Place all the process outcomes after the last line of conditions at the
first column on the left of the table with one outcome on each line.
(iii) Enter all the combinations Y (for yes) or N (for no) for each condition.
The columns after the condition column represent all the probabilities
that are called the rules.
(iv) Mark with an X at each column in the outcome row for each
condition concerned.
Let us try to build a decision table for the „Pay Commission‰ process based
on the steps given. Then, compare your result with the decision table in
Figure 5.13. Take note that there are two conditions for the „Pay
Commission‰ process: Extra Bonus and Total Payment Being More Than
$50,000.

Figure 5.13: Example of decision table for „Pay Commission‰ process

SELF-CHECK 5.5
Describe a process using structured English and a decision table.
(c) Decision Tree

For your information, decision tree is quite similar to the decision table.
Both represent the same elements (condition, action and rules) but in
different forms one in table form, and the other in graphic form.
Decision tree shows a logical structure, which appears like a tree.

Beginning with root and stem on the left, it expands into branches and
leaves towards the right.
Decision table in Figure 5.13 is now shown as a decision tree in Figure 5.14.

Figure 5.14: Example of decision tree for „Pay Commission‰ process

A decision tree is read from left to right, beginning with conditions and
followed by rules for the conditions. Observe that Figure 5.13 has four rules
because there are two conditions. The tree ends with four actions.
5.3.2 Description of Data Flow

Data flow is a collection of data elements. Therefore, data flow description
involves a listing of all these data elements. For example, data flow "Student"
contains data elements like student name, address and field of study. Some of
these data elements contain other data elements. For example, student address is
made up of road, town, postcode and state. Most of these data flows are
documented so as to be consistent with entities defined in the Entity-Relationship
Diagram (ERD).
There are also data flows with a more complex structure; they may consist of a
combination of several other data flows. With several types of notations in the
description of data flows, one notation is by listing all the data elements like the
one shown in Figure 5.15.

Figure 5.15: Description of data flow by listing the elements
Data flows can also be documented by using algebraic symbols (like plus sign) to
describe that they are made up of several other data flows. For example,
Examination Result is made up of Semester Code, Faculty Code, Matrix Number,
Student Name, Course Code, Grade and CGPA (see Figure 5.16).
Figure 5.16: Description of data flow using algebraic symbols
5.3.3 Description of Data Elements

Description of data elements explains the types of data such as characters,
numeric or Boolean. Data elements also need to be defined to describe what is
represented by them. There are data elements that use short names and there are
those that are elaborate. For example, Status of Study is made up of pass,
warning or fail, and terminated.
Size, validity value, maximum and minimum values, fixed value for data
elements are also explained in data dictionary. For example, Customer Code of
character type and its length is at least five and not exceeding 20 and must begin
with A, B or C. Alphabet „A‰ means customer is made up of individuals and
alphabet „B‰ means the customer is made up of companies. Several examples of
data elements are shown in Figure 5.17.

Figure 5.17: Description of data elements
5.3.4 Description of Data Store

Normally, data store is not described any further, because data store inside a
DFD represents data entity inside ERD. If DFD is not linked to ERD, then data
store is defined as a collection of data elements, similar to the description of data
flows.
A data flow diagram (DFD) describes the entire system in graphic form that
is easily understood. DFD shows the main components of a system with
processes, data flows, data stores and external entities.
The general overview of the system can be seen through the context diagram
the highest level DFD. Details of the system are then shown by DFD at
lower levels, beginning with Level-0 DFD, followed by Level-1 DFD, Level-2
DFD, and so on until the Primitive DFD DFD with all the simplest processes
that cannot be decomposed anymore. The DFD drawn must take into account
the concepts of decomposition and consistency to ensure that the diagrams
are correct.
A logical DFD explains business operations without touching on how the

operations are implemented. It only shows what processes and data are
involved.

A physical DFD, on the other hand, shows how the system is implemented,
by stating the individuals, the software, and other aspects.
After DFD has been checked for validity, its components like processes, data
flows and data stores are documented using a number of techniques.
A process is described using several techniques like structured English,

decision tables or decision trees. A data flow is described by listing the data
elements contained inside it, or by using algebraic symbols to describe data
structures that are more complex. Data elements and data stores can be
described by listing their types, length and the meaning of the data
concerned.
Data flow Logical DFD

Data flow diagram (DFD) Physical DFD
Data store Process
Documenting Rules
External entity Standard description
Levels Symbols

Topic System
6 Design
LEARNING OUTCOMES
1. Identify three approaches to the creation of new systems;
2. Describe how to choose a design strategy;
3. Explain the method in building the alternative matrix; and
4. Summarise the steps in creating the physical data flow diagram
(DFD) and physical entity-relationship diagram (ERD).
INTRODUCTION
For your information, the objective of the system design phase is to re-look at the
business requirements, which have already been identified in the analysis phase
and to proceed with making decisions that fulfil these requirements.
During the initial part of the design phase, the project group changes the logical
diagrams of the analysis phase into the physical diagrams that explain how the
system will be built. All the documentation and diagrams become the inputs to
the steps of the design phase.
For example, the logical data flow diagram (DFD) and logical entity-relationship
diagram (ERD) will be changed into the physical DFD and physical ERD. During
the entire design phase, the project group should be careful to consider the new
system in the context of its environment and the current system.

134 TOPIC 6 SYSTEM DESIGN
This topic will also evaluate the basic approaches to developing a new system; to
build, to buy or to outsource. Then it will explain the movement in the DFD and
ERD from logical to physical, and the development of a new design for the new
system.
6.1 DESIGN STRATEGY

There are three approaches in creating a new system, these are:
(a) „Custom in-house‰ application system development;
(b) Buying an application package and customising it; and
(c) Outsourcing (getting external suppliers or service providers to develop the

system).
Please note that each alternative comes with its own strengths and weaknesses.
Therefore, one alternative is better than the others in different situations.
Now let us learn more about these three approaches in the next subtopics.
6.1.1 Custom Development

Do you know that most of the project groups consider custom development as
the best approach to develop a system? This is because the team has complete
control over the functions and shape of the system.
Custom development or developing a new system from the beginning allows

the development to become more flexible and creative in solving business
problems.
In-house system development will assist in:
(a) Increasing the technical skills and knowledge of the developers who work
together with the business users in the company;
(b) Understanding of business development that will make them more skilful
in organising the information system requirements and strategy; and
(c) Projects that use the same technology by making them easier to develop in
future.

TOPIC 6 SYSTEM DESIGN 135
Despite the stated points, custom application development requires intensive

focus like hard work and takes up a lot of time. Most companies have their own
development people who are ready to be committed to fulfilling their request for
a new system, even if they do not have time for many projects. Various skills like
technical, interpersonal, functional and modelling skills need to be provided in
ensuring that a project would continue without interruption.
However, system development from beginning to end has a high risk. This is
because:
(a) No guarantee that the project would be successful;

(b) Developers may get involved in other projects too;
(c) Technical incompetence can slow down system development; and
(d) Business users have no patience to wait for a long development time.
6.1.2 Application Package

Take note that most of the business requirements are not unique. Users can buy
application packages as opposed to developing their own solutions. There are
thousands of commercial software programs that have been developed to fulfil
various human needs in life.
Have you ever considered developing your own word processing software? An
effort to develop your own word processing software may be a loss because there
are various software packages that are already in the market and can be used.
Buying a software package is a wise decision because:
(a) Programs have been created, tested and proven;
(b) Purchased application packages can be installed in a short period

compared with custom system development; and
(c) An application package includes expertise and distribution from the

supplier that created the software.

However, if your company buys an application package, the following problems

need to be accepted:
(a) You need to accept the functions provided by the system;
(b) The package normally does not provide all the companyÊs needs; and
(c) The package that has a big scope can lead to changes in business functions.
The scenario that allows technology to change your business functions may
endanger the business industry.
Most of the application packages allow customisation or manipulation of system

parameters for changing certain functions. These changes are good in creating
functions that are needed, but the said functions my not be present inside the
software package. This is called system integration.
System integration refers to the process of developing a new system by

integrating or combining a software package, an existing legacy system and a
new software.
Many companies are skilful in system integration. It is not impossible for a

company to select software packages and then to outsource the job of integrating
various packages to the consulting companies.
6.1.3 Outsourcing
The last alternative design approach that requires a little in-house resource is
outsourcing. What does it mean?
Outsourcing means paying an external supplier to develop or to provide

services for creating a system.
There are many advantages to allowing other parties to develop your system.
Those parties may have a lot of experience in technology or may have a lot of
resources like programming experience.

If outsourcing is chosen, a number of things need to be observed, such as:
(a) CompanyÊs confidential information may leak out;

(b) Control over future development may be lost;
(c) In-house development skills cannot be upgraded; and
(d) Development skills go to other parties.
Thus, there are many risks if outsourcing is chosen. To reduce the risks, the
following steps need to be taken:
(a) Identify your project requirements completely. Do not outsource something

that you do not understand at all.
(b) Choose your suppliers and developers carefully and check their service
records to see proof of the system and the technology that you need.
Figure 6.1 shows you three types of contracts that can be implemented to control
outsourcing contracts.
Figure 6.1: Three types of outsourcing contract
Further explanation on these types of contract are given in Table 6.1.

Table 6.1: Types of Contract
Contract Type Explanation

Time and Expenses This type is very flexible because you agree to pay for the time
Agreement and expenses incurred to complete the job. However, this
agreement can lead to a high cost and can exceed estimated cost.
Added Value This contract appears to be the most popular. The contractor
Contract receives a percentage of the added value after the system has
been completed. You have a small risk here, but you need to
share the benefits after the system is implemented.
Fixed-Price Contract This means you do not have to pay beyond the estimated cost. If
the contractor spends more than the agreed cost, he has to bear
the cost. So the contractor will fix the needs clearly. Any change
or addition is difficult to entertain.
Creating a fair contract is an art. This is because you need to balance the
requirement flexibility and the clear definition. Requirements will change with
time, but changes to the requirements cannot be made if the contract is too
detailed and limited. You can refer to Table 6.2 for the guidelines to outsourcing.
Table 6.2: Guidelines to Outsourcing
1. Ensure that communication between you and the outsourcer (contractor) is always
active.
2. Define and balance up the requirements before signing the contract.
3. Be of the view that outsourcing is a form of partnership.
4. Select the supplier, developer or service provider with care.
5. Assign someone to manage the relationship.
6. Do not outsource something that you do not understand.
7. Emphasise flexible requirements, long-term relationships and short-term contracts.
Source: Adapted from Dennis, Wixom and Roth (2012)
SELF-CHECK 6.1
What are the differences between time and expenses agreement, fixed-
price contract and added value contract?

ACTIVITY 6.1
Try to think of three approaches in creating a new system. What are the
advantages and disadvantages of each approach?
6.2 CHOOSING A DESIGN STRATEGY

Each design strategy has its advantages and disadvantages. Therefore, before
choosing a design strategy, you need to consider certain factors like the ones
shown in Figure 6.2.
Figure 6.2: Factors involved before choosing a design strategy
These five factors shown in Figure 6.2 are further explained in Table 6.3.

Table 6.3: Five Factors of a Design Strategy
Factor Description
Business If system requirements are normal and technical solutions already exist
Requirements in the market, which can fulfil the systemÊs requirements, it is not
reasonable to develop a custom application. Getting an application
package is therefore the best alternative in fulfilling most of the business
requirements.
On the other hand, if the business requirements are unique and specific,
a custom development alternative needs to be studied. Outsourcing is
the best alternative if the business requirements are not critical.
In-House It would be easy to develop a custom application if in-house experience

Experience is sufficient to fulfil all the systemÊs functional and non-functional
requirements. A system package is a better alternative for companies
that do not have technical skills in building the required system.
Outsourcing is also a good approach in bringing outside experiences

that are absent inside.
Project Skills The skills required to implement a project are functional and technical
in nature. Different design alternatives are possible depending on the
strategic skills present inside the company. A few skills like network
security may go beyond the technical skills, and this may not be part of
the company strategy. Therefore, skill is largely an operational issue.
In this case, a system package or outsourcing needs to be considered so

that the companyÊs staff are more focused on the skills and applications
that are more critical.
Project Custom applications need efficient project management and a proven

Management methodology. There are several reasons that can cause projects to be
halted like insufficient funds, workersÊ lack of motivation and
unreasonable requests by users.
Therefore, the project group needs to choose custom application

development only if coordination at the lower level and the control
mechanism will be present at the right place.
Time Frame When time becomes a factor, the project group needs to look for a
system that has been built and tested. In this way, the company will
have a good idea of the time frame needed by the package to be placed
at a fixed location and what will be the final content.
If you need to choose custom development, consider the technique of

time boxing for managing the problem of insufficient time. The time
required to build a system via outsourcing depends very much on the
system and the resources owned by the outsourcer (contractor).

Lastly, for easy and quick referencing, we can summarise the choice of design
strategies as in Table 6.4.
Table 6.4: Choice of Design Strategies
When to Use
When to Use a When to Use
Needs Custom
Software Package Outsourcing
Development
Business Unique business Normal business Requirements are

requirements. requirments. not important to the
business.
In-House Skills In-house technical In-house functional In-house functional

and functional experience is and technical
experience is present. experience is absent.
present.
Project Skills There is a need for Skills are not Decision to

building in-house strategic. outsource is a
skills. strategic decision.
Project There is a very There is a project There is a project

Management experienced project manager who can manager in a highly
manager and a coordinate skilled organisation
proven suppliers. and is suitable for
methodology. the scope of
outsourcing
agreement.
Time Frame Time frame is Time frame is short. Time frame is short
flexible. and flexible.
6.3 DEVELOPING A DESIGN PLAN

Keep in mind that after you have understood every design strategy that fulfils
project requirements, you now need to start thinking about the ways to
implement the strategies. For example:
(a) Tools and technology needed, if custom development is chosen;

(b) Which supplier can fulfil the project requirements; and
(c) Which application service provider can build the system, if outsourcing is
chosen.

There are ways of knowing the advantages and disadvantages of the design
approach you have chosen. The next subtopic will tell you how to find them.
6.3.1 Alternatives Matrix

Alternatives matrix can be used to organise advantages and disadvantages of the
design alternatives so that the best solution can be chosen. What does it stand
for?
Alternatives matrix is a grid containing technical, financial and

organisational feasibility for each candidate system. It combines a number of
feasibility analyses into a matrix so that alternatives can be compared easily.
The advantages and weaknesses related to the implementation of each solution,

and other useful information can be known when a comparison is made. Let us
see Table 6.5 for an example.
Table 6.5: Matrix of Alternatives for a Buying Program
Alternative 1: Alternative 2: Web Alternative 3: Shop-

Buying From Me Shop N-Go
Technical Feasibility Developed using C Developed using C Developed using

language; very little and Java languages; Java; wish to
in-house experience wish to develop in- develop in-house
in C language. house Java skills. Java skills. Orders
Order is sent to the Flexible export can save some file
company by using characteristics for formats.
e-mail and e-filing. distributing order
information to other
systems.
Economic $150 initial $700 deposit, there $200 per year.

Feasibility payment. is no annual fee.
Organisational Program is used by Program is used by A new application;

Feasibility musical companies. other musical some companies
companies. have experiences
with Shop-N-Go.

Other Very easy to use. Tom is from

Advantages information system
support, less
experience but
thinking positive
towards this
program. Can be
customised easily.
Other Weaknesses Interfaces are not

easy to customise.
Do you know that there is one tool that can help? It is the RFP (request for
proposal), which contains a proposed document for getting alternative solutions
from development suppliers or service providers.
Basically, RFP explains the system that you are trying to develop and the criteria
that you use to select a system.
Later, suppliers will provide feedback by explaining what it means when they
get involved in the solution. They communicate by giving the time, cost and how
the product requirements or services will be met.
There is no formal method of writing the RFP, but it needs to contain basic
information like:
(a) Explanation of the system needed;

(b) Specific technical requirements or situation;
(c) Evaluation criteria;
(d) Instructions on how to give feedback; and
(e) Schedules required.
SELF-CHECK 6.2
What is the most suitable situation for implementing the custom

development strategy?

6.4 MOVING FROM LOGICAL TO PHYSICAL

MODELS
Lastly, let us look at how to move from logical to physical models. After the
design strategy and developing a design plan, the next step is the process of
changing the logical data model into the physical data model. Process model for
the design stage and data model for the design stage are created to show details
of implementation to be done and to explain the specific method of realising the
system.
6.4.1 Physical Data Flow Diagram

A physical data flow diagram (DFD) contains the same components as the logical
DFD. The basic difference between the two models is that the physical DFD
contains specific information to explain how the system will be built and put to
work.
The summaries of the DFD and related matters are explained in the following
tables and figure. Firstly, Table 6.6 describes briefly the steps in creating the
physical DFD.
Table 6.6: Five Steps in Creating a Physical DFD
Steps Description
1. Add implementation Use existing logical DFD; place the direction of data stores,
reference data flows and processes that will be implemented inside
opening statement below each component.
2. Sketch the man- Sketch the boundary line that separates the system being
machine boundary automated from the manual section.
3. Add data stores, Add data stores, data flows and processes (of related
data flows and system) to the model. These are components that are less
processes of related involved with the business process.
system
4. Update data Update data flows for entering data elements of the related
elements inside data system.
flows
5. Update metadata Update metadata inside CASE repository for entering the
inside computer- physical characteristics.
aided software
engineering (CASE)
repository.

Meanwhile Table 6.7 explains the steps in moving from logical ERD to physical
ERD.
Table 6.7: Steps in Changes for ERD
Steps Explanation
1. Change entity to table Begin with logical ERD, change entity to table and
update metadata.
2. Change attribute to field Change attributes to fields and update metadata.

3. Add primary key Place primary keys on all entities.
4. Add foreign key Add foreign keys to represent relationship between
entities.
5. Add component related to Add tables and fields that are related to the system.
the system
Last but not least, the differences between the logical DFD and the physical DFD
are identified and these are shown in Figure 6.3.
Figure 6.3: Differences between logical and physical DFD


There are three approaches in creating a new system, namely custom

development, application package and outsourcing.
In choosing a design strategy, there are five factors that need to be

considered: business requirements, in-house experience, project management,
project skills and time frame.
During planning for design, alternative matrix can help the project group to
understand every strategy in fulfilling project requirements.
Alternatives matrix is a grid containing technical, financial and organisational

feasibility for each candidate system. It combines a number of feasibility
analyses into a matrix so that alternatives can be compared easily.
After the design strategy and developing a design plan, the next step is the
process of changing the logical data model into the physical data model.
The physical DFD contains specific information to explain how the system
will be built and put to work. There are five steps in creating a physical DFD.
Among them is adding implementation reference and sketching the man-
machine boundary.
As for changing from logical entity-relationship diagram (ERD) to physical

ERD, there are five steps to follow. Among them is changing entity to table
and adding primary key.
Alternative matrix Physical entity-relationship diagram

(ERD)
Application package
Project management
Business requirements
Project skills
Custom development
System design
In-house experience
Time frame
Outsourcing

Topic Architecture
7 Design
LEARNING OUTCOMES
1. State the objective of architecture design;
2. Describe four basic functions of architectural components;
3. Describe the architectures of client-server and client server tiers;
4. Differentiate between server-based and client-based architecture;
5. Summarise how to choose the architectures; and
6. Evaluate factors in hardware and software specification.
INTRODUCTION
Every information system involves four main functions: data storage, data access
logic, application logic and presentation logic. Depending on the architecture, the
four functions are performed on a server, on a client or are divided between the
server and the client. As you plan the system design, you must determine where
the functions will be carried out and the advantages and disadvantages of each
design approach. This new topic discusses server and client characteristics and
how each design alternative handles system functions.
7.1 ARCHITECTURE DESIGN ELEMENTS

Firstly, what is the objective of architecture design? The objective of architecture
design is to determine how the software components of the information system
will be assigned to the hardware devices of the system.

148 TOPIC 7 ARCHITECTURE DESIGN
In this subtopic, we will first discuss the major functions of the software to
understand how the software can be divided into different parts. Then we will
briefly discuss the major types of hardware onto which the software can be
placed. Although there are numerous ways in which the software components
can be placed on the hardware components, the most common architecture is the
client server architecture; our focus for this topic.
7.1.1 Architectural Components

Generally, the major architectural components of any system are the software
and the hardware. The major software components of the system being
developed have to be identified and then allocated to the various hardware
components on which the system will operate. Each of these components can be
combined in a variety of different ways.
Basically, all software systems can be divided into four basic functions.
(a) The first is data storage. Most information systems require data to be stored
and retrieved, whether it is a small file, such as a list of lawn chemicals that
are no longer authorised for residential applications or a large database that
stores an organisationÊs human resources records. These are the data
entities documented in entity relationship diagrams (ERDs) which you
have learned in the database course.
(b) The second function is the data access logic. This is the processing required
to access data, often meaning database queries in Structured Query
Language (SQL).
(c) The third function is the application logic. This is the logic documented in
the data flow diagrams (DFDs), use cases and functional requirements.
(d) The fourth function is the presentation logic. This is the display of
information to the user and the acceptance of the userÊs commands (the
user interface).
These four functions (data storage, data access logic, application logic and
presentation logic) are the basic building blocks of any information system.

TOPIC 7 ARCHITECTURE DESIGN 149
7.2 CLIENT-SERVER ARCHITECTURES

Most organisations today are utilising or moving to client server architectures,
which attempt to balance the processing between client devices and one or more
server devices.
In these architectures, the client is responsible for the presentation logic, whereas
the server is responsible for the data access logic and data storage. The
application logic may reside on the client, reside on the server or be split between
both (Figure 7.1). If the client shown in Figure 7.1 contained all or most of the
application logic, it is called a thick or fat client.
Figure 7.1: Two-tiered client server architecture

Source: Denis, Wixom and Roth (2012)
Currently, thin clients, containing just a small portion of the application logic, are
popular because of lower overheads and easier maintenance. For example, many
web-based systems are designed with the web browser performing presentation
and only minimal application logic using such programming languages as
JavaScript, while the server side has most of the application logic, all of the data
access logic and all of the data storage.
Client server architectures have four important benefits. First and foremost, they
are scalable. That means it is easy to increase or decrease the storage and
processing capabilities of the servers. If one server becomes overloaded, you
simply add another server so that many servers are used to perform the
application logic, data access logic or data storage. The cost to upgrade is
gradual, and you can upgrade in small increments.
Second, client server architectures can support many different types of clients
and servers. It is possible to connect computers that use different operating
systems so that you are not locked into one vendor. Users can choose which type
of computer they prefer (such as combining both Windows computers and Apple
Macintoshes on the same network).
Middleware is a type of system software designed to translate between different

vendorsÊ software. Middleware is installed on both the client computer and the
server computer. The client software communicates with the middleware, which
can reformat the message into a standard language that can be understood by the
middleware, which assists the server software.
Third, for thin client server architectures that use Internet standards, it is simple
to clearly separate the presentation logic, the application logic and the data
access logic and design each to be somewhat independent. For example, the
presentation logic can be designed in HTML or XML to specify how the page will
appear on the screen (such as the colours, fonts, order of items, specific words
used, command buttons, type of selection lists and so on). Simple program
statements are used to link parts of the interface to specific application logic
modules that perform various functions. These HTML or XML files defining the
interface can be changed without affecting the application logic. Likewise, it is
possible to change the application logic without changing the presentation logic
or the data, which are stored in databases and accessed by SQL commands.
Finally, if a server fails in client server architecture, only the applications

requiring that server will fail. The failed server can be swapped out and replaced
and the applications can then be restored.
However, client server architectures also have some critical limitations, the most
important of which is their complexity. All applications in client server
computing have two parts, the software on the client side and the software on
the server side. Updating the overall system with a new version of the software is
more complicated too. With client server architectures, you must update all
clients and all servers and you must ensure that the updates are applied on all
devices.
7.2.1 Client-Server Tiers

There are many ways in which the application logic can be partitioned between
the client and the server. Basically, the arrangement in the previous Figure 7.1 is
a common configuration.
In this case, the server is responsible for the data and the client is responsible for
the application and presentation. This is called a two-tiered architecture because
it uses only two sets of computers which are clients and servers.

Now we come to a three-tiered architecture. A three-tiered architecture uses

three sets of computers, as shown in Figure 7.2.
Figure 7.2: Three-tiered client server architecture

In this case, the software on the client computer is responsible for the
presentation logic, an application server(s) is responsible for the application logic
and a separate database server(s) is responsible for the data access logic and data
storage.
Typically, the user interface runs on a desktop PC or workstation and uses a

standard graphical user interface. The application logic may consist of one or
more separate modules running on a workstation or application server. Finally, a
relational DBMS running on a database server contains the data access logic and
data storage. The middle tier may be divided into tiers itself, resulting in an
overall architecture called „n-tier architecture‰.
An n-tiered architecture distributes the work of the application (the middle tier)
among multiple layers of more specialised server computers. This type of
architecture is common in todayÊs web based e-commerce systems (see Figure
7.3).
Figure 7.3: n-tiered client server architecture


The browser software on client computers makes HTTP requests to view pages
from the web server(s) and the web server(s) enable the user to view
merchandise for sale by responding with HTML documents. As the user shops,
components on the application server(s) are called as needed to allow the user to
put items in a shopping cart; determine item pricing and availability, compute
purchase costs, sales tax, and shipping costs, authorise payments and so on.
These elements of business logic or detailed processing are stored on the

application server(s) and are accessible to any application. For example, the cash
register application that needs item price look-ups could use the same price
determination business logic that is used by the e-commerce web site. The
modular business logic can be used by multiple, independent applications that
need that particular business logic. The database server(s) manages the data
components of the system. Each of these four components is separate, which
makes it easy to spread the different components on different servers and to
partition the application logic on a web-oriented server and a business-oriented
server.
The primary advantage of an n-tiered client server architecture compared with a

two-tiered architecture (or a three-tiered with a two-tiered) is that it separates out
the processing that occurs to better balance the load on the different servers; it is
more scalable.
As shown in Figure 7.3, we have three separate server types, a configuration that
provides more power than if we had used a two-tiered architecture with only one
server. If we discover that the application server is too heavily loaded, we can
simply replace it with a more powerful server or just put in several more
application servers to share the load. Conversely, if we discover that the database
server is underused, we could store data from another application on it.
However, there are two primary disadvantages to an n-tiered architecture

compared with a two-tiered architecture (or a three-tiered with a two-tiered).
First, the configuration puts a greater load on the network. If you compare
Figures 7.1, 7.2 and 7.3, you will see that the n-tiered model requires more
communication among the servers; it generates more network traffic, so you
need a higher-capacity network.
Second, it is much more difficult to program and test software in n-tiered

architectures than in two-tiered architectures, because more devices have to
communicate properly to complete a userÊs transaction.

7.3 SERVER-BASED ARCHITECTURE

Do you know that the very first computing architectures were server-based, with
the server (usually, a central mainframe computer) performing all four
application functions? The clients (usually, terminals) enabled users to send and
receive messages to and from the server computer. The clients merely captured
keystrokes and sent them to the server for processing and accepted instructions
from the server on what to display. The following Figure 7.4 shows you the
server-based architecture.
Figure 7.4: Server-based architecture

This very simple architecture often works very well. Application software is
developed and stored on the server and all data are on the same computer. There
is one point of control because all messages flow through the one central server.
Software development and software administration are simplified because a
single computer hosts the entire system (operating system and application
software).
The server-based architecture was the first architecture used in information

systems, but did not remain the only option as hardware and software evolved.
The fundamental problem with early server-based systems was that the server
processed all the work in the system. As the demands for more and more
applications and the number of users grew, server computers became overloaded
and unable to quickly process all the usersÊ demands. Response time became
slower and information system (IS) managers were required to spend
increasingly more money to upgrade the server computer. In the early days,
upgrading to a larger server computer (usually a mainframe) required a
substantial financial commitment; increased capacity came only in large,
expensive chunks.

7.4 CLIENT-BASED ARCHITECTURE

What about client-based architecture? With client-based architectures, the clients
are microcomputers on a local area network and the server is a server computer
on the same network. The application software on the client computers is
responsible for the presentation logic, the application logic and the data access
logic; the server simply provides storage for the data. The following Figure 7.5
shows you the client-based architecture.
Figure 7.5: Client-based architecture

This simple architecture often works very well in situations with low numbers of
users or limited data access requirements.
However, the fundamental problem with the client-based architecture is that all
data on the server must travel to the client for processing. For example, suppose
that the user wishes to display a list of all employees with company life
insurance. All the data in the employee database must travel from the server,
where the database is stored, over the network to the client, which then executes
the query to find each record that matches the data requested by the user.
In the other computing models stated previously, the data access logic would be
executed on the server and only the results of the query transmitted to the client.
In the client-based computing model, the data access logic is executed on the
client system. Therefore, the entire database must be transmitted to the client
before processing can take place. This can overload both the network and the
power of the client computers.

SELF-CHECK 7.1
Create a table that summaries the strengths and weaknesses of client-

server architecture and server-based architecture.
7.5 CHOOSING THE ARCHITECTURES

Generally, most systems are constructed based on the infrastructure that is
already available in the organisation. However, current infrastructure often
constrains the choice of architecture. Therefore, most organisations now set up
various infrastructures inside them. This enables the project group to choose the
architecture based on important factors.
It is important to understand the strengths and weaknesses of every type of

computing architecture and when to use them. There are six features of the
architecture that need to be considered as shown in Table 7.1.
Table 7.1: Features of Computing Architecture
Feature Server-Based Client-Based Client-Server

Infrastructural Cost Very High Medium Low
Development Cost Medium Low High
Facilities Low High Medium
Interface Capability Low High Low
Control and Security High Low Medium
Measurable Low Medium High
These features are further explained as follows:
(a) Infrastructural Cost

Hardware, software and network costs that will support application
systems.
(b) Development Cost

System development cost is an important factor when you think of the
financial advantage of the client-server architecture.

(c) Facilities
Most organisations now have many mainframe applications but less
human resources. Most project groups belittle the work needed to create
security and efficiency of the client-server application.
(d) Interface Capability

Most users expect GUI-based interfaces and graphical objects like buttons,
icons and so on.
(e) Control and Security

Data and information need to be protected from any destruction and
damage. Therefore, security needs to be there inside every application
system.
(f) Measurable
This refers to the capability to add and reduce the capacity of the
computing architecture for fulfilling changes to user needs.
Each of the architectures discussed has its strengths and weaknesses. Client
server architectures are strongly favoured on the basis of the cost of
infrastructure (the hardware, software and networks that will support the
application system). The client server architecture is highly scalable because
servers can be added to (or removed from) the infrastructure when processing
needs change. The GUI development tools used to create applications for client
server architectures can be intuitive and easy to use. The development of
applications for these architectures can be fast and painless.
Keep in mind, however, that client server architectures do involve the added
complexity of several layers of hardware (such as database servers, web servers,
client workstations) that must communicate effectively with each other. Project
teams often underestimate the difficulty associated with creating secure, efficient
client server applications.
7.6 HARDWARE AND SOFTWARE

SPECIFICATION
Take note that the design phase is also the time to begin selecting and acquiring
the hardware and software that will be needed for the future system. In many
cases, the new system will simply run on the existing equipment in the
organisation.

Other times, however, new hardware and software (usually for servers) must be
purchased. The hardware and software specification is a document that describes
what hardware and software are needed to support the application. There are
several steps involved in creating the document. Figure 7.6 shows a sample of
hardware and software specifications.
Figure 7.6: Sample of hardware and software specifications

In order to create the document, firstly you will need to define the software that
will run on each component. This usually starts with the operating system (such
as Windows or Linux) and includes any special purpose software on the client
and servers (such as Oracle database). Here, you should consider any additional
costs such as technical training, maintenance, extended warranties and licensing
agreements (for example, a site licence for a software package). Again, the needs
that you list are influenced by decisions that are made in the other design phase
activities.
Next, you must create a list of the hardware needed to support the future system.
In general, the list can include such things as database servers, network servers,
peripheral devices (such as printers and scanners), backup devices, storage
components and any other hardware component needed to support an
application. At this time, you also should be aware of the quantity of each item
that will be needed.
Finally, you need to describe (in as much detail as possible) the minimum
requirements for each piece of hardware. Many organisations have standard lists
of approved hardware and software that must be used, so, in many cases, this
step simply involves selecting items from the lists.

Other times, however, the team is operating in new territory and is not
constrained by the need to select from an approved list. In this case, the project
team must convey such requirements as the amount of processing capacity, the
amount of storage space and any special features that should be included.
This step will become easier for you with experience; however, there are some
hints that can help you describe hardware needs (see Table 7.2).
Table 7.2: Factors in Hardware and Software Selection
Factor Description
Functions and What specific functions and features are needed (such as size
Features of monitor, software features)?
Performance How fast do the hardware and software operate (such as
processor, number of database writes per second)?
Legacy Databases and How well do the hardware and software interact with legacy
Systems systems (such as can it write to this database)?
Hardware and OS What are the future migration plans (such as the goal is to have
Strategy all of one vendorÊs equipment)?
Cost of Ownership What are the costs beyond purchase (such as incremental
licence costs, annual maintenance, training costs, salary costs)?
Political Preferences People are creatures of habit and are resistant to change, so
changes should be minimised.
Vendor Performance Some vendors have reputations or future prospects that are
different from those of a specific hardware or software system
that they currently sell.
For example, consider the hardware standards within the organisation or those
recommended by vendors. Talk with experienced system developers or other
companies with similar systems.
Finally, think about the factors that affect hardware performance, such as the
response-time expectations of the users, data volumes, software memory
requirements, the number of users accessing the system, the number of external
connections and growth projections.
After preparing the hardware and software specification, the project team works
with the purchasing department to acquire the hardware and software. The
project team prepares a request for proposal (RFP) based on legal and
organisational policies provided by the purchasing department, which then
issues the RFP. The project team then selects the most desirable vendor for the

hardware and software on the basis of the proposals received, perhaps using a
weighted alternative matrix.
On a large project, this evaluation may take months and involves extensive
testing and benchmarking of the projects offered by the vendors. The purchasing
department is actively involved in the vendor selection, again ensuring that
organisational policies are followed.
Finally, the purchasing department negotiates final terms with the vendor, issues
a contract and accepts delivery of the items, subject to approval of the project
team.
The objective of architecture design is to determine how the software

components of the information system will be assigned to the hardware
devices of the system.
There are four functions of all software systems: data storage, data access
logic, application logic and presentation logic. These are the basic building
blocks of any information system.
Most organisations today are utilising or moving to client server

architectures, which attempt to balance the processing between client devices
and one or more server devices. In these architectures, the client is
responsible for the presentation logic, whereas the server is responsible for
the data access logic and data storage.
There are many methods in which the application logic can be partitioned
between the client and the server. Some methods are two-tiered architecture,
three-tiered architecture and n-tiered architecture.
The server-based architecture was the first architecture used in information

systems, but did not remain the only option as hardware and software
evolved.
With client-based architectures, the clients are microcomputers on a local area

network and the server is a server computer on the same network.

It is important to understand the strengths and weaknesses of every type of

computing architecture and when to use them. There are six features of the
architecture to be considered for computing architecture. Among them are
infrastructural cost and development cost.
The hardware and software specification is a document that describes what

hardware and software are needed to support the application.
There are certain factors that can help you describe hardware needs. Among
them are functions and features, performance and cost of ownership.
Application logic Presentation logic

Architecture design Software
Client-server architecture Strength
Data access logic Three-tiered architecture
Data storage Two-tiered architecture
Hardware Weakness
n-tiered architecture

Topic User Interface
8 Design
LEARNING OUTCOMES
1. Describe user interface design and its principles;
2. Identify principles of navigation and its types of control;
3. Describe input design principles and its types;
4. Restate output design principles and its types; and
5. Distinguish between the four types of user reports.
INTRODUCTION
Generally, a user interface is a part of the system with which the users interact. It
includes the screen displays that provide navigation through the system, the
screens and forms that capture data and the reports that the system produces
(whether on paper, on the web or via some other media).
Thus, this topic introduces the basic principles and processes of interface design
and discusses how to design the interface structure and standards.
8.1 USER INTERFACE DESIGN

Firstly, what is meant by user interface design?
User interface design is the process of defining how the system will interact
with external entities (such as customers, suppliers and other systems).

162 TOPIC 8 USER INTERFACE DESIGN
In other words, the user interface design defines the way in which the users will
interact with the system and the nature of the inputs and outputs that the system
accepts and produces.
The user interface includes three fundamental parts. The first is the navigation
mechanism; the way in which the user gives instructions to the system and tells it
what to do (such as buttons and menus). The second is the input mechanism; the
way in which the system captures information (such as forms for adding new
customers). Lastly, the third part is the output mechanism; the way in which the
system provides information to the user or to other systems (such as reports and
web pages).
Each of these is conceptually different, but all are closely intertwined; all
computer displays contain navigation mechanisms and most contain input and
output mechanisms. Therefore, navigation design, input design and output
design are tightly coupled.
The objective of interface design is to make the interface pleasing to the eye and
simple to use, while minimising the effort users expend to accomplish their work.
A good interface design is made up of the following principle combinations (see
Table 8.1).
Table 8.1: Principles of User Interface Design
Principle Explanation
Layout The interface should be a series of areas on the screen that are used
consistently for different purposes, for example, a top area for
commands and navigation, a middle area for information to be input or
output and a bottom area for status information.
Content Users should always be aware of where they are in the system and what
Awareness information is being displayed.
Aesthetics Interfaces should be functional and inviting to users through careful use
of white space, colours and fonts. There is often a trade-off between
including enough white space to make the interface look pleasing and
losing so much space that important information does not fit on the
screen.
User Although ease of use and ease of learning often lead to similar design
Experience decisions, there is sometimes a trade-off between the two. Novice users
or infrequent users of software will prefer ease of learning, whereas
frequent users will prefer ease of use.

TOPIC 8 USER INTERFACE DESIGN 163
Consistency Consistency in interface design enables users to predict what will

happen before they perform a function. It is one of the most important
elements in ease of learning, ease of use and aesthetics.
Minimise The interface should be simple to use. Most designers plan on having no
User Effort more than three mouse clicks from the starting menu until users perform
work.
We have found that the greatest problem facing experienced designers is using
space effectively. Simply put, there is more information to present than room to
present it. Analysts must balance the need for simplicity and pleasant appearance
against the need to present the information across multiple pages or screens,
which decreases simplicity.
8.2 NAVIGATION DESIGN

The navigation component of the interface enables the user to enter commands to
navigate through the system and perform actions to enter and review
information it contains. The navigation component also presents messages to the
user about the success or failure of his or her actions. The goal of the navigation
system is to make the system as simple as possible to use. A good navigation
component is one that the user never really notices. It simply functions the way
the user expects, and not too complicated.
8.2.1 Principles
Do you know that one of the hardest things about using a computer system is
learning how to manipulate the navigation controls to make the system do what
you want?
Analysts usually must assume that users have not read the manual, have not
attended training and do not have external help readily at hand. All controls
should be clear and understandable and placed in an intuitive location on the
screen.

Ideally, the controls should anticipate what the user will do and simplify his or
her efforts. For example, many set-up programs are designed so that, for a typical
installation, the user can simply keep pressing the „next‰ button. Following are
the principles of navigation design (Table 8.2).
Table 8.2: Three Principles of Navigation Design
Principle Description
Prevent Mistakes The first principle of designing navigation controls is to prevent
the user from making mistakes. A mistake costs time and creates
frustration. Worse still, a series of mistakes can cause the user to
discard the system.
Simplify Recovery No matter what the system designer does, users will make
from Mistakes mistakes. The system should make it as easy as possible to correct
these errors. Ideally, the system will have an „undo‰ button that
makes mistakes easy to override; however, writing the software
for such buttons can be very complicated.
Use Consistent One of the most fundamental decisions is the grammar order.
Grammar Order Most commands require the user to specify an object (such as file,
record and word) and the action to be performed on that object
(such as copy and delete).
8.2.2 Types of Navigation Controls

There are two traditional hardware devices that can be used to control the user
interface; the keyboard and a pointing device (such as a mouse, trackpad or
touch screen). In recent years, voice recognition systems have made an
appearance, but they are not yet common.
There are three basic software approaches for defining user commands;
languages, menus and direct manipulation (Table 8.3).

Table 8.3: Three Basic Software Approaches for Defining User Commands
Approach Description
Language Can be divided into two:
(a) Command language; the user enters commands in a special
language developed for the computer system (such as UNIX
and SQL both use command languages).
(b) Natural language interfaces are designed to understand the
userÊs own language (such as English, French and Spanish).
Menu The most common type of navigation system today is the menu. A
menu presents the user with a list of choices, each of which can be
selected. Menus are easier to learn than languages because the user
sees an organised (but limited) set of choices. Some of the more
common types of menus include menu bars, drop-down menus, pop-
up menus, tab menus, tool bars and image maps.
Direct With direct manipulation, the user enters commands by working

Manipulation directly with interface objects. For example, users can change the size
of objects in Microsoft PowerPoint by clicking on objects and moving
the sides or they can move files in Windows Explorer by dragging the
file names from one folder to another.
As for message, it is a way for the system to respond to the user and inform them
of the status of the interaction. There are many different types of messages, such
as error messages, confirmation messages, acknowledgement messages, delay
messages and help messages.
8.3 INPUT DESIGN

Input mechanisms facilitate the entry of data into the computer system, whether
highly structured data, such as order information (for example, item numbers,
quantities and costs) or unstructured information (such as comments). This is
related to input design. What is meant by input design?
Input design means a screen design that is used to input information,

similarly also for the forms that enable users to write or type information.

8.3.1 Principles
The goal of input design is to capture accurate information for the system in a
simple and easy way. The fundamental principles of input design reflect the
nature of the inputs (whether batch or online) and ways to simplify their
collection. These principles are:
(a) Online processing (sometimes called transaction processing), where each

input item (such as a customer order and a purchase order) is entered into
the system individually, usually at the same time as the event or
transaction prompting the input. For example, when you borrow a book
from the library, buy an item at the store or make an airline reservation, the
computer system that supports each process uses online processing to
immediately record the transaction in the appropriate database(s).
Online processing is most commonly used when it is important to have

real-time information about the business process. For example, when you
reserve an airline seat, the seat is no longer available for someone else to
use, so that piece of information must be recorded immediately.
(b) In batch processing, all the inputs collected over a certain period are
gathered and entered into the system at one time in a batch. Some business
processes naturally generate information in batches. For example, most
hourly payrolls are done by batch processing because time cards are
gathered together in batches and processed at once.
Batch processing is also used for transaction processing systems that do not
require real-time information. For example, most stores send sales
information to district offices so that new replacement inventory can be
ordered. This information could be sent in real time as it is captured in the
store, so that the district offices are aware within a second or two that a
product is sold. If stores do not need up-to-the-second real-time data, they
will collect sales data throughout the day and transmit the data every
evening in a batch to the district office.
(c) Capture Data at the Source. Perhaps the most important principle of input
design is to capture the data in an electronic format at the original source or
as close to the original source as possible. In the early days of computing,
computer systems replaced traditional manual systems that were based on
paper forms. As these business processes were automated, many of the
original paper forms remained, either because no one thought to replace
them or because it was too expensive to do so.

Instead, the business process continued to contain manual forms that were
taken to the computer centre in batches to be keyed into the computer
system by a data entry operator.
(d) Minimise keystrokes. Another important principle is to minimise

keystrokes. Keystrokes cost time and money, whether they are performed
by a customer, user or trained data entry operator. The system should
never ask for information that can be obtained in another way (such as by
retrieving it from a database or by performing a calculation).
Likewise, a system should not require a user to type information that can
be selected from a list; selecting reduces errors and speeds entry.
8.3.2 Types of Input

There are several very good methods of putting data into the system. The types
of input devices that can be used to input data are shown in Figure 8.1.
Figure 8.1: Input devices

Each data item that has to be input is linked to a field, on the form into which its
value is typed. There are two methods of entering data into the system, which is
by using:
(a) Screen Form

Screen form is a data entry form that is displayed on the computer screen
and contains specific blocks. Data are entered directly into the system by
using input devices.
(b) Printed Form

It is a conventional method, using forms that are provided in a format that
is printed on paper. All the information in the printed form can be entered
into the system by using the screen form.
8.3.3 Screen Form

What is meant by screen form?
Screen form is a data entry interface that resembles the shape of the original
form. This form is developed by using a certain software for simplifying data
entry by users into the system.
Screen Form Design

Screen form needs to be designed to receive inputs that follow the specification
needed by users. Therefore, screen form design needs to take into account the
following factors:
(a) Internal control;

(b) Graphical user-interface control; and
(c) Additional control.

Explanations of these factors are in Table 8.4 below.
Table 8.4: Factors in Screen Form Design
Factors Description
Internal This is a basic requirement in a computerised information system.
Control The objective is to ensure that the data entered is precise, so that the
system is protected from errors and misuse. Emphasis is given to the
total data that needs to be supervised and that the data entered is
valid.
Graphical This control is needed to simplify user's data entry into the system.
User Figure 8.2 displays a graphical interface which contain certain
Interface components.
Control
Figure 8.2: GUI with various types of input boxes

Source: Mohamad, Safawi and Kamarulariffin (2001)
Additional Additional controls are also important during the process of entering
Control data into the system. Some of them are:
Drop-down calendar;
Slider edit calendar;
Internet link; and
Checklist box.

8.4 OUTPUT DESIGN

Do you know that outputs are the reports that the system produces, whether on
the screen, on paper or in other media, such as the web? Outputs are perhaps the
most visible part of any system, because a primary reason for using an
information system is to access the information that it produces.
8.4.1 Principles
What is the goal of the output mechanism? The goal of the output mechanism is
to present information to users so that they can accurately understand it with the
least effort. The fundamental principles of output design reflect how the outputs
are used and ways to make it simpler for users to understand them. These
principles are:
(a) Understand Report Usage

The first principle in designing reports is to understand how they are used.
Reports can be used for many different purposes. The frequency of the
report may also play an important role in its design and distribution. Real-
time reports provide data that are accurate to the second or minute at
which they were produced (such as stock market quotes).
Batch reports are those that report historical information that may be
months, days or hours old, and they often provide additional information
beyond the reported information (such as totals, summaries and historical
averages).
(b) Manage Information Load

Most managers get too much information, not too little (the information
load confronting the manager is too great). The goal of a well-designed
report is to provide all the information needed to support the task for
which it was designed. This does not mean that the report should provide
all the information available on the subject; just what the users decide they
need to perform their jobs.
In some cases, this may result in the production of several different reports
on the same topics for the same users, because they are used in different
ways.

(c) Minimise Bias

No analyst sets out to design a biased report. The problem with bias is that
it can be very subtle; analysts can introduce it unintentionally. Bias can be
introduced by the way in which lists of data are sorted, because entries that
appear first in a list may receive more attention than those appearing later
in the list. There are no easy answers to this, except to say that the order of
presentation should match the way in which the information is used.
8.4.2 Types of Output

Producing different types of output requires different technologies. For printed
output, the options include a variety of printers. For screen output, the options
include attached or stand-alone displays. Audio output can be amplified over a
loudspeaker or listened to on a variety of speakers, ranging from small to
surround sound capable on a PC.
Audio output may also be designed for mobile phones. Electronic output is
created with special software tools. As you can see, the choices are numerous.
Some of them are:
(a) Printers
Because printed reports are such a common kind of output, it is logical to
assume that in any large organisation printers are ubiquitous. Although
other types of output are gaining popularity, it is likely that businesses will
still desire printed output or will want to design output that will look good
if customers, suppliers or vendors print it out using their own software and
hardware.
(b) Displays as Output

Display screens are an increasingly popular output technology. Once used
mostly for data entry, screens are also becoming a feasible technology for
many other uses as their size and price decrease and as their compatibility
with other system components increases.
Screens have distinct advantages over printers because of their quietness

and potential for interactive user participation. Screen output can afford
flexibility in allowing the user to change output information in real time
either through deletion, addition or modification. Screens also permit
review of stored output through access to and the display of items from a
relevant database, permitting individual decision-makers to stop storing
redundant printouts.

Display screens as output result in cost savings. If users can complete their
tasks by interacting with a screen, they may not need paper, thereby
eliminating the cost of printing, filing and physical storage. If a report was
previously sent out by post, convincing users to view the documents on
screen can save mailing, as well as printing, costs. Stockbrokers, phone
companies, utilities and banks are all offering electronic delivery of output
to their customers.
Electronic display may also be desirable from the userÊs standpoint. A user
may want just to glance briefly at a monthly statement to verify its
accuracy. The user, however, needs to file the statement away for tax
reasons. If the statement is delivered via e-mail, the electronic copy may be
all that the user wants. This will help record-keeping and consequently
encourage the user to prefer the electronic statement to the paper
statement. Another reason for preferring display output to paper output is
that it is easier to keep the electronic version up-to-date.
(c) Video, Audio and Animation

Many of the tools and application packages you will be working with
facilitate the inclusion of video in the output options. Video is a complex
form of output, as it combines the strength and potential emotional impact
of audio (including sound effects, voice and music) with a visual channel.
Audio output is transient, whereas the printed word is permanent. Audio

output is usually output for the benefit of one user, whereas printed output
is often widely distributed.
Animation is another form of output that can be used to enhance a Web site
or presentation. Animation is the presentation of different images in a
series, one at a time.
(d) CD-ROMS and DVDS

With the demand for multimedia output growing, the display of material
on CD-ROMs has become widespread. CD-ROMs are less vulnerable to
damage from human handling than other output. CD-ROMs can include
full-colour text and graphics, as well as music and full-motion video, so as
an output medium they provide a designer maximum creativity. The DVD
(digital versatile disc) is also a useful output technology. Not only are
DVDs used for output, but they also are used for backup storage.

(e) Electronic Output

Many of the new web-based systems you design will have the capability of
sending electronic output in the form of e-mail, faxes and bulletin board
messages that can be sent from one computer to another without the need
for hard copy.
(f) Pull Technology

An important output technology made possible by the web is pull
technology. If you have tried to pull information from the web by clicking
on links, you have used the most basic type of pull technology.
In the future, evolutionary agents (programmed using intelligent agent software)

may be used to help organisational members find what they need on the web.
These agents will relieve some of the usersÊ typical burden of searching the web,
because the agents will observe and understand usersÊ behaviour as they interact
with a variety of material on the web and then can be programmed to seek out
the information users want. In this way, web searches will be more efficient and
more effective for users.
Push Technology
Another type of output analyst design is web and wireless content delivered via
push technology. Push technology can be used for external communication to
push (electronically send) solicited or unsolicited information to a customer or
client. It can also be used within the organisation to focus the immediate
attention of an employee or a decision-maker who is facing a critical deadline on
critical items. The term push technology can be described as any content sent to
users at specified times, from basic webcasting to selective content delivery using
sophisticated evolutionary filtering agents.
As a conclusion, Table 8.5 summaries the comparison between the output

methods.

Table 8.5: Comparison of Output Methods
Output Method Advantages Disadvantages

Printer Affordable for most Still requires some operator
organisations intervention
Flexible in types of output, Compatibility problems with
location and capabilities computer software
Handles large volumes of May require special, expensive
output supplies
Highly reliable with little Depending on model, may be
down time slow
Environmentally unfriendly
Display screen Interactive May require cabling and setup
space
Online, real-time
transmission May still require printed
documentation
Quiet
Takes advantage of
computer capabilities for
movement within
databases and files
Good for frequently
accessed, ephemeral
messages
Audio output and Good for individual user Has limited application
podcasts
Good for transient Needs ear buds where output
messages will not interfere with other
tasks
Good where worker needs
to be hands free
Good if output needs to be
widely distributed
DVD, CD-ROM Allows multimedia output Requires a computer and display
and CD-RW for reading data
Has large capacity
Electronic output Reduces paper Is not conducive to formatting
(e-mail, web sites, (e-mail)
Can be updated very
blogs and RSS
easily Is difficult to convey context of
feeds)
messages (e-mail)
Can be „broadcast‰
Web sites need diligent
Can be made interactive
maintenance

8.4.3 Types of User Reports

Lastly, let us look at four types of reports that can be provided for users. They are
explained in Table 8.6.
Table 8.6: Four Types of Reports
Report Types When to Use Note

Complete Report: Need full This report is normally provided following
A complete list of information on enquiries on the item that fulfil certain
information the items. criteria.
related to all items This report is normally read one by one to
needed. help understand one or more items clearly.
Summary Report: When users This report is normally provided following

A list of need concise enquiries on the item that fulfil certain
summarised information on criteria, but it can become a complete
information on all some items. database.
items. This report is often read for the purpose of
comparing some items with each other.
Arrangement of items is very important.
Turnaround When users It is a report that contains input and output,
Document: (normally such as a bill sent to a client that contains
Turnaround clients) need to total payment information and also contains
output that later return the a form to be filled, which needs to be
becomes the input. output for returned by the client together with the
processing. payment.
Graph: When users A good graph can help users to compare two
A chart is used as need to compare or more items and to understand how a
an attachment to a data among certain item changes with time.
report besides the several items. Graphs are weak in terms of helping users to
table. identify values precisely and need to be
replaced or combined with tables when a
precise value is needed.
Bar graph is better than tables and other
graphs when it involves comparing values
among items.
Line graph simplifies value comparison
according to time.
Pie chat shows divisions or distribution
among total items.

SELF-CHECK 8.1
1. State five types of output and their functions.
2. Identify four types of reports generated for users and what are
their purposes?
User interface design is the process of defining how the system will interact
with external entities (such as customers, suppliers, other systems).
Some principles of user interface design are layout, aesthetics, user

experience and consistency.
Three basic principles of navigation design are preventing mistakes, simplify

recovery from mistakes and use consistent grammar order.
There are two traditional hardware devices that can be used to control the
user interface the keyboard and a pointing device. As for software
approaches for defining user commands, they are language, menu and direct
manipulation.
Input design means a screen design that is used to input information,

similarly also for the forms that enable users to write or type information.
The goal of input design is to capture accurate information for the system
simply and easily.
Input design principles depend on online processing, batch processing.

Others are capture data at the source and minimise keystrokes.
Input devices can be keyboard, mouse, touch screen, scanner and many more.
Three basic principles of output design are understand report usage, manage
information load and minimise bias.

There are numerous types of output which include printers, displays as

output, video, audio and animation, CD-ROMs and DVDs and electronic
output.
Four types of user reports are complete reports, summary reports,

turnaround document and graph.
Input design Output types

Input types Principles
Navigation control Screen form
Navigation design User interface design
Output design User reports

Topic System
Development
9 and
Implementation
LEARNING OUTCOMES
1. Differentiate between system development and implementation
phases;
2. Identify the steps in system development;
3. Describe how to design programs using structure chart;
4. Summarise three types of testing involved in application testing; and
5. Distinguish between the four types of documentation.
INTRODUCTION
System development and implementation is the fourth of five phases in the
systems development life cycle. In the previous phase, system design, you
created a logical and physical model of the system. Now you will develop and
implement that design. This phase includes application development,
documentation, testing, training, installation, data conversion and evaluation.
The deliverable for this phase is a completely functioning information system.
During system implementation, the system design specification serves as a

blueprint for constructing the new system. The initial task is application
development, which requires systems analysts and programmers to work
together to construct the necessary programs and code modules. Before
installation, the system must be tested and documented carefully, users must be

TOPIC 9 SYSTEM DEVELOPMENT AND IMPLEMENTATION 179
trained and existing data must be converted. After the new system is operational,
a formal evaluation of the results takes place as part of a final report to
management.
While system implementation and installation take place, the old system will be
replaced by a new system. The new system will show its real capability and
whether or not it can operate in the real environment.
In this topic, you will be introduced to development activities. Normally,

development is done together with specific testing to ensure that the system can
be produced and is error-free. You will also learn about testing, which is to be
done throughout the implementation phase.
9.1 SYSTEM DEVELOPMENT AND

IMPLEMENTATION
Let us look at the definitions of system development and system implementation
first.
System development is a process done to develop, install and test the

components that make up a system.
After going through the development phase, the system will be used in the real
environment via the implementation phase.
System implementation involves testing the systemÊs capability to operate

with varieties of workload in the real environment. This phase aims to
implement all the planning that has been made at the beginning.
System development can be long and costly if planning was poorly done. This
phase aims to implement all the planning that has been made at the beginning.
On the contrary, it can also become something that closely follows the schedule
and does not require high cost if planning was done carefully. This is being
specific to development if careful analysis and design have been done earlier,
development can be completed on schedule.

180 TOPIC 9 SYSTEM DEVELOPMENT AND IMPLEMENTATION
However, if there were shortcomings in the design that are only known during
development, the design must be modified and this may delay the actual
development work.
9.1.1 Development Steps
ACTIVITY 9.1
Before you read the steps involved in the development phase of a system,
try to think of the basic things that you need to do if you want to make a
new product that can be used, like the telephone. Try to list down the
steps involved to produce this new product.
Now, let us look at the process of producing a good application system. Any
new system will pass through planning, development and testing. When a
development strategy has been chosen, the program that forms the system
will be developed. Development contains the activities of design, coding,
testing and documentation. The sequence of activities is shown in Figure 9.1.
Figure 9.1: Steps in application development


Now let us focus on Figure 9.2 which highlights the four steps in the development
phase.
Figure 9.2: Four steps in the development phase
Further explanation on the development steps are as follows:
(a) Design
As explained previously, design work is to be performed by referring to the
documents that were produced from an earlier (analysis) phase. The
documents being referred to are:
(i) Data flow diagram (DFD);

(ii) Entity-relationship diagram (ERD);
(iii) Source documents; and
(iv) Any other documents that help the programmer to understand the
functions that need to be included in the programs.
Documents also help the programmer to understand the relationships

among various programs.
(b) Coding
What does coding do?
Coding will convert all the process logic into a program that can be
executed by the computer.
By means of coding, the programmer will turn all the earlier planning and
design into a reality.

From the design documents that have been produced, the programmer will
use a certain programming language to change the process logic into
program codes. Normally, a program will be divided into several smaller
modules. Another programmer may be assigned to write some of these
smaller modules.
For a large-sized program that is divided into separate modules, each

module is large and complex enough to be developed by a programmer or
even a group of programmers. In this way, several modules can be
developed concurrently.
In the past, this coding activity used to take a long time. Now, the same
activity can be done in a much shorter time. This can be implemented by
using a software development tool, which can reduce coding time. The tool
can be used effectively if you have the know-how.
The success in coding depends on the thoroughness of the analysis and

design phases. If both phases could be done carefully and be completed,
then not many problems would crop up during coding. Programming
would then become a smooth translation from specifications into codes.
There are many programming languages that can be chosen in application

development. Among the popular programming languages are Visual C++,
Visual Basic and SQL. With an increase in the request for new applications
and systems based on the web today, web programming languages like
Active Server Pages (ASP) from Microsoft and Java or PHP that are mostly
used for the Linux system have become more popular among programmers.
(c) Testing
After coding is done and even during coding, the programmer will test the
program codes produced to see whether they work well. A program is
normally tested individually, then tested as a group and finally as a whole
in one system. Testing will be described in detail in another section.
(d) Documentation
Documentation will record any kind of facts, information and specifications
for a certain information system. Documentation is very important because
it will be referred to at any time in the future, while the system is in
operation in the real environment.

9.2 DESIGNING PROGRAMS

It is tempting to jump right into the implementation phase by coding without
much thought or planning, but this can lead to disastrous results, such as
inefficient programs, code that does not work with other code and a system that
does not do what it is supposed to do.
Instead, analysts should first take time in the design phase to create a
maintainable system. In other words, analysts should create a design that is
modular and flexible. To do this, analysts can design programs in a top-down
modular approach, using a variety of program design techniques.
Good program design is similar to the top-down modular approach that we

described. First, analysts create a high-level diagram that shows the various
components of a program, how the components should be organised, and how
the components interrelate. This diagram, known as the structure chart,
illustrates the organisation and interactions of the different pieces of code within
the program to the analysts and programmers so that the program can be
developed by many programmers working independently. The diagram can be
used when the project team plans to write code from scratch or when existing
pieces of code will be assembled to build the system. The physical process
models just described provide a good starting point for understanding what this
structure chart needs to include.
Once the overall program is defined at a high level, with a structure chart,
program specifications are written to describe exactly what needs to be included
in each program module. The specifications include basic module information
(such as a name, calculations that need to be performed and the target
programming language), special instructions for the programmer and
pseudocode. Pseudocode is a technique similar to structured English that is used
to communicate what needs to be written, using programming structures and a
generic language that is not program language specific. Program specifications
leave the implementation details to the programmers, but they communicate the
basic logic and programming structures to help reduce logical and syntactical
errors during the implementation phase. Some RAD approaches deemphasise
program specifications.
You will notice that the design techniques that are described here are based on
information and techniques from earlier phases of the SDLC. For example, the
components of the structure chart typically mirror the processes found on the
data flow diagrams and the process descriptions suggest the ways in which
structure chart components should interrelate. Data models are used to explain

the data that pass throughout the diagram. Also, analysts use the techniques and
information to develop the program specifications, especially when writing
pseudocode. Often during design, the analysts detect problems or inconsistencies
with the analysis deliverables and they must fine-tune or clarify previous work
as they move forward.
At the end of program design, the project team compiles the program design
document, which includes all of the structure charts and program specifications
that will be used to implement the system. The program design is used by
programmers to write code.
9.2.1 Structure Chart

What does structure chart represent?
Structure chart represents the inter-relationships between the program

modules.
The structure chart is an important technique that helps the analyst design the
program for the new system. The structure chart shows all the components of
code that must be included in a program at a high level, arranged in a
hierarchical format that implies sequence (in what order components are
invoked), selection (under what condition a module is invoked) and iteration
(how often a component is repeated).
The components are usually read from top to bottom, left to right and they are
numbered by a hierarchical numbering scheme in which lower levels have an
additional level of numbering (such as the third level of modules would be
numbered 1.1.1, 1.1.2, 1.1.3⁄ ).
Among the symbols in a structure chart is the perfect rectangle that represents a
module (together with arrows) and other symbols that give additional
information. High-level (control) modules direct the lower (subordinate)
modules.
The symbols inside a structured chart are:
(a) Module
Module is represented by a perfect rectangle. A perfect rectangle with lines
at the sides represents a library module. A library module can be re-used
and can be started from one or more points in the chart. A control module
is a higher-level component that contains the logic for performing other
modules, and the components that it calls and controls are considered
subordinate modules. Figure 9.3 shows an example of the modules in a
structure chart.
Figure 9.3: Example of modules in a structure chart

(b) Data Couple

Couples (shown by arrows) are drawn on the structure chart to show that
information is passed between modules, with the arrowhead indicating
which way the information is being sent. Arrow with a hollow circle
represents a data couple (see Figure 9.4).
Figure 9.4: Data couple

A data couple shows data that is transferred from module to module.

(c) Control Couple

Arrow with a filled (black) circle represents a control couple (see Figure
9.5).
Figure 9.5: Control couple

Control couple shows a message that is also called a flag. A flag is sent
from one module to another module. A module uses a flag to show a
condition or an action to another module.
(d) Condition
Arrow-line with a diamond at one end represents a condition (see Figure
9.6).
Figure 9.6: Condition

This shows that the control module determines the lower modules which
one to start depends on a certain condition.
(e) Loop
Curved arrow represents a loop. A loop shows that one or more modules
are repeated. In Figure 9.7, Get Student Grade module and Calculate GPA
(grade point average) module are repeated a few times according to how
many reports need to be produced.
Figure 9.7: Loop

(f) Cohesion
What does cohesion measure?
Cohesion measures the scope of a certain module and the processing

characteristics of the module. A module that performs only one
function or task has a high degree of cohesion.
A high degree of cohesion for a certain module is important because when

a module focuses on one function, it is easier to maintain and re-use (see
Figure 9.8).
Figure 9.8: Comparing a low degree with a high degree of cohesion

For example, compare a module called Access Student Number with a

module called Calculate and Print CGPA. The Access Student Number
module has a higher degree of cohesion compared with the Calculate and
Print CGPA because its job is more focused.

The tips that can be obtained here is that if a certain module has the word
„and‰, it means the module contains more than one job. Therefore,
programming that is required for that module is more complex, and
maintenance becomes more difficult.
In general, to achieve a high degree of cohesion and a better program

quality, the jobs need to be separated into different modules.
(g) Coupling
What does coupling measure?
Coupling measures the relationship and mutual dependence among

the modules. What is needed is for it to be a module that is less
dependent on another module or what is called loosely coupled.
Examples of structure charts that have loose coupling and tight coupling
are shown in Figure 9.9 (a) and Figure 9.9 (b).
Figure 9.9 (a): Structure chart for loose coupling


Figure 9.9 (b): Structure chart for tight coupling

The characteristics of these two modules are described in Table 9.1.
Table 9.1: Characteristics of Modules
Characteristics Explanation
Loosely They are easier to maintain and change. This is because the logic
Coupled inside one module does not affect the other modules. A programmer
who wants to modify a loosely coupled module needs to make
changes at one location only.
Tightly It means the module refers to a logic contained inside another
Coupled module. For example, Calculate CGPA module may refer to a
variable called Student Status that is contained inside a module
called Update Student Status. In this case, any logical error inside
the Update Student Status module will affect the Calculate CGPA
module.
SELF-CHECK 9.1
1. What is the meaning of cohesion and coupling?
2. Before you continue with your reading, try to explain the symbols
contained inside the structure chart.
(a) Module (b) Data Couple
(c) Control Couple (d) Condition
(e) Loop (f) Cohesion
(g) Coupling

9.2.2 Steps in Developing a Structure Chart

Structured charts are developed by referring to the data flow diagrams (DFD)
that were developed in earlier topics. There are four steps in producing a
structure chart. The steps are explained in Table 9.2.
Table 9.2: Steps in Producing a Structure Chart
Step 1 Refer to the DFD to identify the process and method present. Ensure that
the diagrams produced are balanced, precise and complete by taking into
account any change that has been made.
Step 2 Identify the modules and the relationship between control module and
subordinate modules.
Step 3 Add symbols for the couple, loop and conditions.
Step 4 Examine the structure chart to ensure that it meets the system
documentation.
Once the analyst has communicated the big picture of how the program should
be put together, he must describe the individual modules in enough detail so that
programmers can take over and begin writing code. Modules on the structure
chart are described by the use of program specifications, written documents that
include explicit instructions on how to program pieces of code.
Typically, project team members write one program specification for each
module on the structure chart and then pass them along to programmers, who
write the code during the implementation phase of the project. Specifications
must be very clear and easy to understand or else programmers will be slowed
down trying to decipher vague or incomplete instructions. There is no formal
syntax for a program specification, so every organisation uses its own format,
often a form like the one in Figure 9.10.

Figure 9.10: Sample of program specification

9.3 TESTING
Testing actually begins during application development. When a program is
compiled, the compiler would examine the syntax to track down syntax errors.
Syntax errors will be corrected by the programmer, and repeated until the
program is implemented without any syntax error message.

Figure 9.11 shows a program that passes through unit testing, integration testing
and system testing.
Figure 9.11: Program tests
The following subtopics will elaborate more on these three types of program
tests.
9.3.1 Unit Testing
Unit testing is done on the program or individual modules. This test will
examine the module's function individually to track down any error. Thus,
the test is also known as module testing.
This test is done together with coding. It aims to identify and remove logical
errors that cause the program to fail to function. During unit testing, the
programmer should also test the modules that interact with other modules before
all the individual modules are integrated. This test uses a technique called stub
testing.
Stub testing aims to test whether one program site can go to another program
site, and then return to the original program site. How to prove that you have
reached one program site? One way is to issue a print statement, such as „I have
arrived at Module A‰. By using stub testing, therefore, the programmer can
simulate the linking of all the related modules to show that they can work
together successfully, even before the modules are coded.

9.3.2 Integration Testing

This test is done to a group of modules that make up a sub-system. It can also be
done on several programs that are mutually dependent on each other. This test is
done bit by bit. In the beginning, two related modules are tested. Later, other
modules are grouped together to continue with the testing. Testing will continue
until all the modules that make up a sub-system are tested together.
9.3.3 System Testing

After unit testing and integration testing are done, all the programs will be tested
as a complete system. In system testing, different kinds of programs (sub-
systems) are combined together into one system and are tested. This test is also
done bit by bit.
System testing is good to be done using real data in the real working
environment, together with other systems that are present inside the working
environment. Through system testing, a software system will be tested to see
whether or not it is ready to handle the real workload effectively.
SELF-CHECK 9.2
1. What is another name for unit testing?
2. What is the difference between unit testing and integration

testing?
3. What is the objective of system testing?
9.4 DOCUMENTATION
Do you know that a systemÊs successful operation and maintenance depend on
good documentation? What is meant by documentation?
Documentation is an activity of recording all the specifications and facts

about an information system as a reference for the future.

References are certainly required whether for maintenance or for performing any
modification in future. A system that has completely gone into operation will not
remain permanent just like that. From time to time, there will be changes made.
The programmer who does the change on the program requires accurate
documentation. Besides that, the operators and users working on the system
throughout the system's life also need to refer to the documentation.
Documentation can simplify, speed up and reduce the cost of maintenance.

Among the main functions of documentation are:
(a) To describe the system; and

(b) To help users interacting with the system.
There are four types of documentation as shown in Figure 9.12.
Figure 9.12: Four types of documentation
These four types of documentation are explained in detail below:
(a) Program Documentation

Program documentation begins even during the systems analysis phase.
Processes for this documentation continue until the implementation phase.
The systems analyst provides the entire documentation, like process
description and report presentation. The programmer provides
documentation by providing the modules (program codes) together with
comments and explanations that are easy to understand and maintain. The
systems analyst will endorse the program documentation as being
complete and accurate.
(b) System Documentation

If the program documentation records information about the programs,
system documentation will explain the system's functionality and how the
functions are implemented.

Among the content of the system documentation are:
(i) Data dictionary;

(ii) Data flow diagram;
(iii) Entity relationship model;
(iv) Screen presentation;
(v) Source documents; and
(vi) System request that has initiated the project.
During system implementation, the analyst will examine system

documentation to endorse that it is complete, accurate and updated.
System documentation needs to include any change that has been made in
the process of implementation.
(c) Operating Documentation

Operating documentation helps the system operators (being workers in the
computer room) to execute jobs that are related to the execution of an
information system. Operator documentation contains all information
needed to process and distribute printed outputs. Among the contents of
this documentation are (Mohammad Noorman et al, 2001):
(i) Information about system's storage space;

(ii) Running or operating manual;
(iii) Frequency of operation; and
(iv) Systems management report.
Operation workers may not be able to operate the system without the
operating manual. The operating manual contains the steps for:
(i) Operating the system;

(ii) Handling of errors;
(iii) Getting the forms; and
(iv) Accessing the files as well as providing system security.
Operating documentation should be clear, easy to understand, and can be

accessed online. The operating manual typically looks like a list of „do's
and donÊts‰.
(d) User Documentation

This documentation contains instructions and information for users to
interact with the system. User documentation needs to be written in a
language that is easily understood by users. The usage of special terms that
are too technical needs to be avoided. This is because users do not know
anything about system development.
User documentation contains matters related to the system that help users
when they use the system. This type of documentation can be in the form of
user manual, help screen and tutorials.
Lastly, Table 9.3 summaries the four types of documentation.
Table 9.3: Four Types of Documentation
Documentation Summary
Program Information about programs that have been developed in the
Documentation system.
System Detailed information on the system design specifications and

Documentation their functionality.
Operating Detailed information for the use of the operating group on how to
Documentation start and stop the system, plus other activities to run applications
daily.
User Written or graphical information about the application system,

Documentation how the system functions and how to use the application.
SELF-CHECK 9.3
1. Explain each step that is contained in the development stage.
2. Writing for the documentation is an important activity in system

development. Give your opinion on the factors that need to be
emphasised in producing good documentation.
3. Describe four documentation types that you have learnt so far.

Why is documentation important during development?
4. Give the definition of unit testing, integration testing and system

testing.

System development is a process done to develop, install and test the

components that make up a system.
As for system implementation, it involves testing the systemÊs capability to

operate with varieties of workload in the real environment. This phase aims
to implement all the planning that has been made at the beginning.
Development contains the activities of design, coding, testing and

documentation.
Programs can be designed in a top-down modular approach, using a variety

of program design techniques. One of them is a structure chart.
Structure chart represents the inter-relationships between the program

modules. It describes module, data couple, control couple, condition, loop,
cohesion and coupling. There are three steps in producing a structure chart.
Three types of program testing are unit testing, integration testing and
system testing.
Documentation is one of the important activities during development. There

are four types of documentation like program documentation, system
documentation, operating documentation and user documentation.
Coding System documentation

Design System implementation
Documentation System testing
Integration testing Testing
Operating documentation Top-down modular approach
Program documentation Unit testing
Structure chart User documentation
System development

Topic Transition to
10 New System
LEARNING OUTCOMES
1. Describe migration plan;
2. Identify four installation approaches;
3. Describe how to conduct user training;
4. Explain three methods of data conversion; and
5. Summarise how to do evaluation.
INTRODUCTION
This topic discusses the activities needed to install the information system and
successfully convert the organisation to using it. Installing the system and making
it available for use from a technical perspective is relatively straightforward.
However, the training and organisational issues surrounding the installation are
more complex and challenging because they focus on people, not computers.
10.1 MIGRATION PLAN

The transition from the old business processes and computer programs to the
new business processes and computer programs will be facilitated by ensuring
that a number of business, technical and people issues are addressed. The
decisions, plans and procedures that will guide the transition are outlined in the
migration plan (see Figure 10.1.).

TOPIC 10 TRANSITION TO NEW SYSTEM 199
Figure 10.1: Elements of a migration plan

The migration plan specifies what activities will be performed when and by
whom as the transition is made from the old to the new system.
In order to ensure that the business is ready to make the transition, the project
team must determine the best conversion strategy or also known as installation
strategy to use as the new system is introduced to the organisation. Also, plans
should be made to ensure that the business can continue its operations even in
the event of technical glitches in the new system. These plans are termed as
business contingency plans.

As for technical readiness, it is achieved by arranging for and installing any
needed hardware and software, and converting data as needed for the new
system. These arrangements, while essential, are usually the least difficult of all
the issues dealt with in the migration plan.
Last but not least, ensuring that the people who will be affected by the new
system are ready and able to use it is the most complex element of the migration
plan. Managing the „people‰ side of change requires the team to understand the
potential for resistance to the new system, develop organisational support and
encouragement for the change and prepare the users through appropriate
training activities.
10.2 INSTALLATION
When a new system has been completely developed and tested, it needs to be
installed at locations where it is supposed to run. The process of installation is a
complex one as it involves users who need to leave the old system behind and
begin to use the new system completely. Installation will confirm whether or not
the new system can perform the functions that have been planned for it.

200 TOPIC 10 TRANSITION TO NEW SYSTEM
However, there are some issues related to installation. Among them are:
(a) Cost involved when both the new and old systems run concurrently;
(b) Tracking and correcting errors in the new system;
(c) New system installation that disturbs daily running of an organisation; and
(d) User training and customer familiarisation with the new system.
Take note that different ways of system installation have different effects on the
costs, complexity and risks.
There are four approaches to installation. These are shown in Figure 10.2.
Figure 10.2: Four installation approaches
Take note that every method of installation has its own advantages and
disadvantages; these will be explained further in the next subtopics.
10.2.1 Direct Installation

Through this method, a new system is installed and will operate directly, while
the old system is immediately stopped. The old and new systems may overlap
for a very short period (if required) while waiting for the new system to be up
and running.
The advantage of this approach lies in the fact that it is easily done. Since the old
and new systems do not operate concurrently, the cost is low and additional
resources are not required.

However, the disadvantage of this approach is associated with the risk of failure
of the new system. If the new system fails to function, the organisation does not
have support from the old system anymore, because the old system has been
discontinued. Figure 10.3 illustrates the method of direct installation.
Figure 10.3: Direct installation

Source: Adapted from Satzinger, Jackson and Burd (2002)
This method can be used in any of the following situations:
(a) When there is no existing system, whether manual or computerised, the

new system is not replacing any current system in the organisation, as such
the only one running is the new system; and
(b) If you can tolerate a system's failure for a few days or weeks, you may
adopt this approach, otherwise try to avoid it.
If you are not in either of these two situations, then you have to look for other
approaches like phase installation, parallel installation or pilot installation.
10.2.2 Parallel Installation

In parallel installation, the old and new systems will operate at the same time for
a certain period of time, maybe weeks or months. In this way, the old system will
continue to function until the new system is completely tested, endorsed free of
errors and can operate independently on its own.

The advantage of parallel installation is the low risk of system failure and the low
effect of system failure. Figure 10.4 shows the method of parallel installation.
Figure 10.4: Parallel installation

10.2.3 Pilot Installation

Through this method, the entire system is installed at one chosen location of the
company. For example, Sales Management System is installed in one branch of
TESCO Supermarket in Peninsular Malaysia. The location that uses the system
for the first time is called pilot site (Shelly et al, 2001).
When the new system is used at that location, the old system is still running in
the entire company. When the new system has been tested completely at the pilot
site and used successfully there, only then the system is installed completely in
other branches of the company by following the direct installation approach.
The advantage of this method is the risk of failure is less when compared with
the direct installation approach. The costs of operating the old system and the
new system at the chosen location are also less than the parallel installation.
Figure 10.5 shows the method of pilot installation.
Figure 10.5: Pilot installation

10.2.4 Phase Installation

Lastly, let us look at the phase installation. Through this approach, the system is
installed and begins to operate on a phase-by-phase basis. From beginning to the
end of installation, each phase will add more to the systemÊs functionality. For
each phase, the system will be tested to ensure that it can continue to the
subsequent phase.
The advantage of the phase installation approach is the reduction of risk. Risk is
reduced because failure of one phase gives smaller problems when compared
with failure of the entire system.
However, the main disadvantage of phase installation is the increase in

complexity and time. When the installation is divided into different phases, it
will create more activities to be managed and will drag the time further.
This installation is suitable for a large-sized and complex system. Such a system
contains many sub-systems that are suitable for phase installation. Figure 10.6
shows the method of phase installation.
Figure 10.6: Phase installation


SELF-CHECK 10.1
1. What are the methods that can be used to install new systems in
an organisation?
2. What are the differences between direct installation and phase

installation?
10.3 TRAINING
Firstly, let us learn the meaning of training.
Training is a process to enable users to understand the system and how the
system can be used to help increase productivity and facilitate them in
performing their jobs more effectively.
Training is probably the most self-evident part of any change management

initiative. How can an organisation expect its staff members to adopt a new
system if they are not trained? The system that has been developed and installed
perfectly would be of no use if users of the system cannot use it effectively. As
such, before users start to use the system, they need to be trained and be
knowledgeable in the use of the system.
Who needs training? Training needs to be given to:
(a) Users;
(b) Managers; and
(c) Staff of the information technology department.
Training for a new system cannot be ignored even if the new system has many
similarities with the old system. There are bound to be differences in their mode
of operation. Therefore, even while documentation is developed, we need to
think of how it will be used during training. Training needs to be provided to the
right people at the right time.
The first thing that needs to be done is to identify who needs to be present at the
training and the form of training that needs to be provided. Example of training
for certain user groups is listed in Figure 10.7.

Figure 10.7: Training for different groups with different needs

Every group has its own but different requirements. Among them are:
(a) Managers need not understand every function of the system. Nevertheless,
they need the overall picture of the system to ensure that users are trained
correctly and use the system wisely.
(b) Users need to know how to execute their daily jobs without knowing the
cost of operations for different sections.
(c) The group that needs a lot of information is the Information Technology
staff. They need to understand the system's functions, how the system
supports business needs and the skills that users need to have in order to
use the system in performing their jobs.
When the objectives of the system have been identified, we then need to
determine how training will be provided.

ACTIVITY 10.1
1. In your opinion, what will happen to a certain system if system

users are not given the training on how to handle the system? What
are the basic items that need to be known by system users?
2. Give five examples of training that are suitable for users.
10.3.1 Training Guide

Kendal and Kendal (2001) list four main guides on the conduct of training from
the early phase to the final phase. These guides are listed in Figure 10.8.
Figure 10.8: Main guides on training from early phase to final phase
Source: Kendal and Kendal (2001)
These guides are further explained as follows:
(a) Training Objective

Training objectives are determined by the participants of each session. The
objectives of each group must be clear. Through clear objectives, the
training participants will know what skills they need to learn from the
training session. By comparing what they learn with the objectives
outlined, they can provide feedback for the training evaluation.

(b) Training Method

Every group needs a training method that is different and related to the
type of work they do. Besides that, an individual's ability and background
will also influence acceptance of the training. Among the training methods
used are listening, seeing and practice.
Normally, training sessions will combine all these three methods so that
every individual need can be fulfilled. For the listening method, training
takes the form of speech, discussion and question-and-answer sessions. The
seeing method involves demonstration of tools and hardware, while the
practical method involves training that makes use of tools.
(c) Training Site

Training can be done at different locations. Computer suppliers provide
special off-site locations that store the hardware. Users can focus attention
on learning a new system at these locations.
However, the disadvantage of off-site training is that users cannot learn the
system in the real environment. Aside from off-site training, on-site
training inside the organisation can also be organised. Through on-site
training, users can use the system in the real environment.
(d) Training Material

Training material that is complete and well provided will make the training
objective a success. Among the content of the training material are the
manual, training cases, prototypes and output examples. User
understanding of the system depends on the training material provided.
Therefore, the training material must be clearly explained. As far as

possible, the use of technical terms in the training material should be
reduced.
10.3.2 Types of Training

After learning about the guidelines on the conduct of training, we will next learn
about the types of training that are available. Among the types of training that
will be discussed are:
(a) Supplier Training

Most of the software and hardware suppliers offer training programmes for
free or for a suitable price together with the goods they sell. Companies can
also negotiate on the training cost with the supplier by considering the
relationship with suppliers and the long-term prospect of a relationship.
Training that is done at a supplier's place is normally conducted by an

expert in the field, with long practical experience.
However, if the training involves many participants from one organisation,

it can be negotiated to be conducted inside the organisation itself. Supplier
training focuses on the product that is developed by the supplier itself.
Therefore, the scope of training is limited to the software or hardware
version that is owned by the supplier.
(b) External Training Source

Besides the supplier, training firms can also provide software or hardware
training. Among the hardware and software companies that provide
training are IBM and Hewlett Packard (Shelly et al, 2001).
(c) In-House Training Source

Staff in the information technology department of a company are normally
responsible for the conduct of training when the software is developed in
the company itself. Microsoft Power Point presentations that include
multimedia elements can be used to provide presentations effectively.
Shelly et al (2001) lists out several guidelines to conduct training as stated
in Table 10.1.
Table 10.1: Guidelines on the Conduct of Training
In-House Training Description

In Group Conduct the training in groups with different training
programmes for different groups. Group training saves time
and training resources. Training sessions need to take into
account the background, skills and type of work of the
participants from different groups.
Site Choose the site that is most effective to conduct the training.
Conducting training in the company itself has several
advantages such as reduction of travelling cost and training
is done in the real environment in which the system
operates.
However, the disadvantages of this method are:
Training participants may be disturbed by things related

to real jobs.
The use of computer resources for training may disturb

company's operation and this will reduce the opportunity
for practical training.

Method Ensure that listening, seeing and practical elements are

included in the training session. The way a person learns
something is different from one individual to another. As far
as possible, a training programme needs to fulfil every
different method of learning.
Effective Training Get ready with effective training materials and interactive
Material tutorials. Training material that is user-friendly will produce
effective training and will become a useful resource for users.
Training material can be in the form of training manuals,
handouts or online material.
Services of Workers Try to use the services of workers who have gone through
who have gone the same sort of training before. After one group has
through the same undergone training, they can help another group. This
Training strategy is called „train-the-trainer‰, which can be done by
selecting an employee with wide experience who can train
other people later.
Source: Shelly et al (2001)
SELF-CHECK 10.2
1. What are the examples of training items that are used to train
managers in an organisation?
2. Describe four guidelines on the conduct of training as proposed

by Kendal and Kendal (2001)?
10.4 DATA CONVERSION

Do you know that data conversion is an important part of the system installation
process? During data conversion, existing data is loaded into the new system.
Depending on the system, data conversion can be done before, during or after the
operational environment is complete.
You should develop a data conversion plan as early as possible and the
conversion process should be tested when the test environment is developed.
When a new system replaces an existing system, you should automate the data
conversion process, if possible. The old system might be capable of exporting
data in an acceptable format for the new system or in a standard format, such as
ASCII or Open Database Connectivity (ODBC).

ODBC is an industry-standard protocol that allows DBMSs from various vendors

to interact and exchange data. Most database vendors provide ODBC drivers,
which are a form of middleware. Middleware connects dissimilar applications
and enables them to communicate.
If there is no standard format, a program can be developed to extract data and

convert it into an acceptable format. When a new system is developed to replace
a manual system, any data from the manual system needs to be typed into the
new system one by one. However, this can be avoided by simply scanning the
old data and storing it.
You should maintain strict input controls during the conversion process, when
data is extremely vulnerable. You must ensure that all system control measures
are in place and operational to protect data from unauthorised access and to help
prevent erroneous input.
Even with careful data conversion and input controls, some errors will occur. For
example, duplicate customer records or inconsistent part numbers might have
been tolerated by the old system, but will cause the new system to crash. Most
organisations require that users verify all data, correct all errors and supply
every missing data item during conversion. Although the process can be time-
consuming and expensive, it is essential that the new system be loaded with
accurate and error-free data.
Kendall and Kendall (2001) say that there are three methods of data conversion
that can be used in the process of moving on to a new system. These methods are
given in Table 10.2.

Table 10.2: Methods of Data Conversion
Method Explanation
Using the This is the simplest method of data conversion, in which the old
Existing database is directly used by the new system, without change or with
Database just a little change. Changes needed may be the addition of classes or
entities, attributes and relationships. Existing attributes may also
change. All these changes are done using the functions of database
management system (DBMS).
Reload the Sometimes, a database needs to pass through complex changes before
Content of being used by a new system. In this case, data needs to be reloaded
Database into the database after the change process has been completed. Most
DBMS have facilities to extract and load data from databases, file and
documents that are scanned. This facility simplifies the process of data
imported from other sources.
Create a A new database is developed for a new system or a system that

New replaces a manual system. Data for the database of this kind can be
Database obtained from records or other automated systems in the organisation.
SELF-CHECK 10.3
What are the methods that can be used to convert data?
10.5 EVALUATION
Before we end this topic, let us look at evaluation. Are you aware that once the
new system is operational, you must perform post-implementation evaluation? A
post-implementation evaluation assesses the overall quality of the information
system.
The evaluation is conducted to verify that the new system meets specified
requirements, complies with user objectives and produces the anticipated
benefits.
In addition, by providing feedback to the development team, the evaluation also

helps improve IT development practices for future projects.

A post-implementation evaluation should examine all aspects of the

development effort and the end product of the developed information system. A
typical evaluation includes feedback for the following areas:
(a) Accuracy, completeness and timeliness of information system output;

(b) User satisfaction;
(c) System reliability and maintainability;
(d) Adequacy of system controls and security measures;
(e) Hardware efficiency and platform performance;
(f) Effectiveness of database implementation;
(g) Performance of the IT team;
(h) Completeness and quality of documentation;
(i) Quality and effectiveness of training; and
(j) Accuracy of cost-benefit estimates and development schedules.
You can apply the same fact-finding techniques in a post-implementation

evaluation that you used to determine the system requirements during the
systems analysis phase. When evaluating a system, you should:
(a) Interview members of management and key users;

(b) Observe users and computer operations personnel actually working with
the new information system;
(c) Read all documentation and training materials;
(d) Examine all source documents, output reports and screen displays;
(e) Use questionnaires to gather information and opinions from a large
number of users; and
(f) Analyse maintenance and help desk logs.
Whenever possible, people who were not directly involved in developing the
system should conduct the post-implementation evaluation. IT staff and users
usually perform the evaluation, although some firms use an internal audit group
or independent auditors to ensure the accuracy and completeness of the
evaluation.

When should post-implementation evaluation be done? Is it better to wait until

the new system has been in operation for one month, six months, one year or
longer? Users may forget details of the developmental effort if too much time
elapses before the evaluation. After several months or a year, for instance, users
might not remember whether they learned a procedure through training, from
user documentation or by experimenting with the system on their own.
Users also might forget their impressions of IT team members over time. An
important purpose of the post-implementation evaluation is to improve the
quality of IT department functions, including interaction with users, training and
documentation.
Consequently, the evaluation team should perform the assessment while users
are able to recall specific incidents, successes and problems so they can offer
suggestions for improvement. Post-implementation evaluation is primarily
concerned with assessing the quality of the new system. If the team performs the
evaluation too soon after implementation, users will not have enough time to
learn the new system and appreciate its strengths and weaknesses. Although
many IT professionals recommend conducting the evaluation after at least six
months of system operation, pressure to finish the project sooner usually results
in an earlier evaluation in order to allow the IT department to move on to other
tasks.
Ideally, conducting a post-implementation evaluation should be standard

practice for all information systems projects. Sometimes, evaluations are skipped
because users are eager to work with the new system or because IT staff
members have more pressing priorities. In some organisations, management
might not recognise the importance and benefits of a post-implementation
evaluation. The evaluations are extremely important, however, because they
enable the development team and the IT department to learn what worked and
what did not work. Otherwise, developers might commit the same errors in
another system.

Migration plan outlines the decisions, plans and procedures that will guide
the transition from the old business processes and computer programs to the
new business processes and computer programs.
Four installation approaches are direct installation, parallel installation, phase

installation and pilot installation.
Training is a process to enable users to understand the system and how the
system can be used to help increase productivity and facilitate them in
performing their jobs more effectively.
Training needs to take into account who will be trained, the specific needs of
the trainee group, who are the trainers, the training methods, the training
materials and others.
Main guides on training are training objectives, training methods, training

sites and training material.
Three methods of data conversion are using the existing database, reload the
content of database and create a new database.
A post-implementation evaluation assesses the overall quality of the

information system.
The evaluation verifies that the new system meets specified requirements,
complies with user objectives and produces the anticipated benefits.
The same fact-finding techniques can be applied in a post-implementation

evaluation to determine the system requirements during the systems analysis
phase.

Data conversion Pilot installation

Direct installation Post-implementation evaluation
Evaluation Training material
Migration plan Training method
Parallel installation Training objective
Phase installation Training site

Topic System
11 Support and
Maintenance
LEARNING OUTCOMES
1. Describe the types of support in system support;
2. Identify the objectives and types of maintenance;
3. Explain the steps in maintenance request;
4. Describe what is maintenance release;
5. Identify the signs of system obsolescence; and
6. Summarise the backup policy needed for an organisation.
INTRODUCTION
The operation and support phase involves a lot of maintenance activities. The
maintenance done is again divided into several types, such as corrective
maintenance, adaptive maintenance and so on.
Normally, corrective maintenance is the most often done. Expenses for the
information system do not end by the time it is completely built. Instead, more
expenses are incurred for maintenance rather than for system development.
Expenses for system maintenance would even go up higher from year to year. An
information system needs to be maintained and upgraded from time to time in
response to the need for changes in business requirements.

TOPIC 11 SYSTEM SUPPORT AND MAINTENANCE 217
11.1 SYSTEM SUPPORT

Once the project team has installed the system and performed the change
management activities, the system is officially turned over to the operations
group. This group is responsible for the operation of the system, whereas the
project team is responsible for the development of the system. Members of the
operations group usually are closely involved in the installation activities
because they are the ones who must ensure that the system actually works. After
the system is installed, the project team leaves but the operations group remains.
Providing system support means helping the users to use the system. Usually,
this means providing answers to questions and helping users understand how to
perform a certain function; this type of support can be thought of as on-demand
training.
Online support is the most common form of on-demand training. This includes
the documentation and help screens built into the system, as well as separate web
sites that provide answers to frequently asked questions (FAQs) that enable users
to find answers without contacting a person.
Obviously, the goal of most systems is to provide sufficiently good online

support so that the user does not need to contact a person, because providing
online support is less expensive than providing a person to answer questions.
Most organisations provide a help desk that provides a place for a user to talk
with a person who can answer questions (usually over the phone, but sometimes
in person). The help desk supports all systems, not just one specific system, so it
receives calls about a wide variety of software and hardware. The help desk is
operated by level 1 support staff who have very broad computer skills and are
able to respond to a wide range of requests, from network and hardware
problems to problems with commercial software and with the business
application software developed in house.
The goal of most help desks is to have the level 1 support staff resolve 80% of the
help requests they receive on the first call. If the issue cannot be resolved by level
1 support staff, a problem report is compiled (often using a special computer
system designed to track problem reports) and passed to a level 2 support staff.
The level 2 support staff are people who know the application system well and
can provide expert advice. For a new system, they are usually selected during the
implementation phase and become familiar with the system as it is being tested.
Sometimes, the level 2 support staff participate in training during the change

218 TOPIC 11 SYSTEM SUPPORT AND MAINTENANCE
management process to become more knowledgeable with the system, the new
business processes, and the users themselves.
The level 2 support staff work with users to resolve problems. Most problems are
successfully resolved by the level 2 staff. In the first few months after the system
is installed, however, the problem may turn out to be a bug in the software that
must be fixed. In this case, the problem report becomes a change request that is
passed to the system maintenance group.
11.2 SYSTEM MAINTENANCE

What is meant by system maintenance?
System maintenance is the process of refining the system to make sure it

continues to meet business needs.
Over a systemÊs lifetime, more money and effort are devoted to system
maintenance than to the initial development of the system, simply because a
system continues to change and evolve as it is used. Most beginning systems
analysts and programmers work first on maintenance projects; usually only after
they have gained some experience are they assigned to new development
projects.
Satzinger et al (2002) state that according to the Institute of Electrical and

Electronic Engineers (IEEE) and American National Standards Institute (ANSI),
software maintenance on software products is done to fulfil at least one of the
objectives shown in Figure 11.1.
Figure 11.1: Objectives of system maintenance

Maintenance includes any change to the system after it has been completely
developed. Maintenance involves changes in various aspects. Making changes to
a system in operation can be more complex than making changes during system
development. This is because any change in the system in operation would affect
users, customers and the organisation. However, maintenance needs to be done
to prevent system failure during operation.
Satzinger et al (2002) list out several activities of maintenance as follows:
(a) Tracing the request for change and error reports;

(b) Implementing changes;
(c) Checking the system's capability and upgrading capability or capacity;
(d) Upgrading the status of hardware and system software; and
(e) Updating of documentation for changes made through maintenance.
There are many similarities between maintenance of an old system and

development of a new one. Among them are:
(a) Analysis;
(b) Design;
(c) Development;
(d) Testing; and
(e) Documentation.
Their differences are mainly in terms of the scope and limitations of the
implementation. The maintenance process involves the activity of changing the
system through suitable maintenance work. There are four types of maintenance,
namely corrective maintenance, adaptive maintenance, perfective maintenance
and preventive maintenance.
11.2.1 Corrective Maintenance

Firstly, what does corrective maintenance mean?
Corrective maintenance is a process that corrects any problem in the system

that has been caused by mistakes and errors.

In spite of the fact that the system has been completely developed and tested, it is
not necessarily free from problems. Mistakes could be inside the formula or
could be due to rounding errors. This is the most frequently done maintenance.
Any mistake or error present in the system has the potential of disturbing the
systemÊs operation. Therefore, this kind of problem needs to be solved quickly to
avoid losses in future.
To do this maintenance, the party involved needs to refer to the program

documentation that contains technical explanations. Program documentation that
is complete would help those doing the corrective maintenance to track down
mistakes quickly and make appropriate corrections. Mistakes and errors that are
hidden in the system would appear only when the system begins to operate in
the real environment.
11.2.2 Adaptive Maintenance

What does adaptive maintenance mean?
Adaptive maintenance adapts the software to a new enviornment. It may

also give new additions in the form of features and capabilities to enable it to
function in the new environment.
The need for adaptive maintenance is born out of changes in the computing as
well as the business environments. Computers experience changes in operating
system from Windows to UNIX and so on. Similarly, business experiences
change like new products and services, new technology, support for web-based
operation and so on.
11.2.3 Perfective Maintenance

What does perfective maintenance mean?
Perfective maintenance is a process that changes the system to make it more

effective, more reliable or more maintainable. It also involves addition of
new feartures and capabilities to move the system closer to perfection.

Sometimes, the effectiveness of a system's operation will decrease while the

system is in operation. So, perfective maintenance is done to make it more
effective. Now features and functionality need to be added to every system in
order to satisfy users. This is the province of perfective maintenance.
11.2.4 Preventive Maintenance

Lastly, let us look at preventive maintenance. What does it stand for?
Preventive maintenance refers to any change to the system that is done to

prevent any problem in future. It also involves changes to make it more
maintainable so as to prolong the system's life.
Problems can be viruses, system failure, program readability, Y2K type of issues
and so on. To prevent such problems from occurring, analysis is done on the
section that might cause them. Preventive maintenance would upgrade
performances and user satisfaction, and reduce system failure and cost.
11.3 MAINTENANCE REQUESTS

Typically, maintenance requests involve a series of steps, as shown in Figure 11.2.
Figure 11.2: Steps in the request for maintenance
After a user submits a request, a system administrator determines whether

immediate action is needed and whether the request is under a prescribed cost
limit. In non-emergency requests that exceed the cost limit, a systems review
committee assesses the request and either approves it with a priority or rejects it.
The system administrator notifies affected users of the outcome.

Now let us get back to the steps of maintenance request. Further explanations of
these steps are as follow:
(a) User Makes Request

When a system does not function properly, a user sends a request for
adaptive or corrective maintenance. Users also send a request if they want
a new feature to be added to the system. Information technology staff
would normally request for perfective and preventive maintenance. To
keep proper records of every maintenance work, all jobs need to be
preceded by requests from users in the form of letters or e-mails.
(b) System Administrator Makes Initial Decision

A system administrator is often responsible for the management of a
certain system configuration. When a user sends a request, the
administrator makes the initial decision. If the request is related to a serious
problem, a team is instructed to do the corrective maintenance.
In a non-critical situation, the administrator accepts or rejects the request.

The administrator also postpones his action and makes a detailed study.
Then, the administrator informs any decision to the user who has made the
request and the system evaluation committee regarding any decision made
and the reason to that effect.
(c) System Evaluation Committee Makes Final Decision

When a request exceeds a predetermined cost level or involves a major
configuration change, the systems review committee either approves it and
assigns a priority or rejects it.
(d) Task Completion

The system administrator is usually responsible for assigning maintenance
tasks to individuals or to a maintenance team. Depending on the situation
and the companyÊs policy, the system administrator might consider
rotating assignments among the IT staff or limiting maintenance tasks to
certain individuals or teams.
(e) User Notification

Users who initiate maintenance requests expect a prompt response,
especially if the situation directly affects their work. Even when corrective
action cannot occur immediately, users appreciate feedback from the
system administrator and should be kept informed of any decisions or
actions that could affect them.

The process of determining the priority for maintenance work can be done in two
ways:
(a) The system evaluation committee separates the requests for maintenance
from the requests for new system development before evaluating and
determining their priorities. So, the requests for maintenance will given
priorities.
(b) All the requests for new systems and for maintenance of existing systems
are gathered as a group and given priorities. In this case, all the requests
would be evaluated, and the most important project would be given the
highest priority, regardless of whether they are for maintenance or for new
developments.
Both the stated methods contain advantages and disadvantages. In either

method, the most important thing is to produce a procedure that can balance
maintenance and new system development so that it can support business
requirements.
SELF-CHECK 11.1
1. What are the two main activities in the system support and
operation phase?
2. What are the reasons for doing maintenance?
3. Explain what is meant by corrective maintenance.
11.4 MAINTENANCE RELEASES

Keeping track of maintenance changes and updates can be difficult, especially for
a complex system. When a maintenance release methodology is used, all non-
critical changes are held until they can be implemented at the same time. Each
change is documented and installed as a new version of the system called a
maintenance release.
For an in-house developed system, the time between releases usually depends on
the level of maintenance activity. A new release to correct a critical error,
however, might be implemented immediately rather than saved for the next
scheduled release.

When a release method is used, a numbering pattern distinguishes the different

releases. In a typical system, the initial version of the system is 1.0, and the
release that includes the first set of maintenance changes is version 1.1. A change,
for example, from version 1.4 to 1.5 indicates relatively minor enhancements,
while whole number changes, such as from version 1.0 to 2.0 or from version 3.4
to 4.0, indicate a significant upgrade.
The release methodology offers several advantages, especially if two teams

perform maintenance work on the same system. When a release methodology is
used, all changes are tested together before a new system version is released. This
approach results in fewer versions, less expense, and less interruption for users.
Using a release methodology also reduces the documentation burden, because all
changes are coordinated and become effective simultaneously.
However, a release methodology also has some potential disadvantages. Users

expect a rapid response to their problems and requests, but with a release
methodology, new features or upgrades are available less often. Even when
changes would improve system efficiency or user productivity, the potential
savings must wait until the next release, which might increase operational costs.
Commercial software suppliers also provide maintenance releases, often called

service packs. As Microsoft explains, a service pack contains all the fixes and
enhancements that have been made available since the last program version or
service pack.
11.5 SYSTEM OBSOLESCENCE

Do you know that every system would experience obsolescence? Even the system
that is actively being maintained will become obsolete one day. System
obsolescence is closely related to the development of information and
communication technologies (ICT).
These technologies are always fast developing and this causes systems to have
limited lifetime. Managers and analysts need to realise that system obsolescence
can be predicted, actually, guided by some signs. Among the signs of system
obsolescence are when users do not need a set of system functions or when the
systemÊs platform becomes out-of-date.

The main reason for terminating a system's life is when the system is no longer
useful economically and this is shown through the following signs (see Table
11.2).
Table 11.2: Signs of System Obsolescence
Signs Explanation
History of History of system maintenance shows that adaptive and corrective
Maintenance maintenance becomes more frequent.
Cost or Time Operation cost or implementation time has increased rapidly and
perfective maintenance cannot reverse this trend.
Software There are software experts in the market who provide services that are
Experts comparable, but faster, better and cheaper than the existing system.
Technology New technology provides the method of doing the same functions
more effectively.
Difficult and Maintenance for changes or additions has become more difficult and
Expensive more expensive to be done.
New Users make requests for new features to support business

Features requirements.
Source: Shelly et al (2001)
Operation and support of the system would continue until a new replacement
system is installed. While approaching the end of a system's operation life, users
would not make any more requests for adaptive or perfective maintenance
because they are waiting for a new system.
At the same time, information technology staff would not do anymore perfective
or preventive maintenance, because its cost cannot be justified by getting a
system with a very short life. Therefore, towards the end of system's life, the
system only needs corrective maintenance just to continue with its operation.
User satisfaction influences much of the system's life. The critical success factor of
a system is whether the system is able to help users to achieve the operation and
business objectives. Information technology staff would receive inputs from
users and managers throughout the system development process. Any negative
input needs to be investigated in detail because this may become an early sign of
pushing the system towards obsolescence.

SELF-CHECK 11.2
1. What are the steps in managing requests for changes?
2. What are the signs of system obsolescence?
ACTIVITY 11.1
You find that the existing system in your company needs changes. You
wish to see a new system that is more effective. Your company chief has
asked you to plan for a change to the system. Try to state what are the
activities that need to be done during your planning for changes.
11.6 BACKUP AND RECOVERY

Lastly, let us learn about backup and recovery. Take note that every system must
provide data backup and recovery.
Backup refers to copying data at prescribed intervals or continuously.
On the other hand, recovery involves restoring the data and restarting the system
after an interruption. An overall backup and recovery plan that prepares for a
potential disaster is called a disaster recovery plan.
The cornerstone of business data protection is a backup policy, which contains

detailed instructions and procedures. An effective backup policy can help a firm
continue business operations and survive a catastrophe. The backup policy
should specify backup media, backup types and retention periods.

11.6.1 Backup Media

This includes tape, hard drives, optical storage and online storage. Physical
backups must be carefully identified and stored in a secure location.
As for offsiting, it refers to the practice of storing backup media away from the
main business location, in order to mitigate the risk of a catastrophic disaster
such as a flood, fire or earthquake. Even if the operating system includes a
backup utility, many system administrators prefer to use specialised third-party
software that offers more options and better controls for large-scale operations.
11.6.2 Backup Types

This can be full, differential, incremental or continuous. A full backup is a
complete backup of every file on the system. Frequent full backups are time
consuming and redundant if most files are unchanged since the last full backup.
Instead of performing a full backup, another option is to perform a differential

backup, which is faster because it backs up only the files that are new or changed
since the last full backup. To restore the data to its original state, you restore the
last full backup and then restore the last differential backup. Many IT managers
believe that a combination of full and differential backups is the best option,
because it uses the least amount of storage space and is simple.
The fastest method, called an incremental backup, only includes recent files that
have never been backed up by any method. Most large systems use continuous
backup, which is a real-time streaming method that records all system activity as
it occurs. This method requires expensive hardware, software and substantial
network capacity. However, system restoration is rapid and effective because
data is being captured in real time, as it occurs.
11.6.3 Retention Periods

Generally, backups are stored for a specific retention period after which they are
either destroyed or the backup media is reused. Retention periods can be a
specific number of months or years, depending on legal requirements and
company policy. Stored media must be secured, protected and inventoried
periodically.

Support activity begins after the system has begun operating. System support
activity helps the organisation and users to use the system's capability to the
fullest. Certain types of support are on-demand training, frequently asked
questions (FAQs) and help desk.
System maintenance objectives are to correct errors, upgrade capability and

other attributes and to adapt the product to changes in the environment.
There are four types of maintenance, namely corrective maintenance,

adaptive maintenance, perfective maintenance and preventive maintenance.
The steps in maintenance request are user makes request, system

administrator makes initial decision, system evaluation committee makes
final decision, maintenance tasks are distributed and results are made known
to the users.
Each change is documented and installed as a new version of the system

called a maintenance release.
The signs of system obsolescence are history of maintenance, cost or time,

software experts, technology, difficult and expensive and new features.
Backup refers to copying data at prescribed intervals, or continuously.
Recovery involves restoring the data and restarting the system after an
interruption.
An overall backup and recovery plan that prepares for a potential disaster is
called a disaster recovery plan.
The backup policy should specify backup media, backup types and retention
periods.

Adaptive maintenance Perfective maintenance

Backup policy Preventive maintenance
Corrective maintenance Recovery
Maintenance release System obsolescence
Maintenance request System support

MODULE FEEDBACK
MAKLUM BALAS MODUL
If you have any comment or feedback, you are welcome to:
1. E-mail your comment or feedback to modulefeedback@oum.edu.my
OR
2. Fill in the Print Module online evaluation form available on myINSPIRE.
Thank you.
Centre for Instructional Design and Technology

(Pusat Reka Bentuk Pengajaran dan Teknologi )
Tel No.: 03-27732578
Fax No.: 03-26978702


CBAD2103 System Analysis and Design Capr14 (RS) (M) PDF

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

CBAD2103 System Analysis and Design Capr14 (RS) (M) PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CBAD2103 System Analysis and Design Capr14 (RS) (M) PDF

Uploaded by

Copyright:

Available Formats

Faculty of Science and Technology

Copyright © Open University Malaysia (OUM)

Copyright © Open University Malaysia (OUM)

Module Writers: Kamsuriah Ahmad

Translated & Revised: Mohd Zahari Awang

Moderator: Hazalina Hashim

Developed by: Centre for Instructional Design and Technology

First Edition, November 2008

Copyright © Open University Malaysia (OUM)

Topic 1 Introduction to Information Systems 1

Topic 2 System Development Methodology 17

Copyright © Open University Malaysia (OUM)

2.4 Selecting the Appropriate Development Methodology 36

Topic 3 Managing a Project 41

Topic 4 Determination of System Requirements 67

Copyright © Open University Malaysia (OUM)

Topic 5 Process Modelling 104

Topic 6 System Design 133

Topic 7 Architecture Design 147

Copyright © Open University Malaysia (OUM)

Topic 8 User Interface Design 161

Topic 9 System Development and Implementation 178

Topic 10 Transition to New System 198

Copyright © Open University Malaysia (OUM)

10.4 Data Conversion 209

Topic 11 System Support and Maintenance 216

Copyright © Open University Malaysia (OUM)

Copyright © Open University Malaysia (OUM)

Copyright © Open University Malaysia (OUM)

Copyright © Open University Malaysia (OUM)

Table 1: Estimation of Time Accumulation of Study Hours

1. Explain the business process;

2. Identify information system components;

3. Describe system development methodology, tools and techniques;

4. Elaborate on system development life cycle;

5. Determine system requirement by fact-finding and process modelling; and

6. Summarise the system design, maintenance and support activities.

Copyright © Open University Malaysia (OUM)

Topic 3 begins with discussion on the systems analystÊs role in managing a

Copyright © Open University Malaysia (OUM)

Topic 9 explains the development and implementation activities. Applications are

Topic 10 revolves around activities involved in transitioning to a new system

TEXT ARRANGEMENT GUIDE

Self-Check: This component of the module is inserted at strategic locations

Copyright © Open University Malaysia (OUM)

References: The References section is where a list of relevant and useful

Copyright © Open University Malaysia (OUM)

TAN SRI DR ABDULLAH SANUSI (TSDAS) DIGITAL

Copyright © Open University Malaysia (OUM)

Copyright © Open University Malaysia (OUM)

However, off-the-shelf software may not fit the needs of a particular

Information system can be defined as a combination of information technology,

1.1 MODELLING THE BUSINESS PROCESS

This illustrates the impact of information technology on business operations

Information systems experts need to understand the business operation of a

A systems analyst applies a technique called business process modelling to

In your opinion, what is the impact of information technology on the