Projets-2016-2017-SmartSelfService/SRS
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 | Authors | Description | Validator | Validation Date | |
|---|---|---|---|---|---|---|
| 0.0.1 | 16/01/2017 | Alicia A. Gilles B. | First version | // | // |
| 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.3 Definitions, acronyms and abbreviations
- QRcode : Quick Response Code, is a grid containing black and white squares which can be interpreted to extract data (here a request) when seen through a camera.
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
In the following parts are described the general functions of our app : what is will do and which importance each feature has. Then we will go throught some more specific constraints and requirements the app should meet. Finally, we will describe the possible evolution of our app and how we would like to make or see it evolve.
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.4 General constraints
This project includes some constraints from the previous years and technologies already in place, but also due to the choices concerning the implementation of the product :
- Use the physical support already in place
- Design an adaptable database model
- Create an accessible web and mobile application
- The lockers access will be possible via a mobile authentication
- Implement a safety system to "secure" the loan of objects
2.5 Assumptions and dependencies
In this project, we assume 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 1.1.1 | User's functions
Function:
Description:
All the users' functions
Inputs: user actions
Source: physical or application
Outputs: ???
Destination: physical or application
Action:
- MUST create an account
- MAY delete his account
- MUST consult available items
- SHOULD book an item
- MUST borrow an item
- MUST bring back borrowed items
Non functional requirements:
- User has an account or creates it
Pre-condition:
- Database structure is established
Post-condition:
Side-effects:
3.2 Requirement 1.1.2 | [User Extension] Owner's functions
Function:
Description: All the functions available for an owner
Inputs:
Source: physical or applications
Outputs:
Destination: physical or applications
Action:
- MUST Drop-off an object
- MAY privatise it
- MUST Take-off an own object
- MAY block an object since take-off
Non functional requirements:
Pre-condition:
- user is an owner
Post-condition:
Side-effects:
3.3 Requirement 1.2 | Admin's functions
Function:
Description: All the admin's functions
Inputs: admin account
Source: physical or applications
Outputs: Edit the database, opens lockers...
Destination: physical or applications
Action:
- MUST create / update an account
- MAY delete an account
- MUST control a locker
- MAY restrict an user
- MUST manage "points"
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects:
- admin account overrides any action from an user
- "restricted" user can still take-off it's own items
3.4 Requirement 2 | Connected Lockers
Description: Make the lockers communicate with the database
Inputs: An order registered by a QRCode
Source: A camera fixed on the locker
Outputs: The result of this order, depending on the input (basicly openning a locker)
Destination: ???
Action:
- Present a QRCode to the camera
- The locker connects to the database
- Depending on the QRCode, opens the locker (or not) and wait for an action from the user
Non functional requirements: The QRCode exists in the database and is not already used
3.5 Requirement 3 | Web-App : drop-off
Description: A way to drop-off an object in a locker
Inputs:
- Empty locker
- Object
- Description
- [Optional] : authorized user or group of users
Source: Database and user
Outputs:
- Database updated
- [Optional] : Notification to concerned users
Destination: Database
Action:
Non functional requirements:
Pre-condition:
- User has an account and is logged
Post-condition: The locker is marked as filled in the database and the informations related to the object are known
Side-effects:
3.6 Requirement 4 | Web-app : Take-off
Description: A user must be able to take one of his object he left for someone to borrow
Inputs:
- The ID of the object (or the corresponding locker)
- The ID of the user
- [Optional] the desired pick-up date
Source: The user
Outputs: Unlocking a locker and upadting the database.
Destination: The database
Action: Please see the corresponding UML
Non functional requirements:
- Security : A user must have access to his objects and his objects only.
- If a user wants to pick up an object, is someone borrowed it he must return it <== based on trust for the delays.
Pre-condition:
- The object is in on locker and not borrowed at the moment
- The given Id for the object or locker corresponds to an object belonging to the user connected.
Post-condition:
- One locker is now empty
Side-effects:
3.X 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 and system could evolve depending on hardware evolution, customer evolution or added features.
New system for the lockers
The lockers we got from previous years projects are connected through Wi-Fi, this can be a security flaw. Therefore, the product could evolve if instead of using a wireless network those lockers were to be connected using cables and other system. It would mean : changing the ahrware but also changing the app and code because it will be built on APIs different fromt he one this project uses.
New lockers with the same system
At the moment, we plan on managing only one set of locker, but if lockers were to be placed in different places, the app will have to have a feature allowing administrators to registers new lockers.
Deployment for a company
A possibility would be to deploy it into stores or a postoffice where the connected lockers will be used so that people can come pick up their mail and packages even when the office is closed.
Exchanging and/or selling items
This system 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. In order to do that new features will have to be implemented and a system of money or value in points corresponding to items will have to be created.
5. Appendices
You can find the UML diagrams attached to this project here