REQUIREMENTS DETERMINATION

RAVIMOHAN
SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
■ Planning
■ Feasibility Study (optional)
■ Requirements Determination
Analysis

■ Conceptual Design
■ Physical Design
■ Construction and/or Purchase
(prototype)
■ Training
Design

■ Conversion - old to new

■ Implementation
■ Evolution - maintenance &
enhancements
 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.

RAVIMOHAN REQUIREMENT DEFINITION 3

 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 cost-
effectiveness of an information system solution.

RAVIMOHAN REQUIREMENT DEFINITION 4

 ECONOMIC FEASIBILITY Example

• Costs to develop, maintain and operate

• Benefits when operational

• Break-Even point (Costs = Benefits)

RAVIMOHAN REQUIREMENT DEFINITION 5

1. Systems Development Costs (one-time; representative only)
Personnel:
• 2 Systems Analysts (450 hours/each @ Rs45/hour) 40,500
• 5 Software Developers (275 hours/each @ Rs36/hour) 49,500
• 1 Data Communications Specialist (60 hours @ Rs40/hour) 2,400
• 1 Database Administrator (30 hours @ Rs42/hour) 1,260
• 2 Technical Writers (120 hours/each @ Rs25/hour) 6,000
• 1 Secretary (160 hours @ Rs15/hour) 2,400
• 2 Data Entry clerks during conversion (40 hrs/ea @ Rs12/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: Rs161,670

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

Personnel:
• Maintenance Programmer/Analyst (250 hrs/year @ Rs42/hr) 10,500
• Network Supervisor (300 hrs/year @ Rs50/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: Rs201,670

==========
 TANGIBLE BENEFITS
➪ Fewer processing errors
➪ Increased throughput
➪ Increased response time
➪ Elimination of job steps
➪ Reduced expenses
➪ Increased sales …Equate these
to Rupees
➪ Faster turnaround
➪ Better credit
➪ Reduced credit losses
➪ Reduction of accounts receivables

RAVIMOHAN REQUIREMENT DEFINITION 8

INTANGIBLE BENEFITS
➪ Improved customer goodwill

➪ Improved employee morale

➪ Improved employee job satisfaction

➪ Better service to the community

➪ Better decision making

…Equate these
to Rupees

RAVIMOHAN REQUIREMENT DEFINITION 9

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

(Cum Benefit (Cost

150,000
100,000 88,330
50,000
18,330
-
(41,670) Cum Benefit (Cost)
(50,000)
(100,000) (91,670)
(131,670)
(150,000) (161,670)
(200,000)
0 1 2 3 4 5
SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
■ Planning
■ Feasibility Study (optional)
■ Requirements Determination
Analysis

■ Conceptual Design
■ Physical Design
■ Construction and/or Purchase
(prototype)
■ Training
Design

■ Conversion - old to new

■ Implementation
■ Evolution - maintenance &
enhancements
Business “problems” come in all sizes and shapes!
■ Name & Address Book
■ CD Collection
■ Course Registration
■ Reservations
■ Student Grades
■ Payroll
■ ATM machine & Banking in General
■ Check-Out Counters at Retail
Examples: Stores
■ Order Fulfillment - Mail or Web
Ordering
■ Manufacturing
■ Securities Portfolio Management
■ Space Shuttle Flight
■ Election Results
■ Video GamesREQUIREMENT
RAVIMOHAN (Arcade DEFINITION
and Home) 12
 REQUIREMENTS DETERMINATION
An activity used to determine what is “in” and what is
“out”!
Problem Domain
Details

Requirements Determination Activity

Problem Domain
Required Details

RAVIMOHAN REQUIREMENT DEFINITION 13

 What are Requirements?
Three (3) alternative ways to think about
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).

RAVIMOHAN REQUIREMENT DEFINITION 14

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.

RAVIMOHAN REQUIREMENT DEFINITION 15

 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.
RAVIMOHAN REQUIREMENT DEFINITION 16
 Documenting the Requirements
• Text is not the optimum form for all requirements. 2 of 2

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

RAVIMOHAN REQUIREMENT DEFINITION 17

 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.
us
oc

• Project Requirements
rF
Ou

– stipulates resources for those conducting

the project.
– stipulates how different aspects of the
project will be carried out.
RAVIMOHAN REQUIREMENT DEFINITION 18
 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.

RAVIMOHAN REQUIREMENT DEFINITION 19

 Types of Requirements
There are three major types of requirements:

• User-Driven

• User-Reviewed

• User-Independent

RAVIMOHAN REQUIREMENT DEFINITION 20

 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.

RAVIMOHAN REQUIREMENT DEFINITION 21

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.

RAVIMOHAN REQUIREMENT DEFINITION 22

 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.

RAVIMOHAN REQUIREMENT DEFINITION 23

 METHODS USED TO GATHER
INFORMATION SYSTEMS REQUIREMENTS

Three Perspectives:

• Global

• Individual

• Collective (group)

RAVIMOHAN REQUIREMENT DEFINITION 24

 METHODS USED TO GATHER
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

RAVIMOHAN REQUIREMENT DEFINITION 25

 METHODS USED TO GATHER
INFORMATION SYSTEMS REQUIREMENTS
Perspective: Individual

• Interviews

• Observations

• Questionnaires (surveys)

• Create a prototype

RAVIMOHAN REQUIREMENT DEFINITION 26

 METHODS USED TO GATHER
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

RAVIMOHAN REQUIREMENT DEFINITION 27
METHODS USED TO GATHER INFORMATION
SYSTEMS REQUIREMENTS
Three Common Threads in all Methods:

• Feedback to the user(s)

• Technology-free information content

• Good communication skills needed

RAVIMOHAN REQUIREMENT DEFINITION 28

 REQUIREMENTS AMBIGUITY*

EXPLORE
GOAL START WITH and
ITERATE
want/need,
what but they
what do not
the the ask for
user user
wants/ does not
needs want/ do not
need want/need,
but ask for

RAVIMOHAN REQUIREMENT DEFINITION 29

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

RAVIMOHAN REQUIREMENT DEFINITION 30

 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.

RAVIMOHAN REQUIREMENT DEFINITION 31

 Contradictions
• Contradictions may be the result of: Problem #2

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

RAVIMOHAN REQUIREMENT DEFINITION 32

 Ambiguities
• Ambiguities are often the result of: Problem #3

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

RAVIMOHAN REQUIREMENT DEFINITION 33

 Duplications
• Duplications may be Problem #4

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

RAVIMOHAN REQUIREMENT DEFINITION 34

 Inaccuracies
• It is not uncommon for systems analysts Problem #5

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.
RAVIMOHAN REQUIREMENT DEFINITION 35
 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.

RAVIMOHAN REQUIREMENT DEFINITION 36

 Too Much Design
• One of the greatest temptations in systems
Problem #7

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.

RAVIMOHAN REQUIREMENT DEFINITION 37

Irrelevant Information
• Systems analysts are often reluctant to throw Problem #8
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.

RAVIMOHAN REQUIREMENT DEFINITION 38

REQUIREMENTS DETERMINATION
How to get started?????

• Four sub-activities

• Kozar’s Requirements

Model

• Enterprise Objects

RAVIMOHAN REQUIREMENT DEFINITION 39

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

RAVIMOHAN REQUIREMENT DEFINITION 40

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

RAVIMOHAN REQUIREMENT DEFINITION 41

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 Specific measurable statements

Actions to accomplish
TACTICS & NEEDS
objectives

INFORMATION SYSTEMS Support for user actions

More
Details

RAVIMOHAN REQUIREMENT DEFINITION 42

 Kozar’s Requirements Model - page 1 of 3
STIMULI A change of some type Hired a marketing consultant

BUSINESS forces changed enterprise needsRecommends better tracking

BENEFIT
OBJECTIVES of where sales orders come from S

BUSINESS causing changed user behaviors Mkt. code on each promo. piece
TACTICS mailed out COSTS

INFO. SYS. requiring changed information needs

Develop mkt. codes
OBJECTIVES Track sales based on mkt. codes BENEFIT
Reports showing promo. piece S
effectiveness

INFO. SYS. requiring changed I.S. activities Modify Sales Order Fulfillment Sys
TACTICS (about 2 dozen changes)
COSTS

RAVIMOHAN REQUIREMENT DEFINITION 43

Kozar’s Requirements Model - page 2 of 3
STIMULI

BUSINESS OBJECTIVES
Creates one or more

BUSINESS TACTICS
Creates one or more

INFORMATION SYSTEMS
Creates OBJECTIVES
zero or more

INFORMATION SYSTEMS
Creates TACTICS
one or more

RAVIMOHAN REQUIREMENT DEFINITION 44

Kozar’s Requirements Model - page 3 of 3

Business Objectives Business Tactics Info. Sys. Objectives Info. Sys. Tactics
1. ...... 1.1 ...... 1.1.1 1.1.1.1
2. ...... 1.2 ...... 1.1.2 1.1.1.2
3. ...... 1.3 ...... 1.1.3 1.1.1.3
4. ...... 2.1 ...... 1.2.1 1.1.1.4
etc.... 3.1 ...... 1.2.2 1.1.2.1
3.2 ...... 2.1.1 1.1.2.2
4.1 ...... 2.1.2 1.1.3.1
4.2 ...... etc... etc.....
4.3 ......
4.4 ......
etc....
Business Objectives Information Systems
Business Tactics
create one or more Objectives create
create zero or more
Business Tactics one or more
Information Systems
Information Systems
Objectives
Tactics

RAVIMOHAN REQUIREMENT DEFINITION 45

 Video Store Requirements Model (partial)
MISSION STATEMENT
To be the video store of choice by successfully providing a generous page 1 of 4
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.

RAVIMOHAN REQUIREMENT DEFINITION 46

Video Store Requirements Model (partial)
BUSINESS OBJECTIVES page 2 of 4
(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.

RAVIMOHAN REQUIREMENT DEFINITION 47

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.
RAVIMOHAN REQUIREMENT DEFINITION 48
 Video Store Requirements Model (partial)
INFORMATION SYSTEMS OBJECTIVES - continued
2.1.2 Provide membership information reports such as (not limited to): page 4 of 4
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)

RAVIMOHAN REQUIREMENT DEFINITION 49

 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

RAVIMOHAN REQUIREMENT DEFINITION 50

 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
specific business problems (ex: Order Entry, Ticketing, Acct setup)

RAVIMOHAN REQUIREMENT DEFINITION 51

 Enterprise Objects

Information
System

Business Objects Application Objects

Technology Objects
RAVIMOHAN REQUIREMENT DEFINITION 52
AN OBJECT-ORIENTED REQUIREMENTS
DETERMINATION METHODOLOGY
EMPHASIZES:

• OBJECTS

• PATTERNS

• RESPONSIBILITIES

• SCENARIOS
RAVIMOHAN REQUIREMENT DEFINITION 53
 AN OBJECT-ORIENTED
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.

RAVIMOHAN REQUIREMENT DEFINITION 54

 AN OBJECT-ORIENTED
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.

RAVIMOHAN REQUIREMENT DEFINITION 55

 AN OBJECT-ORIENTED
REQUIREMENTS DETERMINATION
METHODOLOGY
The preceding 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)

RAVIMOHAN REQUIREMENT DEFINITION 56

 AN OBJECT-ORIENTED
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

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

RAVIMOHAN REQUIREMENT DEFINITION 57
 page 1 of 3

Types of Information System Feature

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

Log Information Conduct Business

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

Analyze results Interact with

other systems
Business Problem Results
• Business Problem Integratio
 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...
RAVIMOHAN REQUIREMENT DEFINITION 59
 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
RAVIMOHAN REQUIREMENT DEFINITION 60
• etc...
 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.
RAVIMOHAN REQUIREMENT DEFINITION 61