Coursework Specification

Please read the entire coursework specification before starting work.

This is a group project development coursework.

The overall task for this project is to design and develop a standalone application for a toyshop e-retail system with the specifications below. The specifications outlined are based on the system requirements for AllAboutToys Ltds digital services expansion, given to you as a case study on COMP1821. On COMP1821, you were required to design the system using object-oriented concepts. For COMP1811, you are expected to implement that design in Python.

Implementing the project will give you practical experience in OOP development. You will implement the same object-oriented system design you produced for your coursework on COMP1821. This means youll implement and use the classes, relationships and methods identified in your UML diagrams. If necessary, you may modify your design based on the feedback you received on COMP1821 or if you think you can improve on your initial design.

The coursework specification provides less overview on how to do the project as you are expected to come up with and design the solution yourself. Your project development is the culmination of what you have learnt about OOP development and all your hard work for part one of this module. The system you develop should become a strong addition to your programming portfolio. You should aim to produce a system that is well-designed, robust and useful. The GUI design should be clean and simple to navigate. The system should operate smoothly without sluggishness or crashes and should not require instructions or a manual to use.

Scenario

AllAboutToys Ltd. (AAT) have decided to move their brick-and-mortar business online. They believe that expanding to an online presence will widen their customer base and increase their sales. They have produced as set of system specifications for the online system and have contracted you to develop their new toyshop e-retail system in Python.

System Specifications

The toyshop e-retail system should allow customers to buy toys online, as well as offer support to those who prefer to browse the online catalogue but buy in-store or those who simply need to submit queries about different toys online. AAT Ltd. would also like to reach out to their customers by providing a customer review service where customers can share/write their honest views about a toy and their experience with AAT.

Customers should be able to search for and browse the toys catalogue, read toy descriptions/specifications and customer reviews, write reviews and also purchase products using conventional electronic shopping-basket and check-out functionality. On check-out, customers should be given different delivery options including collection in- store and should determine delivery rates based on the option chosen. All online payments will be by credit card and will be verified through VISACheck. Your prototype system only needs to emulate VISACheck by simply creating a function that assumes that all payments are verified. After the payment is processed, the system should produce a receipt with a breakdown of the items purchased including any discounts applied, the delivery method and cost, and the total amount paid. The system should update stock after each payment is complete. The online catalogue must clearly indicate to the customer those products that are out of stock.

The system needs to allow for discount schemes to encourage sales. The discount schemes should offer discounts such as weekend special offers (10% discount) or BOGOF (Buy one get one free) for limited edition toys.

AAT Ltd. also expect the system to provide features for their administration and sales staff, and that these features are accessed with private login credentials. Sales staff should be able to access features that enable them to read and respond to customer queries and reviews. They should be able to generate and save sales reports outlining the total sales revenue, the number of sales per product, the top 10 best-selling products and the worst performing product category for a given sales period (start/end date), month, quarter or year. Administration staff should be able to add new products, and update and delete existing products. Product details should include a product ID/catalogue number, name, image, description, category (type of toy e.g. doll, soft toy, mechanical, etc.), age category, location in warehouse, price, and quantity. Administration staff should also be able add, update and delete discount schemes and choose how they are applied. The discount scheme should have an ID, name, type (10% or BOGOF), time duration (star/end date, weekend, 10 days), and the category of product the scheme applies to.

System Requirements

The system must provide the following features and comply with the System Specifications outlined above. Each member of your group must implement one of the features below and integrate it with other group members features. All features will require a GUI and database/file handling.

F1 Administration Features

1. login with UID and password:
   • check whether the entered credentials are correct;
   • prompt administrators with an error message if the UID does not exist or UID/password do not match.
2. maintain a list of product/toy categories:
   • add a category:

administrators should be able to enter a category code and name, then add the category to a database; prompt administrators if the category already exists;

• edit a category:

administrators should be able to select a category from available categories, edit its name and update the database;

• delete a category:

administrators should be able to select a category then delete its record from the database.

3. maintain products/toys:
   • add a new product/toy:

administrators should be able to enter a new product code and details, then add the new product to a database; prompt administrators if the product already exists.

• edit a product:

administrators should be able to select a product from available products, edit its details and update the database;

• delete a product:

administrators should be able to select a product then delete its record from the database.

4. perform stock taking:
   • create a permanent record of the list of products

administrators should be able to save the list of all products, their price and the quantity in stock to a file with the date when stock taking was done in its filename so that it can be saved and printed.

• alert administrators about all products that are low in stock (below 20 items)

this feature should display the list of product codes for items low in stock; the results can be displayed in a

dialog box prompted to administrators when they first open the application or when this feature is selected from menu. The feature should also allow administrators to save the list of products to a file so that it can be printed.

F2 Customer Features

1. Browse the toys catalogue:
   • display a list of all available products; each product should show the product name, image and price;
   • for those products that have 0 stock, display "Out of Stock" and display "Low Stock" for that products with stock below 20 items.
2. Search for a toy or category:
   • allow the user to enter a search keyword and display all products that match the keyword;
   • allow the user to select a product category and display all products within that category.
3. View a toy description/specification:
   • allow the user to select a product from the list of products in i or ii above;
   • display the products description and full details;
   • display a button to purchase the product and another to display its product reviews.
4. View and write a product review:
   • display all existing product reviews;
   • allow the user to write a new review and store it to a database.

F3 Order Processing

1. Shopping basket:

this feature should display/update the product name, its price and the quantity required, and any discount that applies to the purchase. The price needs to be updated depending on the quantity required. Discount may be applied at checkout if any are applicable, clearly indicate to the user that "discounts will be applied at check-out".

1. • add products to shopping basket;
   • update shopping basket
   • delete items from the shopping basket.
2. Check-out:
   • display delivery options and allow the user to select one or to use a default option;
   • apply any applicable discount scheme and update the total sales price;
   • calculate delivery cost and update the total sales price.
3. Payment:
   • allow the user to enter payment details;
   • verify payment using a simple VISACheck emulator as described in the system specifications above;
   • store the sales transaction and delivery details on your database;
   • for each product purchased, update the remaining stock quantity on your database.
4. Generate sales receipt:
   • display the receipt in an appropriate GUI;
   • allow the user to save the receipt to a file for printing.

F4 Sales Staff Features

1. Login with UID and password:
   • check whether the entered credentials are correct;
   • prompt the user with an error message if the UID does not exist or UID and password do not match.
2. Read and respond to customer queries and reviews:

this feature should allow sales staff to select the type of customer communication (query or product/customer services review), then:

2. • display a list of all unread communication;
   • repeatedly select a communication to respond to and save the response to the responses file/database, or discard a response attempt if necessary so that it can be reviewed at a later date.
3. Generate and save the following sales reports for a given sales period:

this feature should allow sales staff to select a report from the following and select a sales period (start/end date, month, quarter or year), then generate the report and display it in an appropriate GUI. The feature should provide the option to save the report to file for printing. Implement any three of the following:

• total sales per product and the overall sales revenue;
• number of sales per product category, per single product or for all products:

this feature should additionally allow sales staff to select between the above report options;

3. • top 10 best-selling products;
   • best and worst performing product categories.
4. maintain discount schemes and apply them to products:
   • add a scheme:

administrators should be able to enter a scheme ID and details, then add the new scheme to a database; prompt staff if the category already exists;

• edit a scheme:

administrators should be able select a scheme from available schemes and edit its details;

• delete a scheme:

enable Administration staff to select a scheme then delete its record.

• apply the scheme to a category of products:

administrators should be able to select a product category and apply the discount to all products in that category.

Development

As a group, you are expected to develop a standalone (desktop) version of the application and do not need to implement any web-based features. An appropriate GUI needs to be implemented to present the system features to users in a user friendly way. The features implemented by each group member must be fully integrated so that the system runs as one application. Your implementation must demonstrate appropriate use of the Python object- oriented concepts covered. Getting your project to function as required is important, but it is only one part of this assessment. What is most significant is the quality of your code and the OOP design features you implement. Make sure your classes apply appropriate abstraction and encapsulation. Try to use at least one appropriate inheritance hierarchy consisting of at least three classes. All three classes should be ones declared in the program and not classes from the Pythons modules and libraries. Remember to avoid code duplication in your programs. Many of the features are very similar. Think about how you can use classes and inheritance to reduce duplication in the code. This must be discussed as a group to avoid group members producing different versions of similar functions.