Projets-2016-2017-UltraTeamBest/SRS

Read first:

• http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
• http://en.wikipedia.org/wiki/Software_requirements_specification
• IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

Document History

	Version	Date (DD/MM/AAAA)	Authors	Description	Validator	Validation Date
	0.1.0	05/02/2017	Clément Rouquier & Anthony Geourjon ( senseix )	SRS's first version	TBC	TBC

1. Introduction

1.1 Purpose of the requirements document

This document aims to clearly define requirements, and so features, for our application, both functional and not-functional. Features presented here are the atomic core of the future application.

1.2 Scope of the product

The scope of the product is to make an application onwhich members of a same network would be able to locate and exchange datas with each other equiped member. This has to be possible for every users (depending on their own equipment) regardless of natural conditions (Weather, Relief) nor network coverage of the area. Optionnal equipement would allow more data knowledge. Scope users could be:

• Trailers: Be able to locate themselves, and have a constant possibility of contact with organization team.
• Hunters: Have a direct visualization of the area covered during a try to regroup beasts. It's also a safety measure to don't shoot an human.
• Hikers: For organisms like UCPA, could be used to watch children during hiking, preventing any losts. New activities could be created thanks to the application, which only create an easy way to take care of every child at once.

-> Urgent signals such as SOS are features specifically for these users.

1.3 Definitions, acronyms and abbreviations

• GPS: Globaml Positionning System
• LoRaMote: Device able to broadcast his own position using the LoRaNetwork and GPS
• Module RN2483: Communication module able to send date at specific frequencies, using a USB Sserie-port
• Group: Network of users, contain at least a Receiver.
• Users: General term for all members of a group
• Receivers: Specific users: Have at least an Android Phone with the application running, a LoRaMote and (optionnal) a Module RN2483. They are able to send and receive data
• Senders: Speciific users: Have at least a LoRaMote and (optionnal) a Module RN2483. Are only able to send their own data.

1.4 References

This is the first year this projet is conducted, and so we do not have previous bases for this specific project. Although, here's an non-exhaustive list of documentation on technologies which are going to be in use:

• A Book on STM32, 32-bit microcontroller integrated circuits by STMicroelectronics
• A LoRa Documentation, provided by Orange
• Semtech LoraMote Documentation
• Developing IoT Mashups with Docker, MQTT, Node-RED, InfluxDB, Grafana
• Docker
• MQTT
• Node-RED
• InfluxDB
• Grafana
• Leaflet
• Meteor
• Code de Base

1.5 Overview of the remainder of the document

In the following parts of the documents, specific features and constraints of usage are detailled. It also quantify the importance of every single one. Finally, ideas of future development are included.

2. General description

2.1 Product perspective

The product will manage a group.

Each user has

• (Optional) A smartphone and bluetooth equipement
• A LoRaMote device, making him visible for each receiver.

-> Availability to keep receivers informs on its own position through Lora Network

-> Can manually launch specific signals such as SOS

Each receiver has:

• (Optional) A bluetooth equipement such as GPS watch or cardio belt.
• Module RN2483
• An Android Running and Bluetooth friendly Smartphone

-> Availability to keep other receivers informs on its own position and various data through 3G or Lora Network

-> Can catch and display on the Smartphone information broadcasted by all users.

-> Can interact with other receivers for specific information

Public Restrictions

LoRa Network uses Public Radio Frequencies, and so the traffic on these frequencies is limited. The application has to be data-friendly in order to respect these regulations.

2.2 Product functions

Senders:

• Automatic broadcast on Lora Network its own GPS position every quantum of time. Quantum would be predefined considering battery life and accuracy.
• Manual SOS signal through Lora Network with a physical SOS button.
• (Optionnal) Receive near data using bluetooth and provided by specific equipements (Cardio belt, GPS watch...)
• (Optionnal) Visualization of its own data on a map powered by OpenStreetMaps. It could be a possibility to allow senders with a smartphone to share data with the group using 3G

Receivers:

• Automatic broadcast on Lora Network and/or 3G its own GPS position every quantum of time. Quantum would be predefined considering battery life and accuracy.
• Manual SOS signal through Lora Network with a physical SOS button.
• Catch all GPS broadcasted information and display it on an OpenStreetMap powered map. Show also computed data such as distance, speed (using data history)...
• (Optionnal) Receive near data using bluetooth and provided by specific equipements (Cardio belt, GPS watch...) and broadcast it using LoRa Network and/or 3G
• Catch all data broadcasted display all available data as further information on a clic on a point of the map, representing an user.

2.3 User characteristics

User characteristics had already been described splitting users into 2 groups: receivers or senders If a group has only 1 user, this one would be alone, and can also use the application to visualize data from himself (GPS, Bluetooth received data..) as if it where a receiver (even without Module)

2.4 General constraints

• Battery life of LoRa device
• Cost of each equipement
• Public Network Pollution (Problem of public frequencies, already described)
• Really adaptive design to make it suitable for every usage of the application

2.5 Assumptions and dependencies

• At least one Android Smartphone with USB port per group

Nothing else is mandatory

3.Specific requirements, covering functional, non-functional and interface requirements

• document external interfaces,
• describe system functionality and performance
• specify logical database requirements,
• design constraints,
• emergent system properties and quality characteristics.

3.1 Requirement X.Y.Z (in Structured Natural Language)

Function:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:

• Natural language sentences (with MUST, MAY, SHALL)
• Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
• Mathematical Notations
• Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

3.2 Requirement 2-Transmit GPS position with Lora-Mote

Description:The Lora-Mote send in broadcast his GPS position.

Inputs: The GPS positions of the lora mote

Source: LoraMote

Outputs: A Lora signal (no LoraWan) containing the identifiers of the lora mote and it's GPS positions

Action:

• The slave send his position and the master get the slave's position

Non functional requirements: The message must be compact.

4. Product evolution

The project can become a base to develop more specific application like a CMS. For example, we can imagine our application adapted to hunting with the management of a group of hunters and a lot a dog. An other example is the use in ski station with some paths at the downhill and other at the climb with the time of climb of lifts (data deliver by the station).

More technicaly, the app can be carry on iOS and others platforms.

Finally the modem and the antenna can be miniaturied to be more practical.