Reach - Software Requirements

1. Introduction

Reach is an Android and Web based application that makes finding and hosting events easier for everyone. Users can host their events on Reach, where it will then be advertised to other users on the app. By using a user defined radius, Reach finds events hosted on the application within that radius, relative to the user's GPS coordinates. Reach also helps find directions to events, as well as providing useful information regarding the event. This creates a fast and easy way to find something to do, especially in last minute situations.

1.1 Purpose

This document is a framework for Reach. This document is intended for whoever would like to gain an in depth understanding of the application as well as Reach's development team.

1.2 Scope

Reach is an application where users can either locate or advertise their events in a radius around their current location. Users consist of Hosts and Guests. Hosts can set up a broadcast radius, fill in relevant details regarding their event, and then post it so other users can see it. Guests define the radius around them, all events are listed within the radius, and Guests can express interest in any event they choose. This gives the Host an idea of the potential number of people attending their event.

1.3 Definitions

Guest:
A user who attends an event
Host:
A user who schedules an event
Post:
Adds an event into the database to be advertised
Search:
Request a list of events that are scheduled to begin or have already begun
User Radius:
The user-defined radius in kilometers around their current location in which to search or advertise

1.4 References

IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998

1.5 Overview

The rest of this document contains the 'Overall Description section' & 'Specific Requirements' section. The former goes into detail about what factors affect Reach and its requirements. The latter discusses what these requirements are.

2. Overall Description

2.1 Product Perspective

Reach operates as two seperate applications. One is a web-based application and the other an Android-based application. Both applications operate using three major components: a front end, back end, and database.

Front End:

The front end is the user interface component of the application. It is the only part of the application users can see and interact with. The front end is responsive and supports multiple screen sizes and resolutions. It should work on any modern browser or Android device depending on the application used.

Back End:

The back end is responsible for interacting with both the front end and database. It should receive information from both in order to carry out various functions. These functions include the creation, finding, and viewing of events and should update the front end and database with required information.

Database:

The database holds information regarding the application. This information includes user info, such as usernames and encrypted passwords. It also includes event information, such as addresses and times.

2.2 Product functions

Reach has three main functions which users can utilize. These functions are implemented with the help of the Google Maps Platform and its various related API's.

Create Event:

The first main function is the ability to create and host an event. When creating an event users are prompted to input various required information. This information includes a name and description for the event, as well as the address, times, and cost if it is a paid event. After the information is filled out, a pin is created and placed on the map at the specified address.

Find Event:

The next main function is the ability to find events that are created. Finding events is done automatically and is only dependent on a radius specified by the user. Within the radius of the user's location, a list of events that are upcoming or ongoing is created. These events are then displayed as pins on a map, which the user can select to view details about the event.

View Event:

The last main function is the ability to view the information of found events. Selecting a pin on the map displays all the information regarding the event. Further options for the user can also be displayed, such as directions to the party.

2.3 User Characteristics

Users only require a basic level of technical expertise with using a website or mobile application. Users who wish to act as Hosts are provided with a simple form to input their event details. Meanwhile, the Search interface is intuitive to use so users seeking events to attend at the last minute can find one quickly and without hassle. Users are provided with a tutorial the first time they use the application.

2.4 Constraints

Development of this application faces both time and cost constraints. As there is no budget, the application's capabilities are restricted to the monthly $200 free credit provided by the Google Maps API.

2.5 Assumptions and Dependencies

It is assumed that a user's device or browser is compatible with the Google Maps, and connected to the internet. The website version should function on any operating system, and all major, up-to-date internet browsers. This includes Google Chrome, Firefox, Microsoft Edge, and Internet Explorer. The Android version should function on newer android based devices and the vast majority of older devices.

3. Specific Requirements

3.1 External Interfaces

The following are all forms of data which the user either uses or inputs using the software

3.2 Database

User Information: Database contains user specific information such as:

Party Information: Database also contains information specific to each party/event such as:

3.3 Standards Compliance

3.4 Software System Attributes

Maintainability:

Regular patches released on a monthly basis focused on optimization and implementing fixes based on bugs noticed internally or on feedback from the user base. "Hotfixes" will be released on an "as needed" basis to address any critical bugs noticed with the software.

Security:

Login: If the given username/email doesn't exist within the database then an error is handed back to the client side. If the username/email does exist the designated Salt for that username/email (stored in the database) is added to the given password and hashed using SHA256. The hash generated will then be checked with what is stored in the database. If the two don't match an error is returned.

Encryption Algorithm: SHA256

3.5 Use Case Diagram