System Anaysis Design Study Guide Updated 2012

Systems Analysis and Design Study Guide
TABLE OF CONTENTS
CHAPTER ONE: BASIC INFORMATION SYSTEMS CONCEPTS ............................................... 5

OBJECTIVES ....................................................................................................................................... 5
By the end of this chapter, you should be able to: ............................................................................. 5
 Define an information System and name the types of information systems (IS). applications
5
 Identify different types of stakeholders who use or develop IS. ............................................... 5
 Define the role of systems analysts in development of information systems. .......................... 5
 Describe the business drivers that influence IS development. .................................................. 5
 Describe the technology drivers that influence IS development. .............................................. 5
 Describe a simple process for developing IS............................................................................... 5
INTRODUCTION................................................................................................................................. 5
What is a system? .............................................................................................................................. 5
What is a business system?............................................................................................................... 5
What is an information system? ...................................................................................................... 5
Importance of information systems ................................................................................................. 2
Measuring the success/effectiveness of a recently implemented system ...................................... 2
LEVELS OF MANAGEMENT AND THEIR INFORMATION NEEDS ...................................... 2
Operational management ................................................................................................................. 3
Tactical management ........................................................................................................................ 3
Strategic management ...................................................................................................................... 3
TYPES OF INFORMATION SYSTEMS........................................................................................... 4
Transaction Processing Systems ...................................................................................................... 4
Management Information Systems ................................................................................................. 4
Decision Support Systems ................................................................................................................ 4
Expert Systems .................................................................................................................................. 4
WHAT IS SYSTEMS ANALYSIS AND DESIGN? .......................................................................... 4
STRUCTURED APPROACHES TO SYSTEMS DEVELOPMENT .............................................. 5
Benefits of structured methodologies .............................................................................................. 7
Disadvantages of using structured methods ................................................................................... 7
Examples of structured methods ......................................................................................................... 8
Structured Systems Analysis and Design Methodology (SSADM)............................................... 8
SSADM life cycle ............................................................................................................................... 9
THE SYSTEMS ANALYST’S ROLE IN SYSTEMS DEVELOPMENT ..................................... 10
Formal duties of a Systems Analyst .............................................................................................. 10
Characteristics of a good analyst ................................................................................................... 10
Problems encountered by a systems analyst................................................................................. 11
SYSTEMS DEVELOPMENT LIFE CYCLE .................................................................................. 12
Limitations of the life cycle approach to systems development .................................................. 16
CHAPTER TWO: business analysis and INFORMATION SYSTEMS PLANNING ..................... 18

1
OBJECTIVES ..................................................................................................................................... 18
 By the end of this chapter you should be able to: .................................................................... 18
 Discuss the objectives of IS development .................................................................................. 18
 Identify the components of a business IS strategy ................................................................... 18
 Identify the tasks involved in developing a business IS strategy ............................................ 18
 Identify the competitive strategies used with information systems ........................................ 18
INTRODUCTION............................................................................................................................... 18
BUSINESS ANALYSIS ...................................................................................................................... 18
Levels of understanding ................................................................................................................. 18
Linkage of information systems to business objectives ............................................................... 18
STRATEGIC PLANNING................................................................................................................. 19
Developing A Business/Is Strategy .................................................................................................... 19
Investigating the Business Strategy ............................................................................................... 19
Components of a business strategy ................................................................................................ 19
Vision.................................................................................................................................................... 19
Mission ................................................................................................................................................. 19
Documenting business processes ................................................................................................... 21
Documenting the external business environment ........................................................................ 21
Examining and documenting the current information system provision .................................. 21
Determining the gap between business strategy and IT provision ............................................. 21
COMPETITIVE STRATEGIES USED WITH INFORMATION SYSTEMS......................... 22
CHAPTER THREE: SYSTEMS ANALYSIS ..................................................................................... 24

What is systems analysis? ................................................................................................................... 24
A structured approach to analysis..................................................................................................... 24
Planning the analysis process............................................................................................................. 26
THE FEASIBILITY STUDY ............................................................................................................. 26
Sections of a feasibility report ........................................................................................................ 27
SYSTEM INVESTIGATION/FACT FINDING .......................................................................... 27
METHODS /TOOLS OF FACT RECORDING .............................................................................. 33
DATA FLOW DIAGRAMS (DFDS) ............................................................................................. 33
ENTITY MODELLING ..................................................................................................................... 38
DATA DICTIONARY ........................................................................................................................ 43
ENTITY LIFE HISTORIES .............................................................................................................. 46
QUALITY IN SYSTEMS ................................................................................................................... 49
Quality in the Structured Life Cycle ............................................................................................. 51
Structured Walkthrough ................................................................................................................ 52
Fagan Inspections............................................................................................................................ 54
PROBLEM SPECIFICATION...................................................................................................... 56
CHOOSING SOFTWARE AND HARDWARE .......................................................................... 58
2
CHAPTER FOUR: SYSTEMS DESIGN ............................................................................................ 61

Objectives of Systems Design ............................................................................................................. 61
Design Constraints .............................................................................................................................. 62
Human-Computer Interface design .................................................................................................. 63
OUTPUT DESIGN.......................................................................................................................... 63
INPUT DESIGN .............................................................................................................................. 65
DIALOGUE DESIGN .................................................................................................................... 66
ERGONOMICS AND INTERFACE DESIGN ............................................................................ 70
DOCUMENTATION DESIGN ......................................................................................................... 71
LOGICAL DATA DESIGN ............................................................................................................... 71
DATA NORMALIZATION........................................................................................................... 72
FILE AND DATABASE DESIGN .................................................................................................... 74
File Organisation............................................................................................................................. 74
DATABASE DESIGN .................................................................................................................... 75
PROCESS DESCRIPTION TOOLS................................................................................................. 77
Decision Trees.................................................................................................................................. 77
Structured English .......................................................................................................................... 78
Decision Tables ................................................................................................................................ 80
CASE TOOLS ..................................................................................................................................... 81
PROTOTYPING ................................................................................................................................. 85
DEVELOPING SYSTEMS WITH APPLICATION SOFTWARE PACKAGES ...................... 87
SECURITY AND CONTROL DESIGN........................................................................................... 87
Types of controls ............................................................................................................................. 88
Administrative controls .................................................................................................................. 88
System Development controls ........................................................................................................ 93
Application controls ........................................................................................................................ 97
PROGRAM DESIGN ....................................................................................................................... 104
What’s in a good program specification? ................................................................................... 105
Suggested Program Specification contents ................................................................................. 105
The design specification .................................................................................................................... 106
Contents of the design specification ............................................................................................ 106
CHAPTER SIX: SYSTEMS IMPLEMENTATION ......................................................................... 108

Introduction ....................................................................................................................................... 108
Testing ................................................................................................................................................ 108
Optimization. ................................................................................................................................. 109
File Conversion.................................................................................................................................. 110
Documentation .................................................................................................................................. 111
Training ............................................................................................................................................. 111
Implementation Strategies .............................................................................................................. 111
3
CHAPTER FIVE: SYSTEMS POST IMPLEMENTATION ........................................................... 113

OBJECTIVES ................................................................................................................................... 113
INTRODUCTION............................................................................................................................. 113
Use/purpose of Post Implementation .............................................................................................. 113
What is evaluated? .......................................................................................................................... 113
Benefits of post implementation evaluation .................................................................................... 114
CHAPTER SEVEN: PROJECT MANAGEMENT .......................................................................... 115

Introduction ....................................................................................................................................... 115
Why information systems projects require more planning .......................................................... 115
Project Planning ................................................................................................................................ 116
Project control ................................................................................................................................... 116
Why system development projects fail ............................................................................................ 117
Techniques For Estimating .............................................................................................................. 117
Scheduling Tools ............................................................................................................................... 121
The Gantt chart ............................................................................................................................. 121
The PERT chart and CPA ........................................................................................................... 122
Cost Estimation ................................................................................................................................. 126
Benefits Estimation ........................................................................................................................... 127
COST-BENEFIT ANALYSIS.......................................................................................................... 128
Payback Analysis .......................................................................................................................... 129
Return on Investment Analysis.................................................................................................... 129
Net Present Value Analysis .......................................................................................................... 130
End User Computing (End-User Development) ........................................................................ 135
Information Centers ..................................................................................................................... 138
Distributed Processing .................................................................................................................. 138
Centralisation ................................................................................................................................ 139
Revision Questions ................................................................................................................................ 141
4
CHAPTER ONE: BASIC INFORMATION SYSTEMS CONCEPTS
OBJECTIVES
By the end of this chapter, you should be able to:
 Define an information System and name the types of information systems (IS). applications
 Identify different types of stakeholders who use or develop IS.
 Define the role of systems analysts in development of information systems.
 Describe the business drivers that influence IS development.
 Describe the technology drivers that influence IS development.
 Describe a simple process for developing IS.
INTRODUCTION
What is a system?
A system is simply a set of components that interact to accomplish some objective. It can consist of
tools, suppliers, machines, procedures ad people and requires orderly management.
The two main types of systems are business systems and information systems.
What is a business system?

A business system is aimed at accomplishing specific business goals e.g. a factory is a business system
with the goal of manufacturing products. A business system is usually broken down into smaller
components or subsystems. For example, in a factory business system, subsystems can be: -
- Maintenance of the factory building.
- Controlling the assembly of products that the organization sells.
- Processing customer orders.
- Billing customers.
- Paying employees, etc,
However, the subsystems must be managed in an orderly fashion so as to accomplish the company‘s
goal/mission.
What is an information system?

An information system is a set of components that manages the data needed by a business system and
hence is a subsystem of a business system.
An information system exists only to serve the business system of which it is a component. It keeps
records and maintains the various facts and figures needed to run the business.
Information systems produce the information required by managers to make decisions about the firm
and therefore must satisfy the information needs so that accurate and timely decisions can be made.
5
Example: An information system for the subsystem that bills customers would probably keep track of
each customer‘s name and address, recent sales to the customer, recent payments from the customer and
the total amount the customer owes.
An information system consists of data, people, procedures and machinery (including, but not limited to
computers) as its building blocks.
Importance of information systems

An information system provides a competitive advantage to an organization. That is, an organization is
able to manage its resources better, giving it a competitive advantage over its competitors. Without
accurate and timely information, it is difficult to make informed decisions. The best information systems
can actively contribute to business performance. The concern of managers today is how information
systems and the computers that are part of them can add value by improving employee productivity,
enhance customer satisfaction, boost employee morale and increase profits.
Because information is critical, we need to be concerned about its function, management and
maintenance.
Measuring the success/effectiveness of a recently implemented system

 Does the system achieve the goals set for it? Some of these will be operational running goals
concerned with performance, some will be system goals concerned with production of outputs and
some will be system goals addressing the purpose of the system development.
 How well does the system fit the business structure for which it was developed?
The new system will no doubt have been developed based on an understanding of the present structure
of the organisation and some appreciation of how it might change in the future. However it might not be
an ‗albatross system‘ that hangs around the organisation‘s neck limiting it to movement and freedom to
reorganize. Systems should be designed in a flexible way so that they an meet changing business
conditions.
 Is the new system accurate, secure and reliable? There will be basic requirements for financial
control and auditing but the system should also be robust so as to continue in operation with degraded
performance during partial failure. Security from unauthorised access has also now become increasingly
important with the growth in the development of tactical and strategic information systems.
 Is the system well documented and easy to understand? Increasingly large proportions and of the
budget of systems development departments are being used in the maintenance and updating of the
existing systems. The biggest single way of limiting these expenses in the future is to take account of it
when we design today the systems of tomorrow.
 What is the cost effectiveness of the system?
LEVELS OF MANAGEMENT AND THEIR INFORMATION NEEDS
An organisation‘s management can be classified in three levels:
(i) Operational management

(ii) Tactical management
(iii) Strategic management
2
Operational management
It deals with the day-to-day activities of the organization. These are the basic activities that the
organization must perform in order to remain in business. As such, the role of managers at this level is
supervisory. Examples of activities at this level are order processing, inventory control, customer
billing, production scheduling, etc.
- Information is derived entirely from entirely from internal sources and is relevant in the short term.
- The information is highly detailed (lowly summarized), for example, a report of daily orders,
daily bank deposits, daily list of patients, etc.
- Decisions associated with these activities cover a relatively narrow time frame and are also
delegated to the lowest possible level of the organization where they can be made quickly and
effectively.
- Information is purely based on quantitative data,
- Decisions made at this level tend to be recurring and as a result, the decision making process
becomes routine and structured. A structured decision is one that is predictable and can be made
following a well defined set of procedures, for example in inventory control, clerks will check inventory
levels and reorder previously set amounts for items that have fallen below the reorder point. Executing
an operational level decision gives results that have a high degree of certainty
- The decisions have an immediate but short-term effect on the firm.
Tactical management
This is the middle level management. Managers at this level are concerned with how best to allocate and
control the firm‘s resources. The decisions are meant to implement the goals that the strategic
management has set, for example what credit should we give to each class of customers? Which supplier
should be our main source of raw materials? The decisions made at this level are not as routine and
structured as operational decisions.
The information required to make such decisions is derived from a more restricted range of sources
(though internal) and is relevant to both the short and the intermediate term. The information is also
relatively summarized. The information is also largely quantitative.
Strategic management
It is concerned with setting long-term goals of the firm and therefore the decisions will provide
guidelines on which the firm will run. For example, which strategy do we follow in competing against
other firms? Strategic decisions are highly complex and unstructured. They have a high degree of
uncertainty and as such, demand the most experience and a good sense of judgment on the part of the
managers.
The decisions made here have a long-term impact on the firm and it is difficult to reverse the impact of a
strategic decision. The decisions are directed towards such issues as:
(i) Strategic planning e.g. how the firm‘s growth should be financed and which markets should
be tackled first.
(ii) Allocation of scarce resources.
(iii) Policy formulation.
3
The information to make such decisions is derived from internal and external sources and is highly
summarized. The information may be prepared on demand or ad-hoc basis. It is both quantitative and
qualitative.
TYPES OF INFORMATION SYSTEMS

Information systems are classified according to the level of management they serve. They include:-
- Transaction Processing Systems (TPS).
- Management Information Systems (MIS).
- Decision Support Systems (DSS).
- Expert Systems (ES).
- Executive information systems
Transaction Processing Systems

 They are used for routine processing and mechanization of routine tasks.
 They often involve the updating of master files from transaction files and are unique to a particular
application. They only make decisions based in pre-programmed rules.
 The information used is based in operational data, summaries and measures, which monitor the
system.
 These systems serve operational management.
Management Information Systems

 It collects information used for management planning and control.
 They are used in applications requiring human management decisions; can indicate decisions to
managers, create routine reports, but can provide more detailed reports, if requested.
 They serve all levels of management, particularly middle management.
Decision Support Systems

 Used for semi-structured problems, enabling choices to be defined and evaluated.
 They are also used when planning.
 DSS require interactive access to data.
 They produce recommendations and evaluation of different courses of action.
 They serve mainly senior management, but also anyone making strategic decisions
Expert Systems
 They are used to provide specialist knowledge to decision makers; Used when decisions requiring
scarce expertise must be made. They use a knowledge base, decision rules (inference engine), a
knowledge acquisition program and an interface for user dialogue. The information produced includes
decisions and recommendations.
 They are capable of making non-subjective decisions.
 They can be used by senior managers, specialists and non-expert decision makers.
WHAT IS SYSTEMS ANALYSIS AND DESIGN?

4
Systems Analysis and Design refers to one aspect of the process of creating or modifying an information
system in order to meet the needs and the goals of the given business system.
When a business decides that it has outgrown its current information system, it goes through the process
of analysis and design as it attempts to remedy the problem.
Analysis is the phase in which the requirements of a new information system are identified. It is a
process of gathering and interpreting facts, diagnosing problems and using the information to
recommend improvements to the system.
Design is the phase in which those requirements are used to create blueprints, or actual plans for the new
system. (The word system in this case refers to both business and information systems, since neither can
exist without the other).
Systems Analysis and Design is therefore a process of planning a new business system or one to replace
or complement an existing one.
However, before this planning can be done, a thorough understanding of the old system is required in
order to determine how best computers can be used to make operations more effective.
Analysis specifies what the system should do while design states how to accomplish the objectives.
STRUCTURED APPROACHES TO SYSTEMS DEVELOPMENT

In the late 1970‘s, a number of people in the IT industry begun to consider why so many IS
developments had gone wrong and failed to live up to their promises and, mostly, they reached a similar
conclusion: projects went wrong initially during the analysis phase and efforts to improve the situation
later were usually a waste of time and even more money. Most of these authorities agreed that there was
a need for new methods of analysis and design that would offer:
 Greater formality of approach that would bring systems development nearer to the scientific
method or to an engineering discipline than had been common in IS projects.
 More clarity of stated requirements by using graphical representation as well as text.
 Less scope for ambiguity and misunderstanding.
 A greater focus on identifying and then satisfying business needs
 More trace ability, to enable a business requirements to be followed through initial analysis, into
the business level specification and finally into the technical design.
 More flexible designs of system, not unduly tied to specific technical platforms.
 Much more user involvement at all stages of development.
All the structured methods result from attempts to meet these requirements in one way or another. As a
result, there some features that are common to all structured methods and to the structured approach in
general.
Focus on data structures

Most of the methods concentrate heavily on a thorough examination of the data requirements of the
proposed information system. The reasons for this concentration on data are twofold:
5
 Processing requirements of the organisations can change often and may change significantly,
the underlying data is relatively stable; therefore the data provides the soundest base for the
development process.
 An inflexible data structure can act as a severe constraint on an organisation wishing to change
its systems to match changing requirements. Evolving flexible data structure early during development
yields may benefit later on in the life of a system.
With a sound a flexible data structure in place, it is possible to amend the processing to meet the
changing needs of the organisation.
Use of diagrams and structured English

Another common feature of the structured methods is their heavy reliance on diagrams to convey
information. The reasoning here is that:
 Diagrams are generally easier for people to assimilate than large quantities of text thereby
providing an easier means of communication between users and developers
 It is less easy to commit sins of omission or ambiguity with diagrams; for instance, failure to
mention an important dataflow, on an incorrect statement about the direction of flow, may not be noticed
in along written specification but it will be immediately obvious on a dataflow diagrams.
Together with diagrams, many make use of ‗structured English‘. This aims to reduce the complexity of
the language and reduce the written component of the documentation to brief, terse, unambiguous
statements.
6
Concentration on business requirements

Another important feature of structured methods is the separation of the logical and physical aspects of
the analysis and design process. This is done so that both analysts and developers focus on the business
requirements of the proposed information system, rather than considering too soon the technical details
of its implementation.
So, with a structured method, the developers will focus for much of the time on the business
requirements of the proposed system. They will look at the data needed to support the system and at the
kind of processing which the users will want to support their business. Only once these things have been
clearly established will they consider how these features may be implemented.
Benefits of structured methodologies

 Structured methodologies concentrate on system‘s data requirements. Since these are more stable
than the processing requirements, a system built around a flexible data structure will approve amenable
to change and have a longer life.
 The use of diagrams and structured English improves communications between users and
developers and increases the chances of the users getting the system they really need.
 Because of the rigour/thoroughness and cross checking inherent in structured methods, it is
relatively easy to spot errors and omissions in the analysis which could otherwise lead to problems later
in the development.
 Systems built using structured methods are based on the business requirements and should deliver
business benefits. Technology is not used for its own sake but in support of the business objectives.
 Because technical issues are addresses relatively late in structured development projects, much of
the design will be suitable for implementation in a number of environments. Should the users‘ hardware
or software policy change, it should be possible to go back to the logical documentation and –re-develop
from there for the new platform.
 A system built using structured methods will have complete, rigorous and consistent documentation
which will greatly help in maintaining and enhancing the system over time.
 Using a recognised structured method means that the users are not tied to any one developer. This
means that one could, for instance commission one firm to carry out the analysis and another to produce
the design.
Disadvantages of using structured methods

 Users seem to have to wait for a long time before they actually see any concrete results from the
development such as actual screens or reports. This is because with a structured method, more effort is
expended earlier in the project, during analysis and design and a decrease in the programming effort
(though not testing).
 With a structured method, user involvement is usually explicitly set out and the users will be asked
to contribute to reviews and approvals at various stages. This should result in the production of higher-
quality systems which better meet their users‘ needs. The amount of user involvement must however be
carefully explained at the beginning of the project and the necessary commitment, to the time and effort
involved, must be obtained. In addition, it may be necessary to provide suitable training so that key users
can fully understand the documentation being presented to them.
 Some structured methods remain the intellectual property of their designers and developers who
will provide advice, training, and consultancy and sometimes support tools for their use. The dangers in
this are that one can get ‗locked-in‘ to the single source of supply and that the high prices charged for
the various services may add a considerable extra cost to the development budget.
7
 CASE tools are becoming more widely used in systems developments and some of the structured
methods become very difficult to use without some form of computerized support. The development of
CASE tools has not quite kept up with the development of the structured methods themselves.
Examples of structured methods

 INFORMATION ENGINEERING (IE)
 OBJECT ORIENTED DESIGN (OOD)
 SSADM
Structured Systems Analysis and Design Methodology (SSADM)

The method presents a ‗three-views‘ model of an information system. The method views:
 The data in the system
 The events to which the system must respond
 The functions in the system, as perceived by the users.
SSADM is documented in a set of classic manuals which describe:

 The structure of an information system project, in terms of the modules, stages, steps and tasks by
which the work is tackled.
 A set of analysis and design techniques, to be applied at various stages of the project.
 A series of product definitions, including the quality control criteria to be applied at each stage.
 ‗Hooks‘ so that the method can be coupled with structured approaches to project management and
to programming, mainly to Jackson Structured Programming (JSP)
The major techniques employed are:

 Requirements analysis
 Dataflow modelling
 Logical Data modelling
 User/User role modelling
 Function definition
 Entity/Event modelling
 Relational data analysis
8
SSADM life cycle
USERS DEVELOPERS
TORs, Information, Decisions
FEASIBILITY
TERMS OF
STUDY
REFERENCE
REVIEW OPTIONS
Questions, Options
FEASIBILITY
REPORT
Information, Decisions
REQUIRMENT
ASSIST/CHECK ANALYSIS
ANALYSIS
SELECT OPTION
Questions, Options
SELECTED
BUSINESS
SYSTEM
OPTIONS
Questions
ASSIST/CHECK
SPECIFICATION REQUIREMENT
SPECIFICATION
REQUIREMENT
SPECIFICATION
Questions, Options
CHECK
LOGICAL
LOGICAL
DESIGN
DESIGN
SELECTED LOGICAL
TECHNICAL DESIGN
SYSTEM
OPTIONS
Designs
CHECK PHYSICAL
PHYSICAL DESIGN
DESIGN
Review responses
PHYSICAL
DESIGN
To program specifications,
coding, etc
9
THE SYSTEMS ANALYST’S ROLE IN SYSTEMS DEVELOPMENT
Formal duties of a Systems Analyst

(a) Identify and define the problem area following discussion with the users and management. The
objectives of the project must be clearly studied and the terms of reference agreed and written
down.
(b) Carry out a feasibility study to establish whether a full study of the problem would be worth while.
This findings will include a careful weighing of the costs and benefits of any new system.
(c) Carry out a detailed analysis of the proposed system by employing a variety of analysis techniques.
This results in the Set of Requirements.
(d) With approval from the management, the analyst proceeds to design a computer based information
system to be documented in a design specification.
(e) Guide programs as they write the system‘s programs or recommend the type of packaged software to
buy.
(f) Introduce the new system and prepare a detailed plan for implementation. This will cover file
conversion, training, method of changeover, documentation, etc.
(g) Monitor the system during its early weeks of operation. Thereafter, periodic review will be required
and amendments done on the system when circumstances demand.
(h) Prepare the documentation and plan for user training.
Characteristics of a good analyst

(a) The analyst must enjoy working with people, for he or she must serve as a translator between the
technical staff (such as programmers) and the non-technical staff (users and managers). The analyst
must therefore be able to communicate with the two widely differing audiences; people who frequently
speak computer jargon and people who are baffled by it. Excellent communication skills are therefore
critical.
(b) He/she must be a diplomat and a good motivator

He/she must try to elicit cooperation or enthusiasm from everyone involved in the project, from team
members to users. If an analyst is to build an effective system and then ‗sell‘ it to the users, motivational
skills are required.
(c) Must be able to work in a project team, both as a team member and as a team leader. All team
members must forget their egos, i.e. they must put aside personal prejudices in order to help the team as
a whole function more effectively. As a team leader, the analyst co-ordinates the efforts of programmers,
estimators, testers and other analysts, as well as resolves conflicts and monitors the results of the team
effort. In order to do this, the analyst must be a good manager
(d) Must have well developed problem solving skills

The analyst must be able to identify symptoms, determine the cause of the symptoms, and to find a
solution to the problem. All of this requires an organized approach to problem solving as well as a great
10
deal of creativity. Without organisation, the analyst can easily become overwhelmed by the scope and
details of the problem. Without creativity, the analyst may be tempted to solve new problems with the
same old solutions.
(e) Must be a business generalist, maintaining a broad perspective at all times. A good analyst needs to
know as much about business systems as about computer systems, in order to be able to link the two. He
or she must be able to look at a system from multiple points of view; as a programmer, as a manager, as
a user and as a company financial officer. For example, a programmer might insist that, for efficiency,
she needs to use assembler language to code a particular module. But the analyst having greater
knowledge of how hard an assembler routine will be to maintain in future, must convince the
programmer that perhaps in this case, programming efficiency is not the primary concern.
Problems encountered by a systems analyst

(a) The process of analysis and design is full of ambiguity
There is rarely a right or wrong solution to a design problem. Instead, there are a multitude of solutions,
some more right or wrong than others, and the chosen one if often a compromise. Picking the best
design is not an easy task to analysts.
(b) It is often difficult to choose the appropriate analysis and design tool.
Analysis and design involves choosing among the variety of tools available to the analyst. No single tool
is perfect for all projects. Each project has a different personality and needs to be tackled differently.
Therefore, it is up to the analyst to know what tools are available and choose among them intelligently .
(c) The analyst must keep up with the latest development in the fast changing world of computer
hardware and software.
The analyst should know what is currently available in the market. This is to enable the analyst
recommend appropriate specific hardware and software. This does not mean that the analyst needs to
know every little technical detail about every product as long as he or she knows where to go or with
whom to talk to in order to get the information when it is really needed.
(d) Technology may change quickly but so does the typical business environment.
Analysts may talk of ‗freezing the specifications‘ or not allowing any changes to the requirements after
the project has begun. Yet freezing the specifications is impossible because the business organization
cannot be frozen. New products are always being developed, new government regulations are always
being handed down and new reports are always being needed. For example, no sooner are the
specifications for the general leader system almost done than the revenue authority decides that the
income tax forms will be radically changed, so the specifications for the new system must be changed,
too.
(e) The analyst usually spends more time dealing with people rather than technology.
 The analyst works with individual personalities
People are more ambiguous than the process of analysis and design itself, and analysts must solve more
people-related problems than technology related ones. Every person in the organisation has his or her
personal quirks, prejudices, likes and dislikes. One person may fear a new system because he thinks it
may make his job obsolete and put him out of work. Another one might be afraid she won‘t be able to
learn the new system, thereby making a fool of herself, etc. Most people tend to prefer the status quo; its
far less threatening than something new and untried.
11
 Working with group dynamics

Any time people are put into groups; they tend to form political entities with different goals and
personality conflicts. Employees may align themselves against a supervisor they don‘t like or office
mates may quarrel over who is doing the most work.
The analyst should be aware of the political situation, but should never get personally involved in such
politics because this can affect the implementation of a new system. For example, the person afraid of
making a fool of herself may be too shy to ask necessary questions and might therefore be using the
system incorrectly. A supervisor who distrusts the computer might be passing that message on to his
employees, who then do everything they can to maker the new system fail. On the positive side, if the
analyst gains the support of key people in the organisation, their enthusiasm can often sway those who
are less eager.
SYSTEMS DEVELOPMENT LIFE CYCLE

Information systems of all types go through a predictable series of phases namely-:
- Problem Recognition
- Feasibility Study
- Analysis
- Design
- Construction
- Conversion
- Maintenance
The systems development life cycle is a recognized sequence of tasks, decision points and supporting
documentation leading to the successful implementation of a system.
Problem Recognition
The birth of a new system occurs when managers or/and users realize that an information system is
needed for new business or that an information system for an existing business no longer reflects the
organization‘s functions. For example, a business might have expanded considerably while its
information system remained the same, or perhaps the current information system does not offer
functions that management believes are necessary for the future growth of the business. In any case,
awareness of this inadequacy could come about as a result of a formal review of the system or
complaints from users.
If the differences between the business needs and what the information system can do are sufficiently
serious, management may decide to call in a systems analyst to examine the problem in depth.
Feasibility Study
The purpose of a feasibility study is to define the problem and to decide whether or not a new system is
feasible, spending a minimum amount of time and money in the effort.
During a feasibility study, a systems analyst quickly studies the problem to assess its magnitude and at
the same time, attempts to restrict (or at least identify) the scope of the project. Since a change to one
part of a system can quickly mushroom throughout other areas of the company, it is critical to decide
upfront exactly what will and what will not be included in the current project.
12
The analyst lists precisely what is wrong with the current system as well as what will be required of any
new system. For example, he may indicate the current number of records that the system is able to
maintain. He may also list a set of reports that the management may require but are not available within
the current system.
- The analyst must determine if the needed system is technically, humanly (socially) and economically
feasible for the company.
- Technical questions are those that deal with equipment and software. For example, can a system be
developed using the organization‘s current computer facilities? If the current facilities are not adequate,
are the necessary hardware and software technologies available in the market place?
- The analyst must decide whether the new system is humanly feasible given the organization‘s
personnel. Some of the issues to be tackled are: Are there enough trained personnel to build and install
the system?, If so, is this really the way they should spend their time?, what do users think about the
system?, What is the management‘s opinion?.
- The analyst next determines the system‘s economic feasibility, roughly estimating the time it
will take to develop the system, the cost to build and maintain it, and the benefits it will deliver.
Note: It is impossible to deliver exact estimates in a feasibility study, since the system has not been fully
specified and designed. After the estimates are prepared, the analyst must correlate the costs with the
benefits. Cost-benefit analysis is a procedure for evaluating costs to see if they are justified by the
benefits they deliver.
After management has examined the cost-benefit analysis, it can choose either to abort the project
because it is not worth the cost or to proceed to the analysis phase.
Analysis
If the outcome of the feasibility study is positive, the project continues into the analysis phase.
Next, the analyst defines the requirements of a new system. The analyst uses fact-finding techniques
such as reading existing documentation, examining current procedures and interviewing users and
managers who deal with the system.
- From the existing documentation, the analyst can extract reference manuals, listing of programs,
organization charts and glossaries of error messages. These items reveal to the analyst why the system
was designed in the present structure as well as its strengths and weaknesses.
- Examining the current procedures shows the systems analyst how the system actually works, which
may or may not be the same as how it was intended to work. Procedures can include anything from what
is followed in deciding what bills to pay, to how a clerk enters a vendor into the computer. Watching the
users at work may reveal the problems and the strong points of the system.
- Interviewing users and management allows an analyst to tap the expertise of the people most
involved in the system. These people provide valuable information on what is currently working well
and what is lacking in the present system as well as what is needed from a new one. There may,
however, be some users who are uncertain of what a new system should do, or who are unable to
conceptualize and verbalize it. These people must be interviewed skillfully if the analyst is to extract the
13
needed data. This requires that the analyst must have the communication skills. Without such skills, the
analyst cannot expect to obtain the co-operation that is so vital.
- After the necessary facts are gathered, they are used to complete the analyst‘s understanding of the
current system and the ‗wish-list‘ for the new one.
- Diagrams are made that document the current system. These diagrams are studied as the analyst
considers the functions of the new system. The analyst then prepares another set of diagrams
incorporating the new functions that users need without specifying how those functions are to be
performed.
- The analyst may use the facts that have been gathered to prepare a prototype, which is an
abbreviated version of the new system. A prototype may be developed quickly using systems
development tools such as fourth generation languages.
- The analyst can then show the prototype to users, letting them ‗play‘ with it and make suggestions.
At this point, users can evaluate how close the prototype comes to satisfying the ‗wish-list‘. In some
cases, the prototype may actually evolve into the finished system. In others, the system may need to be
rewritten using more traditional programming tools, such as COBOL or Pascal.
Design
Early in the design phase, the analyst uses the management decisions from the analysis phase to make
final equipment decisions. Purchased hardware and software must be ordered early in the design phase if
it is to arrive on time for the construction phase, which follows.
- Next, the analyst transforms the functional diagrams of the analysis phase into hierarchical diagrams
of the design phase. This transformation allows the analyst to see exactly what programs are needed and
how they are related to one another. At the same time, the analyst evaluates the entire design for quality,
using such criteria as how completely each program achieves a unified function and how straightforward
the user interface is.
- The functional requirements detailed in the systems specification are translated into the plans for a
series of computer programs that will perform the required functions. The analyst decides on program
structure, program interfaces and the hierarchy, or order in which programs will be arranged. While the
analysis phase is concerned with what must be done, the design phase is concerned with how it will be
done.
- Analysts are also responsible for ensuring quality during design. One of the primary tools is the
structured walkthrough, which is a group review of a program or design. Group reviews can find
errors that the program author may have missed. Users should be involved in these group reviews since
they are the people who understand exactly how the new system should perform.
- When designing the programs, the analyst must also incorporate security measures, into the system
to guard against potential errors and computer crimes. Security can include such safeguards such as
requiring passwords for users, keeping backup copies of all files and encoding of sensitive data.
- The Analyst also designs the user interface, including all the input forms, output reports
and the format of displays on terminal screens. Input forms must be designed in such a way that it is it
14
difficult for the user to make a mistake and easy for any data entry person to enter information into the
computer. The primary concerns when designing output reports are clarity and easy of use.
- The analyst designs the procedures to be used, specifying for example, exactly how an input
transaction is entered into the system. The analyst also determines staffing requirements, such as the
data entry people needed and how many hours the computer will be in operation each day.
- During design, a database designer plans a database i.e. data and file requirements. The analyst
works with the designer, clarifying the requirements, but as merely a consultant.
- The Design Specification is the primary output and documentation of the design phase. When
completed, it contains all the information the programs will need.
Construction
In the construction phase, the computer environment is prepared, the program required for the new
system are written and tested and the user documentation and training materials are developed. The
output of this stage is a coded and tested system ready for conversion.
- Early in the stage, the analyst must see the technicians prepare the computer environment properly.
This can entail installing electrical lines and outlets, communications lines, furniture, air conditioning
etc. Finally, the computer hardware is installed and tested, usually by the firm for which it was
purchased.
- The programmers use the problem and design specifications as a guide for writing the programs. The
more accurate and complete the specifications are, the easier the programmer‘s task becomes and the
better the programs will be. If software is to be purchased instead of being custom-programmed, the
programmers may have to modify the purchased system at this time.
- The analyst is not actively involved in programming but must be consulted if the programmers wish
to make changes to the system.
- The analyst helps to plan the testing process, although the actual testing is usually done by
programmers or a testing group. A rigorously chosen set of test data is used to ascertain that the new
system performs as intended and that it is free of defects.
- The analyst supervises the writing of the user documentation and training materials. Documentation
can include user manuals, quick reference guides and on-screen ‗help‘ facilities. Users can be trained by
instructors on a one-to-one or group basis or by tutorial programs run on the computer. Thorough
documentation and training are critical if the new system is to be used correctly.
Conversion
During this phase, the company converts from the old system to the new one. The analyst plans and
supervises the conversion, the data entry staff enters any required data, and finally the operations staff
begins using the system on the specified data.
- In many instances, data files from the old system can be moved electronically to the new system,
using some type of software to direct the transfer. In other situations, particularly if the old system is not
15
computerized, data entry staff must input the necessary data manually. There must be a way of ensuring
that critical data have been entered correctly.
- Conversion can be done gradually, with part of the new system one month, and more of it the next
month, or it can be done abruptly, by turning off the old system and turning on the new one on the same
day. The safest conversion is the parallel operation, where both systems are in use simultaneously, for
some period of time. Both are given the same input data and the outputs are compared to make certain
that the new system parallels the old.
Maintenance
In the maintenance phase, system modifications are made after the system is operational.
Maintenance is necessary for two reasons-:
 Defects in the system when it was delivered.
The system as delivered may have been specified incorrectly; perhaps requirements were missed, or the
programs as delivered had ―bugs‖.
 Changing nature of the business environment.
A system must also continually evolve to keep pace with the changing business environment. The
business may also introduce a new product line that has different information needs than existing
products do. On the other hand, the management may ask for a new report that will greatly aid in
decision making. Whatever, the type of change, the information system must be able to adapt.
The process of maintenance should be controlled by the analyst. When a manager or user suggests a
change to the system, regardless of the reason, the analyst prepares diagrams and estimates of its impact.
Then, the management or a change control board decides whether or not to implement the change. If the
verdict is positive, the analyst modifies all system documentation by merging the diagrams and
estimates into the existing problem and design specifications.
The programmers and testing team are responsible for incorporating any change into the programs and
testing the system to make sure problems have not been introduced as a result of the change. After the
change has been certified to be defect-free, the revised system goes into operation.
Limitations of the life cycle approach to systems development

(a) It is resource intensive
A long time must spent gathering information and preparing voluminous specification and sign-off
documents. It may take years before a system is finally installed. If development time is prolonged, it
may take years before the system is operational. Moreover, a system that spends large amounts of time
and money to build may become obsolete while it is still on the drawing board.
(b) The approach is inflexible and inhibits change

The life cycle approach allows for revisions to the system to ensure that the requirements are met.
Whenever requirements are incorrect or an error is encountered, the sequence of life cycle activities can
be repeated. But volumes of additional documents must be generated, thereby increasing development
time and costs. Because of this possibility, the methodology encourages freezing of specifications early
in the development process. This means changes cannot be made. Once users approve specification
documents, specifications are frozen. However, users traditionally have had trouble visualizing a final
system from specification documents. In reality, they may need to see or use a system to make sure they
know what it is that they need or want. Because this is not possible with the life cycle approach, it is
16
common for users to sign off specification documents without fully comprehending their contents, only
to learn during programming and testing that the specifications are incomplete.
(c ) It is not suited to decision oriented applications.

Decision making can be rather unstructured and fluid. Requirements constantly change or decisions
may have no well-defined models or procedures. Decision makers often specify their information needs
in advance. They may need to experiment with concrete systems to clarify the kind of decisions they
wish to make. Formal specification of requirements may inhibit system builders from exploring and
discovering the problem structure. This high level of uncertainty cannot be easily accommodated by the
life cycle approach.
Some of these problems can be solved by alternative approaches to systems building such as
prototyping.
REVIEW QUESTIONS
1. Why are IS essential in organizations?

2. As an analyst, why should take time to identify who the stakeholders are?
3. What would be consequences of lack of ownership of an IS?
4. Giving examples, discuss the differences between internal and external users.
5. What kind of knowledge and skills are essential for a systems analyst?
6. Discuss the importance of good interpersonal skills to the systems analyst.
7. Discuss the business and technological drivers behind modern IS.
8. Distinguish between:
i. E-Commerce and E-Business
ii. Information and Knowledge
17
CHAPTER TWO: BUSINESS ANALYSIS AND INFORMATION SYSTEMS

PLANNING
OBJECTIVES
 By the end of this chapter you should be able to:

 Discuss the objectives of IS development
 Identify the components of a business IS strategy
 Identify the tasks involved in developing a business IS strategy
 Identify the competitive strategies used with information systems
INTRODUCTION
Information systems are expensive to develop and maintain, so it is clear that businesses do not
commission them for the fun of it. The need of an information system must grow out of some perceived
business requirement and the justification for it must be expressed in business terms.
Often Information system projects do start with clear links back to business plans and strategies. System
developers often take the sketchiest of briefs and start to develop something they think meets the need
only to be surprised when the user refuses to accept it because it does not properly meet their specific
business requirements.
So, before starting to develop a new information system, before even beginning the analysis for that
system, the developers must investigate, document and agree with the users the nature of the business
need and the contribution that the information system is to make.
BUSINESS ANALYSIS
Levels of understanding
A proper analysis of system requirements requires that those carrying out the investigation have a
balance of skills and knowledge.
 A broad based knowledge; of finance, accounting, marketing, production, distribution.
 A more specific grasp of the important features of the particular business being studied. For
example, an analyst working for a chain of shops should have knowledge of the retail sector and be able
to discuss retailing matters knowledgably with the customer
 A broad knowledge of the possibilities and limitation of information technology.
Linkage of information systems to business objectives

There are many reasons why businesses should want to develop information systems but some of the
most common objective are:
 Reduce manpower costs
 Improve customer services
 To improve management information : Management decisions can only be as good as the
information on which they are based, so many computer systems have been designed to produce more
accurate and timely information.
18
 To secure or defend competitive advantage.
STRATEGIC PLANNING
Every organization faces hundreds of problems and opportunities for improvement. Because of scarce
resources and finite organizational capacity to accommodate change, one of the major challenges facing
managers is to decide which of several projects that address possible problems or opportunities should
be initiated – a process called strategic planning (a process of deciding which of several projects to
assign resources)
Developing A Business/Is Strategy

The are a number of tasks that need to be carried out before developing such a strategy:
 The business strategy of the company needs to be analysed, which markets are regarded to be
important, which markets are declining, what changes in the market base are expected and how is the
company going to react to them.
 The current way that the company does business needs to be addressed and evaluated with respect
to the deliverables from the first step.
 There is a need to determine the critical success factors for the business, what are they and how can
they be quantified.
 There is a need to identify the processes which add value to the products or services which the
company provides.
 There is a need to create an architecture which shows how the information systems resources and IT
resources could fit together to satisfy the demand being placed on the company by its strategic plans.
Investigating the Business Strategy

This is the first step and involves a number of activities. Depending on the company, the business
strategy may be embedded in a variety of forms: In a well organized company, the business strategy will
be documented in corporate documents; in other companies this strategy may be held as a mix of formal
documents, informal documents and ideas in senior members‘ minds.
Typical statements which might emerge from an analysis of a business strategy are:
 In the next five years, there will be growth in internet shopping. We intend to take advantage of this
by developing a series of internet sites which are dedicated to each of our core products.
 There will be an increase of 8% of retirees with large quantities of disposable income over the next
five years. We intend to expand our leisure village concept in order to cater foe this potentially
profitable market segment.
Components of a business strategy

A good organizational plan includes the following elements:
Vision
It is the view that the top management has for the future of the company. It is generally expressed in
terms of what the company wants to become and wants to achieve. The vision for the company creates a
model that represents what the organisation will look like and what it will achieve in the future
environment in which it will operate.
Mission
This is the bottom line purpose of the organisation, in other words, why it exists. The mission gives
meaning and substance to the vision and provides legitimacy and purpose for the people who will have
19
to accomplish the vision. Thus, the organisation needs to set goals and objectives, establish a clear
strategy, gain consensus and commitment and successfully implement projects that help to achieve the
vision.
 Goals
These are broad statements of the end results that the organisation intends to achieve in fulfilling its
mission.
 Objectives
They are specific and tangible measures of the results that the organisation wants to achieve.
 Strategies
These are statements of how to reach the vision and achieve the organization‘s objectives. The strategy
implemented by an organisation is bounded by resource limitation and the perceptions, imagination and
the boldness of its leadership. The difference between a successful and unsuccessful strategy is an
organisation lies in how well it addresses the realities of its environment; how well it uses what it has to
work with and how well it compensates for its limitations.
 Critical success factors

These are the things which have to be put right in order for the business objectives of the company to be
achieved. For example, a manufacturing firm, competing with companies who are reducing their defect
rates, will regard the reduction of defect rates as a key critical success factor.
 Consensus and Commitment

The leadership of the organisation must agree and be dedicated to help achieve the vision and mission.
 Business drivers
These are the forces for change that a company needs to respond to. These include drivers such as an
increased market share or a reduction of costs.
Example : Vision, mission, goals, objectives and strategies for Fortune100 Company.
Vision
We are a company strongly oriented t0o research – to search for a breakthrough and innovative
production. We are a company on the move – a company with the critical mass of financial strength of
scientific research, of marketing expertise, and of existing and future production to meet the global
challenges we face and to give us significant growth.
Mission
We are a company dedicated to enhancing life from pharmaceutical products we make and market, to
the consumer, health care, and the nutritional products we will continue to develop and sell.
Goals
- Achieve global prominence in our pharmaceutical, consumer, medical and nutritional business.
- Firmly establish the company as one of the major world‘s truly research – based companies with a
commitment to excellence in biomedical science that is recognized by the medical and scientific
community around the world.
Objectives
20
- Achieve better than 15% annual compounded increase in per share earnings, along with continuing
attention to gain improvement and increase or maintenance of market share.
- Achieve product leadership in our core business, both in the UK and in the key foreign markets.
Strategies
- Co-ordinate sales and marketing activities and the scope and quality of the combined
pharmaceutical research and development effort.
Improve efficiency in the administrative and manufacturing areas of the company throughout the world
to produce savings that will provide additional resources to invest in the company‘s future growth.
Documenting business processes

Once a business strategy has been established, the next step is to document the individual processes that
make up the business. This involves the documentation of the tasks and documents required for a
business process, the decisions that need to be made and the people making them, and the outputs of
these processes. For example, a process such as the approving of a loan in a banking system.
Documenting the external business environment

This looks at the way the world outside the business is working and how it may work in the future. This
involves looking at:
 The effect that new technology is having and might have on the sector in which the business is
working.
 The effect of government policy changes.
 The way competitors conduct business.
Examining and documenting the current information system provision

Here the company evaluates what current applications have been computerized, which systems are in
place, what the skills of IT personnel are, etc. It should also include systems that are under development.
From this, some conclusions such as the following might emerge:
 That there is some duplication of data between a number of applications.
 That there are major differences in the time that data is processed between applications.
 That some data processes are well supported by while others are less supported.
 That a number of core processes are little supported by IT.
Determining the gap between business strategy and IT provision

It involves comparing what IT resources that company has to the way in which the business will conduct
itself over its strategic horizon. This will result in a number of plans for change.
Typically, the gap analysis will identify:

 Business processes which are carried out manually that can be computerized. These will range fro
those processes which are routine to those which could greatly affect the business in the future.
 Business processes which are computerized but which are slow in duration.
 Those information requirements of management that are either not satisfied or are incompletely
satisfied by the information systems that are currently being operated.
 Strategic requirements that cannot be satisfied by the current set of applications.
21
COMPETITIVE STRATEGIES USED WITH INFORMATION SYSTEMS
(i) Reduction of the cost of a product or service

This strategy is based on the hypothesis that market success depends on the price of a product or service.
Usually, the firm with the lowest price will become dominant in the market place and this leads to
discounts and economies of scale, which will in turn reinforce its position as the producer with the
lowest costs.
This strategy is known as the Market Share or Market Position strategy and the result is a strategy that
minimizes costs and allows the product to be sold at a price equal or less than the competition.
Computerization may contribute to this strategy by reducing:-
- The direct unit cost of a service or product
- The overall overhead costs associated with the production of that product or service.
(ii) Increasing revenues by offering a competitive advantage
This aims to produce a product/service differentiation, which permits the company‘s product or service
to be successfully differentiated from its competitors. This differentiation is often achieved though
service or product quality and usually provides an organisation with a competitive edge.
In many markets, customers expect to be provided with accurate up-to-date information. This may not
be essential for the running of the business, but a failure to offer such a service is likely to reduce the
firm‘s competitive position.
This approach effectively ties customers into the products information systems and hence achieves a
competitive edge by making it more difficult for customers to switch suppliers.
(iii) Provide a market or image differential
This strategy defines the way in which the firm will differentiate itself from competition in the eyes of
the customer.
Customers/purchasers are often affected by the image of the product or services offered. Marketing and
promotion campaigns project to appeal to a particular market niche.
Systems may be used to help create and reinforce this image though improving product presentation and
quality.
(iv) Provide organizational growth
This is concerned with the selection of those areas in which a firm wishes to undertake business in the
first place. It is concerned with the analysis of the product and market opportunities available to an
enterprise beyond the scope of its current objectives. This selection is called Portfolio Analysis and
helps decide whether the firm should easily diversify or expand in some way in order to achieve the
primary objective.
REVIEW QUESTIONS
1. What is the importance do the following general concepts have for the systems analyst? Give
examples of each as they apply to IS.
a. System boundary
b. System environment
c. Feedback
d. Open system
e. Closed system
22
f. Subsystem
g. Interface
h. Performance standard
2. What is the impact of IS on our everyday activities? Where has the greatest impact been on
business?
3. In what ways has the use of IS become strategic to industrial growth?
4. What is meant by ―working smarter‖, and how is it encouraged through effective use of IS?
23
CHAPTER THREE: SYSTEMS ANALYSIS
OBJECTIVES
 By the end of this chapter you should be able to:

 Define systems analysis
 Identify and discuss the merits of using structured methods
 Discuss the stages of the SDLC
 Identify the general quality principles as applicable to organizations.
What is systems analysis?

The Oxford Dictionary defines analysis as ‗the separation of a substance into parts for study and
interpretation; detailed examination.
In the case of systems analysis, the ‗substance‘ is the business system under investigation and the parts
are the various sub-systems which work together to support the business. Before designing a computer
system which will satisfy the information requirements of a company, it is important that the nature of
the business and the way it currently operates are well understood. The detailed examination will then
provide the design team with the specific data they require to ensure that all the client‘s requirements are
fully met.
The following guidelines will assist the analyst during analysis:

 Check and agree the terms of reference before beginning your work.
 Involve the client as much as possible, both formally and informally, in developing your
understanding of the system.
 Don‘t take information at face value.
 Be prepared for some resistance. The analyst is concerned with change and this is uncomfortable
with many people.
 Be aware of political issues in the organisation, but don‘t get involved.
 Remember that ownership of the system must always stay with the users.
A structured approach to analysis

Analysis can be considered to be a four-stage process.
1. Understanding the current physical system. This will involve fact finding activities and the recording
of information about how the current system operates. As part of this process, the analyst will also be
constructing models to show the data and the processing within the system as well as documenting
problems and requirements as described by the users of the system. The users are required to review and
agree the analysis results.
2. The next stage requires the analyst to move away from the constraints which determine how the
current system is physically implemented, and to put together a clear picture of the logical functions
carried out by the system. In other words, to state exactly what the system is doing rather than how it is
doing it. This view is described as the current logical system. Again, the users are asked to review and
agree the logical system description.
24
3. The required/new logical system. The customer‘s requirements for a new information system must be
mapped onto the current logical system. This will state what the new system will do. By discussing the
requirements with users who specified them, priorities can be assigned and a number of alternative
versions can be presented of the required logical part of the system proposal
4 The required physical system. This involves specifying in detail exactly how the system will work. All
the business requirements are transformed into a physical design for implementation on a specific
hardware and software platform. As the issues dealt with here are mainly technical, user involvement
will be less than during earlier stages, but user approval must still be obtained to the final specification.
CURRENT LOGICAL SYSTEM
REQUIRED LOGICAL SYSTEM
REQUIRED PHYSICAL SYSTEM
Structures systems analysis, which is based on the four-stage model described above also has associated
with it the following principles
 Modelling
 Partitioning
 Iteration
 Documentation
 Review
Modelling refers to the use of graphics models which are employed wherever possible, in place of
narrative text, to provide clean and unambiguous information about the system.
Partitioning describes a method of breaking the system down into a number of smaller oparts so that it
can be more easily understood, so that work can be allocated to the members of the project team. The
system is first considered as a whole to establish the system boundaries. Once these have been agreed
wit the users, the system is portioned on a top-down basis.
Iteration: Since it is unlikely that the first representation of the current system and the requirements for
the new system will be completely accurate the first time, structured systems analysis provides
opportunities for revisiting and amending the models of the system. If this iteration of the process of
analysis is carried out in close consultation with the users, it will ensure that our understanding of the
existing system is correct and agreed with client before development of the new system begins.
25
Documentation: Keeping a written record. It is hard to control a project that is recorded only in the
memories of the team members. Team members are not necessarily permanent. Consistent and up-to-
date documentation serves as a permanent record of all aspects of the project. Without written
documentation, it becomes difficult to train new project team members, to verify the project is fulfilling
its original goals and to determine if it is on schedule.
Review: Using the diagrams of the finished system to uncover errors or misconceptions before they are
incorporated into the end product. This is because, it costs less to abandon or change a system that exists
only on paper. In contrast, finished systems are expensive to modify or even costly to throw away. The
earlier in the project life cycle that the problems are uncovered, the less expensive they are to repair.
Therefore the validation process must begin during the feasibility phase and must continue during each
of the phases that follow.
Planning the analysis process

As part of the planning process, analysts must ensure that:
 They understand the objectives and terms of reference agreed with the client.
 They are aware of the constraints which impact the analysis process.
 They plan the research, initial contact and other tasks to be completed during the investigation and
manage time appropriately.
Objectives and terms of reference

To understand more about the client‘s expectations, you need to ask a number of key questions at the
beginning of the analysis phase of the project:
 Who initiated the project?
 What is their role in the organisation?
 What are their objectives for the project?
 What are company‘s objectives?
The main areas of the terms of reference are:

 System boundary - This will define the area of the organisation under investigation and may also
specify the limit of any new system implemented as a result of the project
 Constraints – Factors, including budget, time scale technology, which may restrict the study, or the
solution in some way.
 Objectives:- An ambiguous statement of the expectations of those in the client‘s organisation who
have initiated the project. These may be broken down by function of department. Well defined
objectives are clear and measurable.
 Permission - This will indicate who in the client‘s organisation is responsible for the supervision of
the project and, if permission needs to be granted – for example to extend the scope of the analysis –
who has the authority to do so. Points of structure and the appropriate reporting structure may also be
defined.
 End products- A clear description of the deliverable or end products of the investigation. This will
usually take the form of a written report and a supporting presentation to the managers of the client
organisation.
THE FEASIBILITY STUDY

A Feasibility study is a small scale analysis and differs from a full analysis in the level of detail. The
results of the study helps the user to decide whether to proceed, amend or postpone or cancel the project
particularly when the project is large, complex and costly.
26
Analysts should concentrate on providing answers to four key questions:

How much? The cost of the project
What? The objectives of the system
When? The delivery timescale
How? The means and procedures used to produce the new system.
During the feasibility study, a number of structured techniques can be used to record the findings in an
effective way, and later to present data in a graphical form. At the end of the study a report is prepared
for the client.
The feasibility study report has to address three levels of feasibility:

 Technical feasibility Is it going to work?
 Business/Economic feasibility Are cost and timescales right for the business and will
potential returns justify the initial outlay?
 Functional specification Will the solution satisfy the end users
Sections of a feasibility report

 Background
- Terms of reference
- Reasons for the study
 The current situation
- Overview of current situation
- Problems and requirements identified
 Proposed solution
A description of the requirements of a new system along with a number of options explaining how this
situation might be implemented. Each option will address:
- Technical implications – how it meets the requirements, the hardware and software needed.
- Operational implications – The impact the solution will have on the business in terms of human,
organizational and political aspects.
- Cost implications – Both initial (capital) and continuing (operational)
 Cost/benefits analysis
A comparison of the costs and benefits prepared using whatever evaluation technique is favoured by the
organisation.
 Recommendations
- Summary of the previous section of the report
- Recommendations as to how the client should proceed; either:
(i) Progress with the full detailed analysis
(ii) Review the terms of reference or the scope of the study before proceeding further or making any
judgement on feasibility
(iii) Scrap the project as it is not feasible, that the resources could be better spent elsewhere.
SYSTEM INVESTIGATION/FACT FINDING

Various methods are used to gather facts about the existing system:
 Documents inspection
 Questionnaires
 Interviews
 Observation
27
 Sampling
(The first four are the most popular and are discussed below).
Interviewing
In this technique the analyst personally questions managers and users about the current system and
solicits their opinions about any new system.
Principles of interviewing
-The analyst must display a likeable character to the user. A user who dislikes an analyst will almost
certainly dislike the proposed system regardless of its merits. Good user-analyst relationships can
contribute to the success of new systems.
- The analyst must project an image of sincerity to the user. We must try to show that we want the user
to solve his or her problems. The concept of user involvement is critical in systems development today.
- During the interview, the analyst should never offer opinions, suggestions or promises. An interview is
only a fact-finding session. Solutions are premature. Rash promises may return to haunt the analyst by
causing deep embarrassment. The best thing is to make a sincere, but general promise.
- The analyst must always behave professionally. He must remain in control of himself; without
antagonizing the user or showing anger.
- The analyst should not apply a rigid approach to the interview, since the clients as individuals have
unique personality. A method or attitude that may work with one client may fail dismally with another.
- The analyst needs to be aware of the environment in which he is working. A business has its own
politics and as such the analyst should avoid any involvement in such internal affairs.
The following points are important to remember as an analyst prepares for an interview with any user or
client.
 He should obtain copies of all reports that could be discussed during the interview session.
 Make an appointment at a convenient time and confirm the appointment with the client before the
interview.
 Define objectives, specifically what information needs to be obtained in order to concentrate on
those areas that are most important.
 The questions should be limited so that the interview takes one hour or less, since any longer tires
the client and the analyst too.
 The analyst should allow the user sufficient time to prepare so that he (analyst) can have verifiable
statistics rather than just estimates for some facts.
Conducting the interview

The interview can be conducted in one of three places: the client‘s workplace, the analyst‘s office, or a
neutral area such as a conference room. Using the client‘s workplace has the advantage of putting the
client at ease. On the other hand, the client might be distracted such things as phone calls and visitors.
Using the analyst‘s office may eliminate the distractions but may have the effect of intimidating some
clients. A neutral area such as a conference room may be less intimidating, yet still minimize
distractions.
28
- The analyst sets the interview tone. A good first impression is likely to last and therefore the analyst
should strive to make each impression a good one.
- The analyst should explain the purposes of the interview; first that the client has the business
expertise that the analyst lacks and second that they must both work together to develop an effective
system. The intent of this introduction is to convince users that the system will be their system, not the
analyst’s system. This introduction can lay a good foundation for trust and cooperation. The client
should also be assured that any specific requests for confidentiality will be honored.
Question and Answer period

-The analyst must have some means of recording the information gathered from the client. As he takes
notes, he should maintain eye contact as much as possible. Alternately, he can use a tape recorder
because it frees the analyst so as to be able to maintain eye contact and concentrate on what the client is
saying and how it is being said.
- Questions should be slanted towards the duties and responsibilities of the clients; abstract, policy
directed questions directed to a manager; more detailed procedure-directed questions to a clerk. We
could ask a company vice-president about the company policy regarding bad-debt collection, but we
should ask a clerk about the precise procedures used to determine what is a bad debt and how to collect
it.
- The analyst can start with broad and open questions, such as questions to do with clients‘
responsibilities and duties. This is an area which the clients are quite familiar with and would enjoy
talking about. As the interview progresses, the questions should become increasingly specific. The
‘specific‘ approach will mean asking many questions, but will also garner more detailed and useful
information.
- After posing a question, the analyst should listen to the answer. Rather than listening carefully to the
answer, picking up shadings of meaning and undertones as well as the overt response, an analyst may
instead be interpreting the answer to suit some perceived notion or be thinking ahead to the next
question. This may lead to wrong deductions being made.
- The analyst should not accept superficial answers to questions. If he does not understand the answer
or he feels it is incomplete, he should probe for more information.
- The analyst should also observe the non-verbal communication of the client, for instance, does the
client sit with open arms and uncrossed legs? If so, this might signify that the client is relaxed and open
to ideas. On the other hand, a closed posture and crossed legs could mean nervousness. Eye contact can
also give clues as to what the client is thinking
- The analyst must avoid doing more talking than listening and asking leading questions. The types of
questions depend largely on the objectives of the interview. Appropriate questions may deal with system
controls, current job practices, analyses of work volumes, data that are available or not available to the
client, data sources, data timeliness and accuracy and future information requirements.
- In addition to factual questions, the analyst should ask the client to evaluate and criticise the current
system and offer suggestions for the new one. The analyst should also allow the client to raise any
further points which the analyst may have missed.
After the interview:-

- The conversation should be transcribed immediately (before the conversation is forgotten). The
transcript should be written on a word processor with a narrative or question-and-answer format. This
should include the information considered to be important from the conversation.
- A copy of the transcript , with a thanks acknowledgment should be sent to the client for final
verification. The transcript should also be made available to other project team members.
29
- The final stage in interviewing is analyzing the information collected to judge how accurate and
unbiased it is.
Advantages of interviews
- They provide instant feedback.
- Closer contact between analyst and interviewee. Both can ask clarification for questions and answers
- Helps overcome the fears and resistance to change that may be felt by the employees and to gain
their trust
- Most appropriate for senior executives, who will have views about what the new system should
achieve overall, and who will have particular information needs, but who are unlikely to be greatly
involved in its day-to-day operation or concerned about the detail of how it does what it does.
QUESTIONNAIRES
Sometimes the user are remote from the analyst. Indeed from the development of products for an
anticipated for an anticipated market, the users may not be accessible at all. In these circumstances,
questionnaires can be used to gather facts, attitudes and some suggestions about the system.
Questionnaires are inevitably limited in the information detail that can be collected when compared with
interviews. However, they are valuable in acquiring information from a large sample of users.
The adoption of questionnaires as a fact finding tool is not as straightforward as the inexperienced
systems analyst might assume. It is wise to give careful consideration to their employment/application
and design.
Situations Suited To Questionnaires

 Where the systems analyst is located at considerable distance from the staff to be questioned e.g.
managers for the widespread branches.
 Where there is a large number of respondents such that interviewing is prohibited by the time
available e.g. a large sales force.
 As a means of verifying information found by other methods. The questions in this case must be
framed so as to avoid leading the respondent.
 When the questions are simple and call for direct answers, preferably when they are to be selected
from a list of answers shown on the questionnaire i.e. multiple choice.
 When a full set of replies is not necessary in order to determine the facts. People tend to give low
priority to filling out questionnaires, and therefore the response is rarely 100 percent. The sample
returned must, however be large enough to provide a reasonably accurate picture of the situation.
Guidelines to questionnaire design

 Clearly explain the purpose of the questionnaire
 Phrase the questions so that they are unambiguous, concise and unbiased
 Avoid long questionnaires with many different types of information being sought.
 Machine readable questionnaires should be used if at all possible. This permits accurate and
faster tabulation of results. It also dictates using a special machine-readable form as well as limiting the
questions to either true/false, multiple choice or ranking type of answers. Open (essay questions) must
be evaluated manually.
 The surveyor should use terminology the same way it used by the organization. For example an
employee called a sales representative by one organization is called a territory manager by another. It
requires sufficient time to learn the organizational vocabulary before constructing a questionnaire.
30
 Test the wording and structure of the questionnaire and ask sample respondents to explain their
understanding of each question.
 Decide how the results are to be analysed beforehand. A questionnaire can be set out in a way
which permits direct input of answers into a computer system, where results can be analysed with an
appropriate statistical package.
 Impose a deadline for the response and include a prepaid envelope for postal respondents.
 Group questions by topics and structure the questionnaire so that the questions and groups follow
a logical order as far as possible.
 Give instructions for answering questions, and if the reply set is known, then make this explicit
and ask the user to underline or circle their choice , e.g. please select one of the following:
novice/experienced/expert.
 Avoid biasing the answer in a question.
 Design the questions; A list of open and closed questions can be used, although it is useful to
restrict the scope of open questions so that the questionnaire focuses on the area under investigation.
Advantages of questionnaires
 It is relatively cheap, particularly when there is a scattered group of users and operators.
 It is free of interviewer distortion and error.
 It permits time to refer to documents and documentation. Questions which concern detailed
factual data e.g. How many customers live in the South West? Are suited to questionnaire collection.
 It may be possible to ask more personal and controversial questions particularly is the
response is to be anonymous.
Drawbacks
 Low response rates to the questionnaire may lead to unrepresentative responses being analysed to
draw incorrect conclusions.
 Lack of direct contact with the analyst may mean that questions are interpreted in different ways.
There is no opportunity to clarify ambiguities unless a follow-up visit or phone call is made.
 There is no possibility of the analyst observing the user‘s work place or work practices.
RECORDS SEARCHING AND DOCUMENT ANALYSIS

Time constraints can prevent systems analysts from making as thorough investigations of the current
system as they might wish. Conclusions can be drawn from a sample of past and present results of the
current system. It involves looking through written records to obtain quantitative information,, and to
confirm or quantify information already supplied by the user staff or management. Information can be
collected about:
- The volume of the file data and transactions, frequencies and trends
- The frequency with which the files are updated
- The accuracy of the data held in the system
- Unused forms
- Exceptions and omissions
The major objective of this exercise is to determine how accurate the documentation is ; has the
organization made any attempt to update it as its methods have changed. Therefore the documentation's
age is a clue to reliability; the older it is, the less reliable it is likely to be.
31
Using this information, as assessment of the volatility of the information can be made and the usefulness
of the existing information ca be questioned if it appears that some file data is merely updated, often
inaccurate or little used. All of the information collected by record searching can be used to cross check
information given by the users of the system.. While this does not imply that user opinion will be
inaccurate, discrepancies can be evaluated and the reasons for them discussed.
Where there is a large number of documents, statistical sampling cam be used. This will involve
sampling randomly or systematically to provide the required quantitative or qualitative information. This
can be perfectly satisfactory if the analyst understands the concepts behind statistical sampling, but is is
a very hazardous exercise for the untrained. One particular misleading notion is to draw conclusions
from a non-representative sample. Extra care should be taken in estimating volumes and data field sizes
from the evidence of the sample.
When inspecting the data flow through a system, we can collect documents which show how this
information is organized. Such documents might include reports, formal lists, organization charts and
forms. In order to understand the purpose of a document in an organization, the analyst must ask
questions about how, where, why and when it is used. This is called document analysis
Observation
Here, the analyst observes in person the current procedures. This shows us how the system really
operates, as opposed to the theoretical procedures detailed in the system documentation. In many cases,
there is little resemblance between the two.
The following issues are pertinent if observation is to be employed for fact gathering:
- Before beginning, we should get permission from the person to be observed and the supervisor.
- Planning our observation in order to take note of the cross sample of the variety in a procedure such
as when work volume is high, low or moderate and unusual conditions, like what happens when
there is a special order from a customer.
- An explanation to the people we are observing is also necessary. They need to know that we are not
evaluating their personal job performance, but instead trying to understand job procedures and
incorporating them, changed or unchanged into the new system. We should solicit the people we are
observing for their opinions on the current procedures. This is because they will be the people most
affected by the changes we might make.
- Observation should not interrupt or disrupt the activities in progress. By observation, analysts
change the environment that they observe. Their presence makes the people they are watching to
behave differently; being nervous and self-conscious, people work more conscientiously than they
normally would, or they may panic and may do it more carelessly. For instance factory workers
under observation might follow safety regulations than they would otherwise ignore.
- Participatory observation in which the analyst actually performs the activity in question can be a
valuable fact gathering technique. Learning by observation can help one understand more thoroughly
than passive observation can.
32
METHODS /TOOLS OF FACT RECORDING

The analyst collects a considerable amount of information during the investigation phase which may
include interview reports, observation records, sample documents, completed questionnaires and a list of
problems and requirements. Some of these relate to the current system, and some to the new system
required by the client.
It is important for the analyst to record this information in an unambiguous, concise manner which will
be clear and accessible to others and which can be used by other analysts and designers involved in
developing the new system. Structured techniques were developed to help system developers to record
information in this way, using diagrams (or popularly known as models) and a limited amount of text.
Structured techniques are used to model the existing manual or computer system using information
gathered from users. These models are then modified and extended with new user requirements in order
to produce new models of the new, required system. The model of the required system is based on the
current system because there is usually a core set of processing which will still be required unless there
has been a drastic change in the way the enterprise operates. The data held by the existing system is
unlikely to change although in most cases new data will be required.
Data Flow diagrams and Entity models are two useful tools or techniques.
To create and edit these diagrams, the analyst will also have to make use of CASE tools and data
dictionaries.
DATA FLOW DIAGRAMS (DFDS)

The data flow diagram is the primary graphic tool in the analysis phase of the systems development life
cycle. Analysts use DFDs to show what happens to data items as they flow through a system. In other
words Its is a model of the processes that transform data in a system. DFDs can be understood by uses
and are less prone to misinterpretation than textual description. A compete set of DFDs provides a
compact top-down representation of a system which makes it easier for users and analysts to visualize
the system as a whole.
DFD Components
Entity
External entities represent the sources of data that enter the system or the recipients of data that leave the
system. Examples are clerks who receive and enter the data into the system or customers who receive
the letters produced by the system.
Since the entities are not part of the system with which the DFD is about, we are not concerned with the
internal workings of an entity, only the data it supplies or receives.
Symbol:
Customer
e.g.
Data Store
Data stores represent stores of data within the system. Examples are computer files and databases, or in
a manual system, paper files in filing cabinets. They are drawn as open-ended rectangles with a unique
33
identifier, a box at the closed end and the name of the store I the open section. Manual data stores are
identified by the letter M followed by a number and identifiers for computerised stores are prefixed by a
D.
A data flow entering a data store indicates an Update (Add, Change, Delete) to the file, while a data
store from a data store indicates a Read activity.
e.g.
Order
Data Flows
They represent the movement of data between other components, for example a report produced by a
process and sent to an external entity. They are shown as named arrows connecting the other
components of the diagram. Data flows are generally shown as one-flow only
e.g.
Stock Evaluation Report
All flows must either begin or end at a process symbol. In logical DFDs, no two data flows should have
the same name. If two flows, separated by a process, appear to be identical, then it is likely that the
process that separates them is not transforming data in any way and so should be discarded. Data flows
moving out of stores do not necessarily require names because the store name may be sufficient to
describe them.
Processes
Processes are transformations, changing incoming data flows into outgoing data flows. In other words, a
process is work that must be done or a function that must be completed. They are shown as larger
rectangles with a numeric identifier in a box at the top left corner. The location where the process takes
place is recorded in a box in the top right corner and is only used in diagrams of the current physical
system. The name of the process is recorded in the remaining area at the bottom. Process names should
be unambiguous and should convey as meaning as possible without being too long. In general, names
should take the form of an imperative and its object e.g. ‗Open Account‘. Generalised verbs such as
Process or Update are not usually helpful. The name of a process tells its general function.
Symbol:
e.g. 2 Sales Dept
Compare
invoice
Note:
(i) A data flow is not permitted between (to or from) a data store and another data store or a data
store and an external entity, only between a data store and a process.
(ii) A data flow is not permitted between (to or from) an external entity and another external entity
or an external entity and a data store, only between an external entity and a process.
34
(iii) Data flows are permitted between processes and data stores and external entities.
(iv) Note: A boundary is sometimes drawn around a DFD to show (perhaps arbitrarily) the limits of
the system which is being charted.
DFD Hierarchies/levels
A system is rarely simple enough to be shown on a single DFD and so a hierarchical set is produced.
This consists of a top – level DFD in which the processes are major system described in more detail by
one or more associated lower-level DFDs. The process of breaking down a higher – level (parent) DFD
into its constituent lower-levels (child) DFDs is known as leveling.
Example:
Level 1 DFD for a library system
Reservation Card
Delivery note
4 Loans Counter
Lend Books Loan

Details
Supplier
1 Acquisitions Book
Order Recall
Acquire Books Reservation
Supplier Book
Borrower
Details
D1 Book
Catalogue
Membership
Details
M1 New
Acquisitions D2 Borrowers
Advertised Book File Membership
Details
Card
2 Cataloguing 3 Loans Counter
Catalogue Books Register Borrowers
Publications
35
Level 2 for lend books
D2 Borrowers File
4 Lend Books
Borrower
Details
Loan
Details
4.1 Loans Counter 4.2 Loans Counter

Book Details
C
Borrower Record Loan Record Reservation
D1 Books
catalogue
Reservation
D4/1 Loans File
Book Retail
C
Borrower
Loan Retail
Reservation Card
4.3 Loans Counter
Record Returns D2 Borrowers File
Borrower Details
Book Details
D1 Books
catalogue
A context diagram is similar to a top-level DFD but with the whole system shown as ‗black-box‘. In
other words, external entities and data flows in and out of the system are drawn but no processes or data
stores are shown. They are used early in a project as a means of describing and agreeing the scope or
boundary of the system to be developed.
36
Context diagram (Level 0 DFD) for the library system.
Supplier Publication
Delivery Note
Order Advertiser
Book Details
Supplier
Book Details
Library System
Loan
Details
Reserva-
tion card
Member-
ship Card
Book Borrower
Recall Details
Reservation
Borrower
Advantages of DFDs
(i) Simple to draw since they use only a set of four standard symbols.
(ii) They help substantiate the logic underlying the data flow of the organization
(iii) Identification of error (in structured walkthroughs).
(iv) They give an overview of the system as a guide to later fact finding.
(v) They show in detail how the system works from overview to minute detail using the leveling
technique.
(vi) They demonstrate in overview terms how various solutions might appear.
37
ENTITY MODELLING
An entity model represents the network of relationships between classes of things which need to have
data recorded about them in the system. The term ‗entity‘ or ‗entity type‘ is used to describe a ‗class of
things‘. Having a drawn an entity model, it is possible to show how the system can use these
relationships by following them as paths for obtaining related pieces of data either for update or for
reporting and enquiry purposes
One of the commonly used diagrams in entity modelling is the Entity Relationship (ERD) / Logical Data
Structures.
Entity relationship models use 3 major abstractions to describe them. These are;
(i) Entities: These are classes of distinct things about which data is recorded in a system. It is usually
represented as a rectangle containing its name, written as a singular noun.
(ii) Relationships: - Meaningful interactions or associations between the entities e.g. an entity
department may be associated with an entity employee via a relationship employs.
They are shown as lines linking entities. They can be traversed in both directions and so each end of the
relationship is named in order to describe it from the point of view of the entity at that end.
(iii) Attributes: - These are the properties of the entities and relationships. A descriptive value associated
with an entity e.g. Employee Number, Employee Names might to be attributes of the Employee entity.
The ER modelling , an entity is usually represented as a rectangle
The degree of a relationship

The degree of a relationship specifies the number of relationships in which an entity can appear. The
degree can be:
(a) One - to - One (1:1)

For any entity type A, there may only be one member of entity type B and for any entity type of type B,
there is only one member of entity type A associated with it.
e.g.
Works for
MANAGING
DIRECTOR COMPANY
employs
One – to- one relationships are uncommon as it is usually found that two entities which are linked in this
way can be combined to form a single entity.
(b) One to Many (1:M )

For any entity A, there may be many members of entity B and for any B, there is only one member of
A associated with it.
e.g.
comprises COMPANY
DEPARTMENT EMPLOYEE
38
works in
( c) Many to Many (M:N)

For any A, there may be many members of B and for any B, there may be many members of A
associated with it.
e.g. Made of
PRODUCT RAW
MATERIAL
Part of
Note: Whenever the degree of a relationship is many to many, we must decompose the relationship to
one-to-many or many -to-one. The decomposition process will create a new entity.
e.g.
BOOK BORROWER
BOOK BORROWER
LOAN
Relationships can also be classified in terms of their optionality. Optionality is where the analyst
considers whether an entity occurrence at one end of a relationship can ever be present in the system
without the presence of a corresponding occurrence of the entity at the other end of the relationship.
e.g.
a) responsible for
Doctor Patient
registered
with
39
b) responsible for
Doctor Patient
registered
with
c)
responsible for
Doctor Patient
registered
with
d)
responsible for
Doctor Patient
registered
with
From the above entity occurrence diagrams:

a) A doctor must be responsible for one or more patients and a patient must be registered with one and
only one doctor.
b) A doctor may be responsible for one or more patients and a patient must be registered with one and
only one doctor
c) A doctor must be responsible for one or more patients and a patient may be registered with one and
only one doctor
d) A doctor may be responsible for one or more patients and a patient may be registered with one and
only one doctor
Relationships can be described as exclusive. One type of exclusivity occurs if a detail entity has two (or
more) masters and an occurrence of the detail may only be linked to one of the masters but not both. The
other is the converse situation where a master may be linked to only one of two or more sets of details.
40
e.g.:
Doctor Nurse Midwife
Appointment
An appointment may only be made with one doctor or one nurse or one midwife
Doctor
Patient
Research
Programme
A doctor may have responsibility either for one or more research programmes or for one or more
patients, but cannot have responsibility for both patients and research programmes.
It is possible for entities to be related to themselves in what are called recursive relationships. That is,
individual occurrences of entities can be related to other occurrences of that entity. For example the
relationship between managers in a company. The senior manager has a number of middle managers
working for him, each of whom has a number of low-level managers working for them. This can be
shown by identifying three entities, senior manager, middle manager and lower manager or by a single
entity called manager which has a recursive relationship with itself.
41
Example of a recursive relationship
Senior
Manager
Supervisor of
Reports to
Supervisor of
Middle
Manager Middle
Manager Reports to
Supervisor of
Reports to
Lower Manager
Representing attributes
Although E-R diagrams describe many of the important features of the logical model, they do not show
the attributes associated with each entity. This additional information can be represented conveniently in
form of a table.
Tables may be used to represent attributes associated with each entity type. Consider the following
entity relationship:
Assignment of patients to hospital wards.

Assume the key attribute for ward and patient are Ward_Name and Patient_No respectively.
Ward Patients
Assigned to
WARD TABLE
WARD_NAME WARD_TYPE
LONGONOT ORTHOPAEDIC
TANA CARDIAC
ELGON MENTAL
KIRINYAGA ORTHOPAEDIC
PATIENT TABLE
PATIENT_NO PATIENT_NAME WARD_NAME
1294 JAMES ELGON
1201 MARY LONGONOT
1301 CAROL LONGONOT
1152 TED TANA
1350 SMITH KIRINYAGA
42
Types of attributes
Key attribute
This is an attribute that uniquely identifies each entity type e.g. PATIENT_NO, COURSE_CODE,
STUD_NO, WARD_NAME. It is also called a primary key.
Candidate Keys – Is a set of all possible unique identifiers. Each entity type must have at least one
candidate key. For a given entity type, we choose one of the candidate keys to be the primary key. The
remainders are called alternate keys.
Composite key – When the primary key is a combination of more than one key, we call the combination
a composite key.
Foreign key – An attribute in one table whose values are required to match those of the primary key of a
different table. Foreign keys are means of maintaining relationships between entities in relational DBMS
e.g. in the PATIENT table above, the Ward_name is a foreign key since it is the key attribute of the
WARD table.
Another way of representing attributes is listing them alongside the relevant entity types.
e.g. WARD(Ward_name,Ward_type)
PATIENT(Patient_No, Patient_Name, Ward_name)
The key attributes are underlined while the non-key attributes are not.
DATA DICTIONARY
The Data Dictionary (DD) is a storehouse of data about data. It is the single place in the system where
one can go to learn more about any piece of data in the system.
The Data Dictionary defines templates for the data that the finished system itself will eventually store.
These templates tell the format, where and how data items are used and any components that make up
the data item. For instance, the data dictionary entry for invoice number would not give specific invoice
numbers, but it would instead state that the invoice number is a numeric field, five digits long that is
used within certain files in the system..
A DD serves all phases of the Systems Development Life Cycle from analysis onwards. It is not merely
documentation that is haphazardly created at the end of the project; rather it is a tool to be used from the
very beginning (of analysis). It may start out small, but it can expand at a high rate as a project
progresses through design into programming.
A data dictionary may be manually compiled or it may be fully automated (The automated DD is
referred to as the Data Dictionary Software (DD), but for simplicity it is known as the Data Dictionary).
Usually data is held about three of the four main components of the Data Flow Diagram; the Store,
Process, and the Flow. It is also necessary to record information about the entity descriptions that
support the logical data structure and the attributes (data elements or data items) contained in each
description. Thus in a DD, it is necessary to hold entries about data elements, data structures, data flows,
data stores and processes. The structure of the Data Dictionary for each of these will vary.
43
Basically, a data dictionary provides a method for looking up the items of data held in the database, to
establish the following:
 A list of the entity, attribute and relationship types
 A list of the aliases
 A list of all processes which use data bout each entity type.
 How to access the data in whatever manner is required.
 What the data codes and symbols mean
 The origin of the data.
 Possible range of values
 Ownership of the data.
 Other comments
Data Dictionary: Data Element

Name: A meaningful unique name.
Description: A short description of the meaning of the data element. An example might be included.
Aliases: Several departments may refer to the element by a different name or term. This has to be
explicitly recognised and may require a large amount of detective work. Different employees in
an examination system may be using the terms ―Unit‖ and ―Module‖ to refer to the same data element.
This was can only be recognised through the analysis work required in the compilation of the Data
Dictionary.
Type: Usually Character, Numeric or alphanumeric.
Format: To prepare for Format Checks in the subsequent system design. A convention for
representing numbers by nines (9) and characters by Xs can be adopted.
Values: Discrete data elements have a meaning associated with each value. Listed below are some
examples from a payroll system.
O33 Arrears of Pay
701 Sickness Benefit
52 Maternity Pay
Security: Who (or which level of employee) is allowed to modify, add or delete a given data item.
This will be important in the design of security features such as passwords and audit checks.
Editing: This may concern the way the way in which data is produced from the system For
example, should a credit of £30 be shown as -30, +30, 30CR or (30)
Comments: A final section in which to record special information about this data element.
44
Example:
Data Element Name: ENROL NO
Short Description: Student Enrolment number, this is

made of COLLNO, YEAR, ADMIT
Aliases: STUDID, APPLICNO Type: Positive integer

plus check letter
Format 999-9999999-A
VALUES
Part A is a discrete value assigned 1. Part C is continuous within year
to identify this college. This is the 00000 - 99999
same for all students attending this
college. 2. Positive values only
Part B is the year of enrolment 3. Last enrolment number assigned

e.g. ‗93‘ is stored as LASTENR
Part D is a check letter
Validation
1. Check college ID matches COLLNO
2. Check ENROLNO does not appear on X ENROL list
3. Use algorithm to validate checkletter
4. Check is < LASTENR
Editing
1. Once assigned, ENROLNO is never changed
2. When a student leaves ENROLNO is not assigned to another student, it is

added to the XENROL list of unused enrolment numbers
Where used
Programs Common routine

Enrol student (ENROL) Validate enrolment number
Record exam results (RECRES) (VALENROL)
Assign tutorial groups(ASSTUT)
45
ENTITY LIFE HISTORIES

An Entity Life History is an analysis technique within SSADM that is concerned with:
- Identifying events that cause changes in stored data.
- Establishing the sequence of these events
- Defining valid states for entity occurrences.
Events and Effects

An ELH shows the events which may have an effect on a particular entity occurrence (or record) . An
event can be defined as something that triggers a process to update system data. An event is not a
process, it is the stimulus which causes that process to be invoked. So, for example, the process might be
Create Order but the event is Receipt of Order or Order Received. In practice, due to the diagram
space constraints, event names are frequently shortened; Examination Result, Examination Notification,
Resignation, etc. However, care should be taken that the name reflects the event rather than the DFD
process, otherwise there is a danger that other events triggering the same process may be missed.
Three types of events can be distinguished:

 External event – A transaction arriving from the outside world. For example Receipt of Order. These
events are normally associated with data flows of the Data Flow Diagram.
 Internal process event – This occurs when a predefined condition within the stored data has been
met. For example, the Ship Cleared event takes place when all the timber has been sold from the timber
berth.
 Time-based event – This occurs when a particular process is to be triggered at a regular time interval:
a set time of day, month, year, etc. For example, the event Pay Wages on each Friday at 1400 Hrs.
A single event instance may cause more than one entity occurrence to change. The changes within a
single entity occurrence caused by an event is called an effect.
An effect can lead to the:

- Creation of a new entity occurrence:
For example receipt of order causes the creation of an entity occurrence Order.
- Deletion of an existing entity:
For example, Resignation may cause the deletion of an entity occurrence of Member.
- Modification of existing entity occurrence:
For example, Payment Receipt causes the modification of the data item Amount_Due in the
entity occurrence Customer.
Entity Life Histories Notation

The ELH is a tree-like structure where:
 Nodes are drawn as square – cornered boxes.
 The root node represents an entity type and contains the name of the entity.
 The elementary (leaf) nodes represent events which have an effect on the life of an entity occurrence
of the entity type.
 The elementary nodes (effects) contain the name of the event.
The typical life of an entity starts with an event which triggers processing to create a new entity
occurrence. Once an entity occurrence has been created then an event can trigger processing whose
effect is to modify attribute values of that occurrence. At some later time in the life of the entity
occurrence an event will occur which will trigger processing which will have the effect of terminating
46
the life of that occurrence. A terminating event means that the occurrence is archived or transferred to
another file for use by other systems. The typical life of an entity illustrates the fundamental structure of
an ELH.
Sequence
The sequence structure is fundamental to all ELHS. This structure is shown below. It shows the
chronology of events for a Course Attendance. Notification of Enrolment (create occurrence event)
always takes place before the Written Examination Result can be notified. The Written Examination
Result event occurs before the Notification of Graduation (terminate occurrence event).
Course Attendance
Notification of Written Notification of

Enrolment Examination Result Graduation
Sequence of Events
Selection
In the figure below, the small circles in the two Assessment events denotes that these are alternate
events. Thus an assessment event is either a notification of a Written Examination Result or a
notification of an Oral Examination Result. The alternative events are grouped under a selection node.
Course Attendance
Notification of Assessment Notification of

Enrolment Graduation
Written Examination Oral Examination

Result Result
47
Iteration
The asterisk(*) in the figure below denotes that the event may affect an entity occurrence zero or more
times. Continous Assesment Result may have zero, one or many results before the Notification of
Graduation occurs.
Course Attendance
Notification of Assessment Notification of

*
Continous
Assesment Result
The figure below illustrates the iteration of a substructure of the ELH. In this case, the sequence of
events notification of Written Examination Result and notification of Oral Examination Result may not
occur, may occur once, or may occur many times. Each instance of the iterated sequence must be
complete before the next sequence can begin.
Course Attendance
Notification of Course Life Notification of

*
Assesment
Written Oral
Examination Examination
Result Result
48
QUALITY IN SYSTEMS
A good system should:-
- meet the needs of the user
- be cost effective.
- be produced on time and within budget..
Quality Concepts
The term ‗quality‘ means different things to different people, depending on their perspective. To some, it
means ‗finding the errors‘ or ‗making sure it is correct‘ and involves checking the deliverables of a
system. For others, it is about the process of production and means ‗doing it right first time‘, achieving
the standard‘ or ‗getting the job done in the best possible way‘. All these definitions point to the fact that
there are a number of dimensions to the concept of quality.
Our working definition is :

Conforming to the customer’s requirements’
where ‘customer‘ can be either an external customer (a client) or an internal customer (a colleague)
and ‗requirements‘ relate to both the product and the service delivered.
The following general principles about quality apply in organisations:

 quality is a continuous process for an organisation
 building quality into the production process – prevention – is more effective than just testing or
checking the product at the end of the process – inspection.
 the management is the agent of change, and that training and education should be continuous
processes at all levels
What are the implications of these ideas for software developers?

 There needs to be a greater investment of time and effort in the early stages of system development,
if the cost of correcting at the end is to be reduced. Research has shown that 75% of software
development costs are associated with testing, debugging and maintaining software, and if this figure is
analysed, over 80% of the testing, debugging and maintenance cost can be traced back to problems
introduced during analysis. A more systematic approach to analysis could make a dramatic difference to
these figures, and this is the purpose of the structured methods.
 There cost of correcting an error during implementation is many times greater than the cost of
putting it right during analysis. The use of reviews and walkthroughs at every stage of development
would help with the early detection of errors.
 By investing in the training and training and development of their staff, a company will be raising
the chances of doing the job right first time and also building the client’s confidence.
 Management as an agent of change, must take the lead in making quality an intrinsic part of the
development process. Often software development project managers don‘t give the projects a chance to
achieve this because they only focus on two issues: ―Is the project running according to budget?‖ and ―Is
it on schedule?‖, rather than first asking the key question , ―Are we meeting the customer‘s needs?‖.
Once this has been addressed, the other questions about schedule and budget can then be asked.
Quality Management
To ensure that quality is maintained when developing software so that products and services are
delivered which conform to the customer‘s requirement, three concepts are important – quality control,
quality assurance and quality management.
49
Quality Control is the task of ensuring that a product has been developed correctly – to requirements and
to standard – and that the procedure identified for its development is effective and has been followed.
- It is done best by the person or team who did the work, but it should include an independent
contribution from a peer – someone who could have done the work, but who didn‘t. For instance, a
completed system design document should be reviewed, not just by the person who has written it, but
also by an independent person.
- It also covers the procedures and methods used for the work. These must be identified beforehand,
even if they are the usual ones, in a quality plan, and any deviation from them must be explained and
assessed.
- Records should be maintained on how quality control has been carried out, and to indicate on the
product or if this is not possible, on an associated record that this has been done successfully.
Quality Assurance is the responsibility of a smaller group of people. Someone independent of the work
area or project checks that quality control has been performed, that it has been effective, and that the
products are complete and suitable for delivery or for further use by someone else within the project.
Quality Management is the establishment and maintenance of a quality system within the organization,
the company, the division or the project and is usually thee responsibility of senior people in that areas.
Quality pyramid
QUALITY
MANAGEMENT
QUALITY ASSURANCE
QUALITY CONTROL
The foundation of an organization‘s quality management system is a statement of its objectives and
policy for quality, which should, of course correspond to the type and scope of product or service being
offered. The must be a description of the responsibilities and the internal organization for the QMS, to
ensure that quality control and quality assurance practices are understood and are operated effectively. A
major reason for doing this is to allow an external customer to assess the supplier‘s attitude and
approach to quality, both before work is placed with the supplier, and throughout the progress of the
work. A QMS is a company‘s framework, within which all the work is performed, using only
procedures and methods which are defined, checked and visible.
Standards
A QMS will specify the standards to be used for tasks carried out within the organization.
50
Why are standards necessary in organizations

- to help people do the job right the first time (prevent mistakes)
- As a means of communication
- Making it easier for teams to work together
- Ensure that products developed will be compatible and contribute to producing consistent
maintainable systems.
Benefits of a formal Quality Management Systems

- It helps the to identify the company
- It helps to ensure repeat business
- It makes practices coherent (rational)
- It helps new joiners settle in more easily.
- It gives greater confidence in the company‘s ability to deliver.
- Products get the stamp of quality.
- It brings companies closer to their customers.
- Businesses become more professional in their approach.
- A sense of ownership is created within the organization
- A quality culture attracts quality people to work for the company.
A quality manager will usually have a day-to-day responsibility for the QMS, although this may not
need to be a full–time role once the quality system is established and running effectively
The QMS is documented in a quality manual which also includes or refers to descriptions of the
methods and procedures used on work tasks. This manual also becomes a valuable marketing and selling
aid, as it provides evidence to the outside world of the means by which a supplier achieves quality of
work and product, and is part of the basis on which the quality system can be assessed.
Quality in the Structured Life Cycle

In the traditional approach to developing an information system, there was little or no quality checking
at each stage of the development process. There was ample testing of programs, interfaces, sub-systems
and finally the complete system, which ensures that when the system went live, it worked. However the
quality system did not ensure that the working system satisfied the requirements of the customer who
has asked for it.
If testing is properly designed and planned, it can be very effective as locating defects. However, testing
has the following disadvantages:
 It can never be completely comprehensive.
 Checking every path through even a simple program can take a large amount of time.
 It is particularly difficult to trap defects introduced in the earliest stages of analysis and design,
or facilities that have been ‗lost‘ between one stage of development and the next. Such defects are the
ones that cause the most concern.
 It can only be done in the later stages of development at it actually exercises code.
Various studies show that at the testing phase the cost of correction may be many times greater than a
correction made before the coding begins.
51
With the introduction of structured approaches to system development, each stage of the project became
a ‗milestone‘, the deliverables of which had to be signed off by the developer and the customer before
the next stage began. This ensures that not only does the system work when it finally goes live, but also
that the client is in full agreement with the interpretation of the requirements – from the earliest stage to
final implementation. A procedure for agreeing and signing off milestones, which is part of many
structured methods, is the structured walkthrough, while a more formal technique which is also used on
software development projects is the Fagan inspection.
Structured Walkthrough
It is the review of products at the end of a stage in the development of a system by a group of relevant
and competent persons.
The prime objective of a Structured Walkthrough (SWT) is to identify problems and initiate the
necessary corrective action.
Structured walkthroughs are done at all stages of a project, from the models of the analysis phase to
design and onto the programs and documentation of the implementation. Organisations that subject all
systems to stringent walkthroughs can reportedly reduce the program error.
Types of Walkthroughs
(i) Formal – It is a full review of the work done in one stage of the structured development and
involves the client.
(ii) Informal – It is internal to the development project and reviews each step of the development
within a stage. User involvement is optional.
Roles in a walkthrough
Presenter Is the person who has done all the work and is now submitting the relevant
documentation for quality assurance.
Chairperson Is the person responsible for:

 Circulating the documentation prior to the meeting
 Choosing the time and the location
 Chairing the meeting
He must familiar with the appropriate standards.
Secretary Is the person responsible for documenting the problems raised and then reading them
back at the end of the meeting so that priorities can be assigned and follow-up action agreed.
Reviewer Is a person from the same project as the presenter.
In formal walkthroughs, there will be extra reviewers:
A user representative mandatory for the formal agreement and signing off of a development stage.
An extra observer from the same project.
An unbiased observer from another project, an optional role which can be useful in providing
objectivity.
52
Even though each team member has a primary function, all are equally accountable in terms of
examining the quality of the system and offering comments and criticisms. The responsibility of the
team is to give an accurate appraisal/assessment, good or bad of the product being reviewed. All
criticisms should be specific, indicating exactly where more work is needed. The participants should
identify defects, but should not attempt to correct them, since correction is the responsibility of the
author.
Stages of a Structured walkthrough

Preparation, Meeting, Follow-up.
Preparation
- This should be done at least three days before the walkthrough meeting
- The presenter prepares documentation on the product to be reviewed
- Presenter passes documentation to chairperson who then distributes the documentation
and notifies the reviewers of the time and location of the walkthrough meeting.
Meeting
- It should be kept short – preferably 60-90 minutes.
- Presenter walks the reviewer through the product. The prime purpose is to ensure the
product meets the requirement and conforms to the appropriate standards and that any
defects are identified. Additional benefits is to spread information, knowledge , ideas and
new approaches.
Follow –up Actions:

- Accept and sign off product.
- Recommend minor revisions with no need for a further review
- Recommend major revisions and schedule another walkthrough to review the revised
product. In this case, the person creating the product will have a written record of the
identified problems produced by the secretary, and the actions required. The necessary
corrections are then made for resubmission in the next walkthrough.
Problems associated with Structured Walkthroughs

- Inadequate preparation by the reviewers
- Too much time spent discussing solutions rather than identifying defects
- Author being defensive about his work.
- Walkthrough rambling on for too long
- The tendency of people to forget the important points in favour of arguing over the inconsequential
parts.
- The tendency to fix blame on others; and the tendency to behave as prima donnas, upstaging
everyone else in an attempt to discredit the work of another member.
Solutions to problems
It is the chairperson‘s responsibility to avoid these problems by:
53
- Enforcing a time limit

- Ensuring walkthrough standards are adhered to
- Reminding attendees, before the meeting of the purpose of the walkthrough and the importance of
preparation.
- Careful selection of team members
- A checklist of specific topics for review should be available to keep a team on track.
The outcome of the walkthrough is the walkthrough report prepared by the scribe. On the first page; the
summary, all participants must sign the report to show that they are in agreement with it. This reinforces
the idea of shared responsibility for the quality of the product. At the bottom of the summary page, the
final verdict is given. The product is accepted as it is or with minor revisions, or it is rejected. Rejection
is broken down into three categories; the product has so many flows that it must be completely rebuilt,
the product needs major revisions, or the review was incomplete and must be continued later.
Fagan Inspections
A Fagan inspection is a formal review technique developed by Michael Fagan, a British Engineer who
worked for IBM. It was based on established review methods, such as the structured walkthrough, but
was designed to eliminate the problems with walkthroughs.
An inspection can be defined as a formal examination of an item, against a previously produced item, by
a group of people led by an independent chairperson with the objectives of:
(i) Finding and recording defects, using standardized checklists and techniques;
(ii) Initiating rework as necessary, monitoring the rework,
(iii) Accepting the work, based on stated exit criteria;
(iv) Adding to and utilizing a base of historical defect data.
The objectives of a Fagan inspection is to identify and correct as many defects as possible early in the
development process, so that the next stage can proceed with confidence, and to minimise the number of
defects in the final system so that maintenance costs are reduced.
The inspection process consists of a number of fixed stages:

(i) Planning – The inspection team is appointed and any administration is performed
(ii) Overview – Ensures that those inspecting the document understand how it fits into the system as a
whole.
(iii) Meeting – The document is formally examined
(iv) Rework – All defects found are corrected, performed by the author of the inspected item.
(v) Follow-up – Checking that the rework has been performed adequately.
54
MOVING FROM ANALYSIS TO DESIGN

In structured methodologies, a lot of emphasis is placed on the need to spend considerable time and
effort ensuring that analysis is rigorous so that the design process, and later the implementation, will be
straightforward. A key factor is the use of structured techniques and they help in ‗bridging the gap‘
between analysis and design.
BRIDGING THE GAP

In traditional approaches to system development, there was frequently a gap between the information
about the system documented by the analyst, and the detailed technical task which lay ahead for the
designers. While the existing physical was described in detail, usually in the form of a lengthy narrative.,
it still left the designer, who had to produce designs for files or databases, processes or interfaces and
controls, with a lot of unanswered questions. Analysis ends with a description of what the system must
do, while design must specify how this will be done by selecting one of the many possible ways of doing
it. The gap between the end of analysis and the beginning of design is shown below.
ANALYSIS DESIGN
describing WHAT describing HOW

THE GAP
the system will do the system will do
it
All structured methodologies share the view that logical models must be integral to the process of
systems development in order to ease the transition between analysis and design, and also to enable
intermediate views of the system to be discussed with the users.
A logical model describes exactly what the system does rather than how it does it, by ignoring the
physical constraints which determine how the current system is physically implemented. A required
logical view is created by mapping the customer‘s requirements for a new information system onto the
current logical model. The structured techniques during analysis which provide this logical view
include:
 Data flow diagrams
representing the processes which manipulate the data as it passes through the system.
 An entity model
showing the relationship between the data items held within the system.
 A data dictionary
Providing an overall consistent definition of the data used by the organisation. This definition can
include the content of the data stores, data flows and processes shown on the data flow diagrams, and the
entities which make up the entity model.
55
ANALYSIS
DESIGN
Data Flow Diagrams
P lanning of CONTROLS
A sking Entity Model
R ecording INTERFACES
Data Dictionary
I interpreting
DATA
S pecifying
PROCESSES
THE BRIDGE
These logical models provide a sound basis for the process of design and the designer will use, amend
and develop these models to create design documentation. For example, data flow diagrams is the
starting point for designing input to the system such as an order form, outputs from the system such as a
sales report and human computer interfaces such as an on-line enquiry screen.
In this way the logical model support both the current system which is in operation. And the new system
being developed, and can be used to overcome the analysis/design gap by providing a ‗bridge‘ of
techniques central to the process of analysis and design.
PROBLEM SPECIFICATION
By the end of the analysis phase, the analyst has accumulated a lot of separate documents, from process
descriptions to data models. At some point, these need to be bundled together to form the problem
specification, which will be used by designers and programmers throughout the life of the project.
Components of Problem Specification

Typical contents of a problem specification are:
 Table of Contents
A list of what the problem specification contains is a necessity.
 Current System Deficiencies

Going through the feasibility study, the interviewing, and the creation of systems models, the analyst
found many problems in the current system. These problems must be set down in a formal list.
 New System Restrictions

The analyst must document any restrictions that will limit the choice of systems, including the resources
available (machines, people, and money) and the maximum time until the project completion (because
of external deadline, such as a new product going into production). Sometimes there are other
restrictions such as a stipulation that the new computer must be compatible with the computer in the
home office, which might dictate the purchasing of the new hardware from a particular vendor.
Acceptance Criteria
56
The analyst has also to indicate what must be delivered by any new system. This is detailed in the
acceptance criteria. The acceptance criteria will later be referred to when the analyst tries to prove to the
users that the system meets the users‘ stated requirements. These criteria serve as a protection for the
users, ensuring that the requirements have been met.
In order to be effective, the acceptance criteria must be measurable. For instance, how could we prove to
the user that the system has managed to ―improve the collection of overdue accounts‖? Precisely what
does ―improve‖ mean? Can we measure it, quantify it? Hardly. This requirement could be more clearly
stated in this form: ―lower the percentage of bad debts from the current 10% of the accounts receivable
to 3%. Reduce the average days overdue from the current 120 days to 90 days. Reduce the average
account balance from the current $5,400 to $3,500‖. That these requirements have been met can be
verified to the users‘ satisfaction.
Nevertheless, the analyst must keep in mind that the users‘ expectations of what the system can do for
them will change as a project progress. One reason for this is that the business environment cannot
remain static until the system is completed. Another reason is that as the users become acquainted with
the system, they will gradually discover more ways in which could help them if only those functions
could be incorporated. Analysts must work closely with the users so there is some means of modifying
the system and its acceptance criteria and its project progress.
System models
Each proposed system model consists of DFDs (showing the evolution from the current physical model
to the new physical model), process specifications, data models, and cost-benefit analysis.
The chosen model is not put into problem specification. It should be accompanied by management‘
written authorization to continue forward with this option and documentation as to why management felt
this was the best choice.
The rejected system models are included in an appendix to the problem specification, where they will be
out of the way yet available for reference. Analysts never throw away anything on which they have
expended a great deal of work; it might be needed again. Perhaps two years from now the president of
the company will decide to go with that high-cost option that was currently rejected. If so it will be
ready.
Data Dictionary
The data dictionary has been modified as the project have progressed, so it should be in its finished form
at this point.
Guide to problem specification

The guide to problem specification contains whatever information is necessary to tutor a new member in
using the problem specification. It includes the explanation of each document and the conventions
adopted for each one. The guide should be reusable from project to project.
Index
All key concepts and the terms should be included in the index.
Anything else required by the users, management, or good sense
57
No two projects are alike, and each will have peculiarities that need to be documented at this stage. For
example a user may have a pet report that she absolutely has to see designed at this point. Although
report formats are not part of conventional problems specification, in the interest of user satisfaction, the
format should go in.
CHOOSING SOFTWARE AND HARDWARE

This decision must be made at the end of the analysis phase, for much of the design phase can be
omitted if the decision is made to purchase. Once the requirements of any new system have been
specified, the analyst can then look at available software packages to see which ones most closely fit the
user‘s needs, all without actually ‗designing‘ that system.
Even though most analysts and programmers are more pleased in designing and building a new system
from scratch (since it is what they are trained for), it is economically more feasible for many businesses,
especially smaller ones, to buy rather than to build software. Commercial software have several
advantages.
- They are cheaper. The cost of development is distributed among many purchasers, rather than
being carried solely by one organization
- They are already debugged. If several organizations have been using the software for some time,
it is reasonably safe to assume most of the bugs have been found and fixed.
- They are available sooner.
- User personnel can bring up the new system in less time. Most organizations have other activities
on which the staff should be working, so this can be a critical consideration.
- Users can try out the product without investing a great deal of money.
Disadvantages
- Only rarely will it meet the needs of the users. Users may have to adapt their procedures to the
requirements of the software, or analysts may be obliged to modify the software, (which can be
expensive if not impossible)
- It may not be compatible with existing software applications in the organization
- Different applications from different vendors will mean that each application will have a
different user interface, making it difficult for users to use the various types of software.
- There may be no in-house expert on board from the first day the application goes to use.
- They cannot be easily modified if the needs of the users change in the future.
When evaluating commercial software, an analyst might use a decision table format to consider the
following:
 How closely does the package with what is needed? Will it be necessary to modify the programs, or
the proposed system procedures, or both?
 How stable is the software vendor? Will the company still be I the business in a year or two in case
any problems arise?
 Does the vendor give prompt, courteous, and reliable support when problems arise? A toll-free 24-
hour telephone line is a good omen, but test by calling with a question to see what kind of response is
given and how often the line is busy.
 Will the vendor be providing ongoing enhancements and upgrades to the software? At what cost?
 Are source programs supplied so that the organization can do its own modifications?
 Is there a trial period during which the package can be returned for a full refund?
58
 How many other installations have used the software package? For how long? (A vendor should
supply a list of users‘ names, but it is not always helpful to ask those users for evaluation. The vendor
would not be likely to give out the names of dissatisfied customers. We could ask those users for second
level-references—other organizations they are using the package, but which the vendor has failed to
mention. There is where the skeletons can be uncovered.)
 How flexible is the software? Can it change along with the changing business environment? Are
there any growth limits on file size, number of transactions, or embedded tables?
 Is the software user – friendly? With what other applications currently used by your organization
does this application communicate? With what other applications currently on the market (both from this
vendor and others) does it communicate? Do these various compatible application packages have similar
user interfaces?
Only after collecting data on the various software packages available does the analyst begin to worry
about choosing hardware. The software is really what determines how well the computer meets the
user‘s needs, so there is less anxiety connected with choosing the hardware on which that software runs.
There are a few constraints on hardware selection which are much the same as many of those detailed
for software; stability of the vendor, existence of a trial period, satisfaction of the users, flexibility and
user – friendliness. In addition, machinery should be upwardly compatible, meaning that the user
organisation can easily upgrade to a larger or faster model in the future without scrapping existing data
or programs.
When shopping for hardware, the analyst sends out a Request for Proposal (RFP) to vendors that
might be able to supply the necessary equipment. In return, interested vendors return a proposal listing
the specifications for their hardware and its cost.
Of course the organisation is always concerned with the comparative costs of the various system
solutions in both hardware and software selection. The costs and benefit of the alternative solutions to a
system problem need to be evaluated in depth regardless of whether the solutions involve commercial
or custom-programmed software, or hardware from one of several vendors.
REVIEW QUESTIONS
1. A purchasing department receives a purchase requisition from the stores. The requisition is checked,
and an invalid requisition is returned to the stores for correction. An order is made out using a file of
approved suppliers, and sent to the appropriate supplier. A copy order is filed. The requisition is filed.
When the goods are received, the invoice is compared with the filed order copy, and an invalid invoice
is returned to the supplier. Valid invoices are passed to the accounts department for payment and
fulfilled orders are filed.
Draw a DFD for the above.
2. When an invoice is received from a supplier, it is checked against a file of authorized purchases. If
the invoice does not match an authorized purchase, then a querying letter is prepared and returned back
with the invoice to the supplier. If the invoice matches an authorized purchase, but is for an incorrect
amount, then a standard form is completed and returned together with invoice to the supplier. If the
invoice reconciles, a payment authorization is made out. A cheque is then prepared and sent to the
supplier, and the invoice and the authorization are filed.
59
Draw a DFD for the above.
3. An electrical wholesale company stocks 20,000 different items and have 1,000 customer accounts. It
receives an average 150 orders per day with an average of 10 unique items per order.
Orders are taken by telephone, mail and fax in the administration department and over the trade counter
in the warehouse.
The order details are transferred to a 4-part ‗OPD‘ (Order/Picking/Dispatch) document set. The fourth
copy is retained in the administration department in a file and the remaining three copies are sent to the
warehouse for processing. The store-man assembles the delivery and amends the OPD set with any
alterations necessary due to the unavailability of stock.
Copy 1 of the OPD (dispatch note) goes with the goods to the customer, Copy 2 goes to the accounts
department for invoice preparation and Copy 3 is returned to the sales administration where the
information is used to update stock records and then filed with Copy 4 in the order file. Re-order levels
are held on the stock record cards and sales information inform the purchasing department when stocks
fall below the re-order level.
If an item goes out of stock, the warehouse will inform the purchasing department who will raise a
purchase order, a copy of which is passed to the goods inwards area of the warehouse.
Customer returns are inspected by the warehouse staff and return notes are raised and passed to the
accounts for credit notes to be issued.
Supplier deliveries are checked against copies of the purchase order in the goods inwards area of the
warehouse and a goods received note is raised. This is passed first to sales administration to update their
stock records and then to accounts department.
The company has already computerized its accounting system, i.e. Invoicing/Sales ledger/Purchase
ledger and Payroll and is now looking to computerize its order processing and stock control activities.
You are required to design a computer system to cover the order processing and stock control activities.
(i) Draw a context diagram showing the external inputs and outputs of the order processing and stock
control system
(ii) Draw a Level 1 DFD of the current system, showing the processes, flows, stores and the interfaces
with existing other external entities.
60
CHAPTER FOUR: SYSTEMS DESIGN
OBJECTIVES
At the end of this chapter you should be able to
1. Discuss the objectives of Systems design.
2. Identify design constraints.
3. Discuss the principles of Human computer interface design.
4. Identify the steps in database design.
5. List and apply common process description tools.
6. Identify security considerations in an IS.
7. Identify the contents of a program design specification.
Objectives of Systems Design

It is important, right at the start of the design process, for the designer, or design team, to set clear
objectives. The primary objective will always be to design a system which delivers the functions
required by the client to support the business objectives of their organisation. For example, the
system may be required to speed up the production of accurate invoices, so that the company‘s cash flow
can be improved; or to provide up-to-date, detailed management information to improve the managing
director‘s control over the business; or to help senior managers to make strategic decisions. In other
words to be a quality product, a system must conform to the customer‘s requirements, and to be
delivered in a way that meets their expectations.
Other objectives which must be considered if a good design is to be produced:

(ii) Flexible
The design should enable future requirements of the business to be incorporated without too much
difficulty. Often, during the analysis phase users may not be clear about exactly what they will require
from the new system, for example which reports will be most useful to them. However, during the
evaluation period after the new system becomes operational, the real needs often merge and a flexible
design will be able to accommodate these new requirements. In addition, businesses change over time
and a good design enables the system to reflect these changes.
(iii) Maintainable
This is closely linked to the previous objective because it is about change. A good design is easy to
maintain and this reduces the client‘s maintenance costs, which usually represent a high proportion of
the total lifetime cost of the system.
(iv) Portable
A client who has bought a software system may wish to change the hardware on which the system runs.
A good design is portable – in other words it is capable of being transferred from one machine
environment to another with the minimum amount of effort to covert it.
(v) Easy to use

With the increasing exposure of people to computer applications at home as well as in the office,
expectations of computer systems in terms of their ease of use are also increasing. A good design will
result in a system that is ‗user-friendly‘ – easy to understand, not difficult to learn how to use and
straightforward to operate.
61
(vi) Reliable
This objective is about designing systems which are secure against human error, deliberate misuse or
machine failure, and in which data will be stored without corruption. While this is desirable in any
computer system, for certain systems in the areas of defence, process control or banking, it will be a key
design objective.
(vii) Secure
In order to protect the confidentiality of the data, particularly if it is commercially sensitive, it may be
important to build in methods to restrict access to authorised users only, for example by introducing
passwords.
(viii) Programmer-friendly
While the other objectives are mainly about delivering benefits to the client, the designer must also
consider how easy it will be for the programmers to produce the code from the program specifications.
By producing a programmer-friendly design, both the costs of production and the risk of building in
errors are reduced.
(ix) Cost-effective
This includes a number of the other objectives, and is about designing a system which delivers the
required functionality, ease of use, reliability, security, etc. to the client in the most cost – effective way.
Design Constraints
In addition to time, which is always limited, and money- the available budget will limit the options
available to designers – there are a number of other constraints which need to be taken into
consideration. These are:
 Resources
The availability of resources of resources – particularly the technology to be used in delivering a
solution to the client.
 The client’s existing systems
A major constraint would be the need for a new system to interface with other systems – hardware,
software and manual – which already exist and will continue to be used by the client organisation.
 Procedures and methods
The final design might also be constrained by internal or external procedures, methods or standards. For
example, it might be a company standard to develop systems is SSADM, the CASE tool to be used in
development might be specified, as might the programming language in which the system must be
coded.
 Knowledge and skills
The knowledge and skills of the development team may limit a designer‘s options, as might the
competence or ‗computer literacy‘ of the potential users. Also, financial considerations may be
important here - ‗how much does it cost to employ two trainees compared to the cost of employing one
expert?‘
Elements to be designed
(i) System security and controls
(ii) Human Computer interfaces; Outputs, Inputs, Dialogues, etc.
(iii) Logical data: entity modeling and normalisation
(iv) Files
(v) Databases
62
(vi) Physical data design

(vii) Programs
(viii) Choice of hardware
Human-Computer Interface design

The specification of inputs, outputs and dialogues forms a key part of the designer‘s task because of the
high visibility of these interfaces to the users. The output produced by the computer is the main reason
for developing the new system. If the users are clear what they want from the system, the inputs needed
to produce this output can then be identified. Should the output fail to meet the requirements of those
who have to use it, the system can be seen as a waste of time by those users, who may little appreciation
of the internal, and therefore invisible, sound design or elegant code.
The layout of a screen and the consistency of the dialogue will be important to those users who have to
spend a lot of time sitting in front of terminals, and who will base their evaluation of the whole system
on these interfaces. If the method of entering data is difficult, because of a poorly designed input form,
for example, then the chances of inaccurate data entering the system will be greatly increased, which
will in turn affect the value of the output produced. The tine and effort spent getting the design of forms,
screens and reports right will enable the designer meet the objective mentioned earlier of making the
system easy to use.
OUTPUT DESIGN
Having identified from logical model of the new system where the outputs will be, by listing those data
flows, which cross the system boundary as they leave the system, the next stage in the process is to
determine their content. Structured techniques play a useful role here, because the designer can turn to
the data dictionary to find the content of each data flow, which represents an output. Considering an
example from the DFD the output is described as Stock Valuation Report. According to the data
dictionary, the contents of this data flow are as follows:
DATA ITEM TYPE LENGTH
Inventory group character 25

Stock code 99999 5
Product description character 30
Unit cost 999.99 6
Quality stock 99 2
Unit selling price 9999.99 7
Expected sales 999 3
A quality output is the one that meets the requirements of the end user, and which presents the
information in away which is clear, easy to read and visually attractive. In order to decide on an
appropriate method of presentation, and a suitable format, a number of questions need to be asked:
 Who receives the output?

What profile can you create of your target population and their needs? The output may be received, for
example, by users within the company, e.g. a listing of accommodation available, or by people outside
the organization, such as customers, e.g. an invoice, or government departments, e.g. Inland Revenue
returns, or by management, e.g. a monthly report.
63
 Under what circumstances will the output be received?

Does the environment place constraints on the technology that can be used? For example if output is to
be generated on a factory floor, the device used may have to operate effectively in dust or dirty
conditions, or in a noisy environment where an error message ‗bump, which could be perfectly in an
office setting, would be inappropriate.
 When and how often is the output needed.
What implications will the required frequency of information have for the selection of an output
method? For example, a warehouse supervisor may require a daily stock report, whereas senior
management may only need to receive reports once a month.
The answers to these questions will help the designer make decisions about whether a display or a
printed copy of the output is required, the type of device needed to produce the output required, and the
layout of the information which would best meet the needs of the users.
OUTPUT TECHNOLOGY
Two methods exist:
 Printing
 VDU output
Printing
Types of printers: impact where a hammer strikes an inked ribbon to produce a character , and non-
impact which work in a number of ways to produce a character on paper, without making physical
contact with it (photocopy technology).
Impact printers; e.g. dot matrix, daisy-wheel

Non-impact: laser, ink-jet.
While impact printers have traditionally been more commonly used in computer systems because they
are less expensive, new systems are increasingly using laser printers to produce printed output because
of the better print quality, the possibility of integrating graphics and text and because the cost of
technology is decreasing.
VDU output
It is appropriate where only a short-lived image rather than a printed document is required. The display
would be monochrome or colour. Colour monitors are now being used more in developing systems, and
high resolution graphics enable sophisticated presentations of data to be displayed in the screen.
Other output alternatives:

 Plotters to produce coloured line drawings, such as graphs and maps
 Facsimile
 Sounds such as beeps or clunks for example music or video messages.
 Magnetic media such as magnetic, optical disks, microfilm, microfiche
 Speech output
Presenting information
Three important principles apply whether the output is printed on paper or displayed on the screen:
 The content should be kept simple. This is achieved by presenting only that information which is
needed by the user.
64
 The page or screen should not be cluttered and easy to read. The use of whitespace on a printed
page significantly improves its readability.
 The information should be arranged logically on the page on screen in such a way that it can be
easily and quickly used and understood by the user. Every output screen or report should include a main
heading which identifies the purpose of the output and subheadings which identifies the various sections
within it.
The use of tables and graphics

Reports are commonly arranged as tables, especially those containing financial information, and this is
appropriate if the detailed information is arranged in discrete, labeled groupings, if totals are included
and a few explanatory comments are needed.
Graphics can be effectively used to present data in ways other than tables and low cost technology is
available to produce high-quality diagrams and charts. However, these graphics need to be used with
care if they are to be effective, and much will depend on the designer‘s judgement and the requirements
of the users as described by the analyst.
INPUT DESIGN
When designing input, the objective is to ensure that the data, which will be processed by the system, is
collected and entered into the system efficiently, according to the specified requirements, and with the
minimum of errors. In discussion with the client, the design will choose a method of input, which is cost
effective and acceptable to the end users. The process of input design, like output design, which was
described earlier, consists of four stages:
 Firstly, identify the inputs into the system, by listing the data flows on the required logical data flow
diagram, which cross the system boundary on their way in.
 Then determining the content of these inputs by inspecting the data dictionary.
 Next choosing an appropriate input device to change the user‘s data into a form, which can be read
and processed by the computer system.
 And finally completing the detailed design work involved in specifying forms, input screens and any
other data collection documents.
The first two steps are linked together, and involve the designer in looking at the data flow diagram for
the required logical system, and the data dictionary. If the data dictionary for the system were to be
inspected, the contents of the data flow, which correspond to these inputs, could be determined. For
example the data items, which make up the input called new customer details, are:
Customer number, customer type, sales region, discount code, name, address, and delivery instructions,
While new product details contains the following data: Product number, description, manufacture,
origin, inventory group, product class, dispatch unit, re-order level, discount prices, vat code and VAT
rate. In this way the contents of each input can be confirmed, as can information about the source,
volume and the frequency of the input.
The next stage is then to choose the appropriate technology for introducing the data contained in each of
these inputs into the system. There are a wide variety of different ways of entering data, and the choice
of the appropriate method will depend on a number of factors, the two most important of which can be
summarized in the following questions:
 Which method will be most suitable to the needs of the users who have to enter the data? While a
keyboard will be appropriate in many situations, it may not be appropriate to a checkout operator in the
supermarket, where speed and accuracy are important.
65
 Which method will be most suitable for the format and volume of the data to be entered? if an
educational institution has a large number of multiple choice answer sheets completed during
examinations, and wishes to put these results onto the system, then an optical mark reader – which can
read the input directly from the students answer sheets – would be the most suitable
Whichever method is chosen, it will include some or all of the following steps:
1. The initial recording of significant data by the user;
2. The transcription of data into an input document
3. The conversion of the data from a ‗human-readable‘ into a ‗computer-readable‘ form;
4. Verification of this data conversion to pick up any errors;
5. The entry of the checked data onto the computer system;
6. The validation of the data by the system to ensure it is logically correct;
7. The correction of any errors highlighted by the data validation program.
As passing through all these steps makes data entry a costly process, the key guideline for the designer is
to make the process as simple as possible. If this can be done in a way which minimizes the cost to the
user, minimizes the chance of data transcription errors occurring and minimizes the delay in entering the
data onto the system, then the designer will once again be building quality into the system.
While there are a large number of different input devices, they can be grouped according to the way in
which data is entered: either by keyboard transcription from clerical documents, by direct input onto the
computer system via a peripheral device, by direct entry through intelligent terminals or by speech or
body movement.
DIALOGUE DESIGN
For most of computer systems, the main contact with the system is through an on-screen dialogue, and
their perception of how ‗friendly‘ the system is will depend on the characteristics of this dialogue.
Ambiguities and difficulties in the dialogue cause problems in training and operation and lead to
systems under performing.
For example it is important that developers use style guides to ensure that screens which are part of the
same system, but which are designed or programmed by different individuals, have a consistent layout.
This area of systems design is important for the developer who, in seeking to design an effective
dialogue, will be concerned to ensure that the conversation between the system and the user flows freely.
This depends on understanding the characteristics and requirements of the users, as well as the type
hardware and operating system available, and on having an appreciation of the principles of screen
design and the different ways in which the dialogue can be structured.
Screen Design
The quality of the screen can be a direct impact on the performance of the users of the system, and the
designer needs to consider the format as well as the content of the screens on which the dialogue, or
interaction, between the user and the system is based.
Screen features:
Text – must be easily readable.
- Choose appropriate font and size for the character.
- Using lower and upper case letters can improve readability, rather than the approach sometimes
adopted in screen design of using all upper case.
66
- Evenly spaced text, with an unjustified right margin, is easier to read than right justified text,
which has spaces of varying sizes between the words.
- The use of concise phrases, familiar vocabulary and appropriate abbreviations make it easier for
the reader to understand the text.
- The most visible section of the screen is the upper left-hand corner, and it is a good idea to locate
important messages in this area.
Highlighting – can be used to make parts of the text stand out from the rest. There are a number of
different ways of doing this. The text can be
In UPPER CASE
Underlined
In bold typeface
Enclosed in a box
Or in a shadowed box
Or it can be larger the rest.
In addition, because the medium is a VDU screen, rather than paper, other techniques can be used to
highlight the important information. It can be made to flash, to be brighter than the surrounding text, or
reverse video can be used – creating an effect rather like a photographic negative, with white text on a
black background.
Colour – Being in a different colour to the rest or being enclosed in a coloured box can highlight text.
Background colors can be changed or a design convention can be used in which different types of
information are displayed in different colors. The consistent use of colour on screens within the same
system is important, and the designer must be wary of using too many colors or creating lurid
combinations as these will work against the effectiveness of the screen design. In addition, the designer
must also be aware of avoiding colour combinations which could cause problems for those users who
are colour-blind
Graphics – can be used to good effect for displaying information, especially trends in numerical data.
They can be coloured, solid, three-dimensional or animated, and the designer must decided on what is
appropriate to the purpose. Another use of graphics is as an integral part of the structure of the dialogue
– known as graphical user interface (GUI). A key feature of GUI design is the use of small pictures
called icons, which are used to represent entities such as files, documents and disks. An icon should
communicate exactly what it represents to the user without the need for accompanying text. Where they
are used, each icon should be easily distinguished from any others, and used consistently to represent the
same thing.
Animation - although this is little used in screen design, it can be a power technique for attracting the
attention of the user, because the eye is always drawn to a moving object; to mark the position of an
object, for example, a blinking cursor can be used; or to communicate a message, a clock with a moving
hand, or an hourglass with moving sand, indicate to the user that they have to wait while some
processing is carried out by the machine.
67
Dialogue types
There are a number of different approaches, which can be taken when designing the conversation or
dialogue between the user and the computer system. Essentially a dialogue consists of user responding
to a prompt from the computer by providing input. This input is processed by the computer and a
response is output to the screen, which in turn may prompt the user for the next input.
Main dialogue types:

 Menus
In this approach, the user is presented with a set of alternatives from which one will be selected. These
alternatives can be displayed on the screen using text or graphics, and usually each alternative has a
number or a letter associated with it. When the user selects an option, the letter or the number is entered
through the keyboard, or the arrow keys are used to move the cursor between the options. Alternatively
if a mouse is attached to the computer, an option can be selected by pointing at it. An item on the menu
can be selected by typing either the appropriate number or the initial letter of the word.
Menus are widely used in screen design because they require minimal effort, and skill, on the part of the
user. This in turn reduces the training requirement when preparing to individuals to use the system. A
common approach is to structure the menus hierarchically in a ‗nest‘: selecting an option on the first
menu takes a user to a second menu from which another option is chosen, and so on. This allows the
number of alternatives on any one screen to be kept to a minimum.
When designing nested menus, it is important to build in shortcuts to allow experienced users to move
quickly through the system and avoid the frustration of having to go through several ,menu screen for
each transaction, and to allow an exit which doesn‘t involve traveling back through each of the previous
menus. The principals of good design should also be applied by keeping the menus simple, with an
upper limit of ten choices per screen; minimizing the number of levels of menus through which a user
has to navigate; and ensuring consistency in the way options are selected from each of the related
menus.
In some applications a menu is permanently displayed in a bar across the top of the screen from which
other menus can be pulled down as required. This is known as a pull- down menu.
 Question and answer: This type of dialogue involves the system prompting the user by asking a
question, and then carrying out the processing associated with the user‘s answer. The question usually
requires one of a limited number of answers, e.g. yes or no, which eliminates errors and reduces the
amount of validation of answers required.
Do you really want to delete this file? Type ‘Y’ or’ N’

(Where the default is ‘N’)
 Form-filling this is particularly appropriate for the user who has to enter information into the
system from a paper input form, and as closely as possible to minimise the risk of errors. This type of
dialogue is also called a template. The areas in which data has to be entered will usually be highlighted
in some way to stand out from the background text- using color shading or graphics for example.
68
Example of a form-fill screen

Galaxy Electrical Products Limited
SCREEN LAYOUT
NEW PRODUCT INPUT/PRODUCT AMENDMENT
PRODUCT NO (--------------) DESCRIPTION (-----------)
MANUFACTURER (---------) ORIGIN (-------------)
INVENTORY GROUP (------) PRODUCT CLASS (----)
DESPATCH UNIT (-----------) RE-ORDER LEVEL (------)
DISCOUNT PRICES A (----------)

B (----------)
C (----------)
D (----------)
When data has been entered, the cursor moves to the next input area. Form-fill is useful when a large
amount of similar information has to be entered quickly into the system
 CommandVAT CODE
language. (----------)
This VAT RATE
type of dialogue (-------------)
can appear very ‗unfriendly‘ to the inexperienced user as
the prompts are usually very limited, and response by the user has to be syntactically correct in order to
be accepted by the system. However it is a very fast and efficient dialogue for the experienced user and
short commands or abbreviated forms of these commands will initiate specific processing. There is a
great deal of freedom to move around the application, as the user rather than the system is structuring
and ordering the conversation. The designer should ensure that there is a visible output on screen to
show that the user‘s input has been accepted by the system and should endeavor to make error and help
messages in such a dialogue as meaningful as possible.
Example:
Type Exit to return to menu
C:\>A: DIR
Not ready reading drive A

Abort, Retry, Fail? R
General failure reading drive A

Abort, Retry, Fail? F
Invalid drive specification
Bad command or filename
69
Type EXIT to return to menu

C:\>
 Natural languages – They are much closer to the way people would speak. This type of dialogue
relies on artificial intelligence and translate them into instructions which can be followed by the
computer. The problem with natural language is that most natural languages, like English, are
characterized by ambiguity and inconsistency in their syntax. These dialogues therefore require the use
of a limited vocabulary and syntax, with which users need to be familiar before they use such a dialogue
WIMP INTERFACES
This is an increasingly common interface used in many applications. The WIMP interface is so called
because it incorporates:
WINDOWS, several of which can be opened on screen at the same time,

ICONS which represent entities such as files and documents, a
MOUSE to select and move icons around the screen and
Pull down menus.
ERGONOMICS AND INTERFACE DESIGN

In designing an ergonomically safe workstation, attention must be paid on to a number of points, such
as:
 The body should be upright and the body weight fully supported on the chair.
 There should be good lumbar support, and the seat back should be adjustable.
 The height of the seat should also be adjustable.
 When the height of the seat is correct, the fore arms should be horizontal, the shoulders relaxed and
not hunched up Feet should be flat on the floor, and the footrest should be provided if required.
 Thighs should be supported by the front of the chair, but there should be no excess pressure from the
chair on the underside of the thighs or the back of the knees.
 Space should be allowed for changing the position of the legs and obstacles removed from under the
desk.
 Space should be provided in front of the keyboard to support hands and the wrists during pauses in
keying.
 The distance between eye and screen should be in a good range so the data on the screen can be read
comfortably without squinting or leaning forward.
 The height of the VDU screen should be adjusted according to the user‘s typing proficiency, and the
needs of the task.
 For those with touch typing skills, or whose work is purely to screen without referencing written
material, the top of the screen should be level with the eyes, should be angled approximately 15-20
degrees to the horizontal.
 Users who are trained touch typists, and switch between screen, keyboard and reference material,
should have the screen set in a lower position to avoid eye and neck strain in constantly switching back
and forth. The screen plane should be as close as possible to 90 degrees from the line of sight.
 Contrasts and brightness should be set to produce a display which is comfortable to use, and should
be adjusted to take account of varying light conditions during the day.
 The screen should be positioned to avoid glare from either direct sunlight or artificial light. Where
possible blind should be used to shield the screen.
70
DOCUMENTATION DESIGN
A software product is composed of code and documentation. Documentation includes a wide range of
technical and non-technical books, manuals, descriptions and diagrams. The production of effective
documents is sometimes overlooked. Documentation is aimed at three different audiences:
 The software developer – who will depend on the documentation from previous life cycle stages to
guide continued development and maintenance.
 The manager – who will use documents from past projects to plan and understand current projects.
 The user – who will use learn how to use the software from the documentation.
In preparing documentation, careful consideration has to be given to a number of factors:
(i) Documentation should be complete i.e. All known pertinent information should be given or stated
somewhere.
(ii) Documentation should be consistent. Inconsistency will destroy the readers' confidence in the
documentation. The biggest challenge is not the consistency in the original documentation but
maintaining consistency through all the changes the product may undergo.
(iii) Documentation has to be pitched at the right level for its intended audience. A training manual
cannot demand as much from its readers as a design documentation can. Hence, we have to identify the
audience, determine its characteristics, background, and needs and plan accordingly. We should use
appropriate level of formality, and appropriate vocabulary in our presentation.
(iv) We need to select the right approach in presenting information so that it will be readily understood.
This includes a choice of format: text, technical manual (workbook) tutorial, video or audiotape, on-line
help package etc. Illustrations and tables are very important, since they organize and present large
amounts of material for quick comprehension. Adjunct material like indices, exercises, appendices,
glossaries must also be considered.
LOGICAL DATA DESIGN

Introduction
Data only has value to the organisation when it is accurate and properly controlled. Business process
change frequently but the underlying data is relatively stable and unless the core business of an
organisation changes, the data it uses will remain unchanged. For example, the processes needed to
control a warehouse stock retrieval system may change from being completely manual where paper
records are kept and where stock is stored and retrieved by forklift truck to being fully automated. In the
new system, the incoming goods are identified to the system by barcodes, the system decides where to
store the item and it controls cranes and automated goods vehicles to transport items from and to
locations. The core data, the item numbers and locations, remain unchanged, even though the processing
has changed dramatically.
During the 1960s, little attention was paid to data analysis and data design. Because no thought was
given to the fact that data has a right to exist on its own , separately from any processing that used it,
data came to be stored in the system only when a process required it. This also resulted in each user
holding their own customized version of the data. This means an increase of different names, sizes and
71
formats for the same data item. One piece of data could be held many times in different files in different
formats.
With the introduction of structured methods and database techniques greater attention was paid to data
analysis: a method which considers in its own right, independent of processing limitations or hardware
and software constraints. It also ensures that there is only version of data, and any duplication is clearly
agreed and controlled.
The resulting data model provides a complete picture of the data used by the organisation.
A logical data model consists of:

- Data entities
- Key fields for entities
- A list of attributes for each entity
- Relationships between entities.
DATA NORMALIZATION
Normalization is a process of removing duplication, and grouping related data to minimise
interdependence between data groups. The less interdependence that exists between data groups, the less
impact a data modification has, such as increasing the size of a data item. This approach to data analysis
allows the analyst to build a data model starting wit the attributes and subsequently grouping these
together to form entities.
The analyst then identifies the relationships between those entities. To take data through the full
normalisation process, you first need to access all data the organisation stores in the system. Typically,
this will be done by collecting one copy of every type of form and report. If there is an existing
computer system, screen printouts can also be used. From these inputs and outputs, every item that
appears is listed. The analyst must then identify how these data items relate to each other.
Normalisation stages
 First Normal Form
 Second Normal Form
 Third Normal Form
First Normal Form (1NF)

A table or relation is said to be in first normal form if and only if it contains no repeating groups. That
is, it has no repeated values for particular attributes within a single record. If there are repeating groups
of attributes, they should be isolated to form a new entity.
Second Normal Form (2NF)

A table is said to be in 2NF if and only if it is in first normal form and every non-key attribute is fully
dependent on the key attribute. All non-key attributes that are not dependent on the key attribute should
be isolated to form a new entity.
Third Normal Form (3NF)

A table is said to be in 3NF if and only if it is in second normal form and every non-key attribute in not
dependent on any other non-key attributes. All non-key attributes that are dependent on other non-key
attributes should be isolated to form a new entity.
72
Example: An invoice
Invoice No: Date:
Customer Delivery To:

Address
Product Code Description Qty Price Amount

1.
2.
3.
4.
Invoice Total
Unnormalised data
INVOICE (Invoice_No, Date, Cust_Address, Del_Address, (Prod_Code, Prod_Desc, Qty, Unit_Price,
Amount), Inv_Total)
First Normal Form (1NF)

INVOICE (Invoice_No, Date, Cust_Address, Del_Address, Inv_Total)
PRODUCT (Prod_Code, Invoice_No, Prod_Desc, Qty, Unit_Price, Amount)
Second Normal Form (2NF)

INVOICE (Invoice_No, Date, Cust_Address, Del_Address, Inv_Total)
INVOICE-PRODUCT (Prod_Code, Invoice_No, Qty, Amount)
PRODUCT (Prod_Code, Prod_Desc, Unit_Price)
Advantages of normalisation
 It is a formal technique with each stage of normalisation process eliminating a particular type of
undesirable dependency, as well as each stage of normalisation eliminating a certain type of redundancy.
 It highlights constraints and dependencies in the data and helps in understanding the nature of the
data.
 The 3NF produces well designed databases which provide a high degree of independence.
Disadvantages:
 Demands a thorough understanding of the entities and their relationships.
 It is a complex process, particularly if the entities are many.
73
FILE AND DATABASE DESIGN

File Organisation
The two general methods of file organisation are sequential and random access. Records in sequential
files must be read and written in the sequence in which they are physically stored in the files; that is the
user must always start at the beginning of the file and work to the end. With sequential files, users
cannot jump to the middle even if they are looking for just a single record. Sequential files reside on
either tape or disk and are used only in batch environments.
Random access files, on the other hand, allow the user to get any records on key without first reading the
records preceding it. Random files must reside on disk and are required for online environments.
There are two basic types of random access; direct access and indexed sequential. Direct access files
allow for the fastest retrieval of a single record but sometimes they waste space on disks and do not
allow for easy access of the records in sequential order. Indexed sequential files, on the other hand, are
slightly slower to access, but they do not waste quite so much space and they do allow for sequential
access.
The trend in the last few years has been towards random access files (just as the trend is towards on-line
processing), but there will always be some applications where sequential files are appropriate,
particularly those with a large volume of transactions and infrequent updating. Payroll data, for instance,
usually needs updating only once a week or a month, in time to produce paychecks. It is rarely necessary
to know how many hours an employee has accumulated as of the middle of the week. Therefore
sequential files might be adequate for a payroll system.
Factors influencing file design

 Purpose of the file. If for example, a file is to be used for on-line enquiry, direct access is needed
and the file must be organized so as to permit this, perhaps using indexed sequential organization or
random organization. This will in turn mean that disk or tape must be used to store the file. Files that are
to be used for batch processing only and where many of the records will require to be processed should
be organized serially or sequentially on tape as it is cheaper than disk.
 Constraints imposed by the system hardware? Does the available hardware support a particular file
organization and method of access? What data storage media are available?
 Updating required : It is either ‗in situ‘ or using the ‗grandfather - father – son‘ method. In-situ
involves updating, inserting or deleting records on – line, without retaining the old version of the file.
There should, of course be back up copies of the old version, in case something goes wrong, or as
archive files. In-situ updating of records in a random order requires direct access to a random or full
indexed file
The ‗father-son method involves taking a file and producing a new version, thus resulting in having two
generations of the file, the father and son generations. The method is more secure than in-situ because if
the system fails the old version of the file should be unharmed. Three generations of the file;
grandfather, father and son are often created before the oldest version is destroyed and the storage space
re-used.
 Frequency of file accessing for enquiry or updating (Hit rate). How many records in one file will
have to be accessed in one process? If the hit rate is high, batch processing of a sequential file may be
the most efficient design.
 Volatility How often will records need to be inserted, amended or deleted. Some files, for example
library files may rarely change. An indexed file copes with high volatility better than sequential files
74
since these have to be constantly re-organized to bring records to overflow areas back into sequence. An
index file need only its index updated when records are added to the file.
 Response time Online and real time systems require fast response times. Fast processing of records
can also be important in large batch systems because of the sheer number of the records involved. Where
fast response or fast processing times are required, the speed of access to records can be the dominant
factor for the file design and this usually means direct access methods with key transformation.
 The expected file size
DATABASE DESIGN
Database systems
A database can be defined as a structured organization of data stored in such a way that there is
minimum duplication to provide consistency of the data and also provide access for many users,
independently of the programs that are used.
Database management systems

Many installations are using database management systems (DBMS) to control data for which random
access is required. A DBMS is software that organizes and controls the reading and writing of data to
the database. Its purpose is to automate and simplify the accessing of data. With the DBMS, maintaining
the database is so much easier that programmers are free to spend more time on new applications.
Advantages of databases
 Avoidance of unnecessary duplication of data.
 Multipurpose data: -data can be used for several purposes.
 Stores data for the organization as a whole, not just for individual departments. The database concept
encourages management to regard data as a resource that must be properly managed, just like any other
resource. The installation of a database encourages management to analyse data, relationships between
data items and how data is used in different applications.
 Consistency:- Because data is held only once, it is easier to ensure that it is up to date so that no
department in an organization uses out of date data, or data that is different from the data used in other
departments.
Disadvantages
 Problems of data security and data privacy because data is accessible by many users. Strict controls
for access and sharing must be used.
 Since there is only one set of data, it is essential that data should be accurate and free of corruption.
 Since data is held only once but its use is widespread, there are potential problems of recovery of
data in the event of systems failure.
 Costs of creating and maintaining the database.
 Complexity:- It requires expert knowledge, particularly of the capabilities of the DBMS software,
setting up and controlling the database.
Database Structures /models

There are three database models;
Hierarchical model
Many relationships are One-to-Many or Many-to-One. Such relationships can be expressed conveniently
in a hierarchy. Each data item is related to only one item above it in the hierarchy, but to any number of
items below it.
75
In a customer database, for example, the hierarchical model might be used to show customers and
customer orders. An extract from a parts department database might be structured as follows;
Parts
Sales
CUSTOMER B100 CUSTOMER B102 CUSTOMER

JAMES MARY B200 SMITH
ORDER ORDER ORDER ORDER ORDER

2 x product P4 1 x product N9 4 x product P4 3 x product N9 1x product B6
1x product P2
The biggest drawback to files organized in this structure is that the user is limited in the number of
ways he or she can look for the records; the file organization makes it much easier to search for certain
items in the file records than for others. In the example above, in order to access an order record, it is
necessary to specify the customer to which it belongs, which is straightforward. However, if we were
required to obtain a listing of all customers who have ordered a particular part number, this would
require a search of each customer record, which is a long and tedious process.
Network model
Whereas a hierarchical structure allows a one – to -many relationships between data items, a network
database is a database in which the logical structure allows many-to-many relationships, as follows;
JAMES
B100 B102 B200 SMITH
JAMES MARY
B100: 2 x P4 B100: 1 x N9 B100: 4 x P4 B102: 1 x P2 B200: 3 x N9 B200: 1x B6
P4: Pin N9: Nuts B6: Bolt

P2: Pin 2mm
4mm
Relational model
A relational model organizes data elements in a series of two-dimensional tables consisting of rows and
columns. A row represents a record, and columns represent fields, or a part of the record. In a relational
data structure, the structure of the file is independent of the actual data. The relationships between
different entity types have been determined at the outset, and are not embodied in the records
76
themselves. A relational database thus does not have to navigate through other data before reading the
required data. The normalization process helps eliminate redundancies where records in any table
(relation) are identified using a key field.
CUSTOMER table
B100 JAMES
B102 MARY
B200 SMITH
PRODUCT table
B6 Bolt
P2 Pin
2mm
P4 Pin
4mm
N9 Nuts
ORDER table
B100 P4 2
B100 N9 1
B102 P4 4
B102 P2 1
B200 N9 3
B200 B6 1
There are six special properties of relational tables:

1. Entries in the columns are single valued. This implies that columns contain no repeating groups. In
other words, they have been normalized.
2. Entries in columns are of the same kind.
3. Each row is unique.
4. The sequence of columns is insignificant.
5. The sequence of rows in insignificant.
6. Each column has a unique name.
PROCESS DESCRIPTION TOOLS

Systems analysts use three documentation tools to create process descriptions:
 Decision trees
 Structured English
 Decision tables
Processes comprise of step-by-step procedures and decisions that are made as the processes progress.
Decision Trees
People will often have different ways of saying the same thing. This can create difficulties in
communication during system studies (analysts and manager may misunderstand each other‘s comments
77
or forget to discuss all the details). Decision trees are a method for describing decisions, while avoiding
difficulties in communication.
A decision tree is a graphical documentation tool that represents conditions and their resulting actions.
Characteristics
A decision tree is a diagram that presents the conditions and actions sequentially and thus shows which
conditions to consider first, second and so on. It is also a method of showing the relationship of each
condition and its permissible actions. The diagram resembles the branches on a tree, hence the name.
The root of the tree, on the left of the diagram, is the starting point of the decision sequence. The
particular branch to be followed depends on the conditions that exist and the decision to be made.
Progression from left to right is the result of making a series of decisions. Following each decision point
is the next set of decisions to be considered. The right side of the tree lists the actions to be taken,
depending on the sequence of conditions that is followed.
Decision trees are beneficial to analysts in two ways;
(i) The need to describe conditions and actions forces analysts to formally identify the actual
decisions that must be made. It becomes difficult for them to overlook an integral step in the decision
process, whether it depends on quantitative or on-quantitative variables.
(ii) Decision trees also force analysts to consider the sequence of decisions. The analyst can
subsequently determine which conditions are relevant and their order for certain actions to be taken.
Structured English
This method uses narrative statements to describe a procedure.

Structured English specifications still require analysts to identify the conditions that occur in a process,
decisions that must be made when these conditions occur and alternatives actions to take. However the
method also allows analysts to list steps in the order in which they must be taken. It does not show
decision rules as in decision tables, it states them.
No special format or symbols are used. Furthermore, entire procedures can be stated quickly since only
English-like statements are used.
Developing structured statements

Structured English uses three basic types of statements to describe a process: sequence structures,
decision structures and iteration structures. They work well for decision analysis and carried over into
programming and software development.
Sequence structure
A sequence structure is a single step or action included in a process. It does not depend on the existence
of any condition and when encountered, it will always be taken. For example, in an Accounts Payable
processing system, the following sequence of five steps would apply;
 Accept invoice for processing

 Prepare payment voucher using invoice
 Revise account balance sue using payment voucher
 Write supplier cheque
 Mail cheque to supplier
78
The steps are carried out in the order in which they occur.
Decision structures
Decision structures occur when two or more actions can be taken, depending on the value for a specific
condition. One must assess the condition and then make the decision to take the stated actions or sets of
actions, for that condition. Once the determination of the condition is made, the actions are
unconditional.
Through the use of IF/THEN/ELSE phrases, the structure points out alternatives in the decision process
quite clearly. From the invoice authorization example;
If invoice is signed
If goods not accepted
Reject invoice
End if
If valid purchase order was prepared
If authorization not received

Reject invoice
End If
If invoice is properly priced
Else
Reject invoice
End If
Then
Log invoice
Prepare payment voucher
End If
Iteration structures
In routine operating activities, it is common to find that certain activities are repeated while a condition
exists or until a condition occurs. Iteration instructions permit analysts to describe these cases.
From the above example:
Do until all invoices are processed

If invoice is signed
Else
If goods not accepted
Reject invoice
End if
If valid purchase order was prepared
Else
If authorization not received
Reject invoice
End If
If invoice is properly priced
Else
79
Reject invoice
End If
Then
Log invoice
Prepare payment voucher
End If
End do
Decision Tables
A decision table is a two-dimensional matrix with one horizontal row for each condition and each action
and one vertical column for each combination of values and resulting actions
Condition stub Condition entry

Action stub Action entry
 Each vertical column of a decision table is called a rule and each rule symbolizes one combination
of values. If constructed properly, the decision table has a rule to cover every possible combination.
Rules are made of selectors symbolized by Y(Yes), N(No) and - (for redundant or irrelevant rules).
Completing the table

 If the number of conditions identified is c, the number of possible rules is found by applying the
formula; Number of rules = 2c.
 Entries opposite the lowest condition should be completed, using Y and N alternately, until all the
vertical rules have been dealt with.
 Entries opposite the second lowest condition should be completed next using Ys and Ns in pairs until
all rules have been dealt with.
 Entries for the next condition are then completed using Ys and Ns in fours
 This process continues, using twice the number of Ys and Ns each time until all conditions are
completed.
 Once entered, the rules are read vertically in each column and an X entered at the action that
appropriately completes that rule. Actions which are mutually exclusive can be combined on a single
line.
Example 1
A student who passes the examinations and completes the course work and project satisfactorily is
awarded a pass. If the course work and the project are unsatisfactory, the student is asked to resubmit
the unsatisfactory work, as long as the exams have been passed. A student who fails the examinations is
deemed to have failed the whole course unless both the course work and the project are satisfactory, in
which case the student is allowed to re-sit the examinations.
80
Reduced
1 2 3 4 5 6 7 8
Exams passed Y Y Y Y N N N N
Course work Passed Y Y N N Y Y N N
Project passed Y N Y N Y N Y N
Pass X
Resubmit Course X X
work
Re-sit X
Fail X X X
Resubmit Project X X
Example 2
Candidates are accepted for employment if their qualifications and reference are satisfactory . If they
pass the interview and the qualifications or reference (but not both) are unsatisfactory, a job for
probationary period is offered. In all other circumstances the candidates application is rejected.
Eliminate redundancy
1 2 3 4 5 6 7 8
Qualifications Y Y Y Y N N N N
satisfactory
Reference satisfactory Y Y N N Y Y N N
Passed the interview Y Y Y N Y N Y N
Employ X
Employ on probation X X
Reject X X X X X
CASE TOOLS
Definition
A CASE (Computer Aided Software Engineering) tool is a software package that supports the
construction and maintenance of logical system specification models. They are often designed to
support the rules and interaction of models defined in a specific methodology. More
sophisticated CASE packages permit software prototyping and code generation.
CASE techniques aim to automate this document production process by ensuring the
automation of some of the analysis and design operation.
Although these tools may not completely automate the process of analysis and design, they are
certainly an improvement over the old ‗pencil-paper‘ method.
There are two types of CASE tools;

 Analyst workbenches
 Programmers' workbenches.
81
Analysts’ workbenches
These are software tools which perform several analysis tasks such as;
 Create design diagrams (e.g. DFDs on screen)
This enables the production of high quality documentation that can be easily updated.
Maintenance of complex models such as DFDs and E-R models can be made easy by the use of
diagramming facilities with the use of a mouse as in most graphic packages.
CASE toolkits come with a bank of pre-designed symbols including those used in DFDs and
flowcharts. They also offer a simple word-processing facility to assist in the production of the
material such as system specification and other reports to be produced.
 Checking adherence to design and development standards.
A CASE tool will not allow for rules to be broken such as linking a data store within a DFDS to
an external entity.
 Consistencies and relationships
CASE tools can verify that changes are consistent with each other and the relationships are
correct.
 They help generate input and output documentation
 Data dictionaries
They can create a logical data dictionary for the items identified. Entries will be made for
entities, data flows, data stores, processes, external entities and individual data items The
dictionary can easily be maintained, checked for consistency, cross referenced and analyzed. For
example, it will be produced to produce a listing of all data flows where a particular data item is
used.
Programmers workbenches
They provide similar features to ensure consistency of coding during the later stages of the
design cycle as follows;
 There is a code generator facility to automate the production of code in a high level language,
from say, Structured English.
 Diagnostic aids enable subroutines or modules to be tested independently of other programs.
 A library of subroutines is also provided. These can be incorporated into programs.
CASE Advantages
 They make the construction of various analysis and design logical elements such as DFDS,
E-R models easy.
 Integration of the separate elements. For example, an analyst looking at a diagram can pull
up a dictionary definition for a piece of data without exiting the dictionary screen. By pointing to
a file symbol, the analyst can display the data model for that file. Such integration allows the
software to do additional rechecking, such as notifying the analyst when a data flow diagram
contains a piece of data that hasn‘t yet been defined in the dictionary.
 Streamline development of analysis documentation. CASE allows developers to use graphics
like data flow diagrams that were previously cumbersome to draw and revise, particularly for
84
large projects. Data dictionaries with thousands of entries, which were also impossible to
maintain manually, can be maintained and made available to analysts.
 Allow easy maintenance of specifications, which in turn means the specifications will be
more reliably updated. Specifications that are up-to- date provide a documentation trail for later
system maintenance efforts.
 Enforce rigorous standards for all developers and all projects. In effect, everyone is talking
the same language, which makes communication between developers more efficient.
 Check specifications for errors, omissions, and inconsistencies.
 Provide everyone on the project team with easy access to the very latest update of the project
specifications.
 Encourage iterative refinement, since the specifications are easier to change. As a result, a
higher –quality system (i.e. one that has fewer defects and missed requirements) that better meets
the needs of the users is developed. This has a net effect of increasing productivity by decreasing
correction efforts.
CASE Disadvantages
 CASE products can be expensive.
 CASE is still in its infancy, and most practitioners are often in the position of being
pioneers. Because the technology is not yet fully evolved, CASE software is often large,
inflexible, and temperamental.
 Today‘s CASE products do not yet provide a fully integrated development environment. The
user must often piece together different tools from different vendors in order to serve all phases
of the system development life cycle.
 Users often expect CASE to be an overnight cure for system development problems, but
instead there is usually a long period of learning before the tools can be effectively used. As a
result, positive results may not show up on the organisation‘s income statement. It takes time to
reap the benefits of CASE.
 The installation and implementation of a CASE product requires a great deal of control and
monitoring on the part of the management. If the proper training and motivation are not
provided for the practitioners, CASE may be used a little more productively.
Analysts must have a mastery of structured analysis and design techniques if they are to exploit
CASE. If analysts are expected to learn these structures techniques at the same time they are
learning CASE, all time and cost estimates for the project should be inflated to allow for an
extended learning period
PROTOTYPING
Prototyping is the process of building an experimental system information system quickly and
inexpensively for evaluation and demonstration so that end users can better determine
information requirements.
The prototype is a working version of an information system or part of the system, but is meant
to be only a preliminary model. Once operational, the prototype will be further refined until it
conforms precisely to users‘ requirements. For many applications, a prototype will be extended
and enhanced many times before a final design is accepted. Once the design has been finalized,
the prototype can be polished to a finished production system.
85
- Building a prototype during the analysis and design phases can clarify the users‘ requirements
and verify that the finished system will meet those requirements. A prototype also gives users the
opportunity to see what they have asked.
- Prototyping is user centered, that is the user and the analyst work closely together as the
prototype evolves through a process of iteration, or incremental refinements.
Steps in Prototyping
(a) Identify user‘s basic requirements- The system designer (usually an IS specialist) captures
the users basic requirements.
(b) Develop a working prototype- The systems designer creates a working prototype quickly,
most likely using the 4GL, CASE tools, etc. The prototype may only perform the most
important functions of the proposed system, or it may consist of the proposed system with
restricted files.
(c) Use the prototype - The user is encouraged to work with the system to determine how well
the prototype meets his or her needs and to make suggestions for improving the prototype.
(d) Revise and enhance the prototype- The system builder notes all changes requested by the
user and refines the prototype accordingly.
Advantages of prototyping
(a) Heavy user involvement means a more complete, accurate and user friendly interface.
(b) It is likely to foster positive attitude on the part of the user.
(c) Prototyping often results in a development project that costs less and takes less time to build.
(d) A system that has been prototyped during information gathering is cheaper to maintain
because of reduced uncertainty; there are often fewer errors and omissions. A prototype that
evolves into a finished system is also often inexpensive to maintain because a system coded in
say, a fourth generation language is easier to modify than one coded in a third generation
language.
Disadvantages of prototyping
a) It is only suited for applications that are oriented to simple data manipulation and decision
support. However, systems that are based on batch processing or that rely on heavy calculations
and complex procedural logic are generally unsuitable for the prototyping process.
b) Rapid prototyping can gloss over essential steps in systems development. Basic systems
analysis and requirements analysis cannot be short- circuited. The appeal of an easily and rapidly
developed prototype may encourage the development team to move too quickly towards a
working model without capturing even a basic set of requirements.
c) The final steps to convert the prototype into a polished system may not be carried out. Once
finished, the prototype often becomes part of the system. If the prototype works reasonably well,
management may not see the need for reprogramming and redesign. Some of these hastily
constructed systems may be difficult to maintain and support in a regular production
86
environment. Prototypes may not be very technically efficient to accommodate large quantities
of data or a large number of users in a production environment.
d) Prototyped systems still need to be documented and tested , but often these steps are
shortchanged. Because prototypes are constructed so effortlessly, managers may assume that
testing can be handled by users on their own and any further testing requirements can handled
later. Because the system is so easily changed, documentation may not be kept up to date.
DEVELOPING SYSTEMS WITH APPLICATION SOFTWARE PACKAGES

Another alternative to information systems development is by purchasing an application
package. An application package is a set of prewritten, pre-coded application software programs
that are commercially available for sale or lease. When an application package software is
available, it eliminates the need for writing software programs when an information system is
developed and reduces the amount of design, testing, installation and maintenance work as well.
Examples of applications for which application packages are available.

 Hotel Management
 General ledger
 Inventory Control
 Payroll
Packages are chosen as a development strategy under the following circumstances:

(i) Where functions are common to many companies. For example, every company has a payroll
system and payroll systems typically perform the same functions.
(ii) Where information systems resources for in-house development are in short supply.
With trained and experienced systems professionals in limited supply, many companies do not
have staff that is either available or qualified to undertake extensive in-house development
projects. Under such circumstances, packages may be the only way to enable a system to
be developed. Most companies also lack a budget to develop all their systems in house and
consequently, the most effective development strategy is likely to involve use of an application
package.
(iii) When desktop microcomputer applications are being developed for end users.
SECURITY AND CONTROL DESIGN

Data processing by computer creates extra problems for control because of its special
characteristics, which are that:
(i) Large volumes of data are concentrated into files that are physically very small.
(ii) Large volumes of data are processed without human intervention, and so without humans
knowing what is going on. This places greater reliance on the accuracy of programs and of data
and data on files.
87
(iii) It is easy to lose data on files. Equipment can malfunction, data files can become corrupt
and store meaningless data, data can get lost when files are copied, and data files are susceptible
to loss though theft, flood or fire.
(iv) Unauthorized people can gain access to data on files, and read confidential data or tamper
with the data. This is a particular problem with on-line systems because access to a computer
program and master file can be from any remote terminal. It is even possible for ‗hackers‘ to use
their home computers to gain access to the files and programs of other systems.
(v) Information on a computer file can be changed without leaving any physical trace of the
change.
Risks to data
The dangers associated with information storage on a magnetic medium include the following.
(vi) Physical security; Tapes or disks can be stolen, mislaid or damaged, or destroyed by fire,
flood or vandalism.
(vii) Environmental security; Tapes and disks are susceptible to magnetic fields, dust and
extremes of temperature and humidity.
(viii) Loss of confidentiality; Information stored in magnetic files may be accessed by

unauthorized persons. This is a particular problem in larger systems, with remote terminals.
(ix) Processing the wrong file; Since data in magnetic form, and not visible, the wrong file
could be read, or a file could be overwritten when its data is still needed.
(x) Hardware or software corruption; Hardware or software faults may damage or destroy
the data on files.
Types of controls
(i) Administrative controls which are designed to ensure the smooth running operation of the
systems.
(ii) System development controls, which are designed to ensure that any new system does not
present new risks to the environment.
(iii) Application controls are built into operations and ensure that processed data is accurate and
complete.
Administrative controls
These are controls over data and data security that are achieved by administrative measures.
They include;
(xi) Controls over personnel;
(xii) The segregation of duties;
88
(xiii) Physical security;

(xiv) Access controls;
(xv) Protection against viruses and hacking;
(xvi) Good office practice;
(xvii) Back up and standby facilities;
Personnel
Controls related to personnel, which were developed before the advent of computers, include;
(i) Job rotation, so that employees change at random interval, thus making it uncertain that
an individual will be able to set up a breach of security in the time available.
(ii) Enforced vacations;
(iii) Access to information granted, not on the basis of rank in the management hierarchy or
precedent but on a need-to-know basis.
The segregation of duties

Work should be divided between systems analysts, programmers and operating staff, and
operations jobs themselves should be divided between data control, data preparation and
computer room operations. The functions of an organisation structure, as far as control is
concerned, are;
(i) To assign responsibility for certain tasks to specific jobs and individuals. A person in a
given job is responsible for ensuring that certain controls are applied. Some jobs are specifically
control jobs. These are the jobs of the data control clerks and, to a large extent, of the file
librarian.
(ii) To prevent fraud. It is easier for a person to commit fraud if he can input data, write
programs and operate the computer all by himself. By dividing up the work, it is made harder to
commit fraud or tamper with data, except in collusion with others.
Duties may be segregated by ensuring that no member of staff on more than one of:
(i) Data capture and entry
(ii) Computer operations
(iii) Systems analysis and programming
An organisation chart and manuals which sets out clearly who does what, and what practices are
forbidden, should be forbidden.
Data processing staff should be properly trained in security and control measures and the need
for them.
Physical security
Physical security comprises two sorts of controls:
(i) Protection against disasters such as fire and flood;
(ii) Protection against intruders gaining physical access to the system.
89
Fire is the most serious hazard to computer systems. The destruction of data can be even more
costly than the destruction of hardware. A proper file safety plan is an essential feature of
security procedures, in order to prevent fires, detect and put out fires. Fire safety includes:
(a) Site preparation (appropriate building materials and fire doors)

(b) Detection (smoke detectors)
(c) Extinguishers
(d) Training for staff i.e. observing safety procedures.
Methods of controlling human access:

(i) Personnel (security guards)
(ii) Mechanical devices (such as keys, whose issue is recorded);
(iii) Electronic identification (such as card-swipe systems, where cards are passed though
readers)
Physical security installation

Measures to ensure physical security in the computer room are as follows:
(a) Computer rooms should be kept locked when not in use. Only authorized personnel should
have keys. Locks to computer rooms should be secure.
(b) Computer files should be kept locked in a safe place, such as fireproof safe.
(c) The physical conditions in which the hardware and files are kept should be suitable, that is
too hot, dump or dust.
(d) Measures should be taken to minimize the risks of fire. Waste paper should not be allowed to
pile up. Computer rooms should have smoke alarms and be fully equipped with fire
extinguishers.
Access controls
Access controls are controls designed to prevent unauthorized access to data files or programs.
Access controls which can be built into system ‗s software are:
(a) Passwords;
(b) Encryption and authentication
Passwords
Passwords can be applied to data files, program files and parts of a program. The computer does
not allow a user access to the relevant facilities until he or she has typed the appropriate
password.
(a) One password may be required to read a file and another to write new data.
(b) The terminal user can be restricted to the use of certain files and programs
90
Many password systems come with preset passwords. It is essential that there be changes if the
system is to be at all secure, since such common passwords may become widely known to people
in the industry.
Passwords ought to be effective in keeping out unauthorized users, but they are by no means
foolproof.
The following are reasons why.

- Passwords can be guessed especially when simple passwords have been used.
- Authorized users of passwords can reveal them to unauthorized people
- When carelessly handled; for example hiding password codes beneath keywords or
stashing them in drawers.
-
The following should be observed when passwords are used;
(i) Keep your password secret. Do not reveal it to anyone else.
(ii) Do not write the password down.
(iii) Change your password regularly.
(iv) Change and use your password discreetly.
(v) Do not use an obvious password. (Such as your name)
(vi) Change your password if you suspect that anyone else knows it.
Data communication controls: Encryption and authentication

When data is transmitted over a communication link or within a network, there are three security
dangers:
(i) A hardware fault
(ii) Unauthorised access by an eavesdropper
(iii) Different intervention by someone who sends false messages down a line, claiming to be
someone else, so that the recipient of the message will think that it has come from an authorized
source.
Encryption is the only secure way to prevent eavesdropping (since eavesdroppers can get round
password controls, by tapping the line or by experimenting with various likely passwords).
Encryption involves scrambling the data at on end of the line, transmitting the scrambled data
and unscrambling it at the receiver‘s end of the line.
Protecting against hacking and viruses

As it becomes common for computers to communicate over long distances, the risks of
corruption or theft of data or even whole programs become much greater. Two interconnected
issues are hacking and viruses.
 Hacking
A hacker is a person who attempts to invade the privacy of a system. Hackers are normally
skilled programmers, and have been known to find out passwords with ease. The fact that a lot of
information can be transmitted over the public telephone network has made it hard to trace
individual hackers, who can therefore make repeated attempts to invade systems. Hackers have
91
in the past mainly been concerned to copy information, but a recent trend has been their desire to
corrupt it.
 Viruses
Computer viruses are currently the cause of much concern. A virus is a piece of software which
infects programs and data and which replicates itself. There are a number of types of viruses;
A Trojan is a program that while visibly performing one function, secretly carries out another.
For example, a program could be running a computer game, while simultaneously destroying a
data file or program.
A logic bomb is a piece of code triggered by certain events. A program will behave normally
until a certain event occurs, for example disk utilization reaches a certain percentage. A logic
bomb, by responding to such conditions, maximizes damage, for example it will be triggered
when a disk is nearly full or when a large number of users is using the system.
A trap door is not itself a virus, but it is an undocumented entry point into a computer system. It
may not be found in design specifications, but may be put in by software developers to enable
them bypass access controls while working on a new piece of software. Because it may not be
documented, it may be forgotten and used at a later date to insert a virus.
Viruses can spread via disks, but have been known to copy themselves over whole networks.
How can organisations protect themselves from viruses?

(c) Vaccine programs exist which can deal with some viruses, but if the virus lives in the
bootstrap program, the virus can work before the vaccine is loaded.
(d) Organisations must guard against the introduction of unauthorised software to their systems.
Many viruses have been spread on pirated software or popular computer games.
(e) Organisations should as a matter of routine ensure that any disk received from outside with
data on it is virus-free before the disk is used. Any flaws in a widely used program should be
rectified as soon as they come to light.
(f) Establish procedures and reviews to minimize the chances of infection. Virus protection
controls should become part of the internal control system of an organisation, as with controls to
prevent fraud.
Good office practice

Data is often shared between users.
 There should be a designated data owner for each file responsible for:
(a) Keeping the data accurate and up to date.
(b) Deciding who should have access to the data.
(c) Developing security procedures in conjunction with the data security manager.
92
 If computer printout is to include confidential data, it should be shredded before being

thrown away.
 Disks should not be left lying around an office. They can get lost or stolen. More likely, they
can get damaged.
 The computer environment (humidity, temperature and dust) should be controlled
 Files should be backed up regularly.
 Appointment of a system expert to be responsible for learning technical details about the
office computer user problems.
 Have a user support facility such as an information center.
 Have a binding, strong contract with the manufacturer or a third party for service and repair
of machines or insurance cover.
Back ups and standby facilities

All master files should be backed up after each updating run. Back ups should be stored in a
different place from the original files.
Standby hardware facilities

Hardware duplication will permit a system to function despite a hardware breakdown. The
provision for backup computers is costly, particularly where these systems have no other
function. Many organisations will use several smaller computer systems and find that a
significant level of protection against system faults can be provided by shifting operations to one
of the systems still functioning. Where a organisation has only one system to rely upon, this
ready recourse to a back up facility is unavailable. In these instances, one response would be to
negotiate a maintenance contract which provides for back up facilities.
System Development controls

When a computer system is developed from scratch, either in house or a by a software house,
there should be controls over the system design, development and testing. Because of the time
spent on systems development, the cost of it and the complexity and the volume of work
involved, it is essential to lay down high standards of control.
The main objectives of system development controls are as follows.

(a) To ensure that new computer systems are developed only if they appear to be beneficial.
System justification should be on the grounds of favourable cost-benefit analyses or other
performance criteria
(b) To ensure that each system under development has clear, specified objectives.
(c) To control the scheduling of development work. This can be achieved through techniques
such as critical path analysis.
(d) To ensure that suitable operational and administrative and controls are built into the system
design when it is being developed.
93
(e) To ensure that users acquire an understanding of the new system. The handover of the
computer system from the hardware and software experts to non technical staff must be done in
such a way that the computer users are able to learn as much about their system as they need to
know. Training of staff will be necessary, but there should also be full, clear and non-technical
documentation of the system.
(f) To establish a basis for management review of the system
(g) To ensure that systems and programs are maintained when the system becomes operational
(h) To ensure that proper and complete documentation of the system is created and maintained.
Many of these controls will be provided by the systems development methodology used.
Controls over amendments to the system design is needed. Once development has started, it is all
too easy for the system designer or the user department managers to think of new features to add
to the system or improvements that can be made, with the result that amendments get written into
the system as development progresses. Some amendments may be desirable, others may not be
worthwhile.
Controls should be exercised over amendments so that if any amendments are proposed which
were not included in the system specification, they must be authorised at a suitable managerial
level. The authorization and details of the amendment should be included in the amendments
section of the system specification.
Controls over file conversion

The conversion of a master file is one of the big problems of systems implementation and proper
procedures and controls must be laid down to ensure that there are no unauthorized conversions
and that the correct records are accurately and completely transferred onto magnetic files. The
procedures may include:
(a) Full planning of the file conversion, including staff to be used, records to be converted
(possibly via data preparation), controls to be set up and the date of conversion.
(b) The establishment of a control group to follow up errors which may occur during the
conversion.
(c) Printing out master files after conversion and manually checking them back to the
original records.
(d) The reconciliation of accounting records to those kept under the old system.
(e) Division of responsibility among the conversion staff (additional staff may have to be
brought in to help with the conversion).
(f) Testing of the new master files using the test data and the control and documentation of
any changes necessary.
94
Data processing standards

Data processing standards are standards for the development; Procedures and documentation of
computer systems. The purpose of the standards is to minimize the likelihood of errors and
misunderstandings in both the development and operation of computer systems. More
specifically, standards are helpful in the following ways;
 The documentation of a computer system

Documentation is needed for systems and program specifications, and also for operator
instructions. The existence of standards for documentation:
(a) Establishes the need to document a system:
(b) Provides a standard format for documenting the system, which helps to ensure that
nothing is left out of the specification:
(c) Gives the people operating a system somewhere to look up and learn the system‘s
operating requirements:
Usefulness of documentation standards

 Communication of information about the system
Standards documentation provides a means whereby information about a system can be
communicated, for example between programmers and analysts, and between system developers
and the users and the operators of the system.
 Continuity after the staff changes and an aid to training

People leave their job from time to time or are absent for one reason or another. Unless a system
is well documented in a standard way, or has been designed according to a standard procedure, it
might be difficult for a person‘s stand-in or replacement to pickup the job where his predecessors
left out.
 Standards help people to learn the system. They are particularly helpful for staff moving
from one job to another because they will have some familiarity with the format of the
documentation standards e.g. if a computer operator moves from his job in A Ltd to a new job in
the computer center for B Ltd, he will be able to learn his new job partly by referring to B Ltd.‘s
standards for computer operations. These standards will be similar in format to the ones used in
A Ltd and so the operator will know how and where to look up information that he needs to
know.
Documentation for a system includes user manuals, hardware and operating software manuals
System specification and program documentation. Documentation is a feature for most systems
analysis and design methodologies.
95
Data processing standards should ensure that all the staff involved in the computer system has
proper instructions and that these have been fully documented. This means that there must be:
(a) Operation instructions for each computer installation
(b) Operation instructions for each program
(c) File library instructions, specifying how files should be labeled, safeguarded, issued and
if necessary, reconstructed.
(d) Data conversion instruction for the data preparation staff
(e) Data control instructions for the control section
(f) User department instructions
The system specification

The system specification is a complete description of the whole system and must be kept up to
date as part of the system are changed or added to. Many of the problems in computer
installations because of inadequate documentation and controls must be set up to ensure the
updating procedures are always carried out.
Program specifications
Program specifications or program documentation describe programs using charts, full listings of
the programs and details of test data and results.
Program specification (excluding listings of programs themselves) is drawn up by the system

analyst. A copy of a program specification is given to the programmer responsible for writing the
program, and the programmer then uses the program as the basis for writing and testing the
required program. When the program has been written and tested and, one copy of the final
specification will form part of the overall systems specification and the final copy will be
retained by the programmer to form part of the programmer‘s own documentation for the
program.
Computer operations manual

Computer operations manual provides full documentation of the procedures necessary to run the
system. Amongst the matters to covered by this documentation are:
(a) Systems set-up procedures. Including details for each application of the necessary file
handling and stationery requirements;
(b) Security procedures. Particular stress should placed on the need to check that proper
authorization have been given for processing operations and the need to restrict use of the system
to authorized operators.
(c) Reconstruction procedures. Precise instruction should be given for such matters as file
dumping and also recovery procedures to be adopted in the event of a systems failure.
96
(d) System messages. A listing of all messages likely to appear on operators‘ screens
should be given together with an indication of the responses, which they should evoke.
(e) Operating systems manual. These are manuals that describe an operating system.
User manuals
User manuals or users documentation explain to users how to run a system, but do not give
unnecessary technical details such as program listings. Matters to be dealt with include:
(a) Acceptance testing: responsibilities for the preparation of test data and subsequently
checking the test results.
(b) Input: responsibilities and procedures for the preparation of input including
requirements for the establishment of batch control totals and for authorization;
(c) Error reports; full explanation of the nature and form of error reports (such as reports of
items rejected by computer checks) and instructions as to the necessary action to be taken;
(d) Master file amendment procedures: full explanations of the authorization and
documentation required for master file amendments:
(e) Output: what is produced, what form it takes and what should be done with it.
System changes manuals

Amendments to the original systems specification will almost inevitably occur, in addition to the
computerization of additional activities. The objective of a system changes manual is to ensure
that such changes are just as strictly controlled as the original systems development and
introduction.
Application controls
Errors in data processing can easily occur. Application controls are intended to detect errors and
ensure that they are corrected before processing proceeds further.
Input data can get lost, or it might contain errors. Human error is the greatest weakness in
computer systems. The extensiveness of the input controls will depend on the method of
processing input data (for example key board input or OCR document input) and the cost of
making an input error. If the consequence of input errors would be costly, the system should
include more extensive input controls than if the cost of input errors were insignificant.
Errors may occur at various stages of data processing:

Data capture
Mistakes include:
(a) Writing an incorrect figure, such as 1243 pounds instead of swapping 1234 pounds:
swapping figures around by mistakes is referred to as a transposition error:
97
(b) Spelling mistakes, such as getting a customer‘s name wrong:

(c) Measuring mistakes, such as timekeeper writing down an incorrect time for job because
he read his watch incorrectly
(d) Classifying mistakes such as a cost accountant recording a direct labor cost as an
overhead item or an expenditure in administration as a production cost.
Errors in data capture are difficult to spot once they have been made, because they are often
errors on the source document. Checking can reduce them. One person‘s work might provide a
check on the accuracy of another‘s. For example, getting another person to add up to the total
amount of invoices received that day, from the invoices themselves could check the recording of
suppliers‘ invoices. This total could then be checked against the total for invoices recorded.
Another way of dealing with errors in data capture is to reduce the likelihood of errors arising in
the first place by including as much pre-printed information on the data recording documents as
possible and by giving clear instructions about how the documents should be filled in.
The use of turnaround documents and OCR, MICR, bar coding or in some applications plastic
cards with magnetic stripes containing some of the input data reduces the need for manually-
prepared input data, and so reduces data capture errors.
Transcription
Transcription errors occur when data is copied from one form to another. For example a person
might jot down some data on a piece of scrap paper, and then copy it incorrectly onto a formal
document later on.
Data preparation errors occur when the original captured data has to be transcripted into a form
that the computer can read such as a magnetic tape or magnetic disk. Errors arise because the
original data can be copied wrongly in the machine – readable form. These errors are sometimes
referred to as data conversion errors.
If input data must be prepared manually, controls can be applied to minimize the number of
errors.
(a) Staff who prepare data for input should be well trained and properly supervised.
(b) Data input documents should be in a format which helps the person preparing the data
to fill them properly.
(c) When data is input by keyboard the screen should be formatted so as to help the
keyboard operator to input the correct data. User-friendly software packages might provide on-
screen prompts and formatted for input data.
98
If data must be converted form one form to another for input, for example from a paper
document onto disk the data could be keyed to check for the copying errors. However this is
expensive.
The staff that prepares the data should be encouraged to look for errors.
(a) If input is done by keyboard the input data will be shown on the VDU screen and a
visual check on the data can be made.
The input record will often have a key field identification code. For example a sales ledger file
will consist of customer records, which each customer having a code would be part of input data
and the program might search for the customer record on the sales ledger file, and display it on
the VDU screen. The input operator could then check visually that the correct customer record is
being processed.
(b) If input is done in batches, the program might produce a listing of the input data, which
could be checked for accuracy. Printed listings of input data also provide an audit trail in
computerized accounting systems so that internal and external auditors can follow transactions
through the system later.
Data transmission
Errors in transmitting data, involve the loss or corruption of data, which is sent to the computer,
by post, courier or telecommunications link from a remote terminal.
When data is input from a terminal, the terminal user should be able to check that the data has
been input fully and accurately by obtaining a printout back from the computer of all accepted
data.
When data input is batched and physically dispatched to a computer center processing, batch
control checks can be applied to ensure that all the data that has been dispatched is safely
received at the computer center. These checks involve:
(a) The user department giving each batch a unique identification number:
(b) The identification numbers of all batches being written on a batch control document, by
the user department supervisor. This document will be sent to the computer center, with a copy
being retained by the user.
(c) The data control clerks in the computer center checking that the batches that are
received tally with the numbers on the batch control document.
Processing
99
Errors might occur or come to light during data processing, for three broad reasons.
(a) It may become apparent during processing, when it would not necessarily have been
apparent at the data capture stage, that there is something wrong with the transaction data. An
attempt should be made to locate these errors as soon as possible, to prevent the computer from
acting on invalid data. A data validation (or data vet) program is used to check the input data for
errors that can be spotted by computer logic.
(b) It may become apparent during processing that there is something wrong with the
master file record. Examples would be:
(i) Trying to record an invoice sent to customer number 234, when
no such customer account has been opened;
(ii) Trying to delete employees number 678 from the payroll when there is no such
employee in the payroll records
(iii) Trying to open a new account for supplier number 372 when there is already
an account for that supplier.
These are referred to as errors because they come to light when the master file is updated.
(c) There may be a programming error i.e. a flaw in the logic of computer program.
Validation checks
Some checks on the validity of input data can be written into the system‘s programs. These data
validation checks (or data vet checks) might be performed by a separate data validation program
in a batch processing system. Alternatively any program can incorporate validation checks on
input data for example on data keyed from a terminal into an on-line system.
Data validation
The data validation program or program which incorporates data validation routines, will be the
first program in each batch processing application. The program attempts to find errors in the
input record or batch to prevent them any further.
The checks, which can be made, are logical checks, which prevent some of the worst types of
error form getting through to be processed. Data validation does not provide a comprehensive
error check, however and some errors on source document are likely to go undetected. This
emphasizes the need for control over source document creation.
The main types of data validation checks are outlined below. Note that the same type of check
can be made on different fields of a record and not all types of check need appear in a data
validation program. However a single program might carry out dozens of validation checks on
different records and fields.
100
(a) Range checks are designed to ensure that the data in a certain field lies within predetermined
limits. For example in a wages application, the program may contain instructions to reject any
clock card with ‗hours worked‘ outside from the range from 20 to 80 hours and to print out a
special report (for checking) on any clock card with hours worked outside the range from 35 to
60 hours.
(b) Limit checks sometimes called credibility or reasonable checks are very similar to range
checks, but check that data is not below a certain value, or above a certain value. In the previous
example the check of hours worked might be that the value in the record field does not exceed 80
with a rage check, there is an upper bound but not both.
(c) Existence checks are checks on record fields to ensure that to ensure that the data is valid for
that field. For example:
(i) Check that the record type is 1, 2 or 3
(ii) Check that the stock code exists by looking up the stock code number of the
record in reference file.
(d) Format checks (picture checks) check that the record has the required data fields and that
each data field has data in the correct format. For example.
(i) Check that the format is all numeric 9999 (here, four figures);
(ii) Check that the format is all alphabetic AAAAA (here, five letters);
(iii) Check that format is alphanumeric A999 (here, one letter followed
by figures);
(e) Consistency checks check that the data in one field is consistent with data in other field.
For example in a payroll system there might be a check that if the employee is a Grade C worker,
he or she belongs department 5, 6 or 9.
(f) Sequence checks check that records and batches are processed in the correct sequence.
(g) Completeness checks

(i) A check can be made to ensure that all records have been processed. For
example, if a weekly processing run must include one record for each of the five working days of
the week, a completeness check can ensure that there are five input records.
(ii) Completeness checks on individual fields would check that the item of data has
not been omitted from an input record.
101
(h) Check digits are numbers (or perhaps letters) added to a code to give it some special
mathematical property, which can be checked by the computer.
(i) Batch total checks. In a batch processing system, the number and/or the total value of the
records processed by the computer from each batch, including rejected records, should reconcile
with the control total(s) in the batch control slip, which will also have been input to the program.
When validation checks identify an error, there are a number of possible outcomes.
(a) The record concerned will probably be rejected and processed no further with perhaps a
message on screen. Rejection reports may be printed out at some stage during processing.
(b) The record concerned may not be rejected, but an exception report might still be output
or the operator advised in some way on screen. This may happen, for example, where a range or
limit check is not satisfied. Just because a record is not within pre-set limits does not
automatically mean that it is incorrect. If it is valid, then not processing it would be a waste of
time. However, administrative controls must ensure that all exception reports are followed up.
(c) If an error is revealed by batch controls, the whole batch must be checked.
Output controls
There should be controls over output from computer processing.
(a) In a batch processing system, where data is batched and sent off to a computer center there
should be a check to make sure that the batches that were sent off have been processed and
returned.
(b) All input records that have been rejected by data validation checks and master file update
checks must be looked at to find out the reasons. Corrected data should then be prepared for re-
input. Some errors might need immediate correction, such as those on input records, which have
been, rejected by data validation checks in a payroll program for preparing salary payments to
staff.
(c) Output should be correctly distributed and a log should be kept of the distributions that
have been made. In a computer center, this is the responsibility of the data control staff. In an
office, someone has to be responsible for dealing with output from the printer.
(d) Output onto magnetic files should be properly labeled and stored.
File controls
Controls can be applied to ensure that:
(a) The correct files are used for processing
(b) Data is not lost or corrupted
(c) If data is lost or corrupted then it can be recreated
102
(d) Unauthorised access to data is prevented
In a large computer center, the administrative responsibility for the physical security should be
assigned to a member of staff.
Software controls over files

The computer will check that the correct file has been loaded for processing before it will begin
its processing operations. It can do this by checking the file header data written on the file in
magnetic form, and comparing this data with data about the file that it has been instructed to
process. If the computer has been instructed to process master file A, it will first of all check the
master file A has been loaded for processing, and that correct generation of the file has been
loaded.
Checkpoints and recovery procedures

A checkpoint or restart program is a utility that intervenes at certain points (checkpoints) during
the running of a program and dumps the entire contents of memory onto a storage device.
Should anything turn out to be wrong with the running of the application program the application
program can be taken back to the checkpoint before the error occurred and restarted with
conditions exactly as they were before.
Control totals
A control total could be:
(a) The number of records on a file
(b) The total of the values of a particular field in all the records on a file for example the
total of debts outstanding in all the customer records on a sales ledger file.
(c) The number of records in a batch (batch control total)
(d) A harsh total. This is a total that has no meaning except as a total check; for example, the
total of customer account numbers.
Control total checks are written into programs to ensure that:

(a) No records have been lost
(b) No records have been duplicated
(c) Input files have been read fully
(d) All output records have been written to output files.
103
Control totals are established into two different ways, for example by adding up the account
numbers after the most recent run, by taking the total after the previous run and adjusting it for
new accounts for accounts closed. Any difference between the totals can be investigated.
Database controls
Databases present a particular problem for computer security. Databases can often be accessed
by large numbers of people, and also there is a risk of alteration, unauthorised disclosure or
fraud.
It is possible to construct complicated password systems, and the DBMS can be programmed to
give limited views of its content to particular users. However there are problems in ensuring that
individuals do not circumvent the controls by means of inference. For example, an employee
database might forbid you to ask whether John is an employee in category A. However, if you
know there are only three employee categories, A, B, and C, and there is no prohibition on
asking about categories, B, and C, you can work out the members of category A by elimination.
Interference controls may make this difficult by limiting the number of queries, or by controlling
the overlap between questions.
PROGRAM DESIGN
A ‗program‘ has many synonyms: process, module, unit, routine, subroutine, macro, etc. All of
these are lines of code with a beginning and an end, they serve one purpose, such as validate
customer number, and have a well defined interface with the rest of the system.
The following points are important in program design:

 One function. Systems are portioned by a hierarchy of programming modules. Each program
should carry out only one function. Modularity makes the program easier to maintain.
 Size. The fewer the number of lines of code in a program, the more efficient the code will be
(in terms of storage pace and execution time) and the easier it will be to maintain.
 Cohesion measures the strength of relations within a program. This means that what
happens in one subroutine affects the other subroutines of that program. A program that performs
more than one function will have low cohesion. A high degree of cohesion within programs
results in a more maintainable system, and therefore a higher quality solution.
 Coupling is a measure of the strength of the bonds between programs. Ideally programs
should have little dependence on other programs in the system. This is so that any amendments
to the program have little or no impact on the other programs in the system.
Why break the system into programs?

 One program should be written by one programmer, so if the system was just one program, it
would take one programmer months or years to write.
104
 Smaller programs are easier to specify, test and modify because errors or the impacts of a
change are contained within fewer lines of code.
 Programmers are more motivated to code in the areas of the system that interests them.
 A large number of small programs makes rescheduling the work easier. If one programmer is
taking longer than estimated on a program, one of their later programs can be assigned to
someone else to write.
What’s in a good program specification?

A program specification is like any other document in that it should be accurate, brief and clear.
The specifier also needs to know who the specification is written for. Apart from the
programmers(s), programs specifications are also used by system maintainers and quality
auditors. Both of the latter two groups welcome the move towards a consistent approach to
documenting program specifications. It also allows the programming team leader to reschedule
work more easily.
Processing outlined in any program design is one of three categories: processing sequence
decision or iteration. A processing sequence is a number of instructions that must be
programmed in the order detailed in the sequence. A decision indicates that there more than one
possible path through a program and that the path taken will depend on whether the decision
criteria are met. Iteration indicates that a section within the program will be executed zero, one
or mote times until the exit condition is met.
Suggested Program Specification contents

The following is a suggested contents list for a program specification
 Document details This consists of header information which uniquely identifies this
specification: title, author, reviewer, circulation list, release date, system identifier, program
identifier and version number.
 Introduction One of he most frequently discussed aspects of program design is the level of
explanation it should contain. Here again the argument of stifling creativity arises: the specifier
defining the process at too low a level is doing the programmer‘s job. We suggest using three
levels of description within the document. The introduction is the first of these and gives a brief
summary of what the program does in business terms. Data referred to in the program overview
should be at the data file level, not lower. This is because the overview will be read by users,
project managers, team leader, and maintenance programmers who need a short summary of
what the program does.
 Assumptions and restrictions This section lists any constraints on the program such as
‗normal path processing must complete within 0.2 seconds‘. It will also add information which
affects the logic of the program. This could be ‗the program will be cloned to run on each user‘s
terminal‘ or ‗a maximum of 10 messages will be queued to this program‘.
 Attributes This section outlines the program‘s environment and will cover aspects like the
hard ware it will run on, the operating system used and the programming language to be used. If
this information is the same throughout the project, this section might simply refer to a higher-
level design document containing this information.
105
 Data The input to the program and any output it generates is detailed here. It provides a data
–driven view of what the program does. The section also refers to the data dictionary to cover the
format and validation rules for all shared data used in the program.
 Functional description This intermediate level of [process description may not be necessary
for small, simple programs but the default is to include it. It provides a ‗big picture‘ view of the
program‘s input, outputs and processing before going on to explain the detail. Data in this
description is referred to at the record level.
 Detailed processing This section expands on the previous description to give a low-level
detailed view of the processing paths through the program but continues to focus on what has to
be done. Data is referred to at the data field level.
 Errors and exception conditions this deals with anything other than the normal case, such
as events occurring out of sequence. It describes how the program will cope with these, lists any
error messages and identifies the destination of each message.
 Operational considerations Information from this section may be incorporated into the user
manual later. It describes how the operator interacts with this program in the normal case and
how the operator can recover to a safe state or restart the program if anything should go wrong.
 Subroutines Common routines used by the program are identified as are their input
parameters. Input parameters could again simply be referred to if they are denied in a higher-
level document. Calls to the system executive (i.e. manufacturer-supplied functions/procedures)
are also listed here. The reason for having a separate section on subroutines is so that if a
subroutine changes- let‘s say an extra parameter is added –the modifier need only check this
section rather than read through the whole document to find out whether this program must be
amended.
 Messages this section identifies messages sent and received by the program. It lists the
message identifier and its purpose.
Print layouts detailed print layouts or screen layouts are included here. Sometimes the document
only includes a pro forma layout and the details are added by the programmer.
The design specification

The design specification is the primary document of the design phase. It should contain
everything needed by the programmers in order to program the system. The design specification
is both the documentation of the finished system design and the tool used to create the design. In
other words, the documentation is not created after the fact, but instead it is a result of the design
itself; when the design is complete, so is the documentation.
Contents of the design specification

 Table of contents
 Process descriptions
 Data dictionary
 Screen Report and Source Document Design
 Detailed and software specifications
 Security requirements
 Programmer‘s handbook.
 Guide to using the design specification
 Index
106
REVIEW QUESTIONS
1. What is the essential difference between systems analysis and systems design?
2. What are some of the model driven methodologies?
3. What are some of the benefits of prototyping?
4. What are the five high level tasks involved in conducting system design for a
development project to be built in-house?
5. What are the goals of interface design?
6. What is a RFC?
7. Prototyping has many strengths and weaknesses. Discuss.
8. Data security and privacy are increasingly important issues in modern IS. What are some
examples security and privacy issues we need to be aware of in developing and
maintaining a relational database system?
107
CHAPTER SIX: SYSTEMS IMPLEMENTATION
OBJECTIVES
At the end of this chapter you should be able to:
 Explain the purpose of the implementation phase of the SDLC.

 Discuss major tasks, roles, inputs and outputs involved during system implementation.
 Identify the contents of a system‘s documentation.
 Identify system conversion strategies.
Introduction
The handover between analysis, design and development is becoming more and more informal
especially with the accessibility of 4GLs and CASE tools to produce code. Artificial boundaries
between analysis, design and development are becoming increasingly irrelevant.
However, whatever software is used or organizational arrangements adopted, the newly

developed system must now be delivered and implemented. Some practical tasks must be
completed i.e. testing, conversion, documentation and training. Also a consideration should be
done of the different implementation strategies that can be adopted.
Testing
During the programming stage, each programmer or programming team will perform their own
program testing to the specifications laid out by the designers. The completed programs are then
passed to the designer for further testing, who will examine them and approve their interfaces
with the rest of the system.
Testing will be performed by:

 Desk checking –comparing programming flowcharts with original specifics.
 Running with test data.
Test data should be manually compiled and the results produced by the system compared with
the appropriate clerical figures of the current computer system.
Common input errors to test for:

 Oversize and undersize data items.
 Incorrect formats
 Out of range items
 No data at all
 Invalid combinations
 Negative numbers.
Errors may be caused by:

 Incorrect programming
 Misunderstanding specifications
108
 Omissions in original design.
After the required amendments are coded by the programmer, the programs and system must be
retested. This is because fixing of a fault can be a source of another fault in a program.
Some timing aspects of the system can also be clarified during testing e.g.
* Response times e.g. retrieval speed of a record
* Processing time
* Output schedules.
Any related problems may be solved by file restructuring or the use of faster programming
languages. Problems due to hardware not achieving what is claimed in the specification must be
taken up with the supplier.
A modular approach permits progressive testing as follows:

a) Module testing – Validating the internal code of a module.
* Desk check
* Compile
* Test data
b) Suite testing – Seeks to test that a logical sub-system is working correctly and that data is
passed properly between the modules in this subsystem.
c) System testing – Designed to ensure that the sub-systems work properly together. It should
pass through the following phases:
* Single run – Testing the system over a single pass of data.
* Cyclic tests – Testing the system over several cycles of processing to ensure it correctly deals
with end of period routines.
* Clerical tests – Tests all aspects of the interface between the user and the system.
c) User Acceptance Testing – This is the testing of the system by the user department, after the
system has passed the systems test. This test seeks to:
- Find out exactly what are the user demands of the system
- Find out whether any major changes in the system will be necessary
- Find out how the system responds to large volumes of data (as expected to be input by the
user) and at the same time use the tests as an opportunity to train staff in the new system, etc.
Optimization.
What if the system fails its acceptance test because it is too slow? What if, for instance, it has a
five-second-response time on a critical function for which a one second response is required?
Prior to the testing stage, we would have had no reason to be concerned with the efficiency of the
programs unless we were working with a system in which speed was a requirement. After all, for
a standard business application, it is futile to worry about efficiency when we have not yet made
sure that the system will even work. We should wait until the system is complete, find the places
where it is too slow, and then perform optimization, modifying it so that it is faster in those
places where more speed is required.
109
We try to optimize the parts of the system in which the changes will give us the greatest benefits.
Maybe we have determined that optimizing one small subroutine that is used repeatedly within a
slow program will speed up the entire program considerably. Conversely, changing a statement
that is executed only once will have no appreciable effect.
We should be careful in attempts at optimization, since our actions may sometimes have the
opposite effect from what we intend. Recording in assembler language, for instance, will make a
program more efficient only if the programmer is good at writing efficient assembler code.
Optimization Techniques.
There are many ways to optimize a system, including the following:
 Acquire improved hardware in order to improve system performance. This might be a
cost-effective solution in that the hardware might be less expensive than the cost of paying
programmers to optimize the code.
 Use an optimizing compiler
 Record in assembler language.
 Improve input and output speed (Traditionally among the slowest of computer task) by
changing file access methods, increasing buffer and block size to minimize accesses, or
eliminating unnecessary accesses.
 Eliminate subroutine calls by replacing them with macros.
 Curtail the use of fourth-generation languages.
 Improve the algorithm of the module.
 Denormalize files. That is, combine files that are often accessed together, with that
access happening frequently.
If the analysts decide that the software needs optimization, the organization‘s very best
programmers should be given the assignment, because optimization is an extremely delicate task.
It is also the programmers, not the analysts, who should decide what is the best way to attack the
problem, although the analysts should retain the right to veto any methods that have been shown
to be especially difficult to maintain. In the process of optimizing a system, programmers may
reduce its ease of maintainability. If a COBOL routine is recorded in assembly language, for
example, that routine will become harder for the average programmer to maintain. It is for such
reason that we optimize only when we are forced to do so, and even then we try to limit the
changes to only those that are necessary.
File Conversion
The movement of data from one format to another may lead to both programming and
management tasks. If the files are currently held on a computer system, then it should be possible
to move the data from the present implementation to the target hardware and software. However,
a thorough investigation should be done on cost and compatibility. Some routines may need to
be written to modify the data after conversion.
The task of organizing the creation of files must be approached carefully. It may require extra
clerical resources. File conversion creates important technical and operational requirements
which have to be planned for by the designer.
110
Documentation
Documentation is a constant task in system development. The documentation during system
analysis and design prompts for action, not just a record of action.
Implementation documentation
Three types of documentation are associated with implementation.
a) Training Documents
i) Easing the transition from the current system to successor.
ii) Providing detailed tuition in the operations of the proposed system.
Such documentation may use conventional media and methods i.e. handouts, lectures and tests –
in the traditional setting of a training course.
b) User Documentation
- Reference documents rather than learning documents.
- Reflects the expertise and vocabulary of the variety of users involved in the system.
- It should concentrate on the issues that concern users the most i.e. functions and errors.
b) Operations Documentation
- Responsible for the day-to-day running of the system
- It teaches the normal operating procedures and how to respond to errors.
Training
- It covers the retraining of current staff and the recruitment of new personnel. The latter -
involves job specifications, advertising, salary advice and interviewing.
- For training to be effective, it must be clear what it is trying to achieve. The training
objective suggests ways of delivering that training e.g. lectures, tutorials, case studies, practice,
etc.
In summary, the tasks of implementation require careful planning and co-ordination. Lack of this
will undo months of good system and programming work.
Implementation Strategies
There are four possible strategies available.
i) Parallel running
-Old and new system are run simultaneously for an agreed period of time and results from the
two systems are compared. Once the user has complete confidence in the new system, the old
system is abandoned.
Disadvantages
- Large administrative overhead -double work
- Time consuming
Advantages
- Security - fall back
111
ii) Pilot running

Two possibilities exist.
a) Retrospective parallel running -Uses historical data and the output produced is compared
with the known results.
b) Restricted entry data running – Involves a complete logical part of the whole system being
chosen and run as a unit on the new system. If it works, the remaining parts are then transferred.
iii) Direct changeover – Implement the new system completely and withdraw without any sort
of parallel running at all. It demands thorough testing and well planned file creation and training
strategies.
Advantages
- Quick and most complete.
Applicable where:
- There is little similarity between the old and the replacement system(s), cross checking not
possible.
- Cost of parallel running is so prohibitive that it is cheaper to pay for the mistakes of a direct
changeover.
iv) Phased changeover

Takes 2 possible forms
a) Where the organization is divided into various divisions and the system is implemented
in phases.
b) Where the information system is divided into components and the components are
installed in stages.
Applicable where:
- Large projects
- Where distinct parts of the system are geographically dispersed.
REVIEW QUESTIONS
1. What are the tasks involved in the building and construction of databases?
2. Who are typically involved in the installation and testing of new software packages?
3. What are the four common conversion strategies?
4. What are some of the problems facing the following strategies?
a. Abrupt cut-over
b. Parallel conversion
5. What are the responsibilities of the systems analyst when training users?
112
CHAPTER FIVE: SYSTEMS POST IMPLEMENTATION
OBJECTIVES
By the end of this chapter you should be able to:
 Discuss the purpose for a post implementation evaluation.
 List the benefits of post implementation evaluation.
INTRODUCTION
Research has shown that 79% of organizations are currently performing post implementation
evaluations of some or most of their installed CBIS. It has been observed that post
implementation evaluation is performed only on a small fraction of the systems developed.
Research findings reveal that much of evaluation is performed and managed by the members of
the systems development team. These are the people who have the most say in determining
evaluation criteria and evaluation methodology. Since the design ideals and the values of the
developers are instrumental in shaping the system design and the systems development process,
it is unlikely that an evaluation managed and performed by the development team will discover
any basic flows in the process or the product design.
Evaluation of the systems as they are developed and implemented may take place at the
completion of various stages of the SDLC. Formative evaluation produces information that is fed
back during development to help improve the product under development. It serves the needs of
those who are involved in the development process.
Summarative evaluation is done after the development is completed. It provides information

about the effectiveness of the product to those decision makers who are going to be adopting it.
Post implementation evaluation include evaluations performed just before installation, just after
installation, and considerably after installation i.e. after the system has a chance to settle down.
Use/purpose of Post Implementation

(i) To verify that the installed system meets user requirements.
(ii) To provide feedback to the development personnel.
(iii) To justify the adoption, continuation or termination of the installed system.
(iv) To clarify and set priorities for needed modifications.
(v) To transfer the responsibility for the system from the development team to the users.
What is evaluated?
The criteria evaluated include:
i. Accuracy of information
ii. Timeliness and currency of information
iii. User satisfaction
iv. Attitudes towards the system
v. Internal controls
vi. Project schedule compliance
vii. Systems fit and impact upon the organization structure
113
viii. Quality of programs

ix. Net operating costs
x. Savings of system
xi. Systems impact on user and their jobs
xii. Quality and completeness of system documentation.
Benefits of post implementation evaluation

(i) Improvement of systems development practice decisions; to adopt, modify or discard
information systems.
(ii) Evaluation and training of personnel responsible for system development.
(iii) Ensure compliance with user objectives.
(iv) Improvement in the effectiveness and productivity of the design.
(v) Realization of cost savings by modifying system through evaluation, rather than after a
real operation
114
CHAPTER SEVEN: PROJECT MANAGEMENT
OBJECTIVES
By the end of this chapter you should be able to:
 Identify contents of a project team‘s TOR document.

 Discuss project planning in the IS context.
 Identify causes of IS project failures.
 Discuss the steps in project planning.
 Discuss project estimation techniques.
 Identify and apply typical project scheduling tools.
Introduction
A project is a type of work (made up of several tasks) whose end product is a single item on a
large scale. Information systems, like many other projects involve a large number of people, long
periods of time and a large amount of money.
Project management and control is the integrated collection of techniques and procedures that
help in successful and timely completion of a project within the budget and time constraints.
Terms Of Reference
At the start of a project, a project initiation document may be drawn up setting out the terms of
reference for the project. The typical contents of a PID are:
(a) Outline of resources that will be used – staff, finance and technical resources.
(b) Business objectives – The business objectives should be clearly identified and must be the
first point of reference when progress is being reviewed to ensure that the original aim is not lost.
(c) Project objectives.
(d) The scope of the project (What is it intends to cover)
(e) Constraints i.e. maximum amounts to be spent, interim and final deadlines, etc.
(f) An analysis of risks inherent in the project and how they are to be avoided.
(g) A project plan (targets, activities, etc) and details of how to organize and manage the project.
(h) Purchasing and procurement policy e.g. specifying acceptable suppliers and delivery details.
Why information systems projects require more planning

(a) They require heavy financial investment and therefore the management is concerned about
the project completion within budget and time constraints.
(b) They compete with other corporate projects for resources.
(c) Management can use them for competitive advantage. A project failure or delay may result in
a permanent or temporary loss of that competitive advantage.
115
(d) They determine the risk nature of the firm and their failure threatens the very survival of the
origin.
Project Planning
Project planning is an attempt to develop accurate estimates for the time, costs, and expected
benefits and to adjust the estimates if they prove inaccurate. The project plan is the primary
documentation tool and all activities are executed according to this plan; Planning involves:
- Developing overall project targets of costs and timescale (e.g. analysis, programming, testing
design, testing).
- Identifying various activities in the project and putting them in the right and logical sequence
and their duration to manage the project.
- Developing the firm‘s procedures and structures necessary to manage the project.
- Estimating personnel resource requirement and training needed for certain members of the
project team.
- Drawing the network of activities.
- Have reporting structures and procedures.
Each project should be planned in great detail before any actual work on the project begins, and
the plan must continue to evolve as the system evolves.
The project plan includes separate, smaller plans for each of the following tasks or phases of the
project: analysis, design, coding, testing, documentation, training and conversion. Each of these
plans in turn consists of various components such as time and schedule estimates, cost estimates
benefit estimates, and cost-benefit analysis.
Project control
Project control as opposed to project planning is the ongoing process of monitoring the actual
plan to see whether it is meeting the objectives detailed in the project plan. We must continually
check if we are on schedule and under budget, since the sooner we detect problems the more
effectively we can deal with them. It is the taking of corrective actions when activities fall
behind schedule or more resources are needed to complete the project. It involves
- Rescheduling of activities or reallocation of resources
- Quality control over work done through the use of systems development standards
- Establishment of feedback procedures to aid control monitoring of the project e.g. timeliness,
keeping to budgets.
- Ensure proper communication between members involved in development of various project
segments.
- Analysing the effects of delay.
- Revising the network and setting up new schedules.
- Reporting to the steering committee or senior management on a regular basis as part of the
control procedures.
116
Why system development projects fail

The following factors, it not well addressed could cause expensive disaster and eventual failure
of the project.
(i) Inadequate user involvement –The users should be allowed to educate analysts on
policies, requirements and applications.
(ii) Failure of two or more segments of the new system to fit together properly i.e. no system
integration. This is because different work groups of technical specialists fail to communicate
well during development.
(iii) Non-existence of control i.e. no performance reviews
(iv) Poor or non existent planning
(v) Project manager accepts an unrealistic deadline for having the system up and running.
For example, the user‘s idea of when the system would be needed is taken before sufficient
consideration is taken to the realism of the deadline.
(vi) Poor time tabling and resourcing.
(vii) Users changing their requirements - Users change their requirements, resulting in costly
changes to the systems. This is due to the fact that users needs were not known early enough.
(viii) Where the project manager has a number of conflicting requirements;

- The systems manager (The project manager‘s boss) wants the project delivered on time to
specification and within budget.
- The project manager has to plan and supervise the work of analysts and programmers and
these are rather different roles
(ix) Users and management want a system that does everything they require- but they are not
certain of what they want. Furthermore users and management may not be able or willing to take
time off from their normal duties to help out. If the project is late, over budget and does not do
all they expect it to do users will be the most vocal critics.
Techniques For Estimating

- Use estimating formulas based on metrics (number of functional primitives, number of data
stores , and so on).
- Apply the standard business technique of weighted average based on optimistic, most likely
and pessimistic estimates.
- Refine the estimates and the project plan continually as the project progresses.
- Document all assumptions.
- Present estimates to management in a standard format, such as a decision table.
- Base all estimates on realistic expectations
- Assemble an estimating group.
-
117
Estimation Formulas
A specific set of formula will help us to develop our estimates, and those formulas need to be
broad enough that, with only minor variations, they will apply to all systems. DeMarco (1982)
suggests that there are system elements, called metrics (or function points by other experts) that
can be counted. When these metrics are given weighing factors, they can be used to predict the
money and time required to build a system. Although we will not go into complexities of
formulas here, we will briefly discuss the some of the metrics that are involved.
- The number of functional primitives is generally the primary metric used in developing
estimates, since it seems to be directly related to the size of the system. Different types of
functional primitives may be rated differently; for example, perhaps we should give a calculation
module a higher rating than a module that writes a report line.
- Secondary metrics used in the formulas include numbers of the following: decisions, data
stores, data elements, data repetitions, data choices, optional data items, and pointers between
data entities.
- We must also look at the system type, rating a real-time system, for example, much higher
overall than one that does only on-line inquiry. For a data strong system, such as one whose
primary purpose is inquiry against an existing database, we would probably give the metrics
relating to data heavier emphasis, whereas a function-strong system revolving around updates
would call for heavier weighting on the functional primitives.
- Factors beyond system characteristics also influence the estimates. Personnel characteristics
that impact the estimates include skills, experience, and turnover rate. The number of expected
system users, their computer experience, and their expectations of the system are also expected
system users, their computer experience, and their expectations of the system are also pertinent.
So too is the development environment.
To whatever estimate we arrive at by using the formulas we should always add a ―fudge factor‖.
There are so many elements beyond our control that is unrealistic to put absolute faith in a
precise calculation. An expectedly high inflation rate, for instance, can destroy a budget for a
long-term project, and a vendor who does not deliver equipment on time can put a project weeks
behind schedule. The ―fudge factor‖ we use should be fairly large since we might have multiple
catastrophes such as these. One way to incorporate ―a fudge factor‖ in our estimates is to apply
the standard business management technique that requires formulating an optimistic, a
pessimistic, and most likely estimate. We then use three figures to calculate an average weighted
toward the most likely estimate:
Weighted = ( optimistic estimate) = (most likely estimate) = (pessimistic estimate)

average
6
This takes into account unforeseen disasters as well as miracles, without skewing the estimate
too far either way.
118
Refining the Estimates

Since we do not know a lot about a system at the beginning of the project, early estimates are not
as accurate as later, more refined, ones will be; we continue to refine estimates as we clarify the
analysis and design of the system. Note also that these estimating techniques depends on the
consistent use of a structured methodology and that a certain amount of analysis must be done
before estimating can begin. This means that we cannot expect to achieve a precise estimate of
time and cost during the feasibility study; but as a project progress, we can develop increasingly
more accurate estimates. During each phase of development, we are able to improve our all
estimates and project plan and to produce a detailed estimate for the next phase.
Documenting the Estimates

We should always document all assumptions. If a project‘s budget is based on a 5 percent
inflation rate and a 12 percent prime rate for borrowing money, we should say so.
High inflation rates, for example, can destroy the value of long-term estimates. (The rapid rise in
costs in the early 1970s caught many data processors off guard. They had assumed that the
inflation would remain at the same low rate that had prevailed for a number of years. As it
turned out, projects that had begun in a year of low inflation often had a life span that carried
them through one or two years of high inflation. As a result, the anticipated high cost of the last
years caused the projects to go over budget. Since at the time of the original estimates only a
crystal ball could have predicted with total accuracy the future economic climate, these
estimating problems were not really the fault of estimators. Nevertheless, had they documented
in the original estimate such assumptions as inflation rate, they could at least maintained their
credibility).
In addition, documentation of assumptions allows estimators to see exactly what went wrong so
that they can learn from their mistakes. Estimators should keep very detailed, measurable data on
how they developed their estimates and then how close they came, to enable them to refine their
techniques as the become more experienced.
Presenting the Estimates

A standard format for presenting estimates to management is a necessity. One way to offer a
quick overview is to show the various options in a decision table or matrix format. Each option is
a rule, or column. The factors affecting the estimates such as hardware, software, and benefits
delivered are used as the variables.
Prediction Versus Setting Goals

All estimates should be based on realistic expectations, not on other factors such a management‘s
goals or external deadlines. For instance, if estimators predict that a project will take three years
when management says it must be done in one year, and the project does take three years, then
the estimators have been successful even if the project is not. If that same project is completed in
three months, the estimators have failed. In other words the estimators should not try to set goals;
they should merely predict. They do not state what should happen, but rather what will happen.
If management chooses to ignore the predictions of experienced estimators in flavor of
establishing their own goals, they are setting the project up for disaster.
119
Establishing an Estimating Group

In most organizations, the analyst and designers working on the system also do the estimating.
In contrast, some larger companies establish a separate estimating group, or metrics group. Such
a group is composed of former system analysts who now concentrates solely on estimation.
Since estimation is their only duty, they do it in many times in the year, as a result, they become
quite good at it. An additional reason for using a special estimating group rather than members of
the development team is that the latter may have their own egos wrapped up in the estimates.
Since they are building the system (and they know they are such terrific system builders), they
will tend to underestimate.
Types of Estimates
There are three elements in which estimates must be developed: time, costs, and benefits.
Because they are interdependent, these three estimates must be developed together. For example,
creating an accurate estimate of the costs depends on knowing the scope of the expected benefits,
since smaller systems tends to be cheaper, Furthermore the time schedule cannot be estimated
without knowing the extent of available resources. For instance state-of-the-art development
tools, while they will undoubtedly increase the cost, may compress the schedule. Therefore, even
though we discuss these three estimates separately we must keep in mind the close relationship
among them.
Time Estimation
- Use verifiable milestones to partition the schedule
- Construct Gantt chart and PERT charts to graphically illustrate the schedule.
- Use a PERT chart rather than a Gantt chart whenever showing the dependencies between
tasks is important.
Time, in a systems analysis terms, is how long it will take, broken down into increments, to build
and install a new system. A time estimate such as ―six months to build and install‖ is of little
value since it gives us nothing, with which to check our progress along the way—we would not
know whether we were behind schedule until 5 months and 29 days are over. Therefore when
making time estimates, we break the project down into small chunks and then predict when each
chunk should be done. By breaking each into piece we are better able to determine exactly how
involved the project is and can therefore do a more accurate job of estimating.
Milestones
We mark the end of each of the project‘s chunks with a milestone. This is merely a significant
point in the development of the project, but it must be a measurable or verifiable point in time.
For instance, ―problem specification completed‖ is verifiable—it is either completed or not.
―Problem specification halfway completed‖ is not verifiable—who can tell what is ―halfway‖?
No one can determine what ―half‖ is exactly until there is a whole with which to compare it.
Unverifiable milestones are especially abused during the programming phase, since some
programmers like to measure their progress by ―weighing the code,‖ or counting the number of
pages of completed source code. This practice has several drawbacks. The number of lines of
code produced is not necessarily a meaningful indication of progress, since that code could be
from the less complex areas of the system or could be written but not yet tested. Furthermore,
120
since during the programming phase we do not yet know the number of lines in the completed
system, we cannot accurately gauge how far along we are.
A better way of measuring programming progress, based on the incremental method of testing, is
to count the number of finished, defect-free modules. Verifiable milestones might be ―vice
president modules completed,‖ followed by ―efferent modules completed‖. These milestones
could be broken down even further, with completion dates for small groups of modules within
the larger groups.
Scheduling Tools
Two graphical tools are useful in time charting; The Gantt chart and the PERT chart.
The Gantt chart

A Gantt chart, a type of bar chart, usually displays time across the horizontal axis and activities
on the vertical axis.
A Gantt chart shows exactly how long a given task is scheduled to take, as well as how long it
actually takes (See the figure below).
WEEKS
1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2
0 1 2 3 4 5 6 7 8 9 0
Feasibility
Analysis
Design
Coding
Testing
121
Key
= scheduled time
= actual time
Unfortunately, it does not show the precise dependencies between tasks. So although a Gantt
chart can be very useful for a broad view of a project‘s schedule, it does not tell us everything we
might need to know. For example, we can see from the figure above that the feasibility study
must be completed before the analysis phase can begin. We can also see that the coding and
testing phases overlap considerably, but we are not shown exactly which stages of the coding
must be finished before the testing begins. So, although a Gantt chart can be very useful for a
broad view of a project‘s schedule, it does no tell use everything we might need to know.
The PERT chart and CPA

PERT stands for Project Evaluation and Review Technique. A project is viewed as a network of
activities, of which some must be completed before others can begin. A PERT tool does illustrate
dependencies between tasks.
Note:
(d) Each activity in the network is represented by an arrowed vector.
The activity arrows are not necessarily drawn to scale
(e) Each activity starts and ends at an event (milestone) symbolized by a circle.
An event marks the end of an activity or activities and the beginning of others.
Several activities can have a common head event or tail event.
A D
B E
C F
Common head event Common tail event

(f) The network direction is left to right.
122
(g) Dummy activities, represented by broken vectors, take no resources and

are drawn to complete the network logic.
(h) All nodes must be tied into the network, i.e. no nodes should dangle in the network.
e.g.
Dangling node
(i) There should be no loops in the network
- Label the activities (usually alphabetically). Number your event nodes (usually in numeric
sequence).
(j) A network has only one entry (start event) and one exit (terminal event)
123
Illustration:
Activity Preceding activity Duration (Weeks)

A - 5
B - 4
C A 2
D B 3
E B 5
F B 5
G C, D 4
H F 3
124
5 6
A C
0 0 7 8 12 12
5 2
G
1 4 4 6
B D
4 3 E H 3
5
3 F 5
5
4 4 9 9
(The critical path in shown by the heavy vectors)
Key
EST LCT
EST= (Earliest start time) at an event is the earliest time activities ahead of that event can start,
keeping in mind that ALL activities before the event must be complete. It is calculated in the
forward pass. We add up activity durations in each path leading to that event, then take the
largest. The first event has EST value 0. The EST in the last event gives us the project duration.
In the above figure the project duration is therefore 12 weeks.
LCT = (Latest start time) at an event is the latest that preceding activities can complete without
delaying any of the succeeding activities. It is calculated in the backward pass, starting from the
last event, whose LCT is set to the project duration (in the above case, 12). We subtract activity
durations in each path leading backwards to that event, then take the smallest.
The critical path is the sequence of activities that have the same EST and LCT values.
Critical Path analysis

This involves the use of network analysis. It is useful in planning and controlling large projects
such as construction projects, computer information system, research projects, etc. It pinpoints
the critical activities (those that if delayed beyond allotted times would delay the completion of
the entire project)
Drawing the network:

(i) Estimate the duration of each activity
(ii) Put the activities in logical sequence (Successor –predecessor)
(iii) Represent this in a network
125
(iv) Compute the earliest start time (EST) and latest completion test (LCT) by use of forward
and backward pass method
(v) Identify the critical path and critical activities
Choosing a scheduling tool

We choose a time –charting tool on a contingency basis; that is, we use the one that best suits the
situation. The PERT chart, however, has several advantages over the Gantt chart.
 Activity times can be used as an aid in assigning tasks to the project team.
 The chart can be modified in order to reflect proposed scheduled changes.
 It can be used in simulations in which the purpose is to try to shorten the critical path and
therefore the time it takes to complete the project.
 It allows us to focus on the danger areas in the schedule and estimate the total time it will
take to complete the system.
On the other hand, we must not get so wrapped up in maintaining the PERT chart, modifying it
for every little schedule change throughout the life of the project, that the amount of actual
project work we do suffers. We must keep the charting tools in perspective, remembering that
they are only tools, not goals.
Although we can maintain a Gantt or PERT charts manually, it is much faster and easier to use
computerized graphics or, even better, a software package designed for project planning and
control, such as Microsoft Project. Such a package allows us to create multiple charts related to
one another, so that a change in one is automatically reflected in others.
Cost Estimation
Financial Cost estimation are derived by evaluating the resources that will be needed to develop
and operate a system. These resources include the necessary personnel, computer hardware, and
supplies, each of which can be translated to a dollar value.
Development costs, or start-up costs, are the resources that are expanded when creating the
system. Development costs encompass expenditure for the following:
 Salaries (plus attendant taxes and benefits ) for analysts, designers, programmers estimators,
testers and all staff involved in the development effort.
 Computer hardware - the initial purchase price, as well as transportation and installation
costs.
 Software development tools - automated data dictionaries, fourth generation languages, test
data generators, and database conversion programs.
 Production software - operating systems, utility programs and canned software packages.
 Suppliers - papers, disk packs, tapes, etc.
 Site preparation - installing special electrical systems, heating and air conditioning, and
physical security measures.
 User training and documentation—breaks down into previously listed categories such as
salaries and supplies yet is important enough to warrant separate mention.
 Parallel operation—also breaks down into other categories yet warrants separate listings.
126
Operating costs are the costs that occur on daily basis throughout the life of a system. They
include expenditures for the following:
 Salaries (plus taxes and benefits) for data processing staff, as well as for any additional staff
hired elsewhere in the organization as a direct result of the new system.
 Hardware and software—leasing fees or, incase of direct purchase, depreciation costs (since
each day an item looses value as an asset).
 Repairs and maintenance—if not included in the part of leasing or purchase agreement for
hardware and software.
 Supplies—paper, preprinted forms, additional disk pack and tapes, office supplies.
 Utilities, rent of office space, and insurance,
Some of these operating expenses are variable costs; that is they will rise as the volume of work
increases. For example, higher volume of work usually results in an increase in the consumption
of paper. Such costs as hardware leasing fees or building rent fees are fixed costs, which are not
affected by the work volume.
In order to evaluate the costs of the new system more effectively, it is helpful to have the cost of
the old system in comparison. Although one would expect to be able to get those costs easily
enough for the general ledger, it does not always prove to be true. Some organizations do not
segregate information processing costs from other categories. In addition some of the costs of an
existing system are very difficult to quantify. Examples of such costs include the cost of
opportunities lost because management did not get timely reporting on the financial condition of
the business or the cost of time (and thus wages) wasted because an inefficient method of data
was used. Such costs are called intangible costs, while costs that are relatively easy to quantify
are termed as tangible costs.
Benefits Estimation
Benefits are the functions a system delivers. To identify potential benefits we must ask exactly
what the system will do that is not already done. Most benefits can be measured as either an
increase in revenues or a decrease in expenses.
As we try to identify the benefits, we must look at both the tangible and the intangible ones.
Tangible benefits are those that can be assigned a dollar value and that are tied directly to the
installation of the new system. Examples of the tangible benefits include the following:
 Most efficient use of data processing personnel, thereby reducing payroll costs by
minimizing overtime, cutting down on staff, or avoiding hiring new staff in the near future.
 Reduce supply costs from such improvements as replacing paper reports with screen
displays, replacing purchased cards with online data entry, or using on-line data entry instead of
paper source documents.
 Provision of services never available such as new reports, analyses of trends, or end user
query of a database.
 Improved ability to take advantage of offered discounts on account payable invoices because
of more efficient reporting method.
 Ability to operate efficiently with a smaller inventory on and, resulting in lower insurance
rates, better utilization of storage space, and the opportunity of investing the liberated funds
elsewhere.
127
In order to assign a dollar value to a tangible benefit, we usually need to do some type of
calculations. For instance, suppose we estimate that a new system could eliminate 95 percent of
the accounts payable overtime pay for a company. Last year the company paid $5,000 in
overtime; following the trend of the past, we would expect that the figure to increase by 10
percent this year. Therefore, if the system were to go into operation on the first day of this year,
the calculation might look as follows:
This year‘s expected overtime without new system:

$5000 x 1.1 = $5500.
This year‘s expected overtime with new system:

$5500 – ($5500 x 9.5) =$275.
Expected savings as a result of new system:

$5500 - $275 = $5225.
Thus we predict the new system would save $5,225 in overtime, in the first year alone.
Most tangible benefits can be quantified be looking at previous cost and comparing hem with
projected costs. Unfortunately, intangible benefits are not easily quantifiable. Intangible
benefits are those for which it is difficult or impossible to develop an exact dollar value, since
their positive impact on the organization is not directly measurable. Intangible benefits can
include the following:
 Improved employee morale, with the attendant reduction in sick day and job related
accidents and the attendant increase in productivity.
 Improved collection of accounts receivable because of better reporting methodology.
 Fewer inventory shortages—which result in production rises and lost customer orders—
because of automatic reordering of parts.
 Closer control and monitoring of investments, resulting in better investment decisions on the
part of management.
 Higher sales as direct result of improved customer service.
 Reduced risks, such as improved security on access to financial data.
In all cases benefits alone have little meaning? As stated earlier in this chapter, benefits must be
tied to associated costs and time estimates if we are to evaluate them accurately. To do so we
utilize several techniques, collectively termed cost-benefit analysis.
COST-BENEFIT ANALYSIS
After we develop the estimates and put them into a standard format such as a matrix, managers
must decide which benefits are worth associated time and costs.
Cost –benefit analysis is used to evaluate alternatives such as these. Cost-benefit analysis helps
us to find the optimum system, the one that delivers the most benefits for the money spent.
128
Cost benefit analysis is really the job of management. The job of the analyst is to develop and
present the pertinent figures. Of course, the analysts must have some understanding of the
process in order to be able to deliver all the necessary facts and figures. He must also understand
that developing a new system is in effect to an investment; the business invests money, time,
knowledge, and human resources in the project, in the hope of reaping some monetary benefits in
the future. The three most popular methods of evaluating the relative merits of proposed
projects are payback analysis; return on investment analysis, and net present value analysis.
Payback Analysis
In payback analysis, we are concerned with how soon the lifetime benefits of the system
surpass/better the lifetime cost. Suppose we look at a five-year projection in which we estimate
the costs incurred and the benefits received for each year of a proposed accounts payable system
(table below). Year 0 refers to the development year, and year 1 begins on the day of cutover. As
we can see, total lifetime benefits exceed total lifetime costs somewhere between the third and
the fourth year of operation. Examining the figures more closely, we can say that the payback
period for this option is approximately 3 years and 7 months. This may or may not be considered
a reasonable payback period; each organization will develop its own guidelines.
Although payback analysis can be first step in evaluating the alternative, it has two serious
drawbacks; first it does not take into account the time value of money. For instance, a dollar
saved today is more worth to us than one saved ten years from now, since today‘s dollar could be
drawing interest in a bank for us for the ten years. second, payback analysis does not consider
any benefits of the system that are accrued after the payback period. For instance an alternative
solution might produce the greatest benefits at the lowest cost a year after the payback period has
ended, a fact that is ignored by payback analysis.
Decision Table of Estimated Costs and Benefits for Accounts Payable.

Year Year Year Year Year Year
0 1 2 3 4 5
Development $20,000 - - - - -
costs
Operating - $5,000 $5,200 $6,000 $6,000 $8,500
costs
Total $20,000 $25,000 $30,200 $36,200 $42,200 $50,700
lifetime costs
Benefits - $8,000 $10,000 $12,000 $15,000 $20,000
Total - $8,000 $18,000 $30,000 $45,000 $65,000
lifetime
benefits
Return on Investment Analysis

In return on investment analysis, we calculate as a percentage of the lifetime profitability of a
proposed solution. The formula is as follows.
Return on investment = lifetime benefits – lifetime costs x 100
Lifetime costs
129
In other words, it is the net benefit divided by how much it costs to reap those benefits. This
gives the rate of return (similar to interests on bank account) that the investment gives over its
lifetime.
Suppose we invested $1.00 in a bank for two years at 5 % interest rate.

At the end of two years, the account will be worth $1.11:
Year 1
$1.00 + (1.00 x .05) = $1.05.
Year 2
$1.05 + (1.05 x .05) = $1.11.
Return on investment for this example would be 11%:
$1.11 – 1.00 x 100 = 11%

$1.00
You notice that although 11% looks like a good interest rate, it is a real product of the two years
at a 5 % rate. Therefore, high return on investments rate should be evaluated in terms of the
number of years it took to get that rate e.g. in the table above, the rate of return on investment is:
Return on investment = $65,000 - $50,700 x 100 = 28.21%

$50,700
Again, an organization will generally set a minimum acceptable rate of return for all investments.
If several alternatives satisfy the minimum, then the one with the highest rate of return is
generally considered to be the best investment.
Return on investment analysis has the same drawback as payback analysis in that it does not
consider the time value of money. In order to evaluate this time factor, we must use net present
value analysis.
Net Present Value Analysis

Net present value analysis takes into account the time value of money by expressing all costs
and benefits as their equivalents in today‘s dollars. For example, suppose we expect to reap
$1.00 in benefits one year from now. Also suppose that we are expecting a 10% annual return on
any investments. The $1.00 to be received one year from now is equivalent to approximately
$0.91 today, because $0.91 invested today at 10% will yield $1.00 in one year.:
$0.91 + ($0.91 x 0.10). Therefore, $0.91 today is the financial equivalent of $1.00 a year from
now, provided we are sure we can get a 10 % return on our money.
If we perform net present value analysis for a proposed system we must bring all projected costs
and benefits back to today‘s dollars. By expressing all future costs and benefits in today‘s
dollars, we can easily compare projects that have different life spans.
130
The formula for calculating the present value for some future amount, whether that amount is a
cost or a benefit, is as follows:
Present value = amount x 1

n
(1 + rate)
The amount is the future value of cost or benefits in question, the rate is equal to expected annual
rate of return on the investment, and n is the number of years that will pass before the cost or
benefit will occur.
We can double-check our earlier calculation of the present value of $1.00 by plugging the figures
into formula:
Present value = $1.00 x 1

(1 + 0.10)1
= $1.00 x 1
1.10
= $1.00 x 0.909
= $0.91.
Continuing this example, suppose the $1.00 will occur 3 years in the future instead of one. The
formula will then look like this:
Present value = $1.00 x 1

3
(1 + 0.10)
= $0.75
To summarize, $1.00 received in three years from now is financially equivalent to $0.75 received
today if we assume a 10% rate of return.
The following table shows the present value calculations for each of the costs and benefits, 14
percent having been assumed as the expected or desired rate of return. At the bottom, the total
costs are subtracted from the total benefits to obtain the net present value. If the net present value
is positive, the investment will deliver the desired rate of return and is therefore considered to be
a good investment. If the net present value is negative, the investment is a poor one. Te solution
with the highest positive net present value is considered to be the best investment.
Development costs, year 0 $20,000
Operating costs, year 1 $5,000 * 1 $4,386

(1.14)1

(1.14) 2
131

(1.14) 3

(1.14) 4

(1.14) 5
Total costs at present value $40, 403
Benefits , year 0 0
Benefits , year 1 $8,000 * 1 $7,016

(1.14)1
Benefits , year 2 $10,200 * 1 $7,690

(1.14) 2
Benefits , year 3 $12,000 * 1 $8,100

(1.14) 3
Benefits , year 4 $15,000 * 1 $8,880

(1.14) 4
Benefits , year 5 $20,500 * 1 $10,380

(1.14) 5
Total benefits at present value $42, 066
Net present value = benefits – costs = $1,663.
Alternatively, we might insert the figures into a spreadsheet program, since most such programs
contain functions to calculate present value automatically. Spreadsheet programs have the
additional benefit of allowing us to run ‗what if ‗simulations easily. For instance, what if we
lowered the initial development costs by $2,000? Or what if we instead raised the third year
benefits by $3,000. Which would more significantly affect the profitability of the project?
Project Control
- Conduct project reviews to detect problems as soon as possible.
- When slippage occurs, choose one of these options
 Increase resources
 Extend the deadline
 Eliminate or postpone completion of the scheduled functions of the system.
- When asking for more time or resources, take ―no small slips‖.
132
- By means of a final project review, analyze both the quality of the completed system and the
proficiency of the project management.
Analysts must continue to monitor a project throughout its life span, since even the best of
estimates can be off, and as stated repeatedly in earlier chapters, the sooner a problem is detected
the easier and cheaper it us to correct.
We use the same tools for project control as we used for planning: time charting, cost and benefit
estimation, and cost benefit analysis. Additionally, structured walkthroughs monitor the quality
and the content of the finished project. As analysts, we must also hold regular project reviews on
a weekly, biweekly, or at least monthly schedule. In a project review the project itself, not the
finished product, is examined. We look at the estimates and compare them with what is actually
happening. Are we as far along as we expected to be? Are we staying under budget? Will we be
able to deliver the expected product? Is the project progressing smoothly? As always, the
comparison must be quantifiable, since ―guesstimates‖ tell us little of value.
Even though structured walkthroughs and project reviews measure different aspects of a system,
they are related. If the walkthroughs prove that a system has serious defects, whether the project
is on time or under budget is irrelevant. If the quality is consistently poor, the walkthroughs will
indicate to us that extra work will be required, and hence our estimates for resources, time and
scope of the finished product are unreliable.
When we discover a problem at any point, we must attempt to correct it immediately. If we are
one week behind schedule at the end of the month, we should try to make up that one week
during the following month. If we wait until we are twelve weeks behind ,at the end of the
twelve months, it will be almost impossible to get back on schedule. The same holds true for the
budget; the sooner we make adjustments for over expenditures, the better chance we have for
bringing the entire project in under budget.
Slippage
The process of falling behind schedule or going over budget is called slippage.
When we experience it, we have three options;
- Add more resources at the problem
- Extend the schedule or
- Trim the tasks.
 Add more resources

Adding more resources, which is the same as increasing costs, may help in some instances. If for
instance, we know that the main factor slowing us down is shortage of microcomputers,
purchasing more will probably increase productivity. Or, if we have 100 independent programs
that must be written, increasing the programming staff from 10 to 20 might allow us to finish
faster. Doubling the staff will not however allow us to finish in half the time. More time means
that more time training, meetings, management and communication in general, which means that
adding 10 people will not result in 80 more hours of work each day. There may even be a point
beyond which adding more staff will increase the time necessary to complete the project.
133
Furthermore, when the task is not partitionable – that is, when it cannot be divided into discrete
chunks for different people to work on – it is futile to add more personnel. If it takes one person
eight hours to write a single non- partitionable subroutine, we cannot give it to eight people and
expect it to be done in 1 hour. It will still take eight hours since only one person can work on it at
a time.
 Allow more time

If the problem is such that expending more resources will not solve it, or perhaps additional
resources are not available, we may want to extend the deadline.
 Trim the task

This means reducing the scope of the finished product and thus reduces the benefits it delivers.
In this case, we will produce the system on time and within budget, but we will not deliver all of
the functions. We may postpone or eliminate those that are not critical to everyday operations.
For example, on a June 1 deadline, we might deliver everything except the income tax
processing unit, which could be delayed for several months since it will not needed until the end
of the year.
 Take no small slips

When we ask for more resources or more time or a smaller task, we should be generous with
ourselves. After all, the first estimates were apparently inadequate; we cannot count on the new
ones to be much more accurate. Besides, we want to be able to turn out a quality product without
having to deal with slippage once again.
REVIEW QUESTIONS
1. What is a project?
2. What are some of the common reasons for IS project failure?
3. What is the difference between scope creep and feature creep?
4. What are the basic project management functions?
5. What are the major activities in the project management cycle?
6. What are the factors to consider in estimating task durations?
7. What should project managers to manage changes that occur/or are requested during a
project?
8. Why is critical path analysis important?
134
CHAPTER EIGHT: SOME MODERN TRENDS IN COMPUTING AND

SYSTEMS DEVELOPMENT
OBJECTIVES
By the end of this chapter, the learner should be able to:
 Identify current trends and applications of IS.
 Identify capabilities of emerging IS.
 Distinguish between centralized and decentralized systems.
End User Computing (End-User Development)

May be defined as the direct hands-on approach to computers by users - Not direct use through
the systems professionals. It can also be defined as any information processing activity
performed by end users who use their own micro computers to access data and programs either
programmed by them (end users) or others.
The main purpose of end user computing is to increase individual productivity. End users include
managers, office staff, sales people, production workers, secretaries etc.
End user computing is a large and growing field and some of the applications are listed below:
(a) Decision support systems
(b) Expert systems
(c) Executive information systems
(d) Text handling and publishing
Trends favoring end-user development/computing

The following summary lists existing factors that lead to high levels of end user development: -
 Users have accumulated experience from working with applications that were developed for
them earlier.
 Applications being developed in organizations are becoming complex. System analysts need
to continually involve users to understand the business functions being studied.
 Better systems development tools are emerging. Some allow users to design and develop
applications without involving much training.
 Increasingly powerful desktop hardware – this makes it possible to run powerful software
that allows users even with limited technical skills to develop systems.
 Declining hardware costs: - Users can now acquire PC‘s that are much more powerful than
old mainframe computers at a lower cost. The declining cost makes it possible for everybody to
have a computer increasing the potential for powerful software tools to support end user
developers.
 Increasing computer literate population: - computers are becoming common at work, at home
etc. with this experience; people are able to their own applications.
 Backlog of information systems (IS) projects - In most organizations, the internal IS unit has
a large backlog of new systems development projects. In absence of priority users may have to
wait for several years for work on their projects to start. This requires alternative sources
including end user development.
135
What end users can do;

(i) Low volume word processing
(ii) Financial analysis using spreadsheets (they have to use simple models).
(iii) Design of simple reports – will use fourth generation languages to write simple queries to
give information that fits certain criteria.
(iv) Low volume data entry.
(v) Write small application programs.
What end users cannot do:

(i) High volume data entry (should be centralized).
(ii) Changing data values in existing database systems.
(iii) Development of applications taking long development periods.
(iv) Development of applications using the first to third generation languages meant for use by
professionals.
Challenges in end user management

(ii) End users strategy: - who will be the users – or white and blue collar workers should have a
work station.
(iii) End user support: - end users are non-computer professionals and they need support from
information centers. The support comes in form of hardware or software education or training.
(iv) Security and privacy: - end-users should be taught how to protect privacy and how to
secure data and information systems.
(v) Cost justification: - every user has to justify the demand for IT resources.
(vi) Data definition and strategy: - although systems developed at end-user level are in principal
based mainly in ―local‖ data (data originating within a department concerned), this data may be
of interest to other departments and it is rare that a department uses no data at all from external
sources it is the responsibility of the system analyst to ensure that there is a maximum degree of
consistency and coherence between departmental systems in terms of data definition, duplication,
database design etc.
(i) Standards: - standards save time in development and maintenances as well as assuring
maximum levels of quality and consistency. It is therefore important that standards are used in
end- user computing. The problem is that many end users are not aware of standards relevant to
their own situations and so the analyst has a vital role to play.
(ii) Conformity with systems development strategy: - although end users may have
considerable freedom in the specifics of systems developed, the main systems principles applied
must for the sake of the organization as a whole fall within the overall systems development
strategy. If not, major long-term problems gradually set in such as incompatibility between data,
hardware and software. The systems development department should therefore define and
136
disseminate an overall systems development strategy, including hardware and software choice
and acquisition to end users and monitor its application.
(iii) Responsibility for maintenance: - most systems developed by end users need to be
modified in the course of time as needs evolve. It is therefore essential that the systems analyst
make end users aware of the demands of possible future maintenance at the time when the
systems are created.
(iv) Ergonomic and human factors: - a frequently overlooked aspect of systems design and
implementation is that of matching the systems work place. Familiarity with the ergonomic
principles concerning such factors as physical layout is essential knowledge for the systems
analyst, but so are the aspects related to work organization, avoidance of stress and software
ergonomics which are very important in ensuring the best conditions for working with the new
system.
(v) The information center: - in order to support end user computing many organizations have
implemented the concept of information center with the key functions of:
 Help desk availability

 Consultancy role on a wide range of end user questions.
 Support in analyzing user needs and implementing systems
 Training
 Market monitoring of available products and service, which could be useful to end-users.
Advantages of end user computing

(i) It speeds up data processing as local end users needs are done or performed by end users.
(ii) It increases individual productivity
(iii) It diffuses IT knowledge across the entire organization
(iv) Improved user satisfaction from user involvement
(v) It reduces information systems project backlogs. End user development relieves the
central IS unit for the development of other projects.
Problems with end user computing

(i) End users who develop applications may need more expensive software and hardware
(some additional spending will be necessary
(ii) End users can also incur hidden costs – the employees may create support costs
elsewhere.
(iii) Different units may duplicate efforts by producing different separate systems that
essentially do the same thing
(iv) Development of localized systems and database may conflict with the organizational
goals for the increased data sharing among operating units (sub–optimization).
137
(v) Managers outside the IS or area generally have limited skills which make it difficult for
them to evaluate end user development activities.
(vi) In some cases, lack of competence may result in failed projects: -systems that do not
work at all. In other cases, systems that seem to function adequately may actually produce
inaccurate results/output that that leads to bad decisions.
(vii) End users often fail to produce adequate documentation for their systems, which can
create maintenance problems later especially if the developers have left the organization.
(viii) End users may not understand or be able to implement organizational standards for data
security as a result they may fail to safeguard confidential data of properly backup data and
programs.
Information Centers
These are support departments, which provide assistance to people within the organization who
use computers. They also provide help to users who wish to develop their own appllications.
Typical services provided by an information center

(i) To identify areas where IT could be usefully employed.
(ii) To provide technical advice on existing and new hardware: -their capability limitations,
speed etc.
(iii) To show users how to deal with all types of software: -application packages operating
systems, programming languages etc.
(iv) To encourage good practice throughout the organization e.g. systems or programs
documentation, backup procedures, quality checks etc.
(v)To provide general IT training and specialized training on new development equipment,
software, etc.
(vi) To help avoid overlap and duplication of efforts among the units and users.
(vii) To provide assistance and guidance to users developing their own systems.
Distributed Processing
Distributed processing means that processing facility is made available at a no. of sites instead of
a single computer centre. We can have;-
 A number of computers at different sites not linked to each other
 A number of computers linked to a central mainframe
 A network of computers linked to each other without a central mainframe
all the computers in the network belong to the same organization.
138
Advantages
 Each computer can be used to process data like a decentralized system. In addition, a
computer at one location can also transfer data and processing jobs to and from computers at
their locations.
 It allows greater flexibility in placing the computer at the location where it is needed.
 Better computer facilities are easily available to end users i.e. users can use micro computer
systems for processing small jobs
 However, for complex jobs, they can easily access large computer systems
 It facilitates quick and better access to data and information especially where distance is a
major factor
 Telecommunication cost can be lower when much of the local processing is handled by on
site micro computers rather than distance central mainframe computers
Disadvantages
 There is lack of proper security controls for protecting the confidentiality and integrity of the
user. Programs and data that are stored on line and transmitted over network channel
 It is relatively easy to tap data communication line
 One technique used to protect security and privacy over data communication line is
encryption. Encryption device is a coding device placed on either end of the data
communication line putting a very complex code on the data
 At the other end of data communication line another encryption device is used to decode the
signal into to a meaningful message
 Due to lack of adequate computing/communication standards, it is hard to link different
manufacturers into a smoothly functioning network. This means that several good resources may
not be available to users of a network because of incompatibility.
 Due to decentralization of resources at remote site, management from a central control point
becomes very difficult. This normally results in increased complexity, poor documentation and
non availability of computer communication specialists at the various sites for proper
maintenance of the system
 Duplication of equipment
Centralisation
When an organization has established a single computer department to provide data processing
services, this department is often referred to as a centralized computer facility.
It is called centralized because it alone supplies data processing support to all other
departments in the company.
Advantages
 Cost effectiveness. The cost effectiveness of computer hardware resources is increased
because equipment is not duplicated at different locations
 Co-ordination and control. Processing activities are easier to co-ordinate and control in a
centralized facility
 Standards. The ability to impose and enforce processing standards is easier in a centralized
facility.
139
Disadvantages
 Lack of accountability. It is difficult to track and fairly allocate the costs of the computer
processing facility to the specific departments based on individual department use
 Unfamiliarity. The computer specialists responsible for the design of computer application
software ends up being responsible for working in many areas of the company with which they
are unfamiliar. As a result, the specialist often take a lot of time to understand the processing
requirements of a new department
 This problem often causes delays in a project and sometimes leads to misunderstandings in
other words, some of the software developed may fail to meet them on time
 Delays. In many cases, the data processing staff in centralized computer facilities has so
many demands placed on their time that users have to wait for a long time.
(Bentley, 2007) (Rosenblatt, 2006) (Senn, 1989)
140
REVISION QUESTIONS
1. A particular software application within the organization for which you work is giving cause
for concern due to the large number of errors occurring early in its operational life. You have
been asked to chair a meeting that will clearly state the problem and recommend appropriate
action. The Managing director then wishes you to give him a short verbal summary of the main
issues and back this up with a report.
How would you:-

(a) Plan this challenging assignment.
(b) Given control of this project, how would you have avoided the problem in the first place?
2. You are the project manager charged with the task of carrying out a cost-benefit analysis
exercise on a proposed computer-based application.
What techniques would you make use to demonstrate the costs and benefits of your proposed
system?
3. You have been asked by you managing director to prepare a report on a project which is
considered to be in difficulties.
(a) Describe what you would expect to be the symptoms of a failing project.
(b) Identify the typical causes of project failure.
(c) Identify also the possible consequences of project failure.
(a) Discuss the following systems implementation issues;
 Training
 Documentation
 System changeover
 File conversion
4.Distinguish between an information system and a business system.
5. Investigating and documenting the current business system is one of the stages of the Systems
Development Life Cycle.
(a) Briefly explain two reasons why it is important that the analyst should investigate and
document the current business system.
(b) Briefly describe three methods or models used in investigating and documenting the current
business system.
6. An important aspect of systems analysis is the ‗fact finding‘ stage of a systems investigation.
Depending on the circumstances and the system being studied, several different methods of fact
finding may be used;
141
You are required to:

(a) State four methods of fact finding.
(b) Give the circumstances in which each might be used.
(c ) Give an advantage and disadvantage for using each of the methods stated in (a) above.
7. A small trading company has decided to computerize its order, dispatch and invoicing
procedures. It intends to select an integrated package to fulfill all its requirements. The owner of
the company is concerned about the control and security procedures of the proposed application
and so is particularly looking at the password and audit trail features of each package.
(a) (i) What are passwords and what is their primary function?
(iii) Briefly explain to potential problems with passwords.
(iv) (iii) Explain how each of these potential problems could be overcome.
(b )Describe the operation, content and purpose of an audit trail software package, in particular
identifying attributes to be recorded.
8. (a) Explain what is meant by the terms physical and logical design. How the features of a
structured systems methodology could be applied to overcome the problems previously
experienced by the company.
(b) The promotion of the so called ‗End user computing‘ requires not only support from the
information center, but the provision of suitable software aids.
What is meant by the respective terms ‗end-user computing‘, ‗information center‘ and ‗software
aids‘.
9.
(a) What is entity modeling and why is it used?
(b )Describe the normalisation process and explain why it is used?
(c ) Draw an LDS (E-R model) for the following:-
An organisation has several subsidiary companies, which are not subsidiaries of any other
organisation. Some of the organisation‘s directors also directors of other organisations. Each
subsidiary has a number of employees, each of which works only for that subsidiary. Each
factory is allocated to one subsidiary only. Because of the nature of their work, some employees
work at more than one factory within a subsidiary.
Each factory makes a number of products, some of which for ease of distribution are made at
various factories within a subsidiary. Each product needs various raw materials, which are used
in several products. An individual customer buys any number of products.
142
10. (a) There are two stages of computer software testing

 Systems Testing
 User Acceptance Testing
Briefly describe these two stages.
(b)Certain deliverables in the System Development Life Cycle cannot be easily tested because
they are in the form of written documentation, specifically those deliverables likely to result
from the analysis stage such as DFDs (Data Flow Diagrams) and ERMs (Entity Relationship
models).
Describe how the correctness and quality of these deliverables can be ascertained.
11. A small chain of department stores is located in and around major metropolitan area .It is
about to implement in all stores point of sales system with linkages to a large centralized
computer . The stores all currently use conventional cash registers. You have been asked to assist
in the conversion process to the new system
(a) Evaluate the various approaches available for the system changeover and
recommend a method
(b) Produce a check list in sequence of those activities to be carried out during Implementation.
(c) Suggest as to how the new system might be evaluated after a period of operational running.
12. Ace Machine Tools is a medium sized engineering company. The sales director proposes to
purchase a standalone computer and automate the sales department‘s quotation and customer
order processes. You believe that there may be further advantages to be gained by linking the
new software to the existing stock control and accounting software.
You have a choice of purchasing standard application packages and adapting them for use, or by
commissioning a software company to write a dedicated suite of programs for your company.
Compare and contrast the two approaches.
13. List five benefits claimed by carrying out a Post Implementation Review.
14. In assessing the viability of projects, one criteria used is the economic feasibility which
involves evaluating the costs and benefits of the application concerned.
(a) Benefits can be classified as being either TANGIBLE or INTANGIBLE. Explain the,
meaning of these two terms and give two examples of each which might be applicable to a
stock control system.
(b) Costs can be described as being CAPITAL or ONGOING. Again, explain these two terms
and provide examples of each.
143
SPECIMEN EXAMINATION PAPER

Question 1.
The organisation for which you work has decided to base all future application development on a
‗structured methodology‘. However it has to select one from a choice of several.
(i) Identify and describe the critical requirements that you would consider if you had to make
the choice.
(10 marks)
(b) Detail the benefits that can be expected from the use of a structured methodology.
(10 marks)
Question 2.
(a) At which stages in project development should the systems analyst use data flow diagrams to
assist in the analysis and design of the system.
(10 marks)
(b) Identify and comment upon the benefits to be gained from the use of data flow diagrams as a
functional analysis tool.
(10 marks)
Question 3.
Investigating and documenting the current business system is one of the stages of the System
Development Life Cycle.
(a) Briefly explain two reasons why it is important that the analyst should investigate and
document the current business system.
(10 marks)
(b) Briefly describe three methods or models used in investigating and documenting the current
business systems.
(10 marks)
Question 4.
(a) There are two stages of computer software testing:
- Systems testing
- User Acceptance Testing
Briefly describe these two stages (10 marks)
(b) Certain deliverables in the System Development Life Cycle cannot easily be tested because
they are in the form of written documentation. Specifically, those deliverables likely to result
from the analysis stage such as DFDs (Data Flow Diagrams) and ERMs (Entity Relationship
models).
Describe how the correctness and quality of these deliverables can ascertained.
(10 marks)
Question 5.
Increasingly in systems development, use is being made of CASE tools.
(a) Briefly describe what a CASE tool is.
144
(4 marks)
(b) Additionally, in systems development, the following issues are considered to be important:-
 Producing and maintaining documentation
 Adhering to development standards
 Maintaining a logical data dictionary
 Prototyping
With reference to the above four issues, explain what advantages a CASE tool offers the system
developer compared to systems development using manually produced and maintained diagrams,
standards and documents.
(16 marks)
Question 6.
(a) Briefly describe the stages involved in a systems development cycle, starting with the
original identification of the problem by management and ending with a report back on
successful (or otherwise) implementation.
(12 marks)
(b) List the various skills that the analyst would be expected to employ during this cycle.
( 4 marks)
(c) Indicate the MAJOR human problems likely to be encountered by the analyst.
( 4 marks)
Question 7.
A particular software application within the organisation for which you work is giving cause for
concern due to the large number of errors occurring early in its operational life. You have been
asked to chair a meeting that will clearly state the problem and recommend appropriate action.
The Managing Director then wishes you to give him a short verbal summary of the main issues
and back this up with a report.
How would you:

(b) Plan this challenging assignment.
(12 marks)
(b) Given control of this Project, how would you have avoided the problem in the
first place. (8 marks)
Question 8.
(a) Monthly meetings are held to monitor the progress of a particular system development. At
one such meeting there is an item on the agenda regarding ‗actual/planned progress‘.
Suggest an approach you would use for capturing progress information and suggest a method of
reporting.
(10 marks)
(b) The starting point for many system developments is the production of a Project Initiation
Document (PID). This will contain the initial information required for analysts to start work on
an IT development. Discuss in general terms the kind of information you would wish to see in a
PID or EQUIVALENT DOCUMENT.
145
(10 marks)
146
SUGGESTED ANSWERS
QUESTION ONE
(a)
 Use of diagrams - which are easier to assimilate than large quantities of text thus giving
easier means of communication. They are also less liable to ambiguity or omission.
 Use of structured language - which helps reduce the complexity to terse, unambiguous
statements.
 Concentration on business requirements - the separation of the logical and physical
components of the analysis and design process. This enables analysts and developers to focus on
the business requirements rather than consider, too soon, the technical details.
 Analysis of current physical system - existing system is studied and documented. This means
that the models will cover all sorts of peculiarities which are purely the result of how the system
is implemented as distinct from what it is supposed to achieve.
 Derivation of current logical system - by stripping away the physical aspects of the current
system, the analyst forms a picture of what the system does, which can be used as a basis for the
specification of the new improved system.
 Specification of required logical system - further detailed analysis to ensure requirements are
clearly understood.
 Specification of required physical system - only when all the business requirements have
been specified is the design converted into a physical design for implementation.
(b) Benefits
 Concentration on system data aspects leads to a flexible data structure amenable to change.
 Use of diagrams and structured language improves communication and reduces errors.
 Errors and omissions spotted more easily due to rigorous cross checking
 Systems are built on business requirements and so should deliver business benefit.
 Since technical aspects are addressed late in development cycle, design should be suitable for
implementation in a variety of environments.
 Using a recognized structured method means that users are not tied to any one
developer.
Question 2.
(a).
 Before fact finding to outline the system as it appears to be
 During and after fact finding to show the system as it is
 During the physical to logical conversion to simplify the existing system
 During the BSO (Business Systems Options) stage to present different methods of tackling
the problems
 To enlarge upon the selected BSO
 Checks at various stages such as the Entity/Data store cross-reference
 To help identification of events and functions
 To present to users during walkthroughs
(b). To give an overview of the system as a guide to later fact finding

 To show in detail how the system works from overview to minute detail using the levelling
technique
147
 To clarify procedures and show how redundant/duplicated processes and data stores might be
simplified or removed
 To demonstrate in overview terms how various different solutions might appear. This is a
guide only and will need enlargement later
 To show the detail of selected options and act as a guide for further development of the
design of function processing and the data structure
 To provide essential details for development of catalogues and ELHs
 To act as a communication tool which the non DP person can readily comprehend thus
ensuring quality control of systems proposals at many stages through the project development.
Question 3.
(a). Reasons for investigating and documenting the current business system might include:
 Many of the processes and functions of the current system will be required in any successor -
it is important that proposed computer systems do not exactly mimic the operations of the current
system. However it is likely that fundamental processes performed in the current system will be
required in the future system. Consequently these functions must be understood and documented
so that they can eventually be implemented successfully in the new system.
 To gain the confidence of users - users need to have confidence in the analysts developing
the required computer system. One way of building this confidence is for analysts to competently
investigate, document and model the current system. This allows them to show their competence
in part of the life cycle in which the user is very familiar with. In general users value analysts
who understand their business systems. Investigating and documenting their current system gives
the analyst an opportunity to demonstrate understanding.
 Understanding the system‘s problems is essential for solving them - in some instances the
investigation of the system identifies problems and difficulties that can be resolved without
recourse to further system specification and development. There may be unnecessary bottlenecks
in the process, duplicated clerical procedures and unnecessary checks and balances. Resolving
these problems may lead to improved system performance regardless of whether the system is
eventually computerized.
(b) Methods include:

Interviewing
Formal meetings between analyst and user. These meetings establish how the current system
works, discuss any problems in the current process and identify and discuss screens, forms and
reports used in the current system. Subsequent meetings will focus on requirements for new
system. These interviews should be formally documented and contents agreed with interviewee.
Interviews provide the opportunity for the analyst and user to establish a rapport and to
investigate certain points in detail. However they are time consuming to organize, conduct and
document.
Questionnaires
Where not practicable to conduct an interview it may be possible to send a questionnaire listing
questions about the current system. They can be tested prior to distribution and each user is
asked exactly the same question.
148
However there is no opportunity to build rapport etc. or probe in detail.
DFDs
They are simple models which can be used to graphically document the operation of the current
system. The processes of the current system may be modeled with a standard set of symbols.
These diagrams can be presented to the user who can agree them as a true representation of
current business process.
Decision tables
In some cases the user may have explained processes which lead to a variety of outcomes
dependent on conditions. This can be modeled using a decision table where actions and
conditions are linked through a comprehensive set of combinations. If the analyst identifies
outcomes for each of these conditions then they can be fairly confident that they have fully
analyzed and documented the problem.
Question 4.
(a). Systems Testing
Individual programs are usually tested by the programmers who wrote them and by their team
leader who has certain testing responsibilities. Once a program has passed program‘ or ‗unit
‗testing it is passed on for system testing. System testing is usually undertaken by a systems
analyst or project leader.
Systems‘ testing considers whether the individual units or programs fit together properly. In
doing such tests the analysts will wish to verify that the programs interact successfully - passing
data from one to the other-and correctly.
Systems testing will also usually consider the error trapping and reporting facilities of the
system. Consequently the tester will enter values that will cause the system to fail or undertake
procedures leading to sudden or unpredictable failure. The ester will also need to ensure that the
error reporting messages are correct and that appropriate messages are displayed. The tester may
also take responsibility for ensuring that the interface is consistent e.g. same function key used to
quit the system and where appropriate it conforms to agreed standards and conventions.
Finally system testing ensures that the system fulfills its functional requirements. It is the last
chance to do this prior to the release of the system out of the department to the user.
User acceptance testing (UAT)

After the completion of systems testing the system is passed on for (UAT). In this stage the users
are asked to formally consider whether the system fulfills their requirements. In theory users
should evaluate the system against the formal specification they approved earlier in the project.
In practice it is a time when deviations between the system‘s operations and user‘s actual
requirements come to light.
UAT will consider the functional characteristics of the system but it is unlikely to replicate the
detailed range and format checks undertaken in system testing. By this stage users should expect
error trapping to work successfully. In contrast user acceptance testing will focus on the usability
149
of the system checking that the natural flow of the business process is reflected in the way the
software works.
UAT may also be concerned with:

 testing and agreeing cyclical activities
 testing and accepting generalized housekeeping functions (back-up and restore)
 testing and accepting documentation
(b) Systems and UAT is usually undertaken for physical working deliverables –programs or
systems whose behavior can be executed or documented. For example a program to calculate
average prices can be tested to see if it performs the calculation correctly. This procedure is not
always possible for deliverables early in the SDLC - such as DFDs and LDSs. Consequently
these are usually reviewed in structured walkthroughs. A structured walkthrough is a formal
meeting where a product is presented and checked for its:
 Functional accuracy. This is usually undertaken by the user at the walkthrough. Their role is
to confirm that a business process has been properly understood.
 Technical accuracy and adherence to standards. A standards or audit representative is present
to ensure that the product meets the quality standards defined in the methodology. The
walkthrough may also be attended by the presenter or author of the product. Walkthroughs are
also appropriate for testing working deliverables such as programs and systems and so are useful
at all stages of the SDLC.
Question 5.
(a). CASE stands for computer aided software/system engineering. A CASE tool is a S/W
package that supports the construction and maintenance of logical system specification models.
Many CASE tools are designed for a specific methodology and so support the rules and
interaction of the models defined in that methodology. More sophisticated tools permit S/W
prototyping and code generation.
(b). Documentation - the graphical editing facilities provided by all CASE tools means that high
quality, easily read documents can be produced. Furthermore changes to those documents can
easily be made and charts and models re-printed. Such editing is particularly useful with
diagrammatic models, such as DFDs and entity relationship models. It is very difficult to
maintain manually produced versions of these diagrams.
Standards - these define how development will be carried out. Individual models have standard
rules of construction e.g. a data store cannot be linked directly to an external entity in a DFD.
However there is nothing to stop the designer making such a connection in a manually produced
version and it will not be picked up until assessed in a quality review. A CASE tool cannot
produce such a diagram because it is not allowed to and in this way the CASE tool ensures that
standard construction rules are adhered to.
Data dictionary - this stores information about the constituent parts of the logical data systems
specification. There will be logical data dictionary entries for dataflows, data stores etc. A
manually compiled example is difficult to maintain and analyse. A CASE tool will hold all this
information in a computerised data dictionary. Reports and analyses will be available. The
150
logical data dictionary will also support the consistency checks performed by the CASE tool,
cross referencing, for instance, the logical data stores of the DFD to the entities of the entity
relationship diagram.
Prototyping - this can be supported in one of two ways, through developing screens and output
prints for the input and output dataflows. Each dataflow is defined in its logical content in the
data dictionary. The CASE tool may allow these logical contents to be displayed on a
demonstration screen and to link these screens together using menus and other dialogue
structures. Thus the user sees a demonstration of the system through the CASE software. A
second possibility is for the CASE tool to offer program and data generation. Such tools convert
the process descriptions of the logical data dictionaries into programs and the data stores/entities
into files/databases. The user can then experiment with the S/W. Any changes in requirements
are made in the definition of the models and the system regenerated for further use. In this way
the models and actual system are always in harmony.
Question 6.
(a). Stages
These will vary slightly, dependent upon experience and methodology, but should encompass.
 Project Initiation/definition
 Feasibility
 Analysis
 Design
 Implementation
 Production
 Post Implementation review
(b). Skills/techniques
Interviewing, observation, questioning, document search, sampling, estimating, DFD, LDS,
ELH, presenting skills, walkthroughs etc.
(c). Human Problems

 Fear, suspicion
 Reticence
 Lack of commitment
 Computer/business naiveté
 Obstructionism etc.
Question 7.
 Consider first the implications of the assignment find out who can contribute towards
resolving this issue and bring them together in a constructive environment - hence need to
consult, confer and set up workshop
 Organise an effective meeting - where, when, careful preparation, well structured info given
(possibly in advance) clear presentation of ideas
151
 Investigate the problem and identify the solutions - again consultation, analysis
 Make a brief presentation to him - know your audience, your purpose, your material and
location
 Write an accurate and comprehensive report - why are you writing, what does the reader do
as a result, do prewriting, writing and rewriting, remember structure of report Each of these is a
system task in itself.
(b) Avoidance of problem

Much of the initial problem could have been avoided by proper planning of the development
approach and preparation of a suitable testing plan. Hence:
 Use of a project management methodology to manage and control
 Use of a structured development methodology
 Use of properly prepared test plan covering module, program, suite system testing
concluding with UAT and sign off by users
Question 8.
(a). Implicit in this question is the need to track progress against plan for any contracted staff and
to support same. Responsibility for capturing this information lies with the Project Manager and
requires each member of the project team to be responsible for recording their effort towards the
project to include holidays, sickness etc. The process commences with the first activity on the
project and ends when the final activity is complete.
In brief, the process is:-

1. Time sheets are issued for completion by appropriate team members. This should be done in a
consistent fashion to maintain the quality. It should also be done on a pre-determined frequency.
2. The following should be recorded..
 actual start and end dates for activities

 effort spent on activities
 effort remaining to complete each activity
 estimated start and completion dates for each activity in progress or deviating from plan
 number of activities started to date
 number of activities completed to date
 number of activities in progress
 effort expended on completed activities
 comparison of current position against plan
 reason for variances
 current position regarding achievement of milestones
 details of any newly identified activities and dependencies
 details of costs
 absences, issues, changes

3. Completed time sheets go to Project Manager for verification
152
4. Project Plans should be updated accordingly
(b). Contents of a PID (Project Initiation Document) will vary but should contain
 Terms of reference
 Project Plans
 Aims and objectives
 Controls
 Risks
 Business case
 Quality plan...and policy
 Assumptions
 Constraints
 Project organisation
 Priorities
 Scope and boundaries
153
REFERENCES
1. Bentley, J. L. (2007). systems Analysis and design methods. New Delhi: Tata
McGwaraw-Hill.
2. Rosenblatt, S. C. (2006). Systems Analysis and Design. Boston: Shelly Cashman
Series.
3. Senn, j. A. (1989). Analysis and design of Information Systems. McGRAW-HILL
PUBLISHING COMPANY.
154

System Anaysis Design Study Guide Updated 2012

Transféré par

Informations du document

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

System Anaysis Design Study Guide Updated 2012

Transféré par

Droits d'auteur :

Formats disponibles

Systems Analysis and Design Study Guide

CHAPTER ONE: BASIC INFORMATION SYSTEMS CONCEPTS ............................................... 5

CHAPTER TWO: business analysis and INFORMATION SYSTEMS PLANNING ..................... 18

CHAPTER THREE: SYSTEMS ANALYSIS ..................................................................................... 24

CHAPTER FOUR: SYSTEMS DESIGN ............................................................................................ 61

CHAPTER SIX: SYSTEMS IMPLEMENTATION ......................................................................... 108

CHAPTER FIVE: SYSTEMS POST IMPLEMENTATION ........................................................... 113

CHAPTER SEVEN: PROJECT MANAGEMENT .......................................................................... 115

Revision Questions ................................................................................................................................ 141

CHAPTER ONE: BASIC INFORMATION SYSTEMS CONCEPTS

By the end of this chapter, you should be able to:

 Define the role of systems analysts in development of information systems.

 Describe the business drivers that influence IS development.

 Describe the technology drivers that influence IS development.

 Describe a simple process for developing IS.

What is a business system?

What is an information system?

Importance of information systems

Measuring the success/effectiveness of a recently implemented system

LEVELS OF MANAGEMENT AND THEIR INFORMATION NEEDS

An organisation‘s management can be classified in three levels:

(i) Operational management

TYPES OF INFORMATION SYSTEMS

Transaction Processing Systems

Management Information Systems

Decision Support Systems

WHAT IS SYSTEMS ANALYSIS AND DESIGN?

STRUCTURED APPROACHES TO SYSTEMS DEVELOPMENT

Focus on data structures

Use of diagrams and structured English

Concentration on business requirements

Benefits of structured methodologies

Disadvantages of using structured methods

Examples of structured methods

Structured Systems Analysis and Design Methodology (SSADM)

SSADM is documented in a set of classic manuals which describe:

The major techniques employed are:

SSADM life cycle

THE SYSTEMS ANALYST’S ROLE IN SYSTEMS DEVELOPMENT

Formal duties of a Systems Analyst

(h) Prepare the documentation and plan for user training.

Characteristics of a good analyst

(b) He/she must be a diplomat and a good motivator

(d) Must have well developed problem solving skills

Problems encountered by a systems analyst

 Working with group dynamics

SYSTEMS DEVELOPMENT LIFE CYCLE

Limitations of the life cycle approach to systems development

(b) The approach is inflexible and inhibits change

(c ) It is not suited to decision oriented applications.

1. Why are IS essential in organizations?

CHAPTER TWO: BUSINESS ANALYSIS AND INFORMATION SYSTEMS

 By the end of this chapter you should be able to:

Linkage of information systems to business objectives

 To secure or defend competitive advantage.

Developing A Business/Is Strategy

Investigating the Business Strategy

Components of a business strategy

 Critical success factors

 Consensus and Commitment

Documenting business processes

Documenting the external business environment

Examining and documenting the current information system provision

Determining the gap between business strategy and IT provision