RICM4 2017 2018 - UltraTeamMV : SRS: Difference between revisions

From air
Jump to navigation Jump to search
No edit summary
 
(25 intermediate revisions by the same user not shown)
Line 1: Line 1:
The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.
This document is inspired of the [http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf IEEE/ANSI 830-1998 Standard].


=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.


It will present our solution's functionalities and problem solved but also list our system requirements.
'''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]


==Scope of the product==
{|class="wikitable alternance"
This project consists of :
|+ Document History
* a LoRa and BLE protocol conception a and implementation,
|-
* a web application development.
|
This project should allow a hikers team to localise each other in real time.
!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


It should be really easy to add new members (Numeric code, QRCode, NFC, …).
|}



=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for project StartAir Safe.
In case of a open source project, we must present the requirement to others potential contributors. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 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.
The system should work whether or not there is a 2G/3G/4G or LoRa connection.


==1.3 Definitions, acronyms and abbreviations==
==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 23:
*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
==1.4 References==
==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


==1.5 Overview of the remainder of the document==
==Overview of the remainder of the document==


=2. General description=
=General description=
==2.1 Product perspective==
==Product perspective==
The product is supposed to be an open source.
Becoming a worldwide outdoor geolocation leader.


It is a web based system implementing client-server model. The UltraTeamMV System provides simple mechanism for outdoor geolocation in white & gray network areas.
==2.2 Product functions==

==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).


==2.3 User characteristics==
==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).


About age group, anyone that is comfortable with using a smartphone (hence ~15-70).
==2.4 General constraints==

==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.


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


=3.Specific requirements, covering functional, non-functional and interface requirements=
=Specific 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.


'''This section will describe two types of requirements : '''
* User requirements
* User requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
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 [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeamMV_:_UML#Case_details use case section of the UML page of the project].'''
* 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.


==Requirement 1 : BLE connection establishment ==
'''Those requirement will be classified in 3 categories :'''
* Functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. It may also state what the system should not do.


'''Function''':
* Non-functional requirements
BLE connection establishment.
Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.


'''Description''':
* Domain requirements
Establish a BLE connection between a smartphone and an ESP32.
Constraints on the system from the domain of operation.


'''Inputs''':
Smartphone.


'''Source''':
None.


'''Outputs''':
An established BLE connection between ESP & smartphone.


'''Destination''':
* document external interfaces,
None.
* describe system functionality and performance

* specify logical database requirements,
'''Action''':
* design constraints,
# Identify which devices to connect via smartphone.
* emergent system properties and quality characteristics.
# 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) ==
==3.0 Template : Requirement X.Y.Z (in Structured Natural Language)==
'''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 state, a signal 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.

==Requirement 4 : Distress signal forwarding (ESP32 ⇶) ==
'''Function''':
Distress signal forwarding via broadcast by ESP32.

'''Description''':
An ESP21 detects a distress signal, it should immediately be broadcasted to other users' ESP32.

'''Inputs''':
A distress signal.

'''Source''':
User's ESP32.

'''Outputs''':
A distress signal.
'''Destination''':
Other users' 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 LoRa communication priority. ESP can send signal more than 1% of the time via LoRa.

'''Pre-condition''':
None.

'''Post-condition''':
None.

'''Side-effects''':
None.

==Requirement 5 : Geolocation signal broadcasting (ESP32 ⇶)==
'''Function''':
Geolocation signal broadcasting from ESP32 via LoRa

'''Description''':
To be known from other ESP32, a geolocation must be broadcasted via LoRa.

'''Inputs''':
A geolocation information.

'''Source''':
ESP32.

'''Outputs''':
A geolocation signal.

'''Destination''':
LoRa broadcast.

'''Action''':
# Forge LoRa packet,
# Send LoRa packet.

'''Non functional requirements''':
ESP can send signal more than 1% of the time via LoRa.

'''Pre-condition''':
ESP32 has a geolocation information to send.

'''Post-condition''':
None.

'''Side-effects''':
None.

==Requirement 6 : Geolocation signal transmission (Smartphone → ESP32) ==
'''Function''':
Geolocation signal transmission from smartphone to ESP32 via BLE.

'''Description''':
To be able to send geolocation information, ESP32 must be aware of it. Thus, user's smartphone should be able to transmit it to ESP32 via BLE.

'''Inputs''':
A geolocation information.

'''Source''':
User's smartphone.

'''Outputs''':
A geolocation information.

'''Destination''':
User's ESP32.

'''Action''':
# Forge BLE packet,
# Send BLE packet.

'''Non functional requirements''':
None.

'''Pre-condition''':
A geolocation information is available on smartphone.

'''Post-condition''':
None.

'''Side-effects''':
None.

==Requirement 7 : Information upload (Smartphone → server)==
'''Function''':
User's smartphone information upload to server via HTTP (RESTful API)

'''Description''':
To transfer information via 3G/4G, smartphone should be able to send information to server. It is done via a RESTful API.

'''Inputs''':
A list of users (UID, name, Geolocation, potential distress state).

'''Source''':
User's smartphone.

'''Outputs''':
An update on users list.
'''Destination''':
Server.

'''Action''':
# List every changes since last update.
# For each, forge an API request.
# Send requests.

'''Non functional requirements''':
None.

'''Pre-condition''':
Smartphone should have a working 3G/4G connection.

'''Post-condition''':
None.

'''Side-effects''':
None.

==Requirement 8 : Distress signal transmission (Smartphone → server)==
'''Function''':
Distress signal transmission from smartphone to server via HTTP (RESTful API).

'''Description''':
A distress signal should be, if possible, transferred via 3G/4G. It is done via a RESTful API.

'''Inputs''':
A distress signal.

'''Source''':
User's smartphone.

'''Outputs''':
A distress signal.
'''Destination''':
Server.

'''Action''':
# Detect distress signal,
# Parse distress signal (which is the corresponding location and UID ?),
# Forge corresponding BLE packet,
# Forge an API request,
# Send request.

'''Non functional requirements''':
None.

'''Pre-condition''':
Smartphone should have a working 3G/4G connection.

'''Post-condition''':
None.

'''Side-effects''':
None.

==Requirement 9 : Server information download==
'''Function''':
Server information download by smartphone via HTTP (RESTful API)

'''Description''':
To be able to receive 3G/4G-transmitted information, user's smartphone should be able to receive updates from server.

'''Inputs''':
A list of users (UID, name, Geolocation, potential distress state).

'''Source''':
Server.

'''Outputs''':
A user(s) update.

'''Destination''':
Smartphone.

'''Action''':
# Smartphone forges an update API request,
# Server sends update as request response,
# Smartphones parses response.

'''Non functional requirements''':
None.

'''Pre-condition''':
Smartphone should have a working 3G/4G connection.

'''Post-condition''':
None.

'''Side-effects''':
None.

==Requirement 10 : Geolocation information retrievement ==
'''Function''':
Geolocation information retrievement on smartphone via GPS.

'''Description''':
To be able to locate its device, one's smartphone should be able to retrieve its geolocation. It is done via GPS.

'''Inputs''':
None.

'''Source''':
Satellite.

'''Outputs''':
Geolocation information.

'''Destination''':
Smartphone.

'''Action''':
# Smartphone retrieves its geolocation via GPS communication with satellite.

'''Non functional requirements''':
None.

'''Pre-condition''':
None.

'''Post-condition''':
None.

'''Side-effects''':
None.

==Template : Requirement X.Y.Z (in Structured Natural Language)==
'''Function''':
'''Function''':


Line 128: Line 460:
'''Side-effects''':
'''Side-effects''':


=4. Product evolution=
=Product evolution=


=5. Appendices=
=Appendices=
'''SRS related documents used to establish this page:'''
* 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]

Latest revision as of 15:14, 23 February 2018

This document is inspired of the IEEE/ANSI 830-1998 Standard.

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 consists of :

  • a LoRa and BLE protocol conception a and implementation,
  • a web application development.

This project 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€.

About age group, anyone 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

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:

  1. Identify which devices to connect via smartphone.
  2. 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:

  1. Detect distress signal,
  2. Parse distress signal (is it from user's ESP or from another ESP ? Which is the corresponding location and UID ?),
  3. Forge corresponding BLE packet,
  4. 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 state, a signal 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:

  1. Detect distress signal,
  2. Parse distress signal (which is the corresponding location and UID ?),
  3. Forge corresponding BLE packet,
  4. 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 4 : Distress signal forwarding (ESP32 ⇶)

Function: Distress signal forwarding via broadcast by ESP32.

Description: An ESP21 detects a distress signal, it should immediately be broadcasted to other users' ESP32.

Inputs: A distress signal.

Source: User's ESP32.

Outputs: A distress signal.

Destination: Other users' ESP32.

Action:

  1. Detect distress signal,
  2. Parse distress signal (which is the corresponding location and UID ?),
  3. Forge corresponding BLE packet,
  4. Send said packet.

Non functional requirements: This transmission should be above all in LoRa communication priority. ESP can send signal more than 1% of the time via LoRa.

Pre-condition: None.

Post-condition: None.

Side-effects: None.

Requirement 5 : Geolocation signal broadcasting (ESP32 ⇶)

Function: Geolocation signal broadcasting from ESP32 via LoRa

Description: To be known from other ESP32, a geolocation must be broadcasted via LoRa.

Inputs: A geolocation information.

Source: ESP32.

Outputs: A geolocation signal.

Destination: LoRa broadcast.

Action:

  1. Forge LoRa packet,
  2. Send LoRa packet.

Non functional requirements: ESP can send signal more than 1% of the time via LoRa.

Pre-condition: ESP32 has a geolocation information to send.

Post-condition: None.

Side-effects: None.

Requirement 6 : Geolocation signal transmission (Smartphone → ESP32)

Function: Geolocation signal transmission from smartphone to ESP32 via BLE.

Description: To be able to send geolocation information, ESP32 must be aware of it. Thus, user's smartphone should be able to transmit it to ESP32 via BLE.

Inputs: A geolocation information.

Source: User's smartphone.

Outputs: A geolocation information.

Destination: User's ESP32.

Action:

  1. Forge BLE packet,
  2. Send BLE packet.

Non functional requirements: None.

Pre-condition: A geolocation information is available on smartphone.

Post-condition: None.

Side-effects: None.

Requirement 7 : Information upload (Smartphone → server)

Function: User's smartphone information upload to server via HTTP (RESTful API)

Description: To transfer information via 3G/4G, smartphone should be able to send information to server. It is done via a RESTful API.

Inputs: A list of users (UID, name, Geolocation, potential distress state).

Source: User's smartphone.

Outputs: An update on users list.

Destination: Server.

Action:

  1. List every changes since last update.
  2. For each, forge an API request.
  3. Send requests.

Non functional requirements: None.

Pre-condition: Smartphone should have a working 3G/4G connection.

Post-condition: None.

Side-effects: None.

Requirement 8 : Distress signal transmission (Smartphone → server)

Function: Distress signal transmission from smartphone to server via HTTP (RESTful API).

Description: A distress signal should be, if possible, transferred via 3G/4G. It is done via a RESTful API.

Inputs: A distress signal.

Source: User's smartphone.

Outputs: A distress signal.

Destination: Server.

Action:

  1. Detect distress signal,
  2. Parse distress signal (which is the corresponding location and UID ?),
  3. Forge corresponding BLE packet,
  4. Forge an API request,
  5. Send request.

Non functional requirements: None.

Pre-condition: Smartphone should have a working 3G/4G connection.

Post-condition: None.

Side-effects: None.

Requirement 9 : Server information download

Function: Server information download by smartphone via HTTP (RESTful API)

Description: To be able to receive 3G/4G-transmitted information, user's smartphone should be able to receive updates from server.

Inputs: A list of users (UID, name, Geolocation, potential distress state).

Source: Server.

Outputs: A user(s) update.

Destination: Smartphone.

Action:

  1. Smartphone forges an update API request,
  2. Server sends update as request response,
  3. Smartphones parses response.

Non functional requirements: None.

Pre-condition: Smartphone should have a working 3G/4G connection.

Post-condition: None.

Side-effects: None.

Requirement 10 : Geolocation information retrievement

Function: Geolocation information retrievement on smartphone via GPS.

Description: To be able to locate its device, one's smartphone should be able to retrieve its geolocation. It is done via GPS.

Inputs: None.

Source: Satellite.

Outputs: Geolocation information.

Destination: Smartphone.

Action:

  1. Smartphone retrieves its geolocation via GPS communication with satellite.

Non functional requirements: None.

Pre-condition: None.

Post-condition: None.

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:

Product evolution

Appendices

SRS related documents used to establish this page:

Retrieved from "https://air.imag.fr/index.php?title=RICM4_2017_2018_-_UltraTeamMV_:_SRS&oldid=40082"