BBAS4203 Accounting Infomartion System II PDF

BBAS4203
ACCOUNTING
INFORMATION
SYSTEM II
Dr Lau Yeng Wai
Copyright Open University Malaysia (OUM)
Project Directors:
Prof Dato Dr Mansor Fadzil

Prof Dr Wardah Mohamad
Open University Malaysia
Module Writer:
Dr Lau Yeng Wai
Moderator:
Dr Jaspal Singh
Developed by:
Centre for Instructional Design and Technology

Open University Malaysia
Printed by:
Meteor Doc. Sdn. Bhd.

Lot 47-48, Jalan SR 1/9, Seksyen 9,
Jalan Serdang Raya, Taman Serdang Raya,
43300 Seri Kembangan, Selangor Darul Ehsan
First Printing, August 2014

Copyright Open University Malaysia (OUM), August 2014, BBAS4203
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
Topic 1
ixxiv
Introduction
1.1 Systems Development Life Cycle
1.1.1 Systems Strategy
1.1.2 Project Initiation
1.1.3 In-house Development
1.1.4 Commercial Packages
1.1.5 Maintenance and Support
1.2 Objectives of Systems Development
1.2.1 Accurate and Timely Information
1.2.2 Time Required for Systems Development
1.2.3 Satisfying Organisational Needs
1.2.4 Users Satisfaction with New Systems
1.3 An Overview of Systems Development Documentation
1.3.1 Systems Planning and Analysis
1.3.2 Systems Design
1.3.3 Systems Implementation, Evaluation and Control
1.3.4 Systems Maintenance and Review
1.4 Systems Development Technologies and Practices
1.4.1 Structured Programming
1.4.2 Computer-aided Software Engineering (CASE)
1.4.3 Prototyping
1.4.4 Object-oriented Technology
1.4.5 Business Process Reengineering
1.4.6 Programme Change Control
1.4.7 Database Administration
1.4.8 Internal Auditors Involvement
1.5 Planning and Organising a Systems Project
1.5.1 Project Selection
1.5.2 Project Team
1.5.3 Phases and Tasks
1.5.4 Time Estimates
1.5.5 Project Accounting
Summary
Key Terms
References
1
2
4
4
4
4
5
5
5
6
6
7
7
8
9
10
12
12
13
14
16
18
20
22
23
23
24
24
24
26
26
28
28
29
29
iv
TABLE OF CONTENTS
Topic 2
Systems Planning
2.1 Overview of Systems Planning
2.1.1 Steering Committee
2.1.2 Objectives and Systems Constraints
2.1.3 Systems Strategy
2.2 Assess Strategic Information Needs: Strategic Business Needs
2.2.1 Vision and Mission
2.2.2 Industry and Competitive Position
2.3 Assess Strategic Information Needs: Legacy Systems
2.3.1 Architecture Description
2.4 Assess Strategic Information Needs: User Feedback
2.4.1 Recognising a Problem
2.4.2 Defining the Problem
2.4.3 Specifying Systems Objectives
2.4.4 Determining Project Feasibility
2.4.5 Preparing a Formal Project Proposal
2.5 Develop a Strategic Systems Plan
2.5.1 Setting Priorities for Systems Projects
2.6 Create Action Plans
2.7 The Role of Accountants
Summary
Key Terms
References
30
32
32
33
33
35
35
35
36
36
37
37
38
39
39
42
43
44
45
47
48
49
49
Topic 3
Systems Analysis
3.1 Overview of Systems Analysis
3.1.1 Joint Application Development (JAD)
3.1.2 Rapid Application Development (RAD)
3.1.3 Agile Methods
3.2 Stages in Systems Analysis
3.2.1 Stage 1: Survey Current Systems
3.2.2 Stage 2: Identify Information Needs
3.2.3 Stage 3: Identify System Requirements
3.2.4 Stage 4: Prepare a Systems Analysis Report
3.3 Fact-gathering Techniques
3.3.1 Observation
3.3.2 Task Participation
3.3.3 Personal Interviews
3.3.4 Document Review
3.4 Techniques for Organising Facts
3.4.1 Work Measurement
3.4.2 Work Distribution
3.4.3 Flowcharts and Other Graphics
51
52
53
53
54
55
56
60
61
63
65
65
65
65
66
68
68
69
69
TABLE OF CONTENTS
Topic 4
Topic 5
3.4.4 Decision Analysis

3.4.5 Narratives
Summary
Key Terms
References
70
71
72
73
73
74
Systems Design Evaluations and Choices

4.1 Alternative Systems Designs
4.2 Evaluation and Selection
4.2.1 Step 1: Detailed Feasibility Study
4.2.2 Step 2: Cost-benefit Analysis
4.2.3 Step 3: Systems Selection Report
4.3 In-house Development
4.3.1 Reasons for In-house Development
4.3.2 End-user Computing (EUC)
4.3.3 End-user Development (EUD)
4.4 Customising Software Packages
4.5 Acquisition of Commercial Packages
4.5.1 Reasons for Acquiring Commercial Software
Packages
4.5.2 Step 1: Evaluate Requirements of Information
Systems
4.5.3 Step 2: Identify Potential Vendors or
Outsourcing Options
4.5.4 Step 3: Evaluate Alternatives
4.5.5 Step 4: Perform Cost-benefit Analysis
4.5.6 Step 5: Prepare a Recommendation
4.6 Outsourcing
4.6.1 Benefits of Outsourcing
4.6.2 Risks of Outsourcing
Summary
Key Terms
References
75
76
78
78
81
86
86
87
88
89
90
91
Systems Design
5.1 Conceptual Systems Design
5.1.1 Output
5.1.2 Data Storage
5.1.3 Input
5.1.4 Processing Procedures and Operations
5.1.5 Conceptual Systems Design Report
91
92
93
94
95
95
95
96
97
98
98
99
99
53
103
104
104
105
105
105
vi
Topic 6
TABLE OF CONTENTS
5.2
Physical Systems Design

5.2.1 Output Design
5.2.2 File and Database Design
5.2.3 Input Design
5.2.4 Programme and Procedure Design
5.2.5 Controls Design
5.2.6 Physical Systems Design Reports
Summary
Key Terms
References
107
109
111
114
118
120
121
123
123
124
124
Systems Change and Implementation

6.1 An Overview of Systems Implementation
6.2 Implementation Planning
6.3 Site Preparation, Installation of Hardware and Software
6.3.1 Completing Systems Designs
6.3.2 Acquiring Hardware and Software
6.3.3 Writing, Testing and Debugging Computer
Programmes
6.4 Personnel Selection and Training
6.5 Systems Testing
6.5.1 Types of Tests
6.6 Systems Documentation
6.6.1 Designer and Programmer Documentation
6.6.2 Operator Documentation
6.6.3 User Documentation
6.6.4 Accountant Documentation
6.7 Database Conversion
6.8 Systems Conversion
6.9 Operation and Maintenance
Summary
Key Terms
References
126
127
128
131
131
134
135
136
137
138
139
140
140
141
144
145
146
149
152
152
153
154
COURSE GUIDE
COURSE GUIDE
ix
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
BBAS4203 Accounting Information System II is one of the courses offered by the
OUM Business School at Open University Malaysia (OUM). This course is worth
3 credit hours and should be covered over 8 to 15 weeks.
COURSE AUDIENCE
This is a core course for all learners undertaking the Bachelor Degree in
Accountancy programme.
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 confirm the course material, the course requirements and 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.
COURSE GUIDE
Table 1: Estimation of Time Accumulation of Study Hours

Study Activities
Study
Hours
Briefly go through the course content and participate in initial discussions
Study the module
60
Attend 3 to 5 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.
Describe the Systems Development Life Cycle (SDLC) and its processes;
2.
Discuss the role of accountants in the Systems Development Life Cycle;
3.
Analyse various approaches to developing an accounting information

system;
4.
Apply various approaches to developing an accounting information

system; and
5.
Evaluate appropriate/relevant project management softwares.
COURSE SYNOPSIS
This course is divided into six topics. The synopsis for each topic can be listed as
follows:
Topic 1 discusses the entire systems development process and information
systems strategy. This will be followed by an explanation on the information
systems action committee in general and the systems project group. Learners
will also be exposed to all five steps of the Systems Development Life Cycle
(SDLC) and the implementation and commission of external consultants as well
as internal experts. This topic will also introduce other systems development
approaches such as Business Process Reengineering (BPR), Prototyping and also
CASE Technology. The advantages and disadvantages of these systems
development approaches will also be discussed.
COURSE GUIDE
xi
Topic 2 focuses on the planning of systems development. Planning is a part of

SDLC and learners will be exposed to problem identification and definitions of
existing and proposed systems. The proposed systems objective specification,
systems planning strategy and identification of project feasibility will be
deliberated on. The use of formal project proposals and the role of accountants in
systems planning will be identified, defined and elaborated as well.
Topic 3 begins with an analysis of systems development. Systems analysis is a
part of SDLC and learners will be exposed to the need for analysing the current
systems achievement and user needs. The techniques used to collect information
for decision-making will be discussed in detail and presented in a report of the
particular system and finally an accountants role in systems analysis will be
identified, defined and elaborated.
Topic 4 covers systems evaluation and choices. The focus of this topic will be to
analyse the feasibility test and also to learn about conducting the cost-benefits
analysis, by which systems evaluation and choices report will be generated. The
chosen analysis, which will be a decision to make or buy, either SDLC or a
commercial software or outsourcing, will be discussed. Finally, the role of
accountants in systems evaluation will be identified, defined and elaborated.
Topic 5 presents the design of systems development. Systems design is a part of
SDLC and learners will be exposed to the need for concept design of a system
with alternative design evaluation of a given system in this topic. The physical
design that covers elements of input, software, database, control and output will
be discussed. A systems design report will be prepared for decision-making
purposes and finally an accountants role in systems design will be identified,
defined and elaborated.
Topic 6 explores systems change and implementation. The focus of this topic will
be determining the preparation of the location for the installation of a computers
hardware and software. This topic will also discuss the testing of a new system
and the required training for staff members who will be the end-users of this new
system. The methods applied in administrating the changing of a system, which
includes new system documentation and evaluation of the new system after its
implementation will also be discussed. The role of accountants in being a part of
systems change and implementation will be identified, defined and elaborated.
xii
COURSE GUIDE
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 subsections. 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
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.
COURSE GUIDE
xiii
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
No prior knowledge required.
ASSESSMENT METHOD
Please refer to myVLE.
REFERENCES
Bodnar, G. H., & Hopwood, W. S. (2013). Accounting information systems
(11th ed.). Boston, MA: Prentice Hall.
Garton, C. (2005). Fundamentals of technology project management (2nd ed.).
Boston, MA: MC Press online.
Gelinas, Romney, M., & Steinbart, P. (2006). Accounting information systems
(10th ed.). Upper Saddle River, NJ: Prentice Hall.
Hall, J. A. (2013). Accounting information systems (8th ed.). Mason, OH: SouthWestern, Cengage Learning.
Maylor, H. (2010). Project management (4th ed.). London: Financial Times
Prentice Hall.
Romney, M., & Steinbart, P. (2012). Accounting information systems (12th ed.).
Upper Saddle River, NJ: Prentice Hall.
Romney, M., Steinhart, P., & Cushing, B. (2006). Accounting information systems
xiv
COURSE GUIDE
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, Books247, 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
LEARNING OUTCOMES
By the end of this topic, you should be able to:
1.
Explain the key stages of systems development;
2.
Discuss the objectives of systems development;
3.
Describe the documentation used and their purposes at different

stages of systems development;
4.
Identify common systems development technologies and practices;

and
5.
Apply the process of planning and organising a systems project.
INTRODUCTION
The saddest aspect of life right now is that science gathers knowledge faster
than society gathers wisdom.
Isaac Asimov
Well-designed information systems enable a business organisation to gather
wisdom. Equipped with wisdom, the organisation is in a better position to
manage various aspects of the business, ranging from reducing inventory and
eliminating non-value-added activities to improving customer service and
coordinating supply chain activities.
TOPIC 1
INTRODUCTION
This topic provides an overview of information systems development. First, we

will discuss the key stages in systems development. We will then examine the
objectives that systems development should strive to achieve in order for the
resultant systems developed to be useful. Next, this topic will examine the
relevant documentation that help to plan, manage and control the systems
development process. We will also look at some common systems development
technologies and practices. Finally, we will discuss how to gather and coordinate
with relevant experts in planning and managing a chosen systems development
project.
1.1
SYSTEMS DEVELOPMENT LIFE CYCLE
Large organisations with unique information needs tend to develop their own
information systems in-house. Smaller organisations with relatively standardised
information needs tend to acquire off-the-shelf software. Regardless of whether to
acquire or develop the information systems, there is a certain degree of risks
involved, such as cost overrun, failure to meet information needs and others.
Careful planning, execution, control and documentation of the entire systems
development life cycle (SDLC) help to minimise these risks.
Figure 1.1 illustrates the key stages of the SDLC. The remainder of this section
provides an overview of each stage. The details of each stage will be discussed in
the remaining topics in this module. In practice, systems development does not
necessarily follow each and every stage of the SDLC sequentially. Some stages
and/or specific tasks within stages may require repetition until a satisfactory result
is attained. Some stages and/or tasks within stages may be integrated with other
stages and/or tasks. The section on systems development technologies and
practices will further elaborate on such deviations from the SDLC.
TOPIC 1
INTRODUCTION
Figure 1.1: Systems Development Life Cycle (SDLC)

Source: Hall (2013)
1.1.1
TOPIC 1
INTRODUCTION
Systems Strategy
The first step in SDLC is to develop a systems strategy. Prior to developing a

systems strategy, you will need to identify and understand the strategic business
needs of your organisation. You can derive your organisations strategic business
needs from the organisations vision and mission statements, analyses of
competitive pressures on the organisation and current as well as anticipated
future market conditions. Strategic business needs reflect the organisations
future direction in attaining and maintaining strategic advantage. In addition,
you should consider the implications of the new information systems to existing
legacy systems as well as users concerns, based on their feedbacks. At the end of
this stage, you will need to produce a strategic plan for meeting the various
needs and a timetable for implementation of the selected systems.
1.1.2
Project Initiation
Project initiation involves assessing systems proposals for consistency with the
strategic plan. Systems proposals are evaluated in terms of their feasibility as
well as costs and benefits. Alternative conceptual designs are also considered.
The selected conceptual design will enter the contract phase of the SDLC.
Selected proposals will require in-house development, a commercial package or
both depending on the nature of the project and organisational needs.
1.1.3
In-house Development
In-house development activities include analysing users needs, designing

processes and databases, creating user views, programming applications and
testing and implementing entire systems.
1.1.4
Commercial Packages
Among the advantages of acquiring commercial packages over in-house

development are lower initial costs, shorter implementation times and better
controls. Furthermore, commercial packages have already been tested and
validated. Vendors also provide support services. However, organisations need
to ensure that commercial packages meet organisational information needs and
are compatible with existing systems.
TOPIC 1
1.1.5
INTRODUCTION
Maintenance and Support
Maintenance and support activities include acquiring and upgrading to the latest
versions of commercial packages and making in-house modifications to existing
systems in line with changes in users information needs. The extent of
maintenance ranges from minor modifications to an application to produce a
new report, to extensive programming of new functionalities into the systems.
The maintenance and support stage of the SDLC is also perceived as the
beginning of a new SDLC. Rapid development in technological innovations and
constant changes in information needs shorten the lifespan of information
systems. Information systems developed using an incremental approach rather
than in a single big-bang release are better able to accommodate for changing
information needs.
SELF-CHECK 1.1
1.
What are the key stages of the Systems Development Life Cycle
(SDLC)?
2.
Why would organisations develop their own information systems

in-house when commercial packages are readily available?
1.2
OBJECTIVES OF SYSTEMS DEVELOPMENT
This section discusses the general objectives of information systems development

(Boockholdt, 1999), to ensure that the information systems developed are aligned
with business needs.
1.2.1
Accurate and Timely Information
Lack of familiarity with newly developed information systems, regardless of

in-house development or acquisition of commercial packages, can give rise to
the possibility of previously unknown errors and even provide avenues for
malpractices. The appropriate internal controls are required to minimise errors
and avenues for malpractices. The participation of accountants and auditors
knowledgeable about internal controls in systems development is important.
TOPIC 1
INTRODUCTION
The information systems need to be aligned with the appropriate processing

modes to produce timely information. For instance, immediate processing mode
produces real-time information but not periodic processing mode.
1.2.2
Time Required for Systems Development
Systems development should be completed within a reasonable time period.

Excessive time for systems development gives rise to excessive costs, exceeding
the systems benefits. Among the measures to keep systems development within
a reasonable time period are as follows:
(a)
Limit the scope of the new system to a size that can be developed within a
reasonable time period. Having defined the boundaries of the new systems,
time and effort should be limited to the components within these boundaries.
Even though components outside the boundaries require changes, such
changes can be addressed at a later date. For instance, accountants should
identify the application systems within a transaction cycle that need to be
improved on rather than improving the entire transaction cycle. Once a new
version of the identified application systems is completed, only then should
the accountants proceed to other systems within the cycle; and
(b)
Use project management techniques like budgets, Gantt charts and PERT
diagrams. By using these techniques, all the relevant activities can be
identified, together with the estimated times and costs for each respective
activity. This way, elapsed time and costs for each activity can be
monitored. In response, the scope of the new systems and resources
assigned can be adjusted.
1.2.3
Satisfying Organisational Needs
Systems development is expensive and time-consuming and it is important to

ensure that the new systems meet information needs for many years. Adequate
systems planning is required to identify and anticipate current as well as future
needs.
Setting up the information systems steering committee to consider and approve
new systems ensures that current information needs will be met. Long-range
systems planning is also required to identify the requirements of long-term
information resources and develop a master plan for new information systems.
An understanding of overall organisational goals, proposed new products
and/or services, new markets and future critical business operations is required
to ensure new information systems are able to accommodate a wide range of
business needs, from transaction processing to strategic decision-making.
TOPIC 1
1.2.4
INTRODUCTION
Users Satisfaction with New Systems
Users satisfaction indicates that the new information systems are providing
information in line with business needs. Pre- and post-implementation reviews to
ascertain whether intended users count on the new information systems and are
satisfied with the systems operations and outputs are important.
1.3
AN OVERVIEW OF SYSTEMS
DEVELOPMENT DOCUMENTATION
Systems development documentation provide a plan for organising information

of the systems. These documentation help to ensure that the required resources,
methods, measures and records are in place at every stage of systems
development. It is important to have back-up copies of all documentation for
recovery purposes in the event original copies are destroyed, sabotaged, etc.
Complete, current and sufficient systems documentation need to be periodically
verified. Among the benefits of keeping systems documentation current and
complete are as follows (Bodnar and Hopwood, 2001):
(a)
Ensures that all relevant considerations and actions are undertaken at each
phase of systems development;
(b)
Ensures effective review of the proposed system by the management and

other relevant parties;
(c)
Provides a guide for operating and maintaining the proposed system; and
(d)
Specifies the deliverables of the proposed system.
Documentation can be developed in-house and/or in consultation with

accounting or management consulting firms. Major computer vendors and
government agencies provide systems documentation standards. An overview of
the documentation relevant for each systems development phase is discussed in
the remainder of this section. The documentation will be further discussed in
detail in subsequent topics.
1.3.1
TOPIC 1
INTRODUCTION
Systems Planning and Analysis
The documentations relevant for systems planning and analysis are as follows:
(a)
Feasibility Study
A feasibility study is undertaken to ascertain whether a proposed system
can be implemented later on. The proposed system is assessed from
various perspectives, for instance, available technology and infrastructure,
whether the systems benefits exceed costs and whether the system works,
i.e., the system will be accepted and used.
There are no hard-and-fast rules in conducting a feasibility study. The
complexity and duration of the study depends on the size of the system
and number of alternatives available. Feasibility studies can be conducted
in-house and/or with the assistance of external consultants.
(b)
Logical Flow Diagrams

Diagrams such as system flowcharts and data flow diagrams provide a
statement of the operational characteristics of a proposed system.
(c)
Data Dictionary
Data dictionary documents specific contents of a database and lists and
describes each field.
(d)
User Specifications
User specifications provide a description of a proposed systems
operational characteristics based on interviews with users. The description
is non-technical. Users can review and approve the description.
(e)
Conceptual design
The conceptual design report serves as the basis for systems design. The
report consists of logical diagrams and user specifications. The report
should contain:
(i)
Narrative description in non-technical terms;
(ii)
Specifications of output requirements (format, content, timing and

distribution);
(iii)
Specifications of input requirements (the necessary forms to capture

data);
(iv)
Hardware and software requirements; and
(v)
Costs, development plans and budget information.

TOPIC 1
1.3.2
INTRODUCTION
Systems Design
The documentation relevant for systems design is as follows:

(a)
Systems Design Report

The conceptual design report is translated into a systems design report.
The systems design report details system performance and functional
specifications. The report should contain:
(i)
Input requirements: The source documents how documents are

prepared and transmitted, frequency of preparation and volume of
transactions expected;
(ii)
Processing specifications: The procedures of how inputs are used to

prepare the desired outputs the required files, records, frequency of
files used and current and expected processing volumes associated
with each file;
(iii)
Output requirements: Output specifications form, contents and

frequency of each report;
(iv)
Control provisions: Control measures steps taken to provide the

necessary internal control; and
(v)
Cost estimates: Estimates of conversion costs and operating costs of

the proposed system.
(b)
Flowcharts
Flowcharts illustrate the detailed design of the proposed system.
(c)
Programme Description
Programme description includes:
(i)
Narrative description of the programme;
(ii)
Programme flowchart;
(iii)
Programme source listing;
(iv)
Description of the data formats used in the programme; and
(v)
The output the programme generates.
10
(d)
TOPIC 1
INTRODUCTION
Run Manual
Run manual is a collection of operating procedures for a particular
application. The run manual contains:
(i)
Description of the application system;
(ii)
Description of the programme; and
(iii)
Operating instructions.
Operating instructions in the run manual guide includes actual running of

the programme and definitions of the operators duties in starting, running
and terminating the programme.
(e)
File Descriptions and Data Entry Procedures

File descriptions and data entry procedures contain instructions for users
involved with the operation of the proposed system, including data entry
clerks and computer operating personnel.
1.3.3
Systems Implementation, Evaluation and

Control
Implementation of the proposed system requires a coordination of activities.

Among the implementation activities that are often used are the re-training of
operating personnel, site preparation and file conversion. Formal documentation
techniques such as Gantt charts and PERT diagrams can be used to document
this stage.
The documentation relevant for systems implementation, evaluation and control
is as follows:
(a)
Conversion Plan
There are three possible conversion strategies.
(i)
Immediate cutover is suitable for incompatible or minor changes, but

is risky;
(ii)
Parallel operation allows a period for both the old and new
systems to operate simultaneously. Parallel operation allows a phase
for testing and debugging any deficiencies associated with the
performance and capability of the proposed system; and
TOPIC 1
(iii)
INTRODUCTION
11
Phase conversion lowers risks and enables successive refinements to

the proposed system. Phasing can be by system modules (data entry
or file conversion), organisational units or applications (payroll first,
then accounts receivables, etc.).
Figure 1.2 illustrates the differences between the three conversion

strategies.
Figure 1.2: Conversion strategies

Source: Bodnar and Hopwood (2001)
(b)
Testing Plan
The testing plan documents the activities undertaken to evaluate the
proposed system including the nature of the data tested and a summary of
test results.
(c)
Operating and Maintenance Schedules

The operating and maintenance schedules document the allocation of
resources of the proposed system for operations and maintenance.
12
1.3.4
TOPIC 1
INTRODUCTION
Systems Maintenance and Review
The documentations relevant for systems maintenance and review are as follows:
(a)
Audit Plan
The audit plan specifies the activities undertaken to evaluate the
performance of the proposed system; and
(b)
User Comments
This document specifies the plan to solicit and review user comments once
the proposed system becomes operational and to share the findings.
SELF-CHECK 1.2
1.
What are the objectives that systems development should strive to

achieve for the information systems developed to be useful?
2.
What do you think can happen when systems development is not

properly documented?
1.4
SYSTEMS DEVELOPMENT TECHNOLOGIES

AND PRACTICES
Systems analysts and programmers are the key people involved in systems
development. Analysts communicate with end-users via natural language, for
example using English or Malay. They document the interfaces with users, which
is then reviewed and approved by the users. Use of structured analysis, design
and graphic techniques improve analyst-user interface. As for programming, the
main concerns are maintainability of the resultant programmes and productivity
during programme development. Increasing maintainability of programmes at
the development phase saves time and costs required to maintain the
programmes. Systems development technologies and practices that serve to
assist analysts and programmers are discussed in the remainder of this section
(see Bodnar and Hopwood, 2001, for more information on the technologies and
practices).
TOPIC 1
1.4.1
INTRODUCTION
13
Structured Programming
Structured programming (SP) aims at improving programme clarity and

maintainability through a set of guidelines or standards for programme design.
The set of guidelines or standards specify how programmers should use a
programming language, stylistic guidelines and how programmes are to be
designed to fit together. The standardisation that SP provides makes
programming:
(a)
Systematic, via a series of prescribed techniques and guidelines; and
(b)
Inexpensive to write, test and maintain.
The standardisation that SP provides suits the team approach in systems design.
A major control feature that SP enables is formal reviews or walk-throughs of
programme codes by independent parties, such as team or project leaders. As SP
aims to promote programme clarity and maintainability through standardisation,
tricky and complex codes, which individual programmers take pride in
developing are eliminated in a highly structured programming approach that
involves organisation of teams consisting of chief programmers.
(a)
Teams
A team consists of a lead or chief programmer, assistant programmers and
a programming secretary, if required. Lead and assistant programmers
work together. All programme codes are developed together rather than
individually. The programming secretary performs clerical functions and
prepares programme documentation. Reviews or walk-throughs can be
incorporated into the development process rather than left till the end of
the process.
(b)
Technical Aids
Technical aids like pre-processors and automated documentation systems
enhance programmers productivity. Pre-processors reduce clerical errors
by expanding abbreviations into full syntax, checking for syntax errors and
reformatting programme code into a structured format prior to submitting
the code for processing to the source statement compiler. Pre-processors
can be used on a batch basis or online processing basis. Automated
documentation is post-processing and relieves programmers of clerical
work in terms of documentation.
14
1.4.2
TOPIC 1
INTRODUCTION
Computer-aided Software Engineering (CASE)
Computer-aided software engineering (CASE) is automated engineering for

software development and maintenance, with the support of computer software
technology. CASE aims to:
(a)
Increase productivity and software quality through stringent standards and

analysis; and
(b)
Decrease costs of software development, documentation and maintenance.
CASE involves a highly structured approach to software analysis, design, coding,

testing and maintenance. There are various CASE tools categorised in a variety of
ways. Examples of CASE tools are as follows:
(a)
Upper CASE and Front-End CASE are tools for the analysis and design
phase;
(b)
Lower CASE and Back-End CASE are tools for the implementation phase;
(c)
Data-oriented CASE tools are for database design;
(d)
Process-oriented CASE tools are for business function definition, data flow
diagrams, programme design and programme code;
(e)
Integrated CASE combines data, process, upper and lower CASE and
management support;
(f)
Real-Time CASE is an integrated CASE with timing and interrupted

messages added to the code; and
(g)
Embedded CASE is Real-Time CASE with hardware simulation added to it.
For a truly integrated CASE, interfaces between various CASE tools should be
seamless regardless of the diverse vendors used. Industrywide standards
facilitate the seamless flow and integration of various CASE tools. Figure 1.3
illustrates the various CASE tools, which are then further discussed in detail.
TOPIC 1
INTRODUCTION
15
Figure 1.3: CASE tools

(a)
Repository
Repository is central to CASE. Repository includes:
(i)
Data dictionary, which contains information about data flow, report

design and specifications;
(ii)
User interface; and
(iii)
Central directory, which consists of code generation and reports.
Repository may also contain planning information, such as application

design, documentation and project management information.
(b)
Diagramming Tools
Diagramming tools provide automated support for drawing data flow
diagrams, flowcharts and other graphics often used as a medium of
communication for most structured systems. Diagramming tools improve
clarity, facilitate revisions and minimise errors.
(c)
Syntax Verifiers
Most CASE products are capable of performing consistency checks and
other error-checking procedures, which is particularly important in
structured systems analysis where compliance with specific rules is
required. For instance, verification and correction of data flow diagrams as
per proper use of diagramming techniques.
16
TOPIC 1
INTRODUCTION
(d)
Prototyping
Prototyping tools develop system interfaces, such as screen displays and
report formats, with users even before the development of the proposed
systems. Data definitions stored in the repository are used to specify the
input/output fields in a screen and/or report.
(e)
Code Generation
Code generation tools automatically develop programme code based on
systems analysts input specifications, often in a high-level language.
Programme code produced is in a highly structured format. Code
generation tools minimise the distinction between programme analysis and
design when integrated with other CASE tools. Such tools enable systems
development to deviate from the traditional SDLC where software analysis,
design and coding can be integrated.
(f)
Project Management
Project management tools track the progress and manage resources for a
project, based on standards established for the various tasks of the project.
1.4.3
Prototyping
There are circumstances when strict application of structured development tools

in accordance with the steps in the SDLC are not possible, for instance in the
development of decision support systems and expert systems. Structured
development tools require that users know in advance what they need and
specify their needs before the system is developed.
In circumstances where users cannot specify their needs in advance, prototyping
is used. Prototyping deviates from the SDLC discussed at the beginning of this
topic. Systems development tasks are executed iteratively, for example analysing,
designing, reanalysing, redesigning, etc. Prototyping aims at resolving problems
associated with incomplete and inaccurate system specifications. Incomplete and
inaccurate system specifications are often attributable to the following reasons
(Gelinas et al., 1999):
(a)
Users and the systems development team cannot or do not communicate

adequately;
(b)
Users do not have a clear understanding of what they want the information
systems to do or how they want the systems to operate; and
(c)
The systems development team fail to spend adequate time determining

user requirements and specifying the systems.
TOPIC 1
INTRODUCTION
17
Prototyping also aims at producing system specifications that are highly likely to
be accepted by users and less likely to require major modifications once the
information systems are implemented. However, complete documentation can be
a challenge in light of the iterative nature of the prototyping process, which
makes prototyping less useful in developing large, complex information systems
where complete documentation is pertinent to system operation and maintenance.
Prototyping assists users to express their opinions on their needs by providing a
prototype of an actual system. Users are able have a feel of the prototype
systems, which can be nothing more than computer screens, data entry screens or
output report screens. Initial users requirements are estimated and implemented
in a prototype system. Based on users experience with the prototype system,
users modify their requirements. The prototype is revised based on new
requirements and re-implemented. The interaction continues until users are
satisfied. Figure 1.4 summarises the interactive process.
Figure 1.4: Interactive process of the prototyping approach

18
TOPIC 1
INTRODUCTION
Among the potential problems associated with prototyping are:

(a)
When users are satisfied with an unfinished system, the system is accepted
as final. Missing controls are not uncommon to speed up development of
prototype systems; and
(b)
The iteration process is difficult to manage and control. Requests for minor
changes that have no real impact on the use of the systems might continue
indefinitely.
Prototyping is often incorporated in team-based systems development

approaches such as rapid application development (RAD), where users become
members of the systems development team.
1.4.4
Object-oriented Technology
Based on conventional understanding of data processing, programmes process

data. Objects are intelligent data. Objects contain data and programme, i.e., the
rules and procedures that dictate how objects relate to other objects. An object
can be an invoice, purchase order, a product or an employee.
(a)
Object-oriented Programming
Object-oriented programming (OOP) makes software easier to develop,
simpler to use and more reliable through reusability. Objects are reusable.
Programmes are not built from scratch and can be upgraded by adding
new objects to it. Reusability is possible via encapsulation, inheritance, and
the use of messages, which is detailed as follows:
(i)
Encapsulation Encapsulation involves information hiding. The

interface to the programme hides information about its inner
workings, separating the user of an object from the author of the
object. Objects contain their own data and procedures but not the
data and procedures of other objects. An object knows the messages it
can process, reject and pass on to other objects. Each object does not
know the capabilities and inner workings of other objects. An object
can be modified without affecting other objects.
(ii)
Inheritance Objects are categorised into classes. Each class consists

of methods and data that summarise common characteristics of a set
of objects. For instance, an accounts receivable system is a class and a
specific customers account is an object. Classes can have sub-classes
and objects can have sub-objects. The common methods and data
from a set of objects is a reusable code that is stored in a repository.
TOPIC 1
INTRODUCTION
19
Common attributes of a class can be extended, or inherited by objects

within the class. Changing the parent objects methods creates subobjects (sub-classes). The original code remains with the parent.
Messages that sub-objects modified methods cannot handle are
automatically routed to the parents.
(iii)
(b)
Messages Messages connect objects to their environment and

invoke the procedures contained in objects as objects respond to
messages. Objects from different classes respond to common
messages with their own procedures, which is called polymorphism.
Object-oriented Databases
Data and the procedures that operate on the data are stored as an object.
An object can be data, document, image of texts, video or voice data.
Objects in a database interact by exchanging messages and operations are
performed by sending messages.
Object-oriented technology accommodates for contemporary organisational

needs where users need to consistently interact with computer systems to enter
large amount of data and directly observe output on video displays. The amount
of software to support direct user interface alone pull-down menus, graphic
displays, icons and mouse movements is enormous. Furthermore, data comes
in great variety, from traditional transactional data, to digitised voice, text and
image data.
Object-oriented technology ensures that common functions are defined as objects
and are stored in a repository, which minimises systems development work. Subobjects need not develop their own code from scratch. When new (children)
objects need to be developed, new objects can inherit, i.e., reuse, the code stored
in their parent objects.
Reusability of existing software is a major concern. Reengineering extracts code
segments from existing software and restructures the code to enhance efficiency
and reusability. With reengineered codes stored in a repository, new programmes
can reuse these reengineered codes rather than develop their own code from
scratch to perform the same tasks.
Reengineering makes software easier to create, simpler to use and more reliable
through reusability. It applies any programming system, such as object-oriented
technology, where objects are reusable.
20
1.4.5
TOPIC 1
INTRODUCTION
Business Process Reengineering
Business process reengineering encompasses more than systems development;

it addresses all business processes in the organisation. It focuses on four key
components, as follows (Gelinas et al., 1999):
(a)
(b)
Fundamental Rethinking of Business Processes

Business process reengineering requires organisations to ask fundamental
questions such as:
(i)
Why do we do what we do?; and
(ii)
Why do we do it the way we do?
Radical Redesign of Business Processes

Business process reengineering requires adopting a fresh-start, clean-slate
approach in examining the organisations business processes. This approach
focuses on reinventing what is done and how it is done rather than making
marginal, incremental, superficial improvements to what is already being
done. It requires asking the following question:
If we were a brand-new business, how would we operate our company?
(c)
Dramatic Improvements in Performance Measurements

Both fundamental rethinking and radical redesigning of business processes
aim at making quantum leaps in performance, for example, employee
reduction by 75% at Ford Motor Company.
(d)
Focus on End-to-end Business Processes

Business process reengineering adopts a holistic view of business
processes. Business processes constitute a string of activities that cut
across departments and functional lines. The focus of business process
reengineering is on the results of the process, i.e., activities that add value
to the process. For instance, instead of order taking and picking and
shipping goods, business process reengineering examines the entire
process of order fulfilment and focuses on select activities that add value
for the customers.
TOPIC 1
INTRODUCTION
21
The principles of business process reengineering are (Gelinas et al., 1999):

(a)
Organise around outcomes, not tasks

This principle can be attained via the following means:
(i)
Identify what activities or tasks are required to achieve the outcome.

Eliminate non-value-added activities; and
(ii)
Create parallel activities so that many activities can be accomplished

simultaneously, which improves output timeliness.
(b)
Have those who need the results of a process perform the process
For instance, an electronic equipment manufacturer requires its customers
to perform some of their own routine repairs and carry the spare parts
inventory required for their own machines. Field service representatives of
the electronics manufacturer primarily answer customer calls and guide
customers through the repair process based on a diagnosis support system,
which is an expert system. The electronics manufacturer achieves better
customer service and lower inventory carrying costs with this method.
(c)
Integrate the processing of information into the work process that produces
the information
For instance, the receiving department produces and processes information
about goods received. The receiving department then compares the goods
received with the order and either sends the goods back or creates a
payable. Segregation of duties is relaxed. Compensating controls must be in
place and risks of increased opportunity of unauthorised and/or inaccurate
transactions must be evaluated.
(d)
Treat geographically dispersed resources as though they are centralised

For instance, centralising the purchasing function enabled Hewlett-Packard
to benefit from quantity discounts. Hewlett-Packard created a centralised
database of vendors with whom they have negotiated contracts.
Decentralised units can access the database to execute purchase orders.
(e)
Link parallel activities instead of integrating their results

For instance, in a loan application process, decisions of one function that
will affect the ultimate loan decision must be communicated immediately to
other functions.
22
TOPIC 1
INTRODUCTION
(f)
Put the decision point where the work is performed and build controls into
the process
We can flatten the organisational structure and eliminate the need for a role
to monitor, control and make decisions. Information technology is able to
capture and store data, as well as supply information to empower decisionmaking and thus change the role of manager from controller to supporter
and facilitator.
(g)
Capture information once and at the source

Information technology communication networks, electronic data
interchange (EDI) and relational database systems is able to facilitate the
collecting and storing of data in online databases for all who need them.
While drastic changes in business processes often bring quantum-leap

improvements, not every business process reengineering endeavour leads to a
positive outcome. Among the barriers to successful business process
reengineering is inertia or resistance to change, inadequate top management
support and involvement and lack of effective change management plans.
1.4.6
Programme Change Control
Programme change controls prevent unauthorised and fraudulent changes to

computer programmes as part of programme maintenance. Maintenance
requests are often of emergency or crisis in nature. For instance, errors are
discovered or changes are mandated by external regulatory requirements.
During an emergency or crisis, it is not uncommon to overlook proper testing
and verification of changes. Among the practices and procedures that prevent
unauthorised and fraudulent changes to computer programmes are as follows:
(a)
Segregation of Duties
Changes should not be made directly to programmes. Custody of
programmes should be segregated from programmers.
(i)
Change requests should be written, reviewed, sequentially numbered

and entered into the programme change register;
(ii)
The person responsible for the programme change register notifies

programmers and thus authorises change requests. Programmers
then obtain the programme and the related documentation; and
TOPIC 1
(iii)
INTRODUCTION
23
When a change has been programmed, tested and programme

documentation has been revised, the person administering the
programme change register should review and approve the change
based on the change authorisation form.
(b)
Control of Documentation
A programme change file accumulates programme change documentation
for each application programme. Processing programme change on a batch
basis minimises costs and improves control, as changes to programmes can
only occur at specific, pre-authorised times. Review of operating system
statistics provides control over unauthorised changes made outside preauthorised times.
(c)
Management Considerations
Maintenance is considered as small-scale systems development and should
be subject to controls. Structured programming techniques, adequate
programme documentation and the use of object-oriented technology serve
to enhance the maintainability of programmes. Emergency or crisis
exceptions should be carefully reviewed and documented, especially when
deviations from documented procedures are avoidable.
1.4.7
Database Administration
As part of systems development, database administration deals with data issues

such as security, integrity, sharing, backup, recovery and audit trail. One of the
major control activities of database administration is to establish standards and
documentation for data elements in the database, primarily via the data
dictionary. Database administration functions should not include operations of
the computer systems, initiation of transactions into the database, documentation
of system changes and custody of operational files and programmes.
1.4.8
Internal Auditors Involvement
The role of internal auditors in systems development includes ensuring that the
necessary audit and control features are built into the computer systems. The
auditability of computer systems depend on the underlying system of controls
built into the system during its development stage.
24
TOPIC 1
INTRODUCTION
SELF-CHECK 1.3
1.
What are the benefits of a structured approach in systems

development, as in CASE?
2.
What can systems designers do in circumstances where users

cannot specify their own information needs?
3.
What are the purposes of ensuring reusability, e.g., reusable

software and programme codes?
4.
What do you understand by business process reengineering?
1.5
PLANNING AND ORGANISING A SYSTEMS

PROJECT
A project is a specific application approved for development. Project management

includes analysing, designing, programming, testing, implementing, operating and
maintaining the project.
1.5.1
Project Selection
The steering committee (or another organisational unit) is responsible for

ensuring active user participation in project selection. The steering committee
considers the project proposals submitted. A proposal should contain estimates
of costs and benefits. Expected return on investment (ROI) is an important
selection criterion especially when limited organisational resources should be
allocated to projects that yield the most benefits. Once a project is selected and
approved for development, a project team is formed.
1.5.2
Project Team
Typical members of an information systems project team are systems analysts,

programmers, other technicians and representatives from the user departments.
A member must be selected to be the project team leader to lead and control
responsibilities for the project. Selecting a user representative as a leader will
ensure commitment to meeting various information needs. Selecting an analyst
or programmer as a leader will ensure quality of technical leadership for the
project team.
TOPIC 1
(a)
INTRODUCTION
25
Project Leaders Responsibilities

The project leader is directly responsible to the steering committee for
progress and completion of the project. The steering committee needs to
assure a high level of user involvement in the work of the project team. The
project team consists of a project leader, analysts, programmers and user(s)
from the organisational department for which the project is undertaken.
While each member is responsible to his/her own manager/supervisor at
his/her own department, each member also reports to the project leader.
The project leader must liaise with the manager/supervisor of the principal
user department that the project is primarily developed for. The user
manager/supervisor is typically the person who approves the project upon
completion. The project leader must also liaise with technical specialists,
such as database administrators and internal auditors while completing the
project. He/She is also responsible for planning, scheduling and controlling
the project.
(b)
(i)
Planning includes dividing the project into phases and tasks and
allocating resources for each phase and task;
(ii)
Scheduling includes organising phases and tasks into activities in

chronology and assigning responsibilities to project team members.
Use of Gantt charts and PERT diagrams facilitate scheduling; and
(iii)
Controlling includes periodic progress and project status reporting to

upper management. Project accounting systems facilitate controlling.
Project Uncertainty
The project team is confronted with uncertainties including:
(i)
The user-designer interface is highly uncertain. Users are frequently

unaware of the real problems that create the need for the new project
and/or users are often not sure of the specific information they need;
and
(ii)
Software development is also highly uncertain. Time required is

uncertain. Whether the software developed is reliable and conforms
to system specifications is also uncertain.
The project team needs to reduce all sources of uncertainties and

coordinate activities of the various parties working on the project to
complete the project within a reasonable time and cost.
26
1.5.3
TOPIC 1
INTRODUCTION
Phases and Tasks
Breaking down a project into phases or tasks reduces uncertainties. The project
becomes easier to control and understand. Each task or phases requirements can
be predicted and specified. There is no hard-and-fast rule in breaking down a
project. A variety of factors affect how a project should be broken down, for
example determining the requirements of the project and the commercial project
management packages used. The basic principle is that each phase or task should
have deliverables upon completion.
Having a project broken down into phases or tasks facilitates assignment and
control of labour and other resources. Tasks should be broken down to a level
where task requirements are clear enough to enable individuals to be assigned to
the tasks, based on the individuals expertise. Time required for each task can
also be estimated and specified.
1.5.4
Time Estimates
There are no pre-set and pre-determined time estimations for each phase or task
of a project. Experience with project management increases time estimation skills.
Nevertheless, the basic steps in time estimation are as follows:
(a)
Understand the nature of the tasks to be estimated;
(b)
For each task, estimate the amount of work required;
(c)
Convert the amount of work into time estimates by multiplying the amount
by a standard or estimated processing rate; and
(d)
The estimated processing rate includes circumstantial considerations such

as idle time and task complexity, newness or familiarity.
TOPIC 1
INTRODUCTION
27
Figure 1.5 provides an example of time estimation for the task of interviewing
four categories of employees.
Standard Man-Days for Interviews
People to Be
Interviewed
Number to Be
Interviewed
Managers
Standard Man-Day
Allowance
Total
Man-Days
0.5
Supervisors
17
1.0
17
Technical Staff
18
1.5
27
0.5
47
50
Clerical Staff
Total
Complexity Factors
Simple
0.500.75
Average
1.001.50
Complex
2.002.50
Complexity judgment for the case in point is somewhat above

average
Assign a factor of 1.30
Adjusted man-days = standard man-days times complexity factor
= 50 1.30
= 65 adjusted man-days
Figure 1.5: An example of time estimation for the task of interviewing

Among the common practices of time estimation are as follows.

(a)
Guesstimates are frequently used in early phases of a project rather than

detailed, systematic calculations;
(b)
It is common to revise time estimates as the project progresses. Accuracy of

time estimation improves in latter phases of the project; and
(c)
Initial time estimates are frequently low, known as low-balling. Submitting

a proposal with low time and cost estimates makes the proposal more
appealing due to the desire for efficiency. Once the proposal is selected and
accepted, the project is likely to be completed regardless of actual time and
costs required.
28
1.5.5
TOPIC 1
INTRODUCTION
Project Accounting
Project accounting includes setting measurable milestones for each phase or task,
reporting actual performance levels and evaluating deviations from project
plans. Effective project control requires keeping track of costs incurred at each
phase of the project. Costs to date as the project progresses materials, labour
and overhead costs need to be evaluated against budgeted costs. Among the
common reasons that contribute towards cost-overrun are scope creep (where the
project grows larger in scope than initially anticipated), lack of user consensus,
inaccurate project plans, lack of user involvement, inaccurate cost projections and
lack of qualified personnel.
SELF-CHECK 1.4
1.
Who are the typical members of a project team?
2.
What are the

completion?
3.
What are the steps that a project team can take to minimise
uncertainties pertaining to project completion?
typical
uncertainties
pertaining
to
project
Systems development life cycle (SDLC) includes deriving current and future
information needs, assessing systems proposals to ensure consistency with
information needs and feasibility, selecting and implementing a systems
proposal via in-house development and/or acquisition of commercial
packages and maintaining the new systems.
Systems developed should provide accurate and timely information, be

completed within a reasonable time, be consistent with organisational needs
and satisfy users.
Documentation facilitate systems development in planning, analysing,

designing, implementing, evaluating, controlling and in maintenance and
review.
TOPIC 1
INTRODUCTION
29
Various technologies and practices, each with its respective benefits and
functionalities, facilitate systems development.
A project team responsible for a systems project needs to plan and organise
the project in a manner that minimises uncertainties pertaining to project
completion.
Business process reengineering
Project leader
Commercial packages
Project team
Computer-aided software engineering Prototyping

(CASE)
Reengineering
Information needs
Structured programming
In-house development
Systems development life cycle (SDLC)
Object-oriented technology
Bodnar, G. H., & Hopwood, W. S. (2001). Accounting information systems (8th

ed.). Boston, MA: Prentice Hall.
Boockholdt, J. L. (1999). Accounting information systems (4th ed.). Irwin: Times
Mirror Books.
Boston, MA: MC Press.
Gelinas, Jr., U. J., Sutton, S. G., & Oram, A. E. (1999). Accounting information
systems (4th ed.). Mason, OH: South-Western, Thomson Corporation.
30
TOPIC 1
INTRODUCTION

Prentice Hall.
Topic Systems
Planning
LEARNING OUTCOMES
1.
Explain the importance of systems development planning;
2.
Describe the role of the steering committee;
3.
Discuss the major tasks in systems strategy development;
4.
Identify the major sources of information that contribute towards

systems strategy development; and
5.
Examine the role of accountants in systems development.
INTRODUCTION
If you were to build your own family house without proper planning, you might
find that your garage space is not enough for your cars, or you need to add
another bedroom or bathroom later on. The same goes to systems development.
Without proper planning, it will not be surprising to find that the information
systems are not providing you with the right kind of information at the right
time to support business operations and attainment of organisational goals.
This topic covers systems development planning. First, we will discuss why
systems development planning is important and identify the main issues in
planning, especially in aligning systems development with the organisations
most important goals, i.e., strategic goals. Next, we will discuss the major tasks in
planning and the relevant information to consider in ensuring alignment with the
organisations strategic direction. Finally, we will discuss how accountants can
assist in systems development.
32
2.1
TOPIC 2
SYSTEMS PLANNING
OVERVIEW OF SYSTEMS PLANNING

ACTIVITY 2.1
Imagine you have a budget of RM1,000 for a new mobile phone. You
want your new mobile phone to meet as much of your personal
information needs as possible, such as emailing, Internet surfing, social
networking, online shopping and GPS navigation while driving. Will
you simply purchase any mobile phone you come across? Will you at
least have in mind the basic functionalities that your new mobile phone
should have?
Write down the steps that you will take to make sure your RM1,000 is
spent on a mobile phone that meets as much of your information needs
as possible.
Systems planning includes identifying which aspects of an information system

are problem areas that require special attention, either immediate attention or
sometime in the future, in order to develop an overall systems plan. The overall
systems plan guides systems development and should strive to achieve the
following objectives (Bodnar & Hopwood, 2001):
(a)
Target resources on specific aspects of the information system that requires

most attention;
(b)
Minimise duplication and waste of time, effort and other resources; and
(c)
Align systems development to the organisations strategic objectives.
As top management determine the overall orientation and major decisions of the
organisation, their support and approval of the systems plan and strategy is
crucial. It is important to communicate with the top management to get a better
understanding of the organisations strategic plans, critical success factors and
overall objectives.
2.1.1
Steering Committee
The organisations steering committee provides guidance and oversight for overall
systems development. The steering committee represents top management and
key functional areas in the organisation. Typical members of the steering
committee include the chief executive officer (CEO), chief financial officer (CFO),
chief information officer (CIO), senior management from user departments,
TOPIC 2
SYSTEMS PLANNING
33
internal auditor and senior management from the computer services department.
The committee can also include external experts such as management consultants
and external auditors.
The primary responsibility of the steering committee is to direct focus to the
overall current and future information needs of the organisation and ensure that
the information systems are aligned with the overall organisational strategic plan.
While the steering committee is responsible for overall planning and controls of
systems development efforts in the organisation, the committee is not involved in
the details of specific development projects. Individuals who supervise and
manage development projects report periodically to the steering committee.
2.1.2
Objectives and Systems Constraints
Setting of general objectives for the organisation and specific objectives for
individual subsystems make systems development planning more effective.
General objectives include strategic objectives related to the long-term direction of
the organisation. Setting tactical objectives facilitate the achievement of strategic
objectives. Tactical objectives have a shorter time horizon, for example from one to
three years.
In addition to organisational objectives, the organisations critical success factors
must also be incorporated into objectives for systems development. Critical
success factors distinguish an organisation from its competitors. For instance,
some organisations are well known for low product price, high product quality,
or speed of product delivery. For example: if speed of product delivery is a
critical success factor, information related to late deliveries is important for the
shipping or delivery system.
2.1.3
Systems Strategy
Systems strategy aims to connect individual system projects to the organisations

strategic objectives. Recall that developing a systems strategy is the first step in the
Systems Development Life Cycle (SDLC), which was briefly discussed in the first
topic.
Systems strategy development involves three major tasks (Hall, 2013):
(a)
Determining the organisations strategic information needs;
(b)
Developing a strategic systems plan; and
(c)
Creating action plans.

34
TOPIC 2
SYSTEMS PLANNING
Systems strategy development is primarily based on three sources of information

(Hall, 2013):
(a)
Strategic business needs;
(b)
The legacy systems situation; and
(c)
Feedback from the user department.
Figure 2.1 summarises the major tasks in systems strategy development. Based on
an understanding of the organisations strategic business needs, situation of the
legacy system and feedback from the user department, the organisations strategic
information needs are first assessed. Next, a strategic systems plan is developed,
followed by an action plan. How the three major systems strategy development
tasks are performed is further discussed in the remainder of this topic.
Figure 2.1: Major tasks in systems strategy development
TOPIC 2
SYSTEMS PLANNING
35
SELF-CHECK 2.1
1.
Is systems development planning important? Why do organisations

plan for systems development?
2.
What is the role of the steering committee in systems development?
2.2
ASSESS STRATEGIC INFORMATION NEEDS:

STRATEGIC BUSINESS NEEDS
Strategic business activities include allocation of resources at a macro level for

objectives to be achieved in the long-run, e.g., spanning five years, such as product
development, market research and business expansion. All business operations
and functions should support business strategy. In a similar manner, the
information systems should support business strategy as well. Systems strategy
should be aligned with the business strategy.
2.2.1
Vision and Mission
As organisational vision and mission shape business strategy, understanding this

vision and mission is important for systems strategy development. Some
organisational vision and mission are not clearly formulated and articulated. Lack
of clarity in organisational vision and mission often leads to lack of viable business
strategy as well as systems strategy. Information system needs tend to emerge out
of crisis rather than via proper planning.
2.2.2
Industry and Competitive Position
In addition to organisational vision and mission, many dynamic factors also

shape business strategy, such as organisational consolidations and mergers,
competitions, technological developments and changes in the regulatory
environment. There are two methodologies to capture information on dynamic
factors:
(a)
Industry Analysis
Industry analysis offers information on industry trends and the potential
risks and opportunities that can affect an organisations business
performance.
36
(b)
TOPIC 2
SYSTEMS PLANNING
Competency Analysis
Competency analysis offers information on an organisations effectiveness
in terms of its resources, infrastructure, products and/or services and
customers.
Information on the dynamic factors helps to determine an organisations strengths,

weaknesses, core competencies and strategic options. Examples of strategic options
are market-entry and new product development.
When choosing a suitable business strategy, analyses of strengths, weaknesses and
core competencies of competitors and potential trading partners are also helpful.
Such analyses shed light on new business opportunities and potential strategic
synergies from partnerships.
2.3

LEGACY SYSTEMS
Legacy systems refer to the current applications, databases and business

operations that are in full operation in an organisation. Legacy systems are difficult
to maintain and enhance, therefore most organisations maintain the old legacy
systems as well as incorporate new technologies. They are mapped to current
business processes to ascertain alignment with organisational vision and mission.
Assessment of future strategic business needs together with mapping of legacy
systems to current business processes will shed light on the appropriate migratory
strategy to move legacy systems to new, future systems with minimal disruptions
to business operations.
2.3.1
Architecture Description
An architecture description is a formal description of information systems.

The description explains the structural properties, components and their
interrelationships that make up the entire information system. The description
serves as a guideline for new systems development and commercial packages
procurement and ensures harmonious workings of components of the overall
system. The description also serves as a foundation for a legacy migratory
strategy.
TOPIC 2
SYSTEMS PLANNING
37
SELF-CHECK 2.2
1.
How do you find out about an organisations strategic business

needs to ensure alignment with systems strategy?
2.
How do you assess an organisations legacy system?
2.4

USER FEEDBACK
Evaluation of user feedback includes detection of areas of user needs,

preparation of proposals, evaluation of proposals feasibility and contribution to
business strategy and prioritisation of individual projects. Typically, lower-level
managers and operational personnel who are in continuous contact with day-today operations are in the best position to notice symptoms of a problem, such as
difficulties in liaising with disgruntled customers, suppliers and the financial
community. Most reports of symptoms of a problem as well as systems requests
originate from lower-level management.
The major phases of user feedback evaluation will be discussed in greater detail
in the following.
2.4.1
Recognising a Problem
There are various symptoms that suggest the need for new or improved
information systems. Symptoms can be innocuous, vague and confusing in the
early stages of a problem. Failure to act on the problem results in these
symptoms becoming more pronounced as the underlying problem becomes more
severe, eventually causing business operations to be in a state of crisis. There are
two positions in approaching a problem, reactive and proactive management.
(a)
Reactive Management
Reactive management responds to a problem only when the problem is in a
state of crisis and can no longer be ignored. This position is considered
extreme due to the pressure to resolve a problem that is already out of
control, i.e., in a state of crisis. Pressure to derive a solution can result in
hurried analysis, incomplete problem identification, shortcuts in design
and poor user participation, which may lead to suboptimal solutions.
38
(b)
TOPIC 2
SYSTEMS PLANNING
Proactive Management
Proactive management constantly looks for avenues to improve on
information systems and is alert of subtle symptoms of a problem. This
position is likely to recognise a problem at an early stage. Early problem
detection prevents the problem from developing to a state of crisis and
provides sufficient time for a complete and thorough investigation of the
problem.
2.4.2
Defining the Problem
A typical mistake in defining a problem is that most people tend to leap from the
symptoms to the problems, confounding symptoms with problems. For instance,
increased product returns, delays in product shipments to customers, excessive
overtime for operational personnel and slow inventory turnover rates are
symptoms that suggest underlying problems. Such symptoms can be construed
as problems when conclusions are drawn in haste as exemplified in Figure 2.2.
Figure 2.2: Defining the problem
TOPIC 2
SYSTEMS PLANNING
39
It is important to learn enough about a problem to derive an informed and

rational solution. While it is not possible to conduct exhaustive information
search and evaluation, the nature of the problem has to be specified based on the
symptoms identified and reported to the systems professionals, or information
systems department. Systems professionals need to interact with the users to
develop a formal project proposal. The steering committee will then examine and
approve the project proposal.
The three stages that follow specifying systems objectives, determining project
feasibility and preparing a formal project proposal require collaborative efforts
from systems professionals and the manager/supervisor of the user department
from which the problem originates.
2.4.3
Specifying Systems Objectives
User information needs are translated into operational objectives for the new,
improved information systems. Examples of operational objectives include
processing 10,000 sales orders in an hour, providing up-to-the-minute inventory
status and ensuring that all customer orders received by 2pm each day are
shipped to the customers by the end of the day.
2.4.4
Determining Project Feasibility
Preliminary project feasibility is conducted to ascertain how to proceed with

the project in question. A systems project feasibility or likelihood of success
is evaluated prior to committing financial, human and other resources. The
acronym TELOS technical, economic, legal, operational and schedule guides
the project feasibility assessment (Hall, 2013).
(a)
Technical Feasibility
Technical feasibility looks at whether the system can be developed with
existing technical resources. Otherwise, new resources have to be acquired.
Technical resources, especially technology, are the foundation for most
systems design features. Technical feasibility bears substantial weight on
the overall feasibility of the proposed project. The following questions
guide assessments of technical feasibility of a proposed project (Shelly &
Rosenblatt, 2010):
(i)
Does the organisation have the necessary hardware, software and

network resources? If not, can those resources be acquired easily?
(ii)
Does the organisation have the required technical expertise? If not,

can the technical expertise be acquired?
40
TOPIC 2
SYSTEMS PLANNING
(iii) Does the proposed platform have sufficient capacity for future needs?
If not, can it be expanded?
(iv) Is a prototype required?
(v)
Are the hardware and software reliable? Do they integrate with the
information systems of other organisations? Will they be able to do
so in the future? Do they interface properly with the systems of
customers, suppliers and other trading partners?
(vi) Does the combination of hardware and software ensure adequate

performance? Are expectations and performance specifications clear?
(vii) Is the system capable of handling future transaction volume and
company growth?
(b)
Economic Feasibility
Economic feasibility pertains to the economic resources available to
complete the project. Availability of economic resources determines the
scope and nature of the proposed system. As the proposed project
competes with other capital projects for economic resources, it is important
for the proposed project to demonstrate benefits that outweigh estimated
costs. Estimated costs of a proposed project include costs of acquisition,
ongoing support and maintenance. Benefits of a proposed project can be
tangible and measured in monetary terms, such as costs-savings and
increase in revenues. Examples of tangible benefits are as follows (Shelly &
Rosenblatt, 2010):
(i)
A new scheduling system that reduces overtime;
(ii)
An online product delivery tracking system that improves services

and decreases the need for clerical work; and
(iii)
An inventory control system that eliminates excess inventory and

production delays.
Benefits of a proposed project can also be intangible, cannot be translated

into monetary terms. Examples of intangible benefits are as follows (Shelly
& Rosenblatt, 2010):
(i)
A user-friendly system that enhances employee job satisfaction;
(ii)
A sales tracking system that supplies valuable information for

marketing decisions; and
(iii)
An improved website that enhances an organisations image.

TOPIC 2
(c)
(d)
SYSTEMS PLANNING
41
Legal Feasibility
Legal feasibility requires ascertaining whether the proposed project is in
conflict with the organisations responsibilities to fulfil legal requirements
and obligations. Examples of legal requirements and obligations that
organisations need to fulfil include:
(i)
Internal control requirements as laid down in the Statement on

Auditing Standards No. 78 and Sarbanes-Oxley legislation; and
(ii)
Maintaining the privacy and confidentiality of stored information

pertaining to customers, suppliers, other trading partners and
employees.
Operational Feasibility
Operational feasibility refers to the degree of compatibility between
existing organisational practices, procedures and personnel skills with
the operational requirements of the new systems. A high degree of
compatibility between existing and new systems makes users more
receptive of the new systems, as users have less difficulties adapting to the
new systems. Among the questions that guide assessment of operational
feasibility are as follows (Shelly & Rosenblatt, 2010):
(i)
Does management support the project? Do users support the project?

Is the current system well-liked and effectively used? Do users see the
need for change?
(ii)
Do the new systems result in workforce reduction? If so, what will

happen to affected employees?
(iii)
Do the new systems require training for users? If so, does the
organisation provide resources for training of current employees?
(iv)
Are users involved in planning the new systems development from

the beginning?
(v)
Do users feel stressed when using the new systems? Is information

less accessible or produced less frequently? Is performance
compromised in any way? Does the overall gain outweigh losses?
(vi)
Are customers adversely affected in any way, temporarily or

permanently?
(vii) Is the organisations image or goodwill adversely affected?
42
TOPIC 2
SYSTEMS PLANNING
(viii) Is the project in conflict with other priorities of the organisation?

(ix)
(e)
What are legal or ethical issues involved, if any?
Schedule Feasibility
Schedule feasibility refers to the ability to implement and complete the
project within a reasonable timeframe. It affects the scope of the project and
whether the project will be developed in-house or acquired from software
suppliers. There is typically a trade-off between time and costs; speedy
project completion makes projects feasible but is more expensive. The
questions that guide assessment of schedule feasibility are as follows
(Shelly & Rosenblatt, 2010):
(i)
Can the factors that affect schedule feasibility be controlled?
(ii)
Have schedules and milestones been established for the project?
(iii)
Does speeding-up project completion pose any risk? If so, are the
risks acceptable?
(iv)
Are project management techniques in place to coordinate and

control the project?
(v)
Has a project manager been appointed and assigned to the project?
2.4.5
Preparing a Formal Project Proposal
A systems project proposal serves as a basis when deciding whether to proceed

with a project or not. Project proposals have two main purposes:
(a)
The proposal summarises findings of investigations conducted to-date, into

general recommendations for a new or modified system. The proposal
enables management to evaluate the perceived problems and how the
proposed system will serve as a solution to the problems; and
(b)
The proposal links the objectives of the proposed system to the business
objectives of the organisation. It also enables evaluation of whether the new
system complements the organisations strategic direction or otherwise.
TOPIC 2
SYSTEMS PLANNING
43
SELF-CHECK 2.3
1.
What are the major phases of user feedback evaluation?
2.
What is the common mistake in defining a problem?
3.
What are the preliminary feasibility tests to ascertain whether to

proceed with a systems project?
4.
What are the purposes of preparing a formal project proposal?
2.5
DEVELOP A STRATEGIC SYSTEMS PLAN
Based on the information gathered on business needs, legacy systems and user
feedback, the steering committee and systems professionals will evaluate each
project proposal. This includes assessing each projects benefits, costs and
strategic implications on the organisation. Proposals that show the greatest
potential for supporting the organisations business objectives in the most cost
effective manner are approved for development.
A strategic systems plan is a major output of the steering committee and
professionals in-charge of systems development. The plan is a written document
that contains long and short-term goals related to systems development. Among
the important information the plan should include are (Bodnar & Hopwood,
2001):
(a)
Statements related to the critical success factors of the organisation and

organisational objectives;
(b)
Descriptions of the information systems that require development;
(c)
Statements on priorities in systems development, which areas are given the

highest and lowest priority;
(d)
Descriptions of resources required human resources, equipment, etc.

and cost of the required resources; and
(e)
Tentative schedules for specific systems projects.
44
TOPIC 2
SYSTEMS PLANNING
2.5.1 Setting Priorities for Systems Projects

Setting priorities for systems projects is crucial to ensure that the limited
resources available to the organisation are managed efficiently. Prioritising
systems projects should be done in a manner consistent with capital budgeting,
where financial budgets are prepared. Specific benefits of the projects should be
defined and costs should be estimated as accurately as possible.
Benefits of systems development are not readily quantifiable and measureable in
monetary terms, but costs are readily quantifiable and measurable in monetary
terms, which complicates the priority-setting task. For example, the benefit of a
new sales order system is to allow monitoring of incomplete orders. A possible
solution to evaluating the benefits of the sales order system is to relate improved
monitoring of incomplete orders to customer satisfaction and increase in sales.
Improved monitoring of incomplete orders minimises overdue orders and
enhances customers satisfaction, leading to increase in sales by five percent, for
instance. Another solution is to assess the extent to which the benefit of the sales
order system is aligned with organisational strategic objectives and critical
success factors. Systems projects that are more aligned with organisational
strategic objectives and critical success factors deserve higher priority.
Figure 2.3 illustrates how competing systems projects can be presented clearly for
comparisons and evaluations. The vertical axis represents project priority in
terms of organisational needs. The horizontal axis represents expected costs of
projects. The size of the circle reflects each projects strategic impact.
Figure 2.3: Evaluation of competing systems projects to determine priority

Source: Hall (2013)
TOPIC 2
2.6
SYSTEMS PLANNING
45
CREATE ACTION PLANS
Strategies both business and system strategies need to be translated into

action. A balance scorecard is a management tool that helps to translate strategy
into action. The scorecard provides feedback for both internal business processes
and external outcomes to direct continuous improvements on strategic
performance. The balanced scorecard suggests that organisations should be
viewed and evaluated from four perspectives:
(a)
Learning and Growth Perspective

Learning and growth includes employee training and cultural attitude
towards self-improvement. Metrics based on this perspective encourages
self-learning and guides channelling of training funds.
(b)
Internal Business Process Perspective

Metrics based on this perspective reflect how well business operations are
managed and whether products and services conform to customer
requirements.
(c)
Customer Perspective
Metrics based on this perspective are leading indicators. If customers are
not satisfied, other perspectives, especially financial perspectives are
affected; sales, profitability and other financial implications will eventually
be affected as customers will find other suppliers capable of meeting their
needs.
(d)
Financial Perspective
Metrics based on this perspective are traditional measures of performance,
such as sales and revenues and profitability, which are also known as lag
indicators. Overemphasis on this perspective leads to short-term focus and
creates an imbalance with other perspectives.
The key benefit of the balance scorecard lies in the linkages between the four
perspectives of performance. For instance, poor performance from the financial
perspective as measured by decline in sales is attributable to dissatisfied
customers, as measured by low customer retention from the customer
perspective. Root causes and potential solutions for this issue can then be found
by examining the learning, growth and internal business process perspectives,
e.g., processing time of customer order, product delivery time, etc.
46
TOPIC 2
SYSTEMS PLANNING
Figure 2.4 illustrates how a balanced scorecard can be used to translate a

hypothetical online banking project into action. Performance of the online
banking project can be assessed in terms of the four perspectives. The online
banking project is expected to improve performance across the four perspectives,
as represented by the metrics under each perspective.
Figure 2.4: Evaluating an online banking project with a balanced scorecard

Source: Hall (2013)
The balanced scorecard also serves as a tool to assist the steering committee in
setting priorities among competing systems projects. In addition to strategic
impact, competing systems projects can also be assessed in terms of the four
perspectives. The steering committee can decide whether to approve systems
projects based on the metrics under each of the four perspectives. Approved
systems projects proceed to the project initiation phase, which is discussed in the
next topic. Rejected systems projects will not be further considered within the
current budget period.
TOPIC 2
2.7
SYSTEMS PLANNING
47
THE ROLE OF ACCOUNTANTS
Accountants are considered uniquely qualified to participate in systems

development for two major reasons (Gelinas et al., 1999):
(a)
Accountants have a combination of IT, business, accounting, internal

control, as well as behaviour and communication knowledge. Such
combination of knowledge ensures that the new information systems meet
user needs and possess sufficient internal controls; and
(b)
Accountants have specialised skills, such as accounting and auditing. Such

skills are particularly useful in performing costs and benefits analyses of
proposed systems.
Figure 2.5 provides a summary of how accountants can contribute in their

position as a systems specialist, consultant, staff accountant, internal auditor and
independent auditor in systems development.
Accountant Type
Involvement in Systems Development
Systems specialist
As an employee of the organisation possessing some systems

specialty, such as systems analyst the accountant undertakes
many of the activities in a systems development project.
Consultant
Hired from outside the organisation possibly from the

management consulting division of a public accounting firm
the accountant may undertake many of the activities in a
systems development project.
Staff accountant
As an employee of the organisation, an accountant can become

involved in systems development as the user of the system and
as the requestor of the system changes. The accountant might
also join the development team.
Internal auditor
Internal and information technology (IT) auditors review

systems and make recommendations that lead to system
changes. Also, they review development projects to ensure that
systems are developed efficiently and effectively and that the
systems being developed will have sufficient internal controls
and will be auditable.
Independent auditor
An independently auditor must review the systems that produce

financial statements; if the auditor finds inefficient systems,
he notifies management in the management letter; if he finds
inadequate controls, he notifies management and may alter the
audit. The management letter recommendations may lead to the
initiation of systems development.
Figure 2.5: The role of accountants in systems development

Source: Gelinas et al. (1999)
48
TOPIC 2
SYSTEMS PLANNING
Accountants can contribute to systems development planning in several ways

including:
(a)
As a systems specialist or consultant, accountants can become a member of

the systems development team to identify strategic information needs,
develop strategic systems plan and action plans;
(b)
As a staff accountant, who is well-versed with the organisations strategic

objectives and performance measurement systems, accountants can
cooperate with the systems development team, especially in the
preparation and analysis of costs and benefits reports for new systems
feasibility assessment and prioritisation; and
(c)
As an internal or independent auditor, knowledgeable about information

systems and its weaknesses, accountants can indicate deficiencies of the
information systems, prompting users requests for new systems.
SELF-CHECK 2.4
1.
What is a strategic systems plan?
2.
What is the purpose of setting priorities for systems projects?
3.
Is there any difference between a strategic systems plan and an

action plan? What are the differences, if any?
4.
What can accountants do to faciliate systems development

planning?
Planning ensures efficient use of resources and aligns systems development

to the organisations strategic objectives.
Systems development planning includes assessing strategic information

needs, developing a strategy systems plan and an action plan.
Information on organisational strategic business needs, situation of the legacy

system and user feedback are most important in systems development
planning.
TOPIC 2
SYSTEMS PLANNING
49
Accountants equipped with expertise in IT, business, accounting, auditing

internal control, as well as behaviour and communication can contribute in
many ways towards systems development.
Action plan
Schedule feasibility
Balanced scorecard
Strategic information needs
Critical success factors
Strategic systems plan
Economic feasibility
Steering committee
Legal feasibility
Systems objectives
Operational feasibility
Systems strategy
Project proposal
Technical feasibility

Prentice Hall.
50
TOPIC 2
SYSTEMS PLANNING
Shelly, G. B., & Rosenblatt, H. J. (2010). Systems analysis and design (8th ed.).
Boston, MA: Course Technology, Cengage Learning.
Topic Systems
Analysis
LEARNING OUTCOMES
1.
Explain why systems analysis is important;
2.
Discuss why user participation in systems analysis is important

and the methods of enlisting user participation;
3.
Describe the major stages in systems analysis;
4.
Identify the purposes and functions of various fact-gathering

techniques; and
5.
Analyse the purposes and functions of various techniques for

organising facts.
INTRODUCTION
What do you think of the comic strip in Figure 3.1? Is it important to get to know
the existing information systems and software applications? Or, since the existing
systems and applications are already in place, should everybody already know
everything about them?
Figure 3.1: Understanding the current information systems

Source: http://www.dilbert.com
52
TOPIC 3
SYSTEMS ANALYSIS
The previous topic covered systems development planning, which highlighted

the importance of planning to ensure that the proposed systems projects are
aligned with organisational goals and support business needs. This topic covers
systems analysis for a better understanding of both the current as well as the
proposed new systems. First we will discuss the importance of systems analysis
and why user participation is important. Then we will discuss the key stages in
systems analysis for a complete and thorough understanding of the current and
proposed systems. Next, we will discuss the common techniques used in
gathering, organising and analysing information. Finally, we will discuss how
accountants can contribute in systems analysis.
3.1
OVERVIEW OF SYSTEMS ANALYSIS
Systems analysis is the foundation of systems development and is the first step in
project initiation. Project initiation involves investigating projects approved by the
steering committee. Problems from user feedback are examined further to identify
alternative solutions. Each alternative is evaluated in terms of its feasibility, costs
and benefits. The chosen alternative proceeds to the construct phase, in-house
development and/or commercial packages acquisition depending on the nature of
the project and the needs of the organisation.
The primary objectives of systems analysis are (Bodnar & Hopwood, 2001):
(a)
To understand the existing information systems;
(b)
To identify and understand problems;
(c)
To translate problems into information needs and system requirements; and
(d)
To identify which subsystems deserve the highest priority.
Once specific subsystems are targeted for development, systems analysis focuses
on defining the information needs and system requirements in order for the
systems to implement organisational objectives. System requirements are
translated into specific applications during the design phase of systems
development.
Systems analysis requires analytical and interpersonal skills. Analytical skills are
required to identify and evaluate problems and develop useful solutions.
Interpersonal skills are valuable when working with users at all organisational
levels and in balancing conflicting needs of users.
TOPIC 3
SYSTEMS ANALYSIS
53
As information systems affect users throughout the organisation, users are often
perceived as partners in systems development for better communication, speedy
development and more satisfied users. While IT personnel like systems analysts
and programmers play a central role, users active participation in various systems
development tasks are pertinent. Three team-based techniques JAD, RAD and
agile methods are used in engaging users in systems analysis and will be further
discussed in the following (Shelly & Rosenblatt, 2010).
3.1.1
Joint Application Development (JAD)
Joint application development (JAD) is a fact-finding technique that includes users

as members of the JAD team. Users are involved in discussions on business and
information needs as well as new systems requirements. JAD allows key users to
participate in new system requirements modelling, which can result in more
accurate statements of system requirements, a better understanding of common
organisational goals and stronger commitment to success for the new systems.
However, JAD can be expensive and cumbersome when the JAD team is too large
in relation to the size of the systems project.
3.1.2
Rapid Application Development (RAD)
Like JAD, rapid application development (RAD) is also a team-based technique,

but goes much further. JAD engages users in system requirements modelling
whereas RAD engages users in producing functional information systems. Users
are involved in the four phases of RAD as follows:
(a)
Requirements Planning
Users are involved in the discussions and agree on business needs, project
scope, constraints and system requirements.
(b)
User Design
Users interact with systems analysts in developing models and prototypes
that represent all system processes, inputs and outputs. CASE tools are often
used to translate user needs into working models. An interactive process
allows users to understand, modify and approve the working model of the
system that meets users needs.
(c)
Construction
Users continue to participate and suggest changes and/or improvements as
actual screens and/or reports are developed as part of a programme and/or
application development.
54
(d)
TOPIC 3
SYSTEMS ANALYSIS
Cutover
The cutover phase includes data conversion, testing and changeover to the
new systems and user training. With this, the new systems are built,
delivered and fully operational much sooner.
3.1.3
Agile Methods
Agile methods develop information systems incrementally. A series of prototypes

are built and consistently adjusted to suit user requirements. Each incremental step
is determined by what is learned in prior steps. There are many agile modelling
tools, such as Unified Modelling Language, entity-relationship diagrams, data flow
diagrams and business process modelling. Use of whiteboard displays and
arrangements of movable sticky notes can also be used for a simple, rapid, flexible
and user-oriented agile strategy.
SELF-CHECK 3.1
1.
Why do organisations conduct systems analysis?
2.
What are the three techniques in enlisting users participation in

systems analysis? How does each technique engage users in
systems analysis? Complete the table below.
Techniques
1.
Joint application
development (JAD)
2.
Rapid application
development (RAD)
How Does Each Technique Engage Users in

Systems Analysis?
3. Agile methods
TOPIC 3
3.2
SYSTEMS ANALYSIS
55
STAGES IN SYSTEMS ANALYSIS

ACTIVITY 3.1
Imagine that you have switched on your desktop computer for about
10 minutes by now, but the computer monitor is still blank. Will you
replace the computer monitor?
Write down the steps that you will take, if any, before deciding whether
to replace your computer monitor.
Incomplete or defective analysis leads to incomplete or defective solutions.

Systems analysts require a comprehensive understanding of a business problem to
formulate alternative solutions. To ensure a comprehensive understanding,
systems analysis should encompass four stages, surveying current systems,
identifying information needs, identifying system requirements and preparing a
systems analysis report (Bodnar & Hopwood, 2001). The four stages are illustrated
in Figure 3.2 and further discussed in the remainder of this topic.
Figure 3.2: Four steps in systems analysis
56
3.2.1
TOPIC 3
SYSTEMS ANALYSIS
Stage 1: Survey Current Systems
The systems development team needs to be familiar with the current systems
under consideration for change. It is dangerous to implement changes that are not
fully understood to information systems. Surveying the current systems enables
the systems development team to understand the systems. The primary objectives
of systems survey are as follows (Bodnar & Hopwood, 2001):
(a)
Obtain a thorough understanding of the operational aspects of the systems;
(b)
Establish a working relationship with users of the systems;
(c)
Collect data useful in developing systems design; and
(d)
Identify specific problems that require focus in subsequent design efforts.
Becoming familiar with the users working with the systems on a daily basis is
important for a better understanding of the problems that top management are
completely unaware of. To a certain extent, quality of the relationship between the
systems development team and users working with the systems determine the
success of systems development.
A poor relationship between the systems development team and users working
with the systems can result in misunderstandings, misdirected focus and
misplaced design efforts. Furthermore, users can reject the new systems, which are
designed for them. Users can resist implementation of the new systems in several
ways, either via complaints to top management, strikes or sabotage. The following
approaches can help to bridge the communication gap between the systems
development team and users:
(a)
Get to know as many users working with the systems, especially those most
affected by the new systems, as soon as possible;
(b)
Communicate the benefits of the new systems, especially to users who are
most affected;
(c)
Provide assurances, whenever possible, to all users that there will be no loss
of jobs or major changes in job responsibilities; and
(d)
Provide assurances that the systems development team are genuinely

concerned with making life better for all users involved in the systems.
The systems development team normally begins by determining which
aspects of the current information systems are relevant and should be
preserved as a part of the new systems. This requires detailed systems
survey. First, information gathered based on preliminary questions is
TOPIC 3
SYSTEMS ANALYSIS
57
analysed. As analysts acquire a better understanding of the problems at

hand, more specific questions can be developed to gather more information.
This information gathering step may go through several interactions until the
analysts arrive at an assessment of the current information systems. Though
surveying the current systems facilitates systems development in general,
there are some pitfalls to this as well. The following explains the pitfalls and
advantages of surveying the current systems and details the various aspects
involved in this process.
(a)
Pitfalls in Surveying the Current Systems

Surveying the current systems can be a daunting and tedious task for
systems analysts, especially when the systems have been in place and
operational since time immemorial; essentially the systems development
team is getting to know the old way of doing things that the organisation
has been stuck with all this while.
Surveying the current systems has also been contended to stifle creativity. As
analysts find out more about how things were previously done, they may
develop a constrained notion about how the new information systems
should function (Hall, 2013). Analysts attempts to preserve part of the
current systems results in an improved old system rather than a radically
new approach. Enterprise resource planning (ERP) is an example where
reviewing the current systems serves little purpose, as successful
implementation of Enterprise resource planning (ERP) requires reengineering
business processes to employ the best practices in the industry.
(b)
Advantages of Surveying the Current Systems

However, surveying the current systems helps to identify which aspects of
the old systems are still functionally sound and can serve as a foundation for
the new systems. The systems development team is then able to decide
which aspects of the systems are worth preserving and which should be
modified in the new systems.
The systems development team also needs to decide what tasks, procedures
and data should be phased out with the old systems and which should
continue in the new systems. The team needs to specify the conversion
procedures and what is to be done with the old as well as new systems.
Hence, the team requires a thorough understanding of the old systems.
Surveying the current systems enables the team to determine the causes of
the reported symptoms of problems. There are times when the root of the
problems is not the information systems, but is related to the management or
employees, which can then be resolved without redesigning the information
systems.
58
(c)
TOPIC 3
SYSTEMS ANALYSIS
Gathering Facts
Surveying the current systems is a fact-gathering exercise. The systems
development team gathers pieces of data that describe the key features,
situations and relationships of the current systems. It is important to gather
facts from both internal and external sources. System facts can be broadly
categorised as (Hall, 2013):
(i)
Data sources: Of both external entities customers and vendors and

internal sources from other departments;
(ii)
Users: Includes managers and operational level users;
(iii)
Data stores: Includes files, databases, accounts and source documents

used in the systems;
(iv)
Processes: Includes manual processing tasks and computer operations

that represent a decision or action that is triggered by information;
(v)
Data flows: Includes movement of documents and reports between

data sources, data stores, processes and users;
(vi)
Controls: Includes accounting and operational controls, manual

procedures as well as computer controls;
(vii) Transaction volumes: The systems development team requires a

measure of transaction volumes for a specific time period. Information
systems are typically replaced due to having reached maximum
capacity. It is important to understand the characteristics of a systems
transaction volumes and its rate of growth in assessing the capacity
requirements for the new systems;
(viii) Error rates: Transaction errors are dependent on transaction volumes.
Having reached the systems maximum capacity, error rates tend to
increase to an intolerable level. The systems development team must
determine the acceptable error tolerance for the new systems;
(ix)
Resource costs: Resources that the current systems consume include

labour, computer time, materials (invoices) and direct overhead.
Resources that disappear with the elimination of the systems are
escapable costs. Escapable costs are treated as benefits to the new
systems; and
TOPIC 3
(x)
(d)
SYSTEMS ANALYSIS
59
Bottlenecks and redundant operations: The systems development team

must identify bottlenecks in the existing systems. At peak periods,
bottlenecks result in delays and promote processing errors. Delays are
also attributable to redundant operations, such as unnecessary
approvals or sign-offs. The team can avoid the same mistakes
bottlenecks and redundant operations in the design of the new
systems.
Analysis of Survey Findings

Facts gathered should be thoroughly analysed to determine the strengths and
weaknesses of the current systems. The following checklist of questions
(Bodnar & Hopwood, 2001) facilitates assessing these strengths and
weaknesses:
(i)
Is a given procedure necessary?
(ii)
Does the procedure involve unnecessary steps?
(iii)
Is the procedure cost-effective?
(iv)
Is a given report clear and easy to read?
(v)
Are the source documents well designed?
(vi)
Are reports generated not required or used?
(vii) What additional reports might be useful to the management?

(viii) Is the systems documentation adequate?
In evaluating strengths and weaknesses of the current systems, certain
standards must be used as benchmarks. Such standards often relate to the
efficiency and effectiveness in accomplishing organisational objectives set for
various organisational levels and functions in the planning phase of systems
development. Evaluation of efficiency and effectiveness in attaining
organisational objectives should focus on bottlenecks, which represent
weaknesses in the current systems. Minor adjustments aimed at bottlenecks
can result in major improvements to the systems. For instance, an
organisation is having difficulties delivering goods to customers on time.
Job scheduling has been found to be ineffective as there are times employees
are idle, despite backlogs in the production and delivery schedule. Hence,
the focus should be to improve on the production scheduling system, the
bottleneck.
60
3.2.2
TOPIC 3
SYSTEMS ANALYSIS
Stage 2: Identify Information Needs
The second step in systems analysis is to identify the information requirements

for managerial decision-making. This step requires studying the information
inputs to the specific decisions that managers make, which is also known as
information needs analysis (Bodnar & Hopwood, 2001).
Managers are often unable to articulate the specific information they need to
make decisions. They frequently think in terms of getting jobs done rather than
the information they need. In order to identify information needs, you need to be
familiar with the kind of decisions managers make and the problems and/or
difficulties that managers frequently encounter when making decisions. Basic
approaches in identifying information needs are as follows:
(a)
Identify the primary job responsibilities associated with the position of a

manager;
(b)
Identify how the manager is evaluated, which determines the approaches

the manager adopts in dealing with day-to-day tasks and problems. For
instance, an advertising manager who is evaluated on customers
responsiveness to advertising campaigns would require reports related to
advertising expenditures and sales and/or other measures of customer
responsiveness;
(c)
Identify the major problems that the manager faces, which typically require
asking the manager lots of questions about what the manager does. The
answers are not straightforward and require careful listening to; and
(d)
Identify how managers evaluate their own output, that is, the quality of their
decisions.
SELF-CHECK 3.2
1.
What are the purposes of surveying the current information

systems?
2.
Why is it important to identify bottlenecks?
3.
How do you identify information needs for decision-making?
TOPIC 3
3.2.3
SYSTEMS ANALYSIS
61
Stage 3: Identify System Requirements
The third step in systems analysis is to specify system requirements. The major
categories of system requirements are inputs and outputs. Input requirements
are specific needs that must be met for the systems to achieve their objectives. For
example, input requirements of a production control system are sales forecasts,
reports on materials availability, specifications of quality control and standard
costs and reports required to determine job priorities. Output requirements of
production control systems are daily progress reports, financial reports, reports
on defective units and reports on problems with raw materials.
The input requirements for one subsystem are the output requirements of
another subsystem. For instance, a report of problems with raw materials, which
is an output requirement of production control systems, is an input requirement
for the materials procurement system.
System requirements are features that must be included in the new information
systems to satisfy business and user information needs. These requirements
constitute the benchmark cum checklist to measure the overall acceptability of
the completed, new systems. In addition to requirements pertaining to inputs
and outputs, there are three other categories of system requirements that must be
specified, which are: process, performance and control requirements. Examples
of the system requirements under each of the five categories are as follows
(Shelly & Rosenblatt, 2010).
(a)
Examples of output requirements:

(i)
The website must report online statistics every four hours and hourly
during peak periods;
(ii)
The inventory system must produce daily reports on the inventory

code, description, quantity on hand, quantity allocated, quantity
available and unit costs of all inventory items sorted by the inventory
code;
(iii) The contact management system must generate daily reminder lists
for all sales representatives;
(iv) The purchasing system must provide suppliers with up-to-date
specifications;
(v)
The sales tracking system must produce a daily fast-moving-item

report listing all products that exceed the forecasted sales volume by
style, colour, size and reorder status; and
62
TOPIC 3
SYSTEMS ANALYSIS
(vi) The customer analysis system must produce a monthly report that
identifies changes in ordering patterns or trends with statistical
comparisons to the previous six months.
(b)
Examples of input requirements are:

(i)
Factory employees must swipe their ID cards into online data

collection terminals that record labour costs and calculate production
efficiency;
(ii)
The department head must enter overtime hours on a separate screen;
(iii) The grades of students must be entered on machine-scannable forms

prepared by the instructor;
(iv) Each input form must include the date, time, product code, customer
number and quantity;
(v)
Data entry screens must be uniform, except for background colour,

which users can adjust; and
(vi) Data entry personnel from a medical group must input patient
services into the billing system.
(c)
Examples of process requirements include:

(i)
A student records system must calculate the GPA at the end of each
semester;
(ii)
A payroll system must update employee salaries, bonuses, benefits

and tax data as the final step in year-end processing;
(iii) A warehouse distribution system must analyse daily orders and

create a routing pattern for delivery trucks that maximises efficiency
and reduces unnecessary mileage;
(iv) A human resources system must interface properly with an existing
payroll system;
(v)
A video rental system must not execute new rental transactions for
customers who have overdue tapes; and
(vi) A prescription system must automatically generate an insurance claim

form.
TOPIC 3
(d)
SYSTEMS ANALYSIS
63
Examples of performance requirements are as follows:

(i)
The system must support 25 users online simultaneously;
(ii)
Response time must not exceed 10 seconds;
(iii) The system must be operational seven days a week, 365 days a year;
(iv) An accounts receivable system must prepare customer statements by
the third business day of the following month;
(v)
A student records system must produce class lists within five hours
after the end of registration; and
(vi) An online inventory control system must flag all low-stock items
within one hour after the quantity falls below a predetermined
minimum.
(e)
Examples of control requirements include:

(i)
The system must provide logon security at the operating system level
and at the application level;
(ii)
An employee record must be added, changed or deleted only by a

member of the human resources department; and
(iii) The system must maintain separate levels of security for users and
system administrators.
3.2.4
Stage 4: Prepare a Systems Analysis Report
The final step in systems analysis is to prepare a systems analysis report. The
report organises and documents the findings of the first three steps of systems
analysis. The report is important for future decision-making and guides
subsequent phases in systems development. Without proper documentation at
the time of analysis, a lot of the findings may be forgotten as systems
development progresses. Among the important information the report should
contain includes:
(a)
The Scope and Purpose of Systems Analysis

(i)
Scope and purposes as specified in the systems project proposal; and
(ii)
Changes in the scope and purposes since systems analysis began.
64
TOPIC 3
SYSTEMS ANALYSIS
(b)
How the Project Relates to Systems Strategy

Priority of the project in terms of alignment with organisational strategic
objectives.
(c)
Problems in the Current Systems and Specific Subsystems Under

Investigation
(i)
Techniques used to gather facts;
(ii)
Problems identified in the fact-gathering process; and
(iii) Analysis of facts.

(d)
Decisions Being Made

Information input requirements.
(e)
Statement of User Requirements
(f)
(g)
(i)
Specific user needs in key areas, such as output requirements (specific

reports) and performance requirements (transaction volumes and
response time); and
(ii)
Non-technical terms for a broad-based audience, including end-users,

management and the steering committee.
Resource Implications
(i)
Preliminary assessment of economic effects; and
(ii)
Evaluation of economic feasibility as stated in the project proposal.
Recommendations for Improving Current Systems or Designing New

Systems
(i)
Recommendations related to modifying the objectives of the

subsystem under study; and
(ii)
Recommendations of system requirements specifications.
The systems analysis report constitutes a common understanding of what

the information systems must do, including the objectives and goals of the
information systems primarily between systems professionals, management
and users. The report clarifies the data stores, users, data files, general
processes, data flows, controls and transaction volume capacity required of
the systems. The report does not specify the detailed design of the proposed
systems specific processing methods, storage media and record structures
to avoid constraining systems design.
TOPIC 3
SYSTEMS ANALYSIS
65
The systems analysis report is reviewed and discussed at the steering committee
and/or top management level to decide whether a preliminary systems design
should be undertaken.
SELF-CHECK 3.3
1.
Why do you need to specify the requirements of the proposed,

new systems? What are the important categories of system
requirements that should be specified?
2.
Why do you need to prepare a systems analysis report?
3.3
FACT-GATHERING TECHNIQUES
There are several techniques the systems development team can use to gather facts.
3.3.1
Observation
Observation involves passively observing or watching the physical procedures of

the systems. This technique reveals what gets done, who performs the task, when
they do it, how they do it, why they do it and how long it takes.
3.3.2
Task Participation
Task participation involves playing an active role in performing the users work.
This technique allows first-hand experience with the problems associated with the
operations of the current systems. Among the information revealed when actively
performing users work are whether documents source and product documents
are properly designed, whether time is sufficient to complete the required
procedures and peak-load problems, if any, which cause bottlenecks and
processing errors. Active participation often reveals better ways to perform the
tasks.
3.3.3
Personal Interviews
Personal interviews involve extracting information about the current systems

and discovering user perceptions about the requirements for new systems. The
instruments used to gather information using this technique include interview
questions that are often administered verbally as well as formal questionnaires.
66
TOPIC 3
SYSTEMS ANALYSIS
Interview questions can be open-ended as well as structured.

(a)
Open-ended interview questions allow users to elaborate on the problems

and offer suggestions as well as recommendations. Answers to open-ended
questions provide a fundamental understanding of the current systems.
However, answers are often difficult to analyse. Interviewers need to listen
closely and focus on the important facts. An example of an open-ended
question is: What is the problem with our sales order system?;
(b)
Structured interview questions often follow once interviewers have

obtained a fundamental understanding of the current systems and
problems at hand. Interview questions are prepared beforehand and put in
the same order for each user. Answers are easier to analyse as they can be
reliably aggregated and compared; and
(c)
Questionnaires can be used to ask more specific and detailed questions.

They also restrict users responses to facilitate analysis. Use of
questionnaires is appropriate when gathering objective information. For
instance, information about the nature of specific procedures, volumes of
transactions processed, sources of data, users of reports and control issues.
3.3.4
Document Review
Document reviews are able to provide a fundamental understanding of the

current systems and are helpful prior to conducting interviews and
administering questionnaires. However, sometimes the current systems do not
operate as documented. Examples of documents that provide an overview of the
current systems include:
(a)
Flowcharts and flow diagrams;
(b)
Organisation charts;
(c)
Procedure manuals;
(d)
Operations manuals;
(e)
Reference manuals;
(f)
Historical records such as financial statements;
(g)
Job descriptions;
(h)
Chart of accounts; and
(i)
Policy statements.
TOPIC 3
SYSTEMS ANALYSIS
SELF-CHECK 3.4
What can you hope to find out about current information systems using
each of the following fact-gathering techniques?
Complete the table below.
Techniques
What Can You Find Out About the Current

Systems?
1. Observation
2. Task participation
3. Open-ended
interview questions
4. Structured
interview questions
5. Questionnaires
6. Document review
67
68
3.4
TOPIC 3
SYSTEMS ANALYSIS
TECHNIQUES FOR ORGANISING FACTS
Once the fact-gathering techniques are applied, information gathered must be

formally organised and documented for a better understanding of the systems.
Some of the techniques helpful in summarising and organising information are
discussed in the following. Each technique has its respective functions, which are
useful for different purposes.
3.4.1
Work Measurement
Work measurement summarises the resources required for various tasks. It is

similar to the fundamentals employed in standard cost systems in accounting. A
standard or yardstick is essential in work measurement to gauge efficiency of
business operations and procedures. Basic steps in work measurement are:
(a)
Identify the tasks;
(b)
Determine time estimates for performing the tasks, based on time-andmotion studies, test runs, historical data, interviews or some other sources;
(c)
Adjust time estimates for idle time and similar considerations; and
(d)
Analyse resource requirements based on the information summarised and

organised in the first three steps.
Work measurement is useful in two major areas of applications:

(a)
Evaluation of Technical Requirements

Examples include determining the number of magnetic disks required to
store a specific number of documents, determining the capacity of the
computer systems required to process a proposed workload and
determining the number of clerical staff required to key-in data.
(b)
Performance Evaluation of Systems Related Tasks

Performance evaluation requires determining performance standards in
terms of directly measureable criterions such as number of sales order
entered, or hours of work, so that actual performance can be quantified and
evaluated.
TOPIC 3
3.4.2
SYSTEMS ANALYSIS
69
Work Distribution
Armed with information on resources required for specific tasks as determined

through work measurement, work distribution involves summarising employee
time utilisation for the tasks. Work distribution requires detailed information
about the functions and responsibilities of all employees involved. It enables
evaluation of task assignments, for instance to determine whether tasks are
assigned rationally, while taking into consideration employees qualifications
and expertise, internal controls and timing of events. More formal techniques,
such as mathematical programming, further facilitate the evaluation of task
assignments.
3.4.3
Flowcharts and Other Graphics
Flowcharts and other graphics documents, systems and programme flowcharts,

data flow diagrams, entity relationship diagrams and decision flows depict
flows and relationships in processes and procedures. Flowcharts enable
evaluation of various requirements of business processes and their
interrelationships. For instance, a systems flowchart specifies the input and
output devices data terminal, printer, storage devices such as magnetic tape or
disk related to a process. On the other hand, the data flow diagram
demonstrates similar elements related to a process, but leaves the exact physical
descriptions open, which enables systems analysts to separate out problems
associated with data flow versus physical implementation.
CASE tools offer powerful modelling features. Systems analysts can model factfinding results into flowcharts and other graphics. By studying the flowcharts,
they are able to determine whether additional fact-finding is required.
70
TOPIC 3
SYSTEMS ANALYSIS
Unified Modelling Language (UML) is a method of visualising and documenting

systems designs. When modelling system requirements, systems analysts can
utilise UML to represent information systems from a users view point. UML
provides graphical tools such as case diagrams which can be used to visually
represent the interaction between users and the information systems. Users, who
are in the position of actors, interact with a case (e.g., credit card validation). As
the case (e.g., credit card validation) is depicted through the eyes of the user
(actor), the user is able to describe the transaction (e.g., credit card validation) in
common business language, which will inadvertently assist systems analysts in
system requirements modelling.
3.4.4
Decision Analysis
Decision analysis involves summarising the decisions and required information

inputs. Branching and decision tables are primarily used in decision analysis in
systems development.
(a)
Branching Table
Branching tables can be used to depict a decision function. It is composed
of a statement of the decision to be made, a list of conditions that can occur
and the path to be followed for each condition.
(b)
Decision Table
Decision tables tabulate decision-making processes. It is similar to a
branching table except that the decision table incorporates multiple
decision criteria. Decision tables are constructed on an IF_THEN premise,
which depicts a condition-action relationship for a given decision.
Figure 3.3 provides an example of a decision table of a labour distribution

system. The conditions are at the top-half of the table. Y (i.e., yes) indicates
presence of a condition, N (i.e., no) indicates absence, and " indicates nonapplicability. The actions are at the bottom-half of the table. x indicates the
relevant actions for a given set of conditions.
TOPIC 3
SYSTEMS ANALYSIS
71
Figure 3.3: A Decision Table

3.4.5
Narratives
Narratives are written summarisations. Narratives are useful in documenting the

systems development teams preliminary findings and understanding at the
early stages of fact-gathering and analysis. It serves as a basis for the team to
decide the subsequent choice of techniques to gather and analyse more
information. Narratives become wordy and difficult to follow as the team gains a
more complete and thorough understanding of the systems. This is when other
techniques work measurement, work distribution, flowcharting and decision
analysis are used instead in the task of documenting and analysing findings.
72
TOPIC 3
SYSTEMS ANALYSIS
SELF-CHECK 3.5
How does each technique for organising facts assist systems analysis?
In other words, what are the purposes and functions of each technique?
Complete the table below based on your understanding of the
techniques.
Techniques
1.
Work measurement
2.
Work distribution
3.
Flowcharts and other

graphics
4.
Decision analysis
5.
Narratives
3.5
Purposes/Functions
Accountants can contribute to systems analysis in a number of ways, as follows:

(a)
As systems specialist or consultant, accountants can be a member of the

systems development team in conducting a survey to understand the
current systems, identify information needs, specify system requirements
and prepare the analysis report;
TOPIC 3
SYSTEMS ANALYSIS
73
(b)
As a staff accountant, who is in the position of the user and/or requester of

new systems, accountants can cooperate with the systems development
team to enable the team to understand the current systems and the
systems weaknesses and/or problems; and
(c)
As an internal auditor knowledgeable about the systems and control

problems and control requirements for the new systems, accountants can
advise the systems development team and ensure that the team follows
appropriate procedures for efficient and effective systems development.
Systems analysis provides an in-depth understanding of the current

information systems and its associated problems, which assist in specifying
requirements for the proposed, new systems.
For a complete understanding of the current systems and new system

requirements, systems analysis should encompass surveying the current
systems, identifying information needs, identifying system requirements
and preparing a systems analysis report.
A variety of techniques, each with its respective purposes and functions,

assist in gathering, documenting, organising and analysing information
throughout the systems analysis process.
Agile methods
Output requirements
Bottlenecks
Performance requirements
Control requirements
Process requirements
Decision analysis
Questionnaire
Flowchart
Rapid application development (RAD)
Input requirements
Systems analysis report
Interview
System requirements
Joint application development (JAD)
Task participation
Narratives
Work measurement
Observation
Work distribution
74
TOPIC 3
SYSTEMS ANALYSIS

Mirror Books.
Prentice Hall.
Topic Systems Design
Evaluations
and Choices
LEARNING OUTCOMES
1.
Explain the major steps in systems design evaluations and choices;
2.
Describe the two major analysis conducted in systems design

evaluations and choices;
3.
Discuss the major options for a chosen systems design to enter the
construct phase of systems development; and
4.
Identify the advantages and disadvantages of each option for a

chosen systems design that is to be constructed.
INTRODUCTION
Manchester, 7 February 2013 Windmill Software is delighted to launch
their Enhanced Windmill software suite. Enhanced Windmill includes
human machine interface software, data logging, charting, output control,
programming tools, alarm monitoring and drivers for environmental
monitoring instruments communicating over Ethernet, Internet, USB, Modbus,
RS232, RS422, RS485 and TCP/IP.
Enhanced Windmill runs under Windows 8 and earlier versions of Windows.
The package is available for just 295 and the company offers free technical
support for life.
(Source: Environmental-expert.com, 7 February 2013)
76
TOPIC 4
SYSTEMS DESIGN EVALUATIONS AND CHOICES
Every new product or upgrade launched boasts of being better than existing or
earlier versions of the product. How do you decide whether a new product or
upgrade is suitable for you and/or your business, organisational needs? This
topic covers how to shop for such a product.
This topic covers the choices that you have in putting a new, proposed system in
place. First, we will identify how to select an appropriate systems design based
on the system requirements identified in the systems analysis phase discussed in
Topic 3. There are various options in constructing a chosen systems design and
we will look at some of the major options available to us in-house development,
acquisition of commercial software packages, outsourcing or any combination
thereof. Each option has its respective pros and cons. Finally, we will discuss
how accountants can contribute towards systems design evaluations and
decisions.
4.1
ALTERNATIVE SYSTEMS DESIGNS
To avoid imposing preconceived constraints on the new, proposed systems,

several alternative conceptual designs that satisfy the system requirements
identified during the systems analysis phase are produced. These alternative
designs enter the selection stage, where each is evaluated in terms of costs and
benefits, after which an optimum design is chosen for construction.
Alternative designs should highlight the differences between critical features of
competing systems to facilitate selection. The designs should identify all inputs,
outputs, processes and other necessary distinguishing features. Use of data flow
diagrams (DFDs), which omit physical descriptions, is useful for comparison
across alternatives. In certain circumstances, use of context diagrams is sufficient.
When distinguishing features between alternative designs are subtle, use of lowerlevel data flow diagrams is required.
TOPIC 4
77
Figure 4.1 illustrates two alternative designs for a purchasing system. Physical
features such as database record structures, processing details, control techniques,
format of input screens, source documents and output report formats are
excluded. Briefly, option A is a batch purchasing system. Purchase requisition
from inventory control is the input to the purchase process. Purchase orders are
transmitted daily by mail to the suppliers. By contrast, option B is an online
purchasing system using electronic data interchange (EDI) technology. Purchase
requisition from production planning is the input. Purchase order is transmitted
online to the suppliers.
Figure 4.1: Two alternative systems designs for a purchase system

Source: Hall (2013)
78
4.2
TOPIC 4
EVALUATION AND SELECTION

ACTIVITY 4.1
If you are required to evaluate the two alternative systems designs for a
purchase system as illustrated in Figure 4.1, what are the steps that you
will take in doing so? Write down these steps.
Though there is no hard-and-fast rule in the evaluation and selection of systems

designs, typically two steps are involved, a detailed feasibility study and costbenefit analysis. Results of the evaluation and selection as well as the choice of
systems design are reported formally to the steering committee for approval.
4.2.1
Step 1: Detailed Feasibility Study
A project feasibility study is conducted at the planning phase of systems

development, as discussed in Topic 2. The purpose of conducting a project
feasibility study at the planning phase is to determine whether a proposed
systems project is likely to succeed. Once a proposed project is deemed likely to
succeed and allowed to proceed, a detailed feasibility study is conducted to
determine how the proposed project should proceed.
Once alternative designs to the proposed project are specified, systems designers
will have a better picture of the most appropriate way for the proposed project to
proceed, i.e. what is good and bad about each alternative design. A detailed
feasibility study is then conducted to evaluate each alternative design. Besides
using the feasibility study as a framework, various expertise and opinions for
instance from systems analysts and designers, users, management and auditors
are required for a detailed feasibility study. Similarly, TELOS guides project
feasibility assessment as detailed in Topic 2 and can be used in determining the
feasibility of systems designs as well (Hall, 2013):
(a)
Technical Feasibility
Use of familiar, well-established technology is less risky and thus more
technically feasible. Newly released, unfamiliar technology that is a hybrid
of several vendors products presents more risks and is thus less technically
feasible for systems professionals to install and maintain.
TOPIC 4
79
(b)
Legal Feasibility
Legality has often been an issue for information systems that process
sensitive data such as customers credit card information, hospital patient
records and personal credit ratings. It is important to ensure the systems
designs accommodate for critical controls, security and audit trail issues
and that the designs do not violate laws pertaining to rights of privacy
and/or use and distribution of information.
(c)
Operational Feasibility
An alternative systems design that enables users to feel comfortable and
motivated to migrate to the new systems is more operationally feasible.
Operational feasibility is a reflection of ease of transition to the new
systems. Users who are well-trained, experienced with technology and
receptive of new technology and procedures make the new systems more
operationally feasible. On the other hand, users who require extensive
training with the migration to a more highly technical environment
enhance risks and lower operational feasibility.
(d)
Schedule Feasibility
Schedule feasibility is the likelihood of the new systems to be completed
on schedule. The systems design, existing technology platform and need
of user training all contribute towards schedule feasibility. Use of
systems development technology, such as use of computer-aided software
engineering (CASE) and prototyping, helps to enhance schedule feasibility.
(e)
Economic Feasibility
Economic feasibility at the planning phase evaluates costs and benefits
of the systems project in a general manner. With specific features and
processes laid out in alternative systems designs, costs and benefits analysis
for each design can be conducted in a more precise manner.
80
TOPIC 4
SELF-CHECK 4.1
Compare and evaluate the batch versus online, EDI-based purchase
system as illustrated in Figure 4.1 in terms of the five feasibility aspects.
Based on your understanding, identify which design alternative is more
feasible. Justify your answer.
Complete the following table once your analysis is done.
Batch Versus Online, EDI-based Purchase System:
Which one is more feasible and why?
Technical feasibility
Legal feasibility
Operational feasibility
Schedule feasibility
Economic feasibility
TOPIC 4
4.2.2
81
Step 2: Cost-benefit Analysis
The primary objectives of cost-benefit analysis are to determine whether and to

what extent benefits from a proposed system outweigh its costs. Systems projects
are evaluated just like any other capital projects, where expected return on
investment is determined. Unlike typical capital projects however, costs and
benefits of systems projects are not as readily quantifiable. However, when
applied in conjunction with the feasibility study, cost-benefit analysis is useful in
evaluating competing systems designs.
Cost-benefit analysis consists of three-steps, which are: identify costs, identify
benefits and compare costs and benefits (Hall, 2013).
(a)
Step 1: Identify Costs

There are two major categories of costs, one-time costs and recurring costs.
(i)
One-time costs are initial investments incurred only once to develop

and maintain the proposed systems project. Common one-time costs
are as follows:
Hardware acquisition costs include costs of mainframe servers,

computers and peripheral equipment such as networks and disks.
Vendors can provide an estimation of such costs;
Site preparation costs include costs of installation of additional airconditioning and other building modification work, equipment
installations and freight charges. Vendors and subcontractors can
provide an estimation of such costs;
Software acquisition costs are the purchase price of software for

the proposed systems, if such costs are not bundled with hardware,
such as operating system software, network control software and
commercial applications such as accounting packages. Vendors
can provide an estimation of such costs;
Systems design costs are costs incurred during systems planning,

analysis and design. While costs incurred up to the point of
systems design are sunk costs, it is important to estimate costs
required to complete the detailed systems design;
82
(ii)
TOPIC 4
Programming and testing costs are based on estimates of

personnel hours that are required to write new programmes,
modify existing programmes for the proposed systems and to
bring together individual programmes for testing as an entire
system. Past experiences serve as a basis to estimate these costs;
Data conversion costs are incurred when data from one storage
medium or structure is transferred to another. The number and
size of the files serve as a basis to estimate these costs; and
Training costs involve educating users to operate the new systems.

Costs of formal training that certain organisations provide can
be easily obtained. Costs of in-house training include instruction
time, training facilities and lost productivity.
Recurring costs include operating and maintenance costs incurred

throughout the lifespan of the information systems. Common recurring
costs are:
Hardware maintenance costs include costs of upgrading the

computer (e.g., increasing the memory) and costs of preventive
maintenance and repairs to the computer and peripheral
equipment. There are vendors who offer maintenance contracts
and thus can provide an estimation of these costs;
Software maintenance costs include costs of upgrading and

debugging operating systems, purchase of applications and
in-house developed applications. Software vendors, who offer
maintenance contracts, can provide an estimate of these costs.
Historical data provides an estimate of in-house maintenance costs;
Insurance costs are incurred to protect informational systems

against hazards and disasters such as fire, hardware failure,
vandalism and destructions, both intentional and unintentional;
Supplies costs are incurred through routine consumption of

supplies like printer cartridges and paper, magnetic disks,
magnetic tapes and other general office supplies; and
Personnel costs refer to salaries of individuals involved with the

information systems, for example operational personnel exclusively
employed as part of the systems under analysis, database
administrators and computer room personnel. The expected levels
of involvement of personnel with the systems serve as a basis to
estimate these costs.
TOPIC 4
(b)
(c)
83
Step 2: Identify Benefits

Benefits can be tangible as well as intangible:
(i)
Tangible benefits can be expressed and measured in monetary terms.

It comes in two forms, benefits that increase revenue and benefits that
reduce costs. Increase in sales due to better customer service is an
example of a tangible benefit that increases revenue. Reduction in
inventory carrying costs is an example of a tangible benefit that
reduces costs. You need to be careful to ensure that only escapable
costs are included when measuring cost reductions. Escapable costs
are costs that cease to exist when the system ceases and are directly
related to the system; and
(ii)
Intangible benefits cannot be readily measured and quantified.

Increased customer satisfaction is an example of an intangible benefit.
Though greater customer satisfaction can be translated into increased
sales, the specific increase in sales value is highly subjective. Systems
professionals have attempted to quantify intangible benefits in
monetary terms, through the use of customer surveys, statistical
analysis, expected value techniques and simulation models. However,
a substantial degree of judgement is still involved in the quantification
process.
Step 3: Compare Costs and Benefits

The costs and benefits identified in the first two steps should be compared
to get a better idea of the relationship between the two. Common methods
in comparing costs and benefits are net present value and the payback
method (Hall, 2013):
(i)
Net Present Value Method

Present value of costs is compared with the present value of benefits
over the life of the systems. A positive net present value (benefits are
greater than costs) indicates an economically feasible systems project.
When all benefits and costs are tangible and quantifiable, the
alternative design with the highest positive net present value is
deemed to be most economically feasible. However, intangible
benefits and costs need to be taken into consideration regardless of
whether they are quantifiable or not.
84
(ii)
TOPIC 4
Payback Method
The payback method determines when a systems project will breakeven, which occurs when total costs equal total benefits. Figure 4.2
illustrates the payback method. The present value of total costs curve
consists of one-time costs and recurring costs over the life of the
project. The present value of total benefits curve includes tangible,
quantifiable benefits over the life of the project. The intersection of the
two curves indicates the number of years into the future where the
project breaks-even. The shaded area represents the present value of
future profits of the project.
Figure 4.2: Discounted payback method of cost-benefit analysis

Source: Hall (2013)
TOPIC 4
85
The payback method is useful in light of rapid advances in technology,

where effective lifespan of information systems tend to be short. Ensuring
that a systems project pays back prior to the end of its effective life should
take precedence over other intangible benefits.
SELF-CHECK 4.2
Provide examples of one-time and recurring costs, as well as tangible
and intangible benefits for a batch versus online, EDI-based purchase
system as illustrated in Figure 4.1.
Complete the table below.
Purchase System
Batch
Online, EDI-based
One-time costs
Recurring costs
Tangible benefits
Intangible benefits
86
4.2.3
TOPIC 4
Step 3: Systems Selection Report
A systems selection report documents findings of the feasibility study, costbenefit analysis and intangible costs and benefits of each alternative design.
Based on the report, the steering committee will select a systems design that will
enter the construct phase of the systems development life cycle.
In the construct phase, the chosen systems design may require in-house
development, acquisition of commercial software packages, or both depending
on the needs of the design. Figure 4.3 illustrates the development options of
information systems.
Figure 4.3: Development options

Source: Shelly and Rosenblatt (2010)
Another option is to outsource the information systems, which includes hiring an

outside organisation to develop, operate and maintain the information systems.
Each option is discussed in the sections that follow.
4.3
IN-HOUSE DEVELOPMENT
In-house development is required when design requirements are unique, or

design complexity necessitates a custom package. Developing custom software
can be challenging, error-prone and consume a great deal of time and resources.
Among the common difficulties experienced with in-house development are lack
of time, complexity of the desired system, poor requirements and systems
planning, inadequate communication and cooperation between affected
departments and users, lack of qualified staff and poor support from top
management. It is important to maintain control over the in-house development
process. Among the recommended guidelines to maintain control over this form
of development are (Romney & Steinbart, 2009):
TOPIC 4
87
(a)
Careful Selection of a Developer

The developer selected, especially if it is an outside developer, must be
familiar with the organisations industry and has an in-depth understanding
of how the organisation conducts its business in general.
(b)
Contractual Agreement with the Developer

The organisation should sign a contractual agreement with the developer.
The contract should emphasise the developers responsibilities in meeting
the organisations requirements and should allow the organisation to
terminate the project if key conditions are not met.
(c)
Planning and Monitoring of Each Step

The project should be designed in detail with milestones and checkpoints
indicated clearly for monitoring purposes.
(d)
Maintenance of Effective Communication

The relationship between the organisation and the developer should be
clearly defined. Frequent communication with the developer is necessary.
(e)
Control of Costs
All costs should be controlled and outflows of cash should be minimised
until the project is completed and accepted.
4.3.1
Reasons for In-house Development
In light of the difficulties associated with in-house development, systems

professionals tend to recommend that only custom software that bring significant
competitive advantages to the organisation should be developed in-house.
Nevertheless, whether custom software brings significant competitive
advantages is open to subjective judgement. The following are general guidelines
that assist in determining whether in-house development is appropriate for
individual organisations (Shelly & Rosenblatt, 2010):
(a)
Satisfying Unique Business Requirements

In-house development is appropriate when no commercially available
software package can meet unique business requirements. For instance, a
university requires a course scheduling system based on curriculum
requirements, student demand, classroom space and available instructors.
If commercially available software packages cannot handle such
requirements, in-house development is the only option available to the
university.
88
TOPIC 4
(b)
Minimising Changes in Business Procedures and Policies

Installation of new software packages often requires a certain degree of
changes and adjustments in how an organisation conducts its business
operations. If such changes and adjustments are too disruptive to current
business operations and processes, in-house development is more
appropriate.
(c)
Meeting Constraints of Existing Systems

New software installed must be able to operate together with existing
systems and databases. If finding commercially available software (e.g.,
new budgeting system) that works together with existing systems (e.g.,
existing accounting information systems) proves too difficult, in-house
development is appropriate.
(d)
Meeting Constraints of Existing Technology

New systems must be able to operate with existing hardware and legacy
systems. Some organisations have older microcomputers that cannot
handle graphic-intensive software or high-speed Internet access. If technical
feasibility suggests that the organisation should maintain rather than
upgrade existing hardware and legacy system, in-house development is
appropriate if no commercially available software packages can operate in
the existing hardware and legacy system environment.
(e)
Developing Internal Resources and Capabilities

In-house development also promotes training and development of an
organisations IT team. The in-house development process enables the IT
team to familiarise themselves with the organisations business functions
and information support needs. In-house IT resources and capabilities can
constitute a competitive advantage; in-house IT team is in a better position
to respond to business opportunities and threats and provide guidance and
long-term stability.
4.3.2
End-user Computing (EUC)
Sometimes, business requirements do not require a formal information system or

commercial software package to fulfil. End-user computing (EUC) refers to users
meeting their own information needs, via hands-on development which gives
them use and control of information systems. The advent of powerful and
inexpensive software allows users to develop their own systems to create, store,
TOPIC 4
89
access, download and share data and computer resources in networks. There are
two major benefits in allowing users to meet their own needs. First, users get to
know how computers can be used to meet their own information needs. Second,
users hands-on experience with meeting their own needs create new uses and
needs for information.
Systems professionals continue to develop and maintain the information systems
and databases that end users draw on to meet their information needs. Systems
professionals also provide technical advice, operational support and make as
much information available for end-users as possible.
4.3.3
End-user Development (EUD)
End-user development (EUD) refers to users managers, accountants and

internal auditors developing their own applications, also known as user
applications, with the advice of computer specialists. EUD offers a simple, lowcost solution. Microsoft offers software suites and integrated applications that
can exchange data with programmes that include tutorials, wizards and Help
features useful to less-experienced users. Empowering users to develop their
own applications requires providing users with the technical support, such as
setting up a helpdesk, information centre and hotline assistance within the IT
department, responsible for providing user support.
EUD is inappropriate for complex applications that process huge volumes of
transactions or update database records, such as payroll processing, accounts
payables and receivables, general ledger and inventory. Examples of applications
where EUD is appropriate are (Romney & Steinbart, 2009):
(a)
Information retrieval from organisational databases to produce simple

reports or answer one-time queries;
(b)
What-if, sensitivity and statistical analyses;
(c)
Development of applications using pre-written software, such as a

spreadsheet or a database system; and
(d)
Preparation of schedules and lists, such as depreciation schedules, accounts

receivable aging and loan amortisations.
90
TOPIC 4
SELF-CHECK 4.3
1.
When is in-house development most appropriate for a chosen

systems design?
2.
What are the advantages and disadvantages of in-house

development?
4.4
CUSTOMISING SOFTWARE PACKAGES
Organisations can customise commercially available software packages to suit

the requirements and needs of the organisation. There are three ways to
customise a software package (Shelly & Rosenblatt, 2010):
(a)
There are vendors who offer basic packages in a standard version with
add-on components that are configured individually. There are also firms
which offer services in selecting and configuring basic packages. A human
resources information system is a typical example where each organisation
handles employee compensation differently and therefore requires
different add-on components;
(b)
Organisations can negotiate with the software vendors to make

enhancements that meet their fee requirements; and
(c)
The acquired software package can be modified as long as such

modifications are permissible under the terms and conditions of the
software license. Systems analysts and programmers typically require time
to familiarise themselves with the software to ensure correct modifications.
The benefits of acquiring commercially available software packages are typically

lost when the software is customised. Modified software typically costs more, if
vendors are doing the customisation and takes a longer time to obtain. New,
improved versions of the software have to be upgraded as well, when the new
versions are released.
TOPIC 4
4.5
91
ACQUISITION OF COMMERCIAL PACKAGES
While certain organisations will opt for the in-house development approach of
their information systems, there are others that prefer acquiring commercial
packages instead.
4.5.1
Reasons for Acquiring Commercial Software

Packages
Acquisition of commercial software packages can prove to be an attractive option

due to the following reasons (Shelly & Rosenblatt, 2010):
(a)
Lower Costs
Software vendors spread the software development costs over several
customers, which makes acquisition of commercially available software
packages cheaper. In-house development of software requires expensive
initial investment.
(b)
Less Time to Implement

Commercial software packages have already been designed, programmed,
tested and documented; time spent on such tasks is unavoidable when
software is developed in-house. Only installation and integration of the
software packages into existing systems environment takes time.
(c)
Proven Reliability and Performance Benchmarks

Any major problems associated with commercially available software
packages that have been on the market for a length of time have already
been detected and corrected. Ratings and evaluations of independent
reviewers of popular software packages facilitate making software
acquisition decisions.
(d)
Less Technical Development Staff

Acquisition of commercially available software packages enables the
organisations IT team to focus on systems with requirements that cannot
be satisfied by such software packages. The number of programmers and
systems analysts in the IT team can also be reduced.
92
TOPIC 4
(e)
Vendors Provide Future Upgrades

Software vendors regularly receive input and suggestions from existing
users in upgrading and adding enhancements to create new, improved
versions of the software packages.
(f)
Obtain Input from Other Organisations

Organisations can contact users of other organisations for opinions and
suggestions about commercially available software packages. They can also
request for a trial version of the software packages or make a site visit to
observe the systems in operation prior to making an acquisition decision.
The following are typical steps and issues considered when acquiring
commercial packages (Shelly & Rosenblatt, 2010).
4.5.2
Step 1: Evaluate Requirements of Information

Systems
During the analysis phase as discussed in Topic 3, information system

requirements have been specified. Based on the list of information system
requirements, now the features, network and web-related issues, estimates of
volume and future growth, specifications on hardware, software, or personnel
constraints must be elaborated on further and a request proposal or quotation
should be prepared.
(a)
Key Features
A list of critical features should first be developed based on the list of
system requirements that can serve as an overall guide for the proposed
systems project.
(b)
Network and Web-related Issues

Whether or not the proposed systems will run on a network, Internet, or a
company intranet must be decided on and the list of critical features should
be modified accordingly. Organisations must also determine whether the
proposed systems will be able to exchange data with vendor or customer
systems and ensure that the proposed systems will be compatible with
their systems to be able to do so.
(c)
Volume and Future Growth

The list of key features should be assessed against current volume of
transactions and forecasted future growth. The hardware and software
platform must be able to cope with current and future transaction volumes
and data storage requirements.
TOPIC 4
93
(d)
Hardware, Software or Personnel Constraints

Existing hardware, software and personnel issues must be evaluated to
determine if it will affect the organisations acquisition decisions, e.g.,
whether there is a large number of legacy systems and the human resource
requirements to develop, acquire, implement and maintain the systems.
(e)
Request for Proposal or Quotation

Either a request for proposal or request for quotation will need to be
prepared. Both documents are used to obtain vendors replies in a clear,
comparable and systematic manner to enable informed selection decisions.
(i)
A request for proposal is for the vendors to decide whether they have
the products and/or services that meet the organisations needs. The
request for proposal should describe the organisation, list the IT
products and services required and specify the essential as well as
desired features; and
(ii)
A request for quotation is more specific. The organisation already

knows the specific products and/or services it wants. All is needed
is to obtain the price quotations and leasing options including
maintenance or technical support terms.
4.5.3
Step 2: Identify Potential Vendors or

Outsourcing Options
There are a few avenues to identify potential vendors or outsourcing providers.

There are descriptive information on the Internet. Internet bulletin board systems
also contain forums and newsgroups that cover the products and services
relevant to the organisations needs. Visiting websites of specific companies, such
as that of Microsoft, technical chat rooms and webcasts should also be done.
Applications for specific industries can be found in research as well as trade
journals, blogs and/or reviews for industry-specific software. Consulting firms
also provide specialised services in software selection for a fee. Consultants
expertise in software selection can minimise mistakes.
Evaluating potential vendors is an important step in acquiring commercial
software. This can be done before making a decision on acquisition with the
following checklist of questions (Romney & Steinbart, 2009):
(a)
How long has the vendor been in business?
(b)
Is the vendor financially stable and secure?
94
TOPIC 4
(c)
How much experience does the vendor have with the hardware and
software in question?
(d)
How well does the vendor stand behind his/her products? How good is
the guarantee?
(e)
Does the vendor regularly update his/her products?
(f)
Does the vendor provide financing?
(g)
Will the vendor put promises in a contract?
(h)
Will the vendor provide customer references?
(i)
Does the vendor have a reputation for reliability and dependability?
(j)
Does the vendor

maintenance?
(k)
Does the vendor provide implementation and installation support?
(l)
Does the vendor have high-quality, responsive and experienced personnel?
provide
hardware
and
software
support
and
(m) Does the vendor provide training?

(n)
How responsive and timely is vendor support?
4.5.4
Step 3: Evaluate Alternatives
Based on either the organisations request for proposal or request for quotation,
vendors will respond with a list of alternative products and/or services, leasing
options, maintenance or technical support terms, etc. Evaluation of the
alternatives presented from as many sources of information as possible should be
done to ensure the best option is chosen in the end. The following guidelines will
help in the process of evaluation:
(a)
Existing Users
Contact existing users to learn about their experiences. Large-scale software
packages like ASP supply user references, but such user references can be
biased and lean more towards the positive.
(b)
Application Testing
Application testing can range from using a demonstration copy to enter a
few sample transactions, to getting a team of IT personnel and users to
perform tests for several weeks.
TOPIC 4
(c)
95
Benchmarking
The time a package takes to process a number of transactions can be
measured to determine whether the package can handle a certain volume
of transactions efficiently. Benchmarking is useful in comparing the
performance of two or more competing products in a standard environment.
Benchmark tests and surveys of software packages are also often published
in IT publications and can serve as reference during evaluation.
4.5.5
Step 4: Perform Cost-benefit Analysis
A cost-benefit analysis should be performed to assess each of the software

presented by the various vendors. The costs must be identified and compared
one-time and recurring costs, with benefits tangible and intangible. When
acquiring software, essentially the organisation is buying a software license that
gives them the right to use the software under certain terms and conditions.
Caution has to be given to license restrictions however. For instance, does the
license allow the organisation to use the software on a single computer, a
specified number of computers, a network or an entire site? For large-scale
systems, one can often negotiate the licenses terms and restrictions to ensure that
it fits with organisational needs.
4.5.6
Step 5: Prepare a Recommendation
Recommendation of which alternative is most appropriate based on the costs,

benefits, advantages and disadvantages in comparison with those of other
alternatives must be prepared. The recommendation can be presented in writing
as well as orally. Depending on the size and/or complexity of the systems
project, the steering committee and/or top managements approval of the
recommendation may be required.
4.6
OUTSOURCING
Outsourcing transfers information systems development, operation, or

maintenance to an outside organisation for a fee. It can be done on a temporary
as well as long-term basis. They are many ways to outsource: For instance,
outsourcing minor programming tasks, renting software from a service provider,
outsourcing basic business processes or outsourcing handling of the organisations
entire IT function. All these methods however have their respective benefits and
risks, which must be carefully considered before deciding to outsource.
96
TOPIC 4
4.6.1 Benefits of Outsourcing

The benefits of outsourcing are as follows (Romney & Steinbart, 2009):
(a)
Business Solution
Outsourcing is a viable business solution as it allows organisations to
instead concentrate on their core competencies. There is however a need
to work closely with outsourcers to meet organisational strategic and
operational data processing objectives.
(b)
Asset Utilisation
Outsourcing prevents organisational resources from getting tied up in
hardware, software and other IT infrastructures. Organisations are instead
able to concentrate organisational resources on revenue-generating
activities and processes.
(c)
Access to Greater Expertise and More Advanced Technology

Outsourcing minimises costs of retaining experts to manage, develop,
maintain and upgrade increasingly complex computer systems and
networks.
(d)
Lower Costs
Skilled overseas providers for example Chinese companies, can perform the
needed work at lower labour rates. Outsourcers can pass on some of their
cost savings achieved via economies of scale, for example by standardising
user applications, buying hardware at bulk prices, splitting development
and maintenance costs between projects and by operating at higher volumes.
(e)
Improved Development Time

Outsourcers who become experienced industry specialists can often
develop and implement a proposed systems project more efficiently and
effectively than in-house development IT teams.
(f)
Elimination of Peaks-and-valleys Usage

Organisations often experience seasonal fluctuation in computer and
information processing needs. IT personnel and other IT resources become
overused or underused depending on seasonal fluctuation of such needs.
Outsourcing minimises problems associated with overuse and underuse of
IT resources.
(g)
Facilitation of Downsizing
Outsourcing enables elimination of unnecessary IT functions and facilitates
downsizing.
TOPIC 4
4.6.2
97
Risks of Outsourcing
Organisations that outsource are not without their problems which include
(Romney & Steinbart, 2009):
(a)
Inflexibility
Organisations risk getting tied-up in long-term outsourcing contracts,
for example one that lasts for 10 years. If organisations are dissatisfied,
outsourcing contracts are often difficult or costly to break.
(b)
Loss of Control
Organisations risk losing control of their information systems and data,
especially when confidential data is being shared with others.
(c)
Reduced Competitive Advantage

Organisations risk losing a fundamental understanding of the needs
of their information systems and how the systems can provide the
organisations with competitive advantages.
(d)
Locked-in System
Once organisations have outsourced, such decisions are not readily
reversible. It is difficult and costly for organisations to bring back its
information systems in-house. Organisations often need to set up new
infrastructure, recruit experts, etc.
(e)
Unfulfilled Goals
There are organisations who fail to realise the goals and benefits of
outsourcing, such as cost savings.
(f)
Poor Services
Outsourcers may not be responsive to organisations changing business
conditions and needs.
(g)
Increased Risks
Organisations are exposed to various sources of risks, including
operational, financial, technology, strategy, market position, human capital,
legal, regulatory and reputation impairment risks.
98
TOPIC 4
SELF-CHECK 4.4
1.
What are the benefits of acquiring commercial software packages?

What are the circumstances that can result in the failure to realise
such benefits of acquiring software packages?
2.
What are the benefits and risks of outsourcing?
4.7
Accountants can contribute towards systems design evaluations and choices in a

number of ways:
(a)
As a systems specialist or consultant, accountants can assist in translating

system requirements into essential as well as desired physical features of
the proposed systems to be constructed;
(b)
As a staff accountant, accountants can provide assistance in evaluating

alternative systems designs, especially in the preparation and analysis of
cost and benefit reports for the feasibility assessment of each design; and
(c)
As an internal or independent auditor, knowledgeable about information

systems and appropriate controls, accountants can determine the presence
and absence of key control features when evaluating each alternative
systems design.
Systems design evaluations and choices involve a detailed feasibility study

and cost-benefit analysis.
A choice has to be made regarding how a selected systems design should be

constructed, either via in-house development, acquisition of commercial
software packages, outsourcing or any combination thereof.
In-house development is appropriate when design requirements are unique

to suit business and organisational needs, but can be time-consuming and
costly.
TOPIC 4
99
Acquisition of commercial software packages resolves various challenges

associated with in-house development, but commercially available packages
may not be aligned with business and organisational needs.
Outsourcing enables organisations to capitalise on outsourcers expertise and

economies of scale, but outsourcing agreements are inflexible and cannot be
readily aligned with changing business and organisational needs.
Cost-benefit analysis
Intangible benefits
Customising software
One-time costs
Detailed feasibility study
Outsourcing
End-user computing
Recurring costs
End-user development
Software acquisition
In-house development
Tangible benefits

Mirror Books.
100 TOPIC 4 SYSTEMS DESIGN EVALUATIONS AND CHOICES

Prentice Hall.
Topic Systems Design
LEARNING OUTCOMES
1.
Explain the importance of systems design development;
2.
Describe conceptual systems design and its key elements;
3.
Discuss physical systems design and its key design phases; and
4.
Identify key design considerations that affect design choices.
INTRODUCTION
Take a look at Figure 5.1. Do you agree with it? Is a systems design equivalent to
an architectural design? An architectural design of a house is a blueprint that is
useful to electricians, plumbers and carpenters. If plumbing is omitted from the
design, walls and floors of the completed house will have to be ripped out to
retrofit the omitted plumbing later on. Similarly, a systems design is a blueprint
of an information system that is useful to accountants, internal auditors,
programmers and management. Similar problems will occur to an information
system developed based on a design with mistakes and omissions of key
elements.
102 TOPIC 5 SYSTEMS DESIGN
Figure 5.1: Systems design and architectural design
This topic covers how to develop a systems design in a systematic manner to

minimise mistakes and omissions. First, we will discuss how to develop a
general, conceptual design. Next, we will discuss how to develop more specific,
physical designs. Finally, we will discuss how accountants can contribute in
systems design development.
TOPIC 5
5.1
SYSTEMS DESIGN
103
CONCEPTUAL SYSTEMS DESIGN

ACTIVITY 5.1
Can you think of how a systems design is developed? What do you

think are the steps and/or procedures that help to minimise mistakes
and omissions of important elements in systems design development?
You can use the Internet to help you with this research.
Systems design is equivalent to a blueprint for a completed information system.

Development of systems design begins from general, conceptual design
specifications and proceeds to specific, physical design specifications. General
functions and objectives of the information systems must first be identified, which
is often accomplished in the systems analysis phase. General functions and
objectives of the information systems are translated into conceptual design
specifications and subsequently, physical design specifications.
Topic 4 has discussed how to select an appropriate systems design based on a
detailed feasibility study and cost-benefit analysis. Once a systems design is
selected, the project team develops the conceptual design specifications for key
elements, such as output, data storage, input and processing procedures and
operations (Romney & Steinbart, 2009).
In theory, the project team should first develop primarily conceptual design
specifications, leaving out the physical descriptions to avoid constraining the
resultant physical system developed. However, in practice, having to specify
systems design purely in broad, conceptual terms can be challenging. For ease of
explication, physical design considerations are also included in conceptual design
specifications. The key elements that require development of specifications are
discussed as follows.
5.1.1
Output
As information systems are designed to meet user information needs, output

specifications should be prepared first. Among the options available for output
specifications are:
(a)
Output frequency How often to produce a report (instantaneously, hourly,

daily, weekly or monthly);
(b)
Output schedule Users can require a report at either predetermined times

or on demand;
(c)
Output format How the report should look like (narrative, table, graph,
80-column report, pre-printed form, etc);
(d)
Output content What the report should contain (sales volume, sales centre,
sales personnel ID among others);
(e)
Output medium Hardcopy, display screen, voice, CD, microfilm, etc; and
(f)
Printed output Pre-printed forms, turnaround documents or systemgenerated forms.
5.1.2
Data Storage
Output specifications determine the data storage specifications. Which data

elements are stored affect the kind of output produced. Among the options
available for data storage specifications are:
(a)
Data storage medium How data should be stored, either on tape, disk, hard
drive, CD or paper;
(b)
Data storage structure What type of file or database to use to store data,
either a centralised or decentralised database; and
(c)
File organisation and structure Random, sequential or indexed-sequential

access.
TOPIC 5
5.1.3
SYSTEMS DESIGN
105
Input
Output specifications also affect input specifications. Data elements captured affect
the data that are stored, which in turn determine the kind of output that can be
produced. Among the options available for input specifications are as follows:
(a)
Input medium Keying, optical character recognition (OCR), magnetic ink

character recognition (MICR), point-of-sales (POS) terminals, electronic data
interchange (EDI) or voice; and
(b)
Input format Source documents, turnaround documents, source data

automation or screen.
5.1.4
Processing Procedures and Operations
Specifications of processing procedures and operations determine data flow,

including how data is captured, stored and processed to produce the specified
output. Specifications of processing procedures and operations include:
(a)
Processing mode Manual, online, batch or real-time processing;
(b)
Processor Personal computer, server or mainframe;
(c)
Update frequency Instantaneously, hourly, daily, weekly or monthly;
(d)
Communication channels Telephone lines, coaxial cable, fibre optics,

microwave or satellite; and
(e)
Operations In-house or outsourcing.
5.1.5
Conceptual Systems Design Report
Once conceptual design specifications are developed, a conceptual systems design

report is prepared. The report is prepared:
(a)
To guide physical systems design;
(b)
To communicate how management and user information needs will be met;

and
(c)
To enable the steering committee to assess system feasibility.
The report primarily contains descriptions of one or few recommended systems

designs. Descriptions of systems designs often include the following information:
(a)
Contents of each output, database and input;
(b)
Processing flows and relationships among programmes, files, inputs and

outputs;
(c)
Hardware, software and resource requirements;
(d)
Audit, control and security processes and procedures; and
(e)
Assumptions and/or unresolved problems.
Table 5.1 provides an example of a table of contents of a conceptual systems design

report to provide an indication of the various areas that should be incorporated
into the report.
Table 5.1: An Example of a Table of Contents of a Conceptual Systems Design Report
I.
Executive Summary of Conceptual Systems Design
II.
Overview of Project Purpose and Summary of Findings to Date
III. Recommended Conceptual Design(s) of Proposed System

A.
Overview of Recommended Design(s)
B.
Objectives to be Achieved by Design(s)
C.
Impact of Design(s) on Information Systems and Organisation
D.
Expected Costs and Benefits of Design(s)
E.
Audit, Control and Security Processes and Procedures
F.
Hardware, Software and Other Resource Requirements
G.
Processing Flows: Relationships of Programmes, Databases, Inputs and Outputs
H.
Description of System Components (Programmes, Databases, Inputs and Outputs)
IV. Assumptions and Unresolved Problems

V.
Summary
VI. Appendices, Glossary
TOPIC 5
SYSTEMS DESIGN
107
SELF-CHECK 5.1
Try to develop general conceptual design specifications in terms of
output, data storage, input and processing procedures and operations
for a typical batch purchase system, i.e., purchase orders are placed on a
periodic, batch basis.
Complete the following table.
Conceptual Design Specifications for a Batch Purchase
System
Output
Data storage
Input
Processing
procedures and
operations
5.2
PHYSICAL SYSTEMS DESIGN
Physical systems design translates broad, user-oriented requirements of conceptual

design into detailed, physical specifications that can be used to programme and
test computer applications. The phases of physical design include designing
output, creating files and designing databases, designing input, writing computer
programmes, developing procedures and building controls into the new
information systems.
Figure 5.2 illustrates the physical design phases as well as the major design
considerations that affect design choices of system elements at each phase. Each
design phase is discussed in the remainder of this section.
Figure 5.2: Physical systems design phases, design considerations and design choices of
system elements
TOPIC 5
5.2.1
SYSTEMS DESIGN
109
Output Design
Output design determines the nature, format, content, timing of reports,

documents and screen displays. Systems designers need to cooperate with users
to tailor output design. Systems designers prepare output samples for users to
evaluate for completeness, relevance and usefulness. Unacceptable output is
modified and reviewed in an iterative manner until users sign a document stating
that the formats and contents of the output are acceptable.
The most important consideration for output design is cost effectiveness, which
involves maximising the benefits-to-costs ratio while satisfying objectives of
information systems. As illustrated in Figure 5.1, cost effectiveness is important in
every systems design phase. Besides cost effectiveness, reports should include
timely information that is relevant to a particular user and exclude irrelevant
information that result in excessive information costs. Clarity of the report is also
important to prevent users from misinterpreting and/or ignoring important
reports. Clarity can be achieved with the inclusion of appropriate titles and
captions within the reports (Bodnar & Hopwood, 2001).
The following checklist of questions together with important design considerations
such as cost effectiveness, relevance, clarity and timeliness, guide design choices of
output elements (Romney & Steinbart, 2009).
(a)
Users Who will use the output, why and when do they need it and what
decisions will they need to make?
(b)
Output medium Should output be in a hardcopy, on screen, in voice

response, email or some combination thereof?
(c)
Format What format can best convey the most information? Tables,
narratives or graphics?
(d)
Pre-printed Should hardcopy of the output be in a pre-printed form?

Should turnaround documents be used?
(e)
Location Where should output be sent to?
(f)
Access Who should have access to hardcopy and on-screen output?
(g)
Details Should lengthy output be accompanied by an executive summary

and a table of contents? Should headings and legends be used to organise
data and highlight important items? Should detailed information be
delegated to the appendices?
(h)
Frequency/Trigger How frequent should output be produced?

There are four categories of output (Romney & Steinbart, 2009):

(a)
Scheduled reports are prepared on a regular basis with pre-specified contents

and formats, such as monthly performance reports, weekly sales reports and
annual financial statements;
(b)
Special purpose analysis reports are ad-hoc reports with no pre-specified

contents and formats. These reports are prepared in response to ad-hoc
requests to evaluate an issue, such as which of the new products is the most
profitable;
(c)
Triggered exception reports are prepared in response to abnormal conditions

with pre-specified contents and formats. Examples of abnormal conditions
that trigger these reports are excessive absenteeism, cost overruns, inventory
shortages and other situations that require immediate corrective actions; and
(d)
Demand reports are prepared only on requests and have pre-specified

contents and formats. Demand reports are used in conjunction with triggered
exception reports to facilitate management decision-making. Figure 5.3
illustrates a users view when requesting for demand reports.
Figure 5.3: Users request for demand reports

Source: www.maverickracing.co.uk
TOPIC 5
5.2.2
SYSTEMS DESIGN
111
File and Database Design
In addition to cost effectiveness, integration is particularly important in file and

database design, to avoid collecting and maintaining the same set of data in more
than one location. Standardisation is also important, where all data are entered in a
standard format and assigned a common name to facilitate data-sharing. Data
should also be designed in a manner that is flexible so that users can structure a
variety of queries (Bodnar & Hopwood, 2001).
The following checklist of questions together with major design considerations
such as cost effectiveness, integrations, standardisation, flexibility, security,
accuracy, efficiency and organisation guide file and database design choices
(Romney & Steinbart, 2009).
(a)
Storage medium Should data be stored in hardcopies, hard-drives, disks,

CD or tape?
(b)
Processing mode Should manual, batch or real-time processing be used?
(c)
Maintenance What procedures are required for effective data maintenance?
(d)
File size How many records will be stored in the database and how large
will the records be? How fast is the quantity of records expected to grow?
(e)
Volume of use What is the percentage of records being added, deleted

and/or updated each year?
The following steps can serve as a guide for file and database design (Shelly &
Rosenblatt, 2010):
(a)
Create an initial entity-relationship diagram

(i)
Review data flow diagrams to identify system entities;
(ii)
Consider data stores on data flow diagrams to determine whether they

represent entities; and
(iii)
Analyse each relationship between entities to determine whether it is a

1:1, 1:M or M:M relationship.
Figure 5.4 illustrates an example of an initial entity-relationship diagram of a

video rental store.
Figure 5.4: Initial entity-relationship diagram using a video rental store as an example
(b)
Assign all data elements to entities

Identify and verify each data element in the data dictionary to an entity. At
the bottom of Figure 5.4, data elements for the entities identified in the initial
entity-relationship diagram are listed.
(c)
Generate the final entity-relationship diagram

(i)
Create third normal form (3NF) designs for all data tables;
(ii)
Include new entities when required; and
(iii)
Assign primary and foreign keys.
Figure 5.5 illustrates the final entity-relationship diagram for the video rental
store example. RENTAL has been identified as a new entity that connects
MEMBER and VIDEO tables. With the new entity, the M:M relationship
illustrated in Figure 5.4 becomes two 1:M relationships.
TOPIC 5
SYSTEMS DESIGN
113
Figure 5.5: Final entity-relationship diagram for the video rental store example
(d)
(e)
Verify all data dictionary entries

(i)
Ensure data dictionary entries for all data stores, records and data
elements are documented completely and correctly; and
(ii)
Documents in the data dictionary are made up of all codes developed

or identified during the data design process.
Transform the final entity-relationship diagram and normalised table design

into a database.
Figure 5.6 provides a screenshot of Microsoft Access, which depicts a relational

database design for a travel agency. Relational databases are flexible and powerful.
New entities and attributes can be added anytime without having to restructure
the entire database. New customers, new travel agents and airlines can be added
without affecting existing data and their relationships. Relational databases can
run on many platforms, such as on personal computers and in client-server
environments. Notice that the primary keys are shown in bold. Foreign keys are
indicated by the lines that connect the data tables. Notice the symbols used to
indicate one-to-many relationships, 1 and respectively.
Figure 5.6: An example of a relational database design
5.2.3
Input Design
When designing input, systems designers must identify the different types of data
input as well as optimal input methods. Accuracy is a challenging issue in input
design, as input should be designed in a manner to ensure accurate data entry
without omissions (Bodnar & Hopwood, 2001).
The following checklist of questions together with major design considerations
such as cost effectiveness, accuracy, uniformity and integrity, guide input design
choices (Romney & Steinbart, 2009).
(a)
Input medium Should data be entered using a keyboard, optical character

recognition (OCR), magnetic ink character recognition (MICR), point-of-sales
(POS) terminal, barcodes, radio frequency identification (RFID) tags,
electronic data interchange (EDI) or voice input?
TOPIC 5
SYSTEMS DESIGN
115
(b)
Source Where do data originate from - computers, customers or remote

locations? How do the origins of data affect data entry?
(c)
Format Which format efficiently captures data with the least effort and
cost, for example is it source or turnaround document, computer screen or
source data automation?
(d)
Type What is the nature of the data?
(e)
Volume of transactions How much data should be entered?
(f)
Personnel What are the data entry personnels abilities, expertise and
functions?
(g)
Frequency How often must data be entered?
(h)
Cost How to minimise costs without adversely affecting efficiency and

accuracy?
(i)
Error detection What are the possible errors that might occur? How can
errors be detected and corrected?
There are primarily two types of data input, forms and computer screens.
(a)
Designing Forms
The following checklist of questions can serve as a guide in designing forms
(Romney & Steinbart, 2009):
(i)
General issues
Are pre-printed data used to the maximum extent as is possible?
Are the weight and grade of the paper appropriate for the planned
use?
Are bold type, double-thick lines and shading appropriate to
highlight different parts of the form?
Is the form in a standard size?
Is the size of the form in line with requirements for filing, binding or
mailing?
Can the form be used for mailing to external parties where the
address can be positioned in a window envelope?
Are copies of the form being made in different colours to facilitate

proper distribution?
Are there clear instructions on how to complete the form?
(ii)
Introductory section of forms

Does the name of the form appear at the top? Is the name clearly
visible?
Is the form pre-numbered sequentially?
Are the companys name and address pre-printed on forms meant
to be distributed to external parties?
(iii)
Main body of forms

Are related information, such as customer name and address,
grouped together?
Is there sufficient space to record each data item?
Are the data items ordered in a manner consistent with the
sequence in which data items are most likely to be acquired?
Are standardised explanations pre-printed to ensure codes or check
offs can be used instead of written user entries?
(iv)
Conclusion section of forms

Is space provided:
- To record final disposition of the form or approval date?
- For signature(s) to indicate final transaction approval?
- For numeric totals, such as volume and costs?
Is the distribution of each copy of the form clearly indicated?
TOPIC 5
(b)
SYSTEMS DESIGN
117
Designing Computer Screens

The following are guidelines that should be followed when designing
computer input screens (Romney & Steinbart, 2009):
(i)
Organising the computer screen to ensure that data can be entered

quickly, accurately and completely. Minimising data input with
retrieval of as much data as possible from the information systems. For
instance, entering customer ID triggers retrieval of customers name,
address and other important information;
(ii)
Entering data in the same order as displayed in the hardcopies of

forms to capture data;
(iii)
Completing the screen from left to right and top to bottom. Grouping
related data together;
(iv)
Designing the screen in a manner that allows users to jump from one
data entry location to another, or to use a single key, or to go directly to
screen locations;
(v)
Making the correction of errors easy. Clear and explicit error messages
should be made consistent across all screens. Help features to provide
online assistance must be made available; and
(vi)
The amount of data on the screen and the number of menu options on
a single screen should be restricted.
Figure 5.7 depicts a screenshot of a computer input screen design. The few menu
options and textboxes on the screen are organised in a top-down manner with
minimal clutter to facilitate speedy and error-free data entry.
Figure 5.7: A screenshot of a computer input screen design

Source: http://www.wufoo.com
5.2.4
Programme and Procedure Design
As discussed in Topic 1, structured programming facilitates programme

development. Programmes are subdivided into smaller modules to reduce
complexity and enhance reliability and modifiability. Programming standards
ensure consistency among programmes, which makes programmes cost effective
to manage. The standards also ensure uniformity and integration, which are also
important considerations in systems design, as this allows data processing to run
on any computer within the same organisation (Bodnar & Hopwoods, 2001).
TOPIC 5
SYSTEMS DESIGN
119
While accountants need not know the details related to programme code
development, accountants do however need to know how programmes are
developed in general. There are eight steps in programme development, which are
detailed in the following (Romney & Steinbart, 2009). However, not every step in
programme development is performed in the systems design phase.
(a)
Step 1: Determine User Needs

This step is performed as part of systems analysis as discussed in Topic 3.
System designers consult users to determine software requirements.
(b)
Step 2: Develop a Plan

This step is performed as part of conceptual systems design development. A
programme development plan is produced and documented at this stage.
(c)
Step 3: Write Programme Instructions, Code

This step is performed in the systems design phase, where programme
instructions or code is written. The hierarchical programme design is often
used, where computer programmes are developed top down to more
detailed levels.
(d)
Step 4: Test the Programme

Once a programme is coded, desk-checking is conducted; a visual and
mental review is conducted to detect programming errors. Syntax errors are
detected at the programme compilation stage. Simulation of as many real
processing situations or input data combinations as possible is conducted to
test for logic errors. Large programmes are often tested in three stages. First,
individual programmes are tested. Second, linkages between modules and a
control module are tested. Finally, interfaces between the programme being
tested and other application programmes are tested. The process of detecting
and eliminating programme errors is known as debugging.
(e)
Step 5: Document the Programme

How the programme works is documented. Programme documentation
includes use of flowcharts, data flow diagrams, record layouts, entityrelationship diagrams, narrative descriptions and other appropriate
documentation techniques. Programme documentation should be organised
in a meaningful manner to serve as a manual when correcting and resolving
errors.
(f)
Step 6: Train Programme Users

Programme documentation also serves as a guide for user training, which
begins in the systems design phase and continues to the subsequent systems
implementation phase, which will be discussed in the next topic.
(g)
Step 7: Install the System

The programme being developed is combined with all existing components
of the information system. The organisation will then begin to use the new
information system.
(h)
Step 8: Use and Modify the System

Programmes in operation are revised as part of programme maintenance.
Examples of programme maintenance activities include requests for new or
revised reports, changes in input, file contents or values, tax rates, error
detection and conversion to new hardware.
Procedure designs aim at assisting everyone who interacts with the newly
designed information systems. It can be in the form of system manuals, user
instruction classes, training materials or online help screens. Procedures should
encompass input preparation, transaction processing, error detection and
correction, controls, reconciliation of balances, database access, output preparation
and distribution and computer operator instructions.
5.2.5
Controls Design
Controls design must be developed and built into information systems to ensure
efficiency and effectiveness in input, processing and database functions. The
designs should aim at minimising errors and detecting and correcting errors in the
event errors cannot be prevented.
The following checklist of questions together with major design considerations,
such as cost effectiveness, comprehensiveness and appropriateness, can serve as a
guide for controls design choices (Romney & Steinbart, 2009).
(a)
Validity Are all system interactions valid, for example are cash
disbursements made only to valid vendors?
(b)
Authorisation Are input, processing, storage and output activities properly

authorised, for instance are payroll additions appropriately authorised?
(c)
Accuracy Is input verified for accuracy? Are controls in place to ensure

data are not lost in-between processing activities?
(d)
Security Are data protected against unauthorised physical and logical

access to prevent improper use, alteration, destruction or disclosure of
information and software? Are the systems protected against theft of system
resources?
(e)
Numerical control Are documents pre-numbered to prevent misuse and

facilitate detection when documents are missing or stolen?
TOPIC 5
SYSTEMS DESIGN
121
(f)
Availability Are the systems available for operation and use at times as
agreed in service-level agreements? Can users enter, update and retrieve
data during the agreed-upon times?
(g)
Maintainability Can the systems be modified when required without

compromising systems availability, security and integrity? Are only
authorised, tested and documented changes made to the systems and data?
Are resources available to manage, document and communicate changes to
management and authorised users?
(h)
Integrity Is data processing complete, accurate, timely and authorised?

Is data processing compromised by unauthorised or inadvertent system
manipulations?
(i)
Audit trail Can transaction data be traced from source documents to output
and vice versa?
5.2.6
Physical Systems Design Reports
At the end of the systems design phase, a physical systems design report is
prepared. The report summarises what has been accomplished, which serves as a
basis for the management and/or steering committee to decide whether to proceed
to the implementation phase. Table 5.2 provides an example of a table of contents
of a physical systems design report.
Table 5.2: An Example of a Table of Contents of a Physical Systems Design Report
I.
Executive Summary of the Physical Systems Design
II.
Overview of Project Purpose and Summary of Findings to Date
III. Major Physical Design Recommendations

A.
Output Design
B.
Input Design
C.
Database Design
D.
Software and Processing Design
E.
Hardware Design
F.
Controls Design
G.
Procedures Design
IV. Assumptions and Unresolved Problems

V.
Summary
VI. Appendices, Glossary

SELF-CHECK 5.2
1.
What is the major design consideration that plays an important

role in each and every physical design phase? Why is the design
consideration important?
2.
Identify a specific physical design choice such as monthly sales

report in hardcopy, data entry via point-of-sales (POS) terminal,
etc. for each design phase that you believe is most cost effective
for a typical batch purchase system. Explain why your choice is
most cost effective.
Identify a Physical Design Choice that is Most Costeffective for a Batch Purchase System and Justify your
Answer.
Output design
File and
database design
Input design
Programme and
procedures
design
Controls
TOPIC 5
5.3
SYSTEMS DESIGN
123
Accountants can contribute towards systems design development in a number of

ways:
(a)
As a systems specialist or consultant, accountants can assist in translating

system requirements first into general, conceptual design specifications and
subsequently into more specific, physical design specifications;
(b)
As a staff accountant, accountants can provide assistance in ensuring that

the choice of design specifications at each design phase is most cost
effective, which is a major design consideration relevant to each and every
design phase;
(c)
As an internal or independent auditor who has an appreciation and

detailed expertise for controls, accountants can review the entire systems
design to identify inadequacies in control that systems analysts may have
overlooked.
Systems design development begins with conceptual design specifications

where general, conceptual descriptions are developed for output, data
storage, input and processing procedures and operations.
Based on the conceptual system specifications, systems design development

then proceeds to physical design specifications, where more specific, physical
descriptions are developed for output, file and database, input, programme
and procedures and controls.
Cost effectiveness is a major design consideration at each and every design

phase. The choosen physical systems design should produce the highest
benefits-to-costs ratio to achieve the given information systems objectives.
Conceptual systems design
Integration
Conceptual systems design report
Physical systems design
Controls design
Physical systems design report
Cost effectiveness
Procedure design
Database design
Programme design
Input design
Standardisation
Output design

Mirror Books.
Prentice Hall.
TOPIC 5
SYSTEMS DESIGN
125
Topic Systems
Change and
Implementation
LEARNING OUTCOMES
1.
Explain the different phases of systems implementation;
2.
Describe the goals and/or purposes of each systems implementation

phase; and
3.
Identify the appropriate tools, procedures, practices and/or

approaches that facilitate attainment of goals and/or purposes at
each systems implementation phase.
INTRODUCTION
As illustrated in the case of Hewlett-Packard (HP) in Figure 6.1, many problems
can occur during systems implementation. Proper plans, procedures and controls
for systems implementation should be established and put in place to minimise
problems.
TOPIC 6
SYSTEMS CHANGE AND IMPLEMENTATION
127
Figure 6.1: Problems with systems implementation
6.1
AN OVERVIEW OF SYSTEMS
IMPLEMENTATION
Systems implementation involves installation of hardware and software and

putting the new information systems into operation. The implementation
process requires planning, site preparation, personnel selection, systems
testing, documentation preparations, database conversion, conversion to the new
information systems and operation and maintenance. Figure 6.2 summarises the
various phases in systems implementation. Notice that some of the phases take
place concurrently. Each phase is discussed in further detail in the remainder of
this topic.
128 TOPIC 6 SYSTEMS CHANGE AND IMPLEMENTATION
Figure 6.2: Systems implementation phases
6.2
IMPLEMENTATION PLANNING
ACTIVITY 6.1
Returning to the Hewlett-Packard (HP) case in Figure 6.1, HP was

actually aware of all the problems even before they happened. What do
you think HP could have done to prevent all the problems from
snowballing into a $160 million cost in order backlogs and lost revenue?
Write down a list of things that HP could have done. You can search the
Internet and/or other materials to help you.
TOPIC 6
129
An implementation plan typically lays out the following information (Bodnar &
Hopwood, 2001; Romney and Steinbart, 2009):
(a)
A breakdown of the systems project into various phases and/or tasks;
(b)
Expected completion dates for each of the phases and/or tasks;
(c)
Budgets associated with each phase and/or task; and
(d)
Personnel responsible for each phase and/or task.
The plan specifies when the new information systems should be completed and
operational. Risks that can cause a delay in completion of the new information
systems as well as the corresponding coping strategies should also be identified in
the plan.
A Gantt chart is useful in depicting the phases and/or tasks of a systems project
together with their respective expected completion dates. Figure 6.3 provides an
example of a Gantt chart. The chart helps to plan times for a given task, which can
be used to subsequently monitor actual implementation of each task. Corrective
actions can be taken on tasks with actual times exceeding planned times to ensure
timely project completion.
Figure 6.3: An example of a Gantt chart

Besides a Gantt chart, a network diagram, which depicts the sequence in which
tasks must be performed, is also useful. Figure 6.4 provides an example of a
network diagram. A network diagram can also be expanded to include expected
completion times of each task.
Figure 6.4: An example of a network diagram

Source: Adapted from Bodnar and Hopwood (2001)
As complements to the network diagram, statistical tools like Programme

Evaluation and Review Technique (PERT), which is frequently used in conjunction
with Critical Path Method (CPM) can be used to estimate the critical path of the
systems project. Critical path refers to the sequence of tasks critical to the systems
project, where delay in completion of any of these tasks compromise project
completion. The critical path should be the focus of monitoring efforts to ensure
timely project completion.
TOPIC 6
6.3
131
SITE PREPARATION, INSTALLATION OF

HARDWARE AND SOFTWARE
Site, i.e., space, is required for equipment, storage, offices, etc. Site preparation
activities include adding electrical outlets, data communication facilities, raising
floors, humidity controls, lightings and air-conditioning. Security measures such
as fire protection and alternative power supply are also important. Site
preparation should begin in advance to facilitate installation of the necessary
hardware and software for the new information systems.
Prior to installation of hardware and software, we need to make sure the systems
design is complete. Next, we must acquire the required hardware and software.
Finally, we write, test and debug computer programmes (Gelinas et al., 1999).
These intermediate steps in systems implementation are illustrated in Figure 6.5
and discussed in the remainder of this section.
Figure 6.5: Intermediate steps in systems implementation
6.3.1
Completing Systems Designs
First, we need to make sure the systems design is developed as discussed in

Topic 5 and is complete for each specific business process. If the design is not
complete, we must first complete the design.
Figure 6.6 depicts the sequence in completing the design using an example of a
sales order processing and invoicing.
Figure 6.6: Sequence in completing a systems design

Source: Gelinas et al. (1999)
TOPIC 6
133
First, output design should be completed based on design considerations and

options. Data required for output include:
(a)
Entered A sales persons identification is entered with the sales order;
(b)
Generated (calculated) For example prices on the sales order are

calculated each time the sales order is printed; and
(c)
Retrieved from previously stored data The name of the sales person is
retrieved from the employee master file.
Based on output design specifications, input and database design should be

completed, while taking into account the design considerations and options as
discussed in Topic 5. Files must be laid out to map the logical record into storage.
Figure 6.7 depicts the layout of three files, employees, orders and order details.
To complete database design, the required files should be added together with
their connections to existing files. The design of each file should be made
complete as well.
Figure 6.7: An example of files layout
Figure 6.8 depicts the logical view of an employee file, which enables you to
complete design specifications of the file, for areas such as field name, field
length and so on.
Figure 6.8: An example of a logical view of a file
Finally, design of processes manual and computer-based processes must be

completed. Design of manual processes must be complete to enable development
of procedure manuals, while design of computer-based processes must be
complete to enable development of computer programme codes.
6.3.2
Acquiring Hardware and Software
When acquiring hardware and software, close attention should be given to

contract negotiation and preparation. Computer and legal expertise are required
in contract negotiation and execution. Contracts should be as comprehensive as
possible, leaving nothing open to assumptions. Detailed specifications will
protect both the buyers and sellers. Contracts should also encompass computer
hardware and software lease, rental, or purchase, as well as services provided.
The installation of hardware and software should be straightforward with wellwritten contracts and adequate site preparations. In the event of delays in site
preparation and/or equipment delivery, contingency plans should be considered
(Gelinas et al., 1999).
TOPIC 6
6.3.3
135
Writing, Testing and Debugging Computer

Programmes
The programming phase, which includes writing, testing and debugging

computer programmes, often consumes more time and resources than any other
systems development task. Programmers must first develop a test plan. The test
plan outlines how each programme module is developed and tested. Testing
typically requires the user, programmer and another member of the systems
development team to walk-through the module specifications and the test plan to
ensure that they are adequate. A walk-through is a step-by-step review of
procedures and programme logic. The programmer then codes the programme.
Alternatively, computer software, a code generator writes programme code.
Walk-throughs constitute an important type of test and is used at various phases
of programming including:
(a)
Early in systems design, prior to writing the programme code, walkthroughs can be conducted by both the systems development team and
users, with a focus on the inputs, files, outputs and data flows;
(b)
Subsequently, once the programme code is developed, programmers will

walk-through the code to ensure the code faithfully implements module
specifications. The focus of the walk-through is on the logical and
structural aspects of the programme code; and
(c)
Programmers also walk-through programme code of individual modules to

test and remove errors. Errors are also known as bugs. Removal of
programme errors is also known as debugging.
At the end of the programming phase, programmers must complete the

programme documentation. The documentation are important for programme
maintenance. Programme maintenance includes activities such as making
programme changes, correcting errors in the programmes and adding
enhancements to the programmes (Gelinas et al., 1999).
SELF-CHECK 6.1
1.
In systems implementation planning, what are the tools useful in

ensuring timely completion of systems implementation? Describe
the tools.
2.
What should you do before you acquire and install hardware and
software?
3.
What do you understand by walk-throughs? When should you

conduct them?
6.4
PERSONNEL SELECTION AND TRAINING
Organisations must select personnel to operate the new information systems.

While personnel who operate the systems require training to perform their
system-related tasks, users require training on the new systems purposes,
functions and capabilities. A cost-benefit analysis can be conducted to determine
whether to train, or not to train, as well as how much and what kinds of training
to deliver. While employees can be hired from outside the organisation to
minimise or even eliminate the need for training, newly recruited employees
require time to familiarise themselves with the organisations business and
operations. Training and transfer of existing employees who are displaced as a
result of the new systems will boost employee loyalty and morale.
The choice of the training delivery system should be in line with training needs
and objectives, as well as cost-benefit considerations. Training can be delivered
via a combination of methods, ranging from vendors specialising in training, inhouse training, computer-assisted learning, interactive tutorials, to on-to-job
training with instructions and on-going assistance.
Computer-based training provides learning via computers. This form of training
can be interactive, permits individualised instructions and can capture and keep
trainees attention with colour displays and high-quality graphics. Online Help
functions as well as technical support can reduce the amount of formal, up-front
training and provide ongoing assistance to users (Gelinas et al., 2009).
TOPIC 6
6.5
137
SYSTEMS TESTING
The entire information system must be tested. The goals of testing the entire
system are:
(a)
To determine whether the information systems together with the newly

installed hardware and software are operational;
(b)
To determine whether system requirements established in consultation

with users are met; and
(c)
To determine whether both users and system operators are satisfied with
the operation of the new systems.
The systems development team together with the users test the entire
information systems. Tests should simulate the real-life production environment
in terms of data, inputs, and operations whenever possible. The closer the
tests simulate a real-life production environment, the more representative the test
will be. The tests results will also be more conclusive and convincing. Systems
testing consists of five generic steps, as follows (Gelinas et al., 1999).
(a)
Specify test conditions;
(b)
Review, walk-through and test conditions;
(c)
Create test data;
(d)
Execute test; and
(e)
Evaluate results.
6.5.1
Types of Tests
Based on the five generic systems testing steps, several types of tests can be
conducted. Each type of test has different purposes and functions and can be
used in conjunction with other tests depending on the objectives of conducting
the tests (Gelinas et al., 1999; Romney & Steinbart, 2009). The different types of
tests are:
(a)
Systems Test
Systems test verifies the new systems against original requirement
specifications. The systems development team will conduct this test first,
followed by users.
(b)
Acceptance Test
Acceptance test verifies whether all components of the new systems are
satisfactory from the users point of view. Users conduct this test, which
includes testing the adequacy of the systems in terms of both their manual
and automated components, user manuals and other documentations and
the training users received. Copies of real-life transactions and files are
used in the test rather than hypothetical test data. Users set acceptance
criteria to evaluate whether to accept the new systems.
(c)
Processing Test Transactions

Processing test transactions verifies the new systems with both valid as
well as erroneous data to determine whether test data both valid and
erroneous are handled appropriately. The correct system responses must
be specified in advance to evaluate the test results.
(d)
Operations or Environment Test

Operations or environment tests verify the new systems by running a
subset of the systems in a real-life production environment. This test
determines whether the new systems, with new hardware and software,
operate in conjunction with other factors in the environment data entries,
document and report deliveries, telephones and electricity in a
satisfactory manner.
TOPIC 6
139
SELF-CHECK 6.2
What are the goals of systems testing? Describe how the different types
of tests help to achieve each of the goals of systems testing that you
have identified.
Goals of Systems Testing
Types of test
1.
2.
3.
6.6
SYSTEMS DOCUMENTATION
Systems documentation describe how information systems work. Complete

systems documentation serve a wide range of useful purposes. Examples of some
of the useful purposes are (Bodnar & Hopwood, 2001):
(a)
Assist in ensuring systems design specifications are met;
(b)
Provide useful information that serve as a guide for future programme

evaluations and modifications;
(c)
Assist in the training of new employees; and
(d)
Provide useful information for evaluating internal controls.
Four types of documentation and their respective requirements are discussed in

each of the following subsections.
6.6.1
Designer and Programmer Documentation
Systems designers and programmers require documentation to maintain the

information systems, for example debugging and upgrading processes.
Designers and programmers are involved with the systems at a technical level
and require both general and specific information to complete their tasks
successfully. Among the information that they require are: (Hall, 2013):
(a)
System flowcharts that depict the relationships between inputs, processes

and programme and outputs at a general level;
(b)
Programme flowcharts for each individual programme, which provides

detailed descriptions of the sequential and logical operations of the
programme; and
(c)
Descriptions of the programme code with comments and test results.
6.6.2
Operator Documentation
Computer operators require documentation, a run manual, to help them operate

the information systems. A run manual often includes the following information
(Hall, 2013):
(a)
Name of the system for example purchase system;
(b)
Run schedule (daily, weekly and time of day);
(c)
Required hardware devices (tapes, disks and printers);
(d)
Files required (the specific transaction or input files, master files and output
files);
(e)
Run-time instructions (descriptions of error messages that may appear,

actions required and the name and contact number of the programmer on
call in the event the system fails); and
(f)
Users who receive the output from the run.
Operators should not be allowed to have access to information pertaining to the

systems internal logic to prevent misuse both intentional and unintentional
of the system. System flowcharts, programme flowcharts and descriptions of
programme code should be excluded from the run manual.
TOPIC 6
6.6.3
141
User Documentation
Users require documentation to help them use the information systems, e.g.,
entering input for transactions, making inquiries of account balances, updating
accounts and generating reports. User documentation should be developed while
taking into consideration users levels of sophistication with computers and
technologies. There are four categories of users based on their levels of
sophistication (Hall, 2013):
(a)
Novices
Documentation and user training should be extensive and detailed for
novices. Novices typically have minimal knowledge and experience with
computers and technologies, as well as assigned tasks. They are often
embarrassed to ask questions.
(b)
Occasional Users
Occasional users require less documentation and training than novices.
These users make use of information systems on an occasional basis and at
times forget some essential commands and procedures that they have used
before.
(c)
Frequent Light Users

Frequent light users are familiar with certain aspects of the information
systems. Their knowledge of the information systems is more at the
superficial level. These users require documentation and training with
unfamiliar aspects of the systems.
(d)
Frequent Power Users

Frequent power users have an in-depth understanding of the information
systems and require primarily abbreviated documentation. They are
intolerant of detailed instructions. They tend to find shortcuts and use
macro commands to improve performance. They are ready to adapt to new
systems.
In light of the varying degrees of user sophistication, user documentation,

which is often in the form of a user handbook, typically contains the following
information (Hall, 2013):
(a)
Overview of the information system and its major functions;
(b)
Instructions for getting started;
(c)
Descriptions of procedures accompanied by step-by-step visual references;
(d)
Example of input screens and instructions for data entry;
(e)
List of error message codes together with their respective descriptions;
(f)
Reference manual of commands to operate the system;
(g)
Glossary of key terms; and
(h)
Services and support information.
Figure 6.9 provides an example of instructions from a user handbook, which

provides an overview of how to get started with a notebook computer and its
major command keys.
Figure 6.9: Example of instructions from a notebook computers user handbook
TOPIC 6
143
Besides user handbooks, online documentation with interactive features have

also become increasingly common. Two common forms of online documentation
are:
(a)
Tutorials
Online tutorials are useful to train novices and occasional users with a
certain degree of realism.
(b)
Help Features
Online help features with varying degrees of sophistication can be used to
train users at various levels of sophistication. An example of a simple help
feature includes an error message displayed on the screen, which prompts
users to walk-through the screens to search for solutions to the problem.
More sophisticated help is context relevant and the help feature will
analyse what the user is doing at the time of the error and provide help
with the specific functions as required.
Figure 6.10 depicts an example of an error message that informs users of a

problem, lost communication with the printer. The error message also outlines
how to solve the problem and even provides the contact number of the technical
support personnel in charge.
Figure 6.10: An example of an error message
6.6.4
Accountant Documentation
Accountants require documentation to fulfil their responsibilities for the design

of certain security procedures, accounting controls and audit trails. While most of
the documentation discussed in this section assist accountants in their position as
internal and external auditors, the following documentation are particularly
useful in understanding and evaluating segregation of duties, adequacy of source
documents and the presence as well as location of files that support audit trails
(Hall, 2013).
(a)
Data flow diagrams, which describe the logic of the system; and
(b)
System and document flowcharts, which provide a physical view of the

system, such as tasks that are actually performed and the specific types and
number of documents that carry information.
When such documentation are not prepared or are incomplete, accountants often
prepare their own documentation when auditing the information systems.
SELF-CHECK 6.3
What are the purposes of systems documentation? Describe how the
different types of documentation together with their respective
requirements help to achieve the various purposes of the systems
documentation that you have previously identified.
Complete the following table with your opinions.
Purposes of Systems Documentation
Types of Documentation and

Documentation Requirements
1.
2.
3.
4.
TOPIC 6
6.7
145
DATABASE CONVERSION
Database conversion is the process of transferring data from its existing form to
the format and medium compatible with new information systems. Complexity
of the conversion process depends on the technology leap from the old to the
new system. Conversion activities can range from manually entering data into
the new database to writing special conversion programmes to accomplish data
transfer.
Regardless of the complexity of the conversion process, the following
precautionary steps should be taken as database conversion is risky (Hall, 2013).
(a)
Validation
The old database must be validated prior to conversion. Validation
involves analysing each class of data to decide whether the data are
complete, accurate and consistent. Errors in the data are removed.
Validation also includes deciding which data and files should be
reproduced in the new database.
(b)
Reconciliation
The new database must be reconciled with the old database postconversion to ensure data are not lost during the conversion. Reconciliation
can be accomplished manually, record by record and field by field.
However, reconciliation is more often accomplished by writing a
programme to automate the process of comparing the two sets of data.
(c)
Backup
Original data and files must be kept as backups in case of discrepancies in
the converted data. The new systems should be monitored from time to
time to ensure they run smoothly. When users are certain and confident of
the accuracy and completeness of the new databases, original data and files
can be destroyed especially when they are in the form of paper documents
that create storage problems.
6.8
SYSTEMS CONVERSION
Systems conversion is the process of migrating from the old to the new
information systems. Besides database, hardware and software, procedures must
also be converted. The conversion process is complete when the new information
systems have become a routine part of organisational business operations. The
conversion process typically follows one of the approaches discussed as follows
(Hall, 2013; Romney & Steinbart, 2009).
(a)
Cold Turkey or Big Bang Conversion

Under this conversion approach, the organisation migrates to new
information systems and simultaneously terminates the old systems. This
conversion approach is also known as immediate cutover. This approach is
simple, easy, least costly and most appropriate when the old system has no
value and/or the new system is different to the extent that comparisons
between the two systems are meaningless.
However, this approach can be risky when the information systems are
complex with no backups from the old systems. When the new information
systems fail to operate as expected, for example system errors are not
detected during walk-throughs and other testing phases materialise
unexpectedly, the organisation can be in serious trouble without the old
information systems as a backup.
(b)
Phased-in Conversion
Under phased-in conversion, the organisation gradually migrates to the
information systems in modules. For instance, the organisation can begin
with the sales subsystem, followed by the inventory control subsystem and
finally the purchasing subsystem. Gradual migration to the new systems
allows data processing resources to be acquired over time. Phasing in the
new information systems in modules also minimises risk of a devastating
system failure.
TOPIC 6
147
However, having part of the old and new information systems running
simultaneously can create incompatibilities between the new subsystems
and yet-to-be-replaced old subsystems. Implementing special conversion
systems that provide temporary interfaces during the conversion period
can alleviate such incompatibilities.
(c)
Parallel Operation Conversion

Under parallel operation conversion, both the old and new information
systems run concurrently for a period of time. Resource consumption
doubles during the conversion period as the two information systems
require twice the source documents, processing times, databases and
output productions.
Running the two systems concurrently allows users to test the functionality
of both the new systems. Users can compare and reconcile outputs from the
two systems, as well as identify and debug errors prior to allowing the new
systems to operate independently.
(d)
Pilot Conversion
Pilot conversion implements the new information systems in just a part
of the organisation, for example in a branch or plant. When problems
associated with the new systems are identified and resolved, only then
will the new information systems be implemented in other parts of the
organisation. This conversion approach localises problems with the new
systems and enables training in a live environment.
However, migration to the new systems consumes more time. Interfaces
between the old and new systems are required until the entire organisation
migrates to the new systems.
SELF-CHECK 6.4
1.
What are the precautionary steps that should be taken in database

conversion?
2.
What are the advantages and disadvantages of each of the

following systems conversion approaches? Complete the
following table.
Systems Conversion
Approaches
1.
Cold turkey or big

bang conversion
2.
Phased-in
conversion
3.
Parallel operation
conversion
4.
Pilot conversion
Advantages
Disadvantages
TOPIC 6
6.9
149
OPERATION AND MAINTENANCE
The final phase in systems implementation is to operate and maintain the

new information systems. A post-implementation review must be conducted on
the new information systems to measure success of the systems in meeting
set objectives. The post-implementation review is often conducted as soon as
the new systems operate at full capacity. The review should examine fully
functioning information systems to minimise erroneous conclusions about the
systems performance.
The review provides insights into how best to further improve on the
information systems as well as systems development practices. Any problem
identified during the review is brought to the attention of the management
for corrective actions. Among the goals of post-implementation review are to
(Gelinas et al., 1999):
(a)
Ascertain whether users are satisfied with the new information systems;
(b)
Assess the degree of correspondence between system performance

requirements and the systems achieved performance;
(c)
Assess the quality of the new systems documentation, training programmes

and file conversions;
(d)
Assess performance of the new systems and recommend the necessary

improvements, if required;
(e)
Ascertain the extent to which the organisations systems development

plans and the systems development life cycle are followed during systems
development;
(f)
Recommend improvements to the organisations systems development

standards manual, if required;
(g)
Review costs and benefits estimations and ascertain the degree to which
they are achieved;
(h)
Review project planning procedures by evaluating total project costs and

the project teams ability to adhere to project costs estimates and schedules;
and
(i)
Make other recommendations to improve the operations of the system

and/or development of other information systems.
A diversity of areas can be included in the post-implementation review in order

to achieve the above-mentioned goals. Areas of particular concern in postimplementation review are (Hall, 2013):
(a)
Systems Design Adequacy

The physical design of the information systems should be reviewed to
ensure user needs are met. The following checklist of questions assists in
the review process (Hall, 2013).
(i)
Does output from the systems possess information characteristics

such as relevance, timeliness, completeness and accuracy?
(ii)
Is output in a useful format tables, graphs, electronic, hardcopy, etc.

which users desire?
(iii)
Are databases accurate, complete and accessible?
(iv)
Does the conversion process result in losses, corruptions and/or

duplications in data?
(v)
Are input forms and screens properly designed and consistent with
user needs?
(vi)
Are users using the systems properly?
(vii) Does processing appear to be correct?

(viii) Can all programme modules be accessed and executed properly? Do
users get stuck in a loop?
(b)
(ix)
Are user documentation accurate, complete and easy to follow?
(x)
Do the systems provide users with adequate help and tutorials?
Accuracy of Time, Cost and Benefit Estimates

In terms of time, costs and benefits, a review of actual performance in
comparison with estimates provides critical feedback to future budgeting
decisions. The following checklist of questions assists in the review (Hall,
2013).
(i)
Are PERT and Gantt chart estimates accurate to within 10%?
(ii)
What are the areas of significant deviations from estimates?
(iii)
Are deviations from estimates controllable (internal) in the short-run

or non-controllable (external, supplier problems)?
TOPIC 6
151
(iv)
Are estimates of the number of lines of programme code accurate?
(v)
Is the degree of rework attributable to design and coding errors

acceptable?
(vi)
Are actual costs in line with budgeted costs?
(vii) Do users receive the expected benefits from the systems?

(viii) Are the benefits fairly valued?
On completion of the review, a post-implementation review report is prepared.
While users and auditors acceptance of the post-implementation review report is
the final activity in systems development, maintenance of the information
systems for example software modifications, upgrades, etc. continues. Table
6.1 provides an example of a table of contents of a post-implementation review
report.
Table 6.1: An Example of a Table of Contents of a Post-implementation Review Report
I.
Executive Summary of Post-implementation Review
II.
Overview of Development Project
III. Evaluation of the Development

A.
Degree to which Systems Objectives are Met
B.
Analysis of Actual versus Expected Costs and Benefits
C.
User Reactions and Satisfaction
IV. Evaluation of Project Development Team

V.
Recommendations
A.
Recommendations for Improving the New Systems
B.
Recommendations for Improving the Systems Development Process
VI. Summary
6.10
Accountants can contribute towards systems implementation in a number of

ways, including:
(a)
As a systems specialist or consultant, accountants can assist in completing

the systems design prior to acquisition and installation of hardware and
software as well as review of the systems design post-implementation;
(b)
As a staff accountant, accountants can provide assistance in ensuring that

the choice of design specifications is cost effective and in line with
regulatory standards and requirements, such as the GAAP, GAAS, KLSE
listing, reporting requirements and tax requirements; and
(c)
As an internal or independent auditor who has an appreciation and

detailed expertise for controls, accountants can assist in ensuring complete
systems documentation to facilitate periodic statutory audit as well as postimplementation review. Accountants can assist in evaluating adequacy of
security and controls in post-implementation review.
SELF-CHECK 6.5
1.
What do you think could happen if post-implementation review is

omitted?
2.
What do you think can happen if the systems project team were to
lack expertise in controls and regulatory requirements?
The first step in systems implementation is to develop a plan, which specifies

the required phases and/or tasks and their respective completion dates,
budgets and personnel in-charge.
Prior to acquiring and installing hardware and software, systems designs

must be completed and the site must be prepared. Once hardware and
software are acquired and installed as per the systems design, computer
programmes are written, tested and debugged. Personnel are selected to
operate the systems and both operators and users are trained.
TOPIC 6
153
To ensure newly installed hardware and software operate in conjunction with

the existing systems to the satisfaction of users and operators, the entire
system must be tested. Documentation of the systems must be complete to
facilitate designers and programmers, operators, users and accountants to
use, manage, monitor and improve on the systems. Database conversion must
follow three precautionary steps validation, reconciliation and backup.
There are four major approaches cold turkey or big bang, phased-in,
parallel operation and pilot conversion to convert the old information
systems to new ones. Each approach has its respective advantages and
disadvantages.
Once the new systems are fully functional, post-implementation review is

conducted to ascertain how best to further improve on the systems as well as
the organisations other systems projects and overall systems development
practices.
Acceptance test
Parallel operation conversion
Accountant documentation
Phased-in conversion
Cold turkey or big bang conversion
Pilot conversion
Debugging
Post-implementation review
Designer and programmer

documentation
Processing test transactions

System test
Implementation planning
User documentation
Operator documentation
Walk-throughs
Operations or environment test

Mirror Books.
Prentice Hall.
Wailgum, T. (2009). 10 famous ERP disasters, dustups and disappointments.
Retrieved from www.CIO.com.
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 myVLE.
Thank you.
Centre for Instructional Design and Technology
(Pusat Reka Bentuk Pengajaran dan Teknologi)
Tel No.:
03-27732578
Fax No.:
03-26978702

BBAS4203 Accounting Infomartion System II PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BBAS4203 Accounting Infomartion System II PDF

Transféré par

Droits d'auteur :

Formats disponibles

BBAS4203

Copyright Open University Malaysia (OUM)

Prof Dato Dr Mansor Fadzil

Dr Lau Yeng Wai

Centre for Instructional Design and Technology

Meteor Doc. Sdn. Bhd.

First Printing, August 2014

Copyright Open University Malaysia (OUM)

Copyright Open University Malaysia (OUM)

Copyright Open University Malaysia (OUM)

3.4.4 Decision Analysis

Systems Design Evaluations and Choices

Physical Systems Design

Systems Change and Implementation

Copyright Open University Malaysia (OUM)

Copyright Open University Malaysia (OUM)

Copyright Open University Malaysia (OUM)

COURSE GUIDE DESCRIPTION

Copyright Open University Malaysia (OUM)

Table 1: Estimation of Time Accumulation of Study Hours

Briefly go through the course content and participate in initial discussions

Study the module

Attend 3 to 5 tutorial sessions

Assignment(s), Test(s) and Examination(s)

TOTAL STUDY HOURS

Discuss the role of accountants in the Systems Development Life Cycle;

Analyse various approaches to developing an accounting information

Apply various approaches to developing an accounting information

Evaluate appropriate/relevant project management softwares.

Topic 2 focuses on the planning of systems development. Planning is a part of

Copyright Open University Malaysia (OUM)

TEXT ARRANGEMENT GUIDE

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)

Explain the key stages of systems development;

Discuss the objectives of systems development;

Describe the documentation used and their purposes at different

Identify common systems development technologies and practices;

Apply the process of planning and organising a systems project.

Copyright Open University Malaysia (OUM)

This topic provides an overview of information systems development. First, we

SYSTEMS DEVELOPMENT LIFE CYCLE

Copyright Open University Malaysia (OUM)

Figure 1.1: Systems Development Life Cycle (SDLC)

Copyright Open University Malaysia (OUM)

The first step in SDLC is to develop a systems strategy. Prior to developing a

In-house development activities include analysing users needs, designing

Among the advantages of acquiring commercial packages over in-house

Copyright Open University Malaysia (OUM)

Maintenance and Support

Why would organisations develop their own information systems

OBJECTIVES OF SYSTEMS DEVELOPMENT

This section discusses the general objectives of information systems development

Accurate and Timely Information

Lack of familiarity with newly developed information systems, regardless of

Copyright Open University Malaysia (OUM)

The information systems need to be aligned with the appropriate processing

Time Required for Systems Development

Systems development should be completed within a reasonable time period.

Satisfying Organisational Needs