Modern Systems Analysis and Design Third Edition Chapter

Modern Systems Analysis and Design Third Edition Chapter 6 Determining System Requirements 7. 1

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

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 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 7. 5

Traditional Methods for Determining Requirements �Questionnaires Vs Interviews �Interviews are very expensive and time-consuming �Questionnaires are not expensive and can gather information 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 �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 7. 6

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 � 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 How often(? ) do you backup your computer files (C: or hard disk)? a) frequently b) sometimes c) hardly at all d) never 7. 7

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 7. 8

Modern Methods for Determining Requirements A. 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 analysts control the sequence of questions answered by users �may last from four hours to an entire week and may consist of many weeks B. Prototyping �Goal: to develop concrete specifications for ultimate system 4. 9

B. 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. 10