FEASIBILITY ANALYSIS and REQUIREMENTS DETERMINATION

1

FEASIBILITY ANALYSIS

and

REQUIREMENTS DETERMINATION

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)A

naly

sis

Planning

Feasibility Study (optional)

Requirements Determination Conceptual Design Physical Design Construction and/or Purchase

(prototype) Training Conversion - old to new Implementation Evolution - maintenance &

enhancements

Desig

n a

nd

Imp

lem

en

tati

on

3

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

FEASIBILITY ANALYSIS

4

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 cost-

effectiveness of an information system solution

FEASIBILITY TYPES

5

ECONOMIC FEASIBILITY Example

Costs to develop, maintain and operate

Benefits when operational

Break-Even point (Costs = Benefits)

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

Personnel:• 2 Systems Analysts (450 hours/each @ $45/hour) $40,500• 5 Software Developers (275 hours/each @ $36/hour) 49,500• 1 Data Communications Specialist (60 hours @ $40/hour) 2,400• 1 Database Administrator (30 hours @ $42/hour) 1,260• 2 Technical Writers (120 hours/each @ $25/hour) 6,000• 1 Secretary (160 hours @ $15/hour) 2,400• 2 Data Entry clerks during conversion (40 hrs/ea @ $12/hr) 960

Training:• 3 day in-house course for developers 7,000• User 3 day in-house course for 30 users 10,000

Supplies:• Duplication 500• Disks, tapes, paper, etc. 650

Purchased Hardware & Software:• Windows for 20 workstations 1,000• Memory upgrades in 20 workstations 8,000• Mouse for 20 workstations 2,500• Network Software 15,000• Office Productivity Software for 20 workstations 20,000

TOTAL SYSTEMS DEVELOPMENT COSTS: $161,670

2. Annual Operating Costs (on-going each year)

Personnel:• Maintenance Programmer/Analyst (250 hrs/year @ $42/hr) $10,500• Network Supervisor (300 hrs/year @ $50/hr) 15,000

Purchased Hardware & Software Upgrades:• Hardware 5,000• Software 6,000

Supplies and Miscellaneous items 3,500

TOTAL ANNUAL OPERATING COSTS: 40,000

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

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

8

Fewer processing errors

Increased throughput

Increased response time

Elimination of job steps

Reduced expenses

Increased sales

Faster turnaround

Better credit

Reduced credit losses

Reduction of accounts receivables

TANGIBLE BENEFITS

…Equate these to Dollars ($)

9

Improved customer goodwill

Improved employee morale

Improved employee job satisfaction

Better service to the community

Better decision making

INTANGIBLE BENEFITS

…Equate these to Dollars ($)

BREAK EVEN (PAYBACK) ANALYSIS

Year 0 Year 1 Year 2 Year 3 Year 4 Year 5Development Costs (161,670) - - - - - Operational Costs - (40,000) (40,000) (40,000) (40,000) (40,000)

Tangible Benefits - 50,000 55,000 60,000 65,000 70,000 Intangible Benefits - 20,000 25,000 30,000 35,000 40,000

Benefit (Cost) (161,670) 30,000 40,000 50,000 60,000 70,000 Cum Benefit (Cost) (161,670) (131,670) (91,670) (41,670) 18,330 88,330

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

Break Even (Payback) Analysis Example*

Cum Benefit (Cost)

(161,670)(131,670)

(91,670)(41,670)

18,330

88,330

(200,000)(150,000)(100,000)

(50,000)-

50,000100,000150,000

0 1 2 3 4 5

Cum Benefit(Cost)

11

REQUIREMENTS

DETERMINATION*

* AKA: Requirements Engineering, Requirements Management, Requirements Assessment

Planning Feasibility Study (optional)

Requirements Determination

Conceptual Design Physical Design Construction and/or Purchase

(prototype) Training Conversion - old to new Implementation Evolution - maintenance &

enhancements

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)A

naly

sis

Desig

n a

nd

Imp

lem

en

tati

on

13

Name & Address BookName & Address Book CD CollectionCD Collection Course RegistrationCourse Registration ReservationsReservations Student GradesStudent Grades PayrollPayroll ATM machine & Banking in GeneralATM machine & Banking in General Check-Out Counters at Retail Check-Out Counters at Retail

StoresStores Order Fulfillment - Mail or Web Order Fulfillment - Mail or Web

OrderingOrdering ManufacturingManufacturing Securities Portfolio ManagementSecurities Portfolio Management Space Shuttle FlightSpace Shuttle Flight Election ResultsElection Results Video Games (Arcade and Home)Video Games (Arcade and Home)

Business “problems” come in all sizes and shapes!Business “problems” come in all sizes and shapes!

Examples:

14

REQUIREMENTS DETERMINATIONAn activity used to determine what is “in” and what is “out”!

Problem Domain Details

Requirements Determination Activity

Problem DomainRequired Details

15

What are Requirements?

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).

Three (3) alternative ways to think about Requirements:

16

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), understand, or document.

17

Documenting the Requirements

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.

1 of 2

18

Documenting the Requirements

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.

2 of 2

19

Product Requirements Versus Project 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.

Two very different sets of requirements:

Our

Focu

s

20

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.

21

Types of Requirements

User-Driven

User-Reviewed

User-Independent

There are three major types of requirements:

22

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.

23

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.

24

User-Independent Requirements

Defined and specified without a particular user being present.

The most common example of user-independent requirements are those requirements which are defined by software product vendors when they choose to develop a new software product.

25

Global

Individual

Collective (group)

METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS

Three Perspectives:

26

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

Perspective: Global


27

Interviews

Observations

Questionnaires (surveys)

Create a prototype

Perspective: Individual


28

Create a prototype

Joint Application Design (JAD)

Automated support tools, such as EJAD

and integrated CASE tools

Electronic Meeting Facilitation

Perspective: Collective (group)


29

Feedback to the user(s)

Technology-free information content

Good communication skills needed

Three Common Threads in all Methods:


30

REQUIREMENTS AMBIGUITY*

GOAL

whattheuserwants/needs

whattheuserdoes notwant/need

START WITH

want/need,but theydo notask for

do notwant/need,but ask for

EXPLOREand

ITERATE

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

31

Be Suspicious of the Quality of Requirements

Omissions Contradictions Ambiguities Duplications Inaccuracies Introduced elements Too much design Irrelevant information

Requirements usually have one ormore of the following 8 problems:

32

Omissions

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.

Problem #1

33

Contradictions

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.

Problem #2

34

Ambiguities

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.

Problem #3

35

Duplications

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.

Problem #4

36

Inaccuracies

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 come to light.

Problem #5

37

Introduced Elements

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.

Problem #6

38

Too Much Design

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.

Problem #7

39

Irrelevant Information

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.

Problem #8

40

Four sub-activities

Kozar’s Requirements Model

Enterprise Objects


How to get started?????

41

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)

Framework #1: Requirements Determination Sub-Activities

42

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.

43

Actions to accomplish objectives

MoreAbstract

MoreDetails

MISSION/PURPOSE

GOALS

OBJECTIVES

TACTICS & NEEDS

INFORMATION SYSTEMS

Reason for existence

General statements

Specific measurable statements

Support for user actions

Kozar’s Requirements Model is partially based onthe traditional Top-Down MANAGEMENT Pyramid*

* Note: The pyramid model on this slide is NOT part of Kozar’s Model

44

A change of some type

forces changed enterprise needs

causing changed user behaviors

requiring changed information needs

requiring changed I.S. activities

STIMULI

BUSINESSOBJECTIVES

BUSINESSTACTICS

INFO. SYS.OBJECTIVES

INFO. SYS.TACTICS

BENEFITS

COSTS

BENEFITS

COSTS

Hired a marketing consultant

Recommends better trackingof where sales orders come from

Mkt. code on each promo. piecemailed out

Develop mkt. codesTrack sales based on mkt. codesReports showing promo. piece effectiveness

Modify Sales Order Fulfillment Sys(about 2 dozen changes)

Kozar’s Requirements Model - page 1 of 3

45

STIMULI

BUSINESS OBJECTIVES

BUSINESS TACTICS

INFORMATION SYSTEMS OBJECTIVES

INFORMATION SYSTEMS TACTICS

Creates one or more

Creates one or more

Creates zero or more

Creates one or more


46

Business Objectives1. ......2. ......3. ......4. ......etc....

Business Tactics1.1 ......1.2 ......1.3 ......2.1 ......3.1 ......3.2 ......4.1 ......4.2 ......4.3 ......4.4 ......etc....

Info. Sys. Objectives1.1.11.1.21.1.31.2.11.2.22.1.12.1.2etc...

Info. Sys. Tactics1.1.1.11.1.1.21.1.1.31.1.1.41.1.2.11.1.2.21.1.3.1etc.....


Business Objectivescreate one or moreBusiness Tactics

Business Tacticscreate zero or more

Information SystemsObjectives

Information SystemsObjectives create

one or moreInformation Systems

Tactics

47

Video Store Requirements Model (partial)

MISSION STATEMENT

To be the video store of choice by successfully providing a generousselection of home video products for sale or rental at competitive prices.

GOALS

1. Increase market share and maintain profitability2. 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 years4. 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.

page 1 of 4

48


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

page 2 of 4

49

INFORMATION SYSTEMS OBJECTIVES

GENERAL OBJECTIVES:

A. Provide Just-in-Time (JIT) trainingB. The systems we implement must be friendly and easy to learn and useC. 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.

Video Store Requirements Model (partial)page 3 of 4

50

INFORMATION SYSTEMS OBJECTIVES - continued

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)


page 4 of 4

51

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

52

Enterprise Objects

InformationSystem

Business Objects

Technology Objects

Application Objects

53

• 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

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

Enterprise Objects

54

AN OBJECT-ORIENTED


METHODOLOGY*

* Based on the work of Peter Coad and others...

55

OBJECTS

PATTERNS

RESPONSIBILITIES

SCENARIOS

AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION METHODOLOGY

EMPHASIZES:

56

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.


57

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

Four Activities:


58

Problem Domain component (PD)

Human Interaction component (HI)

Data Management component (DM)

System Interaction component (SI)

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


59


Problem Domain

Data Management System Interaction

Information System

Human Interaction

GUI Forms & Windows Business Rules & Policies

Database Activities Integration with other systems

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

Log Information Conduct Business

Analyze results Interact with other systems

Types of Information System Features

(“needed information”) •Business Problem Master/Reference Data

• Business Problem Transaction Data

• Business Problem Results• Business Problem Integration

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

page 1 of 3

61

Features ExamplesFeatures 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...

page 2 of 3

62

Features ExamplesFeatures Examples

Analyze results:•Produce Periodic Sales Report s by:

•Product•Employee•Fastest-moving rentals•Fastest-moving sales

•Produce “On-Order” Report by Vendor

•product “On-Order” Report by Product

•etc… Interact with other systems:

•Validation of Credit Cards•etc...

page 3 of 3

63

Some Final Thoughts 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

64

65

QUITTING TIME

Documents

FEASIBILITY ANALYSIS and REQUIREMENTS DETERMINATION