Proj-2015-2016-IndoorGeoloc/SRS - Revision history

Imad-Seddik.Arrada at 07:33, 6 April 2016

2016-04-06T07:33:42Z

← Older revision		Revision as of 07:33, 6 April 2016
Line 162:		Line 162:
	* Improving the localisation (more precise)		* Improving the localisation (more precise)
	* Finding a way to putting up with signal mitigations		* Finding a way to putting up with signal mitigations
	=5. Appendices=
	=6. Index=

Imad-Seddik.Arrada at 07:32, 6 April 2016

2016-04-06T07:32:25Z

← Older revision		Revision as of 07:32, 6 April 2016
Line 109:		Line 109:
	'''Function''': fetching data from the database, sending it to the rightful device		'''Function''': fetching data from the database, sending it to the rightful device

			'''Description''': using MQTT, the server access the database in order to fetch the last or any position at a given date, it then publishes the position of a beacon on a specified topic permitting the clients subscribing to the topic to receive the location.
	'''Description''':

	'''Inputs''':		'''Inputs''': computed distance

			'''Source''': Database containing every the location of all the beacons
	'''Source''':

			'''Outputs''': Every location of the beacons are delivered to the right topics.
	'''Outputs''':

	'''Destination''':		'''Destination''': The Android clients

	'''Action''':		'''Action''':
			* Fetching and sending the location to the Android devices



	'''Non functional requirements''':		'''Non functional requirements''':

	'''Pre-condition''':		'''Pre-condition''': The database in non empty, the android clients are connected to internet

	'''Post-condition''':		'''Post-condition''':
Line 131:		Line 131:
	'''Side-effects''':		'''Side-effects''':

	==3.3 Requirement 3 : Rendering the received data on a map on Android ~~smartphone~~ ==		==3.3 Requirement 3 : Rendering the received data on a map on Android smartphones ==
	'''Function''': using the received data ~~ton~~ display the information into a map		'''Function''': using the received data in order to display the information into a map

			'''Description''': The Android client receives locations of beacons thanks to the subscribe method. It uses the OSMDroid API tu display the items on a map.
	'''Description''':

	'''Inputs''':		'''Inputs''': Beacons location as markers

			'''Source''': The server publishing the locations on the different topics.
	'''Source''':

	'''Outputs''':		'''Outputs''': A map displaying every beacon

	'''Destination''':		'''Destination''': The Android smartphone

	'''Action''':		'''Action''':
			* Rendering the beacons on the map by marking them in an overlay.



	'''Non functional requirements''':		'''Non functional requirements''':

	'''Pre-condition''':		'''Pre-condition''': The positions are not ambiguous, not duplicated.

	'''Post-condition''':		'''Post-condition''': Every beacon has its representative figure on the screen

	'''Side-effects''':		'''Side-effects''':
Line 158:		Line 158:
	=4. Product evolution=		=4. Product evolution=

			* Having a better rendering of the map, more interactive
			* Using different detecting sensors
			* Improving the localisation (more precise)
			* Finding a way to putting up with signal mitigations
	=5. Appendices=		=5. Appendices=
	=6. Index=		=6. Index=

Imad-Seddik.Arrada at 05:41, 6 April 2016

2016-04-06T05:41:06Z

@@ Line 45: / Line 45: @@
 * OpenStreetMap (OSM) : is a collaborative project to create a free editable map of the world.
 * STM32 is a family of 32-bit microcontroller integrated circuits by STMicroelectronics. The STM32 chips are grouped into related series that are based around the same 32-bit ARM processor core, such as the Cortex-M7, Cortex-M4F, Cortex-M3, Cortex-M0+, or Cortex-M0. Internally, each microcontroller consists of the processor core, static RAM memory, flash memory, debugging interface, and various peripherals.
-* Arduino : Programmable microcontroller able to generate and analyse electric signals. For our project, the Arduino get the measures from the HB100 sensor. Once the voltage and frequency values are available, they are transformed into distance and speed values, and send to the Raspberry by serial link.
+* Arduino : Programmable microcontroller able to generate and analyse electric signals. The Arduino measures the BLE signals. Data is sent to a server which will compute a distance.
-* Raw data : Data returned by the sensor and send to the Arduino.
+* Raw data : Data returned by the sensor sent to the server computing the distance.
 ==1.4   References==
@@ Line 81: / Line 81: @@
 * emergent system properties and quality characteristics.
-==3.1 Requirement X.Y.Z (in Structured Natural Language)==
+==3.1 Requirement 1 : acquisition of data with computation of distance ==
-'''Inputs''':
+'''Inputs''': BLE signals
-'''Source''':
+'''Source''': TI beacons, iTag
-'''Outputs''':
+'''Outputs''': database with distance computation for a beacon
 '''Action''':
-'''Post-condition''':
+'''Pre-condition''': identifiers between beacons must be unique
-'''Side-effects''':
+'''Post-condition''':
 =4. Product evolution=

Imad-Seddik.Arrada: re

2016-04-06T04:47:38Z

← Older revision		Revision as of 04:47, 6 April 2016
Line 59:		Line 59:
	=2. General description=		=2. General description=
	==2.1 Product perspective==		==2.1 Product perspective==
			The product is meant to be enabling people to locate things into a building. The user interface will contain a list of emitting beacons, a map where these beacons are located. The hardware interface contains a flow of data that a server receives and use in order to mesure the RSSI distance of the object. The freshly computed position is saved into a databased which is accessible from another side of the server. That server will send the data to Android clients via the MQTT protocol.


	==2.2 Product functions==		==2.2 Product functions==
			* Locate objects on a map

			* Locate people on a map
			* Find a way to get to the located object

	==2.3 User characteristics==		==2.3 User characteristics==
			The application can be used by anyone who wants to locate things emitting bluetooth (BLE) waves. The user has to be connected to internet. The user must have an Android smartphone (version 4.4.4 KitKat minimum), but we hope that in the future this application can be developped for any smartphone OS.

		⚫	==2.4 General constraints==
			* The use of the STM32 board are a constraint, they can detect only BLE waves.
			* Developped in Java
			* Network connexion strong and unfiltering the opening of ports

⚫	==2.4 General constraints==
	==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=
	* document external interfaces,		* document external interfaces,

Imad-Seddik.Arrada at 22:48, 5 April 2016

2016-04-05T22:48:00Z

@@ Line 20: / Line 20: @@
  !scope="row" |
  | 0.1.0
- | TBC
+ | 18/01/2016
  | TBC
  | TBC
@@ Line 31: / Line 31: @@
 =1.   Introduction=
 ==1.1   Purpose of the requirements document==
 ==1.2   Scope of the product==
 ==1.3   Definitions, acronyms and abbreviations==
 ==1.4   References==
 ==1.5   Overview of the remainder of the document==
 =2.   General description=
 ==2.1   Product perspective==
 ==2.2   Product functions==
 ==2.3   User characteristics==
 ==2.4   General constraints==
 ==2.5   Assumptions and dependencies==

Imad-Seddik.Arrada: Created page with "The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard. '''Read first:''' * http://www.cs.st-an..."

2016-04-05T20:51:59Z

Created page with "The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard. '''Read first:''' * http://www.cs.st-an..."

New page

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.

'''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
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}

=1. Introduction=
==1.1 Purpose of the requirements document==
==1.2 Scope of the product==
==1.3 Definitions, acronyms and abbreviations==
==1.4 References==
==1.5 Overview of the remainder of the document==
=2. General description=
==2.1 Product perspective==
==2.2 Product functions==
==2.3 User characteristics==
==2.4 General constraints==
==2.5 Assumptions and dependencies==
=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=