requirement determination

REQUIREMENTS DETERMINATION

RAVIMOHAN


RAVIMOHAN

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)A

naly

sis

Desig

n Planning Feasibility Study (optional) Requirements Determination Conceptual Design Physical Design Construction and/or Purchase

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

enhancements

RAVIMOHAN REQUIREMENT DEFINITION

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


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 Rupees


9

Improved customer goodwill

Improved employee morale

Improved employee job satisfaction

Better service to the community

Better decision making

INTANGIBLE BENEFITS

…Equate these to Rupees

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

5 4 3 2 1 0

Cum Benefit (Cost)

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

naly

sis

Desig

n


12

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” comeBusiness “problems” come in all sizes and shapes!all sizes and shapes!

Examples:


13

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

Problem Domain Details

Requirements Determination Activity

Problem DomainRequired Details


14

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:


15

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.


16

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


17

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


18

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


19

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.


20

Types of Requirements

• User-Driven

• User-Reviewed

• User-Independent

There are three major types of requirements:


21

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.


22

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.


23

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.


24

• Global

• Individual

• Collective (group)

METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS

Three Perspectives:


25

• 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



26

• Interviews

• Observations

• Questionnaires (surveys)

• Create a prototype

Perspective: Individual



27

• Create a prototype

• Joint Application Design (JAD)

• Automated support tools, such

as EJAD and integrated CASE

tools

• Electronic Meeting Facilitation

Perspective: Collective (group)



28

• Feedback to the user(s)

• Technology-free information content

• Good communication skills needed

Three Common Threads in all Methods:



29

REQUIREMENTS AMBIGUITY*

GOAL

whattheuserwants/needs

whattheuserdoes notwant/need

START WITH

want/need,but theydo notask for

do notwant/need,but ask for

EXPLOREand

ITERATE


30

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:


31

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


32

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


33

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


34

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


35

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


36

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


37

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


38

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


39

• Four sub-activities

• Kozar’s Requirements

Model

• Enterprise Objects


How to get started?????


40

• 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


41

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


42

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*


43

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


44

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



45

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


46

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

page 1 of 4


47

Video Store Requirements Model (partial)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


48

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


49

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)

Video Store Requirements Model (partial)

page 4 of 4


50

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


51

• 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


52

Enterprise Objects

InformationSystem

Business Objects

Technology Objects

Application Objects


53

• OBJECTS

• PATTERNS

• RESPONSIBILITIES

• SCENARIOS

AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION METHODOLOGY

EMPHASIZES:


54

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

AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION

METHODOLOGY


55

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:


METHODOLOGY


56

• Problem Domain component (PD)

• Human Interaction component (HI)

• Data Management component (DM)

• System Interaction component (SI)

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

AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION METHODOLOGY


57


METHODOLOGY

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


59

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

page 2 of 3


60

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

page 3 of 3


61

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.

requirement determination

Documents