CPSC 410 Project SRS Document Final
-
Upload
mohammad-sadiq-samim -
Category
Documents
-
view
95 -
download
2
Transcript of 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
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
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
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.
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
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
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
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
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.
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
11 | P a g e
3.3.1 Use Case Diagram
12 | P a g e
Design Documents
Architecture Diagram Architecture Overview:
Architecture Detail:
13 | P a g e
User Control Page:
14 | P a g e
Bidding State Charts:
15 | P a g e
Database Tables:
16 | P a g e
UML Class Diagram
17 | P a g e
18 | P a g e
Page-flow Diagram New User:
Create New Auction:
19 | P a g e
Deal with Expired Auction:
20 | P a g e
Chat:
21 | P a g e
Bid on Auction: