Difference between revisions of "RICM4 2017 2018 - Dashboard/ SRS"
Jump to navigation
Jump to search
(Blanked the page) |
|||
| Line 1: | Line 1: | ||
| − | {|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= |
||
| − | * Use OAR API |
||
| − | * Availability is important |
||
| − | |||
| − | ==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= |
||