Projet-2016-2017-UltraTeam/SRS - Revision history

Romane.Gallier: /* 3.4 Requirement 1- Recuperation pulsation cardiaque via ceinture */

2017-02-05T09:51:26Z

3.4 Requirement 1- Recuperation pulsation cardiaque via ceinture

← Older revision		Revision as of 09:51, 5 February 2017
Line 179:		Line 179:
	==3.4 Requirement 1- Recuperation pulsation cardiaque via ceinture==		==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.
	'''Description''':

	'''Inputs''':		'''Inputs''': A bluetooth signal from the belt

	'''Outputs''':		'''Outputs''': a display on the screen

	'''Action''':
	*

	'''Non functional requirements''':

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

Romane.Gallier: /* 3.5 Requirement 1- Affichage des personnes emettant autour sur une carte */

2017-02-05T09:48:56Z

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

← Older revision		Revision as of 09:48, 5 February 2017
Line 192:		Line 192:
	==3.5 Requirement 1- Affichage des personnes emettant autour sur une carte==		==3.5 Requirement 1- Affichage des personnes emettant autour sur une carte==

	'''Description''':~~The~~ ~~phone~~ ~~application~~ ~~use~~ the ~~modem~~ to ~~send~~ is position		'''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 ~~phone~~		'''Inputs''': The GPS positions of the people around

	'''Outputs''': An ~~instruction~~ to the ~~modem~~		'''Outputs''': A display on the phone screen

	'''Action''':		'''Action''':
	*The GPS position is ~~recupered~~ and ~~send~~		The GPS position of the people are traited and placed on the screen


	'''Non functional requirements''':

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

			==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=		=4. Product evolution=

Romane.Gallier: /* 3.4 Requirement 1- Recuperation pulsation cardiaque via ceinture */

2017-02-05T09:43:38Z

3.4 Requirement 1- Recuperation pulsation cardiaque via ceinture

← Older revision		Revision as of 09:43, 5 February 2017
Line 190:		Line 190:
	'''Non functional requirements''':		'''Non functional requirements''':

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

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

Romane.Gallier: /* 3.2 Requirement 1- Position emisions by Lora-Mote */

2017-02-04T19:12:59Z

3.2 Requirement 1- Position emisions by Lora-Mote

← Older revision		Revision as of 19:12, 4 February 2017
Line 156:		Line 156:

	'''Outputs''': A lora signal containing the identifiers of the lora mote and it's GPS positions		'''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''':

			'''Inputs''':

			'''Outputs''':

			'''Action''':
			*

			'''Non functional requirements''':

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

			'''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''':		'''Action''':

Romane.Gallier: /* 3.1 Requirement X.Y.Z (in Structured Natural Language) */

2017-02-04T16:18:37Z

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

← Older revision		Revision as of 16:18, 4 February 2017
Line 145:		Line 145:

	'''Side-effects''':		'''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.

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

Alexandre.Ferrera: /* 2.5 Assumptions and dependencies */

2017-02-04T11:50:42Z

2.5 Assumptions and dependencies

← Older revision		Revision as of 11:50, 4 February 2017
Line 109:		Line 109:

	==2.5 Assumptions and dependencies==		==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=		=3.Specific requirements, covering functional, non-functional and interface requirements=
	* document external interfaces,		* document external interfaces,

Alexandre.Ferrera: /* 2.4 General constraints */

2017-02-04T11:42:36Z

2.4 General constraints

← Older revision		Revision as of 11:42, 4 February 2017
Line 105:		Line 105:

	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 : [https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300]		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 : [https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300]

			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==		==2.5 Assumptions and dependencies==

Alexandre.Ferrera: /* 2.4 General constraints */

2017-02-04T11:39:21Z

2.4 General constraints

← Older revision		Revision as of 11:39, 4 February 2017
Line 101:		Line 101:

	==2.4 General constraints==		==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 : [https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300]

	==2.5 Assumptions and dependencies==		==2.5 Assumptions and dependencies==
	=3.Specific requirements, covering functional, non-functional and interface requirements=		=3.Specific requirements, covering functional, non-functional and interface requirements=

Alexandre.Ferrera: /* 2.3 User characteristics */

2017-02-04T11:35:52Z

2.3 User characteristics

← Older revision		Revision as of 11:35, 4 February 2017
Line 91:		Line 91:

	==2.3 User characteristics==		==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==		==2.4 General constraints==
	==2.5 Assumptions and dependencies==		==2.5 Assumptions and dependencies==

Alexandre.Ferrera: /* 2.2 Product functions */

2017-02-04T11:23:35Z

2.2 Product functions

← Older revision		Revision as of 11:23, 4 February 2017
Line 88:		Line 88:


	In order to make the application easier to use, users should be able to ~~store~~ in it their personnal data.		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==		==2.3 User characteristics==