A Final Project Report On E-FUEL Engineering Thesis- Pokhara University

A Final Project Report on
E-FUEL
A Major Project
PRJ 400.5
SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR
THE DEGREE OF BACHELORS OF ENGINEERING IN COMPUTER ENGINEERING
AWARDED BY POKHARA UNIVERSITY
Submitted by:
Ankit Shrestha (10305)
Bishal Shrestha (10310)
Ojesh Rimal (10324)
Saurav Sharma (10338)
January 2015
Department of Computer and IT Engineering
NEPAL COLLEGE OF
INFORMATION TECHNOLOGY
Balkumari, Lalitpur, Nepal

A Final Project Report on
E-FUEL
A Major Project
SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR
THE DEGREE OF BACHELORS OF ENGINEERING IN COMPUTER ENGINEERING
AWARDED BY POKHARA UNIVERSITY
Submitted by:
Ojesh Rimal (10324)
Under Supervision of
Er. Prakash Paudel
January 2015
Department of Computer and IT Engineering
NEPAL COLLEGE OF
INFORMATION TECHNOLOGY
Balkumari, Lalitpur, Nepal

Declaration
I hereby declare that the Report of the Final year Project Work entitled
“E-FUEL” which is being submitted to the Nepal College Of Information
Technology, Pokhara University, in the partial fulfillment of the requirements
for the award of the Degree of Bachelor of Engineering in COMPUTER
ENGINEERING in the Department of Computer and IT Engineering, is a
bonafide report of the work carried out by us. The material contained in this
report has not been submitted to any University or Institution for the award of any
degree.
Name Signature
ANKIT SHRESTHA (10305)
BISHAL SHRESTHA (10310)
OJESH RIMAL (10324)
SAURAV SHARMA (10338)

Transmittal letter
January 25th
, 2015
Mrs. Resha Deo
Department of Computer and IT
NCIT, Balkumari,
Lalitpur.
Dear Madam,
In compliance with the fulfillment of the requirements we hereby
would like to present the report entitled E-FUEL, in accordance with your
instructions. This report includes all the details and the facts about the plans of the
project. The main purpose of the document is to give a comprehensive idea about
the development of an android app that helps provide genuine data of fuel stations
providing fuel nearby and schedule of load-shedding.
Thus we hope that you will thoroughly go through this report and will
respond to us for the better understanding among us for further works.
Sincerely,
Ankit Shrestha
Bishal Shrestha
Ojesh Rimal
Saurav Sharma
(B.E.C.E 8th semester)

COPYRIGHTS
The author has agreed that the library of Nepal College of Information
Technology may make this report freely available for the inspection. Moreover, the
author has agreed that permission for the extensive copying of this project report for the
scholarly purpose may be granted by the supervisor who supervised the project work
recorded herein or, in his absence the Head of Department wherein the project work was
done. It is understood that the recognition will be given to the author of the report and to
the department of Computer Engineering, NCIT in any use of the material of this project
report. Copying or publication or other use of this report for financial gain without
approval of author's written permission is prohibited. Request for the permission to copy
or to make any other use of the material in this report in whole or in part should be
addressed to:
Head of department
Department of Computer and IT engineering
NCIT
Balkumari
Lalitpur, Nepal

CERTIFICATE FROM THE SUPERVISOR
This is to certify that Mr. Ankit Shrestha (CE-10305), Mr. Bishal Shrestha
(CE-10310), Mr. Ojesh Rimal (CE -10324) and Mr. Saurav Sharma (CE-
10338) has successfully completed the final year project entitled as "E-
FUEL" for the partial fulfillment of completion of Degree of Bachelor of
Engineering in Computer Engineering (BECE) under the Pokhara
University, Nepal.
During the supervision, I have found the students to be hard working, skilled
and bonafide and ready with skills to undertake any professional work
related to their field of study.
………………………
Er. Prakash Paudel
Project Supervisor

CERTIFICATE
We hereby certify that the work which is being presented in the Bachelor Of
Engineering Major Project Report entitled “E-FUEL”, in partial fulfilment of the
requirements for the major project of the Bachelor Of Engineering (Computer
Engineering) and submitted to the Department of Computer & IT Engineering of Nepal
College Of Information Technology , Balkumari , Lalitpur is an authentic record of our
work carried out during a period from October 2014 to January 25, 2015 (8th semester)
under the supervision of Er. Prakash Paudel, Computer & IT Engineering
Department.
The matter presented in this Project Report has not been submitted by us for the
award of any other degree elsewhere
Submitted by:
ANKIT SHRESTHA (CE - 10305)
BISHAL SHRESTHA (CE - 10310)
OJESH RIMAL (CE - 10324)
SAURAV SHARMA (CE - 10338)
This is to certify that the above statement made by the students is correct to the best of my
knowledge.
------------------------
Supervisor
Er. Prakash Paudel
------------------------
Program Officer
Computer and IT Engineering
------------------------
Internal Examiner
------------------------
External Examiner

Table of Contents
Abstract........................................................................................................................................... i
Acknowledgement......................................................................................................................... ii
List of Figures............................................................................................................................... iii
List of Tables ................................................................................................................................ iv
Acronyms........................................................................................................................................v
1 Project overview.......................................................................................................................1
1.1 Introduction to E-fuel.................................................................................................................... 1
1.2 Project Scope and Application...................................................................................................... 2
1.3 Project Goal and Objective ........................................................................................................... 3
1.4 Motivation..................................................................................................................................... 4
1.5 Problem Statement........................................................................................................................ 4
1.5.1 Existing System...................................................................................................................... 4
1.5.2 Proposed Solution................................................................................................................. 5
1.5.3 Problem Solving Algorithm ................................................................................................... 5
1.6 Report Organization...................................................................................................................... 5
2 Literature Review ....................................................................................................................7
2.1 Background of existing Scenario.................................................................................................. 7
2.2 Related Works............................................................................................................................... 7
2.3 Related Algorithms....................................................................................................................... 8
2.4 Limitation of previous works........................................................................................................ 8
2.5 A brief Study about Android Studio ............................................................................................. 9
2.6 A brief Study about SQLite database.......................................................................................... 10
2.7 A brief Study about Android Device .......................................................................................... 10
3 Analysis...................................................................................................................................11
3.1 Risk Analysis .............................................................................................................................. 11
3.1.1 Risk Survey .......................................................................................................................... 11
3.1.2 Risk Table ............................................................................................................................ 12
3.2 Task Analysis.............................................................................................................................. 13
3.3 Feasibility study.......................................................................................................................... 14
3.3.1 Technical Feasibility ............................................................................................................ 14
3.3.2 Economic Feasibility............................................................................................................ 14
3.3.3 Behavioral Feasibility .......................................................................................................... 14
3.4 Requirement Analysis................................................................................................................. 14
3.4.1 Project Requirement........................................................................................................... 14
4 System Design.........................................................................................................................17
4.1 Block Diagram............................................................................................................................ 17
4.1.1 Simple Block Diagram ......................................................................................................... 17
4.1.2 Logical Block Diagram ......................................................................................................... 17
4.2 Data flow Diagram...................................................................................................................... 18
4.2.1 Control Flow Diagram ......................................................................................................... 18
4.2.2 Data flow diagram............................................................................................................... 18
4.3 Class Diagram............................................................................................................................. 19
4.3.1 Simple Class Diagram.......................................................................................................... 19
4.3.2 Class Collaboration Diagram............................................................................................... 20
4.4 System Sequence Diagram ......................................................................................................... 21

4.4.1 System Sequence Diagram for Petrol ................................................................................. 21
4.4.2 System Sequence Diagram for Electricity ........................................................................... 21
4.4.3 System Sequence Diagram for Login .................................................................................. 22
4.5 Use Case Diagram....................................................................................................................... 22
4.6 State transition Chart................................................................................................................... 23
4.6.1 State Transition chart for petrol ......................................................................................... 23
4.6.2 State Transition chart for electricity ................................................................................... 23
4.7 Gantt chart................................................................................................................................... 24
4.8 Budget......................................................................................................................................... 25
5 Methodology...........................................................................................................................26
5.1 Approach and Model.................................................................................................................. 26
5.2 Technologies that has been used................................................................................................. 27
5.2.1 Developers framework ....................................................................................................... 27
5.3 Team members & Roles.............................................................................................................. 28
6 System Overview....................................................................................................................29
6.1 Libraries used.............................................................................................................................. 29
6.2 System Architecture.................................................................................................................... 29
6.3 Block Diagram............................................................................................................................ 30
6.4 Flow Diagram ............................................................................................................................. 30
6.5 Class Diagram............................................................................................................................. 30
6.6 System Sequence Diagram ......................................................................................................... 30
6.7 Use case Diagram ....................................................................................................................... 30
6.8 State Transition Diagram ............................................................................................................ 30
7 Result and Discussion ............................................................................................................31
7.1 Result .......................................................................................................................................... 31
7.2 Analysis of result ........................................................................................................................ 31
7.3 Testing and evaluation................................................................................................................ 31
7.3.1 Database Testing................................................................................................................. 31
7.3.2 Unit Testing......................................................................................................................... 31
7.3.3 Assertion testing ................................................................................................................. 32
7.3.4 Test results.......................................................................................................................... 32
8 Conclusion and future works................................................................................................33
8.1 Conclusion .................................................................................................................................. 33
8.2 Limitation.................................................................................................................................... 33
8.3 Further works.............................................................................................................................. 34
Appendix A – Business Model
Appendix B – SRS of E-Fuel
Appendix C – Screen Shots
Appendix D - NOC List
Reference

i
Abstract
This paper gives the comprehensive idea about our project on android application for
engineering major project, entitled– “E-FUEL”. The main objective of our project is to
help the users find fuel pumps and that are supplying fuels in times of scarcity and to
aware users if distributors are providing petrol. This application can be used by general
users who do not own a vehicle as well to check the schedule of load shedding for their
home use as well.
This report discusses the degree completeness of our project that has been done till date.
This report also documents the analysis and research of our project during different
phases. In the existing load shedding section, we still have to work on adding additional
features in our application. We have added load shedding section targeting electric cars
(i.e. Reva e20 in context of Nepal), which has android enabled features with android
running hardware.
This application is still in developing phase, however partial features of the application
have already been developed and running. For the electricity section, has been table
according to NEA whereas in the fuel section we have create maps layout and list layout,
with database integration. We plan to give all users an option to rate upon a network
amongst all the users of the application can view the information updated by the
developers.
This progress report is concerned with a task to build fully functional android
application to provide information about the availability of the fuels and electricity. We
have discussed the methods in the titles below.
Keywords: Eclipse, JDK, SDK, ADT

ii
Acknowledgement
Our sincere gratitude to the teachers of the NCIT for providing us the
opportunity to work on the project entitled “E-FUEL”. We are also very
grateful to the Department of Computer and IT for providing suitable
environment.
We owe a debt of gratitude towards our supervisor Mr. Prakash Paudel, for
the guidance, encouragement and support through the period to go through
setting the title and objectives for our plan with providing us a suitable
environment to take initiative. He had shown the attitude and the substance
of a genius: he continually and persuasively conveyed a spirit of adventure in
regard to research and an excitement in regard to teaching. Without his
supervision and help this dissertation will not be possible
We would like to thank NOC Team, who welcomed us to give us the entire
list of fuel pump and also for encouraging us to work towards a new kind of
product.
Thank you to our Head of Department Mrs. Resha Deo, and friends for their
valuable suggestions for the betterment of the project, we highly appreciate
and are grateful.
During the course of our research, we have had the good fortune of
interacting with our project coordinator of NCIT Mr. Nitesh Rijal. We are
grateful to rest of the team for their support and help working with the idea
and development of the project.

iii
List of Figures
Figure 1: Task Analysis Diagram........................................................................................ i
Figure 2: Simple Block Diagram...................................................................................... 17
Figure 3: Block Diagram for petrol section .................................................................... 17
Figure 4: Context flow diagram ....................................................................................... 18
Figure 5: DFD level-1 ...................................................................................................... 18
Figure 6: DFD level-2 ...................................................................................................... 18
Figure 7: Class Diagram................................................................................................. 19
Figure 8: CRC.................................................................................................................. 20
Figure 9: Sequence Diagram for petrol........................................................................... 21
Figure 10: Sequence Diagram for Electricity ................................................................. 21
Figure 11: Sequence Diagram for login........................................................................... 22
Figure 12: Use case Diagram.......................................................................................... 22
Figure 14: State Transition Chart Electricity................................................................... 23
Figure 13: State transition chart for petrol ...................................................................... 23
Figure 15: Gantt chart...................................................................................................... 24
Figure 16: Spiral Model - Software Development life cycle (SDLC)............................... 26
Figure 17: System Architecture ........................................................................................ 29

iv
List of Tables
Table 1: Compatibility among Devices for portability...................................................... 2
Table 2: Software Version Update Table............................................................................ 3
Table 3: Risk Table........................................................................................................... 12
Table 4: Cost Estimation .................................................................................................. 25
Table 5: Team Member..................................................................................................... 28

v
Acronyms
NEA : Nepal Electricity Authority
FP : Function point
NOC : Nepal Oil Corporation
SDLC : Software Development Life Cycle
OS : Operating System
ICS : Ice Cream Sandwich
XML : Extensible Markup language
HTTP : Hyper Text Transfer Protocol
ADB : Android Debug Bridge
DDMS : Dalvik Debug Monitor Server
CRUD : Create Read Update Delete
GPS : Global Positioning System
SRS : Software Requirement Specification
TBD : To Be Determined
IDC : International Data Corporation
JSON : JavaScript Object Notation
API : Application Programming Interface
ADT : Android Developer Tools
JDT : Java Development Tools
RDBMS : Relational Database Management System
CDT : C/C++ Development Tooling
EMF : Eclipse Modeling Framework
GEF : Graphical Editing Framework
GPRS : General Package Radio Service

of 34
1 Project overview
1.1 Introduction to E-fuel
With the gradual enhancement of technology, everything has been
computerized. Computers now do things that were managed manually
before. Taking a step further, the data that were accessed locally, are now
distributed among a large set of users.
“E-Fuel” is an android application that facilitates the users a convenient way
to check the availability of fuels in times of scarcity. Since, the fuel scarcity
occurs only few times within a year, we fear of our app not being used. We
have also included the feature for electric cars by providing load shedding
schedule in our app. However, there exists many other load shedding apps
for our country, keeping that in mind we have planned to make a location
based application and few other extra features such as forum that enables the
users to post a thread and make the app useful electric car owners as well.
We researched about the problems that we are facing today locally. The fuel
scarcity has troubled many vehicle riders at different times at the year. This
android application will enable its user to view the status of the Fuel pump,
whether or not the fuel is being distributed in that particular pump. E-Fuel
will allow its users to manage their time and will make it easy for all to
access fuels. E-Fuel might be helpful to our people because:
 It will provide supply status about the fuel pump around present
location.
 It will allow users to find a common forum to discuss about petrol and
electricity.
 It will allow users to check all the list of available pumps in the area.
 It will broadcast the information updated by one authorized user of a
pump, being cited by other user; where the authorized user can be
reported on false update. We have also decided to allow all users to
post and start a new thread as a discussion in our forum.

of 34
The development has been completed using android studio and the
information that has to be retrieved and stored has been done using SQLite.
1.2 Project Scope and Application
At the completion of the overall project, we have forecasted the download of
our project by the users and help them reduce the stress of scarcity of petrol
and load shedding to some extent. We have estimated a time period of 4 to 5
weeks for finalizing of beta version. We will release a beta version,
gathering comments, feedbacks and we will attempt to release the full
version of the product after few life cycles. On the first version the
application will help the electric vehicles users as well as petrol fuel
vehicles to manage there.
Table 1: Compatibility among Devices for portability
As in today’s world, the then luxury of having a wireless mobile phone has
now become a daily necessity for people to develop in the society. Mobile
phone had helped people to communicate easily when first introduced.
Today the scope of web is slow and less if compared to the rising mobile
phone technology. The smart phones have replaced laptop for the use of
internet surfing to some extent. Seeing this we have the best chances of
penetrating the market with the development of application designed for
smart phones. The development and versions of our product has been shown
on next page along with the reason for version change.
Name Date Reason For Changes Version
Layout Modification 2014-1-10 The layout was made user 0.0.1
Mobile Phone Tablet pc Laptop
Size of monitor Small Moderate Large
Easiness to be carried Easy Moderate Easy
Flexibility for the
design of data entry
form
Low Moderate High
The dissemination in
people
High Low High

of 34
friendly with side navigator
option.
Background 2014-21-10 The background gradient
image was changed to high
level.
0.0.2
Simplified Version 2014-11-12 Changes to fit basic principles
without navigator and icons.
0.0.3
Electricity hardcode
And places API
2014-11-15 Schedule hard coded for
understanding of DB
Retrieved places from Google
places.
0.0.4
Pull from Database
schedule
2014-12-5 Created a DB and pulled table
into application layout.
0.0.5
Revised Database
design
2014-12-8 Created table more efficiently. 0.0.6
Revised Google
places
2014-12-10 Revised pumps and filtered in
hard code.
0.0.7
Created DB for
Places
2014-1-10 Entered pump stations along
with its coordinates in DB
0.0.8
Entered genuine data 2014-1-23 Entered few genuine gas
station’s data.
0.0.9
Login for Privileged
user
2014-1-24 Created a login activity 0.0.10
Table 2: Software Version Update Table
1.3 Project Goal and Objective
Our main objective is to build an app that will guide the vehicles owners
completely about load shedding and in times of fuel scarcity. Our
application will also include the location for both fuel and electricity section
which will be an additional feature. We aim to provide easy access for
information regarding petrol availability in times of scarcity.
The location based load shedding scheduling helps the owner know about
the availability of electricity of a specific location regardless of whether the
user possess the knowledge about the group specified by NEA in the
particular location. We plan to add give privilege to shops and fuel pump to
broadcast their load shedding status as well which will allow the user who
travels to different places and find electricity for electric vehicles, even in a
completely new area.

of 34
1.4 Motivation
Technologies have the potential to improve the lifestyles of people, and
these technologies can be terms as lavish technology that provide help and
facilities to improve human lifestyle. Though developed countries has
applications that facilitates them with comparing price of fuel between
different stations, Nepal still lacks behind and we struggle to find petrol and
electricity in times of need.
The motivation is to facilitate us and person using vehicles to use the app to
know the information about the petrol pump status and load shedding
schedule for vehicles to recharge. It may be a new application for computer
project.
As, our country is known to have maximum load shedding and scarcity of
petrol we had an opportunity to fill the gap for electric vehicle owners and
other vehicles. We are motivated to work on the project featuring fuels. We
wanted to make user friendly application that can help general citizen to get
information regarding the availability of the petrol and places to recharge
battery. Seeing the lack of software technology in field of Oil sector we
decided to make the “E-Fuel” app. Besides focusing only on petroleum run
vehicles, our concern went to scalability and durability of the application as
well. In our country there are many times when there is shortage of petrol
but that will not attract users all the time. Hence we added feature of load
shedding to help electric vehicle owners find plug-in places and schedule
there charging time.
1.5 Problem Statement
1.5.1 Existing System
The existing mobile applications related to load shedding are simple and to
the point; which should be the objective of the project. However, just seeing
the time of load shedding in the application, it might not be a help for our

of 34
electric vehicle users who might have to go to different places as they are
unknown to the group category of every location. Most users appreciate the
use of technology as it is helping us to be updated about the scheduled load
shedding time, by NEA; but still many things could be done to help them
regarding load shedding.
However, the system is different with our application, till date there exists
no application that notifies about the supply of fuel in times of scarcity
about when and where they are available.
1.5.2 Proposed Solution
The solution to aware the location of the group can be done with various
techniques. Our application will allow the users to view the time schedule as
well as find the group of specific locations.
The location and the group will at first be categorized according to the NEA
data, however later when the app will be widely downloaded by many users.
We plan to take permission to use their location and plot it in the
coordinates and categories the groups as they change it in the general
settings of the application.
1.5.3 Problem Solving Algorithm
The algorithm developed for this problem was to pull information using
APIs. The user gets an option to choose option among two, fuel and
electricity. Fuel section shows the list of petrol pumps that are providing
fuel at real time and electricity provides list of load shedding schedule
focusing for electric vehicle owners.
The logic is that we have a made a logical layer in the application that
restricts the general user to update information. The privileged user, i.e.
who has logged in will be allowed to update their particular pumps status
using a toggle button. Further development will be conducted with feature of
report false status of petrol pump and inform friends with SMS.
1.6 Report Organization
The rest of this report is organized as follows. Chapter 2 is literature review
of E-FUEL; we discuss the background of our Android Mobile Application,
and its related works. We introduce the limitations of existing similar works
and the studies that we performed to build this project. The topics of study
are about android studio, SQLite, Android Devices, and Android Emulator
that has been used.
Chapter 3, explains about the analysis that we had done before starting to
code the project. This analysis shows the risk involved, survey taken for the

of 34
project. We have also discussed the task analysis procedure. The section
also includes the feasibility study and shows table regarding why we focused
on mobile application. Concluding with the requirements that we had to take
care during the development phase and for further development.
In Chapter 4, we have diagrammatically explained about the system design
and architecture. This section also describes about the software budget
evaluation and the task duration that we had done. There are various
diagrams describing different state and algorithms of the project mainly
focusing on electric section of the project. However, we are working on
coding for petrol pump section as well.
Chapter 5 describes the model that we used to develop the program. It
briefly describes about the SDLC, technology used by us, and our roles as an
individual.
Chapter 6, it is the overview of the system we have developed and the
system used. This chapter explains the diagrams of the System design and
Architecture that has been showed in Chapter 4.
In Chapter 7, we have shown our findings that we collected of this project
till date. This chapter also explains about the two testing done during the
development cycle. In Chapter 8, we conclude the major project report and
sum all the success we gathered during the development phase of this
project.

of 34
2 Literature Review
2.1 Background of existing Scenario
The existing scenario in context of Nepal is that we often face fuel scarcity.
According to the NOC report, Nepal consumes more than 950,000 liters of
petroleum products and there has been times when it causes acute shortage
of petroleum products. In such times, the vehicle owners often face problem
in finding fuel and there is no remedy to help them. The information of
availability of fuel is only known through friends or by directly visiting the
petrol station and seeing if they are distributing petrol.
In case of electric cars, though it is not used as petroleum vehicles, it does
exist. Today, Nepal imports Mahindra Reva (i.e. electric car) which has
android display inbuilt with various features. However, the craze for the
electric car is low as Nepal lacks behind in electricity supply.
2.2 Related Works
The existing applications provide the nearby petrol stations which makes us
easy to find our nearby Petrol Station. Just what we need if we are low on
fuel.
The maximum apps that have been developed do not need any login
procedure because the users are allowed to view petrol pumps only.
The features that have been provided by existing apps are:-
 Quickly find nearby petrol station, gas stations or petrol pumps near
us.
 It locates petrol pump worldwide.
 It locates our phone with GPS also works without GPS and then
provides you with the top local searches sorted by minimum distance
nearby so you can find where you need to go.

of 34
 It will provide contact details, address, distance, website and location
of each place and overall user rating for their service.
 We also can write review for the particular petrol station in few
applications.
 We can get directions with Map with estimated time and distance.
2.3 Related Algorithms
The algorithm used by these applications might be justifiable in their native
country as the maximum available applications displays the petrol pumps
and their contact number, but not the status whether or not there is fuel
available. The application is not feasible to country like Nepal, since, we
have petrol pump but due to petroleum product crisis or load shedding we
cannot find fuel.
The algorithm of the existing app is:
 Open application
 Find nearby petrol station, gas stations or petrol pumps nearby.
 Use different Google API from its console.
 View the minimum distance, contact details, address, distance, website and
location of each place and overall user rating for their service
 Get directions with Map with estimated time and distance.
 Head towards the nearest pump to refuel your car.
2.4 Limitation of previous works
The applications that currently are available in the app store are generally
developed to search and contact the petrol pumps. Generally, these
applications with the help of Google API list places, distance, remind and
display maps. However the application as those are focused to provide
overall service worldwide making them unaware of genuine petrol stations
that exists and those that have already been shut down.

of 34
In terms of electricity, there exists an application that shows schedule, these
applications are used for household purposes. However, the application does
not provide map service to the vehicle owners for them to recharge their car.
2.5 A brief Study about Android Studio
Android Studio is an integrated development environment (IDE) for
developing on the Android platform. It was announced on May 16, 2013 at
the Google I/O conference by Google's Product. Google's Android Studio
makes creating native Android apps very easy. Android Studio is freely
available under the Apache License 2.0. Android Studio was in early access
preview stage starting from version 0.1 in May 2013. The beta version was
released from version 0.8 which was released in June 2014. The first stable
build was released in December 2014, starting from version 1.0. Based on
JetBrains' IntelliJ IDEA software, the Studio is designed specifically for
Android development. It is available on platforms such as Windows, Mac
OS X and Linux.
The key features include but not limit the followings:
 Flexible Gradle-based build system.
 Build variants and multiple apk file generation.
 Template-based wizards to create common Android designs and components.
 Rich layout editor with support for drag and drop theme editing.
 Lint tools to catch performance, usability, version compatibility, and other
problems.
 ProGuard and app-signing capabilities.
 Built-in support for Google Cloud Platform, making it easy to integrate Google
Cloud Messaging and App Engine
 Provision for beta releases and staged rollout.
 Android-specific refactoring and quick fixes.
 Live Layout: WYSIWYG (What You See Is What You Get) Editor.
 Live Coding - Real-time App Rendering.
 Developer Console: optimization tips, assistance for translation, referral
tracking, campaigning and promotions - Usage Metrics.
 Support for building Android Wear apps.

of 34
2.6 A brief Study about SQLite database
SQLite is a relational database management system. It implements C
programming library. It is not implemented as a separate process of the
android system instead as the part of the using application.
SQLite is Atomicity, Consistency, Isolation, and Durability implements
most of the SQL standard, using a dynamically and
weakly typed SQL syntax that does not guarantee the domain integrity.
SQLite is a popular choice as embedded database for local/client storage in
Android application software.
2.7 A brief Study about Android Device
Electronic device which uses android operation for the purpose of its
operation can be termed as an android device.
Android device may be categorized as follows:-
Android Phones: - Android phone includes the software suits provided by
operating system by default it includes Google's proprietary applications,
such as Maps, Calendar, Gmail, and a full HTML web browser. In October
2008, HTC released the HTC Dream, the first phone to use Android.
Android supports the execution of native applications and third-party apps
which are available via Google Play, as Android Market. By 2010, Android
became the best-selling smartphone platform.
Android Tablets: - At first Google primarily focused on smartphones and
restricted the App Market from non-phone devices. After 2011, Android was
reworked to include more tablet features. Android 3.0 (Honeycomb) and
later versions support larger screen sizes, mainly tablets, and have access to
the Google Play service. Android supports low-cost ARM systems. Vendors
such as Motorola and Lenovo deployed their tablets. Other vendors sell
customized Android tablets such as Nook and Kindle Fire, which are used to
consume mobile content and provide their own app store, rather than using
the larger Google Play system, thereby fragmenting the Android market.
Google introduced the Nexus 7 and Nexus 10 tablets in 2012.
Other Android device: - Other device such as watches, glasses, televisions
are some of the device which has implemented android operating. Android
wear is the modified version of android operating system used for these
types of devices.

of 34
3 Analysis
3.1 Risk Analysis
3.1.1 Risk Survey
a) Have top software and customer managers formally committed to support the
project?
Yes
b) Are end-users enthusiastically committed to the project and the
system/product to be built?
Yes
c) Are requirements fully understood by the software engineering team and
their customers?
Yes
d) Have customers been involved fully in the definition of requirements?
Yes
e) Do end-users have realistic expectations?
Yes
f) Is project scope stable?
No
g) Does the software engineering team have the right mix of skills?
No
h) Are project requirements stable?
No
i) Does the project team have experience with the technology to be
implemented?
No
j) Is the number of people on the project team adequate to do the job?
Yes
k) Do all customer/user constituencies agree on the importance of the project
and on the requirements for the system/product to be built?
Yes

of 34
3.1.2 Risk Table
RISK TABLE
Risks Category Probability Impact RMMM
Project is not complete PS 30% 1 0.3
Size estimate may be significantly
low
PS 60% 2 0.3
Larger Number of users than planned PS 20% 3 0.066
Less Reuse than planned PS 70% 2 0.35
End-User will not spend much time BU 80% 3 0.266
Registered and genuine data problem PS 90% 2 0.45
Shortage will improve with
technology
TE 10% 1 0.1
Lack of training on tools DE 50% 1 0.5
Inexperienced Developers ST 30% 2 0.15
Low development time frame DE 80% 1 0.8
Total Risk Factor 0.3
Impact Values:
Catastrophic 2- Critical
Marginal 4- Negligible
Table 3: Risk Table
Comment
There is 30% chance of catastrophic risk in developing this project and for
sustaining it without proper research and support.

of 34
3.2 Task Analysis
Figure 1: Task Analysis Diagram

of 34
3.3 Feasibility study
3.3.1 Technical Feasibility
As our project has been developed in Android platform, we require an
android mobile or a similar device that runs on ICS (API 14) or more. Our
application is compatible for mobile phone only and not for android TV or
watch. We have a total of around 10% of smart phone that runs on android
in Nepal. (i.e. 100,000 cell phone) and around 80% of it runs on android
version ICS (API 14) or more.
3.3.2 Economic Feasibility
Economically Nepal is a under developed country and people here tend to
save money for retire plan and not for luxury. However, as android phone in
Nepal and other country are becoming available at lower price. One can
easily afford an android phone in around NRS 10,000 (i.e. 100 dollar).
3.3.3 Behavioral Feasibility
Once the application is fully complete, the scarcity will be perfect period for
us to release a beta version and check how to handle traffic. The scarcity of
petrol will be an opportunity for us to survey the petrol pumps if they will
respond with the application properly. Assuming done so, the application
will be widely used; at least among 10,000 people within the valley per
month. Assuming that traffic is handled well for the database. The
application can generate revenue for sustaining itself with good support and
regular Version updates.
3.4 Requirement Analysis
3.4.1 Project Requirement
3.4.1.1 Technical Requirements
 Android operating system version 2.3 or higher
 Access to the android market. (Google play )
 20MB of free memory on the device for installation
 GPS to view locations on maps.
 1GB memory Space on Internal Storage system or in a micro SD card.

of 34
3.4.1.2 Software Requirements
 The software requirements to run our application is android version must at least
be higher than ICS (API 14)
 Must support Google Play services
 Must have play store for application to be downloaded.
3.4.1.3 Non Function requirements
3.4.1.3.1 Performance Requirements
The product must be permitted to use the services such as internet services,
GPS services and memory management services for the app to perform well.
If failed to do so, the app will provide old information that had been there as
either default information or as the information that had been updated when
the app was last connected to the internet. The performance will also be
depending on the RAM and processing capability of the mobile phone.
3.4.1.3.2 Safety Requirements
The product can be used to violate any information related to gas stations or
change the information of any class thus causing a malfunction in the
broadcasting of the information and tempering with the usual scenarios of
the product. Thus a good monitoring of the user id and password is needed
for authentic login.
3.4.1.3.2.1 Security Requirements
The access to the database should be committed by the administrator and
reviewed by other users as well. The unauthorized access of any other user
than the administrator is to be controlled. The database should be restricted
to the authorized user only and should be used to view the necessary
information only. The password should be regularly regulated and changed
in a matter of months to guarantee security of the product. The login for
verification of user can be done by using login with different social
networking sites, by using their freely available API.
3.4.1.3.3 Software Quality Attributes
The software quality attributes of the product are:

of 34
1. Flexibility: The product is flexible i.e. it can work on any platform (TBD).
2. Interoperability: The product is well equipped to maintain a relation between
the system and the managers.
3. Correctness: The product is designed to deliver genuine data at the real time
environment with trusted ratings (TBD).
4. Availability: The project will be available to any user that is in a reach of
internet connection and has android mobile running on ICS or higher.
5. Reliability: Since the system information will generated by privileged user
and reviewed by users with correct information the system will be very much
reliable.
6. Adaptability: The product is developed to be adaptive to its users and provide
the controls according to the users.
3.4.1.3.4 Business Rules
Our Mission is to provide information to the travelers and promote local
business. We can create ventures with the local Gas Station, Cyber Cafes,
and fuel related sectors. We have a vision of 3 years before we start up as a
complete product. Till then we will launch beta version of the product. If
Possible we would take data from the government agencies and exchange the
data as it helps to fight the scarcity of the fuel and load-shedding.
The revenue is to be generated through Google ad sense and other methods
of advertising like advertising in the ad space within the lists.

of 34
4 System Design
4.1 Block Diagram
4.1.1 Simple Block Diagram
4.1.2 Logical Block Diagram
Figure 3: Block Diagram for petrol section
Figure 2: Simple Block Diagram

of 34
4.2 Data flow Diagram
4.2.1 Control Flow Diagram
4.2.2 Data flow diagram
Figure 4: Context flow diagram
Figure 5: DFD level-1
Figure 6: DFD level-2

of 34
4.3 Class Diagram
4.3.1 Simple Class Diagram
Figure 7: Class Diagram

of 34
4.3.2 Class Collaboration Diagram
Figure 8: CRC

of 34
4.4 System Sequence Diagram
4.4.1 System Sequence Diagram for Petrol
4.4.2 System Sequence Diagram for Electricity
Figure 10: Sequence Diagram for Electricity
Figure 9: Sequence Diagram for petrol

of 34
4.4.3 System Sequence Diagram for Login
Figure 11: Sequence Diagram for login
4.5 Use Case Diagram
Figure 12: Use case Diagram

of 34
4.6 State transition Chart
4.6.1 State Transition chart for petrol
4.6.2 State Transition chart for electricity
Figure 14: State Transition Chart Electricity
Figure 13: State transition chart for petrol

of 34
4.7 Gantt chart
Figure 15: Gantt chart

of 34
4.8 Budget
The cost of the project is calculated using Function Point.
Table 4: Cost Estimation
Function Point (FP) = 1.17 * 75 = 29.75 where 1.17 = Complexity Factor
Assuming
 Estimated FP = 32
 Average Productivity = 8.5 FP/p-m (person-month)
 Labor rate = 1000 Rs/p-m
Then
 Estimated Effort = 32/8.5 = (3.764) = 7 p-m
 Cost per FP = 1000/8.5 = 118 Rs/FP
 Number of worked months = 2
 Project Cost = 1000 * 7 * 2= Rs. 14,000
The budget of the project has been around Rs. 14,000.
Info Domain
Optimist
ic
Likel
y
Pessimist
ic
Est.
Count
Weigh
t
Count
No. Of inputs 4 13 15 4 2 8
No. Of outputs 5 10 12 5 1 5
No Of inquiries 1 8 9 1 2 2
No. Of files 2 5 6 2 2 4
No. Of external
interface
4 2 3 4 2 8
Algorithms 5 5 5 5 1 5
Total
=
32

of 34
5 Methodology
5.1 Approach and Model
We have be of using (SDLC) as spiral model for the development of our
project. This technique helps us with high amount of risk analysis and helps
us to avoid these risks. Also our application is produced earlier in the life
cycle so that it is better evaluated not only by us but also the users so that
the bugs if any may be dealt with. The continuous communication between
the users and our team helps in identifying, estimating and monitoring
technical feasibility. Proof of concept will be developed before the actual
software product is produced.
First at the initial stage we analyzed the problems and researched about the
possibilities of the market and weakness of different apps available in the
market. Then we analyzed and ranked the different kinds of risk of working
on this project. The requirements has been collected by different person
from different location. Their problems has been kept into consideration and
we found that though we have risk from this building this project, we might
have chance to compete with other apps in the market. We have developed a
design of the software, and worked with the minimum backend
programming. We have integrated APIs and have designed the entire layout
required.
Figure 16: Spiral Model - Software Development life cycle (SDLC)

of 34
The list for the petrol pumps has been provided by NOC. Using Google
maps we retrieved information of the existing petrol pumps and verifying
with the help of with NOC’s list we have stored 144 places in database.
Using the location we believe that we will be able to give the users nearest
location where fuels are available.
5.2 Technologies that has been used
5.2.1 Developers framework
Various other technologies including software and other interfaces were
used to develop this application. Some of the technologies that were used to
build this application are described as below:
 Android Developer Tools: ADT includes Eclipse platform, JDT, CDT, EMF,
GEF, and WTP. All of which are copyrights of Eclipse contributors and others.
 Software Development Kit Tools: SDK Tools is a downloadable component
for the Android SDK. It includes the complete set of development and
debugging tools for the Android SDK. It is included with ADT Bundle. Using
the SDK manager, we can update latest version of SDK Tools.
 Emulator: Genymotion is an Android emulator which comprises a complete
set of sensors and features in order to interact with a virtual Android
environment. With Genymotion, we can test our Android applications on a
wide range of virtual devices for development, test and demonstration purposes.
Genymotion is fast, simple to install and powerful thanks to user-friendly
sensor widgets and interaction features. It is available for Windows, MacOSX
and Linux operating systems.
 SQLite: SQLite is a relational database management system. It implements C
programming library. It is not implemented as a separate process of the android
system instead as the part of the using application.

of 34
5.3 Team members & Roles
Title
Name Description
Tester Ankit Shrestha
Testing of user friendly design for layouts and
system.
Database handler Bishal Shrestha
Designing &Integration of SQLite db.
Analyst Ojesh Rimal
Designing of layouts
Activity programmer
Developer Saurav Sharma
Back end designing and developer of software
and data flow.
Table 5: Team Member

of 34
6 System Overview
6.1 Libraries used
- Google places Master
- Google Play Services and support libraries
6.2 System Architecture
Figure 17: System Architecture

of 34
6.3 Block Diagram
The block diagram shows the user and the server system. Figure 2 (i.e.
Simple Block Diagram) shows basic communication. The logical block
diagram explains the system in blocks. It shows how the mobile UI
communicates with web, API and database.
6.4 Flow Diagram
The flow diagram shows how the user application calls for a query and what
it does. The CFD shows basic rule. DFD from level 1 and 2 shows the
database and the role of privileged user to run the application efficiently.
6.5 Class Diagram
The Class diagram shows the class file that we have prepared while
developing the application along with its function and attributes. The class
diagram briefly describes how one class call another class and how it is
related to one another.
6.6 System Sequence Diagram
Similar to the class diagram, system sequence diagram show the method of
how the class inter communicate. The attribute and functions can be seen in
this diagram.
6.7 Use case Diagram
The design and architecture of the E-Fuel app. The figure below shows a
Use case diagram of the E-Fuel app. It shows what an actor can do within a
system and how the system works.
6.8 State Transition Diagram
The state transition diagram shows the various states of the program.

of 34
7 Result and Discussion
7.1 Result
We have used various android devices of different sizes to see our design if
it is feasible and user friendly or not. Portrait mode will be set as default to
maintain the quality, the landscape mode has been disabled. With the use of
android studio we could learn more easily and in less time.
The application communicates with the users to list the petrol pumps nearby,
and display the pump that has been verified according to the list provided by
NOC. Our application has a wide scope in the market to fill the gap.
7.2 Analysis of result
The outputs were tested in the development phases, the result was achieved
like electricity schedule from the database and names of petrol pump that
has been stored in the database as well. However the map section has not
been documented since it is still under development.
7.3 Testing and evaluation
The focus of our test strategy was primarily functional and end to end
testing due to project life cycle. The Android SDK provides a set of
integrated development and testing tools that include a built in emulator,
debugger and device drivers that allow running application on android
phone. The emulator was used extensively in the testing phase. Since
Google’s maps API didn't support in emulator, we used mobile devices to
check GPS support as well.
7.3.1 Database Testing
E-Fuel uses Database for storing username, passwords, list of petrol pumps,
and their fuel status, it also has load shedding schedule in the database.
We used the built in android debug bridge tool to test the basic CRUD
(Create, Read, Update, Delete).
7.3.2 Unit Testing
We preformed Junit testing with the help of templates provided in junit.org
and GitHub. We performed unit testing in supporting classes in our package,
which were designed to provide re-useable functionality.

of 34
7.3.3 Assertion testing
The outputs that we received in Junit were verified when the test case also
passed assertion testing. Both unit test and assertion testing has been
successful in present application developed. However, there are still lots of
functions to complete the planned project as a proper outcome.
7.3.4 Test results
The testing gave us a good insight into our application. It helped us to
resolve many faults and errors, also fixing some bugs along the ways. The
testing methods have helped us to make the software more of a complete
package. The application is set to the quality expected. The results of the
testing were:
 A good validation function and a certified content.
 Individual functions capable of quality response.

of 34
8 Conclusion and future works
8.1 Conclusion
This report paper gives the comprehensive idea about our on android
application for engineering major project, entitled– “E-FUEL”. The
objective of our project is to help the users find fuel pumps and that are
supplying fuels in times of scarcity. This report discusses our research of
problems faced by users of existing load shedding apps, and we plan to help
them by adding additional features in our application.
At the completion of the project, we have forecasted the download of our
project by the users to small scale (i.e. up to 100 users) as it will help them
reduce the stress of scarcity of petrol and load shedding to some extent. We
have still left with completion of Alpha version with a full time working
period of 4 to 5 weeks for finalizing and entering beta version.
Our application will allow the users to view the load shedding time schedule
as well as find the group of specific locations so that they can charge their
vehicle. It will allow users to manage their time and will make it easy for all
to access fuels in times of scarcity. It will provide supply status about the
fuel pump around present location.
Our application has included the location for electricity section which will
be an additional feature. The location based load shedding scheduling helps
the user know about the availability of electricity of a specific location
regardless of whether the user possess the knowledge about the group
specified by NEA in the particular location.
8.2 Limitation
The limitation of our project, though we tried to complete the project by
2014, we had various technical problems as that has already been calculated
before development cycle begins. Hence due our project can be concluded
that it has only been finish around 30% and still is developing.

of 34
8.3 Further works
It broadcasts the information updated by one authorized user of a pump,
being cited by other users; where the authorized user can be reported on
false update.
We plan to add give privilege to shops and fuel pump to broadcast their load
shedding status as well which will allow the user who travels to find
electricity, even in a completely new area.

APPENDIX A - BUSINESS MODEL
1. What opportunity you’re tapping in?
Petrol Pumps: - The petrol pumps will use our application to broadcast their availability of
fuel in their pumps.
Users: - The users are constantly searching for fuel when there is load-shedding, scarcity
of petrol, we are trying to give them platform to show them the availability of fuel around
them.
(These are the client we are trying sell ads to and make money out of it. The rest model
will be provided with the final document)

Software Requirements Specification for Project on EFUEL Page i
APPENDIX B

Software Requirements Specification for Project on EFUEL Page ii
Software Requirements
Specification
for
E-FUEL
Version 0.0.3 - Alpha
Prepared by
Ojesh Rimal(10324)
Nepal College of Information Technology (BECE)
Date: 2014/12/14

Software Requirements Specification for Project on EFUEL Page iii
Table of Contents
Table of Contents......................................................................................................................... iii
Revision History......................................................................................................................... ivv
1. Introduction..............................................................................................................................1
1.1 Purpose............................................................................................................................................. 1
1.2 Document Conventions.................................................................................................................... 1
1.3 Intended Audience and Reading Suggestions.................................................................................. 1
1.4 Product Scope .................................................................................................................................. 1
1.5 References........................................................................................................................................ 2
2. Overall Description..................................................................................................................2
2.1 Product Perspective.......................................................................................................................... 2
2.2 Product Functions ............................................................................................................................ 2
2.3 User Classes and Characteristics ..................................................................................................... 3
2.4 Operating Environment.................................................................................................................... 3
2.5 Design and Implementation Constraints.......................................................................................... 3
2.6 User Documentation ........................................................................................................................ 3
2.7 Assumptions and Dependencies ...................................................................................................... 3
3. External Interface Requirements ...........................................................................................4
3.1 User Interfaces ................................................................................................................................. 4
3.2 Hardware Interfaces......................................................................................................................... 4
3.3 Software Interfaces .......................................................................................................................... 4
3.4 Communications Interfaces ............................................................................................................. 4
4. System Features .......................................................................................................................4
4.1 Anonymous rating by users ............................................................................................................. 5
4.2 Time decay factor on rating............................................................................................................. 5
4.3 SMS ................................................................................................................................................. 6
5. Other Nonfunctional Requirements.......................................................................................6
5.1 Performance Requirements.............................................................................................................. 6
5.2 Safety Requirements........................................................................................................................ 6
5.3 Security Requirements..................................................................................................................... 7
5.4 Software Quality Attributes ............................................................................................................. 7
5.5 Business Rules................................................................................................................................. 7
Appendix A: Glossary....................................................................................................................8
Appendix C: To Be Determined List..........................................................................................14
Contact Details ............................................................................................................................15

Software Requirements Specification for Project on EFUEL Page iv
Revision History
Name Date Reason For Changes Version
Layout Modification 2014-1-10 The layout was made user
friendly with side navigator
option.
0.0.1
Background 2014-21-10 The background gradient
image was changed to high
level.
0.0.2
Simplified Version 2014-11-12 Changes to fit basic
principles without navigator
and icons.
0.0.3
Electricity hardcode
And places API
2014-11-15 1. Schedule hard coded for
understanding of DB
2. Retrieved places from
google places.
0.0.4
Pull from Database
schedule
2014-12-5 Created a DB and pulled
table into application layout.
0.0.5
Revised Database
design
2014-12-8 Created table more
efficiently.
0.0.6
Revised google
places
2014-12-10 Revised pumps and filtered
in hard code.
0.0.7
Created DB for
Places
2014-1-10 Entered pump stations along
with its coordinates in DB
0.0.8
Entered genuine
data
2014-1-23 Entered few genuine gas
station’s data.
0.0.9
Login for Privileged
user
2014-1-24 Created a login activity 0.0.10

Software Requirements Specification for Project on EFUEL Page 1
1. Introduction
1.1 Purpose
The purpose of the SRS document is to provide the customer the information about the product
they are about to take in. In this SRS document we describe the ongoing progress on the project E-
FUEL. This SRS will define the necessary and important features of the application along with its
diagrams and other important definitions.
1.2 Document Conventions
The document conventions for the SRS are:
Headings: Bold Font size 18 with Font Arial
Sections: Bold Font size 14 with Font Arial
Sub-sections: Bold Font size 12 with Font Arial
Content: Font size 12 with Font Arial
Web links: Italic font size 11 with font Arial
1.3 Intended Audience and Reading Suggestions
The document is intended for developers, project managers, marketing staff, users, testers,
and documentation writers. The SRS contains the specifications and the features of the project, how
the project will interact with the user and how the user will get the response from the application. The
reader is suggested to go through the overall description section and know about the project
perspective and the main scope of the project. This shall give an idea to the reader about the features
of the application and the special features section of the document can be better understood.
The first Section 1, discusses about the paper’s introduction and what the project is
all about. Purpose, Document Conventions, Intended Audience and Reading Suggestions, Product
Scope, References.
The second section 2, contains overall description and basic data of the project,
where one can find Product Perspective, its functions, User Classes and Characteristics, Operating
Environment of the product, Design and Implementation Constraints, along with the assumptions
that we have made during this progress.
Similarly third section, are of external interface requirements, fourth being system features
and fifth other nonfunctional requirements.
This SRS also contain a section where the reader can fill up the form write to us or contact us
for further understanding of the project. Emails and phone numbers are available at the end of this
document.
1.4 Product Scope
The project aims to provide easy access to petrol even in times of scarcity and provide location
based load shedding information as well. The citizens facing problem to find a fuel station where there
is availability of the petrol and diesel. This will help the users to have an efficient view of the
availability of fuels and can be updated with the daily market supply. The Internet Cafes and Gas
Stations on the other hand can have a relief of customers not being aware of the scarcity and supply

of the either electricity or fuel with them, solving this problem it will help them to serve their customers
more efficiently and faster. (Refer to E-FUEL Midterm report Chapter for more details)
1.5 References
The references to the SRS document has been taken from
 Writing a software requirement document by Tanya Berezin,
Sections of requirements document (page 9 - 14)
 The reference has also been taken from,
http://www.cise.ufl.edu/~dgoldste/se/SRS.doc
 The reference has also been taken from,
http://www.frontiernet.net/~kwiegers/process_assets/srs_template.doc
2. Overall Description
2.1 Product Perspective
The project is a completely new kind to Nepal, the scarcity of fuel and electricity has not been
monitored by the public in a live feed. The existing system of knowing if a gas station is distributing
fuel is either by asking a friend or either looking by oneself.
The E-fuel app shall also replace the existing system of load-shedding apps of viewing the
lists of information only. The available load-shedding apps are still absent in making an app that
provides users with geographical information where users can view the gas stations and internet cafes
where the managers operates even in times of load-shedding.
This application shall provide a more efficient way of utilizing the technology at hand and
thus create an efficient way of getting the information.
2.2 Product Functions
 The product offers 2 ways to initialize the application by swiping on either sides. If a user
swipes left, the app teaches and guides them through the app as a tutorial, whereas swiping to
the right will allow start using the app.
 The product contains major 2 sections, a fuel finder and electricity finder.
 One of the major section is the Fuel finder. It will allow all the users to check the availability
of petrol and diesel. The app not only shows the list of Gas stations available near the user but
also the distance and availability of fuel in the pump. The user can switch either to the list view
or the maps view to find near fueling places.
 Another section is related to viewing load-shedding schedules that has been generated by the
NEA. This data is publicly available and is published by NEA itself, the application provides
the information in a list, whereas in the maps it lists the places around you that operates even
in times of load-shedding.

2.3 User Classes and Characteristics
The various user classes that will be using this product are general public, gas station, Cyber
Cafes, Restaurants and other users. The major target are the vehicle owners, as they are in search of a
fuel stations at times of scarcity. Then the data is intended to be taken from petrol pump owners, who
will further be reviewed by the users. The rating of the status is taken and further actions will be taken
in cases of fraud and false ratings. The privileged users are gas station managers. However, in case of
absence of gas station managers, the users rating will be considered as privileged users rating. The
rating made by the managers and users will be calculated into a scale and publicly broadcasted. The
user must not be highly educated to understand the basic principle of this app. The app is intended to
use Nepali and English language support through settings, so that everyone with basic knowledge can
use it in a friendly manner.
2.4 Operating Environment
This product is mobile-based application and will be later hosted in web services as well. This
product can be viewed by any android phone user, and has been built for compliance with Android
ICS. The Android phone must allow access to GPS, memory management and internet access enabled.
The product is OS independent and can run on any operating system higher than or equal to Android
ICS.
2.5 Design and Implementation Constraints
There are some memory requirement constraints. The memory is to be used for storage
of offline maps and data. Since our app plans to use maps, the app in order to function
properly, needs permissions of internet access, GPS and memory management. The users
might not accept these permissions and our app will not be able to function properly. So the
toasts were re-designed to make it seem more user friendly for the users to understand the
basic permissions needed by the app.
The app also lacks some logical integrity and consistency constraints that need to be
resolved. (TBD)
2.6 User Documentation
The sample user documentation of the product can be viewed as an example in section 3.1.
The final and full user documentation of the product will be given in the final report of the project.
The basic tutorial of using the app can be found with the first use of the app itself. (To view screenshots
see midterm report Appendix A)
2.7 Assumptions and Dependencies
For the product we have assumed that the users will input correct data and the gas station’s
manager will be honest. We have also assumed that during our beta phase, our users will remain under
1000 numbers since the third party APIs used in the app restricts the number of users only. We have
also assumed that the users will trust our app and help with the beta release, for further development
of the App. We also assume the data provided by the users and the rating done by the users to be
genuine.

3. External Interface Requirements
3.1 User Interfaces
The first user interface is the home page that will give multiple options to the user. For any
user the home page will provide a view of a button with a note saying swipe left to view tutorials, on
viewing these tutorials the users will be provided with the basic working principle of the app. The
users will also have option to go to main screen and continue by simply clicking at the apps logo on
the top left corner.
The users can then proceed on viewing both load shedding schedules and places of availability
of electricity or of the gas stations near them.
Privileged users will have the permission to enter the privilege controls through a successful
login through the setting from the side navigator. On access denial a prompt will be given to check the
username and password. The privileged users will have two options either yes or no. The activity will
give a live information about the data available or in case of no internet connectivity, the app will
broadcast the last received data by warning users.
(Details of the user interface design is documented in a midterm Report)
3.2 Hardware Interfaces
Though not necessarily interfacing with the extra hardware other than GPS, external memory,
the system must make use with an internet connection. The product is only made to be used with a
hardware specification of android mobiles of ICS or higher but not in other devices thus there is no
way of viewing the information in any browser or other devices.
3.3 Software Interfaces
Along with the internet connection, the system makes indirect use of an operating system
libraries. Needs permission to use GPS to view locations on maps, up to 1GB memory space on
Internal Storage or in external storage is needed where the offline maps can be saved as cache file.
Outside of the java code, the code doesn’t use any other languages. The xml are used to design the
interface layout and the user interface design whereas the JavaScript are the backend developing
languages, connecting the application to the SQLite server and acquiring the necessary logical
algorithms to make the product more efficient.
3.4 Communications Interfaces
As the application is hybrid system uses an internet connection to connect to the database and
download offline maps. The code itself though, does not specifically direct the network controllers to
do any work. The product uses HTTP to connect to the internet. The system has not been tested against
any encryption issues and other threats to the system to this point.
4. System Features
The app has the following features.

4.1 Anonymous Rating by users
4.1.1 Description and Priority
The users can rate anonymously on answer that has been posted by privileged users. The
anonymous rating ensures the safety and maintains confidentiality among the reviewers. This feature
is of high priority. The rating bar will be used to rate the truthfulness of the response, the rating will
be taken and averaged. The averaged data will be broadcasted over all. The benefit of making
anonymous rating is that the users can feel free to tell what they feel. The risk involved is if the users
posts random reviews to the post.
4.1.2 Stimulus/Response Sequences
The users will first see the post of either gas stations or the place of availability of the
electricity and rate in a bar with full rating of 5 star and low of none. The ratings will then be
calculated and updated in the database. The updated rating will then be published and broadcasted
when the place if reviewed next time.
4.1.3 Functional Requirements
The function requirements is the privacy of the users and encouragement for the users to
give genuine data. The data will be verified by other users as well therefore the false statements
and rating will automatically be pushed by the true state.
REQ-1: enter correct information in the review/ status bar.
REQ-2: insuring the users their security and privacy.
4.2 Time Decay Factor on Rating
The user’s anonymous rating are there for a day and then deleted on the next day since the
data must be real time data, as the users must be provided with genuine data, for example if a petrol
station says there is fuel not available but the next day early in the morning, if the tanker fills up the
station the app must show the availability of the fuel. Hence the negative status made in previous
day must be refreshed and the post of the privileged user must be used until the review made by the
general users. The benefit of making time decay factor on rating will help the users with nearly
accurate data even when no one has voted. The risk involved is if the users see the post of availability
and when reached to the station the fuel might be finished, so the time decay factor might be useful
if shortened.
The users will rate the status of the stations and the rating will be in the queue for finding
out the average rating for a day, and when the queue in full the FIFO principal is used to update
the data, if no data has been updated then the information provided by the gas stations will be
broadcasted.
The function requirements for this feature is the time decay factor must be set for such a
time that will be beneficial for all the users to get genuine real time data. The data will be verified
by other users as well therefore the false statements and rating will automatically be pushed by
the true state.

REQ-1: users enter correct information status bar and will be averaged.
REQ-2: insuring the user’s old status are deleted.
4.3 SMS
The users can send load-shedding SMS to a friend, the availability of the petrol also be
planned to be sent through SMS. The petrol pumps’ location will be included in the text. The benefit
of making SMS feature is that the user will find it easy to send SMS to friend easily. And the SMS
seen by a particular user will find more convenient to send to friends. The risk is not involved as the
SMS is to be send from the default SMS application present in the android phones.
The users will be aware of the availability of the fuel in their area, the SMS is then sent to
a friend or friends to make them aware about the availability of fuel in a particular station or
availability of electricity in certain area.
The function requirements for this feature is that the cost of the SMS to the users must be
covered by users themselves and the data will be sent without users interference after the click of
send button. The data will be written in the SMS and be pushed by the phone itself if the SMS is
unable to reach.
5. Other Nonfunctional Requirements
5.1 Performance Requirements
The product must be permitted to use the services such as internet services, GPS
services and memory management services for the app to perform well. If failed to do so, the
app will provide old information that had been there as either default information or as the
information that had been updated when the app was last connected to the internet. The
performance will also be depending on the RAM and processing capability of the mobile
phone.
5.2 Safety Requirements
The product can be used to violate any information related to gas stations or change
the information of any class thus causing a malfunction in the broadcasting of the information
and tempering with the usual scenarios of the product. Thus a good monitoring of the user id
and password is needed for authentic login.

5.3 Security Requirements
The access to the database should be committed by the administrator and reviewed by
other users as well. The unauthorized access of any other user than the administrator is to be
controlled. The database should be restricted to the authorized user only and should be used
to view the necessary information only. The password should be regularly regulated and
changed in a matter of months to guarantee security of the product. The login for verification
of user can be done by using login with different social networking sites, by using there freely
available API.
5.4 Software Quality Attributes
The software quality attributes of the product are:
1. Flexibility: The product is flexible can work on any platform (TBD).
2. Interoperability: The product is well equipped to maintain a relation between the
system and the managers.
3. Correctness: The product is designed to deliver genuine data at the real time
environment with trusted ratings (TBD).
4. Availability: The project will be available to any user that is in a reach of internet
connection and has android mobile running on ICS or higher.
5. Reliability: Since the system information will generated by privileged user and
reviewed by users with correct information the system will be very much reliable.
6. Adaptability: The product is developed to be adaptive to its users and provide the
controls according to the users.
5.5 Business Rules
Our Mission is to provide information to the travelers and promote local
business. We can create ventures with the local Gas Station, Cyber Cafes, and fuel related
sectors. We have a vision of 3 years before we start up as a complete product. Till then we
will launch beta version of the product. If Possible we would take data from the government
agencies and exchange the data as help to fight the scarcity of the fuel and load-shedding.
The revenue is to be generated through google ad sense and other methods of
advertising like advertising in the ad space within the lists.

Appendix A: Glossary
SRS = Software requirements specification
NEA = Nepal Electricity Authority
ICS = Ice Cream Sandwich
OS = Operating System
GPS = Global Positioning System
TBD = To be determined
XML = Extensible Markup language
HTTP = Hyper Text Transfer Protocol
SMS = Short Message Service
API = Application Program Interface

Appendix B: To Be Determined List
The list of TBD (To Be Determined):
1. To create maps
2. To work on any platform.
3. Algorithm with logical integrity to generate a consistent routine

Contact Details
Name: Ankit Shrestha
Roll No: 10305
Email: ankitshrestha@gmail.com
Phone: +9779803701420
Name: Bishal Shrestha
Roll No. 10310
Email: bishal061@gmail.com
Phone: +9779808719321
Name: Ojesh Rimal
Roll No: 10324
Email: ojeshrimal@gmail.com
Phone: +9779808658050
Name: Saurav Sharma
Roll No. 10338
Email: saurav2049@hotmail.com
Phone:- +9779841389805

REFERENCES
1. Global Positioning System. www.gps.gov
2. Wi-Fi.org. https://www.wi-fi.org
3. http://www.idc.com/tracker/showproductinfo.jsp
4. https://www.sqlite.org
5. https://www.genymotion.com
6. http://stackoverflow.com/questions/4567241/external-project-reference-in-android
7. http://leansoftwareengineering.com/2008/05/05/boehms-spiral-revisited/
8. http://developer.android.com/tools/projects/projects-eclipse.html
9. http://www.codeproject.com/Articles/665527/A-GPS-Location-Plotting-Android-
Application
10. https://www.json.org
11. https://code.google.com/p/open-gpstracker/
12. http://androidexample.com/GPS_Basic__-
__Android_Example/index.php?view=article_discription&aid=68&aaid=93
13. http://developer.android.com/tools/projects/projects-eclipse.html
14. http://www.slideshare.net/VishwakSolutions/strategies-for-software-test-documentation
15. http://www.cs.gordon.edu/courses/cs211/AddressBookExample/CRCCards.html
16. http://www.inf.ed.ac.uk/teaching/courses/seoc/2011_2012/notes/SEOC06_notes.pdf
17. http://dspace.org/sites/dspace.org/files/archive/1_6_2Documentation/ch11.html
BOOK REFERENCE
1. Head First Android = http://www.it-ebooks.info/book/644/
2. Software Engineering =
http://dewiar.staff.gunadarma.ac.id/Downloads/files/13560/EBookPressman__Software_
Engineering.pdf
VIDEO REFERENCE
1. Android Tutorials - The New Boston = http://thenewboston.org/list.php?cat=6

A Final Project Report On E-FUEL Engineering Thesis- Pokhara University

Recommended

Recommended

More Related Content

Similar to A Final Project Report On E-FUEL Engineering Thesis- Pokhara University

Similar to A Final Project Report On E-FUEL Engineering Thesis- Pokhara University (20)

More from Karla Adamson

More from Karla Adamson (20)

Recently uploaded

Recently uploaded (20)

A Final Project Report On E-FUEL Engineering Thesis- Pokhara University