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

2. Chapter 5 5-2 © Prentice Hall, 2007 Chapter Objectives Af ter studying this chapter you should be able to: – Describe options for and develop plans for designing and conducting interviews to determine systems requirements – Explain advantages and pitfalls of observing workers and anayzing business documents to determine systems requirements

3. Chapter 5 5-3 © Prentice Hall, 2007 Chapter Objectives (Continued) Af ter studying this chapter you should be able to: – Participate in and help plan Joint Application Design (JAD) sessions – Use prototyping during requirements determination

4. Chapter 5 5-4 © Prentice Hall, 2007 Chapter Objectives (Continued) Af ter studying this chapter you should be able to: – Describe agile approaches to requirements determination – Select the appropriate methods to elicit system requirements

5. Chapter 5 5-5 © Prentice Hall, 2007

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

7. Chapter 5 5-7 © Prentice Hall, 2007

8. Chapter 5 5-8 © Prentice Hall, 2007 How to Determine Requirements

9. Chapter 5 5-9 © 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

10. Chapter 5 5-10 © Prentice Hall, 2007 How to Conduct Interviews

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

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

13. Chapter 5 5-13 © 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

14. Chapter 5 5-14 © 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

15. Chapter 5 5-15 © 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

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

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

18. Chapter 5 5-18 © Prentice Hall, 2007 Observations vs. Document Analysis

19. Chapter 5 5-19 © 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

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

21. Chapter 5 5-21 © Prentice Hall, 2007

22. Chapter 5 5-22 © 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

23. Chapter 5 5-23 © Prentice Hall, 2007

24. Chapter 5 5-24 © 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.

25. Chapter 5 5-25 © 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

26. Chapter 5 5-26 © 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

27. Chapter 5 5-27 © 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

28. Chapter 5 5-28 © 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

29. Chapter 5 5-29 © 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

30. Chapter 5 5-30 © Prentice Hall, 2007

31. Chapter 5 5-31 © Prentice Hall, 2007 Recap After studying this chapter we learned to: – Design and conduct interviews – Use direct observation and business document analysis – Work in JAD sessions – Use prototyping for requirements determination – Use agile methdologies for requirements determination