Chapter

3

INFORMATION SYSTEMS PLANNING & SELECTION

:

[Determining System Requirements] PRESENTED BY: WALTER O Angol, Consultant IT 1

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 2

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

The Information Systems Planning Process  1) 2) 3) 4) 5) 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. 4

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

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 6

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 7

4.8

8

Traditional Methods for Determining Requirements 9

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 10

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 11

12

4.13

13

4.14

14

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 15

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 16

4.17

17

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 18

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 19

20

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 21

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

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

24

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 25

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 26

27

Selecting the Best Alternative Design Strategy   Two basic steps 1.

Generate a comprehensive set of alternative design strategies 2.

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 28

Selecting the Best Alternative Design Strategy  Deliverables 1.

At least three substantially different system design strategies for building the replacement information system 2.

A design strategy judged most likely to lead to the most desirable information system 3.

A Baseline Project Plan (BPP) for turning the most likely design strategy into a working information system 29

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 30

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 31

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 32

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

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 34

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

36

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

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 38

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