SOFTWARE ENGINEERING

PROF. DR. AMANY SARHAN

2023
1
PROJECT FEASIBILITY STUDY

2
 FEASIBILITY STUDY

• A feasibility study is a study made before committing

to a project.
• A feasibility study leads to a decision:
• go ahead
• do not go ahead
• think again
• In production projects, the feasibility study often leads
to a budget request.
• A feasibility study may be in the form of a proposal.
3
 •WHY ARE FEASIBILITY STUDIES DIFFICULT?

• Uncertainty
• Clients may be unsure of the scope of the project.
• Benefits are usually very hard to quantify.
• Approach is usually ill-defined. Estimates of resources
and timetable are very rough.
• Organizational changes may be needed.
• Therefore, feasibility studies rely heavily on the judgment
of experienced people.
• Mistakes made at the beginning of a project are the most
difficult to correct.
4
 PROJECT SCOPE

• Scope expresses the boundaries of the system:

• It will have a list of included functions
• It will have a list of excluded functions
• It will have a list of dependencies
• It will have a list of current systems to be replaced
• Confusion over scope is a common reason for clients
to be dissatisfied with a system.
• "Is that all you planned to do?" "But I assumed that
you were going to do xyz." "I can't use the system
without abc."
5
 EXAMPLE OF SCOPE CONFUSION

• A government organization, L, required a "warehouse system" to

store and make accessible large amounts of material over long
periods of time.
• An outside organization, C, built the warehouse system to store
and manipulate these material.
• BUT...
• Nobody built the sub-systems needed to organize, validate, and
to load material into the warehouse.
• L expected the warehouse system to include these sub-systems.
C considered the sub-systems separate from the warehouse
system.
• A good feasibility study would have seen this confusion.

6
 ALTERNATIVES

• • Continue with current system, enhance it, or

create new one?
• • Develop in-house, or contract out? (How will a
contract be managed?)
• Make it web-based or desktop?
• Multiple users or single user profiles?

7
 ASSESSING PROJECT FEASIBILITY

• Six Categories
• Economic
• Technical
• Operational
• Schedule
• Legal and contractual
• Political
9
 1- ASSESSING ECONOMIC FEASIBILITY

• We perform a cost – benefit analysis

• Determine benefits (two types)
A)tangible benefits
• Can be measured easily in money
• Examples
• Cost reduction and avoidance (better inventory
management)
• Error reduction (10% time correcting data entry error)
• Increased flexibility (time to manually organize data)
• Increased speed of activity
• Improved management planning and control (analysis of
data available in the system)
• Opening new markets and increasing sales opportunities
5.10
 EXAMPLE OF TANGIBLE BENEFITS WORKSHEET

A. COST REDUCTION OR AVOIDANCE 4,500

B. ERROR REDUCTION 2,500
C. INCREASED FLEXIBILITY 7,500
D. INCREASED SPEED OF ACTIVITY 10,500
E. IMPROVEMENT IN MANAGEMENT 25,000
PLANNING & CONTROL
TOTAL 50,000
5.11
 ASSESSING ECONOMIC FEASIBILITY

B) intangible benefits
• Cannot be measured easily in money
• Examples
• Increased employee morale/confidence
• Competitive necessity
• More timely information
• Encouragement of organizational learning and understanding
• Determine costs (two types)
• A) tangible costs
• Can easily be measured in money
5.12 • Example: (next page)
 EXAMPLES OF TANGIBLE COSTS

• Procurement (acquisition) start-up

• Consulting costs * O/S
• Equipment purchase * communication equipment
• Equipment installation *start-up personnel
• Site preparation
• Management & staff time

• Project-related
• Application S/W
• Software modifications
• Personnel for in-house development
• Training
• Collecting & analyzing data
• Operating
• System maintenance
• Rental of space & equipment
• Management, operation, and planning personnel
5.13
 ASSESSING ECONOMIC FEASIBILITY

• B) Intangible Costs
• Cannot be easily measured in money
• Examples:
• Loss of customer kindness/care
• Loss of employee confidence

5.14
 ASSESSING ECONOMIC FEASIBILITY

• The previous costs can be divided into two

types:
• 1) one-time costs
• Associated with project startup, initiation and
development
• Examples:
• System development
• New hardware and software purchases
• User training
• Site preparation
• Data or system conversion

5.15
 EXAMPLE OF ONE-TIME COST WORKSHEET

A. DEVELOPMENT COSTS 20,000

B. NEW HARDWARE 15,000
C. NEW (PURCHASED) SOFTWARE 5,000
D. USER TRAINING 2,500

TOTAL $42,000

5.16
 ASSESSING ECONOMIC FEASIBILITY

• 2) Recurring Costs
• Associated with ongoing use of the system
• Examples:
• Application software maintenance
• Incremental data storage expense
• New software and hardware releases
• Consumable supplies (paper,…)
• Incremental communications

5.17
 ASSESSING ECONOMIC FEASIBILITY

• Time value of money (TVM)

• The process of comparing present cash outlays to future
expected returns
• All costs & benefits must be viewed in relation to their
present value PV

PVn = Y * 1 / (1+i)n

5.18
 ASSESSING ECONOMIC
FEASIBILITY

Y1 Y2 Y3
1,500 1,500 1,500
PV 1,363.65 1,239.60 1,126.95
NPV 1,363.65 2,603.25 3,730.20 3730

• OVERALL NPV = NPV OF BENEFIT- NPV OF COST

• OVERALL ROI = OVERALL NPV / NPV OF ALL COSTS
5.19
 COMMONLY USED ECONOMIC COST-BENEFIT ANALYSIS
TECHNIQUES

• There are many techniques used to analyze the cost-

benefit information:
1- Net Present Value (NPV) uses a discount rate to establish
the present value of a project
2- Return of Investment (ROI) ratio of the net cash receipts
of the project divided by the cash outlays .
3- Break-Even Analysis (BEA) finds the amount of time
required for the cumulative cash flow from a project to
equal its initial investment

5.20
 EXAMPLE OF THE ECONOMIC
FEASIBILITY ANALYSIS

• Consider the following data that describes the

costs and benefits of a certain information
system.
• Use these data to find whether or not the system
is profitable, the breakeven point, the roi.

5.21
5.22
5.23
 Year 0 Year 1 Year 2 Year 3 Year 4 Year 5
Benefits 0 50,000 50,000 50,000 50,000 50,000
PV of Benefits 0 44,643 39,860 35,589 31,776 28,371
NPV of Benefits 0 44,643 84,503 120,092 151,867 180,239 180,239

One- time cost 42,500 0 0 0 0 0

Recurring cost 0 28,500 28,500 28,500 28,500 28,500
PV of recurring cost 0 25,446 22,720 20,286 18,112 16,172
NPV of all costs 42,500 67,946 90,666 110,952 129,064 145,236 145,236

Overall NPV 35,003

ROI 0.24

Break-even analysis
Yearly NPV cash
(42,500) 19,196 17,140 15,303 13,664 12,200
flow
Overall NPV cash
(42,500) (23,304) (6,164) 9,139 22,803 35,003
flow
5.26
 2- ASSESSING TECHNICAL FEASIBILITY

• It is the assessment of the development

organization’s ability to construct a
proposed system
• Project risk can be assessed based upon:
• Project size
• Project structure
• Development group’s experience with the application
• User group’s experience with development projects and
the application area
5.27
 ASSESSING TECHNICAL
FEASIBILITY

5.28
EFFECTS OF DIFFERENT FACTORS ON PROJECT
IMPLEMENTATION RISK
 ASSESSING OTHER PROJECT FEASIBILITY
CONCERNS

• Operational feasibility
• Assessment of how a proposed system solves
business problems or takes advantage of
opportunities
• Schedule feasibility
• Assessment of time frame and project
completion dates with respect to organization
constraints for affecting change

5.30
 ASSESSING OTHER PROJECT FEASIBILITY CONCERNS

• Legal and contractual feasibility

• Assessment of legal and contractual ramifications
(consequences) of new system {copyright, work/employment
laws, foreign trade regulations

• Political feasibility
• Assessment of key stakeholders in organization’s view toward
proposed system

5.31
 BUILDING THE BASELINE
PROJECT PLAN

• Objectives
• Assures that customer and development group have a
complete understanding of the proposed system and
requirements
• Provides sponsoring organization with a clear idea of
scope, benefits and duration of project

5.32
 BUILDING THE BASELINE
PROJECT PLAN

• Four sections
• Introduction
• System description
• Feasibility assessment
• Management issues

5.33
 BUILDING THE BASELINE
PROJECT PLAN

• Introduction
• Brief overview
• Recommended course of action
• Project scope definition
• Units affected
• Who inside and outside the organization would be
involved
• Interaction with other systems
• Range of system capabilities

5.35
 BUILDING THE BASELINE
PROJECT PLAN

• System description
• Outline of possible alternative solutions
• Narrative format of selected solution
• Feasibility assessment
• Project costs and benefits
• Technical difficulties
• High-level project schedules
• Management issues
• Team composition
• Communication plan
• Project standards and procedures
• Other project-specific topics
5.37
 REVIEWING THE BASELINE
PROJECT PLAN

• Objectives
• Assure conformity to organizational standards
• All parties agree to continue with project

• Walkthrough
• It is a peer group review
• Ensures that the work product adheres to organizational
technical standards
• Reviews the work product in terms of future maintenance
activities.
• Recommends required changes

5.38
SOFTWARE ENGINEERING

PROF. DR. AMANY SARHAN

2022
1
REQUIREMENT ENGINEERING

(ANALYSIS)

2
 REQUIREMENTS

• Requirements define the function of the system from the

client's viewpoint.
• The requirements establish the system's functionality, and
constraints by consultation with the client, customers, and users.
• The requirements may be developed in a self-contained study,
or may emerge incrementally.
• The requirements form the basis for acceptance testing.
• The development team and the client need to work together
closely during the requirements phase of a software project.
• The requirements must be developed in a manner that is
understandable by both the client and the development staff.
3
WHY ARE REQUIREMENTS IMPORTANT?

4
 REQUIREMENT PHASE GOAL

• Understand the requirements in appropriate detail.

• Define the requirements in a manner that is clear to
the client. This may be a written specification,
prototype system, or other form of communication.
• Define the requirements in a manner that is clear to
the people who will design, implement, and
maintain the system.
• Ensure that the client and developers understand
the requirements and their implications.

5
REQUIREMENTS WITH AGILE DEVELOPMENT

6
 THE REQUIREMENTS PROCESS

Domain

Req. Req. Structuring Validation

Determination and
Verification

Users

7
 PERFORMING REQUIREMENTS DETERMINATION
(ELICITATION)

• Gather information on what system should do from

many sources
• Users: Interviews, questionnaire, forms, ….
• Documents (Domain): Reports, Procedures,
previous systems, domain
• Brain storming sessions
• Note that making SW for specific users, elicitation is
different from making generic SW. ???
• Client interviews are the heart of the requirements
analysis.
8
 INTERVIEWS WITH CLIENTS

• Clients may have only a vague concept of requirements.

• Allow plenty of time, be neutral and listen carefully.
• Gather facts, opinions,…
• Observe body language and emotions (feeling)
• Prepare a plane for the interview before you meet with the
client.
• Make Appointment (convenient for the interviewee)
• Give him an idea of the subject of interview (he may need
to prepare things before)
• Checklist of the interview
• Keep full notes (you may record it after taking permission).
• If you do not understand, ask the question in another form
further, again and again.
 INTERVIEWS WITH CLIENTS

• Repeat what you hear to ensure that the client is satisfied.

• Requirements must be realistic, i.e., it must be possible to meet them.
• Wrong: The system must be capable of x (if no known computer
system can do x at a reasonable cost).
• Requirements must be verifiable, i.e., since the requirements are the
basis for acceptance testing, it must be possible to test whether a
requirement has been met.
• Wrong: The system must be easy to use.
• Right: After one day's training an operator should be able to input 50
orders per hour.
• Type up notes within 48 hours 10

• Do not set expectations about the new system

 INTERVIEWS WITH CLIENTS

• Interview questions
• Open-ended
• No pre-specified answers (gives the
interviewee freedom to speak)
• Close-ended
• Interviewee is asked to choose from a set of
specified responses (T/F or MCQ or ranking)
• Do not phrase questions in ways that imply a
wrong or right answer

11
 TRADITIONAL METHODS FOR
DETERMINING REQUIREMENTS

2- questionnaires
• More cost-effective than interviews
• Be careful when choosing respondents
• Should be representative of all users
• Design
• Mostly closed-ended questions
• Can be administered over the phone or in
person

12
 TRADITIONAL METHODS FOR
DETERMINING REQUIREMENTS

3- Interviewing Groups
• Make an interview of a group instead of individually
• Advantages
• More effective use of time
• Enables people to hear opinions of others and to agree or
disagree
• Disadvantages
• Difficulty in scheduling a specific time

13
 TRADITIONAL METHODS FOR
DETERMINING REQUIREMENTS

4- Directly Observing Users

• Observe the users while they are working to
understand how do they perform the work
• Serves as a good method to supplement interviews

• Disadvantage:
• Often difficult to obtain unbiased data as people
often work differently when being observed (better
or worse)

14