Presentation on theme: "Chapter 6 Determining System Requirements"— Presentation transcript:
1 Chapter 6 Determining System Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. ValacichChapter 6Determining System Requirements
2 Learning ObjectivesDescribe interviewing options and develop interview plan.Explain advantages and pitfalls of worker observation and document analysis.Explain how computing can support requirements determination.Participate in and help plan Joint Application Design sessions.Use prototyping during requirements determination.Describe contemporary approaches to requirements determination.
4 Characteristics for Successful Requirements Determination ImpertinenceImpartialityRelaxing constraintsAttention to detailsReframing
5 Deliverables of Requirements Determination From interviews and observationsInterview transcripts, observation notes, meeting minutesFrom existing written documentsMission and strategy statements, business forms, procedure manuals, job descriptions, training manuals, system documentation, flowchartsFrom computerized sourcesJAD session results, CASE repositories, system prototype displays and reports
6 Traditional Requirements Determination Methods Interviewing individualsInterviewing groupsObserving workersStudying business documents
7 What is Interviewing?Dialogue with user or manager to obtain their requirementsTwo forms:Open-ended: conversational, questions with no specific answers in mindClosed-ended: structured, questions with limited range of possible answers
8 Guidelines for Effective Interviewing Plan the interview.Prepare interviewee: appointment, priming questions.Prepare agenda, checklist, questions.Listen carefully and take notes (tape record if permitted).Review notes within 48 hours.Be neutral.Seek diverse views.
9 Interview Guide is a document for developing, planning and conducting an interview. Each question in an interview guide can include both verbal and non-verbal information.
10 Disadvantages of Individual Interviews Interview one person at a timeAdvantagesEasier to schedule than group interviewsDisadvantagesContradictions and inconsistencies between intervieweesFollow-up discussions are time consuming
11 Group Interviews Interview several key people together Advantages More effective use of timeCan hear agreements and disagreements at onceOpportunity for synergiesDisadvantagesMore difficult to schedule than individual interviews
12 Nominal Group Technique (NGT) A facilitated process that supports idea generation by groups.ProcessMembers come together as a group, but initially work separately.Each person writes ideas.Facilitator reads ideas out loud, and they are written on blackboard.Group discusses the ideas.Ideas are prioritized, combined, selected, reduced.
13 Other Approaches What is Direct Observation? Watching users do their jobsCan provide more accurate information than self-reporting (like questionnaires and interviews)What is Document Analysis?Review of existing business documentsCan give a historical and “formal” view of system requirements
14 Analyzing Procedures and Other Documents Types of information to be discovered:Problems with existing systemOpportunity to meet new needOrganizational directionNames of key individualsValues of organizationSpecial information processing circumstancesReasons for current system designRules for processing data7.14
15 Analyzing Procedures and Other Documents (cont.) Four types of useful documentsWritten work proceduresDescribes how a job is performedIncludes data and information used and created in the process of performing the job or taskBusiness formExplicitly indicate data flow in or out of a systemReportEnables the analyst to work backwards from the report to the data that generated itDescription of current information system7.15
16 Written work procedure is a business document that formally describes work processes, provides useful information regarding system functionality and logic.
17 Potential Problems with Procedure Documents May involve duplication of effortMay have missing proceduresMay be out of dateMay contradict information obtained through interviews
18 Formal vs. Informal Systems The official way a system works as described in organization’s documentationProcedure documents describe formal systemInformalThe way a system actually works in practiceInterviews and observation reveal informal system
19 Business form is a document that contains useful information regarding data organizations and possible screen layouts.
21 Contemporary Methods for Determining Requirements Joint Application Design (JAD)Brings together key users, managers, and systems analystsPurpose: collect system requirements simultaneously from key peopleConducted off-siteGroup Support SystemsFacilitate sharing of ideas and voicing of opinions about system requirements
22 Contemporary Methods for Determining Requirements (cont.) CASE toolsUsed to analyze existing systemsHelp discover requirements to meet changing business conditionsSystem prototypesIterative development processRudimentary working version of system is builtRefine understanding of system requirements in concrete terms
23 Joint Application Design (JAD) Intensive group-oriented requirements determination techniqueTeam members meet in isolation for an extended period of timeHighly focusedResource intensiveStarted by IBM in 1970s
25 JAD Participants Session Leader: facilitates group process Users: active, speaking participantsManagers: active, speaking participantsSponsor: high-level champion, limited participationSystems Analysts: should mostly listenScribe: record session activitiesIS Staff: should mostly listen
26 Joint Application Design (cont.) End ResultDocumentation detailing existing systemFeatures of proposed systemCASE Tools During JADUpper CASE tools are usedEnables analysts to enter system models directly into CASE during the JAD sessionScreen designs and prototyping can be done during JAD and shown to users
27 Joint Application Design (cont.) Supporting JAD with GSSGroup support systems (GSS) can be used to enable more participation by group members in JADMembers type their answers into the computerAll members of the group see what other members have been typing
28 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 requestsMost useful when:User requests are not clearFew users are involved in the systemDesigns are complex and require concrete formHistory of communication problems between analysts and usersTools are readily available to build prototype
29 Prototyping (cont.) Drawbacks Tendency to avoid formal documentation Difficult to adapt to more general user audienceSharing data with other systems is often not consideredSystems Development Life Cycle (SDLC) checks are often bypassed
30 Business Process Reengineering (BPR) Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and servicesGoalsReorganize complete flow of data in major sections of an organizationEliminate unnecessary steps
31 Business Process Reengineering (BPR) Goals (cont.)Combine stepsBecome more responsive to future changeIdentification of processes to reengineerKey business processesSet of activities designed to produce specific output for a particular customer or marketFocused on customers and outcomeSame techniques are used as were used for requirements determination
32 Business Process Reengineering (cont.) Identify specific activities that can be improved through BPRDisruptive technologiesTechnologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes
34 Agile Methodologies for Requirements Determination Continual user involvementReplace traditional SDLC waterfall with iterative analyze – design – code – test cycleAgile usage-centered designFocuses on user goals, roles, and tasksThe Planning GameBased on eXtreme programmingExploration, steering, commitment
36 Agile Usage-Centered Design Steps Gather group of programmers, analysts, users, testers, facilitatorDocument complaints of current systemDetermine important user rolesDetermine, prioritize, and describe tasks for each user roleGroup similar tasks into interaction contextsAssociate each interaction context with a user interface for the system, and prototype the interaction contextStep through and modify the prototype
38 Summary In this chapter you learned how to: Describe interviewing options and develop interview plan.Explain advantages and pitfalls of worker observation and document analysis.Explain how computing can support requirements determination.Participate in and help plan Joint Application Design sessions.Use prototyping during requirements determination.Describe contemporary approaches to requirements determination.
Your consent to our cookies if you continue to use this website.