Difference between revisions of "Projets-2016-2017-SmartSelfService/SRS"
| Line 34: | Line 34: | ||
==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. |
||
| + | However, this year we will try to find a way to turn it in a solution to deploy in a real context. |
||
| + | |||
| + | 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. |
||
| + | |||
| + | 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. |
||
| + | |||
==1.3 Definitions, acronyms and abbreviations== |
==1.3 Definitions, acronyms and abbreviations== |
||
==1.4 References== |
==1.4 References== |
||
Revision as of 17:57, 16 January 2017
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 | // | // |
1. Introduction
1.1 Purpose of the requirements document
This document aims to define the different features of the project throught functional and non functional requirements. In the end we should have an application able to control a smart locker.
It is our contract as it defines what is required for us, developpers, to do.
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. However, this year we will try to find a way to turn it in a solution to deploy in a real context.
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.
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.
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
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: