INFORMATION SYSTEMS PLANNING & SELECTION :

1. 3 Chapter INFORMATION SYSTEMS PLANNING & SELECTION: [Determining System Requirements] PRESENTED BY: WALTER O Angol, Consultant IT

2. Learning Objectives • Describe options for designing and conducting interviews • Discuss planning an interview • Discuss using questionnaires to determine system requirements • Explain advantages and disadvantages of observing workers and analyzing business documents to determine requirements

3. Learning Objectives • Learn about Joint Application Design (JAD) and Prototyping • Discuss appropriate methods to elicit system requests • Examine requirements determination for Internet applications

4. The Information Systems Planning Process • The five step plan outlined here is sage advice for IS planning: • Understand the vision & objectives [both organizational and relating to IT] • Identify current system - what is/is not working • Establish measures to understand impact of changes • Identify specific opportunities, and • Buiild/exercise a prototype.

5. Performing Requirements Determination • Gather information on what the system should do from many sources • Users • Reports • Forms • Procedures

6. Performing Requirements Determination • Characteristics for gathering requirements • Impertinence • Question everything • Impartiality • Find the best organizational solution • Relaxation of constraints • Attention to detail • Reframing • View the organization in new ways

7. Deliverables and Outcomes • Types of deliverables: • Information collected from users • Existing documents and files • Computer-based information • Understanding of organizational components • Business objective • Information needs • Rules of data processing • Key events

8. 4.8

9. Traditional Methods for Determining Requirements

10. Traditional Methods for Determining Requirements • Interviewing and Listening • Gather facts, opinions and speculations • Observe body language and emotions • Guidelines • Plan • Checklist • Appointment • Be neutral • Listen • Seek a diverse view

11. Traditional Methods for Determining Requirements • Interviewing (Continued) • Interview Questions • Open-Ended • No prespecified answers • Close-Ended • Respondent is asked to choose from a set of specified responses

13. 4.13

14. 4.14

15. Traditional Methods for Determining Requirements • Administering Questionnaires • More cost-effective than interviews • Choosing respondents • Should be representative of all users • Types of samples • Convenient • Random sample • Purposeful sample • Stratified sample

16. Traditional Methods for Determining Requirements • Questionnaires • Design • Mostly closed-ended questions • Can be administered over the phone, in person or over the Internet or company intranet • Vs. Interviews • Interviews cost more but yield more information • Questionnaires are more cost-effective • See table 4-4 for a complete comparison

17. 4.17

18. Traditional Methods for Determining Requirements • Directly Observing Users • Serves as a good method to supplement interviews • Often difficult to obtain unbiased data • People often work differently when being observed

19. Analyzing Procedures and Other Documents • Types of information to be discovered: • Problems with existing system • Opportunity to meet new need • Organizational direction • Names of key individuals • Values of organization • Special information processing circumstances • Rules for processing data

21. Modern Methods for Determining Requirements • Joint Application Design (JAD) • Brings together key users, managers and systems analysts • Purpose: collect system requirements simultaneously from key people • Conducted off-site • Prototyping • Repetitive process • Rudimentary version of system is built • Replaces or augments SDLC • Goal: to develop concrete specifications for ultimate system

22. Joint Application Design (JAD) • Participants • Session Leader • Users • Managers • Sponsor • Systems Analysts • Scribe • IS Staff

23. Joint Application Design (JAD) • End Result • Documentation detailing existing system • Features of proposed system

25. Prototyping • Quickly converts requirements to working version of system • Once the user sees requirements converted to system, will ask for modifications or will generate additional requests • Most useful when: • User requests are not clear • Few users are involved in the system • Designs are complex and require concrete form • History of communication problems between analysts and users • Tools are readily available to build prototype

26. Prototyping • Drawbacks • Tendency to avoid formal documentation • Difficult to adapt to more general user audience • Sharing data with other systems is often not considered • Systems Development Life Cycle (SDLC) checks are often bypassed

28. Selecting the Best Alternative Design Strategy • Two basic steps • Generate a comprehensive set of alternative design strategies • Select the one design strategy that is most likely to result in the desired information system • Process • Divide requirements into different sets of capabilities • Enumerate different potential implementation environments that could be used to deliver the different sets of capabilities • Propose different ways to source or acquire the various sets of capabilities for the different implementation environments

29. Selecting the Best Alternative Design Strategy • Deliverables • At least three substantially different system design strategies for building the replacement information system • A design strategy judged most likely to lead to the most desirable information system • A Baseline Project Plan (BPP) for turning the most likely design strategy into a working information system

30. Generating Alternative Design Strategies • Best to generate three alternatives • Low-end • Provides all required functionality users demand with a system that is minimally different from the current system • High-end • Solves problem in question and provides many extra features users desire • Midrange • Compromise of features of high-end alternative with frugality of low-end alternative

31. Drawing Bounds on Alternative Designs • Minimum Requirements • Mandatory features versus desired features • Forms of features • Data • Outputs • Analyses • User expectations on accessibility, response time and turnaround time • Constraints on System Development • Time • Financial • Legal • Dynamics of the problem

32. Issues to Consider in Generating Alternatives • Outsourcing • The practice of turning over responsibility of some to all of an organization’s information systems applications and operations to an outside firm • Can provide a cost-effective solution

33. Issues to Consider in Generating Alternatives • Sources of Software • Hardware manufacturers • Packaged software producers • Custom software producers • Enterprise solution software • In-house development

34. Criteria for Choosing Off-the-Shelf Software • Cost • In-house versus purchased • Functionality • Mandatory, essential and desired features • Vendor Support • Installation • Training • Technical Support • Viability of Vendor

35. Criteria for Choosing Off-the-Shelf Software • Flexibility • Ease of customization • Documentation • User documentation • Technical documentation • Response Time • Ease of Installation

37. Validating Purchased Software Information • Information from vendor • Software evaluation period • Customer references from vendor • Independent software testing service • Trade publications

38. Hardware and Software Issues • Request for Proposal (RFP) • A document provided to vendors to ask them to propose hardware and system software that will meet the requirements of your new system

39. Implementation Issues • Technical and social aspects of implementation need to be addressed • Training • Disruption of work