Module 13

Information System Development

Module Contents
• Introduction
• Learning Objectives
• People in Information System development
• The system Building phases
• Software requirements analysis and specification
• System design and implementation
• Systems operations and maintenance
• The context on system development methodologies
• Methodologies
• Choice of methodology
• Summary

13.1 INTRODUCTION

Information Systems, whether they are individual, workgroup, organizational,

interorgazational, or global, are developed by people who have an understanding of how
to apply Information Technology to meet business needs. Individual Information systems
are often developed by end users to solve specific business problems. Multiple user
information systems used by workgroups or organization are developed by specialists
who are knowledgeable in system development technique. This module discusses the
process of developing multiple­ user information systems, emphasizing user involvement
in the process.

13.2 LEARNING OBJECTIVES

After going through this module, you should be able to:

• Explain the roles of the people who are involved in information system
development.
• Outline the phases and steps in the information system development process.
• Describe the user’s involvement in each phase of the system development
process.
• Explain the purpose of common tools used for system development.

1
 • Explain the use of prototyping and rapid application development in system
development.

13.3 PEOPLE IN INFORMATION SYSTEM DEVELOPMENT

The people who are primarily responsible for developing information systems are called
Systems analysts. System analysts follow step­by­step process to develop Information
systems. Other people such as computer programmers may also be involve in the process.
Programming however is just part of the system development. Users of the system are
another important group of people involved in the system development process. An
information system is designed to meet the needs of its users.
Usually, Information systems are developed by a group of people who form a project
team. The team may consist of several system analysts, programmers, and users.

13.4 THE SYSTEM BUILDING PHASES

The development of software for commercial use requires business to have a view of the
entire process. Large software systems take a long time to develop and are (or should be)
in use for a much longer period of time. The first model of the software life cycle was
proposed by Royce (1970), and although many other models have been proposed since
then, the basic elements of the life cycle remain consistent and centered around four
categories of activities.
(i) Requirements Analysis and Specification,
(ii) Design and Implementation,
(iii) Validation and Verification, and
(iv) Operation and Maintenance.

2
Software Requirements Analysis and Specification

The requirements analysis exercise which focuses specifically on the software. The
information domain needs to be thoroughly understood by the analyst and
requirements of function, behavior, performance, interface etc. need to be
discussed with the user. Following analysis, the functionality of a system can be
defined.

Software design and Implementation

A number of stages are covered here. The requirements need to be partitioned into
hardware and software systems. The software systems design considers the
structure and interconnection of one or more systems. Data structure, software
architecture, interface representations and existing systems all have to be
considered before procedural or algorithmic detail can be considered. The designs
are converted into one or more programs in a suitable programming language.

Validation and Verification

A number of levels of testing need to be carried out. Each program needs to be

documented and tested as a unit. The entire system needs to be integrated and
tested before delivery to the customer. Checks need to be made to ensure that the
software does what was required.

Operation and Maintenance.

All software has a tendency to have errors despite rigorous testing. In addition to this user
requirements change over time, so the software has to be updated to cater for this.

Following are detailed issues dealt with in each of the activities.

3
13.5 SOFTWARE REQUIREMENTS ANALYSIS AND SPECIFICATION

Requirements analysis and specification includes three main activities: (i) the feasibility
analysis (ii) cost­benefit analysis and (iii) systems definition.

13.5.1 The Feasibility Study

• Is it possible?, is it practicable?, can it be done?
• Not only economic feasibility, but also technical feasibility, schedule feasibility,
operational feasibility.
• Economic feasibility ­ are the benefits greater than the costs? (see CBA)
• Technical feasibility ­ do we ‘have the technology’?; if not, can we get it ?
• Schedule feasibility ­ will the system be ready on time?
• Operational feasibility ­ do we have the resources to build the system? Will the
system be acceptable?, will people use it?

Feasibility Issues Include

• We cannot properly answer many of these questions at this stage. For example, data
on actual costs and benefits is not available; we don’t know what resources will be at
our disposal.
• The feasibility study is an educated guess. Often a ‘rough and ready’ approach’
• Some elements of feasibility will be more important than others and some may
directly conflict.
• Sometimes ‘external considerations’ are more important than the narrow feasibility
issues discussed here.

Other Questions Addressed in the Feasibility Study include

• What are the requirements of the users?
• What data is needed? Where does it originate? How much data is needed?
• What are the main functions and characteristics of the proposed system?
• What are the design alternatives? ( e.g. simple v sophisticated, manual v computer)
• What are the development alternatives? (Which methodology? do we need
prototyping or pilot studies?)
• Is all of this consistent with the business and IT strategy?

The Feasibility Report

• The feasibility study will normally be carried out by analysts or consultants who
interview potential users and review documentation.
• The feasibility report should include a description of functional requirements and
possible alternative solutions.
• It should cover the four aspects of economic, technical, schedule and operational
feasibility together with recommendations on the best way to proceed.

4
13.5.2 Cost Benefit Analysis
• The cost benefit evaluation should consider costs, benefits, and a time phased analysis
of the cash flows arising from the costs and benefits.
• Costs can be one­time costs in developing and implementing the system or recurring
or running costs ­ the costs associated with the ongoing operation of the system.
• One time costs include systems personnel costs, user personnel costs and equipment
costs.
• Running costs include staff costs, equipment and communication charges and other,
miscellaneous, charges.
• Benefits can be tangible (measurable) direct or indirect benefits or intangible benefits.
• Both costs and benefits must be considered over time. Costs will be incurred at
different rates and levels during development and benefits will return to the
organisation at different times.
• The major techniques used in CBA allow for time phased analysis of costs and
benefits ­ Payback, DCF, NPV and IRR.

13.5.3 The Systems Definition

• This phase adds detail to the system outlined by the feasibility study.
• The purpose of the definition phase is to produce a detailed design specification.
• The major part of the definition phase is determining user requirements.
• The design specification must also cover any constraints, which apply.
• Techniques used in the definition phase include DFD’s and Data Modelling.

13.5.4 Requirements Determination

• Requirements determination involves requirements acquisition, requirements analysis
and requirements specification.
• This is the least well­defined stage of the whole systems development process and
varies greatly from organization to organization.
• Also it is difficult as requirements can frequently change (see later)

Requirements Acquisition
• Analysis of existing system ­ outputs, inputs, procedures etc.
• Observation of existing behaviour and workflow ­ participative or non­participative.
• Analysis of desired systems documentation ­ strategy plans, feasibility study etc.
• Interviews
• Questionnaires ­ useful in supporting other methods.

Requirements Analysis
• The purpose of this stage is to take an unstructured mass of requirements data and
turn it into a specific, structured requirements specification.

5
• Requirements analysis uses techniques such as DFD’s, Data Modeling and
Prototyping.
• Requirements analysis is an important communication between the analyst and the
user.

Requirements Specification
• This forms the basis for discussion between the analyst and the user and should be
expressed in precise, clearly defined but understood language.
• It also forms the basis for actual systems design

Problems with Requirements Determination

• Users change their minds. For example, they become better informed or
disagreements emerge.
• External events may make original requirements obsolete. For example a
‘competitive system’ may no longer be needed.
• Implementation of a system to address some or all of the original requirements may
not be feasible.
• It is very difficult to estimate resource requirements in advance.
• Often organisational, social and political issues are ignored.

13.6 SYSTEM DESIGN AND IMPLEMENTATION

Whereas Systems Definition was concerned with what the system should do, Systems
Design and implementation is concerned with how it should do it.

13.6.1 Systems Design

• Systems Design covers all aspects of the system solution ­ output, input, data,
interface, procedures, hardware and software.
• We can distinguish between logical design and physical design. High level logical
design takes the systems definition and provides a basis for low level physical design.
• In principle consideration of physical design is postponed as long as possible to make
the design as computer independent as possible.
• Design is an iterative process and more detail is added with each iteration

Output Design
• A good starting point. Consider what we want from the system before considering
how to produce it. (a bit like baking a cake)
• Requirements specification will detail what output the users want (information
content) we now must determine how that information should be presented.
• Output medium
• Output frequency and timing

6
• Exception reporting
• Output format and presentation

Input Design
• Input design is greatly influenced by output design. For example, if we need a quick
response from the system the input must be online.
• Data capture methods
• Validation of data input
• Type of input forms and layout
• Volume of input forms.

Interface Design
• The interface is commonly thought of as the point at which the user interacts with the
system. In most systems this is the display screen or VDU.
• However, interface design must consider not just screen design and layout but the
entire user ­ computer interaction including the user’s mental model of the system.
• Screen design choices include text v graphical screens, the use of color and icons v
menus.
• Output, input and interface design can be collectively termed DIALOGUE design.

Data Design
• Based on a decision on how data will be processed we must decide how it will be
stored and accessed.
• Access and storage requirements will determine the type of storage media, which can
be used.
• We must also consider issues of data integrity and security. (see later)

Hardware Design
• This should include a detailed description of the computers, storage devices, I/O
devices and networking devices required by the system.
• Specific details would include processor speed, memory capacity, response times,
storage capacity and access times, quality and speed of printers.
• Because this is the first time that hardware has been specified in detail, costs will
have to be revised and the CBA re­worked.

Procedures Design
• Procedures are instructions which people use to operate the system.
• Procedures must be written for normal operation, for example how to start up the
computer, how to print a report etc.
• Procedures must also be written for failure recovery, e.g. what to do if the system
crashes.

7
• Ideally these procedures should be written at the same time, as the other elements of
the systems design are being developed (not added at the end) and should involve
users.

13.6.2 Software Development

• Software is a set of instructions or a program, which the computer follows to execute
certain tasks.
• The design and writing of software or programs is a major task in itself and in need of
its own quality testing and project management.
• However, we may not have to ‘code’ ourselves but can generate low level code from
an application generator or fourth­generation language or simply buy the software as
a package from someone else (see Buy / Build Analysis).

Programming Aims
• Reliability ­ the program will do what it is supposed to do, when it is supposed to.
• Maintainability ­ the program will be easy to change or modify when the need arises.
• Portability ­ the program can be transferred to a different computer with a minimum
of modification.
• Readability ­ the program will be easy for a programmer to read and understand.
• Performance ­ the program causes tasks to be done quickly and efficiently.
• Storage saving ­ the program should not be unnecessarily long.

Stages Of Programming
• Understand the problem (based on program specification).
• Plan the method of solution (who does what and when, how sub­programs are
integrated).
• Develop the method of solution by breaking the project into smaller tasks using
stepwise refinement.
• Type the instructions into the computer using a programming language.
• Test the program.
• Document all the work involved in producing the program (best done stage by stage).

13.6.3 Principles of Design and Development

• Data should be entered into a system, once and once only.
• Data should be captured as close to the source as possible.
• Computer systems should be fully integrated into general work procedures.
• The design should be ‘user friendly’.
• Data should be held in a database, which minimises redundancy and inconsistency
and allows pre­planned and ad­hoc queries.
• Data should be available to everyone with ‘a need to know’.
• Systems should be designed for maximum flexibility.
• Systems should be designed to facilitate maintenance.

8
• Systems performance should be satisfactory to the users.
• All transactions should be controlled by security measures, including transaction
histories.
• The system should incorporate backup and recovery procedures.
• System output should be provided directly to the person requiring it in a format suited
to his or her needs.

13.6.4 Tools in Systems Design and Development

Flowcharting
• Flowcharting is one of many techniques used to show what’s happening inside
existing or proposed systems. Other techniques include Data Flow Diagrams, HIPO
charts and Decision trees.
• Flowcharting is probably the oldest method of diagrammatically representing system
processes (or sequence of activities)
• There are system flowcharts, procedure flowcharts and program flowcharts.

Drawing a Flowchart
• Decide what activities are to be shown and the purpose of drawing the flowchart.
• Obtain the information needed to draw the flowchart
• A flowchart proceeds from top to bottom and from left to right.
• Use arrowheads to show the direction of flow and improve clarity.
• A flowchart may be any size but keep dimensions and be as neat and tidy as possible.
• The flowchart should be identified with a title, the date and name of the author.

Limitations of Flowcharts
• Different levels of detail can easily become confused. As flowcharts become more
complex they can resemble ‘spaghetti.’
• There is no obvious mechanism for proceeding from one level to the next.
• The essential story of what is done can easily get lost in the detail of how it is done.
• Flowcharts are best used in relatively simple process sequences such as system
overview diagrams or user procedures.

Decision Trees & Tables

• Decision Trees and Tables are useful for the analysis and design of multiple choice
decision environments.
• Decision Trees and Tables are also useful in highlighting deficiencies in existing
methods and information systems.
• Decision Trees and Tables should be used to supplement other charting methods, nor
replace them.

9
Decision Trees
• A decision tree breaks down systematically the decision making process, showing all
possible options.
• Identify the range of decisions, which have common input, processing or output.
• Relate each group of decisions to a specific user group.
• Identify decision­making inputs and outputs.
• Identify the decision rules which users use to make decisions.
Decision Tables
• Decision Tables are an effective way of expressing the relationship between data,
actions and people.
• Identify the general conditions and list them in the upper left­hand part of the table.
• Identify the general actions and list them in the lower left­hand part of the table.
• Examine each required combination of general conditions marking them with Y, N,
or a dash ­ if not applicable.
• For each set of conditions the corresponding actions are indicated by an X.
• Decision tables becomes more comprehensive if combinations of general actions are
shown which satisfy combinations of general conditions.
• Decision tables can represent more than logical relationships. They can be used as a
check on the consistency, accuracy and completeness of the analysis.
• Decision tables can be converted directly into machine code, thus reducing systems
development effort.

Limitations Of Decision Tables

• Decision tables are not good at expressing sequence or procedure. This is best left to
graphical techniques such as flowcharting.
• Multiple decision environments can quickly produce very large decision tables. These
can be split into a number of smaller tables but interrelating these tables can be
difficult.
• Nevertheless, decision tables are a useful tool for the analyst throughout the systems
development process.

Data Flow Diagram (DFD)

• The DFD shows the logical relationships between processes and the way in which
data moves to support those processes.
• A powerful feature of DFD’s is that they can be decomposed or exploded to provide
increasing levels of detail.
• DFD’s are a widely used technique in structured methodologies

DFD Conventions
• A process represents an activity which happens to data (calculate).
• Processes are described using an action verb followed by a description of the data
being processed.

10
• A data store represents data at rest. (stored for any length of time, in whatever
format.)
• Data flow represents data in motion (the flow of data between processes or data
stores)
• An external entity represents the point of origin of inputs or the point of destination of
outputs from the system being diagrammed.

Drawing A DFD
• Identify the aspect or the extent of the system to be diagrammed.
• List and draw all processes involved.
• List and draw the outputs or data flows produced by each process and connect them
to their appropriate destination.
• List and draw the inputs or data flows and connect them to their point of origin.
• Label and name each data flow, external entity, data store and process.
• Restructure the DFD to give the clearest possible graphical representation.

Limitations Of DFD’s
• They also can become over­complex (although not as bad as conventional flowcharts)
• They are not good at showing error handling or exceptional situations.
• They are data oriented. Although this is fine for applications which emphasis data
(such as banking or insurance) DFD’s are not as appropriate for applications where
there is less emphasis on data (for example in manufacturing applications, we are
more concerned with the flow of goods and services, not data.)
• However these are minor criticisms, DFD is a powerful and widely used technique.

13.7 SYSTEMS OPERATIONS AND MAINTENANCE

• Operation and maintenance must be planned for (at the project planning stage) and
controlled.
• Acquire, integrate and test systems components
• Convert data
• Train users
• Integrate and test system ­ including procedures
• Install system ­ options include parallel, piecemeal, pilot, or plunge.

13.7.1 Evaluation or Review

• Implementation is not the end of the story ­ the system must be reviewed to see if it
has met its objectives
• Post­implementation audit must be conducted after the system has been running for
an agreed time period. This will compare benefits to costs, assess systems
performance and user reactions, identify problems and errors and make
recommendations for improvement.

11
• Thereafter, systems should be reviewed periodically to ensure effective and efficient
operation.

13.7.2 Maintenance
• Maintenance can be sub­divided into ­ corrective maintenance, ongoing maintenance
and system enhancement
• Corrective maintenance occurs early in the operational life of the system and is
frequently urgent
• Ongoing maintenance adapts the system to meet (small) changes in its environment
(mostly to meet evolving user needs).
• Enhancements are major modification to the system initiated for business, technical
or organisational reasons.
• All maintenance activity should be managed.

13.7.3 Problems of Maintenance

• Maintenance of existing systems is a major cost element of systems development
activity (up to 80%)
• Many systems implemented contain errors, do not incorporate changes identified
during development and are poorly documented.
• Programmers prefer creating new systems to maintaining old ones and because of
high staff turnover few were around when old, ‘legacy’ systems were developed.
• Users make heavy demands for systems changes; many of these are unrealistic.

13.7. 4 Possible Solutions

• Separate maintenance from development and introduce a specialist career path.
• Collect more data on maintenance, including statistics.
• Use software tools to improve the productivity and quality of maintenance activity.
E.g. reverse engineering.
• However, these address the symptoms not the cause of the problem. Maintenance
problems are caused by poor development, particularly poor requirements definition.
• The earlier the error in the development process the more expensive the maintenance
cost in eliminating the error. Requirements errors account for up to 82% of total
maintenance costs.

13.7.5 Modification Control

• Modification or Configuration control is an important aspect of project management.

• It is vital to document all (but the most trivial) requests for systems modification
• Each request should be put in writing and signed by a responsible person in the user
department.
• Each request should be evaluated in terms of costs and benefits.

12
• If costs exceed benefits the request should be rejected (unless the change is
mandatory or the user department insists ­ in writing)
• Proper change control is good practice and gives future programmers a history of the
systems evolution.

13.8 THE CONTEXT ON SYSTEM DEVELOPMENT METHODOLOGIES

13.8.1 Notable Frustrations from Previous Development Practices

• DTI ­ (1985) Time overruns in 66% of projects, 55% of projects over budget.
• DTI ­ (1988) Poor quality s/w costs £1bn. per annum. Direct costs only.
• Ken Eason (1988) Survey of development efforts during 1980’s. Found 40% of
systems never delivered / failed / rejected. 40% had marginal effect. 20% had
positive effect.
• Tom DeMarco (198?) In a survey of 500 projects since 1977 found 15% came to
nothing (cancelled / aborted / never used). The bigger the project the more likely
the failure. 25% of projects >25 man­years came to nothing.
• Quality problem ­ wrong problem, wrong analysis, not usable, errors and bugs.
• Productivity problem ­ too slow & expensive.
• Maintenance problem ­ expensive & inflexible.
• Reliability problem ­ due to bugs and errors.
• Security problem ­ hackers and viruses.

13.8.2 Methodological Reasons (By Checkland)

• Problems not structured but fuzzy and subject to change because people are
involved.
• Requirements emerge from a discussion and bargaining process and include non­
technical issues.
• Advocates 6­stage process, emphasis on problem definition, user participation and
non­technical issues.
• Criticism of structured systems development ­ only covers requirements stage,
requires time, money and experts, empirical data limited, no evidence that it
works.

13.8.3 Methodological Reasons (by Mumford)

• Participation ­ because ethical, expedient, gain expert knowledge, a motivator.
Different levels of participation.
• Socio­technical approach ­ considers not just technical aspects of a system (tools,
techniques, procedures) but social aspects (network of roles, relationships and

13
 tasks). Aims to increase organisational effectiveness in the technical system and
job satisfaction in the social system.
• Criticised also because limited to requirements analysis, added costs, lack of
empirical data.

13.8.4 Methodological Reasons (by Whiteside & Nielsen)

• Attempt to specifically include usability criteria early in the development cycle.
• Usability criteria determined by competitor system, manual system, and absolute
scale.
• Usability only really measurable in specific user actions in specific situations ­
difficult to generalize or anticipate these early in development.
• Some usability metrics make assumptions about the dialogue design that may not
be valid e.g. fewer steps are better.

13.9 METHODOLOGIES
• A methodology is ‘an ordered set of ideas or procedures; a set of guidelines,
standards and procedures’ (Bingham).
• A methodology is ‘an integrated set of procedures and techniques which, when
applied in a certain sequence, result in the specification or generation of an
information system’ (Flynn).
• There are many methodologies or approaches to the development of information
systems ­ common ones are the structured approach, the data­centered approach
and the prototyping approach.

13.9.1 Structured Approach

• Originated in ‘software crisis’ and birth of ‘software engineering’ in the late 60’s early 70’s.
Applied initially only to programming.
• Characterized by top down functional decomposition ­ analysis and design breaks
down the system into smaller and smaller parts and each stage results in a
‘deliverable’. Also known as the ‘waterfall’ method.
• Emphasis on the process rather than the data. It is primarily concerned with the
sequence of activities taking place in the system.

13.9.2 Criticism of Structured Approach

• Rigid ­ requirements need to be fixed early.

• Costly ­ linear approach can be time consuming (iteration makes it more so)
• Narrow ­ focus on technology, not human or social aspects.
• Focus on functionality at the expense of usability.
• Works best where ­ large, structured system, phases clear cut, few changes during
dev. but unsuited to many (most) environments.

14
13.9.3 Data­Centered Approach

• In part, a response to the deficiencies of the structured process method, which is

not good at establishing new user requirements.
• Emphasis on data and the relationships between data, which are relatively stable
as opposed to processes which are not.
• Also recognized the need for iteration ­ the re­visiting or re­working of previous
phases as analysis and design progressed (in contrast to waterfall method).

13.9.4 Object­Oriented Approach

The Heart of the Matter for Object oriented approach is ­ The "Black Box"

Object­oriented is all about objects. An object is a "black box" which receives and sends
messages. A black box actually contains code (sequences of computer instructions) and
data (information which the instructions operate on). In the previous two approaches,
code and data have been kept apart. Not so for object­oriented approach. Why??? A
primary rule of object­oriented approach is this: as the user of an object, you should never
need to peek inside the box!

Why shouldn't you need to look inside an object? For one thing, all communication to it
is done via messages. The object which a message is sent to is called the receiver of the
message. Messages define the interface to the object. Everything an object can do is
represented by its message interface. So you shouldn't have to know anything about what
is in the black box in order to use it.

And not looking inside the object's black box doesn't tempt you to directly modify that
object. If you did, you would be tampering with the details of how the object works.
Providing access to an object only through its messages, while keeping the details private
is called information hiding. An equivalent buzzword is encapsulation. Why all this
concern for being able to change software? Because experience has taught us that
software changes. A popular adage is that "software is not written, it is re­written". And
some of the costliest mistakes in computer history have come from software that breaks
when someone tries to change it.

13.10 THE CHOICE OF METHODOLOGY

• In practice most methodologies incorporate elements of the structured, data­

centered and object­oriented approaches (although each will have a particular
emphasis).
• There is no one best methodology; each will be more or less suitable in given
situations.

15
 • In general, structured methodologies are best suited to situations in which
requirements are known and stable.
• Data­centered approaches excel in situations where multiple systems are being
developed around a corporate database.
• Object­Oriented approaches can be good at identifying user requirements.
• While Structured approach is top­down (you primarily worry about how to
organize the whole before thinking about individual components), object­oriented
approach is normally bottom up. (i.e. you primarily worry about building
individual components before thinking about how best they will work together).

13.11: SUMMARY

16