UNIVERSITY OF GONDAR

FACULTY OF INFORMATICS
DEPARTMENT OF COMPUTER SCIENCE
ONLINE COMPLAINT MANAGEMENT SYSTEM
IN UOG
INDUSTRIALPROJECT
BY
NAME OF THE STUDENTS IDNO

Adisu Zeleke GUR/01373/09

Amanuel Tegegne GUR/01400/09
Berhane Hailay GUR/01447/09
Betelhem Abebe GUR/01452/09
Daniel Mamo GUR/01489/09

A Group Project
Submitted to the Department of Computer science, Faculty of Informatics,
University of Gondar, in meeting the preliminary project requirement for partial
fulfillment of the award of Bachelor of Science Degree in Computer science.
Gondar, Ethiopia
Date/Year: February 10, 2020.
 APPROVAL

This Group Project entitled Online Complaint Management System in the University Of Gondar
has been read and approved as meeting the preliminary project requirements of the Department
of Computer science in partial fulfillment for the award of Bachelor of Science degree in
Computer science, University of Gondar, Gondar, Ethiopia.

Approved by:-

1. Name of Advisor: ___________________________ Signature:________Date:___________

2. Name of Project Coordinator: ____________________Signature_______Date:___________

i
 ACKNOWLEDGMENT
Primarily, we would like to thank the almighty God for the endless blessing and grace that has
been reasons for these achievements.

Secondly, We would like to express our gratitude and heartfelt thanks to our advisor instructor
Zewudu who advises us what to include and what to exclude in our project friendly. We could
not do much without your guidance and support.

We are thankful to people who participated in our survey study for their responses and
cooperation. Your response to our questions was important to the success of our project.

Last but not the least, we would like to thank the University of Gondar Department of
Computer Science project committee for their contribution to the achievement of our
project by losing their time to create a suitable condition to do our project.

ii
 Contents
APPROVAL .................................................................................................................................... i
ACKNOWLEDGMENT................................................................................................................. ii
LIST OF FIGURES ....................................................................................................................... vi
LIST OF TABLES ........................................................................................................................ vii
EXECUTIVE PROJECT SUMMARY........................................................................................ viii
LIST OF ACRONYMS ................................................................................................................. ix
CHAPTER ONE ............................................................................................................................. 1
1. INTRODUCTION ................................................................................................................... 1
1.1. Background of the study .................................................................................................. 2
1.2. Statement of the Problem ................................................................................................. 2
1.3. Objectives of the project .................................................................................................. 3
1.3.1. General objectives ..................................................................................................... 3
1.3.2. Specific Objectives ................................................................................................... 3
1.4. Scope of the project .......................................................................................................... 4
1.5. Limitation of the project................................................................................................. 4
1.6. System Development Methodology ................................................................................. 4
1.6.1. Investigation (fact-finding) methods......................................................................... 5
1.6.2. System Development Tools ........................................................................................... 6
1.7. Significance of the Project ............................................................................................... 8
1.8. Beneficiaries of the project .............................................................................................. 9
1.9. Feasibility Study............................................................................................................... 9
1.9.1. Operational feasibility............................................................................................. 10
1.9.2. Economic Feasibility .............................................................................................. 10
1.9.3. Technical Feasibility ............................................................................................... 10
1.9.4. Legal feasibility ...................................................................................................... 10
1.10. Time and Budget plan................................................................................................. 10
1.10.1. Estimated Time Schedule .................................................................................... 10
1.10.2. Budget Breakdown .............................................................................................. 11

iii
CHAPTER TWO .......................................................................................................................... 13
2. REQUIREMENT ANALYSIS .............................................................................................. 13
2.1 Current System Description ........................................................................................... 13
2.1.1. Major function of the current system ...................................................................... 13
2.1.2. Problem of Existing System.................................................................................... 13
2.2. Requirement Gathering .................................................................................................. 14
2.2.1. Requirement Gathering Methodologies .................................................................. 14
2.2.2. Business Rules ........................................................................................................ 14
2.3.1. Overview ................................................................................................................. 17
2.3.2. Functional Requirement .......................................................................................... 17
2.3.3. Nonfunctional Requirement .................................................................................... 18
CHAPTER THREE ...................................................................................................................... 21
3. SYSTEM MODEL ................................................................................................................ 21
3.1. Scenario .......................................................................................................................... 21
3.1.1. Use Case Model ...................................................................................................... 25
3.1.2. Use Case Diagram................................................................................................... 25
3.1.3. Description of Use Case Model .............................................................................. 27
3.1.4. Activity diagram ..................................................................................................... 39
3.1.5. Object Model .......................................................................................................... 44
3.1.6. Data dictionary ........................................................................................................ 44
3.1.7. Class model ............................................................................................................. 46
3.1.8. Dynamic Modeling ................................................................................................. 47
3.1.9. User Interface .......................................................................................................... 52
CHAPTER FOUR ......................................................................................................................... 54
4. SYSTEM DESIGN ................................................................................................................... 54
4.1. Introduction .................................................................................................................... 54
4.1.1. Design goals ............................................................................................................ 54
4.2. Current software architecture ......................................................................................... 55
4.3. Proposed software architecture ...................................................................................... 55
4.3.1. Subsystem decomposition....................................................................................... 56
4.3.2. Hardware/ software mapping .................................................................................. 57

iv
 4.3.3. Persistent data modeling ......................................................................................... 58
4.3.4. Access control and security .................................................................................... 59
4.3.5. Detailed class diagram ............................................................................................ 60
4.3.6. Package Diagram .................................................................................................... 61
4.3.7. Deployment ............................................................................................................. 62
REFERENCES ............................................................................................................................. 64

v
 LIST OF FIGURES
Figure 1.1 Incremental model ......................................................................................................... 5
Figure 3.1 Use case diagram for complaint management system ................................................. 27
Figure 3.2 Activity diagram for login ........................................................................................... 40
Figure 3.3 Activity diagram for add user. ..................................................................................... 40
Figure 3.4 Activity diagram for send decision.............................................................................. 41
Figure 3.5 Activity diagram for view notice. ................................................................................ 42
Figure 3.6 Activity diagram for the user or compliant person registration. ................................. 43
Figure 3.7 Activity diagram for log out. ....................................................................................... 44
Figure 3.8 Class diagram .............................................................................................................. 47
Figure 3.9 Sequence diagram for login ......................................................................................... 48
Figure 3.10 Sequence diagram for creates account and update account....................................... 49
Figure 3.11 Sequence diagram for handling grievance office view compliant information ........ 50
Figure 3.12 Sequence diagram for registering a compliant user. ................................................. 51
Figure 3.13 Sequence diagram for send solution to the compliant person. .................................. 52
figure 3.14 Home page user interface. .......................................................................................... 53
Figure 3.15 Login user interface. .................................................................................................. 53
Figure 4.1 System architecture for the proposed system .............................................................. 56
Figure 4.2 Subsystem decomposition. .......................................................................................... 57
Figure 4.3 Deployment diagram. .................................................................................................. 58
Figure 4.4 Persistent data modeling. ............................................................................................. 59
Figure 4.5 Detailed class diagrams. .............................................................................................. 61
Figure 4.6 Package diagram .......................................................................................................... 62
Figure 4.7 Deployment diagram. ................................................................................................. 63

vi
 LIST OF TABLES

Table 1.1 Estimated Time Schedule ............................................................................................. 11

Table 1.2 Budget breakdown ........................................................................................................ 12
Table 2.1 Business rule ................................................................................................................. 16
Table 3.1 Use case description for Login ..................................................................................... 28
Table 3.2 Use case description register complain. ........................................................................ 29
Table 3.3 Use case description for update account ....................................................................... 30
Table 3.4 Use case description for view notice ............................................................................ 30
Table 3.5 Use case description for send decision. ........................................................................ 31
Table 3.6 Use case description for send feedback. ....................................................................... 31
Table 3.7 Use case description for view feedback. ....................................................................... 31
Table 3.8 Use case description for logged files. ........................................................................... 32
Table 3.9 Use case description for view decision. ........................................................................ 32
Table 3.10 Use case descriptions for Generate report. ................................................................. 33
Table 3.11 Use case descriptions for Backup and restore the database ........................................ 34
Table 3.12 Use case descriptions to add staff members. .............................................................. 34
Table 3.13 Use case description for view report........................................................................... 35
Table 3.14 Use case descriptions for Update complaint. .............................................................. 36
Table 3.15 Use case description for create a new account. .......................................................... 37
Table 3.16 Use case descriptions for view complaints information. ............................................ 37
Table 3.17 Use case description for post notices. ......................................................................... 38
Table 3.18 Use case description for log out. ................................................................................. 39
Table 3.19 Data dictionary............................................................................................................ 46
Table 4.1 Access control. .............................................................................................................. 60

vii
 EXECUTIVE PROJECT SUMMARY
The objective of the project, the online complaint management system in case of the University
of Gondar which enables the grievance handling office to record complaints in the organization,
viewing complaint records, customers register to complain easily. The online Complain
management System project mainly consists of different types of actors. Those are grievance
handling of organization, employees, and students In general term the function of this project to
manage the information of complaint in terms of fast, managing input/output and advertising.

The system enables employees and students of the university to participate in controlling the
quality service provided in a university and able to users’ report/complain their problems to the
grievance handling office to have an effective and efficient response.

viii
 LIST OF ACRONYMS
Acronyms Description

BR Business Rule

CPU Central Processing Unit

CSS Cascading Style Sheath

DBMS Database Management System

GB Giga Byte

GUI Graphical User Interface

HRM Human Resource Management

HTML Hypertext Markup Language

MYSQL My Structural Query Language

OCMS Online Complaint Management System

PHP Hypertext Preprocessor / Personal Home Page

PC Personal Computer

PW Password

RAM Random Access Memory

TCP/IP Transmission Control Protocol / Internet Protocol

UC Use case

UN User Name

UML Unified Model Language

URL Uniform Resource Locator

WAMP Window, Apache, MYSQL, and PHP.

ix
 CHAPTER ONE

1. INTRODUCTION

Advancement in information communication technology changed the scene of communication

between governments and citizens. Information communication technology not just gives
chances to governments to direct their citizens to the websites for information, applications, and
transactions yet it likewise permits citizens to take advantage of the internet in place should
launch their contact with governments furthermore should express their appeals, complaints,
suppositions, and suggestions.

E-government allows citizens to interact with the 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 websites 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 can request public services electronically and get response accordingly
[1]. The portal allows users to provide their feedback for future improvements.

The emergent area in which citizens can interact with government is websites. Website is a
natural extension to e-Government and one promising area of the website is a complaint and
problem management, which is 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.

Therefore this project aims to design and implement a web-based compliant management system
for the University of Gondar.

Hence developing a systematic approach to managing those complaints successfully, there is a

need to computerize the manual system.

1
 Introduction 2020G.C

1.1. Background of the study

Establishments such as schools, hospitals, government secretarial, financial institutions, etc.
which have a large number of customers or clients received an enormous amount of complaints
per day, and this complaint has to be documented and field for access and stored for future
reference.

Academic growth can be of various concerns in the academic environment to promote the social
and functioning educational system. For an effective educational system to take place some
issues in an academic environment should properly address to, take for instance issue of
complaints management system in the university. This issue had created a lot of problems for
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 the administrator to
make every effort to resolve potential or actual academic complaints [2].

1.2. Statement of the Problem

Currently, the university has no web-based system developed for controlling different complain
management. The current complaint registration system is time taking and inconvenient for the
complainant.

Anyone who wants to register complaint should visit in person one of the offices found in the
required office. 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 fears to report
thinking something wrong might happen to them do not have other means to place their
complaint. Also there is no any form of application system that used to help for customers to
process their complaint from everywhere and every time with their PC. So that it becomes
necessary for user to have desktop or laptop for using the system and making their complaint
suitably.

The design and implementation of a complaint management system is an online application that
will solve the complaint information problem facing customers in the university environment.
The basic problems facing (manual) complaint monitoring are:

 As the complaint is accepted from the customer it is documented manually.

2
 Online Complaint Management System In University Of Gondar 2020G.C

 Times taking to generate a complaint report.

 When the customers explain their complaint to the grievance handling office physically
they may fear than sending their complain by writing.
 The same complaint information is stored in many copies repeatedly in different forms.
 Lose of complaint files or documents.
 Finding and retrieving data are difficult.
 The poor performance of the manual system may lead to the missing or exploitative of
the complaint by the staff or any member of the management.
 Deprived customer satisfaction because of the manual based service and it takes time to
provide the system less responsive to make self-assessment over customer satisfaction

1.3. Objectives of the project

1.3.1. General objectives

The general objective of this project is to design and implement the web-based complaint
management system at the University of Gondar.

1.3.2. Specific Objectives

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

 Explore the existing University of Gondar approach to handling employees' and

students' complaints.
 To design web-based complaint registration, solving and appeal management system.
 To analyze and organize compliant information in a way that it will be used to design
the new system.
 To design and implement a database for proper implementation of the complaint
management system.
 To design an easy, fast and secure way for complaining management.
 To announce the rule and regulation of the institutions to the members of it.
 To make a backup of the system and restore it when necessary.
 To develop a communication system among members of the association with the users
of the institution.

3
 Introduction 2020G.C

1.4. Scope of the project

This study covers the procedure for managing complaints information at the University of
Gondar in which:-

 Employees and students can report issues from their desktop PC,
 Compliant handler manages the reported issue at the back-end infrastructure.

1.5. Limitation of the project

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

 With regard to its use, the system will only cater to the English reader. The GUI
and associated documentation are in English. This may present a problem for non-
English readers.
 Customer is required to have basic computer skill to use the system.
 The system will not accept customer speech.

1.6. System Development Methodology

System development methodology refers to the framework that is used to structure plan and
control the flow of developing an information system there are different system development
methodologies that are suitable for different projects based on the values technical organizational
project and team considerations. For this project, the team used the incremental model. The
reason why we select incremental model development is that it has the following advantages.

 It is flexible and less expensive to change requirements and scope.

 Object-oriented systems development is a way to develop software by building self–
contained modules or objects that can be easily replaced, modified and reused.
 Errors are easy to be identified.
 Encourages re-use not only modules but also the entire design.
 A customer can respond to each building.
 It is easier to test and debug during a smaller iteration.
 Ease of modification and extensibility of object-oriented models.

The Incremental Approach is a method of software development where the model is

designed, implemented and tested incrementally (a little more is added each time) until the

4
 Online Complaint Management System In University Of Gondar 2020G.C

product is finished. Specification, development, and validation activities are interleaved

rather than separate, with rapid feedback across activities.
activities
In an incremental model, the whole requirements are divided into various builds. Each
module (independent units) passes through the requirements, designs,, implementation
implementation, and
phases.
The incremental model build model is a method of software development where the product
is implemented and tested incrementally until the product is finished.

Build Build build Whole

1 2 3 requirements

Figure 1.1 Incremental model

1.6.1. Investigation (fact-finding)

( methods

There are several data collection methods. From these methods

methods to do our project
project, we used
observation and interview methods.
method

[Link]. Interview technique

we interview members of the organization from their office and members from their workplace.
Like:

5
 Introduction 2020G.C

What kind of system the organization has used?

How does the existing system work?
What is the duty of the institution workers?
What are the problems of the existing system?

[Link]. Observation
We use this method to get the right information about the organization and also to understand
how the existing system works. In this method, all team members have observed and note down
the events from that observation.

1.6.2. System Development Tools

[Link]. Software tools

We use the following programming tools to develop our system.

A. Back end tools

 MYSQL DBMS
 The group members have well experienced in MySQL from the course that we have
taken.

 PHP

Why PHP?
Because:-
 Increased efficiency & usability - PHP provides incomparable efficiency and usability
when it is used for the development of websites.
 Compatible- PHP is compatible with all operating systems including windows and
UNIX among other systems.
 Data processing - a website that has been developed using the PHP functions has fast
features of data processing.
 Easy to understand - when compared with other scripting languages, PHP can be
understood easily because it has simple techniques and features.
 Integration - it is easy to integrate popular web applications using this scripting
language.

6
 Online Complaint Management System In University Of Gondar 2020G.C

 We are familiar with the PHP language, so we select it to develop the proposed
system.

B. Front end tools

 HTML

Why HTML?
Because:-

 Html is a platform-independent language that is predominantly used in the web and

web-based application.

 CSS
Why CSS?

Because:-

 To separate structure from appearance, Create consistent appearance, Ease of

maintenance, Increase accessibility and to apply additional effects (E.g. add a hover
effect to links and Remove underlines on links).

 JavaScript

Why JavaScript?
Because:-

 JavaScript is browser-independent
 Java script is object-oriented (It allows the creation of interactive web page )
 It used to data entry validation.

C. Source code editor

 Bracket.

D. Web server
 Wamp server

7
 Introduction 2020G.C

E. Web browser
 Google chrome
 Baidu spark browser

F. For documentation
 Microsoft office 2007

G. Diagram drawing tool

 Edraw max.

H. For presentation
 Microsoft PowerPoint 2007.

[Link]. Hardware tools

The software which we develop requires the following minimum hardware configuration:

 Computer
 Processor:-Pentium i-5
 RAM:- 4GB
 Hard disk:- 500GB
 Flash
 printer

1.7. Significance of the Project

The significance of this study is to serve better than the existing system which is highly manual
and therefore difficult in terms of monitoring the complaint in the University, it is intended to
improve the database and enhance effectiveness, efficiency, and security of the system. It is also
intended that the study will help in the development of a new and hopefully and standard better
computer-aided system. 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 the
complaint system and also improve the relationship between student, lecturer, and management.
The system is expected to be easy as the student can login to their complaint anytime, staff and
management also can equally respond to customer’s complaints in a more easy way.

8
 Online Complaint Management System In University Of Gondar 2020G.C

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

 To give customers and students satisfaction.

 Faster decision making due to the report generation functionality.
 Investigates and resolves complaints on time.
 Lower human resource needs to accomplish a task.
 Reduce resource wastage.
 View complaints online
 To view notification
 Customers use time effectively.
 Supplies timely information for users.
 To post and submit notifications.

1.8. Beneficiaries of the project

The target beneficiaries of the new system are the organization and the employees and students.
 This project gives the following benefits to the organization.
 Reduce resource consumption of the university (money and human resource).
 Reduce the work overload of the employer this leads to them are loyal to the
institution.
 It increases customer satisfaction by giving efficient services.
 Benefits to the customer
 Reduce employee work overload.
 Give satisfaction
 Improve employee morale
 Benefits to the students
 They can make good and simple communication with their teacher.
 Give satisfaction.

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

9
 Introduction 2020G.C

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.9.1. Operational feasibility

Proposed applications are beneficial only if they can be turned into user-friendly that meet the
users’ requirements. The new system that we develop require organization end-user potential and
skilled manpower, also social acceptability that the system completely changed from a manual
system to computerized due to this potential and skilled manpower of our team to operate the
system is operationally feasible.

1.9.2. Economic 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.

1.9.3. 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 the 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. In this project, the team uses languages such as
HTML, PHP, JavaScript, and CSS to develop the new system. All these are the technology side.
The technical persons who develop the new system are all the members of the project.

1.9.4. Legal feasibility

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

1.10. Time and Budget plan

1.10.1. Estimated Time Schedule

10
 Online Complaint Management System In University Of Gondar 2020G.C

Concerning the project schedule, it will be bound by strict timing so it must be delivered within
the time-bound given below the table. We intend to finalize it hopefully planed it and have it run
in a real environment before June 2020. 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.

Time

May. 05
Dec. 09

Dec. 10

Feb. 05

Jan. 01

May 06
May 16

May 20
May 26
Dec. 04

Feb. 15

Jan. 02
Activities
Project
Proposal

Requirement
Analysis

Design

Implementation
& coding
Testing

Project
Defense
Table 1.1 Estimated Time Schedule

1.10.2. Budget Breakdown

It refers to the benefits or outcomes we are deriving from the product compared to the total cost
we are spending on developing the product. If the benefits are more or less the same as the older
system, then it is not feasible to develop the product. In the present system, the development of
the new product greatly enhances the accuracy of the system and cuts short the delay in the
processing of the application. The errors can be greatly reduced and at the same time providing a
great level of security. Amount of money needed for this project is listed below:-

No Material Amount Price per unit Total price

1. A4 size paper 1 Destin 100 Birr 100 Birr

11
 Introduction 2020G.C

2. Pen 2 5 Birr 10 Birr

3. Flash disk 1 150 Birr 150 Birr
4. For Print 100 sheet 1 Birr 100 Birr
5. HP computer 1 15000 15000 Birr
6. Total:-15,360 Birr
Table 1.2 Budget breakdown

12
 CHAPTER TWO

2. REQUIREMENT ANALYSIS
This chapter contains and describes the current system description, the problem of the existing
system, requirement gathering, requirement gathering methodology, business rules of the
organization, an overview of the proposed system, functional and non-functional requirements of
the system.

2.1 Current System Description

2.1.1. Major function of the current system
The existing system of conducting the complaining process is through a manual system.
Whenever a user’s of the University requires service from the concerned body he/she required to
submit the complaint to the respective office managers. Then the managers will look after it and
then he will take care of the customer’s problems. After that, the managers will enquire and
allocate the problem to the specified person in that department.

2.1.2. Problem of Existing System

The current system is complaining to written in paper and will be submitted at the grievance
handling officers. Due to these users of the existing system wastes much amount of resources.

The current system is time taking, unqualified, costly and not satisfactory since the current
system not uses a fully computerized system for complaint purposes. Respondents spend much
time to work its activity due to all information is transferred manually by a 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 to the lodging a complaint
and evaluate the investigation process, the 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
complaints may lose where and when the jurisdiction is performed. In general, almost all
activities in the system are done manually, so this system consumes time and money. So we
introduce a new system which is fully computerized.

13
 Requirement Analysis 2020G.C

2.2. Requirement Gathering

Requirements gathering (also known as Requirements elicitation or Capture) are the process of
generating a list of requirements (functional, system, technical, etc.) from the various
stakeholders (customers, users, vendors, IT staff, etc.) that will be used as the basis for the
formal Requirements definition. This section describes the steps and procedures that were
followed to accomplish the project. The study was conducted as followed:

2.2.1. Requirement Gathering Methodologies

To obtain data required for the project, the project team used different methods. From the
different methods used includes interviews and observation are among the different
methodologies of collecting the data and information required for the proposed system [3].

Interview
The teams have the chance of asking different questions to the organization employee for
obtaining the required information and data. Generally, by asking appropriate questions the
teams have gathered information’s like it permits clarification of questions.

 How to manage files?

 How they currently perform all activities like how to manage complaints?.
 What is the structure of the organization?
 What is the mission of the organization?
 How the organization currently work?

Observation

The project team uses an observation method for collecting the information in which the
project team observed the actual events which happen in the system. It helped the project team
to get some real information on how the grievance office performs its function and this helps to
strengthen the data that gathered through interview.
2.2.2. Business Rules

In every organization or institution’s there are rules and policies, which used to govern all
activities in a specified workflow, control the workflow, and performed in the work environment
this business rules Or business rules are statements about the organization’s way of doing

14
 Online Complaint Management System In University Of Gondar 2020G.C

business. So the complaint management in the University of Gondar governs and controls the
workflow through the following rules:-

Identifier Username Description

BR1 Administrative
 Work fairly any activities between students without any
Office
discrimination.
managers
 Evaluate complaints based on the rules and guidelines of the
organization.
 Solve the student and employee complain based on evidence.
 Transfer complaints to the next higher body if he cannot solve it.

BR2 Users
 Users must assign the complaint to 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 a solution to their
complaints starting from the lowest one.
 The member of the institution can get complain more than one times if it
is necessary.
 Users of the system contact with the office workers to follow their
complaint procedure.
 Users see the complaint decision on the notice board or by direct
physical communication.
 The customer must have a complaint before register the organ of the
complaint/handling grievance office.
 When members or users get into the organization to get service
they must first register to the institution.

BR3 Department  Receive user complain through oral speech and solve the problem
Head based on complain solving principles.
 The department head solves the user complaints and forwards it to
the college dean if it is beyond its capacity.

15
 Requirement Analysis 2020G.C

 The department head should replay the decision to users.

 The department head should write and post the notice for the customer
complaints.
BR4 College dean  Accept requests from the department head or directly from
customers.
 The decision process is based on rules of the college or it supports
by a 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 satisfy by the decision of their Complaint College
Dean gives the freedom to ask the next branch officer.
 They post a report on the notice board.
BR5 Human  To solve customer notification the complaint solve based on the order of
Resource sequence.

Management  Access of information depends on the authority of the user.

(HRM)  Manage employees of the organization dismiss from the university if

they did not properly work their task.
 They should give different information to employee-customer.
 They post a report on the notice board.

BR6 Grievance  To get immediate response users should face their complaint to the
handling employee who gives that service
officer,  If users are not satisfied with the response they can ask the next
Vice president,
officer.
president
 And also if the next officer not satisfied his/her complaint users
has the right to continue until the final stage (President).
 Officers should clearly announce the service standard.
 They should get to the office on time at work time
Office workers should give a fair decision to complain.
Table 2.1 Business rule

16
 Online Complaint Management System In University Of Gondar 2020G.C

2.3.1. Overview

The proposed system will help the organization to accomplish its tasks such as compliant
registration, retrieving compliant information as well as order request from the service controller
efficiently and effectively and getting feedback from the users. The proposed system is an
automated process of sending a 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 new
system enables all university of Gondar customers to register compliant information to handling
grievance office, to view their notification and helps to handle grievance office replay solution to
the submitted customer post notice to the customer, allows coordination among workers, allows
authorized users to access any file without wasting any time, and the system can store a large
amount of data. The new system increases the security, availability, and performance of the
system. In this system, customers can easily register to complain by sitting at his/her computer
using the system, rather than going to the handling grievance office. All these processes are
handled electronically in the system. The new system handles a log event of all user activities to
increase the security of the system.

2.3.2. Functional Requirement

A Functional Requirement is a description of the service that the software must offer. It describes
a software system or its component. A function is nothing but inputs to the software system, its
behavior, and outputs. It can be a calculation, data manipulation, business process, user
interaction, or any other specific functionality which defines what function a system is likely to
perform.

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

 The system is capable of request complain to the concerned body online.

 The system is capable of registering new compliant and complaint information to the
database.
 The systems enable the users to take or get the registered complaint that they registered
orderly.

17
 Requirement Analysis 2020G.C

 Document the file which is placed on the system of the database to be accessed as
registers information.
 The system should allow the user to manage account i.e. it can change the username, and
change password.
 It organizes and makes searchable sites.
 The system validates data entry for correctness.
 The system generates a report.
 The system should allow the administrator to activate and deactivate users.
 The system should allow the administrator to Backup and retrieve the database.
 Concerned body (dep. head, HRM, etc…)
 Check users' message complaints (request).
 The concerned body can see and decide complaints to handle.
 Response and gives a solution to complaints of a privileged user.
 Prepare report.
 User
 Send, see and notify, decision, print, and review check information messages
made.
 User to change his user profiles’.
 Users can update complaints.

2.3.3. Nonfunctional Requirement

Non-Functional requirements describe user-visible aspects of the system that are not designated
to the functional behavior of the system. As the name suggests, non-functional requirements are
requirements that are not directly concerned with the specific functions delivered by the system.
It essentially specifies how the system should behave and works that it is a constraint upon the
system's behavior. Non–functional requirements place restrictions on the product being
developed, the development process, and specify external constraints that the product must meet.
The following are non-functional requirement associated with the system:-

[Link]. Performance
The system is error-free when accessing a huge amount of data. The system must support parallel
transactions involving different clients from different locations.

18
 Online Complaint Management System In University Of Gondar 2020G.C

 Response time:-The output should be generated within a maximum of 5 seconds

depends on internet connection speed and peak hours of internet usage.
 Capacity: - should be accessed by many users simultaneously.
 Resource utilization: - the application should utilize a minimum amount of CPU and
memory of the device.

[Link]. Scalability
Scalability typically involves adding resources to the system but should not require changes to
the deployment architecture.

[Link]. Availability
The system will be available to users for 7 days of the week for 24 hours unless there is power
loss. And a measure of how often a system’s resources and services are accessible to users often
expressed as the uptime of a system.

[Link]. Reliability
The new system under normal condition should keep service without any fault and it should not
access without authentication or it is secured than the manual system. The system should handle
invalid inputs and displays an error message to the users. Reliability is one feature of the system
that significantly validates user inputs.

[Link]. Maintainability
The user interface is user-friendly and interactive so it easy to fix while errors occur. The failure
of the system causes many problems, repairing the system must not be difficult since the user to
easily fix the problem.

[Link]. Security
The correct implementation of the system will be avoiding unauthorized persons to access.
The security service provided by the system will maintain the security of the system. Users will
have their username and encrypted password access the system.

[Link]. Environmental
The proposed system we are going to develop can be affected by the physical environment when
a natural disaster occurs. The new system will be affected by the internal physical environment
like attacked by viruses, worms and the like. So to overcome these problems the system store on
a different web server.

19
 Requirement Analysis 2020G.C

[Link]. Usability
Our system designed to have user-friendly interfaces and easy to navigate from one link to the
other, which enhances users’ efficiency. It is also designed in such a way that the user can easily
learn how to interact with the system.

 User operability-The system will offer simple navigation function so, can be operated by
any user.
 Language support-The proposed system support only English language

[Link]. Interoperability
The system can couple or facilitates the interface with other systems. That is the system shall be
interoperable with other system of the university.

20
 CHAPTER THREE

3. SYSTEM MODEL
The system modeling helps the analyst to understand the functionality of the system and models
are used to communicate with customers. Generally, a system model is the conceptual model that
describes and represents a system.

3.1. Scenario
This describes the particular sequence of activities within a use case.

Scenario 1:

Scenario name: Login

Participating actor: system administrator, grievance handling officer, department head, college
dean, administrative office manager, HRM, president, vice president, and user.

Flow of event

 the user initiates the system

 Users enter username and password.
 The system validates username and password.
 If the username and password are valid access shall be granted.
 If the username and password are invalid access is denied and the system displays an
error message.

Alternative case:

 If the Username and password are invalid, the system displays an error message and
allows the user to try again.

Scenario 2:

Scenario name: Register staff members

Participating actor: system admin.

21
 System Model 2020G.C

Flow of event
 The system admin login to the system.
 The system admin click to add staff member link and then the system displays the form.
 The system admin fills the required information of the administrative office managers.
 If administrative office manager information is valid, record into the database.
 If administrative office manager information is invalid, the system displays an error
message and allows the system admin to fill the form again.

Scenario 3

Scenario name: create account

Participating actor: users.

Flow of event

 The user initiates the system

 The user clicks to the create account button and fills the form.
 If the user’s information is valid and the user is a member of the university, record into
the database.
 If the user’s information is invalid or the user is not a member of the university, the
system displays an error message.

Scenario 4

Scenario name: Edit profile

Participating actor: system administrator, president, vice president, grievance handling officer,
department head, college dean, administrative office managers, HRM, and user.

Entry condition: The users' login to the system with their username and password

Event 1: Event: Change password

 The system displays the home page.

 The user clicks to the setting and chooses the change password link.
 The system displays the change password form.

22
 Online Complaint Management System In University Of Gondar 2020G.C

 The user enters the old, new, confirmation password and submits the form.
 If the form is filled correctly, the system display “password changed successfully”.
 If the form is not correctly filled, the system display “password not much”.

Event 2: Event: Change username

 The user clicks to the setting link and chooses the change username link.
 The system displays the username form.
 The user enters the new username and submits the form.
 If the form is filled correctly, the system display “username changed successfully”.
 If the form is not correctly filled, the system displays an “error message”.

Scenario 5

Scenario name: Manage account

Participating actor: system Admin

Entry condition: The system Admin logs in to the system by using his account.

Flow of event

 The system Admin click Account link and the system load account page.
 The system Admin click either deactivate or activate button
 The system warns the account to Block or to activate
 The system admin clicks to the ok button, then the system blocks the account from the
database and clicks on the ok button to activate the account.
Scenario 6
Scenario name: Send decision

Participating actor: president, vice president, handling grievance office, college dean, department
head, administrative office managers, HRM.

Entry condition: president, vice president, handling grievance office, college dean department
head, administrative office managers, HRM logs in to the system by using his/her account.

Flow event

23
 System Model 2020G.C

 The system displays the home page

 Those actors select the send menu;
 The system displays the form.
 The fill and click the send button.

Scenario 7

Scenario name: send feedback

Participating actor: users

Entry condition: The user login to the system by his/her account.

Flow of event

 The system displays the home

 Users click the comment link and the system load the text area to send the feedbacks of
users.
 Users fill the required information (comment).
 The users click the send button then the system sends the required notification
information to the database.

Scenario name: Generate report.

Participating actor: president, vice president, handling grievance office, college dean department
head, administrative office managers, HRM.

Entry condition: Users log in to the system by entering a user name and password.

Flow of event

 Users click on the generate report link.

 The system display report form that contains the following:-

 Date of report
 Reporter body
 The system generates the report to the login in the user.

24
 Online Complaint Management System In University Of Gondar 2020G.C

 The users fill the necessary information and click the generate button
 The system display report generates successfully.

Scenario 9

Scenario name: view feedback

Participating actor: president, vice president, handling grievance office, college dean department
head, administrative office managers, HRM.

Entry condition: president, vice president, handling grievance office, college dean department
head, administrative office managers, HRM login to the system by using his/her account.

Flow of event

 The system displays the home page.

 The user clicks on the view feedback link.
 The system displays the feedback.

3.1.1. Use Case Model

Use case Diagram Describe the functional behavior of the system as seen by the user. It is a
sequence of actions that provides measurable value to an actor another way to look at it is
that a use case describes a way to which a real-world interacts with the system. [4]
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.

3.1.2. Use Case Diagram

Actor of the system

 Officers such as

 Grievance handling officer

 Department head

25
 System Model 2020G.C

 HRM officer

 Collage dean

 Vice president

 President

 Administrative office managers such as

 Dormitory officers
 Clinic managers
 Cafeteria managers
 Library managers
 Student dean
 Discipline committee
 Users
 Students
 Employees

26
 Online Complaint Management System In University Of Gondar 2020G.C

Figure 3.1 Use case diagram for complaint

compl nt management system

3.1.3. Description of Use Case Model

Use case name Login

Use case ID UC1
Actors Officers and users
Description Users are authenticated and taken to their user interface

27
 System Model 2020G.C

Pre-conditions Users have username and password

Post-conditions User is authenticated and taken to his/her user interface
Basic course of action User action System response
Use case flow Step1: The user opens the Step2: The system displays the Main Home
main home page by page
writing the URL of the Step4: The system validates the account
website. and displays the user Require information.
Step3: The user inputs Step5: use case ends
user name and password
and submits System
Response.
An alternate course of A login name or password is invalid
action 4. The system displays invalid user name or password message
5. The user reenters the user name and password.
6. The use case continues from step 3 actors may Change password.
Table 3.1 Use case description for Login

Use case name Send complain

Use case ID Uc2

Actor User

Description The user can register to complain to handling grievance office

Precondition Users must be logged in to his/her account

Post condition The system can register complaint information

Basic course of action User action System response

28
 Online Complaint Management System In University Of Gondar 2020G.C

1. The user clicks on 2. The System displays the register

the send compliant link complaint information Page.
3. The user fills the 4. The System displays a success message
Necessary information 5. Use Case Ends.
and submits the forms

If the submitted form is not filled complete or invalid.

The system displays the “unsuccessful” message

The alternative course of The user fills the missing information and corrects invalid inputs
action The use case continues login page

Table 3.2 Use case description register complain.

Use case name Edit profile

Use case ID UC3
Actor Officers, Users
Description The listed actors may be updating their accounts.
Precondition They must be first registered into the database and login to the
system.
post condition updating their account in the system
User Action System response
Basic course of action
1. The actor invokes on the 2. The System displays the edit
edit profile page. profile page.
3. The actor fills the 4. The System displays a
necessary information and success message.
submits the forms [Link] Case Ends
Alternative course of action A1: If the submitted form is not filled complete or invalid.
A4. The system displays the “unsuccessful” message.
A2. The actor fills the missing information and corrects invalid

29
 System Model 2020G.C

inputs
A3. The use case continues from step 4
Table 3.3 Use case description for update account

Use case name View notice

Use case ID UC4
Actors Users, Department head, HRM, College dean, grievance handling
officer, Administrative office mangers, vice president
Description This Use case allows to View notice posted by a higher body.
Pre-condition Actors must be logged in to the system.
Post Condition View important Notice
Basic course of action User action System response
Step1: The actors invoke the Step2: The System displays the
view notice link. view notice Page.
Step3: The user views the Step4: Use Case Ends
information.
Table 3.4 Use case description for view notice

Use case name send decision

Use case ID UC5
Actors President, vice president, Handling grievance
office, college dean, department head, HRM,
administrative office managers.
Description Those actors submit their complain resolution to
their user and organ of the compliant after
completed.
Pre-condition Those actors login first must do their solution
Post condition Send their resolution to the owner of the
complaint.
Basic course of action Step1: Those actors open the home page.
Step2: click on send menu
Step3: Fill the information on the label.

30
 Online Complaint Management System In University Of Gondar 2020G.C

Step4: Click at the send button

Table 3.5 Use case description for send decision.

Use case name Send Feedback

Use case ID UC6
Actor Users
Description This user sends feedback to their boss
Precondition The users interact (open) with the home page of
the system.
Post condition users send important feedbacks to their officers
Basic course of action Step1: The listed users open the home page.
Step2: click on feedback menu
Step3: Fill the information on the form.
Step4: Click at the send button.
Alternative course of action If there is no feedback the system displays no
feedback is posted
Table 3.6 Use case description for send feedback.

Use case name View feedback

Use case ID UC7
Actor Officers

Description The officers view feedbacks sent by users.

Precondition The officers should log in to the system
Post conditions The officers successfully watch feedbacks
Basic course of action User action System response
Use case flow Step1: officers click Step2: The system makes
on the view display feedback
feedback link

Alternative course of action The officers may replay feedback

Table 3.7 Use case description for view feedback.

31
 System Model 2020G.C

Use case name View logged files.

Use case ID UC8
Actors System admin
Description This use case allows the system admin to view users who access the
system.
Pre-conditions 1. The user access the system.
2. System Admin must be logged in to the system.
Post-conditions It allows getting detail information about who accesses the system.
Basic course of action User action System response
Use case flow Step1: system admin Step 2: The system displays the home page.
logged in to the system. Step4: the system display all logged users
Step5: Use case end.
Step3: clicks the view
logged user.
Table 3.8 Use case description for logged files.

Use case name View decision

Use case ID UC9
Actors Users
Description Users see decisions send from their officers.
Pre-condition Users must be logged into the system by his/her account.
Post condition User sees the solution for their complaint.
Basic course of action User action System response
Step1: The user invokes the Step2: The System displays the
view decision link. view decision Page
Step3: The user views the Step4: Use Case Ends
decision.
Alternative case Users may transfer the complaints to the next higher body if they don’t
get the right solution.

Table 3.9 Use case description for view decision.

32
 Online Complaint Management System In University Of Gondar 2020G.C

Use case name Generate report

Use case ID UC10
Actors Officers
Description This Use case Generate report
Pre-condition Officers must be logged in to the system by his/her account.
Post condition Officers generate report

Basic course of action User action System response

Step1: The officers click on Step2: The system display
the generate report link. report form that contains the
Step3: the users fill the following:-
necessary information and
 Date of report
click the generate button.
 Reporter body
Step4: the system generates the
report to the login in the user.
Step5: the system displays a
success message.
Step6: Use case ends.
Alternative case 3.1: If the officer enters invalid information then the system will
generate an error message to fill again the information properly.
Table 3.10 Use case descriptions for Generate report.

Use case name Backup and Restore database

Use case ID UC11
Actors System Admin
Description This use case allows to backup and restores data to the system admin.
Pre-conditions System Admin should be login to the system.
Post-conditions Backup and restore the database.
Basic course of action User action System response
Use case flow Step1: The admin click Step 2: The system displays Backup and
manage database the link restores links.

33
 System Model 2020G.C

Step3: The system admin Step4: The systems backup the database
wants to back and click and display a success message.
on the backup link.
Step5: Use case end.
Alternative case 3.1 The system admin wants to restore the database click on the restore
database.
Table 3.11 Use case descriptions for Backup and restore the database

Use case name Add staff members

Use case ID UC12
Actor System admin
Description The admin creates user name and password for users
Precondition Admin first log in to the system
Post condition Successfully create account
Basic course action User action System response
Step1: login in the system Step2: Display admin page
Step3: Admin clicks on step4: Display creates new
add user link account form.
step5: system admin fill step7: Check the filled
the required information. information on the form.
step6: system admin click Step8: If the filled information is
on the create button. correct the system saves on the
system database.
Alternative course of action A: system display ‘’account is not created message’’.
A1: repeat from step4.
Table 3.12 Use case descriptions to add staff members.

Use case name View report

UC_ID UC13
Actor Officers
Use case Description This use case is to allow higher officers to
view the report, which is generated by the

34
 Online Complaint Management System In University Of Gondar 2020G.C

lower officers.
Precondition: 3. The lower bodies should generate the
report.
4. The higher officers must be logged in to
their account.
Post condition The higher officers view a report
Actor action System response
Step1: the officers Step 4: the system displays the selected report
invoke the view report automatically.
link. Step 5: the view process end.
Step 3: The officers
select a report type
menu item.
Use Case flow
Alternative course of action 3.1: the system does not display the report.
3.2: the view process ends.

Table 3.13 Use case description for view report.

Use case name Modify complain

Use case ID UC14
Actor End-user

Description The end-user updates their complaint.

Precondition The users should be logged into the system
Post conditions The users successfully update their complaints.
Basic course of action User action System response
Use case flow Step1: users click on Step2: The system
the update my displays the update
complaint link. complaint form.
Step3: fill the form Step4: The system checks
and click the update the filled information.

35
 System Model 2020G.C

button. Step5: If the filled

information is correct the
system saves on the
system database. And
display a success message.

Alternative course of action 3.1: system display ‘error message ’.

3.2: repeat from step 3.

Table 3.14 Use case descriptions for Update complaint.

Use case name Create a new user account

Use case ID UC15
Actor users
The new End-user wants to complain and
Use case Description register first.
1. Users must interact with the system.
Precondition: 2. Users must be members of the university to
register.
Post condition Users create account
Actor action System response
Step1: users invoke the step2: the system creates displays form.
create account link on the Step5: The system validates new user detail.
home page. and check whether the user is a member of the
Step3: users fill id university or not.
username, and password, Step6: If the user is a member of the university
Use Case flow role. the system saves user detail to the complaint
Step 4: user click create
database.
button
Step7: Then the system displays a success
message.
Step8: end of use case

36
 Online Complaint Management System In University Of Gondar 2020G.C

3.1: If the user does not enter the required

Alternative course of action information correctly, the system displays a
message “account not created”.
5.1: if not correct the system doesn’t save the
entered information to the database.
6.1: the system displays a fill again message
and allows him/her to fill again.
6.2: use case ends

Table 3.15 Use case description for create a new account.

Use case name View complaint person information.

Use case ID UC16
Actor Officers.
Description Officers view complaint persons’ information
Precondition The officer must be logged into the system by his/her account
Post condition Allows getting detail information on registered complaints.
Basic course action User action System response
Step1: officer login into Step2: Display the home page of
the system the respective officer.
Step3: The officer click s step4: the system directed to the
on the view complaint view person.
information link step7: The system displays detail
step5: The officers select information based on criteria.
search criteria.
step6: The user presses the
submit button.
Table 3.16 Use case descriptions for view complaints information.

37
 System Model 2020G.C

Use case name post notice

Use case ID UC17

Actor Officers.
Use case Description In this Use case the officers can post any
information,
Precondition: the officers should have to enter a valid user
name and password to log in

Post condition If officers entered valid account type, user name

and password then he/she can post the
information.
Actor action System response
Step1: user login into the Step3: the system displays the notice form
system. Step5: The system checks the filled form.
Step 2: the officer wants to Step6: the system stored the posted information
post any notice or any on the database
news and clicks on the post Step7: the system displays a success message.
Use Case flow
notice link.
Step4: The officer fills the
needed information.
Step5: Then click the post
button
Step8: Use case ends.
Alternative course of action 5.1: The system displays an error message.
5.2: The post-process back to fill the form

Table 3.17 Use case description for post notices.

Use case name Logout

Use case ID UC18

38
 Online Complaint Management System In University Of Gondar 2020G.C

Actors All the listed actors

Description This use case allows to logout and back to the login page
Pre-conditions All actors should be login to the system and want to log out.
Post-conditions All actors logged out of their privileges and go back to the home page.
Basic course of action User action System response
Use case flow Step1: The user clicks Step 2: The system return to login page
the logout link
Step3: use case end.
Table 3.18 Use case description for log out.

3.1.4. Activity diagram

An activity diagram describes the flow of control in the system. So it consists of activities and
links. The flow can be sequential, concurrent or branched. Activity diagrams are used to
visualize the flow of control in a system. This is prepared to have an idea of how the system will
work when executed. The activity diagram is a flowchart to represent the flow from one activity
to another activity. The activity can be described as an operation of the system. The activity can
be described as an operation of the system. So the purpose can be described as

 Draw the activity flow of a system

 Describe the sequence from one activity to another
 Describe the parallel, the branched and the concurrent flow of the system.

39
 System Model 2020G.C

Figure 3.2 Activity diagram for login

Figure 3.3 Activity diagram for add user.

40
Online Complaint Management System In University Of Gondar 2020G.C

Figure 3.4 Activity diagram for send decision.

41
 System Model 2020G.C

Figure 3.5 Activity diagram for view notice.

42
Online Complaint Management System In University Of Gondar 2020G.C

Figure 3.6 Activity diagram for the user or compliant person registration.

43
 System Model 2020G.C

Figure 3.7 Activity diagram for log out.

3.1.5. Object Model

We draw a class diagram depicting the inheritance relationships and associations that exist
between the entity objects that we identified earlier.
3.1.6. Data dictionary

44
 Online Complaint Management System In University Of Gondar 2020G.C

Entity Object Attribute Description

Admin First_ name Describes the first name of system admin
Middle_name Describes middle name of system admin
Last_name Describes the last name of system admin
Admin_Id Describes id of system admin
Email Describes email of system admin
User name Describes username of system admin
Password Describes password of system admin
Address Describes the address of system admin
User First_name Describes the first name of the user
Middle_name Describes the middle name of the user
Last_name Describes the last name of the user
user_Id Describes id of the user
campus Describe the campus of the user
Sex Describes the sex of the user
Age Describes age of the user
Email Describes email account of the user
Department/role Describes the department or role of the user
Block_number Describes the block number the user
problem Describe the problem of the user
Phone Describe phone number of user
Feedback Feedback_id Describes the id of the feedback

Detail Describes the detail of the feedback

User_Id Describes the id of the sender

Date Describes the written date of feedback

Submitted to Describes the receiver of the feedback

45
 System Model 2020G.C

Entity object Attribute Description

Notice id Describes Id number of notice

Title Describes the short idea of notice

content Describes the message posted in the

notice
Date
Describes dates when notice posted
Report Rep_id Describes the id of the report

Reporter Describes the reported body.

Rep_date Describes the reporting date

Decision Dec_id Describes the id of the decision

Content Describes the content of the decision

Decided_body Describes who give the decision

date Describes the deciding date

Table 3.19 Data dictionary

3.1.7. Class model

This design level introduces changes to the analysis class model based on implementation
technologies. It focuses on the solution domain instead of the problem domain.

 The class diagram is the main building block in our project modeling.
 It is used both for general conceptual modeling of the systematic of the
application and for detailed modeling translating the models into programming
code.

Classes are represented by rectangles with three sections.

These are:-

 The top section is the name of the class.

 The middle section contains the attributes which store information about an item

46
 Online Complaint Management System In University Of Gondar 2020G.C

 The bottom section contains the methods/operation that shows

show what is done on the
object or class.

The class diagram

iagram below shows the class of our system, their
their interrelationship (including
inheritance and association) and the
th operations and attributes of each class.

Figure 3.8
8 Class diagram
3.1.8. Dynamic Modeling

We have identified a number of entity,

e boundary and control objects, along the w
way we have also
identified some of their attributess and associations, we represent this object seque
uence diagrams.

[Link]. Sequence diagram

Sequence diagrams describe interactions among classes in terms of an exchange of messages
over time. They are also called event diagrams. A sequence diagram is a good way to visualize

47
 System Model 2020G.C

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.

UML sequence diagrams model the flow of logic within our system in a visual manner, enabling
us both to document and validate our logic and are commonly used for both analysis and design
purposes.

Figure 3.9 Sequence diagram for login

48
Online Complaint Management System In University Of Gondar 2020G.C

Figure 3.10 Sequence diagram for creates account and update account..

49
 System Model 2020G.C

Figure 3.11 Sequence diagram for handling grievance office view compliant information

50
Online Complaint Management System In University Of Gondar 2020G.C

Figure 3.12 Sequence diagram for registering a compliant user.

51
 System Model 2020G.C

Figure 3.13 Sequence diagram for send solution to the compliant person.

3.1.9. User Interface

52
Online Complaint Management System In University Of Gondar 2020G.C

figure 3.14 Home page user interface.

Figure 3.15 Login user interface.

53
 CHAPTER FOUR

4. SYSTEM DESIGN

4.1. Introduction
System design is the transformation of the analysis model into the system design model. It
focuses on the solution domain rather than on the problem domain. The deliverable of this phase
is a system design model that serves as a blueprint for the implementation of the system.

The purpose of designing is to show the direction of how the system is built and to obtain clear
and enough information needed to drive the actual implementation of the system. It is based on
the understanding of the model the software built on. The objectives of design are to model the
system with high quality. Implementing a high-quality system depend on the nature of the design
created by the designer. If one wants to change to the system after it has been put into operation
depends on the quality of the system design. So if the system is designed clearly, it will be easy
to make changes to it.

4.1.1. Design goals

Design goals describe the qualities of the system that developers should optimize. In the design
stage, designing the project is according to customer satisfaction or user satisfaction.
Such goals are normally derived from the non-functional requirements of the system.

Design goals describe the qualities of the system should consider.

 Easy to implement: the design of the system is easy to change it into implementation or
easy to code for the project group. It is to design and implement the database of the
system.
 Response Time: the online complaint management system will deliver a quick response
after a single click.
 Usability: The web application will have consistent patterns in page content, structure, and
navigation. Although images are important contents in websites, the use of images will be
reduced to decrease the distraction of the users. This system also designed to work with the

54
 Online Complaint Management System In University Of Gondar 2020G.C

English language. It also provides user manuals and helps content on how to use the web-
based application.
 Reliability: The information provided by the system to the users will be fetched from the
database. To make the system reliable to the students as well as to the employee making
sure information stored on the database is correct is the main task. To make sure this is
achieved form validation will be applied to every input data against pattern errors, invalid
data, and wrong data.
 Availability: the system is available when it needed and when the internet connection not
interrupted.
 Security: the proposed system should be secured, i.e., not allow other users or
unauthorized users to access data that has no right to access it.
 Modifiability: the proposed system should be modifiable for further modification and
enhancement of the application

4.2. Current software architecture

The existing system is performed manually. So, there is no any type of software architecture.

4.3. Proposed software architecture

A system architecture is a conceptual model that defines the structure, behavior, and more view
of a system. An architecture description is a formal description and representation of a system,
organized in a way that supports reasoning about the structures and behaviors of the system.

The system architecture can comprise system components, the externally visible properties of
those components like users, web browser, servers and database and the relationships (e.g. the
behavior) between them. It can provide a plan from which systems developed and work together
to implement the overall system. Such an architecture is one of the most commonly used types of
architecture for web-based applications as it provides greater application scalability, high
flexibility, high efficiency and better reusability of components.

55
 System Design 2020G.C

Figure 4.1 System architecture for the proposed system

4.3.1. Subsystem decomposition

Any system can be decomposed into different subsystem based on the functional services.
System decomposition is undertaken to reduce the complexity of the system and gaining
insight into the identity of the constituent components. The purpose of this activity is to divide
the system into self-contained components that can be managed individually.
The proposed web-based compliant management system is decomposed into a smaller sub-
system as shown in the following figure. The major sub-system identified includes:-
User management subsystem, DBMS subsystem, Notification subsystem, feedback subsystem,
account management subsystem, compliance management subsystem, and report generation
subsystem.

56
 Online Complaint Management System In University Of Gondar 2020G.C

Figure 4.2 Subsystem decomposition.

4.3.2. Hardware/ software mapping

This section describes the Hardware/Software mapping of the proposed system. To describe this,
we use the UML deployment diagram.
OCMS is inherently a distributed system. We distinguish between three types of nodes: the user
Machine (computer) to provide a user interface, the server machine to run the application logic
and more generally to give a response for the requests made by OCMS client running on the user
Machine, and the Storage Machine for persistent data storage.

57
 System Design 2020G.C

Figure 4.3 Deployment diagram.

4.3.3. Persistent data modeling

Persistence is “the continuance of an effect after its cause is removed”. A persistent object is an
instance Persistent data management deals with how the persistent data are stored and managed.
Information related to complaints and users are persistent data and stored in a database
management system.

To store data persistently in a database those class objects identified in the class diagram of
OCMS is mapped into tables and the attributes into fields to the respective tables. The Tables of
the system with their respective fields and the relationships that exist between the tables are
expressed in this portion of the project.

58
 Online Complaint Management System In University Of Gondar 2020G.C

Figure 4.4
4. Persistent data modeling.

4.3.4. Access control and security

System access control and security is the main issue of the project. Therefore system identif
identifies
someone who is, what he/she wants to access, check whether the somebody is authorized or not
and
nd granting permission or deny. But in our case different actors have access to different
functions and data, therefore
erefore these privileges prevent unauthorized users from accessing data that
they don’t have granted to access. Authentication: takes place by letting users insert usernames
and passwords in the display login form.

59
 System Design 2020G.C

System Presid Vice Grievance Collage Department HRM Administrati user

Actor Admin ent president Handling dean Head ve
officer Office
managers
activities
Send 
A complaint

      
Generate

report
Manage 
user

Register 
complaint

Send       

decision
Manage 
account
Post       
notice
Add user 

Table 4.1 Access control.

4.3.5. Detailed class diagram

The class diagram depicts the system’s object structure. They show object classes that the system
is composed of as well as the relationships between those object classes. UML class diagram
shows the classes of the system, their inter-relationships, and the operations and attributes of the
classes.

60
 Online Complaint Management System In University Of Gondar 2020G.C

Figure 4.5 Detailed class diagrams.

4.3.6. Package Diagram

Package diagram a kind of structural diagram, show the arrangement and organization of
model elements in middle to large scale project. The package diagram can show both
structure and dependencies between subsystems.

61
 System Design 2020G.C

Figure 4.6 Package diagram

4.3.7. Deployment

UML deployment diagram shows the physical view of the system, taking software into the real
world by showing how software gets assigned to hardware and how communicates. The
deployment diagram shows how the software components, processes, and objects are deployed
into the physical architecture of the system. It shows the configuration of the hardware units (e.g.
Computers, communication devices, etc.) and how the software components are distributed
across the units.

62
 Online Complaint Management System In University Of Gondar 2020G.C

Figure 4.7 Deployment diagram.

The description of the architecture of the system is described as following

Clients are responsible for:-

 Provide user interface to the user enabling to get services

 Receiving inputs from the user
 Checking a range of performance
 Initiating database transactions once all necessary data are collected.
The server is responsible for:-
 Transaction performance
 Guaranteeing the integrity of data.
 Putting backup of the database.

63
 System Design 2020G.C

REFERENCES
[1]. Ministry of Communication and Information Technology, “Ethiopian Electronic Services”,

2012, retrieved from [Link] (last accessed on March

02, 2020).

[2]. ([Link]
andimplementation-of-complaint-management-system-for-university-student/project-topics).

[3]. Object-Oriented Software Engineering: A Use Case Driven Approach, I. Jacobson, et al,
Addison-Wesley 1992.

[4]. [Booch99] Booch, G. et al., the Unified Modeling Language User Guide, Chapters 19, 20,
21, 24. Addison-Wesley.

64