Chapter one: Introduction

Complaint is disagreement with the set of rule. Complaint management

system is a set of integrated tools optimized to meet efficient handling of
complaints and automated process like registering new complaints, managing
existing complaints by respective person. Complaint management system is
protected from unauthorized system access by its user management model. Its
logging facility ensures complete management control over its usage. This
ensures that the system is used to meet its purpose. The key to building the
university community relationship is to create superior value and satisfaction
which can be achieved through effective complaint management system.
Complaint management system can manage the entire complaint or appeal
handling process. Poor communication can result in poor service being
provided by the university. Therefore the university needs to develop its
internal and external communication towards its users to achieve success.
Every day user logged their complaint because of feelings dissatisfied in
direct or indirect accusation such as face to face complaints, telephone
complaints, complaint latter, and massage on the web, all the complaints
should be accepted and properly cared.

1.1 Background of the organization

1.2 Background of the project
Complaint management system is a new system in HU it can solve all the
problems with in the university which held due to the manual system. We
have considered the entire problem with in the system to come on solution.
Our new system can solve the existing problem as much as possible. The team
try to cover the main functionality of the project such as make complain, view
complain, receive response, forward complain, register new user and so on.
Generally we considered the background of the system, we realized all the
problems in the system, we viewed solutions to those problems and we have
collected data in many ways about the existing system, we also used many
 methodologies to get facts about the system. We are also using different
hardware and software tools to develop this project. According to our
consideration the complaint management system can solve the problem of the
organization and provide enough service in a short period of time at any point
regarding the problems they are facing.

1.3 Statement of the problem

Currently the university is facing many problems due to the use of manual
system in its day to day activity. Since the system is handled manually used
and no organized database there is Lack of availability, use vast amount of
human power, no proper solution for complaints, no security in the documents
of the system, data modification is very difficult and searching for complaint
information (records) is difficult to get, the university community give their
complain write on the paper and put it in the box and the university
community has to visit the one who is responsible for complains whenever
they have any complaints regarding to the problem they face so this wastes lot
of time and generating report is late in manual system because individual
activities write on paper during this time consume more time and other
resource such as paper, pen, time etc. so it is difficult to give response for the
complaints and to make complain.

1.4 Objective of the project

1.4.1 General objective
The main objective of this project is to develop compliant management
system for the Haramaya University and change manual system to web
based and mobile based system.
1.4.2 Specific objective
To achieve the above mentioned general objective, the system will address
the following specific objectives:
 • To Analyze the existing system and design better system for the
university
• To design and develop a user friendly system to handle data insertion,
updating, deletion, retrieving on the database.
• To store all data’s of the applicants into the database.
• To design the interface for the system
• To create complain login page for Haramaya University community or
students, teacher, department head, facility heads etc.

• To create user registration form

• To design mobile application for the client side
• To design generate report form
• To develop a secured Database to register and perform the decision
activity.

1.5 Scope of the project

This project is focus only in Haramaya University. All students, teachers,
academic staffs, administrative employee, applicants and those who have
complaints in the university to query and enter their information only, but
our project do not work for other organization because the structure of HU
and other organization is not the same and we have not enough time to do
for other with budget.

1.6 Significance of the project

This project having the potential to reduce the gap between the university and
student, academic and administrative employee and a desired significance to
Haramaya University This system also has the following significance:

• Increasing speed of activity of complaint because the current system is slow.

• To get information on time.
• Improve complaints moral regarding to the fulfillment of their needs.
• To help the complainers getting their problems solved in online without
going to the office regularly until the problem is solved. By this system the
user can save his/her time and eradicate loss of human power.

• To make easy and suitable distribution of solutions and reports to registered

complaint.
• Creating better working environment for complaint.
• To express their feelings freely
• Can use the information that is captured to make process improvement.
• To satisfy the university community.

1.8 Methodology
The purpose of the methodology is to give an experienced investigation
enough information to replicate the study.
For conducting our project we used the following methodologies
1.8.1 Data gathering methodology
We will use observation and interviewing for data gathering because these
data gathering methodology are best to understand the problem and to find
a best solution

• Observation:- To understand directly how the existing working system

currently, we have used observation and this technique helps to
understand problems raised by the current working(direct contact or
complaint box) system of the university. We observed compliant
interaction with the university.

• Interviewing: - Most analysts use interviewing as a primary way of

gathering requirement in information system projects. We will be
interview head of the department, student, and registrar office to gather
facts, opinions, and truths of users about the current system.
 1.8.2 Developmental methodology
We will be use object-oriented methodology instead of structured approach,
object oriented approach is use for the project because it is more acceptable
due to its great advantage of Polymorphism, Abstraction, Encapsulation,
Modularity, inheritance, Hierarchy, Concurrency,
Persistence, etc. in terms of its:
• Increased Extensibility

• Increased Reusability

• Improved Quality

• Lesser maintenance cost and burden

• Less complexity and application backlog

1.8.3 Developmental approach

There are many developmental approaches:-
• Waterfall (linear)
• Prototype (iterative)
• Evolution (incremental)
• Spiral

Among these developmental approach we select Evolution

(incremental) because:-  The whole requirement is divided

in to various builds.

 Each subsequent release of the model adds function to the previous

release.
 This model is more flexible less costly to change scope and
requirement
  It is easier to test and debug during a smaller iteration

1.8.4 Development Tools

Tool of our project contains hardware and software which is used to
develop the system in proper ways.
1.8.4.1 Hardware requirements
Different hardware tools are used to develop our project.
• Computer: - used to install software’s that are necessary for our work
like MS word, visual basic and to do other tasks related to our work.

• Printer: - for printing documentation

• Network cable: - we used twisted pair cable to get the internet access
which is used us to get many information about our project.

• Flash disk and CD: - used for the movement of data from one machine
to another  Memory: Recommendation: 2GB RAM.
• Hard disk: to keep the permanent data.

1.8.4.2 Software requirements

Different software tools are used to develop our project.
• Operating system: window 7 or window 8 is recommended
• MS word: -used to write the proposal of our project
• Microsoft Power point: - use to present the document in abstract forms.
We use it to present our presentation in short and brief way.

• Edraw: - it is object oriented modeling tools. For designing UML

diagrams, user interface associated with the project.

• Php: -used to write at the fore end because it has fast load time, less
expensive and hosting, flexible for database connectivity to design
attractive user interface.

• MYSQL server:- for database at the back end since it is powerful

database management system software and easily integrated with vb.net.
• Adobe photo shop cs4: -used to edit images used in our project.

1.10 Feasibility Study

These complaint management system have an economic and operational
standpoint. A comprehensive feasibility study of operational, economic and
technical aspects has also been made and implemented as below:-

1.10.1 Operational Feasibility

The service of complaint management system is flexible and expandable.

By looking this flexibility and expandability users support this system. If
some serious problems occurred, the system will be easily maintained by
the team. And the user will also maintain the system by reading training
manual that has been given for them. Therefore, the system is designed to
be operationally feasible. That means, the system can operate in any kind of
platforms without any mal functionalities. Any user can access the data or
file as he/she have access right.

1.10.2 Technical Feasibility

For the future, our campus strongly wants to buy hardware and software
like computers, servers, operating systems, and they are also voluntary to
host the system. This system is easily upgraded to provide the necessary
information for the users and users use the system without any difficulty,
therefore the system is technically feasible.

1.10.3 Economic feasibility

Our system is economically feasible, because it reduces the time needed to
perform certain actions such as budget to cover man-power, paper, pen, it
 reduces budget to buy the software for complain management system for
the HU which they are using for manual work.

1.11 Project plan

1.11.1 Time schedule plan
Table 1: Time schedule plan
s.n Phase 1st quarter 2nd quarter 3rd quarter 4th quarter 5th quarter
o
1 Introduction Nevober4
Nevonber11/20
10
2 Requirement Nevober13
elicitation Nevonber25/20
10
3 System Nevober27
analysis desember10/20
10
4 System design Desember20
January15/20
10
5 Conclusion January 21
and January25/2
recommendati 10
on
Table 2: Giant chart
S.N Phases 1st quarter 2nd quarter 3rd quarter 4th quarter 5th quarter
o
Nevober4 Nevober27 Desember20 January 21
Nevonber11/20 Nevonber25/20 desember10/20 January15/20 January25/
10
 10 10 10 10
1 Introduction
2 Requirement
elicitation

3 System
analysis
4 System
design
5 Conclusion
and
recommendati
on

Remarks: Start End

1.11.2 Budget plan
Table 3: budget plan
No Item description Quantity Price(birr)
1 Computer or laptop 2 24,000
2 Paper One full pack 150
3 Flash 1 150
4 Print ----- 400
5 Pen ------ 100
6 Tea break ------ 300
7 Other material ----- 3000
8 Total cost ---- 28,100
Chapter Two: Requirement Elicitation

2.1 Introduction
Requirement is a feature that the system must have or constraint that it must
be accepted by the client and requirement elicitation-focus on describing the
purpose of the system.
The main objective of this part is to study the nature of the system in detail
and identify the problem as well as to define the relevant way to design a new
system for Haramaya University. When we were analyzing the existing
system of HU complain, we have tried to study the detailed nature and
procedure of the tasks and operations performed. By having this analysis over
the system we will try to explain the tasks performed:
In this chapter we try to describe the existing system its business rule,
advantage and disadvantage of the existing system for it weakness we propose
a solution and select the preferred one for this project try to describe the
existing system using domain modeling with CRC card and draw a use case
diagram and describe it using a table at the last of this chapter we insert a
photo of the a existing system how it accept complains using essential user
interface prototype.

2.2 Existing system description

In the existing system the university community (student teacher other HU
workers) must go to the office for any kind of help. For complaining about a
problem there is a system called manual or comment box in which the
complainers can write their problems on raphe paper, go directly to office for
their complain, and use a form and fill it their complain then put it on the box
and even for simple information they should go to office because of the
 unavailability of compliant management system in our university. The
complaint was opened by the secretory or other person the one who was not
concerned with so the complaint was not go to the concerned body. Since the
existing system works on paper based it is difficult to search, store and get
complainer information easily, doesn’t have much popularity and is not user
friendly and the major function of the existing system is accepting the
complaint may be the complaint was not seen by the appropriate person and
for the seen complains give the answer directly or indirectly.

2.3 Business rule

• There is boxes around some area used to collect comments 

Comment box is opened by an authorized person only.
• The box opened once per a week.
• After opening the box they give answer complains if they can’t
answer transfer complains to the authorized person.

• The complainer must write and put it on the comment box or go

physically and tell complain.

• Complainers must be member of HU community.

• The report is generated by the person during the meeting time.

2.4 Advantage of the existing system

The advantage of the existing manual system is:-
• Not use network or smart devices for complain it only use paper
for writing the complaint.

• It accept complains

2.5 Disadvantage of the existing system

• No quick data searching facility for useful information
• No proper management of information
• Data are store physical file
• Possibility of loss complaint record complaint handle so there is
possibility to loss of complaints because of the transferring complains
record between different physical levels  Lots of paper work.
• Time consulting problem. There is no proper management procedure
for a complaint inquiry for university community.

• The comment box is opened once per a week so they do not give
answer fast.
• Most of the time the comment not read by the proper person and the
complaint so the information do not delivered to the proper person.

• Not on time response or no quick answer

• Performance (Response time) The performance of the existing systems
are very low because all activities can be done in manual form this
manual activity can consume mare time and increase response time of
the system.

• Input (Inaccurate/redundant/flexible) and Output (Inaccurate) since

each activity can be doing in paper form it makes many mistakes like
redundant registration of one person in different department and in
different service.

• Security and Controls In existing system the security mechanism and

control systems are very low. For example if record file could be stolen
or lost all the list comment will be lost.so as we observe its security
mechanism is no sufficient.

• Efficiency In existing system there is no efficiency because all activities

performed manually in the paper. It can reduce the efficiency of the
system. As we observed in existing system to perform some action it
takes more time and a lot of resources and it results economic problem.
2.6 Proposed solution
The proposed system of our project changes the existing manual process of
the organization to new system. To eliminate drawback of the existing
system, the only way is computerization. The new system gives full system
functionality that is needed by system user to perform system functionality.
The new proposed system tries to address the problems that arise in existing
system. Some of the
Problems that solved in new
systems:-
 Easy
access of files.
• Storing and maintaining data in database.
• Gives fast service to the user.
• Fastest response time and higher performance.
• Create automated system that enables the user to search
information easily.
• Reports generated based on information stored in the database.
• Reduce cost that can pay for paper and other files.

• Web based system

It refers to a network Connection using HTTP (Hyper Text Transfer Protocol)
rather than existing with a devices memory.it use client server application
where the system will interact with the system online and store the data in
their server.
2.8 Domain Modeling with CRC card
Table 4: CRC 1 Table 5: CRC 2

Student and employee Head

Responsibili Collaborati
 ty on Responsibility Collaboration
give Has
complain complain Give complain Student and employee
view
View complain
feedback
Give feed back
Forward complain

Table 5: CRC 3
Dean
Responsibility Collaboration
Give complain Head
View complain
Give feed back
Forward complain

Table 6: CRC 4 Table 7: CRC 5

Department assembly Service directors
Responsibilit Collaboration Responsibility Collaboration
y
View Head View complain Student
complain dean Receive complain employee
Give Give feed back
feedback
Forward Forward complain
complain

Table 8: CRC 6
Vice president
Responsibility Collaboration
View complain Service
Give feed back directors
Forward complain Head dean
 Table 9: CRC 7
President
Responsibility Collaboration
View all complain Head
Give feed back Dean
Service directors
Vice president
2.9. Essential use case

Figure 1: essential use case diagram for the existing system

2.10 Essential use case documentation
Table 10: use case documentation for write complain
Name write complain
Identifier UC-01
Description Write a complain
Actor Student and employee
Pre-Condition They must be member of the HU community
Post Condition They write their complain on a given form or raphe
paper or go by them self
Extend None
Include None
Basic course of action
1.The student or employee must write or tell the complaint.
2..put the written comment to the comment box or give for the authorized
person
Alternative course of action
If they don’t write the complain there is no solution for their complain
Table 11: Use case documentation for view feedback
Name View feedback
Identifier UC-02
Description View the answers for the complain
Actor Employee and student
Pre-Condition They must be a member of HU
Post Condition Check the feedback
Extend None
Include None
Basic course of action
 1. They see the answer for their complain.

Alternative course of action

Table 12: Use case documentation for give feedback

Name give feedback
Identifier UC-03
Description Give answer for the complains
Actor Head, dean, department assembly, service
directorate, vice president, president.
Pre-Condition They must be in the position and there must be
complain
Post Condition Replay appropriate solution
Extend None
Include None
Basic course of action
1. They read the complains.
2. Discuss on the complains and give the answers for them
3. If they can’t answer the complains in their position forward them

Alternative course of action

Table 13: Use case documentation forward complains
Name Forward complain
Identifier UC-04
Description Forward complain for the higher class
Actor Head, dean, department assembly, service director, vice
president
Pre-Condition They must be in the position and complain, view the
complaint.
Post Condition Forward the complaint to the concerned body
Extend None
Include None
Basic course of action
1. forward the complaint for the higher class if they can’t solve it

Alternative course of action

Table 14: Use case documentation for view complain

Name View complain
Identifier UC-05
Description View complain
Actor Head, dean, department assembly, service director,
vice president and president
Pre-Condition They must be in the position and complain, open the
comment box
Post Condition Give feed back to the complainer
Extend None
Include None
Basic course of action
1. They open the comment box.
2. And view the complains.

Alternative course of action

The president can see all complains that are given by the student and
employee
2.11. Essential user interface prototype

Figure 2: Essential user interface prototype

Chapter three: System analysis

3.1 Introduction
The development of the proposed model is not only depending on how the
system work it also depend on the working flow process that being identified
and need to be implemented and follow.
In this project, the team used an object oriented system development
methodology because the Object oriented system development approach gives
easier way to break down problems into simple and small components so that
it reduces the vague appearance of the big problem which incorporates two
principal phases. These principal phases are Object-Oriented Analysis and
Object-oriented Design. This chapter discusses the first phase of the
methodology: object oriented analysis (OOA).During Object Oriented
Analysis the following major activities are performed. System Requirement
Specifications (SRS), Use case modeling and documentation (for each use
case identified), and the development of sequence, activity and conceptual
class diagrams and business rule of the new system. The new system changes
the existing working system into new system and provide suitable graphical
user interface.

3.2 Overview of the new system

The new system provide a way of solving the problem faced by university
community by saving time and the ability of providing many of report on the
system and add to facilitate the process of submitting a complaints.
Everything done in more formal and efficient manner. This system act as an
interface between the complainers and the appropriate person that solve the
complain there by enabling them to forward the complaint to the appropriate
person. Hence, making the work easy for both complaint raisers and the
person who resolve the complaints. The new system is to gather and forward
the complaint for resolve complaint that arises in different services given by
the HU.

3.3 System requirement

The following are Functional and Nonfunctional requirements of the
proposed new system that a project team have identified from requirement
use cases associated with each actor and use case interactions.
3.3.1 Functional requirement
Functional Requirements are those that refer to the functionality of the
system, i.e., what services it will provide to the user. Statements of services
the system should provide how the system should react to particular inputs
and how the system should behave in particular situations. Our new system
performs the following tasks.

• Create account
• Login
• Register all HU community
• Update information of HU community
• Delete information of HU community
• View information of HU community
• Write complain
• Write comment
• View feedback
• View complain
• View comment
• Forward complain
• Give feed back
 • Evaluate the service by the given parameters
• Generate report
• Change password
• Forgotten password
• Delete complain
• Edit complain

3.3.2 Non-functional requirement

Those requirements which are not the functionalities of a system but are the
characteristics of system Non-functional requirements pertain to other
information needed to produce the correct system and are detailed
separately. Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development process,
standards, etc.

• User interface: - The system will be implemented using the users

interface. The users are familiar to the system easily.

• Hardware consideration: - the organization should have

computers having typical storage capacity and processing speed.

• Security: - the system should have a security privilege that

secures the system. That means the system can only accessed by
authorized persons and on their privileges. The administrator of
the system monitor over all activity.

• Usability:-The system ability to provide search help is user

friendly.
• Performance: -The system works in efficient manner.
• Supportability: - The system ability to make easily to install and
maintenance.
• Modifiability or Extensibility: - The system ability to add future
functionality.
• Compensability: - The system ability to compose systems from
plug-and-play components

• Reusability: - The system ability to reuse in future system

3.4 System modeling
3.4.1 System use case
Figure 3: Use case diagram for Complain management system

Actors
Complainers: make a complaint against the provided service. The complainer
are Student,
Academic and Administrative employee
Admin: create system users account and manage their privilege
Respondent: manage the complaints cause and actions in the system then
provide solutions. The respondent are head, dean, department
assembly, service directors, VPARA, VPSPBD. President.
3.4.2 System use case documentation
The following consecutive tables show the use case documentation for the
use cases that are illustrated in the above use case diagram. Each table
contains the use case name, the actor which initiates and interacts with the
use case, description of the use case and typical course of events that
show the interaction between the actor and the use case which enable the
team to easily depict the functions of the proposed system. Table 15: Use
case description for login
Use case Login
Actor Student, academic employee, administrative employee, head,
dean, department assembly, service directors, VPARA,
VPSPBD, president, system administrator
Description The user logins to the system.
Pre-condition The user should be registered.
Extend Logout
Include None
Basic course Actor action System response
of action
1. User opens the web page. 2.Login form displayed
3.Enter username and password. 5.validate data entry
4.User clicks on Login button. 6. User’s homepage
displayed.
Alternative 5.1 If the user did not insert correct username and password,
course of system displays incorrect username and password combination
action message.
Post The user is logged in the system and provided with privileges for
condition actions
Table 16: Use case documentation for change password

Use case Change password

Actor Student, academic employee, administrative employee, head,
dean, department assembly, service directors, VPARA,
VPSPBD, president, system administrator
Description The user wants to change the password
Pre-condition The user should be registered.
Extend None
Include None
Basic course Actor action System response
of action
1. User opens the web page. 2.Login form displayed
3. Enter username and 6.validate data entry
password. 7. Successfully changed.
4. User clicks on change
password button.
5. Enter the previous password
and the new password
Alternative 6.1.If the user did not enter the correct previous password display
course of error massage
action
Post The user is open the web page
condition
Table 17: Use case description for forgotten password

Use case forgotten password

Actor Student, academic employee, administrative employee, head,
dean, department assembly, service directors, VPARA,
VPSPBD, president, system administrator
Description The user forgot password
Pre-condition The user should be registered.
Extend None
Include None
Basic course Actor action System response
of action
1. User opens the web page. 2.Login form displayed
3. Enter username and 6.the message will send to e-
password. mail
4. User clicks on forgotten
password button.
5. Enter your e-mail
7.get the password
Alternative 6.1.If the user did not enter the correct email display error
course of massage
action
Post The user is open the web page
condition
Table 18: Use case description for logout

Use case Logout

Actor Student, academic employee, administrative employee, head,
dean, department assembly, service directors, VPARA,
VPSPBD, president
Description After using the system, the user should be logged out from the
system.

Preconditio The user is already logged in..

n
Extend Login
Include None
Basic course o Actor action System response
action f
1. User click logout. 2. the system will go back
to home page

Alternative 2.1.The user logged out.

course of
action
Post condition

Table 19: Use case description for write complains.

Use case Write Complains
Actor Student, academic employee, administrative employee,
head
Description Eligible complainers write complain.
Precondition Complainers must be login before make complain.
Extend None
Include Login
Basic course of Actor action System response
action
1. Clicks write complains 2. System search for
link. displayed form.
3. Choose to whom
5. Display the complaint
complain write and enter details.
complain title, complain
description to make
complain.
4. Click on give
complain button.
Alternative course 5.1 Displayed complain detail.
of action
Post condition The complaint detail should be displayed with open status.

Table 20: Use case documentation for delete complain

Use case Delate complain

Actor Student, academic employee, administrative employee
Description Eligible complainers delete complain.
Precondition Complainers must be login and there must be a complain to
delete.
Extend None
Include Login
Basic course of Actor action System response
action
1. Clicks delete complains 2. System search for the
link. complaint. And view the
3. Choose complain to complain
delate. 4. Display the complaint
5. Click on delete complain details.
button.
Alternative course 4.1 Displayed complain detail.
of action
Post condition The complaint detail should be displayed with open status.

Table 21: Use case for edit complain

Use case edit complain
Actor Student, academic employee, administrative employee
Description Eligible complainers edit complain.
Precondition Complainers must be login and there must be a complain to
edit.
Extend None
Include Login
Basic course of Actor action System response
action
1. Clicks edit complains link. 2. System search for the
3. Choose complain to edit. complaint. And view the
5. Click on edit complain complain
button. 4. Display the complaint
details.
Alternative course 4.1 Displayed complain detail.
of action
Post condition The complaint detail should be displayed with open status.

Table 22: Use case documentation for view feedback

Use case View feedback
Actor Student, academic employee, administrative employee
description Users view received complain.
Precondition Users login the system.
Extend None
Include Login
Basic course o Actor action System response
action f
1. Click on view feedback 2. Display the feedback
link
Alternative 2.1.Notify the user if there is feedback
course of action
Post condition If there is no feedback do not notify

Table 23: Use case for evaluate performance of services

Use case Evaluate service performance

Actor Student, academic employee, administrative employee
description Eligible complainers evaluate the service.
Precondition Complainers must be login before to evaluate the service.
Extend None
Include Login
Basic course of Actor action System response
action
1. Clicks evaluate service 3. Display evaluation
link. parameters.
2.Select the service to 7. The system check if the
evaluate 4. The users box was picked or not.
evaluate the service by
given parameters and check
the box.
6. click on evaluate button
Alternative course 7.1. If the given parameter was not checked display error
of action message.
Post condition

Table 24: Use case description for View Complains

Use case View Complains

Actor Head, dean, department assembly, service directors,
VPARA, VPSPBD, president
description To view complains.
Precondition The listed actors must be login to view complain.
Extend None
Include Login
Basic course of Actor action System response
action
1. Click view complains link. 2. Display complains details.
Alternative course 2.1 If there is no any complain the system display no
of action complain message.
Post condition The complaint detail should be displayed with open status.
Table 25: Use case description for give feedback

Use case Give feedback

Actor Head, dean, department assembly, service directors, VPARA,
VPSPBD, president.
description To give feedback for the complains
Precondition The user should login the system.
Extend None
Include Login
Basic course Actor action System response
of action
1.Click on give feedback link. 3. Display a box for response
2.view the complain complains for complainers.
4. Write the response and click on 5.Display
submit button. acknowledgement
message.
Alternative 4.1 If there is no complains there Is no need give response.
course of
action
Post Complain should be sent to wanted staff.
condition
Table 26: Use case description for Forward complains.

Use case Forward complains

Actor Head, dean, department assembly, service directors, VPARA,
VPSPBD.
description To forward complains.
Precondition The user should login the system.
Extend None
Include Login
Basic course Actor action System response
of action
1. Click on forward complains. 2. Display complains view.
3. select the complain to 6. display message
forward successfully forwarded
4. Select to whom
the complaint forwarded
5. Click on forward complain
button.
Alternative 2.1 If there is no complain details the display there is no
course of forwarded complain message.
action
Post Complain should be sent to wanted staff.
condition

Table 27: Use case for register user

Use case Register user Information.
Actor Head, service directors
description To register users information.
Precondition The actors should be login.
Extend None
Include Login
Basic course Actor action System response
of action
1. Head and service director Click 2 .display registration form.
on register link. 5. Does the validation.
3. the head and service 6. display
acknowledgement
directors fill the forms
message
4. Click on submit link.

Alternative 5.1 The system displays error message if required fields missed.
course of
action
Post New user added to the system
condition

Table 28: Use case description for update users’ information

Use case Update user Information.
Actor System administrator
description To edit or update users information.
Precondition The actors should be login.
Extend None
Include Login
Basic course Actor action System response
of action
1. Click update link. 2 .Display the page
3. Search the user by using his/her 4. Display user detail.
identification number. 7. Does validation.
5.update the new information 8.display message
6.Click on update button. successfully update

Alternative 4.1 If there is no user detail information, then system display this
course of user is not registered.
action
7.1.If the actor do not fill the new information display you do not
fill the information
Post Display updated user’s detail.
condition

Table 29: Use case description for delete user information

Use case Delete user

Actor System administrator
description To delete user.
Precondition The actors should be login.
Extend None
Include Login
Basic course Actor action System response
of action
1. Click on users delete link. 2. Display delete page.
3. Search the user by using his/her 4. Display user detail.
identification number. 6.does validation
5. Click on delete button. 7. display successfully
delated
Alternative 6.1 If there is no user detail information, then system display this
course of user is not registered.
action
Post
condition
Table 30: Use case description for View user’s detail.

Use case View users detail

Actor Head, service directors, administrative
description View user detail.
Precondition The actors should login the system.
Extend None
Include Logout
Basic course of Actor action System response
action
1. Click on view user link 2. Display users detail

Alternative course 2.1 If actors need to delete or edit user click on edit or
of action delete link from users detail
Post condition Users detail would be displayed.
Table 31: Generate Report Use Case
Use case Generate report
Actor Head, service directors, dean, department assembly, VPARA,
VPSPBD, president
description This use case describes the event of creating a report
based on the information collected by the system
Precondition The listed actors should login the system.
Extend None
Include Login
Basic course Actor action System response
of action
1. The use case activated when the 2. Displays “Report Page”.
administrator selects “Report”. 4. Generates report based on
3. The user enters report criteria the criteria.
from drop down menu.

Alternative Report from database is generated and the user view or print the
course of report.
action
Post
condition

3.5 Sequence diagram

A UML sequence diagram showing the sequence of interactions among
objects and used to represent or model the flow of messages, events and
actions between the objects or components of a system. Sequence diagrams
are also used primarily to design, document and validate the architecture and
interfaces of the system by describing the sequence of actions that need to be
performed to complete a task.
 Figure 4: Sequence diagram for login

Figure 5: Sequence for write complain

Figure 6: Sequence diagram for view feedback

Figure 7: Sequence diagram for delate complain

Figure 8: Sequence diagram for edit complain

Figure 9: Sequence diagram for register user

Figure 10: Sequence diagram for delete user

Figure 11: Sequence diagram for view user

Figure 12: Sequence diagram for give feedback

Figure 13: Sequence diagram for view complain

Figure 14: sequence diagram for change password

Figure 15: sequence diagram for forgotten password

Figure 16: sequence diagram for evaluate service performance

Figure 17: sequence diagram for forward complain

Figure 18: sequence diagram for update user information

Figure 19: sequence diagram for generate report

3.6 Activity diagram

Activity diagram is a special form of state chart diagram that is suitable for
expressing the activity execution flow. Activity diagram is commonly used
for expressing workflow and it is frequently used for objects like classes,
packages and operations.
 Figure 20: Activity diagram for log in

Figure 21: Activity diagram for register user

Figure 22: Activity diagram for delete user
Figure 23: Activity diagram for write complain
Figure 24: Activity diagram for forward complain

Figure 25: Activity diagram for view complain

Figure 26: Activity diagram for delete complain
Figure 27: Activity diagram for edit complain

Figure 28: Activity diagram for view feedback

Figure 29: Activity diagram for update user information

Figure 30: Activity diagram for generate report

Figure 31: Activity diagram change password

Figure 32: Activity diagram for forgotten password

Figure 33: Activity diagram for evaluate service performance

Figure 34: Activity diagram for give feedback

Figure 35: Activity diagram for view user information

3.7 Conceptual class diagram

The class diagram is the main building block of object oriented
modeling. It is used both for general conceptual modeling of the
systematic of the application, and for detailed modeling translating
the models into programming code. Class diagrams can also be used
for data modeling. The classes in a class diagram represent both the
main objects, interactions in the application and the classes to be
programmed. In the class diagram, classes are represented with
boxes which contain three parts:

• The top part contains the name of the class

• The middle part contains the attributes of the class
• The bottom part gives the methods or operations the class can take or
undertake
 Figure 36: Conceptual class diagram for Complain management system
3.8 Business rule of the system
 The complainer must be member of DDU community
 System admin must create an account for the users
 The complainers must be registered
 There must be a complain to give feedback
 The complaint feedback giver must be in position to give response
 Chapter four: System design

4.1 Introduction
System design is a phase after system analysis which specifies the detail
structure or blueprint of the system. We tried to defining the elements of a
system such as the architecture, modules and components, the different
interfaces of those components and the data that goes through that system. In
the case of our project the team members used object-oriented analysis and
design methods. This object-oriented method is the most widely used methods
for systems design and analysis because it makes complex code easier to
develop, more reliable, more maintainable, and generally better. The UML
has become the standard language in object-oriented analysis and design.
Design phase is very important because a majority of errors discovered during
deployment and operation stages could be traced down to the system design.
 The result of the system design is a model that include a clear description of
proposed software architecture, sub system decomposition, system class
diagram, state chart diagram, collaboration diagram, persistent data
management, component diagram, Hardware/Software mapping(Deployment
diagram) and Graphical user interface design of the system.

4.2 Proposed software architecture

Figure 37: proposed software architecture

4.3 Sub-system decomposition

A software system all ways divided into several subsystem that
make it easier for development and testing. The different subsystem
are known as the modules and the process of dividing an entire
system into subsystem is known as decomposition. The different
module shown below:-
Figure 38: sub system decomposition
4.4 System class diagram

Figure 39: system class diagram

4.5 State chart diagram

State chart diagram is a diagram that show the state change of object which
occur when event appear or happens. The state chart diagram is used to show
the class with dynamic attribute.
 Figure 40: state chart for login

Figure 41: state chart for change password

Figure 42: state chart for forgotten password

Figure 43: state chart for delete complain

Figure 44: state chart for delete user

Figure 45: state chart for edit complain

Figure 46: state chart for evaluate service performance

Figure 47: state chart for give feedback

Figure 48: state chart for register user

Figure 49: state chart for generate report

Figure 50: state chart for update user

Figure 51: state chart for view complain

Figure 52: state chart for view feedback

Figure 53: state chart for view user

Figure 54: state chart for write complain

Figure 55: state chart for forward complain

4.6 Collaboration diagram

Figure 56: collaboration diagram for login

Figure 57: collaboration diagram for change password

Figure 58: collaboration diagram for forgotten password

Figure 59: collaboration diagram for delete complain

Figure 60: collaboration diagram for edit complain

Figure 61: collaboration diagram for delete user

Figure 62: collaboration diagram for evaluate service performance

Figure 63: collaboration diagram for forward complain

Figure 64: collaboration diagram for give feedback

Figure 65: collaboration diagram for register user

Figure 66: collaboration diagram for generate report

Figure 67: collaboration diagram for update user

Figure 68: collaboration diagram for view complain

Figure 69: collaboration diagram for view user

Figure 70: collaboration diagram for write complain

4.7 Persistent data management
Data management is the design of the structure of a system. During the
management identification of the data that will be persistence should be
identified.
Data can be stored by flat file, relational database or object oriented database
storage management mechanism.
The proposed Dire Dawa University E-complain Management System
persistence data management is described below:
Table 32: User Account
No- Attribute Data Visibilit Description Key
type y
1 User Name Varchar - NOT primary
NULL
2 Password Varchar - NOT
NULL
Table 33: User registration
N Attribute Data type Visibility Description Key
O
1 ID Varchar + NOT Primary
NULL key
2 First name Varchar + NOT
NULL
3 Middle name Varchar + NOT
NULL
4 Last name Varchar + NOT
NULL
5 Sex Varchar + NOT
NULL
6 Phone no Number + NOT
NULL
7 e-mail Varchar + NOTNULL
8 Work type Varchar + NOT
 NULL
9 Department Varchar + NOT
NULL
Table 34: head, service directors
NO Attribute Data type visibility Description Key
1 First name Varchar + NOT
NULL
2 Middle name Varchar + NOT
NULL
3 Last name Varchar + NOT
NULL
4 ID Varchar + NOT Primary
NULL key
5 Sex Char + NOT
NULL
6 Phone number Int + NOT
NULL
Table 35: complain
NO Attribute Data visibility Description Key
type
1 Complain ID Varchar + NOT Primary
NULL key
2 Complain_Name Varchar + NOT
NULL
3 Complain_Type Varchar + NOT
NULL
4 Complain Varchar + NOT
description NULL
5 Date_of_complain Varchar + NOT
NULL

4.8 Component diagram

A component is a container of logical elements and represents
things that participate in the execution of a system. Components
also use the services of other components through one of its
interfaces. Components are typically used to visualize logical
 packages of source code, binary code (deployment components), or
executable files (execution components).

Figure 71: component diagram for e-complain management system

4.9 Deployment diagram

Hardware/ Software mapping the run time components like
subsystems and objects in the systems and hardware nodes
relationship. The components are self-centered that provide
services to other components or actors. It can be represented by
UML deployment diagram. The proposed system deployment
diagram is shown below:-
Figure 72: deployment diagram for e-complain management system
4.10 Graphical user interface

Figure 73: Graphical user interface for login

Figure 74: Graphical user interface for student complainer

Chapter five: Conclusion

Conclusion
Reaching large group of people and colleting complaints from them then
giving a solution for the
Collected complaints is not an easy task. The problem becomes worst when
collection and Processing of complaints is done manually. Dire Dawa
University currently uses Manual data collection and processing to handle
complaints. As seen in different parts of world, Use of ICT in government
system improves services provided for citizens. To alleviate the Problems
observed in the current complaint management of the city administration, a
web based and mobile based Complaint management system is developed for
the university.
In this project, we first study the current system to get necessary information
to have a clear view Of the existing system. This is done using only
observation and interview because there is no written documents about the
current system.
We interviewed the students, departments, student service, and the university
workers and so on.Clear view of the current system is obtained from Gathered
data. Based on requirements gathered, analysis and design documents are
prepared. Then we used appropriate tools to implement the system.
The system shall ensure the university to register and follow complaint status
using website or by sending SMS message. This enables to collect complaints
from large group of people. Moreover, the system reduces the time needed to
Collect and process complaints.
We will have develop the Complaint management system. The system will
develop with all its features that enable the user to conduct complaint with a
set of close-ended questions and for known respondents
References
[1] E-complaint Management System and GIS Mapping for Addis Ababa City
Administration by Abdi Mulatu
[2] Design and Implementation of SMS Based Public Opinion Polling System
By Aminu
Mohammed
[3] Resources on the Internet
[4]History of complaint management system/www.smarter .com/find/quality
result.
[5] search1.cnet.com/Cnet-Results
[6] www.smarter.com/Find/Quality Results
[7] uk.ask.com/Results/Save_your_time
[8] www.chennaisunday.com/.../E-commerce%20Complaint%20Management
%20System.
[9] www.academia.edu/13516063/Students_Complaints_Management_Syste
m
[10] www.nsitgurukul.com/projects/cse/CSE03421
[11] www.mpwrd.gov.in/documents/18/9cd57e9f-6770-4509-bc0d-
6d1a4519b3ef
[12] https://www.scribd.com/document/333177690/Online-Complaint-
Management-System
[13] https://www.scribd.com/doc/186286819/Complaint-Management-
System-PPT
[14] https://www.slideshare.net/himanshuchaurishiya/himanshuchaurishiyafm
aiitppts
[15] ijrise.org/asset/archive/CSE_UG506.pdf
[16] ijiset.com/vol2/v2s6/IJISET_V2_I6_45.pdf
 [17] 1000projects.org/online-complaint-management-system-project-
java.html

Appendix

Interview Questions
The following interview questions were used to understand the current
complaint collection and Management method used by the Dire Dawa
University.
1. Which types of complaints are frequently reaches to your office?
2. How complaint is collected from complainant?
3. Is there any precondition to give complaints?
4. How you verify the appropriateness of registered complaint?
5. What kind of complaints you collect?
6. At a time how many complaints can be given by a person?
7. What are the steps to give a solution for registered complaint?
8. In average how many days it takes to give a solution for registered
complaint?
9. How the registered complaint is stored?
10. Does your organization use any type of software for the purpose of
accepting or analyzing reports accepted from the public?