http://application.em-dmkm.eu/logind http://www.em-dmkm.eu/Application/91-EN-Application_procedure http://www.scholarshipstimes.

com/2012/12/26/2013-2015-scholarships-for-european-masters-course/ Mr Solomon DEMISSIE, You have received this message because you have requested to change your password. You may now authenticate with your email and password: 3930 An Auction Application Chapter 1 INTRODUCTION

1.1 Background of the Study Internet auctions appeared on the scene in the mid 1990s, and quickly became one of the most successful applications of electronic commerce. EBay, the premier consumer-to-consumer (C2C) Internet auction site, is generally held up as an exemplar for the industry. However, it is widely predicted that the potential transaction volume in business-to-business (B2B) auctions will be much greater than in the C2C channel (Keenan, 2000; Rosenthal, 2002).

In the B2B marketplace, auctions were initially pressed into service as tools to dispense with excess inventory. The current wave of B2B integration represents a much deeper integration of auction technology into the daily operations of many businesses. In particular, companies are using auctions in many procurement situations in an effort to extract better prices from their suppliers. Auction systems are a major component of the electronic marketplace that allow users at any site to sell and buy products. The sellers set up auctions for their products while the purchaser who bids the highest amount wins the right to purchase the product in an auction.

Auction systems have three distinct sets of users: the bidders, the auction initiator, and the auction system administrator. Each class of users requires different core and complementary features of an auction system. Note that we do not treat sellers and buyers separately; in the general case they are both bidders and have the same needs. On most consumer-to-consumer sites, the seller is the auction initiator, and places his one and only bid, to establish the reserve price, during the creation of the auction, if at all. The auction system administrator is the person (or group of people) who installs, configures, and maintains the auction site.

Introduction In a traditional auction business, the merchandise has to be physically moved to a central location and then shipped to the bidder from, if it were sold. If the item were not sold, then the seller has to either take the merchandise back, or stock it at the central location for a bid at a later time. This is a great overhead for both the seller as well as the bid organizer. The costs ultimately roll into the bidding price. Because of this overhead, only costly items are placed for bidding. The bidders have to be at the location to bid. The bidding duration is typically limited to a few minutes.

A web-based application reduces the overheads associated with a traditional auction system. The merchandise need not be moved to the central location. There is no physical presence required by the bidders, sellers or the organizers. Because of low overhead, cheaper items can be placed on bid and the bid duration can be much longer than the traditional auction model. Thus the buyers base, seller base, and the amount of merchandise increases exponentially. This is a revolution. ANALYSIS AND DESIGN OF THE PROPOSED SYSTEM 4.1 Introduction This chapter namely system analysis and design is created to solve problems of existing system, it should describe the requirements specification, functional requirement, non functional requirement, block diagram and entity relationship diagram. 4.2 Requirement specifications 4.2.1 Functional Requirements In software engineering, a functional requirement defines a function of a software system or its component can be capturing the intended behavior of the system. This behavior may be expressed as Services, tasks or functions the system is required to perform. This part of the requirements document states in detailed and precise manner what the application will do. ---------------------Non Functional Requirements Non functional requirements are those characteristics that cannot be expressed in this project. The system should be usable, reliable and should be available all the time except for maintenance. The system should show accurate information (no stale bids etc) The system should support concurrent users System and Database Administration tools will not be provided.

The response time should be reasonable Use Case Diagram The purpose of Use case diagram is that it shows the interaction between external actors and actions performed within a system. Use case diagram is developed in the analysis phase of the object oriented system development life cycle. It is done in the early stages of system development to help developers gain a clear understanding of the functional requirement of the system, without worrying about how those requirements will be implemented. In object development orientation, use cases are used to find objects and often generate new requirements as the system is analyzed and the design takes shape. It serves as the foundation for developing system test cases. Use Case diagram allows users to participate in a way that is seldom possible using the abstractions of Class diagram alone and helps the analyst get to grip with specific user needs before analyzing the internal mechanics of a system. Use cases provide a basis for early prototyping and readily identifiable units for incremental delivery. They also provide a means of traceability for functional requirements upstream in the process and for constructing test plans downstream in the process. --------------------The purpose of a class diagram is to depict the classes within a model. In an object oriented application, classes have attributes, operations and relationships with other classes. Class diagrams are useful throughout the software lifecycle for a variety of team members such as analysts, business modelers, developers and testers.