TOPIC 3: SYSTEM’S

ANALYSIS
BAC 3110
ACCOUNTING INFORMATION SYSTEMS 2
Learning Objectives
• Various types of feasibility analysis
• Calculation for economic feasibility
• Key issues in system analysis
• Steps in the systems analysis
• initial investigation,
• systems survey,
• feasibility study,
• information needs and systems requirements, and
• systems analysis report
FEASIBILITY ANALYSIS- PART 1
• During the systems analysis phase, a feasibility
study (aka, a business case) is prepared and is
updated during the remaining steps in the SDLC.
• The extent of the feasibility study depends on the
size and nature of the system.
• Feasibility team should include:
• Management
• Accountants skilled in controls and auditing
• Systems personnel
• Users
FEASIBILITY ANALYSIS
• The feasibility study and its updates are used by the
steering committee as the project proceeds to decide
whether to:
• Terminate the project
• Proceed
• Proceed if specific problems are resolved
FEASIBILITY ANALYSIS
• Five aspects need to be considered during a
feasibility study:
• Technical feasibility
• Is the technology there to do it?
• Legal feasibility
• Does it comply with legal, regulatory, and contractual
obligations?
• Operational feasibility
• Do we have people who can do it, and will it get used?
• Scheduling feasibility
• Can it be done in time?
• Economic feasibility
• Will the benefits exceed the costs?
FEASIBILITY ANALYSIS
Technical Feasibility
• In evaluating technical feasibility, a well-established and understood
technology represents less risk than an unfamiliar one.
• The use of technology that is new (first release) and unfamiliar to
systems professionals who must install and maintain it, or that is a
hybrid of several vendors’ products, is a more risky option.

Legal Feasibility
• The evaluator should be concerned that the conceptual design
recognizes critical control, security, and audit trail issues and that the
system does not violate laws pertaining to rights of privacy and/or the
use and distribution of information.
FEASIBILITY ANALYSIS
Operational Feasibility
• The availability of well-trained, motivated, and experienced users is
the key issue in evaluating the operational feasibility of a design.
• If users lack these attributes, the move to a highly technical
environment may be risky and will require extensive retraining
• This may also affect the economic feasibility of the system.

Scheduling Feasibility
• At this point in the design, the system evaluator is in a better position
to assess the likelihood that the system will be completed on
schedule.
• The technology platform, the systems design, and the need for user
training may influence the original schedule
FEASIBILITY ANALYSIS
• Calculating economic feasibility costs and
benefits
• Economic feasibility is probably the most important and
frequently analyzed aspect.
• This examination requires a careful investigation of
costs and benefits.
• It typically uses a capital budgeting model that
considers:
• Cost savings and other benefits
• Initial outlay costs
• Operating costs
• Other costs
FEASIBILITY ANALYSIS
• When possible, benefits and costs should be estimated
and included even if they are not easily quantifiable.
• If some costs and benefits cannot be accurately
estimated, they should at least be listed, along with the
likelihood of their occurrence and their expected impact.
FEASIBILITY ANALYSIS
Perform Cost-benefit Analysis
• Cost-benefit analysis helps management determine whether (and by how
much) the benefits received from a proposed system will outweigh its costs.

• This technique is frequently used for estimating the expected financial value of
business investments.

• There are three steps in the application of cost-benefit analysis: identifying

costs, identifying benefits, and comparing costs and benefits.

Identify Costs
• One-time costs include the initial investment to develop and implement the
system.

• Recurring costs include operating and maintenance costs that recur over the
life of the system.
FEASIBILITY ANALYSIS
One-Time Costs
• Hardware Acquisition. This includes the cost of mainframe
servers, PCs.

• Site Preparation. This involves such frequently overlooked

costs as building modifications.

• For example, adding air-conditioning or making structural

changes; equipment installation, which may include the
use of heavy equipment; and freight charges.
FEASIBILITY ANALYSIS
• Benefits might include:
• Cost savings.
• Improved customer service, productivity, decision making, or data
processing.
• Better management control.
• Increased job satisfaction and employee morale.

• A rigorous cost-benefit analysis is a good strategy for

ensuring the benefit of new information technology exceeds
the cost.
FEASIBILITY ANALYSIS
• Costs might include:
• Equipment costs
• Initial outlay plus ongoing operating costs.
• Software costs
• Costs of acquiring, maintaining, supporting, and operating.
• Human resource costs
• Salaries, as well as costs of hiring, training, and relocating staff.
• Site preparation costs.
• Installation and conversion costs.
• Supplies.
• Overhead.
• Financial charges.
• The primary operating cost is maintaining the system.
• Makes up 65–75% of the organization’s system efforts.
FEASIBILITY ANALYSIS
• Capital budgeting

These are three common approaches from a capital budgeting

perspective to analyze if a potential IS project is economically feasible.

• For the payback period approach, the project with the shortest
payback period is usually selected.
• For the NPV approach, the project with the highest positive NPV is
usually selected.
• For the IRR approach, the project with the highest percent of IRR
usually selected.
FEASIBILITY ANALYSIS
• Capital budgeting
• Most organizations use a capital budgeting return on investment
technique to evaluate the economic merits of different system
alternatives.
• There are three commonly used techniques:
• Payback period

• Calculates the number of years before the new savings from

the project equal the initial cost of the investment.
• Select projects with shorter payback periods.
FEASIBILITY ANALYSIS
• Capital budgeting
• Most organizations use a capital budgeting return on investment
technique to evaluate the economic merits of different system
alternatives.
• There are three commonly used techniques:
• Payback period
• Net present value (NPV)

• Estimate future cash flows with discounted rate for time

value of money.
• Calculates and sums the discounted future cash flows of the
costs and benefits.
• Select projects with higher positive NPV.
FEASIBILITY ANALYSIS
• Capital Budgeting
• Most organizations use a capital budgeting return on investment
technique to evaluate the economic merits of different system
alternatives.
• There are three commonly used techniques:
• Payback period
• Net present value (NPV)
• Internal rate of return (IRR)

• Calculates the effective interest rate that would result in a

net present value of zero for the project.
• It means that the interest rate that makes the present value
of total costs equal to the present value of total earnings.
• Select projects with higher IRRs.
FEASIBILITY ANALYSIS
• Reactions to change can be improved by observing the
following guidelines:
• Meet user’s needs with respect to the form, content, and volume of
system output.
• Keep communication lines open. Managers and users should be
fully informed about:
• What changes are being made
• Why
• How it will benefit them
• Who to contact with questions
FEASIBILITY ANALYSIS
• Maintain a safe and open atmosphere.
• If employees become hostile, it’s an uphill battle you probably won’t win.
• Obtain management support.
• Allay fears.
• To the extent possible, reassure employees that no major job losses or
responsibility shifts will occur.
• If employees are terminated, severance pay and outplacement services
should be provided.
FEASIBILITY ANALYSIS
• Solicit user participation.
• It is ego enhancing, challenging, and intrinsically satisfying.
• Users who participate will be more committed to using the system.
• Provide honest feedback.
• Explain which suggestions are and are not being used and why.
• Make sure users understand the system.
• Don’t underestimate training needs.
FEASIBILITY ANALYSIS
• Humanize the system.
• Employees shouldn’t feel the computer is controlling them or has
usurped their positions.
• Describe new challenges and opportunities.
• The system can provide greater job satisfaction and increased
opportunities.
• Reexamine performance evaluation.
• Are performance standards and criteria realistic in light of the change?
• Test the system’s integrity.
• It’ important to minimize bad impressions
FEASIBILITY ANALYSIS
• Avoid emotionalism.
• Emotional issues should be allowed to cool, handled in a
non-confrontational manner, or sidestepped.
• Present the system in the proper context.
• Address the concerns of the people to whom you’re
speaking, not the concerns of management or developers.
• Control the user’s expectations.
• Don’t oversell, and be realistic.
• Keep the system simple.
• Avoid complex systems that cause radical changes.
FEASIBILITY ANALYSIS
 Ignoring the preceding steps can leave to behavior issues
that are difficult or impossible to reverse.
SYSTEMS ANALYSIS- PART 2
• When a new or improved system is needed, a written
request for systems development is prepared. That
request describes:
• The current system’s problems.
• The reasons for the proposed changes.
• The goals and objectives of a proposed system.
• The anticipated benefits and costs.
SYSTEMS ANALYSIS
• The project development team will conduct the systems
analysis in five steps:
• Initial investigation
• Systems survey
• Feasibility study
• Information needs and systems requirements
• Systems analysis report
SYSTEMS ANALYSIS
• The project development team will conduct the systems
analysis in five steps
• Initial investigation
• Systems survey
• Feasibility study
• Information needs and systems requirements
• Systems analysis report
SYSTEMS ANALYSIS
• The initial investigation is conducted to:
• Gain a clear picture of the problem or need.

• Sometimes what is thought to be the cause of the problem

is not the real source.
SYSTEMS ANALYSIS
• The initial investigation is conducted to:
• Gain a clear picture of the problem or need.
• Determine the viability of the project and expected costs and
payoffs.
SYSTEMS ANALYSIS
• The initial investigation is conducted to:
• Gain a clear picture of the problem or need.
• Determine the viability of the project and expected costs and
payoffs.
• Evaluate the scope and nature of the new AIS.

• A new AIS is useful when problems are a result of:

– Lack of information
– Inaccessibility of data
– Inefficient data processing
• A new AIS will not answer problems such as:
– A manager who has too many subordinates
– A manager who lacks organizational skills
– Failure to enforce existing problems
SYSTEMS ANALYSIS
• The initial investigation is conducted to:
• Gain a clear picture of the problem or need.
• Determine the viability of the project and expected costs and
payoffs.
• Evaluate the scope and nature of the new AIS.
• Recommend whether to proceed.

• Either:
– Initiate the project as proposed.
– Modify it.
– Abandon it.
SYSTEMS ANALYSIS
• If the project is approved:
• A proposal to conduct systems analysis is prepared.
• The project is assigned a priority and added to the master plan.
• The development team begins a survey of the existing AIS.
• The proposal will be modified as more information becomes
available.
SYSTEMS ANALYSIS
• The project development team will conduct the systems
analysis in five steps
• Initial investigation
• Systems survey
• Feasibility study
• Information needs and systems requirements
• Systems analysis report
SYSTEMS ANALYSIS
• A systems survey involves an extensive study of the
current AIS which could take weeks or months. Objectives
are:
• Gain a thorough understanding of:
• Company operations, policies, and procedures.
• Data and information flow.
• AIS strengths and weaknesses.
• Available hardware, software, and personnel.
• Make preliminary assessments of current and future processing
needs, and determine extent and nature of needed changes.
• Develop working relationships with users and build support.
• Collect data that identify user needs, conduct a feasibility
analysis, and make recommendations to management.
SYSTEMS ANALYSIS
• Data can be gathered from:
• Employees.
• Documentation such as organization charts and procedure
manuals.
• External sources such as:
• Consultants
• Customers
• Suppliers
• Industry associations
• Government agencies
SYSTEMS ANALYSIS
• Four common methods of gathering data are:
• Interviews
• Questionnaires
• Observation
• System documentation
SYSTEMS ANALYSIS
• Four common methods of gathering data are:
• Interviews
• Questionnaires
• Observation
• System documentation
SYSTEMS ANALYSIS
• Advantages of interviews:
• Can answer “why” questions.
• Can allow for follow-up and clarification.
• Provides opportunity to build positive relationships with
interviewees and support for new system.
• Disadvantages of interviews:
• Time-consuming.
• Expensive.
• Personal biases or self-interest may produce inaccurate
information.
SYSTEMS ANALYSIS
• When you do interviews:
• Make an appointment.
• Explain the purpose ahead of time.
• Indicate the amount of time needed.
• Be on time.
• Be familiar with the interviewee’s responsibilities.
• Make notes on points to cover.
• Put the interviewee at ease and let him/her do the
talking.
• Pay attention to nonverbal cues.
• Take notes and augment them with impressions after
the interview.
• Request permission to tape critical interviews.
SYSTEMS ANALYSIS
• Four common methods of gathering data are:
• Interviews
• Questionnaires
• Observation
• System documentation
SYSTEMS ANALYSIS
• Questionnaires can be used when:
• The amount of information to be gathered is small and well defined.
• The information is to be obtained from many people or from those
who are remotely located.
• The information is intended to verify data from other sources.
SYSTEMS ANALYSIS
• Advantages of questionnaires:
• Can be anonymous.
• Not time-consuming to complete.
• Inexpensive.
• Allows the subject time to think about responses.
• Disadvantages of questionnaires:
• Does not allow in-depth questions or answers.
• Does not allow follow-up or clarification.
• Does not build relationships.
• Difficult to develop.
• May be ignored or completed superficially.
SYSTEMS ANALYSIS
• Four common methods of gathering data are:
• Interviews
• Questionnaires
• Observation
• System documentation
SYSTEMS ANALYSIS
• Advantages of observations:
• Can verify how the system actually works rather than how it should
work.
• Results in greater understanding of systems.
• Disadvantages of observations:
• Time-consuming.
• Expensive.
• Difficult to interpret.
• People may alter behavior while being observed.
SYSTEMS ANALYSIS
• When you do observations:
• Identify what is to be observed and estimate the time required.
• Obtain permission.
• Explain what will be done and why.
• Don’t make value judgments.
• Take notes and document impressions ASAP.
SYSTEMS ANALYSIS
• Four common methods of gathering data are:
• Interviews
• Questionnaires
• Observation
• System documentation
SYSTEMS ANALYSIS
• Advantages of systems documentation:
• Describes how the system should work.
• Written form facilitates review and analysis.
• Disadvantages of systems documentation:
• Time consuming.
• May be elusive.
• When you examine systems documentation:
• Keep in mind that the system doesn’t always work as it
should per the documentation.
• If documentation is unavailable, it may be worthwhile to
develop it.
SYSTEMS ANALYSIS
• Once the data is gathered, document findings and model
the existing system.
• Documentation consists of:
• Questionnaire copies
• Interview notes
• Memos
SYSTEMS ANALYSIS
• Another form of documentation is a system model:
• Physical models illustrate how a system functions by describing:
• Flow of documents.
• Computer processes performed and the people doing them.
• Equipment used.
• Any other physical elements.
• Logical models illustrate what is being done regardless of how the
flow is accomplished.
SYSTEMS ANALYSIS
• When documentation is complete, analyze the existing
system:
• Evaluate the AIS’s strengths and weaknesses to develop ideas for
designing and structuring the new AIS.
• Try to retain strengths.
• Correct weaknesses.
• Sometimes, you need revolutionary, rather than evolutionary
change.
• Called reengineering.
SYSTEMS ANALYSIS
• At the end of this phase, prepare systems survey report:
• Outlines and documents the data gathered.
• Provides recommendations that result from the systems survey.
SYSTEMS ANALYSIS
• The project development team will conduct the systems
analysis in five steps:
• Initial investigation
• Systems survey
• Feasibility study
• Information needs and systems requirements
• Systems analysis report
SYSTEMS ANALYSIS
• After the systems survey, a more thorough feasibility
analysis is conducted.
• This analysis is updated regularly as the project proceeds
and costs and benefits become clearer.
SYSTEMS ANALYSIS
• The project development team will conduct the systems
analysis in five steps:
• Initial investigation
• Systems survey
• Feasibility study
• Information needs and systems requirements
• Systems analysis report
SYSTEMS ANALYSIS
 Once a project clears the feasibility hurdle, the company
identifies the information needs of AIS users and
documents systems processes, including:
- Processes
• Describes what is to be done and
by whom.
SYSTEMS ANALYSIS
 Once a project clears the feasibility hurdle, the company
identifies the information needs of AIS users and
documents systems processes, including:
- Processes
• Describes name, size, format,
- Data elements
source, and significance of
necessary data elements.
SYSTEMS ANALYSIS
 Once a project clears the feasibility hurdle, the company
identifies the information needs of AIS users and
documents systems processes, including:
- Processes
- Data elements
- Data structure • A preliminary structure showing
how the data elements will be
organized into logical records.
SYSTEMS ANALYSIS
 Once a project clears the feasibility hurdle, the company
identifies the information needs of AIS users and
documents systems processes, including:
- Processes
- Data elements
- Data structure
- Outputs • Layouts of system outputs and a
description of their purpose,
frequency, and distribution.
SYSTEMS ANALYSIS
 Once a project clears the feasibility hurdle, the company
identifies the information needs of AIS users and
documents systems processes, including:
- Processes
- Data elements
- Data structure
- Outputs
- Inputs • A copy of system inputs and a
description of their contents,
source, and who is responsible for
them.
SYSTEMS ANALYSIS
 Once a project clears the feasibility hurdle, the company
identifies the information needs of AIS users and
documents systems processes, including:
- Processes
- Data elements
- Data structure
- Outputs
- Inputs • A description of deadlines, schedules,
- Constraints security requirements, staffing
limitations, and legal requirements.
SYSTEMS ANALYSIS
 Once a project clears the feasibility hurdle, the company
identifies the information needs of AIS users and
documents systems processes, including:
- Processes
- Data elements
- Data structure
- Outputs
- Inputs
- Constraints
- Controls • Controls that are needed to ensure
accuracy and reliability.
SYSTEMS ANALYSIS
 Once a project clears the feasibility hurdle, the company
identifies the information needs of AIS users and
documents systems processes, including:
- Processes
- Data elements
- Data structure
- Outputs
- Inputs
- Documentation constraints
- Controls
• Changes in staffing, job functions,
- Reorganizations
etc., that would be necessary.
SYSTEMS ANALYSIS
• Issues:
• There is much to be specified, even for a simple AIS.
• It may be difficult to get employees to accurately articulate their
needs.
• Errors are best caught early, as the cost to correct them increases
significantly the farther you are into the project.
SYSTEMS ANALYSIS
• Systems objectives and constraints
• Many entities take a systems approach to determining information
needs and systems requirements.
• Problems and alternatives are viewed from the standpoint of the
entire organization—as opposed to a single department.
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness
• Able to help users make decisions.
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness
- Economy
• Benefits exceed costs.
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness
- Economy
- Reliability
• Data is processed accurately and
reliably.
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness
- Economy
- Reliability
- Availability
• You can access it when you need
it.
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness
- Economy
- Reliability
- Availability
- Timeliness
• More critical information is
provided first.
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness
- Economy
- Reliability
- Availability
- Timeliness
- Customer service
• Efficient and courteous.
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness - Capacity
- Economy • Can handle peak periods.
- Reliability
- Availability
- Timeliness
- Customer service
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness - Capacity
- Economy - Ease of use
- Reliability
- Availability
- Timeliness
- Customer service
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness - Capacity
- Economy - Ease of use
- Reliability - Flexibility
- Availability • Can accommodate changes.
- Timeliness
- Customer service
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness - Capacity
- Economy - Ease of use
- Reliability - Flexibility
- Availability - Tractability
- Timeliness • Easily understood.
- Customer service • Facilitates problem solving and
future development.
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness - Capacity
- Economy - Ease of use
- Reliability - Flexibility
- Availability - Tractability
- Timeliness - Auditability
- Customer service
SYSTEMS ANALYSIS
• Systems objectives must be identified, so
analysts and users can focus on those elements
most vital to success of the AIS. These may
include:
- Usefulness - Capacity
- Economy - Ease of use
- Reliability - Flexibility
- Availability - Tractability
- Timeliness - Auditability
- Customer service - Security • Available only to
authorized users.
SYSTEMS ANALYSIS
• There are often trade-offs between objectives.
• Organizational constraints make it impossible to
develop all parts of an AIS simultaneously.
• You divide it into modules that are analyzed, developed,
and installed independently.
• When changes are made, only the affected modules
need to be changed.
• The modules should be properly integrated into a
workable system.
SYSTEMS ANALYSIS
• Success often depends on the project team’s ability to
cope with organizational constraints, including:
• Requirements of governmental agencies.
• Managerial policies and guidelines.
• Lack of sufficient, qualified staff.
• Capabilities and attitudes of users.
• Available technology.
• Limited financial resources.
SYSTEMS ANALYSIS
• Strategies for determining requirements:
• One or more of the following four strategies are used to determine
AIS requirements:
• Ask users what they need

• This is the simplest and fastest strategy.

• But many people don’t realize or understand their true
needs.
• It’s sometimes better to ask them what decisions they make
and what processes they are involved in.
• Users also need to think beyond their current information
needs.
SYSTEMS ANALYSIS
• Strategies for determining requirements:
• One or more of the following four strategies are used to determine
AIS requirements:
• Ask users what they need
• Analyze existing systems

 Internal and external systems should be analyzed to avoid

reinventing the wheel.
SYSTEMS ANALYSIS
• Strategies for Determining Requirements:
• One or more of the following four strategies are used to determine
AIS requirements:
• Ask users what they need
• Analyze existing systems
• Examine existing system use

• Certain modules:
– May not be used as intended
– May be augmented by manual tasks
– May be avoided altogether
• Helps determine whether the system really needs to be
simply modified rather than replaced.
SYSTEMS ANALYSIS
• Strategies for Determining Requirements:
• One or more of the following four strategies are used to determine
AIS requirements:
• Ask users what they need
• Analyze existing systems
• Examine existing system use
• Create a prototype

• Entails roughing out a system for users to critique.

• When they see something on a screen, it’s easier to
identify what they like and don’t like.
• Goes through iterations of improving and reviewing with
users until users agree on their needs.
SYSTEMS ANALYSIS
• Documentation and approval of user requirements:
• Detailed requirements for the new AIS should be created and
documented.
• How to produce the required features is determined during the design
phases of the SDLC.
• The requirements list should be supported by sample input and output
forms and charts that make it easier to conceptualize.
• A nontechnical summary is often prepared for management.
SYSTEMS ANALYSIS
• Once user requirements have been determined and
documented, the project team:
• Meets with users.
• Explains the requirements.
• Obtains their agreement and approval.
• When an agreement is reached, user management should
sign off on the requirements.
SYSTEMS ANALYSIS
• The project development team will conduct the systems
analysis in five steps:
• Initial investigation
• Systems survey
• Feasibility study
• Information needs and systems requirements
• Systems analysis report
SYSTEMS ANALYSIS
• The last step in systems analysis is the systems
analysis report.
• Summarizes and documents the activities.
• Serves as a repository of data from which designers
can draw.
• Outlines:
• Goals and objectives of the new system.
• Scope of the project.
• How the new system fits into the company’s master plan.
• User processing requirements and information needs.
• Feasibility analysis.
• Recommendations for the new system.
SYSTEMS ANALYSIS
• A go-no-go decision is usually made three times during
systems analysis:
• During the initial investigation to determine whether to go ahead
with a systems survey.
• At the end of the feasibility study to determine whether to proceed
with the information requirements step.
• At the completion of the analysis phase to decide whether to
proceed to the next phase (conceptual design).
SYSTEMS ANALYSIS
• When systems analysis is completed, the project can
move on to:
• Conceptual design phase
• Physical design phase
• Implementation and conversion
• Operation and maintenance
 Acknowledgements
This PowerPoint presentation contains materials compiled
from various sources. Credits are hereby given to their
respective owners. Please refer to the reading list for
details.

Reminder
The lecture slides serve only as a quick learning guide.
Students are required to refer to the main textbook for
detailed elaboration.