Chapter 2

DR: saleh Al-zahrani

Faculty of Computer and Information Systems
The systems approach
According to the general system theory, a system is a set of interrelated elements (Turban et
al, 2001). However, Checkland, (1999) defines a system as a set of interacting systems, some
of which do not work very well and can be engineered to work better. Yet Bocij et al. (1999)
consider a system as a set of elements, such as people and things that are related to achieve
goals. In this sense, Imam Mohammed Bin Saud Islamic University can be viewed as a
system, and the Faculty of Computer and Information Science may be seen as a subsystem of
the large system with its own function. Also, we could look to United Nation (UN)as systems
and Saudi Arabia as sub systems of large system.
All human actions take place within a wider context or situation. The essential aspect of
understanding situation from a system perspective is to consider the system as a whole. One
of the most popular descriptions of this system or the holistic view is known as the (SSM),
which is generally known as the Checkland approach. A systems approach tends to be an
approach to a problem that takes the broad view, which takes all aspects into account, and
which concentrates on interactions between different parts of the problem. An approach is the
way of tackling a problem, and obviously, a particular approach may be relevant to more than
one subject (Checkland, 1981).
A system approach use systems thinking to help in understanding the world and its behaviour.
System thinking involves the use of systems concepts (ideas) and system methodologies and
leads to construction of models of the system. Soft system modelling is a subjective process
because no two people will look at any particular aspect of the world (except hard system) in
exactly the same way. A system model is a set of organised assumptions about a particular
aspect of the world and the way it works which have been identified as a system. Identifying
system is not a purely objective process since the purposes and interests of the researcher will
be involved. The system approach is not an attempt to understand every thing about a system,

rather its tries to include all factors relevant to the topic or problem under consideration. This
helps to highlight requirements of the system. System approach by itself is not a
methodology, but involves the use of systems methodologies. Jenkins (1969) states that
systems methodology comprises stages of system analysis, systems design, implementation
and operation, formulation of the problem or objective is starting point. System approach is
not a method, it is a way of looking at a problem. As result of this, finding a methodology,
which uses the systems approach to apply to this study was essential Checkland's soft
methodology which use system approach was chosen.
SSM has stimulated much interest and also has attracted considerable academic debate
regarding its use in wider management problems and information systems issues. Indeed,
SSM is not a technique (a method that requires certain procedures to be followed in order in
obtain a predictable outcome), but is a set of guidelines for applying system ideas. Although
these guidelines help an analyst to approach investigations methodically, they still allow
considerable scope for individual interpretation. Since the original group of people who
developed this approach was part of the Department of Systems Engineering, much of the
activity was developed using characteristics of industry. Only in recent years, has experience
outside industry contributed significantly to SSM development (Checkland, 1999). However,
during the past two decades since its inception, SSM has had a considerable success as a
general purpose problem - solving methodology, tackling the messy or unstructured problems
which managers of all kinds and at all levels have to cope within their work. The emphasis of
SSM is not on finding a solution to a specified problem, it is on understanding the situation in
which a perceived problem is thought to lie.

Distinction between 'hard' and 'soft' problems

In selecting a methodology for problem-solving, a distinction between hard and soft problems
is very important. A hard or structured problem is one which is exclusively concerned with a
'how' type of question. This kind of problem is the domain of the design engineer who seeks
effective and economic answers on 'how' to provide. For example, 'How can we transfer an
objective from point A to B at a minimum cost'? Another example of a hard system is an
engineering application or a computer system development. Hard problems are problems
characterised by the fact that they can be well defined. It is assumed that there is a definite

solution, and a number of specific goals that must be accomplished can be defined. Hard
approaches to systems analysis and design have been very successful at developing computer
systems that, viewed from a technical perspective, are efficient and effective information
providers. However, there have been cases when new information systems have not had user
acceptance or seem to be misplaced as solutions to spurious problems (Curtis, 1998). This
indicates that an alternative approach is required to capture the human element of a system
design. In contrast, the soft or unstructured problem is one that embodies a mixture of both
what and how questions. Checkland (1981) believes that the main difference between the
hard and soft approaches is that where the former can start by asking what system has to
be engineered to solve this problem, or what system will meet this need and can then take the
problem or the need as given, the latter has to allow completely unexpected answers to
emerge at later stages. He thinks the soft methodology is seen to be the general case of
which hard methodologies are special cases. These by definition, soft problems are difficult
to define. For example, they may have a large social and political component. A good
example to illustrate a soft problem is how the transfer of highly sophisticated technology
from Western Countries to Saudi Arabia can be achieved. In this case, there are different
stakeholders with different perspectives, and interest for example, political, economic, social,
cultural issues. These several issues contribute to an unclear picture.
It is often stated that the hard system thinking is appropriate in well-defined technical
problems and soft system thinking is more appropriate in fuzzy, ill-defined situations
involving human beings and cultural considerations (Checkland, 1999). Different approaches
have different strengths and weaknesses, different areas of applicability and differing
objectives. The aim of this chapter is not to explore the differences between hard and soft
systems, but rather to give overview of their interactions. Table 1 below shows what can be
considered as the main criteria that distinguish between hard and soft problems (Harry, 1994).
Hard problem

Soft problem

Defined
Clearly bounded
Separable problem
Clear who ought to be involved
Information needs known
Know what the solution would look like

Undefined
Fuzzy-edged
What is the problem?
Not sure who ought to be involved
Unsure what information is needed
Not sure what the solution would look like

Table 1. Show the main criteria that distinguish hard and soft problem
.
REAL-WORLD APPLICATIONS OF SYSTEMS IDEAS
HARD SYSTEMS

SOFT SYSTEMS

ANALYSIS:

ANALYSIS:

Machine-based or hardwaredominant systems approach for

hard, well-structured problems

Human activitybased systems

analysis for soft,
messy, complex
and ill-structured
problems

APPLICATIONS OF SYSTEMS IDEAS TO ACADEMIC PROBLEMS:

e.g.

Planning
Medicine

Education
Geography

Social work
Ecology, etc.

Figure .1. A map of system ideas (adapted from Checkland, 1990)

Figure. 1 shows a map of system ideas that summarises the views taken, of hard and soft
systems and their applications thus far. From a methodological perspective the research
question can be formulated as:
What kind of system model would be best suited to improve the messy and ill-structured
problem situation involved in this study?

Systems Development Methodologies

The systems development life-cycle that is described in the previous section, is a model of the
systems development process. To perform, manage, and control this process, a methodology
is normally used. A systems development methodology may be defined as A methodology is
based on some philosophical view, and is made up of a collection of phases, procedures, rules, techniques, tools,
documentation and management aids. These aids help systems developers choose the appropriate techniques for
each phase of a project and also help them plan, manage, and control information systems projects.

There are hundreds of methodologies available, many of which are very similar to each other.
All are based on some philosophical view (e.g. scientific structured, functional; humanistic
participation, prototyping; object-oriented). The systems development life-cycle is similar
to a methodology, according to the above definitions:

It is split into discrete phases.

It makes extensive use of documentation.

It is standardised and can be applied in many circumstances.
It uses techniques and tools.
There is an implied philosophy (i.e. that computerisation is a good way of dealing with,
for example, clerical problems).

Types of Methodology
There are a variety of methodologies available and some examples of hard and soft methods
along with their main phases are listed below.

1.

Hard system methodology

The hard methods consider systems that have a clear purpose and well-defined goals, and are
useful for designing solutions that achieve those gaols. These methods were developed in or
around the 1960s when computers were big boxes that lived in large rooms. They view an
information system as an input process connected to that computational process connected to
an output process. They also view the process of problem solving as being a clear linear
These methods, on the whole, only concentrate on the information and computation
components and they do not focus on any part of values, which provide a basis for judging
and deciding on actions. Following are good examples of hard systems
A. System analysis: The decision-making sequence is tackled in 4 steps:
1. Problem analysis: 2 Generating alternative solutions: 3 Evaluation of alternative: 4.
Selection of the optimal alternative:
B. Information engineering(IE) (Jenkins)Jenkins was the starting point in the evolution of
SSM. This approach passes through 4 basic stages: 1. System analysis: 2. System design: 3.
Implementation :4. Operation:
C) Operations research:
This approach passes through 5 major steps: Thos steps are Formulation of the problem,
Constructing a mathematical, Mode, Deriving a solution to the model, Testing the model
and evaluation and Implement solution.

1. Soft systems methodology

The soft methods recognise that many human activity systems are so complex that they do
not have a single goal and to impose a solution that embodies a single purpose can be
extremely damaging to the system under investigation. A number of methods have been
developed around the theory that specifically address human issues in design,
A: Soft system approach(SSM)
SSM has been developed since the 1970s by Professor Peter Checkland at Lancaster
University. SSM has stimulated much interest and also has a roused considerable academic
debate regarding its use in wider management problems and information systems issues. It
was developed through action research, where systems ideas are tested out in client
organisations. According to SSM, the problem-solver defines the problem situation and then
uses this methodology to recommend action to improve it. SSM involves a seven stage
process of analysis which uses the concept of a human activity system as a means of getting
from 'finding out' about the situation, to 'taking action' to improve the situation.
B: Prototyping (Also its known as rapid application development or RAD). Its a
development methodology in which the system development phases are executed at the same
time, rather than in sequence like the SDLC. Its relies on prototype, working or experimental
models of a system.
C: The Structured System Analysis and Design Method (SSADM)
A methodology defines the methods of analysis and that should occur in a large-scale
software development project. It is used extensively in the UK, particularly in government
and public organisations. It attempts to address four questions that continually arise in the
process of systems development. For example: What is the system to do? When should it be
done? How should it be done? Where is the information to be recorded?
SSADM focuses on the feasibility, analysis and design aspect of the systems development
lifecycle. It provides fewer guidelines on changeover and maintenance aspect of an IS
project. It has six stages and each stage is broken down into a set of smaller steps, which
define the input, output and tasks to be performed. The SSADM methodology, as it stands, is
a soft methodology, in that it recognises that for any problem there are a number of different
solutions that may be appropriate, and that the appropriateness of different solutions is largely
determined by the particular viewpoints of those people who have an interest in the problem
and its solution. The methodology demands that a system-oriented approach to design are

taken, where design is viewed as the creation of a formal system, which must have certain
features in common with all other systems. Obviously, a key feature in this methodology is
the ability to represent and detect conflicts of interest among the holders of various
viewpoints.
D: The Object Oriented Methods
Object Oriented Analysis (OOA) methodology

is considered as one of the major object-

oriented approaches for system analysis. It consists of five major activities as listed below:
Finding class-and-objects Identifying structure Identify subject, Defining attributes, Defining
services. Furthermore, the OOA methodology does not include design and implementation
phases, although the authors address design in some detail in other sources. However, the
transition from analysis to design in OOA is not a question of changing, or introducing new
concepts. The transition is simply a matter of extending the detail of the object-oriented
models and specifications and adding components concerning human interactions
.Concerning the user participation approach, OOA prescribe a passive role for the users, with
the traditional view of users as a source of information and reviewers of models developed. It
only allows for the identification, representation and validation of the informational and
computational component and it pays no attention to any of the axiologial framework
components. OOM have been applied to both business process reengineering and analysis
and design organisational information systems. The methods, in general, view the system as a
set of interacting objects
E: The Scandinavian Style Method
The Information Systems Work and Analysis of Changes (ISAC) method is a problemoriented method and seeks to identify the fundamental causes of the problem. The approach
taken by the ISAC methodology is designed to analyse problem owners business problems
and to solve aspects of them where appropriate. The ISAC approach to problem solving is to
educate the problem owners by helping them to understand better the nature their problems.
The ISAC method is a stepwise methodology that starts with trying to understand the
problems that are facing the problem owners. The key difference between ISAC and other
methods is that it directly places in the problem In general, they do not excel at the
identification, representation and validation of any of the components from the axiological
framework. The Scandinavian style of methods can be viewed as empowering the problem

owners through education and the free exchange of information. This style of method has
been slowly gaining in popularity and is now used in Europe and North America
F: The Socio-Technical Methods (Ethics)
Effective Technical and Human Implementation of Computer-Based System (ETHICS) is a
socio-technical system development method developed by Enid Mumford of the Manchester
Business School in the late 1970s and early 1980s. Moreover, it is based on the participative
approach to information system development where user participation is very crucial
throughout the development lifecycle. The ETHICS methodology adopts the socio-technical
approach that for the system to be effective the technology must fit with social and
organisational factors and the social and technical parts of the system must be given the same
amount of concern. In particular, this means that an improved quality of working life, and
enhanced job satisfaction for the users must be a major objective of the system design
process.
In additional, ETHICS the development of computer based systems is seen as a change
process and is, therefore, likely to involve conflicts of interest between all the participants or
actors in that process. These conflicts are not simply between managers and worker but often
between worker and worker and manager and manager. The successful implementation of a
new system, therefore, requires a process of negotiation between the affected and interested
parties. These parties are probably the most knowledgeable about the current workplace
situation and the future requirements.
The job satisfaction needs and the efficiency needs (workflow problems) are collected and
diagnosed by means of questionnaires given to all people who work in the organisation unit.
Decisions are made by involving all workers in the unit who should all support the decisions.
The decision about the change option should be verified with the appropriate management
authorities. ETHIC can best be viewed as a development method for organisation units, with
equal emphasis on the job satisfaction aspect, the workflow aspect and the information
aspect.

Alternative approaches

Most large computer information systems are now developed in a sequence of steps called
the Systems Development Life Cycle (or simply the systems life cycle). The key point is
that it provides system builders with a structured approach to follow. It is used to:

organise the large number of activities which are necessary in building a system.
specify an orderly way to proceed through these activities.
make it easier to solve problems as they occur in the development process.
produce reports on project status, resource usage etc. as development progresses.

A number of different kinds of life cycle are used in practice, the most common systems
development process takes an essentially linear approach dividing the necessary tasks into a
number of stages. No stage in the sequence can commence before the previous stage has been
completed.
There is little consensus on the terminology, the subdivision or the exact content of each stage
of the life cycle, but the most common approach is Problem Definition,Feasibility Study
Systems (and Requirements) Analysis, Systems Design, Implementation and ,Maintenance.
Thos stages well be outlined below:
1. Problem Definition
This stage establishes the nature of the problem to be solved, and estimates the scope of the
problem. The problem definition basically states the reason/idea for the new system, at a
high level. The new system might be needed to:

Solve a problem (e.g. replace a manual system with a computer system in order to
increase processing speed, provide better communication, reduce costs, or enhance
competitive advantage).
Take advantage of an opportunity (e.g. to expand or improve organisational performance,
improve customer service).
Respond to a directive (e.g. new legislation).

This is often considered to be the most important stage in development because it sets the
direction of the rest of the project. The project limits are set in terms of what parts of the
system can be changed by the project and what parts are outside its control. The resources to
be made available to the project are also specified at this stage. These three important factors
- goal, bounds, and resource guidelines are referred to as terms of reference and they form
the main deliverable of this stage.
At this stage too, a project committee may be established, which is made up of system
analysts, users and management.

The role of the systems analyst is to bridge the communications gap between users and
programmers (who will later write the programs for the new system).
The systems analyst translates user needs into the technical specifications needed by the
programmer. The role of management is to control the systems development process.

2. Feasibility Study
Starting with the problem defined in the previous stage, an investigation known as the
Feasibility Study is carried out to determine quickly and with little expense:

If there is a feasible solution (i.e. can the problem be solved?).

If the problem is worth solving.

If not, then time, effort, and money have not been wasted on a full project. The task of the
Feasibility Study is NOT to solve the problem, but to gain a sense of its scope and determine
if a problem is worth solving. The Study is important because it ensures that the right system
is to be developed. The rest of the development effort concentrates on making the system
work right. So, if the wrong system is defined here, all further work is pointless.
In the Feasibility Study, three aspects of feasibility need to be considered:
(i) Technical Feasibility
It must be established whether or not the organisation has the technology and skills needed to
carry out the project? If it does not, can these skills be bought, through hiring extra staff or
through employing an outside consultancy firm?
(ii) Operational Feasibility
The system users are shown the proposed solution and asked if it seems to satisfy their
requirements.
(iii) Economic Feasibility
Management need to determine if the project can be carried out within the resource limits
allocated to it. They must also decide if the benefits of the new system will outweigh the
costs it will inevitably incur.
A Feasibility Study should cover the following:

Nature of the existing system.

Shortcomings and problem areas (bottlenecks etc.).
Scope for improvements.
Alternatives available. Once the problem is understood, alternative solutions are
developed.
The preferred solution.
Preliminary estimates of cost and benefits of the preferred solution. The Feasibility Study
must show that the solution will help the organisation attain its objectives, that it
conforms to the organisations strategic plan, and that it is technically, economically, and
operationally feasible.
The recommended approach i.e. a plan plus a rough time scale.

These issues can be resolved using methods such as Fact-Finding techniques and CostBenefit Analysis. Through fact-finding techniques (e.g. interviews with users and managers),
the analyst can find out what the existing system is like, what the problems are, and what is
needed by the new system (i.e. high-level functional requirements what the system will do;
high-level non-functional requirements resource restrictions, security isuses, number of

users, equipment needed/available, retraining of employees, availability of people to develop

system, etc.).
Using Cost-Benefit Analysis, the Feasibility Study can show how the preferred solution will
help the organisation attain its objectives, how it conforms to the organisations strategic plan,
and how it is technically, economically, and operationally feasible. When preparing the CostBenefit Analysis, the analyst will ask questions such as:

What will be the difference in cost and profit between the old and the new system? Is
a new system justified on the basis of cost alone?
Will the cost of maintenance of the new system be greater than the old one? What are
the true savings in maintenance costs in the short and long term?
What indirect benefits will resuts from the new system? Will changing the design of
one system improve the operation of another?
Will the new system be more reliable and dependable? Can we expect less down-time
from equipment breakdowns? How can we put a value on these changes?
What improvements in personnel attributes will result? Will the new system lead to
greater motivation, less absenteeism, and greater productivity?

The Feasibility Study ends with a formal presentation to users and management: a GO / NO
GO decision must be made.
3. Systems (and Requirements) Analysis
The aim of analysis is to develop a model of the way the current system works, on the
assumption that the existing system provides a good guide as to what is required of a new
system (as opposed to how the new system will achieve the requirements). Analysis
summarises and models key elements in the system to faciliate understanding of the system
and to help with the System Design stage.
Analysis therefore, is about what is to be done in order to satisfy the requirements of a new
system. The how comes later (in the Systems Design stage). During the analysis stage, the
analyst uses the facts gathered during the Feasibility Study about the existing system and
about the requirements for the new system, to model the system. Generally, the analyst will
need to gather more detailed facts about the existing system and about the requirements for
the new system than is available from the Feasibility Study. To do this, s/he can use the same
fact-finding techniques as used Feasibility Study.
This stage consists of a detailed investigation (using the usual fact-finding techniques) of the
workings of the system currently in use, whether manual or computerised. The analyst must
become familiar with:

what the system is supposed to do.

whether or not, under current conditions, it actually does it.
what constraints the system operates under.
what controls are imposed on it.
what type of data is processed.
exception circumstances.
problems with present working conditions.

This stage should result in detailed models of what the existing system does (if there is one)
and models of what the new system will do. This stage should also produce a list of
requirements for the new system (i.e. a requirements specification).
To develop the models of the system, this stage uses techniques and aids such as Data Flow
Diagrams, Entity Relationship Models, Entity Life Histories, Data Dictionaries, Structured
English, Decision Tables, and Decision Tress.
4. Systems Design
Using the facts and models from the Feasibility Study and Analysis stages, a design for the
new system is developed. At this stage, the models from analysis are amended to incorporate
any new requirements (for the new system) and any inefficiencies or mention of physical
aspects are removed. Both of these are legacies of having used an existing physical system as
the basis for analysis. The result is that the design for the new system should eliminate the
problems of the old system. Systems Design shows how the new system will be
implemented (i.e. a design for the new system is produced).
In their design of the new system, analysts have to:

Select the hardware will be needed to implement the new system.

Write specifications of new programs or amendments to existing ones in terms of what
they must do and what languages they should be written in. Programs can be specified
using Structure Charts.
Specify a database structure, what data should it contain, and what queries will be made
of it.
Provide details of input data, outputs, processes, security and backup provisions,
implementation and testing plans, file structures, etc.
Design user interfaces.
Develop user procedures which will instruct the users how to make the most of their new
system.
Develop cost estimates and an implementation schedule.

5. Implementation
In this stage, individual system components are built, i.e. programs are written, the database
is created etc. System components are tested individually and then linked and tested again to
ensure that they hang together properly without causing the system to crash. The user
interface, i.e. the screens which link the user with the system are developed. Users are
introduced to the system and encouraged to voice their opinions on it. The hardware
specified in Systems Design is acquired and installed. Targeted training and education are
provided for staff. Historical data is loaded into the system.
6. Maintenance (and Review)
This stage is ongoing throughout the useful life of the system and involves correcting faults
which are not detected during testing and making enhancements to the system in order to
satisfy new requirements. This is the most expensive part of the life cycle and, in order to
minimise costs, every effort should be made during earlier stages to get the requirements right
first time and to trap as many errors during testing as is possible.