32
HFOOAD Chapter 2 Requirements

HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

Embed Size (px)

Citation preview

Page 1: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

HFOOAD Chapter 2

Requirements

Page 2: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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

Page 3: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

Who provides requirements?

1

2

3

4

5

3

Page 4: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

1

2

3

4

5

Who provides requirements?

4

We call these people Stakeholders

Customer

End user

Development team members

Management

Technology providers

Page 5: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

This chapter’s application

5

Doug + Dog + Door = Great Idea

Page 6: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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.

Page 7: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

The initial product

7

This is a piece of cake, right? And you’re getting paid for this!

Page 8: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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.

Page 9: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

DogDoor Remote

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

Page 10: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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(); } }}

Page 11: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

A word from the QA department…

11

Are you sure it works? Where are your tests?

Page 12: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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?

Page 13: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

The customer is the final judge

13

Page 14: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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?

Page 15: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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?

Page 16: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

Define the problem‣ Talk to the customer

‣ Talk to other stakeholders

‣ Ask questions

‣ Brainstorm

‣ Look at the problem from many points of view

16

Page 17: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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!

Page 18: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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

Page 19: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

Requirements from the book

19

Page 20: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

A scenario of how the system works

20

Page 21: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

Do we need a diagram?

21

Page 22: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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

Page 23: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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

Page 24: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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

Page 25: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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.

Page 26: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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) involvedBasic Flow: The most common or expected path through the use caseAlternate Flows: Those paths or exceptions that can occurPreconditions: Things that must be true before the use case can beginPostconditions: Things that must be true when the use case ends successfully

Page 27: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

How formal do you need to be?

27

If it works, use it!

Page 28: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

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.

Page 29: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

29

DogDoor Remote

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

Page 30: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

Time to refactor

30

Fix the code!

Page 31: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

Looking ahead

31

Page 32: HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we

Possible features for V2

32

1

2

3

4