Donald Bren School of Information and Computer Sciences



Requirements Document for Groceries@Home

Introduction

For the past 15 years, the Grocery Home Delivery Service. (GHDS) has been serving the elderly, disabled, and other citizens of Orange County who are unable to travel to the market themselves by bringing groceries to their homes. Until now, GHDS has operated solely through telephone and fax machine, both for placing the orders and for coordinating their pickup and delivery. GHDS now wishes to expand and automate their service through Groceries@Home, a desktop application that allows customers to place their orders, and facilitates the fulfilling of these orders by the system administrators. As a welcome side effect, GHDS hopes this new system will also expand their customer base to include anyone who has a computer and an Internet connection, not just shut-ins.

Because GHDS is a small company, it does not have its own team of software engineers. Consequently, it has hired Scootie Software Inc. to develop this requirements specification for the Groceries@Home system, as well as its subsequent design and implementation. The information in this requirements specification is based on interviews conducted with the relevant parties at GHDS, by the requirements engineers at Scootie Software Inc. All information in this document was determined to be accurate at the time of this writing.

This document contains the detailed requirements specification for the Groceries@Home system that Scootie Software Inc. is developing for GHDS. The document should serve as the official basis for any further development of Groceries@Home.

This document contains the following sections:

• Executive Summary

• Application Context

• Functional Requirements

• Environmental Requirements

• Software Qualities

• Other Requirements

• Time Schedule

• Potential Risks

• Future Changes

• Glossary

• References

Executive Summary

GHDS is seeking to take advantage of the ubiquity of the Internet and popularity of online shopping by automating its ordering process through Groceries@Home. Groceries@Home allows customers to browse and search for groceries, place orders, and track orders, all via their own PC, in the comfort of their own home. By having this system in place, fewer employees will be needed at GHDS to coordinate the ordering placement and fulfillment process – the bulk of the work will be performed by the system. In addition, the process will be done in a fraction of the time – no longer will a GHDS employee have to answer the telephone, place customers on hold during busy times, take their orders, and manually type them into a system. GHDS anticipates that the overall effect of Groceries@Home will be a larger customer base, a more rapid and streamlined ordering, pickup, and delivery process, and, most importantly, a resulting growth in company revenue.

Groceries@Home provides the following key features:

• Automated shopping and ordering process: Customers can search and browse groceries, place orders, and track orders completely through the Groceries@Home system.

• Easy coordination and tracking of deliveries and drivers: Because drivers will enter their up-to-date order and delivery status each time they return to the GHDS warehouse, the system will accurately reflect this information for customers who wish to track their orders, and for administrators who wish to use this information to make informed decisions about driver assignments.

• Automated report generation: Groceries@Home will provide interested parties at GHDS with accurate, useful, and customizable reports in a rapid manner.

Three of the most important risks posed by the development of Groceries@Home are the following:

• Security – Because customers will be entering private information into the Groceries@Home system (credit card number, address, etc.), it is imperative that the system is secure and not vulnerable to any illegal access.

• Usability – Groceries@Home must be extremely intuitive and easy to use, due to the fact that many of its users are not likely to be very computer literate.

• Rapid development – The schedule according to which Groceries@Home will be developed is extremely aggressive to ensure that another company will not develop a similar product first and claim the market. Other qualities cannot be sacrificed as a result of this rapid development.

Although the contents of this document were thoroughly verified, it may still occur that some requirements are inconclusive or ambiguous. If it is so determined, it is requested that Scootie Software Inc. be contacted via e-mail at emilyo@ics.uci.edu to resolve the issue.

Application Context

Users of the Groceries@Home system fall into three different categories: customers, administrators, and drivers. Customers are able to browse and search grocery items, place orders, and track order status. Administrators can add edit, and delete users, drivers, shipping fees, and stock items, assign orders to drivers, and generate reports about all orders placed. Drivers can enter information about their deliveries and view their upcoming assignments.

Deployment of the Groceries@Home system will result in substantial changes for customers, GHDS telephone operators, and GHDS drivers: Although GHDS will still accept phone orders, customers might find it faster and easier to instead use Groceries@Home. (Note, however, that telephone orders will also be faster than before, since the operators will be using the system themselves.) Fewer GHDS employees will be needed to answer telephones, and may either be retained as telephone operators but trained to use Groceries@Home to place the orders, or retrained as GHDS system administrators. GHDS drivers will need to be trained to use the system to enter information about their deliveries, such as which orders they have delivered or are about to deliver, so that the system will be able to reflect accurate information about order and driver status.

Functional Requirements

1 CUSTOMER FUNCTIONALITY

1 Login

2 Existing customers can log in with their username and password. New customers can choose an option for “new customer.”

3 New customers are prompted for their preferred login name, password, first and last name, email address, phone number, second phone number (optional), billing address, shipping address, phone number, mother’s maiden name, and credit card type, number, and expiration date (optional).

4 If the customer’s shipping address is the same as the billing address, they can say so and won’t have to enter the address twice.

1. If the customer’s shipping address is not in Orange County, CA, they should be notified that GHDS doesn’t deliver to locations outside of Orange County, and will not be able to go any further unless the shipping address is changed to somewhere in Orange County.

5 Login names must be unique.

2. There should be an option for a customer who has forgotten his/her password, in which they can enter their mother’s maiden name and the password will be emailed to them.

3. There should be an option to change any of their information, except for their username and password.

6 Viewing grocery items

4. For each item, the system should display the following information:

7 Name: The name of the item, e.g., “toilet paper”, “cheddar cheese”, or “Honey Bunches of Oats.”

1. UPC/ID Number: A unique, 10-character alphanumeric string that identifies this item.

8 Brand: The manufacturer of the item, e.g., “Charmin”, “Kraft”, or “General Mills.”

9 Picture: A picture of the item.

10 Price: How much one of these items is being sold for.

11 Sale items should instead show the previous price with a slash through it, and the new price in red.

12 Description: A brief description of the item, e.g., “Healthy wheat flakes and crunchy oat clusters packed with loads of toasty golden brown almonds.”

13 Price per lesser unit: A breakdown of how much the item is per ounce, fluid ounce, 100-count, pound, or whatever measurement is applicable.

14 Rating: 1 to 5 stars based on average of ratings given it by other customers, with an option to view the raters’ comments. If no ratings have been made, this part is omitted.

15 If it’s out of stock, make that known and give the customer the option of getting notified via email when the item becomes available. (The email will be generated as soon as the item(s) is entered into the system)

16 If less than 5 of the items are available, make it known to the customer: “limited quantity available.”

17 Requesting similar items

5. For each item viewed, the customer can ask the system to show them similar items, and the system will show them other items with the same item name. If there are no other items with the same item name, they will be given other items that are in the same aisle subcategory.

6. The user can sort these similar items by price, alphabetically by item name, or alphabetically by brand. The default for secondary sorting is in the order mentioned in the previous sentence.

18 Searching for items

19 Groceries@Home should allow a customer to search for items at any point in time.

20 Customers can enter search terms and choose to search on item names, brands, price, or keywords in any field.

21 Both before and after search results are returned, customers can choose to sort search results by price, alphabetically by item name, or alphabetically by brand.

22 The default for search result sorting is by price.

23 Secondary sorting is performed in the order listed in 4.1.4.3.

24 Shopping by aisle

25 The application should allow customers to choose a particular category that would correspond to an aisle in a supermarket, and choose subcategories within each aisle, based on the types of items. For example, a customer should be able to choose “deli aisle”, and then be able to choose a subcategory such as “cheese” or “lunch meat.”

26 Shopping list

27 A customer should be able to enter a list of grocery items (no more than 50) and have the application either: a) return the lowest-priced option for each item or b) for each item, return all items matching that item. The customer should be able to choose option a or b.

28 Showing items on sale

29 At any point, the customer should be able to view all items on sale or all items on sale within a particular aisle subcategory.

30 Rating items

31 For any item viewed, the customer should have the option of rating that item (1-5 stars) and adding a comment about the item (5000 characters maximum).

33 Adding items to shopping cart

34 The customer should be able to add an item to their shopping cart by clicking a button and choosing the quantity.

35 If the customer requests more items than are in stock, the application should say so, and give them the option of receiving an email when the item(s) is in stock. (This email will be generated as soon as the item(s) are entered into the system.)

36 Viewing items in shopping cart

7. At any point, the customer should be able to view the items in their shopping cart, along with the quantity and price of each item, and the subtotal of the entire order.

37 Deleting/editing items in shopping cart

8. When the customer is viewing the items in their shopping cart, they should be able to delete and/or change the quantities of any item.

39 Subtotal and number of items in shopping cart

40 At any point in time, the current subtotal and number of items in the shopping cart should be visible to the user, even if one or both of these numbers is 0.

42 Checking out

43 The customer should be able to check out at any point in time, as long as they have at least 1 item in their cart.

44 The customer’s billing name, email address, billing address, shipping address, phone number, mother’s maiden name, and credit card type, number, and expiration date (if already given) should appear.

45 The customer should be able to edit any of this information at this time. If changes are made, the customer should be given the option to save this information so that it will appear automatically next time.

1. If the customer changes the shipping address to a location outside of Orange County, CA, they should be notified that GHDS doesn’t deliver to locations outside of Orange County, and be prevented from placing the order unless they enter a shipping address within Orange County, CA.

46 The customer should be able to choose whether or not it’s okay to leave the groceries outside their front door if they are not home.

47 The customer should be able to include a tip for the driver at this point, if desired.

9. The customer should be able to choose one of the available 90-minute delivery windows, up to one week in advance. Specifically, there are eight 90-minute delivery windows every Monday through Friday (including all holidays): 8-9:30am, 9:30-11am, 11am-12:30pm, 12:30-2pm, 2-3:30pm, 3:30-5pm, 5-6:30pm, and 6:30-8pm. Each window can hold ten deliveries. Once a delivery window has all of their ten slots filled, that delivery window is no longer available for subsequent customers to choose. An order for a delivery window can be placed up to 30 minutes before the beginning of that delivery window, as long as it is not full.

48 Finally, an itemized list of all the charges (grocery items, tax, delivery charge, tip), along with a grand total, should be presented to the customer and allow them to confirm the purchase.

49 Once the customer has confirmed the purchase, they will see “Thank you for your order. You should be receiving it on ___, between the hours of ___ and ___” with the information about the chosen delivery window in the blanks.

50 A confirmation email should be sent to the customer with the same information shown in 4.1.13.7.

51 Check the status of an order not yet delivered

52 A logged-in customer with an order that has not yet been delivered should be able to check the status of their order – whether it is en route to their home yet or not.

54 Help Section

55 The application should have a “Help” function that allows the customers to search for help on a variety of topics.

56 The help function should also include a short tutorial guide on how the customer interface for Groceries@Home can be used.

10. The help section should also include a customer service phone number and email address for reaching GHDS.

2 ADMINISTRATOR FUNCTIONALITY

1 Login

2 Administrators can log in with their username and password.

3 Editing administrator username and password

4 An administrator should be able to edit the administrator username and password.

5 Adding/deleting/editing drivers

6 Administrators can add, delete, and edit drivers.

7 The information stored by the system for a driver is his/her first and last name, login name, password, social security number, radio number, license plate of the truck, and current status (clear or on a job).

8 Adding/deleting/editing customer accounts

11. Administrators should be able to add, delete, and edit customer accounts, including all of the information stored for a customer.

9 Adding/deleting/editing items for sale

12. An administrator can enter the following information for each item. All of the following information must be entered for an item before it is added to the database:

1. UPC/Item ID number: A unique sequence that identifies this item.

2. Item name: (See 4.1.2.1.1)

3. Picture: A picture of the item.

4. Selling price: How much the item can be sold for. If it’s on sale, they must enter both the old price and the new price.

5. Description: (See 4.1.2.1.6)

6. Unit of measurement: e.g., ounce, 100-count, pound, fluid ounce.

10 Aisle: The name of the aisle in a physical grocery store that the item would be found in, e.g., “frozen foods” or “baby items.” This must be chosen from a standard set of choices in order to ensure consistency.

7. Aisle subcategory: The subcategory within an aisle in a physical grocery store that the item would be found in, e.g., “ice cream” or “diapers.” This must also be chosen from a standard set of choices.

8. Number in stock: How many of the item are currently in stock.

11 Viewing/browsing/searching for grocery items

13. An administrator should also be able to perform the functions described in 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.6, and 4.1.7.

12 Searching for orders

14. An administrator should be able to query the database of all orders placed by searching on the following fields: order number, customer name, date, customer login name, and order status (picked up or not picked up).

13 Adding/deleting/editing orders

15. An administrator should be able to add, delete, and edit any orders in the system

15 Entering delivery information

16 An administrator should be able to enter the price per mile for delivery.

18 Assigining drivers to orders

19 Administrators should be able to view all of the orders that have not been delivered yet (order number and assigned driver (if there is one), destination address, and current status (pending or en route)), along with a list of all drivers and their status (clear or on a job).

20 Administrators should be able to assign drivers to orders using the view described in 4.2.8.1.

21 An assignment can be changed as long as the driver is not en route to the customer yet.

23 Canceling orders

24 An administrator should be able to cancel an order unless it is already en route to the customer.

26 Generating reports

27 Groceries@Home should be able to generate the following types of reports:

28 Orders placed for a particular date range: The administrator can choose a date and the system should generate a listing of all orders placed on that day. For each order, it should list the order number, customer login name, assigned driver, time completed (or reason order was not completed) and order total (not including driver’s tip). The orders should be listed in ascending order by order number. In addition, a grand total of all orders placed that day should be at the end of the report.

29 Orders for a particular driver: The administrator can choose a particular driver, along with a date range, and the system should generate a report that lists all of the orders delivered by that driver for that date range. For each order, it should list the order number, address of destination, mileage driven, time completed, and order total (not including the driver’s tip). The orders should be listed in ascending order by order number. In addition, a grand total of all orders in the report and all of the mileage in the report should be at the end of the report.

30 All orders for a particular item: The administrator can choose a particular item (either by name or ID), along with a date range, and the system should generate a report that lists all of the orders for that item for that date range. For each order, it should list the order number, quantity of the item, price at which the item was sold, and the total paid for the item(s). The list should be in ascending order by order number. At the end of the report, a grand total of the totals paid for the item(s) should be given.

1. All orders for a particular brand: The administrator can choose a particular brand, along with a date range, and the system should generate a report that lists all of the orders for items of that brand for that date range. For each order, it should list the order number, all items of that brand in that order, quantity of each item, price at which each item was sold, and the total paid for the item(s) of that brand in that order. The list should be in ascending order by order number. At the end of the report, a grand total of the totals paid for the item(s) should be given.

2. Low/out of stock items: The system should generate a report that lists all of the items currently out of stock or with stock less than 5. For each item, it should list the UPC/ID, item name, item brand, and number in stock. They should be listed in ascending order by brand and then item name.

31 Help Section

32 The application should have a “Help” function that allows the adminstrators to search for help on a variety of topics.

33 The help function should also include a short tutorial guide on how the administrator interface for Groceries@Home can be used.

3 DRIVER FUNCTIONALITY

1 Login

2 Drivers can log in with their username and password.

3 Entering information about deliveries

16. A driver should be able to enter the information in the following field about each order assigned to them:

1. Current status: This can be either “picked up from warehouse”, “delivered” (along with the time delivery was completed), or “problem – not delivered” (along with a description of the problem).

4 Receiving assignments

17. Drivers should be able to view all of their assigned, non-completed orders (order number, items in order (name, ID, and quantity), customer name, destination address, and delivery type (standard or express)). Orders should be listed by order number (ascending).

5 Printing out customer receipts

18. For each order that is assigned to them, drivers should be able to print out a receipt with the information from 4.1.13.7 in it to bring to the customer.

4 MISCELLANEOUS FUNCTIONALITY

1 User Interface

2 GHDS has very few requirements about the user interface. The only requirement is that the user interface always displays “Groceries@Home” and the company logo across the top. The layout of the rest of the user interface is left to the designers.

3 Error Handling

4 All error handling is left to the designers of Groceries@Home.

Environmental Requirements

Since Microsoft Windows is the most popular and widespread platform of today, GHDS has decided that Groceries@Home should be able to run on Windows XP, Windows 2000, Windows 98, and Windows NT desktops. Other platforms do not have to be supported, since GHDS expects sufficient numbers of users from these basic platforms.

GHDS has also hired a consultant regarding programming languages, and, based on her report recommends that Groceries@Home be implemented in Java™, to ensure portability across platforms as well as easy maintainability. Use of the JDK 1.4 is expected.

Other Requirements

Groceries@Home will operate as a stand-alone application and does not have to interface with other applications.

The cost of development for the Groceries@Home system must not exceed $399,999.98. GHDS has consulted with financial analysts to determine that this is the maximum amount the system can cost without becoming unprofitable.

Scootie Software Inc. should carefully document all decisions made, especially decisions pertaining to changes in this document (and subsequent documents; always per agreement with GHDS).

Scootie Software Inc. will deliver detailed user manuals for the Groceries@Home application.

Software Qualities

• User-friendliness – Because many of Groceries@Home’s users are expected to be people with minimal to average computer literacy, it is imperative that the system be as user-friendly as possible.

• Correctness – Because GHDS is in the business of bringing their customers’ their desired set of groceries in an accurate and timely manner, it is important that Groceries@Home perform all of its requirements correctly and does not result in customers receiving orders that are incorrect, or do not otherwise meet their expectations.

• Reliability – Reliability of Groceries@Home is not essential, but nonetheless important. The accepted rate of failure is one crash per month. Any failure rate above this will create an unfavorable impression of GHDS and its service.

• Performance – Performance is crucial to Groceries@Home – if the system is too slow, customers may revert to phone-ordering because they feel it would be faster. Any search performed by a customer must not take more than five seconds. All other operations must be performed nearly instantaneously.

• Reusability – Because it is not expected that Groceries@Home will ever be resold or adopted for other purposes, reusability is not an issue.

• Extensibility – Several future enhancements for Groceries@Home have already been proposed, and there will undoubtedly be more forthcoming. Therefore, it is critical that Groceries@Home can be extended with relative ease.

• Evolvability – Groceries@Home is expected to undergo significant changes as GHDS strives to position the product for future market leadership. Evolvability is central to this goal.

• Robustness – Groceries@Home must not crash if a user enters incorrect or invalid data, or performs some otherwise unexpected action. A reasonable response that allows the application to resume normal operation must be given.

• Verifiability – Although it is preferable that the system undergo formal, thorough verification and testing before deployment, this is not feasible with the rigorous time schedule desired by GHDS. However, extensive testing of the accuracy of the system’s functionality should be performed before release.

• Maintainability – GHDS anticipates that Groceries@Home will be used over long periods of time, eventually by large numbers of users. Due to this fact, the likelihood of several future enhancements, and the high probability of an equally tight time schedule for their development, it is imperative that Groceires@Home be easily maintanable.

• Repairability – Because Groceries@Home is being developed under such a tight time schedule, it is likely that testing will not be done as thoroughly as desired, and some faults will make it into the product. Therefore, the system must be easily repairable in order to fix these defects in a timely manner so as not to disrupt the business of GHDS.

• Safety – Since Groceries@Home is not a safety-critical application, there are no safety concerns.

• Portability – Due to the fact that Groceries@Home will be implemented entirely in Java™, a highly portable language, portability will not otherwise be a concern in the design and implementation of the system.

• Understandability – To support evolvability, repairability, and maintainability, it is imperative that all aspects of Groceries@Home be easily understood, even to future developers who are not currently involved in the creation of the system.

• Interoperability – For this current set of requirements, the interoperability of Groceries@Home with any other application is not needed.

• Productivity – Because GHDS would like to release the Groceries@Home application as quickly as possible, it is desireable that the productivity of all involved in the development of Groceries@Home be supported and facilitated with quality processes and tools as much as possible. However, limited funding is available for this requirement, so it must be foregone.

• Size – Hard drive space and memory are abundant nowadays – size is not an issue.

• Timeliness – It is imperative that all artifacts of the Groceries@Home system be delivered on time. Time-to-market is of utmost importance to GHDS.

• Visibility – Due to the rigorous time schedule, extra time and effort to make the project status visible should be forfeited.

Time Schedule

The development schedule for Groceries@Home is as follows:

1 Design must be completed by February 20th, 2003 at 12:30 PM.

2 Implementation and module testing must be completed by March 4th, 2003 at 12:30 PM.

3 System testing must be completed by March 13th, 2003 at 12:30 PM.

Potential Risks

• Difficult to use – Groceries@Home has a lot of features and addresses every kind of user. Furthermore, a significant portion of its expected user base are non-computer literate. Hence, it is possible that some users might find it too difficult to use Groceries@Home.

•

• Limited schedule – The schedule according to which Groceries@Home is being developed is extremely aggressive and may result in a product that does not adequately satisfy the needs of GHDS.

•

• Sophisticated database technology – Groceries@Home must store an enormous amount of information about its orders, its users, and the stock of the GHDS warehouse. Therefore, Scootie Software Inc. will have to carefully design and implement optimal database storage and retrieval techniques for this information.

• Lack of adequate support processes and tools – A project of this size would ideally be supported by a number of quality software engineering processes and tools. Unfortunately, GHDS lacks the funds necessary to obtain these tools.

Future Changes

• Web Interface – In future versions, GHDS may want to create Web interfaces for all three user groups.

• Driver interface for PDAs – GHDS would like to further streamline the delivery processing procedure and make the information in the system even more up-to-the-minute by allowing drivers to directly enter their changes through a PDA interface while out in the field.

• Chat – GHDS would like to further reduce burdensome and/or slow telephone, fax, and email communication between GHDS employees, drivers, and customers, by incorporating a customized chat program into Groceries@Home.

• Linking with online cookbook programs – GHDS would like to pursue a partnership with online cookbook programs, such as the Digital Cookbook, and allow automatic placement of orders based on ingredients needed for a recipe.

• Linking with local grocery stores – In the future, GHDS would like to partner with local grocery stores and pick up their stock from them in order to provide their customers with a larger and more variegated stock to choose from, and obliterate the need for GHDS to maintain their own warehouse. This would require some substantial changes to the system – most notably, grocery stores would have to have their own interface to Groceries@Home.

Glossary

• Administrator – One of the three roles in the Groceries@Home application; Administrators have the ability to modify major information in the system, view stock information, and obtain reports on orders.

• Aisle – A category in which to place items depending on their type; each aisle corresponds to an aisle you might find in an actual grocery store.

• Aisle subcategory – A category within an aisle into which grocery items are placed depending on their type.

• Customer – One of the three roles in the Groceries@Home system; customers are ordinary people who wish to use the application to order groceries to be delivered to their home.

• Driver – One of the three roles in the Groceries@Home system; drivers are those who drive the trucks delivering groceries that have been ordered through Groceries@Home. They can enter information about their deliveries and view their assignments using the application.

• GHDS – Grocery Home Delivery Service. The client company contracting the development of Groceries@Home.

• Groceries@Home – The system under development; a software application that allows people to order groceries to be delivered to their home.

• Grocery item – Any item that a customer can purchase using the Groceries@Home system.

• Java™ - A highly portable, general purpose programming language developed by Sun Microsystems in the early- to mid-1990’s.

• Scootie Software Inc. – The company that will develop the Groceries@Home system.

References

•

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download