HARAMAYA UNIVERSITY

College of Computing and Informatics

Department of Information Systems
Title: Complaint management system and information hub

Group Members

Name ID

1. Kebede Kumsa……………………………616/08

2. Damitu Nagasa……………………………1373/07

3. Tiringo Nugussie………………………….638/08

4. Fasika Alene……………………………….600/08

ADVISER BY: CO ADVISER BY:

Mr. Atkilt Ms. Woyineshet

(Lecturer….) (Lecturer….)
 2018-2019

1.1.1 CERTIFICATE

This is to certify that the work embodies in this project entitled

“______________________________________________________” being
submitted by following students for partial fulfillment of the requirement
to “Haramaya University” during the academic year 2018-19 is a record of
bonafide piece of work, carried out by them under my supervision and
guidance in the “Department of Information Systems”, College of
Computing and Informatics.

Name ID

1. Kebede Kumsa 616/08

2. Damitu Nagasa 1373/07
3. Tiringo Nugussie 638/08
4. Fasika Aleni 600/08

ADVISER BY: CO ADVISER BY:

Mr. Atkilt Ms. Woyineshet

(Lecturer….) (Lecture….)

HEAD OF DEPARTMENT

Mr. BeyeneBedasa
(Lecturer….)
 CHAPTER ONE

1. INTRODUCTION
E-government allows citizens to interact with government to achieve objectives without being
restricted to time and location, and eliminates the necessity for physical travel to government
agents. Taking this into consideration, e-government applications are being developed. The
government of Ethiopia has launched an E-service portal by aiming improving public services to
citizens, residents, businesses, and brings its institutes closer to stakeholders by which citizens
and businesses are able to request public services electronically and get response accordingly.
The portal allows users to provide their feedbacks for future improvements.

Skielse stated that emergent area in which citizens can interact with government is M-
government or mobile government. One natural extension to e-Government and promising area
of m-government is complaint and problem management, where mobile applications used to
offer citizens convenient ways of rapidly reporting problems and to express their dissatisfaction
with procedures and services of a government entity. As the complaints hold the voice of the
citizen they provide critical knowledge about the organization and its service which can be
utilized for the improvement of the organization.

As supposed by experts, due to increasing wider acceptance and usage of smart phones
worldwide, it is expected that the number of smart phone users in the country will increase. The
use of mobile for internet growing and the demand for mobile services and internet access
continues to grow exponentially. Hence, using a mobile application as complaint management
increases citizens’ participation and interaction by providing real time information to government
officials on the move.

Therefore this project aims to design and implement automated compliant management system
and information hub for Haramaya University.
 1.1 Background of the organization
Haramaya University has gone through a series of transformations since its establishment as a
higher learning institution. The agreement signed between the Imperial Ethiopian Government
and the Government of the United States of America on May 15, 1952 laid the foundations for
the establishment of Jimma Agricultural and Technical School and the Imperial College of
Agricultural and Mechanical Arts (IECAMA).

The Agreement between the Government of Ethiopia and the Technical Cooperation
Administration of the Government of the United States of America, signed on May 16, 1952,
gave the mandate to Oklahoma State University to establish and operate the College, conduct a
nationwide system of Agricultural Extension and set up an agricultural research and experimental
station. Based on the Emperor’s wish, it was decided to establish the College at its current
location at Haramaya. Later on, the agreement signed between the United States Department of
States and the Imperial Government provided the basis for the operation of Jimma Agricultural
and Technical School that received its first class of eighty students in October 1952.

In the last few years, the University has witnessed tremendous expansion in terms of fields of
study. In September 2002, two more faculties, namely Faculty of Law and Faculty of Business
and Economics, were opened. Furthermore, Faculty of Veterinary Medicine and Faculty of
Technology were initiated in 2003 and 2004, respectively to further diversify the training
programs of the university. The institution was renamed Haramaya University in February 2006.

The University, apart from undergraduate programs, has been highly engaged in the expansion
and diversification of graduate programs. Currently, the previous Faculties were reorganized into
nine Colleges , one institute and one Directorate namely, College of Agriculture and
Environmental Science (CAES),College of Business and Economics(CBE) , College of
Computing and Informatics (CCI), College of Medical and Health Sciences(CMHS), College of
Social Sciences and Humanities(CSSH), College of Law(COL), College of Veterinary
Medicine(CVM), College of Natural and Computational Sciences (CNCS), College of Education
and Behavioral Sciences(CEBS) , Directorate of Continuing and Distance Education (CCDE)
and Haramaya Institute of Technology (HIT
 1.2 Background of the project

An academic growth can be of various concerns in academic environment to promote social and
functioning educational system. Recently introduced mobile Internet and related technology are
among the most advanced delivery channels that are leading to a new era of mobile government
services and business models. For an effective educational system to take place there are some
issues in an academic environment that should properly address to take for instance issue of
complaint 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.3 Statement of problem

The current system faces many problems as it uses manual work for the following mentioned
activities. In view of this fact, the team suggests to change the manual system into computerized
system.

Specifically the existing system of the academic complaining process in Haramaya University
has the following problems.

 Anyone who wants to register complaints should either appear in person to one of the
office found in the required office or write letter to the required staff. Because of this
constraint, those who do not have time to go to one of the offices have no alternative way
to report about the problem. On the other hand, those who fear to report thinking
something wrong might happen to them do not have other means to place their complaint.

 No form of automated system that is used to help for complainant to process their
complaint and for respondents as well to give solution for the complaint already
complained, being anywhere at any time with their mobile devices even.

 The most types of complaint are not well organized and measurable, since the complaint
processing system is manual and there is no specific rule.
  Deprived user satisfaction because, it takes time to provide the solution for the complaint
that complained before long time. This in turn makes the system less responsive.

 When the complainant explain their complaint to the grievance handling office physically
they may fear than sending their complaint by writing.

 As the complaints received from the complaint, it is documented manually.

 Finding and retrieving data are difficult.

1.4 Objective of the project

1.4.1 General Objective

 The objective of this project is to Design and implement automated compliant

management system for Haramaya University.

1.4.2 Specific Objective

 Facilitate timely management decision making.

 To analysis the most frequent type of complaint.

 To organize and create suitable conditions for management ofcomplaint processing.

 Identify functional and non-functional requirements for the new systems.

 Identifying problems of the Existing System.

 Improving current complaint system.

 To transfer reliable, accurate, and real-time complaint related information.

1.5 Data collection methodology

There are a number of data collection methods. Among these methods to do our project we used
observation, interview and document analysis method.

1.5.1 Interview technique

We interviewed members of the association from their office, and members from their work
place. Like:-
 What kind of system the organization has used?

How the existing system works?

What are the problems of the existing system?

1.5.2 Document analysis

We have also tried to read the document which is prepared by the institution that explains about
the institution feature since its establishment.

1.5.3 Observation

We use this method to get the right information about the organization and also to understand
how the existing system works.

1.6 Scope of the project

The scope of our project is extended out from student to many organs having connection with
complaint management process. These organs are: department head, HRM, staff, registrar staff,
college dean, library manager, ICT office, and duplication center manager.

 The department head, HRM, registrar staff, college dean, library manager, ICT
office, and duplication center manager can view the complaint that comes from
the compliant.

 Student can register, view answer for his /her complaint, searches his/her previous
complaint and send request to the respondent office.

 Admin creates account for all users (department head, HRM, registrar staff,
college dean, library manager, ICT office, and duplication center manager) except
student.

 Students create their own account.

 The system can be responsive in different devices.

1.7 Significance of the project

The significance of this study is to serve the system which is better than the existing system,
which is highly manual and therefore difficult in terms of monitoring the complaint in the
educational area of the Universityand enhance effectiveness and efficiency and security of the
system. It is also intended that the study will help in the development of a new and hopeful and
standard better computer aided system.

The system is expected to be easy as user can browse their complaint anytime; staff and
management also can equally response to customer’s complaint in a more easy way.

Generally this system provides the following significances to the system users

 To simplify the compliance process to be easy

 Anyone can send his/her complaint from anywhere and anytime using his smart phone.

 Reduce the paper work

 Protecting corruption and promoting good governance

 The complainant can offer their feedback without fears

 To reduce the unwanted communication from the complainants

 Complainants use time effectively.

 Creates Job satisfaction to the employees and the complainants

1.8 Feasibility study

It is an analysis of the ability to complete a project successfully, taking into account economic,
technical, 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.

1.8.1 Economic Feasibility

Economic feasibility is the variation between the existing and the proposed system in terms of
the tangible and intangible benefits that they incur or consume.

Tangible Benefits:- Benefits that are easily gained from the proposed system are:
 Faster processing time of complaint and reduced processing errors.
  Reduced effort to give response to complaint.
 Reduced effort to complain for the service the complainant is not satisfied.
 Reduce cost of manual data management.

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

1.8.3 Operational Feasibility

Proposed applications are beneficial only if they can be turned into user friendly that meet the
users’ requirements. This feasibility states that the system should be feasible operationally after
completion. That means, the system will operate without failure because of its ease of access or
use. In addition to this, the system is applicable under network connection and also its operation
is easyfor the users relative to the existing system.

1.8.4 Schedule feasibility

We have done and will do all the tasks in this project according to a prescheduled plan specified
as the following WBS.

Task to be Time given for the task

performed
Dec. Jan. Feb. March April May June

w
WWW W W W W W WW W W W W W W W W W W W W W W W W W
e
e e e e e e e e e e e e e e e e e e e e e e e e e e e
e
e e e e e e e e e e e e e e e e e e e e e e e e e e e
k
k k k k k k k k k k k k k k k k k k k k k k k k k k k
4
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3
Selecting
Title
 Understanding
the existing
System

Requirement
gathering and
analysis

System
analysis and
Interface
design
Implementat
ion
Testing and
presentation

1.9 Team configuration

1.9.1 Team configuration and management
Throughout the development of our project, we did every things included within the project
together. Brainstorming the activities, we assigned and completed the responsibility assigned to
us. So, throughout the project, all the members of the group performed and will perform the
following responsibility.

Name Id number Responsibility

Damitu Nagasa 1373/07 Requirement gathering

and analysis

Tiringo Nugussie 538/08 System analysis

Fasika Aleni 600/08 System design

Kebede Kumsa 616/08 Implementation and testing

1.9.2 Communication plan

Throughout our project development, we used a number of methods to communicate about the
project, to reduce the problem regarding understanding the existing system and proposed system
as well. We used a communication medium like phone and social media like face book,
messenger etc. for the communication purpose.

1.9.3 Change management

In our project development management, we have a management structure that lead to project
quality that enhances project quality.

1.10 Limitation of the project

 Users are required to have basic computer skill to use the system.

 The system will not accept the customer speech and image
 CHAPTER TWO
2. MODELING AND PROTOTYPING

2.1 Introduction of existing system

Whenever a compliant requires service from the office, he/she is required to go to the concerning
staff of the University and then he/she is required to present the grievance to the required
grievance handling office. In the current system, complaints written in paper and will be
presented to the grievance handling office. Then the manager will look after it and then he /she
will take care about the complainant’s problems. After that the manager tries to solve the
problem despite the fact that its process is time consuming.

The current system is time taking, unqualified, costly and not satisfactory since the system is not
computerized system for complainant’s purpose. Employee/admin spend much time to work their
own activity due to all information is transferred manually by paper-based method and difficult
to register new complainant, complainant must physically join to the office to get service,
difficult to manage compliant information. So this system consumes time and money.

In the existing system to Compliant Management System details or in the document or the user
should use much time to disclose his complaint to the grievance handling office. Some defects in
the existing system are:

 Performance:

To give real time complaints related solution to the users, current system does not
perform quick response.

 Service:

 Current system cannot give the information quickly because offices work
manually rather than using computerized system.
 2.2 Proposed system

To improve the current complaint handling system for the University, we have proposed mobile
device based complaint management system. The system simplifies registration process of
Complaints. The system enables users of the system to register complaint by sending text
message to the system. This system is designed to create alternative way of complaint
management system for the university. It reduces burden for the grievance responding organ and
any users simply use the system from anywhere at any time.

 The registered complainant forwards his/her complaint to the required office; this in turn
will reduce time needed to process and provide a solution for complaint.

 Provide a very good and fast service for the users by computerized system.

 The system being developed solves the problems appear in the current system.

 The new system enables users to register their information.

 The new system increases the availability and performance of the system. In this system
user can easily register complaint being on his/her computer or smart phone using the
system, rather than going to office .

2.3 System Requirement Specifications

Requirement specifications develop a recommended process improvement action which can

include quick fix for serious problem, modification of existing manual systems or the initiation
of the a organization. There are two main types of system 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.3.1 Functional requirement

The functional requirements are concerned with the actual performance of the system that is
going to be developed. Functional requirements describe the functionality or service provided by
the new system:
  The system is capable of sending complaint to the required office/department.

 The system is capable Registering new complaint and complaint information to the
database in the main process of the system.

 Allow registering complaint by sending text message.

 Enabling the users to retrieve the registered complaint that they registered orderly.

 It organizes and makes searchable buttons.

 The system generates a report: Allow to generating different types of reports which
include types of complaints registered on specific date, month or year, viewing
summarized report.
 Allow the administrator to manage access to the system.

2.3.2 Non-functional 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 accessing huge amount of data. And the
system should be accessed by many users and should have fast response time.

• User interface:-The system is user friendly. Users can have access to the system from
anywhere using their desktop or mobile phones.

• We should make the system simple and easy to understand and to interact with. It should
be easy and painless for the user to register and view information.
 2.4 System Requirement Specification and Analysis modeling (SRS)

2.5 CRC (class responsibility collaboration)

Class Responsibility Collaboration (CRC) cards are a brainstorming tool used in the design of
object-oriented software. They are typically used when first determining which classes are
needed and how they will interact.

 Class –represents a collection of similar objects. An object is a person, place, thing,

event, or concept that is relevant to the system at hand. The name of the class appears
across the top of a CRC card and is typically a singular noun or singular noun phrase.
 responsibility – something that a class knows or does
 collaborator- another class that a class interacts with to fulfill its responsibilities

There are three types of classes

 Actor Classes – actors that appear in use case.

 Business Classes – places, things, concepts, and events that describe what the business is
all about

UI Classes – screens, menus, homepages, and reports

Figure 2.1 CRC diagram of actor class
Figure 2.2 CRC diagram of user interface class
Figure 2.2 CRC diagram of user interface class

Figure 2.3 CRC diagram for business class

 2.6 Use case modeling
2.6.1 Essential use case modeling
The Essential Use Case is a use case represents a description of system functionality from a
particular point of view. Its purpose is to present a graphical overview of the functionality
provided by a system in terms of actors, their goals (represented as use cases), and any
dependencies between those use cases. The actors of our system that we used to do the project
are administrator, respondent and the complaint. But in the context of this section the essential
use case describes the existing system which runs manually has three actors (namely
complainant, respondent and higher respondent) each of which consisting different actors
performing the same function within the system. Thus the following use case is elaboration of
the existing system.
Figure 2.4 essential use of complaint management system
 2.6.2 Essential use case description
Use case name Complain by letter
Use case ID UC1
Actors Complainant (Student, staffs, department head, college dean,
registrar staff).
Description Complainant need to have a form to be filled; for a serious issue
that is necessarily not complained orally
Pre-condition The complainant must fill the form correctly
Post condition His/her complaint will be accepted by the respondent
Basic course of action 1. The complainant is dissatisfied by the service provided by
different sectors like staffs, department head, college dean,
library, HRM, book store, etc.
2. The complainant decides to complain to the respondent for
which service he was dissatisfied.
3. The complainant fills the form that illustrates who the
complainant is, the way in which he/she was treated/body
of the complaint/.
4. Takes the filled form embodied his/her complaint to the
respective respondent.
5. The respondent receives the filled form.
6. The respondent starts checking the filled form
7. Use case ends.
Alternative course of action If the complainant does not fill the form correctly,
6. the respondent tell him/her to fill the form correctly
again
7. return to step 3
8. the use case ends

Table 2.1 essential use case description for complain by letter

Use case name Apply to the higher

Use case ID UC2
Actors Complainant(student, staff, department, registrar staff)
Pre-condition The complainant must first see the decision made by the lower

Post condition
Basic course of action
Alternative course of action
academic hierarchy administration.
The complainant’s complain will be hosted by the higher respondent
1. the complainant dissatisfied by the decision made by the
lower respondent
2. The complainant fills new form correctly that mention his/her
dissatisfaction with decision made by the lower respondent
and for which service /purpose/ his/her truth is kept hidden.
3. The complainant then takes the filled form to the respective
higher hierarchy respondent for revision of decision made.
4. The higher respondent checks the form
5. The higher respondent receives the complaint brought by the
complainant
6. The use case ends
If the complainant were unable to fill the form correctly,
4.the higher respondent tell him/her to fill new form correctly again
5. return to step 2
6. use case ends

Table 2.2 essential use case description for apply to the higher

Use case name Provide feedback

Use case ID UC3
Actors Complainant (staffs, department, student, registrar staff).
Precondition Feedback provision goes after the respondent made decision on
complaint complained before, despite the complainant satisfaction.
Description Complainant provides feedback after they got solution for their
complaint.
Post condition Feedback given for the respondent
Basic course of action 1. The complainant sees the decision made by the respondent.
2. The respondent provides the complainant with feedback
filling form for which service they had already complained.
3. The complainant fills the forms correctly
4. The respondent receives the filled feedback form from the
complainant
5. The respondent checks filled form
6. The complete feedback will be stored.
7. Use case ends.
Alternative course of action If the complainant doesn’t fill the feedback from correctly…
 5. The respondent orders the complainant to fill it again
correctly.
6. Return to step 2
7. Use case ends.

Table 2.3 essential use case description for provide feedback

Use case name Respond by letter

Use case ID UC4
Actors Respondent (department, ICT directorate, college dean, HRM)
Description Respondent provide solution for which complaints they were
presented in letter form.
Precondition There must be complaint delivered in letter form.
post condition The solution for the complaint comes to available.
Basic course of action 1. The respondent analyses the complaint/problem
2. The respondent finds out the causes of the problem
3. Abstract solution for the problem come to existence
4. The abstract solution is written on formal paper.
5. The solution/response written on the paper will be given to
the organ of complaint.
6. The use case ends.

Table 2.4 essential use case description for the respond by letter

2.6.3 System use case modeling

In the complaint management system the actors and functional requirements interact with use
case models. Use case diagram shows over all activities of the system diagrammatically.

Actor of the system

 Officers such as

• Grievance handling officer

• Department head

• Human resource management officer

• Collage dean
 • Library manager

• Book store, etc.

 Users

 System administrator

• Use case

• Login

• send complaint

• Modify complaint

• View notification

• View and replay complaint

• Create account

• Manage account

• Add user

• Send decision

• Send feedback
Figure 2.2 system use case of complaint management system

2.6.4 System use case description

Use case name Login

Use case ID UC1
Actors System administrator, student, Department head, Human resource
management, Collage dean, staff manager, Finance Directorate, library
manager, book store manager, etc.

Description Users are authenticated and taken to their own

user interface
Pre-conditions Users have username and password
Post-conditions User is authenticated and taken to his/her own user interface
 Basic course of action User action System response
1. The user opens the main 2.the system display the Main
home page Home page
3. The user selects what type of 4. The system takes the user to
user (complainant, respondent or his/her account type interface.
admin) is he/she.
5. the user inputs user name and 6. The system takes the user to
password and click on login button his/her home page.
7. The use case ends.
Alternate course of action login name or password is invalid
6.The system displays invalid user name or
password message
7.The user reenters the user name and
password
8. The use case continues from step 5.
9. The use case ends.

Table 2.5 use case description to Login

Use case name send complaint

Use case ID Uc2

Actor Complainant(student, staffs, staffs manager, department head)

Description The user can register complaint to the required respondent.

Precondition The complainant must login first

Post condition The system can register complaint information

Basic course of action User action System response

1. The user opens compliant 2. The System displays the register

page complaint information Page.

4.The System displays a success

 3. The user fills the Necessary
message
information and Submit the
forms. 5 .Use Case Ends

Alternative course of If the submitted form is not filled completely or invalid.

action 4 The system displays “unsuccessful” message

5. The user fills the missing information and corrects invalid inputs

The use case continues from step 3

6. The use case ends.

Table 2.6use case description to send complaint

Use case name Manage account

Use case ID UC3

Actor Administrator of the system
Description This system process, enable the system administrator to manage
all user account of the system. This is user account creation,
activate and deactivate.
Precondition The system admin must login first
post condition User accounts managed by the administrator
Basic course of action Actor action System response
 1. The administrator 2. The system displays the admin
opens the admin home home page.
panel.
4. The pops up the system admin
3. The admin selects the
with three buttons namely
“manage account” button.
(remove, deactivate and activate
5. The admin selects and
account).
clicks the button he/she
deserves. 6. The system displays the form
7. The system admin inputs that will be filled with user’s
the user unique identifier into unique identifier.
the provided space and click
8. The system checks the input and
on “search” button.
displays the required user
9. The admin then performs
information with his/her account
the operation.
status.

10. The system displays the

“successful” message.
11. use case ends
Alternative course action If the administrator fillsan identifier that does not much any
account….
8.the system displays “no matching account available” and system
rolls back to step 7
9. Use case ends.
Table 2.7 Use case description for manage account

Use case name View notification

Use case ID UC4
Actors Department head, Human resource management system, Collage dean, staff, staff m
Description User or organs of the compliant ask/post their difficult complaint to the required re
Pre-condition Users must login first.
Post condition Respondent views the complaint
Basic course of action User action System response
 1.The user click on view 2.The System displays the
Notification button. notification Page
3. The user views the 4.Use Case Ends
notification.

Table 2.8 Use case description for view notification

Use case name send decision

Use case ID UC5
Actors Department head, Human resource management system,
Collage dean, staff, library, book store manager
Description Respondents submits their complain resolution to their user
and organ of the compliant after completed.
Pre-condition The complainant must login first.
Post condition Send their resolution to the owner of the complaint.
Basic course of action actor action System response

1 the respondent login to the 2 the system displays the home

system page of the respondent.
3 the respondent click on the 4 The system displays the
respond button. form that will be filled
5. The respondent fills the by the respondent.
response information 6the system checks the fields
correctly and click on submit are filled correctly and pops up
button. “sent successfully” message.
7. The use case ends.

Alternative course of action If the respondent is unable to fill the response format correctly

6. The system tells the respondent that he/she hasn’t filled

the response format correctly.

7. The use case return back to step 5

8. Use case ends.
Table 2.9 Use case description for send Decision

Use case name Send Feedback

Use case ID Uc6

Actor Complainant(student and other complainant )

Description complainant provide feedback after they received response from

the respondent

Precondition Must login first.

post condition The complainant sends important feedbacks to the respondent.

Basic course of action Actor action System response

1. The complainant opens the 2 the system displays the home

home page. page.

3. click on feedback menu 4 the system provides the space

5. Fill the information on the
label and Click on submit
button.
provided for the feedback filling
form.
6 the system checks the user inputs
and pops up the “successfully sent”
message.

7 the use case ends.

Alternate course of action If the complainant does not fill the form correctly….

6. The system displays “fields not filled correctly” message.

7. the use case goes back to step 5

8. Use case ends.

Table 2.10 use case description for send feedback

 Use case name View feedback
Use case ID UC7
Actor Department head, Human resource management system, Collage
dean, Office manager, Finance Directorate
Description The listed actors view feedbacks sent by users.
Precondition The replayed feedback from the complainant must exist
Post conditions The actors successfully watch feedbacks
Basic course of action •Actors click on view feedback icon
•The system makes display feedback
•Use case ends
Alternate course of action The complainant may not replay feedback
The feedback viewer logs out of the system
Table 2.11 Use case Description for View feedback Table1.12 Use Case Description for Search

Use case name Manage timely process

Use case ID UC8

Actor System administrator

Precondition Admin first login.

Description The system administrator manages the timely process after

the complaint is sent to the respondent. This speeds up the
timely ongoing of the process.

Post condition The administrator sends notification for the respondent (if
any)
Basic course of action Actor action System response

1. User fills, the 2.the system checks the

type of information and sends the
complaint, and information to the system
the user name of administrator
the respondent 4 the system displays the
 and click on information sent to the admin.
“submit” button. 6. The system checks the
3. The administrator information and pass it to the
open his/her home and respondent for which the admin
view what the user sent sent the notification.
to him/her. 7. Use case ends.
5. The administrator fills
the notification form
correctly and send to the
respondent under control.
Alternative course of A1 If the user does not fill the information correctly to send
to the system administrator…
action
2. The system displays error message and use case roll
back to step 1
A2 if the administrator makes error while filling notification
form…..
6. The system displays error message and the use case goes
back to step 5.
7. The use case ends.

Figure 2.14 Use Case Description for Manage timely process

Use case Name Add User

Use case ID UC9

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

Flow of Events 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 acknowledgment

message.

A2 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 2.15Description of Add User Use Case
Use case name Create account
Use case ID UC10
Actor Student
Description Students should create account to be part of the system
Precondition The student should have the campus Id and UID
Post condition The student creates account
Basic course of action Actor action system response

1. Student open the 2. System displays the home

website on browser. page of the system.
3. The user click on the 4. The system displays the form to
create account button. be filled with the user information.
5. The student fills the 6. The system checks the
information correctly and information filled by the student
then click on the submit and pops up the “account
button. successfully created” message.
7. Use case ends.
Alternative course of action  If the student information does not match with the
existing information.
5. The system tells the student to fill the correct information.
6. The use case stars again from step 5.
7. Use case ends.
Table 2.16 Description of create account Use Case

2.6.5 Features
Features of the system are the features that the system is all about after completed and describes
how efficient and effective the system is. So our system will have the following features after
completed.

• User interface:-The system user friendly. We should make the system simple and easy to
understand and to interact with. It should be easy and painless for the user to register and
view information user can understand the system.

• Resources: - the system is compatible with the specified hard ware and software
requirement and the system should have compatible with any environment.
 • Scalability:-The ability to add capacity (and users) to a deployed system over time.
Scalability typically involves adding resources to the system but should not require
changes to the deployment architecture.

• Availability:-The system to be available 7 days a week and 24 hours a day. And A

measure of how often a system’s resources and services are accessible to end users, often
expressed as the uptime of a system

• Performance:-The systems have high performance and error free and the measurement of
response time and latency with respect to user load conditions.. So, the system should be
capable of handling as many users as possible while maintaining the performance of the
system.

 Error Handling

The system is expected to handle errors while input. The system validates data entry for
correctness. Errors that occurred from the wrong doing of users will be handled by appropriate
exception handling mechanism. If an error occurs, for instance if required fields missed while the
user submit complaint using website, the system will identify the error and notify the user so that
he/she can take the appropriate corrections.

2.7 User interface prototyping

2.7.1 Traditional User-Interface Prototyping
User interface prototype is a low fidelity model or prototype of the user interface for system that
represents the general ideas behind the user interface in a technology-independent manner.
Figure 2.3 traditional user interface of complaining form

2.7.2 User-Interface Flow Diagramming

User Interface prototype is an excellent means of exploring user interface. User-interface flow
diagrams—also called storyboards, interface flow diagrams, Windows navigation diagrams, and
context-navigation maps of the complaint management system and information hub of Haramaya
University. The importance of this diagram is that to show the simple flow of system function.

The boxes represent major user interface elements and the arrows represent the possible flow
between them.
Figure 2.3 user interface flow diagram of the system

2.8 Supplementary specification

2.8.1 Business rules
Business rules are a formal expression of knowledge or preference, a guidance system for
steering behavior (a transaction) in a desired direction. On the grand scale, business rules, then,
are the guidance system that influences the collective behavior of an organization’s people and
information systems.

Business rules approach aims to deliver that guidance system as externalized rules, automated as
an integral and active component in systems architecture. The following descriptions are the
business rule of the proposed system.
The system does not allow the student, respondent and the system administrator without logging
in to the system.

 Description: all user of the system should inter valid user name and password to
interact with the system or create account if he/she is new comer for the system,
otherwise access denies.

Name: create account

Identifier: #BR1

Description: all new students need to create account depending on the fact that their user
information has already been registered to the data base for the approval purpose otherwise they
should be senior user of the system.

Name: login to the system

Identifier: #BR2

Description: all the actors (student, system administrator and the respondent) are eligible only
when they input correct user name and password to operate within the system.

Name: register complaint

Identifier: #BR3

Description: the complainant send their complaint to the appropriate respondent by selecting
only complainant account type otherwise he/she cannot perform what the complainant can do by
logging via rest of the account type.

Name: response replay

Identifier: #BR4

Description: all respondents replay a response logging in via respondent account only
otherwise they cannot respond to complaint using other account type.

Name: feedback replay

Identifier: #BR5

Description: actors those replay feedback need to be those got service (response) from the
respondent, because feedback is usually given after certain service has been delivered regardless
of its satisfaction/dissatisfaction.

Name: addition of user to the system

Identifier: #BR6

Description: once user added to the data base of the system, he/she can create his/her
respective account that enables to interact and perform activities within the system. This helps to
prevent unusual trick.

Name: modification of complaint

Identifier: #BR7

Description: whenever user wants to modify the complaint, the user can retrieve the previous
complaint and re-write /edit the complaint to whatever he/she wants to focus. This all is done by
selecting the “modify complaint button”.

Name: account management

Identifier: #BR8

Description: in our system, admin is the account manager in which he/she can deactivate
when the user leaves the system for specified period of time, activate user account after the
restored back to the system and remove the account only when the user leaves the system
permanently.

Name: generate report

Identifier: #BR9

Description: the respondents generate report that elaborates how much the complaint is hosted
and replayed, i.e. it generates the number of complaints replayed with response and those
complained but not replayed with response, so useful for performance evaluation.

2.8.2 Constraints
Constraints are problems those occur while performing the project to restrict the project from
attaining its objective or reduce the quality of the system. In our project the constraints we are
facing are:

 Resource unavailability
 Shortage of time
 Work overload
 Situation discomfort ability
Chapter Three
3. DESIGN DOCUMENT
3.1 Classes-type layered approach

Figure 3.1 classes type layer approach diagram for the system.
Figure 3.2 class diagram of complaint management system
 3.2 Sequence diagram
Sequence diagrams describe interactions among classes in terms of an exchange of

messages over time. They're also called event diagrams. A sequence diagram is a

good way to visualize and validate various runtime scenarios. These can help to

predict how a system will behave and to discover responsibilities a class may need

to have in the process of modeling a new system.

Figure 3.3 sequence diagram for login

Figure 3.4 sequence diagram for create account
Figure 3.5 sequence diagram for add user
Figure 3.6 sequence diagram for send complaint
Figure 3.7 sequence diagram for send response
Figure 3.8 sequence diagram for manage account
Figure 3.9 sequence diagram for view complaint
Figure 3.10 sequence diagram for view response
 3.3 3.2 Activity diagram

Figure 3.11 activity diagram for login

figure 3.12 activity diagram for add user.

Figure 3.13 activity diagram for create account.

Figure 3.14 Activity diagram for sending complaint
Figure 3.15 activity diagram for manage account
Figure 3.15 activity diagram for send feedback

Figure 3.17 activity diagram for view response

Figure 3.18 state chart diagram for login
Figure 3.18 state chart diagram for create account

Figure 3.19 state chart diagram for add user

Figure 3.20 state chart diagram of send complaint
Figure 3.21 state chart diagram for manage account.
Figure 3.22 object diagram of complaint management system
 Persistent Modeling/ Database Design
Data base name: CMS

Tables name:

 Account
 Complaint
 Response
 Feedback
 Student
 Respondent
 Administrator
 Report

N Table name Attributes Data type Primary key Foreign key

o
1 Account User id Varchar(20) User id
password Varchar(20)
User type String(20)
User name Varchar(20)
First name String (20)
Middle name String (20)
Last name String(20)
Sex int(3)
2 Complaint Comp.id Int(9) Comp.id Stud.id
Respt.id
Comp. type String (20)
Comp. content
Resp.name
Complainant
name
3 Response Resp.id Int(9) Resp.id Respt.id
Resp.content String() Stud.id
Respt.name String(20)
Compt.name String(20)
4 feedback Fed.id Int(9) Fed.id Stud.id
Fed. Type String(20) Respt.id
Stud.name String(20)
Respt.name String(20)
5 Student Stud id Int(10) Stud.id Comp.id
First name String(20) Resp.id
Middle name String(20)
Last name String(20)
Batch String(2)
Address Varchar(50)
Sex String(20)
Age Int(3)
department String(30)
6 Respondent Respt.id Int(10) Respt.id Stud.id
First name String(20) Comp.id
Middle name String(20) Fed.id
Last name String(20)
Staff no. Int(5)
Position String(30)
Address Varchar(50)
7 administrato Admin.id Int(10) Admin.id
r First name String(20)
Middle name String(20)
Last name String(20)
Address Varchar(50)
Role String(30)
8 report Rep.id Int(10) Rep.id Admin.id
Date Date
No. complaint Int()
No. response Int()

Normalized Physical database model

Figure 3.23 component diagram of complaint management system.
Figure 3.24 deployment diagram of complaint management system