REQUIREMENTS DETERMINATION
RAVIMOHAN
REQUIREMENTS DETERMINATION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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==========
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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:
RAVIMOHAN REQUIREMENT DEFINITION
13
REQUIREMENTS DETERMINATIONAn activity used to determine what is “in” and what is “out”!
Problem Domain Details
Requirements Determination Activity
Problem DomainRequired Details
RAVIMOHAN REQUIREMENT DEFINITION
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:
RAVIMOHAN REQUIREMENT DEFINITION
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.
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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.
RAVIMOHAN REQUIREMENT DEFINITION
20
Types of Requirements
• User-Driven
• User-Reviewed
• User-Independent
There are three major types of requirements:
RAVIMOHAN REQUIREMENT DEFINITION
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.
RAVIMOHAN REQUIREMENT DEFINITION
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.
RAVIMOHAN REQUIREMENT DEFINITION
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.
RAVIMOHAN REQUIREMENT DEFINITION
24
• Global
• Individual
• Collective (group)
METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS
Three Perspectives:
RAVIMOHAN REQUIREMENT DEFINITION
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
METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS
RAVIMOHAN REQUIREMENT DEFINITION
26
• Interviews
• Observations
• Questionnaires (surveys)
• Create a prototype
Perspective: Individual
METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS
RAVIMOHAN REQUIREMENT DEFINITION
27
• Create a prototype
• Joint Application Design (JAD)
• Automated support tools, such
as EJAD and integrated CASE
tools
• Electronic Meeting Facilitation
Perspective: Collective (group)
METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS
RAVIMOHAN REQUIREMENT DEFINITION
28
• Feedback to the user(s)
• Technology-free information content
• Good communication skills needed
Three Common Threads in all Methods:
METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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:
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
39
• Four sub-activities
• Kozar’s Requirements
Model
• Enterprise Objects
REQUIREMENTS DETERMINATION
How to get started?????
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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*
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
Kozar’s Requirements Model - page 2 of 3
RAVIMOHAN REQUIREMENT DEFINITION
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.....
Kozar’s Requirements Model - page 3 of 3
Business Objectivescreate one or moreBusiness Tactics
Business Tacticscreate zero or more
Information SystemsObjectives
Information SystemsObjectives create
one or moreInformation Systems
Tactics
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
52
Enterprise Objects
InformationSystem
Business Objects
Technology Objects
Application Objects
RAVIMOHAN REQUIREMENT DEFINITION
53
• OBJECTS
• PATTERNS
• RESPONSIBILITIES
• SCENARIOS
AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION METHODOLOGY
EMPHASIZES:
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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:
AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION
METHODOLOGY
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
57
AN OBJECT-ORIENTED REQUIREMENTS DETERMINATION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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
RAVIMOHAN REQUIREMENT DEFINITION
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.