air - User contributions [en]

HandTrainer-SRS

2015-03-25T07:41:39Z

RICM4-prj14-grp13:

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:*This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:*This document is a guideline about the functionalities offered and the problems that the system solves.

==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 the low cost camera [https://www.leapmotion.com/ LeapMotion]).
:* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:*The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:*The patient must understand clearly and quickly how to interact, send results, etc
:*The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:*The system must help patient to rehabilitate their hand with different exercices
:*The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:*The system must handle prescription for patient, e.g. exercices that has to be done
:*The system must help doctors to follow their patient and their progression
:*The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:*The system must be able to run on Windows 7 or higher
:*The system must not consume too much CPU
:*The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:39:38Z

RICM4-prj14-grp13: /* Other requirements */

HandTrainer-SRS

2015-03-25T07:39:05Z

RICM4-prj14-grp13: /* Functional requirements */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:*This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:*This document is a guideline about the functionalities offered and the problems that the system solves.

==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 the low cost camera [https://www.leapmotion.com/ LeapMotion]).
:* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:*The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:*The patient must understand clearly and quickly how to interact, send results, etc
:*The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:*The system must help patient to rehabilitate their hand with different exercices
:*The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:*The system must handle prescription for patient, e.g. exercices that has to be done
:*The system must help doctors to follow their patient and their progression
:*The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume too much CPU
:The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:38:42Z

RICM4-prj14-grp13: /* Purpose of the requirements document */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:*This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:*This document is a guideline about the functionalities offered and the problems that the system solves.

==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 the low cost camera [https://www.leapmotion.com/ LeapMotion]).
:* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:*The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:*The patient must understand clearly and quickly how to interact, send results, etc
:*The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume too much CPU
:The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:38:26Z

RICM4-prj14-grp13: /* External interface requirements */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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 the low cost camera [https://www.leapmotion.com/ LeapMotion]).
:* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:*The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:*The patient must understand clearly and quickly how to interact, send results, etc
:*The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume too much CPU
:The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:38:11Z

RICM4-prj14-grp13: /* External interface requirements */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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 the low cost camera [https://www.leapmotion.com/ LeapMotion]).
:* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
*The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
*The patient must understand clearly and quickly how to interact, send results, etc
*The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume too much CPU
:The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:37:37Z

RICM4-prj14-grp13: /* Scope of the product */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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 the low cost camera [https://www.leapmotion.com/ LeapMotion]).
:* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume too much CPU
:The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:37:25Z

RICM4-prj14-grp13: /* Scope of the product */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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 the low cost camera LeapMotion [https://www.leapmotion.com/ LeapMotion]).
:* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume too much CPU
:The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:36:40Z

RICM4-prj14-grp13: /* Scope of the product */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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 the low cost camera LeapMotion [https://www.leapmotion.com/]).
:* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume too much CPU
:The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:35:20Z

RICM4-prj14-grp13: /* Other requirements */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume too much CPU
:The system must not consume too much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer

2015-03-25T07:33:47Z

RICM4-prj14-grp13: /* Week 9 (March 23rd - March 27th) */

[[Image:HandTrainer-Cover.jpg|400px|right|HandTrainer Cover]]
= Introduction =

In France, the rehabilitation is a major problem from the fact that patients have troubles taking charge of their own rehabilitation. They need to be supervised by a health professional. This is a strain of mobility and time for the patient and a significant cost. The patient must be able to rehabilitate from his home while being followed at a distance by the doctor in charge of the medical record.

Also, studies show that rehabilitation of the hand is more effective when both hands are used. Indeed, the growth of the invalidated hand is more important when it is in parallel with the healthy hand. The system must take into account both hands. HandTrainer proposes a completely different approach to the rehabilitation of the hand. It will provide an interactive and entertaining look to the user, by offering him a serious game. It will therefore be able to work his rehabilitation while having fun. It may also use specific exercises every movement involved in rehabilitation.

The patient should be able to use the software from anywhere, only if it has a computer and the right equipment. It also needs an internet connection in order to send its result to the medical professional.

The doctor should be able to recover any time patient outcomes which he is responsible, in order to effectively study and follow their evolution. He needs the software and an internet connection.

= Team =

*Tutors : Didier Donsez, Alessandro Semere

*Members : Patrick Perea, Arthur Clerc-Gherardi, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Related documents =

= Project objectives =

* Create a software that can be used for hand recovery
* Develop a serious games and exercices that use the five rehabilitation movements
* Make it possible for doctors to follow his patients and their progression

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[HandTrainer-SRS|here]].

= Progress of the project =

The project started January 26th, 2015.

== Week 1 (January 26th - January 30th) ==

*Writing of the specifications

*Writing of the SRS that can be found [[HandTrainer-SRS| here]]

*Writing of different UML diagrams :
::- Context Diagram
::- Logical Diagram
::- Physical Diagram
::- Sequence Diagram
::- Use Case Diagram

*Comparison between different technology in order to chose the best one:
[[Image:Photo-Test-1.jpg|200px|Xtion Pro Live 1]]
[[Image:Photo-Test-2.jpg|200px|Xtion Pro Live 2]]
[[Image:Photo-Test-3.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-4.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-5.jpg|112px|Leap Motion]]

*Writing of the game scenario

== Week 2 (February 2nd - February 6th) ==
[[Image:Meeting-HandTrainer.jpg|250px|thumb|right|Meeting HandTrainer]]
*Choice of the Leap Motion for our application
*Design of game's HMI
*Design of software's HMI
*Writing of a game scenario
*Development of a web interface to make it possible for doctors to create their account
*Reflection about the necessary datas for the database
*Conception of the database
*Launching of the database on our server
*Choice of a communication protocol
*Choice of XML's architecture
*Conception of HMI Wireframe
*Meeting with Alessandro SEMERE

== Week 3 (February 9th - February 13th) ==

*Development of game design
*Development of authentification page for the software
*Sending of XML from the software for patient's medical records
*Reception of XML from the software for patient's medical records
*Writing notes by the doctor in XML
*Writing patient's progression in XML
*Training session about Handicap with Noella Renou from Execo-France
[[Image:Formation-Handicap.jpg|300px|center|Training Session Handicap]]

== Week 4 (February 16th - February 20th) ==

Holidays, less development this week

*Development of the action "Open a door" for the game
*Recognition of several rehabilitation movements :
::- Fist
::- Duck
::- Hand Opening
::- Claw
*Changing of servers because our OVH server didn't allow the direct access from the software

== Week 5 (February 23rd - February 27th) ==

*Development of the action "Destroy a wall" for the game
*Development of the action "Pull a lever" for the game
*Development of the action "Up a harrow" for the game
*Development of the action "Bring down a bridge" for the game
*Recognition of thumb rotation
*Development of level loading by XML
*Meeting with Alessandro Semere

== Week 6 (March 2nd - March 6th) ==
*Development of several HMI :
::- View for progression ( Patient side )
::- View for writing notes ( Doctor side )
::- View for adding patient ( Doctor side )
*Development of the score for the game
*Make it possible to add patients in the Database
*Reedition of several sprites in the game for a better visual

== Week 7 (March 9th - March 13th) ==
*Development of specific exercices for :
::*Claw
::*Duck
::*Fist
::*Thumb Rotation
::*Hand opening
*Development of a tutorial
*Development of HMI for :
::*Patient medical records ( Doctor side )
::*Consultation of patients list ( Doctor side )
::*Reading of notes ( Patient side )
*Link between Leap Motion and the game for each actions
*Meeting with Alessandro Semere

== Week 8 (March 16th - March 20th) ==
*Integration of the game in the main interface ( still working on it .. )
*Integration of the database link in the main interface
*Development of charts for the patient evolution
*Completion of several HMI
*Edition of charts for the final presentation
*Writing of the final report
*Meeting with Alessandro Semere

== Week 9 (March 23rd - March 27th) ==

*Edition of the video for Defi H
[[Image:Photo-Tournage-HandTrainer-1.jpg|280px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-2.jpg|280px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-3.jpg|250px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-4.jpg|250px|Tournage]]
*Preparation of the final presentation
*Writing of the final report

HandTrainer

2015-03-25T07:32:57Z

RICM4-prj14-grp13: /* Week 9 (March 23rd - March 27th) */

HandTrainer

2015-03-25T07:32:36Z

RICM4-prj14-grp13: /* Week 9 (March 23rd - March 27th) */

[[Image:HandTrainer-Cover.jpg|400px|right|HandTrainer Cover]]
= Introduction =

In France, the rehabilitation is a major problem from the fact that patients have troubles taking charge of their own rehabilitation. They need to be supervised by a health professional. This is a strain of mobility and time for the patient and a significant cost. The patient must be able to rehabilitate from his home while being followed at a distance by the doctor in charge of the medical record.

Also, studies show that rehabilitation of the hand is more effective when both hands are used. Indeed, the growth of the invalidated hand is more important when it is in parallel with the healthy hand. The system must take into account both hands. HandTrainer proposes a completely different approach to the rehabilitation of the hand. It will provide an interactive and entertaining look to the user, by offering him a serious game. It will therefore be able to work his rehabilitation while having fun. It may also use specific exercises every movement involved in rehabilitation.

The patient should be able to use the software from anywhere, only if it has a computer and the right equipment. It also needs an internet connection in order to send its result to the medical professional.

The doctor should be able to recover any time patient outcomes which he is responsible, in order to effectively study and follow their evolution. He needs the software and an internet connection.

= Team =

*Tutors : Didier Donsez, Alessandro Semere

*Members : Patrick Perea, Arthur Clerc-Gherardi, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Related documents =

= Project objectives =

* Create a software that can be used for hand recovery
* Develop a serious games and exercices that use the five rehabilitation movements
* Make it possible for doctors to follow his patients and their progression

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[HandTrainer-SRS|here]].

= Progress of the project =

The project started January 26th, 2015.

== Week 1 (January 26th - January 30th) ==

*Writing of the specifications

*Writing of the SRS that can be found [[HandTrainer-SRS| here]]

*Writing of different UML diagrams :
::- Context Diagram
::- Logical Diagram
::- Physical Diagram
::- Sequence Diagram
::- Use Case Diagram

*Comparison between different technology in order to chose the best one:
[[Image:Photo-Test-1.jpg|200px|Xtion Pro Live 1]]
[[Image:Photo-Test-2.jpg|200px|Xtion Pro Live 2]]
[[Image:Photo-Test-3.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-4.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-5.jpg|112px|Leap Motion]]

*Writing of the game scenario

== Week 2 (February 2nd - February 6th) ==
[[Image:Meeting-HandTrainer.jpg|250px|thumb|right|Meeting HandTrainer]]
*Choice of the Leap Motion for our application
*Design of game's HMI
*Design of software's HMI
*Writing of a game scenario
*Development of a web interface to make it possible for doctors to create their account
*Reflection about the necessary datas for the database
*Conception of the database
*Launching of the database on our server
*Choice of a communication protocol
*Choice of XML's architecture
*Conception of HMI Wireframe
*Meeting with Alessandro SEMERE

== Week 3 (February 9th - February 13th) ==

*Development of game design
*Development of authentification page for the software
*Sending of XML from the software for patient's medical records
*Reception of XML from the software for patient's medical records
*Writing notes by the doctor in XML
*Writing patient's progression in XML
*Training session about Handicap with Noella Renou from Execo-France
[[Image:Formation-Handicap.jpg|300px|center|Training Session Handicap]]

== Week 4 (February 16th - February 20th) ==

Holidays, less development this week

*Development of the action "Open a door" for the game
*Recognition of several rehabilitation movements :
::- Fist
::- Duck
::- Hand Opening
::- Claw
*Changing of servers because our OVH server didn't allow the direct access from the software

== Week 5 (February 23rd - February 27th) ==

*Development of the action "Destroy a wall" for the game
*Development of the action "Pull a lever" for the game
*Development of the action "Up a harrow" for the game
*Development of the action "Bring down a bridge" for the game
*Recognition of thumb rotation
*Development of level loading by XML
*Meeting with Alessandro Semere

== Week 6 (March 2nd - March 6th) ==
*Development of several HMI :
::- View for progression ( Patient side )
::- View for writing notes ( Doctor side )
::- View for adding patient ( Doctor side )
*Development of the score for the game
*Make it possible to add patients in the Database
*Reedition of several sprites in the game for a better visual

== Week 7 (March 9th - March 13th) ==
*Development of specific exercices for :
::*Claw
::*Duck
::*Fist
::*Thumb Rotation
::*Hand opening
*Development of a tutorial
*Development of HMI for :
::*Patient medical records ( Doctor side )
::*Consultation of patients list ( Doctor side )
::*Reading of notes ( Patient side )
*Link between Leap Motion and the game for each actions
*Meeting with Alessandro Semere

== Week 8 (March 16th - March 20th) ==
*Integration of the game in the main interface ( still working on it .. )
*Integration of the database link in the main interface
*Development of charts for the patient evolution
*Completion of several HMI
*Edition of charts for the final presentation
*Writing of the final report
*Meeting with Alessandro Semere

== Week 9 (March 23rd - March 27th) ==

*Edition of the video for Defi H
[[Image:Photo-Tournage-HandTrainer-1.jpg|270px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-2.jpg|270px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-3.jpg|250px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-4.jpg|250px|Tournage]]

HandTrainer

2015-03-25T07:32:19Z

RICM4-prj14-grp13: /* Week 9 (March 23rd - March 27th) */

[[Image:HandTrainer-Cover.jpg|400px|right|HandTrainer Cover]]
= Introduction =

In France, the rehabilitation is a major problem from the fact that patients have troubles taking charge of their own rehabilitation. They need to be supervised by a health professional. This is a strain of mobility and time for the patient and a significant cost. The patient must be able to rehabilitate from his home while being followed at a distance by the doctor in charge of the medical record.

Also, studies show that rehabilitation of the hand is more effective when both hands are used. Indeed, the growth of the invalidated hand is more important when it is in parallel with the healthy hand. The system must take into account both hands. HandTrainer proposes a completely different approach to the rehabilitation of the hand. It will provide an interactive and entertaining look to the user, by offering him a serious game. It will therefore be able to work his rehabilitation while having fun. It may also use specific exercises every movement involved in rehabilitation.

The patient should be able to use the software from anywhere, only if it has a computer and the right equipment. It also needs an internet connection in order to send its result to the medical professional.

The doctor should be able to recover any time patient outcomes which he is responsible, in order to effectively study and follow their evolution. He needs the software and an internet connection.

= Team =

*Tutors : Didier Donsez, Alessandro Semere

*Members : Patrick Perea, Arthur Clerc-Gherardi, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Related documents =

= Project objectives =

* Create a software that can be used for hand recovery
* Develop a serious games and exercices that use the five rehabilitation movements
* Make it possible for doctors to follow his patients and their progression

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[HandTrainer-SRS|here]].

= Progress of the project =

The project started January 26th, 2015.

== Week 1 (January 26th - January 30th) ==

*Writing of the specifications

*Writing of the SRS that can be found [[HandTrainer-SRS| here]]

*Writing of different UML diagrams :
::- Context Diagram
::- Logical Diagram
::- Physical Diagram
::- Sequence Diagram
::- Use Case Diagram

*Comparison between different technology in order to chose the best one:
[[Image:Photo-Test-1.jpg|200px|Xtion Pro Live 1]]
[[Image:Photo-Test-2.jpg|200px|Xtion Pro Live 2]]
[[Image:Photo-Test-3.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-4.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-5.jpg|112px|Leap Motion]]

*Writing of the game scenario

== Week 2 (February 2nd - February 6th) ==
[[Image:Meeting-HandTrainer.jpg|250px|thumb|right|Meeting HandTrainer]]
*Choice of the Leap Motion for our application
*Design of game's HMI
*Design of software's HMI
*Writing of a game scenario
*Development of a web interface to make it possible for doctors to create their account
*Reflection about the necessary datas for the database
*Conception of the database
*Launching of the database on our server
*Choice of a communication protocol
*Choice of XML's architecture
*Conception of HMI Wireframe
*Meeting with Alessandro SEMERE

== Week 3 (February 9th - February 13th) ==

*Development of game design
*Development of authentification page for the software
*Sending of XML from the software for patient's medical records
*Reception of XML from the software for patient's medical records
*Writing notes by the doctor in XML
*Writing patient's progression in XML
*Training session about Handicap with Noella Renou from Execo-France
[[Image:Formation-Handicap.jpg|300px|center|Training Session Handicap]]

== Week 4 (February 16th - February 20th) ==

Holidays, less development this week

*Development of the action "Open a door" for the game
*Recognition of several rehabilitation movements :
::- Fist
::- Duck
::- Hand Opening
::- Claw
*Changing of servers because our OVH server didn't allow the direct access from the software

== Week 5 (February 23rd - February 27th) ==

*Development of the action "Destroy a wall" for the game
*Development of the action "Pull a lever" for the game
*Development of the action "Up a harrow" for the game
*Development of the action "Bring down a bridge" for the game
*Recognition of thumb rotation
*Development of level loading by XML
*Meeting with Alessandro Semere

== Week 6 (March 2nd - March 6th) ==
*Development of several HMI :
::- View for progression ( Patient side )
::- View for writing notes ( Doctor side )
::- View for adding patient ( Doctor side )
*Development of the score for the game
*Make it possible to add patients in the Database
*Reedition of several sprites in the game for a better visual

== Week 7 (March 9th - March 13th) ==
*Development of specific exercices for :
::*Claw
::*Duck
::*Fist
::*Thumb Rotation
::*Hand opening
*Development of a tutorial
*Development of HMI for :
::*Patient medical records ( Doctor side )
::*Consultation of patients list ( Doctor side )
::*Reading of notes ( Patient side )
*Link between Leap Motion and the game for each actions
*Meeting with Alessandro Semere

== Week 8 (March 16th - March 20th) ==
*Integration of the game in the main interface ( still working on it .. )
*Integration of the database link in the main interface
*Development of charts for the patient evolution
*Completion of several HMI
*Edition of charts for the final presentation
*Writing of the final report
*Meeting with Alessandro Semere

== Week 9 (March 23rd - March 27th) ==

*Edition of the video for Defi H
[[Image:Photo-Tournage-HandTrainer-1.jpg|250px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-2.jpg|250px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-3.jpg|200px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-4.jpg|250px|Tournage]]

HandTrainer

2015-03-25T07:32:00Z

RICM4-prj14-grp13: /* Week 9 (March 23rd - March 27th) */

[[Image:HandTrainer-Cover.jpg|400px|right|HandTrainer Cover]]
= Introduction =

In France, the rehabilitation is a major problem from the fact that patients have troubles taking charge of their own rehabilitation. They need to be supervised by a health professional. This is a strain of mobility and time for the patient and a significant cost. The patient must be able to rehabilitate from his home while being followed at a distance by the doctor in charge of the medical record.

Also, studies show that rehabilitation of the hand is more effective when both hands are used. Indeed, the growth of the invalidated hand is more important when it is in parallel with the healthy hand. The system must take into account both hands. HandTrainer proposes a completely different approach to the rehabilitation of the hand. It will provide an interactive and entertaining look to the user, by offering him a serious game. It will therefore be able to work his rehabilitation while having fun. It may also use specific exercises every movement involved in rehabilitation.

The patient should be able to use the software from anywhere, only if it has a computer and the right equipment. It also needs an internet connection in order to send its result to the medical professional.

The doctor should be able to recover any time patient outcomes which he is responsible, in order to effectively study and follow their evolution. He needs the software and an internet connection.

= Team =

*Tutors : Didier Donsez, Alessandro Semere

*Members : Patrick Perea, Arthur Clerc-Gherardi, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Related documents =

= Project objectives =

* Create a software that can be used for hand recovery
* Develop a serious games and exercices that use the five rehabilitation movements
* Make it possible for doctors to follow his patients and their progression

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[HandTrainer-SRS|here]].

= Progress of the project =

The project started January 26th, 2015.

== Week 1 (January 26th - January 30th) ==

*Writing of the specifications

*Writing of the SRS that can be found [[HandTrainer-SRS| here]]

*Writing of different UML diagrams :
::- Context Diagram
::- Logical Diagram
::- Physical Diagram
::- Sequence Diagram
::- Use Case Diagram

*Comparison between different technology in order to chose the best one:
[[Image:Photo-Test-1.jpg|200px|Xtion Pro Live 1]]
[[Image:Photo-Test-2.jpg|200px|Xtion Pro Live 2]]
[[Image:Photo-Test-3.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-4.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-5.jpg|112px|Leap Motion]]

*Writing of the game scenario

== Week 2 (February 2nd - February 6th) ==
[[Image:Meeting-HandTrainer.jpg|250px|thumb|right|Meeting HandTrainer]]
*Choice of the Leap Motion for our application
*Design of game's HMI
*Design of software's HMI
*Writing of a game scenario
*Development of a web interface to make it possible for doctors to create their account
*Reflection about the necessary datas for the database
*Conception of the database
*Launching of the database on our server
*Choice of a communication protocol
*Choice of XML's architecture
*Conception of HMI Wireframe
*Meeting with Alessandro SEMERE

== Week 3 (February 9th - February 13th) ==

*Development of game design
*Development of authentification page for the software
*Sending of XML from the software for patient's medical records
*Reception of XML from the software for patient's medical records
*Writing notes by the doctor in XML
*Writing patient's progression in XML
*Training session about Handicap with Noella Renou from Execo-France
[[Image:Formation-Handicap.jpg|300px|center|Training Session Handicap]]

== Week 4 (February 16th - February 20th) ==

Holidays, less development this week

*Development of the action "Open a door" for the game
*Recognition of several rehabilitation movements :
::- Fist
::- Duck
::- Hand Opening
::- Claw
*Changing of servers because our OVH server didn't allow the direct access from the software

== Week 5 (February 23rd - February 27th) ==

*Development of the action "Destroy a wall" for the game
*Development of the action "Pull a lever" for the game
*Development of the action "Up a harrow" for the game
*Development of the action "Bring down a bridge" for the game
*Recognition of thumb rotation
*Development of level loading by XML
*Meeting with Alessandro Semere

== Week 6 (March 2nd - March 6th) ==
*Development of several HMI :
::- View for progression ( Patient side )
::- View for writing notes ( Doctor side )
::- View for adding patient ( Doctor side )
*Development of the score for the game
*Make it possible to add patients in the Database
*Reedition of several sprites in the game for a better visual

== Week 7 (March 9th - March 13th) ==
*Development of specific exercices for :
::*Claw
::*Duck
::*Fist
::*Thumb Rotation
::*Hand opening
*Development of a tutorial
*Development of HMI for :
::*Patient medical records ( Doctor side )
::*Consultation of patients list ( Doctor side )
::*Reading of notes ( Patient side )
*Link between Leap Motion and the game for each actions
*Meeting with Alessandro Semere

== Week 8 (March 16th - March 20th) ==
*Integration of the game in the main interface ( still working on it .. )
*Integration of the database link in the main interface
*Development of charts for the patient evolution
*Completion of several HMI
*Edition of charts for the final presentation
*Writing of the final report
*Meeting with Alessandro Semere

== Week 9 (March 23rd - March 27th) ==

*Edition of the video for Defi H
[[Image:Photo-Tournage-HandTrainer-1.jpg|300px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-2.jpg|300px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-3.jpg|300px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-4.jpg|300px|Tournage]]

File:Photo-Tournage-HandTrainer-4.jpg

2015-03-25T07:31:38Z

RICM4-prj14-grp13:

File:Photo-Tournage-HandTrainer-3.jpg

2015-03-25T07:31:14Z

RICM4-prj14-grp13:

File:Photo-Tournage-HandTrainer-2.jpg

2015-03-25T07:30:57Z

RICM4-prj14-grp13:

File:Photo-Tournage-HandTrainer-1.jpg

2015-03-25T07:30:40Z

RICM4-prj14-grp13:

HandTrainer

2015-03-25T07:30:23Z

RICM4-prj14-grp13: /* Week 9 (March 23rd - March 27th) */

[[Image:HandTrainer-Cover.jpg|400px|right|HandTrainer Cover]]
= Introduction =

In France, the rehabilitation is a major problem from the fact that patients have troubles taking charge of their own rehabilitation. They need to be supervised by a health professional. This is a strain of mobility and time for the patient and a significant cost. The patient must be able to rehabilitate from his home while being followed at a distance by the doctor in charge of the medical record.

Also, studies show that rehabilitation of the hand is more effective when both hands are used. Indeed, the growth of the invalidated hand is more important when it is in parallel with the healthy hand. The system must take into account both hands. HandTrainer proposes a completely different approach to the rehabilitation of the hand. It will provide an interactive and entertaining look to the user, by offering him a serious game. It will therefore be able to work his rehabilitation while having fun. It may also use specific exercises every movement involved in rehabilitation.

The patient should be able to use the software from anywhere, only if it has a computer and the right equipment. It also needs an internet connection in order to send its result to the medical professional.

The doctor should be able to recover any time patient outcomes which he is responsible, in order to effectively study and follow their evolution. He needs the software and an internet connection.

= Team =

*Tutors : Didier Donsez, Alessandro Semere

*Members : Patrick Perea, Arthur Clerc-Gherardi, Paul Mariage

*Departement : [http://www.polytech-grenoble.fr/ricm.html RICM 5], [[Polytech Grenoble]]

= Related documents =

= Project objectives =

* Create a software that can be used for hand recovery
* Develop a serious games and exercices that use the five rehabilitation movements
* Make it possible for doctors to follow his patients and their progression

= Software Requirements Specification =

* The Software Requirements Specification (SRS) can be found [[HandTrainer-SRS|here]].

= Progress of the project =

The project started January 26th, 2015.

== Week 1 (January 26th - January 30th) ==

*Writing of the specifications

*Writing of the SRS that can be found [[HandTrainer-SRS| here]]

*Writing of different UML diagrams :
::- Context Diagram
::- Logical Diagram
::- Physical Diagram
::- Sequence Diagram
::- Use Case Diagram

*Comparison between different technology in order to chose the best one:
[[Image:Photo-Test-1.jpg|200px|Xtion Pro Live 1]]
[[Image:Photo-Test-2.jpg|200px|Xtion Pro Live 2]]
[[Image:Photo-Test-3.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-4.jpg|200px|3Gear system 1]]
[[Image:Photo-Test-5.jpg|112px|Leap Motion]]

*Writing of the game scenario

== Week 2 (February 2nd - February 6th) ==
[[Image:Meeting-HandTrainer.jpg|250px|thumb|right|Meeting HandTrainer]]
*Choice of the Leap Motion for our application
*Design of game's HMI
*Design of software's HMI
*Writing of a game scenario
*Development of a web interface to make it possible for doctors to create their account
*Reflection about the necessary datas for the database
*Conception of the database
*Launching of the database on our server
*Choice of a communication protocol
*Choice of XML's architecture
*Conception of HMI Wireframe
*Meeting with Alessandro SEMERE

== Week 3 (February 9th - February 13th) ==

*Development of game design
*Development of authentification page for the software
*Sending of XML from the software for patient's medical records
*Reception of XML from the software for patient's medical records
*Writing notes by the doctor in XML
*Writing patient's progression in XML
*Training session about Handicap with Noella Renou from Execo-France
[[Image:Formation-Handicap.jpg|300px|center|Training Session Handicap]]

== Week 4 (February 16th - February 20th) ==

Holidays, less development this week

*Development of the action "Open a door" for the game
*Recognition of several rehabilitation movements :
::- Fist
::- Duck
::- Hand Opening
::- Claw
*Changing of servers because our OVH server didn't allow the direct access from the software

== Week 5 (February 23rd - February 27th) ==

*Development of the action "Destroy a wall" for the game
*Development of the action "Pull a lever" for the game
*Development of the action "Up a harrow" for the game
*Development of the action "Bring down a bridge" for the game
*Recognition of thumb rotation
*Development of level loading by XML
*Meeting with Alessandro Semere

== Week 6 (March 2nd - March 6th) ==
*Development of several HMI :
::- View for progression ( Patient side )
::- View for writing notes ( Doctor side )
::- View for adding patient ( Doctor side )
*Development of the score for the game
*Make it possible to add patients in the Database
*Reedition of several sprites in the game for a better visual

== Week 7 (March 9th - March 13th) ==
*Development of specific exercices for :
::*Claw
::*Duck
::*Fist
::*Thumb Rotation
::*Hand opening
*Development of a tutorial
*Development of HMI for :
::*Patient medical records ( Doctor side )
::*Consultation of patients list ( Doctor side )
::*Reading of notes ( Patient side )
*Link between Leap Motion and the game for each actions
*Meeting with Alessandro Semere

== Week 8 (March 16th - March 20th) ==
*Integration of the game in the main interface ( still working on it .. )
*Integration of the database link in the main interface
*Development of charts for the patient evolution
*Completion of several HMI
*Edition of charts for the final presentation
*Writing of the final report
*Meeting with Alessandro Semere

== Week 9 (March 23rd - March 27th) ==

*Edition of the video for Defi H
[[Image:Photo-Tournage-HandTrainer-1.jpg|360px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-2.jpg|360px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-3.jpg|360px|Tournage]]
[[Image:Photo-Tournage-HandTrainer-4.jpg|360px|Tournage]]

HandTrainer-SRS

2015-03-25T07:24:50Z

RICM4-prj14-grp13: /* Logical database requirement */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:24:40Z

RICM4-prj14-grp13: /* Logical database requirement */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[Image:HandTrainer-Database.jpg|400px|Database Diagram]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:22:59Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:22:43Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|thumb|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|thumb|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|thumb|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:22:20Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|360px|Context Diagram]]
[[Image:HandTrainer-logique.png|360px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:22:00Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|350px|Context Diagram]]
[[Image:HandTrainer-logique.png|350px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|350px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:21:47Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|400px|Context Diagram]]
[[Image:HandTrainer-logique.png|400px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|400px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:21:34Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|300px|Context Diagram]]
[[Image:HandTrainer-logique.png|300px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|300px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:21:09Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|left|300px|Context Diagram]]
[[Image:HandTrainer-logique.png|right|300px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|center|300px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:20:46Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|left|500px|Context Diagram]]
[[Image:HandTrainer-logique.png|right|500px|Logical Diagram]]

ergregerg
[[Image:HandTrainer-Cas-Usage.png|center|500px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:20:24Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|left|500px|Context Diagram]]
[[Image:HandTrainer-logique.png|right|500px|Logical Diagram]] 

ergregerg
[[Image:HandTrainer-Cas-Usage.png|center|500px|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:20:12Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|left|500px|Context Diagram]]
[[Image:HandTrainer-logique.png|right|500px|Logical Diagram]] 

ergregerg
[[Image:HandTrainer-Cas-Usage.png|center|500px|humb|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:19:57Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|left|500px|Context Diagram]]
[[Image:HandTrainer-logique.png|right|500px|Logical Diagram]] 
[[Image:HandTrainer-Cas-Usage.png|center|500px|humb|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:19:44Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|left|500px|Context Diagram]]
[[Image:HandTrainer-logique.png|right|500px|Logical Diagram]] 
[[Image:HandTrainer-Cas-Usage.png|center|500px|humb|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:19:17Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|center|500px|Context Diagram]] 
[[Image:HandTrainer-logique.png|center|500px|Logical Diagram]] 
[[Image:HandTrainer-Cas-Usage.png|center|500px|humb|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:18:38Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|500px|Context Diagram]]::
[[Image:HandTrainer-logique.png|500px|Logical Diagram]]::
[[Image:HandTrainer-Cas-Usage.png|500px|humb|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:17:23Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|500px|Context Diagram]]
[[Image:HandTrainer-logique.png|500px|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|500px|humb|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:17:07Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|500px|thumb|Context Diagram]]
[[Image:HandTrainer-logique.png|500px|thumb|Logical Diagram]]
[[Image:HandTrainer-Cas-Usage.png|500px|thumb|Use Case Diagram]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:16:15Z

RICM4-prj14-grp13: /* Product perspective */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[Image:HandTrainer-Context.png|400px|thumb|right|HandTrainer Context]]
[[File:HandTrainer-logique.png]]
[[File:HandTrainer-Cas-Usage.png]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

HandTrainer-SRS

2015-03-25T07:15:21Z

RICM4-prj14-grp13: /* Licensing Requirements */

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[File:HandTrainer-Context.png]]
[[File:HandTrainer-logique.png]]
[[File:HandTrainer-Cas-Usage.png]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Still to be defined

File:HandTrainer-Database.jpg

2015-03-25T07:14:50Z

RICM4-prj14-grp13:

File:HandTrainer-Cas-Usage.png

2015-03-25T07:14:31Z

RICM4-prj14-grp13:

File:HandTrainer-logique.png

2015-03-25T07:14:08Z

RICM4-prj14-grp13:

File:HandTrainer-Context.png

2015-03-25T07:13:38Z

RICM4-prj14-grp13:

HandTrainer-SRS

2015-03-25T07:13:12Z

RICM4-prj14-grp13:

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
* [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
|-
|
!scope="col"| Version
!scope="col"| Date
!scope="col"| Authors
!scope="col"| Description
!scope="col"| Validator
!scope="col"| Validation Date
|-
!scope="row" |
| 0.1.0
| TBC
| TBC
| TBC
| TBC
| TBC

|}
=Introduction=

==Purpose of the requirements document==

:This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project .
:This document is a guideline about the functionalities offered and the problems that the system solves.

==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.

==Definitions, acronyms and abbreviations==

==References==

:*The main page of the project: [[HandTrainer| HandTrainer]]<br\>
:*[http://en.wikipedia.org Wikipedia] for definitions.

==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 | 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.

=General description=

==Product perspective==

[[File:HandTrainer-Context.png]]
[[File:HandTrainer-logique.png]]
[[File:HandTrainer-Cas-Usage.png]]

==Product functions==

:The product we are developping has several fonctions, separeted between the doctor and the patient.

:*'''Doctor''':
::- Registration on a website
::- Identification throught login and password
::- Create accounts for his patients so they can use the system
::- View the totality of his patients with quick summary
::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes
::- View patient progression in details
::- Send notes and advices to patients

:*'''Patient''':
::- Play serious games
::- Train in specific exercices
::- Send his results
::- View his progression
::- Consult notes

== User characteristics==
:* The user doesn’t need to be familiar with programming.
:* He has to understand how the program is working, and the camera needs to be set up.
:* He has to have an internet connexion in order to send his results.

==General constraints==
:*Platform constraints:
::- The system must operated on every platform that support the camera.

:*Environemental constraints:
::- Internet access is required in order to log in and send results
::- The environment must be optimal for finger and hand detection. In depends on the camera.

==Assumptions and dependencies==
:* The user as internet access
:* The user is in an environment that make it possible to get the shape and position of his hand and fingers
:* The camera and the software is well installed
:* The doctor and the patient have their account set up on the system

=Specific requirements, covering functional, non-functional and interface requirements=

==External interface requirements==
:The interface must be easy to use because our system is designed for all the patient, friendly or not with technology.
:The patient must understand clearly and quickly how to interact, send results, etc
:The doctor must not waste his time searching where are the fonctions

==Functional requirements==
:The system must help patient to rehabilitate their hand with different exercices
:The system must handle all the patient medical record which contain :
::-First name
::-Last name
::-Sex
::-Age
::-Weight
::-Type of disease
:The system must handle prescription for patient, e.g. exercices that has to be done
:The system must help doctors to follow their patient and their progression
:The system must deliver notes and advices given by the doctor to the patient properly, so that he can improve himself during his exercices

==Performance requirements==
==Design constraints==
:The system will be an MVC system. The server will be the center of our system, containing all the informations about patients and doctors, and will deliver access to patient and doctor.
:The clients software will communicate through the server for progression and notes

==Logical database requirement==

[[File:HandTrainer-Database.jpg]]

==Software System attributes==
===Reliability===
:The system must deliver correct informations all the time, so that :
::-The doctor will receive correct informations and progression about the patient
::-The patient will recieve correct exercices, advices and notes from the doctor

===Availability===
:The system must be available during a normal work day of a doctor, so that both patient and doctor are able to use it whenever they want.

===Security===
:The security of the system must be optimal, because medical informations about patients are confidential
:Communications have to be crypted between client and server

===Maintainability===
:Updates have to be easy to do, in order to :
::- Add exercices without problems
::- Correct bugs

:Server must be easy to reboot to maintain availability of our services

===Portability===
:For the moment, the system will be available in Windows only, because most of SDK are available on Windows.
:However, if SDK are available on other systems, we might release the system on other OS later.

==Other requirements==
:The system must be able to run on Windows 7 or higher
:The system must not consume to much CPU
:The system must not consume to much Memory

=Product evolution=
:The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive.

=Appendices=

==Specification ==
* The global project's page can be found [[HandTrainer | here]].

==Sources ==

==Licensing Requirements==

Proj-2014-2015-iRock/SRS

2015-03-23T10:31:00Z

RICM4-prj14-grp13: /* 4. Product evolution */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[Extensions XBMC Sujet 2015]]
*Last year project : [[Extensions XBMC Sujet 2014]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the Extensions XBMC 2015 project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=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)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use the updated version of LoRA
* Use STM Cube for future development
* Improve detection and prediction algorithme
* Implement an alarm system
* Enable reprogramming of micro-controllers from the backend

=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:'''
* 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]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T10:26:05Z

RICM4-prj14-grp13: /* 3.1 Requirement X.Y.Z (in Structured Natural Language) */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[Extensions XBMC Sujet 2015]]
*Last year project : [[Extensions XBMC Sujet 2014]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the Extensions XBMC 2015 project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=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)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** At least 5 microcontrollers (mix of STM32 Nucleo, F3 , F4)
** Mbed module for LoRA
** Sparkfun weather station
** Raspberry PI as the access point
** Battery power for a span of a year or 2.

*Software conditions:
** Keil MDK 4 or 5 to debug and flash micro-controllers
** Mbed compiler to debug and flash micro-controllers
** Grafana and InfluxDB association
** Appropriate relay program flashed on each micro-controller

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use of Bluetooth instead of/with the NFC tags
* Find a way to avoid installing Kinect sdk to use the Addon
* Play (a movie or a music) on the remote between two screens using an elegant method

=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:'''
* 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]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T09:59:34Z

RICM4-prj14-grp13: /* 3.1 Requirement X.Y.Z (in Structured Natural Language) */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[Extensions XBMC Sujet 2015]]
*Last year project : [[Extensions XBMC Sujet 2014]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the Extensions XBMC 2015 project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=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)==
Requirement : Grafana and InfluxDB installed on selected server hosting provider with enough bandwidth to accomodate the incoming data.

'''Function''': allow user to visualise environmental data sent over a long distance by LoRA Technology, and then predict landslides occurences.

'''Description''': Using LoRA enabled radio and sensors embedded to various microcontrollers (STM32 Nucleo STM32 F3, STM32 F4), we will get environmental data such as temperature, humidity, and land movement relayed to a time-based database and from theron, analyse the data and predict lanslides.

'''Inputs''': environmental data such as temperature, humidity and movement

'''Source''': STM32 Nucleo, F3 F4 and LoRA radio module

'''Outputs''': Time-based graphs and MS Excel files

'''Destination''': User and prediction algorithm

'''Action''':
* Deploy iRocks evenly over a terrain the size of a football field
* Start Grafana and InfluxDB
* If applicable, start prediction algorithm on output (Grafana or Excel files)

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** Android device with Wi-Fi and NFC
** NFC tags
** computers with screens
** network
** kinect (optionnal)

*Software conditions:
** netwotk between coputers used as screens and android device
** shared media files on the network between machines
** same version of Kodi on every computers used as screeens
** our Kodi Addon installed on the computers used as scrrens
** our remote control android applciation installed on the Android device
** kinect sdk installed on computer(s) where the kinect(s) is(are) connected

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use of Bluetooth instead of/with the NFC tags
* Find a way to avoid installing Kinect sdk to use the Addon
* Play (a movie or a music) on the remote between two screens using an elegant method

=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:'''
* 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]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T09:41:10Z

RICM4-prj14-grp13: /* 2.5 Assumptions and dependencies */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[Extensions XBMC Sujet 2015]]
*Last year project : [[Extensions XBMC Sujet 2014]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the Extensions XBMC 2015 project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider
*No obstacles between radio embedded micro-controllers

=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)==
Requirement : same version of Kodi (former XBMC) installed on the computers used as screens, our Addon installed on these computers, our version of the remote control application installed on an android device with NFC technology and Wi-Fi, a network between computers and android device, kinect sdk installed on the computers used with kinect mode, NFC tags, files shared on the network

'''Function''': allow user to change screen while watching a movie or listening to music with Kodi, with minimum interaction and resuming the media

'''Description''': an android application and a Kodi Addon to

'''Inputs''': options in the Addon, options in the Android application, number of person in front of a screen, "position" of the user

'''Source''': keyboard or mouse in the Addon option menu in Kodi, ouch screen on the Android device, kinect, NFC tags for the "position"

'''Outputs''': video or sound, depending of the media played

'''Destination''': user(s)

'''Action''':
* play media using network shared files
* resume play of media on various screen
* automatically add host on the remote control Android applicaion thanks to NFC tags

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** Android device with Wi-Fi and NFC
** NFC tags
** computers with screens
** network
** kinect (optionnal)

*Software conditions:
** netwotk between coputers used as screens and android device
** shared media files on the network between machines
** same version of Kodi on every computers used as screeens
** our Kodi Addon installed on the computers used as scrrens
** our remote control android applciation installed on the Android device
** kinect sdk installed on computer(s) where the kinect(s) is(are) connected

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use of Bluetooth instead of/with the NFC tags
* Find a way to avoid installing Kinect sdk to use the Addon
* Play (a movie or a music) on the remote between two screens using an elegant method

=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:'''
* 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]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence

Proj-2014-2015-iRock/SRS

2015-03-23T09:33:15Z

RICM4-prj14-grp13: /* 2.5 Assumptions and dependencies */

=1. Introduction=
==1.1 Purpose of the requirements document==
This Software Requirements Specification (SRS) identifies the requirements for the iRock project. This document is a guideline about the functionalities offered and the problems that the system solves.

==1.2 Scope of the product==

* The purpose of this project is to allow its users to predict and detect landslides and based on information sent by a number of sensors and radios embedded to microcontrollers.

* The code used in this project is extensible and open-source.

==1.3 Definitions, acronyms and abbreviations==
* '''LORA''' : 2-way wireless solution that complements M2M cellular infrastructure, and provides a low-cost way to connect battery operated and mobile devices to the network infrastructure
* '''SX1276''' : A stable implementation of LORA
* '''Mbed''' : A platform and operating system for internet-connected devices based on 32-bit ARM Cortex-M microcontrollers
* '''STM32 Nucleo''' : An affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features.
* '''Keil''' : Complete software development environment for a wide range of ARM, Cortex-M, and Cortex-R based microcontroller devices.

==1.4 References==
*Page of the project : [[Extensions XBMC Sujet 2015]]
*Last year project : [[Extensions XBMC Sujet 2014]]

==1.5 Overview of the remainder of the document==
The rest of the SRS examines the specifications of the Extensions XBMC 2015 project in details. Section two of the SRS presents the general features of the FollowME extension. Section three outlines the detailed, specific and functional requirements, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2. General description=
==2.1 Product perspective==
Monitor changes in environment such as temperature, movement, humidity and radio signal in order to detect landslides and predict the possibility of lanslides based on history

==2.2 Product functions==
The product has a built in relay infrastructure that transfer environmental data from the micro-controllers to a backend processing unit that stores the data in a time-based database. Analysis and prediction can be made based on this database, which is visualised in time graphs on Grafana.

==2.3 User characteristics==
The user does not need to be familiar with coding or computer science. But preliminary knowledge on geotechnical aspects of landslides is prefered to interpret the history of environmental data.

==2.4 General constraints==
* Communication based only on LoRA technology
* Deployment on non snowy terrain
* The user need to have a standard EC Amazon account activated for the backend
* Alarm notification system is not included in the scope of our project

==2.5 Assumptions and dependencies==
*Product availability/uptime depends on backend host provider

=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)==
Requirement : same version of Kodi (former XBMC) installed on the computers used as screens, our Addon installed on these computers, our version of the remote control application installed on an android device with NFC technology and Wi-Fi, a network between computers and android device, kinect sdk installed on the computers used with kinect mode, NFC tags, files shared on the network

'''Function''': allow user to change screen while watching a movie or listening to music with Kodi, with minimum interaction and resuming the media

'''Description''': an android application and a Kodi Addon to

'''Inputs''': options in the Addon, options in the Android application, number of person in front of a screen, "position" of the user

'''Source''': keyboard or mouse in the Addon option menu in Kodi, ouch screen on the Android device, kinect, NFC tags for the "position"

'''Outputs''': video or sound, depending of the media played

'''Destination''': user(s)

'''Action''':
* play media using network shared files
* resume play of media on various screen
* automatically add host on the remote control Android applicaion thanks to NFC tags

'''Non functional requirements''':

'''Pre-condition''':
*materials conditions:
** Android device with Wi-Fi and NFC
** NFC tags
** computers with screens
** network
** kinect (optionnal)

*Software conditions:
** netwotk between coputers used as screens and android device
** shared media files on the network between machines
** same version of Kodi on every computers used as screeens
** our Kodi Addon installed on the computers used as scrrens
** our remote control android applciation installed on the Android device
** kinect sdk installed on computer(s) where the kinect(s) is(are) connected

'''Post-condition''':

'''Side-effects''':

=4. Product evolution=

* Use of Bluetooth instead of/with the NFC tags
* Find a way to avoid installing Kinect sdk to use the Addon
* Play (a movie or a music) on the remote between two screens using an elegant method

=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:'''
* 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]

==5.2 Sources==
* The other groups who work on Kodi/XBMC extensions
* [http://www.microsoft.com/en-us/kinectforwindows/develop/learn.aspx www.microsoft.com/en-us/kinectforwindows]
* [http://developer.android.com/index.html developer.android.com]
* [https://www.python.org/doc/ www.python.org]
* [http://mirrors.xbmc.org/docs/python-docs/14.x-helix/ mirrors.xbmc.org/docs/]

==5.3 Licensing Requirements==
XBMC extension (or more precisly FollowMe) will be released under a GNU/GPL licence