Upload
joy-james
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
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 build.
These are called REQUIREMENTS.
2
Who provides requirements?
1
2
3
4
5
3
1
2
3
4
5
Who provides requirements?
4
We call these people Stakeholders
Customer
End user
Development team members
Management
Technology providers
This chapter’s application
5
Doug + Dog + Door = Great Idea
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.
The initial product
7
This is a piece of cake, right? And you’re getting paid for this!
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.
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
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(); } }}
A word from the QA department…
11
Are you sure it works? Where are your tests?
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?
The customer is the final judge
13
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?
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?
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
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!
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
Requirements from the book
19
A scenario of how the system works
20
Do we need a diagram?
21
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
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
‣ 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
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.
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
How formal do you need to be?
27
If it works, use it!
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
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
Time to refactor
30
Fix the code!
Looking ahead
31
Possible features for V2
32
1
2
3
4