5-1 © Prentice Hall, 2007 Chapter 5: Determining Object-Oriented Systems Requirements Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer

Chapter © Prentice Hall, 2007 Chapter Objectives – Describe options for and develop plans for designing and conducting interviews to determine systems requirements – Explain advantages and pitfalls of observing workers and analyzing business documents to determine systems requirements – Participate in and help plan Joint Application Design (JAD) sessions – Use prototyping during requirements determination – Describe agile approaches to requirements determination – Select the appropriate methods to elicit system requirements

Chapter © Prentice Hall, 2007

Chapter © Prentice Hall, 2007 Characteristics for Successful Requirements Determination Impertinence Impartiality Relaxing of constraints Attention to details Reframing

Chapter © Prentice Hall, 2007

Chapter © Prentice Hall, 2007 How to Determine Requirements

Chapter © Prentice Hall, 2007 What Is Interviewing? Dialogue with user or manager to obtain their requirements Two forms: – Open-ended – conversational, questions with no specific answers in mind – Closed-ended – structured, questions with limited range of possible answers

Chapter © Prentice Hall, 2007 How to Conduct Interviews

Chapter © Prentice Hall, 2007 Interview Guide is a document for developing, planning, and conducting an interview.

Chapter © Prentice Hall, 2007 Each question in an interview guide can include both verbal and non-verbal information.

Chapter © Prentice Hall, 2007 What is Direct Observation? Watching users do their jobs Purpose – obtain firsthand, objective measures of employees’ interactions with the information system Can provide more accurate information than self-reporting in interviews Pitfalls – observed employees may change their behavior; time limitations make observation more difficult

Chapter © Prentice Hall, 2007 What is Document Analysis? Review of existing business documents Can give a historical and “formal” view of system requirements Relevant documents – mission statements, business plans, organizational charts, policy manuals, job descriptions, correspondences, reports from organizational studies

Chapter © Prentice Hall, 2007 Formal vs. Informal Systems Formal system – the official way a system works as described in organizational documentation Informal system – the way the system actually works

Chapter © Prentice Hall, 2007 Written work procedure is a business document that formally describes work processes. Provides useful information regarding system functionality and logic.

Chapter © Prentice Hall, 2007 Business form is a document that contains useful information regarding data organizations and possible screen layouts.

Chapter © Prentice Hall, 2007 Observations vs. Document Analysis

Chapter © Prentice Hall, 2007 Joint Application Design (JAD) Intensive group-oriented requirements determination technique Team members meet in isolation for an extended period of time Highly focused Resource intensive Started by IBM in 1970s

Chapter © Prentice Hall, 2007 JAD Team Members Session leadercoordinator Usersinformation source Managersinformation source Sponsorchampion Systems analystslisteners Scriberecorder IS stafflisteners

Chapter © Prentice Hall, 2007

Chapter © Prentice Hall, 2007 What Is Prototyping? A repetitive process in which analysts and users build a rudimentary version of an information system based on user feedback Repeated cycle: build, use, evaluate

Chapter © Prentice Hall, 2007

Chapter © Prentice Hall, 2007 When to Use Prototyping 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 © Prentice Hall, 2007 Pitfalls of Prototyping Prototyping has the following drawbacks: – Tendency to avoid creating formal systems requirement documentation – Prototypes may be indiosynchratic to the individual user and difficult to adapt for others – Prototypes are designed as standalone systems, so do not address data sharing and integration – Checks in SDC are bypassed, so issues like security, controls and standardization may be ignored

Chapter © Prentice Hall, 2007 What are Agile Methodologies? Techniques for eliciting user requirements that encourage continuous user involvement and adapt to incremental changes in system design over time Two approaches: – Agile user-centered design (similar to JAD) – eXtreme programming

Chapter © Prentice Hall, 2007 Steps in Agile User-Centered Design 1. Gather stakeholders together in sequestered environment 2. Give everyone a chance to vent complaints and record them 3. Determine and list most appropriate user roles 4. Determine tasks for each user role 5. Group tasks by similarity, into “interaction context” 6. Write a description for each task in an interaction context 7. Treat each interaction context as a single user interface screen, and sketch the user interface 8. List all the steps of the user interface, and make sure these can be accomplished in the prototype

Chapter © Prentice Hall, 2007 eXtreme Programming Typically involve 2-person programming teams Fusion of planning, analysis, design, and implementation Characterized by: – Short development cycles – Incremental planning – Focus on automated tests for monitoring development process – Reliance on evolutionary development

Chapter © Prentice Hall, 2007 eXtreme Programming Planning Game Players – business and development Three phases: – exploration – commitment – Steering Three stacks of story cards – Essential features – Value-added features – Noce-to-have features Story cards are replaced by task cards during Iteration Planning Game

Chapter © Prentice Hall, 2007