New Project Documentation

PURCHASING MANAGEMENT SYSTEM
Software Requirement Specification for

Purchase management system for the
department of purchasing of HU
Version 1.0
Prepared by
Group name:
Bereket Getachew 1500/03 bereket@gmail.com
Berihun Adis 1501/03 berihunaddis32@gmail.com
Chala Tesfaye 1514/03 chalatesfaye22@gmail.com
Advisor: Mr. Abdisa Kebede
Date: January, 30, 2014
Contents
1|Page
Chapter 1.....................................................................................................................................................5
1. Introduction.........................................................................................................................................5
1.1. Documentation purpose...............................................................................................................6
1.2. Product scope...............................................................................................................................7
1.2.1. In scope................................................................................................................................7
1.2.2. Out scope.............................................................................................................................7
1.3. Intended audience and document overview.................................................................................8
1.4. Definitions, acronyms and abbreviation.......................................................................................9
1.5. Reference and acknowledgment................................................................................................10
1.5.1. Acknowledgements............................................................................................................10
1.5.2. Reference...........................................................................................................................10
Chapter 2...................................................................................................................................................11
2. Overall description............................................................................................................................11
2.1. Product perspective....................................................................................................................11
2.2. Product functionality.................................................................................................................11
2.3. Users and characteristics............................................................................................................14
2.4. Operating environment..............................................................................................................15
2.5. Design and implementation constraints.....................................................................................17
2.6. User documentation...................................................................................................................17
2.7. Assumption and dependency.....................................................................................................17
Chapter 3...................................................................................................................................................18
3. Specific requirements........................................................................................................................18
3.1. External interface requirements.................................................................................................18
3.1.1. User interfaces...................................................................................................................18
3.1.2. Hardware interface.............................................................................................................25
3.1.3. Software interface..............................................................................................................25
3.1.4. Communication interface...................................................................................................25
3.2. Functional requirements............................................................................................................25
3.2.1. User class1: User...............................................................................................................25
3.2.2. User class 2: Administrator................................................................................................28
3.3. Behavior requirements...............................................................................................................29
2|Page
3.3.1. Use case view....................................................................................................................29

Chapter 4...................................................................................................................................................37
4. Other non functional requirement......................................................................................................37
4.1. Performance requirements.........................................................................................................37
4.2. Safety and Security requirements...............................................................................................37
4.3. Software quality attributes.........................................................................................................38
4.3.1. Flexibility...........................................................................................................................38
4.3.2. Correctness........................................................................................................................38
4.3.3. Adaptability.......................................................................................................................38
4.4. Reliability..................................................................................................................................38
4.5. Availability................................................................................................................................38
4.6. Maintainability...........................................................................................................................38
4.7. Portability..................................................................................................................................38
Chapter 5...................................................................................................................................................39
5. Analysis Model..............................................................................................................................39
5.1. Sequence diagram......................................................................................................................39
5.2. Data flow diagrams (DFD)........................................................................................................46
5.3. State transition diagram.............................................................................................................52
Chapter 6...................................................................................................................................................56
6. Design consideration.........................................................................................................................56
6.1. Design goals..............................................................................................................................56
6.2. Design trade-offs.......................................................................................................................57
6.3. Assumptions and dependencies.................................................................................................57
6.4. General constraints....................................................................................................................57
Chapter 7...................................................................................................................................................58
7. System decomposition.......................................................................................................................58
7.1. Subsystem interaction................................................................................................................58
Chapter 8...................................................................................................................................................59
8. User interface design.........................................................................................................................59
8.1. Class diagram............................................................................................................................59
8.2. Detailed design..........................................................................................................................60
3|Page
8.3. Entity relationship......................................................................................................................67

Chapter 9...................................................................................................................................................71
9. Appendix............................................................................................................................................71
Chapter 10.................................................................................................................................................72
10. Glossary.........................................................................................................................................72
4|Page
Chapter 1
1. Introduction
This SRS Document is prepared for the Purchase Department of Haramaya University to develop
computerized system named Purchase Management System. The project is concerning
developing the computerized system for the organization of Haramaya University.
The purchase management system of Haramaya University is the one of the system that works
various activities manually which is not efficient, and because of this we are going to develop a
computerized system for the department in the university. This system works manual which is
not computerized because of this, we are going to develop a computerized system for the
University.
The project is classified into two parts which is documentation part and implementation part. The
first part of the project takes two months starting from now. The second part (implementation
part) of the project which will take place in second semester takes around three months.
Generally this project life time will take around five months in Haramaya University for the
Purchase Management System to be delivered to the department or the advisor.
This documentation includes the following topics with their detailed information which are
essential for the development of the system in our project.
 Overall description of the project

 Specific requirements
 Other non-functional requirement
 Analysis models
 Design considerations
 System decomposition
 User interface design
The topics which are listed above are discussed in this documentation of the project.
5|Page
1.1. Documentation purpose

The requirements in this documentation are for the purchasing management system of Haramaya
University. Purchase Management System aims at the management of the asset purchase in the
university. The application focuses on creating well defined purchase reports for individuals as
well as cost reports categorized yearly / monthly. When an employee creates an asset request,
he/she may then submit it. The next approval authority can view the request with the asset details
categorized according to the request id (requisition No). He may then have to either approve the
request or reject it with his comments. The requestor, at every stage will be intimated by mail
regarding the current status of his request or may view it in the “My Request status” option in the
left Navigator that found on his/her page. The person with the Administrator access can make
various configuration settings for the application.
The purchasing management system works as follow:
1. Employee / Requestor initiates request by filling purchase requisition form with

specification of the resources required and sends it to the Department Head for approval.
When the department head approves, it is sent for further approval to college dean. From
college dean the approval request goes to VPASS (Vice president for Administration and
student services) or AVP if the request is for academic purpose and after that, it goes to
Purchase Head and the budget of the request is checked.
2. In all of the above mentioned levels, the request may be rejected at any of the stages. If
the request is rejected the rejection message is sent back and the process stops.
3. After the budget approval by purchase head, the purchase department decides either the
purchasing process is bid or normal purchase from individual supplier based on the costs
of the requested resources. If the costs of resources is less than 100,000birr, the resources
are purchased from individual supplier normally but if the resources cost is more than
100,000 birr, the resources are purchased by bid.
4. If the purchasing process is by bid, the system provides full information about the bid and
how the bidder evaluated. The system also registers the bidder information.
5. The bid committee evaluate the bidder and decides the winner of the bid and the system
tells evaluation result of bid to the bidder.
6. After the evaluation result of the bid, purchase head signed on purchase order form and
purchaser raise the Purchase order to the winner of the bid.
7. The system orders the purchaser to collect resources from the supplier.
8. When the requested resources are received, then the inspection process takes place to
verify that the purchased resources are the required (requested) one by checking the
specification of the requested resources.
9. After inspection, if the resources are those requested (as specified), it is registered and
stored in property management. But if the resources are not those requested, they are
rejected.
10. At last the requester department informed as resource is arrived.
6|Page
1.2. Product scope
1.2.1. In scope
The system in scopes is:
Register employee
Register users of the systems
Receiving request
Approve request
Check the budget
Provide help for the users
Generate request report
Generate cost report
Tell the status of the request
View request report
View cost report
Reject request
Register bidder information
Tells evaluation result of bid to the bidder
Raise purchase order
Inspection of the resources
Register the purchased resources
Notify the requester department when resources purchased
1.2.2. Out scope

Making a payment
Competing bidder
Benefit of the project
Security of data.
Ensure data accuracy’s.
Administrator controls the entire system.
Minimize manual data entry.
Greater efficiency.
User friendly and interactive.
Minimum time required.
7|Page
Objectives of projects
General objectives
Developing the most reliable and flexible system which solves the current problem of the
organization.
Specific objectives
The specific objectives of the project are:
 To overcome the manual resource requisition of the department (section)
 To provide the fast reply(resource providing) of the purchasing department
 Creating fast and comfortable resource requisition forms.
 Providing reliable and fast approve of the requested resources
 Reducing the time delayed for resource request
 Reduce costs that are used for the resource requisition
 Familiars the people with the new technology
 Automating the database system
 Provide transparency in work flow
Goal of the project
The goal of our project is providing the simple and more usable purchasing management system
for the University.
1.3. Intended audience and document overview

The readers of this project documentation are our advisor, examiner, the developers’ team
of this project, Software Engineering staff, and purchase department members. Developers of the
project is responsible for writing the documentation beginning from the requirement gathering to
Implementation of the project and Advisor of the project has the role of advising and giving
guides to the developer at each section of the documentation. Examiner and software
Engineering staff members are responsible for examining the project documentation and
implementation at the end to evaluate and approve the project.
8|Page
The users of this system (products) are the following:
Employees of Haramaya University

Purchasing department
Head of each sections/department/
College dean
VPASS
AVP
Internal and external suppliers
purchaser
Administrator
1.4. Definitions, acronyms and abbreviation

AVP- Academic Vise President
Dept.head- Department head
DFD-Data Flow Diagram
Emp-employee
GB –Giga Byte
GHz-Giga Hertz
HU – Haramaya University
HUPMS-Haramaya University Purchase Management System
LAN-Local Area Network
MB-Mega Byte
RAM-Random Access Memory
SRS- Software requirement specification
SQL-Structured Query Language
SVGA- Super Video Graphics Array
UC-use case
VGA-Video Graphics Array
VPASS- Vise president for Administration and Student services
9|Page
1.5. Reference and acknowledgment
1.5.1. Acknowledgements
First, we would like to thank our GOD for giving us hope to finish writing this documentation
strongly. Secondly, we would like thanks to Haramaya University College of computing and
informatics, department of Software Engineering for giving the chance for doing our final
(senior) project as well as our advisor Mr.Abdisa Kebede who support us from the beginning of
requirement gathering to the end of the documentation writing by giving us good comments and
recommendations that help us to finish our project documentation writing successfully.
At last, we acknowledge HU purchasing management system department staffs that support us
by giving the necessary requirements and support us by materials.
1.5.2. Reference
1. Guideline of SRS
2. HU_Redesigned_Procurement_Finance_and_Pproperty_Management_p(old)
3. www.google/object oriented system analysis and design .com
4. WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems
Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapters 8
5. HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) 4th ed., Modern Systems
Analysis and Design, Benjamin/Cummings, Massachusetts. Chapter 7
6. Ethiopian Federal Government Economic and Finance minster manual book
7. Haramaya university purchasing management system department module
10 | P a g e
Chapter 2
2. Overall description
2.1. Product perspective

The system which we are going to develop is new for the organization because there is no a
computerized system for the organization before.
The general diagram that shows the process of the purchasing management system is:
Purchase
managemen
User Web server
t system
Data base Server
Fig.2.1 General Diagram of purchasing management system
2.2. Product functionality
The system to be developed will give easy and fast way to track the available budget of a department
when it requests an item for purchase.
The new online purchase request facility will be very easy, fast and cost effective. The new computerized
system’s approval method is clear, cost effective and faster.
The new system will incorporate a functionality through which a requester of item will know the status of
that item which was requested for purchase and it will have an easy way of retrieving information about
results of evaluation of bid offers of suppliers including the winners, and about results of technical
inspections and also suppliers and purchasers. The new computerized system produces timely reports.
The new computerized system shall have easy way to make specification, standards, rules and price of
items accessible to users. Searching and obtaining information about item, procedure, or anything
relevant is very easy.
11 | P a g e
Generally, the product functionality is described as follow:
 User registration
 User login
 Initiate request
 View status
 Help
 View the report of request
 Approve the request
 Forward the Approved request
 Send the request status
 Manage all users of the system
 Retrieve password
 Post the bid announcement
 Insert bidder information(registering the bidder)
 Bid evaluation result
 Raise purchase order
 Inspection of the resources
 Register resources
 Inform the requester department to collect resources
12 | P a g e
The following is the context free diagram of the data flow diagram (DFD) for HU purchasing
management system.
College dean
Dept.head
Approved request VPASS/VP
Approve request
Approved request
Approve request Approve request
0
Initiate request Check budget
Purchase head
Employee Budget response
Request status HUPMS
Manage user
Register Manage response
Register resource Register response Administrator
Supplier Register response
Purchaser
Fig.2.2 The context free diagram of the system
13 | P a g e
2.3. Users and characteristics

The users of this system are:
Employees of Haramaya University

Purchasing department
Head of each sections/department/
College dean
VPASS
AVP
Internal and external suppliers
purchaser
Administrator
The most important users of the system
Employee of the University: - The system mostly used for the Universities employees to initiate
their request to the department head when they want any resources that is needed for their work
and the department head approves their request (accept/reject). The employees can be from each
department/section/ is found in the college.
Head of each department/section/: - The heads of departments are also the main users of the
system because they receive the requisition from employees and approve it and send it to the
college dean and then to the purchasing department by using the system.
VPASS: is the important user of the system because it receives the requests from college dean
and approve the requests and forward the accepted requests to the purchase department.
College dean: - The college dean is also the most user of the system. After the department head
approved the requisition which are raised from employee of the University, the college dean also
approve the requisition.
Purchasing department: - The purchasing department is the main user of the system because
the system belongs to the department. When purchase order is raised, the purchasing department
receives every requests rose from the college dean, AVP or other vice presidents and the head of
purchasing department also approve the requisition.
Purchaser: Are also the most important users of the system because after all things are
approved, the purchaser is responsible for apply Performa collection, collecting resources from
the supplier and submit the resources to the property management office.
Administrator: Is the most important users of the system because it manages all the other users
of the system according to their responsibility.
The less important users of our system
14 | P a g e
AVP: is less users of the system because AVP is responsible only to approve the requests
initiated for the academic issues.
Internal and externals supplier: - the suppliers are also the less users of the system because
they use the system conditionally i.e. in specific time participating in the bid process and then if
they win they supply the items, purchasing is the task of a purchaser who is the staff of the
purchase department
2.4. Operating environment
SOFTWARE SPECIFICATIONS
Operating System : Windows 7/8
Front end : Visual Basic 2010
Back end : SQL Server 2008
Design Tool : Edraw max
HARDWARE SPECIFICATIONS
Processor : X86 Compatible processor with 1.7

GHz Clock speed
RAM : 512 MB or more
Hard disk : 20 GB or more
Monitor : VGA/SVGA
Keyboard : 104 Keys
Mouse : 2 buttons/ 3 buttons
15 | P a g e
Start
Request generated
Request approved by Request approved by

NO Academic issues? YES YES Dpt. head?
College dean?
YES NO
AVP approve request? NO Reject message sent NO

Back
NO
YES VPASS approve request? YES Budget approved?
NO YES
Register bidder YES Cost >100,000 birr?
NO
Provide bid evaluation

Result
Select some supplier
Purchase order rose Register resources Inform requester Close
YES
Resource inspected?
NO Resource rejected
Fig.2.3 flow chart of purchasing management system

16 | P a g e
2.5. Design and implementation constraints

The following requirements are constraints of the system:
 Lack of online payment technologies
 Lack of knowledge about online transaction
 Hardware limitation
 Time limitation
 Operating language
2.6. User documentation

For our system we can use, user manuals and help menu that provided by system to support the
user of the system.
User manual: is the documentation that is prepared manually to give instruction and usage of
the system for the users or to guide the users how they use the system perfectly and effectively.
This documentation contains the instructions about the system how to operate and use it.
Help menu: this is also one of the user documentation that helps the user by telling them the
main instruction to operate the overall system. We added the help menu to the system as a
navigation menu that is visible to everyone who wants to use system.
2.7. Assumption and dependency

One assumption about the product is that it will always be used when server is Accessible only.
If there is no any connection between server and clients, the system is not Accessible.
The other assumption of the product is when the server fails; the whole system is going to fail as
well.
17 | P a g e
Chapter 3
3. Specific requirements
3.1. External interface requirements
3.1.1. User interfaces

User interface is used to connect the users with the system. Some user interface of our system is
described as follow:
o Home interface
o Login interface
o User registration interface
o Purchase requisition interface
The other user interface of the system is discussed in the detailed design topic of chapter 8.
The following is the home page of the system that displayed first and from this page, the user get
login pages that are used to logs in users to the system, about us and contact us.
18 | P a g e
The first user interface the user gets from home page is Login form. The login form has the
following controls: username, password and user type labels, Textbox for UserName and
password label, Combo box for UserType label and login and cancel buttons and validation
controls (Required field validation).
The user Logs in by filling the UserName, Password and select his user type from UserType
combo box. After filling the form they logs in by clicking on the login button. Then the system
verifies the user and logs in if the user exists in the database of the system. If the user not exists
in the database of the system, error message is displayed and the user not logs in. The user types
are Employee, Department head, college dean, VPASS/AVP; purchase Head, Purchaser, supplier
and Administrator.
The snap shoot of the login pages are as following:
If the user does not fill the forms before submit or if the user is does not exist in the system, the
error message is displayed.
19 | P a g e
Snap shoot of the login page that generate error message are as following:
20 | P a g e
The other user interface of the system is user registration forms that register the user for the
system. To use the system, every user should have its own account. The administrator is
responsible for user registration by filling user name, password, confirm password and user type.
The following are the snap shoot of the user registration form:
If user name, password or user type is not filled or not filled properly, the error message is
generated as follow:
21 | P a g e
22 | P a g e
The other user interface of the system is the purchase requisition form that is used by the
employee to initiate requests. After Employee logged in, they can initiate request. To generate
requests an employee should fill all the forms properly and submit it after that the department
head get it and approve.
The snap shoot of the purchase requisition form are the following:
If the purchase requisition form is not filled properly, i.e. if there is a field which is not filled
before submit, the error message is displayed as follow:
23 | P a g e
The other user interfaces of the system are discussed in the design detail topic in chapter 8.
24 | P a g e
3.1.2. Hardware interface

Hardware interface of our system are clients and servers. Clients are each and every computer
that have browser to connect to the system.
Server is the computer that has the database for our system and performs the validation of the
user, receive request of employee/requester/, process the request and respond to the client as
necessary.
3.1.3. Software interface

The software interface of our system is database of the system and operating system that is
essential for the system to operate within the hardware interface. The database of the system is
created by SQL server 2008 and it is connected with the visual basic 2010 where the front end of
the application is developed. The operating system used is windows operating system version
7/8.
3.1.4. Communication interface

The communication between the different parts of the system is important since they depend on
each other. However, in what way the communication is achieved is not important for the system
and is therefore handled by the underlying operating systems for both client application and
server applications.
3.2. Functional requirements
3.2.1. User class1: User
3.2.1.1. Functional requirement 1.1

ID: FR1
TITLE: User registration
DESC: To use the system any user should first register and have his/her account. The user
should provide their username and password to register.

ID: FR2
TITLE: User login
DESC: After the user has registered to the system, then the user should be able to login to the
system where the user is authenticated whether he is authorized user or not.
25 | P a g e

ID: FR3
TITLE: Initiate request
DESC: Given that the employee is logged in, each employee can send his/her resource
requisition to their department. The employee fills the form of resource requisition by providing
each and every required information, including the resource type, amount, name, quantity, unit
costs, total costs, description of the resource and etc.

ID: FR4
TITLE: View status
DESC: The employee can see the status of the request they send to their department head 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.

ID: FR5
TITLE: Help
DESC: The user can get help that are provided by the system to use the system easily.

ID: FR6
TITLE: View the report of request
DESC: Given that the user is logged in, he/she can get the reports of the requests that are
forward from other users.

ID: FR7
TITLE: Approve the request
DESC: Getting the reports of the request, user can approve the requests either by accepting it or
rejecting it.

ID: FR8
26 | P a g e
TITLE: Forward approved request
DESC: Given that the user approved the request (i.e. request accepted), the user should send the
request to the next level for more approve.

ID: FR9
TITLE: Send the request status
DESC: After approving the request the user should send the status of the request to the other
user who forwards the request to make them to identify as their request is accepted or rejected.

ID: FR10
TITLE: Registering the bidder
DESC: After all approval, the purchase head decides the purchasing process and if purchasing
process should be by bid, the system posts the bid announcement and register the bidder for
competing them. If costs of the resources are not more than 100,000 birr the purchase order can
rose normally i.e. it is bought from suppliers by collecting some Performa of the costs of that
resources, but if the cost of the resources is more than 100,000 birr bid process take place by the
rule and regulation of the auction of the Ethiopian federal government of purchasing.

ID: FR11
TITLE: Bid evaluation result
DESC: After the competing of the bidder is taken place by bid evaluation committee, the
evaluation result should be announced to the bid winner.
ID: FR12
TITLE: Raise purchase order
DESC: After registering the bidder, competing them and telling the winner, the system raise
purchase order to buy the resources from suppliers.
27 | P a g e

ID: FR13
TITLE: Inspection
DESC: After purchasing the resources the system inspects that the purchased items are those
requested based on the specification of the resources requested.
ID: FR13
TITLE: Register resources
DESC: After purchase order raised the system register the provided resources.
ID: FR15
TITLE: Notify requester
DESC: After purchase resources are purchased and registered to the data base, the system should
inform the requester to collect his/her resources.
3.2.2. User class 2: Administrator

ID: FR16
FEATURE: Manage other users of the system
In order to keep track of the users an administrator should be able to manage the users
Scenario: Edit an existing user’s information
Given the administrator is logged in When the administrator edits an existing user then the user
information should be updated.
Scenario: Delete/Inactivate an existing user
Given the administrator is logged in When the administrator deletes an existing user then the
user should be deleted.
28 | P a g e
3.3. Behavior requirements
3.3.1. Use case view

The actors of our systems are the following:
o Requester / Employee/
o Department head
o College dean
o AVP(Academic Vise President)
o VPASS(Vice president for Administration and student services)
o Purchasing department
o Administrator
o Suppliers
o Purchaser
Use cases of the system are the following:
o Registration
o Login
o View status
o Retrieve password
o Manage all users
o Initiate request
o View request
o Approve the request
o Check budget
o Forward the request
o Registering the bidder
o Bid evaluation result
o Raise purchase order
o Register the resources
o Notify the requester
29 | P a g e
Use case diagram for the purchasing management system are the following:
Fig.3.1 Use case diagram 1
30 | P a g e
Fig.3.2. Use case diagram 2
31 | P a g e
Description of the use case diagram
Use case Login

UC ID UC1
Actor Employee, Detp.head, college dean, purchase head, VPASS/AVP,
administrator, purchaser & supplier
Basic course of 1. The actor click login menu bar
action 2. The system prompts the user to inter username and password and
select account type
3. The user enter the above login information
4. The system Validates the entered information.
5. The system Recognize the user.
6. use case end
Alternative course of A4) Entered User name or password is Invalid
action A5) The system informed the user an error message
A6) go to step 3
A7) end use case
Use case Registration

UC ID UC2
32 | P a g e

Administrator, Purchaser & Supplier
Basic course of 1. The Administrator click Register user menu bar
action 2. The system prompts to inter username and password and select
account type
3. The Administrator enter user name, password and select account
type
4. The system Validates the entered information.
5. The system registers the users.
6. use case end
Alternative course of A4) Wrong user name and password inserted or user name and password
action not inserted
A5) The system informed the user an error message
A6) go to step 3
A7) end use case
Initiate request
Use case
UC ID UC3
Actor Employee
Basic course of 1. The Employee fill the requisition form
action 2. The Employee submit the form
3. The system check the submitted forms
4. The system saves the requests to the request database.
5. The system send the success message to the employee
6. use case end
Alternative course of A4) Submitted forms are incorrect
action A5) The system prompt the employee to fill the form again
A6) go to step 1
Use case Approve the request

UC ID UC4
Actor Detp.head, college dean, purchase head, VPASS/AVP
Basic course of 1. The Dept.head click approve request menu
33 | P a g e
action 2. The Dept.head decide to accept or reject the request

3. Forward the accepted request to college dean
4. The college dean view the request
5. The college dean decide to accept or reject
6. Forward the accepted request to AVP/VPASS
7. AVP/VPASS view the request
8. The AVP/VPASS decide to accept or reject
9. Forward the accepted request to purchase head
10. The purchase head view the request
11. The purchase head check the budget
12. Use case end
Alternative course of A3) Request rejected
action A4) The system informed Employee as request rejected
A5) end use case
B6) Request rejected
B7) The system inform Dept.head as request rejected
B8) Use case end
C9) Request rejected
C10) The system inform College dean as request rejected
C11) Use case end
D12) Request rejected
D13) The system inform AVP/VPASS as request rejected
D14) Use case end
Use case Retrieve password

UC ID UC6
Administrator, purchaser & supplier
Basic course of 1. The actor select retrieve password menu (option)
34 | P a g e
action 2. The user fill the retrieve password form

3. The user submit the form
4. The system validate the inserted data
5. success
6. use case end
Alternative course of A5) System provide Failed message
action A6) The continues from step 2
A7) end use case
Use case Manage all users

UC ID UC7
Actor Administrator
Basic course of 1. The actor select manage users menu (option)
action 2. The actor select manage operations
3. The Administrator perform the operation
4. The system validate the inserted, deleted, updated or selected data
5. Success message sent to Administrator
6. Use case end
Alternative course of A5) System provide Failed message
action A6) The use case continues from step 3
A7) end use case
Use case Raise purchase order

UC ID UC8
Actor Purchaser
Basic course of 1. The purchaser raise purchase order to supplier
action 2. The purchaser fill purchase order form
3. The system validate the filled form
4. Identify the supplier
5. Local suppliers provides resources
6. The purchaser collect the resources
7. Use case end
Alternative course of A4) Failed message sent to the purchaser
35 | P a g e
action A5) Use case continues from step 2

B5) foreign supplier provides the resources
B6) The use case continues from step 6
Chapter 4
4. Other non-functional requirement
4.1. Performance requirements

The requirements in this section provide a detailed specification of the user interaction with the
software and measurements placed on the system performance.
Usage of the information link: the information link should be prominent and it should be
evident that it is a usable link. Selecting the information link should only take one click.
Response time: the fastness of the search
4.2. Safety and Security requirements
Communication Security: Security of the communication between the system

and server.
Employee login securely: If an employee tries to log in to the system with a non-
existing account then the employee should not be logged in. The employee should
be notified about log-in failure.
36 | P a g e
Department head login securely: If department head tries to log in to system

with a non-existing account then the department head should not be logged in and
he/she should be notified about log-in failure.
College dean login securely: If college dean tries to log in to system with a non-
existing account then college dean should not be logged in and he/she should be
notified about log-in failure.
Purchase head login securely: If purchasing head tries to log in to system with a
non-existing account then the purchasing head should not be logged in and he/she
should be notified about log-in failure.
Administrator login securely: If administrator 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.
User Create Account Security: The security of creating account for users of the
system. If a user wants to create an account and the desired user name is
occupied, the user should be asked to choose a different user name.
4.3. Software quality attributes
4.3.1. Flexibility
The system is flexible for all users when they inter the correct login form.
4.3.2. Correctness
The system provides correct response to the correct request.
4.3.3. Adaptability
The system interface that will develop is attractive and easily understand to the users reflect the
adaptability of the system.
4.4. Reliability
The data or information which is retrieved from the system is accurate (required) in deserved
time.
4.5. Availability
The system is available for the user whenever there is an internet connection.
37 | P a g e
4.6. Maintainability
The application should be easy to extend. The code should be written in a way that it favors
implementation of new functions, in order for future functions to be implemented easily to the
application
4.7. Portability
The application should be portable with windows 7 and windows 8.
Chapter 5
5. Analysis Model
5.1. Sequence diagram
38 | P a g e
Fig. 5.1.1 sequence diagram of user login to the system
Flow of action events for sequence diagram of user login
1. The user fills login form to login to the system

2. The user clicks on the submit button to submit the login form
3. The submit button give response to the user by checking whether the form is filled
4. If user enters wrong user name or password, error message display
5. The user enter correct data again, the account data base after check return success
message to the user
6. Sequence diagram end
39 | P a g e
Fig.5.1.2. Sequence diagram for Administrator register users
Flow of actions for this sequence diagram is:
1. The Administrator click Register user menu bar
2. The system prompts to inter username and password and select account type
3. The Administrator enter user name, password and select account type
4. The system validates the entered information.
5. The system registers the users.
40 | P a g e
Fig.5.1.2 sequence diagram of employee requisition form
Flow of action events for sequence diagram of employee requisition
1. The employee fills request ion form to initiate request

2. The employee clicks on the submit button after finishing filling the form
3. Form controller initiated
4. If the there is error, failed message displayed
5. If there is no error, the controller get data to the request database
6. Success message sent to the employee
7. Failed message sent to the employee if there is error during saving
41 | P a g e
Fig.5.1.3. sequence diagram of department head approve the request
Flow of action events for sequence diagram of department head requisition
1. The department head views request

2. The department head approve the request
2.1. The accepted request saved to dept. Approved request database
2.2. If the requisition is reject, rejection message sent
3. Success message sent to department head after saving data
42 | P a g e
Fig.5.1.9. sequence diagram of purchaser collect resources
Flow of action events for sequence diagram of purchaser collect resources
1. The purchaser collect resources from suppliers

2. The supplier fill purchase order form
3. Purchase order form controller initiated
4. The form controller check the form
5. If there is an error ,error message sent
6. If there is no an error message ,success message sent
7. Suppliers click submit to save resource to database
8. resource database saved the data
9. success message sent at the end
43 | P a g e
Fig.5.1.3. sequence diagram of users retrieve password
44 | P a g e
Fig.5.1.7. sequence diagram of Administrator manage the users
Flow of action events for sequence diagram of administrator manage the users
1. The administrator manage the account of the users from database

2. The account database update
3. The account database send message, if error occurred while updating
4. The account database manage the employee database
5. Employee database update
6. Employee database send failure message, if error occurred
7. Employee database send success message, if no error
45 | P a g e
5.2. Data flow diagrams (DFD)

Context free diagram
College dean
Dept.head
Approved request VPASS/VP
Approve request
Approved request
0
Initiate request Check budget
Purchase head
Employee Budget response
Request status HUPMS
Manage user
Register Manage response
Register resource Register response Administrator
Supplier Register response
Purchaser
46 | P a g e
Level 0 DFD
1.0
Fill requisition form Request detail
Employee D1 Requested resources
Initiate request
Request detail
Dept.head
2.0
View request
View request
College dean
Approve request
Approved request
View request
VPASS/AVP
5.0
Purchase head
4.0
Raise purchase order
Purchase Item Purchase order
Select Supplier
Approve budget Purchaser
Budget approved
3.0
Purchased resources
Supplier information
Check budget
6.0
Store
D2 Purchased resources
Supplier
Register resources
7.0
Administrator
Manage user
47 | P a g e
Approve request level 1 DFD
48 | P a g e
Select supplier level 1 DFD
4.1
Supplier Supplier detail
Supplier information D7 Supplier
Register supplier information
Supplier detail
Evaluation result 4.1

4.2 Evaluation criteria
Supplier evaluation
Supplier selection
Supplier detail
D8 Selected supplier
49 | P a g e
Raise purchase order level 1 DFD
Raise order
5.1
Order
Purchaser
Supplier
Purchase order
Registration Ordered resource

Response
5.2
5.3 Resource detail
Deliver resource
Registration of
resource
50 | P a g e
Manage user level 1 DFD
User 7.1 7.2

control
Operation Select
Administrator D9 Account
Manage response Select user Select user
Operation
7.3
Add
D10 Account
Add user
7.4
Update
D11 Account
Update user
7.5
Delete
D12 Account
Delete user
51 | P a g e
5.3. State transition diagram

State transition diagram of user registration
click registration
registration form
re registration
submit
error
Validation Failed
success after failed
registered
Create account
State transition diagram for login
Click login
fill login form
Submit
error
Success logout
validate logs in
52 | P a g e
State transition diagram for retrieve password
retrieve password
Enter password
re retrieve password
submit
error
Validate password Failed
success
Change password not re retrieve
password changed
53 | P a g e
State transition diagram for initiate request
initiate request
Requisition form
re initiate request
submit form
error
Validate form Invalid form
success reject
request stored
Request send
54 | P a g e
State transition diagram for approve request
view request
rejected
Approve request Inform requester
accepted
after inform
Forward request
after forward
55 | P a g e
Chapter 6
6. Design consideration
6.1. Design goals

The goal of design in this system is to simplify the complexity of the operations of the system.
Within a design a system is easy to understand. The design goals that are derived from non-
functional requirements are the following:
Flexibility
The system is flexible for all users when they inter the correct login form.
Correctness
The system provides correct response to the correct request.
Reliability
The data or information which is retrieved from the system is accurate (required) in deserved
time.
Availability
The system is available for the user whenever there is a connection between clients and servers.
Maintainability
The application should be easy to extend. The code should be written in a way that it favors
implementation of new functions, in order for future functions to be implemented easily to the
application
Portability
The application should be portable with windows 7 and windows 8.
56 | P a g e
6.2. Design trade-offs

Conceptual design involves a series of tradeoff decisions among significant parameters - such as
operating speeds, memory size, power, and I/O bandwidth - to obtain a compromise design
which best meets the performance requirements. Factors which can be used to evaluate the
design tradeoffs (usually on a qualitative basis) of the system include:
 Expandability: The system is ability to conveniently accommodate increased

requirements by higher speed or by physical expansion, without the cost of a
major redesign.
 Maintainability: The system should be maintainable to recover from malfunction
 Compatibility: Should be developed between the system and its interfaces
 Adaptability: ability of the system to meet a wide range of functional
requirements without requiring physical modification
 Availability: is the probability that the system is operating satisfactorily at a
given time
 Development Status and Cost: are complex management-related factors which
can have significant effects on the design
6.3. Assumptions and dependencies

One assumption about the product is that it will always be used when server is Accessible only.
If there is no LAN connection between server and clients, the system is not Accessible.
The other assumption of the product is when the server fails; the whole system is going to fail as
well.
6.4. General constraints

The following requirements are general constraints of the system:
 Lack of fast internet connection
 Lack of resource like computer
 Lack of online payment system
 The system operate only in English language
 The system only work when electric power is available
57 | P a g e
Chapter 7
7. System decomposition
7.1. Subsystem interaction
Registration
Login
Employee Dept.head College dean VPASS/AVP
Purchaser Supplier Purchase head
Initiate
request
Administrator
and forward and forward Approve request
and forward
Check budget
Supply resources Collect and register
resources
Manage all users
58 | P a g e
Chapter 8
8. User interface design
8.1. Class diagram
Employee Purchase requisition Request DB

1 1
-name: string -requester name: string -requester name: string
-id: int -id: int -id: int
1
-password: string * -department: string -department: string
-address: string -resource: string -resource: string
-department: string -quantity: string -quantity: string
-description: string -description: string
+initiate request (): string -unit cost: string -unit cost: string
-total cost: string -total cost: string
-date required: string -date required: string
+check form (): string +save request (): string
User
Login Account DB
-name: string -user name: string -user name: string
-id:int -password: string 1 -password: string
-password: string -user type: string 1
-user type: string
-address: string 1
-department: string * 1
+validate user (): string
+submit form (): string +logs in user (): string
1
1
*
1
Registration
1 * 1
-user name: string
Administrator
-password: string
-name: string -user type: string
-id: int
-password: string +validate user (): string
-address: string +register user ():
-department: string string
+manage users (): string
59 | P a g e
8.2. Detailed design
The design of the user interfaces of the system are discussed as the following:
After the employee logged in and initiated requested, it can see the request status by using the
following interfaces, selecting their department and filling the requisition number of the request.
The next interface is the view and approve request interface that are used by department head,
college dean and VPASS/AVP to view, approve the request and forward the approved request to
the next level.
The system fetches the requests from the stored request database and displays it into the
following forms. After that the authorized user accepts the request by clicking to accept button or
reject it by clicking on the Reject button and if the request is accepted, it is forwarded to the next
level.
The snap shoot of the view, approve and forward request interface is the following:
60 | P a g e
The other interface is bidder registration. After the end of approval, the purchase department
selects a purchasing process among bid and normal supplier and if the purchasing process should
be bid, the suppliers should be registered. To register the bidder the following form are used:
61 | P a g e
After registration to the bid process, the bidder can get the result of the bid evaluation using bid
evaluation interface. To see the result they have to inter the bid number that are given to them
when they registered.
62 | P a g e
The purchase order form that are raised aftre identification of the supplier and selecting them, is
used to purchase the items (resources) from the selected suppliers. The snap shoot of the
purchase order is as follow:
63 | P a g e
When resources are purchased they should be registered to the property database. The following
is the resource registration form snap shoot.
64 | P a g e
The other user interface of the system is user retrieve password interface that is used by the users
to retrieve their password.
The snap shoot of the user retrieve password interface is:
65 | P a g e
66 | P a g e
8.3. Entity relationship
Entity
o Employee
o Dept.head
o College dean
o VPASS/AVP
o Purchase head
o Purchaser
o Supplier
o Administrator
Attribute of entity
Employee
 Emp name
 Emp ID
 Emp dept.
 Password
 Address

Dept.head
 Name
 ID
 Department
 Password
 Address
College dean
 Name
 ID
 Department
 Password
 Address
VPASS/AVP
 Name
67 | P a g e
 ID
 Password
 Address
Administrator
 Name
 ID
 Password
 Address
Purchaser
 Name
 ID
 Department
 Password
 Address
Supplier
 Name
 ID
 Password
 Address
68 | P a g e
Preliminary design
Name Address Name Address

ID
ID
Employee Password
Dept. head
Password
Department
Department
Address ID
Name Address Name
ID
Address
VPASS/AVP Administrator
Password ID
College dean
Password
Password
Department
Name
Name Address
Name Address
ID ID
Purchase
Head Supplier
Password
Purchaser
Password
Department
Name Address Department Password
ID
Relation ship
Employee initiate request to Dept.head
Dept.head approves and send request to college dean
College dean approves and send request to VPASS/AVP
VPASS/AVP approves and send request to Purchase head
Purchase head order purchaser
Purchaser collects resources from supplier
Administrator manages all users
Over all Entity relation diagram
69 | P a g e
70 | P a g e
Chapter 9
9. Appendix
71 | P a g e
Chapter 10
10. Glossary
Accessibility-able to be accessed
Automation-the user or introduction of automatic equipment in a manufacturing or

other process or facility
Bandwidth-a range of frequency especially one used in telecommunication capacity of

a computer net work
Bid-offer a certain price for something at an auction
Bidder-is a person who participates in an auction
Budget-an estimate of income and expenditure for a set period of time
Compatible-able to exist or be used together without problems or conflict
Competing-strive to gain or win something by defeating or establishing superiority

over others
Deliver-bring and hand over goods to the appropriate recipient.
Malfunction-fail to function normally

Menu-a list of commands or facilities, especially one displayed on the screen
Purchase-is a process of buying goods, different items for the acquisition of property
by one’s
Purchaser-a person who buys goods from the supplier
Request-is an act of asking formally for something
Scenario-a written outline of stage work giving details of the plot and individual scenes
Scope-the extent of the area or subject matter that something deals with or to which it is
relevant or the opportunity or possibility for doing something
Supplier-provide resource for requests that needed
72 | P a g e
73 | P a g e

New Project Documentation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

New Project Documentation

Uploaded by

Copyright:

Available Formats

PURCHASING MANAGEMENT SYSTEM

Software Requirement Specification for

Advisor: Mr. Abdisa Kebede

Date: January, 30, 2014

3.3.1. Use case view....................................................................................................................29

8.3. Entity relationship......................................................................................................................67

 Overall description of the project

1.1. Documentation purpose

The purchasing management system works as follow:

1. Employee / Requestor initiates request by filling purchase requisition form with

1.2. Product scope

1.2.2. Out scope

Benefit of the project

Ensure data accuracy’s.

Administrator controls the entire system.

Minimize manual data entry.

User friendly and interactive.

Minimum time required.

The specific objectives of the project are:

 To overcome the manual resource requisition of the department (section)

 To provide the fast reply(resource providing) of the purchasing department

 Creating fast and comfortable resource requisition forms.

 Providing reliable and fast approve of the requested resources

 Reducing the time delayed for resource request

 Reduce costs that are used for the resource requisition

 Familiars the people with the new technology

 Automating the database system

 Provide transparency in work flow

Goal of the project

1.3. Intended audience and document overview

The users of this system (products) are the following:

Employees of Haramaya University

1.4. Definitions, acronyms and abbreviation

Dept.head- Department head

DFD-Data Flow Diagram

HUPMS-Haramaya University Purchase Management System

LAN-Local Area Network

RAM-Random Access Memory

SRS- Software requirement specification

SQL-Structured Query Language

SVGA- Super Video Graphics Array

VGA-Video Graphics Array

VPASS- Vise president for Administration and Student services

1.5. Reference and acknowledgment

2.1. Product perspective

Data base Server

Fig.2.1 General Diagram of purchasing management system

2.2. Product functionality

Generally, the product functionality is described as follow:

Approve request Approve request

Register Manage response

Register resource Register response Administrator

Supplier Register response

Fig.2.2 The context free diagram of the system

2.3. Users and characteristics

Employees of Haramaya University

The most important users of the system

The less important users of our system

Processor : X86 Compatible processor with 1.7

Request approved by Request approved by

AVP approve request? NO Reject message sent NO

Register bidder YES Cost >100,000 birr?