Software Requirements Specification

1. Introduction

1.1 Project Overview

The purpose of this document is to describe requirements of the application. More details can be found here.

This requirements specification document is designed for an application developing for motorcyclists. The application will be designed to be a registry and resource to which it's user can apply for almost anything that might come to mind related to motorcycle, such as maintenance records, touring places, participated tours, upcoming events, perhaps records of accidents that he has made etc.

2. System Overview

2.1 Twitter Application

2.1.1 Overview

As this software will fetch and aggregate various Twitter data through it's api, an application must be created on Twitter's side. This way, Twitter platform would allow the developer to use it's api using this account.

2.1.2 Functional Requirements

• An application must be created on Twitter's side. See this link for more information. Twitter provides a very good and detailed documentation for it's api. See this link for more information.

2.2 Twitter Authentication

2.2.1 Overview

Twitter offers applications the ability to issue authenticated requests on behalf of the application itself (as opposed to on behalf of a specific user). Twitter’s implementation is based on the Client Credentials Grant flow of the OAuth 2 specification.

2.2.2 Functional Requirements

• An access token should be acquired by making a post request to the api with a Base64 encoded api_key and api_secret. These keys should have been obtained in previous step. See this link for more information.
• Obtained access token should be kept in order to make further requests to Twitter Api.

2.3 Users

2.3.1 Overview

There will be 1 kind of user for this application, a regular User which will be able to register and login using their existing twitter account. User can see nearby tweets around himself on a live map.

2.3.2 Functional Requirements

• Users should be able to sign-up & sign-in using their Twitter account.
• Users should be able to specify their locations.
• Users should be able to see their Twitter username after signed-in.
• Google Maps api should be implemented.
• User should see himself on the map at his current location.
• User should be able to see markers around himself.
• User should be able to see tweets by clicking the markers.
• User should be able to drag the map and markers should be updated based on the current location.

2.4 Continuous Integration

2.4.1 Overview

A continuous integration system would ensure the server is running the latest versioned code all the time. This will both ease the development and deployment processes as well as reducing manual tasks which are both time consuming and error prone.

2.4.2 Functional Reuirements

• TeamCity will be used as a continuous integration server.
• CI Server should have been deployed.
• CI Server should be hooked to the project repositories' master branch.
• CI Server should be triggered when some piece of code is pushed to the master branch of the repository.
• CI Server should be able to get the source code after triggered.
• CI Server should be able to install project dependencies.
• CI Server should be able to run tests.
• CI Server should get sensitive config data from a private repository before deployment.
• CI Server should be able to deploy the code if all tests are passed.