HandTrainer-SRS

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

Read first:
 * http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
 * http://en.wikipedia.org/wiki/Software_requirements_specification
 * IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

=1.  Introduction=

1.1 Purpose of the requirements document
This Software Requirements Specification (SRS) identifies the requirements for the HandTrainer project. This document is a guideline about the functionalities offered and the problems that the system solves.

1.2 Scope of the product

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

1.4 References

 * The main page of the project: HandTrainer
 * Wikipedia for definitions.

1.5 Overview of the remainder of the document
The rest of the SRS examines the specifications of the HandTrainer project in details. Section two of the SRS presents the general factors that affect the HandTrainer project and its requirements, such as user characteristics and project constraints. Section three outlines the detailed, specific and functional requirements, performance, system and other related requirements of the project. Supporting information about appendices is provided in Section three.

=2.  General description=

2.2 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

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

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

2.5 Assumptions and dependencies
=3.Specific requirements, covering functional, non-functional and interface requirements=

Functional, non-functional and interface requirements
=4. Product evolution=

=5. Appendices=

5.1 Specification

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