W86-T&M-I L5

 

Writing Use Cases

This is perhaps the most difficult part of understanding Use Cases. What constitutes a "good" Use case?

  • Describes what the system DOES
    • Does not describe what the system "must" do, "should" do or "could" do.
  • Does not describe HOW the system achieves it's goals
    • Describing HOW is part of design and scenarios are better suited for describing how things work
  • Does NOT describe the User Interface
    • Describes the logical interaction vs physical interaction
    • Eg: "User clicks the 'change password' link" - physical
    • "User indicates that he/she wishes to change his/her password" - logical

 

Identifying Use Cases

  • Identify the goals of each actor
    • What do the actors require from the system?
    • The actor arrives, interacts with the system, then leaves.
  • Review requirements
  • Identify tasks which the system must perform
  • Analyze the roles people fulfill within the business and the tasks they perform

 

Use Case Modeling Errors

  1. Write functional requirements instead of usage scenario text.
    1. We need to keep a clear distinction between (active voice) usage descriptions (behavior) and (passive voice) system requirements.

 

  1. Describe attributes and methods rather than usage.
    1. Methods shouldn’t be named or described in case text because they represent how the system will do things, as opposed to what the system will do.

 

  1. Write the use cases too tersely.

 

  1. Divorce yourself completely from the user interface.

 

 

  1. Write using a perspective other than the user’s, in passive voice.

 

  1. Describe only user interactions; ignore system responses.
    1. Your use case text describes both sides of the dialog between the user and the system, and that all of the software behavior that you’re trying to discover happens on the system side of that dialog.

 

  1. Omit text for alternative courses of action.

 

  1. Focus on something other than what’s “inside” a use case, such as how you get there or what happens afterward.

 

  1. Include information which is redundant to the rest of the system documentation.

 

  1. Do not include information about other use cases.

 

1

Basic Course: The Customer enters the required information. The system validates the information and creates a new Account object.

Alternate Course: If any data is invalid, the system displays an appropriate error message.

 

2

The Customer enters his or her user ID and password, and then clicks the Log In button. The system returns the Customer to the Home Page.

 

3

On the Shopping Cart Page, the Customer modifies the quantity of an Item in the

Shopping Cart, and then presses the Update button. Then the Customer presses the

Continue Shopping button.

 

4

Basic Course: If the Customer modifies the quantity of an Item in the Shopping

Cart, and then presses the Update button, the system will store the new quantity,

and then compute and display the new cost for that Item….

Alternate Course: The system will delete an Item from the Shopping Cart if the

quantity of that Item in that Shopping Cart becomes 0.

 

5

The Receiving Clerk ensures that the Line Items listed on the Purchase Order match

the physical items. The Clerk waves the bar code on the packing slip under the

sensor at the receiving station. The system executes a “change order status” method

to change the Order status to “fulfilled,”and then calls the changeQuantityOnHand

method for each of the variousBooks. The Clerk hands the Books off to the Inventory

Clerk.