1DilbertScott Adams

2DilbertScott Adams

3DilbertScott Adams

4

Writing Effective Use Cases,

Alistair Cockburn

Use Cases: Requirements in Context,

Daryl Kulak

Applying Use Cases: A Practical Guide,

Geri Schneider; Jason P. Winters

References

5

Representing the System Requirements

RECAP

• Use cases represent the features that are seen by the system’s users.

• Users are the “actors” and the requirements are the “use cases” specifications.

6

Actors and Use Case Examples

Order-Processing Actors:– Customer

– Customer Rep

– Shipping Company

– Clerk

– Inventory System

– Accounting System

Defines system boundary… what is outside the system? The Actors.

7

Use Cases

Use Cases that “serve” the Customer:– Place order– Send order– Get status on order– Return product– Cancel order– Register Complaint

8

The Complete Use Case

The “Use Case” specs:– What must be done to deliver the “use” to the

“user”.– Specify:

• Basic functionality• Alternatives• Error conditions• Any and all preconditions• Postconditions

(Refer to Appendix B in the SRS)

9

Example: Place Order Use Case

Precondition: valid user logged into system.

Basic path:1. Begin with customer selecting Place Order

2. Enters name and address

3. If zip is entered, system supplies city & state

…

10. When payment is confirmed, mark order confirmed, return order ID to customer, and use case ends

Postcondition: the order is saved and marked confirmed.

10

Specifying a Use Case

• The Basic path example is one approach.

• Everything in one place…

• Continue refining adding branching or alternative flows… to show:

1. Other alternatives

2. Error handling

11

Alternative Paths

Examples:1. At any time before selecting Submit,

Customer can select Cancel. If Cancel is selected, the order is not saved and the Use Case ends.

2. In Step 7, if any information is incorrect, system is to prompt user to correct information

12

Branching - Example

Find Order Use Case1. User enters order ID, customer ID, or name.

2. User selects Find.

3. If user entered order IDa) Display that order

4. If user entered customer name or IDa) Return list of all orders for that customer

b) User will select one order from the list

c) Display that order

13

Repetition Examples

Place Order Use Case:4. For each product code entered:

a) Supply product description and price

b) Add price to the total

OR4. While customer enters product codes:

a) Supply product description and price

b) Add price to the total

14

Expanded, complex Use Cases

• Think of the “actor” as representing a class… with objects being specific instances of the class.

• Each instance may interact differently… does your Use Case specify how each instance will be responded to?

• The Basic path represents the response to the most common instance… and is called the primary scenario.

15

Secondary Scenarios

• Add alternatives to the Basic case• Write separate flows of events to

represent an alternate scenario• Place Order –scenarios for each case:

1. Order arrives that is complete, with correct payment

2. Order arrives missing payment3. Order arrives missing shipping address

16

Finding Secondary Scenarios

Walkthrough primary scenario and ask:

• Can more than one action be taken at this step?

• Can something go wrong at this step?

• Can something happen at any time?

Give each a secondary scenario name.

17

Adding “easy to understand” detail

Techniques:– Extends (or Uses)

• use case X is optionally extended by the functionality of use case Y

– Includes • use case X always includes use case Y

– Interfaces– Inheritance

<<includes>>X Y

<<extend>>X Y

18

Optionally Extends or Uses

Place Order

<<extends>> <<extends>>

SeasonalSale Price

FrequentCustomer Discount

Extension Points:Seasonal Sale Price, before Step 5Frequent Customer Discount, before Step 6

<<extends>> may never take place!!! … it depends.

19

Always Includes

Find Order Cancel Order<<includes>>

Factor out common behavior … can be re-used in other use cases

20

<< extend >>

• The “extending use case” defines logic that may be required during a given set of steps in the parent use case.

• Continues the behavior of the parent use case by conceptually inserting additional action sequences

• Used when an alternate course of action is complex

Note: The parent use case could include this behavior

21

<< include >>

• Represents one use case “invoking” another– Example: use case that encapsulates common

logic required by several use cases.

• Represent dependencies between use cases– Dashed line is used

22

Inheritance

NOT between use cases…

but between actors!! Customer

Customer Rep

Here, Customer Rep inheritsthe same role as the Customer.

23

Interface

• Describes how to interact with the actor or the use case.

• The interface specs are a set of operations.

• Specify for each operation:– What is passed– What is returned

Actor or Use Case supporting the interface

Actor or Use Case using the interface

24

Example of Interfaces

Place Order

User interface

Place order interface

Customer Rep

Customer

25

Place Order Interface - example

Supported by Place Order use case - and used by the Customer.

1. Get Product Description and Price (Product ID)

return Description, Price

2. Add Price to Total (Price) return Total

3. Submit Order ( ) return Order ID,

Where Description, Price, Total, and Order ID used by Customer

26

User Interface - example

Supported by Customer and used by Place Order use case.

1. Enter Name_and_Address ( )return Name, Address

2. Enter Product_Code ( ) return Product Code

3. Enter Credit_Card_Info ( )return Credit Card, Expiration Date

Name, Address, Product Code, Credit Card, and Expiration Date used by Place Order.

27

Diagramming Use Cases

• Activity Diagrams (Flow Charts)– Documents the steps in a Use Case

• Storyboarding to show the sequence of events from the user interface perspective

28

Storyboarding

• Designed to show the user interface.• Not what it will look like, but the user’s

“steps” in supporting the use case. • Objectives:

1. Clarify what is happening from the user’s point of view.

2. Get early acceptance from user of interface design.

3. Ensure that all required data attributes are identified and specified.

29

What information is needed?

Place Order

Place order interface

Customer

?

?

30

Collecting your data specs…

Reference for transparencies

Computer

Information

Systems Development:

Analysis and DesignMichael Powers

David Adams

Harlan Mills

31

Order Status

Storyboard - PrototypeShipping Name

Order ID Status

Product Description Quantity Item Status

OK

You are not asking for feedback on the GUI Design!

32

Know How To Uncover Reality

“… if I was designing and building an application used to track sales trends for the Sales department in my company, my first instinct, if I decided to research my users, would be to hunt down Molly from Sales and ask her what she would like the application to do…

Molly has no idea what your software might be able to do, and she almost certainly doesn’t have the technical chops to explain it.

33

She likely doesn’t realize that your product could make the task of creating a client birthday list for mailing out discount coupons a matter of two clicks, and therefore, she would never mention that this task is particularly gruesome and ask if your software could do it for her.

Thus, you need to look a little deeper to find out what Molly needs.

34

If you want to know what Molly wants the software to do, don’t ask her directly.

Instead, find out what she does, how she does it, and what she will want to do later.

Eventually, you’ll figure out how all that translates into a Web application.

For now, don’t think about Web applications. Think about users.

35

Developers tend to want to put up dialog boxes and error messages and all sorts of intrusive widgets that explain what’s going on behind the scenes, but users don’t care.

They only want to know the thing is working so they can accomplish their goals.

36

A user’s goals live outside the application.

The goals are personal.

Very few users have a goal of understanding how PeopleSoft works.

That goal is usually encapsulated by a larger goal.

Perhaps Molly wants to earn a promotion at work and thinks that understanding PeoplsSoft better will enable her to be more productive.

The application itself is not a goal at all – it’s an obstacle between Molly and her goal.

37

Acknowledging that the user’s goals have nothing to do with your Web application allows you to design something that pays more attention to the user’s real goals…

Goal-directed design means listening to users, getting to the truth of what they want, and creating applications from a more informed perspective.”

Designing the Obvious

Robert Hoekman, Jr.

Recommended!