SRS - GrenobloisFuté: Difference between revisions
No edit summary |
No edit summary |
||
| Line 24: | Line 24: | ||
==1.5 Overview of the remainder of the document== |
==1.5 Overview of the remainder of the document== |
||
Description of the project |
Description of the project |
||
=2. General description= |
=2. General description= |
||
| Line 73: | Line 74: | ||
=4. Product evolution= |
=4. Product evolution= |
||
=5. Appendices= |
|||
=6. Index= |
|||
Revision as of 19:41, 5 April 2016
1. Introduction
1.1 Purpose of the requirements document
The Software Requirements Specification (SRS) is a document describing the software system of our project: GrenobloisFuté. It describes how the system is supposed to work with functional and non functional requirements.
1.2 Scope of the product
Our application is intended for all motorists Grenoble. The goal is to display the traffic and work presented in the Grenoble area to be able to adjust his path.
1.3 Definitions, acronyms and abbreviations
- Mobile application : it's a standalone program designed to run on a mobile device like a smartphone or a tablet.
- Plugin :it's a tool consisting of a set of computer files, and lets you install new features on the sidelines of a program which it is attached.
1.4 References
Fiche
http://air.imag.fr/index.php/GrenobleFut%C3%A9
Home Page
http://air.imag.fr/index.php/GrenobloisFut%C3%A9
1.5 Overview of the remainder of the document
Description of the project
2. General description
2.1 Product perspective
The project goal is to provide an application that provides traffic and led work to Grenoble to be able to adapt its path.
2.2 Product functions
- Display real-time traffic on the map of the application
- Display real-time work on the map of the application
2.3 User characteristics
Plugin users are motorists who travel in the Grenoble area.
2.4 General constraints
The plugin is available only on android smartphone.
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: Amplifying sounds to enable people who have hearing problems to hear properly
Description:
Inputs:
Source:
Outputs:
Destination:
Action:
Non functional requirements:
Pre-condition:
Post-condition:
Side-effects: