FEASIBILITY ANALYSIS

and
REQUIREMENTS
DETERMINATION
31

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

Design

Analysis

Planning

Feasibility

Study (optional)

Requirements Determination

Conceptual Design

Physical Design

Construction and/or Purchase

(prototype)

Training

Conversion - old to new

Implementation

FEASIBILITY ANALYSIS
FEASIBILITY (in information systems development) is the
measure of how beneficial the development or enhancement
of an information system will be to the business

FEASIBILITY ANALYSIS is the process by which

feasibility is measured

33

FEASIBILITY TYPES
OPERATIONAL FEASIBILITY is the measure of how well
a particular information system will work in a given
environment
TECHNICAL FEASIBILITY is the measure of the

practicality of a specific technical information system

solution and the availability of technical resources
ECONOMIC FEASIBILITY is the measure of the costeffectiveness of an information system solution

34

ECONOMIC FEASIBILITY
Example
Costs to develop, maintain and operate
Benefits when operational
Break-Even point (Costs = Benefits)
35

1. Systems Development Costs (one-time; representative only)

Personnel:
2 Systems Analysts (450 hours/each @ $45/hour)
5 Software Developers (275 hours/each @ $36/hour)
1 Data Communications Specialist (60 hours @ $40/hour)
1 Database Administrator (30 hours @ $42/hour)
2 Technical Writers (120 hours/each @ $25/hour)
1 Secretary (160 hours @ $15/hour)
2 Data Entry clerks during conversion (40 hrs/ea @ $12/hr)
Training:
3 day in-house course for developers
User 3 day in-house course for 30 users
Supplies:
Duplication
Disks, tapes, paper, etc.
Purchased Hardware & Software:
Windows for 20 workstations
Memory upgrades in 20 workstations
Mouse for 20 workstations
Network Software
Office Productivity Software for 20 workstations

TOTAL SYSTEMS DEVELOPMENT COSTS:

$40,500
49,500
2,400
1,260
6,000
2,400
960

7,000
10,000

500
650

1,000
8,000
2,500
15,000
20,000

$161,670

2. Annual Operating Costs (on-going

each year)

Personnel:
Maintenance Programmer/Analyst (250 hrs/year @ $42/hr)
Network Supervisor (300 hrs/year @ $50/hr)

$10,500
15,000

Purchased Hardware & Software Upgrades:

Hardware
Software

5,000
6,000

Supplies and Miscellaneous items

3,500

TOTAL ANNUAL OPERATING COSTS:

40,000

-----------------------------------------------------------------------------------------------------------

TOTAL COST TO DEVELOP AND OPERATE THE SYSTEM: $201,670

==========

TANGIBLE BENEFITS
Fewer processing errors
Increased throughput
Increased response time
Elimination of job steps
Reduced expenses

Equate these
to Dollars ($)

Increased sales
Faster turnaround

Better credit
Reduced credit losses
Reduction of accounts receivables

38

INTANGIBLE BENEFITS
Improved customer goodwill
Improved employee morale
Improved employee job satisfaction
Better service to the community
Better decision making
Equate these
to Dollars ($) 39

BREAK EVEN (PAYBACK)

ANALYSIS
Break Even (Payback) Analysis Example*
Year 0
Year 1
Year 2
Year 3
Year 4
Year 5
Development Costs (161,670)
Operational Costs
(40,000) (40,000) (40,000) (40,000) (40,000)
Tangible Benefits
Intangible Benefits
Benefit (Cost)
Cum Benefit (Cost)

50,000
20,000

55,000
25,000

60,000
30,000

(161,670)
30,000 40,000 50,000
(161,670) (131,670) (91,670) (41,670)

65,000
35,000

70,000
40,000

60,000
18,330

70,000
88,330

* This simple example does not consider the Time-Value of Money

Cum Benefit (Cost)
150,000
100,000
50,000
(50,000)
(100,000)
(150,000)
(200,000)

88,330
18,330
(41,670)
(91,670)
(131,670)
(161,670)
0

Cum Benefit
(Cost)

REQUIREMENTS
DETERMINATION*

* AKA: Requirements Engineering, Requirements Management, Requirements As

41

Design

Analysis

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

Planning

Feasibility Study (optional)

Requirements

Determination

Conceptual Design

Physical Design

Construction and/or Purchase

(prototype)

Training

Conversion - old to new

Implementation

Business problems come in all sizes and sh

Examples:

Name & Address Book

CD Collection
Course Registration
Reservations
Student Grades
Payroll
ATM machine & Banking in General
Check-Out Counters at Retail Stores
Order Fulfillment - Mail or Web Ordering
Manufacturing
Securities Portfolio Management
Space Shuttle Flight
Election Results
Video Games (Arcade and Home)

43

DETERMINATION
An activity used to determine what is in and what is out!

Problem Domain Details

Requirements Determination Activity

Problem Domain
Required Details
44

What are
Requirements?

Three (3) alternative ways to think about Requireme

Requirements are criteria that are necessary,

needed, or demanded.
Requirements are implicit or explicit criteria
that must, should, or might be met.
Requirements equal the wants and needs of the
user(s).

45

Observations about
Requirements
Requirements are not supposed to dictate any details regarding
the implementation of a solution.
We commonly define differing levels of necessity for our
requirements, such as absolutely must be satisfied, nice to
have, and optional.
Some requirements may apply to an entire system, while
others apply only to part of the system.
Compromise is often necessary for conflicting requirements
from different user(s).
Some requirements are static, while others are dynamic and
evolve or emerge over time.
Requirements are not always easy to explain (communicate),
46
understand, or document.

Documenting the
Requirements
1 of 2

One very common way to document requirements is a textual

document containing a list of numbered or bulleted items, i.e.,
the requirements.
Each requirement is (ideally) stated in the form of a single
sentence.
Each sentence contains a word such as must, shall,
should, will, might, or can.
The document contains a way of differentiating those
requirements which are essential/demanded from those
requirements which are optional/suggested.

47

Documenting the
Requirements
2 of 2

Text is not the optimum form for all requirements.

For GUI, specifying colors, window layouts, and the placement of

icons is more easily and directly done using graphical techniques.

For systems using audio, animation, video capture, etc., it is
difficult to be precise if we are limited to textual descriptions.
Both static and dynamic models may be necessary to accurately
and correctly document requirements.
48

Product Requirements
Versus Project Requirements
Two very different sets of requirements:
Product Requirements
define the criteria that must, should, or, might
be met by the delivered product.

Project Requirements
stipulates resources for those conducting the
project.
stipulates how different aspects of the project
will be carried out.
49

Requirements:
Priorities and Constraints
Both product and project requirements may have associated

priorities and constraints.

A priority is a level of importance assigned to an item
helps define which items take precedence over other items.

A constraint is a limit or a restriction placed on an item or

situation
helps define the scope (boundaries) of an item or situation.

50

Types of Requirements
There are three major types of requirements:

User-Driven

User-Reviewed
User-Independent
51

User-Driven Requirements
Defined and specified entirely by the user.
The systems analyst has little, or no, input to
the definition and specification of the system
requirements.
Not a desirable situation.
52

User-Reviewed
Requirements
Specified by the user and the systems analyst
working together.

It is not the analysts job to be an expert in the

users application domain.
It is, however, required that systems analysts
possess the skills, methods, techniques, and tools
with which they effectively define, specify, and
verify requirements through interactions with the
user.
53

User-Independent
Requirements
Defined and specified without a particular
user being present.
The most common example of userindependent requirements are those
requirements which are defined by software
product vendors when they choose to
develop a new software product.
54

INFORMATION SYSTEMS
REQUIREMENTS
Three Perspectives:
Global
Individual
Collective (group)
55

INFORMATION SYSTEMS
REQUIREMENTS
Perspective: Global
Reviewing old reports, forms, and files
Conducting research to find out what
other companies have done - books,
magazines, newspapers, trade & scholarly journals,
vendor literature, colleagues, web...

Conducting site visits

56

INFORMATION SYSTEMS
REQUIREMENTS
Perspective: Individual
Interviews
Observations

Questionnaires (surveys)
Create a prototype
57

INFORMATION SYSTEMS
REQUIREMENTS
Perspective: Collective (group)
Create a prototype
Joint Application Design (JAD)
Automated support tools, such as
EJAD and integrated CASE tools

Electronic Meeting Facilitation

58

INFORMATION SYSTEMS
REQUIREMENTS
Three Common Threads in all Methods:
Feedback to the user(s)

Technology-free information content

Good communication skills needed
59

REQUIREMENTS AMBIGUITY*

START WITH

GOAL

what
the
user
wants/
needs

what
the
user
does not
want/
need

EXPLORE
and
ITERATE

want/need,
but they
do not
ask for

do not
want/need,
but ask for

* Requirements Ambiguity (adapted from [Gause & Weinberg])

60

Be Suspicious of the Quality of

Requirements
Requirements usually have one or
more of the following 8 problems:
Omissions
Contradictions

Ambiguities
Duplications
Inaccuracies
Introduced elements
Too much design
Irrelevant information

61

Omissions
Problem #1

Very often, the initial set of user-supplied

information is incomplete.
During the course of analysis, the systems
analyst will be expected to locate and/or
generate new requirements information.

This new information is, of course, subject to

the approval of the user.
62

Contradictions

Problem #2

Contradictions may be the result of:

incomplete information
imprecise specification methods
a misunderstanding
a lack of consistency check on the
requirements.

If the user alone cannot resolve the

contradictions, the analyst will be required
to propose a resolution to each problem.
63

Ambiguities

Problem #3

Ambiguities are often the result of:

incompletely defined ideas

use of ambiguous words (e.g., big, small)
lack of precision in the specification method
a conscious decision to leave resolution of ideas
to the analysts performing analysis.

Resolution of ambiguities with user input is

important otherwise the resolution is left in
the hands of the systems analyst.
64

Duplications

Problem #4

Duplications may be
the outright replication of information in the
same format in a different place
the replication of the same information in
several different places and formats.

Sometimes duplications are not obvious

the use of several different terms to describe the
same item.

The systems analyst must be careful when

identifying and removing duplications.
65

Inaccuracies

Problem #5

It is not uncommon for systems analysts to

uncover information which they suspect is
incorrect.
Inaccuracies must be brought to the users
attention and resolved.
Often, it is not until the user is confronted
with a precisely-described, proposed
requirements document that many of the
inaccuracies in the original requirements
66
come to light.

Introduced Elements

Problem #6

It is not uncommon for systems analysts to take

the liberty of introducing additional
requirements after they have met with the
users
Forgot to discuss
Think that they will save time by adding it without
discussing it with the users
Think that the user would want it
Think that the user would like it.

Sometimes this is okay and other times it can

be harmful.

67

Too Much Design

Problem #7

One of the greatest temptations in systems

analysis is to do the next persons job.
i.e., to both define a problem and to propose a
(detailed) solution.

One of the most difficult activities during

analysis is the separation of real
requirements from arbitrary (and
unnecessary) design decisions made by
those supplying the requirements.
68

Irrelevant Information

Problem #8

Systems analysts are often reluctant to throw away

any information.
Users sometimes feel it is better to supply too
much information rather than too little (usually
just the opposite).
Without some clear cut mechanisms to identify
and remove irrelevant information, it will be
difficult to develop accurate, cost-effective, and
pragmatic solutions to a users problems.
69

REQUIREMENTS
DETERMINATION
How to get started?????
Four sub-activities
Kozars Requirements Model

Enterprise Objects
70

Framework #1: Requirements Determination Sub-Activities

Requirements Anticipation - being able to relate;

analogical reasoning; patterns

Requirements Elicitation - asking the right questions;

listening & understanding; reflection

Requirements Specification - documenting your

understanding of the real requirements

Requirements Assurance - verifying and validating

(V&V) requirements with the user(s)

71

Framework #2: Requirements Model (Kozar)*

A strategy that links information systems activities with

established business activities.

PREMISE: Information systems support business

activities; therefore, associating information systems

activities with business activities should be possible.
Provides verification and validation (V & V) traceability
* Adapted from Kozar, K.A., Humanized Information Systems Analysis and Design,
McGraw-Hill Inc., 1989, pp. 61-62 and personal communication with the author.

72

Kozars Requirements Model is partially based on

the traditional Top-Down MANAGEMENT Pyramid*
More
Abstract
MISSION/
PURPOSE

Reason for existence

GOALS

General statements

OBJECTIVES
TACTICS & NEEDS
More
Details

INFORMATION SYSTEMS

Specific measurable statements

Actions to accomplish
objectives
Support for user actions

* Note: The pyramid model on this slide is NOT part of Kozars Model73

Kozars Requirements Model - page 1 of 3

STIMULI

A change of some type

Hired a marketing consultant

BUSINESS
OBJECTIVES

forces changed enterprise needs

Recommends better tracking

of where sales orders come from

BENEFITS

BUSINESS
TACTICS

causing changed user behaviors

Mkt. code on each promo. piece

mailed out

COSTS

INFO. SYS.
OBJECTIVES

requiring changed information needs

Develop mkt. codes

Track sales based on mkt. codes
Reports showing promo. piece
effectiveness

BENEFITS

INFO. SYS.
TACTICS

requiring changed I.S. activities

Modify Sales Order Fulfillment Sys

(about 2 dozen changes)

COSTS

74

Kozars Requirements Model - page 2 of 3

STIMULI
Creates one or more

BUSINESS OBJECTIVES
Creates one or more

BUSINESS TACTICS
Creates zero or more

INFORMATION SYSTEMS OBJECTIVES

Creates one or more

INFORMATION SYSTEMS TACTICS

75

Kozars Requirements Model - page 3 of 3

Business Objectives
1. ......
2. ......
3. ......
4. ......
etc....

Business Objectives
create one or more
Business Tactics

Business Tactics
1.1 ......
1.2 ......
1.3 ......
2.1 ......
3.1 ......
3.2 ......
4.1 ......
4.2 ......
4.3 ......
4.4 ......
etc....

Info. Sys. Objectives

1.1.1
1.1.2
1.1.3
1.2.1
1.2.2
2.1.1
2.1.2
etc...

Business Tactics
create zero or more
Information Systems
Objectives

Info. Sys. Tactics

1.1.1.1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.2.1
1.1.2.2
1.1.3.1
etc.....

Information Systems
Objectives create
one or more
Information Systems
Tactics
76

Video Store Requirements Model

(partial)
page 1 of 4
MISSION STATEMENT
To be the video store of choice by successfully providing a generous
selection of home video products for sale or rental at competitive prices.
GOALS
1. Increase market share and maintain profitability
2. Offer superior customer assistance and browsing environment
BUSINESS OBJECTIVES

(what we want to accomplish for the business)

1. Decrease checkout time for customers by at least 50%
2. Improve membership management by 50%
3. Increase memberships by 75% each year for the next two years
4. Improve inventory management by 60%
5. Purchase at least one new store each calendar year for the next 3 years
and then begin acquiring several stores each year thereafter.
77

Video Store Requirements Model

(partial)
page 2 of 4
BUSINESS OBJECTIVES

(what we want to accomplish for the business)

BUSINESS TACTICS
(how we plan to accomplish the business objectives)
1.1 Revise the check-out method for rentals and sales to be more
efficient and effective

2.1 Revise the membership management method to be more effective

and efficient
3.1 Implement a marketing strategy to increase membership
4.1 Revise inventory management to be more effective and efficient
5.1 Replace/implement accounting and financial systems
78

Video Store Requirements Model

(partial)
page 3 of 4
INFORMATION SYSTEMS OBJECTIVES
GENERAL OBJECTIVES:

A. Provide Just-in-Time (JIT) training

B. The systems we implement must be friendly and easy to learn and use
C. The systems we implement must give considerations to security issues
SPECIFIC OBJECTIVES:
1.1.1 Provide an automated system to assist with customer sales/rental
check-outs
2.1.1 Provide and maintain an automated membership database
a. provide current (up to date) membership information on demand
b. capability to add, change, and delete (remove) membership info.
79

(partial)
INFORMATION SYSTEMS OBJECTIVES - continued

page 4 of 4

2.1.2 Provide membership information reports such as (not limited to):

a. least used memberships
b. most used memberships
c. delinquent memberships (both money owing and outstanding rentals)
4.1.1 Provide and maintain an inventory database for both sales and rental items
a. provide current (up to date) inventory information on demand
b. capability to add, change, and delete (remove) inventory information
(sales and rental)
4.1.2 Provide inventory information reports such as (not limited to):
a. least popular rentals
b. most popular rentals
c. delinquent tape rentals outstanding
d. products on order (purchasing report) for sale and for rent items
5.1.1 Provide Sales Reports such as (not limited to):
a. sales for a time period (day, days, week, weeks, month, etc.) by
product code
b. rentals for a time period (same as above)

80

Framework #3: Enterprise Objects

A strategy that maps information systems business objects

with established business functionalities.

PREMISE: Information systems support integrated business

activities; therefore, they should mimic the real world

business activities as closely as possible.

Provides verification and validation (V & V) traceability
81

Enterprise Objects
Objects are not all created equal:
Different object types address different issues
Process and management issues differ
Buy vs. Make decision driven by different motivations
Three types of objects:

Business - business concepts / components, sharable across a

company or industries, independent of applications (ex: customer,
employee, product, vehicle, transcript, course...)
Technology - software and infrastructure building blocks,
frameworks for software development (ex: windows, forms,
controls)
Application - user interfaces to business objects as solutions to
82

specific business problems (ex: Order Entry, Ticketing, Acct setup)

Enterprise Objects

Information
System

Business Objects

Application Objects

Technology Objects
83

AN OBJECT-ORIENTED
REQUIREMENTS
DETERMINATION
METHODOLOGY*
* Based on the work of Peter Coad and others...

84

REQUIREMENTS
DETERMINATION
METHODOLOGY
EMPHASIZES:

OBJECTS
PATTERNS

RESPONSIBILITIES
SCENARIOS
85

REQUIREMENTS
DETERMINATION
METHODOLOGY
OBJECT - a person, place, thing, or concept.
PATTERN - a naturally recurring template of objects within a
problem domain having stereotypical responsibilities and

interactions.
RESPONSIBILITY - something associated with an object:
What the object knows about itself (attributes)

What other objects the object knows (relationships)

What the object does (services performed)

SCENARIO - a time-ordered sequence of object interactions to

fulfill a specific responsibility.

86

REQUIREMENTS
DETERMINATION
METHODOLOGY
Four Activities:
1. Identify the purpose and features of the
information system
2. Identify objects and patterns
3. Establish object responsibilities - attributes,
relationships, and services
4. Work out the information systems dynamics using
scenarios

87

REQUIREMENTS
DETERMINATION
METHODOLOGY
The preceeding four (4) activities are performed
for each of four (4) Object Model Components:

Problem Domain component (PD)

Human Interaction component (HI)

Data Management component (DM)

System Interaction component (SI)
88

REQUIREMENTS
DETERMINATION
METHODOLOGY
Information System
Human Interaction

Problem Domain

GUI Forms & Windows

Business Rules & Policies

Data Management

System Interaction

Database Activities

Integration with other systems

89
Note: This illustrates the 3-Tier or N-Tier Technology concept

page 1 of 3

Types of Information System Features

A feature is a tangible, measurable, desired outcome
that an information system could produce.

Log Information
(needed information)
Business Problem
Master/Reference Data

Analyze results
Business Problem Results

Conduct Business
Business Problem
Transaction Data

Interact with
other systems
Business Problem Integration

page 2 of 3

Features Examples
Log

Information:
Maintain membership information
Maintain product information
Maintain vendor (supplier) information
Maintain employee security information
etc

Conduct

Business:

Rental transaction
Sales transaction
Order products transaction
etc...

91

page 3 of 3

Features Examples
Analyze

results:

Produce Periodic Sales Report s by:

Product
Employee
Fastest-moving rentals
Fastest-moving sales
Produce On-Order Report by Vendor
Produce On-Order Report by Product
etc
Interact

with other systems:

Validation of Credit Cards

etc...

92

Regarding Requirements
Determination
People ARE Different! (Thinking & Behaviors)
Each Software Development Project Is Different!
Requirements Determination Is an Iterative Process
Some Sub-Processes May Be Accomplished Concurrently

The Requirements Determination Effort May Be Accomplished At

More Than One Point In the Life-Cycle
The Requirements Determination Effort May Be Driven By External
or Uncontrollable Circumstances

Requirements Determination Should Not Be Driven By Low-Level

Issues
Verification, Validation, and Quality Assurance Are Always Important
for Requirements Determination

Corrections and changes to Requirements late in the SDLC may cost

between 30 and 70 times their cost if done initially

93