Projets-2016-2017-SmartSelfService/SRS

<<< Retour à la fiche projet

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

Document History

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

Editions à vérifier

	Partie	Détail
	2.4	Création de la partie

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

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

The app should allow users to :

• Create an account
• Log in / Log out
• Leave an object
• Pick up an object (of your own)
• Borrow an object
• Bring back an object you borrowed
• Check available objects

The app may allow users to :

• Delete account
• Leave an object for a specific user only (also search for a user)
• Give a rating to a user
• Give a limit of time for borrowing (eg. max 1 week or penalties will apply)

The app should allow admins to :

• Open any locker
• Know the content of every locker
• Restrict users / Modify their access

2.3 User characteristics

Users of our app will be students and administrators.

• Students will be the main users. They will be ones who posess or have access to an Android smartphone, with an internet connection. The app could also be used by another public, but we are focusing on students.
• Administrators will be users that are allowed to check the content of every locker and have control over every user profile. They will be the ones trating users requests.

2.5 Assumptions and dependencies

In this project, we assumer that all electronics is functional (and taken from previous year's projects) and that we only have to code the dialogue between the webapp and the arduino chip.

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

This app can be deployed to several spots if connected lockers are built. It could also be used as a platform of exchange rather than just lending, or even used to sell objects if money is added into the system.

Another possibility would be to deploy it into stores or a postoffice where the onnected lockers will eb used so that people can come pick up their mail and packages even when the office is closed.