Sad

1
 Chapter 3: The system development life cycle

3.1. The traditional system development life cycle

The goal of the traditional system life cycle is to keep the project under control and
assure that the information system produced satisfies the requirements. The
traditional system life cycle divides the project into a series of steps, each of which
has distinct deliverables. There are different phases included under the traditional
SDLC. However, you may find slight differences with regard to the phases
provided by various scholars. The following phases are among the provided
components by Yeates and Wakefield, 2004.a

 Project initiation
 Feasibility study
 Investigation
 Requirements definition
 Proposals and selection
 Design
 Development
 Testing
 Implementation
 Audit review
 Maintenance

The traditional approach does not mandate the involvement of the system’s users
to any great degree. Users only have to be involved when they are presented with

2
the system specification to review and approve. The most obvious advantage of the
traditional approach is, of course, that it is quite familiar to analysts and that the
general methods of working are well understood.

3.2. Approaches to system analysis and design

There are different type information systems development methods. The

commonly used basic approaches are prototype and system development life cycle
approach (SDLC). They are briefly described below.

System development Life cycle (SDLC)

The development of information system is a complex process; usually involving

many people within a variety of special skills. The process is traditionally broken
down into stages or phases that deliver several intermediate outputs on the way to
the final system. These stages together are known as the System Development
Life Cycle (SDLC).

Prototype Approach

It is not always possible to obtain all the information analysts need to create a
complete logical model just by conducting interviews with the concerned body and
study the existing system. Some processes by their nature are difficult to explain.
In such cases, prototyping is a powerful alternative or supplement to logical
modeling.

Prototype is the process of building an experimental system rapidly and

inexpensively for end user. Prototyping is a technique for quickly building and

3
functioning system, but it is incomplete model of the information system using
rapid application development tools. Prototypes typically evolve in to the final
version of the system or application. The concept behind prototyping is building a
small working mode of the users’ requirements or a proposed design for an
information system, which is usually applied earlier in the systems development
life cycle to perform fact-finding and information requirement analysis.

The prototyping process

Preliminary Build or refine Test

Problem
definition analysis prototype prototype

Yes No Yes
Acceptable Ready Release

No
Define
requirement
s

Design

System

Develop
system

3.3. Systems Development Approaches

4
When organizations develop their new information system or modify the existing
information system, they have to follow the following basic approaches. These
approaches are not mutually exclusive and firms generally employ certain aspects
of each approach.

Ad hoc Approach: This approach is directed towards solving particular problem

or the potential for integrating applications. In this approach, the analyst does not
deal with the overall information requirements of the firm, instead it pinpoint only
the trouble spots. The major advantage of ad-hoc approach is that it is important in
certain emergencies and in organizations undergoing rapid changes.

However, this approach is not without a limitation. It is inconsistent with the

concept of planning an information system. Moreover, it could result in redundant
and inefficient subsystems and database that cannot be integrated or linked each
other.

Data Modeling Approach: Data modeling attempts to develop a common data

base model. The data base should contain all the necessary information to support
the operation of the firm, but it should reduce redundancy. Of course, the approach
does not require that all data be stored in one unit, but physical data base can be
stored in several places, but it should be planned to integrate the data bases. The
emphasis of this approach is on establishing linkages within the data base that
allows common data, common retrieval and common manipulation.

5
Bottom-up approach: Bottom-up approach focuses on the basic transaction
processing requirements of the firm and implements systems to meet these needs
or requirements. The approach tries to identify the basic transaction of the
organizations, such as payroll, order entry and processing. This approach is
important because as management information requirement becomes more
complex, it integrates the stand-alone TPS and to deal with DSS and ESS. It is a
dominating system development strategy because the system development can be
made in a logical revolutionary or step-by-step manner.

Top-down approach: This approach attempts to align information system with

business strategies and to involve top management in the information development
process. It focuses on strategies of the firm, data and information and activities
necessary to implement the strategy of an organization. This approach is not a
step-by-step process. Top management have its strategy to develop IS by
analyzing the whole company problem unlike bottom-up approach which is a step-
by-step process.

The philosophy underlying the information system development in a certain

organization could be either of the above or a combination of them. Regardless of
the underlying philosophy the actual analysis and design of an information system
could be undertaken in either of the following two ways: Prototype approach or
systems development life cycle.

3.4. Software engineering process

Software engineering is an engineering discipline, which is concerned with all

aspects of software production.

6
Generic activities in all software processes are:

o Specification: what the system should do and its development

constraints
o Development: production of the software system
o Validation: checking that the software is what the customer wants
o Evolution: changing the software in response to changing demands

7
 Chapter 4: system selection and planning

For any systems development project, effective project planning is necessary to

ensure that the project meets the deadline, is developed within an acceptable
budget, and fulfills end user expectations and specifications.

In general, systems project is a decision made by managers to commit resources to

transform their organization’s operations from manual or preemptive computer
based system to a more efficient and effective computer based information system.

Before the actual project process is undertaken:

 The need for such project must be identified:

 The project must be defined as a solution to the current information systems
problem and:
 It must be tested for feasibility within the constraints imposed upon the
project.

1.1. Identifying and selecting projects

The basic question pertaining to project selection is “where do system projects

originate?” Projects originate or initiated by a large group of stakeholders to the
firm. Some of these are:

1. End Users: End users initiate most information system projects. Because
they are closer to the activities of the business and know the basic problems
of their firm. Therefore, they initiate a new project in order to solve the
problem they face every day.

8
 2. Analysts: system analysts propose most system development projects.
Because they understand both business and computing. They study business
problems and opportunities and then transform business and information
requirements into the computer based information systems that are
implemented by various technical specialists, such as computer
programmers, system designers and, system builders. A system analyst
studies the problems and needs of an organization to determine how people,
data, processes, communications, and information technology can best
accomplish improvements for the business.
3. Many projects are identified by an intensive information systems planning
activities called Information Resource Management (IRM). Using IRM
methods experienced analysts and non-computing managers chart an
information system direction that mirrors corporate plans. We have said that
system owners and users initiate most projects. However, the impetus for
most projects is some combination of problems, opportunities, and
directives.

1.2. Initiating and planning system development project

As discussed above, end users, system analysts, and information resource

management are initiators of system development project. However, after initiating
an idea there should be a guideline or plan as to how to implement the idea in to
practice.

End users communicate the need for systems project for top managers for
implementation. Because they do not have the necessary knowledge and skills to

9
undertake the system study. To communicate the intention, and convince
management of the firm, the initiator (end user) needs to put his/her idea in
writing. Such a report is known as system study project request proposal. The
proposal should include the following:

1.1. Background: This part of the proposal should describe the

organization or specific work unit where the study in proposed and the
objectives and activities of the organization also need to be incorporated.
The organizational chart, manual, job description and specification are the
source of information for this part.
2.1. Symptoms: This section of the proposal focuses on:
 Listing the problems clearly as much as possible
 Showing the extent to which these problems are chambering the
operations of the organization should be stated.
 Expressing the value of the problems in monetary terms.
3.1. Objectives of the Project: The end user should specify what should
be done about the problems and he/she has to suggest what the management
do and what he/she think to be done at all.
4.1. Benefits and Beneficiaries: The end user should also state the
significance of the study. That means, the benefit of conducting the study
and individuals or functions who benefit from the proposed project, how
much and how it benefits the stakeholders should be clearly defined.

System analysts, unlike end-users, have the necessary knowledge and skill to
undertake the study. Therefore, they have to convince officials that those who
propose the new system are capable and able to do the job. If preliminary

10
investigation is undertaken, the proposal should include its results, otherwise task
of the preliminary investigation should be included

The proposal in general could include the following:

1. Background: This provide a brief description of the organization or specific

work unit or area where the study is being proposed.
2. Symptoms: Problems are expressed through their symptoms and symptoms
are manifestation of existence of a problem. Therefore, system analysts
have to identify and list symptoms as a sort of justifying the project at its
initial stage. When the project study is advanced, later it should be justified
by conducting feasibility study.
3. Objective of the project: The user must clearly specify what should be
done about these problems. Or he has to state (suggest) in clear terms of
what the management has to do and what he think should be done to solve
the problem.
4. Scope and limitation of the project: In this part the proposal should define
activities, which can be included and not included or covered in the study
should be stated.
5. Methodology: The clear description of the methodology to be employed
should be included in the proposal.
6. Benefits and beneficiaries: The significance of studying the problem has to
form one part of his proposal. This could be done by identifying the
benefit(s) of conducting the study; those who are going to benefit and how
they are going to benefit and how they are going to benefit. Especially the

11
 benefits has to be indicated in such a manner that will arouse the interest of
the management to consider the proposal.
7. The study team: The brief description of each individual involved in the
study.
8. The project schedule: This Part focuses on identifying the major activities,
time estimates of the activities, and the whole project, personnel
requirements and other specific issues of the project. In order to
communicate well, analysts can use tools like Gantt chart, Network
diagrams (CPM and PERT).
9. Cost of the project: The cost of the project should also be indicated in detail
decomposition form not in the aggregate form.

In addition to the users and knowledge workers, projects can also originate from
formal organizational plan. This requires intensive information and the
involvement of the top managers.

1.3. Assessing project feasibility

All projects proposed by the different individuals or groups may not be

implemented. It need to be evaluated and assessed in terms of its functionality.
This requires organizations to establish a screening committee to study and
propose their implementation, which is composed of individuals with different
experience and background selected from different departments.

An organization should adapt different procedures in proceeding the proposed

system project. This procedure should normally cover the initial system projects

12
management phases, i.e., until the feasibility report. This is because the
continuation of the project is dependent of the feasibility study result.

The feasibility study report has to address, at least, three levels of feasibility:

 Technical feasibility: is it going to work?

 Business feasibility: are cost and timescales right for the business, and will
potential returns justify the initial outlay?
 Functional feasibility: will the solution satisfy the end users?

After all the necessary analysis and study, the analyst or knowledge worker should
produce a document, which serves as a reference point for further analysis and
evaluation of the system proposed. This document in known as the feasibility
study report. This report may include the following components:

1. Introduction
2. Terms of reference
3. Outline of existing system
4. Outline of the proposed system
5. Likely benefits from the new system
6. Suggested hardware and software as well as vendors
7. Cost of the proposed system
8. Staff and training requirements
9. Suggested implementation time table
10. Information about other organizations who might be using the new proposed
system
11. Ongoing costs

13
 1.4. Baseline project plan

A Baseline Project Plan is the Project Management Plan that is created by the
Project Manager and is approved by the Project Sponsor and the Senior
Management. The Approved/baseline plan outlines how the project will be handled
from start to finish and is like the bible for the project.

14
 Chapter 5: System analysis: determining system requirement

5.1. Traditional methods for determining requirements

The most commonly used methods of determining system requirement are many in
number. However, some of the traditional methods include interviewing,
questionnaires, observation, searching records and document analysis.

5.1.1. Interview

An interview can be defined as ‘a conversation with a specific purpose’. This

purpose could be selection in a recruitment interview, counseling in a performance
appraisal interview, or collecting information in a fact-finding interview. Personal
interview is the most popular, but time consuming fact-finding technique. It is used
to achieve any or all of the following goals: find facts,
 verify facts
 clarity facts
 generate enthusiasm
 get the end-user involved
 identify requirements, and
 solicit ideas and opinions
For interview to be successful, analysts should follow the following guidelines:
 Make a prior appointment with the person to be interviewed and inform the
purpose of the interview.
 Read the background material and go prepared with a checklist.
 State again the purpose of the interview at the beginning of the interview.

15
  Good manners are essential; introduce yourself, be punctual and pay
attention to what the user says.
 Do not use jargon words, explain technical words.
 Avoid yes/no answers; try to get both quantitative and qualitative
information.
 Do not prolong the interview
 Summarized the information gathered by you during the interview and
verifying with the user.

An interview is a form of two-way communication that requires a range of

interpersonal skills to be used by the interviewer to ensure that the purpose is
achieved. The interviewer will need to be a good listener, to be skillful in the use
of questions so that the conversation flows smoothly, and to be able to control the
interview while building and maintaining rapport with the interviewee.

Many fact-finding interviews result in the interviewee describing a lot of complex

procedural details, and it can be difficult to capture this information
unambiguously. A graphical technique can simplify the capture of this sort of
information, but to be effective it must be simple and quick to use, and be easily
understood by the interviewee so it can be checked for accuracy. For example, a
mind map can be used to record information. This consists of a central idea, or
topic, enclosed in a circle with related topics radiating out from the circle. The data
flow diagram, which provides a pictorial view of how data moves around an
information system, is another recording technique that has been used effectively
by many analysts.

16
5.1.2. Administering questionnaires

The use of a questionnaire might seem an attractive idea, as data can be

collected from a lot of people without having to visit them all. Although this is
true, the method should be used with care, as it is difficult to design a
questionnaire that is both simple and comprehensive. Also, unless the
questions are kept short and clear, they may be misunderstood by those
questioned, making the data collected unreliable. A questionnaire may be the
most effective method of fact-finding to collect a small amount of data from a
lot of people

When designing a questionnaire, there are three sections to consider:

 a heading section, which describes the purpose of the questionnaire and

contains the main references – name, staff identification number, date, etc.;
 a classification section for collecting information that can later be used for
analyzing and summarizing the total data, such as age, sex, grade, job title,
location;
 a data section made up of questions designed to elicit the specific
information being sought by the analyst.

5.1.3. Directly observing users

The systems analyst is constantly observing, and observations often provide clues
about why the current system is not functioning properly. Observations of the local
environment during visits to the client site, as well as very small and unexpected

17
incidents, can all be significant in later analysis, and it is important that they are
recorded at the time.

The analyst may also be involved in undertaking planned or conscious

observations when it is decided to use this technique for part of the study. This will
involve watching an operation for a period to see exactly what happens. Clearly,
formal observation should only be used if agreement is given and users are
prepared to cooperate. Observation should be done openly, as covert observation
can undermine any trust and goodwill the analyst manages to build up. The
technique is particularly good for tracing bottlenecks and checking facts that have
already been noted.

Observation checklist

5.1.4. Analyzing procedures and documents

18
When investigating the data flowing through a system another useful technique is
to collect documents that show how this information is organized. Such documents
might include reports, forms, organization charts or formal lists. In order to fully
understand the purpose of a document and its importance to the business, the
analyst must ask questions about how, where, why and when it is used. This is
called document analysis, and is another fact-finding technique available.

5.2. Modern methods

Even though we called interviews, questionnaires, observation, and document

analysis traditional methods for determining a system’s requirements, all of these
methods are still used by analysts to collect important information. Today,
however, additional techniques are available to collect information about the
current system, the organizational area requesting the new system, and what the
new system should be like. Thus, we will look in to two modern methods in the
following section.

Joint Application Design (JAD) and Prototyping

Main idea behind joint application design (JAD) is to bring together the key users,
managers and systems analysts involved in the analysis of the current system
(similar to group interview). But JAD follows a particular structure of roles and
agenda, which enables to collect systems requirements from all the key people
simultaneously. Typical participants:
- JAD session leader – sets and supervises agenda and is neutral
- users – key users of the system, who know the most about it

19
- managers – they provide insight into new organizational directions, motivations
for the system
- sponsor – someone at a relatively high level of the company who pays
- system analysts – they are there to learn from users and managers, and not to
dominate the process
- scribe – a person who takes notes
- IS staff – other staff like programmers, or database analysts (they know some
technical limitations or ideas)
JAD sessions are usually held in special rooms with special equipment. Upper
CASE tools can be used during JAD (diagramming tools, display and report
generation tools) in order to give graphic form to system requirements, show it to
users and make changes based on their reactions.

Also prototyping tools are good for presenting users with graphic illustrations of
what the alternative systems will look like. Prototyping allows to quickly convert
basic requirements (obtained during i.e. interviews) into a working, though limited
version of the desired information system. The prototype will then be viewed and
tested by the user and changes will be introduced. And this will be repeated until
all concrete specifications for the ultimate system are developed. Prototyping is
mostly useful when:
- user requirements are not clear or well understood
- one or a few users are involved
- possible designs are complex and must be concrete
- there are communication problems
- tools for prototyping are available

20
Disadvantages of prototyping: tendency to avoid creating documentation of system
requirements, prototypes may be too specific (based on a certain user’s taste),
prototypes ignore issues of sharing data with other systems (stand-alone systems),
and some important requirements may be missed.

Also group support systems may be used to support JAD sessions (because there
are some typical group meeting problems). Instead of giving everyone a few
minutes to talk all members of the group type their comments into computers and
may see what everyone else has been typing, but the comments are anonymous so
bosses can also be criticized. Pros: everyone has a chance to “say” something,
important ideas are less likely to be missed, and poor ideas more likely to be
criticized. Cons: leader has lower ability to resolve conflicts and the session may
become less structured. One advantageous approach to reduce the limitation of
group support system is using “Nemawashi” approach whereby prior informal
consultation will be held with individual participants about the meeting issue/s.

21
 Chapter 6: System analysis: structuring system requirement

Fundamentally, systems analysis is about problem solving where many approaches

or tools to problem solving are applied. Once the data is gathered through different
techniques explained above, it should be analyzed. Many analytical tools, or
models are available that enable systems analysts to present graphic, or pictorial
representations of a system. Some of the widely applied models are process
modeling, logic modeling, and conceptual modeling. They are briefly explained as
follows.

6.1. Process modeling

Is the analytical representation or illustration of an organization’s process, which is

used to map out an organization’s current processes to create a baseline for process
improvements and to design future processes with those improvements
incorporated. One of the tools under this category is data flow diagram.

6.1.1. Data Flow Diagramming

Data flow diagram graphically shows the flow of the data through a system, that is
the essential processes of a system, along with inputs, outputs, and files. In
analyzing the current system and preparing dataflow diagrams, the system analyst
must also prepare a data dictionary, which is used and expanded during all
remaining phases of the systems development life cycle. A data dictionary defines
all the elements of data that makes up the data flow. The dictionary records what
each data elements is by name, how long it is (how many characters), where it is

22
used (files in which it will be found), as well as any numerical values assigned to
it.

Therefore, DFD serves as an interface between what is happening in the real world
of day-to-day business and how these day-to-day activities can be converted into
suitable software.

The following are commonly used standardized data flow diagram notations or
symbols (there are 2 types of notations for DFD; Yourdon/Demacro and
Sarson/Gane notations).

1. Data flows: - The data flow symbol shows the movement of data (inputs and
outputs) from its source to its destination. It is represented by a bold line with an
arrow head indicating the direction of the flow. It must have a label that explains
the data.

2. Process: - This is the only part of DFD, which portray things actually
happening. It is represented by a rectangle.

(Gane) (Demacro)

3. Data Store: - Data store within the system is indicated by an open-ended

rectangle.

(Gane) (Demacro)

4. External Entities: - are sources or destinations of data outside the processing

system. The entities may be persons, groups of people, customer, supplier, other

23
departments within the organization etc. It is indicated by an ellipse, the entity
description entered within the ellipse together with entity reference.

(Gane) (Demacro)

Preparing a successful DFD requires system analysts to make a decision pertaining

how detail the DFD should be. DFDs can be expanded or decomposed in two or
more levels by separating each process in to sub-processes and then sub-sub-
processes and so on. The following are some of the levels required to draw DFD in
top-down approach.

1. Make a list of activities and determine the entities, processes, data flow, and
data stores.
2. Create the context diagram where there is only one process, and no data store. It
is the highest level in DFD.
3. Develop level 0 diagram or parent diagram that shows more detailed process
and explodes the context diagram. In this level the inputs and out puts remain
constant.
4. Create a child diagram or level 1 diagram that show more detailed process than
parent diagram.
5. The last level of DFD is called primitive data flow diagram.

There are no hard rules as to when to stop or end decomposition of the DFD.
However, the most commonly agreed up on criteria is when;

 All processes have reached in a single decision or calculation

 The user of the system does not need further decomposition

24
  Each data store represents data about one entity

Rules for decomposition

 One child diagram will have one parent diagram but one parent
diagram may have more than one child diagram.
 3 to 9 processes are allowed

Illustration 1: Burger house

Step 1:Identifying entities, processes, etc.

Entities: customer, restaurant Manager, and kitchen

Processes: customer order, receipt, report, and food order

Step 2: context diagram

Customer
Customer order Food order

Receipt

Report

Step 3: draw parent diagram

Customer

Customer order food order

Receipt

25
 Goods sold data Inventorydata

Formatted goods sold data

formatted inventory data

D1 goods sold file report D2 inventory

file

Daily goods sold amount Daily inventory depletion

amount

Step 4: draw child diagram

After the parent diagram is drawn the next step is to decompose the diagram in to
further process. However, this decomposition should continue until all processes
have reached in a single decision or calculation, the user of the system does not
need further decomposition, and each data store represents data about one entity.

6.2 Logical modeling

As with Data Flow Diagrams, Logical Data Structure diagrams (LDS) are not able
to carry all the information that analysts need to record about a system.A logical
data model (LDM) consists of decision tables and structured English.

6.2.1. Modeling Logic with Decision Tables, Structured English

Structured English

26
This tool is used to specify a program structure using a limited subset of the main
language to specify what the program should do. It strips the description down to
its base essential and removes ambiguity, redundancy and inconsistency. This tool
is based on logical construction of sequence, selection and iteration.

Sequence: - is a list of one or more actions or events that follow one another
without interruption. One or more imperative statements represent it. For example,
multiply price by quantity sold giving net price; multiply net price by 0.15 giving
VAT; add VAT to net price giving gross price. This can be written as:

 Calculate Net price= Price*Quantity sold

 Calculate VAT= Net price*.15
 Calculate Gross price= Net price + VAT

Selection: - a selection construct (also called decision construct) occurs when there
are a number of alternative policies which can apply depending up on the results of
some conditions and only one policy is selected. Selection includes the If-else
statement terminated by End-If.

IF dimensions not ok

Reject Product

ELSE (dimension ok)

IF mechanical test ok

IF electrical test ok

27
 Pass product

ELSE (Electrical test not ok)

Repair products

END IF

ELSE (Mechanical test not ok)

If electrical test ok

Repair Product

ELSE (Electrical test not ok)

Reject product

END IF

END IF

END IF

In the structured English description the conditions are checked one after another.
For each question the part after then states the action to be carried out if the answer
to the question is "yes" or "ok", the part after else state the action to be carried out
if the answer to the question is "no" or "not ok". At the end, the if is paired with
end if which indicates the end of the if statement. Indentation is used to aid the
reader see the correct grouping of answers. This style is closer to the way

28
programmers are written in a programming language. In order to understand this
concept in a more detail have look at on the following statement.

Illustration: Give a discount of 10% if the customer pays advance or if the

purchase is for Br. 20,000 or more and the customer is a regular customer. This
statement can be written in structured English as:

If customer pays advance

Then

Give 10% discount

else

If purchase amount  20,000

then

Give 10% discount

else

No discount

end if

else

No discount

29
 end if

end if

Iteration

An iteration construct (also called repetition construct) occurs when an action or

series of actions is repeated subject to a condition that governs the continued
repetition. Such repetition is implemented by such format as REPEAT---UNTIL.

Example:

REPEAT

Add invoice-Total to overall-Total

Add 1 to number xx Invoice

UNTIL no more invoice

Divide overall total by number xx invoice giving average value.

30
Decision tables

Decision tables are used for highly structured and clearly understood process and
when a combination of decision has to be made in order to establish a result. They
are made up of four quadrants.

Condition Condition
Stub Entry
Action Action
Stub Entity

 Condition stub:- In this quadrant list of possible conditions are entered as

direct questions to which the answer is only “Yes” or “No”
 The condition entry: - gives various combinations of conditions.
 Action stub: - In this part we have list of all action depending upon the
circumstance which may exist.
 Action entity: - shows what action to have for each particular note.

Example: Product Quality Control

1. Identify the conditions
 Correct dimension
 Passed mechanical test.
 Passed electric test
2. Identify actions
 Accept product
 Repair product
 Reject product.

31
 3. Determine the number of rules using the formula: 2N, where N is the
number of conditions. In this example, we have identified 3(three)
conditions, so n=3 and the number of rules or policies are 23=8. The
following decision table summarizes this situation.

Decision Rules
Conditions
1 2 3 45 6 7 Condition
entities
8
Correct- Yes YesYesYes No NoNoNo
dimension? Yes Yes No Yes Yes No
Pass mechanical No No
test? Yes No Yes Yes No Yes
Pass electric test? No No
Reject product X XXX Action
entities
Accept product X
Repair product X
X X

32
6.3 Conceptual Data Modeling

6.3.1. E-R modeling

An entity relationship diagram (ERD) illustrates “data at rest”.This contrasts

somewhat with data flow diagram, which for the most part illustrates data in
motion, as data flows. ERD could be viewed as a more detailed picture of the data
stores in the DFD. They do not imply how data is implemented, created, modified
used or deleted.

All systems contain data- usually lots of data andthese data describe persons,
objects events and other things of interest. For example in a typical order-
processing system the entities could be Customers (who are persons); orders
(which are events) and parts (which are objects). These three entities have a
natural relationship such that a customer places an order which contains parts.

There are various symbolic notations suggested by7 different authors and experts.
Among these the very popular one is the CHEN ERD. The following section
describes the Chen symbols and how to use ERD in modeling the data.

Entity:Represents the data entity, which is anything, real or abstract about which
we want to store data ( ).
A data relationship which is a natural association between entities. All
relationships are further described by words or symbols that indicated the number
of occurrences of one entity that can exist for a Single occurrence of the related
entity; and vice versa ( ). There are three general Possibilities.

33
  One-to-one (1:1) - for one occurrence of the first entity there can exist only
one related occurrence of the second entity and vice versa.
 One-to many (1: M or M: 1) - for one occurrence of one entity there can
exist many related occurrence of a second entity; it doesn’t matter Which is
first or second.
 Many-to-many (M: M) - for one occurrence of the first entity, there can exist
Many related occurrences of the second entity, and for one occurrence of the
Second entity there can exist many occurrences of the first entity.

A data element: data elements are characteristics that are common to a particular
entity. Usually, at least one data element takes on a unique value for the entity.
Such data element (s) is (are) called PRIMARY KEY. The key will identify one
and only one occurrence of the entity ( ).
As an illustration we can take an example of the relationship between employee
and department. As it can be seen from the diagram below, the relationship is
many to many.

M M
Employee Ordered by Department

34
 Chapter 7: Design of new systems

The final deliverable from systems analysis is a document containing an un-

ambiguous statement of the client’s requirements for a new system. This
document, called the functional specification, states what the development project
will have to deliver in order to be considered a success. It is written by the analysis
team and agreed and signed off by the client.

The functional specification is the starting point for the designer, who will rely to a
great extent on the accuracy and thoroughness with which the analysts have carried
out their task. The analysts’ understanding of the business, appreciation of the
client’s problems and documentation of requirements provide the foundation on
which the designer will build a working solution.

1.1. Agreeing the System Boundary

In order to identify where in the new system the interfaces will occur, a useful
starting point for the analyst or designer is the data flow diagram for the required
system. This is a logical view, which was described in detail in the previous
chapter. The system boundary must be determined in consultation with the users of
the new system, and in the end it is their decision as to which processes are
automated, and which require human judgment or intuition and are therefore best
done by people. In discussing this with the client, there are three questions to be
asked about any process:

 Can it be automated?

35
  Is it economic to do so? The answer to the first question may be ‘yes’, but
will it be worth the money in terms of the benefit it will bring to the
business?
 Is it operationally possible to automate it? In other words will the
environment allow it? There may be resistance to the automation, for
example from vested interests of some kind.

The designer will present options, but the final decision rests with the client.When
the system boundary has been agreed, both the client and the system developer will
be able to see clearly what is in and what is out of the new system.

7.3. Output design

Output is information delivered to the users through the information system. The
output of information system must be clear, precise and informative. All other
design is performed at the end to have output. Output must be designed based on
the requirements or purpose which are identified in the analysis phase.

Types of output Design

There are different types of output design. Some of them are:

1. Designating printed output

2. Designing screen output
3. Form Design

7.4. Input design

36
The quality of systems input determines the quality of systems output. Information
is the function of data and processing. Therefore, in this design phase, the
following issues should be considered:

- Collection of data itself

- Data entry and
- Data validation

The design elements are: input form design, design input screens and records,
design methods and procedures for getting the data in to the computer. The
objectives of input design are effectiveness, accuracy, consistency, simplicity, and
attractiveness.

When we design input we have to ask the following questions or we have to

consider the following points:

a) What sort of program run? Will it be undertaken?

The decision to be made at this point is to use simple batch inputs versus on-line
inputs. In batch processing, transactions are accumulated into batch processing;
transactions are accumulated into batches for periodic processing. The batch inputs
are processed to update databases and produce appropriate outputs.

Majority of systems have slowly evolved from batch processing to on-line or real-
time processing. On-line inputs and outputs provide for a more conversational
dialogue between the user and computer applications. They also provide near
immediate feedback in response to transactions, problems, and inquiries. In today’s
fast-paced economy, most business transactions and inquiries are best processed as

37
soon as possible. Errors are identified and corrected more quickly because there is
no time lapse between data entry and input. Furthermore, on-line methods permit
greater human interaction in decision-making.

b) Is it possible to input data directly by machine, by using bar code readers or

magnetic ink character readers?
c) What volume of data input needed?
d) Will data need to be transcribed from its original source before it is input?
e) Is some part of the data already entered in to the system?
f) How should the accuracy of the data be ensured?

System user issues for input design

Because inputs originate with system users, human factors play a significant role in
input design. Inputs should be as simple as possible and designed to reduce the
possibility of incorrect data being entered. The needs of system users must be
considered. With this in mind, several human factors should be evaluated.

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. Thus, numerous considerations should be given to the data that is captured for
input. These general principles should be followed for input design:

1. Capture only variable data. Do not enter constant data. Permanent or semi-
permanent data like description of a product ordered should be stored in the
database.

38
 2. Do not capture 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 times price.
3. Use codes for appropriate attributes codes were in

If source documents are used to capture data they should be essay for system users
to complete and subsequently enter into the system. The following suggestions
may help:

 Include instructions for completing the form

 Minimize the amount of handwriting
 Data to be entered (keyed) should be sequenced so it can be
read like this book, top to bottom and left to right.
 When possible, use designs based on known metaphors.

Inputs can be classified according to two characteristics:

(1) How the data is initially captured, entered, and processed and
(2) The methods and technology used to capture and enter the data.

These characteristics are discussed briefly as follows:

When we think of “input”, we usually think of input devices, such as keyboards,

and mice. But input begins long before the data arrives at the device. The actually
input business data into a computer, the systems analyst may have to design source
documents, input screens, the methods and procedures for getting the data into the
computer.

39
 a) Data capture- is the identification and acquisition of new data. It is
always best to capture data as soon as possible after it originates. For
this purpose source documents may be used. Source documents are
forms used to record business transactions in terms of data that
describes those transactions.
b) Data entry – Is the process of translating the source data or document
in to a computer readable format.

Entered data must subsequently be processed. The process may be batch or on-line.
In batch processing, the entered data is collected into files called batches. Each file
is processed as a batch of many transactions. In on-line processing, the captured
data is processed immediately.

Input methods and implementation

Different inputs devices can be used to enter data some of these are:

1. Keyboard – Keyboard data entry remains the most common form of input.
2. Mouse – is a pointing device used in conjunction with graphical user
interfaces (GUI)
3. Touch screen
4. Point-of-sale
5. Sound and speech
6. Magnetic ink
7. Smart cards

7.5. System controls

40
Control should be designed for every other element of the building blocks of the
information system. Control ensures that the system is protected against accidental
and intentional errors and use including fraud.

Types of control

Controls could be classified in to two basic categories: general control and

operational controls.

1. General controls are introduced to ensure that the computer environment is

secured. It can be subdivided into:
a) Administrative controls- Which are designed to sustain the smooth
continuing Operation of systems.
b) Systems development controls- The purpose of this control system is to
ensure that a new system does not introduce new risk to the computer
environment.
2. Operational controls- These are incorporated in to systems operations and
ensure that processed information is accurate, complete, authorized and valid.

Some of the key factor in administrative controlling includes

1. Existence of complete division of responsibility between the DP and user

departments
2. Restricting access to DP staffs to control records maintained by users and
vice versa
3. Documenting all work and keeping it updated

41
 4. Training all staffs properly
5. Supervising staffs and monitoring their performance
6. Establishing good working conditions and appropriate equipment
7. Preparing schedules for all work and monitoring that
8. Providing adequate security
9. Protecting confidential information

Output controls

The following guidelines are used for output controls

1. The timing and volume of output must be precisely specified

2. The distribution of all outputs must be specified
3. Access controls have to be used to control accessibility of video (on-line)
outputs-use password
4. Use batch control totals into all reports: total of accepted and rejected
data
5. Completeness of output reports: End of report

Input control

Input control has to ensure the accuracy of data input to the system. Following are
some guidelines

1. The number of inputs should be monitored

2. Ensure data validity by using the following techniques

42
  Completeness check: ensures whether all required fields on the input have
actually been entered
 Limit and range checks: determines whether the input data for each field
falls within the legitimate set or range of values defined for that field
 Combination checks: determine whether a known relationship between two
fields is valid
 Self-checking are techniques for determining data entry errors on primary
Keys which is a number or character that is appended to a primary key field
 Picture Check: compare data entered against the known picture defined; irds
a general rule, the data elements that comprise any entity should describe
only that Entity for finds the forms, file printouts, reports and so on whose
data.

Process controls

Processing could be undertaken on-line or on a batch. Following are some of the

controls to be designed in to batch systems

 All puts and outputs are scheduled and logged: a run book states where
programs run informs the computer operator of any necessary setup...
 Procedures describe how input errors should be distributed to end-users and
whether processing can proceed before these errors are corrected.
 Procedures require batch control totals to be checked against the historical
report generated for transaction processing
 Procedures describe how scheduled outputs are to be collected, duplicated and
distributed

43
 Procedures specify when and how master and transaction files are backed up
 Procedures specify how files will be recovered in the event that they are lost or
destroyed

Following are controls to be designed for on-line systems

1. Restrict access to on-line systems to authorized end-users

2. Ensure backup and recovery of files in on-line processing
3. Ensure simultaneous processing control by allowing record locking

File/Database Control

Controls are designed into files to ensure the integrity and security of the data in
those files. Some of control issues in files include the following

1. Access control should be specified for all files

2. Length of retention of files
3. Backup methods and procedures
4. Audit trial should be established for all files: this is keeping a permanent
record of any update made by a program on the file

Criteria for Specifying and Evaluating Hardware Acquisition

In specifying a requirement to acquire a hardware technology or in evaluating a

proforma (bid) document, the following factors (minimum) requirement.

1. Processor: type, clock speed, upgradeability

44
2. Hard Disk: capacity, type, access time
3. Memory: capacity, access time, upgrade ability
4. Cache: size, speed
5. Floppy Disk Drives: number
6. CD-ROM Drive: speed
7. Bus Type: type
8. Expansion Slots: number
9. BIOS: security password, flexibility
10.Monitor: Size, Dot Pitch, refresh rate
11.Video Card: resolution, video ram
12.Operating system: type, diskettes, manuals
13.Others: Multimedia Kits, Modem (speed, type), Keyboard. mouse,
mouse pad
14.Non-technical factors: delivery period, warranty, previous experience
15.Price

45
46