INFORMATION SYSTEMS PLANNING

1
INFORMATION SYSTEMS PLANNING SELECTION
3
Chapter

• 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

12
(No Transcript)
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

20
(No Transcript)
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

24
(No Transcript)
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

27
(No Transcript)
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 organizations 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

36
(No Transcript)
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