Académique Documents
Professionnel Documents
Culture Documents
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
2|Page
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
3|Page
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.4 Reference
Flickr Web services API - http://www.flickr.com/services/api/ Zeep Mobile API - http://www.zeepmobile.com/developers/documentation/messaging/200807-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.
4|Page
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.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
3 Specific Requirements
3.1 Functional Requirements
Code User F01 F02 F03 Description Account management system that allows for unique account creation and user login User must be logged in to post Auction, place Bid, or start Chat. Guest accounts can browse the system, but not create auctions or place bids
5|Page
F04 F05
Account names will be made unique Users can add other users as friends for easy communication and auction browsing
Interface F06 F07 F08 F09 Auctions F10 F11 F12 F13 F14 F15 Users can post new auctions The owner of an auction can delete/close an auction at any time The owner of an auction can edit the auctions description at any time Auctions will be separated into categories Closed auctions can be re-opened by the owner Users can link a Flickr album to the auction and the album images will be displayed in the auction page There will be a button to report spam and flag inappropriate auctions The auction page will display the current bid status and show the current top bidder Old auctions will get archived in the database Possible: Price comparing functionality with ebay If the auction owner has a registered phone number, they will receive a text message when an auction is bid on Option to log in and log out should be available Pages will be loaded dynamically (minimum refresh required) Option to search auction titles for a specific item should be available Events that affect the layout of the Interface must be rendered in real-time
Chat F21 F22 F23 Logged in users can initiate conversations with an auction owner Chat logs are saved on the server and can be retrieved at the next conversation Users can communicate through the auction post even after the auction has been closed 6|Page
Chat messaging is delivered in real-time Users can block other users from sending them messages Maximum 5 chat windows opened on the user page
UC#2
User is logged in to the system The auction selected is updated with the new bid amount Auction Web Application User, System None System
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
Pre/event Post/description System Actors Related use cases Owner/Winner
UC#3 An auction has passed its user defined expiry date The auction is closed and notifications are sent to the auction owner and the auction winner Auction Web Application Auction owner/winner, System None System 1: An auction passes its expiry date 8|Page
2: The expired auctions 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.
UC#4
Potential bidder is logged in to system The user leaves a message for the auction owner, and if auction owner is present, they can chat in real time. Auction Web Application Auction Owner, Potential Bidder, System None Auction Owner System
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. 9|Page
Account creation
Pre/event Post/description System Actors Related use cases User 1: User clicks on register new account button None New user account is created Auction Web Application User, System None System
UC# 5
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
10 | P a g e
11 | P a g e
Design Documents
Architecture Diagram
Architecture Overview:
Architecture Detail:
12 | P a g e
13 | P a g e
14 | P a g e
Database Tables:
15 | P a g e
16 | P a g e
17 | P a g e
Page-flow Diagram
New User:
18 | P a g e
19 | P a g e
Chat:
20 | P a g e
Bid on Auction:
21 | P a g e