NAME: ABDI OSMAN EDIN

REGNO: DICT/2021/47115

FACULITY OF BUSINESS AND TECHNOLOGY

COURSE: DIPLOMA OF ICT

PROJECT TITTLE: ONLINE COMPLAINT MANAGEMENT SYSTEM.

Table of Contents
DECLARATION..........................................................................................................................................4
ABSTRACT................................................................................................................................................5
CHAPTER ONE..........................................................................................................................................7
1.0 Background of the Study...................................................................................................................7
1.1 Aim and Objectives of the Study........................................................................................................8
1.2 The specific objectives.......................................................................................................................8
1.3 Statement of the Problem.................................................................................................................8
1.4 Significant of Study............................................................................................................................9
1.5 Scope of the Study.............................................................................................................................9
1.6 Limitation of study.............................................................................................................................9
1.7 Operational Definition of Terms......................................................................................................10
CHAPTER TWO.......................................................................................................................................12
2.0 LITERATURE REVIEW........................................................................................................................12
2.1 Introduction.....................................................................................................................................12
2.2 FRONTLINE RESOLUTION.................................................................................................................14
2.3 INVESTIGATION................................................................................................................................15
2.4 RECORDING THE COMPLAINT..........................................................................................................16
2.5 RESPONSE and REDRESS..................................................................................................................16
2.6 ANONYMOUS COMPLAINTS AND MANAGING UNACCEPTABLE BEHAVIOUR..................................17
2.7.1 DEALING WITH YOUR COMPLAINT...............................................................................................18
2.7.2 INVESTIGATION.............................................................................................................................18
2.7.2 OUTCOME.....................................................................................................................................19
CHAPTER THREE.....................................................................................................................................20
3.0 SYSTEM METHODOLOGYAND DEVELOPMENT.................................................................................20
3.1 METHODOLOGY...............................................................................................................................20
3.2 DATA COLLECTION...........................................................................................................................21
3.2.1 Primary source of data..................................................................................................................21
3.2.2 Secondary sources........................................................................................................................22
3.3 SYSTEM DESIGN...............................................................................................................................23
3.3.1 Flow chart..............................................................................................................................23
3.3.2 DATABASE..............................................................................................................................24
3.3.2.1 Data flow diagram.....................................................................................................................24
3.3.2.2 Entity relationship diagram....................................................................................................25
3.3.3 SYSTEM DEVELOPMENT.........................................................................................................25
3.3.3.1 Tools used..................................................................................................................................25
3.3.2.2 Testing methodology.............................................................................................................25
3.3.2.4 Implementation.....................................................................................................................26
3.3.2.5 Maintenance..........................................................................................................................27
CHAPTER FOUR......................................................................................................................................27
4.0 SYSTEM DESIGN...............................................................................................................................27
4.1 Flow chart design.............................................................................................................................27
4.2 Database logical design...................................................................................................................29
4.3 Database physical design.................................................................................................................30
4.4 The Entity Relationship Diagram (ERD)............................................................................................31
4.5 Data Flow Diagram (DFD).................................................................................................................34
4.5.1 Level 0 DFD diagram.....................................................................................................................34
4.5.2 Level 1 DFD diagram.....................................................................................................................35
4.5.3 Level 2 DFD diagram.....................................................................................................................36
CHAPTER FIVE........................................................................................................................................38
5.0 PROPOSED SYSTEM..........................................................................................................................38
5.1 Main page........................................................................................................................................38
5.2 Registration page.............................................................................................................................39
5.3 Student login page...........................................................................................................................40
5.4 Admin login page.............................................................................................................................41
5.5 Admin main page.............................................................................................................................42
5.6 Student profile.................................................................................................................................43
5.7 User management by admin............................................................................................................44
References.............................................................................................................................................45

DECLARATION
I declare that this is my original work and has not been presented by anyone to any school.

ABDI OSMAN

SIGNATURE……………………. DATE………………….

This research project has been submitted for examinations with my approval as the university
supervisor.

MADAM LUCY MWAURA.

SIGNATURE…………………. DATE …………………

ABSTRACT

Complaint Management System provides an online way of solving the problems faced by the
student by saving time and eradicate corruption. The objective of the complaints management
system is to make complaints easier to coordinate, monitor, track and resolve, and to provide
organization with an effective tool to identify and target problem areas, monitor complaints
handling performance and make business improvements. Umma Complaint Management is a
management technique for assessing, analyzing and responding to student complaints.
Complaints management software is used to record resolve and respond to student complaints,
requests as well as facilitate any other feedback.
 CHAPTER ONE

ONLINE STUDENT COMPLAINT MANAGEMENT SYSTEM

1.0 Background of the Study

A complaint is an expression of dissatisfaction by one or more students about the institutions’

action, inaction or standards of service, provided by or on behalf of the institution, on or off the
campus, which the student(s) have not been able to resolve through informal processes. The
following are not normally dealt with as complaints under this procedure:

A complaint about an admissions decision, A concern about a decision made by an academic

body regarding student progression, academic assessment and awards, Dissatisfaction about the
outcome of an academic misconduct process, A concern about bullying or harassment by a
student and A complaint about the role of representatives of the Students’ Union;

Where a complaint involves multiple issues, which do not fall neatly into the category of
complaint (e.g. because it also covers issues that fall within the remit of academic appeals or
other procedures), with written agreement of all parties, the matters may be considered together.
Depending on the individual circumstances of each incident, the institution reserves the right to
either suspend one procedure pending the outcome of the other, or decide not to pursue a
procedure in favor of the other. Students may make complaints about any unit, function or
service provided by the Institution or on behalf of the institution. The definition of a complaint is
necessarily broad and therefore the list provided is intended to guide users, and is not intended to
be exhaustive. A complaint may relate to the following issues:

The quality or standard of any service provided or failure to provide a service. The quality of
facilities or learning resources. The failure of the institution to follow an appropriate
administrative process. Unfair treatment or inappropriate behavior by a student or a staff member
and an alleged action or inaction by the institution or a member of its staff. In view of the
importance of filing complains, since they are almost on a regular basis submitted, there is need
for an online system to aid easy submission of complaints for timely decision-making. This has
given rise to the development of an online student’s complaint management system. 
1.1 Aim and Objectives of the Study

To develop an online complaints management system that will increase throughput, employ high
level of satisfaction on students and a user-friendly system to students to access the services
easily automated without a lot of effort and easy methods of reporting complaints by students to
the institution. This will ensure a profitable and a competitive advantage tool to most of
educational institutions.

1.2 The specific objectives

1. Reporting of complaints that they feel that affect them on their day-to-day activities and
welfare of the institution and all the complaints and challenges that they face while in the
institution.
2. Provide platform where the other students can comment on the complaints raised to verify
that many of the students have same interest to enable management take a quick action on
the complaint.
3. Enable management to access to details on complaints and their effects to be addressed by
management easily especially the welfare department.

1.3 Statement of the Problem

Design and implementation of online complaint management system is a web-based application

that will solve the problems facing student in the university environment. The basic problems
facing complaint monitoring are:

Lack of fitting security and upkeep of the complaint record in the system that makes an avenue
for disappointment and Control of information.

Lack of legitimate precise, concise data about the student implicit rules and character.

Poor performance of the manual system may lead into the missing or exploitative of the
complaint by the staff or any member of the management,
This is a circumstance where there is no avenue made for survey of the complaint. This obstructs
satisfactory upkeep of the system.

There is no system or database set up to screen transfer of complaint submitted on paper or as

verbal representation

1.4 Significant of Study

The significance of this study is to serve better than the existing system, which is manual and
therefore difficult in terms of monitoring the complaint in the University, improve 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.
The new system will save time, reduce improper handling of complaint system and improve the
relationship between student, lecturer, and management. The system will be easy to use and
navigate as a student can log in their complaint anytime; staff and management also can equally
response to student complaint in an easier way.

1.5 Scope of the Study

This study covers only the procedure for managing complaints in the Student Affair Division of
Umma University. The system will be web-based. Designed to help student login their complaint
and request for management help concerning any complaints.

1.6 Limitation of study

Due to the scope of this project work as mention above, this project work is limited to complaint
management system. This application cannot process the penalties for anybody found being
grieved or the punishment for any staff or student found being at fault of any complaints. Other
limitations include; the application cannot send a notification to SMS but only the recipient email
address and not mobile phone ii. It does not provide the means of live communication between
the complaint and the respond. The system cannot work with other web application. This means
it is not a web service oriented system.

1.7 Operational Definition of Terms

Lecturer: A person who gives lectures, especially as an occupation at a university or college of

higher education.

College: A school or a division of a university that provides tertiary education. It deals with
specific courses and disciplines for various students.

Academic: Designed for students who intend to study at a college after high school, or attending
a school with such courses (Microsoft Encarta 2009)
Registration: The process of enrolling at a college or university, choosing courses, and paying
fees at the beginning of an academic term (Microsoft Encarta 2009)

Staff: A particular group of employees within a company, institution, or organization (Microsoft

Encarta 2009)

Complaint: The act of expressing discontent or unhappiness about a situation (Microsoft

Encarta2009)

Appeal: Request by a complainant to have a matter heard and/or reconsidered after receiving an
unfavorable decision (Microsoft Encarta 2009)

Procedure: An established or correct method of doing something (Microsoft Encarta 2009)

Tedious: Boring because of being long, monotonous, or repetitive (Microsoft Encarta 2009)

Monitoring: A school student who helps a teacher by being given a responsibility or special duty
(Microsoft Encarta 2009)

Complaint: A problem or issue which has not been resolved through discussion and progresses to
a written complaint (Microsoft Encarta 2009)

Discrimination: Unfair treatment of one person or group, usually because of prejudice about
race, ethnicity, age, religion, or gender (Microsoft Encarta 2009)
CHAPTER TWO

2.0 LITERATURE REVIEW

2.1 Introduction

“A complaint is an expression of dissatisfaction by one or more members of the public about an

organization’s action or lack of action, or about the standard of service provided by or on behalf
of the organization”. Every complaint requires a response. One of the main characteristics of a
good complaints system is that it should be easy to find out how to make a complaint and simple
and convenient to then do so. The service provider should remember that the person making the
complaint may find it quite distressing to do so and may have difficulties putting their complaint
in writing.

According to Ali Alkhider Taha,2012 Online students’ complaint management system provides

an online way of solving the complaints submitted by students. The objective of the complaints
management system is to make complaints easier to coordinate, monitor, track and resolve, and
to provide an institution with an effective tool to identify and target problem areas, monitor
complaints handling performance and make-needed improvements. Online students Complaint
Management is a management technique for assessing, analyzing and responding to students’
complaints. Complaints management software enables to record resolve and respond to customer
complaints, requests as well as facilitate any other feedback. An online student’s complaint
management system enables institutions to address complaints and resolve disputes quickly.
(Marcus, 2000).

Complaint systems in higher institutions have undergone several innovations especially with the
advent of internet and online-based systems (Kohavi 1997). Notably in many institutions in
developed nations, conflict management channels and systems have evolved from a major focus
on labor-management relations to a much wider purview that includes unionized workers and
also managers, non-union employees, professional staff, students, trainees, vendors, donors,
customers.  According to (Marcus, 2000), there is also a major need to collect, review and
understand the nature of conflict management and complaint systems around the world. Studies
and citations facilitates on how complaint systems work for women as well as men. Research is
required as to how systems work for many different national groups, for people of different
socio-economic classes, and different ages, and different religions, and especially for different
relationships.

Academic growth can be of various concerns in an academic environment to promote social and
functioning educational system. For an effective educational system to take place there are some
issues in an academic environment that addressed, take for instance issue of complaints
management system in the university. This issue had created many problems for an academic
growth in the various aspects of the educational system. Ali Alkhider Taha (2011).

To support this approach, this project identifies a range of options to use in order to manage and
resolve Academic complaints. This includes, where the opportunity presents itself, the need for
an administrator to make every effort to resolve potential or actual academic complaints as
informally as possible in the first instance. Handling complaints often involve first, to listen and
understand, empathize, offer a solution, execute the solution and then follow up.

Dogan and Wilkinson (2016) defined complaint as any expression of dissatisfaction about
services(s) or about any professional conduct. It prompts more prominent clarity and
consistency of executive activities to determine the protests. Design and equitable complaint
handling system, which is easily accessible and offered to complainants (students) at no charge.
This project defines the policy and steps for handling and resolving complaints as well as to
appeal for an un-favored situation and for this process to take place there must be automation of
the system that will handle the complaints process and appeal method of registration.

Automation can be defined as the aspects involved in using a computer system for the tasks or
process such as circulation, implementation etc. In relation to the above preposition by Marcus, it
is possible for the design and implementation of an online complaint management system to
yield substantial benefits for the users (Marcus, 2000).

Complaints should be accepted in a number of different ways including in person, over the phone
and in writing. The service provider should accept complaints brought by third parties as long as
they obtain appropriate consent from the service user, where possible. The service provider
should explain and signpost the role of any advocacy agencies operating within the sector and
their role in providing assistance to service users. The service provider should ensure that all of
their service users have access to simple and clear information about how to make a complaint.
(Marcus, 2000) This includes taking account of service users with particular requirements, such
as those with intellectual disabilities, who are visually impaired, or with language difficulties and
others. Information about the complaints procedure and policy should be easily accessible at all
times and not just when a service user wishes to complain. It should be available at all public
reception areas and any “common areas” which service users may use as well as being made
widely available to all staff. (Sebastiani 2002)

According to Marcus, (2000) the complaints policy should be clearly available through an easily
accessed area of the service provider’s website (where there is one) – ideally via a link on the
home page. The website and other information material should include the name of the
Complaints Officer and his/her contact details. Service users should be assured that making a
complaint would not adversely affect their ongoing interaction with the service provider.
Information about improvements made following previous complaints should be readily
available.

2.2 FRONTLINE RESOLUTION

The service provider should seek to resolve service users’ complaints as early as possible and
ideally, at the first point of contact. The stages in the complaint handling process should be kept
to a minimum. The service provider should establish clear guidelines as to what type of issues
are suitable for frontline resolution. Staff members who are the subject of a complaint should not
handle or respond to the complaint (Sebastiani 2002). Frontline resolution should be completed
within 5 working days. Complaints resolved at this stage should be recorded by listing details of
the complaint, the outcome and any action taken. Staff should advise service users that they
could progress their complaint on to the investigation stage if they are not satisfied with the
outcome following attempts at frontline resolution. (Abd Allah 2010).

2.3 INVESTIGATION

Every complaint is different so the approach to investigating and resolving it will differ
depending on the nature of the complaint and the issues raised. Investigations should be
conducted in a way that is proportionate to the nature and degree of seriousness of the complaint.
However, all complaints should be thoroughly and objectively investigated. Senior management
should establish clear guidelines to help identify the types of issues appropriate to the
investigation stage. These may include where:

Frontline resolution was attempted but the service user remains dissatisfied. (Wilkinson 2016)
The service user refuses to engage with the frontline resolution process. The issues raised are
complex and will require detailed investigation. The complaint relates to issues that have been
identified as serious or high risk as well as a standard template for documenting a complaint
should be developed outlining the nature of the complaint, the preferred method of
communication and the desired outcomes. All of these should be established and agreed by the
service provider and service user at the outset. (Dogan and Wilkinson 2012).

Service users should have a single point of contact for their complaint (usually the Complaints
Officer). This person is responsible for establishing what information is required and for
gathering that information. They should have a clear remit and investigate effectively and be
empowered to resolve complaints or have access to the person who has the authority to do so.
Service users should be provided with the name and contact details of the person dealing with
their complaint as soon as possible. Staff members who are the subject of the complaint should
not investigate the complaint. In some cases, serious complaints may need to be investigated by
someone independent of the service provider. (J. Ranilla, And R. Mones, 2000).
Complaints should be acknowledged promptly and within 5 working days from date of receipt. A
full response to the complaint should issue within 30 working days of receipt. If, in exceptional
circumstances, the response will be delayed, the service user should be told of this within 30
working days of receipt and should be given a revised timescale for bringing the investigation to
a conclusion as well as an explanation for the delay. An update should be provided every 20
working days thereafter. (R. Mones, 2003).

2.4 RECORDING THE COMPLAINT

A complaint can be an opportunity to increase understanding of the service user’s perspective. It

can also help to improve the service offered. A “fit for purpose” system for capturing and
recording complaint data is therefore a vital element in any effective complaint handling system.
The service provider should maintain a complaint file containing complete and accurate records
of all contact regarding a complaint and ensure that this information is easily accessible. (Lewis
2002) A complaint file should contain information such as the service user’s details, the issues
raised and the action taken. It should also contain, in chronological order, any correspondence
(including emails) about the complaint, notes of meetings and telephone calls (both external and
internal).

The service provider should ensure that the complaint file is available for review by the
Ombudsman, if required. The service provider should put in place a system to record all relevant
data about a complaint after closing it. This should include the category or nature of the
complaint, action taken to resolve the complaint. (J. Ranilla, And R. Mones, 2000) The outcome
of the complaint indicates whether the service user was satisfied with the outcome. Senior
management should be provided with regular reports on the number and type of complaints
received, their outcomes and any actions taken as a result. Particular attention should be paid to
the narrative within complaints data as this can be used to improve an organisation’s service and
effectiveness. Where systemic improvements are put in place arising from complaints all staff
should be duly notified and a record of any changes should be available to all staff on an on-
going basis. (Ranilla 1998).
2.5 RESPONSE and REDRESS

All issues raised in the complaint must be comprehensively responded to. All points raised by
the service user and agreed at the start of the investigation should therefore be properly
considered and fully addressed in the response. Any areas of disagreement or varying accounts
are acknowledged without dismissing what the service user has said. (Lewis 2000) The service
provider’s decision formally communicated to the complainant using the preferred means of
communication and confirmed in writing. Where an investigation identifies a service failure and
the service provider proposes to take action to resolve the issue, the response should include
details of what will be done and when. In cases where a complaint is upheld, the appropriate
Manager should ensure that an action plan is drafted setting out how the recommendations will
be implemented and who will be responsible for implementing them. (Kohavi 2000)

The response should tell the service user about their right to complain to the Ombudsman (or the
Ombudsman for Children, where appropriate) if they are dissatisfied with the outcome of their
complaint. Contact details for the Ombudsman (or the Ombudsman for Children, where
appropriate) should also be provided. The standard form of words provided by the Ombudsman
should be used. A good complaints process should offer a range of timely and appropriate
remedies to those service users who have a justified complaint. The service provider should be
willing and able to offer suitable redress, which meets the needs of the particular complainant.
The service provider should have a clear policy on redress; an appropriate redress could include
a sincere and meaningful apology, an explanation, correcting the error and financial redress (J.
Ranilla, And R. Mones,2000).

According to Sebastiani 2002, Where service failings have been identified, the service provider
should attempt, if possible, to put the service user back in the position they were in before the
error occurred. If this is not possible, then other forms of redress need to be considered such as
providing an explanation or an apology. For more information on redress, including advice on
providing an apology, see “The Ombudsman’s Guide to the Provision of Redress”.
 2.6 ANONYMOUS COMPLAINTS AND MANAGING UNACCEPTABLE
BEHAVIOUR

An organization that values all complaints should also treat anonymous complaints seriously and
take action to consider them, wherever this is appropriate. Anonymous complaints should be
considered where there is sufficient information provided to enable the service provider to
investigate the case. Where there is not sufficient information provided, the service provider may
decide to take no further action but should record the complaint in any event in case it becomes
clear that action is required later (Y. Yang and J.O. Pedersen 1997). A service user’s behavior
should not be regarded as unacceptable just because they are forceful or determined. In addition,
service users who display difficult behaviour may still have a legitimate complaint and the
service provider must therefore treat all complaints seriously. Very few people complain to
cause trouble. (Kohavi 2000)

If a service user’s behaviour causes a problem, they should be clearly told what the unacceptable
behaviour is and what problem it is causing. The service provider can take steps to protect
members of staff in circumstances where the behaviour of service users is unacceptable. This
may include informing the service user that a decision has been taken to restrict their access and
contact. In such circumstances, the service provider should provide a brief statement to the
service user outlining the reasons for this. (Combarro, E. Montan 2005).

2.7.1 DEALING WITH YOUR COMPLAINT

We will formally acknowledge your complaint within (the maximum time to be inserted here is 5
working days) and let you know how we intend to deal with it. We will ask you to tell us how
you would like us to communicate with you and establish whether you have any particular
requirements for example, if you have language difficulties. We will deal with your complaint in
an open and honest way. We will make sure that your interactions with us in the future do not
suffer just because you have made a complaint. If you are making a complaint on behalf of
somebody else, we will need their agreement to you acting on their behalf. (Combarro, E.
Montan 2005).
2.7.2 INVESTIGATION

We will tell you who we have asked to investigate your complaint. If your complaint is
straightforward, we will usually ask somebody from the service to look into it and get back to
you. In some cases, if the complaint is serious, we may ask someone from outside the
organization to investigate. We will set out to you our understanding of your complaint and ask
you to confirm that we have it right. We will also ask you to tell us what outcome you expect. (J.
Ranilla, And R. Mones, 2005).

The person looking at your complaint will usually need to see the files we hold relevant to your
complaint. If you do not want this to happen, it is important that you tell us. If there is a simple
solution to your problem, we may ask you if you are happy to accept this. We will aim to resolve
concerns as quickly as possible and expect to deal with the vast majority within 30 working days
(if appropriate, service providers may wish to insert a shorter timescale here).

According to Lewis 200, The person who is investigating your concerns will aim first to
establish the facts. The extent of this investigation will depend on how complex and how serious
the issues you have raised are. In complex cases, we will draw up an investigation plan.

In some instances, we may ask to meet you to discuss your complaint. Occasionally, we might
suggest mediation or another method to try to resolve disputes (J. Ranilla, And R. Mones,

2007). When investigating your complaint, we will look at relevant evidence. This could include
files, notes of conversations, letters, emails or whatever may be relevant to your complaint. If
necessary, we will talk to the staff or others involved and look at our policies and any guidance.
2.7.2 OUTCOME

If we formally investigate your complaint, we will let you know what we have found in keeping
with your preferred form of communication.

This could be by letter or email, for example.

If necessary, we will produce a longer report. We will explain how and why we came to our
conclusions.

If we find that we got it wrong, we will tell you what and why it happened. If we find there is a
fault in our systems or the way we do things, we will tell you what it is and how we plan to
change things to stop it happening again.
 CHAPTER THREE

3.0 SYSTEM METHODOLOGYAND DEVELOPMENT

3.1 METHODOLOGY

In the system development I implemented the use of agile methodology where the system has
taken into consideration the user requirements and iteration criteria to accomplish the objectives
of the system. To ensure that the system enables the users to accomplish their tasks and goals as
it uses the user input and developed on iteration as testing done severally from the user
requirements and iteration. The iterative process dominates agile development process. Iterations
are usually two or four weeks in length and have affixed completion time to enhance the scope of
the system. Due to its time bound nature, the iteration process is methodical and the scope of
iterations is only as broad as the allotted time allows.

The multiple iterations took place during the agile development life cycle and each followed its
own workflow. During iteration, it is important that the customers and business stakeholders
provide feedback to ensure that the features meet their needs.

My iteration process flow is visualized by;

Requirements: defining requirements for the iteration based on the defined on the complaints
management system backlog, sprint backlog, students and management feedback.

Development: designing and developing an online system based on the requirements from both
students, staff, lecturers and management as well as stakeholders.

Testing: this is by checking on Quality Assurance (QA) testing, internal and external training
and documentation development of the system as a whole.

Delivery: integrate and deliver the working iteration into production for the functionalities in the
organization or institution.

Feedback: accept students and management feedback and work it into the requirements of the
next iteration.
In this agile methodology I had implemented live demonstrations, daily testing on functionalities,
sharing of feed-backs and in all I had to remain agile that means that I was making changes to
my process based on the feedback of customers and stakeholders to ensure each iteration
improves the last to ensure system functions as required from the users and stakeholders. I had
also employed testing of system until an acceptable income was achieved from which I
developed the loans management system. This method had allowed me to interact with end user
that is customers and administration as this system requires many interactions with end users on
interfaces.

I used agile methodology because it is more flexible, productive, transparent, optimization and
reduced risks on the system being developed. In agile methodology, there is faster
implementation of solutions, minimization of resources, adaptable to changes and optimized
development processes. With the use of iteration and testing in each case, it provides a system
that satisfies both users and stakeholders as a better output achieved.

3.2 DATA COLLECTION

This involves the gathering of information and data required for the development of the online
complaint management system. This can be from the users of the system (students) and from the
stakeholders (management). The data collection methods are classified into primary and
secondary sources. Involves gathering user requirements on system and performance on the
development of prototypes and complete system.

3.2.1 Primary source of data.

I developed questionnaires that were given to students, staff, lecturers and stakeholders to
respond to them to gather more information and their requirements from the system as main
users that interact with system. In the survey the questionnaires had a set of standardized
questions often known as items which follow a fixed scheme in order to collect individual data
about the system topics. I included both open questions and closed questions to gather more
information the system requirements. I offered my questionnaires to students and staff inquire
more about system requirements to ensure final system developed achieves their goals and
objectives.
I also applied observations as a method of data collection where I surveyed other learning
institutions that requires the system to observe the challenges of the current system that helped
me design a system that solved various problems facing current system. I also checked on the
security and user interfaces of the current system through observation method. This was achieved
by recording events that perform and check on the guide and protocols applied in the institution.

I had to interview both the students or users and the staff using the system because they are the
entities involved in the daily tasks of the system. I also interviewed the stakeholders to gather
more information on the system they propose to have so as I could meet their requirements too
during my design. Interviews can be both qualitative and quantitative interviews.

3.2.2 Secondary sources

Documents and manuals of systems had also given me more information on the requirements of
users and study the existing system to enable me implement new procedures and functionalism in
the system.

I also checked on the oral histories online about the development of online complaint
management system thus enabled me create a system that met the user and stakeholders’
requirements.

To add on that, I used online portals that have been put in use by other learning and NGOs
institutions for the purpose of complaint system. This helped me to be in touch with a real system
and get the overview of how my system will look like. I interacted with those systems’
administrators to be granted access into the system, try to interact with it and hear respond. This
ensured that I develop a more competitive system to ensure user objectives.
3.3 SYSTEM DESIGN

In system design I came up with the flow chart, data flow diagram, database on both logical and
physical database, entity relationship diagram to show various relationships in the complaint
system as well as the user case diagrams of the system. These design tools will ensure the human
readable and understandable requirements are being transformed into the actual code understood
by machines. The analysis and design tools I used are as discussed below;

3.3.1 Flow chart

When the online complaint management system is, started one may start by registering or as a
visitor who only wants to view the site view functionalities. In the case of a visitor he/she can
view the site, view the available resources and features and can also see the user interface but
cannot make complaints until he/she registers as a user to the system.

For a registered user he provides the login detail that is username and password for entry into the
system if the system authenticates and finds details are valid then one proceeds as student or
staff. If invalid details are provided, then the system returns to login page again for user to check
username and password.

On staff or admin side, the user can manage complaints, manage student details, respond to
complaints, forward the complaints, manage announcements and can generate reports on
complaints and finally logout.

On student side user can make a complaint online, view complaint details, view other
respondents and other tabs, change profile details, delete her complaints, make a follow-up and
send messages to staff and finally logout.
3.3.2 DATABASE

3.3.2.1 Data flow diagram

A data flow diagram shows the way information and data flows through the online complaint
management system. It includes data inputs and outputs, data stores and various sub processes
the data moves through. Data flow diagrams are built using standardized symbols and
notification to describe various entities and their relationships.

The data flow diagrams can be of two ways the physical data flow diagram and the logical data
flow diagram. Physical data flow diagrams focus on how things or activities happen in an
information flow. These specify the software, hardware, files and entities or people involved in
an information flow. The logical data flow diagram focus on what things happen in a particular
information flow: what information is transmitted, what entities are receiving or involved and
what general processes occur. The physical data flow diagram can facilitate the development of
the code needed to implement a system. Data flow diagram can be of three levels; context level
DFD, level 1 DFD and level 2+ DFD.

Context level DFD is the most basic form of data flow diagram. It aims to show how the entire
complaint management system works at a glance. It show the way all the data flows either into or
out of the complaint management system and the whole process. It shows the interactions
between the system and the external entities as well as how they achieve their tasks or goals. The
usually do not contain the data stores. In this case, I will have the online complaint management
system as the main process or system and students, staff, welfare and director. I will include the
activities or the interactions to the system.

Level 1 DFD is a data flow diagram that aims to give an overview of the full system. They give
more details on the system and show more interactions between the entities and the system
processes. The online complaints system process is broken down into various sub-processes and
now the data stores are picked and added and are well shown or indicated in this level 1 data
flow diagram. I will use this level 1 DFD as my final data flow diagram in the online complaint
management system.

3.3.2.2 Entity relationship diagram

On the online complaint system, the main entity of the system is the users who can be the
student, lecturer or staff that is a management member and stakeholders or management who are
also users of the system. The entities are represented by the rectangles. It has also weak entities
like the complaint details, complaint status, complaint feedback and remedy. The weak entities
are represented by double rectangles. The various relationships are shown as one-to-many
relationships (1-M) and the many attributes of the entities like as an example student details are;
student id and student name. Numbers and characters indicate these relationships. The diamonds
represent the relationship sets such as admin manage student details, complaint details, complaint
reporting, complaint feedback and remedies. The attributes of the entities are also indicated in
the diagram by eclipses for example student details have attributes like student id and student
name.

3.3.3 SYSTEM DEVELOPMENT

3.3.3.1 Tools used

I used MySQL that works with windows as my database management system. This is because
there is high-speed data processing, use of triggers increase productivity, with rollback and
commits help in data recovery if required. I used E-draw max software in developing the design
tools like DFDs, ERDs and flow charts because this software has various tools and symbols that
represent various entities, relationships and attributes. E-draw max software contains several
design tools and symbols used to represent system functionalities, all the entities, and the
relationships among the entities in the system. I used VS code, NetBeans, sublime text and
Notepad++ in my programming and editing of my system code because they provide and support
wring a bug-free code and fast or smart code editing.
3.3.2.2 Testing methodology

In system, testing one can use either functional or non-functional testing. In my case, I
implemented use of non-functional testing because I need to focus much on testing partially to
employ security in the system. Non-functional testing helps my testing teams check their
products, particularly in the areas of performance, reliability, security, and usability. This does
not involve testing the system’s functions; it includes testing of system operation. Nevertheless,
this testing type is no less significant than the functional one. For clients, it is critical to know
that products not only perform the assigned functions but also work stably and seamlessly. In this
case, non-functional testing helped in making sure that the system is stable and does not lag
under heavy user load especially on transactions.

The main non-functional software testing types can be as below:

Performance Testing: You can probably guess what this type of testing aimed at: checking the
performance of the product (speed, scalability, and stability). UI Testing: This relates to the
application design. It helps testing teams determine that all elements of the interface work as
expected. You can also understand whether fonts, sizes, and content are in a good shape and
whether the app’s interface resembles an initial plan. Security Testing: Running security tests lets
me find out whether the system can withstand hacker attacks or discover if it contains any
loopholes. This is one of the most important types of software testing because user data is at
stake. Whether you developed a tool for processing credit payments or an app for shopping in an
online store, the safety of the product will always be a top concern for your clients. Compatibility
Testing: This type of software testing helps determine how systems behave with other software,
network environments, or web servers.

3.3.2.4 Implementation

Implementation classified as either parallel implementation, phased implementation, pilot

implementation or direct implementation. In my online complaints system I used the phased type
of implementation, which involves the system changeover from an existing system to a new one
through various stages. It allows the activities of an institution to continue while changes
implemented to the system. The aim of phase implementation is effectively manage the
associated workload and expectations of the system in a realistic and organized timeframe.
Phased implementation must pass through four stages, definition, planning, execution and
delivery.

I used phased implementation in my online complaints management system implementation

because; Training can be completed in small parts, A failure of the new system has minimal
impact because it is only one small part, Less resources are required in development in parts so
cost not felt as such and issues around scale can be addressed without major impact.

3.3.2.5 Maintenance

Maintenance of a system can be preventive maintenance, predictive maintenance, corrective

maintenance and breakdown maintenance. In my system development, I employed use of
predictive maintenance. Predictive maintenance is a method for doing maintenance by replacing
parts based on predictions using a tool. The point is if the preventive method based on the
schedule, then the predictive method based on those results of the measurement. This method can
also use the five senses, for example in bearing inspection can be distinguished from the sound
produced. Or checking temperature, by touching it we can feel the difference or abnormality of
the equipment.
 CHAPTER FOUR

4.0 SYSTEM DESIGN

4.1 Flow chart design

From the diagram, the visitor can only view the site and view the User interface and the contact
details and about UMMA University and exit the system. The staff can login to the system view
the complaints, manage complaints, respond to complaints, generate reports and manage profile
and then exit. The Admin has a lot to do with the system as he can manage and ensure
complaints and users are handled to ensure student satisfaction. He/she manages all the activities
in the system and shares the information with the management to ensure all complaints are
resolved.

Students can register and login to the system and report complaints, view complaint details, view
feedbacks, manage profile and logout of the system. Complaint details are like complaint status,
feedbacks and type plus the remedies for each. The management too can check on reports in case
the staffs request due to other reasons request it. The management takes control of all decision
making process in the all departments and thus efficiency and effectiveness in complaint
handling.
4.2 Database logical design

The diagram shows how the system is structured logically where the Admin is at the top and can
check or view all complaints, students, staff and the complaint details example feedbacks and
also communicates with both students and the staffs who work towards complaints for
satisfaction and dispute settlement.

The staffs ensure student services are offered on complaints and checks all complaint details and
that feedback services are provided in time. On the other hand, the management is ready to
handle the reported complaints for approval on the requirements of the organizations on various
types of complaints.
4.3 Database physical design

The physical design below shows how the various entities of the online complaints management
system work together to achieve student objectives and goals are met on complaints reported.
The Admin manages both the students, complaints and the various details in the university.
Students do report their complaints once registered with the system and complaints recorded in
the database and the staffs registered or assigned those tasks by the institution handle the
complaints. The management verifies the complaints in accordance with rules and regulations of
the organization and then remedy and actions are taken on the same. A student can view
complaint details, complaint status after reporting the complaint. The staffs and the management
can communicate with the Admin and once decisions are made, the status can be updated.
4.4 The Entity Relationship Diagram (ERD)

The ERD is a diagram that shows the relationships in the online complaint management system
and all the entities with their attributes of the system or organization. In the figure below, the
figure represents all the relationships both one-to-one relationships, 0ne-to-many relationships
and many-to-many relationships among the entities. Main entity is at the staff who manages all
the activities within the system. He/she manages loan reported complaints, complaint details,
complaint status, student details, feedbacks and the remedies and ensures that student complaints
are well handled.

The admin on the other side ensures all details for the complaints reported are dealt with and
records are up to date. The students report the complaints; view complaint feedback and the
status of the complaint make follow-ups and view all the details from the system on complaint
handling.
4.5 Data Flow Diagram (DFD)

4.5.1 Level 0 DFD diagram

This level of DFD contains the basic information of the complaints management system is
designed or structured. The main entities of the system are shown to allow the activities of the
system and the functionalities of the system to be achieved as well as the student objectives.

The entities acquire information from the system as shown below to serve all the entities of the
system. This shows the activities like student details, complaint details, reporting of complaints
and complaint status as well as the verification process.
4.5.2 Level 1 DFD diagram

The level 1 DFD below show the various ways in which the entities of the system work together
to achieve the goals of the system. It shows what a given entity can do in a given system and the
activities of the system. All the entities have to register to the system in order to access services
of the complaint management system.

Students after registration can go forward to report their complaints from the system according to
the challenges they are facing while in the organization. The staff and the administrator manage
the complaints and students of the system. The Admin can also update on complaints status and
handling that are beyond the reach of the staffs and facilitate remedies from the management
whose task is ensure student satisfaction is achieved and high standards of welfare and well-
being of students of the institution.

4.5.3 Level 2 DFD diagram

This level 2 DFD is the final level of the data flow diagram in which all the activities of the
system are shown and the entities that perform various processes of the online complaint
management system. The processes are well included like handling of complaints that is
approval and remedy actions, follow-up by students and reporting process of the staffs to the
admin and reports to be handled by management.
 CHAPTER FIVE

5.0 PROPOSED SYSTEM

5.1 Main page

5.2 Registration page

5.3 Report page
5.4 Admin login page

5.5 Admin main page

5.6 Data profile
5.7 User management by admin
 References

B.Y. Ricardo and R.N. Berthier, (1999).Modern Information Retrieval. Addison Wesley
Longman, Journal 25(2).144-190.

H. Kim, P. Howland, And H. Park ( 2005) .“Dimension Reduction in Textclassification with

Support Vector Machines,” J. Machine Learning Research, Vol. 6, Pp. 37- 53.

R. Kohavi and G. John, (1997) . “Wrappers for Feature Subset Selection,” Aritficial Intelligence,
Vol. 97, No. 1-2, Pp. 273-324.

Marcus, (2000). “Complaints Management aspects, “Complaint software, Journal 21(9).124-200.

F. Sebastiani, (2002 ). “Machine Learning in Automated Text Categorization,” Acm Computing

Surveys, Vol. 34, No. 1, Pp. 1-47.

Y. Yang and J.O. Pedersen, (1997). “A Comparative Study On Feature Selection in Text
Categorization,” Proc. 14th Int’l Conf. Machine Learning, Pp. 412-420.

D.D. Lewis, (1992). “Feature Selection and Feature Extraction for Text Categorization,” Proc.
Workshop Speech and Natural Language, Pp. 212-217.

(J. Ranilla, And R. Mones, (2007) Complaint Management “Complaint and ICT, vol.12, No. 2-3,
Pp. 5-6.

E.F. Combarro, E. Montan˜ E´S, I. Dı´Az, J. Ranilla, And R. Mones, (Sept. 2005). “Introducing
A Family of Linear Measures for Feature Selection in Text Categorization,” Ieee Trans.
Knowledge and Data Eng., Vol. 17, No. 9, Pp. 1223-1232.

Osman Abd Allah Nasr Ali .(2014) . Information system .Journal of Management 26(5) 112-
130.

Enayat Ali Alkhider Taha M.Sc. (2012). Information Technology Acm Computing Surveys,
Vol. 14, No. 3, Pp. 7-17.