Difference between revisions of "HandTrainer-SRS"

From air
Jump to navigation Jump to search
Line 50: Line 50:
 
==1.5 Overview of the remainder of the document==
 
==1.5 Overview of the remainder of the document==
   
The rest of the SRS examines the specifications of the [[robAIR2013]] project in details. Section two of the SRS presents the general factors that affect the [[robAIR2013|robAIR]] 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.
+
The rest of the SRS examines the specifications of the [[HandTrainer]] project in details. Section two of the SRS presents the general factors that affect the [[HandTrainer | HandTrainer]] 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.
   
 
=2. General description=
 
=2. General description=
Line 56: Line 56:
 
==2.1 Product perspective==
 
==2.1 Product perspective==
   
<gallery>
 
Image:DiagDeploymentRobAIR.png|General uml of the project
 
Image:Architecture_04_02.jpg|ROS architecture
 
Image:ArchitectureROS.jpg|Detailed ROS architecture
 
</gallery>
 
As mentioned earlier, RobAIR project is part of a larger system consisting of the assembly of the robot (by the 3I4 students) and the ENSIMAG's RobAIR project.<br/>
 
The project interacts with a STM card linked with a serial connection to transmit orders to the robot.<br/>
 
The ensimag project consists of the development of a platform to reserve a robot.
 
<br/><br/>
 
[[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project.<br/>
 
[[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS.<br/>
 
[[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail.<br/>
 
   
 
==2.2 Product functions==
 
==2.2 Product functions==
   
<gallery>
 
Image:usecase.jpg|Simple usecase
 
Image:RobAir2013-RICM4-UseCase.jpg|More complete usecase
 
</gallery>
 
 
<br/>
 
The robot interface functions:
 
::- Control the robot
 
::- See where the robot goes
 
::- Know where is the robot
 
::- Have a feedback on the robot state (battery level, problems encountered)
 
::- Display data about the robot environement to get a feedback (robot velocity, position on the map)
 
<br/>
 
[[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot.<br/>
 
[[Media:RobAir2013-RICM4-UseCase.jpg|This usecase]] is a more complete usecase of our project, offering more action choices.
 
   
 
==2.3 User characteristics==
 
==2.3 User characteristics==
  +
The user doesn’t need to be familiar with programming and doesn't need a specific formation. <br\>
 
He just needs to know how to use a tablet and a television. <br\>
 
   
 
==2.4 General constraints==
 
==2.4 General constraints==
*Platform constraints:
 
::- ROS must operate on an Ubuntu platform.
 
::- Tablet's controller interfaces are developped for the Android platform.
 
   
*Environemental constraints:
 
::- Wifi with Internet access for the robot and for the controller.
 
::- The robot can’t climb up steep slopes.
 
   
 
==2.5 Assumptions and dependencies==
 
==2.5 Assumptions and dependencies==
   
::- The robot site has wifi access in all the visit area.
 
::- A 3D map of the visit site is provide.
 
::- The robot knows the position of its base.
 
::- The robot base can be accessed at any time.
 
::- The robot can estimate the battery life time to know where he needs to go back at its base.
 
   
 
=3.Specific requirements, covering functional, non-functional and interface requirements=
 
=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.
 
   
 
== Functional, non-functional and interface requirements==
 
== Functional, non-functional and interface requirements==
   
'''Function''':
 
- Create a map of the current environment
 
- Locate the robot with accuracy
 
- Allow automatic and semi-automatic movements in regards of the environment (obstacles, stairs, dogs, etc...)
 
   
  +
=4. Product evolution=
'''Description''':
 
   
* The map is dynamically established thanks to both tablet and camera sensors.
 
* Using the accelerometers, gyroscope and compass, RobAIR is able to locate himself with accuracy. This way, it can avoid obstacles.
 
 
'''Inputs''':
 
 
* Robot state messages.
 
* Data about the current location, the environment, the speed, orientation, etc
 
 
'''Source''':
 
 
* Robot sensors
 
* Tablet sensors
 
* State and problems given by the robot
 
 
'''Outputs''':
 
 
* Map with current location of the robot
 
* Instructions and state changing orders
 
 
'''Destination''':
 
 
* RobAIR in order to operate itself
 
* The remote controller
 
* The tablet monitor
 
 
'''Action''':
 
 
* The user must be able to control the robot displacements.
 
* The tablet interface shall access to external data.
 
* The robot must move in its environment without troubles ( avoiding obstacles )
 
* The map must be really accurate in order to give a good overview of the position of RobAIR
 
 
 
* 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''':
 
 
The robot navigate in a safe area without dangers like:
 
* Cars circulation,
 
* Constructions,
 
* Young children or dogs.
 
 
'''Pre-condition''':
 
 
* Last version of RobAIR
 
* A tablet with required sensors and ROS environment
 
* A LDAP camera sensor
 
 
'''Post-condition''':
 
 
* RobAIR is controlled by the remote user using Skype (more information [[Proj-2013-2014-RobAIR-1|here]])
 
 
'''Side-effects''':
 
 
=4. Product evolution=
 
::- Use several tablets (with only one main tablet controlling the robot).
 
::- Ability to read QRcodes and display related contents on the tablet.
 
::- A vocal interface like a GPS.
 
::- Control the robot thanks to a neuronal device.
 
::- Switch between different robots.
 
::- Thanks to a lidar, the robot makes its own map.
 
::- 3D visioconferencing with the treament of two video stream.
 
   
 
=5. Appendices=
 
=5. Appendices=
   
 
==5.1 Specification ==
 
==5.1 Specification ==
* The global project's page can be found [[RobAIR2013|here]].
+
* The global project's page can be found [[HandTrainer | here]].
* The page of the other RICM4 groups working on this project can be found here : [[Proj-2013-2014-RobAIR-1 | WebRTC group]]
 
 
* The UML of the project can be found [[RobAIR2013-RICM4-Groupe3-UML | here]].
 
   
 
==5.2 Sources ==
 
==5.2 Sources ==
* An exemple of JAVA node to communicate with ROS by Rémi Barraquand: [https://github.com/PALGate/palgate-trial/blob/master/prima/knx_control/ http://github.com/PALGate/palgate-trial]
 
 
*The RobAIR 2012 project by Thomas Calmant: [https://github.com/tcalmant/robair/blob/master/trunk/platforms/wifibot http://github.com/tcalmant/robair]
 
 
The robAIR 2013 projects :
 
   
:- [[RobAIR2013-RICM4-Groupe1-Suivi | Group 1]]
 
:- [[RobAIR2013-RICM4-Groupe2-Suivi | Group 2]]
 
:- [[RobAIR2013-RICM4-Groupe3-Suivi | Group 3]]
 
   
 
==5.3 Licensing Requirements==
 
==5.3 Licensing Requirements==
RobAIR will be released under a GPL license and will be open-source.
 

Revision as of 19:45, 26 January 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 the HandTrainer project . This document is a guideline about the functionalities offered and the problems that the system solves.

1.2 Scope of the product

  • The product we are developing is a hand rehabilitation project that can be used for hand recovery. The user will be able to work on several serious games or exercices, and send his results to his doctor.
  • It is a low cost project (using low cost camera).
  • The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

1.3 Definitions, acronyms and abbreviations

1.4 References

1.5 Overview of the remainder of the document

The rest of the SRS examines the specifications of the HandTrainer project in details. Section two of the SRS presents the general factors that affect the HandTrainer 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.

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

Functional, non-functional and interface requirements

4. Product evolution

5. Appendices

5.1 Specification

  • The global project's page can be found here.

5.2 Sources

5.3 Licensing Requirements