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
1
2
3
4
5
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 analyst’s job to be an expert in the
user’s 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 user’s
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 person’s 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 user’s problems.
69
REQUIREMENTS
DETERMINATION
How to get started?????
• Four sub-activities
• Kozar’s 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
Kozar’s 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 Kozar’s Model73
Kozar’s 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
Kozar’s 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
Kozar’s 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 system’s 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