Department of Computer Science & Engineering

PROGRAM OF STUDY: Computer Science

SUBJECT: System Analysis and Design

SUBJECT CODE: ACSC 155

Academic Year: 2010-2011

Semester: Fall
TABLE OF CONTENTS

1. Information Systems...........................................................................3
1.1 What is a System................................................................................................3
1.2 What is an Information System?.................................................3
2. Systems Analysis - Introduction......................................................4
2.1 What is Systems Analysis & Design?...........................................4
3. SYSTEMS ANALYSIS...........................................................................4
3.1 SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)..............................................4
3.1.1 Computer Assistant Software Engineering (CASE)......................................8
3.1.2 Users...................................................................................................................9
3.2 Design by prototyping.....................................................................................11
3.3 SYSTEMS INVESTIGATION.............................................................................13
4. Process Modeling..............................................................................17
5. Systems Design.................................................................................21
6. Input/Output Design and user interfaces........................................25
7. TESTING and DEBUGGING..............................................................33
7.1 TESTING...........................................................................................33
7.2 Debugging........................................................................................34
7.3 Installation - Integration..................................................................36

Page 2 of 38
1. Information Systems
1.1 What is a System
A system is a set of components that interact to accomplish some purpose. e.g. College
system, Economic system, Language system, a Business and its parts - Marketing, Sales,
Research, Shipping, Accounting, Government.

1.2 What is an Information System?

Information System (I.S.): Interrelated components working together to collect,
process, store, and disseminate information to support decision making, coordination
control analysis and visualization in an organization.

ORGANIZATION
INFORMATION SYSTEM

Processing
Input Classify Output
Arrange
Calculate

FEEDBACK

Information: Data that have been shaped into a form that is meaningful and useful to
human beings.

Data: Streams of raw facts representing events occurring in organizations.

Input: The capture or collection of raw data from within the organization or from its
external environment.

Processing: The conversion, manipulation, and analysis of raw input into a form that is
more meaningful to humans.

Output: The distribution of processed information to the people or activities where it will
be used.

Feedback: Output that is returned to the appropriate members of the organization to

help them evaluate or correct the input.

Computer-Based I.S. (CBIS): I.S. that rely on computer hardware and software for
processing and disseminating information.

Page 3 of 38
2. Systems Analysis - Introduction
2.1 What is Systems Analysis & Design?
The process of examining a (business) situation with the intent of improving it through better
procedures and methods.

System Analysis - Process of gathering and interpreting facts, diagnosing problems, and
using the facts to improve the system.

Systems Design - Process of planning a new system to replace or complement the old.
Analysis specifies what the system should do and design states how to achieve the
objective.
Note : This examination should always be initiated by the people involved in the situation
(or who will be involved in a new situation). It is the job of the analyst to suggest solutions,
but not make business decisions. (A computer based solution is not necessarily the only
one!).

What Systems Analysis is NOT

Studying a business to decide which existing procedures should be handled by the
computer and which should be done by non-computer methods.

 Determining what changes should be made.

 Initiate new procedures and practices.

3. SYSTEMS ANALYSIS
OPORTUNITY TO IMPROVE A SYSTEM

3.1 SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

A System development life cycle (SDLC) is a process by which systems analysts,
software engineers, programmers, and end users build information systems and
computer applications. It constists of 5 stages.

S1. Problem Identification (First stage - What is the problem)

Systems Planning: ongoing study of a problem environment to identify problem-
solving possibilities.
Identify and prioritize those technologies and applications that will return the most
value to the business.

e.g.
Stock control system
 Location of each item ile number, shelf etc.
 Which sell most?
 Which is the most profitable?

Page 4 of 38
S2. System Analysis
Priorization of the requirements for solving the problem. The emphasis is on the
business, not the computer.
In other words, is the study of current business and information system, and the
definition of user requirements and priorities for new information system.
Synonyms include business problem analysis, requirement analysis, and logical
design.
Basically, WHAT TO DO, NOT HOW TO DO IT.

What should system do?

- keep records of sales
- keep records of stock levels - produce sales reports

Feasibility Study
Advantages Vs Disadvantage

T Technical feasibility (technically practical, staff, expertise)

E Economic feasibility
 Is it cost effective?
L Law feasibility
 Is it legal?
O Operational feasibility
 Does it fulfil user requirements?
 To what degree?
 Will the work environment change?
 How does users feel about such a solution?
S Schedule feasibility
 Design and implementation in acceptable period of time?

S3. System Design

The evaluation of alternative problem solutions and the detailed specifications of
the final solution computer-based. Emphasis shifts from the business to the
computer solution.
Sent to programmers.
It is also called physical design.
Basically, HOW TO DO IT.

Logical
 What data to hold?
 Which process to transform data?

Physical
 Which software and hardware to use?
 Decided on a package which could be modified

S4. System Implementation

The construction or assembly of the new system and the delivery of that system
into “production” (meaning “day-to-day operation”).

Page 5 of 38
 Buy and install hardware
 Install software
 Set up data files
 "Test Run" system
 "Go live"

S5. System Support & Maintenance

The ongoing maintenance and enhancement of a system after it has been placed
into operation. This includes program maintenance and system improvements.
 Enhancements to software
 to produce reports on certain items only “group" items and sort into
various orders for reports.

Page 6 of 38
3.1 (Continued) Systems Development Life Cycle - Main Steps
1. Produce Identification Terms of Reference
2. Preliminary Analysis Feasibility Reports
3. Systems Analysis Functional Specification
4. Systems Design Detailed Systems Specification
5. Implementation Fully documented System
6. Maintenance Test Runs

System Life Cycle

The feasibility study

No Abort project
GO
AHEAD?

yes

Maintenance
Detailed Detailed system
System analysis Design
Specification

implementation physical
system t e s t i n g a n d
change over

Figure 3.1: System Development Life Cycle

Project: a sequence of activities that have one goal or purpose and that must be
completed by a specific time, within a predefined budjet, and according to
some specification.

Project Manager: The person responsible for supervising a system project from
its initiation to its completion.
3.1.1 Computer Assistant Software Engineering (CASE)
The use of automated tools that support the drawing and analysis of system models and
associated specifications. Some case tools also provide prototyping and code generation
capabilities. You can think of the CASE technology as a software that is used to design and

Page 7 of 38
implement other software(s) (similar to the CAD technology for engineers).

Project Management tools and Techniques

PERT CHART (Project Evaluation and Review Technique)

A graphical network model used to depict the interdependencies between project tasks.

Example: A PERT Chart diagram for the Analysis phase of a system project

LABE ACTIVITY PREDECESSOR DURATION

L
A Conduct Interviews None 3
B Administer Questionaires A 4
C Collect Company Reports None 4
D Analyze Data Flow B,C 8
E Introduce Prototype B,C 5
F Observe Reactions to Prototype E 3
G Perform Cost/Benefit Analysis D 2
H Prepare Proposal G 2
I Present Proposal H 2

Table 3.1: Activities of the Analysis phase

Figure 3.2: PERT Chart for the analysis phase

Page 8 of 38
Gantt Chart
A simple time-charting tool used for project scheduling and progress evaluation. A bar chart
to depict project tasks against a calendar.

Example:

Figure 3.3: Gantt Chart for the System Development.

3.1.2 Users
Direct
 interact with the system direct
 initiate Administrative - Money
 Actually interact with the system. They feed in data or receive output,
possibly using a terminal. A new system will considerably change the daily
work of these users.

Indirect Users
Benefit from the results of reports produced by the Computer System. These
users may be managers of business functions using the system.

Administrative Users
Users that have management responsibilities for Application systems. These
users may use systems directly or indirectly, but they retain authority to
approve or disapprove investment in the development of Application
systems.

People involved in Analysis

Business Analysts (B.A.) – Identification Feasibility Analysis

Conducting system studies to learn the relevant facts about a business activity. The
emphasis is on determining information and processing requirements. Their responsibilities
do not include systems design.

Systems Designers (S.D.) – Design

Begin after the initial investigation by Business Analysts and use that information to design
the system. The emphasis is on converting the requirements into processes (programs)
and data (files or database). They do not write programs but do investigate available
software and hardware.

Page 9 of 38
Systems Analysts - Everything
They combine the responsibilities of B.A. and S.D.

Analyst Programmers - Everything (or what they know)

Combine responsibilities of S.A. and Programmers, i.e. they also develop the software to
implement the design.

What does a Systems Analyst do?

 Conduct a study of the feasibility of the proposed system.
 Liaise with users of the system and determine their requirements.
 Find out the facts relevant to the design of the proposed system.
 Determine the human and computer procedures that will make up the system,
designing forms, files, reports.
 Write program specifications.
 Test the programs and the system.
 Participate in the implementation of the system.
 Document the system.
 Do anything else that will produce an efficient and effective system.

What skills does a system analyst need?

 The ability to communicate verbally and in writing.
 To extract relevant facts - a Detective.
 To obtain information in a reasonable way - a Diplomat.
 To interpret a jumble of facts and convert them into a logical form.
 To understand and have a broad knowledge of modern computer hardware &
software.
 To keep up-to-date on System Methodologies.
 To be creative.

S.A. Characteristics: trusted, develop ideas in an objective way, range of social skills,
patient, perceptive, fair, unbiased, persistent, good listener, empathy.

Questions

1. How would you define an "effective system"?

2. Would a system produced by analyst programmers be more or less "effective"

than one produced by separate people?

3. Users have a right to influence systems design. Do you agree with this?

4. Do users have a responsibility to participate in systems design?

People involved in Systems Investigation

Page 10 of 38
Systems Analysts - all types.

Computer Systems Managers - in the areas of Data entry, Hardware selection, Database
Administration, Operations and Project Management.

Users - all types.

Systems Consultants - people with specialist expertise, e.g. a particular business activity
or database selection.

Internal Auditors - to ensure adequate internal controls and that the systems output can be
audited.

Managers of the organisation - facilitating the required resource allocations and formally
accepting the developed systems.

Objections to the life cycle model

A major criticism of the life cycle model is the time-scale associated with its linear
progression of activities. The gap between specification iand delivery is often so
long that requirements change dramatically in time. This leads to the delivery of
systems that "were required two years ago".

Also, the specification itself is often not understood by the users responsible for
agreeing it. It is often given in computer terms described of such length that there
is little chance of the user really being able to assess if it actually represents his
requirements. Consequently, many delivered systems have to undergo changes that
reflect misunderstanding and altered circumstances. This is often euphemistically called
maintenance.

An alternative approach
Known as prototype has claimed advantages in most aspects of the life cycle.
Prototypes are a first attempt at a design which is then extended and enhanced
through a series of iterations.

3.2 Design by prototyping

Prototype: “an original or model on which something is patterned” and/or “a first full
scale”.

Prototyping stresses the early delivery of an incomplete but working system and the use
of prototypes may be valuable at various stages of the life cycle.

Users have to specify their requirements in advance (unclear to a user how a system
may help him, either because the role of the computer is not understood, or because the
information needed are unclear). Difficult for most users to clearly envisage what they
want and how they can use it until they are able to experiment with a tangible system.

So, a simple prototype designed to accommodate broad needs, together with possibilities

Page 11 of 38
suggested by the designer using experience gained in other projects may be used to
define requirements more accurately.

Prototype
It is a live working system not just a paper based. Users can test its operation and
explore its facilities and so do not have to rely upon written descriptions. It is an iterative
process.

The prototype approach

Analyst
The prototype approach User

USER ANALYST

Identifies basic
information Analyst
requirements develops
system that
fullfil basic
requirements

Experiments
with
basic system in Analyst refines
actual prototype
application system to reflect
identified
requirements

Questions
1. Outline a comparison between the two approaches of designing a system that is the
system life cycle and the prototype.

2. Identify the negative and positive aspects of each one of them? Which one would
you use and why?

Advantages – disadvantages
Technology & Strategy of prototyping

Page 12 of 38
3.3 SYSTEMS INVESTIGATION

1. Interview
2. Questionnaire
3. Record Inspection
4. Observation

Fact finding
 What (information)
 When (to be produced)
 How (is to be presented)
 Why (is it wanted)

1. Model existing system

Model the object system before and after interviews
objects - people and processes
messages - forms, documents, reports

 Before investigation - Informal

 After investigation - Formal - DFD s - Data flow diagram(s)
LD Ss - Logical data structures(s)

2. Search for external similar systems

By talking to colleagues, researching in library, using own past experience
a. gives prompts for questions
b. suggests alternatives
c. learn from other's mistakes and avoid them

Local search in existing system

purpose of data, information, report
new information for improvement
(information from interviewing, but it is often useful to look at existing user manuals
before interviews)

3. Interviewing
Start at the top always asking permission to interview subordinates - ask them as well.
Usefull information can be extracted from interviewing, but it is often useful to look at
existing user manuals before interviews
Basic Processes; Data; Limitations; Controls; Enhancements
You will need a check-list before you conduct the interview

Main questions in mind

1. What is the basic business process?
2. What is the purpose of this business activity?
3. What steps are performed?
4. Where are they performed? Who performs them?
5. How long does this take?

Page 13 of 38
 6. How often is it done?
7. Who uses the resulting information?
8. What data is used and/or produced during the process? Ask to see "records".
9. What are the limits imposed by time and the volume of work? What "triggers" the
activity? When does this happen? When must it be completed? How often does it
happen (volumes)?
10. What performance controls are used?
11. Are there specific performance standards? Who compares performance against
standards? How are mistakes caught and the errors handled? Are the errors
excessive?

How to Conduct a Successful Interview

a. Make an appointment in advance, advise on nature of interview, should be no
longer than 1 hour.
b. Prepare in advance, learn about individual to be interviewed, become familiar with
topic, prepare appropriate set of questions.
c. During the interview:
Introduction: Begin with general questions; Follow up on topics & issues; Limit
note taking; Summarize at end.
d. After interview document results and send copy to interviewee.
e. Consider follow-up interview(s).

4. Questionnaires
Large number of "users"
Distributed over large geographical area
General public users

5. Record investigation
Necessary for data analysis and definition

6. Observation
Watch "users" work
Work with "users"
Partial observation, user `talks through' process

Advantages & Disadvantages of ivestigation methods

1. Interviewing
Advantage: Straight from the "horse's mouth".
Disadvantage: Without initial model or existing system, very difficult to know where to
start (time consuming).

2. Questionnaires
Advantage: Time saving when a lot of far flung interview would otherwise be required.
Disadvantage: Unrepresentative sample due to low response.

3. Record Inspection
Advantage: Impossible to investigate current system without seeing documentation.
(Imagine describing in detail an order form in an interview).
Disadvantage: You could be viewing out-of-date, used differently now documents.

Page 14 of 38
4. Observation
Advantage: See informal system.
See exactly which documents are used and how.
Disadvantage: Observes may feel under pressure to go by the book.
Time.

Problems in Investigation
 Commitment to old system
 Resistance to change
 Embarrassment
 Fear of Job Loss
 Lack of interest
 Analyst's lack of skill. Conflicting interests
 Territorial Instincts
 Expressing position too early

Project Initiation
1. A problem with the existing system.
2. New technology - greater benefits or lower costs.
3. Formalise manual or informal system.
4. New information required.
5. Resources become available for ‘frozen’ investigation.

Past History
1. Little Analysis
2. Poorly Defined Tasks
3. Well defined User Role

End Products
Lengthy Narrative Specifications
1. Difficult to: Read, Understand, Change
2. Confused: Requirements, Design, Implementation

Resulting Systems
1. Took too long to build
2. Cost too much
3. Failed to meet requirements
4. Failed to meet constraints
5. Were inflexible
6. Were poorly documented

System Analysis
1. HOW WOULD YOU DEFINE AN "EFFECTIVE SYSTEM"?
An effective system is a system that makes the most out of its purpose, value for money
and solve the problems that an organization has.
2. WOULD A SYSTEM PRODUCED BY A N A LY S T PROGRAMMERS BE MOR E OR LESS
"EFFECTIVE" THAN ONE PRODUCED BY SEPARATE PEOPLE?
A system made by Analyst programmers is more effective than one made by separate

Page 15 of 38
 people because the analyst will analyze the program having in mind all the problems and
he will not have to explain everything to other person. But if separate people analyze
the system and program then they will have to explain everything to different people.
3. WHICH JOB IS THE MOST SATISFYING, SYSTEMS ANALYST OR ANALYST
PROGRAMMER OR PROGRAMMER?
To be a programmer is the most satisfying job (for most computer science persons) because
you do not depend on anyone else to do your job. You only need the analyst to explain to
you what he wants out of the program.
4. USERS H AV E THE RIGHT TO INFLUENSE SYSTEMS DESIGN. DO YOU AGREE WITH
THIS?
I believe they (must) have the right (and the responsibility) to influence systems
designs because they are the ones who know what their company really needs
(requirments). The users do not know exactly what kind of a program might be useful
for each purpose and what a program needs in order to get the most out of it.
5. EXPLAIN THE SDLC A N D DESCRIBE E ACH OF THIS INVOLVED IN IT?
SDLC are the steps used for system analysis and design which are: …

Page 16 of 38
4. Process Modeling
A technique used to organize and document the system’s processes.

Decomposition Diagram & Data Flow Diagrams (D.F.D.s)

Decomposition Diagram
A tool used to depict the breaking of a system into subcomponents.

Figure 4: Part of the Decomposition diagram of FIT DVD club.

Data Flow Diagram (DFD) show how data flows around an information system.
They are a simple and powerful graphic technique which is both easily updated and easily
understood by users. This is basically one of the main diagrammatic techniques of SSADM
(Structured System Analysis and Design Methodology). SSADM is explained in Appendix A.

Process: Shows a transformation of data and is also referred to as a function.

n is the number of the process, this number also indicates the level of the process.
PN is the process name.

Page 17 of 38
 DFName

Data Flow / Physical Flow of data

DFName: Data Flow Name

EN: Is the external entity name

External entity (source and/or sink of information) – destination. This can be a person,
oranizational unit, system or another orgnization interacting with the system. Also, called
external agent.

DSName

Data Store: Storage of Data

DSn - Data Store n (number)
DSName - Data Store name

Rules (all of the following are not permitted)

Miracle

Black Hole

` P D. S. E.E

Page 18 of 38
 P   
D. S.  × ×
E.E  × ×

Plus, additionally,

Each data store must have at least one input flow and one output flow (read & write).

Gray Hole: Insufficient input

What is a DFD?

A hierarchical set of diagrams which is used to define:

- the boundary of the system to be developed

- the information flow to and from the system
- data flows within the system
- the functions used by the system.

(used to define the project scope and to provide measures of performance - for use in
estimating and planning).

How is it developed?
1. Identify inputs & outputs.
2. Label all data flows.
3. Label all processes.
4. Identify data stores.
5. Label all External Entities.
6. Start again.

Data Flows between

External entity and Process
Data Store and Process,
Process and Process

Note: Information (Data) held for any amount of time between processes is called a
DataStore.

Example: (of a Level 0 D.F.D – also called the Context Diagram)

Page 19 of 38
Object modelling
Is a technique which identifies objects and their relationships within a the system.

Unified Modeling Language (UML)294

An approach that utilizes object modelling languages.

Page 20 of 38
5. Systems Design
The evaluation of alternative solutions and the specification of a detailed computer
based solution. Also called physical design. Driven by system designers and/or system
analysts.

Design System analysis (requirements)

System design deals with the physical or implementation dependent
aspects of a system (the system’s technical specifications) HOW TO.

Systems design builds on the knowledge derived from systems planning and systems
analysis.

Purchase software Vs Develop software (why reinvent the wheel).

Buy software packages – to fulfil end user requirements.

System Analyst
Primarily focused on the logical, implementation
independent aspects of the system (requirements).

System design
Deals with the physical or implementation
dependent aspects of a system (system’s technical specifications).

 Design process
3 phases of System Design
a. Selection Phase - Evaluation and selection of alternative solutions
b. Acquisition Phase - Acquisition or purchase of computer software and hardware
c. Design & Integration Phase - Traditional physical design and integration of
computer-based components

A. Selection Phase
Activities or Steps

1. Specify alternative solutions

 Ideas and opinions from system owner and users also system analysts and
system designers
 Technical consultants and other IS professionals

Some technical choices may be limited by a predefined approved technology

architecture provided by system managers.

Candidate solutions
Candidate matrices (Page 478)

2. Analyse feasibility of alternative solutions

2.1 Technical feasibility (technically practical, staff, expertise)

2.2 Operational feasibility

Page 21 of 38
  Fulfil user requirements?
 What degree?
 Work environment change?
 How does users feel about such a solution

2.3 Economic feasibility

 Cost effective?

2.4 Schedule feasibility

 Design and implementation in acceptable period of time?

3. Recommend a solution

 Infeasible candidate eliminated

 Candidate that offers the best overall combination

 System Proposal (for system owner for final decision)

Project plans
Size estimates
Candidate solutions
Feasibility analysis

B. Acquisition phase and system design

Step or Activity

1. Research Technical criteria and options

Research technical alternatives hardware and/or software requirements
Product and random facts from various sources
 Internal standards may exist for hardware and software selection.
 Information services (survey the marketplace for new products).
 Trade newspapers and periodicals.

2. Solicit Proposals (or Quotes) from Vendors

Baying from a single source Vs use the competitive marketplace

Request for quotation (RFO)

Request for Proposal (RFP)

3. Validate Vendor claims and performance

4. Evaluate and Rank Vendor

Cost benefit analysis

5. Award (or Let) Contract and Debrief Losing Vendors

Winning Vendor Losing Vendors

contract

Page 22 of 38
 agreement

6. Establish Integration Requirements

Integrate or interface the new system to the existing systems
Problems: different technology
techniques
structures

C. Establish Integration Requirements

 Developing technical design specifications

 Design and Integration Phase

General Design Detailed Design

Outline of the overall Developing the detail design
Design specifications for
components in the outline.

1) Analyse and Distribute data

Data model exist development of ideal file and database solutions

Data analysis: A procedure that prepares a data model for implementation as a no

redundant flexible, and adaptable file/database.

Normalization: The procedure that is used to simplify entities, eliminate redundancy

and build flexibility and adaptability into a data model. Data attributes are
grouped together – stable, flexible

Event analysis: A technique that studies the entities of a fully normalized data model to
identify business events and conditions that cause data to be created,
deleted or modified.

DFD’s may need to be revised.

2) Analyse and Distribute process

3) Factor into design units

Smaller pieces – design units

4) Design computer files and/or Database

Not just layout of records
Future programs may use files and databases in way not original envisioned

5) Design Computer Outputs and Inputs

Page 23 of 38
 Input and Output design requirements
End-users -ideas, suggestions, especially regarding format.

6) Design On-line user interface

Dialogue between the end-user and computer easy to learn and easy to use dialogue.

7) Present and Review Design

Computer program specifications that will guide the computer programmer’s activities
during the construction phase of the SDLC.

(1) Implementation plan

(2) A final cost benefit analysis

Review the system with

 System users
 System owners
 Technical support staff
 Audit staff

Installation of the system: Phase, Direct, Pilot, Parallel

Page 24 of 38
6. Input/Output Design and user interfaces
Data Entry Methods and Devices
Keyboard. Most keyboards contain the letters of the alphabet, but not all do, for
instance most calculator keyboards are very different, as are the keyboards for use at
ATM machines. The characters needed for specialist use machines are determined by
the use to which the machine is to be put. Keyboards are the most common form of
input device to a system because they are universally available and understood.
The common keyboard is known as the QWERTY keyboard because those are the first
six characters on the top line.
Ergonomic keyboards.
Touch-sensitive keyboards, or concept keyboards, they are ideal for use outside
because rain will not damage them like a normal keyboard.
Musical keyboard. Normally arranged like a piano keyboard these need a special piece
of hardware to allow them to work properly, known as a MIDI (musical instrument digital
interface)

Mouse. It is particularly useful because it mimics the natural human reaction of being
able to point at something.
Tracker ball used in many laptop computers.
Touch Pad

Keyless Data Entry

Keying errors have always been a major source of errors in computer inputs (and
inquiries). Any technology that reduces or eliminates the possibility of keying errors
should be considered for system design.

OCR (optical character reader). This is a device that reads characters and can
distinguish between the different characters in a given character set. It works by
comparing the shape of a scanned character with a library of shapes that it is intended
that it should recognise. OCR tends to be an unreliable form of input and works more
effectively when it is restricted to having to recognise a standard character set produced
by printing rather than by using hand writing. OCR is used for reading post codes on
printed documents and also for reading documents for blind people, the contents of
which can be output using a voice synthesizer.

OMR (optical mark reader). This device can recognise the presence of a mark on a
sheet of paper. The position of the mark conveys information to the machine. For
example a school register may consist of a list of names of pupils in a class together
with two columns of small rectangles, one for present and one for absent. The same
action (shading in a rectangle) stands for both being present and being absent. The
difference is the position that the mark occupies on the paper. Printing in the sensitive
areas of the sheet is done using a special type of ink which the optical scanner does not
see, that is why OMR documents tend to be printed in a light blue or pink colour. The
other standard use for OMR documents is as multi choice examination answer sheets.

Page 25 of 38
MICR (magnetic ink character reader). This is a device that reads characters that are
printed on an original document at the time of it being created. The characters are
printed using magnetic ink. The value is that the characters are readable by humans and
by machines. The only common use for such characters is the data printed on the
bottom of cheques containing account identification.

The big advantage of both OCR and OMR is that data can be input to a computer
system without having to be transcribed first, thereby cutting down the number of errors
on data input.

The real advances in keyless data entry are coming for on-line systems. Bar coding
systems (similar to universal product code systems that are commonplace in the grocery
and retail industries) are widely available for many modern applications. For example,
Federal Express creates a bar code-based label for all packages when you take the
package to a centre for delivery. The bar codes can be read and traced as the package
moves across the country to its final destination.

Barcode readers. A barcode reader is a laser scanner that reads the reflected laser
light from a series of dark and light coloured lines of varying thickness. The different
widths of pairs of lines make up a code that can be converted into a number. This
number can then be used as the keyfield relating to a file of items that have been
barcoded. The details of the contents of the barcodes are not of importance to us in this
section, except to say that barcodes can easily be misread by the system, so one of the
digits in the number is used to check that the rest of the code has been read properly.
This digit is called the check digit, and will be discussed in more detail later in the
course. Barcodes are particularly useful because they do not rely on human beings to
input the data, although, if the barcode is damaged so that the laser scanner cannot
read it properly, the digits represented by the code are printed underneath so that they
can be input by a user at a keyboard. Barcodes are used where the data does not
change, and so can be printed on original packaging.

Keyless data entry should be considered for appropriate high-volume transaction-based

systems as they become candidates for redesign.

Pen Input
Pen-based computing is starting to evolve. As pen-based operating systems (e.g.,
Microsoft's Pen Windows) become more widely used and tools for building pen-based
applications become available, we expect to see more system designs that exploit this
technology. Some businesses already use this technology for remote data collection. For
example, UPS uses pen-based notebook systems to communicate deliveries to drivers
and to collect delivery confirmation signatures and data from customers and drivers.
When a driver returns to their distribution centre, the data is transmitted from the
pen-based notebook computer to host computers.

Scanners. A scanner is a device that converts a document into a series of pixels (picture
elements – these are small squares that, when put together, form a picture). The larger
the number of pixels, or conversely the smaller each individual pixel, the better the
definition of the final picture. There are different types of scanner, but all use the same

Page 26 of 38
principle to create the image. A typical use for a scanner would be to input a picture of a
house so that it could be included with the details of a house that is for sale in an estate
agent’s publication.

Graphics Tablet. A graphics tablet is a flat surface on which a piece of paper is placed.
The user can then draw on the paper and the tablet will sense where the pencil is
pointing and transfer the line to the screen.

Microphones. Used to input sound to a computer system.

Output Methods and Devices

There are too many output devices to be able to write notes on all of them. Again, the
same thing is true about output as is true about input, that it is important to know about
those devices stated in the syllabus and also a range of devices that will allow for
sensible decisions about peripheral devices to be made for a given scenario in a
question.

Screens. Monitor screens are categorised according to the obvious

colour/monochrome, also according to the number of pixels that there are on the screen.
The more pixels there are, the better the picture will be, known as the screen resolution.
This is being typed using a very low resolution, monochrome screen. If you consider the
contents, there is no reason for any further sophistication to be necessary. However, a
computer system running a game program will need colour and many more pixels in
order to produce a satisfactory picture. The more pixels that there are on the screen, the
higher the resolution is said to be.
A particular type of screen, called a touchscreen, acts as both an input device and an
output device. Information is output by the system onto the screen and the user is invited
to answer questions or make choices by pointing at a particular area of the screen. The
device can sense where the user is pointing and can report the position to the processor.
The processor can then deduce what the user’s reply was according to the position that
was pointed to. Touchscreens are particularly useful in areas where keyboards are not
appropriate, e.g. where the device may suffer from vandalism. They are also useful for
users who would find difficulty using other input devices, e.g. very young children who
want to be able to draw on a screen.

Printers. A printer is a device which provides the user with an output from the system
which is permanent. This output is known as hard copy, so a printer is a device which
produces hard copy. There are many different types of printer and the student should be
aware of a number of them, their uses, advantages and disadvantages. However, there
is no need to understand how they work.
The first type is a dot matrix printer. These tend to be slow, and the output is particularly
poor quality. The big advantage is that the output is produced by using pins to strike at
the surface of the paper. Because of the physical nature of the way that the printout is
produced, it is possible to obtain multiple copies by using carbon paper or self
carbonating paper. A good example of this is the receipt that a shopper is presented with
if buying something using a credit card, there are two copies produced, back to back,
one for the shop to keep and one for the buyer to take away with them.
Ink jet printers, which produce output by spraying ink on to the paper could not produce
the two copies that the dot matrix can, but it can produce much better quality and in

Page 27 of 38
colour, at low cost. This makes ink jet printers ideal for home use.
Laser printers can produce very high quality work at high speed. The cost is more than
with the other types but used where it is necessary to give a good impression, for
instance sending letters from a solicitor’s office to clients.
Plotters are a type of printer designed for drawing lines and geometric designs rather
than for producing characters. The image is created by pens being moved across a
piece of paper, under the command of the processor. Plotters tend to be used for
drawing blueprints, perhaps in an architect’s office to produce detailed drawings of
buildings for builders to follow.

Speakers. Used to output sound from a computer system.

There are many other peripheral devices and, as has been mentioned, knowledge of
some others will not come amiss, however that is enough to be able to answer questions
in the exam. The questions will normally take the form of presenting a scenario and then
asking for a description of the hardware required. The important thing to remember is
how the marks will be awarded. There will not be a mark for every device mentioned, but
the candidate will be expected to give sensible suggestions for each of the four areas of
peripherals mentioned at the start of this section. In other words the mark will not be for
a keyboard or a mouse, but for suggesting sensible methods of input to the system.

Graphical user interfaces

Graphical user interfaces are a method of user communication with an operating
system. Through the interface, the user gives the operating system commands. With a
graphical user interface, rather than typing commands, the user will select icons,
buttons, bars or boxes to perform a task. Usually a mouse is used to make the selection.
Many people believe that graphical user interfaces are quick and easy to learn, promote
standardization of application program interfaces and reduce errors.

Graphical user interfaces (GUIs) were popularized by the success of Apple's

Macintosh and Microsoft's Windows. While the commercial success has been driven by
applications such as word processing and spreadsheets, the popularity of the interface
is driving all applications to the interface.

Technology exists to create GUI-like applications for dumb terminals. Technology also
exists to create true PC-based GUIs that work with host applications via cooperative
processing. And most importantly, GUI technology has become the user interface of
choice for client/server applications.

GUIs do not automatically make an application better. Poorly designed GUIs can negate
the alleged advantages of consistent user interfaces. Fortunately, GUI standards are
evolving to guide system designers to create consistent interfaces. For example,
DOS/Windows and OS/2 Presentation Manager are based on a standard called
Common User Access (CUA). Properly designed GUIs simplify input, reduce keystrokes
required, and provide interesting and useful formatting options for outputs. Many
businesses are mandating their use for all new systems.

Page 28 of 38
System User Issues for Input and Output Design

Because inputs originate with system users and outputs are used by system users,
human factors play a significant role in both input and output design. inputs should be as
simple as possible and designed to reduce the possibility of incorrect data being
entered. System users must find computer outputs easy to use and helpful to their jobs.
Furthermore, if batch input methods are used, the needs of data entry clerks must also
be considered. With this in mind, several human factors should be evaluated.

First, the volume of data to be input should be minimized. The more data that is input,
the greater the potential number of input errors and the longer it takes to input that data.
These general principles should be followed for input design:

• Enter only variable data. Do not enter constant data. For instance, when deciding
what elements to include in a SALES ORDER input, we need PART NUMBERs for all
parts ordered. However, do we need to input PART DESCRIPTIONs for those parts?
PART DESCRIPTION is probably stored in a computer file. if we input PART
NUMBER, we can look up PART DESCRIPTION. Permanent (or semi-permanent)
data should be stored in files. Of course, inputs must be designed for maintaining
those files.

• Do not input data that can be calculated or stored in computer programs. For
example, if you input QUANTITY ORDERED and PRICE, you don't need to input
EXTENDED PRICE, which is equal to QUANTITY ORDERED X PRICE. Another
example is incorporating FEDERAL TAX WITHHOLDING data in tables (arrays)
instead of keying in that data every time.

• Use codes for appropriate attributes. Codes were introduced earlier. Codes can be
translated in computer programs by using tables.

Second, source documents should be easy for system users to complete. The following
suggestions may help:

• Include instructions for completing the form. Also, remember that people don't like to
have to read instructions printed on the back side of a form.

• Minimize the amount of handwriting. Many people suffer from poor penmanship. The
data entry clerk or CRT operator may misread the data and input incorrect data. Use
check boxes wherever possible so the system user only needs to check the
appropriate values.

Third, design documents so that they can be easily and quickly entered into the system.
We suggest the following:

• Data to be entered (keyed) should be sequenced so it can be read like this book, top
to bottom and left to right (see Figure 16A). The data entry clerk should not have to
move from right to left on a line or jump around on the form (see Figure 16AB) to find
data items to be entered.

Page 29 of 38
• Ideally, portions of the form that are not to be input are placed in or about the lower
right portion of the source document (the last portion encountered when reading top
to bottom and left to right). Alternatively, this information can be placed on the back of
the form.

These are only guidelines. System users should have the final say on source document
design! Many of these same system user issues also apply to output design. The
following general principles are important for output design:

1. Computer outputs should be simple to read and interpret. These guidelines may
enhance readability:

• Every report or output screen should have a title.

• Reports and screens should include section headings to segment large amounts
of information.
• Information in columns should have column headings.
• Because section headings and column headings are frequently abbreviated to
conserve space, reports should include legends to interpret those headings.
• Legends should also be used to formally define all fields on a report. You never
know whose hands a report might end up in! (Note: Legends can be built into
on-line outputs using function keys to temporarily interrupt the output to display
legends and help.)
• Computer jargon and error messages should be omitted from all outputs.

On many computer outputs, these guidelines are ignored or overlooked;

consequently, the outputs appear cluttered and disorganized.

2. The timing of computer outputs is important. Outputs must be received by their

recipients while the information is pertinent to transactions or decisions. This can
affect how the output is designed and implemented.

3. The distribution of computer outputs must be sufficient to assist all relevant system
users.

4. The computer outputs must be acceptable to the system users who will receive
them. An output design may contain the required information and still not be
acceptable to the system user. To avoid this problem, the systems analyst must
understand how the recipient plans to use the output.

Internal Controls for Inputs and Outputs

Internal controls, a continuing theme throughout the design chapters of this book, are a
requirement in all computer-based systems. Input controls ensure that the data input to
the computer is accurate and that the system is protected against accidental and
intentional errors and abuse, including fraud. Output controls ensure the reliability and
distribution of the outputs generated by the computer. The following internal control
guidelines are offered for inputs:

Page 30 of 38
1. The number of inputs should be monitored. This is especially true with the batch
method, because source documents may be misplaced, lost, or skipped.
• In batch systems, data about each batch should be recorded on a batch control slip.
Data includes BATCH NUMBER, NUMBER OF DOCUMENTS, and CONTROL
TOTALS (e.g., total number of line items on the documents). These totals can be
compared with the output totals on a report after processing has been completed. if
the totals are not equal, the cause of the discrepancy must be determined.
• In batch systems, an alternative control would be one-for-one checks. Each source
document would be matched against the corresponding historical report detail line
that confirms that the document has been processed. This control check may only be
necessary when the batch control totals don't match.
• In on-line systems, each input transaction should be logged to a separate audit file
so it can be recovered and reprocessed in the event of a processing error or if data is
lost.

2. Care must also be taken to ensure that the data is valid. Two types of errors can
infiltrate the data: data entry errors and invalid data recorded by system users. Data
entry errors include copying errors, transpositions (typing 132 as 123), and slides
(keying 345.36as 3453.6). The following techniques are widely used to validate data:
• Completeness checks determine whether all required fields on the input have
actually been entered.
• Limit and range cheeks determine whether the input data for each field falls within
the legitimate set or range of values defined for that field. For instance, an upper -limit
range may be put on PAY RATE to ensure that no employee is paid at a higher rate.
• Combination checks determine whether a known relationship between two fields is
valid. For instance, if the VEHICLE MAKE is Pontiac, then the VEHICLE MODEL
must be one of a limited set of values that comprises cars manufactured by Pontiac
(Firebird, Grand Prix, and Bonneville to name a few).
• Self-checking digits determine data entry errors on primary keys. A cbeck digit is a
number or character that is appended to a primary key field. The check digit is
calculated by applying a formula, such as Modulus 11, to the actual key (see Figure
16.5). The check digit verifies correct data entry in one of two ways. Some data entry
devices can automatically validate data by applying the same formula to the data as
it is entered by the data entry clerk. if the cheek digit entered doesn't match the
check digit calculated, an error is displayed. Alternatively, computer programs can
also validate check digits by using readily available subroutines.
• Picture checks compare data entered against the known COBOL picture or other
language format defined for that data. For instance, the input field may have a picture
clause XX999AA (where X can be a letter or number, 9 must be a number, and A
must be a letter). The field "A4898DH" would pass the picture check, but the field
"A4891DW' would not.

Data validation requires that special edit programs be written to perform checks.
However, the input validation requirements should be designed when the inputs
themselves are designed.

Internal controls must also be specified for outputs. The following guide lines are
important output control issues:

1. The timing and volume of each output must be precisely specified. You cannot simply

Page 31 of 38
state that a report is needed daily. When daily? 8:00 AM? 10:30 AM2 2:00 P.m.?
Computer facilities have limited resources, and the systems analyst must frequently
negotiate an appropriate schedule with the computer operations staff.

2. The distribution of all outputs must be specified. For each output, the recipients of all
copies must be determined. A distribution log, which provides an audit trail for the
outputs, is frequently required.

3. Access controls are used to control accessibility of video (on-line) outputs. For
example, a password may be required to display a certain output on a CRT terminal.

4. Control totals should be incorporated into all reports. These controls can be
compared with the input controls that will be discussed later in the chapter. The
number of records input should equal the number of records output. These control
totals are compared before the outputs are distributed. If a discrepancy is found, the
outputs are retained until the cause has been determined and corrected.

Indexed sequential access method and the direct file access method.
The indexed sequential access method (ISAM) is a way of storing data records on a
physical storage device in sequential order for sequential processing (such as in payroll
applications). However, ISAM also allows any specific record to be directly accessed
without searching through the file sequentially by using the record's key field to find its
storage address in an index.

The difference between batch and on-line processing

Batch processing involves “batching” transactions together and then applying these
accumulated transactions as a group or “batch” at some later point to update a computer
system master file. On-line processing involves entering a transaction directly into the
computer and processing it immediately. With on-line processing, information in the
system is always up-to-date and current.
Real - Time

Methods of interacting with a system.

 command language: A human computer interaction method where users entered
explicit statements into a system to invoke operations.
 Menu: A human computer interaction method where a list of system options is
provided and a specific command is invoked by user selection of a menu option
 Form: A highly intuitive human-computer interaction method whereby data fields are
formatted in a manner similar to paper based forms.
 Object: A human computer interaction method where symbols are used to represent
command or functions.
 natural language: A human-computer interaction method whereby inputs to and
outputs from a computer base application are in conventional speaking language
such as English.

Page 32 of 38
Fourth-generation languages

"Fourth-generation" languages are extremely sophisticated languages which enable

end-users to perform programming tasks with little or no professional
programmer assistance or that enhance the productivity of professional
programmers. For example, very high-level programming languages, query
languages, or application generators have features that can be employed by
end-users or less skilled programmers and can dramatically increase
application development productivity.

Categories of fourth-generation tools.

The seven categories of fourth-generation tools are:

 Query languages: high-level languages for retrieving data from databases and
files which can support requests for information that are not predefined. Tend to
be on-line and interactive.
 Report generators: facilities for extracting data from files or databases to create
reports in many formats.
 Graphics languages: facilities for displaying data from files or databases in
graphic format.
 Application generators: preprogrammed modules that can generate code for
input, validation, processing, update, and reporting when users provide
specifications for an application.
 Very high level programming languages: perform coding with far fewer
instructions than conventional languages.
 Application software packages: pre-written application software that is marketed
commercially.
 Microcomputer tools: general-purpose application packages developed for
microcomputers, especially word processing, data management, graphics,
desktop publishing and spreadsheet software.

7. TESTING and DEBUGGING

7.1 TESTING
When a system is designed it is important that some consideration is given to making
sure that no mistakes have been made. A schedule should be drawn up which contains
a test for every type of input that could be made and methods of testing that the program
actually does what it was meant to do. This schedule is known as the test plan. Note
that it is produced before the system is produced.
There are a number of ways of testing a program.

1. Black box testing

Different values can be input for variables to determine whether the program can
cope with them. These values should include typical values, borderline values and
values which are not acceptable. For example, if a program is written which uses marks
out of 100 from a maths examination as input, the test data would include typical data
like 27, 73.., borderline data which would be 0 and 100, and unacceptable data like –34,
123, 16.345 This type of testing is called black box testing.

Page 33 of 38
2. White box testing is testing the program to determine whether all the possible paths
through the program produce the desired results. As a large program can have a very
large number of routes, when you take into account the different condition statements
and loops, white box testing is rarely carried out exhaustively.
Think of black box as a test where you cannot see into the box (program) all you see is
what comes out at the end. White box testing means that you are able to see what is
happening as the data goes through the box because it is transparent.

Alpha and Beta testing. When you have written a program and you sit down to test it,
you have a certain advantage because you know what to expect. After all, you wrote the
program. This can be extended to the whole software company, as the employees are all
computer-minded people. Testing carried out by people like this is known as alpha
testing. Eventually, the company will want ordinary users to test the program because
they are likely to find errors that the software specialists did not find. Testing carried out
by the users of the program is called beta testing.

Selection of test data

If a solution is to be tested, someone has to choose what data is going to be used to do
the testing. The test data is usually chosen by the programmer because they know what
they want to test. It is important to test as many different things as possible, the
important word there being ‘different’. The problem for the programmer is that they know
what inputs were expected so they find it very difficult to think of the sort of inputs that
the user of the program might try to put in.

When you are asked to think up different inputs to test a program, it must be different
types of input, not just changing numbers. Imagine a question that states that a program
has been written that will work out the mean of three numbers. You have to come up
with different test data and the reasons for doing those tests. That last bit is in bold
because that is what you get the marks for and the reasons for the tests are the things
that have to be different. In this example you would may thinking of

1, 2, 3 to test whether integers will give an integer answer

1, 2, 4 to test whether the software can cope with a recurring decimal answer
(Note that “1, 2, 4 to test a different set of integers” would not get a mark because the
reason for the test is not different)
1, 2.5, 3 to test whether the program can use decimal inputs
1, 2½, 3 to test whether fractions are allowed
-1, -2, -3 to test whether negative numbers can be handled
1, 2 to test what happens when only two values are input

There are many more that would be acceptable. The important thing to notice is that the
numbers themselves are almost identical but that the reasons for choosing them are
very different.

7.2 Debugging
Errors in computer solutions are called bugs. They create two problems. One is that the
error needs to be corrected, this is normally fairly straightforward because most errors

Page 34 of 38
are caused by silly mistakes. The second problem, however, is much more complicated,
the errors have to be found before they can be corrected. Finding where the error is and
identifying it, can be very difficult and there are a number of techniques available for
solving such problems.
1. Translator diagnostics. Each of the commands that are in the original program is
looked at separately by the translator. Each command will have a special word
which says what sort of command it is. The translator looks at the special word in
the command and then goes to its dictionary to look it up. The dictionary tells the
translator program what the rules are for that particular special word. If the word
has been typed in wrongly, the translator will not be able to find it in the dictionary
and will know that something is wrong. If the word is there, but the rules governing
how it should be used have not been followed properly, the translator will know that
there is something wrong. Either way, the translator program knows that a mistake
has been made, it knows where the mistake is and, often, it also knows what
mistake has been made. A message detailing all this can be sent to the
programmer to give hints as to what to do. These messages are called translator
diagnostics.
2. Sometimes the program looks alright to the translator, but it still doesn’t work
properly. Debugging tools are part of the software which help the user to identify
where the errors are. The techniques available include:
a. Cross-referencing. This software checks the program that has been
written and finds places where particular variables have been used. This
lets the programmer check to make sure that the same variable has not
been used twice for different things.
b. Traces. A trace is where the program is run and the values of all the
relevant variables are printed out, as are the individual instructions, as
each instruction is executed. In this way, the values can be checked to see
where they suddenly change or take on an unexpected value.
c. Variable dumps. At specified parts of the program, the values of all the
variables are displayed to enable the user to compare them with the
expected results.
3. Desk checking is sometimes known as a dry run. The user works through the
program instructions manually, keeping track of the values of the variables. Most
computer programs require a very large number of instructions to be carried out, so
it is usual to only dry run small segments of code that the programmer suspects of
harbouring an error.
4. The splitting up of a problem into smaller and smaller parts, until each part was a
manageable size as we all know is very important. When the parts were combined
they would produce a solution to the original problem. Because we are starting with
a big problem and splitting it into smaller problems, this was called top-down
design. When the program is written, each small program is written separately,
allowing the small programs to be tested thoroughly before being combined. This is
called bottom-up programming. The technique is particularly useful for testing the
finished program because it is far easier to test a lot of small programs than it is to
test one large one. One problem can arise, because the small programs have to be
joined together, these joints have to be tested too to make sure that no silly
mistakes have been made like using the same variable name for two different
things in two parts of the program (tested by cross referencing).
5. Test strategies are important to establish before the start of testing to ensure that
all the elements of a solution are tested, and that unnecessary duplication of tests

Page 35 of 38
 is avoided.

7.3 Installation - Integration

Any system needs to be tested to ensure that it works. This seems to be a fairly obvious
statement, but in reality such testing is impossible in all but the simplest of systems
because it simply is not possible to test every conceivable input to, or logical
construction in, the system. This difficulty means that testing that is to be done must be
carefully planned and that it should relate directly to the criteria referred to earlier in this
section.

When the system has been completed it has to be implemented so that it is performing
the tasks for which it was designed. Initially, this involves
 ensuring that the correct hardware is available
 arranging for staff to be trained in the use of the new system
 inputting the data to the data files, either manually or by downloading them from the
original system.
The system handover, itself can be done in a number of ways:
 Parallel running. Until the system can be considered fault free, the old and new
systems are run side by side, both doing the same processing. This allows results to
be compared to ensure that there is no problem with the new system. Such a system
is ‘safe’ and also allows staff training to be carried out, but it is obviously very
expensive because of the need to do everything twice. Parallel running is used in
situations where the data is so valuable that there must be no possibility of failure.
 Pilot running. Key parts of the new system are run alongside the old system until it
is considered that they have been fully tested. This is a compromise with the idea of
parallel running, but it does not give a clear idea of the effects on the system of the
large amounts of data that are going to be encountered in the full application.
 Big bang, or direct change. The old system is removed and the new system
replaces it completely and immediately.
 Phasing. Parts of a system are replaced while the remaining parts are covered by
the old system. This allows for some testing of the new system to be done, and for
staff training to take place, but also allows for a back-up position if the new version
does not work as anticipated.

Page 36 of 38
APPENDIX A

SSADM – Structured System Analysis and Design Methodology

Principles of SSADM
1. Data Driven
2. Logical and Physical Concepts are separated
3. Iterative Development
4. Logical to Physical Conversion in Prescriptive
5. Performance Estimation and Optimisation before Implementation
6. Active User Involvement
7. Top-down Approach
8. Regular Reviews

SSADM Input – Statement of Requirements

SSADM Output – Program Specification
File/Data Base Specifications
User and Operations Specifications

3 Analysis Stages
3 Design Stages

Techniques used in Methodology

DFDs – Data Flow Diagram(s)
LDSs – Logical Data Structure
ELHs – Entity Life Histories
Process Outlines
TNF – Third Normal Form Data Analysis
1st Cut Design Rules
Plus, Quality Assurance Review and Formal Documentations

The aims of SSADM:

 Better project structure, leading to better planning
 More effective use of inexperienced staff
 Better control and monitoring of progress resulting from task breakdown
 Closer user invlovement
 Better communication with user through documentation
 Higher quality of analysis and design leading to potential lower costs
 Demonstrably provable systems design logic

Structural framework of SSADM

SSADM consists of three phases: feasibility, (optional)
analysis and
design
Each phase is divided into stages and

Page 37 of 38
Each stage is divided into steps.
These in turn are divided into tasks.

SSADM Structure

Phase 1
Feasibility Study
Stage 01 – Problem definition
Stage 02 – Project identification

Phase 2
Systems Analysis
Stage 1 – Analysis of systems operations and current problems
Stage 2 – Specification of requirements
Stage 3 – Selection of technical options

Phase 3
System Design
Stage 4 – Data design
Stage 5 – Process design
Stage 6 – Physical design

Page 38 of 38