FEASIBILITY ANALYSIS and REQUIREMENTS DETERMINATION

1. FEASIBILITY ANALYSISandREQUIREMENTS DETERMINATION

2. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) • 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 Design

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

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

5. ECONOMIC FEASIBILITY Example • Costs to develop, maintain and operate • Benefits when operational • Break-Even point (Costs = Benefits)

6. 1. Systems Development Costs(one-time; representative only) • Personnel: • 2 Systems Analysts (450 hours/each @ $45/hour) $40,500 • 5 Software Developers (275 hours/each @ $36/hour) 49,500 • 1 Data Communications Specialist (60 hours @ $40/hour) 2,400 • 1 Database Administrator (30 hours @ $42/hour) 1,260 • 2 Technical Writers (120 hours/each @ $25/hour) 6,000 • 1 Secretary (160 hours @ $15/hour) 2,400 • 2 Data Entry clerks during conversion (40 hrs/ea @ $12/hr) 960 • Training: • 3 day in-house course for developers 7,000 • User 3 day in-house course for 30 users 10,000 • Supplies: • Duplication 500 • Disks, tapes, paper, etc. 650 • Purchased Hardware & Software: • Windows for 20 workstations 1,000 • Memory upgrades in 20 workstations 8,000 • Mouse for 20 workstations 2,500 • Network Software 15,000 • Office Productivity Software for 20 workstations 20,000 • TOTAL SYSTEMS DEVELOPMENT COSTS: $161,670

7. 2. Annual Operating Costs(on-going each year) • Personnel: • Maintenance Programmer/Analyst (250 hrs/year @ $42/hr) $10,500 • Network Supervisor (300 hrs/year @ $50/hr) 15,000 • Purchased Hardware & Software Upgrades: • Hardware 5,000 • Software 6,000 • Supplies and Miscellaneous items 3,500 • TOTAL ANNUAL OPERATING COSTS: 40,000 • ----------------------------------------------------------------------------------------------------------- • TOTAL COST TO DEVELOP AND OPERATE THE SYSTEM: $201,670 ==========

8. 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 …Equate these to Dollars ($)

9. INTANGIBLE BENEFITS • Improved customer goodwill • Improved employee morale • Improved employee job satisfaction • Better service to the community • Better decision making …Equate these to Dollars ($)

10. BREAK EVEN (PAYBACK) ANALYSIS

11. REQUIREMENTS DETERMINATION* * AKA: Requirements Engineering, Requirements Management, Requirements Assessment

12. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) • 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 Design

13. 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 Stores • Order Fulfillment - Mail or Web Ordering • Manufacturing • Securities Portfolio Management • Space Shuttle Flight • Election Results • Video Games (Arcade and Home) Examples:

14. REQUIREMENTS DETERMINATION An activity used to determine what is “in” and what is “out”! Problem Domain Details Requirements Determination Activity Problem Domain Required Details

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

16. Observations about Requirements • Requirements are not supposed to dictate any details regarding the implementation of a solution. • We commonly define differing levels of necessity for our requirements, such as “absolutely must be satisfied”, “nice to have”, and “optional”. • Some requirements may apply to an entire system, while others apply only to part of the system. • Compromise is often necessary for conflicting requirements from different user(s). • Some requirements are static, while others are dynamic and evolve or emerge over time. • Requirements are not always easy to explain (communicate), understand, or document.

17. Documenting the Requirements 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.

18. Documenting the Requirements 2 of 2 • 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.

19. 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. • Project Requirements • stipulates resources for those conducting the project. • stipulates how different aspects of the project will be carried out. Our Focus

20. Requirements:Priorities and Constraints • Both product and project requirements may have associated priorities and constraints. • A priority is a level of importance assigned to an item • helps define which items take precedence over other items. • A constraint is a limit or a restriction placed on an item or situation • helps define the scope (boundaries) of an item or situation.

21. Types of Requirements There are three major types of requirements: • User-Driven • User-Reviewed • User-Independent

22. User-Driven Requirements • Defined and specified entirely by the user. • The systems analyst has little, or no, input to the definition and specification of the system requirements. • Not a desirable situation.

23. User-Reviewed Requirements • Specified by the user and the systems analyst working together. • It is not the analyst’s job to be an expert in the user’s application domain. • It is, however, required that systems analysts possess the skills, methods, techniques, and tools with which they effectively define, specify, and verify requirements through interactions with the user.

24. User-Independent Requirements • Defined and specified without a particular user being present. • The most common example of user-independent requirements are those requirements which are defined by software product vendors when they choose to develop a new software product.

25. METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS Three Perspectives: • Global • Individual • Collective (group)

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

27. METHODS USED TO GATHER INFORMATION SYSTEMS REQUIREMENTS Perspective:Individual • Interviews • Observations • Questionnaires (surveys) • Create a prototype

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

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

30. EXPLORE and ITERATE START WITH GOAL want/need, but they do not ask for what the user does not want/ need what the user wants/ needs do not want/need, but ask for REQUIREMENTS AMBIGUITY* * Requirements Ambiguity (adapted from [Gause & Weinberg])

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

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

33. Contradictions Problem #2 • 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.

34. Ambiguities Problem #3 • 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.

35. Duplications Problem #4 • 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.

36. Inaccuracies Problem #5 • 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.

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

38. Too Much Design Problem #7 • 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.

39. Irrelevant Information Problem #8 • 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.

40. REQUIREMENTS DETERMINATION How to get started????? • Four sub-activities • Kozar’s Requirements Model • Enterprise Objects

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

42. Framework #2: Requirements Model (Kozar)* A strategy that links information systems activities with established business activities. PREMISE: Information systems support business activities; therefore, associating information systems activities with business activities should be possible. Provides verification and validation (V & V) traceability * Adapted from Kozar, K.A., Humanized Information Systems Analysis and Design, McGraw-Hill Inc., 1989, pp. 61-62 and personal communication with the author.

43. Kozar’s Requirements Model is partially based on the traditional Top-Down MANAGEMENT Pyramid* More Abstract MISSION/ PURPOSE Reason for existence General statements GOALS Specific measurable statements OBJECTIVES Actions to accomplish objectives TACTICS & NEEDS Support for user actions INFORMATION SYSTEMS More Details * Note: The pyramid model on this slide is NOT part of Kozar’s Model

44. Kozar’s Requirements Model - page 1 of 3 Hired a marketing consultant Recommends better tracking of where sales orders come from Mkt. code on each promo. piece mailed out Develop mkt. codes Track sales based on mkt. codes Reports showing promo. piece effectiveness Modify Sales Order Fulfillment Sys (about 2 dozen changes) STIMULI BUSINESS OBJECTIVES BUSINESS TACTICS INFO. SYS. OBJECTIVES INFO. SYS. TACTICS A change of some type forces changed enterprise needs causing changed user behaviors requiring changed information needs requiring changed I.S. activities BENEFITS COSTS BENEFITS COSTS

45. Kozar’s Requirements Model - page 2 of 3 STIMULI BUSINESS OBJECTIVES BUSINESS TACTICS INFORMATION SYSTEMS OBJECTIVES INFORMATION SYSTEMS TACTICS Creates one or more Creates one or more Creates zero or more Creates one or more

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

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

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

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

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