Table of Contents

1. Introduction ................................................................................................................................... 4
1.1. Purpose ................................................................................................................................... 5
1.2 Document Conventions .......................................................................................................... 5
1.3 Intended Audience and Reading Suggestions ............................................................................. 6
1.4 Product Scope .............................................................................................................................. 6
1.5 Software Development Life Cycle ............................................................................................... 6
1.6 Waterfall Model ........................................................................................................................... 8
CHAPTER 02 ...................................................................................................................................... 11
Literature and analysis........................................................................................................................ 11
2.1 Background .......................................................................................................................... 12
2.2 Existing System .................................................................................................................... 12
2.3 Purposed System .................................................................................................................. 12
2.4 User Classes and Characteristics ......................................................................................... 12
2.5 Comparison Table with existing system .............................................................................. 13
2.6 Gantt Chart .......................................................................................................................... 13
2.7 Operating Environment ....................................................................................................... 14
2.8 Design and Implementation Constraints ............................................................................. 15
2.8.1 Admin Module Front End (sublime text 3) .................................................................. 15
2.5.1.1 Bootstrap 4 ....................................................................................................................... 15
2.5.2 Back End (DATABASE): ................................................................................................. 15
2.5.2.1 Microsoft SQL Server:- ................................................................................................. 15
2.5.3 User Module (android studio) ................................................................................................. 15
2.5.3.1 Android with Java ............................................................................................................ 15
2.9 Assumptions and Dependencies ........................................................................................... 15
CHAPTER 03 ..................................................................................................................................... 17
Design & Specification ........................................................................................................................ 17
3.1 Introduction ............................................................................................................................... 19
3.2 Use Case ..................................................................................................................................... 19
3.3 Data Flow Diagram .................................................................................................................... 25
3.3 Entity Relationship diagram...................................................................................................... 29
 3.4 Class Diagram ............................................................................................................................ 32
3.5 Activity Diagram........................................................................................................................ 33
3.5.1. Basic Activity Diagram Notations and Symbols .................................................................... 33
3.6 Sequence Diagram ..................................................................................................................... 36
3.6 Basic Sequence Diagram Notations ........................................................................................... 36
3.7 User Interfaces ........................................................................................................................... 50
CHAPTER 04 ....................................................................................................................................... 52
Implementation ..................................................................................................................................... 52
4.1 Introduction: ................................................................................................................................ 53
4.2 Development plan: ....................................................................................................................... 53
4.2.1 Sequential Phases in Waterfall Model.................................................................................... 53
4.3 Development of program ............................................................................................................. 55
4.4 System Tool Selection: ................................................................................................................ 55
4.4.1 Hardware .............................................................................................................................. 55
4.4.2 Software............................................................................................................................... 55
4.4.3 Communications Interfaces ................................................................................................... 56
CHAPTER 05 ...................................................................................................................................... 57
Deployment .......................................................................................................................................... 57
5.1 Deployment of a system: .............................................................................................................. 58
5.2 Testing of a system: ..................................................................................................................... 58
5.2.1 Purpose of testing: .................................................................................................................... 58
5.2.1.1 Unit Testing ....................................................................................................................... 58
5.2.1.2 Integration Testing ............................................................................................................. 58
5.2.1.3 Acceptance Testing: ........................................................................................................... 58
5.3 Test cases: ................................................................................................................................... 59
5.4 Non-functional Requirements ................................................................................................. 69
5.5 Software Quality Attributes ................................................................................................. 70
5.7 Future Work......................................................................................................................... 71
5.8 Conclusion ............................................................................................................................ 71
List of Figures
Figure 2 Gantt Chart for Quick Complaint Portal ................................................................................... 14
Figure 2 User case diagram (User) ......................................................................................................... 21
Figure 3 Admin Use Case (Admin) ........................................................................................................ 22
Figure 4 Stakeholder Use Case (Sub Admin) ......................................................................................... 24
Figure 5 DFD Level 0 ............................................................................................................................ 27
Figure 6 DFD Level 1 ............................................................................................................................ 28
Figure 7 DFD Level 2 ............................................................................................................................ 29
Figure 8 ERD Diagram .......................................................................................................................... 31
Figure 9 Class Diagram ......................................................................................................................... 32
Figure 10 Create Complaint - Activity Diagram ..................................................................................... 35
Figure 11 User Registration -Activity Diagram ...................................................................................... 36
Figure 12 Create Complaint-Sequence Diagram..................................................................................... 38
Figure 1 Admin Interface ....................................................................................................................... 51
Figure 61 waterfall mothed .................................................................................................................... 53
1. Introduction
Quick Complaint Portal is an android project based on a realistic and real world problem
i.e. complaints for Institute of Southern Punjab Multan. Each student, faculty or employee of
Institute can submit complaint from his mobile app by adopting a certain set of activities i.e. sign
up (for first time), login, update profile (provide his bio data), submit complaint, notifications. His
application is submitted on portal to concerning department. Departments will have their own
logins on web portal. Department will receive this complaint on web application interface and will
forward this complaint to root level. Time to time notifications is issued to complainant to update
complaint status. For example, Complaint may be related to student bullying, ragging, conveyance
route issue/ fast or rash driving etc.

Quick Complaint Portal is a mobile application that allows a Student to register themselves
on it and register their complaints to the concerned departments.

Quick Complaint Portal that allow a student to different Complaint submit for example late timing
conveyance route issue or fast or rash driving or may be related to student bullying, ragging issues.

Quick Complaint Portal that allow a student to Positive Feedback or negative and Pending
Complaint to see on further Process suppose give a Positive Feedback on before check the
Department Complaint on good Response the Complaint Process, and the negative Feedback on
before check the complaint not Process our Complaint submit before a negative feedback submit
the student , Pending Complaint on under process the complaint , student give a Feedback some
star for example Excellent ,poor or very poor.

Department that all the registered complaints is sent to the heads of the departments
(Stakeholder) who would take appropriate action to address the matter.

New Complaints

Any complaint upon its first arrival at a dashboard will get hosted under the icon of the
new complaints. It will remain there until it is opened for some comments or further processing.
The assigned timeline of any complaint either received directly from the Department (Stakeholder)
or forward this complaint to root level.
In Process Complaints
This is the initial stage of a complaint, guidance seeking query reflected on the respective
dashboard. Every complaint has a default resolution time in the system that may vary from
category to category. At this initial stage, a complaint received on a dashboard is reflected as In-
process. This stage involves steps like initiation of action, assignment of complaints to concerned
department and processing till timely resolution.

Response/Comments
Every student, faculty or employee of Institute member maintains an account of his/her
complaints with details. Thus, comments are mandatory at all stages of complaint processing.
However, reply to complainants shall be prompt, accurate, and with courtesy. It shall also be
ensured that comments/response shall be in same language wherein the complaint has been lodged.
While responding/commenting on a complaint during processing, the following shall be
considered.

About Web Application

All the registered complaints’ status would be sent to department on regular basis. The
web application was in the development phase for mobile app users to register their complaints
through this application. Quick Complaint Portal is a department web based Portal and it is
designed to keep track of complaints registered by the student, faculty or employee of Institute, so
this system need to have distributed platform independent web application.
1.1. Purpose
Quick Complaint Portal Resolve all Complaint in the University Institute of Southern
Punjab Multan. Because there is no proper complaint system in the Institute of Southern Punjab.
Complaints are never recorded in written proper. Most of the time all verbal communications are
used to process issues or just they have been ignored.

1.2 Document Conventions

 Times New Roman with bold and size 14 is used in Headings.

 Times New Roman with bold and size 14 and 12 is used in sub-headings.
 Times New Roman with size 12 is used in the Descriptions.
1.3 Intended Audience and Reading Suggestions
In the user Module access only register the student, employee and faculty of Institute of
Southern Punjab and we will use the complaint system. Admin Module resolve all the complaint
or forward this complaint to root level and define the categories. Web Application Access the
admin or Stakeholder.

1.4 Product Scope

The system resolve all submitted complaints related to student, faculty or employee of
Institute of Southern Punjab Multan. Stakeholder is Update Complaint Status (i.e. Complaint is
resolved / not resolved) and also receive this complaint on web application interface and will
forward this complaint to root level. Time to time notifications is issued to complainant to update
complaint status. Stakeholder Profile necessary storage, modification and also Password
Recovery. Admin also add User categories (Student, Faculty, Visitor etc.) or Complaint Category
(i.e. Department, Accounts, Lab, Route, canteen etc.) and Sub-categories (i.e. Corruption, bullying
etc.).

User Registered the Profile or login and also Password recovery Process. User submitted the new
Complaint and see the Withdraw complaint, Re-process complaint. User Give a Feedback
(Positive, Negative and also comments section.

1.5 Software Development Life Cycle

SDLC stands for software development lifecycle. A software development lifecycle is essentially
a series of steps, or phases, that provide a model for the development and lifecycle management
of an application or piece of software. The methodology within the SDLC process can vary across
industries and organizations, but standards such as ISO/IEC 12207 represent processes that
establish a lifecycle for software, and provide a mode for the development, acquisition and
configuration of software systems.

There are various software development approaches defined and designed which are
used/employed during development process of software, these approaches are also referred as
“Software Development Process Models” (e.g. Waterfall model,, incremental model, prototype
model, iterative model, etc.). Each process model follows a particular life cycle in order to ensure
success in process of software development.
Software life cycle models describe phases of the software cycle and the order in which those
phases are executed. Each phase produces deliverables required by the next phase in the life cycle.
Requirements are translated into design. Code is produced according to the design which is called
development phase. After coding and development the testing verifies the deliverable of the
implementation phase against requirements.

There are following six phases in every Software development life cycle model:

1. Requirement gathering and analysis

2. Design
3. Implementation or coding
4. Testing
5. Deployment
6. Maintenance

1) Requirement gathering and analysis: Business requirements are gathered in this phase.
This phase is the main focus of the project managers and stake holders. Meetings with managers,
stake holders and users are held in order to determine the requirements like; Who is going to use
the system? How will they use the system? What data should be input into the system? What data
should be output by the system? These are general questions that get answered during a
requirements gathering phase. After requirement gathering these requirements are analyzed for
their validity and the possibility of incorporating the requirements in the system to be development
is also studied.

Finally, a Requirement Specification document is created which serves the purpose of guideline
for the next phase of the model.

2) Design: In this phase the system and software design is prepared from the requirement
specifications which were studied in the first phase. System Design helps in specifying hardware
and system requirements and also helps in defining overall system architecture. The system design
specifications serve as input for the next phase of the model.

3) Implementation / Coding: On receiving system design documents, the work is divided in

modules/units and actual coding is started. Since, in this phase the code is produced so it is the
main focus for the developer. This is the longest phase of the software development life cycle.

4) Testing: After the code is developed it is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements phase.
During this phase unit testing, integration testing, system testing, acceptance testing are done.

5) Deployment: After successful testing the product is delivered / deployed to the customer for
their use.

6) Maintenance: Once when the customers starts using the developed system then the actual
problems comes up and needs to be solved from time to time. This process where the care is taken
for the developed product is known as maintenance.

1.6 Waterfall Model

In this approach, we see that processes flows in a downward fashion from requirement
phase to accepting phase which meets to client satisfaction. Requirements phase collects software
specifications, functional and non-functional requirements in SRS (software requirement
specification). Analysis phase analyzes cases and work plan on the basis of software requirement
phase that covers use case scenarios up to methodology and work plan. Design phase goes through
with flow charts, algorithms and GUI on the basis of analysis phase. Coding phase generates the
actual logic of the application and provide functionality to the system. The system logic is tested
if it is working as it is as in designing phase. Finally, client acceptance phase verify if application
meets to the client’s requirement.
 CHAPTER 02
Literature and analysis
2.1 Background
Pakistan Citizen Portal is designed and developed by NITB Pakistan which is used to
resolve citizen’s problems in the same way as I declared in our case. Quick Complaint Portal is
designed and Developed by Institute of Southern Punjab is used to resolve all Complaint of
Student, faculty or employee of Institute.

2.2 Existing System

There is no computerized /online complaint system in institute of southern Punjab Multan for
redressal of graveness. All complaints are manually submitted in concerning departments on
paper. Few of them are resolved. While most of complaints are ignored or verbally addressed.

2.3 Purposed System

Quick Complaint Portal that allow must user Registration Form Fill then we will login the Portal
and also update profile (provide his bio data). User is Response in comment Section and give a
feedback after the complaint Submit.
Departments will have their own logins on web portal that allow to must Registration Form Fill
then we will login the web Portal and also update profile (provide his bio data). Department receive
this complaint on web application interface and also forward this complaint to root level.

2.4 User Classes and Characteristics

General User Module classes (Android Application):

 Project has a several classes for example Register the user, login the user, User Profile,
Password Recovery, New Complaint Submission , Withdraw complaint / Re-process
complaint and Feedback (Positive, Negative etc. with comments )

Admin Module (Web Application):

 Admin Login
 Admin Profile
 Password Recovery
 Stakeholder Management (Complaint resolver )
 User categories (Student, Faculty, Visitor etc.)
 Complaint Category (i.e. Department, Accounts, Lab, Route , canteen etc.)
 Sub-categories (i.e. Corruption, bullying etc.)
Stakeholder Module (Web Application):

 Stakeholder login
 Stakeholder Profile
 Password Recovery
 Update Complaint Status (i.e. Complaint is resolved / not resolved)

2.5 Comparison Table with existing system

Feasibilities Existing System (Manual Purposed System (Online

System) Quick Complaint Portal)
Ease in Complaint submission No Yes
Complaint tracing No Yes
Complaint status No Yes
Paper work Yes No
Statistical Analysis No Yes

2.6 Gantt Chart

A Gantt chart, commonly used in project management, is one of the most popular and useful ways of
showing activities (tasks or events) displayed against time. On the left of the chart is a list of the activities
and along the top is a suitable time scale. Each activity is represented by a bar; the position and length of
the bar reflects the start date, duration and end date of the activity. This allows you to see at a glance:

 What the various activities are

 When each activity begins and ends
 How long each activity is scheduled to last
 Where activities overlap with other activities, and by how much
 The start and end date of the whole project
 May June July August September

Analysis

Design

Backend

Deployment

FYP report

Figure 1 Gantt Chart for Quick Complaint Portal

2.7 Operating Environment

To use the developed system it is recommended that user must have a system(Web Server) with
the following minimum specification:

 Processor 3ghz or faster

 Ram 1GB or above
 Disk minimum 2GB space for installation
 MYSQL / MARIADB
 PHP 7.2
 PHPMYADMIN

 Web Application
On the hardware side a web server is a computer that stores web server software and a website's
section files (etc. PHP documents, images, CSS stylesheets, and JavaScript files). It is connected
to the Internet and supports physical data exchange with other devices connected to the web.

Web application is access through an web browser from any environment like support all Windows
(Windows 7, 8.1 and 10) and operating System

 Mobile app
Mobile app support maximum android version. Application is uploaded on google play store to
provide access to user through internet. Jelly Bean 4.1 – 4.3.1 with API level 16-18 or higher is required
to operate this app.
2.8 Design and Implementation Constraints

2.8.1 Admin Module Front End (sublime text 3)

2.5.1.1 Bootstrap 4
Sublime Text will offer to complete entries as the user is typing depending on
the language being used. It also auto-completes variables created by the user. Syntax highlight and
high contrast display. Bootstrap 4 is the newest version of Bootstrap. Which is the most popular
HTML, CSS, and JavaScript framework for developing responsive, mobile-first websites

2.5.2 Back End (DATABASE):

2.5.2.1 Microsoft SQL Server:-

MS SQL Server is used as a database.

 MS SQL Server is a user friendly user database with no special skills required to learn it.
 Database and tables in MS SQL are portable.
 Users can create tables, queries, forms and reports, and connect them together.
 Queries can be viewed graphically or edited as SQL statements.

2.5.3 User Module (android studio)

2.5.3.1 Android with Java

Android apps in the Java programming language using an IDE called Android Studio. Based on
JetBrains IntelliJ IDEA software, Android Studio is an IDE designed specifically for Android
development.

User module or Admin module both are used MYSQL to store data

2.9 Assumptions and Dependencies

The project is planned with the following assumptions

o Windows OS only. (Windows 10 Pro)
 GHz Intel® Processor or greater
o 8 GB RAM
 o 18 GB of Hard Disk Space or more.
o Screen resolution of 1024 x 780 or greater.
o All the users of the system should be considering literate to use the system.
 This software can be easily upgraded in the future.
 It is connected with the internet for easily retrieved data about projects, users can be
easily added into the database, can check status of overall performance.
 CHAPTER 03
Design & Specification
3.1 Introduction

A use case modeling language (UML)allow a software engineering express an analysis modeling that is
governed set of syntactic, semantic, pragmatic rules. Or the Unified Modeling Language (UML) is language
for specifying constructing, visualizing and documenting the artifacts of a software-intensive system. First
and foremost, the Unified Modeling Language focuses the concept of brooch, OMT, and OOOSE, The
result is a single, common, and widely usable modeling language for users of these and other methods.
Secondly, the Unified Modeling Language focuses on a standard modeling language, not a standard process.
Although the UML must be applied in the context of a process, it is our experience that different
organizations and problem domains required different processes. UML define nine types of diagram: class
(Package), Object, Use Case, Sequence, Deployment diagram etc.

The objective of Object Oriented Analysis and Design is to develop a model that describes computer
software as it works to satisfy a set of requirements. After understanding the current situation of the problem
domain I am ready to strive for the solution by using OOAD approach.

3.2 Use Case

A use case describes a sequence of actions that perform by an actor. The sequence of actions can
be described using a series of textual flows and scenarios, using UML activity diagram or using a
combination of both.

Actor
An actor is a person, organization, or external system that plays a role in one or more interactions
with your system, Actor can communicate with the system, is not part of system and exist
independently to the system. It need to use the system rather than just operate.
A use case diagram at its simplest is a representation of a user's interaction with the system and
depicting the specifications of a use case. A use case diagram can portray the different types of
users of a system and the various ways that they interact with the system. This type of diagram is
typically used in conjunction with the textual use case and will often be accompanied by other
types of diagrams as
Use Case
Use cases describe the interactions that take place between actors and IT systems during the
execution of business processes:

Association
An association is a connection between an actor and a use case. An association indicates
that an actor can carry out a use case. Several actors at one use case mean that each actor
can carry out the use case on his or her own and not that the actors carry out the use case
together:

Include Relation
An include relationship is a relationship between two use cases:

User Diagram:
 Figure 2 User case diagram (User)

Actor User

Description: The mentioned use case elaborates the authorities of the user.

Pre-Conditions: User must have login to access panel.

Task Sequence Exceptions

User can change , recover, reset password

User can give a Feedback

User has facility to submit a new Complaint

User can ask for the Process Complaint ,or Closed complaint

User must Sign in and Update the profile

User is return the Complaint

Admin:

Figure 3 Admin Use Case (Admin)

Use Case Title Admin Authorities

Actor Admin

Description: The mentioned use case elaborates the authorities of the admin.

Pre-Conditions: Admin must have login to access the panel.

Task Sequence Exceptions

Administrator can Manage Complaints (Process, Closed, Not Process)

Complaints

Administrator can Add Categories, edit, delete and also Views

Administrator has authority to change and allow authorities to different

Stakeholders (Sub Admin).

Administrator also View the User Feedback.

Admin can add sub Categories edit, delete and also Views

Admin can change, reset and forget password.

Admin can also Update own Profile

Admin can add Department edit, delete and also Views

Admin also Manage Users (Stakeholders) edit, delete, and view

Admin also logout and view Notification

Stakeholder:

Figure 4 Stakeholder Use Case (Sub Admin)

 Use Case Title Stakeholder (Sub Admin)

Actor Sub Admin

Description: The mentioned use case elaborates the authorities of the sub admin.

Pre-Conditions: Sub Admin must have login to access the panel.

Task Sequence Exceptions

Sub Admin can Manage Complaints (Process, Closed, Not Process)

Complaints

Sub Admin also View the User Feedback.

Sub Admin can change, reset and forget password.

Sub Admin can also Update own Profile

Sub Admin also logout and view Notification

3.3 Data Flow Diagram

A DFD also known as ‘bubble chart’ has the purpose of clarifying system requirements and
identifying major transformations. It shows the flow of data through a system. It is a graphical tool
because it presents a picture. The DFD may be partitioned into levels that represent increasing
information flow and functional detail.

DATA FLOW:

The data flow is used to describe the movement of information from one part of the system to
another part. Flows represent data in motion. It is a pipe line through which information flows.
Data flow is represented by an arrow.

PROCESS:
A circle or bubble represents a process that transforms incoming data to outgoing data. Process
shows a part of the system that transforms inputs to outputs.

EXTERNAL ENTITY:-

A square defines a source or destination of system data. External entities represent any entity that
supplies or receive information from the system but is not a part of the system.

DATA STORE:

The data store represents a logical file. A logical file can represent either a data store symbol which
can represent either a data structure or a physical file on disk. The data store is used to collect data
at rest or a temporary repository of data. It is represented by open rectangle.

OUTPUT:

The output symbol is used when a hard copy is produced and the user of the copies cannot be
clearly specified or there are several users of the output.
Source:-
An entity is a source of data or a destination for data.

Level 0:
It is also known as context diagram .It’s designed to be an abstraction view, showing the system
as a single process with its relationship to external entities. It represent the entire system as single
bubble with input and output data indicated by incoming/outgoing arrows.
A context diagram is a top level (also known as "Level 0") data flow diagram. It only contains one
process node ("Process 0") that generalizes the function of the entire system in relationship to
external entities. DFD Layers. Draw data flow diagrams can be made in several nested layers.

Figure 5 DFD Level 0

Level 1:
The Level 1 DFD shows how the system is divided into sub-systems (processes), each of which
deals with one or more of the data flows to or from an external agent, and which together provide
all of the functionality of the system as a whole.

Figure 6 DFD Level 1

Level 2:
2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to plan or record the
specific necessary detail about the system’s functioning.
 Figure 7 DFD Level 2

3.3 Entity Relationship diagram

ERD is an entity relationship diagram is a data modeling technique that graphically illustrates an
information system entities and the relationship between those entities. An ERD is an conceptual
and representational model of data used to represent the entity frame work infrastructure.

E-R Model Constructs

The three basic constructs are:

Entity:

An entity is an object whose information is stored in the database. It is distinguishable from other
objects. For example: specific person, company, event, plant. In other words, anything that may
'have an independent existence and about which we intend to collect data is known as Entity. It is
also known as Entity type.

Entities are the principal data object about which information is to be collected. Entities are usually
recognizable concepts, either concrete or abstract, such as person, places, things, or events, which
have relevance to the database. Some specific examples of entities are EMPLOYEES, PROJECTS,
and INVOICES. An entity is analogous to a table in the relational model.

Entities are classified as independent or dependent (in some methodologies, the terms used are
strong and weak, respectively). An independent entity is one that does not rely on another for
identification. A dependent entity is one that relies on another for identification. An entity
occurrence (also called an instance) is an individual occurrence of an entity. An occurrence is
analogous to a row in the relational table.

Attribute:

Attributes describe the properties of the entity of which they are associated. A particular instance
of an attribute is a value. For example, Ram is one value of the attribute Name.

The domain of an attribute is the collection of all possible values an attribute can have. The domain
of Name is a character string.

Relationship:
A Relationship represents an association between two or more entities. Relationships are classified
in terms of degree, connectivity, cardinality, and existence.
Figure 8 ERD Diagram
3.4 Class Diagram
Class diagrams are one of the most useful types of diagrams in UML as they clearly map out the
structure of a particular system by modeling its classes, attributes, operations, and relationships
between objects. With our UML diagramming software, creating these diagrams is not as
overwhelming as it might appear. This guide will show you how to understand, plan, and create
your own class diagrams.

Figure 9 Class Diagram

3.5 Activity Diagram
Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system.
Activity diagram is basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential, branched,
or concurrent. Activity diagrams deal with all type of flow control by using different elements
such as fork, join, etc

3.5.1. Basic Activity Diagram Notations and Symbols

Initial State or Start Point

A small filled circle followed by an arrow represents the initial action state or the start point for
any activity diagram. For activity diagram using swim lanes, make sure the start point is placed
in the top left corner of the first column.

Activity or Action State

An action state represents the non-interruptible action of objects. You can draw an action state in
Smart Draw using a rectangle with rounded corners.

Action Flow
Action flows, also called edges and paths, illustrate the transitions from one action state to
another. They are usually drawn with an arrowed line.
Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow
from an action to an object means that the action creates or influences the object. An object flow
arrow from an object to an action indicates that the action state uses the object.

Decisions and Branching

A diamond represents a decision with alternate paths. When an activity requires a decision prior
to moving on to the next activity, add a diamond between the two activities. The outgoing
alternates should be labeled with a condition or guard expression. You can also label one of the
paths else.
Create Complaint - Activity Diagram

Figure 10 Create Complaint - Activity Diagram

Figure 11 User Registration -Activity Diagram

3.6 Sequence Diagram

Sequence diagrams describe interactions among classes in terms of an exchange of messages

over time. They're also called event diagrams. A sequence diagram is a good way to visualize
and validate various runtime scenarios. These can help to predict how a system ishave and to
discover responsibilities a class may need to have in the process of modeling a new system.

3.6 Basic Sequence Diagram Notations

Class Roles or Participants

Class roles describe the way an object ishave in context. Use the UML object symbol to illustrate
class roles, but don't list object attributes.
Activation or Execution Occurrence
Activation boxes represent the time an object needs to complete a task. When an object is busy
executing a process or waiting for a reply message, use a thin gray rectangle placed vertically on
its lifeline.

Synchronous Message
A synchronous message requires a response before the interaction can continue. It's usually
drawn using a line with a solid arrowhead pointing from one object to another.

Asynchronous Message
Asynchronous messages don't need a reply for interaction to continue. Like synchronous messages, they
are drawn with an arrow connecting two lifelines; however, the arrowhead is usually open and there's no
return message depicted.
Figure 12 Create Complaint-Sequence Diagram
Admin Login

<?php
session_start();
require 'dbConfig.php';

$email=$_POST["email"];
$password=$_POST["password"];
if ($email=="" || $password=="") {
# code...
echo("eError");
exit();
}
try {
$stmt = $conn->prepare("select * from user where Email=? and Password=?");

$stmt->bind_param("ss", $email,$password);
$result=$stmt->execute();
$result=$stmt->get_result();

if (mysqli_num_rows($result)==0) {
 echo "aError";
} else
if ($result) {
$row=$result->fetch_assoc();
$_SESSION["userId"]=$row["User_ID"];
$_SESSION["userType"]=$row["UserType_ID"];

echo 'done';
}else {
echo mysqli_errno($conn);
}
} catch(PDOException $e) {
echo "Error: " . $e->getMessage();

}
Admin Register

Dashboard
Not process complaint

Closed complaint
Add New user

Department
Edit or view Department

User Feedback
Add Categories

Edit or Delete categories

User Module

Login

New User Register

Dashboard
New complaint

Pending complaint

Resolve complaint
Reject complaint

Feedback
3.7 User Interfaces

 Admin or User must be login with own Password or user name.

 If User name or Password is Invalid then display error message.
 If user or admin forget the Password when we Using Email should be change password.
 User will not be Sign Up then user should be Sign up and also update profile (provide his bio
data) when user is login. Admin Module used in a Bootstrap 4 Frame work.
 User Module using a android with Java and also data store in MYSQL. Sign in Button used in
both admin or User enter the home page and different actions should perform user submit a
new complaint, give a feedback, view in process complaint, not Process Complaint, Closed
complaint, Update a profile and also view Notifications,
 Admin will receive the Complaint this complaint on web interface and will forward this
complaint to root level.
 Admin module is add the Categories or sub Categories and also edit or delete operation
perform, admin view the feedback and also add, edit, delete the department.
 Admin is update the profile.
 Admin view the Complainant details and also take action, and forward this complaint to
department.
 Sub Admin also Manage complaint (not process, process or close complaint) and is own
account setting related to profile, change a password or view the user feedback.
Figure 13 Admin Interface
CHAPTER 04
Implementation
4.1 Introduction:

The implementation of a system is the important phase where visions and plans become reality. The
implementation stage of software development is the process of converting a system specification into an
executable system. It almost always involves processes of software design and programming .In other
words, it is a process of converting system requirements into program codes. Systems implementation is
the process of defining how the system should be built ensuring that the systemic operational and used,
ensuring that the system meets quality standard. In computer science and information technology
department, this is the important stage of any system.

In this chapter, I described my system development plan according to Waterfall Model and also
described each step of the model. And describe about what type of platform I used? And Why?

4.2 Development plan:

The Development plan is planned according to development methodology which is Water fall
model.

Figure 14 waterfall mothed

4.2.1 Sequential Phases in Waterfall Model

 Requirements Analysis
 Design
 Implementation
  Testing
 Deployment
 Maintenance

Requirements

The first phase involves understanding what need to be design and what is its function, purpose etc. Here,
the specifications of the input and output or the final product are studied and marked.

Design

The requirement specifications from first phase are studied in this phase and system design is prepared.
System Design helps in specifying hardware and system requirements and also helps in defining overall
system architecture. The software code to be written in the next stage is created now.

Implementation

With inputs from system design, the system is first developed in small programs called units, which are
integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as
Unit Testing.

Testing

All the units developed in the implementation phase are integrated into a system after testing of each unit.
The software designed, needs to go through constant software testing to find out if there are any flaw or
errors. Testing is done so that the client does not face any problem after shifting system to live server.

Deployment

Once the functional and non-functional testing is done, the product is deployed on virtual machine.

Maintenance

This step occurs after installation, and involves making modifications to the system or an individual
component to alter attributes or improve performance. These modifications arise either due to change
requests initiated by the customer, or defects uncovered during live use of the system. Client is provided
with regular maintenance and support for the developed software.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like
a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved
for previous phase and it is signed off, so the name “Waterfall Model”.
4.3 Development of program

The primary objective of development are to translate the most promising design approach unto a stable ,
interoperable, produce able and cost effective design ,validate the manufacturing and production process
and demonstrate system capabilities through testing

This phase also puts in place the hardware, software and communication environment of the overall system.
At the end of development the system will be ready for activities of integration and testing

4.4 System Tool Selection:

4.4.1 Hardware

The Quick Complaint Portal is independent from the physical hardware meaning it only
manages the Portal hardware that is put in place. The hardware platform this software requires to
run on must have a web server with PHP enabled. The database, MySQL, can be installed on a
machine of its own or the same machine as the web server any webserver with following
specifications at
Least.

Storage RAM Bandwidth

2GB 2GB 10GB

Operating system
We have chosen Windows operating system for its best support and user-friendliness.
4.4.2 Software

Web application using a software sublime text3 or any environment like support all
Windows (Windows 7, 8.1 and 10) and operating System, and also XAMPP is a free and open-
source cross-platform web server solution stack package developed by Apache Friends, consisting
mainly of the Apache HTTP Server, MariaDB database, and interpreters for scripts written in the
PHP and Perl programming languages. Android Studio Create a user application and also used
XAMPP software used in store MYSQL Database.
4.4.3 Communications Interfaces

This system use communication resources which includes but not limited to, HTTP
protocol for communication with the web browser and web server and TCP/IP network protocol
with HTTP protocol. This application will communicate with the database that holds all the
booking information. Users can contact with server side through HTTP protocol by means of a
function that is called HTTP Service. This function allows the application to use the data retrieved
by server to fulfill the request fired by the user.

The proposed methodology for implementing the GUI Subsystem is PHP. This technology uses
Server side, Bootstrap for the actual user interface with a server-side scripted back-end. The
combination of the front-end and back-end allows for a near seamless user interface experience.
The overall goal is to present a more standard application feel versus the typical page loading of
traditional web applications.
CHAPTER 05

Deployment
5.1 Deployment of a system:

Deployment is the process of running software client / user Software. Software is tested on the behalf of
different parameters. How system is responding. In this phase, we will try to validate our newly build
system.

5.2 Testing of a system:

System Testing is a level of the software testing where complete and integrated software is tested. The
purpose of this test is to evaluate the system's compliance with the specified requirements. The process
of testing an integrated system to verify that it meets specified.

5.2.1 Purpose of testing:

Testing verifies that the system meets the different requirements including, functional, performance,
reliability, security, usability and so on. While finding defects / bugs is one of the purposes of software
testing, it is not the sole purpose.

5.2.1.1 Unit Testing

Unit testing is a software development process in which the smallest testable parts of an application, called
units, are individually and independently scrutinized for proper operation. Unit testing can be done
manually but is often automated.

5.2.1.2 Integration Testing

Integration testing is the phase in software testing in which individual software modules are combined and
tested as a group. It occurs after unit testing and before validation testing.

5.2.1.3 Acceptance Testing:

Acceptance testing, a testing technique performed to determine whether or not the software system has met
the requirement specifications. The main purpose of this test is to evaluate the system's compliance with
the business requirements and verify if it is has met the required criteria for delivery to end users.
5.3 Test cases:

A test case in a software engineering is a set of conditions under which a tester will determine whether
application or software system is working correctly or not. The mechanism for determining whether a
software or application has passed or failed such a test is known as a test oracle. It may take many test cases
to determine that a software system is considered sufficient securitized to be released. Test cases are often
referred to as test script, particularly when written. Test case are usually collected into test suits.

After deployment there is an important phases to test some of the important use cases these are known as
test case these all are given on next pages.

Identifier Authenticate administrator

Purpose Admin can login with his account
Priority High
Pre-conditions Email and Password given to administrator
Login Process completed successfully show welcome page to admin
Post-conditions
panel
Typical Course of Action
S# Actor Action System Response
1 Enter Correct Email to required field Email Validation
2 Enter Correct password Password validation
3 Click on ‘login’ button to continue User login and home page is display
Alternate Course of Action
S# Actor Action System Response
After Clicking on ‘Login’ button, if Error is display Please give all
1
required field is empty information
After Clicking on ‘Login’ button, if given Error is display ,this email have not
2
email does not exist account
After Clicking on ‘Login’ button, if Error is display ,please give correct
3
password does not match password

Change Password (Admin)

Identifier Change password (admin)

 Purpose Admin can change his password
Priority High
Pre-conditions Admin should be login
Post-conditions Change password process completed successfully
Typical Course of Action
S# Actor Action System Response
1 Enter old password Password Validation
2 Enter new password Password validation
3 Click on ‘Submit’ button to continue Password changed
4 Enter admin Email Email validation
Alternate Course of Action
S# Actor Action System Response
After Clicking on ‘Submit’ button, if Error is display Please give all
1
required field is empty information
After Clicking on ‘Submit’ button, if Error is display ,this password is not
2
given old password does not exist correct
After Clicking on ‘Submit’ button, if Error is display ,please give correct
3
password does not match password
Error is display ,please give correct
4 If new password length is not correct
password

Manage Complaints

Identifier Manage Complaints (admin)

Purpose Admin can Manage Complaints
Priority High
Pre-conditions Admin should be login
Post-conditions Admin can send Complaints different department
Typical Course of Action
S# Actor Action System Response
1 View Details Admin can view Complainant details
Admin can send complainant to different
2 Take action
department
 3 View User details Admin can view user details
4 Not process complaint Admin can view status
5 Process Complaint Admin can view Process complaint
6 Closed Complaint Admin can closed complaint
Alternate Course of Action
S# Actor Action System Response
After Clicking on ‘Submit’ button, view
1 Show Complainant details
user details
After Clicking on ‘Submit’ button, Take Admin should be send complaint into
2
action department
After Clicking on ‘Submit’ button, if
3 Error is display, this type is not correct.
department does not exist.

Categories and Sub Categories (Admin Module)

Identifier Add Categories and Sub Categories (admin)

Purpose Admin will add Categories or Sub Categories to system
Priority High
Pre-conditions Admin is login
Post-conditions Categories and Sub categories added successfully
Typical Course of Action
S# Actor Action System Response
After login admin click on “add Displayed form in which admin can add
1
Categories” Button categories
2 Enter Correct data into form Form validation
After that admin will fill the add Message is displayed that Categories
3
categories form and click on “Submit” added successfully
After login admin click on “add Sub Displayed form in which admin can add
4
Categories” Button Sub categories
5 Enter Correct data into form Form validation
After that admin will fill the add sub Message is displayed that sub categories
6
categories form and click on “Submit” added successfully
 Alternate Course of Action
S# Actor Action System Response
After login admin click on “Add
Message is display that please fill all
1 Categories” and if admin click on submit
fields first
button
After login admin click on “Add sub
Message is display that please fill all
2 Categories” and if admin click on submit
fields first
button

Edit and Delete categories or Sub categories (Admin Module)

Identifier Edit or Delete Categories and Sub Categories (admin)

Purpose Admin will edit and delete Categories or Sub Categories to system
Priority High
Pre-conditions Admin is login
Post-conditions Categories and Sub categories Edit or Delete successfully
Typical Course of Action
S# Actor Action System Response
After login admin click on “Edit Displayed form in which admin can Edit
1
Categories” Button categories
2 Enter Correct data into form Form validation
After that admin will fill the edit Message is displayed that Categories
3
categories form and click on “Submit” edit successfully
After login admin click on “edit Sub Displayed form in which admin can edit
4
Categories” Button Sub categories
5 Enter Correct data into form Form validation
After that admin will fill the edit sub Message is displayed that sub categories
6
categories form and click on “Submit” edit successfully
The Delete categories form and click on Message is displayed that categories
7
“Delete” deleted successfully
the delete sub categories form and click Message is displayed that sub categories
8
on “delete” deleted successfully
Alternate Course of Action
 S# Actor Action System Response
After login admin click on “edit Message is display that please fill all
1
Categories” fields first
After login admin click on “edit sub Message is display that please fill all
2
Categories” fields first

Add Department or View Feedback (Admin Module)

Identifier Add Department or view Feedback (admin)

Admin will add and delete, update Department or view Feedback
Purpose
to system
Priority High
Pre-conditions Admin is login
Post-conditions Department add, Edit, or Delete successfully or view Feedback
Typical Course of Action
S# Actor Action System Response
After login admin click on “add Displayed form in which admin can add
1
Department” Button Department
2 Enter Correct data into form Form validation
After that admin will fill the add Message is displayed that Department
3
department form and click on “Submit” add successfully
After login admin click on “edit Displayed form in which admin can edit
4
department” Button department
5 Enter Correct data into form Form validation
After that admin will fill the edit Message is displayed that department
6
department form and click on “Submit” edit successfully
The Delete Department form and click on Message is displayed that Department
7
“Delete” deleted successfully
the view Feedback form and click on
8 All show data that give a feedback user
“view nav Bar”
Alternate Course of Action
S# Actor Action System Response
After login admin click on “edit Message is display that please fill all
1
department” fields first
 After login admin click on “add Message is display that please fill all
2
department” fields first
User not feedback then message display
3 If view feedback nav bard click
User not give a feedback

Manage Users

Identifier Manage Users (admin)

Purpose Admin will Different Users add in module
Priority High
Pre-conditions Admin is login
Post-conditions Admin will add users successfully
Typical Course of Action
S# Actor Action System Response
After login admin click on “add Users” Displayed form in which admin can add
1
Navbar Department
2 Enter Correct data into form Form validation
After that admin will fill the add Users Message is displayed that Users add
3
form and click on “Submit” successfully
After that admin will fill the edit Users Message is displayed that users edit
4
form and click on “Submit” successfully
The Delete Users form and click on Message is displayed that Users deleted
5
“Delete” successfully
the add users form click on “add users ”
6 All show data that give a add user
nav bar
Alternate Course of Action
S# Actor Action System Response
Message is display that please fill all
1 After login admin click on “Add Users”
fields first
2 After login admin click on “Edit Users” All Data must be Filled

Admin Profile
 Identifier Admin Profile
Purpose Admin will Update Profile
Priority High
Pre-conditions Admin is login
Post-conditions Admin will Update profile successfully
Typical Course of Action
S# Actor Action System Response
After login admin click on “Picture” Displayed form in which admin can
1
Navbar Update Profile
2 Enter Correct data into form Form validation
admin will fill the Profile Field form and Message is displayed that Profile Update
3
click on “Submit” successfully
Alternate Course of Action
S# Actor Action System Response
Message is display that please fill all
1 admin click on “submit”
fields first

Logout (Admin)

Identifier Logout
Purpose Admin can be logout
Priority High
Pre-conditions Admin must be logged In.
Post-conditions Logout process completed successfully.
Typical Course of Action
S# Actor Action System Response
1 Admin click on logout link Logout successfully

Stakeholders Authenticate (Sub admin)

Identifier Authenticate sub admin

Purpose Sub Admin can login with his account
 Priority High
Pre-conditions Email and Password given to sub admin
Login Process completed successfully show welcome page to sub admin
Post-conditions
panel
Typical Course of Action
S# Actor Action System Response
1 Enter Correct Email to required field Email Validation
2 Enter Correct password Password validation
3 Click on ‘login’ button to continue User login and home page is display
Alternate Course of Action
S# Actor Action System Response
After Clicking on ‘Login’ button, if Error is display Please give all
1
required field is empty information
After Clicking on ‘Login’ button, if given Error is display ,this email have not
2
email does not exist account
After Clicking on ‘Login’ button, if Error is display ,please give correct
3
password does not match password

Stakeholder Change Password (Sub admin)

Identifier Change password (admin)

Purpose Sub Admin can change his password
Priority High
Pre-conditions Sub Admin should be login
Post-conditions Change password process completed successfully
Typical Course of Action
S# Actor Action System Response
1 Enter old password Password Validation
2 Enter new password Password validation
3 Click on ‘Submit’ button to continue Password changed
4 Enter admin Email Email validation
 Alternate Course of Action
S# Actor Action System Response
After Clicking on ‘Submit’ button, if Error is display Please give all
1
required field is empty information
After Clicking on ‘Submit’ button, if Error is display ,this password is not
2
given old password does not exist correct
After Clicking on ‘Submit’ button, if Error is display ,please give correct
3
password does not match password
Error is display ,please give correct
4 If new password length is not correct
password

Stakeholder Manage Complaints (Sub Admin)

Identifier Manage Complaints (sub admin)

Purpose Sub Admin can Manage Complaints or working on Complaints
Priority High
Pre-conditions Sub Admin should be login
Post-conditions Sub admin can process the complaint
Typical Course of Action
S# Actor Action System Response
Sub Admin can view Complainant
1 View Details
details
2 Take action Sub Admin can take action on complaint
3 View User details Sub Admin can view user details
4 Not process complaint Sub Admin can view status
5 Process Complaint Sub Admin can view Process complaint
6 Closed Complaint Sub Admin can closed complaint
Alternate Course of Action
S# Actor Action System Response
After Clicking on ‘Submit’ button, view
1 Show Complainant details
user details
Stakeholder Profile or view User Feedback (Sub Admin)

Identifier Sub Admin Profile and view feedback

Purpose Sub Admin will Update Profile or view Feedback
Priority High
Pre-conditions Sub Admin is login
Post-conditions Sub Admin will Update profile successfully or view feedback
Typical Course of Action
S# Actor Action System Response
After login sub admin click on “Picture” Displayed form in which admin can
1
Navbar Update Profile
2 Enter Correct data into form Form validation
Sub admin will fill the Profile Field form Message is displayed that Profile Update
3
and click on “Submit” successfully
the view Feedback form and click on
4 All show data that give a feedback user
“view nav Bar”
Alternate Course of Action
S# Actor Action System Response
Message is display that please fill all
1 Sub admin click on “submit”
fields first

Logout (sub Admin)

Identifier Logout
Purpose Sub Admin can be logout
Priority High
Pre-conditions Sub Admin must be logged In.
Post-conditions Logout process completed successfully.
Typical Course of Action
S# Actor Action System Response
1 Sub Admin click on logout link Logout successfully
5.4 Non-functional Requirements

1. Performance Requirements

 The performance of the whole system is directly dependent upon the mechanisms
that are used to automatically update the Database.
 It is an online application, so thousands of users will access the Server at once so
we have to use a Strong Server and a Modem that has maximum connections limit
and it is available even network is congested. It is also available at low band width.
 Browser compatibility is handles.
 System is flexible.
 Data recovery is high.
 Database wills response quickly
 Only text information is supported(HTTP)
 All the transactions is processed within seconds

2. Safety Requirements

 Online Project manager will not affect data stored outside of its servers nor will it
affect any other applications.
 Should be entered only correct data.
 Should be used only referred platform.
 Safety Requirements should be include the Database backup, any System Loss then
will recover all data.
 Android application Support on maximum versions.
 Report back to web application in case of app crash / exception error etc.

3. Security Requirements

 Only authorized users is able to access the website by entering the

 Correct login name and corresponding password.
 Deliverables data save with different names by using different techniques to
randomly names to avoid complexities.
 JavaScript checks are used in form validations
 Sql injection not applicable on deliverables
  Quick complaint Portal should be secure password by using hash function (Convert
password into SHA256, MD5 etc. instead of storing plain text)

5.5 Software Quality Attributes

The system provides a help and support menu in all interfaces for the user to interact with
the system. The user can use the system by reading help and support

a. Availability
The system should always be available for access at 24 hours, 7 days a week. Also
in the occurrence of any major system malfunctioning the system should be
available in 1 to 2 working days so that business process is not severely affected. It
is invoke whenever a new staff join the company.

b. Reliability
It means the extent to which program performs with required precision. The website
developed should be extremely reliable and secure so that information about any
questions etc.
c. Usability
The website should be user friendly and should require least effort to operate. The
web server used should provide services like session management to maintain
sessions in the application.
d. Flexibility

It is effort required to modify operational program. The whole website should be

made using independent modules so that any changes done in 1 module should
not affect the other one and new modules can be added easily to increase
functionality.
e. Maintainability

The website can be maintained in present or future. It is easy to incorporate new

requirements in the individual modules.
5.7 Future Work
This system is found tested and examined for its successful processing. Future change in the
environment or processing can be easily adopted by having simple change in coding. It is very
user friendly, cost effective, feature rich and it provides very high level of security. It protects the
unauthorized users. Moreover, the system coding is so well designed that new operations can be
easily incorporated without much modification. A facility to inform through SMS or Email on
landing of the consignment can be added in future.

5.8 Conclusion
The system has the benefits of easy access because it is be developed as a platform independent
web application, so the admin can maintain a proper contact with their users, which may be access
anywhere . All communications between the client/user and administrator has done through the
online, so this communication cost also be reduced. Complaints management software is used to
record resolve and respond to User complaints, requests as well as facilitate any other feedback.
 References

1. https://developer.android.com/studio
2. https://developer.android.com/studio/intro
3. https://www.coursera.org/specializations/android-app-development
4. https://www.google.com.pk/search?q=usecase+diagram&oq=usecase+diagram&sourceid
=chrome&ie=UTF-8https://msdn.microsoft.com/en-us/library/dd409432.aspx
5. https://en.wikipedia.org/wiki/System_sequence_diagram
6. https://en.wikipedia.org/wiki/Database_design
7. https://www.tutorialspoint.com/uml/index.htm
8. https://en.wikipedia.org/wiki/Database_schema
9. https://www.uml.org/