Difference between revisions of "RICM4 2017 2018 - Serre Connectee / SRS"
(Created page with " {|class="wikitable alternance" |+ Document History |- | !scope="col"| Version !scope="col"| Date !scope="col"| Authors !scope="col"| Description !scope="col"| Validat...") |
|||
(21 intermediate revisions by 3 users not shown) | |||
Line 12: | Line 12: | ||
!scope="row" | |
!scope="row" | |
||
| 0.1.0 |
| 0.1.0 |
||
− | | |
+ | | 05.02.2017 |
+ | | Timothée DEPRIESTER, Guillaume BESNARD |
||
− | | Antoine BOISADAM, Oriane DALLE |
||
| TBC |
| TBC |
||
| TBC |
| TBC |
||
Line 27: | Line 27: | ||
==1.2 Scope of the product== |
==1.2 Scope of the product== |
||
− | The project consist of upgrading a classic greenhouse to retrieve live information about its climate. |
+ | The project consist of upgrading a classic greenhouse to retrieve live information about its climate. This information should be available for the farmer to view locally on a screen. |
==1.3 Definitions, acronyms and abbreviations== |
==1.3 Definitions, acronyms and abbreviations== |
||
Line 37: | Line 37: | ||
==1.5 Overview of the remainder of the document== |
==1.5 Overview of the remainder of the document== |
||
+ | We'll then dive deeper into specification and requirements of the project. |
||
+ | |||
=2. General description= |
=2. General description= |
||
==2.1 Product perspective== |
==2.1 Product perspective== |
||
− | The aim of this projet is equip |
+ | *The aim of this projet is equip to equip multiples farms, not only one greenhouse. |
+ | *This project may become a flagship project for ST MicroElectronics |
||
==2.2 Product functions== |
==2.2 Product functions== |
||
Line 47: | Line 50: | ||
*The air moisture |
*The air moisture |
||
*The soil moisture |
*The soil moisture |
||
− | And display these data on a graphic interface (dashboard) |
+ | And display these data on a local graphic interface (dashboard). |
==2.3 User characteristics== |
==2.3 User characteristics== |
||
+ | *Even though those specifics farmers in St Cassien are (former) engineer, we should assume no technical background from the users to be able to use this systems for others farms. |
||
+ | *Users are busy enough with their activity, we shouldn't assume they have time for complex deployment and maintenance. |
||
+ | |||
==2.4 General constraints== |
==2.4 General constraints== |
||
− | *The energy source : There is no power near of the greenhouse, consequently we'll use a |
+ | *The energy source : There is no power near of the greenhouse, consequently we'll use a battery. |
− | *Duty Cycle : We can use only 1% of the time in order to |
+ | *Duty Cycle : We can use only 1% of the time in order to comply with the law. |
− | *Sensors needs to be moveable : Vehicles should be able move along the greenhouse. |
+ | *Sensors needs to be moveable : Vehicles should be able to move along the greenhouse. |
+ | *Easy deployment : we aim to provide an easy way of setting up the systems : |
||
+ | ** Via an easy sets of instructions (tutorial) |
||
+ | ** And/or by using a docker image, containing all the necessary (dependencies and configurations). |
||
==2.5 Assumptions and dependencies== |
==2.5 Assumptions and dependencies== |
||
+ | * We assume that the farm itself will have no (or not long) power outage. |
||
+ | * We assume that the battery will provide enough energy for a time span. |
||
+ | |||
=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, |
||
Line 65: | Line 77: | ||
==3.1 Requirement X.Y.Z (in Structured Natural Language)== |
==3.1 Requirement X.Y.Z (in Structured Natural Language)== |
||
− | '''Function''': |
||
+ | '''Function''': Sensors' measures access. |
||
− | '''Description''': |
||
+ | |||
+ | '''Description''': The farmer need to be able to view the measurements on a screen at any time. |
||
+ | '''Inputs''': Measurements and data from the sensors (Humidity of air/soil and ambiant temperature). |
||
− | '''Inputs''': |
||
− | '''Source''': |
+ | '''Source''': NUCLERO-L073RZ |
+ | '''Outputs''': Visual graph on the screen, using graphana visualization. |
||
− | '''Outputs''': |
||
− | '''Destination''': |
+ | '''Destination''': Raspberry's InfluxDB |
− | '''Action''': |
+ | '''Action''': Visualization |
− | * 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''': |
+ | '''Non functional requirements''': Acceptability / maintainability |
− | '''Pre-condition''': |
+ | '''Pre-condition''': All equipments are powered and properly working. |
− | '''Post-condition''': |
+ | '''Post-condition''': Same state as pre-condition |
− | '''Side-effects''': |
+ | '''Side-effects''': None (visualization is a "passive" action) |
=4. Product evolution= |
=4. Product evolution= |
||
+ | In this iteration we aim to provide a local data viewer. Other groups are working towards an online dashboard solution. It might be interesting to group all this data on the same online virtual machine. |
||
=5. Appendices= |
=5. Appendices= |
Latest revision as of 14:30, 27 February 2018
Version | Date | Authors | Description | Validator | Validation Date | |
---|---|---|---|---|---|---|
0.1.0 | 05.02.2017 | Timothée DEPRIESTER, Guillaume BESNARD | TBC | TBC | TBC |
1. Introduction
1.1 Purpose of the requirements document
The Software Requirements Specification (SRS) is a communication tool between stakeholders and software designers. It gives a description of the software’s purpose and functionality. In other words, the SRS is a document that captures complete description about how the system is expected to perform.
1.2 Scope of the product
The project consist of upgrading a classic greenhouse to retrieve live information about its climate. This information should be available for the farmer to view locally on a screen.
1.3 Definitions, acronyms and abbreviations
- Greenhouse: an area, usually chiefly of glass, in which the temperature is maintained within a desired range, used for cultivating tender plants or growing plants out of season.
- LoRa: Long Range and low energy radio RF technology developed by Semtech. It's an open-source technology.
1.4 References
1.5 Overview of the remainder of the document
We'll then dive deeper into specification and requirements of the project.
2. General description
2.1 Product perspective
- The aim of this projet is equip to equip multiples farms, not only one greenhouse.
- This project may become a flagship project for ST MicroElectronics
2.2 Product functions
At the end, product should return:
- The air temperature
- The air moisture
- The soil moisture
And display these data on a local graphic interface (dashboard).
2.3 User characteristics
- Even though those specifics farmers in St Cassien are (former) engineer, we should assume no technical background from the users to be able to use this systems for others farms.
- Users are busy enough with their activity, we shouldn't assume they have time for complex deployment and maintenance.
2.4 General constraints
- The energy source : There is no power near of the greenhouse, consequently we'll use a battery.
- Duty Cycle : We can use only 1% of the time in order to comply with the law.
- Sensors needs to be moveable : Vehicles should be able to move along the greenhouse.
- Easy deployment : we aim to provide an easy way of setting up the systems :
- Via an easy sets of instructions (tutorial)
- And/or by using a docker image, containing all the necessary (dependencies and configurations).
2.5 Assumptions and dependencies
- We assume that the farm itself will have no (or not long) power outage.
- We assume that the battery will provide enough energy for a time span.
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: Sensors' measures access.
Description: The farmer need to be able to view the measurements on a screen at any time.
Inputs: Measurements and data from the sensors (Humidity of air/soil and ambiant temperature).
Source: NUCLERO-L073RZ
Outputs: Visual graph on the screen, using graphana visualization.
Destination: Raspberry's InfluxDB
Action: Visualization
Non functional requirements: Acceptability / maintainability
Pre-condition: All equipments are powered and properly working.
Post-condition: Same state as pre-condition
Side-effects: None (visualization is a "passive" action)
4. Product evolution
In this iteration we aim to provide a local data viewer. Other groups are working towards an online dashboard solution. It might be interesting to group all this data on the same online virtual machine.