srs document group: ramas rowdy rumbunctious … · srs document group: ramas rowdy ... 1.5...

SRS Document

Group: RAMAS Rowdy Rumbunctious Requirements

Kharthik Ramanthan (20480776)

Nikit Chawla (20489391)

Sudhanva Huruli (20460206)

Michael Moore (20476234)

Date: March 30th, 2017

Owner

Highlight

Owner

Highlight

2

Table of Contents

Introduction .................................................................................................................................................. 6

1.1 Purpose ......................................................................................................................................... 6

1.2 Scope ............................................................................................................................................. 6

1.3 Definition, acronyms, abbreviations ............................................................................................. 7

1.4 References .................................................................................................................................... 7

1.5 Overview ....................................................................................................................................... 8

Overall description ........................................................................................................................................ 9

2.1 Product perspective ...................................................................................................................... 9

2.1.1 System Interfaces ......................................................................................................................... 9

2.1.2 Interfaces ..................................................................................................................................... 9

2.1.3 Hardware Interfaces .................................................................................................................... 9

2.1.4 Software Interfaces .................................................................................................................... 10

2.1.5 Communication Interfaces ......................................................................................................... 10

2.1.6 Memory Constraints .................................................................................................................. 10

2.1.7 User Interfaces ........................................................................................................................... 10

2.2 Product functions ........................................................................................................................ 13

2.3 User characteristics ..................................................................................................................... 16

2.4 Constraints .................................................................................................................................. 17

2.5 Assumptions and dependencies ................................................................................................. 17

Specific requirements ................................................................................................................................. 19

3.1 External Interfaces ...................................................................................................................... 19

3.1.1 Messaging Users ........................................................................................................................ 20

3.1.2 Banning users ............................................................................................................................. 20

3.1.3 Generating financial reports ...................................................................................................... 20

3.1.4 View reviews .............................................................................................................................. 20

3.1.5 View sale .................................................................................................................................... 20

3.1.6 Notifications ............................................................................................................................... 20

3.1.7 View wish list .............................................................................................................................. 20

3.1.8 Post product ............................................................................................................................... 21

3.1.9 Cancel product posting .............................................................................................................. 21

3.1.10 Modify posting ......................................................................................................................... 21

3

3.1.11 Registration..............................................................................................................................21

3.1.12 Login ......................................................................................................................................... 21

3.1.13 Edit profile ................................................................................................................................ 21

3.1.14 Search product ......................................................................................................................... 22

3.1.15 Place bid ................................................................................................................................... 22

3.1.16 Buy item ................................................................................................................................... 22

3.1.17 Review ...................................................................................................................................... 22

3.1.18 Browse ..................................................................................................................................... 22

3.1.19 Add to wish list ......................................................................................................................... 22

3.1.20 View history ............................................................................................................................. 22

3.1.21 View tickets .............................................................................................................................. 23

3.1.22 Reset account ........................................................................................................................... 23

3.1.23 Refund issue ............................................................................................................................. 23

3.1.24 Assign ticket ............................................................................................................................. 23

3.2 Functions (functional requirements) .......................................................................................... 23

3.2.1 Messaging requirement ............................................................................................................. 23

3.2.2 Banning requirement ................................................................................................................. 23

3.2.3 Financial Report requirement .................................................................................................... 23

3.2.4 View reviews requirement ......................................................................................................... 24

3.2.5 View sale requirement ............................................................................................................... 24

3.2.6 Notification requirement ........................................................................................................... 24

3.2.7 View wish list requirement ........................................................................................................ 24

3.2.8 Posting item requirement .......................................................................................................... 24

3.2.9 Cancelling item requirement ..................................................................................................... 24

3.2.10 Modify item requirement ........................................................................................................ 24

3.2.11 Registration requirement ......................................................................................................... 24

3.2.12 Login requirement ................................................................................................................... 24

3.2.13 Edit profile requirement .......................................................................................................... 25

3.2.14 Search product requirement .................................................................................................... 25

3.2.15 Place bid requirement .............................................................................................................. 25

3.2.16 Buy item requirement .............................................................................................................. 25

3.2.17 Review requirement ................................................................................................................ 25

3.2.18 Browse product requirement .................................................................................................. 25

4

3.2.19 Add to wish list requirement ...................................................................................................25

3.2.20 View history requirement ........................................................................................................ 25

3.2.21 View tickets .............................................................................................................................. 26

3.2.22 Reset account ........................................................................................................................... 26

3.2.23 Refund issue requirement ....................................................................................................... 26

3.2.24 Assigning ticket ........................................................................................................................ 26

3.2.25 Use Case Descriptions & State Diagram .................................................................................. 26

3.3 Performance Requirements ........................................................................................................ 26

3.4 Logical database requirements ................................................................................................... 27

3.5 Design constraints ....................................................................................................................... 30

3.6 Quality requirements .................................................................................................................. 31

Appendix ..................................................................................................................................................... 33

Appendix A: Use case descriptions (fully dressed) ................................................................................. 33

Appendix B: Meeting minutes ................................................................................................................ 59

Appendix C: State Diagram ..................................................................................................................... 63

Index............................................................................................................................................................ 65

5

Table of Figures

Figure 1: Use Case Diagram ........................................................................................................................ 12

Figure 2: Domain Model ............................................................................................................................. 19

Figure 3: ER Diagram ................................................................................................................................... 28

Figure 4: State Diagram............................................................................................................................... 63

6

1.1 Purpose

The virtual mall will utilize the Internet and the World Wide Web to build an online

marketplace. This document describes the software requirements and specifications for this

online marketplace. The document is intended for the customers and the developers (including

testers, designers and support). Customers in the context of this document refers to the

interested parties of the VMP Company. The document will describe to the customers how the

product should function. It can be used as an agreement on what the product should do

between the VMP Company and the developers. It can be used as a basis for estimating costs

and scheduling, act as a baseline for validation and as a basis for future enhancements. The

document can be used by developers, testers and designers as a reference on how the product

should function. In this sense, it can be used to reduce the development effort.

1.2 Scope

The Virtual Mall Place (VMP) will provide a web portal and mobile application which will enable

consumers to buy and sell products. A user will be able to sign up for the application using

authentication methods of their choice (Google login or custom sign up). If a user wishes to buy

products, they can add credit cards to their account which can be used for the payment. If a

user wishes to sell products, they will need to link a bank account to their account. Users can

browse for products on sale by browsing for products or searching for products with filters.

Items liked can be favorited and put into a wish list for later use. Users can purchase a product

by buying the product immediately (if the option is enabled) or by entering an auction. The

system allows users to purchase products with a credit card of their choice. Additionally, the

software will allow the user to post products of their choice up for sale or take products they

have posted down (either auction or immediate sale). The service should always be available

given a stable internet connection and should handle all user information with highest security.

The system will handle everything surrounding the sale of an item including sending

appropriate notifications and allowing users to request refunds. However, the VMP does not

handle the shipment details of a product and it is the responsibility of the seller and buyer to

agree on an appropriate shipment method using a third party postage company.

The software will establish a marketplace on the internet whereby customers can experience

the benefits of a marketplace from the web. Profit will be maximized for the seller due to

minimal overhead and costs associated with a transaction. Furthermore, the buyer is benefitted

from the large selection of products on sale at a competitive cost from the convenience of their

smartphone or laptop device. The primary objective of the VMP is to minimize cost of the

7

marketplace compared to brick and mortar shops and to maximize number of sales to increase

profits.

The VMP is not responsible for handling the end to end process of a sale. It provides a

marketplace where buyers and sellers can interact to process products. However, once a sale is

completed, the movement of goods and the delivery process is handled by the parties involved

in the sale.

1.3 Definition, acronyms, abbreviations

The following terms will be useful in understanding the remainder of the SRS document:

API: Application program interface, set of routines and protocols for building software

applications

GB: Gigabyte, measure of computer storage capacity roughly equal to 1 billion bytes

HTTPS: Hyper Text Transfer Protocol Secured, used to encrypt and decrypt user page

requests as well as the pages that are returned by the web server

KLOC: measure of the size of a computer program, size is determined by measuring the

number of lines of source code a program has

MB: Megabyte, measure of computer storage capacity roughly equal to 1 million bytes

PCI: a standard for connecting computers and their peripherals

RSA: a cryptosystem for public-key encryption, widely used for securing sensitive data

VMP: Virtual Mall Place, the system being created

1.4 References

There were a variety of references used for creating of this document. Meeting with the

customers and the minutes was used as a reference, has been provided in Appendix B. IEEE

standards guide has been used a reference. Google developer platform has also been used as a

reference. The references are listed below.

[1] "Integrating google signin into your web app," Google, 25 January 2017. [Online]. Available:

https://developers.google.com/identity/sign-in/web/sign-in. [Accessed 30 March 2017].

[2] S. Beidu, Interviewee, Meeting Minutes. [Interview]. 25 January 2017.

[3] S. Beidu, Interviewee, Meeting Minutes. [Interview]. 1 February 2017.

[4] S. Beidu, Interviewee, Meeting Minutes. [Interview]. 1 March 2017.

[5] S. Beidu, Interviewee, Meeting Minutes. [Interview]. 22 March 2017.

8

[6] "IEEE Style: Sample Reference List," Murdoch University, 14 February 2017. [Online]. Available:

http://libguides.murdoch.edu.au/IEEE/sample. [Accessed 30 March 2017].

1.5 Overview

The rest of the document is organized as follows.

Section 2 contains the overall description of the VMP system. In Section 2.1, the product

perspective is given. The use case diagram for the product is provided as well as an explanation

of the various interfaces present. In Section 2.2, the product functionality will be discussed. All

the various functions that the VMP system can achieve will be given in the form of short use

case description paragraphs. In Section 2.3, the general characteristics of the intended user will

be discussed such as their education level, their technical expertise and how much training is

required for them to use this product successfully. In Section 2.4, the constraints imposed are

discussed. This includes any regulatory policies, hardware limitations, control function, safety

and security consideration, standards, laws etc. Finally in Section 2.5, the assumptions and

dependencies are discussed. The assumptions made about the input and the environmental

behaviour is discussed, the conditions that could cause the system to fail is also stated.

In Section 3, the more specific requirements will be illustrated. Section 3.1 discusses External

Interfaces which illustrates the domain model for the product as well as providing a detailed

description of all the inputs and outputs for the product. For example, the name of inputs and

outputs are given, the source of input or destination of output is discussed etc. In Section 3.2,

the functional requirements of the system are listed. These include the fully dressed use case

descriptions and the state machine model for the product is provided in this section as well. In

Section 3.3, all the performance requirements that the product should meet is stated in

measurable terms. Section 3.4 discusses the logical database requirements which contains any

logic requirements for anything that is to be placed into a database such as data and their

relationships. Section 3.5 discusses the design constraints that can be imposed by other

standards, hardware and limitations. Finally Section 3.6 illustrates the required quality

attributes as testable constraints. These include factors such as reliability, availability, security,

maintainability, portability etc.

In the Appendix section, a copy of the minutes with the customer elicitation session can be

found. The appendix also contains the use case descriptions which are fully in detail. It contains

the state machine model as well. The index maps each important word or phrase to its

corresponding page number for easier cross-referencing.

9

2.1 Product perspective

For the most part, the VMP marketplace is a self-contained system and is not part of a larger

system. It works together with the bank payment system and authorization systems to verify

user bank details and credentials. The VMP system includes the running software on an

undetermined operating system along with the necessary databases to store the data.

Additionally, customer facing web portals and smartphone applications which can

communicate with the VMP system will be supported.

2.1.1 System Interfaces The system will need to use the API provided by the bank authorization gateway to establish a

connection and process requests to the gateway. The API to this gateway will be provided by

the gateway for the mobile application and the web development.

The VMP system will also interact with the Google login system. The application will need to

use the Google Services API to accommodate Google sign in at the login page. The APIs and

developer documents are provided on the Google developer website for web and mobile

development.

The VMP system will need to interact with the ads service gateway to receive ads from the

system to show the user. The APIs used to communicate with this gateway will be provided by

the gateway for mobile and web platforms.

2.1.2 Interfaces The interface between the system and the users are the touch phone devices that run the

smart phone application and the browsers that run the website. The main interface, is the

smartphone application and the website. Both interfaces take standard inputs for the

application (touch, mouse and keyboard). The output of the system will be reflected in the GUI

(application or website) for the user. In other words, the interfaces to the user are used to take

in input and show the output of the processing the system has completed.

2.1.3 Hardware Interfaces There are no specific hardware devices that the VMP system interfaces with. The VMP system

only interfaces with smartphones and devices able to run the web application. In this sense, the

system interfaces to the software on the devices and does not control any hardware. It is

important to note that the smartphone applications will need to be developed to run on iOS

and Android devices. This is an important requirement to ensure the requirement that the

system is available to maximum amount of people.

10

2.1.4 Software Interfaces The only other software product that the system will use is the Google Play Services API to

interface with the Google login authentication service. The description of this software

interface for web and mobile is provided below.

Name: Google OAuth 2.0

Mnemonic: GAuth (Gauth)

Specification #1

Version 2.0

Source: https://developers.google.com/identity/sign-in/web/sign-in

1. Purpose of this software interface is that it allows the system to communicate to Google

services to authenticate user login.

2. The interface content and format is black boxed to the system. To expand, once

implemented the API will handle taking user input and simply provide the system with a

success token and user information upon login.

Any other software interfaces used are not necessarily requirements but more so based on

design decisions. For instance, the ads service interface that will be used to communicate with

the ads gateway is not a requirement but a design decision based on the gateway used.

2.1.5 Communication Interfaces

There are no specific communication interfaces that are used specific to this system that are part of the requirements. All protocols are standard web protocols (HTTPS) to ensure the highest available security. The ads service gateway is assumed to not have any special communication interfaces.

2.1.6 Memory Constraints The only memory constraint is the cache storage available on the smartphone or browser session. When storing local data on the client devices, these limitations (around 1GB) should be kept in mind. Additionally, application size must be less than 500MB in order to be allowed on Google Play Store and the App Store to be available for download. On the system side, there are no known memory constraints since the system will be running in the cloud.

2.1.7 User Interfaces

Buyer: The buyer interface should be simple to allow the buyer to have a seamless experience in finding and purchasing the right item.

Seller: The seller interface should allow the user to post targeted products for sale to ensure a quick and efficient selling process.

Support: The support interface should allow the support to address all support issues quickly and easily. This user will require special access to handle tickets.

11

Security: The security interface should allow the security agent to maintain order on the VMP system. This includes banning users and products.

Accountant: The accountant interface should allow the accountant to generate reports without any assistance. This user will need special operations to process data.

The interactions of the users with the system is captured in the use case diagram below. All use cases in the middle are part of the system.

12

Figure 1: Use Case Diagram

13

2.2 Product functions

The functions of the VMP is outlined in the paragraphs below. Each use case is initiated by a user and will describe the steps taken by the system in response to the user actions. The main functions of the VMP is to provide an online marketplace for a buyer to browse and find products they wish to purchase and for a seller to post and sell products they want to sell. The use cases that will accomplish this main goal are outlined below. The use cases all require an active connection and at any point, if internet connection is lost, then the current state should be persisted by the VMP until the internet connection is re-established.

messaging a user in response to violations the user might have been reported for. The VMP system will need to get the message history between the agent and the user and send notifications for the user who will receive the message sent by the user.

include users and products. This use case is initiated by the security agent addressing a ticket by banning the user or product. The VMP system will need to disable the product or user that has been banned and send a notification to any user affected. It will need to provide UI for the security agent to fully perform all these actions.

system to generate financial reports. The VMP system needs to find and generate reports for the given filters selected by the accountant and display the results.

The VMP system will respond to this by accessing the review table and the user table to generate the reviews left for that user. It will then need to display the reviews for the seller to the user requesting it.

system getting a list of sold products associated with the user and displaying it for the user. Additionally, this requires the VMP system to monitor and track a table of the sale history for a particular user.

about a particular product the seller can initiate in a conversation with the buyer. The VMP system will need to update the message and user table. Additionally, it will need to handle the sending of notifications.

wish list d by the seller when they wish to view wish lists

14

a crucial use case that the seller initiates. This use case handles the posting of an item for sale through an auction and is initiated by the user submitting details about an auction to post to the VMP system. The VMP system will need to ingest details on a particular product and post the product. This includes updating the product and auction tables with the new product. If the user specified to bubble the item up by paying extra, this is handled in this use case by enabling a flag in the product table. This will allow the VMP system to sort the search or browse results to find and display items with this flag at the top. The VMP will then have this product available for auction when a customer searches for a product. Another use case initiated by the se

enter an auction. The item posted must be sold immediately. The VMP system will still need to ingest product details posted by the user and update the user and product tables with the posting of a new item. The user can also opt to bubble this product up by paying extra. This product will be shown in all matching searches and browse use cases. The posting of an item. The user can view items that have currently posted and choose to cancel an existing posting. When this occurs, the VMP system will remove the item posted if there are no bids on it. The item will get removed from the auction table (if applicable), the product table and any associations with the user. The user will receive a notification and UI response that the cancellation is successful. The final use case by viewing items they have posted on sale and submitting a request to modify the price. The VMP system will modify the price by updating the auction (if applicable) and product table if there are no bids on the product. The user will receive UI response from the client indicating the successful modification of the price.

s is initiated when the user accesses the website or mobile application without having an account logged in. The user can submit personal details and create an account. In this use case, the user specifies their credit cards, bank account and personal details that will be verified against the bank to maintain the security standard. The VMP system will create a new record in the user table and the payment tables. Upon successful registration, the user is logged in to the VMP system with their new account.

user accesses VMP and attempts to sign in to their account. If the user enters a username and password, the VMP system will authenticate the details with the database and log the user to the website with their details. An alternative for this use case is that the user can log in with the Google authentication system by passing the VMP system. In this scenario, their credentials are

15

verified with the third party Google system and a token is received by the VMP system to show the user has been verified.

logged in, the user can submit modifications to their profile. This includes changing personal info, adding credit cards, modifying bank details and modifying payment details. In any scenario, the edit will need to be authorized by the authorization gateway and if successful the VMP system will update the payment info, payment and user tables appropriately and let the user know through the UI. The user also has UI telling them if the edit failed.

posting of a product. The VMP system will update the message table and need to pull data from the user table to ensure the message gets sent to the right user. The buyer can view messages sent and received between users as the VMP system processes the messages. The buyer initiateoccurs, the VMP system is responsible for searching the product table and returning a list of products to the user. The VMP system must show the products that have been bubbled up at the top. Additionally, the VMP system will contact the ads service to receive ads to show the user. The buyer then receives the list of products in the UI.

d that is placed is then checked by the VMP system against the highest bid on the particular product in the database. If it is higher, then this user and the bid is the current winning bid on that auction. If not, the user gets UI letting them know they need a higher bid.

Buy Immediately price. When this occurs, the user can choose their credit to pay with along with the shipment details. If the buyer has enough reward points to purchase the item, they can purchase with reward points. The product, user and payment tables are used to complete the payment. There will be notifications sent to both parties when the payment completes. Additionally, when this payment is completed both users are awarded reward points.

for an order. The buyer must wait a certain amount of time before the write a review is enabled. This is handled by the VMP system. If the buyer can leave a review, they can submit their review for the seller and product they purchased. The review table is updated along with the user and product for which the review was left for. The VMP system lets the buyer know their review was received and the seller that sold the product is notified of a new review.

The buyer can optionally add filters to their browsing. The VMP system will return a list of products for the browse based on the filters. The VMP system will interface with the product database for this. The VMP system will need to show products that have been paid to be

16

bubbled up at the top of the return list. The VMP system also contacts the ads service to receive ads to show.

Wish listproduct, the buyer can save the product in their wish list. The VMP system is responsible for updating the wish list with the product saved. The user should see UI letting them know the wish list was updated with the product.

purchase history. The VMP system will respond by accessing the product, history and user table to return a list of purchased products by this user. The buyer will then see UI with their purchase history.

by submitting a request to cancel their existing bid on an auction. The VMP system will respond by updating the bids and auction table if the auction has not ended and notifies both users. The buyer will see UI notifying them of successful cancellation of the bid. The support agent initiates the tickets. The VMP system will get all open tickets from the ticket model and return it to the UI for the support agent to interact with.

case by messaging a user associated with

the user regarding the ticket. The VMP system will need to update the messages table and gather data from the user table to successfully send the messages. The VMP system is responsible for notifying both parties of messages.

the resetting of an account, the support agent will request the VMP system to reset the account associated with the user. The VMP system will work with the user table to reset the account and enable the user to login. The VMP system will need to send a notification to the user that their account was reset.

system will contact the banks to issue the refund and send notifications to both the parties involved. It will also need to update the review, product, auction, and history tables to undo any changes made by the completion of a sale.

2.3 User characteristics

There are several users of the VMP system and they are outlined below.

17

The buyer and seller are regular users who need not have a particular educational level or technical expertise to use the product. The UI needs to simple and intuitive such that anybody with the desire to use the product for purchases and sales can do so with ease. The support and security agents will be employed by the owners of the product. Therefore, they will have sufficient training in their roles and how their roles impact the system. However, the UI needs to be simple and seamless for these users to complete their tasks. They will need training on how their actions can affect the internal system. The financial accountants will not need any training to use the product. Their education level needs to only satisfy the requirements of their role at VMP. The UI on the product should be straightforward for this user to generate the various reports they desire.

2.4 Constraints

There are some notable constraints that will affect the developer in building the product. The first constraint is that any handling of payment information needs to follow industry standards. All payment information needs to be authorized with the authorization gateway. Payment methods accepted (i.e. type of credit cards) are limited to major credit card types provided by major banks. Additionally, the user password needs to be stored using salted hashing to follow industry standards. This means necessary steps will need to be taken to authorize the credit cards and banks accepted by the system. The second constraint that will need to be followed is the posting of certain items. Depending on laws and regulations within the region the system is running, certain items cannot be posted for sale. Therefore, the developers will need to take sufficient steps to ensure the products posted and being processed follow laws and regulations. The final constraint is a technical constraint that the application will need to build to support a variety of mobile devices. Since there is a mobile application component, the platform will need to support iOS devices and Android devices 4.4 or higher.

2.5 Assumptions and dependencies

There is an assumption that the shipment is handled by the seller and buyer independently outside of the VMP. Once a payment is complete, the VMP system does not handle the shipment of the item, the taxes associated with international delivery or the tracking of items.

18

There is an assumption that the user will have an active internet connection while using the product and there is no need to support offline functionality. If there is no connection, the product cannot be utilized and if connection is interrupted, then behavior is not guaranteed. There is an assumption that the website needs to support a thousand users at any given moment. The server running the VMP system is assumed to be handle this requirement. This is a strong dependency on the server since if this fails, the VMP system will not function as expected if it exceeds thousand users. There is an assumption that the website needs to support ten thousand transactions per day. The server running the VMP system is assumed to be handle this requirement. Additionally, the third party bank gateway used is assumed to handle this requirement. This is a strong dependency on the third party services because if they fail the VMP system will fail as well. There is an assumption that the Google login authentication platform is a reliable method to log and register a user in a single step without forcing the user to register through the VMP system. In this sense, this is a dependency on the Google authentication platform to succeed. However, if this service fails, the user can still manually enter details and use the VMP provided authentication gateway. There is an assumption that the authorization gateway can handle all verification of payment details reliably. The VMP system will only make very rudimentary checks against the payment details input (i.e. length) and does not verify against the vendors. There is a dependency on the authorization gateway in this sense. The gateway is also assumed to scale and support payment methods that may evolve or develop in the future. There is a dependency on this gateway to not fail. If this gateway fails for any reason, the VMP system will not work and cannot proceed with any actions that require user authentication. There is an assumption that the ads service gateway need not be determined right away. The service used to show ads can vary and is responsible for the ads that need to be shown. In other words, the VMP system need not send any information to the ads service gateway (this could jeopardize security) and should simply receive ads back upon each request. There is no dependency on the ads gateway other than for the displaying of ads. In other words, if this fails, the system will proceed without ads and nothing is affected. There is also an assumption that all user input is done using traditional input methods (mouse & keyboard, touchpad on mobile devices). It is assumed that these methods of input are available for any customer and that the customer will not be limited to other methods of input (such as voice).

19

3.1 External Interfaces

The domain model for the VMP system is provide in the image below. It illustrates all the different

entities, the type of relationship they share and their cardinality.

Figure 2: Domain Model

20

3.1.1 Messaging Users Inputs - Username of sender, username of receiver, and message Processing - System will check if users exist and are valid. Then check if the message is appropriate before sending it Outputs - Notification to sender and notification to receiver

3.1.2 Banning users

Inputs - password, and reason Processing - Remove the product or user from the system. Outputs - Notification to the security user of the success of the operation.

3.1.3 Generating financial reports Input - Accountant username and password, and date range Processing - redentials to ensure the person is authorized to generate the report. Query the database for the financial report of the date range specified. Output - UI will show the report for the range specified.

3.1.4 View reviews Inputs - Username Processing - System will authenticate the user and then query the database for the reviews of the corresponding user. Outputs - A list of all the reviews of the user will be displayed

3.1.5 View sale Inputs - Username and password Processing - System will authenticate the user and then query the database to provide a list of all the items sold by the user Outputs - A list of all the sales of the user will be displayed

3.1.6 Notifications

Inputs - Username, notification Processing - System will validate the notification and check if the user has the mobile app installed or not and send the notification accordingly. Outputs - User will receive a notification

3.1.7 View wish list

Inputs - Seller username and password, and product

21

Processing - System will authenticate the user and then query the database to provide a list of wish lists of user containing the product Outputs - List of wish lists with the corresponding users are displayed

3.1.8 Post product

Inputs - Username, name, price, description, filter parameters, bubbled up option, and type of sale. Processing - System will verify all the inputs and post the item. Outputs - User will receive a UI prompt informing them of the outcome of the action

3.1.9 Cancel product posting Inputs - Username, action Processing - System will query the database to retrieve all active postings for the user. Verify that the posting to be cancelled is active and there are no current bids on it. Output - Provide the user with UI prompt to inform of the successful cancellation.

3.1.10 Modify posting Input - Username, and updated price Processing - System will query the database to retrieve all active postings for the user. Enable editing of any active posting and save the changes made in the table. Output - The updated posting with the changes reflected and a prompt notifying the success of the action.

3.1.11 Registration Input - Username, password, credit card number, name on card, address, and bank account details. Processing - System will verify the details and process the bank details and credit card information through the authorization gateway. Output - A prompt informing the user if any details are missing or wrong. If not, a success prompt and redirect to personalized homepage.

3.1.12 Login

Inputs - Username, and password Processing - System authenticates the username and password to verify the user Outputs - Personalized homepage is displayed for the user

3.1.13 Edit profile Inputs - Username, updated name, updated credit card details, and updated bank account information Processing - System will query the database with the updated values. Outputs - A prompt notifying the user of the success of the operation.

22

3.1.14 Search product

Input - Product name Processing - System will query the database with the product name and return a list of all the products containing the name. The products with the bubbled up flag active should be displayed at the top. The system contacts the ad service to receive ads to display to the user. Outputs - UI displays the list of all the results of the query

3.1.15 Place bid

Inputs - Bid value Processing - System will update the auction with the new bid as the current winning bid Outputs - UI will reflect the new bid in the auction

3.1.16 Buy item Inputs - Credit card number, name on card, address, and amount Processing - System incorporates the authorization gateway to verify the information and the amount to be charged on the card. Outputs - User is taken to the shipping details page

3.1.17 Review Inputs - Review, username, and product Processing - System will query the database with the review, the seller username, and the product and update the tables with the review. Outputs - A UI prompt notifying the user that the review is posted

3.1.18 Browse Inputs - Filter parameters Processing - System will get a list of all products that have the filters set by the user. The system contacts the ad service to receive ads to display to the user. The system will show products that have been bubbled up at the top of the result set. Outputs - Display list of all products pertaining to the filter parameters

3.1.19 Add to wish list Inputs - Product, username Processing - System will update the table by adding the product to the wish list associated with the username Outputs - A prompt notifying the user of the success of the action

3.1.20 View history Inputs - Username Processing - System will query the database to retrieve all the products purchased by the user Outputs - A list of all the products purchased will be displayed on the screen

23

3.1.21 View tickets

Inputs - Username Processing - System will query the database for all the open tickets Outputs - A list of all the tickets is displayed on the screen

3.1.22 Reset account Inputs - Security username and password, and username Processing - System will verify the credentials of the security user and then retrieve the account of the username provided. Outputs - The user will be sent an email with the next steps to reset their account

3.1.23 Refund issue Inputs - Username, bank account details, and amount Processing - System will issue a refund with the specified amount to the username with the bank details Outputs - The user will be notified through email of the success of the refund

3.1.24 Assign ticket

Inputs - Username, ticket Processing - System will assign the ticket mentioned to the corresponding user Outputs - A UI prompt notifying the user of the success of the assign action

3.2 Functions (functional requirements) The functional requirements of the document are outlined below. The exact sequence of events that need to occur for each requirement along with validity checks and error handling is provided in the use case description below. Finally, the state diagram will be provided to assist in understanding the sequence of actions and the system specific responses to certain actions. Since the state diagram is provided in Appendix C.

3.2.1 Messaging requirement The system shall allow a user to be able to message other users

3.2.2 Banning requirement The system shall allow a security user to be able to ban a product and/or a user

3.2.3 Financial Report requirement The system shall allow an accountant user to be able to run a financial report based on a specific date range

24

3.2.4 View reviews requirement

The system shall allow a user to be able to obtain a list of reviews left for them

3.2.5 View sale requirement The system shall allow a user to be able to obtain a list of sold products by the user

3.2.6 Notification requirement

The system shall be able to send notifications to a user when they receive a message

3.2.7 View wish list requirement The system shall allow a seller user to be able to view wish lists of users containing a certain product that the seller chooses

3.2.8 Posting item requirement

The system shall allow a user to be able to post an item for sale either through auction or immediate sale by providing a name, price, description, filter parameters, and whether it is supposed to be bubbled up or not. There should be a flag set if the bubbled up option is active.

3.2.9 Cancelling item requirement

The system shall allow a user to be able to cancel an active posting by first providing a list of all active postings by the user and then providing a button to cancel a posting if there are no bids on it. If, however, there are bids on an active posting, it shall not be cancelled. After cancellation, a prompt should inform the user of the success of the cancellation.

3.2.10 Modify item requirement The system shall allow a user to be able to modify the price of an active posting by first providing a list of all active postings by the user and then providing an edit button to edit the posting. After the edit, the changes shall be reflected in the posting and a prompt the user of the success of the edit.

3.2.11 Registration requirement The system shall allow a user to be able to register for an account by providing a username, password, credit card details, and bank account details. Credit card details include full name on card, card number, and address. Both the credit card and the bank account shall be verified through the gateway. After successful registration the user shall be taken to their logged in homepage.

3.2.12 Login requirement The system shall allow the user to be able to login using their username and password or using Google login which provides an authentication token to the system to verify the identity of the user.

25

3.2.13 Edit profile requirement

page which goes to the account page. An option to edit the profile is provided which enables the user to edit their name, add credit cards, and/or modify their bank account information. This is then authenticated through the authorization gateway before the user is provided with a prompt to inform them of the success or failure of the operation.

3.2.14 Search product requirement

The system shall allow a user to be able to search products by name. Products with the bubbled up flag active shall be displayed at the top.

3.2.15 Place bid requirement The system shall allow a user to be able to place a bid on an active auction. If the bid is higher than the current winning bid then the bid by the user is made the current winning bid. Otherwise the user shall be prompted to input a higher bid. After the timer for a particular auction has finished, the payment shall be processed of the user with the winning bid and the

3.2.16 Buy item requirement The system shall alloption in a posting. The user can then choose the credit card to pay with and input the shipping address. After the payment is processed, the buyer and the seller shall receive notifications

3.2.17 Review requirement

The system shall allow a user to be able to review a seller and the corresponding product after the product has been delivered. The seller shall be notified after a review has been posted.

3.2.18 Browse product requirement The system shall allow a user to be able to browse products based on filters that the user specifies. Products with bubbled up flag active shall be displayed at the top.

3.2.19 Add to wish list requirement The system shall allow a user to be able to add items to their wish list by clicking a button on the posting.

3.2.20 View history requirement The system shall allow a user to be able to view their purchase history

26

3.2.21 View tickets

The system shall allow a support user to be able to view all open tickets that have not been resolved.

3.2.22 Reset account

a notification after the account has been reset.

3.2.23 Refund issue requirement The system shall allow a user to be able to issue a refund to a user. The seller and the buyer shall receive notifications after the refund has been processed. The refund shall be processed through the authorization gateway.

3.2.24 Assigning ticket The system shall allow a support user to be able to assign a ticket to another support user, or security

3.2.25 Use Case Descriptions & State Diagram The use case description and the state diagram reveal in depth the sequence of events for each requirement along with updates of any states within the system. The fully dressed use descriptions are provided in Appendix A due to their extended length.

3.3 Performance Requirements Since the VMP system is used by many users, it is required that the minimum number of terminals to be supported is 100 million. Seeing that terminals are how many stations that can be used to enter data at the same time, in this product, the posting of a product simulates entering data, hence there can be 100 million users posting products at the same time without the system crashing. The users of the system primarily include buyers and sellers and actors who act as both. Hence, 1000 users will also be supported at the same time, whether they are purchasing products through bidding or buying now or posting new products for sale. There will be a variety of information that will be handled through the lifecycle of this product. Since there are 1000 concurrent users possible at the same time, the amount of information will be 1000 times the amount for one user. For one user, the name of the user, their personal details and account information are information that needs to be considered. Their bank information and their credit card (or multiple credit card) information needs to be processed. If the user is a seller, then the information regarding what items they have posted for sale, which are on bidding and which are on buy now is also handled. If they are a buyer, their buying history and which items they have bids currently going on for also needs to be handled. The

27

reward points for both buyer and seller when a transaction is complete also needs to be handled. Most the information is in string format that needs to be handled, or in double format for example if the information is like price of product or the number of reward points they have obtained so far. Regarding the number of transactions to be processed within a set time period, the requirements are on average (include both normal and peak workload conditions):

95% of the transaction shall be processed within 5 seconds


All transactions can occur concurrently, so 100% of pending transactions are cleared with a 10 second time period

10000 transactions shall be accomplished without any problem per day In normal workload conditions, when the user traffic is not very high, the requirements are:



100% of pending transactions are cleared within a 6 second time period

Max user of the system is less than 500 so handling of less than 500 individual user data

15000 transactions shall be accomplished per day without any problem In peak workload conditions, when the user traffic is high, the requirements are



100% of pending transactions are cleared within a 14 second time period

Max user of the system is more than 500 but less than 1000 so handling of 500 - 1000 individual user data

10000 transactions shall be accomplished without any problem per day

3.4 Logical database requirements

The following section will outline all the data entities that will be required by the VMP system which will be stored in the database. Below is a database schema diagram to most efficiently showcase the database entities present in VMP and their relationship to one another. This diagram was built off the domain model and illustrates the database tables needed for the VMP system.

28

Figure 3: ER Diagram

29

In the diagram above, each entity has a primary key or a set of primary keys which ensure that each entity always has unique rows. Below each entity will be elaborated upon and necessary information about each will be conveyed.

The user table stores all the users that register into the VMP system. As shown in the diagram each user will have a username and password associated with them that will be stored in the database. This information will have to be stored securely by cryptographically hashing the password for every username in the database to ensure

d password data in the user table will have to be accessed once every user session in order to login.

There is a products table which holds all the products registered in the virtual mall place as shown by the products entity in the diagram. The primary key of the products table is a product I.D that is unique to each product. Each of the attributes of the product entity are accessed every time the product details screen is opened to see details of a specific product. The exception is the bubble up flag which is used rarely and only when a user pays to prioritize their product in the mall place.

In the database there is a table that links sellers to their products which is shown by the association present between the two entities in the database diagram. This table has a primary key which encompasses two foreign keys of the product I.D and the Seller I.D from the product table and the user table respectively. These key constraints are in place to ensure that if either the seller or the product is deleted from their specific

There is an auctions table in the database which stores all the current auctions with a primary key of auction I.D. This table also stores the product I.D of the auctioned product, which is also a foreign key, the current highest bid for each auction, as well as the auction status and the time left on the auction. Everytime a new bid is placed the highest bid attribute in the auctions table must be updated, therefore, there is only ever one bid stored in the system. When the auction closes, which is when the end time is reached, the auction instance is kept in the table and the status is changed to close. This persistence is done for history purposes.

The payment methods entity allows storage for multiple credit cards per user. The user must have one set as the default credit card and the database handles this using the primary card Boolean. The credit card number is restricted to 16 digits exactly as shown in the diagram.

The transaction entity links a product with a buyer and seller and has 3 foreign keys encompassed into the primary key. This makes every transaction unique.

30

The ticket entity stores information about support and security tickets. Each instance in the ticket table must have an assigned and submitted user and must specify the whether the type of ticket is directed to support or security.

The other entities in the database diagram are straightforward such as the messages table which hold messages between buyers and seller and uses one primary key to differentiate between messages.

3.5 Design constraints There were three key constraints mentioned in Section 2.4 that will be outlined in more detail in this section. Those three constraints were the need to use industry payment standards, product censorship constraints in certain regions and technical constraints pertaining to mobile device support. The first constraint pertaining to payment industry standards was put in place on the VMP system in order to ensu

marketplace is paramount to ensuring the longevity of users and to build trust with customers. Industry standards that must be followed by the VMP system in order to meet this constraint are PCI compliance, encryption and firewalls. The credit cards that are stored in the Virtual Mall place must be hosted and stored somewhere that is PCI compliant. PCI is a set of rules and standards used by the payment industry to ensure that the storage of credit cards and payment methods are stored securely. Some of these rules include using encryption whenever credit card information is transferred through the system and setting up firewalls and security measures where the credit card numbers are hosted. Additionally, as mentioned in Section 2.4, only credit cards from the major banks will be accepted in order to ensure that VMP is able to get proper support help if a transaction error occurs. The second constraint that must be considered is the fact that in different parts and countries in the world there are different laws and regulations that might censor certain products from being able to be sold. These differing laws must be considered when deploying the Virtual Mall Place in countries around the world. Therefore, developers of the VMP system must take significant measures to ensure that invalid products in certain regions cannot be sold. In order to achieve this, developers will include logic within the process of sellers adding items to the marketplace to find any infractions pertaining to regional laws. Another measure that will be implemented to enforce regional laws is the constant searching through the marketplace by the security users for any products that violate the rules and the removal of these products. With these measures put in place the regional standards of some countries will be upheld. The third and final constraint imposed on the VMP system is the requirement for a mobile application as well as the web client. This imposes constraints on the design and development

31

of the Virtual Mall Place application due to having to build the app with both a mobile and web side in mind. Some additional constraints on the mobile application side are that the application must support iOS devices as well as android devices with Android 4.4 or higher. These constraints require the developers to either develop two separate applications, one for the web and one for the mobile, or build the web application with a framework that provides a mobile first approach to application development.

3.6 Quality requirements The quality attribute for the VMP system include the following. Reliability:

There will be a maximum of 1 bug per KLOC

The system may fail up to a maximum of 50 hour per every 1000 hours but recommended to allow 10 hours out of 1000 hours ensuring 99.9% reliability, in failed cases all users should be alerted of the fail

Availability:

The system should be available 24/7

The system should be available 99.5% of the time in a year, with the 0.5% being used for updates, outages and crashes

The system that allow users to restart with the loss of no data Security:

All Bank transactions and data transferred through the VMP system is secured using RSA encryption

All user logins and actions are stored in a log

Maximum of 3 unsuccessful logins, after which the account is locked and must be unlocked by security team

There shall be no complaints of identity theft due to VMP security system Maintainability:

User interface changes shall made by affecting less than 10% of the VMP functionality within 1 hour

Upgrades to the VMP system shall occur as a background process without the system going down, the upgrades shall take place next time they login

All major features shall be modularized such that they can be replaced without hindering other non-related functionality (for example, bank authorization should not hinder the capability to search/bid/post products etc.)

Portability

The VMP system shall work on all Operating Systems and on all Web Browsers

The VMP system app shall work on all phones (android, iPhone)

32

Accessibility:

The VMP system shall be available in English language as well as other local languages depending on the location of the user

Performance:

The must be no delay in performing actions, if present, the total delay/lag must be less than 2 seconds

Successful login must take less than 15 seconds Reusability:

The VMP system shall be reusable such that any system requiring the same functionalities as VMP can use the same software components

Robustness:

The VMP system shall automatically lock out an user after three incorrect attempts to login

The VMP system shall terminate with an error message in the circumstance that the required server or database could not be connected to

The VMP system shall be protected from the maximum user limit to prevent unexpected number of connections

The VMP system shall reject not terminate on invalid requests Safety:

All information should be transmitted to the appropriate destination, database or server without any tampering or changes

Scalability:

The system shall be able to perform activities faster proportional to the amount of resources incremented

Testability:

The system shall have all components modularized and successful testing should occur through running of unit tests

Usability:

95% of users should be able to learn, operate and navigate the product by themselves

95% of users should be able to accomplish their goal with the system in under 10 mins

33

Appendix A: Use case descriptions (fully dressed)

Name: Browse Products ID: UC 1

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator), Product Database Trigger Event: User selects a category to browse Overview: User browses list of products

Typical Scenario:

Customer System

1. Customer browses for products listed for sale

2. Checks for listed products and sort based on bubbled up items

4. Show user the products (exit use case) 5. Show user ads based on category

6. If customer chooses to add product to short list go to UC 2.

7. If customer wishes to buy a product go to UC 3.

Exception 1: cannot connect to the internet

2. VMP cannot connect to the product database. 2.1 Send failure message to user (exit case)

34

Name: Add Item to Shortlist ID: UC 2

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator), Product Database Trigger Event: User wishes to add a product to their shortlist Overview: User adds a product to the shortlist

Typical Scenario:

Customer System

1. Customer prompts to add product to shortlist when they browse for products listed for sale

2. Sends product & user information to user database for update

4. Show user product was added successfully (exit case)

7. If customer wishes to buy product immediately go to UC 3. Else go to auction use case UC 4.


2. VMP cannot connect to the user database. 2.1 Send failure message to user (exit case)

35

Name: Buy Item Immediately ID: UC 3

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator) Trigger Event: User wishes to buy a product Overview: User wishes to buy a product immediately

Typical Scenario:

Customer System

1. Customer wishes to buy a product now and chooses a credit card to complete payment with

2. Contact the bank authorization system with the payment details of the user 3. Bank validates the payment information with the system and charges the card the amount 4. Pay the seller the appropriate amount with commission moving to VMP 5. Send push notification to buyer and seller of the deduction and addition of money to the account respectively 6. System initiates the rewarding of points to the users based on the size of the transaction 7. Find user and reward user points for the transaction 8. Show user message on how many points they collected for the transaction (exit case) 9. System must update product table and history tables with appropriate updates of the sale

36

Exception 1: payment detail fails to go through

3. Payment fails to go through and there is no money moved between the accounts. 3. n+1. Send push notification to buyer only that the payment failed to validate.

Exception 2: cannot connect payment service

3. Show user failure message (exit case)

Name: Place Bid ID: UC 4

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator) Trigger Event: User wishes to place a bid on a product Overview: Place a bid on a product

Typical Scenario:

Customer System

1. Customer wishes to place bid on an item

2. System queries item information

3. Return product information with existing bids to the system

4. Customer bids amount on the product returned

5. Update product database with latest bid on item

6. Send notifications to the customer with bid information. 7. If customer is highest bid after specified time on item, initiate buy for customer UC 3.

Alternative 1: Customer gets outbid Between Steps 4-7

37

8. Customer gets a notification that they got outbid 9. If customer wishes to place new bid go to Step 1.

Exception 1: Cannot connect to the internet. Between Step 1 and 2.

10. Show customer failure message.

Exception 2: Cannot send notifications. Step 5

11. Update customer profile notification on VMP system only

12. Update user catalog to reflect notifications

Name: Write a Review ID: UC 5

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator) Trigger Event: User wishes to leave a review after purchasing and having the product Overview: Allow user to leave the review for a seller

Typical Scenario:

Customer System

38

1. User wishes to leave a review for a seller and the transaction with the seller

2. Connect to the user database to store the review for the seller

3. Update users information with the latest review

4. Update review for the seller and show the review (exit case)


2. VMP cannot connect to the product database. 2.1 Send failure message to user that leaving a review is not available at this point

Name: Cancel Bid ID: UC 6

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator) Trigger Event: User wishes to cancel a bid Overview: Allow user to cancel a bid

Typical Scenario:

Customer System

1. User wishes to cancel a bid they have initiated to place

2. Get product information from database that the bid is being cancelled for

3. Retrieve and return product for which the bid is being cancelled for

4. Show user the bid they have placed is cancelled 5. Initiate mobile and email notification system to send notifications. (exit case)

Name: Messaging ID: UC 7

39

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator) Trigger Event: A user wishes to message another user Overview: Allows a user to message another user

Typical Scenario:

Customer System

1. User writes and sends a message to another

mation that the message should be sent to

3. Gather user information and return to system

4. Send the message that the user wrote in Step 1 to the other

5. Send message to the user

6. Send notification to the other user with the message. (exit case)

Alternative 1: User cancels the sending of a message Step 1 4

7. User cancels message sending

8. System does not send notification nor does it contact database again and just ends. (exit case)

Exception 1: System cannot connect to the internet Step 1

9. System cannot connect to the internet and must notify user message cannot be sent (exit case)

40

Name: Search Products ID: UC 8

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator), Product Database Trigger Event: User wishes to search a product Overview: Allows user to search for products

Typical Scenario:

Buyer System

1. User enters and types in the search for a product

2. Contact the product database to get a list of products

3. Retrieve and return product for the query

4. Show the user a list of products based on the results

Alternative 1: User adds filters to the search Step 1

2. Contact the product database to get a list of products

3. Retrieve and return product for the query with the filters applied.

4. Show the user a list of products based on the results (exit case)

6. If user wishes to add a product from the results to their shortlist go to UC 2

Exception 1: Cannot connect to the internet. At any step

1. Show user message saying connection to internet lost and display no products (exit case)

42

Name: View Buy History ID: UC 9

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Buyer (initiator) Trigger Event: User wishes to view all their history on VMP Overview: Show user their purchase history of their activity on VMP

Typical Scenario:

Buyer System

1. User navigates to the buy history page

2. Gather user purchase history from the product table.

3. Show user their purchase. (exit case)

43

Name: View Sale History ID: UC 10

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Seller (initiator) Trigger Event: User wishes to view items they have sold Overv

Typical Scenario:

Sellers System

1. Seller wishes to see their sale history

2. Contact the database with user information and get the orders they have sold

3. From the products and user table, extract the sale information for the user

Exception 1: cannot connect to the internet to gather order history

1. Show user a failure message that their order history was not obtainable

44

Name: View Reviews ID: UC 11

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Seller (initiator) Trigger Event: User wishes to view their reviews

Typical Scenario:

Seller System

1. Seller wishes to see their reviews and prompts the system for the reviews from their sale history page

2. Contact the database with user information and get the reviews left for the user

3. From the reviews table using the user information, extract the reviews for the user



45

Name: View Buyer Wish lists ID: UC 12

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Seller (initiator) Trigger Event: User wishes to view buyers who have their wish lists Overview: Gathers wish list items

Typical Scenario:

Seller System

1. Seller navigates to the wish list page and searches for wish lists that match the search string

2. Contact the database with the search string and get all the wish lists that contain their search string

3. Show the seller the wish lists that match their search and give option to message that particular user UC 7



46

Name: Place item on auction ID: UC 13

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Seller (initiator) Trigger Event: From product listings page, the user wishes to create a new auction item Overview: Places a product for auction

Typical Scenario:

Seller System

1. Seller wishes to post an item for auction and posts the details of the item

2. Persist product information and create items in auction table and update the user table



Alternative 1: user submits payment information to bubble item up

1. User submits payment information to bubble item up

2. System processes payment information and charges credit card and updates product table to enable this item to be bubbled up.

3. Persist all product information and create items in the auction table and update the user table

47

Name: Place item for immediate sale ID: UC 14

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Seller (initiator) Trigger Event: User wishes to place an item for immediate sale from the product listings page Overview: Places a product for immediate sale

Typical Scenario:

Seller System

1. Seller wishes to post an item for sale and posts the details of the item

2. Persist product information and create items in auction table and update the user table



Alternative 1: user submits payment information to bubble item up

1. User submits payment information to bubble item up

2. System processes payment information and charges credit card and updates product table to enable this item to be bubbled up.

3. Persist all product information and create items in the auction table and update the user table

48

Name: Cancel an Item ID: UC 15

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Seller (initiator) Trigger Event: User wishes to cancel an item they have posted for sale from their listings page Overview: Cancel an item a user has posted for sale

Typical Scenario:

Seller System

1. Seller navigates to the product listings page and cancels an item they have posted

2. Cancel product and all bids on the item if there are no bids on the item. 3. Send notification to the user and show UI that the product has been cancelled



Alternative 1: there are existing bids on the item

1. Send information to user that the product cannot be cancelled because there are existing bids (exit case). Must show user UI notifying them of this.

49

Name: Change price of item ID: UC 16

Level: System Authors: Sudhanva Huruli System: VMP Online Marketplace Actors: VMP Seller (initiator) Trigger Event: From the product listings page, go to manage product page and change price of item Overview: Changes price of an item for sale

Typical Scenario:

Seller System

1. Seller navigates to manage item page and make modifications to the item

2. Update product table with the price of the item and the modifications if there are no bids on the item. IF there are bids,

done and the user is notified of this (exit case). If there are no bids, make updates and notify the user of successful updates.


1. Show user a failure message that the save was not complete.

50

Name: Run Financial Report ID: UC 17

Level: System

Authors: Kharthik Ramanathan

System: VMP Online Marketplace

Actors: Accountant, VMP System

Trigger Event: Accountant wishes to run a financial report

Overview: Accountant wishes to run a financial report

Typical Scenario:

Accountant System

1. The accountant wishes to run a

financial report

2. VMP systems checks it records and prepares to

send the required items

3. VMP compiles the report and returns it to the

Accountant on their screen

4. Account obtains the required financial

report (exit use case)

Exception 1: cannot connect to the

internet

2. VMP cannot connect to the financial record

database

2.1 Send failure message to user (exit case)

51

Name: Register ID: UC 18

Level: System



Actors: User, VMP System

Trigger Event: A user (buyer or seller) wishes to sign up for the VMP system

Overview: Any user is able to sign up to use the VMP system

Typical Scenario:

User VMP System

1. The user wishes to sign up by

clicking sign up button

2. The VMP system takes the user to the sign up page

3. The user enter their

information like email,

password, age, name, profile

52

4. The VMP system takes this information and sends it to

the user catalog

5. The user catalog is updated with this new user and their

details (exit use case)

6. If user wishes to continue to

login to the system after sign up

go to UC19.

Exception 1: cannot connect to

the internet

2. VMP cannot connect to the record database


Alternative 1: User wishes to

register using Google

authentication

3. User chooses to register using

google authentication

4. System initiates the Google registration flow. 5. Google registration completes and allows user to go

to the homepage directly after system updates all information received from Google servers.

Name: Login ID: UC 19

Level: System



Actors: User, VMP System

Trigger Event: A user wishes to login to the system

Overview: A user is logging in to the system

Typical Scenario:

53

User VMP System

1. The user enters the username

and password

2. The VMP system takes the login details and checks with

the user catalog for authorization

3. The user catalog verifies the information for the user and

gives authorization

4. Once authorized, the user is

logged in (exit use case)

5. If password is wrong, they are

given 2 more opportunities to

repeat Step 1 onwards, after

that their account is locked (exit

use case)

6. If the user wishes to edit their

profile information once logged

in go to UC20

Alternative 1: using external

platform to login ( Gmail)

1. The user enters password for

their external social media

platform

2. VMP verifies with the external company and authorizes

login, then continue from step 4


the internet



Name: Edit Profile ID: UC 20

54

Level: System



Actors: User, VMP System, User Catalog

Trigger Event: A user clicks the edit profile button

Overview: Any user wishes to change their user profile details

Typical Scenario:

User VMP System

1. The user wishes to edit their

profile

2. The VMP system takes the user to the edit profile page

3. The user changes their

information and clicks confirm to

approve their changes. The user

can add payment details here.

4. The information is sent to the user catalog for update.

The system also contacts any third party services

(authorization gateway) if the user modified payment

details or added payment details.

5. Product catalog updates the appropriate details for the

user

6. The updated information now shows up on the VMP

profile page

7. Profile has been successfully

edited (exit use case)


the internet



55

Name: Remove inappropriate

products

ID: UC 21

Level: System



Actors: Security, Product Catalog, VMP System

Trigger Event: An inappropriate product is discovered for sale and is on the ticket page and a

security agent wants to remove it

Overview: The ability to remove the product from being sold to buyers

Typical Scenario:

Security VMP System

1. The security discovers an

inappropriate product

2. Details of the product vendor is obtained

3. The product is removed from the product catalog

4. The product is no longer available to be searched,

browsed and or for sale (exit use case)


the internet



56

Name: Ban Users ID: UC 22

Level: System



Actors: Security, VMP System

Trigger Event: An inappropriate product is discovered for sale and is on the ticket page and a

security agent wants to ban the user

Overview: The ability to remove the product from being sold to buyers

Typical Scenario:

Security VMP System

1. The security discovers an

inappropriate user

2. Details of the user is obtained

3. The user is removed from the user catalog

4. The user is no longer available to login, sell or bid on

items (exit use case)


the internet



Name: View Tickets ID: UC 23

Level: System



Actors: Support, VMP System

Trigger Event: Support agent can view all tickets assigned

57

Overview: The ability to view assigned tickets

Typical Scenario:

Support VMP System

1. The support agent logs in and

can view their tickets

2. Details of the tickets assigned to the user is gathered

3. The tickets gathered are shown to the user


the internet



Name: Reset Account ID: UC 24

Level: System




Trigger Event: From the ticket details page, reset an account

Overview: The ability to reset a user account

Typical Scenario:

Support VMP System

58

1. The support agent from the

ticket details page resolves a

ticket by resetting an account

2. Reset users password and modify login page for user

next time they log in (force them to entre password) 3. Resolve the ticket and send user an email telling

them next steps to login


the internet



Name: Issue Refund ID: UC 25

Level: System




Trigger Event: Support agent issues a refund on a ticket from the ticket details page

Overview: The ability to view assigned tickets

Typical Scenario:

Support VMP System

1. The support agent from the

ticket details page, chooses to

complete a refund request

2. The buyer and seller are refunded from their respective

accounts through a request to the payment service

3. Notify both parties of the completed refund and resolve

the ticket


the internet



59

Appendix B: Meeting minutes

January 25, 2017

Company General Questions 1. What overall company goal will the VMP help achieve?

a. Goal is to provide a place for people to sell their stuff. VMP will help make money.

2. What problems are you facing without the VMP? . Not facing problems. Identified potential money. 3. What are some alternatives that were considered for the VMP? 4. What is the budget? What are the resources allocated? . Out of scope. 5. What is the target delivery date? . Out of scope. 6. How are you currently achieving these goals without the VMP? What extra new features

are being added to the VMP? 7. How is success defined for this application? How is success going to be tracked? . Success is defined by looking at quality attributes. System is successful when it achieves

8. When does the development need to be started? Are there various phases of deliverables

that need to be targeted? General Application Questions 9. Who are the target users for the VMP and how were they chosen? a. Out of scope. 10. Who will be using the system, what is their expertise level and what are the title and roles of the people? 11. Is there going to be support for the VMP once it is deployed? If so, who are they and what are their roles? . Out of scope. 12. Who are the owners of this product within the company that can be approached for more information? . The TAs. SANDY. 13. How are users trained? If any. . Out of scope. 14. How is the user expected to use the application? What is a sample flow? . Buyer: EBAY and amazon works. Browse categories, search for items. If it is a bidding item then you update. If win, notified on both parties and then you proceed with payment and then seller does the shipping. 15. How many languages need to be supported (English, French, etc)?

60

. Multiple languages supported. 16. How many countries will this be deployed to? . Worldwide platform. 17. How is the information served to the users going to be showed? Relevance, Most Recent? . Filters for the users when they are searching. 18. What is your expected load on the system? . A few 1000. 19. What platforms are your users expected to use? Specifics (iOS, Android, Web)? . Interested in working in a browser. All browsers. Support apps. 20. What type of payments and currencies are going to accepted on the system? . Credit cards only. Sellers must have a bank account when registering. 21. What kind of information (if any) is to be tracked? . Engineering decision. Shipping is like amazon. 22. What kind of authentication is desired? . Engineering decision. 23. Where is the user expected to be while using the feature? 24. Where is the application going to be stored? On prem solution or a cloud based solution? . Doesnt matter. 25. When is a user supposed to think about using VMP? . Buy or sell an item. Specific Application Functionality Questions 26. How many screens will the application have? What is the information that is to be displayed on each screen? a. Based on how we design the system. 27. What are the main user functions that will be performed? Describe each one. . Buyer: - search - create a wishlist - place bids - make payments - see orders - track shipments a. Seller: - post an ad - browse wishlists 28. What actions would you like the users to perform while offline, if any? . Always online. 29. What are the attributes that items will be categorized into? Examples include electronics, clothing etc. . By design. 30. Is there going to be a reward program? . Can add as an additional feature. 31. What happens if a seller does not honor the sale and does not ship the item properly? . Contact supports. a. Needs to be an admin account. 32. What happens if a buyer wants to cancel an order after it has been made? . Can cancel if not shipped. 33. What happens if the payment system gets rejected?

61

. The order does not go through. Before you place a bid, a certain amount will be put on hold your credit card. 34. Can customers buy items without entering an auction? For example, the customer pays a certain amount and they instantly buy the item. . Option for buy now exists. 35. When a customer creates an account, are they going to specify if they are a buyer or seller or both along with some questions on items they are interested in? . Both. 36. Can sellers pay extra money to have their item bubbled up to the top of the buyer's screen? . You can pay extra money.

February 1, 2017

1. Can a seller cancel a buy it now/bidding item?

Yes, if no one has placed a bid on it yet.

2. Are we expected to accept multiple credit cards (which a user can choose from when

making a purchase)?

System allows multiple credit cards.

3. How are sellers paid? Are they paid direct to their Credit Card or does it go towards an

account balance which they can withdraw?

Sellers are paid through their bank. All users need to attach a credit card.

4. Should sellers be able to specify shipping costs separate from the price of an item, or

should this cost be rolled into the price of the item listed?

Yes

be

paid by a user?

No fees to pay except a commission.

6. What kind of localization support are you looking for?

None.

7. Should the security officer be monitoring the messaging between the buyer and seller?

No but there should be access to it in case of disputes.

March 1st, 2017:

62

1. Should there be an option for users to retrieve their account information in case they

forget their password?

Reset password button option present, email will show them next steps.

2. Do we need to verify a bank account?

VMP will use account number to contact and verify that the account exists.

3. What happens to cancelled listings? Are they still in the database/Can they be viewed by

users?

Not visible if user cancelled it.

4. What happens to an auction if it expires and no one has bid?

Item will be removed.

5. Can a seller edit a listing after bids have been placed?

6. Can you convert a direct sell listing to an auction?

7. What sort of shipping tracking support will be provided?

Seller need to tell the system it is shipped, buyer will get tracking information.

March 22nd, 2017

1. How many concurrent users should be able to use the system without excess latency?

1000 users

2. What is the number of transactions per day that the system must be able to

support?

10000 transactions per day.

3. What is the target reliability of the system? For every 1000 hours (~42 days), at most how

many hours of downtime is acceptable?

50 hours downtime for every 1000 hours max.

4. Security -- Do you want the same level of security for all information?

Credit card and bank information should not be leaked out.

63

Appendix C: State Diagram

Figure 4: State Diagram

Given on the next page

VMP

Homepage Search ReultsSearchProduct ApplyFilters

Register

Register[isReg=false]

BrowseProduct

RegFail/isReg=false

CancelRegister

LoginPage

FailLogin

RegSuccess/isReg=true

CancelSearch

CancelLoginLogin[isReg=true]

Not Logged In

Logged In User SuperState

LoginSuccess

Logged In User

Action List Page

Financial Reports Page

Tickets Page

viewUserDetails/getUserDetails

Show User Details

ViewProducts[ifSecurity]/getProductListings

Products Page

viewTickets[ifSecurity OR ifSupport]/getAllAssignedTickets

Logged In Employee

Logout

Password Recovery

ResetSuccess/updatePassword

ResetPassword

ResetFail

Product Details Page

viewProductDetails/getProductDetails

removeProduct/updateProductListings

ResetCancel

viewProducts/GetProductListings

modifyFinancialReport/updateFinancialReportShow Financial Report

generateReport/getFinancialReport

viewFinancialReports/getFinancialReports

viewFinancialReports[ifAccountant]/getFinancialReports

ViewHomepage

viewHomepage

View Ticket Details PageviewTicket/

getTicketDetails

removeUser[ifSecurity]/updateUserTable,updateTicketTable

initiateMessage/getMessageSession

Logout

MessagesSuperState

Message List

Chat Page

ViewMessage/getMessage

sendMessage/updateMessage,sendNotification

deleteMessage/updateMessage,sendNotification

deleteMessageThread/updateMessages

viewMessageList/getMessages

exitMessageSession[inState:=chatPage AND (ifSecurity OR ifSupport)]

RefundsSuperState

Refunds List Page

Refund Page Refund Creation Page

getRefundDetails/getRefundDetails

createRefund

viewRefundRequets/getRefundRequests

issueRefund/updateRefundsTable,

sendNotification,updateProductsTable,updateRewardPoints

modifyRefundDetail/updateRefund,

sendNotification

submitRefundDetails/AddToRefundsTable

viewRefundRequests,getRefundRequests

manageRefund[ifSupport]/getRefundDetails

exitRefundsSession[inState:=refundsPage AND ifSupport]

User s Listings Page

Auction Item Creation Page

Buy Now Item Creation Page

Auction Item Management Page

Buy Now Item Management Page

getAllCurrentAndPastListings

createAuctionItemRequest

createBuyNowItemRequestsubmitCreationsDetails[ValidatePaymentInfoIfBubbleUp]/updateProductsTable

cancelNewItemCreation

cancelNewItemCreationviewSpecificAuctionItem/

getAuctionItem

viewSpecificByNowItem/getBuyNowItem

editAuctionItem/updateAuctionItemsTable,

updateproductsTable

updateBuyNowItem/updateProductTable

removeBuyNowItem/removeBuyNowItem,updateProductTable

removeAuctionItem[auction.bid==null]/updateProductTable,updateAuctionTable

cancelManageItem

Product ListingsSuperState

List Of Products PagesearchProduct/

updateProductsPageWithSearchResults

applyFilters/updateProductPageWithFilters

Product Details Page

viewProductDetails/getProductDetails

placeBid[myBid > highestBid AND auction.status == open]/updateAuctionTable,updateProductDetails

Checkout Page

initiateBuyNowRequest

auctionEnded[aucTime == 0]/updateAuctionsTable

selectPaymentCard/updatePaymentMethod

submitPayment/updateProductsTable,

sendNotifications,updateRewardsPoints

viewProductsList/getProductsList

Browse ProductsSuperState

submitCreationDetails[ValidatePaymentInfoIfBubbleUp]/updateAuctionsItemsList,

updateProductsTable

Account Info Page

getProducts()

Payment Info Page

editPaymentInfoRequest

editBankAccount[bankAuth]/updateUserBankAccount

editCreditCard[bankAuth]/updatePaymentInfo

viewAccountInfo/getAccountInfo

editPersonalDetails/updateUserDetails

Account InfoSuper State

Wishlists Page Homepage

viewWishlist/getUserWishlist

viewHomepage

Purchase History PageReview Page

getBoughtProducts

initiateReviewForProduct/getProductDetails,

getUserDetails

createReviewForProduct/updateReviewTable

cancelReviewCreation

HistorySuperState

viewRefunds[inState:=PurchaseHistoryPage]

viewHomepage[inState:=refundsSuperState]

View AccountInfo

View Homepage

Manage Product Listings

View Account Info

View Homepage

View History

View Homepage

View Homepage

banProduct[ifSecurity]/updateProductTable,

sendNotifications

Reviews Page

viewReviews/getReviews

viewUserListings

createNewMessage[inState:=browseProductsSuperState]

createNewMessage

inputWishlistSearch/getWishlistWithSearchParams

addItemToWishlist/updateUserWishlist

resetUserAccount[ifSupport]/updateUserTable,updateTicketTable

viewWishlistItem/getProductDetails

65

Communication Interfaces, 10 Constraints, 17 database tables needed for the VMP, 27 Design constraints, 30 domain model for the VMP system, 19 functions of the VMP, 13 Hardware Interfaces, 9 Interfaces, 9

Memory Constraints, 10 Performance Requirements, 26 Quality requirements, 31 Software Interfaces, 10 State Diagram, 63 use case diagram, 11 User Interfaces, 10

srs document group: ramas rowdy rumbunctious … · srs document group: ramas rowdy ... 1.5...

Documents