Difference between revisions of "DashBoard-SRS"
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 16: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