Java auction

[login to view URL] Specification This document is a high level requirements specification for [login to view URL] which aims to provide a competitive & transparent reverse auction service to users in various regions. There will be only one type of auction supported which is a reverse auction where the minimum unique bid wins. If there are no unique bids at the end of an auction, a search is performed for the smallest group of matching bids (2 matching bids for example), and the person in that group that bid first is the winner. There are two parts to the web site that need to be developed, the first is the user centric pages, and the second is the administration console that will allow a site administrator to manage the site on a day to day basis. The admin console should allow the control of a variety of settings as described in this document. General Design There are some general design guidelines that need to be fulfilled. In terms of the look and feel, a focus on simplicity, cleanliness and consistency is important. Pages should not appear cluttered, and only the relevant information should be provided. Further discussion and prototyping of a logo and colour scheme should be completed as soon as possible. Two critical aspects of the design is that it should be multi region capable. In that regard, the site needs to be designed in such a way that multiple languages can be supported as well as multiple currencies. In terms of language support, the site would have a single reference language, namely English, and would allow the administrator to configure additional languages via the admin console. A dictionary system should allow the administrator to define text to be inserted at appropriate control points in the site. Multi language support (e.g. English, Russian plus others) Multi currency support (e.g. USD, GBP, EUR) In terms of technology, the implementation should be restricted to the use of commonly used open source technologies. Primarily, the target language should be PHP using a mysql database as the data store. Stored procedures are acceptable, however little or no business logic should be in stored procedures. Implemented in Java Client side JavaScript (form validation, AJAX etc...) Cookies (saved preferences etc...) No flash animation Multi Language The multi language features should be configurable by the administrator via the admin console. Ideally a dictionary system in the database should be used to lookup the appropriate text that needs to be inserted into the web page at various control points. The administrator should be able to manage the content for the various languages that are supported via the CMS interface. The user should be able to switch to the language of choice by clicking an appropriate link easily visible on all pages (english | russian) for example. Please bear in mind that one of the supported languages for the site will be Russian, and therefore the cyrillic alphabet needs to be supported by whatever character set you decide to use for the database. Multi Currency The site also needs to support multiple currencies which should be configurable via the admin console. When a user signs up, they should be able to select their preferred currency in which they will observe prices and transact. There will be a global reference currency to administer the site (say USD) and the admin console will always operate in these terms. Furthermore, the admin console should allow for the maintenance of exchange rates to all the supported currencies of the site. When a page is dynamically generated for a user, their preferred currency and language settings (obtained from a cookie) should be intercepted and the page rendered accordingly. When a new user arrives at the site, a default language and currency should be used as configured by the administrator using the admin console. Pages & Sections Home (Live Auctions | Upcoming Auctions | Closed Auctions) How it works Support Frequently asked questions News About us Contact us Feedback Form Vacancies Terms & Conditions Privacy Statement Site Map User Account Page Administrator Console Login Input fields to enter a username and password should be available in the header of every page as well as a “Forgot Password” and “Free Registration” link. In the case of forgotten passwords, a page should be displayed that allows the user to enter their email address. An email should be generated that contains text from an administrator defined template which includes their username and password details. If the user selects the registration link, they should be directed to a page to enter registration details as described in the next section. Once a user has logged in successfully, their name should be displayed in the header of all pages (as opposed to login fields). In addition, the following links should be visible: My Account (see later) Add Funds (see later) Registration When a user registers we wish to capture the following fields: Username Password Email address First Name Last Name Gender Date of birth Preferred Currency (drop down list) Address Line 1 Address Line 2 (optional) City Post code Country Telephone number How did you hear about us selection. Use of client side Javascript for validation is required. Check that the username is available when lost focus on that field (print error message in red below the text field if it is already taken). User needs to type in their password twice to confirm it is correct, highlight in red text if they do not match. User needs to type in their email address twice to confirm it is correct, alert in red text if they do no match. The selection of countries in the drop down box should configurable by the administrator. We do not need to capture county and/or state or other US specific fields. Include check boxes to force the user to indicate that they have read the Terms & Conditions as well as the Privacy statement. Links to these should be provided to make these easy to access, and they should open in a new browser window. The user should also be able to opt out of receiving any news letters or other promotional material. By default, this should be set so that they will receive such materials via email. Finally, the user should be required to enter a security code visible in an included image to prevent fraudulent accounts from being created by non human users. Once they have submitted the registration form, the resulting page should indicate that they will receive an email in which they will need to confirm the account registration by clicking on a link. The account should not be enabled until they have clicked on this link and thereby confirmed that their email address is correct. Reverse Auction Specification There is only a single type of auction that needs to be supported, namely a reverse auction where the minimum unique bid wins. In order to place a bid, a user needs to purchase the right to bid. The cost of a bid should be configurable per product. Generally speaking, the more expensive the product, the higher the cost of bidding on that product, but that is at the discretion of the administrator. A user account will have a balance of funds which they can add to using various payment methods described in a later section. Once they have adequate funds on their account, they will be able to register bids. An auction should be configurable using the following properties: Product name Product description Product description URL (link to external page, usually manufacturers web site) Recommended Retail Price (expressed in reference currency) Start date and time (yyyy-mm-dd HH:MM) Expiry date and time (yyyy-mm-dd HH:MM) Cost per bid (expressed in reference currency) Image of the target product (to be stored in the database) The administrator should be able to use the admin console to create or amend auction details as above. Auctions configured with future start dates should become visible as upcoming auctions. Upcoming auctions should be visible to users so that they can be made aware of what is coming in the coming weeks. What the user should see for a given auction The user should be able to see the following details on an auction listing: Product name Product description Product image Recommended retail price (in their preferred currency) Cost per bid (in their preferred currency) Count down timer to auction close (if auction is live) Count down timer to auction open (if auction is not yet open) The username of the person who currently has the lowest unique bid The count down timers and the username of the currently winning bidder should be changing dynamically in the page using the appropriate Javascript / AJAX calls. The user should not have to refresh the page to get this information. Placing a bid A user needs to be logged in to place a bid. If a user is not logged in and they click a bid button on one of the auctions, they should be redirected to a login page. After a successful login, they should be redirected back to the page from which they were redirected to login. To place a bid, a user must specify a bid price. A text field that only allows numeric data to be entered should be available to allow a user to enter a bid price (it must be a positive number). The price should be expressed in the smallest monetary quantity of the users chosen currency (e.g. cents for USD or EUR, pence if GBP). Therefore an amount entered as 934 implies $9.34 or €9.34 or £9.34. To enter a bid, the user should simply type in the numeric value and then click the bid button. Once a user clicks “Bid”, they should be presented with immediate feedback on the outcome of their bid by dynamically changing the html of the page. At this stage, we identity 5 possible outcomes upon a bid being placed. You do not have adequate funds to place a new bid Congratulations, your bid is unique and currently the lowest! Your bid is unique but unfortunately not the lowest Your bid is not unique You have already bid this value, please try again As described earlier, there is a cost associated with placing a bid on a given product, which is defined for each auction. Each user account will maintain a balance of funds in their preferred currency. If they bid on a product and do not have adequate funds, their bid request is void and the appropriate feedback is presented. Successful bids, which are defined by outcomes 2, 3 and 4 above, should result in a new bid record and the appropriate debit to be made on the users account. The available funds displayed for the current user should be adjusted accordingly. The last scenario is when the user accidently bids a price which they have already placed on this auction. In this case, the user's bid should be ignored and they should not be charged. In the case where they happen to capture the lowest unique bid, their username should be immediately reflected as the currently winning bidder. Appropriate icons should be display with each of the statements above which are characteristic of success, failure or a near miss. The exact design of these icons should be reviewed when candidates are available, but please consult HYPERLINK "[login to view URL]"http://www.bidster.com. Technically speaking, hitting the “Bid” button should trigger an AJAX call to the server to place the bid and establish the result of the operation. Client side Javascript should be used to modify the page to describe the outcome as detailed above. Bid Records Each time a user bids, a record of their bid needs to be created in the database. As much information as possible should be captured at this stage, to include at least the following details: Auction id Date & time of bid (local to the server) Username of the bidder Amount of the bid The auction id should be the unique identifier to the auction record that captures all aspects of the auction as described above. A database table that captures these bid records should later allow for bid history reports to be constructed for both users as well as the site administrator. Auction Termination An auction is terminated by virtue of it reaching the expiry date. Once an auction has expired, users should no longer be able to bid on that auction. Web pages displaying live auctions should obviously filter out any auction that has not started or is expired. The site should include distinct pages to display closed and upcoming auctions. Once an auction is terminated, the software needs to select a winner. The minimum unique bid wins, regardless of currency. For example, if it turns out that a bid exists of $1.34 and another exists of £1.30 then the latter bid wins even though in dollar terms it exceeds the former. The bid record table in fact simply captures a numeric value (integer, 134 and 130 in this case) and the selection is made on that basis. The users preferred currency only becomes important as far as the cost per bid and their account balance is concerned. If there are no unique bids, the software should find the smallest group of matching bids (I.e starting with 2 then 3 then 4 etc...) and select the first person in that group to bid as the winner. That selection can be made on the basis of the date time field on the bid record. Once an auction has completed, the administrator should be able to see a list of completed auctions in the admin console. From the console, it should be possible to see a complete report of the auction, as well as easily identify the winning bid. Associated with the winning record should be actions to control the work flow for notifying the winner, invoicing, and generating a shipping note.. User Account Once a user has logged in, a My Account link should become visible to them. The account page for the user should allow them to view and amend their details which they provided during registration. Any changes to their email address requires a verification that the address is genuine. In addition, their account balance in their preferred currency should be visible. A link to add funds to the account should be available, and various payment options provided. Paypal & credit card payments should be supported, and SMS will be required at a future date. Additional payment systems will need to be supported, details of which will be provided later. A logged in user should be able to refer a friend once they have made 1 or more bids in any auction (i.e. their account has displayed some level of activity). The refer a friend feature should credit the users account with a configurable amount of money. Their account should only be credited once the friend has signed up and credited their account with some configurable monetary value. Administrators Console Various content management features need to be supported via the administrator console. A list of required features is as follows: Multi language features Site settings (languages, currencies, users, auctions) Configure funding plans (see HYPERLINK "[login to view URL]"[login to view URL]) Banner adverts News letters Email templates to be triggered on certain events List of closed auctions