Difference between revisions of "Projets-2016-2017-SmartSelfService/SRS"

From air
Jump to navigation Jump to search
Line 37: Line 37:
   
 
==1.2 Scope of the product==
 
==1.2 Scope of the product==
The first idea is to provide an exchange box to lend little material like a hammer or a book between students.
+
The previous years projects' idea is to provide a controlable exchange box to lend little material like a hammer or a book between students.
However, this year we will try to find a way to turn it in a solution to deploy in a real context.
 
   
  +
This year's aim is to find a way to turn it into a deployable app.
The survey we launched showed that most of the students where interested in sharing with a friend, and not an random individual. Moreover, many people where afraid about the security of this system. A major challenge will be to find a method to protect the user's rights and to penalize those that aren't respecting deadlines.
 
  +
 
The survey we launched showed that most of the students where interested in sharing objects with a friend but not with a random individual. Many people where afraid about the security of this system. So, our challenge will be to find a method to protect the user's objects and to penalize those who aren't respecting deadlines or not returning objects they borrowed.
  +
 
Some users may also want to reserve a special item present in a box. For that a research function will be implemented.
   
Some users also want to reserve a special item present in a box, with a research function.
 
 
A principle of exchange items, like a public library, for example.
 
A principle of exchange items, like a public library, for example.
   

Revision as of 18:52, 30 January 2017

<<< Retour à la fiche projet


Read first:


Document History
Version Date Authors Description Validator Validation Date
0.0.1 16/01/2017 Alicia A. Gilles B. First version // //


1. Introduction

1.1 Purpose of the requirements document

This document aims to define the different features of the project through functional and non functional requirements. In the end we should have a platform to lend objects by controlling smart lockers.

It is our contract as it defines what is required for us, developpers, to deliver.

1.2 Scope of the product

The previous years projects' idea is to provide a controlable exchange box to lend little material like a hammer or a book between students.

This year's aim is to find a way to turn it into a deployable app.

The survey we launched showed that most of the students where interested in sharing objects with a friend but not with a random individual. Many people where afraid about the security of this system. So, our challenge will be to find a method to protect the user's objects and to penalize those who aren't respecting deadlines or not returning objects they borrowed.

Some users may also want to reserve a special item present in a box. For that a research function will be implemented.

A principle of exchange items, like a public library, for example.

1.3 Definitions, acronyms and abbreviations

1.4 References

We are using last years' projects bases, there is some documentation about the technologies used.

  • aREST a Restfull framework to control Arduino.
  • A ESP8266 Documentation for Arduino, a WIFI chip used to transit informations between the lockers and the smartphone.

1.5 Overview of the remainder of the document

2. General description

2.1 Product perspective

We are aiming to produce a renting / lending service in small groups. An administrator should be able to oversee the exchanges and to rule them. The main idea is to drop off an item in a locker, and to let it available for somebody else. In the long term, it would be possible to implement this kind of technology in post offices.

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:

4. Product evolution

5. Appendices

6. Index