Definitions

A system is a set or arrangement of interdependent things or components that are related,

form a whole, and serve a common purpose.

The word system is a common one that is used to describe almost any orderly
arrangement of ideas or constructs. People speak of educational systems, Computer
systems, management systems, business systems, and of course, information systems. In
the old of all system models, a system is a process.

A common theme is systems analysis is the use of models to view and present a system.
The simplest process model of a system is base on inputs, outputs, and the system itself –
view as a process.

A process is work performed on, or in response to, incoming data flows or conditions. A
synonym is transform.

Actor: An actor is anything that needs to interact with the system to exchange
information. To the system an actor could be a customer, user, department, organization,
or another system.

Use case analysis is the process of identifying and modeling business events, who
initiated them, and how the system responds to them.

Timebox: A timebox is a nonextendable period of time, usually 60 to 120 days, by which

a candidate system must be placed into operation.

A systems analyst facilitates the study of the problems and needs of a business to
determine how the business system and information technology can best solve the
problems and accomplish improvements for the business. The product of this activity
may be improved business process, improved information systems, or new and improved
computer applications.

Problems are undesirable situations that prevent the organization from fully achieving its
purpose, goals, and/or objectives.
A Problem is (a) a situation requiring corrective action, or (b) an opportunity to improve
a situation, or (c) a directive to change a situation.

Problem solving is the act of studying a problem environment in order to implement

corrective solutions that take the form of new and improved systems. The next five
problems solving activities are collectively called a Systems Development Life Cycle
when performed by a systems analyst.

Systems Planning – the ongoing study of a business problem environment to identify

problem-solving possibilities. The purpose is to identify and prioritize those information
systems applications whose development would most benefit the business as a whole.
Systems Analysis – the study of the business problem environment and the subsequent
definition and prioritization of the requirements for solving the problem. (Note the
emphasis is on the business not the computer.)

Systems Design (System synthesis) – the evaluation of alternative problem solutions, and
the detailed specification of the final solution. Throughout design, the emphasis usually
shifts from the business to the computer solution.

Systems Implementation – the construction of the problem solution and the delivery of
that system solution into production. Computer programs are written and tested,
managers and users are trained to use the new system, and data and operations are
converted to the new system.

System Support – the ongoing maintenance and enhancement of the system solution after
it has been placed into operation. (This may be weeks, months, or years).

An information System is an arrangement of people, data, processes, interfaces, and

geography that are integrated to support and improve the day-to-day operations in a
business, as well as fulfilling the problem-solving and decision-making information
needs of business managers.

SYSTEM ANALYSIS

Introduction

Scope, Purpose and Methods of System Analysis

System Analysis is a problem-solving technique that decomposes a system into its
component pieces for the purpose of studying how well those component parts work and
interact to accomplish their purpose.

Information System Analysis is defined as those development phases in a project that

primarily focus on the business problem, independent of any technology that can or will
be used to implement a solution to that problem.

System analysis is driven by the business concerns of system owners and system users.
Hence, it addresses the DATA, PROCESS, and INTERFACE building blocks from
system owners’ and system users’ perspectives. The system analyst serves as facilitator
of systems analysis.

The documentation and deliverables produced by systems analysis tasks are typically
stored in a repository.
 A repository is a location (or set of locations) where systems analysis, systems
designers, and system builders keep the documentation associated with one or more
systems or projects.

A repository may be created for a single project or shared by all projects and systems. A
repository is normally implemented as some combination of the following:
• A network directory of word processing, spreadsheet, and other computer-
generated files that contain project correspondence, reports, and data.
• One or more CASE tool dictionary or encyclopedias.
• Printed documentation (such as that stored in binders and system libraries)
• An intranet website interface to the above components (useful for
communication)

The Business
community
Preliminary
Investigation

Problem
Operation and Analysis
Support

Requirement
Implementation Analysis

Decision
Construction Analysis

Design

Purpose
System analysis is done in order to perform system design. A gain is to bridge the gap
between those who need computer-base business solution and those who understand
information technology.

Methods
The following are methods of system analysis:
 • Requirement Discovery Methods
• Business Process Redesign Methods

Both model-driven and accelerated system analysis approaches attempt to express user
requirements for a new system, either as models or prototypes. The requirements for a
system are dependent on the analysts’ ability to discover the problems and opportunities
that exist in the current system: thus, analysts most become skilled to identifying
problems, opportunities, and requirements. Consequently, all approaches to systems
analysis require some form of requirements discovery.

Requirements discovery
This includes those techniques to be used by systems analysts to identify or extract
system problems and solution requirements from the user community.

The following are discovery approaches:

• Fact-Finding
• Joint requirement planning

Fact-Finding Techniques – Fact-finding techniques are an essential skill for all systems
analysts.

Fact-finding (or information gathering) is a classical set of techniques used to collect

information about system problems, opportunities, solution requirements, and priorities.

Fact-finding Techniques
• Sampling of existing documentation, reports, forms, files, databases and memos.
• Research of relevant literature, benchmarking others’ solutions, and site visits.
• Observation of the current system in action and the work environment.
• Questionnaires and surveys of the management and user community.
• Interviews of appropriate managers, users, and technical staff.

Joint Requirements Planning

The classic fact-finding techniques listed above are invaluable; however, they can be
time-consuming in their classic forms. Alternatively, requirements discovery and
management can be significantly accelerated using joint requirement planning.

Joint requirements planning (JRP) techniques use facilitated workshops to bring together
all the system owners, system users, systems analysis, and some systems designer and
builders to jointly perform systems analysis, JRP is generally considered a part of joint
application development (or JAD), a more comprehensive application of the techniques
to the entire system development process.

A JRP-trained or –certified analyst usually plays the role of facilitator for a workshop
that will typically run from three to five full working days.

Business Process Redesign (or BPR-also called business process reengineering)

Is the application of systems analysis methods to the goal of dramatically changing and
improving the fundamental business processes of an organization, independent of
information technology.

The interest is BPR was driven by the discovery that most current information systems
and applications merely automated existing and inefficient business processes.
Automated bureaucracy, automation does not necessarily contribute value to the business
and it may actually subtract value from the business.

Some BPR projects focus on all business processes, regardless of their automation. Each
business process is thoroughly studied and analysed for bottleneck, value returned, and
opportunities for elimination or streamlining. Once the business processes have been
redesigned, most BPR projects conclude by examining how information technology
might best be applied to the improved business processes. This may create new
information system and application development projects to implement or support the
new business processes.

BPR is also applied within the context of information system development projects. It is
not uncommon for project to include a study of existing business processes to identify
problems, bureaucracy, and inefficiencies that may be addressed in requirements for new
and improved information systems and computer applications.

FAST (Framwork for the Application of System Technology) Systems Analysis Strategies
Like most commercial methodologies, our hypothetical FAST methodology does not
impose a single approach on system analysts. Instead, it integrates all the popular
approaches. SoundStage case study will demonstrate these methods in the context of a
typical first assignment for a system analyst. The systems analysis techniques will be
applied within the framework of:
• Your information system building block.
• The FAST phases
• FAST tasks that implement a phase.

A system Analyst studies the problems and needs of an organization in determine how
people, data, processes, communications, and information technology can best
accomplish improvements for the business.

The system analyst is basically a problem solver. The term problem will be used to
describe many situations including:
o True problem situation, either real or anticipated, that require corrective action.
o Opportunities to improve a situation despite the absence of complaint.
o Directives to change a situation regardless of whether anyone has complained.

Functions of System Analyst

The main jobs of the analyst are:
- Identify the problem
- Analyze and understand the problem
- Identify the solution requirements
- Identify alternative solutions
- Design and implement the best solution
- Evaluate the result
• To examine the feasibility of potential computer applications.
• Analysis existing systems with a view to improve their computerization.
• Design of computer-based systems, their implementation and review.
Note that, it is very likely that systems analysts would work in project teams with a
senior analyst in charge.

Project team
Business analyst:
• Analyzing the key business aspects of the system
• Identifying how the system will provide business value
• Designing the new business processes and policies
Systems analyst:
• Identifying how technology can improve business processes
• Designing the new business processes
• Designing the information system
• Ensuring that the system conforms to information systems standards
Infrastructure analyst:
• Ensuring the system conforms to infrastructure standards
• Identifying infrastructure changes needed to support the system
• Change management analyst Developing and executing a change management
plan.
• Developing and executing a user training plan
Project manager:
• Managing the team of analysts, programmers, technical writers, and other
specialists
• Developing and monitoring the project plan
• Assigning resources
• Serving as the primary point of contact for the project

The key person in the System Development Life Cycle (SDLC) is the systems
analyst who analyzes the business situation, identifies opportunities for
improvements, and designs an information system to implement them. Being a
systems analyst is one of the most interesting, exciting, and challenging jobs
around. As a systems analyst,
• you will work with a variety of people and learn how they conduct
business. Specifically, you will work with a team of systems analysts,
programmers, and others on a common mission.
You will feel the satisfaction of seeing systems that you designed and developed
make a significant business impact, while knowing that your unique skills helped
make that happen.
 • It is important to remember that the primary objective of the systems
analyst
is not to create a wonderful system. The primary goal is to create value for the
organization, which for most companies means increasing profits (government
agencies and not-for-profit organizations measure value differently). Many failed
systems were abandoned because the analysts tried to build a wonderful system
without clearly understanding how the system would support the organization’s
goals, current business processes, and other information systems to provide value.
An investment in an information system is like any other investment, such as a
new machine tool. The goal is not to acquire the tool, because the tool is simply a
means to an end; the goal is to enable the organization to perform work better so it
can earn greater profits or serve its constituents more effectively.

Various stages of the System Life Cycles

The systems development life cycle (SDLC) is the process of understanding how
an information system (IS) can support business needs, designing the system,
building it, and delivering it to users. If you have taken a programming class or
have programmed on your own, this probably sounds pretty simple.

In many ways, building an information system is similar to building a house. First,

the house (or the information system) starts with a basic idea. Second, this idea is
transformed into a simple drawing that is shown to the customer and refined (often
through several drawings, each improving on the other) until the customer agrees
that the picture depicts what he or she wants. Third, a set of blueprints is designed
that presents much more detailed information about the house (e.g., the type of
water faucets, where the telephone jacks will be placed). Finally, the house is built
following the blueprints—and often with some changes and decisions made by the
customer as the house is erected.
The SDLC has a similar set of four fundamental phases: planning, analysis,
design, and implementation (Figure 1-2). Different projects may emphasize
different parts of the SDLC or approach the SDLC phases in different ways, but
all projects have elements of these four phases. Each phase is itself composed of a
series of steps, which rely on techniques that produce deliverables (specific
documents and files that provide understanding about the project).

For example, when you apply for admission to a university, there are several
phases that all students go through: information gathering, applying, and
accepting.

Each of these phases has steps: information gathering includes steps like searching
for schools, requesting information, and reading brochures. Students then use
techniques (e.g., Internet searching) that can be applied to steps (e.g., requesting
information) to create deliverables (e.g., evaluations of different aspects of
universities).

In this section, we describe at a very high level the phases, steps, and some
of the techniques that are used to accomplish the steps. We should emphasize that,
in practice, an organization may follow one of many variations on the overall
SDLC. For now, there are two important points to understand about the SDLC.

First, you should get a general sense of the phases and steps that IS projects move
through and some of the techniques that produce certain deliverables.

Second, it is important to understand that the SDLC is a process of gradual

refinement. The deliverables produced in the analysis phase provide a general idea
of the shape of the new system. These deliverables are used as input to the design
phase, which then refines them to produce a set of deliverables that describes in
much more detailed terms exactly how the system will be built. These deliverables
in turn are used in the implementation phase to produce the actual system. Each
phase refines and elaborates on the work done previously.

Planning
The planning phase is the fundamental process of understanding why an
information system should be built and determining how the project team will go
about building it. It has two steps:

1. During project initiation, the system’s business value to the organization is

identified—how will it lower costs or increase revenues? Most ideas for new
systems come from outside the IS area (from the marketing department,
accounting department, etc.) in the form of a system request. A system request
presents a brief summary of a business need, and it explains how a system that
supports the need will create business value.
Preliminary survey or study. The purpose of this survey is to establish whether
there is a need for a new system and if so to specify the objectives of the system.
The IS department works together with the person or department that generated
the request (called the project sponsor) to conduct a feasibility analysis.
The feasibility analysis examines key
aspects of the proposed project:
_ The technical feasibility (Can we build it?)
_ The economic feasibility (Will it provide business value?)
_ The organizational feasibility (If we build it, will it be used?)
The system request and feasibility analysis are presented to an information
systems approval committee (sometimes called a steering committee), which
decides whether the project should be undertaken.
Investigation and fact recording. At this stage in the life cycle a detailed study is
conducted. The study is far more detailed and comprehensive than the feasibility
study. The purpose of this study is fully to understand the existing system and to
identify the basic information requirements. This requires a contribution from the
users both of the existing systems and of the proposed system.

2. Once the project is approved, it enters project management. During project

management, the project manager creates a work plan, staffs the projects, and puts
techniques in place to help the project team control and direct the project
through the entire SDLC. The deliverable for project management is a project
plan that describes how the project team will go about developing the system.

Analysis
The analysis phase answers the questions of who will use the system, what the
system will do, and where and when it will be used. During this phase,
the project team investigates any current system(s), identifies improvement
opportunities, and develops a concept for the new system. This phase has three
steps:
1. An analysis strategy is developed to guide the project team’s efforts. Such a
strategy usually includes an analysis of the current system (called the as-is system)
and its problems, and then ways to design a new system (called the to-be system).

2. The next step is requirements gathering (e.g., through interviews or

questionnaires). The analysis of this information—in conjunction with input from
the project sponsor and many other people—leads to the development of a concept
for a new system. The system concept is then used as a basis to develop a set of
business analysis models that describes how the business will operate if the new
system were developed. The set of models typically includes models that represent
the data and processes necessary to support the underlying business process.

3. The analyses, system concept, and models are combined into a document called
the system proposal, which is presented to the project sponsor and other key
decision makers (e.g., members of the approval committee) that decide whether
the project should continue to move forward.

The system proposal is the initial deliverable that describes what business
requirements the new system should meet. Because it is really the first step in the
design of the new system, some experts argue that it is inappropriate to use the
term analysis as the name for this phase; some argue a better name would be
analysis and initial design. Because most organizations continue to use the name
analysis for this phase, we will use it in this book as well. It is important to
remember, however, that the deliverable from the analysis phase is both an
analysis and a high-level initial design for the new system.

Design
The design phase decides how the system will operate, in terms of the hardware,
software, and network infrastructure; the user interface, forms, and reports that
will be used; and the specific programs, databases, and files that will be needed.
Although most of the strategic decisions about the system were made in the
development of the system concept during the analysis phase, the steps in the
design phase determine exactly how the system will operate. The design phase has
four steps:
1. The design strategy must be developed. This clarifies whether the system will
be developed by the company’s own programmers, whether it will be outsourced
to another firm (usually a consulting firm), or whether the company will buy an
existing software package.

2. This leads to the development of the basic architecture design for the system
that describes the hardware, software, and network infrastructure that will be
used. In most cases, the system will add or change the infrastructure that already
exists in the organization. The interface design specifies how the users will move
through the system (e.g., navigation methods such as menus and on-screen
buttons) and the forms and reports that the system will use.

3. The database and file specifications are developed. These define exactly what
data will be stored and where they will be stored.

4. The analyst team develops the program design, which defines the programs that
need to be written and exactly what each program will do. This collection of
deliverables (architecture design, interface design, database and file specifications,
and program design) is the system specification that is handed to the programming
team for implementation. At the end of the design phase, the feasibility analysis
and project plan are reexamined and revised, and another decision is made by the
project sponsor and approval committee about whether to terminate the project or
continue.

Implementation
The final phase in the SDLC is the implementation phase, during which the system
is actually built (or purchased, in the case of a packaged software design). This is
the phase that usually gets the most attention, because for most systems it is the
longest and most expensive single part of the development process. This phase has
three steps:

1. System construction is the first step. The system is built and tested to ensure it
performs as designed. Since the cost of bugs can be immense, testing is one of
the most critical steps in implementation. Most organizations spend more time
and attention on testing than on writing the programs in the first place.

2. The system is installed. Installation is the process by which the old system is
turned off and the new one is turned on. It may include a direct cutover approach
(in which the new system immediately replaces the old system), a parallel
conversion approach (in which both the old and new systems are operated for a
month or two until it is clear that there are no bugs in the new system), or a
phased conversion strategy (in which the new system is installed in one part of
the organization as an initial trial and then gradually installed in others). One of
the most important aspects of conversion is the development of a training plan
to teach users how to use the new system and help manage the changes caused
by the new system.

3. The analyst team establishes a support plan for the system. This plan usually
includes a formal or informal post-implementation review, as well as a systematic
way for identifying major and minor changes needed for the system.

Investigation and Analysis

Methods of Collecting data
• Interview
• Questionnaire
• Direct observation and
• Examination of existing documents, etc.

Interview
Direct observation
Observation is a fact-finding technique wherein the systems analyst either
participates in or watches a person perform activities to learn about the system.

This technique is often used when the validity of data collected through other
methods is in question or when the complexity of certain aspects of the system
prevents a clear explanation by the end-users.

Advantages
o Data gathered by observation can be highly reliable. Sometimes
observations are conducted to check the validity of data obtained directly
from individuals.
 o The systems analyst is able to see exactly what is being done. Complex
tasks systems analyst can identify tasks that have been missed or
inaccurately describing physical environment of the task (e.g, physical
layout, traffic, lighting, noise level).
o Observation is relatively inexpensive compared with other fact-finding
techniques. Other techniques usually require substantially more employee
release time and copying expenses.
o Observation allows the systems analyst to do work measurements.

Disadvantages
o Because people usually feel uncomfortable when being watched, they may
unwittingly perform differently when bring observed. The famous
Hawthorne experiment proved that the act of observation can alter
behaviour.
o Some systems activities may take place at odd times, causing a scheduling
inconvenience for the systems analyst.
o The tasks being observed are subject to various types of interruptions.
o Some tasks may not always be performed in the manner in which they are
observed by the systems analyst.
o If people have been performing tasks in a manner that violates standard
operating procedures, they may temporarily perform their jobs correctly
while you are observing them. In other words, people may let you see what
they want you to see.

Examination of existing documents

The first document the analysis should seek out is the organization chart. Next, the
analyst may want to trace the history that led to the project. To accomplish this,
the analyst may want to collect and review documents that describe the problem.
These include:
o Interoffice memoranda, studies, minutes, suggestion box notes, customer
complaints, and reports that document the problem area.
o Accounting records, performance reviews, work measurement reviews, and
other scheduled operating reports.
o Information systems project requests-past and present.

In addition to documents that describe the problem, there are usually documents
that describe the business function being studies or design. These documents may
include:
o The company’s mission statement and strategic plan.
o Formal objectives for the organization subunits being studied.
o Policy manuals that may place constraints on any proposed system.
 o Standard operating procedures (SOPs), job outlines, or task instructions for
specific day-to-day operations.
o Completed forms that represent actual transactions at various points in the
processing cycle.
o Samples of manual and computerized database.
o Samples of manual and computerized screen and reports.

Also, don’t forget to check for documentation of previous system studies and
designs performed by systems analysts and consultants. This documentation may
include:
o Various types of flowcharts and diagrams.
o Project dictionaries or repositories.
o Design documentation, such as inputs, outputs, and databases.
o Program documentation.
o Computer operations manual and training manuals.

All documentation collected should be analysed to determine the information’s

currency. Don’t discard outdated documentation.

The need for Identifying Problems/Flaws

Problems are identified to:
• Improve performance
• Improve information (and data)
• Improve economics, control costs, or increase profits.
• Improve control of security
• Improve efficiency of people and processes
• Improve service to customers, suppliers, partners, employees, etc.

The need for specifying the required hardware and software for developing a
new system
The designers’ intent is to prepare software and hardware specification that:
• Fulfill the business process requirements of system users and
• Provide sufficient detail and consistency for communicating the software
design to system builders.
• Identify the hardware capacities the can support the system.

The need for identifying the user and information requirements necessary to
resolve the identified problem
• Is to identify the data, process and interface requirement for the new
system. The purpose is to specify these requirements without prematurely
 expressing computer alternatives and technology details; at this point, keep
analysis at the business level!
• Is to find out what user need or want out of the new system, so as to design
to meet the requirement of the user.
• To identify deliverable for a business requirements statement. This could be
a very small or very large document depending on the methodology or
system complexity.
• The team collects information from the system user and discusses
requirement and priorities.

System Modelling
Different modeling tools in system analysis
 Decision table
 Data flow diagram
 Decision tree

Decision table
A decision table is a tabular form of presentation that specifies a set of conditions and
their corresponding action. Decision tables are very useful for specifying complex
policies and decision-making rules.

The below figure illustrates the three components of a simple decision table.
 Condition stubs (the upper rows) describe the conditions or factors that will affect
the decision or policy.
 Action subs (the lower rows) describe, in the form of statements, the possible
policy actions or decisions.
 Rules (the columns) describes which actions are to be taken under a specific
combination of conditions.

Conditions and Actions Rule 1 Rule 2 Rule 3 Rule 4

C1: Type of check personal payroll personal payroll
Condition C2: Check amount less then equal yes Doesn’t no Doesn’t
stubs to $ 78.00 matter matter
C3: Company accredited by Doesn’t yes Doesn’t no
LMART matter matter
Action
stubs
 A1: Cash the check x x
A2: Don’t cash the check x x

Rule
A sample of decision table

Data flow Diagram (DFD)

Is a tool that depicts the flow of data through a system and the work or processing
performed by that system. Synonyms include bubble chart, transformation graph, and
process model.

The DFD for any nontrivial product is likely to be large. The DFD is a pictorial
representation of all aspects of the logical data flow and, as such, guaranteed to contain
considerably more than 7+ 2 elements. For this reason, the DFD must be developed by
stepwise refinement.

The symbols

Double
square Source or destination of data

arrow Flow of data

Rounded
Process that transforms a flow of data
rectangle

Open-Ended Store of data

Rectangle
The data flow diagram for Kwame’s software shop

Package_Data

Package_detail
s
Process-
Customer
orders

Credit_status

Customer_Data
 First refinement

Steps to consider (How to perform structured system analysis)

1. Draw the DFD
2. Decide what sections to computerize and how (Batch or Online)
3. Determine the Details of the Data Flows
4. Define the Logic of the Processes
5. Define the Data stores
6. Define the physical resources
7. Determine the input-output specification
8. Determine the sizing
9. Determine the hardware requirements.

Data immediate access

The issue of data immediate access depends on what queries are going to be put to the
product. When order is make online, there is a need to include name, function and
machine.

A Decision Tree
A decision tree makes it easy to check that all possibilities have been taken into account,
especially in more complex cases. An example is show below. From the example it is
immediately obvious that the cost to an alumnus of a seat behind the end zone has not
been specified.

Determine football seat prices

40-yard line: $20

Faculty: End zone: $ 12
Undergraduate: $2
40-yard line: $40
Alumnus:
Sample of decision tree

The need for recording information about the current system

• To know the problem of the current system
• To enable analysts estimate the costs of developing the expected system.
• It will help the analysts for better understanding of the problems of the current
system.
• To enhance alternate solutions of their input/output methods, data storage
methods, computer hardware and software requirements, processing methods,
and people implications.

Justify the need for a new system

There will be the need for a new system if the current system does not measure the
following:
• If the current system performance does not provide adequate throughput and
response time.
• If the information from the current system does not provide end-users and
managers with timely, pertinent, accurate, and usefully formatted information.
• If the system does not offer adequate service level and capacity to reduce the cost
of the business or increase the profits of the business.
• If the system does not offer adequate controls to protect against fraud and
embezzlement and to guarantee the accuracy and security of data and information.
• If the system does not make maximum use of available resources including
people, time flow of forms, minimum processing delays, and the like.
• If the system does not provide desirable and reliable service to those who need it.
Again, when is not flexible and expandable.
Note: Each event process should be described to the CASE repository with the following
properties:
• Event sentence – for business perspective.
• Throughput requirement – the volume of the inputs per some time period.
• Response time requirement – how fast the typical event must be handled.
• Security, audit, and control requirements.
• Archival requirements (from a business perspective)

The criteria/qualities of an efficient and effective system (quality assurance)

Data and process models represent different views of the system. But these views are
interrelated. Modelers need to synchronize the different views to ensure consistency and
completeness of the total system specification.

The linkage between data and process models is almost universally accepted by all major
methodologies. In short, there should be one data store in the process models for each
entity in the data model. Some methodologies exempt associative entities from this
requirement, but we believe it is simpler (and more consistent) to apply the rule to all
entities on the data model.

Data-to-process-CRUD (create, read, update, delete) matrix. The decision to include or

not inclined attributes is based on whether processes need to be restricted as to which
attributes they can access.

The synchronization quality check is stated as follows:

Every entity should have all least one C, one R, one U, and one D entry for system
completeness. If not, one or more event processes were probably omitted from the
process models. More importantly, users and management should validate that all
possible creates, reads, updates, and deletes have been included.
Any error omissions should be recorded both on the matrix and in the corresponding data
and process models to ensure proper synchronization.
Process models illustrate the essential work to be performed by the system as a whole.
But process must be distributed to locations where work is to be performed. Some work
may be unique to one location. Other work may be performed at multiple locations.
Before we design the information system, we should identity and document what
processes must be performed at which locations. Before we design the information
system, we should identify and document what processes must be performed at which
locations. This can be accomplished through a process-to-location-association matrix.

A process-to-location-association matrix is a table in which the rows indicate processes

(event or elementary processes); the columns indicate locations; and the cells document
which processes must be performed at which locations.

Criteria for Design

Purpose. The purpose must be to meet the demands of the requirements specification and
for that matter, the objectives that were agreed at the beginning of the project. At one
time, and still in some organizations, a requirements specification was not produced at
the end of the analysis stage and so the system specification had to serve both purpose.

Economical. The cost and benefits of the new system should be compared with those of
the existing system. This is not easy to do because of the difficulty of quantifying benefits
such as “better” or “more” information. It is important, however, that the attempt be
made.

Work flows. The best work flows must be attained. This includes methods of
transmitting data to and from the computer, the number of stages in processing, file ( or
database) organization, the requirements of internal check, and the link with clerical
procedures.

Specialisation, simplification and standardization. The benefits to be derived from the

practice of the “three Ss” are well known. The analyst will have them in mind throughout
the design stage.

Flexibility. Points to be considered here are:

• Integration of procedures. System should be designed with possible integration of
procedures in mind. This is particularly important as the centralized nature of
computer processing makes possible the integration of many procedures carried
out independently under conventional methods.
• Modularity of hardware. It is important when choosing the hardware to ensure
that it is capable of being expanded (units added) when the need arises.
• Peak periods/treatment of exceptions. The system can be designed to cope with
peak-period processing; an alternative arrangement is to use a third party’s
facilities for the unusually high loads. Similarly, exceptional items (i.e those not
recurring frequently) could be designed into the system, but it may be more
convenient to have them dealt with separately by conventional methods.
Exception principle. The principle of exception should be incorporated in the design of
the new system, so that only deviations from plan are reported for management’s
attention. In a stock-control system, for example, warnings would be given of slow-
moving stocks. The analyst must ensure that only necessary output is produced.

Reliability. The reliability of all the hardware and software must be considered. The
analyst must ensure the facilities require for the new system have a proven record of
reliability. Maintenance requirements, the excepted life of the hardware and the back-up
facilities (in case of breakdown) must be considered.

Forms. Where possible, data should be presented to the computer in a machine-sensible

form. The analyst must consider all the methods of input and try to reduce the steps
necessary between origination of data and its input. If output from one run is used as the
input to another, the ideal medium for the subsequent input should be used. When output
is required in a humanly legible form, choice of method of presentation is important.
Methods available are visual display, printed copy, graphical, etc. and the needs of the
person receiving the output will determine which one is appropriate.

Exiting system. Consideration must be given to the existing staff, procedures,

equipment, forms, etc, in the design of any new system. For example, if old-fashioned
equipment is currently being operated, the procedures already exist for transferring the
source data into a machine-sensible form, although it may well not be incorporated into
the design of a new computer system.

Continuous control. As the majority of steps are carried out automatically, there is an
even greater need for the care in internal check. Audit trails (i.e documentary records of
various state in processing that can be used to check that procedures have been carried
out correctly) must be laid to the satisfaction of the auditors. Controls should be
incorporated.

Time. The analyst must design the system to satisfy time requirements. Speeds of
equipment, modes of access and processing methods must be considered. The length of
the processing cycle is a most important consideration. The presentation of source data to
the computer and the production of output document will be subject to strict time
constraints.

SYSTEM DESIGN
Introduction
Purpose and Principles of various design methods
• SSADM
• Prototyping
• Object oriented
Prototyping
There are three activities which are sometimes described as prototyping:
• Mock-ups. A “mock-up” of a proposed system or subsystem is produced
for demonstration purposes at the early stages of a project so as to aid the
users and designers to make decisions about what is required. Usually, the
prototype has the appearance of the final system but lacks any real
processing or storage capabilities.
• Trial prototyping: A simplified working model of the proposed system or
subsystem is produced. It may serve the same purpose as a mock-up but
because it has some of the capabilities of a real system it can provide the
opportunity to try out ideas and to investigate user interface for a new
system.

A prototype is a smaller-scale, representative or working model of the users’

requirements or a proposed design for an information system.

The basic principle behind prototyping is that users know what they want when
they see it working. In RAD, a prototype eventually evolves into the final
information system.

• Rapid application development (RAD), A simplified version of the system

is built and then reviewed. At this early stage this is like trail prototyping.
Following the review the prototype is extended and upgraded to become
version 1 of the new system. It is normally incomplete at this stage but may
have all of the essential features in a simplified form. After a review the
prototype is further upgraded, and so on. The rapid results provided by this
method give rise to its name.

Rapid application development (RAD) techniques emphasize extensive user

involvement in the rapid and evolutionary construction of working prototypes of a
system to accelerate the system development process. RAD is sometimes called a
spiral approach because you repeatedly spiral through the phases to construct a
system in various degrees of completeness and complexity.

Object oriented programming (OOP) –(Object oriented design –(OOD))

Is control Oriented or Process Oriented in that they create program level structures
based primarily upon processing corresponds such as functions and procedures.
For example, the object “rectangle” might be identified as one on which
operations might be performed. The operations to be performed on a rectangle
might include “create”, “remove”, “get_length”, get_breadth” “get_area”. This
suggests that at the heart of any object is data representing its current state. The
operation belong to the object whereas in a process oriented program that data
may be thought of as belonging to the procedures or functions. Individual objects
are created and combined into a complete program.

Object-oriented analysis and design (OOAD) attempts to merge the data and
process concerns into singular constructs called objects. Object-oriented analysis
and design introduced object diagrams that document a system in terms of its
objects and their interactions.

Business objects might correspond to real things of importance in the business

such as customers and the orders they place for products. Each object consists of
both the data that describes the object and the processes that can create, read,
update, and delete that object.

Design and Specification

Objectives and limitations/constraints of the new system

The system outline

• Output
• Input
• Files and processes
• Systems
• Flowcharts
• Computer run charts
• Procedure flowcharts
• Modes of operation

Output
It is necessary to consider what required from the system before deciding how to set
about producing it. These requirements will have become clear as the project progressed.
The analyst will need to consider form, types, volumes, and frequency of reports and
documents. Choice of output media will also have to be made including when to use hard
copy and when to use screen displays.

Input
Consideration of input will be influenced greatly by the needs of output, eg. The
necessity for quick response from the system would determine the need for an online type
of input. Consideration would be given to:
 Data collection methods and validation
 Types of input media available
 Volume of input documents.
  Design of input layouts.

Files and processes

The elements are very much linked to input and output. Input is processed against the
stored data to produce the necessary output. Considerations involved in designing files
are:
 Storage media
 Method of file (database) organization and access
 File (database) security
 Record (table) layout

Systems
The word system is a common one that is used to describe almost any orderly
arrangement of ideas or constructs. People speak of educational systems, Computer
systems, management systems, business systems, and of course, information systems. In
the old of all system models, a system is a process.

Flowcharts
Flowcharts were originally introduced as aids to systematic process of analyzing
problems and developing suitable computer-based solutions. In recent years flowcharts
have been heavily criticized as being cumbersome and inefficient tools for the job.

Used as the first or last symbol in a program or separately drawn

program module.

The terminal symbol

Used to present any kind of processing activity. Add number to
sub total, calculate profit, etc.

The process symbol

Used to present a process which has been set out in detail
elsewhere eg. Soft marks ie. Place marks into numerical order .

A pre-defined process symbol

Used where a decision has to be made in selecting the subsequent

path to be followed. E.g Is number even? No, Yes

Decision symbol
Used where data input or output is to be performed eg. In name

The input/output symbol

Used to show the flow/path of a sequence of symbols. Vertical
lines without arrow heads are assumed to flow to bottom.
Horizontal lines without arrow heads are assumed to flow left to
right.
 Used to add explanatory notes or descriptions.

Start

Is
Number of hour
work of greater than
8
?

Let cost be
Let cost be ( x 8.5)
Hours x 8.5 ((Hours - 8) x 17)

Exit

Detailed Flowchart

Modes of operation
o Batch mode -- process a batch of inputs/outputs together; sometimes most
appropriate solution
e.g., incoming mail (purchase orders), outgoing mail (invoices, cheques)
o On-line mode -- process inputs/outputs as they become available; can save data
entry time, particularly if end user can do the input, clearly the way of the future,
because on-line data entry can be done on PCs
o Remote batch -- data are input on-line on several machines, then fed in a batch
mode to a centralized database.

Output requirement
• Format
• Volume
 • Peak loading
• Special stationery and
• Media

Format

Input requirement
• Data capture method
• Input specification
• Forms design and screen layout
• The user dialogue
• Coding method
• Error control

Data capture method

• How will the data be collected?
The data is “captured” at source in a machine –sensible form. For example, pre-recoded,
pre-printed data on some suitable medium attached goods may be read or collected as the
goods are sold. This application is know a PoS (Point of sale) data capture.

Input specification
The two main considerations here are the definitions of:
o The data items to be input, their data types, what values it is valid for them to take
and what actions are to be taken if an attempt is made by a user to enter invalid
data.
o The formats in which input data values are to be entered. For example, the layout
of screens may need specifying along with a description of how a dialogue with
the user should take place.

Forms design and screen layout

• How is data entered into the computer?
For data input (or output) may be specified on special forms called screen layout charts,
which consist of boxes set out in a grid in rows and columns that correspond to character
positions on the screen. They are similar to print layout charts, which will be described
shortly.

Design Validation Routines

• Check input data is sensible and valid before processing.

Range Check
• Within a pre-determined range.
 e.g.
 o The month of a person's DOB should lie between 1 and 12.
o A telephone bill amount is less than some maximum value for
consumer bills.
Presence Check
• This checks that important data is actually there and has not been missed out.
o E.g. Customers may be required to give their telephone numbers or surname.

Existency
• A code exists.
 E.g.
o Bar code exists in the stock file.
o Dates actually exist e.g. 31/04/07 or 29/02/07 do not exist
but are in the correct format
Length Check
• Has the correct number of characters.
E.g.
o A bank account number may always
be 10 digits long.
o A date must have at least 6 numbers
in it.
o A phone number has 12 numbers.
Character check
• Check for / Reject particular characters.
E.g.
o No numbers in text.
o Hyphen or apostrophe
Type / Format Check
• A check that data is of the right type.
E.g.
o Number, Text etc…
o For currency data - digits point digit
digit
Batch Totals
• This checks for missing records.
• Numerical fields may be added together for all
records in a batch.
• The batch total is entered and the computer checks
that the total is correct.
E.g. Add the 'Total Cost' field of a number
of transactions together.
Hash Totals
• Some sort of meaningless arithmetic performed on a
field.
 E.g. Add the Telephone Numbers together
for a number of Customers.