DesignFest Home

Non E-Commerce

Video Store


[ Home | Problem Collection | Results for this problem ]

Prepared by

Doug Bennett (IBM Consulting Group)


Background

Description of the Domain

Run Time Requirements

Use Cases

Information Interfaces

Build Time Requirements

Change Cases


Background

This problem is stated as a set of requirements. The requirements consist of two parts: the run time and build time requirements. Run time requirements are the familiar (mostly) functional requirements stated in terms of actors and use cases. The build time requirements, stated as change cases, are a quantification of most of the 'ility properties that are claimed to result from using object technology, CASE tools, etc. These properties include ease of maintenance and extension, robustness in the face of change, etc. While these familiar benefits are claimed to derive from using object technology, they actually result from designing the system to be robust and extensible. The purpose of this design problem to challenge DesignFest® participants to specify a system that can be shown to be flexible and robust. The change cases provide the means to evaluate the designs for flexibility and ability to change gracefully. This is a 1/2 day exercise, so there cannot be much detail in the specification.

To evaluate a design for its ability to support the change cases, ask the following three questions of the specification for each change case:

  1. How many components must be changed when the change case is applied to the system? (fewer is better)
  2. Will the interface of the impacted components change as a result of making the changes to the components? (No is better. If the interface changes, then the components that use the changed component must also change.)
  3. Is there behavior and/or information in the impacted component that is not related to the change? (If the answer is no, then there is no chance of having unexpected side effects from making the change)

Any design that claims to address these requirements can be evaluated on whether it provides the run time functionality and supports the build time change cases. If it does, then it is, at least, an adequate design.

This example is based on the example in 'Designing Hard Software, the Essential Tasks'.


Description of the Domain

ACME Video Store is a large, growing concern. They rent videos to retail customers. The rental period and amount of the rental varies with the time of week and the kind of video. They also rent VCRs and game cartridges. They are considering moving into CD disk and player rental, with digital audio tapes (DATs) another possibility. The store also sells a variety of general merchandise such as candy, popcorn, audio tapes, party favors, merchandise related to popular movies, and the like.

The store keeps information on its members (customers) and uses the list for its quarterly newsletter. When videos are overdue, they try to call the customer, and if they cannot reach him or her, they send a letter. Late fees are charged for overdue items.

Management sets limits on member activities, such as the maximum number of tapes that may be held by one member before rental privileges are revoked, the maximum number of tapes in a single transaction, and the maximum number of overdue items held by one member before rental privileges are revoked.

The store has a running bonus policy, such as every 12th tape rental is free, or the second tape rented each month is free. These policies are created and changed by management.

Management is looking for a system to help manage and control the financial aspects of the business. They expect to add more stores in the future and would like any system developed now to support additional stores. They would like to add inventory control in the future.


Run Time Requirements

The system should support rental and check in operations and provide pricing of the rental items.

It should track member financial activity and track current rentals outstanding and over due items held by members.

The system should track daily income, video returns, and overdue videos, at minimum.

The system should grow gracefully to handle multiple stores. At that time it should support remote dial in to any store and exercise of all the normal management activities: request reports, check activity for any view or period, etc., and exchange messages with the local store manager.

System Functions


Use Cases

Roles that Actors in the Domain Can Play

Sales clerk. The sales clerks answer customer questions and check out the videos and other items the customers are renting. They are also responsible for making calls about overdue videos.

Manager. The manager is responsible for tracking the performance of the store and the inventory of rental items. The manager makes the decisions about which items to add to the store, which to remove, and how to price and promote those items. The manager sets the various pricing policies used in the store.

Use Case Names and Descriptions

1. Sales Clerk Use Cases

1.1 Query inventory for a title (or actor or director). Clerk requests "Find" and fills in one or more of the following fields: title, actor, director. The system searches the inventory for a match. The list of matching items is displayed with an indication of how many copies the store has, whether any are in stock, and whether they are reserved.

1.2 Open membership. Clerk requests new member and enters the information into the system. The system verifies that the person is not a current or canceled member. It also checks to see if anyone else at the member's address is a current or canceled member. The clerk enters credit verification information. The system prints a membership card. The system creates an account for the new member.

1.3 Rent a tape in person. The clerk presses the "Rent" button and scans, or enters the item ID (by scanning the bar code or entering the bar code number) into the screen.

1.4 The system verifies that the item is on hand. If present, the system prompts for the customer's name. The name is verified as being a member and as not having exceeded any of the limits (maximum videos out, money owed, number of overdue items, etc.). If the name is not in the member list, the system prompts for "New Member" information: name, address, phone, and driver's license or credit card ID. The system determines the due date. Acceptable responses include a number of days or a date. The amount is shown for that item.

If the item is not present, the system indicates that the item is loaned out (and when it is due back), or that it is not carried.

As each item is entered, the system checks to see if a special applies. If it does, the modified price is shown and a message indicating which special was used is shown. There is a prompt for another item. Other items may be entered or "Total" pressed. The price and tax are shown. Clerk enters cash tendered, or credit card, and the system shows the required change. Two copies of a receipt are printed and the transaction is recorded by the system. When the clerk enters "Done," the inventory and cash drawer are updated.

1.5 Return a tape. Members return items to the desk, or for CDs and videos, may drop them off in the return box outside the store. The clerk enters the "Return" mode. He scans the bar code on the item. As soon as it finds a match, the complete item identification and member identity are presented.

The item is marked returned and is returned to the storage shelf. The system updates inventory and the customer's activity status.

If the tape is late, a late charge is calculated and displayed. The clerk may ask the customer for the late fee and receive payment. The clerk selects payment, enters cash tendered. System shows change and updates the cash drawer content. If the customer is not there, the clerk indicates "Not Paid" and the system adds the late fee to the member's account.

1.6 Verify membership. The clerk asks to verify a membership. The clerk enters the customer's name. The system checks to see if the name is a current member. If one or more members with the entered name are found, the systems presents the names and addresses to the clerk. The clerk may select one of the presented customers as the current customer.

If the customer has any outstanding rentals, overdue items, or money owed (from fines), the system will indicate the number and maximum past due time on the verification presentation.

1.7 Request list of overdue items. At least once per week, a clerk will request a list of overdue items. The list consists of the name, address, and phone of the member, the overdue items, and when they were due. The list may be printed out, or the clerk may select customers and the system will write a reminder letter for each customer selected, including the items due and when they were to be returned.

2. Manager Use Cases

2.1 Request daily, weekly, monthly yearly activity summaries. An operator with administrative permission may request activity summaries. These reports give the dollar income and number of rentals for each of the items selected for the specified time period. The user may specify items by name, director, artist, type of item, or all items. Member activity may be requested by individual member or by time period. Time periods may be specified as a single date, range of dates, week beginning, range of weeks, month, range of months. When a range of periods is specified, the report gives values for each period in the range. The report may be selected as summary or detailed. Summary gives a single value for each type of item selected. A detailed report gives values for all items included in the query.

2.2 Administer members. Clerk requests "Members." Clerk is prompted for member's name. Clerk enters name and is presented with a list of members with that name, showing name, address, and family members. Clerk may select one of the names. System presents detail of member information, including tapes out, overdue, money owed. Clerk may change any personal information: address, family members that may rent, phone, or credit card info. (Only a manager may alter the account information). Clerk may select "New," in which case the system presents a blank member data screen. Clerk fills information and saves it. That member may immediately check out videos.

2.3 Administer member rental limits. A manager requests "Rental Rules." The system presents the current rules and limits. The rules have the form of setting a limit on the value of variables. The variables include the number of items rented, number of overdue items held, the longest overdue period, money owed, and the maximum items in a single rental. If no values are provided, the limit is not applied.

2.4 Request member activity. A user with administrative permission may request reports at any time. The system presents a list of available reports. The user selects "Member Activity." The system prompts for member name or ID and the time period. For the indicated member the system retrieves and presents information on the member, the number of rentals made in the last month, the number of videos currently held, the number overdue, the longest overdue period, and the rental fees paid in the last month and since he or she became a member.

2.5 Administer specials. A manager may select "Edit Specials." The system presents a list of the names of current specials. User may select one to edit, remove, or create a new one. Each special has a name and a rule for calculating whether it applies. Specials are defined as calculations and relationships between a number of predefined variables. Those variables include the day of the week, the base price, the number of items being rented, and the number of items rented in the current month by the customer.

Information Interfaces

Two sample reports.

Report Content Overdue Report

Name

Titles Held

Overdue, days

Fine due

Smith, James

Horse Feathers

3

3

123 Maple

New York Stories

8

8

Any Town, NY 10234

Total

11

Member History Report

Name

Join Date

Total Rentals

Total Sales

Fines Paid

Fines Outstanding

Smith, J

3/4/92

123

10

4

0

Rules and Algorithms

User Constraints

  1. Using the system must be at least as fast as manual checkouts.
  2. Point of sale unit hardware must be Java enabled.


Build Time Requirements

The development organization and sponsor of the development is Rough and Ready Systems. R&R is a small software development company that hopes to grow substantially by leveraging the work done on past systems to benefit present and future systems. R&R has a contract with ACME Video to develop a system for ACME stores. It is R&R's first venture in rental store support systems.

Project Scope and Goals

The project will deliver a working system to the customer, beginning from a statement of need provided by the customer.

Role the Product Will Play in the Development Organization

  1. We wish to enter the market for rental store support systems.
  2. Video rental is the first product. Others might include furniture and contractor's equipment, home owner’s equipment, and party supplies.
  3. This system should be largely reusable in applications for other clients.
  4. The initial system should be readily configurable to suit other video stores.
  5. At minimum, the architecture structure should be applicable to other products.
  6. It is desirable to be able to reuse components in other systems.

Change Cases

Instances of Growth and Change

The change cases for this system are listed below:

  1. Add new rental and sale items, media, and equipment.
  2. Support school and corporate customers.
  3. Manage inventory tracking and reporting.
  4. Support growth to multiple stores.
  5. Integrate with accounting system.
  6. Add custom report definition capability.
  7. Integrate with a separate inventory database.
  8. Configure for another customer on a different platform, different look and feel, single workstation system.

    Ports

  9. Change computer platforms.
  10. Change presentation implementation package.
  11. Change Database.

    Future Configurations

  12. Equipment rental system.
  13. Retail and party goods rental system.

[Change cases 1-7 could be viewed as coming from the target customer. Remaining change cases were derived from the development sponsor's goals for the product.]

Development-Sponsor Constraints

Because this is a production project, all product features and product "ilities" must be demonstrated to be present in design documentation before proceeding with final implementation.

Further References

This problem is used as the example in "Designing Hard Software", Doug Bennett, Manning/Prentice-Hall, 1997. ISBN 1-884777-21-X


Last updated by Torsten Layda, SWX Swiss Exchange, DesignFest® Webmaster.