2. GATHERING REQUIREMENTS

Object-Oriented Analysis and Design

NTPCUG

OOAD 2

Welcome!

• 10 (+) week book study

• Tom Perkins– tomperki@gmail.co

m

• Books available at Nerdbooks.com

• http://69.41.237.216/STUDYGROUPSIG/OOAD

OOAD 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

OOAD 4

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??

OOAD 5

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

OOAD 6

Your new programming job:

Doug’s Dog Doors

(High tech, automated dog doors)

Todd GinaFido

Your first CustomersWhat they want:

An automated, remote-

controlled

Dog Door barks !!!

want to push button to open door

No Problem

!!!

OOAD 7

So, you whip out some code …

(DEMO)

OOAD 8

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!

OOAD 9

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!

OOAD 10

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.

OOAD 11

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

OOAD 12

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 …

OOAD 13

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.

OOAD 14

Todd and Gina’s Dog Door, Version 2.0What 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? Excited3. 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.

OOAD 15

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

OOAD 16

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.

OOAD 17

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.

OOAD 18

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.

OOAD 19

DEMO 2 – Happy path demo

DEMO 3 – Check out the Alternate Path

OOAD 20

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?”

OOAD 21

For an introduction to Extreme Programming, see:

www.extremeprogramming.org – A Gentle Introduction