Difference between revisions of "RICM4 2017 2018 - UltraTeamMV : SRS"
Enzo.Molion (talk | contribs) (3.3 Requirement 3 : Distress signal transmission (ESP32 → smartphone)) |
Enzo.Molion (talk | contribs) (Removed trailing numbers) |
||
Line 29: | Line 29: | ||
− | = |
+ | =Introduction= |
− | == |
+ | ==Purpose of the requirements document== |
This Software Requirements Specification (SRS) identifies the requirements for project [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] project. |
This Software Requirements Specification (SRS) identifies the requirements for project [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV UltraTeamMV] project. |
||
It will present our solution's functionalities and problem solved but also list our system requirements. |
It will present our solution's functionalities and problem solved but also list our system requirements. |
||
− | == |
+ | ==Scope of the product== |
This project mainly consists of a web application development. This app should allow a hikers team to localise each other in real time. |
This project mainly consists of a web application development. This app should allow a hikers team to localise each other in real time. |
||
It should be really easy to add new members (Numeric code, QRCode, NFC, …). |
It should be really easy to add new members (Numeric code, QRCode, NFC, …). |
||
The system should work whether or not there is a 2G/3G/4G or LoRa connection. |
The system should work whether or not there is a 2G/3G/4G or LoRa connection. |
||
− | == |
+ | ==Definitions, acronyms and abbreviations== |
*LoRa = '''L'''ong '''R'''ange : Low powered radio based communication technology |
*LoRa = '''L'''ong '''R'''ange : Low powered radio based communication technology |
||
*LoRaWAN = '''L'''ong '''R'''ange '''W'''ide '''A'''rea '''N'''etworks : LoRa overlayer to ease (& securise) LoRa communication implementation |
*LoRaWAN = '''L'''ong '''R'''ange '''W'''ide '''A'''rea '''N'''etworks : LoRa overlayer to ease (& securise) LoRa communication implementation |
||
Line 45: | Line 45: | ||
*BLE = '''B'''luetooth '''L'''ow '''E'''nergy |
*BLE = '''B'''luetooth '''L'''ow '''E'''nergy |
||
*GPS = '''G'''lobal '''P'''ositioning '''S'''ystem |
*GPS = '''G'''lobal '''P'''ositioning '''S'''ystem |
||
− | == |
+ | ==References== |
* The [http://air.imag.fr/index.php/UltraTeam main page] of the project |
* The [http://air.imag.fr/index.php/UltraTeam main page] of the project |
||
* The [http://air.imag.fr/index.php/UltraTeam_:_UML UML] page |
* The [http://air.imag.fr/index.php/UltraTeam_:_UML UML] page |
||
− | == |
+ | ==Overview of the remainder of the document== |
− | = |
+ | =General description= |
− | == |
+ | ==Product perspective== |
The product is supposed to be an open source. |
The product is supposed to be an open source. |
||
It is a web based system implementing client-server model. The UltraTeamMV System provides simple mechanism for outdoor geolocation in white & gray network areas. |
It is a web based system implementing client-server model. The UltraTeamMV System provides simple mechanism for outdoor geolocation in white & gray network areas. |
||
− | == |
+ | ==Product functions== |
This system should allow low energy cost localisation. |
This system should allow low energy cost localisation. |
||
It should be decentralized as 2G/3G/4G network is sporadic in such environnement. |
It should be decentralized as 2G/3G/4G network is sporadic in such environnement. |
||
It should also centralize all data to allow sending it to appropriate services (rescue team for instance). |
It should also centralize all data to allow sending it to appropriate services (rescue team for instance). |
||
− | == |
+ | ==User characteristics== |
Hikers team, comfortable with using a smartphone but not a technology expert. |
Hikers team, comfortable with using a smartphone but not a technology expert. |
||
No financial criteria other than having a smartphone as an ESP32 costs about 5€. |
No financial criteria other than having a smartphone as an ESP32 costs about 5€. |
||
Age group = any that is comfortable with using a smartphone hence (~15-70). |
Age group = any that is comfortable with using a smartphone hence (~15-70). |
||
− | == |
+ | ==General constraints== |
The system should work whether or not there is a 2G/3G/4G connection |
The system should work whether or not there is a 2G/3G/4G connection |
||
Limited localisation accuracy : GPS. |
Limited localisation accuracy : GPS. |
||
− | == |
+ | ==Assumptions and dependencies== |
As few environnement assumptions as possible. |
As few environnement assumptions as possible. |
||
A team needs at least 1 smartphone (with GPS connection) and 1 ESP32 per hiker. |
A team needs at least 1 smartphone (with GPS connection) and 1 ESP32 per hiker. |
||
− | = |
+ | =Specific requirements, covering functional, non-functional and interface requirements= |
'''This section is supposed to describe two types of requirements : ''' |
'''This section is supposed to describe two types of requirements : ''' |
||
Line 85: | Line 85: | ||
'''Those user requirements are described in [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV_:_UML#Case_details use case section of the UML page of the project].''' |
'''Those user requirements are described in [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV_:_UML#Case_details use case section of the UML page of the project].''' |
||
− | == |
+ | ==Requirement 1 : BLE connection establishment == |
'''Function''': |
'''Function''': |
||
Line 123: | Line 123: | ||
None. |
None. |
||
− | == |
+ | ==Requirement 2 : Distress signal transmission (ESP32 → smartphone) == |
'''Function''': |
'''Function''': |
||
Distress signal transmission from ESP32 to smartphone via BLE. |
Distress signal transmission from ESP32 to smartphone via BLE. |
||
Line 160: | Line 160: | ||
None. |
None. |
||
− | == |
+ | ==Requirement 3 : Distress signal transmission (smartphone → ESP32) == |
'''Function''': |
'''Function''': |
||
Distress signal transmission from smartphone to ESP32 via BLE. |
Distress signal transmission from smartphone to ESP32 via BLE. |
||
Line 197: | Line 197: | ||
None. |
None. |
||
− | == |
+ | ==Template : Requirement X.Y.Z (in Structured Natural Language)== |
'''Function''': |
'''Function''': |
||
Line 224: | Line 224: | ||
'''Side-effects''': |
'''Side-effects''': |
||
− | = |
+ | =Product evolution= |
− | = |
+ | =Appendices= |
Revision as of 18:34, 18 February 2018
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
- IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998
Version | Date | Authors | Description | Validator | Validation Date | |
---|---|---|---|---|---|---|
0.1.0 | TBC | TBC | TBC | TBC | TBC |
Introduction
Purpose of the requirements document
This Software Requirements Specification (SRS) identifies the requirements for project UltraTeamMV project. It will present our solution's functionalities and problem solved but also list our system requirements.
Scope of the product
This project mainly consists of a web application development. This app should allow a hikers team to localise each other in real time. It should be really easy to add new members (Numeric code, QRCode, NFC, …). The system should work whether or not there is a 2G/3G/4G or LoRa connection.
Definitions, acronyms and abbreviations
- LoRa = Long Range : Low powered radio based communication technology
- LoRaWAN = Long Range Wide Area Networks : LoRa overlayer to ease (& securise) LoRa communication implementation
- LPWAN = Low Powered Wide Area Networks
- BLE = Bluetooth Low Energy
- GPS = Global Positioning System
References
Overview of the remainder of the document
General description
Product perspective
The product is supposed to be an open source. It is a web based system implementing client-server model. The UltraTeamMV System provides simple mechanism for outdoor geolocation in white & gray network areas.
Product functions
This system should allow low energy cost localisation. It should be decentralized as 2G/3G/4G network is sporadic in such environnement. It should also centralize all data to allow sending it to appropriate services (rescue team for instance).
User characteristics
Hikers team, comfortable with using a smartphone but not a technology expert. No financial criteria other than having a smartphone as an ESP32 costs about 5€. Age group = any that is comfortable with using a smartphone hence (~15-70).
General constraints
The system should work whether or not there is a 2G/3G/4G connection Limited localisation accuracy : GPS.
Assumptions and dependencies
As few environnement assumptions as possible. A team needs at least 1 smartphone (with GPS connection) and 1 ESP32 per hiker.
Specific requirements, covering functional, non-functional and interface requirements
This section is supposed to describe two types of requirements :
- System requirements
A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.
- User requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
Those user requirements are described in use case section of the UML page of the project.
Requirement 1 : BLE connection establishment
Function: BLE connection establishment.
Description: Establish a BLE connection between a smartphone and an ESP32.
Inputs: Smartphone.
Source: None.
Outputs: An established BLE connection between ESP & smartphone.
Destination: None.
Action:
- Identify which devices to connect via smartphone.
- Connect the two devices.
Non functional requirements: Connection should be established in less than 1 min.
Pre-condition:
- ESP32 & Smartphone are on, with BLE running,
- ESP32 & Smartphone are near enough to communicate via BLE.
- BLE on ESP32 & smartphone should be technologically able to communicate
Post-condition: ESP32 and smartphone are connected via BLE.
Side-effects: None.
Requirement 2 : Distress signal transmission (ESP32 → smartphone)
Function: Distress signal transmission from ESP32 to smartphone via BLE.
Description: As an ESP32 detects a distress signal, it should immediately be transferred to user's smartphone.
Inputs: A distress signal.
Source: User's ESP32.
Outputs: A distress signal.
Destination: User's smartphone.
Action:
- Detect distress signal,
- Parse distress signal (is it from user's ESP or from another ESP ? Which is the corresponding location and UID ?),
- Forge corresponding BLE packet,
- Send said packet.
Non functional requirements: This transmission should be above all in BLE communication priority.
Pre-condition: ESP32 & Smartphone should be connected via BLE.
Post-condition: Both smartphone and ESP32 are aware of the other user's distress state.
Side-effects: None.
Requirement 3 : Distress signal transmission (smartphone → ESP32)
Function: Distress signal transmission from smartphone to ESP32 via BLE.
Description: As a smartphone detects a distress signal, it should immediately be transferred to user's ESP32.
Inputs: A distress signal.
Source: User's smartphone.
Outputs: A distress signal.
Destination: User's ESP32.
Action:
- Detect distress signal,
- Parse distress signal (which is the corresponding location and UID ?),
- Forge corresponding BLE packet,
- Send said packet.
Non functional requirements: This transmission should be above all in BLE communication priority.
Pre-condition: ESP32 & Smartphone should be connected via BLE.
Post-condition: Both smartphone and ESP32 are aware of the other user's distress state.
Side-effects: None.
Template : 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: