Video rental system

Published: 23, March 2015

1.0 Preliminary Investigation

1.1 Case Study
The project we investigated is a video rental system. That is EZzy Video which is a
chain of 14 video stores scattered throughout a major metropolitan area. The chain
started with a single store several years ago and has grown to its present size. The
owner of the chain Eddie Stone, knows that to complete with the national chains will
require a state-of-the-art movie rental system.

Each store has a stock of movie and video games for rent. It is important to keep
track of each movie title to know and to identify its category (classical, drama,
comedy and so on), its rental type (new release, standard), movie rating, and other
general information such as movie produces, release date, cost, and so forth. In
addition to tracking each title, the business must track each individual copy to note
its purchase date, its condition and its rental status. User function must be provided
to maintain this inventory information

Customers, the lifeblood of the business, are also tracked. EZzy Videos considers
each family to be a customer, so special mailings and promotions are offered to
each household. For any given customer, several people may be authorized to rent
videos and games. The primary contact for each customer can also establish rental
parameters for other members of the household. For example, if a parent wants to
limit a child's rental authorization to only PG and PG-13 movies, the system will
track that.

Each time a movie is rented, the system must keep track of which copies of which
movie and games are rented; the rental date and time and the return date and time
and the household and person renting the movie. Each rental is considered to be
open, until all of the movie and games have been returned. Customers pay for
rentals when checking out videos at the store.

1.1 Mission Statement

Based on the case study, EZzy Video which is a chain of 14 video stores scattered
throughout a major metropolitan area. The owner of the chain Eddie Stone, knows
that to complete with the national chains will require a state-of-the-art movie rental
system.

1.2 Project Objectives (Current)

The EZzy video are established to give customers a lovely rental service with more
variety on movie selection. With this in mind, Eddie Stone established The EZzy with
a goal to make customers have a more convenient and comfortable environment to
rent their movies. Eddie Stone also hope that we can complete his state-of-the-art
movie rental system.

By implementing our system, EZzy will have a competitive advantage over other
video stores in the area and a greater overall productivity in terms of sales. In the
long run, this project will strengthen the asset turnover in the video store and help
the video store to make more profit.

1.3 Project Goals (Current)

EZzy video also be the top compare with other video rental shop. They have many
higher requirements , goals and vision which are :
Developing a newer system better than current system.
Enlarge the marketing of video rental to other state or city.
Manage to build up a friendly environment to customers.
The number of members increase to 20 % in 2010.
Most of people choose video rental as their entertainment so that they can earned
more benefit and more famous.
1.3 Project Objectives (Proposed)
The primary objective of this project is to address the common problems, which a
video rental system operate in the rental shop. Our proposed video rental system
are :

To enable the manager to make rapid decision by show chart and graph in the
system
Ensuring all the rental system is in the REAL-TIME performance and always on track
and optimal the utilization of resources.
Use the previous rental system to assist in resource allocation or estimation for
current and future project.
The academic objective are as follows:

To create a movie rental store whose goal it is to exceed customers' expectations.

To develop an alternative to the traditional franchise movie rental store.
To increase the number of clients by 20% per year through superior selection and
customer service.
1.4 Project Goals (Proposed)
Based on the objectives above, our goals targeted to increase the chain of the video
rental shop. Moreover , we decided to promote our video rental system to other
country, such as China , Indonesia , Japan , Korea and Hong Kong. At the future in
2014 , we predict that we can :

Develop a nicer system better than other video rental system.

Most of video rental shop or store are using our video rental system.
The amount of categories of different movies and drama will increase year by year.
Increase 10 % of revenue cost to enhance the video rental shop.
2.0 System Development Methodologies
Prototyping
Prototyping is the process of building a model of a system. In terms of an
information system, prototypes are employed to help system designers build an
information system that intuitive and easy to manipulate for end users. Prototyping
is an iterative process that is part of the analysis phase of the systems development
life cycle.

During the requirements determination portion of the systems analysis phase,

system analysts gather information about the organization's current procedures and
business processes related the proposed information system. In addition, they study
the current information system, if there is one, and conduct user interviews and
collect documentation. This helps the analysts develop an initial set of system
requirements.

Prototyping can augment this process because it converts these basic, yet
sometimes intangible, specifications into a tangible but limited working model of
the desired information system. The user feedback gained from developing a
physical system that the users can touch and see facilitates an evaluative response
that the analyst can employ to modify existing requirements as well as developing
new ones.

Prototyping comes in many forms - from low tech sketches or paper screens from
which users and developers can paste controls and objects, to high tech operational
systems using CASE (computer-aided software engineering) or fourth generation
languages and everywhere in between. Many organizations use multiple prototyping
tools. For example, some will use paper in the initial analysis to facilitate concrete
user feedback and then later develop an operational prototype using fourth
generation languages, such as Visual Basic, during the design stage.

JAD
Joint Application Design (JAD) was developed by Chuck Morris of IBM Raleigh and
Tony Crawford of IBM Toronto in the late 1970's. In 1980 Crawford and Morris taught
JAD in Toronto and Crawford led several workshops to prove the concept. The results
were encouraging and JAD became a well accepted approach in many companies.

In time, JAD developed and gained general approval in the data processing industry.
Crawford defines JAD as an interactive systems design concept involving discussion
groups in a workshop setting. Originally, JAD was designed to bring system
developers and users of varying backgrounds and opinions together in a productive
and creative environment. The meetings were a way of obtaining quality
requirements and specifications. The structured approach provides a good
alternative to traditional serial interviews by system analysts.

A successful JAD session should provide these benefits:

ü Reduced system development time. In JAD, information can be obtained and
validated in a shorter time frame by involving all participants (or at least a
representative set of participants) who have a stake in the outcome of the session.
JAD eliminates process delays and has been shown to reduce application
development time between 20% to 50%.

ü Improved system quality and productivity. Much of the system's quality
depends on the requirements gathered. JAD involves users in the development life
cycle, lets users define their requirements, thus ensures that the system developed
satisfies the actual activities of the business. JAD is quoted the best method for
collecting requirements from the users, customers, or customer advocates.

RAD

RAD, is a team based technique that speed up information systems development

and produces a functioning information system.

RAD is very relying on prototyping and user involvement allow users to examine a
working model as early as possible.

If the user wanted to change, the prototype is modified and the interactive process
will continues to develop until the users are satisfied and fully developed the
system.

RAD - 4 activities:
This Essay is
a Student's Work
Lady Using Tablet
This essay has been submitted by a student. This is not an example of the work
written by our professional essay writers.

EXAMPLES OF OUR WORK

Requirements planning is a combination of system planning and systems analysis
phases of the SDLC. Users, Manager from every department from the company and
IT personnel will gathering together to discuss on the business needs, project
objective, constraints and system requirement.

User Design - User interact with systems analysts and develop models and
prototype that represent all system processes, output and inputs. In this phase, JAD
techniques and CASE tools will be use.

Construction - is more on program and application development tasks similar to the

SDLC. However user will continue to contribute to the system and suggest changes
or improvement as actual screens.

Cutover - Testing, conversion, Changeover to the new system and user training. As a
result, the operation take place in a more smooth environment.

Advantages : Fast and Cost effective.

Disadvantages: Don't not emphasize the company strategic business needs.
( system might work well in short-term, but for long-term objective for the system
might not met)

SSADM
SSADM is a procedural and documentation standards methodology for system
development. This kind of method is systematic approach to the analysis and
design of Information Technology (IT) applications that is commonly used in the UK
(Ashworth, 1993).

The methodology adopts the SDLC phases. The steps in SSADM are similar with
SDLC, but it does not attempt to cover information strategy planning or
construction, testing and implementation of the eventual system (Ashworth, 1993).
In developing a system using this methodology, user - analyst interaction is possible
because according to this method, the system is belong to the user, hence their
participation in the development process is essential.

SSADM consists of 5 main modules:

Feasibility Study
Requirement Analysis
Requirement Specification
Logical System Specification
Physical Design
Advantages of SSADM
SSADM is less complicated to do then SDLC
The chance that the result will satisfy the user is high, since user - analyst
interaction is possible.
SSADM is faster, consume less effort and money compared to SDLC
Disadvantages of SSADM
It does not have good documentation for each step.
For large system, errors and bugs are harder to be found since testing is not
covered in SSADM.

Methodologies Chosen :SSADM

From the project overview above, we conclude that the system will be a small
system that can be applied in a video rental shop. We are going to need a
methodology that can save time and money in developing the system. From the
four different methodologies possible, our group chose SSADM (Structured System
Analysis and Design Methodology) as our methodology.

SSADM methodology is an effective and structured way in developing a system. It is

a fast, well structured methodology that will give satisfaction to its users. Our group
concludes that this methodology is sort of in between of SDLC and RAD. It adopt
some of SDLC phases to ensure good structure and documentation and also
optimize the SDLC phases hence it can be faster and more reliable just as in RAD.

It is a fast methodology that doesn't need lots of resources, time, and money. This
methodology suitable for a small to medium project, that doesn't have long time
and money to produce a reasonably good system. Looking back to the project
overview in the beginning of this chapter, we can see that this EZzy Video requires
a small system that can cope with rental problem. Our group considers that this
system doesn't require high budget and long time period to finish, that is also one of
our reason chose SSDAM as methodology used.

2.1 Problem Description

This project will aim to solve the information-handling problems of EZzy Video , a
video rental service based in state-of-the-art.

EZzy rents videos out to customers who have completed an application form and
become members. EZzy currently has 250 members and a collection of 200 videos.

To do this work and provide these services , information is collected and stored
about videos and members. Information about each video is written down on a card
that is kept inside its case. Information about each member is written down on a
card. These cards are stored in card index box in ascending order of member
number. Information about videos on loan is written down in a loans list each day.

When a customer wants to rent a video they take the empty case from the shelf and
hand it in at the counter. The shop assistant takes the video number from the
details card inside its case and asks the customer for their membership number. If
the member does't know their membership number the assistant looks it up in the

members card index box. The membership number and video number are written
down on the loans list for that day.

The shop assistant asks how many days the customer wants to rent the video for
and writes this on the loans list for the day along with the date that the video will be
due back. The shop assistant puts the videocassette inside the case and hands it to
the customer. When a video is returned the assistant searches through the loans list
for the day it was rented out and crosses out the entry. The videocassette is put
away behind the counter and the empty case is placed back on the shelf.

At the end of every day the loans lists are searched to see if any videos haven't
been returned. Overdue reminder letters are completed by hand and posted to any
members who have overdue videos.

When a new member joins they are asked to fill in two member details cards. The
shop assistant writes the membership number on both cards. One card is given
back to the member - this is their membership card. The other card is put in the
member details card index box.

When a new video is bought, a video details card is completed and put inside the
case. The videocassette is put behind the counter and the empty case is placed on
the shelves. When a member leaves they are asked to hand in their membership
card and it is destroyed along with their card from the member details box. When a
video is sold or thrown away because it is no longer popular or has worn out, the
video details card is taken out of the case and destroyed.

The current system causes the following problems:

Lose Membership cards

Members sometimes lose their membership cards or forget to bring them. When
this happens their details have to be looked up by searching through the members
card index box for the card with their details on it. This can be very time-consuming
and often causes long queues in the shop.

Details cards
The video details cards often go missing from the cases and new ones have to be
written out. The details cards should be added every month for a preparation.

Different members of staff complete the video details cards and loans lists. It is
difficult to read other people's handwriting , which often leads to mistake. Member
details cards are sometimes put in the wrong place in the members card index box
and it takes time to find them when the member's details need to be looked up.

Hard to search problem

If a particular video is not in the right place on the shelves it is difficult to tell if it is
out on loan without searching the shelves and looking through the loans lists. Staff
find it hard to keep up-to-date their knowledge of all the different videos that are
available for rental. This makes it difficult to answer customers when they enquire
about certain titles or types of video.

Reminder system
It take s a long time to look through the loans lists to find out which videos are
overdue and write out reminder letters. Without the reminder system , there are
very difficult to find out the people who was return their rented videos lately or
overtime. Basically, their penalty price is one days RM 1.00, although this amount is
not so large, but it also make shop staff feel scared because they have many past
case that some people are lose their videos after they rented.

2.2 Solution on current system

Eddie Stone could solve their information-handling problems by using a filling
cabinet to store all their information about videos and members instead of using
member and video details cards. The main advantage of this solution is that more
information can be stored in a filing cabinet. The disadvantage of this solution is
that more information can be stored in a filling cabinet. The disadvantage of this
solution is that information would still based on paper records. These could easily be
damaged, misplaced or lost just like the existing member and video details cards. It
would also take just as much time to search through the filling cabinet to find
information as it would to search through member or video details cards.

Another way of solving the problems would be to use a computer to store

information about videos, members and loans. The advantages of this solution are
that computers can store large amounts of data in a small space and search
through it very quickly. That computers can cost a lot of money and some of the
EZzy staff might not know how to use one. Some of them might find this very
frightening and stressful.

There are two ways that a computer could be used. The first is to write a computer
program to solve all of EZzy's information-handling problems. It can also be very
expensive and time-consuming to write a computer program.

3.0 Feasibility Studies I (Current)

Feasibility Study represents a definition of a problem or opportunity to be studied,
an analysis of the current mode of operation, a definition of requirements, an
evaluation of alternatives, and an agreed upon course of action. As such, the
activities for preparing a Feasibility Study are generic in nature and can be applied
to any type of project, be it for systems and software development making an
acquisition, or any other project.

4.1 Technical Feasibility

4.2 Operational Feasibility
4.3 Schedule Feasibility
The schedule feasibility study analyses on whether the project deadline is
completed on time. As the project is initiated by APIIT & UCTI University , the
university had set both the duration and deadline of the project deadline falls on 19
October 2009. Therefore , the project schedule is quite feasible to complete the
entire project development. In addition , Gantt chart will be provided to indicate the
detailed schedule of the project.

Our schedule feasibility consists of:

Workload Matrix
Work Breakdown
Gantt Chart (refer to appendices)
Agreed Work Percentage
4.4 Economic Feasibility
Economic Feasibility is to ensure that the implemented system returns back
estimated amount of benefits within a certain period of time. This involves the
feasibility of the proposed project to generate economic benefits. A benefit-cost
analysis and a breakeven analysis are important aspects of evaluating the economic
feasibility of new industrial projects. The tangible and intangible aspects of a project
should be translated into economic terms to facilitate a consistent basis for
evaluation. (W. Allen)

4.4.1 Cost Classifications

4.4.2 Benefit Classifications
4.5 Payback Analysis
Year Costs Cumulative Cost
Year 0
Year 1
Year 2
Year 3
Year 4
Year 5
Year 6
4.6 Return On Investment Analysis
Lifetime ROI= Total Benefit-Total CostTotal Cost

5.0 Investigation Technique

5. 1 Fact-Findings
5.2 Interview Questions
For this method we have employed various people to go around and interview
people of various race, age and gender background. The purpose of interview is to
identify and understand the tendency to use our services and categories of videos
preferred by interviewee. The questions asked are as below:

1. What information do you store ?

We store information about members , videos and videos that are on loan.

2. How and where do you store information?

Information about members is stored on cards which are kept in a card index box.
Each member has his or her own card. Information about each video is stored on a
card, which is kept inside its case. Information about videos on loan is written down
in a list.

3. What happens when you get new videos?

A new video details card is written out and put inside its case. The information on
these cards is changed if the video details change or it is thrown away or sold.

4. What happens when new members join?

Cards are added when a new member joins. We give the new member two blank
member details cards to complete. We keep one and the other becomes their
membership card.

5. What happens when someone rents a video?

The video cases are stored on the shelves at the back of the shop. There are no
videos in the cases- we keep these behind the counter arranged in order of video
number. Customers look through the shelves to find the videos they want to rent
and take to cases to the counter.

6. How much does it cost to rent a video?

We charge RM 1.00 per day for every DVDs. Members can rent videos for up to one
weeks.

7. What happens when someone returns a video?

When a video is returned the details in the loan list are deleted. If they are late
returned the video rented, we will make little penalty as RM 0.50 per days.

8. How do you deal with overdue videos?

We look through the loans list at the end of every day to see if any videos are
overdue and write out a list of members with overdue videos. The list is used to
prepare reminder letters ,which are posted to the members with overdue videos.

5.3 Questionnaires and surveys

This questionnaire will help us find out what you think about the service currently
offered by EZzy and try to improve it. Your opinions are very important to us. As a
thank you for completing this form we will give you one night's free rental of any
new release.

5.0 Data Flow Diagrams

DFD is a diagram that shows the flow of data from external entities into the system,
showed how the data moved from one process to another, as well as its logical
storage (Ambler, 2006). Data flow diagram is required to illustrate the data
movements and alterations through an information system in a top to down view. Its
objective is to produce a straightforward logical model of an information system
that is easy to understand.

The DFD level 0 diagram describes the whole data flows and movements in the
system. The DFD level 1 diagram gives further explanation of the major processes
that are stated in DFD level 0 and any of these processes can then be analyzed
further in the next level. Our requirement of this project is only to illustrate the
system until DFD level 1. In that case, any of our major processes are only
expanded into DFD level 1.

10.0 References
ref : http://www.scribd.com/doc/7298188/PIECES-Framework
http://www.ucertify.com/article/what-is-the-pieces-framework.html

Data Flow Diagram with Examples - Video Rental System Example

February 16, 2015Views: 21,530PDFLinkCompatible edition(s): Professional,
Standard, Modeler
Data Flow Diagram (DFD) provides a visual representation of the flow of information
(i.e. data) within a system. By drawing a Data Flow Diagram, you can tell the
information provided by and delivered to someone who takes part in system
processes, the information needed in order to complete the processes and the
information needed to be stored and accessed. Data Flow Diagram has a wide use
in software engineering. This article describes and explain Data Flow Diagram (DFD)
by using a video rental system as an example.

The Video Rental System Example

Context DFD
The figure below shows a context Data Flow Diagram that is drawn for a video rental
system. It contains a process (shape) that represents the system to model, in this
case, the "Video Rental Store". It also shows the participants who will interact with
the system, called the external entities. In this example, there are two external
entities, namely Customer and Manager. In between the process and the external
entities, there are data flow connectors indicating the existence of information
exchange between customer and the system.

Context DFD is the entrance of a data flow model. It contains one and only one
process and does not show any data store, which makes the diagram simple.
Level 1 DFD
The figure below shows the level 1 DFD, which is the decomposition (i.e. break
down) of the video rental system that is shown in the context DFD. Read through
the diagram and then we will introduce some of the key concepts based on this
diagram.

The Video Rental System Data Flow Diagram example contains three processes, two
external entities and two data stores. Although there is no design guideline that
governs the positioning of shapes in a Data Flow Diagram, we tend to put the
processes in the middle and data stores and external entities on the sides to make it
easier to comprehend.
Based on the diagram, we know that a Customer makes a Video request to the Rent
Video process. The Rent Video process also receivesVideo info. from the Video
Library data store. As a result, the process produces a Bill to the Customer, and
stores the Rental info. into theRental data store.
A Customer can Return Video by providing Video & Rental info. The process stores
the Video info. into the Video Library data store and Rental info. into the Rental data
store. As a result, Return receipt is delivered to the Customer. Although we said that
the receipt is delivered as a result of the Return Video process, the Data Flow
Diagram implies no such thing. It is our common sense that lead us to interpret the
diagram in the way that we understand it naturally. Strictly speaking, the diagram
only tells us the Return Video process receives Video & Rental info.and
produces Video info., Rental info., and Return receipt, with no order specified. Note
that Data Flow Diagram does not answer in what way and in what order the
information is being used throughout a system. If this information is important and
worth mentioning, consider to model it with diagrams like BPMN Business Process
Diagram or UML Activity Diagram.
Finally, a Manager can receive Rental report from the Generate Rental
Report process and the information involved is provided by the Rentaldata store.

Data Flow Diagram Tips and Cautions

Be aware of the level of details
In this Data Flow Diagram example, the word "info" is used many times when
labeling data. We have "rental info" and "video info". What if we write them
explicitly as "rental date, video rented, person rent", "video id, video name and
video status"? Is this correct? Well, there is no definite answer to this question but
try to ask yourself a question when making a decision. Why are you drawing a DFD?
In most cases, Data Flow Diagram is drawn in the early phase of system
development, where many details are yet to be confirmed. The use of general
terminologies like "details", "information", "credential" certainly leave room for
discussion. However, using general terms can be kind of lacking details and make
the design lost it usefulness. So it really depends on the purpose of your design.
Don't mix up data flow and process flow
Some designers may feel uncomfortable when seeing a connector connecting from
a data store to a process, without seeing the step of data request being shown on
the diagram somehow. Some of them will try to represent a request by adding a
connector between a process and a data store, labeling it "a request" or "request for
something", which is wrong.
Keep in mind that Data Flow Diagram was designed for representing the exchange
of information. Connectors in a Data Flow Diagram are for representing data, not for
representing process flow, step or anything else. When we label a data flow that
ends at a data store "a request", this literally means we are passing a request as
data into a data store. Although this may be the case in implementation level as
some of the DBMS do support the use of functions, which intake some values as
parameters and return a result, in Data Flow Diagram, we tend to treat data store as
a sole data holder that does not possess any processing capability. If you want to
model the system flow or process flow, use UML Activity Diagram or BPMN Business
Process Diagram instead. If you want to model the internal structure of data store,
use Entity Relationship Diagram.

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

Automate check in and check out of rental items, handle logging and
reporting of rental transactions

Provide real-time financial information.

Provide flexibility in quickly implementing pricing plans and promotions.

Support company growth to multiple stores.

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

123 Maple

New York Stories

Total

11

Any Town, NY
10234
Member History Report
Name

Join Date

Total Rentals Total Sales

Fines Paid

Fines
Outstanding

Smith, J

3/4/92

123

10

Rules and Algorithms

Rentals will only be made to people who are signed up as members

People will only be accepted as members who have provided adequate

identity and credit information.

Rentals will be denied to anyone with an outstanding balance of $20 or more.

Only a manager may change pricing or member policy

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 owners 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.