Anthony.Geourjon: /* 3.Specific requirements, covering functional, non-functional and interface requirements */

2017-02-06T08:28:06Z

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

@@ Line 174: / Line 174: @@
 '''Non functional requirements''':
 The message must be compact.
 =4. Product evolution=

Anthony.Geourjon: /* 3.Specific requirements, covering functional, non-functional and interface requirements */

2017-02-06T08:12:39Z

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

← Older revision		Revision as of 08:12, 6 February 2017
Line 155:		Line 155:

	'''Side-effects''':		'''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=		=4. Product evolution=

Anthony.Geourjon: /* 4. Product evolution */

2017-02-06T00:52:02Z

4. Product evolution

← Older revision		Revision as of 00:52, 6 February 2017
Line 158:		Line 158:
	=4. Product evolution=		=4. Product evolution=

	The project can become a base to develop more specific application. For example, we can imagine our application adapted to hunting with a group of ~~hunter~~ and a lot a dog. An other example is the use in ski station with some paths at the downhill and other with the time of climb of lifts (data deliver by the station).		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.		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.

	=5. Appendices=		=5. Appendices=

Anthony.Geourjon: /* 4. Product evolution */

2017-02-06T00:48:41Z

4. Product evolution

← Older revision		Revision as of 00:48, 6 February 2017
Line 157:		Line 157:

	=4. Product evolution=		=4. Product evolution=

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

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

	=5. Appendices=		=5. Appendices=

Clement.Rouquier: Created page with "'''Read first:''' * http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx * http://en.wikipedia.org/wiki/Software_requirements_specification * [http://www...."

2017-02-05T22:56:31Z

Created page with "'''Read first:''' * http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx * http://en.wikipedia.org/wiki/Software_requirements_specification * [http://www...."

New page

'''Read first:'''
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
* http://en.wikipedia.org/wiki/Software_requirements_specification
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

{|class="wikitable alternance"
|+ Document History
|-
|
!scope="col"| Version
!scope="col"| Date (DD/MM/AAAA)
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 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 [https://drive.google.com/open?id=0B_0n2CoDWpWQRXQzR0ZtQTM0Wlk Book] on [https://en.wikipedia.org/wiki/STM32 STM32], 32-bit microcontroller integrated circuits by STMicroelectronics
* A [https://fr.wikipedia.org/wiki/LoRaWAN LoRa] [https://partner.orange.com/wp-content/uploads/2016/04/LoRa-Device-Developer-Guide-Orange.pdf Documentation], provided by Orange
* Semtech LoraMote [http://www.semtech.com/images/datasheet/User_Guide_LoRaMote_STD.pdf Documentation]
* [http://air.imag.fr/index.php/Developping_IoT_Mashups_with_Docker,_MQTT,_Node-RED,_InfluxDB,_Grafana Developing IoT Mashups with Docker, MQTT, Node-RED, InfluxDB, Grafana]
* [http://air.imag.fr/index.php/Docker Docker]
* [http://air.imag.fr/index.php/MQTT MQTT]
* [http://air.imag.fr/index.php/Node-RED Node-RED]
* [http://air.imag.fr/index.php/InfluxDB InfluxDB]
* [http://air.imag.fr/index.php/Grafana Grafana]
* [http://air.imag.fr/index.php/Leaflet Leaflet]
* [http://air.imag.fr/index.php/Meteor Meteor]
* [https://github.com/Lora-net/LoRaMac-node 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''':

=4. Product evolution=

=5. Appendices=
=6. Index=

Projets-2016-2017-UltraTeamBest/SRS - Revision history

Anthony.Geourjon: /* 3.Specific requirements, covering functional, non-functional and interface requirements */

Anthony.Geourjon: /* 3.Specific requirements, covering functional, non-functional and interface requirements */

Anthony.Geourjon: /* 4. Product evolution */

Anthony.Geourjon: /* 4. Product evolution */

Clement.Rouquier: Created page with "'''Read first:''' * http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx * http://en.wikipedia.org/wiki/Software_requirements_specification * [http://www...."