REQUIREMENTS DETERMINATION RAVIMOHAN

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
s s s

Planning Feasibility Study (optional) Requirements Determination Conceptual Design Physical Design Construction and/or Purchase (prototype) Training Conversion - old to new Implementation Evolution - maintenance & enhancements

Analysis

s s s

Design

s s s s

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 costeffectiveness 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) • 5 Software Developers (275 hours/each @ Rs36/hour) • 1 Data Communications Specialist (60 hours @ Rs40/hour) • 1 Database Administrator (30 hours @ Rs42/hour) • 2 Technical Writers (120 hours/each @ Rs25/hour) • 1 Secretary (160 hours @ Rs15/hour) • 2 Data Entry clerks during conversion (40 hrs/ea @ Rs12/hr) Training: • 3 day in-house course for developers • User 3 day in-house course for 30 users Supplies: • Duplication • Disks, tapes, paper, etc. Purchased Hardware & Software: • Windows for 20 workstations • Memory upgrades in 20 workstations • Mouse for 20 workstations • Network Software • Office Productivity Software for 20 workstations 40,500 49,500 2,400 1,260 6,000 2,400 960 7,000 10,000 500 650 1,000 8,000 2,500 15,000 20,000

TOTAL SYSTEMS DEVELOPMENT COSTS:

Rs161,670

2. Annual Operating Costs

(on-going each year)

Personnel: • Maintenance Programmer/Analyst (250 hrs/year @ Rs42/hr) • Network Supervisor (300 hrs/year @ Rs50/hr) Purchased Hardware & Software Upgrades: • Hardware • Software Supplies and Miscellaneous items TOTAL ANNUAL OPERATING COSTS:

10,500 15,000 5,000 6,000 3,500 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 Á Faster turnaround Á Better credit Á Reduced credit losses Á Reduction of accounts receivables
RAVIMOHAN REQUIREMENT DEFINITION 8

…Equate these to Rupees

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 Intangible Benefits Benefit (Cost) Cum Benefit (Cost) (161,670) (161,670) 50,000 20,000 55,000 25,000 60,000 30,000 65,000 35,000 60,000 18,330 70,000 40,000 70,000 88,330

30,000 40,000 50,000 (131,670) (91,670) (41,670)

* This simple example does not consider the Time-Value of Money
(Cum Benefit (Cost 150,000 100,000 50,000 (50,000) (100,000) (150,000) (200,000) 0

88,330 18,330 (41,670) (91,670) (131,670) (161,670) 1 2 3 4 5 Cum Benefit (Cost)

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
s s s

Planning Feasibility Study (optional) Requirements Determination Conceptual Design Physical Design Construction and/or Purchase (prototype) Training Conversion - old to new Implementation Evolution - maintenance & enhancements

Analysis

s s s

Design

s s s s

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

Examples:

s s s s s s s

Name & Address Book CD Collection Course Registration Reservations Student Grades Payroll ATM machine & Banking in General Check-Out Counters at Retail Stores Order Fulfillment - Mail or Web Ordering Manufacturing Securities Portfolio Management Space Shuttle Flight Election Results RAVIMOHAN REQUIREMENT and Home) 12 Video Games (Arcade DEFINITION

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
• One very common way to document requirements is a textual 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

1 of 2

document containing a list of numbered or bulleted items, i.e.,

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

• 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
Ou rF oc us

– define the criteria that must, should, or, might be met by the delivered product. – stipulates resources for those conducting the project. – stipulates how different aspects of the project will be carried out.
RAVIMOHAN REQUIREMENT DEFINITION 18

• Project Requirements

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

GOAL
want/need, but they do not ask for

START WITH

EXPLORE and ITERATE

what the user wants/ needs

what the user does not want/ need

do not 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
• 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

31

Contradictions
• Contradictions may be the result of:
– – – – incomplete information imprecise specification methods a misunderstanding a lack of consistency check on the requirements.

Problem #2

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

Ambiguities

• Duplications may be

Duplications

Problem #4

• Sometimes duplications are not obvious
– the use of several different terms to describe the same item.

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

• The systems analyst must be careful when identifying and removing duplications.
RAVIMOHAN REQUIREMENT DEFINITION 34

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

Problem #5

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.

Problem #6

• 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 analysis is “to do the next person’s job.” • 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

Problem #7

– i.e., to both define a problem and to propose a (detailed) solution.

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

• Systems analysts are often reluctant to throw Problem #8 away any information.

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 General statements
Specific measurable statements Actions to accomplish objectives Support for user actions

GOALS OBJECTIVES TACTICS & NEEDS More Details INFORMATION SYSTEMS

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 OBJECTIVES of where sales orders come from BUSINESS TACTICS causing changed user behaviors Mkt. code on each promo. piece mailed out

BENEFIT S

COSTS

INFO. SYS. requiring changed information needs Develop mkt. codes OBJECTIVES Track sales based on mkt. codes Reports showing promo. piece effectiveness INFO. SYS. requiring changed I.S. activities Modify Sales Order Fulfillment Sys TACTICS (about 2 dozen changes)

BENEFIT S

COSTS

RAVIMOHAN

REQUIREMENT DEFINITION

43

Kozar’s Requirements Model - page 2 of 3
STIMULI

BUSINESS OBJECTIVES Creates one or more

BUSINESSone or more Creates TACTICS

INFORMATION SYSTEMS more Creates zero or OBJECTIVES

INFORMATION SYSTEMS TACTICS Creates one or more
RAVIMOHAN REQUIREMENT DEFINITION 44

Kozar’s Requirements Model - page 3 of 3

Business Objectives 1. ...... 2. ...... 3. ...... 4. ...... etc....

Business Tactics Info. Sys. Objectives Info. Sys. Tactics 1.1 ...... 1.1.1 1.1.1.1 1.2 ...... 1.1.2 1.1.1.2 1.3 ...... 1.1.3 1.1.1.3 2.1 ...... 1.2.1 1.1.1.4 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 create one or more Business Tactics

Business Tactics create zero or more Information Systems Objectives

Information Systems Objectives create one or more Information Systems 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 (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

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 page 4 of 4 2.1.2 Provide membership information reports such as (not limited to): a. least used memberships b. most used memberships c. delinquent memberships (both money owing and outstanding rentals)
4.1.1 Provide and maintain an inventory database for both sales and rental items a. provide current (up to date) inventory information on demand b. capability to add, change, and delete (remove) inventory information (sales and rental) 4.1.2 Provide inventory information reports such as (not limited to): a. least popular rentals b. most popular rentals c. delinquent tape rentals outstanding d. products “on order” (purchasing report) for sale and for rent items 5.1.1 Provide Sales Reports such as (not limited to): a. sales for a time period (day, days, week, weeks, month, etc.) by product code b. rentals for a time period (same as above)

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
GUI Forms & Windows

Problem Domain
Business Rules & Policies

Data Management
Database Activities

System Interaction
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
• Business Problem Transaction Data

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

Analyze results

Business Problem Results • Business Problem Integratio

Interact with other systems

page 2 of 3

Features Examples
x

Log Information:
• Maintain membership information • Maintain product information • Maintain vendor (supplier) information • Maintain employee security information • etc…

x

Conduct Business:
• Rental transaction • Sales transaction • Order products transaction etc...
RAVIMOHAN

REQUIREMENT DEFINITION

59

page 3 of 3

Features Examples
x

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…

x

Interact with other systems:
• Validation of Credit Cards RAVIMOHAN REQUIREMENT DEFINITION • etc...
60

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

Sign up to vote on this title
UsefulNot useful