Trackify (Mehtab & Umer)

Final Project Report
TRACKIFY
Project Supervisor
Mr. Zaid Aslam
Submitted By
Mehtab Ahmed _ Roll # 307

Umer Khan Yousafzai _ Roll # 325
Department of Computer Science,

Rahim Yar Khan Campus
The Islamia University of Bahawalpur
CERTIFICATE
This is to certify that Mehtab Ahmed _ Roll #307 & Umer Khan Yousafzai _ Roll# 325 has worked
on and completed his Software Project at the Department of Computer Sciences, The Islamia
University of Bahawalpur (Rahim Yar Khan Campus) in partial fulfillment of the requirement for
the degree of BS in Computer Sciences under my guidance and supervision.
In our opinion, it is satisfactory and up to the mark and therefore fulfills the requirements of BS
in Computer Sciences.
Supervisor / Internal Examiner

Mr. Zahid Aslam
Lecturer,
Department of Computer Sciences
Rahim Yar Khan Campus
___________________
(Signature)
External Examiner/Subject Specialist

Dr. Waqar Aslam
Assistant Professor,
Department of Computer Sciences
___________________
(Signature)
Accepted By:
_____________
(For office use)
i
EXORDIUM
In the name of Allah, the Compassionate, the Merciful.
Praise be to Allah, Lord of Creation,

The Compassionate, the Merciful,
King of Judgment-day!
You alone we worship, and to You alone we pray for

help,
Guide us to the straight path
The path of those who You have favored,
Not of those who have incurred Your wrath,

Nor of those who have gone astray
ii
DEDICATION
I dedicate this project to God Almighty my creator, my strong pillar, my source of inspiration,
wisdom, knowledge, and understanding. He has been the source of my strength throughout
this program and on His wings only have I soared. I also want to dedicate this project to my
beloved parents. It’s only due to their prayers that we are at this stage and successfully
performing our duties. I also want to say thanks to my respected Sir Zahid Aslam because of
their efforts that I am at the last stage of my destination.
iii
ACKNOWLEDGEMENT
A person is not perfect in all the contexts of this life. He has a limited mind and minor thinking
approaches. It is the guidance from the almighty Allah that shows the man light in the darkness
and the person finds his way in the light. Without this helping light, the person is nothing but a
helpless creature. The same is the case with us, as we experience all these phenomena during
the completion of this project and have been successful in fulfilling this duty assigned to us only
because of the help of ALLAH. The teachings of the Holy Prophet Muhammad (PBUH) were also
the continuous source of guidance for me especially His order of getting knowledge and
fulfilling one’s duty honestly were the keys for motivation. We regard our self very lucky to
work under the kind supervision of Mr. Zahid Aslam whose consistent encouragement and
timely guidance enabled us to overcome the hindrances that come in our way during the
tenure of the project. And his selfless and tireless efforts for providing us all the facilities that
we needed.
iv
PREFACE
This Documentation has been prepared to make our clients and user of the application to
understand the application and use it and get the most out of it. Trackify— Bus tracking
application for The Islamia University of Bahawalpur will be used by the users to track the
location of the buses in real-time, so that they reach university on time. Especially for student
girls, and teachers, face a lot of difficulty. Trackify helps them to reach to the bus stop before
the arrival of the bus. Now with Trackify, you don’t have to wait for bus on the bus stop.
Instead, you can get the location on mobile from home. The Application is straightforward and
easy to use, with the user-friendly UI (user-interface) designed in keeping the end users in
mind. Trackify is in alpha stage of its development and therefore, we are only giving access to
only few users. In usage, you can face some crashes and errors before the final release.
v
PROJECT BRIEF
Project Name: Trackify
Organization: Islamia University of Bahawalpur RYK
Undertaken by: Mehtab Ahmed
Umer Khan Yousafzai
Supervised by: Mr. Zahid Aslam
Date of Start: 10th March, 2020
Date of Completion: 18th June, 2020
Computer Used: Intel(R) Core(TM) i7-6600U
Sources Languages: Dart
Tool Used: Android Studio
vi
Contents
CHAPTER NO.1........................................................................................................................................... 2
INTRODUCTION ...................................................................................................................................... 2
1. Introduction ....................................................................................................................................... 3
1.1. Purpose....................................................................................................................................... 3
1.2. Scope........................................................................................................................................... 3
1.3. Definitions, Acronyms, Abbreviation.................................................................................. 4
1.3.1. API ........................................................................................................................................ 4
1.3.2. Trackify ............................................................................................................................... 4
1.3.3. Flutter .................................................................................................................................. 4
1.3.4. Firebase .............................................................................................................................. 4
1.4. References ................................................................................................................................. 4
1.5. Overview ..................................................................................................................................... 4
CHAPTER NO.2 ......................................................................................................................................... 5
GENERAL DESCRIPTION ........................................................................................................................ 5
2. General Description......................................................................................................................... 6
2.1. Product Perspective ................................................................................................................ 6
2.2. Product Function ..................................................................................................................... 6
2.3. User Characteristics ................................................................................................................ 9
2.4. General Constraints ................................................................................................................ 9
2.5. Assumptions and Dependencies ......................................................................................... 9
CHAPTER NO.3 ....................................................................................................................................... 10
SECIFIC REQUIREMENTS ...................................................................................................................... 10
3. Specific Requirements.................................................................................................................. 11
3.1. External Interface Requirements ....................................................................................... 11
3.1.1. User Interface .................................................................................................................. 11
3.1.2. Hardware Interface......................................................................................................... 11
3.1.3. Software Interface .......................................................................................................... 11
3.2. Functional Requirements..................................................................................................... 12
3.2.1. User Sign Up ................................................................................................................... 12
3.2.2. User Login ........................................................................................................................ 13
3.2.3. User Edit Profile.............................................................................................................. 13
3.2.4. Add User Schedule ........................................................................................................ 14
vii
3.2.5. View Bus Route .............................................................................................................. 15
3.2.6. View Bus Schedule ........................................................................................................ 15
3.2.7. Schedule Notification .................................................................................................... 16
3.2.8. Admin Login .................................................................................................................... 17
3.2.9. Add Bus Schedule ......................................................................................................... 17
3.2.10. Add Bus Route ............................................................................................................ 18
3.2.11. Block users .................................................................................................................. 19
3.3. Use Cases ................................................................................................................................ 20
3.3.1. Use Case Diagram #1 .................................................................................................... 20
3.3.2. Use Case Diagram #2 .................................................................................................... 21
3.3.3. Use Case Diagram #3 .................................................................................................... 22
3.4. Classes / Objects ................................................................................................................... 22
3.4.1. User .................................................................................................................................... 22
3.4.2. Admin ................................................................................................................................ 23
3.4.3. Bus Schedule .................................................................................................................. 24
3.5. Non-Functional Requirements............................................................................................ 24
3.5.1. Performance .................................................................................................................... 24
3.5.2. Reliability .......................................................................................................................... 24
3.5.3. Availability ....................................................................................................................... 25
3.5.4. Security ............................................................................................................................. 25
3.5.5. Maintainability ................................................................................................................. 25
3.5.6. Portability ......................................................................................................................... 25
3.6. Design Constraints ................................................................................................................ 25
CHAPTER NO.4 ....................................................................................................................................... 26
ANALUSIS MODEL .................................................................................................................................. 26
4. Analysis Model ............................................................................................................................... 27
4.1. Sequence Diagram................................................................................................................. 27
4.2. Data Flow Diagram................................................................................................................. 29
4.3. State Transaction Diagram .................................................................................................. 30
CHAPTER NO.5 ....................................................................................................................................... 32
CHANGE MANAGEMENT PROCESS................................................................................................... 32
5. Change Management Process .................................................................................................... 33
5.1. A.1 Appendix 1: Background Study .................................................................................. 33
viii
5.2. A.2 Appendix 2: Data Dictionary ........................................................................................ 33
CHAPTER NO.6 ....................................................................................................................................... 35
INTRODUCTION .................................................................................................................................... 35
6. Introduction ..................................................................................................................................... 36
6.1. Purpose..................................................................................................................................... 36
6.2. Scope......................................................................................................................................... 36
6.3. Definitions, Acronyms, Abbreviation................................................................................ 36
6.3.1. API ...................................................................................................................................... 36
6.3.2. Trackify ............................................................................................................................. 36
6.3.3. Flutter ................................................................................................................................ 36
6.3.4. Firebase ............................................................................................................................ 37
6.4. References ............................................................................................................................... 37
6.5. Overview ................................................................................................................................... 37
CHAPTER NO.7 ....................................................................................................................................... 38
SYSTEM OVERVIEW ................................................................................................................................ 38
7. System Overview ........................................................................................................................... 39
7.1. Technologies Used ................................................................................................................ 39
7.2. Application Overview ............................................................................................................ 39
7.3. Design Language ................................................................................................................... 39
CHAPTER NO.8 ....................................................................................................................................... 40
SYSTEM ARCHITECTURE ...................................................................................................................... 40
8. System Architecture ...................................................................................................................... 41
8.1. Architectural Design ............................................................................................................. 41
8.2. Decomposition Descriptions .............................................................................................. 42
8.2.1. Sequence Diagrams ...................................................................................................... 42
8.2.2. Class Diagrams............................................................................................................... 50
8.2.3. State Transaction Diagram .......................................................................................... 52
8.2.4. Data Flow Diagram......................................................................................................... 54
8.3. Design Rationale .................................................................................................................... 55
CHAPTER NO.9 ....................................................................................................................................... 56
DATA DESIGN ......................................................................................................................................... 56
9. Data Design ..................................................................................................................................... 57
9.1. Data Description ..................................................................................................................... 57
ix
9.2. Data Dictionary ....................................................................................................................... 59
CHAPTER NO.10 ...................................................................................................................................... 61
HUMAN INTERFACE DESIGN .............................................................................................................. 61
10. Human Interface Design ........................................................................................................... 62
10.1. Overview of user interface ............................................................................................... 62
10.2. Screen objects and actions ............................................................................................. 62
10.2.1. Login Screen ............................................................................................................... 62
10.2.2. Dashboard Screen ..................................................................................................... 63
10.2.3. Adding Bus Route ...................................................................................................... 64
10.2.4. Adding Bus Route Schedule ................................................................................... 65
10.2.5. Established Bus Route ............................................................................................. 66
10.2.6. Delete Bus Route........................................................................................................ 67
CHAPTER NO.11 ....................................................................................................................................... 68
REQUIREMENT MATRIX ...................................................................................................................... 68
11. Requirement matrix ................................................................................................................... 69
x
SRS
The Islamia University of Bahawalpur 1

CHAPTER 1 INTRODUCTION
CHAPTER NO.1
INTRODUCTION

1. Introduction
Trackify is a software that is designed with the aim in mind to reduce problems like a schedule
change, Bus Arrival time, Delays. Students face a lot of problems relating to the Bus Schedule.
Students wait for the buses on the Bus Stops. It will reduce the waiting time of the students
and inform them of the exact time and location of the Bus. It will notify the Students with the
arrival time of the Bus. It integrates notification from the university to notify students about
any schedule change. When the bus route comes out from the University or enters in the
University it will notify the students. Students can check bus routes and their travel in real-
time. It informs the Students with the remaining time of the bus to reach on the stop through
notification or student check itself real-time on the Trackify Map. It helps the students to get
their bus without wasting their time and reach to its destination. So no more bus miss.
1.1. Purpose
Trackify ensures that students remain up to date with the bus schedules. It notifies the students
if there's any change in the bus route or schedule thus minimizing the problems like missing
point and reducing the time wastage. With this software students will be able to track their Bus
in real-time as we have incorporated a live tracking of bus on Map, updating students and other
people who will travel via university buses.
1.2. Scope
Trackify is aimed to provide a one-stop solution for all the passengers not only in university
but outside the university as well. Almost millions of passengers use buses and due to no
solution for tracking the buses in which they want to travel, the passengers remain in dark
about the timing of the buses. Sometimes due to some issue a student gets late for the point
and He/She don't know where's the bus has reached and such students and professionals who
come from different cities are affected the most due to the unknown conditions whether they
will reach on time or not. And in city university buses have their schedule.
Our software with the help of the latest Google technologies and APIs will not only track the
buses in real-time but will provide in-depth details to the students and professionals as well.

1.3. Definitions, Acronyms, Abbreviation

1.3.1. API
API stands for Application Program Interface. It is a computing interface that is used for
software components or a system, which allows a programmer to provide a solid solution
more rapidly. API is an intermediary between two software to interact with each other
1.3.2. Trackify
Trackify is the name of the software and this software is for Real-Time Bus Tracking
System.
1.3.3. Flutter
“Flutter is Google’s UI toolkit which is used for building beautiful, natively compiled
applications for mobile, web, and desktop from a single code base”.
1.3.4. Firebase
“Firebase gives you functionality like analytic, databases, messaging and crash reporting
so you can move quickly and focus on your users”.
1.4. References
• https://flutter.dev/
• https://firebase.google.com/
1.5. Overview
Further in this document we specify the functional requirements, specification,

characteristics and the proper implementation of this project. We discuss the general
description, specific requirements, analysis model and change management process in
detail.

CHAPTER 2 GENERAL DESCRIPTION
CHAPTER NO.2
GENERAL DESCRIPTION

2. General Description
In general description, we discuss only those requirements which are easy to understand and it
should be clear that it does not discuss the specific requirement.
2.1. Product Perspective
Trackify is for those people who face problems with the buses schedule on their routes. It
informs the students about the updated bus schedule and its route. If there is any delay or
change in the route then the students will be informed through the notifications. This software
helps the students to remain up to date with new schedules and routes of the buses. It only
needs to install this software on their smartphones or remain connected with the new updates.
For more reliability live tracking system also incorporates on the Map.
2.2. Product Function
It notifies the students with new updates in the bus schedule or routes. It provides the
live tracking of the buses on the Map. It updates the student when the bus comes in or
out of the University. It informs the students with the remaining time of the bus to reach
on its stop or to move from the University. Trackify minimizes the possibility of the
bus miss.
• User Functionality:
Sign-Up:
The user can sign-up which will trigger a function at the back-end, performing this
whole functionality and adding the user in the cloud database.
Login:
The user can log in to the system. By providing the valid credentials at the time of log
in.
Edit Profile:
The user will be able to edit his/her profile and view it and change it later.
User Schedule:

The user will be able to add/edit his/her schedule on the app. He/she will be able to
delete it as well.
Bus Schedule:
The user will be able to view the bus schedules.
Bus routes:
The user will be only able to view the bus routes, meaning that the user will be restricted
to the view of bus routes.
Notifications:
The user will be able to see and interact with the notifications from the application.
• Admin Functionality:
Login:
The admin will be able to use the login functionality of the application, by using the
valid credentials provided by the university.
Edit Profile:
The admin will be able to create/edit his/her profile.
Add bus schedule:
The admin will be able to add the bus schedules.
Edit Bus Schedule:
The admin will be able to edit the pre-added bus schedules and also able to delete them.
View the bus schedule:
The admin will be able to view the added bus schedules.
Add bus route:
The admin will be able to add the bus routes.
Edit Bus routes:
The admin will be given the power to edit and delete the created bus routes.
View Bus Routes:
The admin will be able to view the added bus routes.
Block Users:

The admin will be able to block, such users who have violated or misused applications
in any way or signed up with fake/invalid credentials.

2.3. User Characteristics
Administrator handle the project but User must be:

1. Able to use a smartphone.
2. User should have the basic knowledge about the usage of Android or IOS
application.
3. The user should be a University employee or Student.
2.4. General Constraints
General description that limit the developer to

1. Internet connectivity is a must for users to use our application.
2. Without the Internet, the application will only show the last synced location.
3. Real-time tracking is only available when the device is connected with the internet.
4. Google API is not free and only allows limited transactions.
2.5. Assumptions and Dependencies
• Assumptions
a) Availability of internet.
b) Users should be able to use a smartphone.
c) The user should've a Google account.
• Dependencies
a) GOOGLE APIs.
b) Cloud Fire store Database (cloud database).
c) Need of Flutter (framework).

CHAPTER 3 SPECIFIC REQUIREMENTS
CHAPTER NO.3
SECIFIC REQUIREMENTS

3. Specific Requirements
3.1. External Interface Requirements
In this section we discuss the software design through which users interact with the software.
The design and all the constraints which are used must be Correct, Complete and Consistent.
Here we define how the user will interact with the system and how the system interacts with
the user.
3.1.1. User Interface

Here we describe the interface which is provided by the system to the user and the user
will interact with the system. The user could perform the following functions:
1. Log in with the system.
2. See the schedule of the buses.
3. See the bus routes.
4. Track the bus with the Live Tracking Functionality of the system.
5. Receive the notifications for the system if any change in the bus schedule or route.
6. Make our schedule.
3.1.2. Hardware Interface

Here we describe the Hardware interfaces which incorporates our system to running
well. List of these hardware interfaces are:
1. Smartphone
2. This software runs on both Android or IOS devices.
3. Tracker on the bus.
4. GPS location of the user through there smartphone.
3.1.3. Software Interface

The list of software interfaces which help our system to run well are:
1. Operating System (Android and IOS).
2. Google APIs.
3. Flutter Framework
4. Permission from users to be able to use GPS and the internet.

3.2. Functional Requirements
In this section, we define all the functionality of the software, how will the user interact with the
software and how it will help the user to fulfill their needs. User sign-up, live tracking of buses,
notification facility, bus routes, and schedules and how all these things work are defined in this
section. There are two main actors in this software one is Admin and the second is User
(student/employee)
3.2.1. User Sign Up
Introduction
User Sign-up is necessary because this software is only for University students and
other employees of the university. Because this software aims university students
and faculty that is why user Sign-up is necessary. Only those users can sign up who
belongs to the university.
Input
This user sign-up is only for the students and employees of the university. The
inputs required from the user are Gmail ID, full name, gender, date of birth, contact
number, address, category(student/employee), if student, then their Registration
Number and if employee, then the Employee ID and at the end password is
required.
Processing
The system checks all the information given by the user and according to its
information system accepts or rejects its sign-up request.
Output
If the user has done its sign-up successfully then a confirmation email will be sent
to his/her email id and after that user will be able to log in and use the application.
Error Handling
If the user gives some wrong information or if his/her email id is not unique then
an error message is generated by the system.

3.2.2. User Login

Introduction
Users who successfully signed up can log in to the system. Without correct
credentials, no one can log in with the system. For logging in, the user must provide
his/her valid email and password which they gave at the time of sign-up.
Input
For Login, users only need email and password.
Processing
System process on the given email or password and check it with the database if it
matches then the system allows the user to Login in and use the software.
Output
If the email or password matches then the system directly moves the user to the
dashboard of the application and the user can use the system.
Error Handling
If email id or password doesn’t match with the database record then the system
won’t allow the user to login and will generate an error message.
3.2.3. User Edit Profile
Introduction
In this subsection, the user will update his/her profile. The data which he/she has
given during the sign-up; if he/she wants to edit something then they can use edit
functionality to edit the profile. Users cannot change his/her registration number
because it is issued by the university, so students cannot change them. Same as like
students, employees can also edit their information.
We will provide you the chance at registration time to see that you have entered the
valid credentials but later things like registration number can’t be changed but a
request can be made to the developer about changing the wrong registration
number. This applies to the employees as well.

Input
The attributes which are used at the time of sign up same attributes are used now.
But some extra attributes are also there in its profile, like users can upload its image,
give detail of its department or semester.
Processing
System process the information which user edit and when the user presses the
submit button system update its information and store it in the database.
Output
After processing the information, a notification show on the user screen that the
information has been updated successfully.
Error Handling
If the size of the image is too large or its format is not correct then the system will
display an error message.
3.2.4. Add User Schedule
Introduction
Users add their schedule according to its bus timing to reach the bus stop and the
system will notify him before reaching the bus to their stop. User add schedule and
tell the system that how before he/she want notification from the system.
Input
For adding the schedule user give some input to the system then the system will
notify according to their information. The input which is given by the user is its
stop name, bus route and time how before he/she gets the notification form the bus.
Processing
The system gets the information and store it, according to the user, the information
system will send the notification to the user that the bus will reach the stop in a few

minutes. The time at which the notification will be sent to the user will be
determined based on the information user has added into the schedule panel.
Output
A notification will send to the user that the bus will reach the stop in a few minutes.
Error Handling
If the user adds some schedule and due to network problem the schedule is not
added then the system will inform that his schedule is not added and in add schedule
panel users themselves see their schedule information.
3.2.5. View Bus Route
Introduction
Users see all the bus routes and the detail of the buses that which bus going to which
route.
Processing
When users want to see the bus routes and Live tracking of the buses, the system
will collect information on all the buses and show on the Map to the user with all
details.
Output
Users see the Live Tracking of all the buses on the Map with the bus and the driver
details who drive the bus and also the phone number of the driver.
Error Handling
If the internet connection is lost then the system show network error and the
system only show the last synced location of buses
3.2.6. View Bus Schedule
Introduction
User will see a page giving information about the schedule of the buses in which
the timing of each bus to its stop are defined. The user sees this information in View

Bus Schedule Panel where all the information of each bus with their routes, time to
reach on each stop, the driver who drives the bus everything is defined.
Processing
When the user wants to see the bus schedule then the system will check if there any
change in the schedule then the system will update the schedule.
Output
User see the updated schedule in the View Schedule Panel and the user also get
notification if any change in the schedule.
Error Handling
If the system does not update the schedule due to a network problem then the
system shows the date and time of the last update and gives notification of network
problem
3.2.7. Schedule Notification
Introduction
Notifications are generated by the system to update the user with any change in the
bus schedule, bus route, delays in bus service due to any emergency. Users will
remain up to date with all the information about the buses.
Processing
If any change in bus schedules or any other delays of bus or change in bus routes
then the system generates a message and sends it to all the users.
Output
Users will receive a notification from the system with new changes in the bus
schedule or routes.
Error Handling
Sometimes notifications are not delivered to the user because of network

problems. Then when the user will connect to the network, all notifications will
be sent to the user

3.2.8. Admin Login

Introduction
Admin did not use the system without Login. Login is necessary for everyone who
uses this software.
Input
Admin login their account with an Email ID or password.
Processing
The system checks the email or password with the database if it matches then the
system gives access to the admin to the system.
Output
If email and password match then the system displays a message to the admin that
he/she has successfully logged in with the system. Routing admin directly to the
dashboard.
Error Handling
If email or password does not match then, the system will display an error message
stating, “your email or password is not correct please enter correct email or
password.”
3.2.9. Add Bus Schedule

Introduction
In this panel, the admin will be given the functionality to add the buses and their
schedule. Each time a bus will be added or changed the panel on the client-side will
automatically receive these changes and automatically update the view and
information. In this way, the user will remain notified about any sudden changes in
the schedule.
Input:

Admin will have to give the following information to the system when adding a bus
schedule.
Time of departure from the university,
Time of arrival at different bus stops,
Name of driver,
Bus number,
Route,
Time of arrival back to the university
Processing
On the information given to the system, the system will validate the form and add
or reject the information. A point of notice is that admin will have to add all the
information otherwise the bus schedule won’t be added.
Output
Once the information has been added, all the users will be notified and the
information on the client-side will be updated automatically. Notifying users about
the latest updates.
Error Handling
If in any case, the information is wrong or not filled properly, the System validator
will notify the admin about the issues in the information he/she has provided the
system.
3.2.10. Add Bus Route

Introduction
After the bus schedule has been added or update, the system will route the admin
to another page where the user can either mark the map or write the names of the

places through which the bus will go. The bus routes can be edited later as well and
each information will be updated at the user side automatically.
Input
The admin will have to mark the map or will write the name of places through
which the bus will pass. The time arrival will be given as well. All the information
must provide or the system won’t proceed further.
Processing
Based on the information, the system will validate and proceed further, if the correct
admin will be notified. Otherwise, a message will be displayed.
Output
Once the information is successfully validated and accepted, the system will
automatically notify the users.
Error Handling
If there is an error in the information provided by the admin an error message will
be displayed.
3.2.11. Block users

Introduction:
In this section, If somehow our admin finds out any unauthorized personnel or
student, in any way not associated with the university, admin gets the ability to
block the user and take any necessary action according to university guidelines.
Processing:
If a user is found not associated with the university, an admin will click the block button
and the user will be blacklisted from the application, meaning he/she won’t receive any
information. This is necessary from the security point of view.
Output:

The user will be blocked.
Error Handling:
User can unblock if he/she has mistakenly blocked user
3.3. Use Cases
3.3.1. Use Case Diagram #1


3.4. Classes / Objects
The main classes and the functions used in this software are discussed here.
3.4.1. User
• Attributes
Full Name
Email

Password
Gender
Department
Semester
Date of Birth
Mobile Number
Address
University ID
• Functionality
View Schedule ()
View Route ()
Add Schedule ()
View Notification ()
3.4.2. Admin
• Attributes
Full Name
Email ID
Password
• Functionality
Add Schedule ()
Edit Schedule ()
View Schedule ()
Add Route ()

Edit Route ()
View Route ()
Add Driver ()
Delete Driver ()
Block User ()
3.4.3. Bus Schedule
• Attributes
Bus Number
Route Name
Stop Name
Stop Timing
Driver Name
Tracker Name
3.5. Non-Functional Requirements
Non-functional requirements are those which facilitate the functional requirements e.g
security, reliability, etc. These kinds of requirements are very important because these help
our software to perform well. We discuss some of them
3.5.1. Performance
The performance of the software depends upon the speed of the internet because this is an
Android and IOS application which runs on the internet. Without the internet it only
shows the last synced data, for new updates users must have the internet. If the user has a
good internet connection then the performance of the software is very good because the
software is built-in flutter and flutter is very fast and its response time is very low
3.5.2. Reliability
It must ensure that the software is reliable because it can run on all the smartphones with
both operating system Android or IOS

3.5.3. Availability
Its availability depends on the internet, if user have internet then the user can access it 24
hours. Users can see all the updates and the Live Tracking of the buses at any time and any
place.
3.5.4. Security
The security of the system is very important no one can change the schedule or routes of
the buses for this an authorization is applied, only admin can access these features other
users can only see the schedule and routes
3.5.5. Maintainability
Maintainability of the system must be easy, in the future if something needs to be changed
in the software then users cannot affect it.
3.5.6. Portability
In the future if the version of the operating system changes then the user will also access them
on that operating system.
3.6. Design Constraints
In this software we follow the design of the smartphones. It can run on all the smartphones
with both operating systems Android and IOS. The design of the software is according to the
design of smartphones, it cannot run on Laptops or any other devices.

CHAPTER 4 ANALYSIS MODEL
CHAPTER NO.4
ANALUSIS MODEL

4. Analysis Model
In this section we draw some analysis models to understand the flow of data and logic with the
help of specific requirements discussed previously in SRS.
4.1. Sequence Diagram
The sequence diagram is the interaction between different objects in sequence. The interaction
of different actors from the system and how the system responds to the user all this is discussed
in the sequence diagram. Here we show the sequence of the user requests and answer of the
system in his/her requests.
• Sequence Diagram for Sign-up

• Sequence Diagram for Login
• Sequence Diagram for Bus Schedule

4.2. Data Flow Diagram
• Level 0 DFD
• Level 1 DFD

4.3. State Transaction Diagram
• STD for Admin

• STD for User

CHAPTER 5 CHANGE MANAGEMENT PROCESS
CHAPTER NO.5
CHANGE MANAGEMENT PROCESS

CHAPTER 5 CHANGE MANAGEMENT PROCESS
5. Change Management Process

5.1. A.1 Appendix 1: Background Study
A lot of work has been done in history but this project specifically focuses on the local problem
of the University Transport. Students have to face difficulties while traveling through the
buses, Most of the time, due to traffic jam and issues like buses having technical issues get
behind the schedule and students, go back home due to which there’s a loss of their lectures,
Especially girls suffer the most because of this issue. We have tried to overcome these
problems through this software. we reduce this problem by tracking the buses in real-time,
by using our software students will be able to see where their bus is passing through and in this
way they can manage their tasks and reach on time at the bus stop.
5.2. A.2 Appendix 2: Data Dictionary
• Flutter: Flutter is a UI software development kit which is created by Google. It is used to

make multiple application which runs on multiple platforms like Android, IOS, Window,
Mac.
• Dart: Dart is a programming language and flutter uses dart. Dart was introduced by
Google.
• Android Studio: Android Studio is an integrated development environment and it is used
for developing the Android Application.
• ERD: ERD is an entity-relationship diagram that is used to understand entities and their
attributes.
• DFD: DFD is a data flow diagram that is used to understand the flow of data within the
software.
• STD: STD is a state transition diagram that is used to understand different states of the
software.

SDD

CHAPTER NO.6
INTRODUCTION

6. Introduction
The “System Document Design” or “SDD.” is a way to describe a system in detailed

graphical representation. In other words, the SDD is a blueprint for what’ve described in SRS
(“System Requirement Specification”). It comprises of two parts; In the first part we’re going
to describe the architectural design of the Trackify and in the second part we’ll discuss
everything about design in detail.
6.1. Purpose
The “System Document Design” or “SDD.” is a way to describe a system in detailed

graphical representation. In other words, the SDD is a blueprint for what’ve described in SRS
(“System Requirement Specification”). It comprises of two parts; In the first part we’re going
to describe the architectural design of the Trackify and in the second part we’ll discuss
everything about design in detail.
6.2. Scope
The aim and scope of this document is to provide a detailed design and implementation of the
System Requirement Specification. The Trackify system uses a comprehensive Google API
known as Google maps that will be used in Flutter to provide real-time tracking of the buses,
therefore, reducing the human errors. Everything mentioned in this document will be used
and implemented in the software.
6.3. Definitions, Acronyms, Abbreviation

6.3.1. API
API stands for Application Program Interface. It is a computing interface which is used
for software components or a system, which allows a programmer to provide a solid
solution more rapidly. API is an intermediary between two software to interact with each
other.
6.3.2. Trackify
Trackify is the name of the software and this software is for Real-Time Bus Tracking
System.
6.3.3. Flutter
“Flutter is Google’s UI toolkit which is used for building beautiful, natively compiled
applications for mobile, web, and desktop from a single code base”

6.3.4. Firebase
“Firebase gives you functionality like analytic, databases, messaging, and crash reporting so
you can move quickly and focus on your users”
6.4. References
• https://flutter.dev/
• https://firebase.google.com/
6.5. Overview
Further in this document, we specify the functional requirements, specifications,

characteristics, and the proper implementation of this project. We discuss the general
description, specific requirements, analysis model, and change management process in detail.

CHAPTER 7 SYSTEM OVERVIEW
CHAPTER NO.7
SYSTEM OVERVIEW

CHAPTER 7 SYSTEM OVERVIEW
7. System Overview
In this System Design Document, we will discuss in detail about the modules of Trackify. In
the “System Overview Section”, we will discuss in general about the application and give an
overview of how the application will work.In “System Architecture”
7.1. Technologies Used
The system is designed and coded with Flutter in Android Studio. We will be using Google’s
Online Database called Firebase for storing all the essential data. We will track our code
changes and store our code in the GitHub repository
7.2. Application Overview
This application aims to provide the system that enables all the students and teachers of the
university to track the location of the bus in real-time so that, students don’t have to wait for
the buses. The project is aimed to help students who come from outside the city to track the
location of the bus to reach on time. The application is simple to use; the user can sign in with
Google, then the user can easily start to track the buses and receive notifications about any
sudden change in the schedule.
7.3. Design Language
We’ve used UML for representing the project graphically.

CHAPTER 8 SYSTEM ARCITECTURE
CHAPTER NO.8
SYSTEM ARCHITECTURE

8. System Architecture
8.1. Architectural Design
In the diagram below (fig #1) We have explained the general deployment and functioning of
Trackify. We have planned Trackify in a way that it will be developed as a Single Client
Application (APK). It will be:
• Providing common services for Trackify Application.

• Able to work with Google’s Firebase to retrieve the information and updating it for the
client.
• Providing user ability to interact with the system.
Google’s backend services will be deployed which will be responsible for user interaction and the
response to the user request. These Firebase services will be responsible for the connection link
between the backend and the front-end and will be managing the whole CRUD system.
The Firebase Database will be responsible for containing all the information regarding applications
such as User information, Bus information, Route information.

8.2. Decomposition Descriptions

8.2.1. Sequence Diagrams
• Signup Component
Fig #1: Signup Component
• Login Component and Design
Fig 2: Login Handler Sequence Diagram


Trackify Application manages the connection between Google’s Firebase server and the
application for a signup, login, and logout using a firebase authentication library in Flutter
application.
Trackify Application manages the connection between Google’s Firebase server and the
application for a signup, login, and logout using a firebase authentication library in Flutter
application
For the operations, we have created the four classes which are named “Login, Logout,
Update and Register” handler. We’ve shown all these class figures. For the login operation,
the system will send the user’s name and password (in case of email & password)
authentication to the Firebase Database or if the user will use the Google’s Sign-In option
then only Gmail account will be sent to a database. The very same method will be used for
Signing up the account. The user name and password will be sent to the Server (Firebase

database) and in the case of Google Sign Up only the Gmail account will be added the rest
authentication will be handled by the Google API itself.
Class Diagram for Login and Logout Handler
To decrease the load on the mobile we’ve divided our work process into different threads and
each thread will run when needed. In the table(1.0), we have provided the names of the
threads and their work accordingly
Login Handler This thread is to run when a user tries to login or be logged.
Depending on the option chosen user will be taken to the
dashboard or back to the login screen if he isn’t logged
successfully.
Logout handler The logout thread will run as soon as the user tries to log out once
the logout button is pressed. The system will perform the
necessary operation and the application will end.
Register Handler The Register Handler will run when a user will try to sign up. It is
responsible for sending the user’s data to the server and after
verification user will be allowed to proceed further.
Update Handler Update handler thread is designated to run when the User will try
to update his/her Profile in our application.
Table 1.0

• Setting Class
Figure Sequence Diagram of Setting Manager

Class Diagram of Setting Manager
In Trackify, we will manage all of our settings and user settings in a set class which will be
managed by Setting Manager. Below are the attributes of the Setting class.
isSearchabilityPubliclyAvailable Will the user be able to search about the buses publicly?
isBusLeavingUniversity Whether the bus is leaving university or not?
isBusAriving Is the bus arriving at the designated station?
isBusStanding Is the bus standing somewhere in its travel?
isUserConnected Is the user connected to the internet or not?
isBusRouteChanged Has the bus changed its route or is on its current route?
Also used when University will notify about bus
schedule change
ScheduleUpdate Checks for any schedule if updated
NotifyScheduleUpdate If there’s any change is schedule Update the system will

notify the user about the change.
Table 1.1.1

• Bus, Admin, and User Components (Main Functionality Component)
Figure: Sequence Diagram for Bus, Admin and User Components
In Trackify we are going to handle each of the components as a separate entity. Here We are
going to describe each class in detail.
• User Component
The user class contains the private string to handle user name, University id, and personal details
such as a semester, id, date of birth, department, address, mobile number, etc. While the user will
be able to provide the following functions: As mentioned in the figure (Sequence Diagram)
• User will be able to view schedule: ViewSchedule();

• User will be able to view route: ViewRoute();

• User will be able to add new Schedule routine: AddSchedule();

• User will be able to interact with notification: ViewNotification();
• Admin Component
Sequence Diagram for Admin Component
The admin class is specifically designed for the admin who will manage the backend functions of
the application. Admin will need to provide his full name, Email ID, and password. The admin
will be able to perform the following functions. (as shown in the figure above)
• Admin will be able to add the Schedule, AddSchedule();

• Admin will be able to edit the Schedule, EditSchedule();

• Admin will be able to view the Schedule: ViewSchedule();

• Admin will be able to add the Bus Route, Add_Bus_Route();
• Admin will be able to edit the Bus Route, Edit_Bus_Route ();
• Admin will be able to view the Bus Route: View_Bus_Route();
• Admin will be able to add driver, Add_driver();
• Admin will be able to delete the driver: Del_driver();
• Admin will be able to block the user: blocker();
• Bus Schedule Component
The bus schedule class contains the properties of the bus schedule; the private strings such as “Bus
number”, “Route name” and Booleans “start timings, stop timing”.
• Bus Component
The bus class contains only three private strings to get the data of the bus e.g. “Bus number”,
“Bus route”, and “bus driver”.
8.2.2. Class Diagrams
User Bus Schedule Admin
Full Name Bus Number Full Name
University ID Route Name Email ID
Email Stop Name Password
Password Stop Timing Add Schedule()
Gender Edit Schedule()
Department VIew Schedule()
Add Route()
Semester
Edit Route()
DOB
Bus View Route()
Mobile Number
Bus Number Add Driver()
Address
Bus Route Delete Driver()
View Schedule()
Bus Driver Block User()
View Route()
Add Schedule()
View Notification()
Class Diagram of Trackify

Here in the class above we can see that we have four classes namely User, Admin, bus
schedule, and Bus class.
We’ll discuss a few things about each of them.
The user class is namely a model for them to handle the information from the database and
then populating the fields of the application. Here the datatypes which are discussed in detail
in chapter 4 are to fetch the data from the database and then populate the application.
In the admin class, we fetch the data from the database it acts as a model class. It is also
responsible for populating the fields of the application for the admin panel.
The bus class is responsible for the handling of the data regarding the bus. It contains the bus
number name, and the driver name and the route information.
The bus schedule class is responsible for keeping the track of the bus point stops and the
arrival point while it also holds the data about the bus and the bus driver.

8.2.3. State Transaction Diagram
• STD for Admin

• STD for User

8.2.4. Data Flow Diagram

• Level 0 data flow diagram
• Level 1 data flow diagram

8.3. Design Rationale
What we want is to create a beautiful and easy-to-use system that is available for everyone
everywhere. Especially for female students who have to travel a long way to the bus stop and then
they come to know that either the bus is scheduled out or has passed because the students got late.
We have developed this system in such a way that it isn’t so much storage hungry or data-hungry
meaning it is capable of running on old legacy Android OS (low-end) devices and new devices as
well. We also plan to release the application on iOS mobiles to cover both markets. We’ve use
RESTFUL API and Flutter so that it remain a cross-platform application and easily available to
the users. The reason we’ve used flutter is that it makes it easier to run natively without using any
other virtual machine such as in the case of JAVA and it is platform-independent. The flexibility
of Flutter made it possible for us to compile applications for different platforms.

CHAPTER 9 DATA DESIGN
CHAPTER NO.9
DATA DESIGN

9. Data Design
9.1. Data Description
• USER CLASS:
userFullName: The full name of the user as mentioned in the university Id card.
universityID: user’s university unique ID as in university.
user_email: The email of the user.
user_password: The password of the user
user_gender: The gender/sex of the user
user_DOB: The date of birth as mentioned in the national identity card.
userContact: The contact number of the user.
userAddress: The address of the user.
Semester: The semester user currently enrolled in.
Department: The department of the user.
• ADMIN CLASS:
adminFullName: Full name of the admin.
adminEmail: University Issued Email ID of the administrator.
adminPassword: Desired password of the administrator.
BUS CLASS:
BusNumber: The number of the bus usually issued by the govt e.g RNR323.
busRouteName: The bus route name is the name of the path/route that it will be traveling
to.
busDriver: The name of the bus driver.

• BUS SCHEDULE CLASS:
busNumber: The govt issued a bus number.
busRouteName: The name of the route it will be running on.
busStopName: The name of the bus stop.
busStopTiming: The arrival and departure time of the bus stop.
Relationship Model and Class Data Model.
Bus User
Bus Number Name
Bus Route University ID
Bus Driver Email

Admin
Password
Name
Gender
Email
Bus Schedule Department
Password
Bus Number Semester
Route Name DOB
Stop Name Mobile Number
Stop Timing Address
Route
Route Name
Route Time
Stop Name
Figure: ER Diagram for Trackify

9.2. Data Dictionary

1) User
Parameter Parameter Type
username: String
universityID: String
Email: String
Password: String
Department: String
Semester: Int
Date of Birth: DateTime
Address: String
Mobile Number: int
2) Admin

adminName: String
Email: String
Password: String
3) Bus Schedule


BusNumber: String
BusRoute String
Bus_Stop_Name: String
Bus_Stop_Time: Time
4) Bus

BusNumber: String
BusRoute String
Bus_Driver_Name: String

CHAPTER 10 HUMAN INTERFACE DESIGN
CHAPTER NO.10
HUMAN INTERFACE DESIGN

10. Human Interface Design
10.1. Overview of user interface

At the first running of the application, the user will be prompted to the Signup
screen from where there will be an option for the user to log in to the system via
GOOGLE sign in or using the traditional email and password signup. After which
the user will be taken to the profile screen where the user will be able to update
information such as semester and department and other personal information.
After that, the user will be able to see the dashboard. Where he/she can see the
current schedules of the buses on the real-time map
10.2. Screen objects and actions
10.2.1. Login Screen
The log in screen as shown above in the picture is the first screen that the user will be seeing

10.2.2. Dashboard Screen

10.2.3. Adding Bus Route
This figure indicates the adding bus route functionality on the administrator side

10.2.4. Adding Bus Route Schedule

10.2.5. Established Bus Route

10.2.6. Delete Bus Route

CHAPTER 11 REQUIREMENT MATRIX
CHAPTER NO.11
REQUIREMENT MATRIX

11. Requirement matrix
Here in the requirement matrix, we’re going to create and demonstrate briefly the use cases
that we have included in this document and that is going to be used in the application and are
used in the components.
“X” denotes that the use case has been used in the given component. The name of the use cases
their IDs and their usage in “X” is given below.
Use Case Name Use Case ID
Sign Up UC1
Login UC2
Edit Profile UC3
Add Bus Route UC4
Edit Bus Route UC5
View Bus Route UC6
Add Bus Schedule UC7
Edit Bus Schedule UC8
View Bus Schedule UC9
Add Drivers UC10
User Schedule UC11
Block User UC12

Use Signu Login/ Google

User Admin Bus Database
Cases p Logout Server
Compone Compon Compone Compone
From compo Compon Compone
nt ent nt nt
SRS nent ent nt
UC1 × × × ×
UC2 × × × × ×
UC3 × × × ×
UC4 × × × ×
UC5 × × × ×
UC6 × × × ×
UC7 × × ×
UC8 × × ×
UC9 × × ×
UC10 × × ×
UC11 × × ×
UC12 × × ×


Trackify (Mehtab & Umer)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Trackify (Mehtab & Umer)

Uploaded by

Copyright:

Available Formats

Final Project Report

Mehtab Ahmed _ Roll # 307

Department of Computer Science,

Supervisor / Internal Examiner

Department of Computer Sciences

Rahim Yar Khan Campus

The Islamia University of Bahawalpur

External Examiner/Subject Specialist

Department of Computer Sciences

The Islamia University of Bahawalpur

In the name of Allah, the Compassionate, the Merciful.

Praise be to Allah, Lord of Creation,

You alone we worship, and to You alone we pray for

The path of those who You have favored,

Not of those who have incurred Your wrath,

Project Name: Trackify

Organization: Islamia University of Bahawalpur RYK

Undertaken by: Mehtab Ahmed

Umer Khan Yousafzai

Supervised by: Mr. Zahid Aslam

Date of Start: 10th March, 2020

Date of Completion: 18th June, 2020

Computer Used: Intel(R) Core(TM) i7-6600U

Sources Languages: Dart

Tool Used: Android Studio

The Islamia University of Bahawalpur 1

The Islamia University of Bahawalpur 2

The Islamia University of Bahawalpur 3

1.3. Definitions, Acronyms, Abbreviation

Further in this document we specify the functional requirements, specification,

The Islamia University of Bahawalpur 4

The Islamia University of Bahawalpur 5

2.1. Product Perspective

2.2. Product Function

The Islamia University of Bahawalpur 6

The Islamia University of Bahawalpur 7

The Islamia University of Bahawalpur 8

2.3. User Characteristics

Administrator handle the project but User must be:

2.4. General Constraints

General description that limit the developer to

2.5. Assumptions and Dependencies

The Islamia University of Bahawalpur 9

The Islamia University of Bahawalpur 10

3.1.1. User Interface

3.1.2. Hardware Interface

3.1.3. Software Interface

The Islamia University of Bahawalpur 11

3.2. Functional Requirements

The Islamia University of Bahawalpur 12

3.2.2. User Login

For Login, users only need email and password.

The Islamia University of Bahawalpur 13

The Islamia University of Bahawalpur 14

The Islamia University of Bahawalpur 15

Sometimes notifications are not delivered to the user because of network

The Islamia University of Bahawalpur 16

3.2.8. Admin Login

Admin login their account with an Email ID or password.

3.2.9. Add Bus Schedule

The Islamia University of Bahawalpur 17

Time of departure from the university,