1. HFOOAD Chapter 2 Requirements

2. We create software for a reason. We create software fro people. We need to know what the people want in the software we build. These are called REQUIREMENTS. 2

3. Who provides requirements? 1 2 3 4 5 3

4. 1 2 3 4 5 4 We call these people Stakeholders Customer End user Development team members Management Technology providers

5. This chapter’s application 5 Doug + Dog + Door = Great Idea

6. Your job should you choose to accept 6 Todd and Gina said they want a door installed with a remote button so they can open the door from their bedroom when their dog Fido wakes them up in the middle of the night.

7. The initial product 7 This is a piece of cake, right? And you’re getting paid for this!

8. Our requirements ‣ Push the button on the remote and open the door ‣ Push the button again to close the door 8 This is all we have to do. It’s just what Doug said the system needs to do. It seems like there should be more. Are you really sure this is all we need to do? I think we should do a little design before we implement it.

9. DogDoorRemote 9 ‣ Open ‣ Close ‣ Wait for signal from the remote Our requirements − two classes ‣ Tell the door to open or close ‣ Recognize when the button is pushed

10. 10 public class DogDoor { private boolean open; public DogDoor() { this.open = false; } public void open() { System.out.println("The dog door opens."); open = true; } public void close() { System.out.println("The dog door closes."); open = false; } public boolean isOpen() { return open; } public class Remote { private DogDoor door; public Remote(DogDoor door) { this.door = door; } public void pressButton() { System.out.println("Pressing the remote control button..."); if (door.isOpen()) { door.close(); } else { door.open(); }

11. A word from the QA department… 11 Are you sure it works? Where are your tests?

12. Test program from the book 12 public class DogDoorSimulator { public static void main(String[] args) { DogDoor door = new DogDoor(); Remote remote = new Remote(door); System.out.println("Fido barks to go outside..."); remote.pressButton(); System.out.println("\nFido has gone outside..."); remote.pressButton(); System.out.println("\nFido's all done..."); remote.pressButton(); System.out.println("\nFido's back inside..."); remote.pressButton(); } Are these good tests? Why or why not?

13. The customer is the final judge 13

14. Let’s back up a bit ‣ We did exactly what Doug told us to do ‣ We tested it ‣ The door worked as we programmed it ‣ The hardware works ‣ The software works 14 So, what’s did we do wrong?

15. What is a requirement? 15 ‣ A requirement is a feature that your system must have in order to satisfy the customer. ‣ A requirement is something your system must do. Did we meet the requirements?

16. Define the problem ‣ Talk to the customer ‣ Talk to other stakeholders ‣ Ask questions ‣ Brainstorm ‣ Look at the problem from many points of view 16

17. 17 We don’t want to have to get out of bed in the middle of the night. We want a door that we can open remotely and that will close after the dog goes out I want Fluffy to go out whenever she wants without needing me to go to the door. But, I don’t want the door to open unless I allow it. I just need to go out!

18. What we currently know ‣ Doug ‣ We need a system soon ‣ It has to be cost-effective ‣ Hardware engineers ‣ The door has two signals ‣ Get the current state (open or closed) ‣ Change the door’s state (open-to-closed or closed-to-open) ‣ The remote sends a single signal (button pressed) ‣ Customers’ stated requirements ‣ Door should be able to be opened remotely ‣ Door should close after dog goes out ‣ Customers’ implied requirements ‣ Door should not close while the dog going through it ‣ Door should close automatically and not by remote 18

19. Requirements from the book 19

20. A scenario of how the system works 20

21. Do we need a diagram? 21

22. 1 2 3 4 Fido doesn’t go outside, but stays in Fido doesn’t come back inside The door starts to close when Fido is going out … Other scenarios 22

23. Welcome to use cases ‣ A use case is ‣ A complete sequence of steps that provides value to someone ‣ Something your system must do ‣ Initiated by an Actor (someone or something not part of your system) 23

24. 24 ‣ Provide value ‣ Are complete ‣ Are initiated by an actor ‣ Describe a single goal of the system ‣ Be described by UML diagrams with text ‣ Be formally structured ‣ Be described using a language with formal semantics ‣ Be described by using software tools Use cases definitely… Use cases may… The essence of use cases

25. Use Case ≠ Scenario 25 A scenario is one way to achieve the goal from a specific starting point. A use case describes all ways to achieve the goal from a specific starting point.

26. Parts of a use case 26 Name: Usually verb-noun (e.g. enroll in course) Description: A paragraph or two describing the purpose and value (results) Actors: Name the actor(s) involved Basic Flow: The most common or expected path through the use case Alternate Flows: Those paths or exceptions that can occur Preconditions: Things that must be true before the use case can begin Postconditions: Things that must be true when the use case ends successfully

27. How formal do you need to be? 27 If it works, use it!

28. Dog door system V2 28 import java.util.Timer; import java.util.TimerTask; public class Remote { private DogDoor door; public Remote(DogDoor door) { this.door = door; } public void pressButton() { System.out.println("Pressing the remote control button..."); if (door.isOpen()) { door.close(); } else { door.open(); final Timer timer = new Timer(); timer.schedule(new TimerTask() { public void run() { door.close(); timer.cancel(); } }, 5000); } The responsibility karma is out of balance.

29. 29 DogDoorRemote Our requirements − two classes ‣ Tell the door to open or close ‣ Recognize when the button is pushed ‣ Open ‣ Close ‣ Wait for signal from the remote ‣ Close the door after 5 seconds

30. Time to refactor 30 Fix the code!

31. Looking ahead 31

32. Possible features for V2 32 1 2 3 4