Modern Systems Analysis and Design Third Edition Chapter 7 Determining System Requirements 7.1 Copyright 2002 Prentice-Hall, Inc .

Download Report

Transcript Modern Systems Analysis and Design Third Edition Chapter 7 Determining System Requirements 7.1 Copyright 2002 Prentice-Hall, Inc .

Modern Systems Analysis
and Design
Third Edition
Chapter 7
Determining System
Requirements
7.1
Copyright 2002 Prentice-Hall, Inc .
Performing Requirements Determination
System Analysis phase has three sub phases
 Requirements determination
 Requirements structuring
 Generating alternative design and selecting best one
Gather information on what system should do from many
sources




Users
Reports
Forms
Procedures
Performing Requirements Determination
Characteristics for gathering requirements
 Impertinence
 Question everything
 Impartiality
 Find the best organizational solution
 Relaxation of constraints assuming anything is possible
 Attention to detail
 Reframing
 View the organization in new ways
7.3
Deliverables and Outcomes
Types of deliverables:

Information collected from users
interview transcripts, questionnaire responses, notes of observation

Existing written information
sample business forms and reports, procedure manuals, training manuals

Computer-based information
CASE repository contents and reports of existing system

Understanding of organizational components
 Business objective
 Information people needs
 Data handled and when, how and who moves data
 Rules of data processing
7.4
 Key events
Traditional Methods for Determining
Requirements





Individually interview people who knows current system
Survey people via questionnaires
Interview group of people with different needs
Observe workers at selected times to see how data is handled
Study business documents
Interviewing and Listening
7.5
Guidelines for Effective Interviewing
 Prepare interviewee: set up appointment time and duration convenient
for interviewee
 Prepare checklist, agenda and questions: to know the sequence and
duration of questions to ask
 Listen carefully and take notes
 Review notes within 2 days of interview
 Be neutral and seek diverse views
Traditional Methods for Determining
Requirements
Choosing Interview Questions

Open-Ended questions
 No pre-specified answers like what you think about …?
 Advantages: give interviewees more sense of involvement; put
interviewee at ease as they respond in their own words
 Disadvantages: takes long time to answer; difficult to summarize

Close-Ended questions





7.6
Respondent is asked to choose from a set of specified responses
Examples: True or False, Multiple choice, rating a response
Advantages: takes less time to answer and more topics covered
Disadvantages: useful information may be overlooked
Additional Guidelines




Do not phrase questions in ways that imply a wrong or right answer
Listen very carefully to what is being said – take notes or record
Type up notes within 48 hours
Do not set expectations about the new system
Traditional Methods for Determining
Requirements
Administering Questionnaires

Questionnaires Vs Interviews
 Interviews are very expensive and time-consuming
 Questionnaires are not expensive and can gather information




7.7
from many people simultaneously in a relatively short time
Interviews can have limited number of questions and limited
number of people contacted
Questionnaires give less depth of understanding as they
provide no direct means to ask follow-up questions
Interviews provide the opportunity to judge the truthfulness of
responses by the words or voice tone or the body language of
the respondent
Questionnaires do not provide the opportunity to judge the
accuracy of responses
Traditional Methods for Determining
Requirements
Choosing Questionnaire respondents – if more people to
survey decide which set of people to send questionnaire to or
which questionnaire to send to which group of people




Convenient: people at a local site or willing to get surveyed
Random sample: select any person from a list
Purposeful sample: select people who satisfy certain criteria
Stratified sample: select random set from each of many categories
Designing Questionnaires
Questionnaires are most useful when used for specific purpose and
not for general information gathering
 Questionnaires typically include closed-ended questions
 Questionnaires must be extremely clear in meaning and logical in
sequence as any doubts cannot be cleared
How often(?) do you backup your computer files (C: or hard disk)?
a) frequently
b) sometimes
c) hardly at all
d) never

7.8
Traditional Methods for Determining
Requirements
Interviewing Groups – interview several key people at once by
several analysts, one asks questions other takes notes


Advantages
 More effective use of time
 Enables people to hear opinions of others and to agree or disagree
Disadvantages
 Difficulty in scheduling convenient time as many people are involved
Nominal Group Technique


Facilitated process to support idea generation by groups
Individuals work alone to generate ideas which are pooled under
guidance of a trained facilitator which are then discussed and then
number of ideas are reduced and carry forward
Directly Observing Users


7.9
People cannot always be trusted to reliably report their own actions
Often difficult to obtain unbiased data
 People often work differently when being observed
Analyzing Procedures and Other Documents
Types of information to be discovered in a document:








7.10
Problems with existing system
Opportunity to meet new need
Organizational direction
Titles and names of key individuals
Values of organization
Special information processing circumstances
Reasons for current system design
Rules for processing data
Analyzing Procedures and Other Documents
Four types of useful documents



7.11

Written work procedure for an individual or a work group
 Describes how a job is performed
 Includes data and information used and created in the
process of performing the job or task
 Formal systems: official way a system works as described in
the organizational documentation.
 Informal system: the way a system actually works
Business form
 Explicitly indicate what data flow in or out of a system and
which are necessary for the system to work
Report generated by current systems
 Enables the analyst to work backwards from the report to the
data that generated it – company’s performance is past years
Description of current information system
 If the current system is computer based
Modern Methods for Determining
Requirements
Joint Application Design (JAD)





Similar to group interview as it brings together key users, managers
and systems analysts
Purpose: collect system requirements simultaneously from key
people
Particular structure of roles and agenda is followed and analysts
control the sequence of questions answered by users
Conducted off-site to keep participants away from distractions
may last from four hours to an entire week and may consist of many
weeks
Prototyping


4.12


Repetitive process
Rudimentary version of system is built
Replaces or augments SDLC
Goal: to develop concrete specifications for ultimate system
Joint Application Design (JAD)
Participants







Session Leader – organizes and runs the JAD
Users – key users of the current system
Managers of the workgroups who use the current system
Sponsor – needed to cover expenses
Systems Analysts – to learn from users and managers
Scribe – takes notes
IS Staff – other IS staff like programmers, database analysts
JAD sessions are usually held in special-purpose rooms where
participants sit in a horse-shoe shaped tables.
rooms have whiteboards, audio-visual tools like overhead
projectors, flip charts, transparencies
4.13
Joint Application Design (JAD)
End Result


Documentation detailing existing system
Features of proposed system
CASE Tools During JAD



4.14
Upper CASE tools are used
Enables analysts to enter system models directly into CASE
during the JAD session
Screen designs and prototyping can be done during JAD
and shown to users
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
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
7.15