Software Requirements
Specification
for
Online Shop Software
Version 1.0
Prepared by
Klaudio Dervishaj
UNIVERSITY OF NEW YORK, TIRANE
Table of Contents
Table of Contents ... ii
1. Introduction...1
1.1 Purpose...1
1.2 Document Conventions...1
1.3 Intended Audience and Reading Suggestions ...1
1.4 Project Scope...2
2. UML Diagrams...3
2.1 Use Case Diagrams... ...3
1. Introduction
1.1 Purpose
Online Shopping Software main purpose is to provide customers with the possibility to perform online purchases on products already on store. Customers are identified properly and are able to perform online transactions using three kind of methods: either using credit card or banking documents, but also through PayPal account. Online Customers are divided on two categories upon user account types: basic and business.
Basic accounts beside other attributes contain a specific one named Fidelity which deals with the number of years the user has been joining the online shop. On the other hand is business plan which is characterized uniquely by the Volume attribute that is the total amount of transactions performed within the online shop. The customer is able to operate throughout the system after properly authenticated. He is able to create a cart and add products to it or delete them as well. Then he decides whether he might go on with the checkout operation and complete the purchase. Once the user decided upon the plan to use: basic or business, he is given the alternatives to pay through the previously mentioned methods accordingly. Once the purchase is confirmed by the customer and admitted by shop commission, customer details come into use in order to define the shipping address and other supplementary information. Customer is given the possibility to view and print some information regarding his activity on the shop. For instance he can print the number of purchases completed by him from eh beginning of the current year. He can print the status of previously performed purchases and decide whether to cancel or not a specific purchase if it is still in “Not available” status.
During the process of product selection and addition to cart specifying correspond
quantity the system automatically checks if the product is available within the quantity or not. In case of negative response the system generates a request to the product supplier. Stated in short terms this is the overall situation on hand.
1.2 Document Conventions
Specific terminology is used throughout the specification of the system.
User Profile: stands for the profile of the customer (person) opened in the software. One person can have multiple profiles using different emails. A profile can be linked to none or one account type.
Person: defines an real person who has an identity defined by class attributes. A person can have multiple profiles and consequently multiple accounts. For instance a person can have a basic and a business account.
Account: defines an entity that enables the user to operate throughout the system and perform purchases. It is the super class of two other classes respectively: Basic and Business which extend the super class.
Payment: defines an entity that enables an account to perform a payment transaction using one of alternative methods.
Purchase: defines an entity that encapsulates a purchase object. A purchase is specified by a unique number and status thus using the Status class.
Cart: stands for a container that holds selected products during the session and is included by a purchase.
Cart Products: as the name itself defines an entity that makes possible operations of addition, deletion, and selection of products in and from the cart.
Bank Transfer: stands for a payment method when using a basic plan.
Credit Card: stands for a payment method using a credit card when using a basic plan. PayPal: defines a payment method when using business plan. In this case it includes a PayPal service using a previously configured PayPal account.
1.3 Intended Audience and Reading Suggestions
The system is worth using by an audience that is interested on buying online products and benefit from facilities offered in such a case. Facilities are: saving time, saving money by selecting the best offer, comfort circumstances, safety of money transactions etc...
1.4 Project Scope
The scope of this project is to design and develop a system that is necessary to shops when they need to operate online, sell products online. The shop can keep an electronic history of all purchases and transactions. This gives more control over the operations that the company offers. The system can be adapted to a range of shops from simple small ones to big markets. A shop can outsource the function of shipping to another external company or can handle it itself. Project scope also includes financial transactions that call for other third party services like PayPal. Project scope from customer perspective, limits the range of customers to only those who have internet connation on some form and have a bank account in hand.
The aim of this project is to promote an efficient, user-friendly, time-fashionable, safe way for customers to bye and receive products without being physically at a shop thus using virtual money.
2. UML Diagrams
2.1 Use Case Diagrams
Online Shop from user perspective use case
Description:
This use case provides the viewpoint for the whole process from user perspective. Customer sees only the necessary functions that the system must define.
Actors: Online Customer
Preconditions: Customer must have a bank account.
Base Case:
2. Customer must choose the type of purchase to perform 3. Customer can view and select products
4. Customer can perform a purchase 5. Customer can cancel a purchase
6. He can view additional information regarding the purchase Alternative Flows
None
Post conditions: Customer performs transactions based on defined accounts. Additional Info/Issues: None
View Products Use Case
Description:
View products use case describes the whole operations a user can perform on a product currently on the store. It also describes an exceptional case when a product is not available on the quantity required.
Preconditions: Customer must login and authenticate firstly Base Case:
1. Customer can view the products 2. he can select the products
3. he can add the products to cart
4. he can define quantities on ordered products
5. system checks whether the quantity is satisfied or not 6. system responds to client with approving the purchase 7. system generates an automatic order to products supplier Alternative Flows
None
Post conditions: Customer performs transactions based on defined accounts. Additional Info/Issues: None
Make Purchase Use Case
Description:
This use case defines the cycle when customer makes a purchase. When deciding to perform a purchase the customer proceeds to the checkout operation and then to the payment method and according verifications.
Preconditions: Customer must confirm the final form of the cart and products already in. Base Case:
1. Customer must complete with the cart 2. he is taken to the checkout step
3. he is forwarded to a payment method based on the purchase type that he decided beforehand.
The customer may cancel the purchase when it is in “Not Available yet” status. Post conditions: Customer performs transactions based on defined account.
Additional Info/Issues: Includes third party accounts like PayPal or supporting bank documents.
Payment Use Case
Description:
Payment use case deals with the cycle of performing a payment through on of the methods mentioned.
Preconditions: Customer must authenticate and decide upon the type of purchase to commit.
Base Case:
1. Customer decides on the type of method to pay using either credit card or providing bank documents in case of basic type of purchase.
2. he decides upon PayPal method to pay if he decides on business purchase type. 3. each of the methods forward the user to the corresponding sites where he can
enter credit card info, or upload a document or confirm a PayPal account. Alternative Flows
Post conditions: Customer performs transactions based on defined account.
Additional Info/Issues: Includes third party accounts like PayPal or supporting bank documents.
View Purchase Use Case
Description:
This use case describes processes when the customer can view and print information for purchases he has already performed.
Preconditions: Customer must authenticate. Base Case:
1. Customer can view the status of the purchases already submitted.
2. If the status is “Not available yet” the user has the choice to cancel such a purchase.
3. he can list, view and print purchases from eh beginning of the year also. Alternative Flows: None
Post conditions: None
