Unit 3 System Planning

Lesson Structure
3.0 Objective
3.1 Introduction
3.2 Fact Finding Techniques
3.2.1 Interviews
3.2.2 Group Discussion
3.2.3 Site Visits
3.2.4 Presentations
3.2.5 Questionnaires
3.3 Issues involved in feasibility study
3.3.1 Technical Feasibility
3.3.2 Operational Feasibility
3.3.3 Economic Feasibility
3.3.4 Legal Feasibility
3.4 Cost Benefit Analysis
3.5 Preparing Schedule
3.6 Gathering Requirements of a System
3.7 Joint Application Development
3.8 Prototyping
3.9 Summary
3.10 Questions for Exercise
3.11 Suggested Readings

(41)
 System Planning

3.0 Objective
After going through this unit you will learn:
l Different types of fact finding techniques
l Feasibility study
l Different types of feasibility study
l Cost benefit analysis and
l Gathering requirements of a system

3.1 Introduction
To study any system the analyst needs to do collect facts and all relevant
information. the facts when expressed in quantitative form are termed as data.
The success of any project is depended upon the accuracy of available data.
Accurate information can be collected with help of certain methods/
techniques. These specific methods for finding information of the system are
termed as fact finding techniques. Interview, Questionnaire, Record View and
Observations are the different fact finding techniques used by the analyst.
The analyst may use more than one technique for investigation. 

3.2 Fact Finding Techniques

After obtaining the background knowledge, the analyst begins to collect
data on the existing system’s outputs, inputs and costs. To do fact finding,
the analyst does the following
l Interviews personnel
l Prepares questionnaires
l Observe the current system
l Gathers forms and documents currently in use.
l Determines the flow of data through the system, and
l Clearly defines the system requirements
Need for Fact Finding
Normally, each and every business house or any organization has its own
rules and procedures to run and manage it. When a system needs to be
developed, the systems analyst needs to know the requirements of the system.
Depending on these requirements, the system has to be developed.
3.2.1 Interviews
By studying the organization chart, analyst can confidently schedule
interviews with key personnel involved with the system. There should be
preliminary interviews, and after that detailed interview with people who
actually operate the system. Not only will these people use the newly
(42)
 System Planning

developed system, but they also may be the ones most afraid of change,
especially if they feel the computer might replace them. Like an investigative
reporter trying to discover the who, what, when, why and how of a store, the
analyst should conduct the interview in such a way that people provide honest
descriptions of their jobs.
The following questions can help accomplish this goal
l Who is involved with what you do?
l What do you do?
l Where do you do it?
l Why do you do it the way you do?
l How do you do it?
l Do you have suggestions for change?
Interviews help gather vital facts about existing problems, such as lack
of quality control or sufficient security. But they also allow the analyst to
involve people in change, easing them into it. Always and for all situations,
interviews are not appropriate fact finding methods. It has both advantages
and disadvantages.
Advantages
V Interviews permit the systems analyst to get individual’s views and
get the specific problem work wise and operation wise.
V Interviews allow the systems analyst to obtain a better clarity of the
problem due to feedback from the interviewees.
V In the process of interviews, the interviewer has time and scope to
motivate the interviewee to respond freely and openly.
V Interviews allow the systems analyst to understand the user
requirements and to know the problems faced by the user with the
current system.
V It is an effective technique to gather information about complex
existing systems.
Disadvantages
V Interviews are very time consuming.
V Success of interviews, in most of the cases, depends on the systems
analyst’s interpersonal relationship skills.
V Sometimes, interviews may be impractical due to the location of
interviewees.
Types of Interviews
There are two types of interviews:
1. Structured Interviews
2. Unstructured Interviews

(43)
 System Planning

In structured interviews, there is a specific set of questions to be asked

to an interviewee. In the case of unstructured interviews, there are few specific
questions pertaining to an interviewee. But, you have questions which are
common to all interviewees. Unstructured interviews are conducted with only
a general goal or subject in mind.
Conducting Interview is an art. The success in interview depends on
selecting the individual, preparing for the interview, creating situation in
which the answers offered are reliable and creating a situation in which
opinion can be given without any fear of being criticized by others.

Arranging Interview
the system analyst should prepare properly for the interview. He should
select place of interview, time of interview in such a way so that there will
be minimal interruption. Always, it is important to take appointment with
the interviewee. Time to be spent during interview varies from project to
project. The higher the management level of the interviewee, the less the time
to be scheduled for the interview.
Guidelines for conducting interviews :
For a successful interview, the steps to be followed are given below:

Introduction
During introduction, the analyst should introduce himself by focusing
on purpose of the interview and the confidential nature of interview. Also,
this is the phase wherein first impressions are formed and pave way for the
success of the remaining part of the interview.

Asking questions
Questions should be asked exactly as these are worded in case of
structured interview. Rewording may modify or bias the response. Always,
questions have to asked in the same sequence as prepared.

Recording the interview

Record of the interview must be kept mentioning the source of the data
and its time of collection. Sometimes, the analyst cannot remember the source
of the data which may attribute to the invalid sources.

Doing a final check

After the interview has been completed, the deliberations made during
the interview should be put in the form of a report. The report of the interview
has to be sent to the interviewee for his/her signature. If any discrepancies
are found or any modifications are to be done, these can be done at this point
of time.

(44)
 System Planning

3.2.2 Group Discussions

In group discussion, a group of staff members are invited who are
expected to be well versed in their own wings of the organization. The analysts
will have a discussion with the members for their views and responses to
various queries posed by them.
In this process, individuals from different sections gather together and
will discuss the problem at hand. Ultimately, they come to an optimum
solution. In group discussion, the problems of all sections are taken care of
most of the cases, solutions are found which are acceptable to everyone. The
main disadvantage of group discussion is that it is very difficult to get all the
concerned people together at a time. But, the major advantage is that a
mutually acceptable solution can be found.
3.2.3 Site Visits
The engineers of the development organization visit the sites. Usually,
the systems analysts visit sites to get first hand information of the working
of the system. In this technique, systems analyst watches the activities of
different staff members to learn about the system. When there is confusion
about the validity of data collected from other sources, the systems analyst
uses the method of site visits. The main objective of site visit is to examine
the existing system closely and record the activities of the system.
Advantages
1. The process of recording facts site visits is highly reliable.
2. Sometimes, site visits take place to clear doubts and check the
validity of the data.
3. Site visit is inexpensive when compared to other fact finding
techniques.
4. In this technique, systems analyst will be able to see the processes
in the organization at first hand.
5. The systems analyst can easily understand the complex processes
in the organization.
Disadvantages
1. People usually feel uncomfortable when being watched; they may
unwillingly perform their work differently when being observed.
2. Due to interruptions in the task being observed, the information that
is collected may be inaccurate.
3. Site visits are done during a specific period and during that period,
complexities existing in the system may not be experienced.
4. There may be scheduling problems for the systems analysts when
the activities take place during odd hours.

(45)
 System Planning

5. Sometimes, people may be more careful to adopt the exact

procedure which they do not typically follow.
Guidelines for site visit
Site visits are to be conducted where the work load is normal. After
studying the work and normal work load, systems analyst can observe the
work at peak hours to see the effect caused by increased volumes. The
systems analyst should collect the input /output form, documents at the time
of his/her visit. The following guidelines need to be followed at the time of
observation and site visit:
1. Keep a low profile at the time of site visit.
2. Take necessary permissions from appropriate officials to conduct site
visit.
3. Inform the individuals who will be observed at the time of site visit.
4. Take notes of the study of site visit immediately.
5. Do not make any assumptions.

3.2.4 Presentations
It is another way of finding the facts and collecting data. Presentation
is the way by which the systems analyst gathers first hand knowledge of the
project. The customer makes a presentation of the existing system or about
the organization. Participants in the meeting are representatives from the IT
company and key personnel of the client organization. When a company
needs to develop a software project, it may present its requirements for IOE
(interest of expression) from the interested IT Company. In that case, the
client presents his/her requirements. Based on the requirements, the IT
companies make prototype and show the demo of the prototype. It is very
difficult to obtain information in detail from a presentation. But, information
available through presentation is sufficient to develop a prototype.
Presentation is made by the concerned department in consultation from other
departments and senior officials

3.2.5 Questionnaires
Questionnaires economically gather data from both large and small group
of people develpoment of questionnaires requires in depth planning, and
usually more than one draft is necessary. Questionnaire design is critical.
Questions should be short, easy to understand, unbiased, nonthreatening
and specific. To make sure questions will stimulate needed information, the
analyst can test them with one or two outsiders before widespread
distribution.

(46)
 System Planning

The analyst should send questionnaires to everyone involved with the

system. A questionnaire works particularly well when the analyst must gather
data from a large number of people, when the analyst must ask everyone the
same questions or when facts must be collected from people, such as
suppliers, who do not work for the organization.
Questions may be of four types:
1. Multiple choice: this gives respondents a specific set of potential
answers. The format is ideal for computer tabulating,
2. Open ended: respondents must answer the question in their own
words. Space is provided under each question for response.
3. Rating: this is similar to multiple choice except that respondents
must rate their satisfaction.
4. Rank : rank reqires respondents to priortise their responses from
high to low or on a percentage basis
Advantages
1. It is an inexpensive means of collecting the data from a large group
of individuals.
2. It requires less skill and experience to administer questionnaires
3. Proper formulation and interaction with respondents leads to
unbiased response from the customers.
4. Customers can complete it at their convenience.
5. Responses can be tabulated and analyzed quickly .
Disadvantages
1. Sometimes, the number of respondents is low.
2. There is no guarantee that the respondents will answer all the
questions.
3. Sometimes, the individual may misunderstand the question. In that
situation, the analyst may not get correct answer.

3.3 Feasibility Study

The feasibility study is an evaluation and analysis of the potential of a
proposed project. It is based on extensive investigation and research to
support the process of decision making.
Feasibility is a process that identifies , describes and evaluates proposed
system and selects the best system for the job. During the study, the problem
definition is solved and all aspects of problem to be included in the system
are determined. Size of project, cost and benefits are also estimated with
greater accuracy. The result of feasibility study is simply a report which is a
formal document detailing the nature and scope of the proposed solution.

(47)
 System Planning

Feasibility study starts from the preliminary investigation phase. At this

stage, the analyst estimates the urgency of the project and estimates the
development cost.
The next check point is problem analysis. At this stage, the analyst
studies current system. S/he does it to understand the problem in the better
way. It helps him/her to make better estimates of development cost, and also
to find out the benefits to be obtained from the new system. In feasibility
analysis, we have to study the following.
1. Technical feasibility
2. Operational feasibility
3. Economic feasibility
4. Legal feasibility
3.3.1 Technical Feasibility
This is concerned with specifying equipment and software that will
successfully satisfy the user requirement. The technical needs of the system
may vary considerably, but might include:
The facilty to produce outputs in a given time.
Response time under certain conditions.
Ability to process a certain volume of transaction at a particular speed
Facility to communicate data to distant location.
In examining technical feasibility, configuration of the system is given
more importance than the actual make of hardware. The configuration should
give the complete picture about the system’s requirements. How many
workstations are required, how these units are interconnected so that they
could operate and communicate smoothly. What speeds of input and output
should be achieved at particular quality of printing. This can be used asa basis
for the tender document against which dealers and manufacturers can later
make their equipment bids. Specific hardware and software products can then
be evaluated keeping in view with the logical needs.
At the feasibility stage, it is desirable that two or three different
configurations will be pursued that satisfy the key technical requirements
but which represent different levels of ambition and cost. Investigation of
these technical alternatives can be added by approaching a range of suppliers
for preliminary discussions. Out of all types of feasibility technical feasibility
is the most difficult to determine.
3.3.2 Operational Feasibility
It is mainly related to human organizational and political aspects. The
points to be considered are.
(48)
 System Planning

l What changes will be brought with the system.

l What organizational structures are distributed.
l What new skills will be required? Do the existing staff members have
these skills? If not, can they be trained in due course of time?
Also, there are other issues related with operational feasibility.
Information
The system needs to provide adequate, timely, accurate and useful
information. It should be able to supply all the useful and required
information to all levels and categories of users.
Response time
It needs to study the response time of the system in term of throughput.
It should be fast enough to give the required output to the users.
Accuracy
A software system must operate accurately. It means that it should
provide value to its users. Accuracy is the degree to which the software
performs its required functions and gives desired output correctly.
Security
There should be adequate security to information and data. It should
be able to protect itself from fraud.
Services
The system needs to be able to provide desirable and reliable services
to its users.
Efficiency
The system needs to be able to use maximum of the available resources
in an efficient manner so that there are no delays in execution of jobs.
3.3.3 Economic Feasibility
Economic analysis is most frequently used technique for evaluating the
effectiveness of a proposed system. More commonly known as cost benefit
analysis. The procedure is to determine the benefits and savings that are
expected from a proposed system and compare them with costs. If benefits
outweigh costs, a decision is taken to design and implement the system,
otherwise further justification or alternative in the proposed system will have
to be made if it is to have a chance of being approved. This is an ongoing
effort that improves in accuracy at each phase of the system life cycle.
3.3.4 Legal Feasibility
Legal feasibility studies issues arising out of the need to the development
of the system. The possible consideration might include copyright law, labour
law, antitrust legislation, foreign trade, regulation, etc. Contractual obligation
(49)
 System Planning

may include the number of users who will be able to use the software. There
may be multiple user’s licences, single user licences, etc. Legal feasibility
plays a major role in formulating contracts between vendors and users. If the
ownership of the code is not given to the user, it will be difficult to install it
without proper permission to other systems. Another important legal aspect
is that whenever an IT company and the user company do not belong to the
same country then the tax laws, foreign currency transfer regulations, etc.,
have to be taken care of.

3.4 Cost Benefit Analysis

We can define cost benefit analysis as:
1. That method which we find and estimate the value of the gross
benefits of a new system specification.
2. That method by which we find and determine the increased
operating costs associated with the gross benefits.
3. The subtraction of these operating costs from the associated gross
benefits to arrive at net benefits.
4. Those methods by which we show the time- phased relationship
between net benefits and development costs as they relate to cash
flow, payback on investment.
In economic feasibility, cost benefit analysis will be done. There are two
types of costs associated with a project: The costs involved with development
of the system and costs associated with operation and maintenance of the
system. System development cost can be estimated at the time of planning
of the system and it should be refined in different phases of the project.
Maintenance and operation costs are to be estimated before hand. At the
same time, these estimations are bound to change as the requirements
change during the development process. After the implementation, these
costs may increase or decrease depending on the nature of updations done
to the system. System development cost is one time cost, but maintenance
and operating costs are recurring costs. Different costs are:
1. Cost of human resources
It includes the salaries of system analysts, software engineers,
programmers, data entry operators, operational, and clerical staff. In other
words, the amount that is going to be spent on all the people involved.
2. Cost of infrastructure
The cost of infrastructure including those of computers, cables, software,
etc., comes under this head.

(50)
 System Planning

3. Cost of training
Both the developing staff and operating staff need to be trained for new
technologies and new system. So, the training cost has to be considered for
calculating the cost of the system.
There are two components in economic feasibility: costs and benefits.
The cost consists of tangible hardware, software costs, cost of human
resources and some intangible costs. Tangible costs are saved by the usage
of the system. Intangible costs are saved by the quality of the system. Also,
application of system should lead to efficiency. When the quality of the
system is high, the effectiveness of the services provided by the organizations
increase. If a choice has to be made between efficiency and effectiveness then
it is better to do the right thing inefficiently than to do wrong thing efficiently.
The tangible benefits are those which can be quantified easily. They can be
measured in terms of savings or profits. On the other hand, in the case of
intangible benefits, it is difficult to quantify. Examples of intangible benefits
are improving company goodwill, improving employee moral, better decision
making, etc.

3.5 Preparing Schedule

A system development process scheduling is an activity that distributes
estimated effort according to the planned project duration by allocating the
effort to specific software engineering tasks. But, at the early stage of the
project, macroscopic schedule is developed. This schedule identifies all major
activities of the project. As the project progresses, each entity of macroscopic
schedule is refined into a detailed schedule. For a systems development,
scheduling is meant for setting an end date to the project(s).Systems analysts
have to take care of schedule feasibility of the system. The purpose of
schedule feasibility is to understand the time frames and dates of completion
of different phases of the project. It means that the project can be completed
and be operational so that it will meet the needs of the user requirements.
In most cases, missing the deadline may invite penalties. A systems
analyst has to remember the schedule feasibility at the time before entering
into any agreement with client regarding the delivery schedules. At the project
planning stage, feasibility of conforming to the schedule will be studied by
the analyst. To take a decision, factors such as expected team size, availability
of resources, sub-contracting or outsourcing of activities have to be
considered. Scheduling feasibility will be reassessed during the
commencement of each phase

(51)
 System Planning

3.6 Gathering Requirements of System

Finalizing the requirements of the system to be built forms the backbone
for the ultimate success of the project. It not only includes ascertaining the
functions, but also the constraints of the system. The later part is very
important as the customer needs to be very clear about the services that are
going to be offered by the system. This will avoid any conflicts during the
delivery or intermediate meetings with the client as the client assumes that
the system provides those functions which are actually constraints of the
system.
When the requirements of the system are inaccurate, it may lead to the
following problems:
1. Delivery schedules may be slipped.
2. Developed system may be rejected by the client leading to the loss
of reputation and amount spent on the project.
3. System developed may be unreliable.
4. Overall cost of the project may exceed the estimates.
There are different ways of finding the system requirements. Two of them
are joint application development and prototyping.

3.7 Joint Application Development

It is defined as a structured approach in which users, managers, and
analysts work together for several days in a series of intensive meetings to
specify or review system requirements. The important feature of JAD is joint
requirements planning, which is a process whereby highly structured group
meetings are conducted to analyze problems and define requirements.
The typical participants in a JAD are listed below:
JAD session leader: The JAD leader organizes and runs the JAD. This
person is trained in group management and facilitation as well as system
analysis. The JAD leader sets the agenda and sees that it is met. The JAD
leader remains neutral on issues and does not contribute ideas or opinions
but rather concentrates on keeping the group on the agenda, resolving
conflicts and disagreements, and soliciting all ideas.
Users: The key users of the system under consideration are vital
participants in a JAD. They are the only ones who have a clear understanding
of what it means to use the system on a daily basis.
Managers: The role of managers during JAD is to approve project
objectives, establish project priorities, approve schedules and costs and
approve identified training needs and implementation plans.

(52)
 System Planning

Sponsors: A JAD must be sponsored by someone at a relatively high level

in the company i.e. the person from top management. If the sponsor attends
any session, it is usually at the very beginning or at the end.
Systems Analysts: Members of the systems analysis team attend the JAD
session although their actual participation may be limited. Analysts are there
to learn from customers and managers, but not to run or dominate the
process.
Scribe: The scribe takes down the notes during the JAD sessions. This
is usually done on a personal computer or a laptop. Notes may be taken using
a word processor. Diagrams may directly be entered into a CASE tool.
IS staff like systems analysts, other IS staff such as programmers,
database analysts, IS planners and data centre personnel may attend to learn
from the discussions and possibly to contribute their ideas on the technical
feasibility of proposed ideas or on technical limitations of current systems.
The following are the various benefits of Joint Application Development:
l actively involves users and management in project development,
reduces the amount of time required to develop a system, and
l incorporates prototyping as a means for confirming
requirements and obtaining design process.

3.8 Prototyping
The third strategy for determining user information requirements is used
when the user cannot establish information needs accurately before the
information system is built.
The reason could be the lack of an existing model n which to base
requirements or a difficulty in visualizing candidate systems. In this case, the
user needs to anchor on reallife systems from which adjustments can be
made. Therefore, the iterative discovery approach captures an initial set of
information requirements and builds a system to meet these requirements.
As user gain experience in its use, they request additional requirements or
modifications (iterations), in the system in essence, information requirements
are discovered by using the system. Prototyping is suitable in environments
where it is difficult to formulate a concrete model for defining information
requirements and where the information needs of the usr are evolving, such
as in DSS.
Which of the three strategies is selected depends on uncertainties in the
process of determining information requirements – that is, uncertainly with
respect to the stability of information requirements, the user’s ability to
articulate information requirements, and the ability of the analyst to elicit
requirements and evaluate their accuracy. Thus, the asking strategy is

(53)
 System Planning

appropriate for low- uncertainty information requirements determinations,

whereas the prototyping strategy is appropriate for high uncertainty
information requirements determination.

3.9 Summary
The process of systems planning is a critical activity in the life of a project.
Here, we have focused on determination of requirements, gathering of
information about the existing system. There are many techniques for
requirements determination which include interviews, questionnaires, group
discussions, site visits, and presentations. One or more of the above
techniques are used to gather adequate information about the current system.
Each technique has its own advantages and disadvantages. In personal
interview, the systems analyst gathers information through face to face
interaction. It is very common and simple method of fact finding. In a group
discussion, a group of individuals is called from different work groups. In this
method, problems of all the sections are discussed and a suitable and
acceptable solution is arrived at. In the process of site visits, the systems
analyst watches the activities and learns about the system. Questionnaires
are special type of documents which allow the system analyst to collect
information from the respondent.
In this unit, the process of study of feasibility of developing the system
is examined. In feasibility study, it is stated whether the project assessment
can be accepted for development or is to be rejected for its infeasibility. The
key activity in the project planning is the assessment of different feasibility
issues associated with the project. It includes economic, technical, operational
and legal issues. The economic feasibility judges the cost effectiveness of the
project.
The benefit consists of saving the tangible costs by using the system and
the intangible costs by improving the quality of service. In operational
feasibility, systems analyst assesses the degree to which the proposed system
solves business problem or takes advantage of business opportunity. The legal
issues to be considered are copyright law, antitrust legislation, foreign trade
legislation, etc.
There are several modern information gathering techniques used by the
systems analyst. Some of them are: Joint Application Development (JAD) and
Prototyping. JAD is a structured process in which users, managers, and
analysts work together through a series of meetings to specify system
requirements

(54)
 System Planning

3.10 Practice Questions

1. What are the different fact finding techniques? Explain.
2. What are the issues involved in feasibility study?
3. What are the different feasibility study? Explain.
4. Define cost benefit analysis.

3.11 Suggested Readings

1. Alan Dennis, Barbara Haley Wixom; Systems Analysis and
Design;John Wiley & Sons;2002.
2. Joey George, J. Hoffer and Joseph Valacich; Modern Systems
Analysis and Design; Pearson Education;Third Edition; 2001.
3. Elias M. Awad; Systems Analysis and Design; Galgotia Publications;
Second Edition; 1997
4. Perry Edwards; Systems Analysis and Design; McGraw Hill
Publication;1993.

Referenced Link
1. http://systemanalysisanddesign.blogspot.in/
2. en.wikipedia.org/wiki
3. en.wikipedia.org/wiki/Systems_development_life_cycle
4. www.tutorialspoint.com


(55)