Page 87 -

54 Part 1 • SyStemS analySiS FundamentalS

Figure 3.3
The Three Key Elements of Feasibility
The three key elements of
feasibility are technical, economic, Technical Feasibility
and operational feasibility. Add on to present system
Technology available to meet users’ needs

Economic Feasibility
Systems analysts’ time
Cost of systems study
Cost of employees’ time for study
Estimated cost of hardware
Cost of packaged software or software development

Operational Feasibility
Whether the system will operate when put in service
Whether the system will be used

At the same time, the analyst can ask whether the organization has staff who are technically
proficient to accomplish the objectives. If not, can the organization hire additional programmers,
testers, experts, or others who may have different programming skills from theirs, or maybe
outsource the project completely? In addition, are there software packages available that can
accomplish the objectives, and how significantly does that software need to be customized for
the organization?
ECONOMIC FEASIBILITY. Economic feasibility is the second part of resource determination. The
basic resources to consider are your time and that of the systems analysis team, the cost of doing
a full systems study (including the time of employees you will be working with), the cost of
the business employee time, the estimated cost of hardware, and the estimated cost of software,
software development, or software customization.
The organization must be able to see the value of the investment it is pondering before com-
mitting to an entire systems study. If short-term costs are not overshadowed by long-term gains
or if the project produces no immediate reduction in operating costs, the system is not economi-
cally feasible and should not proceed further.
OPERATIONAL FEASIBILITY. Suppose for a moment that technical and economic resources are both
judged adequate. The systems analyst must now consider the operational feasibility of the requested
project. Operational feasibility is dependent on the human resources available for the project and
involves projecting whether the system will operate and be used once it is put into service.
If users are virtually wed to the present system, see no problems with it, and generally are
not involved in requesting a new system, resistance to implementing the new system will be
strong. The new system has a low chance of becoming operational.
Alternatively, if users themselves have expressed a need for a system that is operational more
of the time which is more efficient and more accessible, chances are better that the requested sys-
tem will eventually be used. Much of the art of determining operational feasibility rests with the
user interfaces that are chosen, as we see in Chapter 14.
Estimating Workloads
The next step in ascertaining hardware needs is to estimate workloads. Thus, systems analysts
formulate numbers that represent both current and projected workloads for the system so that
any hardware obtained will be capable of handling current and future workloads.
If estimates are accomplished properly, the business should not have to replace hardware
solely due to unforeseen growth in system use. (Other events, however, such as superior tech-
nological innovations, may dictate hardware replacement if the business wants to maintain its
competitive edge.)
Out of necessity, workloads are sampled rather than actually put through several computer
systems. The guidelines given in Chapter 5 can be of use here because in workload sampling,
the systems analyst is taking a sample of necessary tasks and the computer resources required to
complete them.