Transcript Chapter 4
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