DEBRE TABOR UNIVERSIY

FACULITY OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE

PROJECT TITLE: - AUCTION MANAGEMENT SYSTEM FOR

DEBRE TABOR UNIVERSITY

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

 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

ABSTRACT
Web based auction management system is a popular method for buying and selling products and
services. It helps to customer to sell and buy products online using need of internet in best price
and best quality without goes to the bid place physically. The main purpose of this project is to
develop web based auction management system for Debre Tabor University. To achieve the
main objective, we use a data collection method like interview, direct observation and document
analysis and we use iterative process model because the development process in cyclic manner
repeating every step after every cycle of software development. The implementation of our
project using PHP, MYSQLI and bootstrap. All the data needed for the application is stored in
the form of tables in the PHPMYADMIN.

i|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

ACKNOWLEDGEMENTS

First of all we would like to thank GOD keeping us healthy, second and foremost, we would
like to thank our advisor Instructor G/Rufael for the valuable guidance and advice he gave us.
He motivated us greatly to work in this project. His willingness to motivate us contributed
extremely to our project. We would like to express our gratitude towards our parents and
friends for their kind co-operation and encouragement which help us in completion of this
project.

ii | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Contents
ABSTRACT.....................................................................................................................i
ACKNOWLEDGEMENTS............................................................................................ii
List of figure..................................................................................................................iii
List of Table....................................................................................................................v
List of acroiam..............................................................................................................vii
CHAPTER ONE.............................................................................................................1
1. INTRODUCTION......................................................................................................1
1.1. Background of the Project..................................................................................................................1
1.2. Motivation............................................................................................................................................1
1.3. Statements of the Problem..................................................................................................................2
1.4. Objective of the Project.......................................................................................................................2
1.4.1. General Objective...........................................................................................................2
1.4.2. Specific Objectives..........................................................................................................2
1.5. Scope of the Project.............................................................................................................................3
1.5.1. Scope out: -......................................................................................................................3
1.6. Significance of the Project..................................................................................................................3
1.7. Feasibility Study..................................................................................................................................4
1.7.1. Operational Feasibility...................................................................................................4
1.7.2. Technical Feasibility.......................................................................................................4
1.7.3. Economic feasibility.......................................................................................................4
1.7.4. Political Feasibility.........................................................................................................5
1.8. Methodology of the Project.................................................................................................................5
1.8.1. Data Source.....................................................................................................................5
1.8.2. Fact Finding Techniques................................................................................................5
1.8.3. Development Tools and Techniques for the Project...................................................6
1.8.4 Software Process Model..................................................................................................7
1.9 Roles and Responsibilities....................................................................................................................8
1.10. Schedule Feasibility...........................................................................................................................8

CHAPTER TWO..........................................................................................................10
STUDY OF THE EXISTING SYSTEM......................................................................10
2.1. Introduction.......................................................................................................................................10
2.2. Existing System Description.............................................................................................................10

iii | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

2.4 users.....................................................................................................................................................12
2.5 Business rule identification................................................................................................................12
2.6. Existing infrastructure......................................................................................................................12
2.7. Proposed System................................................................................................................................13

CHAPTER THREE......................................................................................................14
SOFTWARE REQUIREMENT SPECIFICATION.....................................................14
3.1 Introduction........................................................................................................................................14
3.2 General Constraints...........................................................................................................................14
3.3 Specific Requirements........................................................................................................................14
3.3.1. External Interface Requirements................................................................................14
3.4. Functional Requirements..................................................................................................................15
3.5. Use Case Design.................................................................................................................................17
3.5.1. Actor Identification......................................................................................................17
3.5.2 Use Case Identification.................................................................................................17
3.5.3. Use Case Diagram........................................................................................................19
3.5.4. Use Case Description....................................................................................................20
3.6. Sequence Diagram.............................................................................................................................35
3.7. Activity Diagram...............................................................................................................................41
3.8 Class diagram.....................................................................................................................................46
3.9. Data Structural Model......................................................................................................................47
3.9.1. Entity-Relationship (ER) Model.................................................................................47
3.10. Non-Functional Requirements.......................................................................................................47

CHAPTER FOUR.........................................................................................................49
SYSTEM DESIGN.......................................................................................................49
4.1. Design Overview................................................................................................................................49
4.2. System Architectural Design (include Component and Deployment Diagram) 4.2.1
Deployment Diagram..............................................................................................................................................49
4.2.2 Component Diagram.....................................................................................................50
4.3. Chosen System Architecture............................................................................................................51
4.4 System Interface Description............................................................................................................52
4.3. Detailed Description of Components...............................................................................................53
4.4. User Interface Design........................................................................................................................54
4.4.1. Description of the User Interface................................................................................55
4.4.2. Screen shoot Images.....................................................................................................56

iv | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

4.5. Database Design.................................................................................................................................58

4.5.1. Persistent database design...........................................................................................58

References.....................................................................................................................60

v|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

List of figure
List of figure for chapter one

Figure 1. 1 1iterative process model................................................................................................8

List of figure for chapter three

Figure 3. 1 use case diagram..........................................................................................................19

Figure 3. 2 sequence diagram for create account..........................................................................36
Figure 3. 3 sequence diagram for logout.......................................................................................37
Figure 3. 4 sequence diagram for login.........................................................................................38
Figure 3. 5 sequence diagram for update account.........................................................................39
Figure 3. 6 sequence diagram for send request..............................................................................40
Figure 3. 7 activity diagram for login............................................................................................41
Figure 3. 8 activity diagram create account...................................................................................42
Figure 3. 9 activity diagram for prepare bid document.................................................................43
Figure 3. 10 activity diagram for send request..............................................................................44
Figure 3. 11 activity diagram for block account............................................................................45
Figure 3. 12 activity diagram for logout........................................................................................45
Figure 3. 13 Class diagram............................................................................................................46
Figure 3. 14 ER diagram................................................................................................................47
List of figure for chapter four

Figure 4. 1 Deployment Diagram..................................................................................................50

Figure 4. 2 Component diagram....................................................................................................51
Figure 4. 3 Chosen System Architecture.......................................................................................52
Figure 4. 4 User Interface Design..................................................................................................54
Figure 4. 5 screen shoot image for main page...............................................................................56
Figure 4. 6 screen shoot image for login.......................................................................................57
Figure 4. 7 screen shoot image for create account.........................................................................58
Figure 4. 8 persistent database.......................................................................................................59

vi | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

List of Table
List of table for chapter one

Table 1. 1 Role and responsibilities.................................................................................................8

Table 1. 2 Schedule Feasibility........................................................................................................9
List of table for chapter three

Table 3. 1 use case description for login.......................................................................................20

Table 3. 2 Create account use case description.............................................................................21
Table 3. 3 Update account use case description............................................................................22
Table 3. 4 Deactivate account use case description.......................................................................23
Table 3. 5 Send feedback use case description..............................................................................24
Table 3. 6 View feedback use case description.............................................................................25
Table 3. 7 use case description for assessed supplier....................................................................26
Table 3. 8 post notice uses case description..................................................................................27
Table 3. 9 Prepare bid document use case description..................................................................28
Table 3. 10 Notify winner use case description.............................................................................29
Table 3. 11 View bid document use case description....................................................................30
Table 3. 12 View notice use case description................................................................................31
Table 3. 13 Register use case description......................................................................................32
Table 3. 14 View winner use case description..............................................................................33
Table 3. 15 logout use case description.........................................................................................34
Table 3. 16 Send request use case documentation.........................................................................35
List of table for chapter four
Table 4. 1 Description of the User Interface..................................................................................55

vii | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

List of acronyms

DTU Debre Tabor University

LAN Local Area Network

WAN Wide Area Network

UC Use Cases

MYSQL Structured Query Language

HTML Hyper Text Markup Language

JS Java Script

MS WINDOW Microsoft Window

UML Unified modeling language

PHP Hypertext Preprocessor

UI User interface

ER Entity Relationship

viii | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

CHAPTER ONE

1. 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|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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.

1. 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.
2. 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 supplier 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.
3. Maximize material cost (resource consuming) such as paper, printer and others.
4. 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.

1. Cannot get full information about auction; it might not view all
advertisement or view after left their closed days.
2. Maximizing transport cost. This means if supplier lives far away from
auction place it waste high cost to register in the auction.
3. 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.

2|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

 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 only works on English language.

1.6. Significance of the Project

This project is focuses on auction system. It will cover different activities, such as suppliers
can be registered to the auction in everywhere, system display the list of registered suppliers 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.

3|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

• 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 aspect 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

In this project we will develop a system having less cost incurred to create physical
marketplaces. In addition to this the cost that was spent to conduct auctions physically being
there will be discarded.
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.

4|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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.

5|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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, Draw.io: to draw any diagram that found in the 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.

6|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

 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.

7|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 1. 1 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.

8|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Table 1. 2 Schedule Feasibility

9|Page
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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 requester

• 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

10 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

among the alternative solution and finally to decide the functional requirements of the proposed
new system.

 Send requests

Procurement requests initiated from different department/college or other units and send to
procurement team for purchase.
 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.

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.

11 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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 requester: is initiated from department, college, or other units and summated for
procurement team for purchase.

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 days.

12 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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 protects
information from accessed by unauthorized user.
 The system will enable suppliers get any information about the auctioneer quickly.

13 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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

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
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

14 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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

The system would need a computer with at least 1GB RAM and minimum of 3GB hard disk
space to include database usage for future.
In addition to that, the system should have a monitor screen with 1.70 GHz or higher version
processor and require Network connection

3.3.1.3. Software Interfaces

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

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)

15 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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 show request send by different applicants
Req3: The system shall give form for preparing bid document.
Req4: The system shall display registered supplier.
Req5: The system shall allow procurement team edit profile.
Req6: The system shall allow procurement team logout from the system.
Procurement requester
Req1: The system shall require login before performing any task.
16 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Req2: The system shall give request form.

Req3: The system shall allow procurement requester edit profile.
Req4: The system shall allow procurement requester 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 requester
 Procurement approving committee
 Procurement team
 Admin

3.5.2 Use Case Identification

 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:
 Admin
 login
 Manage account

17 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

o Create account
o Update account
o Deactivate account
o Activate account
o Edit profile

 Supplier
o login
o Register
o Create account
o View notice.
o Pay payment
o View bid document.
o View winner.
o Edit profile
o Send feedback
 Procurement requester
o Send request
o Edit profile
 Procurement team
o Login
o View request
o Post notice.
o Prepare bid document.
o View paid supplier

18 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

o View registered supplier.

o View request
o Assess supplier
o Edit profile
 Procurement approving committee
o login
o Approve assessed supplier.
o View assessed supplier.
o View feedback
o Notify winner.
o Edit profile

3.5.3. Use Case Diagram

19 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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. Procurement requester.
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
password) user name and password.

20 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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, procurement requester 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
password) that user 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.

21 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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.
Step 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.
the form is incorrect) to fill form.
Use case ends.
Precondition: User should have account before in the system.

Post condition: The account now is updated.

22 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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

23 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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.

24 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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.

25 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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

26 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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.

27 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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 request
must log to his/her page. link.
Step2: Click view link. Step5: System display requests send
Step4: Click on request link. by procurement requester.
Step6: Click bid document Step7:The system display form
button. Step9: system validate input
Step8: fills form. Step10: display success message.
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.

28 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Table 3. 10 Notify winner use case description

Use case Name Notify winner
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 Step 5: the system display notify form
Step7: click on notify
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

29 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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

30 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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

31 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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 and pay payment first.

Post condition: Supplier registered.

Table 3. 14 View winner use case description

Use case Name View winner

Use case ID UC14

32 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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 requester, procurement approving

33 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

committee, supplier, procurement team.

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.

Table 3. 16 Send request use case documentation.

Use case Name Send request

Use case ID UC21
Actor(s) Procurement requester
Description Required to send request to procurement team
Basic course of action Actor Action System response
Step1. Procurement requester Step3.The system display form
log in to the system Step 6. system validate input data

34 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Step2click on send request Step 7: display success message.

link. Step 8. Use case end
Step4.fill form.
Step 5: click send button.
Alternate courses of If the customer fill incorrect information
action (if the filling The system displays error message.
the form is incorrect)  The system redirects to go step 4 i.e.to fill the form.
 Use case end
Precondition: The Procurement requester must login in to the system

Post condition: Successfully send comment.

3.6. Sequence Diagram

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

35 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 2 sequence diagram for create account

36 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 3 sequence diagram for logout

37 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 4 sequence diagram for login

38 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 5 sequence diagram for update account

39 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 6 sequence diagram for send request

40 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

3.7. Activity Diagram

In our system activity diagram shows the flow from one activity to another activity. The activity
can be described as an operation of the system.

Figure 3. 7 activity diagram for login

41 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 8 activity diagram create account

42 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 9 activity diagram for prepare bid document

43 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 10 activity diagram for send request

44 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 3. 11 activity diagram for block account

Figure 3. 12 activity diagram for logout

45 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

3.8 Class diagram

In our project class diagram model show the classes of the system, their inter-relationships, and
the operations and attributes of the class. The analysis level class diagram of auction system is
displayed as follows:-

Figure 3. 13 Class diagram

46 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

3.9. Data Structural Model

3.9.1. Entity-Relationship (ER) Model
In this system entity relationship model is a graphical representation of entities and
their relationships to each other, typically used in computing in regard to the organization of data
within databases or information systems.

Figure 3. 14 ER diagram

47 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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: -

Performance

This system gives service 24 hours per day with minimum response time so, it is easy to
participate on the auction.

Reliability

The reliability of the proposed system will be better due to proper storage of information when
users access the application.
Availability

All data in the system will be available all the time.

Security

Should allow login to only authorized users.

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.
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.

48 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

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 derived 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)
4.2.1 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.

49 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 4. 1 Deployment Diagram

4.2.2 Component Diagram

We use Component diagrams to show facility management systems how the physical
components of a system are organized. And also shows which component or objects will be
accessed by whom and what type of security infrastructures it is using. The diagram is simulated
below.

50 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 4. 2 Component diagram

4.3. Chosen System Architecture

We use Three-tier architectures to design our system. Because 3-

tierArchitecture increases performance, flexibility, maintainability, Reusability, and
scalability while hiding the complexity of distributed processing from the
users/clients. The data Layer maintains the applications data such as Candidate data,
instructor data, exam data, Admin data,

The middle layer (web/application server) implements the business logic,

controller logic and presentation logic to control the interaction between the
application’s clients and data. The controller logic processes client requests such as

51 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

requests to view student’s result, to retrieve data from the database. The business
logic dictates how clients can and cannot access application data and how
applications process data. A web server is a program that runs on a network server
(computer) to respond to HTTP requests. HTTP is the standard protocol for transfer
data across the internet.

The client layer is the applications user interface containing data entry forms
and client-side applications. It displays data to the user.

Figure 4. 3 Chosen System Architecture

4.4 System Interface Description

Manage account subsystem: this subsystem used for the following use case.

 Administrator update account.

 Administrator block account.
 Administrator create account.

52 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Post notice subsystem: subsystem used for the following use case.

 Procurement team poste notice for supplier

 Supplier view post notice.

Registration subsystem: subsystem used for the following use case.

 supplier registers for bid

Prepare bid document subsystem: subsystem used for the following use case.

 Procurement team prepare bid document.

 Supplier view the bid document.

Notify winner subsystem: subsystem used for the following use case.

 Procurement approving committee notify winner.

 Supplier view winner

4.3. Detailed Description of Components

Decomposition is breaking a complex problem or system into parts that are easier to conceive,
understand, program, and maintain. It helps to modularize the system so that it will be easier to
design and implement. The following are subsystems or System decomposition:
 Manage account subsystem: This subsystem is used to manage account
information and has the following operations.
 Create an account
 Update account
 block an account
 View subsystem: This subsystem allows for view information and performs this
operation.
 View notice.
 View bid document.
 View winner.

53 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

 View assessed supplier.

 View registered supplier
 prepare sub system:
 Prepare bid document.
 Register sub system:
 Register supplier
 request sub system:
 Send request
 View request

4.4. User Interface Design

54 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 4. 4 User Interface Design

4.4.1. Description of the User Interface

Table 4. 1 Description of the User Interface

No. UI Name UI Description

1 Home Page User interface part where main page of the user will be viewed
and link for related topics (websites).
2 Login Page It is a page which enables user of system log into system by
entering their user’s name and password.
3 About Us Page It is the page that contains detailed information about the
website.
4 Contact us Page The information in which the users can contact the admin or
the coordinators of the system.
5 Procurement team The page that provides preparing bid document and notice,
page view registered supplier and assess them.

6 Supplier p The Page that provides view link to view bid document and
age notice, payment link for bid document and register link to
register for bid
7 Procurement The page that approving committee view assessed supplier,
Approving approve supplier and notify winner.
committee page
8 Admin page The page that contains manage users account and views the
users of the system.
9 Procurement The page that procurement requester prepares and send
Requester page requests

55 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

4.4.2. Screen shoot Images

Figure 4. 5 screen shoot image for main page

56 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 4. 6 screen shoot image for login

57 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 4. 7 screen shoot image for create account

4.5. Database Design

4.5.1. Persistent database design
A persistent database stores persistent data in the form of objects, or records that are durable
when changing devices and software. Persistent data is stable and recoverable. Traditional
relational database management systems (RDBMS) store persistent data in the form of records
and tables. Our project persistence database is:

58 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

Figure 4. 8 persistent database

59 | P a g e
 WEB BASED AUCTION MANAGEMENT SYSTEM FOR DTU April,2014 EC

References
1. Assurance level report on reactive disclosure of project procurement and contract information
by Endale Bewketu.

2. https://www.youtube.com/watch?v=wShAUEynEJs&t=38s

3. https://www.youtube.com/watch?v=sQgoFjxSdxo&t=3s

4. https://www.youtube.com/watch?v=iLsJ0Ix_dho&t=52s

60 | P a g e