Projet-2016-2017-UltraTeam/SRS

From air
Jump to: navigation, search
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]

1.5 Overview of the remainder of the document

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]

If the user has no internet connectivity (frequent situation during a trail), he will need Lora's equipments to communicate.

2.5 Assumptions and dependencies

We can assume that this application will only be used on a phone. It shouldn't need too high performances but a connection through the usb socket is necessary to receive data from other members, and to send them your information (excepted the position, which is communicated through the LoraMote)

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 1- Position emisions by Lora-Mote

Description:The Lora-Mote send in Broad Cast is GPS position.

Inputs: The GPS positions of the lora mote

Source: LoraMote

Outputs: A lora signal containing the identifiers of the lora mote and it's GPS positions

Action:

  • The GPS position is recupered and send

Non functional requirements: The message should be small and the frequenties width should be occuped less than 1/100 of the time.

3.3 Requirement 1- Position emisions by telephone

Description:The phone application use the modem to send is position

Inputs: The GPS positions of the phone

Outputs: An instruction to the modem

Action:

  • The GPS position is recupered and send

Non functional requirements: The message should be small and the frequenties width should be occuped less than 1/100 of the time.

3.4 Requirement 1- Recuperation pulsation cardiaque via ceinture

Description: Si l'utilisateur porte une ceinture qui permet de recuperer son pouls cardiaque elle pourra etre sychronises a l'application de tel sorte a ce que les données puisse etre afficher, mais aussi partager via le reseau choisi.

Inputs: A bluetooth signal from the belt

Outputs: a display on the screen

3.5 Requirement 1- Affichage des personnes emettant autour sur une carte

Description: Display on telephone screen a map with the different people around it place on it thanks to her GPS position.

Inputs: The GPS positions of the people around

Outputs: A display on the phone screen

Action: The GPS position of the people are traited and placed on the screen



3.6 Requirement 1- Choix du reseau disponible

Description:Allow the phone application to choose one available network to send and receive the data

Inputs: The different network available for the phone

Outputs: The most efficient network

Action:

  • The phone analyse the different network available and choose one of them.

4. Product evolution

Add group

5. Appendices

6. Index