DEBRE TABOR UNIVERSIY

FACULITY OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE

PROJECT TITLE: - AUCTION MANAGEMENT SYSTEM FOR DEBRE

TABOR UNIVERSITY

S_NAME ID

ALEMAYEHU MATEBIE…………………………………….COM(R) 013/11

MEBRATU SITOTEW………………………………………..COM(R) 114/11

MEQUANINT YIRGA………………………………………..COM(R) 121/11

YASHIWAS DERSO…………………………………………..COM(R) 165/11

YOHANES MEKONEN………………………………………COM(R) (R) 173/11

SUBMISSION DATE: -

Submitted to:
Ins.G/Rufael

Debre tabor, Ethiopia

 CHAPTER ONE: INTRODUCTION
1.1. Background of the Project
The main concern of this project is studying auction system, which is widely used procurement
method in our country in general and in our institute in particular. Auction is a method of
procurement that could be used for National Competitive Bidding and International Competitive
Bidding. In the current open auction system, there exist some problem and also bidders can’t
have satisfaction in the current system. The current auction system, bidders must attend specific
place; otherwise, they can't participate for the bid. So, our team aim to develop web based
auction management system that avoid problems both bidders and organizations might face.
Debre Tabor University was established in 2001 EC by Ethiopian government and it starts
learning process in 2004 EC.it is located at 4 km far from Debre Tabor town in Amhara region
of Ethiopia, and it is one of the third generation from 44 Universities in Ethiopia The University
has one main campuses, it consists of faculty of technology, faculty of Natural and
computational Science, faculty of Agriculture and environmental science, College of medicine
and Health Science, faculty of Business and Economics, faculty of Social Science and
Humanities.

1.2. Motivation
Our team select web-based auction management system for Debre Tabor university. Auction is a
method of procurement that takes place in day today life. In the current open auction system,
there exist some problem and also bidders can’t have satisfaction in the current system. The
current bidding system, bidders must attend specific place; otherwise, they can't participate for
the bid and also disable person cannot participate for the bid because of distance. So our team
motivated to develop web based auction management system that avoid problems both bidders
and organizations might face.
1.3. Statements of the Problem
Based on the current system DTU procurement team prepares a lot of open auction notice or
advertisements to buy different service, goods, work and consultancy service. During this
transaction there are many problems both buyer and supplier face.

Buyer faces many problems during auction process.

 The first problem is many qualified bidders can`t participates in the tender because of
suppliers can`t see or hear the advertisement that distributed in the form of newspaper or
in media.
 The second problem time wasting that means it takes one or more days to reach bid
documents to federal press distribute through media or newspaper, to register each
suppliers within their full information in specified day, when auction opened suppliers
cannot reach in specified time in auction this results late the bid and buyer can`t get items
want.
 The third problem is that maximize material cost (resource consuming) such as paper,
printer and others.
 The fourth problem is losing of data or information because of data handling method of
existing system is manual or paper based.

Supplier faces many problems during tender process.

 The first problem are cannot get full information about auction; it might
not view all advertisement or view after left their closed days.
 The second problem is maximizing transport cost. This means if supplier
lives far away from auction place it waste high cost to register in the
auction.
 The third problem is personal case (most likely disable person). Disable
can’t participate in the bid because of distance.

1.4. Objective of the Project

1.4.1. General Objective
To develop web-based auction management system for Debre Tabor University.
1.4.2. Specific Objectives
In order to achieving the general objective, the following specific objectives are required:

 Perform requirement analysis to find out system functional and

non-functional requirement.
 Study the existing system and find out the problem.
 Design the new system based on the identified requirements.
 Implement the new system based on the new system design.
 Design the database for storing auction information using MySQL.
 Test the functionality of the system

1.5. Scope of the Project

The scope of our project plans and targets in developing and implementing web-based auction
management system to replace and solve the problems of the existing system.

1.5.1. Scope out: -

• Our system cannot transfer of item done automated.

• The system does not include payment.

1.6. Significance of the Project

This project is focuses on open auction system. It will cover different activities, such as
suppliers can be registered to the auction in everywhere, system display the list of registered
supplier in the database, give service without any time constraint, it enable large number of
suppliers can participate.

 The significance of the system in the supplier side is

• Minimizing wastage of time and energy. Because suppliers can easily view the notice by
clicking view notice option in the system without going to bid place.
• View winner
• Easily registered to the auction.
• Reducing transport cost
 The significance of the system in the buyer side
 • Reduce the workload of employee.

• Reduce resource consumption.

• Reduce redundancy and losing of data, because it will be computerized

form of data handling method.

• Access of information will be easier, faster, and well-organized way.

1.7. Feasibility Study

Feasibility study is conducted to evaluate the feasibility of the project in various aspects. For our
Project we have done the feasibility study and our project is feasible in almost all aspects. The
Following sub chapters are brief description of each aspects of feasibility study.

1.7.1. Operational Feasibility

When the system is applied to operation, we are fully confident that the system will be
operationally Feasible because as we will develop the system that is easy to use and maintain.
With a little training anyone will be able to understand and will be able to handle with the system
easily.
1.7.2. Technical Feasibility

The system is going to be developed by following the php language, html, java script, MySQL
and other language and we have the ability to develop this system without any difficulty since
the team has studied the required methodologies and tools. So the system will be technically
feasible and the system will have GUI interface and very less user-training is required to learn it.

1.7.3. Economic feasibility

The proposed system is economically feasible because: -
 The system requires very less human power.
 The system is going to be computerized system, there is reduction cost for material that
used for manual operation such as cost of paper and pen, save time and make comfortable
working environment for the users.
Tangible benefits
Our new system gives tangible benefits that can be estimated in terms of money which means the
benefit is real or actual rather than imaginary or visionary. For example, the system provides cost
reduction /avoidance such as mobile card, paper, error reduction, increased flexibility,
facilitating the activities, reducing materials consumption.
Intangible benefits
The new system gives intangible benefits that cannot be estimated in money such as:-
• increasing work processing efficiency,
• Moral satisfaction for developers, the purchasing workers and the user.
• Increase security

1.7.4. Political Feasibility

In terms of political feasibility, the system we develop will not violate any laws, rules, and
regulations of the government. Instead it supports strategies of the government in creating
better market opportunities for the people of the country.
1.8. Methodology of the Project
1.8.1. Data Source

The main data source of this project is study the existing system of action activity that takes
place in DTU. For the development of the proposed system the team uses different data sources
such as books, internet and other source as required.

1.8.2. Fact Finding Techniques

1.8.2.1. Interview
The project team use direct interview techniques to get information about current flow of work
by interviewing key workers such as purchasing directorate, procurement approval committee as
they told as the system uses manual way, to store auction information. Generally they have no
computerized system to perform their task.

This information will help us to identify the main actors that participate on the auction and also
about the work flow of the existing system. So, we will analyze information’s of the bid system
that apply in DTU.
 1.8.2.2. Document analysis

To understand the existing system, we can collect more information by referring documents and
other reading materials about auction system.

1.8.3. Development Tools and Techniques for the Project

For the purpose of the development of this project, the team members used different software,
hardware tools and programming language which can be identified as hardware requirement and
software requirement.

1.8.3.1 Hardware Requirement

This project used the following hardware requirements. The following hardware requirements
are needed at minimum to develop the project

• Laptop: used to write proposal, documentation, develop the system.

• Flash: to store data

• Printer: to print documentations

1.8.3.2. Software Requirement

Software requirements are descriptions of the services that a software system must provide and
the constraints under which it must operate. Since, there are many software tools for developing
any projects. This system or project also used much software from start to end.

• XAMPP server: to provide MySQL for creating and manipulating

databases and PHP to design user interface from the front end of software.
• Microsoft office 2013: to write on any necessary documents about the project.
• Web Browser:-is language interpreter that used to understand client side application.
• Anti-Virus Software: -used to keep secure, scan, fix flash disk and to
prevent data destruction and corruption
• E-draw-Max: to design sequence diagram, class diagram, activity diagram
and use case diagram of our system.
 1.8.3.3 Programming Language

Now a day is many programming languages are used to develop projects. but, we select the PHP
programming language due to the following reason: -

 PHP: Hypertext Preprocessor is a widely used, general-purpose scripting

language that was originally designed for web development to produce
dynamic web pages.
 Easy to understand-when compared with other scripting languages, PHP
can be understood easily because it has simple techniques and features.
 Integration-it is easy to integrate popular web applications using this
scripting language.
 Database tool: MYSQL
 Because of its unique storage engine, architecture MYSQL performance is
very high.
 We are familiar with MYSQL, so we select it to manage database system.
 Generally, PHP is clear and easy to understand, OS independent, easier to
fix problems, operates much faster than other scripting languages, easy to
learn and open source.

Additional Programming Languages:-

 HTML:-to display content.

 Java script: for client side scripting (interpreted by the browser).

1.8.4 Software Process Model

Our team to develop this proposed auction management system we choose Iterative
process model approach, because of selecting this approach from other approaches its
projects the development process in cyclic manner repeating every step after every cycle
of software development cycle. Therefore this model is used to discover errors easily. In
this development model the software is first developed on every small scale and all the
steps are followed which are taken consideration then every next and added to the
software. and this model is easier to manage and perform the development process. It has
 also the ability to back up the system. This means the developers got comment from
users, friends and from ours until the team have finished the project.

Figure1. 1iterative process model

1.9 Roles and Responsibilities
Table 1. 1 Role and responsibilities

No Name Role and responsibilities

1 Yashiwas derso All activities of the project

2 Yohanes mekonen

3 Mebiratu sitotew

4 Mequanint yirega

5 Alemayehu matebie
 1.10. Schedule Feasibility
Within the time duration, we will identify the activities of the project in order to accomplish the
project objective within their schedule requirement which is on the table below.

Table 1. 2 Schedule Feasibility

Activity Time

Feb Feb Feb March April June

12/06/2 17/06/2014
014 – -feb 26/06/2014 1/07/2014 13/08/2014 10/10/2

Feb 25/06/2014 014

-march -April -June
16/06/2
-
014 30/07/2014 12/08/2014 9/10/2014 June20/
10/201
4

Requirement
gathering and
analysis

Proposal

Documentation

Design
Implementation and
coding

Testing

CHAPTER TWO: STUDY OF THE EXISTING SYSTEM

2.1. Introduction
In this chapter we will describes the existing system, Major Functions/Activities in the Existing
System, the business rule identification, existing infrastructure, and proposed system.
Now let us start from describing the existing system and identify the compliant for existing
system that can be solved by proposed system.
2.2. Existing System Description

In the existing system auction are takes place in traditional way or a person must be there
physically to participate on the open auction system. A traditional open auction is performed
manually that bidders must be present physically to submit bids document, to view winner and
also make agreement to the institute. After approving bid document prepared by procurement
team send to press and distribute through media or newspaper in order to enable suppliers get
information about the notice. Institute buys item by bid different suppliers who have submit bids
document and select winner by assess their bids document based on appropriate price and quality
of item. Traditionally, there are eight participants in the auction:

• Suppliers

• Procurement team

• Procurement approving committee

2.3 Service provided

Describing the service provided of the existing system to identify problems in the existing
system, to provide alternative solutions for the problem identified, to select the feasible solution
among the alternative solution and finally to decide the functional requirements of the proposed
new system.

 Bidding document and notice preparing

Procurement team prepare bidding document and notice. The bidding document includes
description about the instruction for submission and preparation of bids, information about the
final date recipient of the submission of bids, the period in which the bid remain in force, general
and specific condition of contract and description about required items.
 Distribution of notice
After procurement team prepares bidding document and notice, send notice to press. Then press
distributes the notice either in newspaper or in media.
 Submission and recipient of bids
Based on bidding document prepared by procurement team candidates/suppliers submit the bids
document in writing, signed and in a sealed envelope to procurement team. Procurement team
after receiving the bids put in to bid box and locked it up to opening of the bid.
 Notification of winner and signing contract
Prior to the expiry of the period of bid validity, procurement approving committee shall notify
the winner that its bid has been accepted. The notification of winner shall specify the time within
which the contract must be signed.
 Rejection of bid
Institute specifically procurement team may one or more of the following reasons for rejecting
bid in whole or in part.
 There is a proof of error in procurement proceeding which could affect the
outcome of the bid.
 Bidders fail to meet the minimum criteria set forth in bid document.
 The price offered by the winner exceeds the budgetary allocation made for
procurement and can’t make up for deficiency from other source.
 2.4 users.

Players in the Existing System

 Procurement team: procurement team prepares bidding document only for procurement request
which are already approved by the institute of higher official and distribute the notice.
 Procurement approving committee: The task of procurement approving committee is reviewing
and approving orders.
 Supplier: is a customer that supplier of the item based on document prepared by procurement team.

2.5 Business rule identification

A business rule is a statement that defines or constrains some aspect of the business. It is
intended to assert business structure or to control or influence the behavior of the business. The
business rule regarding to suppliers and buyer are the following:

Supplier:

 Winner supplier must made advance payment (10%) of the price during
contract.
 Supplier must submit bids document along with bid security (2%) of price.
 Winner supplier must made contract with the institute and admit the items in
specified day.
Buyer:
 Extend the deadline of the tender when there is no participant within the specified
schedule.
 Advance payment must be reversed if the winner admits items in specified day.
 The advance payment will be inherited if the winner is not admitting the items in their
specified day.
2.6. Existing infrastructure
The manual Debre tabor university auction management system is time taking, unqualified,
costly and not satisfactory. Because of distance, time, cost, due to all information is transferred
manually by paper-based method.
2.7. Proposed System

In the existing system there are so many problems to adhere those problems we
proposed web-based auction system for Debre Tabor University.

 Development of convenient system web-based auction system to

participate on the everywhere as their own interest.
 It enables the auctioneer to store information on the database.
 Reduce wastage of time for preparing bid document for procurement team.
 Reduce wastage of cost.
 Reduces the number of employees in the auctioneer.
 Minimize the work load of employee.
 Enable computerized form of information handling method, this protect
information from accessed by unauthorized user.
 The system will enable suppliers get any information about the auctioneer quickly.
 CHAPTER THREE

SOFTWARE REQUIREMENT SPECIFICATION

3.1 Introduction

In this chapter we will make a detail analysis of the project starting from constraints,
requirements analysis, and there will be diagrams that will be used to depict the overall system
functionalities. These include the use case diagram, sequence diagram activity diagram, class
diagram and others. There will also be description of the functional and non-functional
requirements of our system.

3.2 General Constraints

Constraints are something that limit or impose our project.

The proposed project is supposed to have the following constraints: -

 Lack of adequate Information: - the problems the system manager to provides the
correct information about the system.
 Inadequate resources: - Starting from gathering information to do this project and
writing proposal we didn’t have enough resources to complete our project.
 Network connection problem.

3.3 Specific Requirements

Requirement is description of the services that provides by the system and its operational
constraint. These requirements reflect the need of customer from the system.

3.3.1. External Interface Requirements

3.3.1.1. User Interfaces

The user wants the interface to graphical interface to browse easily. Each part of the user
interface intends to be as user friendly as possible. The buttons used will be intended to be very
fast and easy to load on web pages. The pages will be kept light in space so that it won’t take a
long time for the page to load.

UI-1: The buttons and icons shall be labeled with descriptive verb.
UI-2: The color used in the GUI shall provide user safe vision and shall not be sharp to the eye.
UI-3: The application shall present error messages on the respective page.
UI-4: The software interface must follow design conventions which allow for familiar location of
drop-down menus etc.
 3.3.1.2. Hardware Interfaces
 Server: for connection to the client computer (to host the system)
 Computers
 Network connection

3.3.1.3. Software Interfaces

The application will run on any computer with an installed web browser.
 Operating System: Windows etc.
 Development tool: PHP: Hypertext Preprocessor, JavaScript,
 Data Base: PhpMyAdmin

3.3.1.4. Communications Interfaces

The Website system shall verify the auction start Time Date and the auction end time date to the supplier
who is a member of the system. The two parties should be connected by LAN or WAN for the
communication.

• NIC (Network Interface Card) – It is a computer hardware component that allows a

computer to connect to a network. NICs may be used for both wired and wireless
connections.
• Ethernet Communications Interface- Ethernet is a frame-based computer network
technology for local area networks (LANs)

3.4. Functional Requirements

A functional requirement describes what a software system should do. The functional
requirements focus on requirements of the proposed system. It deals with what the system should
do or provide for users. The major functional requirement of the proposed system includes:

Admin
Req1: The system shall require login before performing any task.
Req2: The system shall allow administrator to create account for users.
Req3: The system shall allow administrator to update account of users.
Req4: The system shall allow administrator to activate account.
 Req5: The system shall allow administrator to block account.
Req6: The system shall allow edit profile.
Req7: The system shall allow administrator logout from the system.

Supplier:
Req1: The system shall require login before user performing any function.
Req2: The system shall give form for registration.
Req3: The system shall display prepared bid document.
Req4: The system shall allow supplier to create account.
Req5: The system shall show winner.
Req6: The system shall allow edit profile.
Req7: The system shall allow suppliers logout from the system.
Req8: The system shall give feedback form to fill and send it.
Procurement team
Req1: The system shall require login before performing any task.
Req2: The system shall give form for preparing bid document.
Req3: The system shall display registered supplier.
Req4: The system shall allow procurement team edit profile.
Req5: The system shall allow procurement team logout from the system.
Procurement approving committee
Req1: The system shall require login before performing any task.
Req2: The system shall show assessed suppliers.
Req3: The system shall allow notifying winner.
Req4: The system shall approve suppliers.
Req5: The system shall allow edit profile.
Req6: The system shall allow logout from the system.
Req7: The system shall show feedback.
3.5. Use Case Design
3.5.1. Actor Identification
actor represents a type of users of the system or external systems that the system interacts with
an actor are a user of the system playing a particular role. The actors of the new system are:
 Supplier
 Procurement approving committee
 Procurement team
 Admin

3.5.2 Use Case Identification

 Use case describes the sequence of events of some types of users, called Actors, using

some part of the system functionality to complete a process. The possible use case of the
new system is initiated by an actor. After its initiation, a use case may interact with other
actors as well. A use case represents a complete flow of events. The following are listing
of all actors that interact or involved with the system use case: Login in
 Admin
 Manage account
o login
o Create account
o Update account
o Deactivate account
o Activate account
o Edit profile
 Supplier
o login
o Register
o View notice.
o View bid document.
o View winner.
o Edit profile
o Send feedback
  Procurement team
o login
o Post notice.
o Prepare bid document.
o View registered supplier.
o Assess supplier
o Edit profile
 Procurement approving committee
o Approve assessed supplier.
o login
o View assessed supplier.
o View feedback
o Notify winner.
o Edit profile

3.5.3. Use Case Diagram

 Figure 3. 1 use case diagram

3.5.4. Use Case Description

Table 3. 1 use case description for login
Use case name Login
Use case ID UC01
Actor(s) Administrator, procurement approving committee, supplier,
procurement team.
Description Required for login to the system
Basic course of action Actor action System response
step1: User starts the system. step2: System display home
step3: user click login link page interface.
step5: User fills user name and step4: System pop up login
password. form.
step7: User click login button. step6: System validates user
step9: User login to the system name and password.
successfully. step8: System checks user
name and password in
database.
step10: Use case end.
Alternative course of action The system displays error input message
(Incorrect user name and The system redirects the user to step 5 i.e., to fill user
password) name and password.
Use case ends.
Pre-condition A user must have valid user name password.
Post-condition The user successfully login to the system.

Table 3. 2 Create account use case description

Use case name Create account
Use case ID UC02
Actor(s) Administrator, supplier.
Description Administrator assigns privileges to procurement approving
 committee, and procurement team.
Basic course of action Actor action System response
Step1: User open website. Step3: The system displays
Step2: Click user registration the form.
link. Step6: The system validates
Step4: Fill the form entered information.
Step5: Click create account Step7: The system displays
button. account successfully created
Step8: Use case ends. message.

Alternative course of action if the account is already existed

(Incorrect user name and The system display error message that user
password) is already exist.
The system redirects to go to step 4.
Use case ends.
Pre-condition The user must click the login button in the system.
Post-condition The user has account.

Table 3. 3 Update account use case description

Use case Name Update account

Use case ID UC03
Actor(s) Administrator

Description The administrator updates account contents of users to let them

access to the system as per their request.
Basic course of action Actor Action System response
Step 1: Administrator first Step 2: The system display
login to system administrator page.
Ste 3: administrator click Step 4: system display list of
active account link. account.
 Step 5: click update button Step 7: system display form.
Step 8: change data/fill/ Step10: validate data
Step 9: click update button. Step11: display success messages.
Step 12: use case end
Alternate courses of The system displays the error input message.
action (if the filling The system redirects the administrator to Step 8i.e. to fill
the form is incorrect) form.
Use case ends.
Precondition: User should have account before in the system.

Post condition: The account now is updated.

Table 3. 4 Deactivate account use case description

Use case Name Deactivate account

Use case ID UC04
Actor(s) Administrator
Description Require to Administrator deactivate account
Basic course of action Actor Action System response
Step 1: Administrator first Step 2: The system display
login to system. administrator page.
Step 3: administrator click Step 4: system display active
view active account link. account
Step 5: click block button Step 6: display success messages.
Step 7: use case end
Alternate courses of The system not display active account
action (if the filling Use case ends.
the form is incorrect)
Precondition: User should have account before in the system.

Post condition: The account now be blocked.

Table 3. 5 Send feedback use case description

Use case name Send feedback
Use case ID UC05
Actor(s) supplier
Description supplier send feedback to procurement approving committee about
the auction.

Basic course of action Actor action System response

Step1: User login to the Step3: The system displays
system. the feedback form.
Step2: Click on the feedback Step6: The system displays
link. sent and thanks message.
Step4: Fill the form
Step5: Click on send feedback
button.
Step7: End use case.

Alternative course of action If the user fills incorrect date.

(Incorrect user name and The system displays error message.
password) The system redirects to go step 4 i.e.to fill
form.
 Use case ends.
Pre-condition The user must open the webpage.
Post-condition The feedback sends.

Table 3. 6 View feedback use case description

Use case name View feedback
Use case ID UC06
Actor(s) procurement approving committee
Description Procurement team view feedback send by supplier

Basic course of action Actor action System response

Step1: The procurement Step3: The system displays
approving committee login to the feedback link.
the system. Step5: The system displays
Step2: Mouth hover on view the feedback.
menu.
Step4: Click on feedback link.
Step6: End use case.

Alternative course of action

Pre-condition procurement approving committee login to the system.
Post-condition procurement approving committee view feedback.
 Table 3. 7 use case description for assessed supplier

Use case Name view assessed supplier

Use case ID UC07
Actor(s) Procurement approving committee
Description Procurement approving committee view supplier assessed by
procurement team.
Basic course of action Actor Action System response
Step1: Procurement Step3: The system displays the
approving committee first log view assessed supplier.
to his/her page Step5: The system displays
Step2: Click on view link. success message.
Step4: Click assess button Step6: Use case ends

Alternate courses of If the system not display assessed suppliers

action (if the filling Use case ends.
the form is incorrect)
Precondition: Suppliers assessed by procurement team

Post condition: supplier approved by procurement approving committee

 Table 3. 8 post notice uses case description

Use case Name post notice

Use case ID UC8
Actor(s) Procurement team
Description This use case indicates procurement team post notice to buy items,

Basic course of action Actor Action System response

Step1: The procurement team Step3: The system displays the
must log to his/her page. notice link.
Step2: Click post link. Step5: System displays the form.
Step4: Click on notice link. Step7: The system validates the
Step 6: Fill form. input.
Step9: Use case ends Step8: display success message.

Alternate courses of If the form empty.

action (if the filling The system displays error message.
the form is incorrect) The system redirects to go step 6-i.e.to fill form.
Use case ends.
Precondition: The procurement team must login to the system.

Post condition: Procurement teams successfully post notice.

 Table 3. 9 Prepare bid document use case description

Use case Name Prepare bid document

Use case ID UC9
Actor(s) Procurement team
Description This use case indicates procurement team prepare bid document for
supplier.
Basic course of action Actor Action System response
Step1: The procurement team Step3: The system displays the bid
must log to his/her page. approved request link.
Step2: Click view link. Step5: System display request
Step4: Click on approved approved by scientific director.
request link. Step7:The system display form
Step6: Click bid document Step9: system validate input
button. Step10: display success message.
Step8: fills form.
Step11. Use case ends
Alternate courses of If the form empty.
action (if the filling The system displays error message.
the form is incorrect) The system redirects to go step 8-i.e.to fill form.
Use case ends.
Precondition: The procurement team must login to the system.

Post condition: Procurement teams prepare bid document.

 Table 3. 10 Notify winner use case description
Use case Name Notify
Use case ID UC10
Actor(s) Procurement approving committee
Description Procurement approving committee Required to notify the winner supplier
Flow of action: Actor Action System response
Step 1: The administrator wants
to notify the winner.
Step 2: Select view link.
Step 3: The system display winner
Step4: click on the notify link supplier

Step 6: fill notify form
Step7: click on notify
Step 5: the system display notify form
Step 8: validate the given input
Step 9: the system notifies the status
of notifying.
Step 10: use case end

Alternate courses of If the form empty.

action (if the filling The system displays error message.
the form is incorrect) The system redirects to go step 6-i.e.to fill form.
Use case ends.
Precondition: There are winner buyers on the database

Post condition: Successfully notify the winner.

 Table 3. 11 View bid document use case description

Use case Name View bid document

Use case ID UC11
Actor(s) Supplier
Description Required to view bid document
Basic course of action Actor Action System response
Step 1: user first login to Step 3: The system display bid
system. document link.
Step 2: click view link. Step 5: display bid documents.
Step4: click bid document link.
Step 6: Use case ends.
Alternate courses of The system not display bid document (there is no prepared bid
action (if the filling document)
the form is incorrect) Use case ends.
Precondition: The user must login in to the system

Post condition: Successfully view the bid document

 Table 3. 12 View notice use case description

Use case Name View notice

Use case ID UC12
Actor(s) Supplier
Description Supplier view prepared notice
Basic course of action Actor Action System response
Step 1: supplier first login to Step 3: The system displays the
system notice link.
Step 2: click view link. Step 5: system display the notice.
Step 4. Click notice link.
Step 6 end use case
Alternate courses of If system not display notice (there is no prepared notice)
action Use case end
Precondition: supplier must login in to the system

Post condition: View required notice

 Table 3. 13 Register use case description

Use case Name Register

Use case ID UC13
Actor(s) Supplier
Description supplier registered to auction
Basic course of action Actor Action System response
Step 1: supplier first login to Step 3: system display bid
system. document link.
Step 2: click view link. Step 5: system display documents.
Step 4: click document link. Step 6: display register form.
Step 5: click register button. Step 9: Validates the input data in
Step:7 fill form the form.
Step 8: click register button Step 10: system display success
message.
Step 11: Use case ends
Alternate courses of The system displays the error input message.
action (if the filling The system redirects the administrator to Step 7 i.e. to fill form.
the form is incorrect) Use case ends.
Precondition: The supplier must login in to the system

Post condition: Supplier registered.

 Table 3. 14 View winner use case description

Use case Name View winner

Use case ID UC14
Actor(s) Supplier
Description Required to view the winner
Basic course of action Actor Action System response
Step 1: user first login to Step 3: The system display the
system. winner link.
Step 2: click view link. Step 5: system display winners.
Step 4: click winner link.
Step 6: view winner
Step 7: Use case ends.
Alternate courses of The system not display winner (no winner)
action (if the filling Use case ends.
the form is incorrect)
Precondition: The user must login in to the system

Post condition: User view winner

Table 3. 15 logout use case description.

Use case Name Logout

 Use case ID UC15
Actor(s) Administrator, procurement request, property department, finance,
procurement approving committee, supplier, procurement team,
scientific director.
Description After doing any private activity in the system the user logout from
the system.
Basic course of action Actor Action System response
Step1.User click setting link. Step 2. The system displays the
Step 3: click logout link. logout link.
Step5.Use case ends Step4: system display homepage.

Alternate courses of
action (if the filling
the form is incorrect)
Precondition: All must be login in to the system.

Post condition: User log out from his page.

3.6. Sequence Diagram

Sequence diagrams are used to represent graphically how objects interact with each other via
messages in the execution of a use case or operation. In our system the sequence diagrams that
we identified and presented for logout, register, create account and others. Each sequence
diagram in the auction system is displayed as follows.

Figure 3. 2 sequence diagram for create account

Figure 3. 3 sequence diagram for supplier register
Figure 3. 4 sequence diagram for logout
Figure 3. 5 sequence diagram for login
3.7. Activity Diagram
Activity diagram is a flow chart to represent the flow from one activity to another activity. The
activity can be described as an operation of the system.

Figure 3. 6 activity diagram for login

Figure 3. 7 activity diagram create account
Figure 3. 8 activity diagram for prepare bid document
 Figure 3. 9 activity diagram for block account

Figure 3. 10 activity diagram for logout

3.8 Class diagram

3.9. Data Structural Model

3.9.1. Entity-Relationship (ER) Model
3.10. Non-Functional Requirements
Non-functional requirements, as the name suggests, are requirements that are not directly
concerned with the specific services delivered by the system to its users. They may relate to
emergent system properties such as reliability, response time, and store occupancy.
Non-functional requirements, such as performance, security, or availability, usually specify or
constrain characteristics of the system as a whole.
The following are non-functional requirement associated with the system: -

3.10.1. Performance
This system gives service 24 hours per day with minimum response time so, it is easy to
participate on the auction.
3.10.2. Reliability
The reliability of the proposed system will be better due to proper storage of information when
users access the application.
3.10.3. Availability
All data in the system will be available all the time.
3.10.4. Security
Should allow login to only authorized users.
3.10.5. Maintainability
Proposed system has to be easily maintained and updated. For those goals the best option would
be a special administrative page, with preprogrammed functions, which in the long run will
prove useful for the business a whole, since it will save a lot of time. The administrative page is
easy to understand, learn and use.
3.10.6. Portability
This system is portable, since it runs on different desktop platforms. Running on different
platforms in desktop computer browser makes the system accessible by users.
 CHAPTER FOUR

System Design

4.1. Design Overview

Systems design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements. Systems design could be seen as the
application of systems theory to product development.
The purpose of designing is to show the direction how the web page is built and to obtain clear
and enough information needed to drive the actual implementation of web page. It is based on
understanding of the model the web page built on system design also focuses on decomposing
the system in to manageable parts.
To give right service for the right user at the right time on subject of his/her need make the
design properly. The design goals are derive from the nonfunctional requirement, which is the
part of the analysis document, and they describe the quality of the system to be implemented.

4.2. System Architectural Design (include Component and Deployment Diagram)

Deployment Diagram
UML deployment diagrams show the physical view of our system, bringing our software into the
real world by showing how software gets assigned to hardware and how the pieces communicate.
It is also used to show a collection of nodes and also dependencies of associations among them.
The associations between nodes Represents a physical connection. The physical deployment
model provides a detailed model of the way components will be deployed across the system
infrastructure. It details network capabilities, server specifications, hardware requirements and
other information related to deploying the proposed system.

4.2.1. Chosen System Architecture

4.2.2. System Interface Description
34.3. Detailed Description of Components
4.3.1. Component-1
4.4. User Interface Design
4.4.1. Description of the User Interface
4.4.2. Screen shoot Images
4.5. Database Design
4.5.1. Persistent database design