Difference between revisions of "RICM4 2017 2018 - Dashboard/ SRS"

From air
Jump to navigation Jump to search
(Blanked the page)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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
 
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]
 
 
{|class="wikitable alternance"
 
|+ Document History
 
|-
 
|
 
!scope="col"| Version
 
!scope="col"| Date
 
!scope="col"| Authors
 
!scope="col"| Description
 
!scope="col"| Validator
 
!scope="col"| Validation Date
 
|-
 
!scope="row" |
 
| 0.1.0
 
| February 5, 2018
 
| BELGENDOUZ Sekina, LARNICOL Titouan
 
| TBC
 
| TBC
 
| TBC
 
 
|}
 
 
 
=1. Introduction=
 
==1.1 Purpose of the requirements document==
 
The SRS is a document describing the software system of our DashBoard project for OAR.
 
==1.2 Scope of the product==
 
 
 
Our web application is for people using AOR as manager of ressources tasks
 
 
==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==
 
A dashboard web application single page for the task manager and resource OAR.
 
 
==2.2 Product functions==
 
* Add/Remove ressources
 
* Submit/Delete/Configure jobs
 
* See information about ressources and tasks
 
* Restricted access : login/Logout
 
* Time management of the cluster (check saturated bus ...)
 
* Numerous graphic ways to monitor the grid
 
 
==2.3 User characteristics==
 
 
A user who will use the dashboard to manage ressources and tasks
 
 
==2.4 General constraints==
 
 
Make the interface as simple as possible for the user
 
 
Make It enough performant to be easily usable to the users
 
 
==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''': User ressource allocation
 
 
'''Description''':
 
 
'''Inputs''': A token defining a user and a ressource list
 
 
'''Source''':
 
 
'''Outputs''': A boolean to indicate that the ressource is allocated or not
 
 
'''Destination''':
 
 
'''Action''':
 
Select a user -> select ressources and dedicated values (<= available) -> validate -> notify user
 
 
'''Non functional requirements''': -
 
 
'''Pre-condition''': A user token must be created
 
 
'''Post-condition''': The alllocated ressources must be locked to the user (should not apppear as available for the next allocations)
 
 
'''Side-effects''': -
 
 
=4. Product evolution=
 
 
=5. Appendices=
 
=6. Index=
 

Latest revision as of 08:45, 7 April 2018