GLASSCHAIR

Software Requirements and Specification

VER 1.0

Introduction
 This section gives a scope description and overview of everything included in this SRS
document. Also, the purpose for this document is described and a list of abbreviations and
definitions is provided.

Purpose
The purpose of this document is to give a detailed description of the requirements for the
“Glasschair” software. It will illustrate the purpose and complete declaration for the
development of system. It will also explain system constraints, interface and interactions
with other external applications. This document is primarily intended to be proposed to a
customer for its approval and a reference for developing the first version of the system for
the development team.

Scope
“Glasschair” is a smart-glass based solution that helps people with disabilities to get mobile
independently. The application should be shipped with the whole package or the newer
version can be downloaded from the play store or some web portal.

People with disabilities who intend to use “Glasschair” should be able to drive independently
using their electric wheelchair. They can also contact their care-takers in emergency situations
and the rehab-shops in case they need some support concerning application.

Actors and Acronyms

User: Someone who interacts with the Glasschair application.

Rehab Admin: Someone who involves in distributing the Glasschair package and supporting the
user with their problems.

Glasschair Admin: Someone who can remotely help and configure the Glasschair application
for the user.

Glasschair Platform: A web portal where users, rehab and glasschair admin can login and use
respective services.

ACRONYMS USED:
FR Functional Requirements

PR Performance Requirements

OS Operating System

ID Identity

DESC Description

APP Application

BT Bluetooth

SNR Sensor

THR Threshold

HDD Hard Disk Drive

MEM Memory

SD System Dependability

DC Design Constraint

SSA Software System Attributes

REL Reliability

AVAIL Availability

SEC Security

MNT Maintainability

PORT Portability

Overview
The remainder of this document includes three chapters. The second one provides an overview of
the system functionality and system interactions with other systems. This chapter also introduces
different types of stakeholders and their interaction with the system. Further, the chapter also
mention the system constraints and assumptions about the product.
The third chapter provides the requirements specification in detailed terms and a
description of the different system interfaces. Different specification techniques are used in
order to specify the requirements more precisely for different audiences.

The fourth chapter deals with the prioritization of the requirements. It includes a motivation
for the chosen prioritization methods and discusses why other alternatives were not chosen.

The Appendixes in the end of the document include the all results of the requirement
prioritization and a release plan based on them.

Overall description
This section will give an overview of the whole system. The system will be explained in its
context to show how the system interacts with other systems and introduce the basic
functionality of it. It will also describe what type of stakeholders that will use the system and
what functionality is available for each type. At last, the constraints and assumptions for the
system will be presented.

Product perspective
This system will consist of three parts:
1. Smart glass application
2. A raspberry pi adapter
3. A web portal

The smart glass application will be used to drive the wheelchair hands-free using raspberry-pi
adapter and the web portal will be used as a platform for the distribution and support.

The smart glass application will capture head gesture commands using gyroscope and then will
send this command via Bluetooth to the raspberry-pi adapter for further processing. Adapter will
process this commands and then will take a predefined action based on the command.
The application needs bluetooth and gyroscope sensor from the smart glass hardware. The
functionality provided by the bluetooth will be embedded into the application in order for the
user to be able to use the functions in the applications in a seamlessly manner.

Since portal will be used for providing the onsite and remote support, it will be using a cloud-
based database to store all the relevant of the user.

The smart glass application has some restrictions about the resource allocation. To avoid
problems with overloading the operating system the application is only allowed to use 20
megabytes of memory while running the application.

Product functions
With the smart-glass based application, the user will be able to drive the wheelchair hands-free.
Steering the wheelchair will be based on head movements which will be the criteria for user
inputs. All the input commands will be visually shown on the screen for the user benefit.
Additionally, users will be able to switch between different driving modes based on the
requirement, change settings like speed, seat, calibration, and language. Users should also be
able to take picture just by using the head movements.

The web portal will be used for the distribution and configuration of the Glasschair product.

ctd...

User Characteristics
There are three types of actors that interacts with the Glasschair system
Users will use the application to drive the wheelchair.
Rehab admin will use the platform to configure glasschair system as an onsite support.
Glasschair admin will use the platform to configure users glasschair system remotely.

Constraints
Application on smart glass is constrained by following components:
● Operating System on the device must be Android v4.3 or higher (API>=18)
● Bluetooth Low Energy support i.e. version >= 4.0
 ● Presence of gyroscope on the device, with low latency report interval
● Front camera for taking pictures
● Wifi adapter to connect to internet

Hardware adapter is constrained by following components:

● Supports Bluetooth Low Energy i.e. version >= 4.0
● Supports GPIO pin architecture to interface with D9 connector
● Enough memory and processor to run linux based OS
● Ultrasound sensor has low latency in reporting the distance

Assumptions and dependencies

● Always used on a smart glass
● Smart glass has enough resources for running the application, eg. free memory greater
than 512 MB, processor with 1 GHz or more frequency
● Orientation sensors have the same coordinate frame in all smart glasses
● Sensors fast enough report interval to make application run smoothly (more details
below)

Apportioning of requirements
In the case that the project is delayed, there are some requirements that could be transferred to
the next version of the application. Those requirements are to be developed in the second release.

Specific requirements
External Interface Requirements
This section provides a detailed description of all inputs into and outputs from the system. It also
gives a description of the hardware, software and communication interfaces and provides basic
prototypes of the user interface.
User Interfaces
The only user interface for the user is to use the application on the smart glass to steer the
wheelchair or take pictures.

Hardware Interfaces
N/A

Software Interfaces
The application uses sensors in the device to get their values and use those to navigate in the
menu/the wheelchair/take pictures. It also uses bluetooth adapter on the device to communicate
to the adapter.

Communication Interfaces
The communication between the different parts of the system is important since they depend on
each other. However, in what way the communication is achieved is not important for the system
and is therefore handled by the underlying operating systems for both the mobile application and
the adapter.
Functional Requirements
This section includes the requirements that specify all the fundamental actions of the software
system.

FOR USER:
Functional requirement 1.1
ID: FR1
TITLE:
DESC:

FOR REHAB ADMIN:

Functional requirement 1.1
ID: FR1
TITLE:
DESC:

FOR GLASSCHAIR ADMIN

Functional requirement 1.1
ID: FR1
TITLE:
DESC:

Performance Requirements

FOR APPLICATION
ID: PR_APP_0
TITLE: Version of android OS on the device
DESC: The minimum version required to support the application is Android 4.3, which contains
API level 18.
FOR BLUETOOTH
ID: PR_BT_0
TITLE: Version of adapter on the device
DESC: The minimum version required to support the application is Bluetooth 4.0, which means
that the device must support Low Energy mode.

FOR HEAD GESTURE/CALIBRATION

ID: PR_SNR_0
TITLE: Latency of report interval of sensors
DESC: The minimum required latency between sensor values are received from the OS to the
app is approx 200 milliseconds.

System Dependability
ID: SD_OS_0
TAG: AndroidOSDependability
GIST: The android version on the system.
SCALE: If the application is installed on a device that has android version previous than 4.3, the
user should be informed about it and application should terminate after a few seconds.
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: 100% of the time.

ID: SD_BT_0
TAG: BluetoothDependability
GIST: The bluetooth connection of the system.
SCALE: If the application loses bluetooth connection, the user should be informed about it.
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: 100% of the time.

ID: SD_THR_0
TAG: ThresholdDependability
GIST: The fault tolerance of the system.
SCALE: If the application reads 0.0 or doesn’t find saved preference values, it should revert all
values to default(1.25) and inform the user to recalibrate.
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: 100% of the time.

ID: SD_SNR_0
TAG: SensorReadingDependability
GIST: The fault tolerance of the system.
SCALE: If the application receives sensor readings that are not in supposed range (-10 to +10),
it should inform the user and should not connect to the adapter and let user steer the wheelchair
because the outcome could be unknown.
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: 100% of the time.

Design Constraint

Hard drive space

ID: DC_HDD_0
TAG: HardDriveSpace
GIST: Hard drive space.
SCALE: The application’s need of hard drive space.
METER: MB.
MUST: No more than 25 MB.
PLAN: No more than 20 MB.
MB: DEFINED: Megabyte

Memory Usage
ID: DC_MEM_0
TAG: ApplicationMemoryUsage
GIST: The amount of memory occupied by the application.
SCALE: MB.
METER: Observations done from the performance log during testing
MUST: No more than 20 MB.
PLAN: No more than 15 MB
WISH: No more than 10 MB
MB: DEFINED: Megabyte
Software System Attributes
Reliability
ID: SSA_REL_0
TAG: SystemReliability
GIST: The reliability of the system.
SCALE: The reliability that the application steers the wheelchair in desired direction, changes
speed/seat-position, takes pictures from camera in the device.
METER: Measurements obtained from 1000 test-runs during testing.
MUST: More than 98% of accuracy.
PLAN: More than 99% of accuracy.
WISH: 100% of accuracy.

Availability
ID: SSA_AVAIL_0
TAG: SystemAvailability
GIST: The availability of the system when it is used.
SCALE: The average system availability (not considering network/bluetooth failure).
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: More than 98% of the time.
PLAN: More than 99% of the time.
WISH: 100% of the time.

ID: SSA_AVAIL_1
TITLE: Bluetooth Connection
DESC: The application should be connected to the adapter.
RAT: In order for the application to steer the wheelchair, change seat position or speed settings.
DEP: none

Security
ID: SSA_SEC_0
TAG: CommunicationSecurity
GIST: Security of the communication between the system and server.
SCALE: The messages should be encrypted for log-in communications, so others cannot get
user-name and password from those messages.
METER: Attempts to get user-name and password through obtained messages on 1000 log-in
session during testing.
MUST: 100% of the Communication Messages in the communication of a log-in session should
be encrypted.
Communication Messages: Defined: Every exchange of information between client and server.

ID: SSA_SEC_1
TAG: CommunicationSecurity2
GIST: Security of the communication between the application and the adapter.
SCALE: The messages should be encrypted for sending signals via bluetooth, so others cannot
sniff signals that are being sent to control the wheelchair.
METER: Attempts to guess the signal through obtained signals on 1000 driving sessions during
testing.
MUST: 100% of the Communication Messages in the transfer of a driving session should be
encrypted.
Communication Messages: Defined: Every exchange of information between application and
adapter.

ID: SSA_SEC_2
TAG: RehabPersonnelLoginAccountSecurity
GIST: Security of accounts.
SCALE: If an authorized rehab shop owner tries to log in to the web portal with a non-existing
account then the rehab shop owner should not be logged in. The person should be notified about
log-in failure.
METER: 1000 attempts to log-in with a non-existing user account during testing.
MUST: 100% of the time.
ID: SSA_SEC_3
TAG: AdminLoginAccountSecurity
GIST: Security of accounts.
SCALE: If an admin tries to log in to the web portal with a non-existing account then the admin
should not be logged in. The admin should be notified about log-in failure.
METER: 1000 attempts to log-in with a non-existing user account during testing.
MUST: 100% of the time.
ID: SSA_SEC_4
TAG: RehabPersonnelLoginAccountSecurity
GIST: Security of rehab personnel’s account.
SCALE: A rehab personnel should not be able to log-in for a certain time period after three times
of failed log-in attempts.
METER: 1000 attempts to log-in during the lock period after user account has been locked
because of failed log-in attempts of three times.
MUST: The locking period should be half an hour, and during that period the log-in function is
disabled.

ID: SSA_SEC_5
TAG: AdminAccountSecurity
GIST: Security of admin accounts.
SCALE: An admin should not be able to log-in to the web portal for a certain time period after
three times of failed log-in attempts.
METER: 1000 attempts to log-in during the lock period after user account has been locked
because of failed log-in attempts of three times.
MUST: The locking period should be half an hour, and during that period the log-in function is
disabled.

ID: SSA_SEC_6
TAG: UserCreateAccountSecurity
GIST: The security of creating account for users of the system.
SCALE: If a user wants to create an account and the desired user name is occupied, the user
should be asked to choose a different user name.
METER: Measurements obtained on 1000 hours of usage during testing.
MUST: 100% of the time.

ID: SSA_SEC_7
TAG: RehabPersonnelCreateAccountSecurity
GIST: The security of creating account for rehab personnel in the system.
SCALE: If a rehab personnel wants to create an account and the desired user name is occupied,
the rehab personnel should be asked to choose a different user name.
METER: Measurements obtained on 1000 hours of usage during testing. MUST: 100% of the
time.
Maintainability
ID: SSA_MNT_0
TITLE: Application extendibility
DESC: The application should be easy to extend. The code should be written in a way that it
favors implementation of new functions.
RAT: In order for future functions to be implemented easily to the application.
DEP: none

ID: SSA_MNT_1
TITLE: Application testability
DESC: Test environments should be built for the application to allow testing of the applications
different functions.
RAT: In order to test the application.
DEP: none

Portability
ID: SSA_PORT_0
TITLE: Application portability
DESC: The application should be portable with Android version on Google glass and other smart
glasses.
RAT: The adaptable platform for the application to run on.
DEP: none