Projets-2015-2016-IaaS Docker-SRS
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
- IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998
Version | Date | Authors | Description | Validator | Validation Date | |
---|---|---|---|---|---|---|
0.1.0 | February 2016 | Romain Barthelemy, Alan Damotte, Robin Eudes, Kai Guo, Malek Mammar | Collaborative IaaS using Docker | Pierre-Yves Gibello | February 2016 |
Introduction
Purpose of the requirements document
- This Software Requirements Specification (SRS) identifies the requirements for the Collaborative Iaas project .
- This document is a guideline about the functionalities offered and the problems that the system solves.
Scope of the product
The objective of this project is to allow a user group (member) to pool their laptops or desktop in order to calculate big data of few users. To do so, the solution should work with Docker to virtualize user machines and control the use of resources of each machine.
Definitions, acronyms and abbreviations
References
- The main page of the project: Collaborative Iaas<br\>
Overview of the remainder of the document
- The rest of the SRS examines the specifications of the Collaborative Iaas project in details. Section two of the SRS presents the general factors that affect the Collaborative Iaas project and its requirements, such as user characteristics and project constraints. Section three outlines the detailed, specific and functional requirements, performance, system and other related requirements of the project. Supporting information about appendices is provided in Section three.
General description
Product perspective
Product functions
- Client :
- Register to the service
- Ask for an instance precising required resources
- Launch an instance
- Connect to running instance
- Stop an instance
- Remove an instance
- Give a mark to a provider
- Client :
- Provider :
- Register to the service
- Download required files
- Launch coordinator system
- Provide some of his resources
- Start providing
- Stop providing
- See resources consumption of the instances running on his machine
- Provider :
User characteristics
- The client/provider doesn't have to be familiar with programming
- The client/provider should know unix basics
- The client/provider should know how ssh works
- The provider should know how to launch a script in a terminal
General constraints
- System constraint:
- The provider's machine must run on a unix system (Ubuntu for example)
- The provider must have Docker installed
- System constraint:
- Environment constraint:
- Internet access is required to use the service
- Environment constraint:
Assumptions and dependencies
- The client/provider have an internet access
Specific requirements, covering functional, non-functional and interface requirements
Functional requirements
- The system must allow user to create their profile
- The system must allow client to ask for an instance precising required resources
- The system must allow client to launch an instance
- The system must allow client to connect to running instance
- The system must allow client to stop an instance
- The system must allow client to remove an instance
- The system should allow client to give a mark to a provider
- The system must allow client to download required files
- The system must allow client to launch coordinator system
- The system must allow client to provide some of his resources
- The system must allow client to start providing
- The system must allow client to stop providing
- The system should allow client to see resources consumption of the instances running on his machine
Performance requirements
Design constraints
Logical database requirement
Software System attributes
Reliability
The system must deliver correct informations all the time, so that :
- Clients could only connect to their instances
- Clients could know status of their instances
- Providers could know status of their machine
Availability
The system must be available 24h/24, 7days/7 since both providers and clients should be able to use it.
Security
The security of the service must be optimal, clients should not be able to access information on instances of other clients. Furthermore, providers should also not be able to access container's information. The database modifications must be restricted too.
Maintainability
Updates have to be easy to do, in order to add new functionalities, improve the service easily.
Portability
- For the moment, the system will be available in Linux only for provider side
- However, if packages are available on other systems, we might release the system on other OS later.
Other requirements
- The system must be able to run on Linux 14 or higher
- The system must not consume too much CPU
- The system must not consume too much Memory
Product evolution
Appendices
Specification
- The global project's page can be found here.
Licensing Requirements
Project under GPLv3 licence : https://www.gnu.org/licenses/gpl-3.0.fr.html