Projets-2016-2017-UntraTeamBest
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 (DD/MM/AAAA) | Authors | Description | Validator | Validation Date | |
---|---|---|---|---|---|---|
0.1.0 | 05/02/2017 | Clément Rouquier & Anthony Geourjon ( senseix ) | SRS's first version | TBC | TBC |
1. Introduction
1.1 Purpose of the requirements document
This document aims to clearly define requirements, and so features, for our application, both functional and not-functional. Features presented here are the atomic core of the future application.
1.2 Scope of the product
The scope of the product is to make an application onwhich members of a same network would be able to locate and exchange datas with each other equiped member. This has to be possible for every users (depending on their own equipment) regardless of natural conditions (Weather, Relief) nor network coverage of the area. Optionnal equipement would allow more data knowledge. Scope users could be:
- Trailers: Be able to locate themselves, and have a constant possibility of contact with organization team.
- Hunters: Have a direct visualization of the area covered during a try to regroup beasts. It's also a safety measure to don't shoot an human.
- Hikers: For organisms like UCPA, could be used to watch children during hiking, preventing any losts. New activities could be created thanks to the application, which only create an easy way to take care of every child at once.
-> Urgent signals such as SOS are features specifically for these users.
1.3 Definitions, acronyms and abbreviations
- GPS: Globaml Positionning System
- LoRaMote: Device able to broadcast his own position using the LoRaNetwork and GPS
- Module RN2483: Communication module able to send date at specific frequencies, using a USB Sserie-port
- Group: Network of users, contain at least a Receiver.
- Users: General term for all members of a group
- Receivers: Specific users: Have at least an Android Phone with the application running, a LoRaMote and (optionnal) a Module RN2483. They are able to send and receive data
- Senders: Speciific users: Have at least a LoRaMote and (optionnal) a Module RN2483. Are only able to send their own data.
1.4 References
This is the first year this projet is conducted, and so we do not have previous bases for this specific project. Although, here's an non-exhaustive list of documentation on technologies which are going to be in use:
- A Book on STM32, 32-bit microcontroller integrated circuits by STMicroelectronics
- A LoRa Documentation, provided by Orange
- Semtech LoraMote Documentation
- Developing IoT Mashups with Docker, MQTT, Node-RED, InfluxDB, Grafana
- Docker
- MQTT
- Node-RED
- InfluxDB
- Grafana
- Leaflet
- Meteor
- Code de Base
1.5 Overview of the remainder of the document
In the following parts of the documents, specific features and constraints of usage are detailled. It also quantify the importance of every single one. Finally, ideas of future development are included.
2. General description
2.1 Product perspective
The product will manage a group. Each user has
- A LoRaMote device, making him visible for each receiver.
-> Availability to keep receivers informs on its own position through Lora Network
-> Can manually launch specific signals such as SOS
Each receiver has:
- (Optional) A bluetooth equipement such as GPS watch or cardio belt.
- Module RN2483
- An Android Running and Bluetooth friendly Smartphone
-> Availability to keep other receivers informs on its own position and various data through 3G or Lora Network
-> Can catch and display on the Smartphone information broadcasted by all users.
-> Can interact with other receivers for specific information
Public Restrictions
LoRa Network uses Public Radio Frequencies, and so the traffic on these frequencies is limited. The application has to be data-friendly in order to respect these regulations.
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: