ONLINE COMPLAINT MANAGEMENT SYSTEM FOR AMBO

UNIVERSITY

Senior Project Documentation Submitted to Ambo University

In partial Fulfillment of the Requirement for the Degree of Bachelor of Science in

computer science

Name ID

1)Yewegie Molla………………………………………………………………………brt/0256/09

2) Yadesa Feysa………………………………………………………………………brt/0251/09

3) Zelalem Getachew……………………………………………………………….brt/0263/09

4) Dawi Mulugeta……………………………………………………………………brt/1964/09

5) Siranesh Abebaw………………………………………………………………..brt/0231/09

6 ) Wubnesh Hunegnaw…………………………………………………………….brt/0247/09

7) Wubrist Andualem…………………………………………………………………brt/0248/09

8) Debritu Mitku…………………………………………………………………………brt/0139/09

Supervised by: Dr Raja

Ambo University Ambo, Ethiopia

Feb 2020
APPROVAL

The Project is our own and has not been presented for a degree in any other university
with this functionality and all the sources of material used for the project/thesis have been
duly acknowledged. (Name and Signature of the project group members)

Name signature
1) Yewegie Molla…………………………………………………………………………

2) Yadesa Feyisa………………………………………………………………………….

3) Zelalem Getachew…………………………………………………………………….

4) Dawi Mulugeta…………………………………………………………………………

5)Siranesh Abebaw………………………………………………………………………

6) Wubnesh Hunegnaw……………………………………………………………………

7) Wubrist Andualem………………………………………………………………………

8)Debritu Mitku…………………………………………………………………………….

This is to certify that I have read this project and that in our opinion it is fully adequate,
in scope and quality, as a project for the degree of Bachelor of Science.

Name of Advisor Signature

……………………………………………………………………………………………
Examiner Name Signature
1) Examiner 1…………………………………………………………………………
2) Examiner 2…………………………………………………………………………
3) Examiner 3………………………………………………………………………..
4) Examiner 4………………………………………………………………………

i
Table of content

Table of Contents
APPROVAL ................................................................................................................................... i
List of figures .............................................................................................................................. v
Acknowledgment ....................................................................................................................... vi
Abbreviations ........................................................................................................................... vii
Abstract ....................................................................................................................................viii
CHAPTER ONE ............................................................................................................................. 1
1.1 Introduction .......................................................................................................................... 1
1.2 Background of the Organization ............................................................................................ 1
1.3 Statement of the Problem ................................................................................................... 2
1.4 Objectives of the project ....................................................................................................... 2
1.4.1General objectives........................................................................................................... 2
1.4.2 specific objectives .......................................................................................................... 2
1.5 Scope of the Project .............................................................................................................. 3
1.6 Significant of the project ....................................................................................................... 3
1.6.1 Target beneficiaries of the system .................................................................................. 4
1.7 Methodology ....................................................................................................................... 4
1.7.1 Data Collection Approaches ............................................................................................ 4
1.7.2 Software process model ................................................................................................. 5
1.7.2.1 System analysis and design approach ....................................................................... 6
1.7.3 Development tools and techniques ................................................................................ 6
1.8 Limitation of the project ........................................................................................................ 7
1.9 Risks and Contingencies....................................................................................................... 7
1.10 Constraints and Assumptions............................................................................................. 8
1.11 Time Schedule ..................................................................................................................... 8
CHAPTER TWO .......................................................................................................................... 10
2.1 Overview of the existing system .......................................................................................... 10
2.1.1 Players in the existing system ....................................................................................... 10
2.1.2 Major functions in the existing system.......................................................................... 11
2.1.3 Business Rules .............................................................................................................. 11

ii
 2.1.4 Report Generated for the Existing System .................................................................... 15
2.1.5 Bottlenecks of the existing system ................................................................................ 15
2.1.5.1 Performance......................................................................................................... 15
2.1.5.2 Input and output ..................................................................................................... 16
2.1.5.3 Access control and security .................................................................................... 16
2.1.5.4 Efficiency ............................................................................................................ 16
2.2 Overview of the proposed system ....................................................................................... 16
2.3 Feasibility study .................................................................................................................. 17
2.3.1 Operational Feasibility .................................................................................................. 17
2.3.2 Technical feasibility ...................................................................................................... 17
2.3.3 Economical Feasibility .................................................................................................. 17
2.3.4 Political feasibility......................................................................................................... 18
2.3.5 Schedule feasibility ....................................................................................................... 18
2.3.6 Legal feasibility ............................................................................................................. 18
2.4 System Requirement Specifications ..................................................................................... 18
2.4.1 Functional requirement ................................................................................................ 19
2.4.2 Nonfunctional requirements......................................................................................... 20
2.5 Hardware and Software Requirements ................................................................................ 20
2.5.1 Hardware interface....................................................................................................... 20
2.5.2 Software Interface ........................................................................................................ 20
2.5.3 Security and access permissions ................................................................................... 21
2.6 Cost Budgeting .................................................................................................................... 21
CHAPTER THREE ........................................................................................................................ 22
System Analysis and Modeling .................................................................................................. 22
3.1 Introduction ........................................................................................................................ 22
3.2 System requirement specification ....................................................................................... 23
3.3 Product function ................................................................................................................. 23
3.4 User characteristics ............................................................................................................. 23
3.5 General constraints ............................................................................................................. 24
3.5.1 Communication interface ............................................................................................. 24
3.6 Use case .............................................................................................................................. 24
3.6.1 Actors ........................................................................................................................... 26

iii
 3.6.2 Use case diagram ......................................................................................................... 26
3.6.3 Use case diagram description ....................................................................................... 27
3.7 Object Diagram ................................................................................................................... 35
3.7.1 Class Diagram ............................................................................................................... 36
3.7.1.1 Class Diagram Description..................................................................................... 37
3.8 Sequence Diagram .............................................................................................................. 39
3.9 Activity Diagram .................................................................................................................. 44
3.10 State Chart Diagram .......................................................................................................... 48
3.11 Analysis Diagram ............................................................................................................... 52
3.11.1 Sequence Diagram ...................................................................................................... 52
3.11.2 activity diagram .......................................................................................................... 53

List of Tables

Table1: Estimated Time Schedule ............................................................................................... 9

Table 2:Business rules.............................................................................................................. 15
Table 3:Cost Breakdown structure of the project ...................................................................... 21
Table 4:Use case Description for login ..................................................................................... 28
Table 5:Use case Description for register complain .................................................................. 29
Table 6:Use case Description for manage account .................................................................... 29
Table 7:Use case Description for view notification ................................................................... 30
Table 8:Use case Description for send decision ........................................................................ 30
Table 9:Use case Description for send feedback ....................................................................... 31
Table 10:Use case Description for view feedback ..................................................................... 31
Table 11:Case Description for Add user ................................................................................... 32
Table 12:Case Description for Assign complain ....................................................................... 33
Table 13:Use Case Description for Give complain priority ....................................................... 34
Table 14:Use Case Description for generate report ................................................................... 34
Table 15:Use Case Description for change password ................................................................ 35
Table 16:Use Case Description for log out ............................................................................... 35
Table 17:class diagram description of attribute complainer/user ............................................... 38
Table 18: class diagram description of attribute grievance handling officer ................................ 38
Table 19:class diagram description of attribute account ............................................................ 38
Table 20:class diagram description of attribute feedback .......................................................... 39
Table 21:class diagram description of attribute notification ...................................................... 39
Table 22:class diagram description of attribute complain .......................................................... 39

iv
List of figures
Figure 1:Iterative model .............................................................................................................. 6
Figure 2:use case diagram for complaint management system ................................................... 27
Figure 3:class diagram .............................................................................................................. 37
Figure 4:Sequence diagram for create and update account ......................................................... 40
Figure 5:View complaint information ........................................................................................ 41
Figure 6:Sequence diagram for handling grievance officer send solution to User ....................... 42
Figure 7:sequence diagram for login ......................................................................................... 43
Figure 8:sequence diagram for send feedback use case .............................................................. 43
Figure 9:sequence diagram for user complain registration use case ............................................ 44
Figure 10:Activity diagram for login ......................................................................................... 45
Figure 11:Activity diagram to manage account .......................................................................... 46
Figure 12:Activity diagram for handling Grievance officer to view notification ......................... 47
Figure 13:Activity diagram for User compliant registration ....................................................... 48
Figure 14:Activity diagram for handling grievance office send solution ..................................... 48
Figure 15:State chart diagram for our system............................................................................. 49
Figure 16: State chart diagram for Registration.......................................................................... 50
Figure 17: state chart diagram for login ..................................................................................... 51
Figure 18:Squence diagram for send complain in existing system ............................................. 52
Figure 19:sequence diagram for send complain solution in existing system ............................... 52
Figure 20:activity diagram for send complain in existing system ............................................... 53
Figure 21:activity diagram for send solution in existing system ................................................. 53

v
Acknowledgment
First of all, we would like to give thanks for God because helps us every success of our
proposal and analysis phase. Next to this we give thanks for our advisor Dr Raja for his
excellent advice and guidance to do the project from starting to this phase.

In addition to this we would like to give thanks for all the computer science instructors,
because they are the framework to do this project and also thanks for all our friends who
provide advice and some corrections from our error.

vi
 Abbreviations
Acronym Description

BR………………………............Business Rule

DB ………………..................... Database

UI ……………………………… User Interface

HTTP……………………………...Hypertext Transfer Protocol

HRM………………………………Human Resource Management
MYSQL……………………………My Structural Query Language
HTML ……………………………. Hyper Text Markup Language
TCP…………………………………Transfer control protocol
IP……………………………………Internet protocol
UN …………………………………User Name
PW …………………………………. Password

vii
 Abstract
The objective of the project, automated compliant management System in case of Ambo
University which enables the grievance handling office to record complains in
organization, viewing compliant records, customers register complains easily. Automated
Complain Management System project mainly consists of different types of actors. Those
are grievance handling of organization, employees and customer.
In general term the function of this project is to manage the information of complain in
terms of fast, managing input/output and advertising.

viii
 CHAPTER ONE
1.1 Introduction
An academic growth can be of various concerns in academic environment to promote
social and functioning educational system. For an effective educational system to take
place there are some issues in academic environment that should properly address to, take
for instance issue of complaints management system in the university. This issue had
created a lot of problems for an academic growth in the various aspects of the educational
system. To support this approach, this project identifies a range of options that can be
used to manage and resolve Academic complaints. This includes, where the opportunity
presents itself, the need for administrator to make every effort to resolve potential or
actual academic complaints. [1]

1.2 Background of the Organization

Ambo University is located in Ambo, the capital of West Shewa Zone of Oromia
Regional State. It was established in 1939 E.C (1947), and is one of the oldest higher
learning institutions in Ethiopia. It was originally a school. In 1951 E.C (1958) the school
was renamed as Ambo Agriculture and Forestry Secondary School with the addition
of forestry Department .in 1960 E.C (1967)the school was promoted to the level of
„institute‟ and named as Ambo Institute of Agriculture and started to offer a two-year
post-secondary Diploma course in General Agriculture .In 1969E.C (1974) the institute
was granted a Junior College status and named as Ambo Junior College of Agriculture
with an added objective of research and extension apart from teaching. Consequently, the
College launched a continuing education program in 1973 E.C (1980) and continuously
starts. In 1980 E.C (1987) some pedagogical courses were added to the existing
curriculum and a Teacher Education option was added to train agricultural teachers. In
1984E.C (1992) the “junior” status was shed off and the instruction renamed Ambo
College of Agriculture. In 1995E.C (2003) the institution started to offer undergraduate

1
Degree programs in the fields of Crop Production. Animal Production, Applied
Chemistry and Applied Biology. In the Meantime, the College was affiliated to Jimma
University by the name Jimma University –Ambo College.

On Megabit 3, 2000 E.C(12 March,2008),the Government of the Federal Democratic

Republic of Ethiopia promoted the College to status of an autonomous University
College- Ambo University College .In 2009, it was named as Ambo University.
Presently the University runs nine graduate and thirty-seven undergraduate programs
which are divided into eight colleges /institutions and thirty academic departments in
main campus at Ambo, and branches at Awaro campus, Gudar Campus, and Walliso
Campus [2].

1.3 Statement of the Problem

Currently the university has no web based system developed for controlling different
complain management. The overall activity of the complaint office is under taken
manually. Because of these activities there are problems like: Firstly; poor time
management generate complain report, Problems solve schedule creation. Secondly; there
is untimely, updating of file and other records? Thirdly; besides the files are stored on the
offices‟ shelf clearly these documents which are kept on the shelf will be vulnerable to
loss during the searching and looking of. Fourth; the offices have no permanent and
reliable storage area for its data‟s. Fifth; in bid there are different problem like; high
paper & overhead costs, the process is lengthy and time consuming, lower participation
rate to give decision.

1.4 Objectives of the project

1.4.1General objectives
The general objective of the project is to develop online complaint management system
for Ambo University.

1.4.2 Specific objectives

To achieve the general objective, we shall be guided by the following specific objectives:

2
  To evaluate the existing paper-based information of complaint management
system.
 To analyze and organize compliant information in such a way that it will be used
to design the new system.
 To design web based complaint registration and appeal management system.
 To design and implement a database for proper implementation of the complaint
management system.
 To design easy, fast and secure way for complain management.
 To make backup of and restore it when necessary.
 To develop communication system among members of the association with the
user of the institution.

1.5 Scope of the Project

This study covers the procedure for managing complaints information in Ambo
University. Online complaint management system is too wide in its scope but, this project
is done the following points only: -

 Customer can register, view, update and send request to handling grievance
officer.
 Grievance handling officers can assign complaint and give priority for complaint.
 The proposed system keeps in mind the problems of the current system as stated
earlier.
 Complainer can send feedback and complain to the officers.

1.6 Significant of the project

As the current system of complain management system in Ambo University is manual,
this project has many significant for the university as well as to the university
community. The new system will save time, reduce improper handling of complaint
system and also improve relationship between student, lecturer, departments and
management.

Generally, this system provides the following significances to the system users.

3
  Is easily accessible.
 Attempts to resolve complaints as close to the source as possible.
 Faster decision making due to the report generation functionality.
 Investigates and resolves complaints in a timely manner.
 Applies principles of procedural fairness.
 To give customer and students satisfaction.
 Reduce resource wastage.

1.6.1 Target beneficiaries of the system

The main users or actor‟s role played in this system are customers from anywhere or any
people from internal and foreign countries. Also the system gives service for all members
of the Ambo University.

1.7 Methodology
The main use of methodology is to gather data and/or information about how the
complaint will be able to give complain and who the process of complain review and
decision giving mechanism. So in order to gather information the team will used the
following data gathering methodologies.

1.7.1 Data Collection Approaches

Different fact finding techniques or approaches were used to gather information about the
current system. It is the fundamental activity for the development of the system. Without
them data modeling cannot be constructed. In order to know how the existing system
work and what problem are there we have been using the following fact-finding
techniques.
 Observation

Observation is one of the most important methodologies to gathering information by

physical going to the place and looks how the current system works. It can be very
difficult for humans to explain what they do or to even describe accurately how they
achieve a task, so observation very crucial to gathering information. The team used this
method because sometimes what they say and what is really happening may differ. We
have gone to the physically and we have seen how they do their job manually.

4
  Interview

Interview is another important methodology to gathering information by asking someone

a set of questions. It helps us to get critical and important information about the overall
view of the current system. We interviewed two employees from procurement office.

1. What is the complaint management system using? How it works?

2. How the complaint evaluated? If they have problem in speed how they fix?
3. Could you tell me about one of the main challenges face in this position?
4. Can the users carry out appeals? Etc…

1.7.2 Software process model

There are various software development life cycle models defined and designed which
are followed during the software development process. These models are also referred as
“software development process models”. Each process model follows a series of steps
unique to its type to ensure success in the process of software development. But the
proposed system follows iterative model. Because the iterative model illustrates the
software development process in a linear sequential flow. This means that any phase in
the development process begins only if the precious phase is complete and it can be back
to the first phase if it can be error occur. In this iterative model, the phases don‟t overlap.
in the iterative approach, the whole process of software development is divided into
separate phases and, the outcome of one phase acts as the input for the next phase
sequentially and back to the previous phase. [3]

5
Figure 1: Iterative model

1.7.2.1 System analysis and design approach

The goal of this section is to provide the basic overview of the system that we are going
to develop. The system analysis and design approaches for this project we used the object
oriented system analysis and design. Because:

 It provides code and function reuse through the concepts of inheritance,

polymorphism, encapsulation, modularity, coupling and cohesion.
 To design the system, the project team has chosen Object Oriented Modeling
techniques and unified modeling language tools.
 Understanding of the structure is easy because object oriented modeling and tools
used to represent real world entities.
 Modification of the object implementation is easy because objects are loosely
coupled

1.7.3 Development tools and techniques

 DBMS: is the mandatory one for the new system. To implement the database
easily, (My SQL) is recommended.
 Application software: to develop user and administrative interface it also used for
Connecting to the database, Most MS-Office applications are appropriate.
 EDRAW MAX: for designing UML diagram associated with the project.
 MICROSOFT OFFICE: -for documentation.
 Notepad++: for writing the code

6
  HTML: it is a client side programming markup language allows programmers to
develop Web pages.

 Computer, CD drive, monitor, Flash and Printer.

 JAVASCRIPT: -JavaScript is a popular coding language that is often used

Alongside the HTML language in website development. Especially for validation
purposes.
 PHP: -we choose to use PHP as server-side development tools We have use PHP
for coding and use XAMP server to implementation this PHP code Why PHP?
There are several types of web programming language that are used for making a
site more dynamic. But, for this project we are choosing PHP scripting language
to design our database.

1.8 Limitation of the project

Based on the time and resource, the following are the limitations of the system

 Scope of study: if scope creep is made knowingly it may be a limitation since

more time is required to cover the newly added scope.
 This project does not upload and retrieve large size files.
 The system doesn‟t have mechanism to support with special need.

1.9 Risks and Contingencies

Even if we try to care in the system design, different risk may occur and we may face.
From this problem some of are: -

 Power Problem: - We try to use the time appropriately when the power is on. For
extra we use laptop when unfortunately, power is off.
 Unfortunate failure of system: To handle this problem the teams have some
method to resist not completely but partially by using back up mechanisms using
flash disks, CD/DVD.
 Virus attack: We try to scan our data and computer before we use. It is difficult
to control data from virus but try to scan the data, installing and updating antivirus
software and we use CDRW instead of flash.

7
  Time management problem: we solve this problem by working cooperatively,
divide our time by schedule for each phase of the project and we try to use this
schedule effectively

1.10 Constraints and Assumptions

Time constraint: To complete this project there may be time limitation Better result will
be achieved if the project period is lengthened.

Expression: Through the interview and gathering information we cannot understand

some specific terminologies or using their using words

Hard to clarify: some of their domain knowledge is hard to articulate and not clear on
speech.

Technical (skill) constraint: To complete this project there may be different technical
limitation.

The team members of the project assumed some constraints may be faced and planed
counter measures to pass them this include:

Quality issues: the system is assumed to be reliable.

Security issues: to protect users‟ data and system misuse, the system should provide
restriction in using system functionality and information access by its user, i.e. the system
uses Role based authorization technique.

1.11 Time Schedule

Concerning the project scheduling, it will be bound by strict timing so it must be
delivered within the time bound given below the table. Our intention is to finalize it
hopefully planed it and have it run in a real environment before June 2019.The
system can be implemented in an acceptable timeframe given below. The Project
manager (leader) is also responsible for monitoring & controlling the project
development based on the schedule shown below.

8
 Time
Activitie

Nov 08
Nov 11

May15
Jun 20

Feb 20

Jun 10
App20

App25

Jun e1
Des 05
Des 16

Des20
s

115
Project
Proposal

Require
ment
Analysis
Design
Impleme
ntation&
coding
Testing
project
Defense

Table1: Estimated Time Schedule

9
CHAPTER TWO
2.1 Overview of the existing system
This project emphasizes handling complain management. The existing system of
conducting complaining process is through manual system. Due to these users of the
existing system wastes much amount of resources. Whenever a user of the University
requires service from the concerned body he/she required to submit the compliant to the
handling grievance officer. The current system is complains to written in paper and will
be submitted at the grievance handling officers. Then the managers will look after it and
then he will take care about the customer‟s problems. After that the managers will
enquire and allocate the problem to the specified person in that department. The current
system is time taking, unqualified, costly and not satisfactory since the current system not
use full computerized system for complaint purpose. Respondents spend much time to
work its own activity due to all information is transferred manually by paper-based
method and difficult to register new users, users must physically join to the offices to get
service, difficult to manage compliant. For instance, it takes time to respond the lodging a
complaint and evaluate the investigation process, jurisdiction of the complaint as well as
to announce the appeal hearing date to the responder. It takes also large numbers of paper
and even complaint may lose where and when the jurisdiction is performed. In general,
almost all activities in the system are done manually, so it has many problems.so we
introduce new system which is fully computerized. Therefore, the entities that interact
with the existing system are user of the system and have its own roles.

2.1.1 Players in the existing system

Ambo university compliant management institutions have many users that are
participating in the existing system. These are: -

User: A user is a citizen who is interested to forward his/her complaint to office workers
of the university and follow the decision process.
Officer: An authorized employee of the University who solves all the complaints
received form the Users and forwards the complaints response back to the users. The
employees who perform this task are:

10
  Human Resource Management (HRM)
 Academic record directorate
 Finance Directorate
 College Dean
 Department head
 President
2.1.2 Major functions in the existing system
Accepting complaint: Receive the user complain through oral speech and application
form.

Solving complaint: Addressing of complaint problem procedure in the existing system is

different. The complaint solving process takes place by keeping its hierarchy. For
instance, if the complaint is simple it directly solved orally in short time otherwise it
takes long period of time and continues to the end of the institution organ (from the
lowest level to the highest).

Generating report: since the existing system is manual, the report is informed on the
notice board or directly by physical contact with the user.

2.1.3 Business Rules

In every organizations or institution‟s there are rules and policies, which used to govern
all activities in specified work flow, control the work flow, and performed in the work
environment this are business rules. Or business rules are statement about the
organization‟s way of doing business. So the complaint management in Ambo University
governs and controls the work flow through the following rules.

Identifier Username Description

BR1 Teacher  Work harmoniously with students.

 Work fairly any activities between
students without any discrimination.

11
  Evaluate students based on the rules and
guide lines of the department.
 Solve the student complain based on
evidence among students.
 Transfer complaints to the next higher
body if he cannot solve it.

BR2 User  Users must assign the complaint for the target
officer
 The customer should fill the petition form and
personal data clearly and face to the transfer
officer.
 Users must follow the sequence of steps to get
solution for their complain starting from the
lowest one.
 The member of the institution can get complain
more than one times, if it is necessarily
 Users of the system contact with the office
workers to follow their complain procedure.
 Users see the complaint decision on the notice
board or by direct physical communication
 The customer must have complaint before
register the organ of the complaint/handling
grievance office.
 When members or users get in to the organization
to get service they must first registered to the
institution.

12
BR3 Department Head  Receive the user complain through oral speech
and solve the problem based on complain solving
principles. DC committee in the department head
solve the user complain and forward it to college
dean if it is beyond its capacity.
 Department head should replay the decision to
users
 Department head should write and post notice
for the customer complains

BR4 College Dean  Accept request from the department head or

directly from customers
 Solve the complaint by AC committee. The
decision process is based on rules of the college
or it supports by witness (watcher of the evidence
case of the problem).
 College Dean directly accepted some complaints
to it if the case is for them.
 If the user does not satisfied by the decision of
their Complaint College Dean give freedom to
ask to the next branch of officer.
 They post report on the notice board.

BR5 Human Resource  To solve customer notification the complaint

Management solve based on order of sequence.
(HRM)  Access of information depends on the authority
of the user.
 The transfer officer views the data by finding the
customer‟s complaint document. Give employee
yearly okay by selecting from personal fold away
(document).

13
  When the vacant position is announced to
external applicant on notice board on mass media
applicants record most of the time only for
consecutive 6 work days.
 Manage employees of the organization dismiss
from the university if they not properly work
their task in 10 days.
 They should give different information for
employee customer.

BR6 Academic  Students who come late cannot register or they

record directorate should have punished by money.
 An academic record directorate sends form to
colleges and schedules the semester plane.
 Academic record directorate store student grade
online correctly.
 Academic record directorate should modify
student‟s grade if it incorrectly send to the
system.

BR7 Finance  To get immediate response users should

Directorate face their complain to employee who give
that service
 If users not satisfied by the response they
can ask the next directorate officer.
 Also if the next directorate officer not
satisfied his/her complaint users has right
to continue until the final stage
(President).
 Officers should clearly announce the

14
 service standard.
 They should get to office on time at work
time
 Office workers should give fair decision
for complain.

Table 2: Business rules

2.1.4 Report Generated for the Existing System

The major report generation mechanism in the Compliant Management System for Ambo
University is posting notice on the bulletin board manually.

2.1.5 Bottlenecks of the existing system

Grievance handling officers decide the decision by wasting much time and wasting high
labor force. Also customers cannot get quick decision.

In case of performance of the existing system the condition is manual so customers or

applicants contact physically with the officers in order to face their complaint.

The basic bottlenecks of existing system are:

 The process is tedious for officers and users.

 Those who do not have time to go to one of the offices have no alternative way to
report about their problem.
 Customers who fears to report thinking something wrong might happen to them
do not have other means to place their complaint.
 Report generation in general is very difficult in current system.
 Much of the current system of the Compliant Management System is done heavily
in human interaction with the officers.

2.1.5.1 Performance
 Due to the manual system of complaint management system the information of
about complaints is posted in the notice board by printing on paper and when they
want to update the print again in returned manually through long steps.

15
  Searching and getting available information about complaint on notice board
takes long time for complaints.
2.1.5.2 Input and output
Input:
 Due to the manually inserting and printing of data it may face to error.
 Loss of data on the notice board may occur by weather condition, and by some
other ugly peoples.
Output:
 Inaccurate information may be produced.
 Poor flow of information between the Complaints and the University.
2.1.5.3 Access control and security

 Due to the manual work the input data haven‟t any security and it may erase from
the notice board easily.
2.1.5.4 Efficiency

 The manual system is not efficient to select the appropriate complaint.

2.2 Overview of the proposed system
The proposed system will help the organization to accomplish their tasks such as
compliant registration, retrieving compliant information as well as order request from the
service controller in efficient and effective manner and getting feedbacks from the users.
The proposed system is automated process of sending request through the web based
system. The complaints can be sent easily by the customer from anywhere. The services
are given through the system. The system that are developed solves the problems appear
in the current system. The new system enables all ambo university customers to register
compliant information to handling grievance office, to view their notification, to view
summons paper information, and helps handling grievance office to replay solution to
submitted customer post notice to customer, allows coordination among workers, allows
authorized users to access any file without wasting any time. The new system increases
the security availability and performance of the system. In this system customers can
easily register complain by sitting at his/her computer using the system, rather than going
to handling grievance office. All this processes are handled electronically in the system.

16
2.3 Feasibility study
It is an analysis of the ability to complete a project successfully, taking into account legal,
economic, technological, scheduling and other factors. Rather than just diving into a
project and hoping for the best, a feasibility study allows project managers to investigate
the possible negative and positive outcomes of a project before investing too much time
and money.

2.3.1 Operational Feasibility

Proposed applications are beneficial only if they can be turned into user friendly that
meet the users‟ requirements. Simply stated, this test of feasibility asks if the application
will be worked when it is developed. Therefore, the system will be designed to be
operationally feasible. That means, the system will operate without failure. Because of it
is simplicity and easy access. In addition to this the system is practical, applicable and
also the system operation is easy for the users. The new system that we develop require
organization end user potential and skilled man power, also social acceptability that the
system completely changed from manual system to computerized due to this potential
and skilled man power of our team to operate the system is operationally feasible.

2.3.2 Technical feasibility

The technical feasibility in the proposed system deals with the technology used in the
system. It deals with the hardware and software used in the system whether they are of
latest technology or not. It happens that after a system is prepared a new technology
arises and the user wants the system based on that technology.

2.3.3 Economical Feasibility

The project is economically feasibility attempts to weight the costs of developing and
implementing a new system, against the benefits that would occur from having the new
system in place or the cost of developing and implementing a new system less than the
cost that finding benefit from the developed system.

Tangible Benefits of proposed system

• Cost reduction and/or avoidance

• Error reduction
17
 • Increased flexibility

• Increase the speed of activities

• Improvement of management planning and control.

• Reduction in material consumption

Intangible Benefits of the proposed system

• More timely information

• Faster decision making

• improving employee morale

• Increase accuracy

2.3.4 Political feasibility

The system to be developed does not conflict with any government directives, because it
gives service for the employee efficiently and effectively. This means the government is
profitable and the system is politically feasible.

2.3.5 Schedule feasibility

Schedule feasibility is concerned with analyzing the expected completion date of the
project and the constraint that may bring change to this date. We have so many fixed
schedules to work together the project with all groups within each day and for the
simplicity and fast developing purpose. The schedule for this project is feasible due to
rich information exchange between the organization and the developing team.

2.3.6 Legal feasibility

The proposed system not conflicts with legal requirements, the government/ company. It
meets to the rule and regulations of the organization or the university or it is not conflict
to each other.

2.4 System Requirement Specifications

Requirement specifications develops a recommended process improvement action which
can include quick fix for serious problem, modification of existing manual systems or the
initiation of the organization re-engineering process. There are two main types of system

18
requirement specification this are functional and non- functional requirement. Functional
requirements are function that the system undertakes, whereas non-functional
requirement are restrictions that the system consider.

2.4.1 Functional requirement

The functional requirements are concerned with the actual performance of the system that
is going to be developed [3]. Functional requirements describe the functionality or
service provided by the new system:

 system

 The system accepts uploaded record.

 The system should arrange the complaint for the collection.
 The system should generate timely report about the collection.
 The system should store all the data related with all the tasks performed
into a database.

 Administrator

 Only administrator can add, restore and back up the system and
privileged user account
 Manage the whole activities users‟ information by blocking and
unblocking account of the system.
 officers
 Check users message complains (request).
 The concerned body able to see and decide complaints to handle.
 Responds and give solution of complaints of privilege user.
 Prepare report.
 Assign complaints
 Give priority for complaints

 User

 Send feedback, view notification register complains

19
  User to change his user profiles‟.
 User can update complains.

2.4.2 Nonfunctional requirements

Non-functional requirement is a requirement that specifies criteria that can be used to
judge the operation of a system. Non-functional requirements place constraints on how
the system will do so. The non-functional requirement elaborates a performance
characteristic of the system. Also these requirements relate to system attributes such as
reliability and response time and they can arise due to user requirements. Any
requirement which specifies how the system performs a certain function considered when
designing the solution. The following are non-functional requirement associated with the
system: -

 Performance: The system is error free when the user accessing a data and the
system should be accessed by many users and should have fast response time.
 User interface: The system should be user friendly. The developed system
provide web based application user interface and are compatible with browsers
like internet explorer, Mozilla Firefox, Google chrome.
 Resources: the system is compatible with the specified hardware and software
requirement and the system should have compatible with any environment.

2.5 Hardware and Software Requirements

2.5.1 Hardware interface
Since the application must run over the internet, all the hardware shall require to connect
internet will be hardware interface for the system. As for e.g. Modem, WAN – LAN,
Ethernet Cross-Cable.

2.5.2 Software Interface

The “complaint management system” software will interface with a local SQL database
for writing and verifying complaint-records. Commands for interfacing, connecting and
writing data entries will be the same as any standard SQL client-server application.

20
The complaint management system shall communicate with the Configurator to identify
all the available components to configure the product.
2.5.3 Security and access permissions
The application will only allow valid users and customers to access the system. Access to
data must be controlled, no one can log into the system without a registered user name
and password.

2.6 Cost Budgeting

In order to achieve the intended goal, the group needs the following materials.

No Name of Quantity Unit price Total price

material (ETB) (ETB)
1 Pen 4 10.00 40.00
2 Paper 100 0.75 75.00
3 CD 2 10.00 20.00
4 Print 200 2.00 400.00
5 Flash disk 2 150.00 300.00
6 Computer 1 15,000.00 15,000.00
7 Miscellaneous 200.00
Expense
Total 16035.00
Table 3: Cost Breakdown structure of the project

21
CHAPTER THREE
System Analysis and Modeling
3.1 Introduction
System analysis is the process of gathering and interpreting facts, diagnosing problems
and the information to recommended improvements on the system. System analysis is a
problem solving activity that requires intensive communication between the system users
and system developers. System analysis or study is an important phase of any system
development process. The system is studied to the minutest detail and analyzed. The
system analysis includes different activities such as gathering data, identifying system
requirement, prioritize system requirement and recommendation and evaluation of the
system. The system analyst plays the role of the interrogator and dwells deep into the
working of the present system. The system is viewed as a whole and the input to the
system are identified. The outputs from the organizations are traced to the various
processes.

A detailed study of the process must be by various techniques like interviews,

questionnaires, and observation to gather the information on the system, by stating what
is the process in the existing system and how the existing system is works. The data
collected by these different data collection method is stored. The conclusion is an
understanding of how the system functions. After collecting data on existing system and
storing that we must identify the system requirement. Now the existing system is
subjected to close study and problem areas are identified. After identifying what the
requirement of the system and problem of the system the proposed system must generate
and evaluate the alternative. Here what important things the system to do is must be
considered. Additionally, to solve the problem in the existing system and to identify the
system requirement the best way to create the system is must be considered. Then we
now function as a problem solver and tries to sort out difficulties that exist in the current
system. After identifying the problem and the requirement of the system the new system
or the proposed system is going to solve the identified problem. The proposal is then
weighed with the existing system analytically and the best one is selected. In system
analysis there are two requirements, Functional requirement and Nonfunctional

22
requirement. There are different system analysis approaches, but we prefer to use object
oriented approach.

3.2 System requirement specification

The following subsections of the Software Requirements Specifications (SRS) document
should provide an overview of the entire SRS. It tells what the system must do.

3.3 Product function

 The system should enable complain registration.

 The system should enable view and replay complains.

 The system should enable to send complain.

 The system should enable to send decision.

 The system should enable to view and replay feedback.

 The system should enable the users to send a feedback.

 The system enable the officer can assign complaints.

 The system should enable the administrator manage the accounts.

 The system should enable the officer give priority to the officer.

The proposed system can reduce the cost of the organization by considering the number
of users in the campus. The users can send complain in a few minutes which is in the
time not more than three minutes

3.4 User characteristics

Describe those general characteristics of the intended users of the product including
educational level, experience, and technical expertise.

23
 Every user should be:
 Comfortable with Internet Browser.
 He must have brief knowledge of complaint system.
 He must also have knowledge of using computer or mobile too.

3.5 General constraints

A constraint is a restriction on the degree of freedom we have in providing a solution.
Constraints are effectively global requirements such as limited development resources or
a decision by senior management that restricts the way we develop a system.

Provide a general description of any other items that limit our options. These can include:

(1) Regulatory policies

(2) Hardware limitations (for example, signal timing requirements)
(3) Interface to other applications
(4) Parallel operation
(5) Audit functions
(6) Control functions
(7) Higher-order language requirements
(8) Signal handshake protocols
(9) Reliability requirements
(10) Criticality of the application
(11) Safety and security considerations
3.5.1 Communication interface
The online complaint management system shall use the HTTP protocol for
communication over the internet and for the intranet communication will be through
TCP/IP protocol suite.

3.6 Use case

Use cases are used during requirements elicitation and analysis to represent the
functionality of the system. Use cases focus on the behavior of the system from an
external point of view. It describes a function provided by the system that yields a visible
result for an actor. An actor describes any entity that interacts with the system (e.g., a

24
user, another system, the system‟s physical environment). The identification of actors and
use cases results in the definition of the boundary of the system that is, in differentiating
the tasks accomplished by the system and the tasks accomplished by its environment. The
actors are outside the boundary of the system, whereas the use cases are inside the
boundary of the system. Use case is a list of steps, typically defining interaction between
a role of actor and a system to achieve a goal. It made up of a set of possible sequence of
interaction between system and users [4].

The following are use cases of the system:

 Login

 Register complain

 Modify complain

 View notification

 View complain

 Assign complain

 View and replay complain

 Create account

 Send complain

 Manage account

 Add user

 Give priority for complaints

 Send decision

 View and replay feedback

 Send feedback

25
3.6.1 Actors
Actors are individuals involved with the system defined according to their roles, and
represented by strike.

Actor of the system

 System administrator

 Users

 SQL agent

 Grievance handling offices such as:

 Department head
 Human resource management officer
 Collage dean
 President officer
 Finance Directorate

3.6.2 Use case diagram

The use case diagram is concerned with the interaction between the system and
actors (objects outside the system that interact directly with it). It presents a
collection of use cases and their corresponding external actors.

26
Figure 2:use case diagram for complaint management system

3.6.3 Use case diagram description

Use case Id UC1
Use case name Login
Participatory actor All actors without SQL agent
Description Users are authenticated and taken to their own
user interface

Precondition The actors involved to login must already registered and have a
valid user name and password.
Basic flow of event User event System response
1. The user opens the main 2. The system displays the main
home page home page
3. The user inputs user name 4. The system validate the
and password and submit account and display the user
system response require information
5. Use case ends.

27
 Alternative flow of event A login name or password is invalid
A 4. The system displays invalid user name or
password message
A 5. The user re enters the user name and
password
A 6. The use case continues from step 3
actors may Change password

Post condition User is authenticated and taken to his/her own user interface
Table 4: Use case Description for login

UC2
Use case Id
Use case name Complain Register
Participatory actor User
Description The user can register complain to handling grievance offices
Precondition There should be fill available information on the complaint
registration page
Basic flow of event User event System response
1. The user registers complaint page 2. The System displays
3. The user fills the Necessary the register complain
information and Submit the forms. information Page.
4. The System displays a
success message
5. Use Case Ends
Alternative flow of event If the submitted form is not filled completely or invalid.
The system displays “unsuccessful” message
The user fills the missing information and corrects invalid inputs the
use case continues login page

28
Post condition The system can register complain information
Table 5:Use case Description for register complain

Use case Id UC3

Use case name Manage account
Participatory actor System admin
Description The listed actors may be changing their account.
Precondition They must be first registered in to the database.
Basic flow of event User event System response
1. The actor fills the 2.The System displays
necessary information and Submit the edit
the forms profile Page
3.The actor fills the 4.The System displays
necessary information and a success
Submit message
the forms 5.Use Case Ends

Alternative flow of event A: If the submitted form is not filled completely or invalid.
A4. The system displays “unsuccessful” message
A5. The actor fills the missing information and corrects
invalid inputs
A6. The use case continues from step 4
Post condition updating their account in the system
Table 6:Use case Description for manage account

Use case Id UC4

Use case name View notification
Participatory actor Officer and complainer
Description User can view decision from the system and organ of the complaint
can view new complains, solved and unsolved complains.

29
Precondition Actors registered complain first.

Basic flow of event User event System response

1. The user invoke on view 2. The System displays the view
notification page notification Page
3. The user fills the necessary 4. The System displays
information and Submit the notification page
forms. 5.Use Case Ends

Post condition User and organ of the complaint put the content of the question in
the available input box.

Table 7: Use case Description for view notification

Use case id UC5

Use case name Send decision
Participatory actor Department head, Human resource management officer, Collage
dean, Finance Directorate, president officer
Description Those actors submit their complain resolution to their user and
organ of the complaint after completed.
Precondition  handling grievance office login first
 must do their solution

Basic flow of event 1.The handling grievance office opens the home page.
2. click on send menu
3. Fill the information on the label.
4. Click at send button
Post condition Send their resolution to the owner of the complaint.

Table 8:Use case Description for send decision

30
Use case id UC6
Use case name Send feedback
Participatory actor User/complainer
Description This actor‟s send feedback to the handling grievance office
Precondition The listed actors interact (open) with the home page of the system
Basic flow of event 1. The listed actor opens the home page.
2. click on feedback menu
3. Fill the information on the label.
4. Click at send button.

Alternative flow of event If there is no feedback the system displays no feedback is posted

post condition The listed actors send important feed backs to the handling
grievance office
Table 9: Use case Description for send feedback

Use case id UC7

Use case name View feedback
Participatory actor Department head, Human resource
management officer, Collage dean, Finance
Directorate, president officer
Description The listed actors view feed backs sent by
users.

Precondition The actors should interact with system

Basic flow of event Actors click on view feedback icon
The system makes display feedback

Alternative flow of event The actor may replay feedback

Post condition The actors successfully watch feed backs
Table 10:Use case Description for view feedback

31
Use case id UC8
Use case name Add user
Participating Actors Administrator
Description The administrator adds user name and password to database to create
new user.

Entry Condition User with administrator privilege logged in to the system.

Basic flow of event 1. The administrator selects “Add User” link.

2. The system displays add user form.
3. The administrator enters user name, password,
Conformation password, worker name and position.
4. The administrator clicks “Submit” link.
5. System does the validation. A2
6. The system displays acknowledgement message.

Alternative flow of event 1. The system displays error message if required fields missed or the
newly created account name already exist in database or if the
password does not match with conformation password or if the
worker has already account.
2. Go to step 3.

Exit Condition New user added to the system.

Table 11: Case Description for Add user

Use case id UC9

Use case name Assign complain
Participatory actors Department head, Human resource management officer, Collage
dean, and Finance Directorate, president officer
Description When the complaint comes from the user the system assigns new

32
 cases to the right person or group.

Precondition The listed actors interact (open) with the home page of the system
Basic flow of event 1. The handling grievance officers open the home page.
2. click on assign complain menu
3. Fill the information on the label.
4. Click at assign complain button

Alternative flow of 1. The system displays error message if required information

event missed or the newly assign complain already assigned.
2. Go to step 3.

Post condition The system displays assign complaint is already allocated

Table 12: Case Description for Assign complain

Use case id UC10

Use case name Give complain priority
Participatory actors Department head, Human resource management officer, Collage
dean, and Finance Directorate, president officer
Description When the complaint comes from the user the grievance handling
office set complain priority according to the issue.
Precondition The listed actors interact (open) with the home page of the system
Basic flow of event 1. The handling grievance office opens the home page.
2. click on complain priority menu
3. Fill the information on the label.
4. Click at complain priority button

Alternative flow of 1. The system displays error message if required information missed
event or the newly complain priority is already given.

33
 2. Go to step 3.

Post condition The system displays the complaint priority is already given

Table 13: Use Case Description for Give complain priority

Use case id UC11

Use case name Generate Report

Participating Actors Department head, Human resource management officer, Collage dean,
and Finance Directorate, president officer
Description This use case describes the event of creating a report based on the
information collected by the system.
Pre-condition The administrator is logged on
Basic flow of event 1. The use case activated when the administrator selects
“Report”.
2. The system displays “View Report Page”.
3. The user enters report criteria from drop down menu.
4. The system generates report based on the criteria.

Exit Condition Report from database is generated and the user view or print the
report.
Table 14: Use Case Description for generate report

Use case id UC12

Use case name Change Password
Participating Actors Department head, Human resource management officer, Collage dean,
and Finance Directorate, president officer
Description Once the user obtains account, can change his/her password.
Entry Condition User already logged in.
Basic flow of event 1. The user selects “Change password” Button.
2. User is prompted for user name and old password, new password

34
 and confirmation of new password.
3. The user enters the user name, old and new password and submits to
the system. (…. A1)
4. System does the authentication. 5. The system displays an
acknowledgment.

Alternative flow of Authorization fails

event 1. If the old password is invalid, the system informs that
user has entered wrong password or if the new
password does not match with confirmation password; the system
displays error message and allows reentering of the attributes.
2. Go to step 2.

Exit Condition Password is changed.

Table 15: Use Case Description for change password

Use case id UC14

Use case name Log out
Participating Actors Department head, Human resource management officer, Collage dean,
and Finance Directorate, president officer
Description The user should be logged out from the system

Entry Condition The user is already logged in.

Basic flow of event 1.The user presses “Log out”.
2. The system will go back to home page

Exit Condition The user is logged out.

Table 16: Use Case Description for log out

3.7 Object Diagram

Object diagram on the other hand is a graph of instances, including objects and data
values. A static object diagram is an instance of a class diagram. It shows a snapshot of
35
the detailed state of a system at a point in time. The use of object diagrams is fairly
limited, mainly to show examples of data structures.

3.7.1 Class Diagram

A UML class diagrams show the classes of the system, their inter-relationships, and the
operations and attributes of the classes. Class diagrams are typically used, although not
all at once, to:

 Explore domain concepts in the form of a domain model

 Analyze requirements in the form of a conceptual/analysis model
 Depict the detailed design of object-oriented or object-based software

Class diagram is unified modeling language (UML) is a type of static structure diagram
that describe the structure of the system that showing:

 Entity
 Their attribute
 Operation (or method‟s)
 And the relationship among the class

36
 Figure 3: class diagram

3.7.1.1 Class Diagram Description

This section specifies the description of class diagrams contained in our system,
complaint management System for Ambo University. We have listed those descriptions
as follows.

No Field name Data type Description

1 ID VarChar(50) Identification of the user or
complainer
2 Username String User name of the complainer
3 EmailAddress VarChar(50) Email address of the complainer
4 Sex VarChar(20) Sex of the complainer
Age VarChar(10) age of the complainer

37
 Phone VarChar(50) Phone number of the complainer
Status VarChar(50) Status of the complainer
Methods: sendComplaint(),viewNotification(),sendFeedback(),recieveDecision()
SendComplaint(): used to send the complaints.
viewNotification() : used to view the available notifications.
sendFeedback():used to send feedback.
recieveDecision () used to receive the decisions sent by the officers.
Table 17:class diagram description of attribute complainer/user

No Field name Data type Description

1 officeNumber VarChar(50) Office number of the officers
Method:
viewNotification(),receiveComplaint(),sendDecision(),givePriority(),assignComplaint()
viewNotification():used to view the available notifications.
recieveComplaint():used to receive complaints.
sendDecision() used to send decision by officers
givePriority(): used to give priority for complainer by officers.
assignComplaint():used to assign complaints/
Table 18: class diagram description of attribute grievance handling officer

No Field name Data type Description

1 Id Varchar Identification for administrator
2 Name String Name of the officer for whom
account is being created
3 Email VarChar(50) Email of the officer for whom
account is being created
4 Password VarChar(50) password of the officer for whom
account is being created
Method: create()
Create():used to create account by the administrator .

Table 19:class diagram description of attribute account

38
No Field name Data type Description
1 ID VarChar(50) Identification of the feedback
2 Type VarChar(50) Type of the feedback
3 Date VarChar(50) The date in which the feedback is
sent or replayed
Method:send()
Send():used to send feedback by the complainer
Table 20:class diagram description of attribute feedback

No Field name Data type Description

1 ID VarChar(50) Identification of the feedback
2 Type VarChar(50) Type of the feedback
3 Date VarChar(50) The date in which the feedback is
sent or replayed
Method: notifiy ():used to send and replay notifications.
Send():used to send feedback by the complainer
Table 21:class diagram description of attribute notification

No Field name Data type Description

1 ID VarChar(50) Identification of the complain
2 Type VarChar(50) Type of the complain
3 Description String Description for the complain
Method:complaint()
complaint(): used to send and replay complain
Table 22:class diagram description of attribute complain

3.8 Sequence Diagram

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.

39
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 or scenario [2].

Figure 4:Sequence diagram for create and update account

40
Figure 5:View complaint information

41
Figure 6:Sequence diagram for handling grievance officer send solution to User

42
Figure 7:sequence diagram for login

Figure 8:sequence diagram for send feedback use case

43
Figure 9:sequence diagram for user complain registration use case

3.9 Activity Diagram

It represents the flow from one activity to another activity. Activity diagrams model is a
high level business or processes or transitions between states of a class. In this activity
diagram tried to document the flow of logic for the major business processes.

44
Figure 10:Activity diagram for login

45
Figure 11:Activity diagram to manage account

46
Figure 12:Activity diagram for handling Grievance officer to view notification

47
Figure 13:Activity diagram for User compliant registration

Figure 14:Activity diagram for handling grievance office send solution

3.10 State Chart Diagram

The state diagram shows the sequence of states that an object goes through the events that
cause the transition from one state to the other and the actions that result from a state
change.

48
Figure 15:State chart diagram for our system

49
Figure 16: State chart diagram for Registration

50
Figure 17: state chart diagram for login

51
 3.11 Analysis Diagram
3.11.1 Sequence Diagram

Figure 18:Squence diagram for send complain in existing system

Figure 19:sequence diagram for send complain solution in existing system

52
3.11.2 activity diagram

Figure 20:activity diagram for send complain in existing system

Figure 21:activity diagram for send solution in existing system

53
3.11 Reference

[1](http://iproject.com.ng/index.php/computer-science/final-year-project-topics/design-
and-implementation-of-complaint-management-system-for-university-student/project-
topics)
[2] www.ambou.edu.et

[3] (http://www.sunilos.com/case-study/e--crime-file-management-system/functional-
requirements)
[4](Amrute, Ajinkya, "Cloud Based Complaint Management Service" (2020). Master's Pr
ojects. Paper 298.)

54