15
Copyright 2002 Prentice-H all, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 6 Determining System Requirements 7.1

Determining System Requirements

Embed Size (px)

Citation preview

Page 1: Determining System Requirements

Copyright 2002 Prentice-Hall, Inc.

Modern Systems Analysisand Design

Third Edition

Jeffrey A. Hoffer Joey F. George

Joseph S. Valacich

Chapter 6

Determining System Requirements

7.17.1

Page 2: Determining System Requirements

Project identification and selection

Project Initiation and

planning

Analysis

Design

Implementation

Maintenance

Waterfall Model

Page 3: Determining System Requirements

Requirements Determination

• Gather information on what system should do from many sources– Users– Reports– Forms– Procedures

7.37.3

Page 4: Determining System Requirements

Traditional Methods for Determining Requirements

• 1. Interviewing and Listening• 2. Administering Questionnaires• 3. Interviewing Groups• 4. Directly Observing Users• 5. Analyzing Procedures and Other Documents• 6. Joint Application Design (JAD)

• 7. Prototyping

7.47.4

Page 5: Determining System Requirements

1. Interviewing and Listening

– Gather facts, opinions,…– Observe body language and emotions

(feeling)– Guidelines

• Plan– Checklist– Appointment

• Be neutral• Listen

7.57.5

Page 6: Determining System Requirements

Interviewing (con’t)

– Interview Questions• Open-Ended

– No pre-specified answers• Close-Ended

– Respondent is asked to choose from a set of specified responses

– Additional Guidelines• Do not phrase questions in ways that imply a wrong or

right answer• Listen very carefully to what is being said• Type up notes within 48 hours• Do not set expectations about the new system

7.67.6

Page 7: Determining System Requirements

2. Administering Questionnaires

– More cost-effective than interviews– Choosing respondents

• Should be representative of all users

7.77.7

Page 8: Determining System Requirements

Questionnaires (con’t)

– Design• Mostly closed-ended questions• Can be administered over the phone or in person

– Vs. Interviews• Interviews cost more but yield more information• Questionnaires are more cost-effective

7.87.8

Page 9: Determining System Requirements

3. Interviewing Groups

– Advantages• More effective use of time• Enables people to hear opinions of others and to

agree or disagree

– Disadvantages• Difficulty in scheduling

7.97.9

Page 10: Determining System Requirements

4. Directly Observing Users

– Serves as a good method to supplement interviews

– Often difficult to obtain unbiased data• People often work differently when being observed

7.107.10

Page 11: Determining System Requirements

5. 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– Reasons for current system design– Rules for processing data

7.117.11

Page 12: Determining System Requirements

Analyzing Procedures and Other Documents (con’t)

• Four types of useful documents– Written work procedures

• Describes how a job is performed• Includes data and information used and created in the

process of performing the job or task

– Business form• Explicitly indicate data flow in or out of a system

– Report • Enables the analyst to work backwards from the report to the

data that generated it

– Description of current information system

7.127.12

Page 13: Determining System Requirements

6. Joint Application Design (JAD)

– Brings together key users, managers and systems analysts

– Purpose: collect system requirements simultaneously from key people

• End Result of JAD– Documentation detailing existing system– Features of proposed system

4.134.13

Page 14: Determining System Requirements

7. PrototypingPrototyping– Repetitive process– version of system is built– Replaces or augments SDLC– Goal: to develop concrete specifications for ultimate system

• 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

7.147.14

Page 15: Determining System Requirements

Prototyping (con’t)

• Drawbacks– Tendency to avoid formal documentation– Difficult to adapt to more general user

audience– Sharing data with other systems is often not

considered

7.157.15