RICM4 2017 2018 - Dashboard/ SRS: Difference between revisions

From air
Jump to navigation Jump to search
No edit summary
(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 06:45, 7 April 2018