Requirements Gathering

As the group has undertaken the research and design aspects of this project first, with the aim of completing market research and expert opinions before implementation, requirements gathering was undertaken in group meetings by developing ideas about the potential users of our application and the functionality that would be included in the TravelSafe application. Due to the way that this project has been undertaken, these requirements are to provide an idea of the functionality and limitations of our application and may change during the market research stages. This has been influenced by background research that includes the evaluation of Similar Applications. This lead the group to conclude the most important functional and non-functional requirements for the project, which are stated below.

Functional Requirements

The system shall be able to:

1. allow a user to search and select a location based on GPS data
2. allow a user to select a location from a list of saved locations
3. For each location, it must be able to:
   • generate three point to point safe routes using area safety ratings
   • provide a safety rating of a user’s surrounding area based on publicly available crime data
   • provide travel information from publicly available times and map
   • provide safety tips using open data from Government and police service
   • provide an updated news feed from RSS feeds of news source
   • download a pack of the above data that can be accessed and used offline from on-device storage

4. allow users to access and search through a list of Frequently Asked Questions (FAQs)
5. provide translation functionality through use of Google Translate API
6. have a section dedicated to user-input information as free text

Non-Functional Requirements

The system should:

1. be a web-based application
2. provide a comprehensive list of help and instructions for use
3. use a consistent style, layout and colour scheme throughout the application
4. take all reasonable steps to improve accessibility
5. be intuitive for use
6. be compatible with Internet Explorer, Google Chrome, Mozilla Firefox and Apple Safari to ensure compatibility with mobile browsers

Constraints

The application will be limited by/not be able to:

1. the accuracy of the GPS hardware within a mobile device
2. provide external backup of data

This set of finalised criteria were chosen from the extensive discussion of the merits and drawbacks of the potential features, combined with the research into similar applications as well as project constraints such as the time available and the skillsets of the developers within the group. The group feels that the finalised requirement are representative of the type of application that is being suggested, with the quantity of features providing the unique selling point to allow the group to target a niche in the market identified during research utilising both development and time management skills of the group as a whole.

This post represents that coherent structure and story are present in the portfolio which uses the entry and tags mechanism of the blog system. It tells the story of the project by explaining individual roles clearly, explaining why these were decided, and what outcome they will produce later on in the project.  

This post also represents that the group has chosen appropriate economic and social Contextual Factors that directly link to the marking criteria, and are vital to understanding what requirements the product will have. There is evidence that these have been chosen intelligently (by reference to literature and analysis) to produce a specification of professional quality, leading to a successful product. 

In addition design considerations for the project have been addressed in this post. This is evident through the layout of steps that the project should include, how these have been decided, and how this will be implemented to solve a problem. 

Written by Emily.