DHA Suffa University (DSU)

Department of Computer Science

Software Requirement Specifications

CYBORG-daBOT

Submitted by

MUHAMMAD HUNAIN (CS142053)

MUHAMMAD ASSAD SIYAL (CS142050)
TALHA IQBAL (CS142042)

Supervisor

MUHAMMAD AZMI UMER

In partial fulfilment of the requirements for the degree of
Bachelor of Science
(2018)
REVISION CHART

Version Primary Description of Version Date

Author(s) Completed
Assad, Hunain
CYBORG v1 Talha Initial draft created for distribution and review 15 March 2018
comments
Assad, Hunain
CYBORG v2 Talha Second draft incorporating initial review 17 March 2018
comments, distributed for final review
Assad, Hunain
CYBORG v3 Talha First complete draft, which is placed under 20 March 2018
change control

Assad, Hunain
CYBORG v4 Talha Final complete draft, which is giving as deliberal 25 March 2018
CONTENTS

1. Introduction ........................................................................................................................................ 5
1.1 Purpose of Document ................................................................................................................... 5
1.2 Intended Audience ........................................................................................................................ 5
1.3 Abbreviations ................................................................................................................................ 5
2. Overall System Description .............................................................................................................. 6
2.1 Project Background ....................................................................................................................... 6
2.2 Problem Statement ....................................................................................................................... 6
2.3 Project Scope ................................................................................................................................ 6
2.4 Not In Scope .................................................................................................................................. 6
2.5 Project Objectives ......................................................................................................................... 7
2.6 Stakeholders & Affected Groups .................................................................................................. 8
2.7 Operating Environment ................................................................................................................ 8
2.8 System Constraints ....................................................................................................................... 8
2.9 Assumptions & Dependencies ...................................................................................................... 8
3. External Interface Requirements ...................................................................................................... 9
3.1 Hardware Interfaces ..................................................................................................................... 9
3.2 Software Interfaces ....................................................................................................................... 9
3.3 Communications Interfaces .......................................................................................................... 9
4. System Functions / Functional Requirements ............................................................................. 10
4.1 System Functions ........................................................................................................................ 10
4.2 Use Cases .................................................................................................................................... 11
4.2.1 List of Actors........................................................................................................................ 11
4.2.2 List of Use Cases .................................................................................................................. 11
4.2.3 Use Case Diagram ............................................................................................................... 12
4.2.4 Description of Use Cases ..................................................................................................... 12
5. Non - Functional Requirements ..................................................................................................... 14
5.1 Performance Requirements ........................................................................................................ 16
5.2 Safety Requirements ................................................................................................................... 16
5.3 Security Requirements ................................................................................................................ 17
5.4 Reliability Requirements ............................................................................................................. 17
5.5 Usability Requirements ............................................................................................................... 17
5.6 Supportability Requirements ...................................................................................................... 17
5.7 User Documentation ................................................................................................................... 17
6. References ......................................................................................................................................... 19
1. Introduction

1.1 Purpose of Document

The reason of this archive is to supply a Nitti gritty diagram of our computer program items, its
parameters and objectives. This report portrays the project's target group of onlookers and its client
interface, equipment and computer program necessities.

1.2 Intended Audience

The intended audience of this project are the people who like to secure their areas by implementing
surveillance systems whether it a private organizations or government sectors.

1.3 Abbreviations

Term / Abbreviations Definition

API Application Programming Interface
Administrator system that will be responsible to manage complete
Super Admin
project ,having full access to system.
UI User Interface
COCO Common objects in context (coco) is a dataset for detection object
IDE Integrated Development Environment
MySQL MySQL is an open source relational database management system.
NG Non-Governmental Organization
NPO Non-Profit Organization
Viewer The user that can only view the system.
CRUD Create, Read, Update, Delete
2. Overall System Description

2.1 Project Background

According to our research and knowledge there is no such application/software being working that
can detect as well as try to find the person identification by recognizing the culprit with the help of
data provided over the internet. But there is Chinese base project more or less similar to our project
and working on it named as “Chinese street surveillance system”.

2.2 Problem Statement

We have seen that in a security control room only one or two operator are there to manage the huge
amount of computer screens. Normally human couldn’t watch all the computer screens properly at
the same time stamp. So there is a high chance of missing some important events.

2.3 Project Scope

 Target locker
 Objects scanner
 Unethical objects identifier
 Alarming system
 Person recognizer
 Alerting third party

2.4 Not in Scope

 Sensors other than GPS

 Weapon
 Third party control panel
 Client’s own database configuration
2.5 Project Objectives

It will scan all the objects that comes in front of the lens and when a harmful or
unethical object (i.e. gun, knife, etc.) comes in contact with a lens it will notify the
user and will lock that object and the person holding it and will try to identify the
person using facial recognition system form the provided database or over the social
media. We will highlight the target on display screen.
2.6 Stakeholders & Affected Groups

Stakeholders and affected groups of our project would be:

 Muhammad Hunain, Muhammad Assad Siyal and Talha Iqbal (FYP Student)
 Muhammad Azmi Umer (Supervisor)
 Dr. Hironao Takahashi (Co-Supervisor)
 Client( user of our product )

2.7 Operating Environment

Operating environment is a windows desktop application.

2.8 System Constraints

 Lack of resources.
 High processing machine.
 Data gathering.

2.9 Assumptions & Dependencies

 Our product is dependent on anaconda and python which should be installed

in windows.
 Dependent upon the high resolution camera.

 We are giving the user manual to the client and assume that the organization
or client that are going to use our surveillance system must go through the
given manual provided to them and we assume that they can understood the
operating manual.
3. External Interface Requirements

3.1 Hardware Interfaces

Desktop PC or laptop with internet connection.

Cameras for video streaming .
And hub/ports to manage the camera connections.

3.2 Software Interfaces

 Python
 Sypder IDE
 Java
 Netbeans IDE
 J-soup
 NoSQL
 Google API
 Anaconda

3.3 Communications Interfaces

rd
SMTP to send notification (mail) to 3 party.
4. System Functions / Functional Requirements

4.1 System Functions

Function Category Meaning

Evident Should perform, and user should be cognizant that it is performed.
Hidden Should perform, but not be visible to users. This is true of many
underlying technical services, such as save information in a persistent
storage mechanism. Hidden functions are often missed during the
requirements gathering process.
Frill Optional; adding it does not significantly affect cost or other functions.

Ref # Functions Category Attribute Details & Boundary

Constraints
R1.1 The Super Admin Evident System Login within 3 seconds.
shall be able to login Response time
into the system.

R1.2 The admin shall be Evident System Data shall be fed into the
able to Signup registration system within 2 seconds.
time

R2.1 The admin shall be Evident System Login within 3 seconds.

able to Login Response time

R3.1 The Detection Evident System Data shall be fed into the
Response time system within milliseconds.

R3.2 The searching culprit hidden System Login within 15 seconds.

Response time

R4.1 The Alarming system Hidden/ System Load The dashboard shall be
on time loaded within 1 minute
Frill

R4.2 The Notification Hidden/ System Data shall be fed into the
Response time system within milliseconds.
Frill
 System Attributes/ Nonfunctional Requirements

Attribute Details and Boundary Category

Constraints

Detect the object or culprit

Detection in milliseconds when Mandatory
comes in camera frames
Information gathering by
searching via facial
identification in system
Culprit Information database as much as Mandatory
quick we can,
Or search it over the
internet in case of not
found case from database
the searching speed for
this case is based upon
the internet speed.
Alarm active after the
detection phase within 1
Alarm activation minute. In case of panic Optional
occur
Or by press the panic
button by the operator
Notify the third party or any
Notification security agency via mail or Optional
sms in speedy time of
milliseconds

4.2 Use Cases

4.2.1 List of Actors

 Super Admin
 Admin
 system

4.2.2 List of Use Cases

 Login as Super Admin

 Login as Admin
 Detection
4.2.3 Use Case Diagram

Super Admin

Admin
System
4.2.4 Description of Use Cases

Section: Login as Super

admin

Name: Login

Actors: Super admin

Purpose: To create admins and change system settings

A super admin that have full access to the system can make any
Description: change
to the settings and assign the roles to the different users.
Cross References: Functions: R1.1, R1.2
Cases: The Super Admin shall be able to login into the system.
The
admin shall be able to Signup

Pre-Conditions Ideal System

Super admin can easily create sub admins, change settings,

Successful Post-Conditions distribute rights, view admin status, reset system and configure.

Failure Post-Conditions Super admin cannot fulfill these above functionalities.

Typical Course of Events

Actor Action System Response
Super admin logs in to the
1 system 2 Authentication and grant access

Grant sub admin username and

Super admin create sub Password as well as grant
3 admins 4 limited access

Updated settings being in

5 Super admin change setting 6 running state

Super admin change

7 password: 8 Password updated

System reset and configure to

9 Super admin reset the system 10 default.
Section: Login as Admin

Name: Login

Actors: Admin

Purpose: To monitor the system

An admin that will only monitor the working of the system and will
Description: be able to do some minor changes.

Cross References: Functions: R2.1

Cases: The Admin shall be able to login into the system.
And monitor system’s working

Pre-Conditions Ideal system

Successful Post-Conditions Admin can easily view system working.

Failure Post-Conditions Admin cannot fulfill these above functionalities.

Typical Course of Events

Actor Action System Response
1 Admin logs in to the system 2 Authentication and grant access
Monitor the system View the frames of camera and
3 program 4 system’s GUI

Section: Login as System

Name: working

Actors: System

Purpose: To perform functionality.

detection, facial identification, culprit identification, alarming
Description: system and notification.

Cross References: Functions: R3.1, R3.2, R4.1, R4.2

Cases: The System shall be able to perform perfectly.

Pre-Conditions Ideal System

System can perform detection, facial identification, culprit

Successful Post-Conditions identification, alarming system and notification without any issue.

Failure Post-Conditions System cannot fulfill these above functionalities.

Typical Course of Events

Actor Action System Response
Detectacts what the target is and
1 Highlight the target 2 returns the info

Selects the person to be Searches for the person’s

3 identified 4 information in database

Notify the 3rd party of the action

5 Notifying 6 occurred

.
0

5. Non - Functional Requirements

5.1 Performance Requirements

Response Time: Response time depends on the bandwidth of the internet; the
greater the bandwidth, the lesser the response time. Response time of the
search feature will not only depend upon the bandwidth but also upon the
 amount of data stored in the database. And the efficient query we apply to
retrieve the data from the database

Work load: Workload would depend upon the amount of data is stored in the
database, as our system gather a huge amount of data which include pictures,
names, address, numbers etc. so we should designed our system that much
efficient and fast to access the GBs of data in seconds

Scalability: Architecture of our system would be in such a way that it would be

able to handle the additional features when would we introduced in future.

Platform: The platform would be Desktop app for all operating systems, i.e.
Windows, Linux, etc.

5.2 Safety Requirements

 Proper arranged wired

 Cool environment
 Highly protected server room
 Properly setup of cameras
 Power backup
5.3 Security Requirements

 Bugs or Error free system

 Secure lan servers
 Decoy system / interface

5.4 Reliability Requirements

 System should be reliable (should not be corrupted)

 Database updating
 Maintainability

5.5 Usability Requirements

 System should be usable in different areas.

5.6 Supportability Requirements

 Client’s own database

5.7 User Documentation

 User operating guideline steps

 Reset the system to its default
 Password setting
 Admin rights sharing
 Configuration
6. References

List References