1. Introduction
1.1 Purpose
This Document includes software requirements for Collective Buying Portal (CBP), release number 1.0. Collective Buying Portal (CBP) hereafter referred to as CBP. This portal will allow a customer/Merchant the ability to upload their email lists to an online software package that will email auction items to their email recipients. The email recipients can accept these items at the current price offered but as numerical trigger points are reached the price will adjust to a lower price. For example if 1 – 10 people buy the offer, the price will remain at X amount of dollars. From 11 -20 people buy the price would change to Y amount of dollars. The triggers and price controls would be set by the Merchant. The software needs to be able to interface and collect moneys from a merchant gateway using credit cards. The money collected needs to be recorded on the email recipient’s account, the merchants account and the administrative account. The merchants will receive their money from the administrator in weekly, biweekly, and monthly increments depending on the merchant’s choice. The software only needs to track the merchant payouts as actual payment will be by other means. The emails sent out by the software package must be able to be formatted by the merchant by using a WYSIWYG editor. The software also needs to give the Merchant a flash embed code to use on the Merchants website if they choose. The flash embed should have real-time updates of the current price of any given item.


1.2 Document Conventions
1.2.1 When writing this document it was inherited that all requirements have the same priority.
1.2.2 First there is presented an overall view about CBP and then all features and functions are analyzed in detail.
1.3 Intended Audience and Reading Suggestions
This requirement document contains general information about CBP, main classes and use cases, functions, features and special technologies. It describes in detail all that CBP needs to work properly and with safety.
This document is intended for

Developers: in order to be sure they are developing the right project that fulfills requirements provided in this document.
Testers: in order to have an exact list of the features and functions that have to respond according to requirements and provided diagrams.
Users: in order to get familiar with the idea of the project and suggest other features that would make it even more functional.
Documentation writers: to know what features and in what way they have to explain. What security technologies are required, how the system will respond in each user’s action etc.
Advanced end users, end users/desktop and system administrators: in order to know exactly what they can expect from the system, right inputs and outputs and response in error situations.
1.4 Project Scope
This project will have multiple parts:

1.4.1. The User email
1.4.2. The User flash interface (hereafter referred to as ‘the BOX’)
1.4.3. the User page (where user has ability to check previous activity and view current receipts)
1.4.4. the ‘Merchant Platform’ account information, WYSIWYG editor, email list
1.4.5. the Administration ‘back office’ collecting/accounting/ and paying the appropriate sources.

1.5 References
A model that is closely related, is the method by which www.groupon.com uses to sell and advertise for local businesses.
2. Overall Description
2.1 Product Perspective
This is a NEW, Self-contained product.
2.1.1 The User Email should be formatted to the same appearance as the “BOX” and display the items on auction, time remaining, current price, and a buy now button
2.1.2. The ‘BOX’, is a flash embed that Merchants can embed into their website and will display the items on auction, time remaining, current price, and the buy now button.
2.1.3. The User page (user will create his own acct (password and username), this will be the cache for all currently held receipts (that are printable), it will also need to create and a bar-code for each item purchased for identifying and validation purposes, this is also where user has ability to check previous activity and view current coupons/receipts)
2.1.4. The Merchant Platform, where the merchant(our customer) has ability to upload data about his particular sale ie: TITLE heading, Product Description, Product Picture, Date to be sent out (to designated email list), Price breaks, Counter (of coupons bought), Timer/Clock (real time, days>hours>minutes>seconds). The software will need to generate an embed code for a flash object to be embed in the merchants website. The flash embed needs to be able to obtain updated information in real-time. The merchant needs to be able to upload email lists from Excel Sheets, CSV or tab delimited .txt. Emails need to be able to be reviewed before sending.
2.1.2 Administration ‘back office’ operations section will allow the administrator of the software to access all relevant information pertaining to collections/accounting/ and paying the appropriate sources. (this will need to be able to sync to QuickBooks , it will also collect money into a proper Merchant Account, take appropriate revenue % and log all transactions)
2.2 Product Features
Software needs to coordinate the relevant information to all the necessary parties. It must have 3 levels of security, Administration, Merchant and Buyer. The Merchants must be put into two formats one to be email to his list the other to be embedded into his website. The software must have a shopping cart function where products can be placed into a basket and paid for using a credit card. Each sale must generate a unique bar code to identify that sale. All financial records must me downloadable and the ability to interface with Quick Books.

2.3 User Classes and Characteristics
The following is a Hierarchy of product ACCESS:

Administrator (owner password, ie: Brian Ray, David Taylor)
Merchant (who will have his own interface): be able to upload their product data, check a Money revenue stream from each auction, and the necessary data he’ll need to plug into his own mailing lists and website.
User/Retail Customer: who will have his own log-in account.

2.4 Operating Environment
All must be HTML compatible, as well as the Administrative Back Office needs to be compatible with QuickBooks. Email system needs to accept Excel, CSV or tab delimited .txt.
2.5 Design and Implementation Constraints
None at this time
2.6 User Documentation
None at this time
2.7 Assumptions and Dependencies
The email system needs the ability to import Excel. CSV or tab delimited .txt email lists. Merchants and Administrators need the ability to download finical data in QuickBooks format.