Use Cases

I l @ ve RuBoard

Use cases are both a blessing and a curse. On one hand, they are the absolute Bible of what you need to do to make the application work. Without a well-defined set of use cases, you're at the mercy of the client, who can then add new functionality on a whim and claim that it's inside the scope of the project.

On the other hand, use cases are often the dullest, least interesting, most tedious (did I mention boring?) part of the software-development process. They represent a methodical walk through every single way someone can possibly use the application and every possible outcome. It's somewhat like a brute-force computational approach to software design. In any event, it must be done, so it's best to just get started.

An important thing to remember is that, during the process of capturing use cases, you should concentrate on gathering the requirements rather than trying to figure out how to implement them, although you may find yourself flagging certain items as important to remember during implementation. Use-case development is supposed to be about brainstorming, not nitpicking the details.

Use Case: A New User Enters the Site

Start with a new user approaching the site. There are formalized diagrams for use-case analysis, but they can be a bit clumsy, so let's stick to a textual description.

Users are presented with a standard entry page, as was already described. However, in place of the normal "Hello John" message that a registered user with a cookie would receive, the new user gets a "Would you like to register?" prompt and a "Registered users log in here" link.

At this point, you might protest that neither of those elements appeared on the wireframes. This is an example of a feature that the client's business users (the people who understand the business needs of the site) wanted but the graphic designers didn't know about. So, we'll assume two things for the moment:

• Such elements will be designed by the time development begins.

• You need to keep a cookie around with the user ID (which is an e-mail address in the BFG example) to recognize and greet users when they log in.

On the entry page, users can immediately purchase the featured item(s) on the page. This means that both registered and unregistered users can place items in the cart. They can also navigate to a category, click the Login button, or click the Register button. A new user, however, should not be given access to the My Account pages because new users don't have them yet.

Use Case: An Existing User Enters the Site

This is essentially the same as the new user case, except that the personal greeting replaces the registration section. You also need to add a "Not John? Click here to log in as another user or register" button, which will then need to lead to another page for login and registration.

In addition, the My Account links will be active for existing users. Also, if the user had previously placed items in a basket and his session timed out, those items need to spill back into the cart. Notice that you now have a new requirement to create a persistent shopping cart based on this use case.

Use Case: A User Clicks a Category Page

When a user clicks one of the category links, the page is populated from a template. The top portion of the template shows the "hero" product. (In business jargon, this is the product that should be specially featured on a piece of advertising.) The identity of the hero product for a category is flagged in the database. When you hear this, you should immediately make a note to yourself that the category class will need a new attributea pointer to the product that is the featured product for the category.

As you saw in the wireframe in the previous chapter, on the Web page the product list is a table that lists the title, author, and price of each product in the category with Buy and More Info links. The Buy button should refresh the current page so that the mini-cart total will update.

One thing that should raise a red flag at this point and that has not yet been addressed are the number of items to display per page. Suppose that there are 250 products in a category. Do you display them all on a single page? Do you display the first 10 and have Back and Next buttons to let users navigate? And what order do you need to display these products in? By author? By title?

In this case, the client requests that all the appropriate titles be listed on the same page, that the default be to list by title, but that the user should be able to reorder the list by clicking the headings of the table. In the back of your mind, remember that the object you use to model the user session will need to store that data.

Use Case: User Clicks Buy from Any Page

Clicking the Buy button does several things. It adds the item to the cart, combining it with any existing items of the same type in the cart (one book A becomes two book A's rather than two entries for the same book). Then the server redisplays the same page with the updated mini-cart information.

Use Case: User Clicks More Info from Any Page

Clicking the More Info button brings the user to the product detail page. Again, this page is generated from a template with database calls. The only button on the page (other than the normal navigational tools) is a By button with a quantity box next to it.

Use Case: User Clicks View Cart from Any Page

The View Cart button takes the user to the view cart page, as described in the FRD. At this point, any promotional values are displayed (although the price in the mini-cart also reflects any promotions applied to the order).

Promotion Use Cases

Also at this point, you should have the details on the promotion design. Although some sites have hideously complex promotion requirements (I have worked on sites with as many as seven different types of promotions), the BFG site has only two. The Buy One, Get One Free (BOGOF) promotion allows a customer to get a gift if he buys certain promoted items. The Percent Off (%OFF) promotion specifies a certain percentage discount to be applied to targeted books.

And, as is sometimes the case, only one of these promotions will be live at the time the Web site is launchedthe BOGOF promotion. Thus, although the schema should support both types, you'll need only code one right now.

Buy One, Get One Free

The BOGOF promotion works as follows : The BOGOF can apply either to a single book title or to a category of books. If the customer qualifies for a BOGOF based on a purchase of a certain threshold number of items, a gift item is placed in the cart with a zero price.

This leads to several interesting scenarios. For example, suppose that the gift item is already in the cart. Is that item made a free item, or is another copy of the item added to the cart? And if qualifying items are removed from the cart, does the gift item get removed, or is it simply made a nonfree item?

In the BFG example case, the client has indicated that the gift items are not normally sold. For example, a customer might get a leatherette Palm Pilot case if he purchases J2ME books. Because the gifts will not appear in the normal category listings, the customer has no way to add them manually.

If items are removed, bringing the total in the cart below the threshold, the gift is also to be removed.

%OFF

The %OFF promo is much more straightforward. Again, the promotion can apply to a specific book or a category of books. In this case, the promotion requires that the specified discount be taken off the cover price.

If two %OFF promotions happen to apply to the same item, the discount is not compounded. The customer gets the highest of the discounts .

All discounts are indicated by a red line of text under the item in the cart, specifying what discount was received.

The end result of the promotion use cases is this: You'll need to be able to store two different kinds of items in the shopping cartitems that are promotional and regular items. This can be done with two different object classes or with a common class with a flag to indicate the promotional state of the item.

You'll also need objects to model the promotions themselves , objects that will iterate over the cart and modify the cart as appropriate for the individual promotions.

Use Case: User Clicks Checkout from Any Page

The Checkout button takes the customer to the billing and shipping (or checkout) page. At this point, the customer either can choose from a pre-existing shipping address and payment method (if he is a registered customer) or can fill in the form manually. A check box at the bottom of the page allows the customer to register as a new user, but this box is present only if the customer is not already logged in.

A list of shipping methods is also presented as radio buttons with shipping costs. This information is stored in the database; you'll need to add some new objects to model it.

Use Case: User Clicks Submit from Checkout Page

After the customer presses the Submit order button on the checkout page, the following validations and calculations need to occur:

• Check that first and last names are not blank

• Check that the shipping address line is not blank

• Check that the shipping city is not blank

• Check that the shipping state is selected on the pull-down menu

• Check that the shipping postal code is not blank and either is NNNNN or NNNNN - NNNN (where N is a digit)

• Check that the e-mail address is not blank and is of the form [e-mail]

• Check that the credit card number is not blank

• Check that the credit card prefix is valid for the credit card type

• Check that the credit card passes checksum validation

• Check that the credit card name and address pass validation checks for shipping name and address

• Check that the shipping method is selected

A failure of any of the validation checks causes the application to redisplay the page with all the data filled in and a red error message indicating the problem directly above the field in question.

If all the validations are successful, the order-confirmation page is displayed. This page includes the cost for the selected shipping method and any tax calculated (this is the first time you could calculate tax for an order because you previously didn't know where it was being shipped.)

Use Case: User Clicks Buy It on Order-Confirmation Page

When the customer confirms the order, the credit card number that was given is authorized for the charge, the order is written into the database, a confirmation e-mail is sent to the customer, and the customer is brought to the order-receipt page. If the credit card authorization fails, the customer is brought back to the shipping and billing page, with an error message at the top indicating that there was a problem with the credit card.

In addition, if a new address or credit card was used and the Save to Address Book or Save to Wallet box was checked, that data is spilled back to the appropriate database table. If the Register Me check box was checked, a new user is created on the fly.

Use Case: Registered User Clicks My Account from Any Page

Clicking on the My Account button (which is available only to registered users who have logged in) will present a user with the account page, which is basically a navigational tool to the three things that a user can do with an account.

Use Case: User Clicks the My Order History Button from the My Account Page

Clicking the My Order History button causes a list of all the orders placed during the last 30 days to appear in table form with the order number, date, and order total price displayed. Clicking an order number brings up the order receipt.

Use Case: User Clicks the My Address Book Button from the My Account Page

Clicking the address book brings up a list of all of a user's stored shipping addresses in table form, along with an Add New button. Clicking an address allows the user to edit the entry, which is validated as if it were being used in an order. Clicking Add New also brings up a blank form, which is validated in the same manner.

Use Case: User Clicks the My Wallet Button from the My Account Page

Clicking the My Wallet button brings up a list of stored credit cards. The user can edit or add to the list in the same manner as the address book, with the same validations that are done for a credit card in an order.

Use Case: User Clicks Create New User Button

This presents the customer with a form with the basic user information (e-mail address and password with password confirmation). Although a lot more information is required to actually place an order, the site will not gather address book details or credit card information at this point because that much information might be a barrier to entry, making the customer fill in a lot of information before he actually needs to.

I l @ ve RuBoard