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

1. Introduction

1.1 Purpose of the requirements document

This Software Requirements Specification (SRS) identifies the requirements for the robot RobAIR. In case of a open source project, we must present the requirement to others potential contributors. 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 telepresence robot that can be used for museum tours and the user will be able to guide the robot with a tablet. It can also be used for disabled so that they can follow their courses behind home.
It is a low cost robot (well below the maket price).
The platform and software used for this robot are extensible and open-source.

1.3 Definitions, acronyms and abbreviations

Roaming: It ensures that a wireless device is kept connected to the network, without losing the connection.

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.

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.

1.4 References

Another project on RobAIR can be found here : [control of robAIR using WebRTC]
The main page of the project: RobAIR<br\>
Wikipedia for definitions.

1.5 Overview of the remainder of the document

2. General description

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 General constraints

2.5 Assumptions and dependencies

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.

Functional, non-functional and interface requirements

Function: - Create a map of the current environment - Locate the robot with accuracy - Allow automatic and semi-automatic movements in regards of the environment (obstacles, stairs, dogs, etc...)

Description:

The map is dynamically established thanks to both tablet and camera sensors.
Using the accelerometers, gyroscope and compass, RobAIR is able to locate himself with accuracy. This way, it can avoid obstacles.

Inputs:

Robot state messages.
Data about the current location, the environment, the speed, orientation, etc

Source:

Robot sensors
Tablet sensors
State and problems given by the robot

Outputs:

Map with current location of the robot
Instructions and state changing orders

Destination:

RobAIR in order to operate itself
The remote controller
The tablet monitor

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

Side-effects:

4. Product evolution

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:

Proj-2013-2014-RobAIR-2/SRS

Contents