DashBoard-SRS: Difference between revisions
Jump to navigation
Jump to search
| Line 37: | Line 37: | ||
==3.1 Requirement X.Y.Z (in Structured Natural Language)== |
==3.1 Requirement X.Y.Z (in Structured Natural Language)== |
||
'''Function''': |
'''Function''': |
||
'''Description''': |
|||
'''Description''': When traffic is heavy, users see it on the application and can avoid those areas. |
|||
'''Inputs''': |
'''Inputs''': |
||
'''Source''': |
'''Source''': |
||
'''Outputs''': |
'''Outputs''': |
||
'''Destination''': |
'''Destination''': |
||
'''Action''': |
|||
'''Action''': The plugin retrieves the free data and displays it on the map as panels or coloring. |
|||
'''Non functional requirements''': |
'''Non functional requirements''': |
||
* Easy to use interface |
|||
* Free plugin and application |
|||
=4. Product evolution= |
=4. Product evolution= |
||
Revision as of 14:02, 6 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: DashBoard for OAR. It describes how the system is supposed to work with functional and non functional requirements.
1.2 Scope of the product
Our product is intended for a client, using OAR as manager of resources and tasks
1.3 Definitions, acronyms and abbreviations
- Cluster : It is a grouping of multiple servers to perform calculations.
- SPA : Single Page Application
2. General description
2.1 Product perspective
A dashboard web application for the task manager and resource OAR.
2.2 Product functions
- Add/Remove resources
- Submit/Delete jobs
- See information about resources and tasks
- Login/Logout
2.3 User characteristics
Client using OAR as manager of resources and tasks
2.4 General constraints
- AngularJS
- SB Admin v2.0
- Approach of a SPA
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:
Non functional requirements:
4. Product evolution
- For the work : we could view the details of the work (which are present in the xml file) by clicking on the icon.
- For the traffic: we could add an option in the GPS which can change routes depending on traffic.
- Add a zoom setting for the traffic display
- Spread to other cities
- Make an off-line mode