Projet-2016-2017-UltraTeam/SRS

Document History

	Version	Date	Authors	Description	Validator	Validation Date
	0.1.0	02/02/17	Gallier R. Ferrera A.	TBC	TBC	TBC

1. Introduction

1.1 Purpose of the requirements document

The aim of this documents is to provide a definition of the of the different expected feature of our project.

1.2 Scope of the product

The scope of the product is to provide a phone application which will alow you to localise users around you, as long as they are members of your team. This application must be able to work with 3G or lora network.

Users will be able to emit their position thanks to a LoraMote. They will also be able to communicate thanks to Modules RN2483.

The application will allow users to transmit informations such as position, heart rate, speed, etc... depending on the equipment they have.

The application will also allow users to see on a map where are the other members of their group, and access the informations previously mentionned. These users are the Team Leaders

People should also be able to communicate their position to every users, as long as they activate their LoraMote. This could be used as a simple warning or as a SOS message.

1.3 Definitions, acronyms and abbreviations

Users : People who interact with the application.

Team Leaders : Users who have the capability to retrieve the data of their group members.

LoraMote : Device using Lora's Technology to broadcast it's GPS Location

GPS : Global Positionning system

1.4 References

livre sur STM32 : [1]

Guide lora : [2]

s'entrainer avec ce tutoriel : [3]

User Guide Semtech LoRaMote : [4]

2. General description

2.1 Product perspective

The product consist of a mobile application that can interact with others equipments thanks to bluetooth, the usb socket and the Lora Network. The mobile app will provide its users information about other members of their team. These data will be exchanged depending on the equipment of each user.

The mobile app will need to manage bluetooth equipments such as a sport watch or a sport belt.

The mobile app will need to connect to a RN2483 module through the usb socket and use it to send personnal data of a user.

The LoraMote will regularly broadcast its owner's position.

The communication through Lora's Network is restricted since this is an open network. Which means that only small amounts of data can be exchanged, and not too frequently.

The application should use Lora's Network if the other networks (3G) aren't available.

2.2 Product functions

Users will have the possibility to create teams through the app, so they can define who participates to the trail and thus who will be communicating.

If a user has everything (in terms of equipment), the app will provide him a map displaying :

- the position of the members of the team

- the physical condition of the members of the team

- an alert if a member is in danger

- the route taken by the members since the beginning of the trail

- the time that separates people's postitions. (i.e : XX is 2 minutes from you. Which means that you were at XX's position 2 minutes ago)

In order to make the application easier to use, users should be able to create an account and thus store their personnal data / preferences.

2.3 User characteristics

There are 3 types of users. These types depend on the equipment that they own, and their access to networks (3G,...).

Users who only have a phone will be able to manage their bluetooth equipments thanks to the app.

Users who have a LoraMote will be able to send their position to the team, even without internet access.

Users who have a Module RN2483 (and a phone) will be able to communicate with the team. Which means that they will know where everyone is and their physical conditions.

2.4 General constraints

Thanks to Lora's network, an internet acces is not necessary to the app.

However, Lora's network is open, which means that it can't be monopolized. In order to use properly this network, the messages are limited in size and time on air. see this website for more precise info : [5]

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:

4. Product evolution

Add group