Project Title:

BACK AGITATING INTREFACE NETWORK

SOFTWARE REQUIREMENT SPECIFICATION (S.R.S.)

Project Members:
Mehran Khan FA16-BCS-070/WAH
Fazal-e-Majid FA16-BCS-102/WAH

Supervised By:
Dr. Faisal Azam

Date:
07th January, 2020

Department of Computer Science

COMSATS University Islamabad, Wah Campus
TABLE OF CONTENTS
1 Introduction ................................................................................................................... 1
Purpose............................................................................................................ 1
Scope ............................................................................................................... 1
Overview ......................................................................................................... 1
2 General Description ...................................................................................................... 2
Product Functions ........................................................................................... 2
User Characteristics ........................................................................................ 2
User Problem Statement ................................................................................. 2
User Objectives ............................................................................................... 2
General Constraints ........................................................................................ 2
3 Functional Requirements .............................................................................................. 3
Patterns............................................................................................................ 3
Communication ............................................................................................... 3
Software Intrection ......................................................................................... 4
Object detector ................................................................................................ 4
Fuel detector ................................................................................................... 5
4 Interface Requirements ................................................................................................. 5
User interface .................................................................................................. 5
GUI ................................................................................................................. 5
Hardware Interface ......................................................................................... 6
Communication Interface ............................................................................... 6
Software Interface ........................................................................................... 7
5 Performance Requirements ........................................................................................... 7
6 Design Constraints ........................................................................................................ 7
Standards Compliance .................................................................................... 7
Hardware Limitations ..................................................................................... 7
Software Limitations ...................................................................................... 7
Portability Constraints .................................................................................... 7
7 Other Non-Functional Attributes .................................................................................. 8
Security ........................................................................................................... 8
 Reliability........................................................................................................ 8
Maintainability ................................................................................................ 8
Portability........................................................................................................ 8
Extensibility .................................................................................................... 8
Reusability ...................................................................................................... 8
Availability ..................................................................................................... 8
Flexibility ........................................................................................................ 8
Efficiency ........................................................................................................ 8
Application Affinity/Compatibility ................................................................ 8
Serviceability .................................................................................................. 9
Binary Compatibility ...................................................................................... 9
8 Operational Scenarios ................................................................................................... 9
Use Case Diagram .......................................................................................... 9
Class Diagram ............................................................................................... 12
Class Descriptions ........................................................................................ 12
Aero plane ..................................................................................................... 12
Object ............................................................................................................ 13
Fuel ............................................................................................................... 13
Distance ........................................................................................................ 14
Arduino ......................................................................................................... 14
Fuel vibrator .................................................................................................. 14
Object vibrator .............................................................................................. 15
Distnace vibrator ........................................................................................... 16
Introduction

1 INTRODUCTION
In this world everyone wants security for their institutes, organizations, homes and
offices so they use cameras and alarms but there were some problems in these
security tools like a person cannot continuously see the cameras or cannot listen
alarms at any time. To solve these problems we want to create a security system in
which a person can alert without seeing the cameras and without listing any alarms.
In this project we will receive values on a shirt from desktop on the motion of 3D
object. The motion of object will send values to the specific vibrator and vibrator will
tell us about the events acting on it without seeing desktop. Desktop will have
different types of parameters i.e. for distance, height, and fuel etc. When object do
some action these parameters will sent value to the shirt and shirt will activate a
vibrator across the parameter value.
PURPOSE
The purpose of this SRS document is to provide a detailed overview of our
project, its parameters and goals. The system will help the people in security
and management of the specific company and this project will show that how it
is as potential and successful as compare to other security systems. This
document describes the project's target audience and its user interface,
hardware and software requirements.
SCOPE
We are making different type of security system which will be easy to use and it can
also be used at any place for any type of security system it will help people without
any stress or without seeing any cameras.
OVERVIEW
This system will be value able for all of those people who are somehow attached
with security base system. Our security shirt will help those people at any time by
creating vibration on the person’s body every vibrator will have different pattern of
vibrations which will show the currently doing irrelevant task of the specific
location.

1|Page
General Description

2 GENERAL DESCRIPTION
PRODUCT FUNCTIONS
I. Desktop 3D motion of object like game.
II. Receiving signals from desktop to shirt through arduino.
III. Shirts will be provided to the users, by wearing shirt user will tell about event.
IV. Different vibrators with different patterns for event detections.
V. Prediction will show maximum day of occurring events.
VI. User can identify most occurring event and can resolve it.
USER CHARACTERISTICS
I. User 1: He is the primary user of the system. He will maintain all kinds of
data visible to him on desktop.
II. User 2: He is the other hand user wearing shirt. He will tell about the
actions acting on desktop without seeing it.
USER PROBLEM STATEMENT
The system will help the people of any organizations to maintain their security
systems by predicting events they can save coming events for them, which can help
to save their money, time and even their lives.
USER OBJECTIVES
• The system will help users to attentive him without seeing cameras or
listening alarms.
• System will predict the most occurring events for the next time.
• Through this system the people of the organization will be relaxed by using
this shirt.
GENERAL CONSTRAINTS
General constraints of this system are that it requires a shirt with vibrators on it
and connection of vibrators with the desktop through arduino.

2|Page
Interface Requirements

3 FUNCTIONAL REQUIREMENTS
1: Patterns

2: Communication
3: Software interaction
4: Object detector
5: Fuel detector

1. Patterns
On desktop side we will have different types of patterns used for the multiple
categories which get values as parameters and then send it to the hardware having
vibrators by using arduino.

2. Communication

It will show the communication between desktop and vibrators of shirt through
arduino. We will change the object on desktop side and by changing it the vibrator
will become active which means that they have some communication with each
other.

3. Software Interaction

On desktop side one user will interact the 3D model software. User will move an
object on the desktop side just like game. Its means that one of the user is
required for interaction with the software.

4. Object detector

If the object is in the air or moving upward, downward, left or right in software
just like game by changing its motion it will create some values these values will
be sent to the hardware through arduino and specific vibrator across the value
will be activated and by intensity of vibration the other user will be point out its
location.

4|Page
Interface Requirements

5. Fuel detector

If the object cover some distance it will also consume fuel and we will also set
values across the fuel whenever the fuel getting low it will sent a message to the
user who wearing shirt, vibration will produce across the fuel parameter and we
will be know about the fuel that how much is remaining without seeing the
screen of the desktop.

4 INTERFACE REQUIREMENTS
The system will have a user-friendly UI which will be easily understandable for anyone
who uses it.
USER INTERFACE
GUI
User Interface will be 3D based Game with which the invigilator will interact and produce readings to the
hardware.

HARDWARE INTERFACE
In our project we will have a shirt with multiple vibrators which will be connected
to the arduino and the arduino will take values from some system or desktop and
will activate the specific vibrator on shirt against that value. The vibration of the
vibrator is depends on the values if the value is low the vibration will be low but
whenever the values are gradually increasing the vibrator against these values will
be also increasing.

COMMUNICATION INTERFACE
The communication between the components of the system has key importance,
as they depend on each other. Therefore, our system will communicate
between hardware and software through arduino and is the main part of our
project that we want to communicate our system with the our hardware(shirt).

4|Page
Performance Requirements

SOFTWARE INTERFACE
The software interface of the proposed system along with all its components will
look like:

Figure 4.3: Software Interface Diagram

5 PERFORMANCE REQUIREMENTS
Since the system is hardware based, it required hardware and software. The system
requires signals from software and sends it to hardware through arduino.

6 DESIGN CONSTRAINTS
STANDARDS COMPLIANCE
The system should only contain the source code that complies through arduino
for the hardware and will action against that code.
HARDWARE LIMITATIONS
Our system is totally based on hardware without hardware our system cannot
work. All the system is based on a shirt which will be restricted for values and
act against on it.
SOFTWARE LIMITATIONS
The system requires a suitable connection with arduino through usb port
through which it send values or parameters.
PORTABILITY CONSTRAINTS
This system should be designed in such a way that porting this system on any
environment should incur only minimal effort.

6|Page
Other Non-Functional Attributes

7 OTHER NON-FUNCTIONAL ATTRIBUTES

SECURITY
The system should be able to protect privacy of user data. Workspace of the
technical user should only be accessed through user’s own credentials and any
other user should not be able to access the user’s private data.
RELIABILITY
The system has to be reliable due to the importance of data and the damages that
can be caused by incorrect or incomplete data.
MAINTAINABILITY
The system has to be reliable due to the importance of data and the damages that
can be caused by incorrect or incomplete data.
PORTABILITY
The system is fully portable and any system using any security system should
be able to use the features of the system, including any hardware platform that
is available or will be available in the future.
EXTENSIBILITY
The system can be extended later with other functionalities required.
REUSABILITY
If a company needs the data relating to security, then the system should be
capable enough to provide the data that they require.
AVAILABILITY
The system will be operational 24 hours a day and 7 days a week.
FLEXIBILITY
Flexible service will be highly desirable for future extension. Non-Functional
Requirements define system properties and constraints.
EFFICIENCY
Mean Time to Repair (MTTR). Even if the system fails, the system will be
recovered back up within a day or less.
APPLICATION AFFINITY/COMPATIBILITY
The desktop software presence shall be compatible with all modern systems.

7|Page
Operational Scenarios

SERVICEABILITY
It will provide the administrators an easy-to-use interface with capabilities to
maintain the system.
BINARY COMPATIBILITY
The system will be operational with any operating system.

8 OPERATIONAL SCENARIOS

USE CASE DIAGRAM

9|Page
Operational Scenarios

Figure 8.1: Software Use Case

10 | P a g e
Operational Scenarios

CLASS DIAGRAM

Figure 8.5: Class Diagram

11 | P a g e
Operational Scenarios

CLASS DESCRIPTIONS
AEROPLANE
1. ABSTRACT OR CONCRETE
Abstract Class.
2. LIST OF SUPER-CLASSES
None
3. LIST OF SUB-CLASSES
• Object class.
• Fuel Class.
• Distance class
4. PURPOSE
The purpose of making this super-class is because object, fuel and
distance are using the same attributes.
5. COLLABORATIONS
This class doesn’t need to collaboration with any other class because
it is a super-class itself.
6. OPERATIONS
• Take-off()
• landp()
7. CONSTRAINTS
None

OBJECT
8. ABSTRACT OR CONCRETE
Concrete Class.
9. LIST OF SUPER-CLASSES
• Aero plane Class
10. LIST OF SUB-CLASSES
None.
11. PURPOSE

12 | P a g e
Operational Scenarios

The purpose of this class is to define the working of aero plane so

that they can find the motion, fuel and distance of aero plane.
12. COLLABORATIONS
This class depends upon Aero plane Class for take-off and land.
13. OPERATIONS
• left()
• right()
14. CONSTRAINTS
None

FUEL
1. ABSTRACT OR CONCRETE
Concrete Class.
2. LIST OF SUPER-CLASSES
• Aero plane Class
3. LIST OF SUB-CLASSES
None
4. PURPOSE
The purpose of this class is to define the use of fuel so that they can
the usage of fuel of aero plane.
5. COLLABORATIONS
This class depends upon aero plane Class for finding the use of fuel.
6. OPERATIONS
• low()
• high()
• medium()
7. CONSTRAINTS
None
DISTANCE
1. ABSTRACT OR CONCRETE
Concrete Class
2. LIST OF SUPER-CLASSES
Aero plane
3. LIST OF SUB-CLASSES
None
4. PURPOSE
13 | P a g e
Operational Scenarios

The purpose of this class is to the distance of the aero plane.

5. COLLABORATIONS
None
6. OPERATIONS
• near()
• far()
• medium()
7. CONSTRAINTS
None

14 | P a g e
Operational Scenarios

ARDUINO
1. ABSTRACT OR CONCRETE
Concrete Class.
2. LIST OF SUPER-CLASSES
None
3. LIST OF SUB-CLASSES
None
4. PURPOSE
Purpose of this class is to get input and send output.
5. COLLABORATIONS
This class depends upon object, fuel and distance Class for execution.
6. OPERATIONS
• get input()
• show output()
7. CONSTRAINTS
None
FUEL VIBRSTOR
1. ABSTRACT OR CONCRETE
Concrete Class
2. LIST OF SUPER-CLASSES
None
3. LIST OF SUB-CLASSES
None
4. PURPOSE
Purpose of this class is to active the fuel vibrator against the fuel
value getting from arduino.
5. COLLABORATIONS
None
6. OPERATIONS
• low()
• high()
• medium()
7. CONSTRAINTS
None

15 | P a g e
Operational Scenarios

OBJECT VIBRATOR
1. ABSTRACT OR CONCRETE
Concrete Class
2. LIST OF SUPER-CLASSES
None
3. LIST OF SUB-CLASSES
None
4. PURPOSE
Purpose of this class is to active the object vibrator against the
object value getting from arduino.
5. COLLABORATIONS
None
6. OPERATIONS
• left()
• right()
• up() / down()
7. CONSTRAINTS
None

DISTANCE VIBRATOR
1. ABSTRACT OR CONCRETE
Concrete Class
2. LIST OF SUPER-CLASSES
None
3. LIST OF SUB-CLASSES
None
4. PURPOSE
Purpose of this class is to active the distnace vibrator against the
distance value getting from arduino.
5. COLLABORATIONS
None
6. OPERATIONS
• near()
• far()
• medium()
7. CONSTRAINTS
None
16 | P a g e
Operational Scenarios

Sequence Diagram :

17 | P a g e
Operational Scenarios

Page 18