Use-Case Model Exercise: the Movie Shop

We first analyze the system's functional requirements and then present the use-case model. For the purposes of producing the use-case model, we are only interested in those functional requirements that provide something of value for some actor.

• The system must be able to handle both physical and digital movies. functionality: None. This is an implementation requirement.
• It must be able to record which movies are sold and rented and by whom. functionality: Someone: buy movie Someone: rent movie
• For sold movies, the quantity sold should be recorded; for physical movie rental, which copy is rented and when it is due back should be recorded. functionality: Someone: enter movie quantity sold Someone: enter movie copy rented and due date

• The system should keep track of overdue rentals of physical movies and send email notices to customers who have movies overdue. functionality: Customer: receive overdue notice Note that how the notice is received (i.e., by email) is not important from a functionality perspective.
• There will be a customer membership option for an annual fee, which will entitle a member to discounts (10%) on the sale and rental of movies. functionality: Someone: enter member information Member: get discount
• Members should be able to make reservations for physical movie rentals either in person at the shop, by telephone or via the Web. functionality: Member: reserve movie Sales clerk: reserve movie Note that how the reservation is done is not important from a functionality perspective.

• A member can reserve at most five physical movies at any one time, but there is no limit on how many physical movies a member or nonmember can rent at any one time. functionality: No new functionality.
• As an added feature, the shop would like to allow customers (either members or nonmembers) to input, via the Web, mini-reviews (up to 100 words) and a rating (from 1, lowest, to 10, highest) of movies they have purchased or rented. functionality: Customer: enter movie review
• These reviews should be anonymous if the customer so wishes (i.e., customers can specify whether they want their name to be made known when other customers browse the reviews). functionality: Customer: browse movie reviews

• A sales clerk should be able to enter and update the following information about all customers (members or nonmembers): name, address, phone number, age, sex, and email address. functionality: Sales clerk: enter customer information Supersedes the requirement regarding someone entering member information. Sales clerk: update customer information
• Members are assigned a membership number by the shop when they become members and a password, which allows them to change their personal information and to buy and rent digital movies via the Web. functionality: Member: update personal information Member: buy movie Member: rent movie Clarifies who can use buy and rent functionality.
• The shop manager should be able to generate various reports on the sale and rental of movies. functionality: Manager: generate reports

• A sales clerk should be able to sell and rent physical movies and process the return of rented physical movies. functionality: Sales clerk: buy (sell) movie Sales clerk: rent movie Sales clerk: return rented movie Clarifies who can use buy and rent functionality.
• When selling or renting physical movies, a sales clerk must be able to look up customer information and determine whether the customer is a member. functionality: Sales clerk: lookup customer information
• A sales clerk must be able to enter basic information about a movie (i.e., movie id, title, leading actor(s), director, producer, genre, synopsis, release year, running time, selling price, and rental price). functionality: Sales clerk: enter movie information While there may be other functionality that the system should support, here we will only deal with the functionality identified in the requirements statement in constructing the use-case model.

Actors

A customer is someone who uses the system to enter

Customer

and browse reviews and who receives overdue notices from the system.

A member is someone who has paid a membership fee

Member

to the shop. In addition to what a customer can do, a member can also use the system to buy or rent movies, to reserve movies and to access and change their personal information.

Sales clerk A sales clerk is a shop employee who uses the system to

sell and rent movies, to reserve movies, to process the return of rented movies and to enter and update movie and customer/member information.

Manager

A manager is a shop employee. In addition to what a sales clerk can do, a manager can also generate various reports on sales and rentals of movies.

Member or Sales clerk Someone: enter movie quantity sold

Sales clerk

Someone: enter movie copy rented and due date Customer: receive overdue notice Member: get discount Member: reserve movie Sales clerk: reserve movie Customer: enter movie review Customer: browse movie reviews Sales clerk: enter customer information Sales clerk: update customer information Member: update personal

Should customer

information Member: buy movie

be an actor for

Member: rent movie

buy/rent movie?

Manager: generate reports Sales clerk: buy (sell) movie

No! Why?

Sales clerk: rent movie

Customers do not interact

Sales clerk: return rented movie

directly with the system to

Sales clerk: lookup customer information

buy/rent a movie.

Sales clerk: enter movie information

Member: buy movie Member: enter movie quantity sold Member: get discount

Buy Movie

Sales clerk: buy (sell) movie Sales clerk: lookup customer information Sales clerk: enter movie quantity sold Member: rent movie Member: get discount Sales clerk: rent movie Sales clerk: lookup customer information

Rent Movie

Sales clerk: enter movie copy rented and due date Sales clerk: return rented movie Customer: receive overdue notice

System/devices/communication methods are not actors.

⚫

(e.g., web, phone, etc. represent how something is done) ☞

Do not represent input/output devices as actors!

⚫

The client organization is not an actor.

(e.g., Movie Shop) Too large or obscure use cases.

⚫

(e.g., Shop For Movie, Provide Service To Customer) Too small use cases.

⚫

☞

Do not represent each operation/function as a use case!

⚫

Give meaningful names to the use-cases.

(e.g., names too vague or too long)

Do not represent nonfunctional requirements.

⚫

(e.g., 10% discount) Login is not a functional requirement.

⚫

• It is actually a non-functional (security) requirement that can be represented by an administration use case.

⚫

Incorrect use of use-case generalization.

A use-case model is not a structure chart!

⚫

A use-case model is not a domain model!

⚫

A use-case model is not a work of art!

⚫

Use case name:

Brief description:

Actors:

Precondition postcondition

Actor

System

Flow of activities Exception/alternative: