Restaurant Availability Mobile App

This document outlines the design of a mobile application allowing customers to check restaurant availability. The app utilizes GPS location, internet connectivity, and a search form to present users with restaurants matching their criteria within a specific proximity. It details preconditions for use, normal and alternative flow processes, exception handling for internet connectivity issues, and includes assumptions about user language proficiency.

COVER PAGE

Contents
COVER PAGE................................................................................................................................................1
1 Introduction..............................................................................................................................................3
2 Purpose.....................................................................................................................................................3
3 Scope........................................................................................................................................................3
4 Acronyms..................................................................................................................................................3
5 Constraints...............................................................................................................................................3
6 Assumptions.............................................................................................................................................3
7 Requirements...........................................................................................................................................4
7.1 Functional requirements...................................................................................................................4
7.2 Nonfunctional requirements.............................................................................................................4
8 Stakeholders.............................................................................................................................................5
9 Project schedule and deliverables............................................................................................................6
10 Project budget........................................................................................................................................6
11 Risk analysis............................................................................................................................................6
12 Quality assurance...................................................................................................................................6
13 Use case diagram....................................................................................................................................7
13.2 Use case scenarios...........................................................................................................................7
14 Class diagram..........................................................................................................................................9
15 User interfaces.......................................................................................................................................9
Bibliography...............................................................................................................................................14

1 Introduction
The Dining closely is an information system that helps connect customers with their preferred
restaurants. The information system is made up of a number of collective systems that are integrated
together to form the complete information system which can be used by either customers, restaurant
owners or an administrator. The system uses a GPS to help customers find the closest restaurant to their
current location so that they can book a table specifying the number of seats, selecting the type of food
they want and how long they might take before getting to the restaurant. The customers can also pay
directly from the application.
2 Purpose
This report aims at modelling the system by identifying the functional and non-functional requirements
that make up the system while modeling the structural and behavioral architecture using UML. For
better illustrations prototyping using wireframes is done.
3 Scope
This report describes the functional and the nonfunctional requirements of the proposed system. TO
model the requirements a use case diagram is used. The use case diagram shows which actors interact
with the system and to which scope of the system they do it within. The use case diagram shows the
behavioral aspect of the system. A class diagram is used to show the structural aspects of the system by
showing the classes and objects making up the system. Finally, simple wireframes are used to describe a
prototype of the system.
4 Acronyms
GPS- Global Positioning System
UML- Unified Modelling Language
5 Constraints
The constraints of the system are the conditions that should hold for the system to operate as it was
designed to. The following are the constraints of the proposed system.
 The customer sub-system is accessed using a mobile phone only.
 The restaurant sub-system is accessed using a web browser as it is a web application thus any
device capable of opening web application pages can open the restaurant subsystem.
 The administrator subsystem is accessed using a web browser as it a web application.
 The payment subsystem used by the customers to pay for orders should be secure.
 All the subsystems will share a central database to help control and coordinate the flow of
information between all the subsystems making up the system.
6 Assumptions
The following assumptions are made to make the constraints more clear for the implementation of the
system.

 The customer subsystem of the system can only be downloaded on specific application stores.
 The GPS coordinates fed to the system for every restaurant should be accurate and verified by
the administrator.
 The payment system to be implemented for the system will be an external payment service like
PayPal. This is done to avoid developing a payment service for the application from scratch but
instead take advantage of the existing payment services which have been fully developed
overtime and are more secure. This will ensure that the customer’s payment details are kept
secure for any transaction happening in the system.
 For the customer subsystem to work efficiently the customer’s mobile device must be GPS
enabled and at the time of launching the application, the customer must ensure that the mobile
data is on or the device is connected to a wireless network with internet access.
7 Requirements
7.1 Functional requirements
Functional requirements describe what the end user expects the application to do in order to achieve a
certain goal using the system. Functional requirements are functions of the system from the end user’s
point of view. The following are the functional requirements of the system.
 A customer should be able t register and log in to their account after successful registration.
 A customer should be able to check for availability of a restaurant that is closest to them using
their mobile devices which are GPS enabled.
 The restaurant search is based on the current position of the customer, price, restaurant type,
dish and more factors. The customer can specify all the factors except for the current position
which is determined using GPS system on the mobile device.
 A customer can make an order after identifying a restaurant from the search results depending
on the availability of the restaurant
 A customer can specify the approximate time of arrival after making an order.
 A customer can pay for an order using their mobile phone.
 A restaurant owner can register to the system and login after successful registration.
 A restaurant owner can provide restaurant information to the system.
 The administrator can verify restaurant owners information
 The administrator can manage user information.
 The administrator can add GPS information for a restaurant
7.2 Nonfunctional requirements
Nonfunctional requirements are requirements that the end user does not interact with but are needed
to achieve the functional requirements. The following are the nonfunctional requirements of the
system.
 Availability- The system should be available at all times to enable the customers to access it and
use it at any time of the day.
 Performance- the system should have a good performance. The time it takes for the customer
subsystem to search for a restaurant based on the search criteria should not be more than 5
seconds on a good internet connection.

 Robustness- The system should not crash easily in case of errors during runtime. The system
should be designed to handle any possible errors that might come up during runtime.
 Secure- The system should be secure in all aspects to make sure user information is secure from
malicious users. These should be highly enforced especially in the payment subsystem of the
system.
8 Stakeholders
There are four types of stakeholders involved in this system;
 Internal executive stakeholders- These are the stakeholders in charge of making all the
executive decisions. These are the stakeholders owing the idea and the system
 External executive stakeholders-These are the stakeholders that have an influence on the
executive decisions make regarding the project but are external to the organization owning the
project.
 Internal operational stakeholders- These are the stakeholders developing the system could be
internal or outsourced. For the proposed system these stakeholders are StarSoft Pvt. Ltd.
 External operational stakeholders- These are the end users of the system and include the
customers, restaurant owners and the administrators.
The diagram below shows the stakeholder map for all the stakeholders depending on two factors;
importance to the project and influence to the decisions made regarding the project.

Figure 1: Stakeholder map
9 Project schedule and deliverables
The estimated time for the delivery of a working system is 3 months upon which continuous
maintenance will continue after the project is delivered and deployed. The following table shows the
schedule to be followed and the deliverable at each stage of the project.
Stage/milestone Time Deliverable
Requirements gathering 3 Days Requirements Document
Requirements specification 1 Day Specification document
Design 1 Week System design
Implementation 8 weeks Working version of the system
Testing 2 Weeks Test cases
Deployment 3 days Fully working system
Maintenance Onwards System updates
10 Project budget
The estimated project budget is $5000. This cost is calculated for all costs that will be incurred from the
start of the project up to the first year when maintenance is done for free. The cost includes labor costs,
material costs, service costs and subscriptions like web server leasing
11 Risk analysis
During the project planning stage identification of the potential risks that might arise during the project
were identified and contingency plans to deal with the risks were documented.
12 Quality assurance
Continuous quality assurance will be done throughout the project development lifecycle to ensure the
quality of the final system. The team leader will be in charge of the quality assurance.

13 Use case diagram
Figure 2: Use case diagram
13.2 Use case scenarios
The following are the use case scenarios for four important use cases;
 Check availability use case

Use Case ID: UC-1
Use Case Name: Check availability use case
Created By: Author of the document
Date Created: Enter date of creation
Actors: Customer
Description: A customer checks for restaurant availability by searching using a mobile
phone
Trigger: Check availability is pressed on the customers mobile phone
Preconditions:  The customer must be logged in to their account
 The mobile device of the customer should have internet access.
 The mobile device of the customer should be GPS enabled
Postconditions: A restaurant matching the search criteria is presented to the customer.
Normal Flow: 1. Customer presses check availability button on the mobile device
application.
2. Application presents the customer with a form to fill on other
preferences.
3. Customer fills the form and presses the submit button.
4. System accesses the GPI API to determine the location of the
customer.
5. System fetches all restaurants within the proximity of the customer
that match the search criteria specified by the customer.
Alternative Flows: 4.1 GPS is disabled on the users device
4.2 Application opens the settings page and asks the customer to enable
GPS.
4.3 Customer enables GPS
4.4 Go back to step 4.
Exceptions: Mobile device in use by the customer does have access to the internet. The
application should not proceed to display the next page but should prompt
the user to check their internet connection.
Includes:  Add specifications
 Get current GPS location
Frequency of Use: Frequently
Special Requirements: The time it takes to determine the current location of the customer should
not be more than 5 seconds depending on the internet connection.
Assumptions: All the customers understand English as all controls and information is
displayed in English.

14 Class diagram
Figure 3: Class diagram
15 User interfaces
The following are the user interfaces
 Customer login

 Customer registration

 Check availability

 Make order

Bibliography
Booch, G. (1999). The unified modeling language user guide. Google Books.
Fowler, M. (1997). UML distilled (1st ed.). Addsion-Wesley.