Modern Systems Analysis and Design Third Edition Chapter 7 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 Key events 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 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 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 7.6

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 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 7.7

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 People cannot always be trusted to reliably report their own actions Often difficult to obtain unbiased data People often work differently when being observed 7.9

Analyzing Procedures and Other Documents Types of information to be discovered in a document: 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 7.10

Analyzing Procedures and Other Documents Four types of useful documents 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 7.11

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 Repetitive process Rudimentary version of system is built Replaces or augments SDLC Goal: to develop concrete specifications for ultimate system 4.12

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 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 4.14

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