Difference between revisions of "RICM4 2017 2018 - UltraTeamMV/ SRS"

From air
Jump to navigation Jump to search
m
 
(6 intermediate revisions by 2 users not shown)
Line 40: Line 40:
   
 
==1.3 Definitions, acronyms and abbreviations==
  
==1.3 Definitions, acronyms and abbreviations==
−
LoRa = Long Range : communication technology (“”””upgraded””””” bluetooth)
 +
*LoRa = '''L'''ong '''R'''ange : Low powered radio based communication technology
−
LoRaWAN = Long Range Wide Area Networks : 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
  +
*LPWAN = '''L'''ow '''P'''owered '''W'''ide '''A'''rea '''N'''etworks
−
LPWAN = Low Powered Wide Area Networks
  
  +
*BLE = '''B'''luetooth '''L'''ow '''E'''nergy
−
BLE = Bluetooth Low Energy
  
  +
*GPS = '''G'''lobal '''P'''ositioning '''S'''ystem
−
GPS = Global Positioning System
 
 
==1.4 References==
  
==1.4 References==
−
*The main page of the project: [[Proj-2013-2014-StartAIR-2]]
 +
*The main page of the project [http://air.imag.fr/index.php/UltraTeam]
   
 
==1.5 Overview of the remainder of the document==
  
==1.5 Overview of the remainder of the document==
Line 73: Line 73:
   
 
=3.Specific requirements, covering functional, non-functional and interface requirements=
  
=3.Specific requirements, covering functional, non-functional and interface requirements=
  +
  +
'''This section will describe two types of requirements : '''
  +
* User requirements
  +
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
  +
  +
* 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.
  +
  +
'''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.
  +
  +
* Non-functional requirements
  +
Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
  +
  +
* Domain requirements
  +
Constraints on the system from the domain of operation.
  +
  +
  +
  +
 
* document external interfaces,
  
* document external interfaces,
 
* describe system functionality and performance
  
* describe system functionality and performance
Line 79: Line 100:
 
* emergent system properties and quality characteristics.
  
* emergent system properties and quality characteristics.
   
−
==3.1 Requirement X.Y.Z (in Structured Natural Language)==
 +
==3.0 Template : Requirement X.Y.Z (in Structured Natural Language)==
 
'''Function''':
  
'''Function''':
   

Latest revision as of 16:47, 11 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:

Document History
Version Date Authors Description Validator Validation Date
0.1.0 TBC TBC TBC TBC TBC


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.

1.3 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

1.4 References

  • The main page of the project [1]

1.5 Overview of the remainder of the document

2. General description

2.1 Product perspective

Becoming a worldwide outdoor geolocation leader.

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

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

2.4 General constraints

The system should work whether or not there is a 2G/3G/4G connection Limited localisation accuracy : GPS.

2.5 Assumptions and dependencies

As few environnement assumptions as possible. 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

This section will describe two types of requirements :

  • User requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

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

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.

  • Non-functional requirements

Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

  • Domain requirements

Constraints on the system from the domain of operation.



  • document external interfaces,
  • describe system functionality and performance
  • specify logical database requirements,
  • design constraints,
  • emergent system properties and quality characteristics.

3.0 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:

4. Product evolution

5. Appendices

5.1. SRS structure

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

References:

6. Index

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