HandTrainer-SRS
Jump to navigation
Jump to search
The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.
Read first:
- http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
- http://en.wikipedia.org/wiki/Software_requirements_specification
- IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998
Version | Date | Authors | Description | Validator | Validation Date | |
---|---|---|---|---|---|---|
0.1.0 | 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 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<br\>
- 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 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
Diagrams here
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
Entity relationship diagrams
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 here.