+ All Categories
Home > Documents > CPSC 410 Project SRS Document Final

CPSC 410 Project SRS Document Final

Date post: 22-Oct-2014
Category:
Upload: mohammad-sadiq-samim
View: 74 times
Download: 2 times
Share this document with a friend
21
CPSC 410, Chris Lack, Delfino Leong, Harry Chen, Martin Ku, Ted Huang 9/30/2010 Software Requirements Specification CraigsBay Auction House Version 2.0
Transcript
Page 1: CPSC 410 Project SRS Document Final

CPSC 410, Chris Lack, Delfino Leong, Harry Chen, Martin Ku, Ted Huang

9/30/2010

Software Requirements

Specification

CraigsBay Auction House

Version 2.0

Page 2: CPSC 410 Project SRS Document Final

2 | P a g e

Revision History:

Revision 0.0 – 2010-9-30 8:39PM – Initial draft skeleton made

Revision 0.1 – 2010-9-30 11:59PM – Initial Editing

Revision 0.2 – 2010-10-1 3:09PM – Added UML diagram and edited minor mistakes

Revision 2.0 – 2010-10-1 4:23PM – Fixed everything presumably

Page 3: CPSC 410 Project SRS Document Final

3 | P a g e

Contents

1. Introduction

1.1. Purpose....................................................................................................................................................................... 4

1.2. Scope ........................................................................................................................................................................... 4

1.3. Definition, Acronyms, and Abbreviations .................................................................................................... 4

1.4. References ................................................................................................................................................................. 4

2. Overall Description

2.1. Product Functions .................................................................................................................................................. 4

2.2. Interface ...................................................................................................................................................................... 5

2.2.1. User Interfaces ................................................................................................................................................ 5

2.2.2. Software Interfaces ....................................................................................................................................... 5

2.3. Constraints ................................................................................................................................................................. 5

2.4. Assumption and Dependencies ......................................................................................................................... 5

3. Specific Requirements

3.1. Functional Requirements ............................................................................................................................... 5-6

3.2. Non-functional Requirements ........................................................................................................................... 6

3.3. Use cases .............................................................................................................................................................. 5-10

3.3.1. Use Case Diagram ...................................................................................................................................... 11

Design Documents

Architecture Diagrams ........................................................................................................................................................ 12

User Control Diagrams ................................................................................................................................................. 13-15

UML Class Diagrams ...................................................................................................................................................... 16-17

Page-Flow Diagrams............................................................................................................................................................. 17

Sequence Diagrams ....................................................................................................................................................... 18-21

Page 4: CPSC 410 Project SRS Document Final

4 | P a g e

1 Introduction

1.1 Purpose The purpose of this software requirement specification document is to describe the behaviour and

functionalities of the CraigsBay Auction House system. The CraigsBay Auction House is designed to be an

online auction and trading site with built-in real-time communication tools between potential bidders

and the auction owner. The document is intended to serve as the guideline and intended goals for the

implementation of the various functions of the program.

1.2 Scope For the functionality of the auction and trade, the application will be limited to being only the mediator

between users in terms of communication and will not participate in the actual exchange of the goods.

The application will not be implemented to prevent nor will it take responsibility for any fraudulent acts

by any users. Photo sharing services will be provided by using the web service Flickr©. SMS services will

be handled by Zeep Mobile©. Our application will provide chatting services for users in order to

facilitate their trading activities.

1.3 Definitions, acronyms, and abbreviations SMS – Short Message Service

PageFrame – The main class of the client side. Calls on to helper classes to render the page

dynamically for the client. Also serves as a communication hub between the helper classes

1.4 Reference Flickr Web services API - http://www.flickr.com/services/api/

Zeep Mobile API - http://www.zeepmobile.com/developers/documentation/messaging/2008-

07-14/index

2 Overall Description

2.1 Product Functions The CraigsBay Auction House system is an auction and trading website. It provides communication

between users of the site in order to exchange information such as prices and contact information to

facilitate trading between users. CraigsBay Auction House will allow the users to upload photos through

the Flickr© web service to advertise their products. It will also support the sending of SMS messages to

users (through the Zeep Mobile© web service) as event notifications from the site. Users will be able to

create and manage site accounts, as well as post and manage their auctions, place bids on auctions, and

even message the auction creator. Auctions and posts will be classified into categories for easier product

searching. A chat system will also be included in the site to allow live communication between users

online. Any messages sent to a user who is online or offline will also be saved and available to the user

at a later time. Specific functions will be listed in details in the Functional Requirement Section.

Page 5: CPSC 410 Project SRS Document Final

5 | P a g e

2.2 Interfaces

2.2.1 User Interfaces The CraigsBay Auction House website will be accessed through a web browser by the user from his or

her computer. Specific use cases and diagrams are provided in the section 3.3 of this document.

2.2.2 Software Interfaces The program uses the web services provided by Flickr© and ZeepMobile©. Asides from that, there are

no major software interfaces. The server will be hosted through Apache Tomcat.

2.3 User Characteristics The CraigsBay Auction House application will be developed for a general web audience. Anybody

familiar with basic computer skills should be able to use the application. More veteran users of online

trading sites such as eBay or Craigslist will see similar functionalities here.

2.4 Constraints Client Side:

o Must have Internet browser (Suggestion: Chrome or anything other than IE)

o JavaScript must be enabled on the client browser

o Client cannot run more than one instance of the page frame

Server Side:

o Server must be accessible through the Internet

o Hardware constraints: Undecided/unknown at the moment

2.5 Assumptions and Dependencies It is recommended that the user have a broadband connection when using the photo sharing

functionality

User should be accessing the site through a desktop or laptop, not a mobile phone device.\

The site’s primary language of operation is English

3 Specific Requirements

3.1 Functional Requirements

Code Description

User

F01 Account management system that allows for unique account creation and user login

F02 User must be logged in to post Auction, place Bid, or start Chat.

F03 Guest accounts can browse the system, but not create auctions or place bids

Page 6: CPSC 410 Project SRS Document Final

6 | P a g e

F04 Account names will be made unique

F05 Users can add other users as friends for easy communication and auction browsing

Interface

F06 Option to log in and log out should be available

F07 Pages will be loaded dynamically (minimum refresh required)

F08 Option to search auction titles for a specific item should be available

F09 Events that affect the layout of the Interface must be rendered in real-time

Auctions

F10 Users can post new auctions

F11 The owner of an auction can delete/close an auction at any time

F12 The owner of an auction can edit the auction’s description at any time

F13 Auctions will be separated into categories

F14 Closed auctions can be re-opened by the owner

F15 Users can link a Flickr© album to the auction and the album images will be displayed in the auction page

F16 There will be a button to report spam and flag inappropriate auctions

F17 The auction page will display the current bid status and show the current top bidder

F18 Old auctions will get archived in the database

F19* Possible: Price comparing functionality with ebay

F20 If the auction owner has a registered phone number, they will receive a text message when an auction is bid on

Chat

F21 Logged in users can initiate conversations with an auction owner

F22 Chat logs are saved on the server and can be retrieved at the next conversation

F23 Users can communicate through the auction post even after the auction has been closed

Page 7: CPSC 410 Project SRS Document Final

7 | P a g e

F24 Chat messaging is delivered in real-time

F25*

Users can block other users from sending them messages

F26

Maximum 5 chat windows opened on the user page

3.2 Non-functional requirements Code Description

U01 The application must allow for scheduled maintenance times where server will be interrupted

U02 The application must keep a backup record of posts, bids, and chat by users

U03 The application must have an intuitive interface designed for the general public

U04 User must be able to access the website from any reputable Internet Browsers (i.e. Chrome, Firefox, Opera)

*Optional – May change on implementation.

3.3 Use cases

Create an auction UC#1

Pre/event User is logged in to the system

Post/description A new auction is created with the description the user provides

System Auction Web Application

Actors User, System

Related use cases None

Typical process description:

User System

1. User clicks on button to create a new

auction

2: System forwards user to the create new

auction page

3: User enters the details of the auction in the

space provided. Eg, Auction description, title,

starting bid.

4: A new auction is created in the

database

Page 8: CPSC 410 Project SRS Document Final

8 | P a g e

5: User is forwarded to the auction page they

just created

User bids on an auction UC#2

Pre/event User is logged in to the system

Post/description The auction selected is updated with the new bid amount

System Auction Web Application

Actors User, System

Related use cases None

Typical process description:

User System

1. User enters an amount of money > than the

current bid, than clicks on the bid on item

button

2: If the bid is valid, the system updates

the database with the new bid amount

and the new top bidder ID. Other metrics

such as total number of bids is also

updated

3: If the system accepted the bid, the user is

displayed a ‘bid successful’ prompt. Else if

the bid was rejected, the user is displayed an

error message saying why the bid failed.

Auction expires UC#3

Pre/event An auction has passed its user defined expiry date

Post/description The auction is closed and notifications are sent to the auction

owner and the auction winner

System Auction Web Application

Actors Auction owner/winner, System

Related use cases None

Typical process description:

Owner/Winner System

1: An auction passes its expiry date

Page 9: CPSC 410 Project SRS Document Final

9 | P a g e

2: The expired auction’s status is set to

‘closed’ and no further bids will be

accepted

3: Email notifications (and possible SMS

text messages) are sent to the auction

owner and the highest receiver.

4: Auction owner and winner receive an email

about the auction with instructions on how

they can contact each other and facilitate the

transfer.

User initiates chat with aucton owner UC#4

Pre/event Potential bidder is logged in to system

Post/description The user leaves a message for the auction owner, and if auction

owner is present, they can chat in real time.

System Auction Web Application

Actors Auction Owner, Potential Bidder, System

Related use cases None

Typical process description:

Potential Bidder Auction Owner System

1: Potential bidder initiates chat

with auction owner via the

‘Chat’ button in an auction page

2: System opens a chat

window for the auction

owner and potential

bidder

3: Potential bidder can ask

questions regarding the auction

4: If the auction owner is

online and available to chat,

he or she can chat with the

potential bidder in real time

5: All messages sent

between users are

persisted on the server

and can be retrieved in

the future for reference.

Page 10: CPSC 410 Project SRS Document Final

10 | P a g e

Account creation UC# 5

Pre/event None

Post/description New user account is created

System Auction Web Application

Actors User, System

Related use cases None

Typical process description:

User System

1: User clicks on register new account button

2: Web interface prompts user for his

information, such as desired user name,

password, location, email, and potentially

phone number

3: User enters his information and clicks

submit to create account

4: System validates the user information

entered.

A) If information is valid, a new

account is created with the

information provided

B) If information is not valid

(password does not match, or user

name already exists), the system

will prompt the user to fix the

incorrect information.

5: Account is created in the database

Page 11: CPSC 410 Project SRS Document Final

11 | P a g e

3.3.1 Use Case Diagram

Page 12: CPSC 410 Project SRS Document Final

12 | P a g e

Design Documents

Architecture Diagram Architecture Overview:

Architecture Detail:

Page 13: CPSC 410 Project SRS Document Final

13 | P a g e

User Control Page:

Page 14: CPSC 410 Project SRS Document Final

14 | P a g e

Bidding State Charts:

Page 15: CPSC 410 Project SRS Document Final

15 | P a g e

Database Tables:

Page 16: CPSC 410 Project SRS Document Final

16 | P a g e

UML Class Diagram

Page 17: CPSC 410 Project SRS Document Final

17 | P a g e

Page 18: CPSC 410 Project SRS Document Final

18 | P a g e

Page-flow Diagram New User:

Create New Auction:

Page 19: CPSC 410 Project SRS Document Final

19 | P a g e

Deal with Expired Auction:

Page 20: CPSC 410 Project SRS Document Final

20 | P a g e

Chat:

Page 21: CPSC 410 Project SRS Document Final

21 | P a g e

Bid on Auction:


Recommended