Chapter 5 Determining ObjectOriented Systems Requirements ObjectOriented Systems
Chapter 5: Determining Object-Oriented Systems Requirements Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer © Prentice Hall, 2004 5 -1
Chapter Objectives l After studying this chapter you should be able to: – Describe options for designing and conducting interviews. – Design, distribute and analyze questionnaires. Chapter 5 © Prentice Hall, 2004 2
Chapter Objectives (Continued) l After studying this chapter you should be able to: – Compare direct observation and business document analysis – Participate in and help plan Joint Application Design (JAD) sessions. Chapter 5 © Prentice Hall, 2004 3
Chapter Objectives (Continued) l After studying this chapter you should be able to: – Use prototyping during requirements determination. – Select the appropriate methods to determine requirements. – Understand requirements determination for Internet applications. Chapter 5 © Prentice Hall, 2004 4
Chapter 5 © Prentice Hall, 2004 5
Characteristics for Successful Requirements Determination l Impertinence l Impartiality l Relaxing of constraints l Attention to details l Reframing Chapter 5 © Prentice Hall, 2004 6
Chapter 5 © Prentice Hall, 2004 7
How to Determine Requirements Chapter 5 © Prentice Hall, 2004 8
What Is Interviewing? l Dialogue with user or manager to obtain their requirements l Two forms: – Open-ended – conversational, questions with no specific answers in mind – Closed-ended – structured, questions with limited range of possible answers Chapter 5 © Prentice Hall, 2004 9
How to Conduct Interviews Chapter 5 © Prentice Hall, 2004 10
Interview Guide is a document for developing, planning, and conducting an interview. Chapter 5 © Prentice Hall, 2004 11
Each question in an interview guide can include both verbal and non-verbal information. Chapter 5 © Prentice Hall, 2004 12
What Are Questionnaires? l. A written set of questions, sometimes with answers to select from, that is distributed to a cross-section of stakeholders in order to obtain system requirements Chapter 5 © Prentice Hall, 2004 13
Choosing Questionnaire Respondents l Goal: obtain a representative sample of stakeholders l Methods: – Convenience – Random – Purposeful – Stratified Chapter 5 © Prentice Hall, 2004 14
Designing Questions l Avoid ambiguity, especially in closed-ended questions l Pretest questions before use l Closed-ended questions: true/false, multiple choice, rating, ranking l Open-ended questions: for discovering potential probing questions Chapter 5 © Prentice Hall, 2004 15
Interviews vs. Questionnaires Chapter 5 © Prentice Hall, 2004 16
Other Approaches l What is Observation? – Watching users do their jobs – Can provide more accurate information than self-reporting (like questionnaires and interviews) l What is Document Analysis? – Review of existing business documents – Can give a historical and “formal” view of system requirements Chapter 5 © Prentice Hall, 2004 17
Observations vs. Document Analysis Chapter 5 © Prentice Hall, 2004 18
Written work procedure is a business document that formally describes work processes. Provides useful information regarding system functionality and logic. Chapter 5 © Prentice Hall, 2004 19
Business form is a document that contains useful information regarding data organizations and possible screen layouts. Chapter 5 © Prentice Hall, 2004 20
Other Business Documents l Report – Often contains pertinent summary information, and possibly screen layout ideas l Existing system documentation – Gives descriptions of use and inner workings of current information system Chapter 5 © Prentice Hall, 2004 21
Joint Application Design (JAD) l Intensive group-oriented requirements determination technique l Team members meet in isolation for an extended period of time l Highly focused l Resource intensive l Started by IBM in 1970 s Chapter 5 © Prentice Hall, 2004 22
JAD Team Members l Session leader l Users l Managers l Sponsor l Systems analysts l Scribe l IS Chapter 5 staff © Prentice Hall, 2004 coordinator information source champion listeners recorder listeners 23
Chapter 5 © Prentice Hall, 2004 24
What Is Prototyping? l. A repetitive process in which analysts and users build a rudimentary version of an information system based on user feedback l Repeated Chapter 5 cycle: build, use, evaluate © Prentice Hall, 2004 25
Chapter 5 © Prentice Hall, 2004 26
When to Use Prototyping l Prototyping is good when: – Users are unclear about their requirements. – The system affects a relatively small number of users. – Designs are complex. – Communication between users and analysts needs to be strengthened. – Rapid application development tools are available. Chapter 5 © Prentice Hall, 2004 27
Recap l After to: studying this chapter we learned – Design and conduct interviews – Design and use questionnaires – Use direct observation and business document analysis – Work in JAD sessions – Use prototyping for requirements determination – Apply requirements determination to a Web application Chapter 5 © Prentice Hall, 2004 28
- Slides: 28
