Difference between revisions of "HandTrainer-SRS"

From air
Jump to navigation Jump to search
Line 152: Line 152:
   
 
==Other requirements==
 
==Other requirements==
:The system must be able to run on Windows 7 or higher
+
:*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 CPU
:The system must not consume too much Memory
+
:*The system must not consume too much Memory
   
 
=Product evolution=
 
=Product evolution=

Revision as of 09:39, 25 March 2015

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


Read first:

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

Introduction

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.

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).
  • The software is extensible to differents other games and exercices, in order to offer the best recovery for patients.

Definitions, acronyms and abbreviations

References

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.

General description

Product perspective

Context Diagram Logical Diagram 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

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

Sources

Licensing Requirements

Still to be defined