Case Study
Best-Book-Buy Online Bookstore
Requirements Specification Document
(By Henrique Paques, Leo Mark and Shamkant B. Navathe)
1. Introduction
The purpose of this case study is to present a data-intensive application for which a database can
be designed. It is described with sufficient degree of detail so that the application can be
implemented in languages like Java or C using ODBC or JDBC connectivity to the relational
database. This case study is an illustration of the typical project we have been using to teach an
undergraduate class in database design that covers essentially the first 16 chapters of the textbook
at Georgia Tech.
The user interface is defined in screen format – these screens can be implemented using
Visual Basic or Java as needed, or a simpler version of the interface using simple text menus may
be implemented. There are a few reports included in the application specification. They are for
illustrative purposes and may be modified as well. The methodology to be followed uses
conceptual design in the Entity Relationship Model (Chapter 3), followed by a mapping of the ER
schema into the relational schema (Chapter 7). The application is broken into a number of tasks
and the inputs and outputs are related to the tasks by means of an Information Flow Diagram.
Students should use Chapter 12 to understand the overall process of database design used for
design of large databases. A design methodology is developed during the discussion of this case
study and related to the UML diagrammatic notations developed in Chapter 12. Developing a
complete and strictly UML-based methodology for data and application design is outside our
scope. SQL programming (Chapter 8) and database access from application programs (Chapter 9)
is illustrated with examples for implementing the tasks.
Best-Book-Buy (3-B) is an information management system that supports some of the
services involved in an online bookstore, such as Amazon.com. The information system that we
describe here is a simplified version of a full-fledged online bookstore system. The reader may
consider this document as an initial specification provided by the end-users and requirement
analysts on what the application should look like. In other words, this document can be
considered as the initial requirement specification document.
When the customer accesses 3-B.com, the first page that she1 sees is depicted below.
1
We will use she to refer to the customer with no intended bias.
1
Figure 1: Welcome screen.
The rest of this document is organized as follows. We describe the operations and screens that a
user will go through when one of the above options are selected. Then, we discuss some general
aspects relevant to the system as a whole.
2. Search Only
Let’s say that the user only wants to search the bookstore for a specific book. She clicks “Search
Only” and the screen in Figure 2 pops up. Internally, the system will create a temporary shopping
cart for this new user. Briefly, a shopping cart is just a temporary structure in main memory that
will hold the books that the user may decide to purchase while browsing 3-B.com. The shopping
cart is an important component of the system, and we defer more detailed discussion on this
component to later in this document after presenting the main functionalities of the system.
Figure 2: Search screen.
The user enters some keywords in the “Search For” field, determines where these keywords
should be examined (e.g., on the title of a book), and within which category. By default, the
system assumes that the user wants to search using “Keyword anywhere” over all categories. The
search is executed by clicking the “Search” button. When the system finishes executing the
search, the screen depicted in Figure 3 pops up. The option “Manage Shopping Cart” is addressed
next.
2
Initially, the “Search” button is deactivated, and it will only be activated when the user enters
some keywords in the “Search For” field. The search is conducted by checking whether the
keywords provided appear at the beginning of the field(s) indicated in “Search In.” For this
system, we do consider the case where the keywords can appear in any position in the
field. Otherwise, an index at the word level would be required, and the cost of
maintaining such index as well as navigating it could become prohibitive, degrading
significantly the performance of the system.
From the Search screen, the user may also decide to switch to her shopping cart or exit 3-B.com.
If she decides to leave the system, her shopping cart is discarded and the Welcome screen
(Figure 1) is displayed. We discuss later in the text the “Manage Shopping Cart” task.
Let us consider that the user is searching for books with the word “SQL” in the title. One possible
result for this search is depicted in the Search Result screen shown in Figure 3. Books that are not
in stock or that were deleted (see Section 5.1.2) cannot be shown in the search result.
Figure 3: Search Result screen.
In the Search Result screen, the user can perform the following activities:



Add to Cart one or more books listed. By clicking on the “Add to Cart” button next to a book,
the system inserts this book into the user’s shopping cart, disables the respective “Add to
Cart” button, and updates the total number of items in the cart. If the user later decides that
she does not want this book in her shopping, she can remove it by clicking on “Manage
Shopping Cart” button.
Review one or more books listed. By clicking on the “Review” button next to a book, the
system brings up the Book Review screen (Figure 4), which displays a scrollable window that
lists all the reviews for the selected book. By clicking the “Done” button on Book Review
screen, the system brings back the Search Result screen (Figure 3).
Manage Shopping Cart, which allows the user to view the list of books in her shopping cart
and modify this list accordingly. The interface for this option is depicted in Figure 5.
3

Proceed to checkout, which allows the user to place an order for the books in her shopping
cart and make the payment. If she is a new user, then she needs to first register into the
system. For that, the system will pop the screen from Figure 6. Otherwise, the screen from
Figure 8 is displayed. We will describe the checkout process shortly.
If the user requests a New Search, the system will bring back the Search screen.
Figure 4: Book Reviews screen.
Let say that the user has selected both books listed in Figure 3, and she wants to manage her
shopping cart. Upon clicking the “Manage Shopping Cart” button, the screen in Figure 5 will pop
up.
Figure 5: Manage Shopping Cart screen.
From the Manage Shopping Cart screen, the user can remove one of the books from her cart
and/or change the quantity of the selected books. The user can remove a book by clicking on the
4
“Delete Item” button next to the book. The system then deletes the book, updates the cart
accordingly, and recalculates the subtotal.
The quantity of a book can be updated by directly clicking on the “Qty” field, and entering the
new quantity. Then, the user must click on “Recalculate Payment” button so that the system can
update the cart accordingly. However, before the update of the new book quantities can take
place, the system first checks whether there are enough books in stock for matching the new
requests. If sufficient books are not available, the system will notify the user by displaying an
alert message.
If the user clicks on “Checkout”, the following sequence of windows will appear:
Figure 6: Customer Registration screen
Because the customer was not registered, she needs to do it now in order to proceed with the
purchase. When registering with 3-B.com, the customer needs to provide a username and a
password (or PIN) along with other information addition information (see Figure 6). If the
provided username already exists in the database, the system will ask the customer to provide an
alternative username. The customer data will be indexed according to their usernames. The
password can be anything that the customer provides. The customer’s username and password
will be required on subsequent access to the 3-B.com.
If the customer decides not to register, she will not be able to proceed with the payment and the
screen in Figure 6 will pop up. By clicking “OK” in this screen the system will bring up the
Search screen (Figure 2). The system will not clear the shopping cart.
5
Figure 7: Message informing the user why she needs to register to the system.
After successfully registering to the system, the user will see the following payment screen:
Figure 8: Confirm Order screen
If the user provides a new credit card number, this number will be stored in the database. By
clicking on the “Cancel” button, the system will return to the Search screen (Figure 2), but the
shopping cart will not be cleared. If this is the first time that the customer is making a purchase at
3-B.com, she may not have a credit card on file and will be asked to provide one. For this case
study, assume that payments can only be made using credit card and the system will store only
one credit card information for each registered user. Furthermore, we assume that all deliveries
will always take five business days and the cost of shipping and handling will be $2.00 per book.
(We will not worry about sales tax.)
If the user needs to update some of her information (e.g., provide a different address), she can do
it by clicking on the “Update Customer Profile” button, which will bring the screen shown in
Figure 9. The customer can only file one credit card.
6
Figure 9: Update Customer Profile screen
The only information that the customer cannot update from her profile is the username because
we are going to use this field to index the customer information in the database. When opening
this screen, the system must display all the information that is available on file for this customer.
The update will take place only if the customer clicks the “Update” button. If the customer clicks
on “Cancel”, no update is made to her profile. Once the user is done with the update, the system
will return to the Confirm Order screen (Figure 8).
Once the user has provided all the necessary information in screen Confirm Order and clicked the
“BUY IT!” button, the transaction ends and the system will update the inventory accordingly,
generate the needed book orders to be placed by the administrator (see “Behind the Scenes”
Section for further discussion on placing orders), clear the shopping cart content, and display the
Proof of Purchase screen depicted in Figure 10.
Observe that in the Proof of Purchase screen, we indicate which user has purchased which book
at what time. The time must be specified at the second level because we want to be able to ensure
that a given user can make only one purchase at a time. The user may print the Proof of Purchase
screen as a receipt for her files.
When printing the Proof of Purchase screen, the system must be able to correctly print out all
purchased books, even though they are not shown in the screen. In the screen, the user can see all
books that she purchased by scrolling down the window with the books.
We should observe that in a real system, when the customer clicks “BUY IT” on Confirm
Purchase screen, the system should first contact the respective credit card company to authorize
the customer’s payment. After receiving the authorization, the system would then confirm the
purchase and proceed with the inventory updates and shipping process. However, for simplicity
we do not elaborate these processes further.
7
Figure 10: Proof of Purchase screen.
3. Register New Customer
Let’s say that the customer wants to register with 3-B.com. The main reason for registering with
our system is to allow us to provide a more personalized environment for the user whenever she
comes back. Although there are number of possible ways of personalization, for this case study
we will use only a simple one: every time a returning customer logs in, the system will provide a
list of books from the years 2002 and 2003 that are on the same category of books that the
customer purchased in the last transaction (if any). If in her last purchase the customer bought
books from different categories, choose one of the categories (randomly, or applying some
meaningful rationale such as the category that was most common among all books), and construct
the list.
The screen for registering a new customer is presented in Figure 6. Once the registration is
completed, the system brings the customer back to the Search screen (Figure 2).
4. Returning Customer
If the customer has already registered with our system, she can enter it by selecting “Returning
Customer” from the Welcome screen (Figure 1). After clicking the “Submit” button in this
screen, the system will pop up the User Login screen as shown in Figure 11. Once the customer
logs in, the system will then fetch her profile, and based on that, will present a list of suggested
books as shown in Figure 12. (See “Register New Customer” on how to construct this list.)
8
Figure 11: User Login screen.
Figure 12: List of Suggested Books screen.
The customer may add some of the books to her shopping cart, or simply click the “New Search”
button, which will lead to the Search screen (Figure 2). Note that the screen in Figure 12 is the
same as the Search Result screen (Figure 3).
5. Administrator
The administrator will be responsible for maintaining the system inventory up to date. In order to
log in to the system, the administrator needs to first select the “Administrator” option in the
Welcome screen (Figure 1), click Submit, and enter her username and PIN as depicted in Figure
11.
Once the administrator logs in to the system, the following page pops up (Figure 13):
9
Figure 13: Administrator Tasks screen.
5.1 Manage Bookstore Catalog
When a book becomes out of print or a typo on a book title is identified, or when the publishers
announce new titles, the administrator needs to update the catalog accordingly. By clicking on
“Manage Bookstore Catalog” button in the screen of Figure 13, the system brings up the screen
shown in Figure 14.
Figure 14: Manage Bookstore Catalog screen.
5.1.2 Inserting a New Book
The screen associated with the insertion of a new book title is depicted in Figure 14. The book
may have more than one author. The administrator can add more authors by clicking the “More”
button on the right side of the Author(s) field. For deleting an author from the list, the
administrator selects the author to be removed and then clicks the “Fewer” button. Similar
procedure applies for the insertion of book reviews.
10
Figure 15: Book Insertion screen.
Before inserting a new book in the database, the system checks if the ISBN2 does not exist. If
there is already a book with the same ISBN, the system will display an error message requesting
the administrator to enter a different ISBN. The books will be primarily indexed by the ISBN.
Once the ISBN is checked to be a valid, the book is inserted, and an order for the book is
generated. This order will appear in the list of orders that the administrator needs to place (see
Section 5.2).
After the insertion is successfully completed, the system returns to the Manage Bookstore Catalog
screen (Figure 14).
5.1.2 Modifying/Deleting an Existing Book
In order to modify/delete one or more books, the administrator selects the books by using the
search screen shown in Figure 16.
2
ISBN is the unique number assigned to every book by the Library of Congress. It is used in this system to
uniquely identify books.
11
Figure 16: Search screen for modifying/deleting one or more books.
Figure 17: Result screen with the books to be modified or deleted from the catalog.
By clicking “Delete” for one of the listed books from the search result screen (Figure 17), the
system will only flag that the book was deleted, and will not actually remove the book from the
catalog. The reason for that is because the book that is being deleted maybe be related to sales
done previously. Considering that we want to generate reports about sales that occurred in the last
months (see Section 5.5), if we remove this book from the database, we are going to be deleting
important data on sales information.
If a book is flagged as deleted, the administrator can undelete it using the update screen (see
Figure 18). In addition, if a book is deleted, the “Delete” button associated with this book will be
disabled. An example of this situation is the second book listed in Figure 17.
When a book is undeleted, the system generates an order for this book. We assume that when a
book is deleted, its quantity in stock is zeroed. In addition, the pending order for this book (if any)
is also removed from the system.
By clicking “Update” for one of the listed books from the search result screen, the system will
pop up the Update Book screen shown in Figure 18. Once the administrator completes the update
(or decides to cancel it), the system will display again the screen in Figure 17.
12
Figure 18:Update Book screen.
In the Update Book screen, if the administrator changes the minimum quantity in stock to a value
that is larger than the current quantity in stock, then the system will display an alert to the
administrator indicating that this change will generate a book order. If the administrator agrees
with the change, the book update is processed and the associated order is generated.
If the administrator changes the minimum quantity below the quantity current in stock, the system
will remove the pending order for this book, if any.
Using the Update Book screen, the administrator can also re-activate a book that has been
previously deleted by clicking the “Re-Activate” button. If the book is still active, this button will
be disabled. By clicking on the “Re-Activate” button, the system will remove the delete flag from
the respective book, and update the screen of Figure 18, this time indicating that the book is now
active, and disabling the “Re-Activate” button.
5.2 Place Orders
Book orders are automatically generated by the system (see Section 7) and it is the responsibility
of the administrator to manage the generated orders. In order to determine whether there is a
demand for placing new book orders, the administrator has to click on “Place Orders” button
from Figure 13. If there are no outstanding book orders to be placed at this time, the system will
display screen shown in Figure 19. If the administrator clicks “OK” on the screen in Figure 19,
the system will pop up again the screen in Figure 13.
13
Figure 19: Status Message screen.
If there are books to order, the following screen will pop up:
Figure 20: Place Order screen.
Placing orders will be an iterative process. For each book title that needs to be ordered, the screen
in Figure 20 will pop up displaying the ISBN, title, and authors of the respective book, and the
administrator will enter the quantity to be ordered. This quantity plus the quantity in stock needs
to be greater or equal to the minimum required in stock. When all orders were placed, the
Administrator clicks on “Submit Order” button. The system will then fire at most N orders, all of
which must be successfully completed. The “Submit Order” button will be enabled when at least
one order has been placed.
The system will fire less than N orders if the administrator decides to skip some of the orders
suggested by the system. For example, the company may decide to discontinue the availability of
a book title after all books in stock were sold. We do not consider the scenario where the
administrator can directly remove an order from the system. However, a pending order will be
removed when the administrator deletes the book from the catalog, or when she changes the
minimum quantity below the quantity that is currently in stock.
Before updating the inventory with the new book orders, the system needs to certify that the
administrator has placed orders of appropriate size that meet the minimum requirement of each
ordered book. If this is not satisfied, an error message will be displayed requiring the
administrator to revise the orders, and the screen from Figure 20 will pop up again.
In a real situation, once the administrator clicks the “Submit Order” button in Figure 20, the
system would send the request to the respective suppliers and only update the actual quantity of
the requested books when the order arrives. However, in this case study we assume that when the
administrator clicks the “Submit Order” button, the order is instantaneously received and the
14
inventory will be automatically updated to reflect the receipt of actual quantities of books
accordingly.
After successfully placing the orders, the system will then pop up the screen in Figure 13.
5.3 Update Admin Profile
The Update Admin Profile option (see Figure 21) allows the administrator to update her current
information. Observe that each administrator has a date of hire. Throughout its lifetime, 3-B.com
will have more than one administrator and we need to keep a record of the administrator that we
hire. While hired, the administrator will place a number of book orders, and for auditing purposes
we need to know who was responsible for each order placed. Consequently, we never delete an
administrator record from the database and each administrator is identified by the username
‘admin’ plus the date of hire. At any given moment, the system will only have one administrator.
Figure 21: Update Administrator Profile screen.
5.4 System Maintenance
The System Maintenance option allows the administrator to update the book categories, insert (or
remove) states in the US that 3-B.com will start (or stop) servicing, and update the list of credit
card types (see Figure 22).
When removing a category, state, or credit card type, the system will check whether information
being removed is not related to any other data in database. For example, we cannot remove a
category if we have one or more books associated with this category. Otherwise, the database will
become inconsistent.
15
Figure 22: System Maintenance screen.
Once the administrator has completed the necessary updates, she clicks the “Done” button, and
the system shows the screen in Figure 13.
5.5 Reports
Let us assume that the system stores book sales and other related data for the last 12 months.
(Archiving of old sales and order data is beyond the scope of the case study.) In order to have an
idea of how the company is doing in terms of sales, the administrator can request the reports
listed in Report Menu screen (Figure 23).
16
Figure 23: Report Menu screen.
The system only prints one report at a time. Once the administrator selects one report, the system
will first display a preview of the report in a screen. This gives the administrator a chance to
decide whether or not the report is worth printing. By clicking “Print” button in the preview
screen, a printed version of the report is generated.
In the next subsections, we present a possible layout for the preview screen of each report listed
in Figure 23. We do not present the actual “printer” layout of each report.
5.5.1 Report on Previous Month Sales
This report lists the total sales from the previous month for each category. Previous month is
defined as the period between the first and last day of that month. For example, if we are in July,
this report will consider the sales at 3-B.com from June 1st to June 30th. In the next subsections,
whenever we refer to the previous month, we consider the definition for previous month
presented here.
17
Figure 24: Preview screen for report on previous month sales.
Figure 24 shows the preview screen for this report. A variation of this report would be to allow
the administrator to specify for which month the system should generate the report (assuming that
data is available for the past twelve months). In this case study we do not consider this possibility.
5.5.2 Report on Number of Books in Stock
This report lists the total number of books currently in stock for each category. Figure 25 shows
the preview of this report. The date in the screen refers to the day in which the report was
generated.
Figure 25: Preview screen for report on number of books in stock for each category.
5.5.3 Report on Best Sellers
This report lists the top ten best sellers, in descending order of sales, for the last three months.
Figure 26 depicts the preview screen for this report. Two important comments on this screen:
First, the rank is system generated. Second, the letters under the Total Sales column are not meant
to be a mask. These are just used for illustration purposes. Similar observation applies to the
name of category: just illustration.
18
Figure 26: Preview screen for report on the top 10 best sellers in the last three month.
Similar to the report described in Section 5.5.1, we could also have the administrator entering the
month for which the report on best sellers should be generated.
5.5.4 Report on Most Expensive Books
This report lists the most expensive books for each category, in descending order, in the previous
month. In addition, for the book in each category, the report shows the total in sales for the period
considered. Figure 27 depicts the preview screen of the report.
Figure 27: Preview screen for report on the most expensive book of each category sold in the
previous month.
This report is useful when determining how expressive are the sales of expensive books. If the
sales are not interesting, the company may decide to discontinue the availability of one or more
expensive books.
19
The content of the report in Figure 27 is used for illustration purposes.
5.5.5 Report on Number of Distinct Buyers
This report lists the total number of distinct buyers (as identified by their username) for each
book category in the previous month. Figure 28 shows the preview screen for the report.
Figure 28: Preview screen for the report on the number of distinct buyers for each book category
in the previous month.
This report is useful for having an overall picture of the customer habits. If a large number of
customers prefer books of a category X, then it would be interesting for 3-B.com to invest more
on different book titles for this category. This way, not only the profits could increase, but also
new customers could potentially start buying from 3-B.com.
5.5.6 Statistical Report
The last report that the administrator can request provides the following statistical information
about the system: (1) Average amount of sales per customer, in the previous month; (2) Average
number of books per transaction, also in the previous month; and (3) Average number of
customers per day. The preview screen for this report is a simple one, and we do not present it
here.
From the description of this last report, as well as all other reports previously discussed, it is clear
that it is very important that the system maintain daily sales and book order transactions. In this
information is very important for assessing the business performance of 3-B.com and for making
strategic decisions for improving the company.
6. Example of screen sequences in the system
In this section, we give an example of one possible screen sequence in the system for each
customer type. In the examples, we only describe the situation where the customer ends up
buying books. However, each customer could execute many searches, update her profile a
number of times, cancel the purchasing transaction more than once, etc. The sequence of screens
20
for the administrator should be straightforward from the discussion presented under the
“Administrator” Section.
Example 1: Browsing Customer
Start by selecting “Search Only” and clicking “Enter” on the Welcome screen (Figure 1) →
Search Books (Figure 2) → Search Result (Figure 3) → Manage Shopping Cart (Figure 5) →
Customer Registration (Figure 6) → Confirm Order (Figure 8) → Proof of Purchase (Figure 10).
Example 2: New Customer
Start by selecting “New Customer” and clicking “Enter” on the Welcome screen (Figure 1) →
Customer Registration (Figure 6) → Search Books (Figure 2) → Search Result (Figure 3) →
Manage Shopping Cart (Figure 5) → Confirm Order (Figure 8) → Proof of Purchase (Figure 10).
Example 3: Returning Customer
Start by selecting “Returning Customer” and clicking “Enter” on the Welcome screen (Figure 1)
→ User Login (Figure 11) → List of Suggested Books (Figure 12) → Search Books (Figure 2) →
Search Result (Figure 3) → Manage Shopping Cart (Figure 5) → Confirm Order (Figure 8) →
Proof of Purchase (Figure 10).
7. Behind the Scenes
In order for the system to work smoothly, we are going to need the following tasks to be
performed behind the scenes by the system:





Shopping cart
Customer profile
Monitoring the stock level
Sales statistics collection
Administrator account
7.1 Shopping Cart
Whenever a new or existing customer logs in, the system creates a new shopping cart for the
customer. Each time customer selects a book to buy, it places in shopping cart. Repeated searches
do not affect contents of shopping cart. After user completes a buy transaction, inventory is
modified according to the shopping cart contents and the shopping cart is cleared.
7.2 Customer Profile
For each registered customer, the system will maintain a profile with the following information:
name, address, credit card information (if any), a list of book categories from the user last
purchase (if any). Whenever a registered customer comes in, the system will use one of the
categories from the customer’s list of categories (if any) to provide a list of recent books (year
2002 and 2003) on the same category.
21
A registered customer is never deleted. We need this information to capture the purchases of
books information completely in the system. In addition, we may want to maintain the
information of the customers for future promotion used to attract registered customers that have
not visited 3-B.com for a long time.
7.3 Monitoring the Stock Level
After successfully completing each purchase transaction, the system needs to update the stock
level of the bookstore accordingly. When the quantity of a book drops below a given threshold
(the minimum quantity in stock), a message is generated and sent to the administrator to place an
order for this book. Minimum quantity in stock is a threshold that determines when an order for
the book needs to be placed. Entering this threshold for each book is the administrator
responsibility.
7.4 Sales Statistics Collection
In order to be able to generate some of the administrator reports, the system will have to collect
information on the book sales. This information will mainly consist of: date of the purchase,
books that were purchased by each customer, total sale, and username (for distinct customers).
7.5 Administrator account
The administrator account will be created by the DBA for each newly hired administrator. The
administrator cannot use his account for purchasing books in 3-B.com.
7.6 General assumptions about the system
We list below a few possible simplification assumptions that one could use for designing and
developing the initial prototype of 3-B.com.

There will only be one user (customer or administrator) at a time using the system. This
should facilitate the implementation as we don’t need to consider concurrency issues, or
maintaining multiple customer sessions (shopping carts) opened at the same time.

When the customer is new and has chosen not to register to the system (Search Only), we
still need to create a temporary username for this unknown customer because we need to
create a shopping cart for him. When she finally registers in the system, we then update
the temporary username with the correct one.

Every book is listed once in the catalog (no multiple editions for different years)

A customer can file only one credit card in the system. She may update it, but she can
only have one current credit card active.
8. Statistics
The statistics listed below are important while designing the access structures for the underlying
database. However, we should note that these statistics are not intended to characterize any
specific real-system currently available in the industry. These statistics are used for illustration
purposes.
22
Number of registered customers: 25,000,000
Number of books in the database: 1,000,000
Number of new books published per year: 10,000
Number of sessions per day: 500,000
 70% of the sessions are from registered customers
 1% of the sessions are from new registered customers
 29% of the sessions are for “search-only” visitors (i.e., they never register as a
new customer).
Number of inquires to the database per day: 1,000,000 (Note: This number includes not
only the inquires made by the customers, but also the inquiries made by the
administrator.)
Number of purchases per day: 50,000
Average number of books bought per session: 2
Average number of book orders that the system generates per day: 10 (Note: these book
orders refer to the orders that the administrator has to submit to the book suppliers.)
9. Possible Modifications to the System
In the above requirements specification document we proposed a functionality for the 3-B.com
bookstore’s information system that is fairly realistic and closely mimics what an actual system
would do. However, to make the overall task of implementing this application in one semester
reasonable for a group of three or four students, we have simplified or reduced the functionality
in different ways. Instructors can redefine the requirement specification document by
incorporating the following features:
 inventory processing – actual inventory of books is maintained for a warehouse; there is
an explicit transaction to handle books received in the warehouse; there are backorders
generated when a certain book is out of stock at the publisher, or out of print etc.
 cost analysis – all types of costs could be incorporated: costs for received books against
the order, employee payroll and administrative costs, inventory carrying cost etc. An
analysis of profitability can be done.
 more reports: a variety of reports can be added related to slow moving books, books that
did not sell more than x percent of inventory in n months, most profitable books, books
that are being reordered too often etc.
23
24