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

From air
Jump to navigation Jump to search
Line 17: Line 17:
 
| 0.2.0
  
| 0.2.0
 
| April 7, 2018
  
| April 7, 2018
−
| BELGENDOUZ Sekina
 +
| BELGUENDOUZ Sekina
  +
|-
  +
!scope="row" |3
  +
| 0.2.1
  +
| April 7, 2018
  +
| BELGUENDOUZ Sekina
 
|}
  
|}
   
Line 33: Line 38:
   
 
==3. Definitions, acronyms and abbreviations==
  
==3. Definitions, acronyms and abbreviations==
  +
* '''SPA''' : '''S'''ingle '''P'''age '''A'''pplication is a web application accessed by a single web page. Its aim is to avoid loading the page at every user's actions. It interacts with the user dynamically rather than loading entire new pages from a server.
−
SPA
  
  +
* '''RESTful API''' : An '''A'''pplication '''P'''rogramming '''I'''nterface is the defined interface through which interactions happen between applications that use its assets. '''RE'''presentational '''S'''tate '''T'''ransfer API is a type of API that has several requirements :
−
API
  
  +
- Stateless
−
OAR
  
  +
- Client-Server oriented
−
Angular5
  
  +
- Layered system
  +
- ...
  +
* '''OAR''' : OAR is a versatile resource and task manager for HPC clusters, and other computing infrastructures.
  +
* '''Angular5''' : Angular5 is a TypeScript-based open-source front-end web application platform. This framework allow the user to develop one SPA for multiple desktop and mobile browsers.
   
 
==4. References==
  
==4. References==
Line 51: Line 60:
   
 
It is a web based system implementing client-server model. The UltraTeamMV System provides simple mechanism for outdoor geolocation in white & gray network areas.
  
It is a web based system implementing client-server model. The UltraTeamMV System provides simple mechanism for outdoor geolocation in white & gray network areas.
  +
  +
==2. Product functions==
  +
This project will allow users to :
  +
* Add/Remove resources (Administrators only)
  +
* Submit/Delete/Configure jobs (Logged Users only)
  +
* See information about resources and jobs
  +
* Have restricted access : login/Logout
  +
  +
==3. User characteristics==
  +
The users of this application are people that are already using OAR technologies, or the ones interested in it.
  +
  +
There is different types of users:
  +
* Administrators : will use the dashboard to manage resources and jobs
  +
* Logged Users : will use the dashboard to see the resources and submit, modify their jobs
  +
* Anonymous Users : will use the dashboard to see the resources
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
=II. General description=
  +
==1. Product perspective==
  +
This dashboard will be based on the template SB-Admin Angular5 provided. And it will allow the user to use OAR though different buttons and forms.
   
 
==2. Product functions==
  
==2. Product functions==
Line 69: Line 129:
 
* Anonymous Users :
  
* Anonymous Users :
 
A user who will use the dashboard to manage resources and tasks
  
A user who will use the dashboard to manage resources and tasks
  +
  +
==4. General constraints==
  +
  +
Make the interface as simple as possible for the user.
  +
  +
==5. Assumptions and dependencies==
  +
Having an Internet connection.
  +
  +
=III. Specific requirements, covering functional, non-functional and interface requirements=
  +
  +
==1. Requirement X.Y.Z (in Structured Natural Language)==
  +
'''Function''': User ressource allocation
  +
  +
'''Description''':
  +
  +
'''Inputs''': A token defining a user and a resource list
  +
  +
'''Source''':
  +
  +
'''Outputs''': A boolean to indicate that the resource is allocated or not
  +
  +
'''Destination''':
  +
  +
'''Action''':
  +
Select a user -> select resources and dedicated values (<= available) -> validate -> notify user
  +
  +
'''Non functional requirements''': -
  +
  +
'''Pre-condition''': A user token must be created
  +
  +
'''Post-condition''': The allocated resources must be locked to the user (should not appear as available for the next allocations)
  +
  +
'''Side-effects''': -
  +
  +
=4. Product evolution=
  +
  +
=5. Appendices=
  +
=6. Index=

Revision as of 10:54, 7 April 2018

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.

Document History
Version Date Authors
1 0.1.0 February 5, 2018 LARNICOL Titouan
2 0.2.0 April 7, 2018 BELGUENDOUZ Sekina
3 0.2.1 April 7, 2018 BELGUENDOUZ Sekina

I. Introduction

1. Purpose of the requirements document

This Software Requirements Specification (SRS) identifies the requirements for Dashboard. It will specify our Single Page Application's (SPA) functionalities and the problems solved. This document will also detail our project's requirements.

2. Scope of the product

This project consists in updating a SPA. With Angular5 OAR-skylight, the precedent SPA, is not working anymore. Therefore to ease OAR's users and managers who have to use command line, the SPA has to be updated in Angular5.

This SPA will allow users to:

  • Add jobs, resources (if administrator)
  • See a listing of jobs, resources
  • Log in/Log out

3. Definitions, acronyms and abbreviations

  • SPA : Single Page Application is a web application accessed by a single web page. Its aim is to avoid loading the page at every user's actions. It interacts with the user dynamically rather than loading entire new pages from a server.
  • RESTful API : An Application Programming Interface is the defined interface through which interactions happen between applications that use its assets. REpresentational State Transfer API is a type of API that has several requirements :

- Stateless - Client-Server oriented - Layered system - ...

  • OAR : OAR is a versatile resource and task manager for HPC clusters, and other computing infrastructures.
  • Angular5 : Angular5 is a TypeScript-based open-source front-end web application platform. This framework allow the user to develop one SPA for multiple desktop and mobile browsers.

4. References

5. Overview of the remainder of the document

II. General description

1. Product perspective

A dashboard web application single page for the task manager and resource OAR. The product is supposed to be an open source.

It is a web based system implementing client-server model. The UltraTeamMV System provides simple mechanism for outdoor geolocation in white & gray network areas.

2. Product functions

This project will allow users to :

  • Add/Remove resources (Administrators only)
  • Submit/Delete/Configure jobs (Logged Users only)
  • See information about resources and jobs
  • Have restricted access : login/Logout

3. User characteristics

The users of this application are people that are already using OAR technologies, or the ones interested in it.

There is different types of users:

  • Administrators : will use the dashboard to manage resources and jobs
  • Logged Users : will use the dashboard to see the resources and submit, modify their jobs
  • Anonymous Users : will use the dashboard to see the resources

















II. General description

1. Product perspective

This dashboard will be based on the template SB-Admin Angular5 provided. And it will allow the user to use OAR though different buttons and forms.

2. Product functions

This project will allow users to :

  • Add/Remove resources (Administrators only)
  • Submit/Delete/Configure jobs (Logged Users only)
  • See information about resources and jobs
  • Have Restricted access : login/Logout
  • Evaluate the time management of the cluster
  • See the usage of resource and jobs in different graphic ways

3. User characteristics

The users of this application are people that are already using OAR technologies, or the ones interested in it.

There is different types of users:

  • Administrators :
  • Logged Users :
  • Anonymous Users :

A user who will use the dashboard to manage resources and tasks

4. General constraints

Make the interface as simple as possible for the user.

5. Assumptions and dependencies

Having an Internet connection.

III. Specific requirements, covering functional, non-functional and interface requirements

1. Requirement X.Y.Z (in Structured Natural Language)

Function: User ressource allocation

Description:

Inputs: A token defining a user and a resource list

Source:

Outputs: A boolean to indicate that the resource is allocated or not

Destination:

Action: Select a user -> select resources and dedicated values (<= available) -> validate -> notify user

Non functional requirements: -

Pre-condition: A user token must be created

Post-condition: The allocated resources must be locked to the user (should not appear as available for the next allocations)

Side-effects: -

4. Product evolution

5. Appendices

6. Index

Retrieved from "https://air.imag.fr/index.php?title=RICM4_2017_2018_-_Dashboard/SRS&oldid=41333"