System

Integration
and
Architecture 2

Prepared by:

RAOUL REY G. FLORES

Faculty, Institute of Information and Computer Studies

Lesson 2: The Systems Analyst & Systems Development Life Cycle

Introduction
In this lesson focuses on the project identification and initialization of system projects which
organizations identify and initiate potential projects are discussed. The first steps in the process are to
identify a project that will deliver value to the business and to create a system request that provides the
basic information about the proposed system. Next, the analysts perform a feasibility analysis to
determine the technical, economic, and organizational feasibility of the system.

Discussion

Where do project ideas come from?

A project is identified when someone in the organization identifies a business need to build a
system. A need may surface when an organization identifies unique and competitive ways of using IT.
To leverage the capabilities of emerging technologies such as cloud computing, RFID, Web 2.0
Nowadays, many new information system projects grow out of business process management
(BPM) initiatives. BPM is a methodology used by organizations to continuously improve end-to-end
business processes. Business process management can be applied to internal organizational processes and
to processes spanning multiple business partners. By studying and improving their underlying business
processes, organizations can achieve several important benefits, including:
■ enhanced process agility, giving the organization the ability to adapt more rap-idly and effectively to a
changing business environment;
■ improved process alignment with industry “best practices”; and
■ increased process efficiencies as costs are identified and eliminated from process workflows. BPM
generally follows a continuous cycle of systematically creating, assessing, and altering business
processes. Business analysts, with their in-depth business knowledge, play a particularly important role in
business process management by:
1. defining and mapping the steps in a business process,
2. creating ways to improve on steps in the process that add value,
3. finding ways to eliminate or consolidate steps in the process that don’t add value,
4. creating or adjusting electronic workflows to match the improved process maps.
The last step is particularly relevant to our discussion since the need for information systems
projects is frequently identified here. In fact, the automation of business processes (termed Business
Process Automation), is the foundation of many information technology systems. In these situations,
technology components are used to complement or substitute for manual information management
processes with the intent of gaining cost efficiencies. BPM practitioners recognize, however, that it is not
always advisable to just “pave the cow paths” by simply adding automation to speed up existing
processes (step 4 above). In many situations, Business Process Improvement results from studying the
business processes, creating new, redesigned processes to improve the process workflows, and/or utilizing
new technologies enabling new process structures (steps 2, 3, and 4 above). For example, could a retail
store’s checkout process be redesigned along the lines of the EZ Pass toll collection system on highways?
Could customers check out and pay with their mobile devices while clerks simply review the contents of
the customer’s shopping bag? Projects with a goal of business process improvement make moderate
changes to the organization’s operations, and can improve efficiency (i.e., doing things right) and
improve effectiveness (i.e., doing the right things). These types of projects involve more risk than
business process automation projects since more significant changes are made to the organization’s
operations. Business Process Management may also reveal the need for the complete revamping of the
organization’s business processes, termed Business Process Reengineering (BPR). BPR means
changing the fundamental way in which the organization operates—“obliterating” the current way of
doing business and making major changes to take advantage of new ideas and new technology.
As you might expect, BPR projects involve substantial risk due to the significant organizational
and operational changes that result. Top management support and careful management are critical
in these fairly rare types of projects. Both IT people (i.e., the information systems experts) and
business people (i.e., the subject matter experts) should work closely together to find ways for
technology to support business needs. In this way, organizations can leverage the exciting
technologies available while ensuring that projects are based upon real business objectives such
as increasing sales, improving customer service, and decreasing operating expenses. Ultimately,
information systems need to affect the organization’s bottom line (in a positive way!). When a strong
business need for an information system is recognized, often as a result of BPM, a person (or group) who
has an interest in the system’s success typically steps forward. We call this person (or group) the
project sponsor. Often, the project sponsor develops the initial vision of the new system. The
project sponsor works throughout the SDLC to make sure that the project is moving in the right direction
from the perspective of the business and serves as the primary point of contact for the project team.
Usually, the sponsor of the project is from a business function such as marketing, accounting, or finance;
however, members of the IT area also can sponsor or cosponsor a project. The size or scope of the project
often determines the kind of sponsor who is involved. A small, departmental system might be sponsored
by a single manager; however, a large, organizational initiative might be sponsored by the entire senior
management team and even the CEO. If a project is primarily technical in nature (e.g.,
improvements to the existing IT infrastructure or research into the viability of an emerging technology),
then sponsorship from IT is appropriate.
The business need drives the high-level business requirements for the system. Business
requirements describe the reasons for developing the system and outline the benefits it will provide the
organization. These requirements need to be explained at a high level so that the approval committee and,
ultimately, the project team under-stand what the business expects from the final product. Business
requirements summarize the features and capabilities the information system will have to include,
such as the ability to collect customer orders online or the ability for suppliers to receive
inventory information as orders are placed and sales are made. The project sponsor has the insights
needed to determine the business value that will be gained from the system, in both tangible and
intangible ways. Tangible value can be quantified and measured easily (e.g., 2% reduction in operating
costs). An intangible value results from an intuitive belief that the system provides important, but hard-to-
measure, benefits to the organization (e.g., improved customer service, a better competitive position).
Once the project sponsor identifies a project that meets an important business need and he or she can
identify the business requirements and business value of the system, it is time to formally initiate the
project. In most organizations, project initiation begins by preparing a system request.
A system request is a document that describes the business reasons for building a system and the
value that the system is expected to provide. The project sponsor usually completes this form as part of a
formal system project selection process within the organization. Most system requests include five
elements: project sponsor, business need, business requirements, business value, and special issues. The
sponsor describes the person who will serve as the primary contact for the project, and the business need
presents the reasons prompting the project. The business requirements of the project refer to the business
capabilities that the system will need to have, and the business value describes the benefits that the
organization should expect from the system. Special issues are included on the document as a catchall
category for other information that should be considered in assessing the project. For example, the project
may need to be completed by a specific dead-line. Project teams need to be aware of any special
circumstances that could affect the outcome of the system. The completed system request is submitted to
the approval committee for consideration.
This approval committee could be a company steering committee that meets regularly to make
information systems decisions, a senior executive who has control of organizational resources, or any
other decision-making body that governs the use of business resources. The committee reviews the
system request and makes an initial determination, based on the information provided, of whether to
investigate the proposed project or not. If so, the next step is to conduct a feasibility analysis.
Feasibility analysis guides the organization in determining whether to proceed with a project.
Feasibility analysis also identifies the important risks associated with the project that must be managed if
the project is approved.
As with the system request, each organization has its own process and format for the feasibility
analysis, but most include techniques to assess three areas:
 Technical feasibility
 Economic feasibility
 Organizational feasibility
The results of evaluating these three feasibility factors are combined into a feasibility study
deliverable that is submitted to the approval committee at the end of project initiation.

Technical feasibility is the extent to which the system can be successfully designed, developed,
and installed by the IT group. It is, in essence, a technical risk analysis that strives to answer the question:
“Can we build it?”
Risks can endanger the successful completion of a project. The following aspects should be
considered:
 Users’ and analysts’ should be familiar with the application.
 Familiarity with the technology
 Project size
 Compatibility of the new system with the technology that already exists

Economic feasibility analysis is also called a cost-benefit analysis, that identifies the costs and benefits
associated with the system. This attempts to answer the question: “Should we build the system?”

Cash Flow Analysis and Measures IT projects involve an initial investment that produces a steam of
benefits over time, along with some on-going support costs.
Cash flows, both inflows and outflows, are estimated over some future period.
Simple cash flow projection

Common methods for evaluating a project’s worth

Return on Investment The return on investment (ROI) is a calculation that measures the average
rate of return earned on the money invested in the project. ROI is a simple calculation that divides the
project’s net benefits (total benefits total costs) by the total costs. The ROI formula is: A high ROI
suggests that the project’s benefits far outweigh the project’s cost, although exactly what constitutes a
“high” ROI is unclear. ROI is commonly used in practice; however, it is hard to interpret and should not
be used as the only measure of a project’s worth.
Break-Even Point Another common approach to measuring a project’s worth is the break-even
point. The break-even point (also called the payback method) is defined as the number of years it takes a
firm to recover its original investment in the project from net cash flows. As shown in row 4 of Figure 1-
8, the project’s cumulative cash flow figure becomes positive during Year 3, so the initial investment is
“paid back” over two years plus some fraction of the third year.
ROI= (Total Benefits - Total Costs)/Total Costs
ROI= (152,000-138,000)/138,000 = 14,000/138,000 =10.14%
Break-Even Point (BEP)

BEP = Number of years of negative cash flow + (That year’s Net Cash Flow - That year’s Cumulative
Cash Flow) / That year’s Net Cash Flow
Using the values in Figure, the BEP calculation is:
BEP=2+[(41,000-14,000)/41,000] = 2+(28,000/41,000) = 2.68 years

Discounted case flows are used to compare the present value of all cash inflows and outflows for
the project in the today’s dollar terms.

Net present value (NPV): the difference between the total PV of the benefits and the total PV of the costs.
Steps to conduct an economic feasibility analysis

1. Identify Costs and Benefits

2. Assign Values to Costs and Benefits
3. Determine Cash Flow
4. Assess Project’s Economic Value
- ROI
- BEP
- NPV

Identify Costs and Benefits

The costs and benefits and be broken down in to four categories:
 Development costs
 Operational costs
 Tangible benefits
 Intangibles
Assign Values to Costs and Benefits
Once the types of costs and benefits have been
identified, the systems analysts needs to assign
specific dollar values to them.

Determine Cash Flow

A formal cost-benefit analysis usually contains
costs and benefits over a selected number or
years to show cash flow over time.
- Determine ROI
- Determine BEP
- Determine NPV

Organizational feasibility of the system

is how well the system ultimately will be
accepted by its users and incorporated into the
ongoing operations of the organization.
There are many organizational factors
that can have an impact on the project, and seasoned developers know that organizational feasibility can
be the most difficult feasibility dimension to assess.
In essence, an organizational feasibility analysis is to answer the question “If we build it, will they
come?”
One way to assess the organizational feasibility is to understand how well the goals of the project
align with the business objectives and organizational strategies.
A second way to assess the organizational feasibility is to conduct stakeholder analysis.
A stakeholder is a person, group, or organization that can affect a new system
- Project champion
- System users
- Organizational management
- Other stakeholders

SUMMARY
Project Identification and Initiation recognize a business need that can be satisfied through the
use of information technology.
System Request describes the business value for an information system.
A Feasibility Analysis is used to provide more detail about the risks associated with the proposed system.

Assessment:
Your Assessment will be uploaded Online in your Google Classroom.
Your assessment in Module 1 lesson 2 will be schedule on April 30, 2021. Be ready 1:30 PM and will
end/closed automatically at specified time.
Thank you… Stay Safe…

REFERENCE

 DENNIS, A., WIXOM, B. H., ROTH, R. M., SYSTEM ANALYSIS AND DESIGN Fifth
Edition, Copyright © 2012, 2009 John Wiley & Sons.
 Inc.http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf; accessed February,
2011.
 http://www.zdnet.com/blog/projectfailures/critique-62-trillion-global-IT-failure-stats/7695?
tag=mantle_skin;content; accessed February, 2011.