SYSTEM REQUIRMENT SPECIFICATIONS FOR EBIDDING PURPOSE OF THE SYSTEM Electronic Tendering is carrying out the traditional tendering

process in an electronic form, using the internet. The tendering process is a key business process that helps businesses find a suitable contractor. In the building and construction industries, clients invite tenderers to submit an estimate of prices, detailing the costs associated with completing a building. In this way, the client can base their decision on the result of the tenders to select the most suitable contractor. Currently in Hong Kong, many of such tendering processes are still mainly manual and paper based. The tenderers need to collect the tender s booklet, price it, and bring it back to the client s office before the deadline. In this paper, we present a design and implementation of an e!tendering system by using "eb services for the automation of such tendering processes. EXISTING SYSTEM: The price of the product on auction increases with every incremental bid. The price increases as per the minimum bid increment set by the seller. The seller must sell the item to the highest bidder at the close of the auction. #or e$ample, if a seller has put up product % for sale with a reserve price of &s.'( and five buyers bid for it with the highest bid coming in from buyer ) who bids &s.'*, the product is sold to ) for &s.'*. This is an auction where the number of units of a particular product for sale is more than one. This simply means that a number of identical products have been put up for sale by the seller. In an auction like this, there will obviously be more than one winner. )uyers can also bid for more that one unit of that product. %t the end of the auction all the bidders pay the same price ! the lowest winning

bid amount +sub,ect to the reserve price being met- for the product. This is a perfect auction type for those who wish to sell many units of the same product. Here is how it works. The /eller starts by listing a minimum price or starting bid for a product and the 0uantity or number of units for sale. )idders specify both a bid price and the 0uantity they wish to buy. %ll winning bidders pay the same price per item ! the lowest successful bid. If there are more buyers than items, the earliest successful bids get the goods. Higher bidders are more likely to get the 0uantity they asked for. )idders can refuse partial 0uantity. #or e$ample, if you place a bid for '( items and only 1 are available after the auction, you are not obliged or bound to buy any of them. E$ample Case. % seller places '( pens on auction at &e.' each. '( people bid &e. ' for one pen each. In this case, all '( bidders will win a pen for &s. '. However if, let s say, five people bid &s. '.*2 for a pen each and '( others bid &e. '. The minimum bid for the pen will be raised to &s. '.*2 because demand e$ceeds supply. )ecause the &s. '.*2 bidders bid higher than the &e. ' bidders, they will be guaranteed a pen. The other 2 pens will go to the earliest &e. ' bidders. The final price for each pen will be &e. ' +even though some participants placed a higher bid of &s. '.*2- since all winning bidders pay the same price ! which is the lowest successful bid. In this format at the time of allocation of the 0uantities the preference is given to the buyer who puts in the highest bid and he3she will get the 0uantity he bid for and this flows progressively down the bidding value stream. PROPOSED SYSTEM The general description gives an 4e$ecutive overview4 and is very client!oriented. It e$pounds on the functional and data re0uirements of the application. It also lists the limitations, assumptions and dependencies of the application. /ection 5.(, the specific re0uirements section, includes the developers6 technical view of the client s e$pectation of the application. It also touches on

the performance and 0uality re0uirements of the application and provides a solid definition of the interface

2.3 STUDY OF THE SYSTEM In the fle$ibility of the uses the interface has been developed a graphics concept in mind, associated through a browser interface. The 78I6/ at the top level have been categori9ed as '. *. %dministrative user interface The operational or generic user interface

The administrative user interface concentrates on the consistent information that is practically, part of the organi9ational activities and which needs proper authentication for the data collection. The interfaces help the administrations with all the transactional states like :ata insertion, :ata deletion and :ata updating along with the e$tensive data search capabilities. The operational or generic user interface helps the users upon the system in transactions through the e$isting data and re0uired services. The operational user interface also helps the ordinary users in managing their own information helps the ordinary users in managing their own information in a customi9ed manner as per the assisted fle$ibilities Modules The pro,ect is mainly divided into ; modules. !. Ad"#$#s%&'%o& This administrator will maintain all the master information like Items Information, suppliers6 information, Employee information.

2!. E"(lo)ee He is going to prepare the indent for the re0uired product to the purchase department, and also he checks indent status. 3!. Pu&*+'se De('&%"e$% :isplaying indent information from different departments. <reparation of tenders for the indents, Invitation to the supplier for the tender ,!. Su((l#e& /upplier is going to bid the amount for tender with in the stipulated time, and will know the final status of the tender once it is closed.

SD-C METHODO-OGY USED =b,ect =riented %nalysis and :esign +==%:- is the model, chosen to design and develop the proposed system. #eatures of ==%:. It users =b,ects as building blocks of the application rather functions %ll ob,ects can be represented graphically including the relation between them. %ll Key <articipants in the system will be represented as actors and the actions done by them will be represented as use cases.

% typical use case is nothing bug a systematic flow of series of events which can be well described using se0uence diagrams and each event can be described diagrammatically by %ctivity as well as state chart diagrams.

/o the entire system can be well described using ==%: model, hence this model is chosen as /:>C model.

INPUT DESIGN Input design is a part of overall system design. during the input design is as given below. To produce a cost!effective method of input. To achieve the highest possible level of accuracy. To ensure that the input is acceptable and understood by the user. The main ob,ective

INPUT STAGES: The main input stages before the information gets stored in the database media. :ata recording :ata transcription :ata conversion :ata verification :ata control :ata transmission :ata validation :ata correction OUTPUT DESIGN =utputs from computer systems are re0uired primarily to

communicate the results of processing to users. They are also used to

provide a permanent copy of the results for later consultation. The various types of outputs in general are. E$ternal =utputs, whose destination is outside the organi9ation. Internal =utputs whose destination is with in organi9ation and they are the 8ser6s main interface with the computer. =perational outputs whose use is purely with in the computer department. Interface outputs, which involve the user in communicating directly with The outputs were needed to be generated as a hard copy and as well as 0ueries to be viewed on the screen. Keeping in view these The standard outputs, the format for the output is taken from the outputs, which are currently being obtained after manual processing. printer is to be used as output media for hard copies. ARCHITECTURA- F-O. A&*+#%e*%u&e Flo/ The current application is being developed by taking the 5!tier architecture as a prototype. In a three!tier architecture +also known as a multi!tier architecture-, there are three or more interacting tiers, each with its own specific responsibilities.

T+&ee0T#e& A&*+#%e*%u&e Tier '. the client contains the presentation logic, including simple control and user input validation. This application is also known as a thin client. The client interface is developed using %/<.?et /erver Controls and HT@> controls in some occasions Tier *. the middle tier is also known as the application server, which provides the business processes logic and the data access. The business logic3 business rules can be written either with CA.?et or B).?et languages. These business runes will be deployed as :>>6s in II/ web server.

Tier 5. the data server provides the business data. @/!/C> server acts as Tier!5, which is the database layer.

These are some of the advantages of three!tier architecture.

It is easier to modify or replace any tier without affecting the other tiers. /eparating the application and database functionality means better load balancing.

%de0uate security policies can be enforced within the server tiers without hindering the clients.

The proposed system can be designed perfectly with the three tier model, as all layers are perfectly getting set as part of the pro,ect. In the future, while e$panding the system, in order to implement integration touch points and to provide enhanced user interfaces, the n!tier architecture can be used.

CONTEXT -E1E- DFD

FEASIBI-ITY STUDY: <reliminary investigation e$amine pro,ect feasibility, the

likelihood the system will be useful to the organi9ation. The main ob,ective of the feasibility study is to test the Technical, =perational and Economical feasibility for adding new modules and debugging old running system. %ll system is feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary investigation.

Technical #easibility =peration #easibility Economical #easibility

Te*+$#*'l Fe's#2#l#%) The technical issue usually raised during the feasibility stage of the investigation includes the following. :oes the necessary technology e$ist to do what is suggestedD :o the proposed e0uipments have the technical capacity to hold the data re0uired to use the new systemD "ill the proposed system provide ade0uate response to

in0uiries, regardless of the number or location of usersD Can the system be upgraded if developedD %re there technical guarantees of accuracy, reliability, ease of access and data securityD Earlier no system e$isted to cater to the needs of E/ecure Infrastructure Implementation /ystem6. The current system developed is technically feasible. It is a web based user interface for audit workflow at ?IC!C/:. Thus it provides an easy access to the users. The database6s purpose is to create, establish and maintain a workflow among various entities in order to facilitate all concerned users in their various capacities or roles. <ermission to the users would be granted based on the roles specified. Therefore, it provides the technical guarantee of accuracy, reliability and security. The software and hard re0uirements for the development of this pro,ect are not many and are already available in!house at ?IC or are available as free as open source. The work for the pro,ect is done with the current e0uipment and e$isting software technology. ?ecessary bandwidth e$ists for

providing a fast feedback to the users irrespective of the number of users using the system. O(e&'%#o$'l Fe's#2#l#%) <roposed pro,ects are beneficial only if they can be turned out into information system. That will meet the organi9ation6s operating re0uirements. =perational feasibility aspects of the pro,ect are to be taken as an important part of the pro,ect implementation. /ome of the important issues raised are to test the operational feasibility of a pro,ect includes the following. ! Is there sufficient support for the management from the usersD "ill the system be used and work properly if it is being developed and implementedD "ill there be any resistance from the user that will undermine the possible application benefitsD This system is targeted to be in accordance with the above!mentioned issues. )eforehand, the management issues and user re0uirements have been taken into consideration. /o there is no 0uestion of resistance from the users that can undermine the possible application benefits. The well!planned design would ensure the optimal utili9ation of the computer resources and would help in the improvement of performance status. E*o$o"#* Fe's#2#l#%) % system can be developed technically and that will be used if installed must still be a good investment for the organi9ation. In the economical feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. #inancial

benefits must e0ual or e$ceed the costs. The system is economically feasible. It does not re0uire any addition hardware or software. /ince the interface for this system is developed using the e$isting resources and technologies available at ?IC, There is nominal e$penditure and economical feasibility for certain.