Difference between revisions of "SRS ECOM 2015 GRP5"

From air
Jump to navigation Jump to search
(Created page with " {|class="wikitable alternance" |+ Document History |- | !scope="col"| Version !scope="col"| Date !scope="col"| Authors !scope="col"| Description !scope="col"| Validat...")
 
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.
   
  +
{|class="wikitable alternance"
 
  +
'''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
 
|+ Document History
 
|-
 
|-
Line 14: Line 21:
 
| 0.1.0
 
| 0.1.0
 
| TBC
 
| TBC
  +
| TBC
| Eudes, Rossi
 
 
| TBC
 
| TBC
 
| TBC
 
| TBC
Line 24: Line 31:
 
=1. Introduction=
 
=1. Introduction=
 
==1.1 Purpose of the requirements document==
 
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for this datacenter's webUI. The purpose of this document is to easily explain the development of this project and to provide instructions to understand and use the software.
+
This Software Requirements Specification (SRS) identifies the requirements for project StartAir Safe.
  +
In case of a open source project, we must present the requirement to others potential contributors. This document is a guideline about the functionalities offered and the problems that the system solves.
  +
 
==1.2 Scope of the product==
 
==1.2 Scope of the product==
The purpose of this project is to provide an userfriendly web interface to simulate and use a small datacenter.
 
Each node of the datacenter can perform some operations, users can interact with a group of nodes or a specific one.
 
 
==1.3 Definitions, acronyms and abbreviations==
 
==1.3 Definitions, acronyms and abbreviations==
 
* Frontend: intern server allowing to interact with OAR-docker
 
* OAR: task and resources manager
 
* Docker: virtualization tools, using containers' technologies
 
* Containers: VMs sharing their OS, comprising only an application and its dependencies
 
* Cluster: group of nodes link together
 
* Node: calculating unit
 
 
 
==1.4 References==
 
==1.4 References==
  +
*The main page of the project: [[Proj-2013-2014-StartAIR-2]]
 
* [https://www.grid5000.fr Grid'5000]
 
* [http://oar.imag.fr OAR] OAR is a versatile resource and task manager (also called a batch scheduler) for HPC clusters and other computing infrastructures. It's used on Grid'5000.
 
* [https://github.com/oar-team/oar-docker OAR-docker]: oar-docker is a set of docker images especially configured for deploying your own OAR cluster. The main idea is to have a mini development cluster with a frontend, a server and some nodes that launch in just a few seconds on a simple laptop.
 
* [http://oar.imag.fr/sources/2.5/docs/documentation/OAR-DOCUMENTATION-API-USER/ API REST] API for OAR
 
* [http://getbootstrap.com/ Boostrap ] CSS
 
* [http://www.datatables.net/ Datatables ] JQuery plugin, allowing to use tables
 
* [http://jquery.malsup.com/form/ JQuery Plugin Form] JQuery plugin, allowing to check form
 
   
 
==1.5 Overview of the remainder of the document==
 
==1.5 Overview of the remainder of the document==
The SRS document includes 3 main chapters :
 
* General description, which contains the general characteristics of the project and our implementation choices.
 
* Specific requirements, which gives the main requirements of each function.
 
* Product evolution, which details the different steps of implementation we chose.
 
 
=2. General description=
 
=2. General description=
 
==2.1 Product perspective==
 
==2.1 Product perspective==
Our project is based on a simulated infrastructure provided by OAR-docker. This cluster is made up of nodes, which can be used by only one user at a time.
 
Our goal is to product a webUI easily understandable and usable by non-developers.
 
As OAR-docker is designed only to test locally sub-developments' step, our webUI is not appropriate for external access.
 
 
 
==2.2 Product functions==
 
==2.2 Product functions==
 
With this interface, users will be able to manage each node, submit a job to a node, cancel a job, create or delete a node.
 
 
[[File:Diagramme_contexte.bmp]]
 
 
 
==2.3 User characteristics==
 
==2.3 User characteristics==
The user can interacts with the interface even if he does not know how to manage the resources or deal with jobs.
 
 
[[File:Diagramme_utilisateur.bmp]]
 
 
 
==2.4 General constraints==
 
==2.4 General constraints==
We have to gain access to the simulation in a private environment where docker is installed.
 
 
 
==2.5 Assumptions and dependencies==
 
==2.5 Assumptions and dependencies==
 
=3.Specific requirements, covering functional, non-functional and interface requirements=
* Web browser which can interpret AJAX
 
  +
* document external interfaces,
 
  +
* describe system functionality and performance
=3. Specific requirements, covering functional, non-functional and interface requirements=
 
  +
* specify logical database requirements,
  +
* design constraints,
  +
* emergent system properties and quality characteristics.
   
 
==3.1 Requirement X.Y.Z (in Structured Natural Language)==
 
==3.1 Requirement X.Y.Z (in Structured Natural Language)==
 
'''Function''':
 
'''Function''':
* Gather information from several nodes
 
* Post information on a webUI, available from a browser
 
   
 
'''Description''':
 
'''Description''':
* Generate an interface allowing to check resources' states, create or delete nodes and jobs
 
   
 
'''Inputs''':
 
'''Inputs''':
* Information about the nodes of OAR-docker's cluster, sent in a json format.
 
   
 
'''Source''':
 
'''Source''':
* OAR API
 
   
 
'''Outputs''':
 
'''Outputs''':
* A website
 
   
 
'''Destination''':
 
'''Destination''':
* Searchers' team
 
   
 
'''Action''':
 
'''Action''':
  +
* Natural language sentences (with MUST, MAY, SHALL)
* Create or delete nodes
 
  +
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
* Affect or suppress jobs
 
  +
* Mathematical Notations
  +
* Tabular notations for several (condition --> action) tuples
   
 
'''Non functional requirements''':
 
'''Non functional requirements''':
* Easily usable: no user experience required
 
* Small: does only need a few mega octets of space
 
* Safe: specific users can do specific actions
 
* Ethic: free-software used
 
   
 
'''Pre-condition''':
 
'''Pre-condition''':
 
*Software:
 
::- OAR-docker
 
   
 
'''Post-condition''':
 
'''Post-condition''':
Line 116: Line 80:
 
'''Side-effects''':
 
'''Side-effects''':
   
=4. Product evolution=
+
=4. Product evolution=
This webUI just use a part of what OAR-API can do, so it could be improved. Moreover, as OAR-docker is still in development, new functionalities can be added.
 
   
 
=5. Appendices=
 
=5. Appendices=
  +
This document is inspired of the IEEE/ANSI 830-1998 Standard.
 
  +
==5.1. SRS structure==
  +
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
   
 
'''References:'''
 
'''References:'''
Line 126: Line 91:
 
* http://en.wikipedia.org/wiki/Software_requirements_specification
 
* 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]
 
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]
  +
  +
=6. Index=

Revision as of 18:24, 19 October 2015

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


Read first:

Document History
Version Date Authors Description Validator Validation Date
0.1.0 TBC TBC TBC TBC TBC


1. Introduction

1.1 Purpose of the requirements document

This Software Requirements Specification (SRS) identifies the requirements for project StartAir Safe. In case of a open source project, we must present the requirement to others potential contributors. This document is a guideline about the functionalities offered and the problems that the system solves.

1.2 Scope of the product

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

2.2 Product functions

2.3 User characteristics

2.4 General constraints

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:

Description:

Inputs:

Source:

Outputs:

Destination:

Action:

  • Natural language sentences (with MUST, MAY, SHALL)
  • Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
  • Mathematical Notations
  • Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:

4. Product evolution

5. Appendices

5.1. SRS structure

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

References:

6. Index