CHAPTER 3

REQUIREMENT SPECIFICATION AND ANALYSIS

3.1. Introduction
E-Procurement stands for electronic procurement and is a broad term for buying products
or services using electronic means such as the Internet, other computer networks. E-
procurement is the digital process of procurement. This means that paper order forms,
catalogs, and paper price lists aren’t needed and communication with the supplier
is predominantly digital. When it comes to e-procurement, companies rely on software
designed to make their purchasing processes more efficient and it is crucial for e-
procurement that the purchasing process is perfectly integrated. Ideally, the systems of both
businesses would work together seamlessly and the organization can then immediately see
whether the supplier has the required item in stock, and whether the order has been
received. E-procurement have been used by several organizations to purchase direct and
indirect materials for processes such as operations, administration and maintenance,
construction related items, cleaning solvents, and transportation services, among others.
This procedure allows the organizations to have a decentralized purchasing decision, in
which only the accredited suppliers can be seen in their purchasing systems. One of the
tools used within the e-procurement process is the E-RFQ (Electronic Request for
Quotation), where the quotation is requested online in a platform set by the buyer (wcu
procurement management system) in which the form for the quotation is uploaded and the
information requested.
E-Procurement is an online procurement system that enables company/branches, trading
around the country to procure products electronically from both local and international
suppliers by using internet.
This chapter uses different system development methdologies to put the process clearly and
detaily. The methdologies we are going to use are Object-Orianted Analisis, and it will give
deatil information about functionality of the project using Requirement Specifications ,
description of proposed system, system modeling, Use case documentation (for each use
case identified), and Sequence diagram , Activity Diagram and requirement analysis
 3.2. Description of the Proposed System
3.2.1 User Characteristics

3.2.2 Constraints

3.2.3 Assumptions and Dependencies

3.3. Requirement Specifications

3.3.1 Functional Requirement
The most essential processes of system are going to perform will be included in the main
functional requirements; the following functional requirements are essential tasks that the system
should be able to accomplish are:
User login: -The user should be able to login to the system where the user is authenticated
whether he/she is authorized. The user must login with user name and password to enter the
system.
Initiate request:- the employees of system can request his/her goods .The employee fills the
form of goods requisition by providing each and every required information, including the good
type, amount, quantity, quality, name, description of the goods and etc.
View request:-The employee can see request they send to their concerned body to know that
either the request is accepted or rejected and if the request is accepted they should know the
status of the request either it is purchased or on processing.
Approve the request:-Getting the reports of the request, College Dean, academic office and
purchase teams can approve the requests either by accepting it or rejecting it.
Forward approved request:-Given that the approved request (i.e. request accepted),
then the accepted request forwarded to the next level for more approve. But if it is rejected send
back to the targeted person with its reason.
Raise purchase order:- the purchase team raise purchase order to buy the goods from suppliers .
When purchasing team describes the submission date of materials depending on goods either it is
bulky or specific.
Register the supplier: - the system administration register suppliers when they upcoming on the
system.

Evaluate the supplier: - the purchase team evaluate suppliers and then announce the winner.
Document Upload and download: - Bidders download documents of the organization if they
are required to participate in auction. When bidder see the documents which are uploaded from
organization and attach their documents on organization site
Manage account:-In order to keep track of the users an administrator should be able to manage
the users by creating account and delete account if is required etc.
Select bidder: - the purchasing team select the bidder who puts smaller payments or least price,
in based on the request which are listed in auction document.
Generate reports:- if administrator wants to post requested /purchasing goods on site
sequentially order and posts who win the auctions
Announce winner: - Thus bidders whose technical documents match or exceed the wanted
documents by the procuring organization will be selected and their financial documents will be
viewed; whose financial document with least price is selected; winner will be announced online.
Award letter: - For whom who wins with the least prices, and losers will be announced and
rewards the letter and also the award letter written to all bidders.
Contract Agreement:-Contract is send to the winner and the winner downloads the contract
files and makes agreement with winner through online.
Register goods:-Finally when suppliers submit goods on settled schedule time purchased goods,
the purchasing time give model number for goods and store.
 3.3.2 Non-functional Requirement
For an efficient, correct, and robust operation of the system, some additional non-functional
requirements are necessary. These requirements are not directly related to functionality.
Security: The system shall available for authorized users. If users tries to log in to system with
a non-existing account then the administrator should not be logged in and he/she should be
notified about log-in failure. Each user is required to log in system with their secure passwords.
The system should log staff that has been assigned user names and passwords. The system
should be designed to make it impossible for anybody to log in without a valid username and
password. The system is secure because everyone has valid username and passwords to login the
system
Performance:-The performance in this sytem provides a detailed specification of the user
interaction with the software and measurements placed on the system performance.
 Response time:
It represents the fastness of the information displays of system. Response time of the System
should be few second to run and display.
Response time of system refers to the waiting time while the system accesses, queries and
retrieves the information from the databases. When the user login in to the system within less
seconds. The system gives response on few seconds because of response time of the system will
not take long time, almost in a few seconds
Flexibility: -The system is flexible for all users when they enter the correct login form. When
suppliers or employees have their own valid user name and password. The system is flexible to
authenticated persons and no one can access the system without valid username and passwords
because the system have high flexibility in order to enter the system when user fill valid login
form.
Correctness:-The system provides correct response to the correct request. The system can give
response properly based on requested .when suppliers wants to view bidder winner , the system
reply correct response that retrieve from database also employees too.
Adaptability:-The systems interfaces that will develop is attractive and easily understand to the
users because the developed system written in clear form to all users and that reflects the
adaptability of the system.
Reliability:-The data or information which is retrieved from the system database is accurate
(required) in deserved time/ maintained item to perform as required over time and the system is
reliable because of the system should easily be available at any desired time if by any chance the
system fails, the system should store a backup database for each transaction.
Availability:-The system is available for the user whenever there is an internet connection.
When suppliers can access in anywhere at any time and the system are available in 24 hours.
When bid closed the system stop their availability.
Error handling: - when the user login or fill some form in that case he/she fill wrong input ,
system can hold error and display error messages and enter correct form .
Maintainability:-The code is written in a way that it favors implementation of new functions, in
order for future functions to be implemented easily to the system. The system administrator will
be responsible for handling the system maintenance. It refers to the ability of technical support
personnel to install, configure, and monitor computer products, identify exceptions faults, debug
or isolate faults to root cause analysis, and provide hardware or software maintenance in pursuit
of solving a problem and restoring the product into service.
Portability:-The system is applicable in all platforms and can be access on the network
connection. When the system will run on any operating system like window, ubuntu and Macs, if
the connection is available without interruption. When the system run on window also run on
ubuntu there is no difference between the system display pages.
 3.4. System Modeling
3.5.1 Actor Identification
An actor represents any outside entity that interacts with your system. It may request services
from your system; and it may perform services for your system. An actor can be a person,
another system or perhaps a device such as a printer.
The actor participate in our system are:
 Staff
 Department Heads
 College Deans
 Academic office
 Administrator
 Suppliers
 Purchasing team
 Procurement expert
3.5.2 Use-Case Identification
Identifying the activities that are mainly performed on the proposed system is the basic
thing in analyzing a new system. The following use cases have been identified from the
system specification.
 Login
 Request
 View request
 Approve the request
 Register
 Send feedback
 Manage account (Update account, delete account, Create account)
 Prepare bid document
 Modify bid document
 Upload bid document
  Download bid document
 View bidder
 select winner
 Create contract document
 Award sends
 View winner
 supply product
 Logout
3.5.3 Use-Case Diagram
Use case diagrams graphically describe system behavior (use cases). These diagrams represent a
high-level view of how the system is used as viewed from an outsider’s (actor’s) perspective.
From the identified use cases and actors, the use case diagram of the system is shown in below.
Figure 1: use case diagram
 3.5.4 Description of Use-Case
The following tables describe in detail what a specific actor will perform step by step to
accomplish a specific task.
Use case name Login

UC ID UC1

Actor Department Head, purchase team, Staff, supplier, Administrator, Academic

office, College dean

Description It allows user to login in to the system

Pre-condition The user must have username and password

Post-Condition The authenticated user gets the appropriate page

Basic course of action Actor Action System Response

Step 1: User opens the browser to Step 2: System display login page.
login. Step 5: System validate username
Step 3: user enter username and and password
password Step 6: The system displays
Step 4 click login button appropriate page
Step 7: End use case

Alternative course of Actor Action System Response

action
Alternate Course A: Invalid User. A1: The system display message

A2: The actor fills the login form "Invalid Account – please try again".
again
A3: The use case resumes at step 5

Table 4: use case description of login

Use Case Name Request

 UC ID UC 2

Actor Department Head, College Dean, Academic, Staff

Extend None

Include Login

Description Users must ask the request materials

Pre-condition The user must request the procurement in order to be approved by the
concerned body

Post-Condition They user have get the request acceptance

Basic course of Actor Action System response

action
Step 1: user wants to request Step 3: displays the different alternatives
Step 2: clicks request user that are available on the page
menu bar Step 5: display request filled.
Step 4: select one option from Ste p7: validate the request filled form.
list Step 8: The system sends success massage
Step 6: fill the request filled to the user

Step 9: The use case end

Alternate courses of Actor action System response

action
Alternate Course A): if the A1: the system displays a message
user cannot fill the request form indicating that the “fill the appropriate
information on request filled” and “ask the
A2: The actor fills the
user to re-enter the request”.
appropriate information on the
A3: The use case resumes at step 7
request form

Table 5: use case description of request

Use case name view request

 UC ID UC 3

Actor Department Head, College Dean, purchasing team and Academic office

Description The actor needs to view and get information

Pre-condition User must click view request button.

Post -condition The users successfully view selected request

Basic course of action Actor Action System Response

Step 1: The user wants to view Step 3: displays the different

request. options that are available on this
Step 2. Click on view request link page
Step 4: select one option from list Step 5: display the information
and click select button
Step 6: use case end

Alternative course of Actor action System response

action
Alternate Course A): If there is no A1: The system display message
posted request
"no request " and “view other
A2: select another request
request”.

A 3: The use case resumes at step 5

Table 6: use case description of view request

 Use Case Name Register

UC ID UC 4

Actor Supplier

Extend None

Include Login

Pre-condition It allows all new suppliers must registers

Post- condition The system sends that he/she is successfully registered on the system

Basic course of action Actor action System response

Step 1: The user wants to register Step 3: The system display Register
form
Step 2: The user clicks Register
Step 5: The system Validates the
button from user menu bar
entered information.
Step 4: The user fills the form
Step 6: The system registered the
users and display the

massage indicating that “thank you

for registered

Step 7: use case end

Alternative course Actor action System response

action
Alternative Course A): user enter A1: display a message indicating
wrong information that the “fill the appropriate
information on registered filled” and
A2: The actor fills the appropriate “ask the user to reenter the
information on the registered filled
information”

A3: The use case resumes at step 5

Table 6: use case description of register

 Use Case Name Send Feedback

UC ID UC 5

Actor College Dean, department head, purchasing team and Academic office,
Staff

Extend None

Include Login

Description The user sees the accepted request and write feedback

Pre-condition The actors see the accepted request

Post-condition Send feedback

Basic course action Actor action System response

Step 1: The user wants to write Step 3: The system display feedback
feedback form
Step 5: The system Validates the
Step 2: The user clicks feedback entered information.
menu bar Step 6: The system send feedback
Step 4: The user fills the feedback
form and click the submit button Step 7: use case end

Alternative course Actor action System response

action
Alternative Course A): the user A1: system display a message
entered wrong information indicating that the “fill the appropriate
information on feedback filled” and
A2: The actor fills the appropriate “ask the user to reenter the
information on the feedback filled information”
A3: The use case resumes at step 5

Table 7: use case description of send feedback

 Use Case Name Logout

Use case ID UC 6

Actors Department Head, purchase team, supplier, Administrator,

Academic, College dean, staff,

Description To close the logout from the system

Pre-conditions The users become out of the system

Post conditions Click on logout button

Basic course of action Actor action system response

Step 1 users click on logout Step 2: The system makes the

button user out of the system/logged
from the system

Alternative course of None

action

Table 8: use case description of logout

 Use case name Approve request

UC ID UC 7

Description The actor compile and approve the request

Actor College Dean, purchasing team and Academic office

Extend Accept, reject

Include login

Pre-condition The materials are must request from actors

Post-condition Requested materials approved

Basic course of action Actor Action System Response

Step 1: The user wants to Step 3: displays the different request

approve the request. that are available on this page
Step 2. Click on Approve
Step 5: display the information
request link
Step 7: Store the information on the
Step 4: select one option from database and display the massage
request. indicating that “thank you for
Step 6: Read the information accept”
Step 8: The use case ends
then it clicks on “accept”

Alternative course of Actor action System response

action
Alternative course A): A1: Display reject form
Request rejected
A3: The system informed user as
A2: fill the from why rejected request rejected with reasons
the request
A4: Use case end

Table 9: use case description of approve request

 Use case name Update Account

UC ID UC 8

Actor Staff, administrator, college, dean, academic office, purchase team,

supplier, procurement expert

Description All users update their user accounts.

Post-condition The actors are update their user accounts

Post-condition The system displays successfully updated account.

Basic course of action Actor action System response

Step 1. Open the update Step 2. The system Displays the

account page.
Update account page.
Step 3. Users click update
Step 4. The system display update
account link.
account page.
Step 5. Users fills update
account form and click Step 6. The system displays successfully
change button. updated message.

Step 7. The use case end

Alternative course of Actor action System response

action
Alternative action A2: system displays message that the
previous password and username are not
A1: User enter invalid
matched
information entry to update

A3: users go to step 5 and

fill again

Table 10: use case description of update account

 Use case name Create account

Use case number UC 9

Actor(s) Admin

Description The System Admin will create accounts

Pre-condition The admin can create account for new user in the system.

Post-condition The account was successfully created for users

Basic course of Actors action Systems response

action
Step 1: Administrator click on Step 2: The system displays the create user
create account form.
Step 3:Administrator insert the Step 5: The system will validate the inserted
user information to create form.
account. Step 6:System displayed the messages that the
Step 4: Administrator submit account was created.
the inserted information form.
Alternate courses Actor action System response
of action
A1: admin fill empty form and A2: the system display the message that “you
submit are not filled the form
A3: admin can re-enter the and
fill the form and go to step 3
Table 11: use case description of crate account