Difference between revisions of "RICM4 2017 2018 - UltraTeam 7.1/ SRS"
Line 31: | Line 31: | ||
=1. Introduction= |
=1. Introduction= |
||
==1.1 Purpose of the requirements document== |
==1.1 Purpose of the requirements document== |
||
− | This Software Requirements Specification (SRS) identifies the requirements for project [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeam_7.1] |
+ | This Software Requirements Specification (SRS) identifies the requirements for project [https://air.imag.fr/index.php/RICM4_2017_2018_-_UltraTeam_7.1 UltraTeam 7.1] |
This document is a guideline about the functionalities offered and the problems that the system solves. |
This document is a guideline about the functionalities offered and the problems that the system solves. |
||
Revision as of 12:29, 5 March 2018
The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.
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.1.0 | TBC | TBC | TBC | TBC | TBC |
1. Introduction
1.1 Purpose of the requirements document
This Software Requirements Specification (SRS) identifies the requirements for project UltraTeam 7.1 This document is a guideline about the functionalities offered and the problems that the system solves.
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
- The main page of the project: Proj-2013-2014-StartAIR-2
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: Recover data coming from users doing a hike. They can visualize their path and the system can send emergencies if they sent a SOS signal.
Description: recover data via API REST, data sent by the user (date, position, SOS signal,...).
Inputs: API REST
Source: Smartphone application of the user
Outputs: Visualization of data through to maps, and it allows user to analyze his hike.
Destination: Website
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
Application done with Jhipster. Stocking data in SQL database. User can visualize his own information. (TODO)
Non functional requirements:
Pre-condition: Smartphone + Mobile phone plan with internet package / Wi-Fi.
Post-condition: Detailed map of the path and live analyzing.
Side-effects:
4. Product evolution
5. Appendices
5.1. SRS structure
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
References:
- 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