Difference between revisions of "HandTrainer-SRS"
Jump to navigation
Jump to search
| (75 intermediate revisions by the same user not shown) | |||
| Line 27: | Line 27: | ||
|} |
|} |
||
| − | = |
+ | =Introduction= |
| − | == |
+ | ==Purpose of the requirements document== |
| − | This Software Requirements Specification (SRS) identifies the requirements for the [[HandTrainer | HandTrainer]] project . |
+ | :*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. |
+ | :*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. |
+ | :* 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). |
+ | :* 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. |
+ | :* The software is extensible to differents other games and exercices, in order to offer the best recovery for patients. |
| − | == |
+ | ==Definitions, acronyms and abbreviations== |
| + | ==References== |
||
| − | * '''Roaming''': It ensures that a wireless device is kept connected to the network, without losing the connection. |
||
| + | :*The main page of the project: [[HandTrainer| HandTrainer]]<br\> |
||
| − | *'''Telepresence''': It is refers to a set of technologies which allow a person to feel as if they were present, to give the appearance of being present. |
||
| + | :*[http://en.wikipedia.org Wikipedia] for definitions. |
||
| + | ==Overview of the remainder of the document== |
||
| − | *'''Ubuntu''': is a computer operating system based on the Debian Linux distribution and distributed as free and open source software, using its own desktop environment. |
||
| + | :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. |
||
| − | ==1.4 References== |
||
| + | =General description= |
||
| − | *Another project on RobAIR can be found here : [[http://air.imag.fr/index.php/Proj-2013-2014-RobAIR-1|Remote control of robAIR using WebRTC]] |
||
| − | *The main page of the project: [[RobAIR2013 | RobAIR]]<br\> |
||
| − | *[http://en.wikipedia.org Wikipedia] for definitions. |
||
| + | ==Product perspective== |
||
| − | ==1.5 Overview of the remainder of the document== |
||
| + | [[Image:HandTrainer-Context.png|360px|Context Diagram]] |
||
| − | The rest of the SRS examines the specifications of the [[robAIR2013]] project in details. Section two of the SRS presents the general factors that affect the [[robAIR2013|robAIR]] and its requirements, such as user characteristics and project constraints. Section three outlines the detailed, specific and functional requirements, performance, system and other related requirements of the project. Supporting information about appendices is provided in Section three. |
||
| + | [[Image:HandTrainer-logique.png|360px|Logical Diagram]] |
||
| + | [[Image:HandTrainer-Cas-Usage.png|360px|Use Case Diagram]] |
||
| + | ==Product functions== |
||
| − | =2. General description= |
||
| + | :The product we are developping has several fonctions, separeted between the doctor and the patient. |
||
| − | ==2.1 Product perspective== |
||
| + | :*'''Doctor''': |
||
| − | <gallery> |
||
| + | ::- Registration on a website |
||
| − | Image:DiagDeploymentRobAIR.png|General uml of the project |
||
| + | ::- Identification throught login and password |
||
| − | Image:Architecture_04_02.jpg|ROS architecture |
||
| + | ::- Create accounts for his patients so they can use the system |
||
| − | Image:ArchitectureROS.jpg|Detailed ROS architecture |
||
| + | ::- View the totality of his patients with quick summary |
||
| − | </gallery> |
||
| + | ::- View patient medical record with his progression, exercices he has done, exercices he has to do and personnal notes |
||
| − | As mentioned earlier, RobAIR project is part of a larger system consisting of the assembly of the robot (by the 3I4 students) and the ENSIMAG's RobAIR project.<br/> |
||
| + | ::- View patient progression in details |
||
| − | The project interacts with a STM card linked with a serial connection to transmit orders to the robot.<br/> |
||
| + | ::- Send notes and advices to patients |
||
| − | The ensimag project consists of the development of a platform to reserve a robot. |
||
| − | <br/><br/> |
||
| − | [[Media:DiagDeploymentRobAIR.png|This UML diagram]] is the general UML, representing the different parts of the project.<br/> |
||
| − | [[Media:Architecture_04_02.jpg|This global diagram]] represents how the different parts of the project are connected through ROS.<br/> |
||
| − | [[Media:ArchitectureROS.jpg|This detailed diagram]] explains the ROS architecture of the project in detail.<br/> |
||
| + | :*'''Patient''': |
||
| − | ==2.2 Product functions== |
||
| + | ::- Play serious games |
||
| + | ::- Train in specific exercices |
||
| + | ::- Send his results |
||
| + | ::- View his progression |
||
| + | ::- Consult notes |
||
| + | == User characteristics== |
||
| − | <gallery> |
||
| + | :* The user doesn’t need to be familiar with programming. |
||
| − | Image:usecase.jpg|Simple usecase |
||
| + | :* He has to understand how the program is working, and the camera needs to be set up. |
||
| − | Image:RobAir2013-RICM4-UseCase.jpg|More complete usecase |
||
| + | :* He has to have an internet connexion in order to send his results. |
||
| − | </gallery> |
||
| + | ==General constraints== |
||
| − | <br/> |
||
| + | :*Platform constraints: |
||
| − | The robot interface functions: |
||
| + | ::- The system must operated on every platform that support the camera. |
||
| − | ::- Control the robot |
||
| − | ::- See where the robot goes |
||
| − | ::- Know where is the robot |
||
| − | ::- Have a feedback on the robot state (battery level, problems encountered) |
||
| − | ::- Display data about the robot environement to get a feedback (robot velocity, position on the map) |
||
| − | <br/> |
||
| − | [[Media:usecase.jpg|This usecase]] is a simple usecase of our project (in French), representing the list of interactions between the user and the robot.<br/> |
||
| − | [[Media:RobAir2013-RICM4-UseCase.jpg|This usecase]] is a more complete usecase of our project, offering more action choices. |
||
| + | :*Environemental constraints: |
||
| − | ==2.3 User characteristics== |
||
| + | ::- Internet access is required in order to log in and send results |
||
| − | The user doesn’t need to be familiar with programming and doesn't need a specific formation. <br\> |
||
| + | ::- The environment must be optimal for finger and hand detection. In depends on the camera. |
||
| − | He just needs to know how to use a tablet and a television. <br\> |
||
| + | ==Assumptions and dependencies== |
||
| − | ==2.4 General constraints== |
||
| + | :* The user as internet access |
||
| − | *Platform constraints: |
||
| + | :* The user is in an environment that make it possible to get the shape and position of his hand and fingers |
||
| − | ::- ROS must operate on an Ubuntu platform. |
||
| + | :* The camera and the software is well installed |
||
| − | ::- Tablet's controller interfaces are developped for the Android platform. |
||
| + | :* The doctor and the patient have their account set up on the system |
||
| + | =Specific requirements, covering functional, non-functional and interface requirements= |
||
| − | *Environemental constraints: |
||
| − | ::- Wifi with Internet access for the robot and for the controller. |
||
| − | ::- The robot can’t climb up steep slopes. |
||
| + | ==External interface requirements== |
||
| − | ==2.5 Assumptions and dependencies== |
||
| + | :*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 robot site has wifi access in all the visit area. |
||
| + | :*The system must help patient to rehabilitate their hand with different exercices |
||
| − | ::- A 3D map of the visit site is provide. |
||
| + | :*The system must handle all the patient medical record which contain : |
||
| − | ::- The robot knows the position of its base. |
||
| + | ::-First name |
||
| − | ::- The robot base can be accessed at any time. |
||
| + | ::-Last name |
||
| − | ::- The robot can estimate the battery life time to know where he needs to go back at its base. |
||
| + | ::-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== |
||
| − | =3.Specific requirements, covering functional, non-functional and interface 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== |
||
| − | * document external interfaces, |
||
| − | * describe system functionality and performance |
||
| − | * specify logical database requirements, |
||
| − | * design constraints, |
||
| − | * emergent system properties and quality characteristics. |
||
| + | [[Image:HandTrainer-Database.jpg|center|400px|Database Diagram]] |
||
| − | == Functional, non-functional and interface requirements== |
||
| + | ==Software System attributes== |
||
| − | '''Function''': |
||
| + | ===Reliability=== |
||
| − | - Create a map of the current environment |
||
| + | :The system must deliver correct informations all the time, so that : |
||
| − | - Locate the robot with accuracy |
||
| + | ::-The doctor will receive correct informations and progression about the patient |
||
| − | - Allow automatic and semi-automatic movements in regards of the environment (obstacles, stairs, dogs, etc...) |
||
| + | ::-The patient will recieve correct exercices, advices and notes from the doctor |
||
| + | ===Availability=== |
||
| − | '''Description''': |
||
| + | :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 map is dynamically established thanks to both tablet and camera sensors. |
||
| + | :The security of the system must be optimal, because medical informations about patients are confidential |
||
| − | * Using the accelerometers, gyroscope and compass, RobAIR is able to locate himself with accuracy. This way, it can avoid obstacles. |
||
| + | :Communications have to be crypted between client and server |
||
| + | ===Maintainability=== |
||
| − | '''Inputs''': |
||
| + | :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 |
||
| − | * Robot state messages. |
||
| − | * Data about the current location, the environment, the speed, orientation, etc |
||
| + | ===Portability=== |
||
| − | '''Source''': |
||
| + | :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== |
||
| − | * Robot sensors |
||
| + | :*The system must be able to run on Windows 7 or higher |
||
| − | * Tablet sensors |
||
| + | :*The system must not consume too much CPU |
||
| − | * State and problems given by the robot |
||
| + | :*The system must not consume too much Memory |
||
| + | =Product evolution= |
||
| − | '''Outputs''': |
||
| + | :The system will be able to handle more and more exercices over time, so the rehabilitation is not boring and repetitive. |
||
| + | =Appendices= |
||
| − | * Map with current location of the robot |
||
| − | * Instructions and state changing orders |
||
| + | ==Specification == |
||
| − | '''Destination''': |
||
| + | * The global project's page can be found [[HandTrainer | here]]. |
||
| + | ==Licensing Requirements== |
||
| − | * RobAIR in order to operate itself |
||
| − | * The remote controller |
||
| − | * The tablet monitor |
||
| + | Still to be defined |
||
| − | '''Action''': |
||
| − | |||
| − | * The user must be able to control the robot displacements. |
||
| − | * The tablet interface shall access to external data. |
||
| − | * The robot must move in its environment without troubles ( avoiding obstacles ) |
||
| − | * The map must be really accurate in order to give a good overview of the position of RobAIR |
||
| − | |||
| − | |||
| − | * Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT) |
||
| − | * Mathematical Notations |
||
| − | * Tabular notations for several (condition --> action) tuples |
||
| − | |||
| − | '''Non functional requirements''': |
||
| − | |||
| − | The robot navigate in a safe area without dangers like: |
||
| − | * Cars circulation, |
||
| − | * Constructions, |
||
| − | * Young children or dogs. |
||
| − | |||
| − | '''Pre-condition''': |
||
| − | |||
| − | * Last version of RobAIR |
||
| − | * A tablet with required sensors and ROS environment |
||
| − | * A LDAP camera sensor |
||
| − | |||
| − | '''Post-condition''': |
||
| − | |||
| − | * RobAIR is controlled by the remote user using Skype (more information [[Proj-2013-2014-RobAIR-1|here]]) |
||
| − | |||
| − | '''Side-effects''': |
||
| − | |||
| − | =4. Product evolution= |
||
| − | ::- Use several tablets (with only one main tablet controlling the robot). |
||
| − | ::- Ability to read QRcodes and display related contents on the tablet. |
||
| − | ::- A vocal interface like a GPS. |
||
| − | ::- Control the robot thanks to a neuronal device. |
||
| − | ::- Switch between different robots. |
||
| − | ::- Thanks to a lidar, the robot makes its own map. |
||
| − | ::- 3D visioconferencing with the treament of two video stream. |
||
| − | |||
| − | =5. Appendices= |
||
| − | |||
| − | ==5.1 Specification == |
||
| − | * The global project's page can be found [[RobAIR2013|here]]. |
||
| − | * The page of the other RICM4 groups working on this project can be found here : [[Proj-2013-2014-RobAIR-1 | WebRTC group]] |
||
| − | |||
| − | * The UML of the project can be found [[RobAIR2013-RICM4-Groupe3-UML | here]]. |
||
| − | |||
| − | ==5.2 Sources == |
||
| − | * An exemple of JAVA node to communicate with ROS by Rémi Barraquand: [https://github.com/PALGate/palgate-trial/blob/master/prima/knx_control/ http://github.com/PALGate/palgate-trial] |
||
| − | |||
| − | *The RobAIR 2012 project by Thomas Calmant: [https://github.com/tcalmant/robair/blob/master/trunk/platforms/wifibot http://github.com/tcalmant/robair] |
||
| − | |||
| − | The robAIR 2013 projects : |
||
| − | |||
| − | :- [[RobAIR2013-RICM4-Groupe1-Suivi | Group 1]] |
||
| − | :- [[RobAIR2013-RICM4-Groupe2-Suivi | Group 2]] |
||
| − | :- [[RobAIR2013-RICM4-Groupe3-Suivi | Group 3]] |
||
| − | |||
| − | ==5.3 Licensing Requirements== |
||
| − | RobAIR will be released under a GPL license and will be open-source. |
||
Latest revision as of 09:41, 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:
- 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 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
- 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
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
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.
Licensing Requirements
Still to be defined