1. 2. GATHERING REQUIREMENTS Object-Oriented Analysis and Design NTPCUG

2. OOAD2 Welcome! 10 (+) week book study Tom Perkins –tomperki@gmail.comtomperki@gmail.com Books available at Nerdbooks.com http://69.41.237.216 /STUDYGROUPSIG/ OOADhttp://69.41.237.216 /STUDYGROUPSIG/ OOAD

3. 3 Review (Chapter 1) 3 Steps to Good Software 1.Make sure the software does what the customer wants it to do 2.Apply basic OO principles to add flexibility 3.Strive for a maintainable, reusable design

4. OOAD4 Today’s Topic: Requirements How to figure out what the customer wants How to understand the problem Constraints: –Customers may not able to express what they want –Customers may not know what they want ??

5. OOAD5 Learning Objectives Identify the characteristics of a good software requirement Understand the need for the developer to understand the problem Describe a Use Case Create a Use Case Identify the purpose of an Alternate Path Define a scenario Be aware of Extreme Programming methodology

6. OOAD6 Your new programming job: Doug’s Dog Doors (High tech, automated dog doors) Todd Gina Fido Your first Customers What they want: An automated, remote- controlled Dog Door barks !!! want to push button to open door No Problem !!!

7. OOAD7 So, you whip out some code … (DEMO)

8. OOAD8 So, the dog door is installed … Todd and Gina are excited … The first night … Fido barks, button pressed … Fido goes out … Great But, the next morning, who is in the kitchen but …! Todd and Gina didn’t expect to CLOSE the door – Pressed button only once!

9. OOAD9 Remember Rule #1… 1.Make sure your software does what the customer wants it to do. New approach … 1. Gather requirements by talking with Todd and Gina. 2. Figure out what it really should do. 3. Get additional info from Todd and Gina. 4. Build the door software right!

10. OOAD10 So, what is a requirement? A requirement is a specific thing your system has to do to work correctly! Formal defn (systems engineering or software engineering): A requirement is a singular need detailing what a particular product or service should be or do.

11. OOAD11 The best way to establish requirements: TALK TO THE CUSTOMER!!! Focus on WHAT, not HOW … Todd and Gina: “Single button” “door to close automatically after a few seconds” “at least 12” tall for Fido” Todd Gina

12. OOAD12 Todd and Gina’s Dog Door, Version 2.0 Requirements List 1. The door opening should be at least 12” tall. 2. A button on the remote control opens the dog door if the door is closed, and closes the dog door if the door is open. 3. Once the door has opened, it should close automatically if the door isn’t already closed. But … Customers don’t always know what they need. You’ve got to think beyond what the customer says Understand the problem! Break the problem into a series of steps, tasks, or events …

13. OOAD13 Todd and Gina’s Dog Door, Version 2.0 What the Dog Door Does 1. Fido barks to be let out. 2. Todd or Gina hears Fido barking. 3. Todd or Gina presses the button on the remote control. 4. The dog door opens. 5. Fido goes outside. 6. Fido does his business. 7. Fido goes back inside. 8. The door shuts automatically.

14. OOAD14 Todd and Gina’s Dog Door, Version 2.0 What the Dog Door Does (“What can go wrong?” Analysis) 1. Fido barks to be let out. Doesn’t bark? Scratches? 2. Todd or Gina hears Fido barking. Not home? Excited 3. Todd or Gina presses the button on the remote control. Door jam? Hardware problem? 4. The dog door opens. 5. Fido goes outside. Stays inside? 6. Fido does his business. 7. Fido goes back inside. What if door has closed? Can Todd and Gina hear him bark to press button again?” 8. The door shuts automatically.

15. OOAD15 Todd and Gina’s Dog Door, Version 2.0 What the Dog Door Does 1. Fido barks to be let out. 2. Todd or Gina hears Fido barking. 3. Todd or Gina presses the button on the remote control. 4. The dog door opens. 5. Fido goes outside. 6. Fido does his business.. 6.1 The door shuts automatically. 6.2 Fido barks to be let in. 6.3 Todd or Gina hears Fido barking (again). 6.4 Todd or Gina presses button on remote control. 6.5 The dog door opens (again). 7. Fido goes back inside. 8. The door shuts automatically. Todd and Gina didn’t think of this! extra steps are called an Alternate Path

16. OOAD16 We’ve developed a Use Case. A Use Case describes what your system does to accomplish a singular goal. Focuses on “what”, not “how” Single goal: different goal, different use case Users outside the system: Gina, Todd, Fido Dog door and remote inside the system Formal Use Case: A technique for capturing the potential requirements of a new system or a software change. It provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific goal. Scenario: a path through the use case that will result in the goal.

17. OOAD17 Todd and Gina’s Dog Door, Version 2.0 Requirements List 1.The door opening should be at least 12” tall. 2.A button on the remote control opens the dog door if the door is closed, and closes the dog door if the door is open. 3.Once the door has opened, it should close automatically if the door isn’t already closed.

18. OOAD18 Todd and Gina’s Dog Door, Version 2.0 Dog Door Use Case 1. Fido barks to be let out. 2. Todd or Gina hears Fido barking. 3. Todd or Gina presses the button on the remote control. 4. The dog door opens. 5. Fido goes outside. 6. Fido does his business.. 6.1 The door shuts automatically. 6.2 Fido barks to be let in. 6.3 Todd or Gina hears Fido barking (again). 6.4 Todd or Gina presses button on remote control. 6.5 The dog door opens (again). 7. Fido goes back inside. 8. The door shuts automatically.

19. OOAD19 DEMO 2 – Happy path demo DEMO 3 – Check out the Alternate Path

20. OOAD20 REQUIREMENTS AND USE CASES KEY POINTS Requirements: things your system must do correctly. Initial requirements  customer Create Use Cases to help you understand the problem. Use Cases state what your system should do. A use case has single goal, but may have multiple paths. A good use case has a starting point, a stopping condition, an external initiator, and a clear value to the user. A good use case tells the story of how your system works. Each goal in your system has its own use case. A requirements list should make all use cases possible. Most of your effort will come in handling alternate paths, rather than the happy path. Alternate paths handle situations where things go wrong! Always ask, “What can go wrong?”

21. OOAD21 For an introduction to Extreme Programming, see: www.extremeprogramming.orgwww.extremeprogramming.org – A Gentle Introduction