1. Introduction

"Restaurant Review App according to Geographic Location" is a project that helps users find restaurants based on their needs. The main goal of the project is to provide users with an easy-to-use application that helps them find restaurants according to their taste and convenience. Users can also give feedback about restaurants by rating and writing reviews. The Google Maps API shows the restaurants in the current range. The application also makes it easy for the user to send invitations to friends/colleagues for events.

1.1. Purpose

The purpose of this document is to give a detailed description of the requirements for the “Restaurant Review App according to Geographic Location” project. It will indicate the purpose and complete statement for the development of the system. It will also explain system constraints, interface and interactions with other external applications. Through this app, users can share their experience of visiting restaurants and provide reviews of foods reach the restaurants they want to go to. Basically, this app will help build a social community for food lovers.

1.2. Scope of Project

"Restaurant Review App according to Geographic Location" is a GPS-based mobile application that helps users find the closest restaurants based on the user's current location and other features such as top rated restaurants, restaurant type, and more. Restaurant owners can provide restaurant information using this application. This information will form the basis for the search results displayed to the user. An administrator also uses this application to manage the system and keep information accurate. For example, the manager can verify reviews posted in the restaurant's comments section. This information will form the basis for the search results displayed to the user. An administrator also uses this application to manage the system and keep information accurate. The administrator can, for example, update restaurants and manage user information. Also, the software needs both an Internet and GPS connection to receive and display results.
All system information is kept in a database located on a web server. The software also interacts with the GPS Navigator on the user's mobile phone. Using the GPS Navigator, users can view the restaurants they want on the map and have access to a real-time map that will help them access the location of the restaurants. The app is also capable of presenting both summary and detailed information about restaurants. Thanks to this navigator, users can easily find the closest and most perfect place to eat according to their needs and needs. This app will definitely boost restaurant business. On the other hand, this app guides food lovers to meet their restaurant requirements. This app will be a common platform for users and restaurant owners to learn the latest details about restaurants.

1.3. Glossary (Definitions, Abbreviations, Acronyms)

Android Studio: A mobile coding environment for creating an mobile application for Google Play.

Real Time Maps App (Application): Mobile application software which prepared to work on mobile devices.

API (Application Programming Interface): API helps two different software to use each other’s functions.

GPS (Global Positioning System): GPS, or the Global Positioning System, is a global navigation satellite system that provides location, velocity and time synchronization.

SRS: Software Requirements Specification

2D: 2-Dimensional

UI: User Interface

IDE: Integrated Development Environment

UC: Use Case

DB: Database

IEEE: Institute of Electrical and Electronics Engineers

1.4. Overview of Document

This SRS document is generated by using the IEEE STD 830-1998. Also, the rest of the document contains five important parts which are Introduction, Overall Description, Specific Requirements and References. Introduction part describes an overview of the whole SRS. Overall description part contains general information that is not too specific and is provided as a background for the following sections. Specific Requirements contains more detail and presents the requirements with many different diagrams that illustrate the functional requirements of the project.

2. Overall Description

2.1. Product Perspective

This section will give an overview of the whole system. The system will be explained in its context to show how the system interacts with other systems and introduce the basic functionality of it. It will also describe what type of stakeholders that will use the system and what functionality is available for each type. At last, the constraints and assumptions for the system will be presented.

2.1.1. Development Methodology

This system will consist of two parts: one mobile application and one web server. The mobile application will be used to find restaurants and view information about them while the web server will be used for managing the information about the restaurants and the system as a whole. The mobile application will need to communicate to a GPS application within the mobile phone, which in turn communicates with a physical GPS device to find the location of the user. The GPS will provide the mobile application with locations of both the user and the restaurants and the distance between them, but it will also provide maps and the functionality to display the application’s data on the map. The functionality provided by the GPS will be embedded into the application in order for the user to be able to use the functions in the application in a seamlessly manner. Since this is a data-centric product it will need somewhere to store the data. For that, a database will be used. Both the mobile application and web server will communicate with the database, however in slightly different ways. The mobile application will only use the database to get data while the web server will also add and modify data. All of the database communication will go over the Internet.

2.2. Product Functions

Getting user position: After receiving permission from the user we receive their coordinates from their mobile phone. Getting desired position: After receiving a position name from the user, get the desired location’s mathematical coordinates from the database and send that to the receiver. Creating a Map: After getting position and desired position create a 2D map using road map creator(Open for change) to wanted position using the most ideal way. Sending a mail: If a user gets banned or one or more of the user's reviews are getting deleted send a notification to the user(also used for signing up). Update Restaurants/Reviews: As we don't want our information of restaurants or reviews to be old we constantly update our reviews or restaurant information. CheckImage:(Optional): Check if the image entered is a food or food related or other image, if not food ignore image, else receive image. Authentication Services: Making sure user is not bot and User has entered from legal ways.

2.3. User Characteristics

In particular, the users who use this project are the people who have difficulty in deciding what to eat and where to go, and they need options for this. Users should have this information for functions such as search, GPS information and filtering. They should also be aware of the use of mobile phones.

2.4. Constraints

The mobile application is constrained by the system interface to the GPS navigation system within the mobile phone. Since there are multiple system and multiple GPS manufacturers, the interface will most likely not be the same for every one of them. Also, there may be a difference between what navigation features each of them provide. The Internet connection is also a constraint for the application. Since the application fetches data from the database over the Internet, it is crucial that there is an Internet connection for the application to function. Both the web server and the mobile application will be constrained by the capacity of the database. Since the database is shared between both application it may be forced to queue incoming requests and therefore increase the time it takes to fetch data.

2.5. Assumptions and Dependencies

2.5.1. Assumptions

-User expected to know how Google Maps is used.

-User should have bare minimum knowledge regarding smart phone usage.

-Mail services is expected to working.

-Google services should be running.

-We hope users upload images relevant to their comments.

2.5.2. Dependencies

-User should give access to GPS services.

-User should have stable internet connections.

-User’s device should support Android services.

-This application is not made for specified users so it doesn’t have text-to voice services so User is expected to have the capacity to see.

3. Specific Requirements

3.1. External Interface Requirements

3.1.1. User Interfaces

User Interface must be in a clear and user-friendly structure. UI should provide the users consistency of users’ information. Also, possible errors should be minimized because of the situation of target user group. If user meets any error during using the system, error messages should help the user in positive, actionable and professional approach. Also, error messages should be appropriate for user knowledge and situation. The user interface should be successfully designed not to encounter any difficulties. The target user group in the project is the people who are undecided about where to go and what to eat and need options. So the UI filtering option should be good and the options should be well listed.

3.1.2. Hardware Interfaces

The project is a mobile based application. Client side application will be developed as an Android application. To use this system, User should have an Android based operating system. In addition, a camera may be needed for this project in order to comment on restaurants by adding photos. There will also be a server. And on this server, information such as restaurant type, score, location and user information will be stored here.

3.1.3. Software Interfaces

To develop the Android application, Eclipse will be used as a client-side IDE. Also, Java is the main programming language to develop Android applications in Eclipse. Android Studio will be used and Google libraries will be used.

In addition, in order to develop this project, Google's own database, especially the Google API, will be provided by Başarsoft, and information will be gained about roads and a map library. This library will help us to define successful and minimum error.

3.2. Use Cases:

3.2.1. Open Page

Use Case: Open page

• Register
• Login as Admin
• Login as Anonymous
• Login

Use Case Diagram:

Use Case Name: Open Page

Use Case Number: UC-01

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: User, Admin, Anonymous

Overview:

This use case is the page with the options to login to the application.

References: [1], [2], [3]

Related Use Cases: -

Typical Flow Description:

Pre-Condition: 
1. Internet connection must be available.
Post-Condition:
1. The user is logged into the system.
Typical Flow Description:
1. The user clicks the "Register" button to register to the application, or the "Login", ” Login as Admin”, ” Login as Anonymous” button if he / she is registered.
2. The user is transferred to the "Register" or "Login" screen.
Alternative Flow Description:
1. If the person entering the application is "Admin", he / she clicks the
"Login as Admin" button.
2. If the person entering the application is " Anonymous ", he / she clicks the
"Login as Anonymous " button.

3.2.2. Registration Page

Use Case Name: Registration Page

Use Case: Register Page

• Register

Use Case Diagram:

Use Case Number: UC-02

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: User

Overview:

This use case allows users to register with the system.

References: [1], [2], [3]

Related Use Cases: UC-01

Typical Flow Description:

Pre-conditions:
1. User must switch from Open Page to Register Page.
2. The user must not be registered to the system before.
Post-conditions:
1. As a result of the correct actions, it is registered in the system.
Typical Flow Description:
1. The user defines "User Name", "E-mail" and "Password" for himself/herself, fills in the fields and clicks the register button.
2. The system checks whether the Username and E-mail are already registered.
3. If there is an error condition, it is indicated on the screen. Re-enters user information.

3.2.3. Member Login Page

Use Case Diagram:

Use Case: Member Login Page

• Login
• Forgot My Password

Use Case Name: Member Login Page

Use Case Number: UC-03

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: User

Overview:

This use case allows users to log into the system.

References: [1], [2], [3]

Related Use Cases: UC-01

Typical Flow Description:

Pre-Conditions:
1. User must switch from Open Page to Login Page.
2. It must enter the Username and Password correctly.
Post-Conditions:
1. As a result of the correct operations, it has entered the system.
Typical Flow Description:
1. User clicks the "Login" button by filling in the "Username" and "Password" information.
2. The system checks the User Name-Password match.
3. If there is an error condition, it is indicated on the screen. Re-enters user information.
Alternative Flow Description:
1. If the user has forgotten his password, click the "Forgot My Password" button.
2. The system sends a password reset mail to the e-mail address.
3. The user can reset his password in line with the incoming mail.

3.2.4. Admin Login

Use Case Diagram:

Use case name: Admin Login

Use case number: UC-04

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Users, System

Overview:

The role of an admin is important to manage the mobile application maintainability after the deployment. The potential actions that the restaurant admin can perform. This is a super user role that can control or edit the roles of all the other actors in the system. The admin can add, delete or edit the menu items. The admin can edit the users and their roles in the system.

References: [1], [2], [3]

Related use cases: UC-01

Typical Flow Description:

Precondition:
1. User must have an Internet connection.
    Postconditions:
1. User’s login type is set to Admin.
    2. Accepted functions are set.
Exceptional Situations:
    1. Admin forget his/her password.
    Successful Scenario:
1) Admin enters id, password.
2) System sets user’s login type as Admin.
3) Sets acceptable operations.
    Alternatives:	
    1) Admin enters Reboot code.

3.2.5. Anonymous Login

Use Case Diagram:

Use case name: Anonymous login

Use case number: UC-05

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Anonymous User, System

Overview:

When user’s do not want to waste their time to logging in and just search restaurants around them or look for particular restaurant’s reviews. Calls login setter for system,sets value of user to anonymous.

References: [1], [2], [3]

Related use cases: UC-01

Typical Flow Description:

Preconditions:
-
Postconditions:
1. User’s login type is set to Anonymous.
2. Accepted functions are set.
Exceptional Situation:
1. User pressed around the button but not to the button.
Successful Scenario:
1) Presses the anonymous login.
2) System sets user’s login type as Anonymous .
3) Sets acceptable operations.	

3.2.6. Adding to the blacklist

Use Case Diagram:

Use case name: Adding to the blacklist

Use case number: UC-06

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Users, Admin, System, Mail System

Overview:

When a particular User constantly writes wrong reviews that deletes or add’s inappropriate images below food images they are added to blacklist so they can’t reenter this app.

References: [1], [2], [3]

Related use cases: -

Typical Flow Description:

Pre-Conditions:
1. Student DB should be accessible.
2. Admin must select to add blacklist.
3. There should be an user with given id.
Post-Conditions:
1. A mail is sended to the user that says she/he is banned.
2. Users data is added to BlackList Db.
3. User’s id is deleted from User database.
4. User’s reviews is not changed.		
Exceptional Situation:
1. Admin banned wrong person.
Successful Scenario:
1) Admin press send to blacklist.
2) System adds User data to blacklist.
3) System delete users data from User’s database.
4) System sends mail to the User that his/her account is suspended.

3.2.7. Filtering

Use Case Diagram:

Use Case:

• Restaurant type
• Range
• Rating
• Save

Use Case Name: Filtering

Usage Case Number: UC-07

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Anonymous,User

Overview: This use case allows users and Admin to filter by distance and meal options when choosing a restaurant.

References: [1], [2], [3]

Related use cases:

Typical Flow Description:

Pre-Conditions:
1. The user must be logged in.
2. The user must decide what he wants to eat.
3. The user must decide the distance he wants to go.
Post-Conditions:
1. The restaurants that are suitable for the user's selection are listed for the correct actions.
Typical Flow Description:
2. The user chooses the type of food they want from the food options.
3. The user selects the range.
4. The user clicks the save button.
Alternate Stream Description:
1. If there is no restaurant in the desired type or range, it will receive an error message.

3.2.8. Showing Restaurant Details

Use Case Diagram:

Use Case Name: Showing Restaurant Details

Use case number: UC-08

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: User, Anonymous, System, Google Maps

Overview:

When the show button is pressed Restaurant names, average points, location difference between user and restaurant would show if clicked show other reviews according to different user’s reviews to that particular restaurant.

References: [1], [2], [3]

Related use cases: -

Typical Flow Description:

Pre-Conditions:
1. Show button should be pressed.
2. User should have a network connection.
Post-Conditions:
1. Restaurant information would be shown.
2. A cross would be in top right that would go back.
Exceptional Situations:
-
Successful Scenario:
1) User clicks show.
2) User’s current coordinate is sended to System.
3) Restaurant N meters close to the user is selected.
4) Restaurant details are added.
5) Restaurant points are added.
6) Restaurant are listed according to their location.
7) Restaurants are shown in search.

3.2.9. Reviewing Restaurants

Use Case Diagram:

Use case name: Reviewing Restaurants

Use case number: UC-09

Author: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Users, System, Anonymous

Overview:

When users are choosing the restaurants that they would like to eat they would like to make sure that the restaurant is good so reviewing restaurants uc is used to give users an easier way to make sure that restaurant is good.

References: [1], [2], [3]

Related use cases: UC-10, UC-11, UC-12

Typical Flow Description:

Pre-Conditions:
1. There should be restaurant details in the database.
2. User should have internet connection.
3. UC1,UCBa,UCBe should be accessible.
Post-Conditions:
1. If UC-11 or UC-12 is called, the Restaurant reviews page is refreshed.
2. If UC-10 is called check if any of the review is deleted refresh the page.
Exceptional Situations:
-
Successful Scenario:
1) Check for Any Use Case call.
2) If UC-11 is called change the restaurant reviews page.
3) If UC-12 is called refresh Restaurant page.
4) If UC-10 is called, the restaurant reviews page is refreshed.

3.2.10. Commenting And Rating

Use Case Diagram:

Use case name: Commenting And Rating

Use case number: UC-10

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Users, System

Overview:

The user can write a review and see all the reviews of a selected restaurant from these screens. The review includes the rating and an opinion about the restaurant. This use case also allows users to rate restaurants.

References: [1], [2], [3]

Related use cases:-

Typical Flow Description:

Preconditions:
- User should be logged in.
- User should have Internet connection.
- User should give access to GPS services.
- User’s should opened the application in Restaurant location.
Post-Conditions:
- Check location service.
If was in location
- Update database.
- Refresh is called.
- Exit activity.
If wasn’t in location
- Send error message.
- Exit activity.
Exceptional Situations:
Successful Scenario:
1) User clicks give review.
2) System checks if User had been in location for past 2 hours.
İf was in location:
3a) Get user review message.
4a) Send Review to Restaurant DB.
5a) Call refresh use case.
6a) Give Comment is given message.
7a) The user clicks on the rating button of the relevant restaurant.
8a) Gives points from 1-5.
If wasn’t in location
3b) Stop review.
4b) Give error message.
5b) Exit page.
Alternate Stream Description:
If the 1st user has not been to this restaurant, he/she will receive an error message and cannot give points.

3.2.11. Deleting Reviews

Use case name: Deleting reviews

Use case number: UC-11

Author: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Users, System

Overview:

When other users find particular review useful for what they are searching for they would give it a positive point, or if it is fake, irrelevant to the food or not useful to the user’s they could give it a negative point, when a review gets lot genitive points than positive it automatically gets removed by the system.

References: [1], [2], [3]

Related use cases: UC-10

Typical Flow Description:

Pre-Conditions:
1. Restaurant should be in database.
2. User should have internet connection.
Post-Conditions:
1. Review's points should be changed.
2. if negative is higher review should be deleted.
Exceptional Situations:
1. At the same time 2 reviews is given.
Successful Scenario:
1) User would press up or down.
2) The system will check the difference between positive and negative points.
3) If there is a difference Then Delete the review.
4) If there is no difference Then Let the review be there.

3.2.12. GPS Services

Use case name: GPS services

Use case number: UC-12

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Users, Anonymous, System, Google Maps

Overview:

When the user clicks the scan button this use case is called this use case is the parent of UC4 and UC3.

References: [1], [2], [3]

Related use cases: UC12, UC13

Typical Flow Description:

Pre-Conditions:
1. User should click scan.
2. User should have a network connection.
3. Users should accept GPS services.
4. Google Maps should be accessible.
Post-Conditions:
1.User exits the application.
2.User reaches the destination, UC6 is called.
Exceptional Situations:
-
Successful Scenario:
1) User clicks Scan.
2) UC 4 is called in which user asked to select which restaurant does user would like to go.
3) After an Restaurant is selected and accept is selected UC 3 is called which draws a map and reads users coordinates.
4a) If User has reached their destination User will be asked to review that restaurant.
4b) If User closes the app before the user reaches their destination nothing would happen.
5a) UC6 is called.

3.2.13. Show Restaurants

Use Case Diagram:

Use case name: Show restaurants

Use case number: UC-13

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: Users, System, Google Maps

Overview:

When user would like to choose a restaurant around him/her, he/she opens the map every restaurant around the user with different colours according to average points that restaurant has, would have a button that would send user to that location.

References: [1], [2], [3]

Related use cases: UC-14

Typical Flow Description:

Pre-Conditions:
1. User should have internet connection.
2. User should give permission to GPS services.
3. Restaurant coordinates should be in DB.
4. Restaurants should have reviews.
Post-Conditions:
1. Restaurants are listed.
2. Restaurants are printed according to their points average.
Exceptional Situation:
1. Restaurant is closed.
Successful Scenario:
1) User selects scan.
2) Other restaurants around user would shown according to coordinates in coordinate select.
3) System checks their points according to their point average give them a color tag.
4) According to their color tag show restaurant in different colors.
5) Map is done user would choose.

3.2.14. Send To Restaurants

Use Case Diagram:

Use case name: Send to restaurants

Use case number: UC-14

Authors: Beste Şankaynağı, Baran Yiğit, Coşkun Oruç

Actors: User, GoogleMaps, System

Overview:

When User would choose the restaurant that he/she would like to go he/she press the button and the location would open in Google Maps with given coordinates.

References: [1], [2], [3]

Related use cases: -

Typical Flow Description:

Pre-Conditions:
1. User should click send me.
2. User should have network connection.
3. User should accept GPS services.
Post-Conditions:
1. Google Maps will open.
2. A map is drawn according to location.
Exceptional Situations:
1.Restaurant is Closed.
Successful Scenario:
1) Users clicks take me there.
2) User’s location is packaged with restaurant location.
3) Package is sent to Google Maps.
4) Created a shortest route to the restaurant.
5) A map is drawn as an app.

3.3. Performance Requirements

For the best performance user’s should have updated Android services in their phone and Network connection to have stable and up to date info regarding restaurants.

3.4. Security Requiments

For security, we are holding our user's data in web database so there won't be any data of any user in another user's mobile device. Also we are going to add encryption to our database when uploading data so even when someone manage to get user's data in their hands they could not read or change that data as they want.

3.5. Design Constraint

The design shall be according to IEEE Standard 1016-1998 Recommended Practice for Software.

3.6. Software System Attributes

3.6.1. Portability

We are creating a mobile application as around 97.2% of Turkey's population are using mobile phones [4]. After looking at this we could say that around 97% of Turkeys population might use our project on their phone so our project will be pretty portable.

3.6.2. Usability

This application is created for those who are not so close with mobile phones so this app will be pretty easy to use and user friendly.

3.6.3. Reliability

First of all we are making sure no bot’s are entered to this application. Also we are making sure users are logged in to make reviews for any restaurant so our program will be quite reliable also for our user’s comfort. We are also going to use store user data in separate database which only admin can reach that database.

3.6.4. Availability

This mobile application is going to be available on Google Play Store so anyone who has Google Play in their phone, and has network connection can use this application.

3.6.5. Security

For security, we are going to put user data in separate database. Also we could use encryption for changing their data in case of data stealing thieves can't reach users' data in a short time.

4. Reference

1. What Is a Use Case & How To Write One | Wrike. Accessed on: https://www.wrike.com/blog/what-is-a-use-case/.

2. UML Use Case Examples of Common Scenarios | EdrawMax. Accessed on: https://www.edrawsoft.com/article/use-case-diagram-examples.html.

3. Designing Use Cases for a Project - GeeksforGeeks. Accessed on: https://www.geeksforgeeks.org/designing-use-cases-for-a-project/.

4. Akıllı telefon harcamaları yüzde 50 arttı - Son Dakika Haberleri. Accessed on: https://www.trthaber.com/haber/ekonomi/akilli-telefon-harcamalari-son-bir-yilda-yuzde-50-artti-571161.html.

5. Google Maps Platform: Maps API nedir? | Başarsoft. Accessed on: https://www.basarsoft.com.tr/google-maps-platform-api-nedir/.

6. API Nedir? Ne İşe Yarar? | ceaksan | Web Analisti & Veri Bilimi Meraklısı. Accessed on: https://ceaksan.com/tr/api-nedir.