ONLINE AUCTION SYSTEM

A Synopsis Submitted In partial fulfillment For the award of the Degree of Bachelor of Technology In the Department of Information Technology

Project coordinator: Mr.Anuj khanna

Submitted by: Dharmendra Nikhil katiyar Harsh prakash

Department of Information Technology Krishna Institute of Technology Kanpur 2012-13

CONTENTS
1. Abstract 2. Idea of the project 2.1 Motivation 2.2 Overview 3. Technology used 3.1 1-Tier architecture 3.2 2-Tier architecture 3.3 3-Tier architecture 3.4 n -Tier architecture 4. System analysis and requirement elicitation 5. Architecture of project 6. Software requirements and specification(SRS) 6.1 Introduction 6.1.1 Purpose 6.1.2 Scope 6.1.3 Definition and abbreviation 6.1.4 Overview 6.2 Overall description 6.2.1 Product perspective 6.2.2 User 6.2.3 Interface 6.2.4 User interface through form 6.2.5 Product function 6.2.5.1 Guest 6.2.5.2 User 6.2.5.3 Administrator 6.2.6 Constraint 6.2.7 Apportioning of requirement 6.3 Specific requirement 6.3.1 Feasibility study 6.3.1.1 Operation feasibility 6.3.1.2 Technical feasibility 6.3.1.3 Economic feasibility 6.3.2 Hardware requirement 6.3.3 Software requirement 6.3.4 Requirement control plan 6.3.5 Function requirement 6.3.5.1 Guest 6.3.5.1.2Create new account

6.3.5.1.3Login 6.5.2 Guest and user 6.5.2.1 Search for auction 6.5.2.2 View auction for certain category 6.5.2.3 View auction with certain tag 6.5.2.4 Change language 6.5.2.5 Change currency 6.3.5.3 User 6.3.5.3.1 Logout 6.3.5.3.2 Search a user 6.3.5.3.3 Place an auction 6.3.5.3.4 View placed auction 6.3.5.3.5 Bid on a auction 6.3.5.3.6 View active auction 6.3.5.3.7 Modify account information 6.3.5.3.8 Send a personnel message 6.3.5.3.9 View personnel message 6.3.5.3.10 Delete a personnel message 6.3.5.3.11 Follow in auction 6.3.5.3.12 View followed auction 6.3.5.3.13View transaction 6.3.5.3.14 Pay transaction 6.3.5.4 Administrator 6.3.5.5 Security 6.3.5.6 Other 7. Data flow diagram (DFD) 7.1 level 0 DFD 7.2 level 1 DFD 7.3 level 2 DFD

ABSTRACT
The online auctioning system is a flexible solution for supporting lot- based online auctions. The thesis explains the construction of an auction website. The system has been designed to be highly-scalable and capable of supporting large numbers of bidders in inactive auction. The online auction system lets you easily browse lots and place bids using a secure server. All cost of mailing lots will be paid by the buyer. The objective is to develop a user-friendly auctioning site where any kind of product can be auctioned and provide value added services to the bidders and the sellers. The products will be authenticated and the site provides a safe environment for online users.

MOTIVATION AND OVERVIEW

MOTIVATION:
The previous sections have demonstrated that there is a real and growing demand for wide variety of on-line auctions. As has been shown some of these on-line auctions are simply virtuai parallels to existing traditional auctions whilst others have created unique systems to address new markets- As a result, one can expect. And as research suggests, the on-line auction industry will continue to enjoy substantial or even dynamic growth in years to crone. One may also forecast that various organizations and communities will focus on conducting customized on-line auctions that meet their branding, product and consumer requirements. Therefore, the first objective of this thesis is to try to understand what these user requirements are. Once these requirements have been identified, it will become evident what type of flexibility is needed in on-line auction systems. As a result, the second objective of this thesis is also to present a model of an on-line auction that can be easily configured to meet the trading requirements of a particular organization or community.

OVERVIEW:
The Objective is to develop a user-friendly auctioning site where any kind of product can be auctioned and provide value-added services to the bidders and the sellers. The products will be authenticated and the site provides a safe environment for online users: Secure registration of all users including a personal profile Administrators would authorize the product to auction, set auction dates and Minimum auction amount for that product. Prior to each bid, the users bank or credit account must be authenticated for available balance required for the bid. Complete Search/Site Map of the entire site for easy access. Discussion forums for users to interact with other users to know about the products value and originality. Online Legal Documentation to avoid disputes. Guidance to the users about the same must be available. Rare articles may be withheld by owner on the advice of the administrator to be thrown open in special auctions held by the site so as to increase the bid-values.

TECHNOLOGY SPECIFICATION
1-Client-Server Architecture
Typical client-server systems are based on the 2-tiered architecture, whereby there is a clear separation between the data and the presentation/business logic. These are generally data driven, with the application existing entirely on the client machine while the database server is deployed somewhere in the organization.

2-Tier Architecture
In a traditional 2- Tiered application, the processing load is given to the client PC while the server simply acts as a traffic controller between the application and data. As a result, not only does the application performance suffer due to the limited resources of the PC, but the network traffic tends to increase as well.

3- Tier Architecture
In 3- Tier architecture an application is broken into three separate logical layers, each with a well - defined set of interfaces. The first tier is referred to as the presentation layer and typically consists of graphical user interface of some kind. The middle tier, or business layer, consists of application or business layer and the third layer- the data layer contains the data that is needed for the application. The middle tier is basically the code that the user calls upon to retrieve the desired data. The presentation layer then receives the data and formats it for display. This separation of application logic from the user interface adds enormous flexibility to the design of application. The third tier contains the data that is needed for the application.

n- Tier Architecture
In an n - tier architecture the application logic is divided by function rather than physically. N - Tier architecture then breaks down like this: A user interface that handle the user's interaction with the application; this can be web browser running through a firewall, a heavier desktop application or even a wireless device

 Presentation logic that defines what the user interface displays and how a user's requests are handled- depending on what user interfaces are supported we need to have slightly different versions of the presentation logic to handle the client appropriately. Business logic that models the application's business rules, often through the interaction with the application's data. Interface services that provide additional functionality required by the application components, such as messaging, transactional support etc. The Data layer where the enterprise's data resides.

SYSTEM ANALYSIS
System Analysis is an investigation into a problem and how a new system will solve it. It is the most essential part of the development of a project of a system analysis. System analysis consists of system element, process and technology. To analyze a system, has to study the systems in details. The analyst has to understand the functioning and concept of the system in detail, before design the appropriate computer based system that will meet all the requirements of the existing system. The system analyst has to carry out a customary approach to use the computer for problem solving. System analysis includes the following basic concepts Preliminary investigation Requirements specification Feasibility study Detailed investigation Drawing up of strategies Design and coding Testing and training Implementation The above steps constitute the logical framework for the system analysis. After the preliminary investigation and feasibility study, the scope of the defined and comparable items are set forth and hence detailed investigation is executed. This allows the system analyst to comprehend the full scope of the project. Soon after the implementation of the newly developed system, followed by the training of the users, the system analysis is included.

ARCHITECTURE:

SOFTWARE REQUIREMENT SPECIFICATION

1. INTRODUCTION
An Auction is Latin work which means augment. Auction is a bid, a process of selling; buying and services offered take place. There are several different types of auctions and certain rules exist for each auction. There are variations for an auction which may include minimum price limit, maximum price limit and time limitations etc. Depending upon the auction method bidder can participate remotely or in person. Remote auction include participating through telephone, mail, and internet. Shopping online has widely grown; online auction system is increasing rapidly. Online auction is becoming more and more popular in electronic commerce and hence it should system must increase its quality and security. 1.1 Purpose The purpose of this document is to present an overall description and listing of the functionality of the system behind an online auction website. This document is intended for users of the system including designers, testers, implementation unit and the employer. 1.2 Scope A salesman is the system behind an online auction website. An auction site is a web application where users can buy and sell objects. Users can place auctions or bid on auctions of other users. There are also some social features such as sending messages to users, add a seller to favorite sellers and a rating system for users. 1.3 Definition and Abbreviation SRS: Software Requirements Specification UML: United Modeling Language XHTML: Extensible Hypertext Markup Language HTML: Hypertext Markup Language CSS: Cascading Style Sheets HTTPS: Hypertext Transfer Protocol Secure CAPTCHA: Completely Automated Public Turing test to tell Computers and Humans Apart 1.4 Overview Section 2 describes the general factors that abet the product and its require- mints. This section does not state specific requirements. Instead, it provides a background for those requirements, which are denned in detail in Section 3 of the SRS, and makes them easier to understand. Section 3 contains all of the software requirements, to a level of detail us client to enable designers to design the system to satisfy these requirements, and testers to test that the system satisfies these requirements.

2. OVERALL DESCRIPTION 2.1 products Perspective

The project will make use of a database and a web server that can be accessed with any web browser. There are 4 types of users on the system: guests, rag- interred users, administrators and banned users. Before a user can make use of the full functionality of the site, the user has to register. The user will have to enter some personal information in a form in order to do this. Only users of at least 18 years old will be allowed due to legal reasons. Both guests and users can browse the deferent auctions, but only registered users can bid on auctions or place their own auctions. Users can browse through auctions with categories or tags. Users can also search for a septic auction. Deferent auctions can be created such as English auctions or silent auctions. When a user places an auction, he or she also has to specify payment methods, transport methods, a minimum price, duration for the auction and other general information about the auction. A user can follow an auction. The followed auctions list is a list of auctions that interest the user but on which he or she may not have bid yet. Then when the user wants, he or she can bid on the auction. A user can view all the auctions he or she has bid on in the active auctions list. When a user has won an auction, he or she can pay for the item. This will be done through a transaction. The buyer can pay for the item by choosing on of the payment options the seller has specified. One of these methods is through sales pal. This a personal \bank account" on the site that each user has. Buyers can pay for items with the money on this account and sellers can receive money on their sales pal account. Users can top up their sales pal account, i.e. they transfer money to the account. When the transaction is done, buyers and sell- errs can rate the transaction. Each user will have a rating then which is based on the ratings of their transactions. Users can also contact other users through personal messages. Other sellers can also be added to a favorite sellers list, so that a user can easily check if a seller they like has new auctions. Administrators have some extra functionality; they can manage the users and auctions. Administrators can also retract a bid of a user.

2.2 User Characteristics

The users of the system will be users with deferent levels of technical expertise. Any user with a basic understanding of the internet and auctions should be able to make use of all the available functionality of the system. There are three deferent types of users: Guests: These are visitors of the site which don't have an account yet or aren't logged in. Users: These are users of the site who have an account and are logged in. Administrators: These are special members of the site who manage the site. Banned users: These are users that were removed by an administrator.

2.3 Interfaces

The auction site is accessible from any operating system using a web browser and a connection to the web server running the Salesmen soft- ware No special hardware is required by the end-user The client browser must be W3C XHTML compatible Communication between the users and the auction site will be through HTTP communication using TCP/IP port 80 If an error occurs during a request, the user should receive a clear error message. These errors should also be logged 2.3.1 User interfaces through forms Account information Username (mandatory) Password (mandatory) Password verification (mandatory) E-mail (mandatory) E-mail verification (mandatory) Default Language (default English) CAPTCHA (mandatory) Personal information First Name (mandatory) Last Name (mandatory) Address (optional) Phone number (optional) Date of birth (mandatory, minimum 18 years old) Registration form Account information (mandatory) Personal information (mandatory) Login form Username Password Auction search form Auction name Member search form Member name Place auction form Auction name Transport options Minimum price Duration Auction type Category Tags Other information Bidding form

Maximum over Personal message form Subject Message Rate transaction form Overall rating Message

2.4 Product Functions

2.4.1 Guest Guests can Browse through auctions Request an account Log in 2.4.2 User Users can Browse through auctions through searching Browse through auctions by selecting a category Place auctions Bid on auctions Follow an auction View a transaction Pay for a transaction Rate a transaction View their placed, active and followed auctions Access and modify their account information Contact other users Add a seller to their favorite sellers View and top up their sales pal account 2.4.3 Administrator Administrators can Manage the members Manage the auctions Retract bids from users

2.5 Constraints
The system must work on Linux, and more specifically on Wilma The design should be modular, so extensions and replacements of modules will be simplified The web interface should be simple, attractive and standard (CSS, XHTML) The basic programming language must be Java Only open source software and libraries may be used

2.6 Apportioning of Requirements

In order to have a working prototype available at the end of the first iteration, some functionality has different priorities must have these functionalities should definitely be in the system, preferably after the first iteration. Want to have: These functionalities should be in the system, but could be dropped when there isn't enough time. Nice to have: These functionalities should only be implemented if all the 'must have' and 'want to have' requirements are implemented and there is still some time left.

3. SPECIFIC REQUIREMENT
The primary goal of the system analyst is to understand the requirements of the new system that is to be developed. For that the study of specification of the requirements is very essential. For the development of the new system, a preliminary survey of the existing system will be conducted. Investigation is done whether the up gradation of the system into an application program could solve the problems and eradicate the inefficiency of the existing system.

3.1 feasibility study

The basic idea behind feasibility study is to determine whether the project is feasible or not. Feasibility is conducted to identify a best system that meets all the requirements. This includes an identification, description, an evaluation of the proposed systems and selection of the best system for the job. The requirements of the system are specified with a set of constraints such as system objectives and the description of the out puts. It is then duty of the analyst to evaluate the feasibility of the proposed system to generate the above results. Three key factors are to be considered during the feasibility study. 3.1.1 Operation Feasibility An estimate should be made to determine how much effort and care will go into the developing of the system including the training to be given to the user. Usually, people are reluctant to changes that come in their progression. The computer initialization will certainly affected the turn over, transfer and employee job status. Hence an additional effort is to be made to train and educate the users on the new way of the system. 3.1.2 Technical Feasibility The main consideration is to be given to the study of available resources of the organization where the software is to be implemented. Here the system analyst evaluates the technical merits of the system giving emphasis on the performance, reliability, maintainability and productivity.

By taking the consideration before developing the proposed system, the resources availability of the organization was studied. The organization was immense computer facilities equipped with sophisticated machines and the software hence this technically feasible. 3.1.3 Economic Feasibility Economic feasibility is the most important and frequently used method for evaluating the effectiveness of the proposed system. It is very essential because the main goal of the proposed system is to have economically better result along with increased efficiency. Cost benefit analysis is usually performed for this purpose. It is the comparative study of the cost verses the benefit and savings that are expected from the proposed system. Since the organization is well equipped with the required hard ware, the project was found to be economically.

3.2 Hardware requirements

PROCESSOR CLOCK SPEED SYSTEM BUS RAM HDD MONITOR KEY BOARD MODEM MOUSE FDD : : : : : : : : : : PENTIUM III or Above 800 MHZ 32 BIT 256MB or more 40GB SVGA COLOR 101 KEYS 56 KBPS/ADSL Broadband PS2/ Serial 1.44 MB

3.3 Software requirements

OPERATING SYSTEM

: WINDOWS 2000/XP/2003 server

BROWSER

: INTERNET BROWSER : MS SQL 2008

EXPLORER

5.5

OR

ANY

HTTP

DATABASE LAYER

WEB SERVER

: IIS 5 or above

SERVER SIDE SCRIPTING

: ASP.NET & VB.NET

CLIENT SIDE SCRIPTING

: JAVA SCRIPT

CONNECTION

: ADO.NET

PROTOCOL

: HTTP, SMTP

3.4 Requirements Control Plan

This section describes how the different requirements will be described and how modifications to these requirements will be handled .Each requirement will have a unique identifier which will be used for referencing in the source code, the design, ... Some requirements will only be described by a short description, while others will be described by a use case. Whenever a requirement changes, the change will be noted at the description of the requirement. If a requirement is retired, this will also be noted at the requirement description, together with a reason why the requirement was retired.

3.5 Functional Requirements

3.5.1 Guest 3.5.1.1 Create a new account Requirement ID 1 Priority must have Actor Guest Preconditions User is not logged in Description A guest can create a new account so that he or she can use the Full functionality of the site Path1. Guest selects register 2. Guest fills in registration form 3. Guest submits form 4. System checks form and if valid saves it 5. System sends a confirmation mail Exceptions1. Username is already taken 2. Incorrect information in the registration form 3. Incomplete form Result An account is created for the user 3.5.1.2 Log in Requirement ID 2 Priority must have Actor Guest Preconditions the user is registered on the site, user is not logged in Description If a user is registered but not logged in, he or she can log in to Use the full functionality of the site. Path1. Guest _fills in login form 2. Guest submits form 3. System checks if the form is valid and if so logs the user in 4. System redirects the user to the page he or she was on before the login Exceptions1. Incorrect username and or password 2. Incomplete login form Result The user is logged in

3.5.2 Guest and User

3.5.2.1 Search for an auction Requirement ID 3 Priority must have Actor User or Guest Preconditions User is at the home page

Description Guests and members can search for auctions Path1. Users enters a search term in the search _field 2. User submits the search 3. System redirects the user to a page with all found auctions that match This search query Exceptions Empty search _field Result a page with the found auctions for the search term 3.5.2.2 View auctions of a certain category Requirement ID 4 Priority must have Actor User or Guest Preconditions User is at the home page Description Guests and users can view all the auctions of a certain category Path1. Users select a category from the category list 2. System redirects the user to a page with all the auctions of the selected category Exceptions None Result a page displaying all the auctions of a certain category 3.5.2.3 View auctions with a certain tag Requirement ID 5 Priority Want to have Description Guests and users can view all the auctions with a certain tag 3.5.2.4 Change language Requirement ID 6 Priority must have Description Guests and users can change the language of the website to one Of the available languages 3.5.2.5 Change currency Requirement ID 7 Priority Nice to have Description Guests and users can change the currency in which auctions are Displayed

3.5.3 User
3.5.3.1 Log out Requirement ID 8 Priority must have Actor User Preconditions User is logged in Description Members who are logged in can log out Path1. User selects log out 2. System logs the user out 3. System redirects the user to the site's homepage Exceptions None Result The user is logged out

3.5.3.2 Search a user Requirement ID 9 Priority Want to have Actor User Preconditions User is at advanced search page Description Members can search for other members Path1. User enters search term in search user field 2. User submits search 3. System redirects the user to page containing all users corresponding To that search query Exceptions Incorrect or incomplete form Result a page displaying the found members for the search term 3.5.3.3 Place an auction Requirement ID 10 Priority must have Actor User Preconditions User is logged in. User is at home page or user home Description Members of the site can create a new auction on which other members can bid Path1. User selects place auction 2. User fills in new auction form 3. User submits the form 4. System checks the form and if valid creates the auction Exceptions Incorrect information in the form, incomplete form Result Auction is placed 3.5.3.4 View placed auctions Requirement ID 11 Priority Want to have Actor User Preconditions User is logged in. User is at control panel Description Users can view the auctions they have placed Path1. User selects placed auctions 2. System redirects user to user's placed auctions page Exceptions None Result The user views the auctions he or she has placed 3.5.3.5 Bid on an auction Requirement ID 12 Priority must have Actor User Preconditions1. User is logged in 2. User is on an auction page 3. Auction is not of the user Description Members can bid on auctions of other members Path1. User select bid 2. User _fills in bidding form 3. User submits form 4. System checks form and if valid places the bid Exceptions Wrong bid value in the form, incomplete form

Result The bid is placed on the auction 3.5.3.6 View active auctions Requirement ID 13 Priority Want to have Actor User Preconditions User is logged in. User is at control panel Description Users can view the auctions they have bid on Path1. User selects active auctions 2. System redirects user to user's active auctions page Exceptions None Result The user can view the auctions he or she had bid on 3.5.3.7 Modify account information Requirement ID 14 Priority must have Actor User Preconditions User is logged in. User is at control panel Description Members can modify their account information Path1. User selects modify account 2. User changes account information form 3. User submits the form 4. System checks the form and if valid, makes the changes Exceptions Incorrect information, incomplete form Result The account information of the user is changed 3.5.3.8 Send a personal message Requirement ID 15 Priority Nice to have Actor User Preconditions User is logged in. User is at user page Description Users can send messages to other users Path1. User selects send message 2. User _fills in personal message form 3. User submits the form 4. System checks the form and if valid, sends the message Exceptions Incorrect information, incomplete form, users send message to him or herself Result a message is sent to another user 3.5.3.9 View personal messages Requirement ID 16 Priority Nice to have Actor User Preconditions User is logged in. User is at control panel Description Users can view the personal messages Path1 User selects personal messages 2. System redirects the user the user's personal messages page Exceptions None Result The user will view a page with his or her personal messages

3.5.3.10 Delete a personal message Requirement ID 17 Priority Nice to have Actor User Preconditions User is logged in. User is at personal messages page Description Users can delete personal messages they have received Path1. User selects a message 2. User selects delete message 3. System deletes the message Exceptions None Result a message is deleted from the user's inbox 3.5.3.11 Follow an auction Requirement ID 18 Priority Want to have Actor User Preconditions User is logged in. User is at auction page Description Users can follow an auction, i.e. they put it in their following list Path1. User selects follow auction 2. System adds auction to the users followed auctions list Exceptions None Result An auction is added to the user's follow auctions list 3.5.3.12 View followed auctions Requirement ID 19 Priority Want to have Actor User Preconditions User is logged in. User is at control panel Description Users can view the auctions they are following Path1. User selects followed auctions 2. System redirects user to user's followed auctions page Exceptions None Result The user can view the auctions he or she is following 3.5.3.13 View Transaction Requirement ID 20 Priority Want to have Actor User Preconditions User is logged in. User is at auction page. User bought the item. Description Users can view the transaction of an item they bought Path1. User selects view transaction 2. System forwards user to transaction page of auction Exceptions None Result The user views the transaction of the auction 3.5.3.14 Pay transaction Requirement ID 21 Priority Want to have Actor User Preconditions User is logged in. User is at transaction page

Description Users can pay auctions on the transaction page of an auction Path1. User selects pay item 2. User selects a payment method 3. User performs the payment 4. System notifies the seller that the auction is paid for Exceptions Incorrect information, incomplete form Result The transaction is paid for 3.5.3.15 Rate transaction Requirement ID 22 Priority Want to have Actor User Preconditions User is logged in. User is at transaction page, user paid trans-action Description Users can send rate a transaction after it is paid Path1. User selects rate transaction 2. User _fills in rate transaction form 3. User submits the form 4. System checks the form and if valid, rates the transaction 5. System updates the ratings of the user Exceptions Incorrect information, incomplete form Result The transaction is rated 3.5.3.16 Add seller to favorites Requirement ID 23 Priority Nice to have Actor User Preconditions User is logged in. User is at user page Description Users can add a seller to their favorites so they can their auctions easily Path1. User selects add seller to favorites 2. System adds the seller to the favorite seller list of the user Exceptions Seller is already in the favorite seller list Result The seller is added to the favorite seller list of the user 3.5.3.17 View favorite sellers Requirement ID 24 Priority Nice to have Actor User Preconditions User is logged in. User is at control panel Description Users can view his or her favorite sellers Path1. User selects favorite sellers 2. System redirects user to user's favorite sellers page Exceptions None Result The user will view a page with his or her favorite sellers 3.5.3.18 Delete a favorite seller Requirement ID 25 Priority Nice to have Actor User Preconditions User is logged in. User is at control panel Description Users can remove a seller from his or her favorite sellers list

Path1. User selects a seller from the list 2. User selects delete seller 3. System removes the selected user from the list Exceptions None Result a seller is removed from user's favorite sellers list 3.5.3.19 View sales pal Requirement ID 26 Priority Want to have Actor User Preconditions User is logged in. User is at control panel Description Users can view their own personal \bank account" on the site Path1. User selects view sales pal 2. System redirects the user to the user's sales pal page Exceptions None Result The user is on his or her sales pal page 3.5.3.20 Top up sales pal Requirement ID 27 Priority Want to have Actor User Preconditions User is logged in. User is at sales pal page Description Users can add more money on their sales pal account Path1. User selects top up sales pal 2. Users _fills in top up sales pal form 3. System checks the form and if valid tops up the account Exceptions Incorrect or incomplete form Result the user tops up his or her sales pal account 3.5.3.21 View recommended auctions Requirement ID 28 Priority Nice to have Actor User Preconditions User is logged in. User is at control panel Description Users can view recommended auctions for him or her. This list Is generated through tags and categories the user frequently uses Path1. User selects view recommendations 2. System redirects user to user's recommended auctions page Exceptions None Result The user views a page with recommended auctions for the user 3.5.3.22 View buyer's assistant Requirement ID 29 Priority Want to have Description A user can check the auctions the buyer's assistant has found for his or her preferences 3.5.3.23 Comment on an auction Requirement ID 38 Priority Want to have

Description A user can comment on an auction. This comment can be viewed by anyone viewing the auction page

3.5.4 Administrator
3.5.4.1 Remove a user Requirement ID 30 Priority must have Actor Administrator Preconditions User is at control panel Description User selects manages users and selects a user from the users list. After the user is selected, remove user is selected. Exceptions None Result a user is removed from the system 3.5.4.2 Remove an auction Requirement ID 31 Priority must have Actor Administrator Preconditions User is at control panel Description User selects manages auctions and selects an auction from the auction list. After the auction is selected, manage auction is selected. Exceptions None Result Auction is removed 3.5.4.3 Retract bid Requirement ID 32 Priority Want to have Description An administrator can retract a bid from a user when that user has e.g. made a high bid because of a typo

3.5.5 Security
3.5.5.1 Encrypted password Requirement ID 33 Priority must have Description Password must be stored encrypted 3.5.5.2 CAPTCHA Requirement ID 34 Priority must have Description when a user registers, he or she has to fill in a CAPTCHA 3.5.5.3 Limited login attempts Requirement ID 35 Priority must have Description a guest may only try to try to log in with a wrong password a fixed number of times 3.5.5.4 Extra site for banned users Requirement ID 39 Priority Nice to have

Description When a banned user visits the site, he or she will view a special site for banned users 3.5.5.5 Cookies Requirement ID 40 Priority Want to have Description Cookies can be created for the user to let the user log in automatically

3.5.6 Other
3.5.6.1 Basic e-mail notification Requirement ID 36 Priority Want to have Description User can receive an e-mail when he or she has won an auction, when the item is shipped, when an auction is paid for 3.5.6.2 Advanced e-mail notification Requirement ID 37 Priority Nice to have Description User can receive an e-mail when he or she is overbid, when an auction is almost done, with recommended auctions for the user

DATA FLOW DIAGRAM (DFD)

Level 0 DFD

Bidder s

Level 1 DFD for admin

category

admin

login

UI displaying set of operation

items

General Informatio n Bidding informati on

Level 2 DFD for admin

UI interface

Input stage

Add categ ory

Data base

output stage