FACULTY OF ENGINEERING & TECHNOLOGY

Sub name: Software Engineering -(303105254)

B. Tech. 2nd Year/4th semester

Practical – 03
Aim :- Prepare Software Requirement Specification (SRS) document for the
selected module.
Project Title :- IoT Remote Monitoring and Controlling for Smart Home
Management.
Table of Contents
1. Introduction ………………………………………………………. 1
1.1 Purpose …………………………………………………… 1
1.2 Scope ……………………………………………………… 1
1.3 Definitions, Acronyms & Abbreviations ………………… 2
1.4 References ………………………………………………… 2
1.5 Overview ………………………………………………… 2
2. Overall Description
2.1 Product Perspective ……………………………………… 3
2.2 Product Functions ……………………………………… 3
2.3 User Characteristics …………………………………… 4
2.4 Constraints ……………………………………………… 4
2.5 Dependencies and assumptions ………………………… 5
3. Specific Requirements
3.1 functional Requirements
3.1.1 Login ………………………………………….. 5
3.1.2 Explore Courses ……………………………… 6
3.1.3 Register Courses ……………………………… 7
3.1.4 Generate Course Schedule …………………… 8
3.1.5 Recommend Courses ………………………… 9
3.1.6 Maintain Student information ………………… 9
3.1.7 Maintain Course Catalog ……………………… 11
3.1.8 Validate Choices ……………………………… 11
3.2 Non-Functional Requirements
3.2.1 Accuracy ……………………………………… 12
3.2.2 Security ……………………………………… 12
3.3 System Attributes
3.3.1 Scalability …………………………………… 13
3.3.2 Reliability …………………………………… 13

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

1. Introduction
1.1 Purpose
The purpose of this project is to provide a smart home system on top of the
existing home appliances. The smart home management system will
automate the process of managing the appliances and will create an
integrated network of home appliances and various sensors. A central
controller will manage the network and make smart decisions based on the
sensor and user inputs. This would revolutionize our lifestyles and
transform the way in which we perform day to day tasks such as controlling
appliances, floor cleaning, kitchen tasks, multimedia tasks, etc. Smart
home System should also provide security and safety. This document, the
Software Requirement Specifications (SRS), is used to describe and track
all the requirements for the smart home system. It provides a description
of all the functions, specifications, external behaviors, design constraints,
requirements (function and non-functional) and other factors.
1.2 Scope
The Smart Home Manage Management System will reduce the physical
interaction of homeowners with the various appliances like TV, fan, lights
AC, etc. SMART here stands for Self-Monitoring Analysis and Reporting
Technology. The SHMS will blend in the IoT technology into our homes.
Currently, majority of the houses continues to remain apart from the smart
technology. Every appliance like TV, AC, home theatre, etc. comes with
its own remote and each and every gadget or device has no sort of
communication with other devices. The functionality of the devices are
limited to themselves and there isn’t any central controller to control to
provide any sort of feedback and handle the various devices i.e no sort of
automation is performed.
A system comprising of majorly 4 components i.e Electronic Devices and
Sensors, Wireless Network, Central Controller and User Interface can be
deployed into the residences. The SHMS would provide ease of living to
its users. With environment sensing and appliance monitoring, the system
aims to reduce the energy and the billing costs by optimizing the energy
settings and switching off devices which are not in use via constant
monitoring. The system would also alert the user in case of any sort of
emergency. SHMS would need to tackle the issues of security, reliability,
cost of ownership and inflexibility caused due to lack of standardization.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

1.3 Definitions, Acronyms and Abbreviations

TERM DEFINITION

SHMS Smart Home Management System

RFID Radio Frequency Identification
DBMS Database Management System
SKA Smart Kitchen Assistant
IOT Internet Of Things
UPS User Profiling System
SFC Smart Floor Cleaner
UI User Interface
IR Infrared
WSN Wireless Sensor Network
FR Functional Requirement
NFR Non Functional Requirement
SRS Software Requirements Specifications

User Any resident of the SHMS

Admin Administrator of the SHMS
Traditional Functioning as if the system did not exist

1.4 References
1. Scribd website
2. King, Samuel. “Smart fire alarm and gas detection system.”
3. Colens Andre. “Automatic machine and device for floor dusting.”
4. Robles, Rosslin John, Tai-hoon Kim, D. Cook. “A review on security
in smart home development.”
5. Monaco, Pietro A. “Smart garage door opener.”

1.5 Overview
The remainder of this document includes two chapters.
The second chapter provides an overview of the system functionality and
system interaction with other systems. This chapter also introduces

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

different types of actors and their interaction with the system. Further, it
also mentions the system constraints and assumptions about the product.
The third chapter specifies the requirements in detailed terms and provides
a description of the various system interfaces. Also, different specification
techniques are used in order to specify the requirements more precisely for
different audiences.
2. Overall Description
2.1 Product Perspective
The SHMS is an enhancement over the usual home structure. The recent
bloom in IoT technology has opened up millions of possibilities by
providing the capability to connect devices to the internet and integrate
them to define an integrated system of devices of sorts. The proposed
SHMS is a direct implication of IoT as well as other latest tech such as
robotics, DBMS, RFID, WSN, Artificial Intelligence techniques and many
more. The user can continue to perform day to day tasks in a traditional
manner or choose to use the functionalities of the SHMS depending on
his/her choice.
2.2 Product Functions
The above mentioned product description and the interaction between
different modules is intended to be achieved by the help of following
different functionalities:
• A login interface with authentication will allow the different users to
interact with the system. Only the registered users will be able to
interact with the SHMS via the GUI.
• The system will monitor the environmental parameters such as
temperature, humidity, air quality, light intensity, etc. inside the SHMS
and allow the users to view these parameters anytime.
• The system will allow user to control and manage the appliances using
the capabilities of the GUI without any physical interaction.
• The user can monitor and control the SHMS remotely as well.
• The system is equipped with security cameras as well a secure front
door with video capture, facial recognition and PIN security.
• The system is also equipped with fire and gas leakage alarms to alert
the user of any potential mishap.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

• The system has a mobile robot floor duster to assist in the floor cleaning
tasks.
• A UPS is also present which analyzes user choices and preferences and
collects this data to make customized user settings for each user and
adjust the home environment accordingly based on that data.
• A SKA is present to assist the user with kitchen activities such as
locating items or finding recipe or to get some food suggestions.
• The system also possesses the capability to alert the concerned
authorities in case of some mishappening such as fire or burglary.

2.3 User Characteristics

The users are categorized as registered and unregistered users. Only

registered users are allowed to access the functionalities of the SHMS and
unregistered users are not allowed to interact with the SHMS.
The proposed system is intended for users of any age above 10 years. They
just need to possess the basic Knowledge and awareness of operating the SHMS
using the GUI.
The users need not have any knowledge about the involved technologies
such as IoT, RFID, Wireless networking, Artificial Intelligence, et. They just
need to follow the user guidelines for the product.

2.4 Constraints

Internet connectivity is required at all times

RFID associated with the devices
Power availability at all times
There would be some memory constraints due to the capacity of the
Database
Different sensors support different communication mechanisms so there
would be some communication interoperability constraints.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

Time is also a constraint because the system is expected to respond to user

commands or trigger events as early as possible. Communications happening with
the central controller should also be in a time constrained manner.
2.5 Assumptions and dependencies
One assumption about the SHMS is that it the hardware on which GUI is
run would have enough resources available to run the application smoothly

3. Specific Requirements
3.1 Functional Requirements
The functional requirements of the system is represented by the help of use
cases and their description. The following are the use cases that depict the
system functionalities in an abstract manner.
3.1.1 Login use case
• This use case provides the functionality of singing in the system to
interact with other interfaces.
• It helps differentiate between registered users and new users. The new
users are provided interface for registering in the system.
• In case of failure or for enhancing security of the system, the feature of
OTP generation is extended in this use case.
• This is the first point of contact between any user and the system, and
requires validation of details in the backup.
Use case Name Login
This use case provides interface for
Brief Description signing in the system to interact with
internal interfaces.
Actor Student
PreCondition No pre condition
1) The user enters his username.
2) The user enters the password.
Basic Flow 3) Generate OTP(optional).
4) The system validates the details.
5) If new user, goto SignUp interface.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester
6) The user fills in registration
details.
In case the user forgets his password,
Alternate Flow he has the option of changing his
password via OTP generation.
Post Condition No postcondition

3.1.2 Explore courses

Use case name Explore Courses
In this use case scenario, the student can
Brief Description view or browse through the list of available
courses. The student can also search for a
particular course if required.
Actor Student
Precondition The student must be logged into the system
using his/her crendentials.
1. The student will select the ‘Select
Courses’ option.
2. The system shall display the list of
available courses, with ‘n’ (for e.g
10) courses displayed on each page
along with an option to ‘search for
courses’
3. The student shall browse through the
available courses by clicking on
Basic Flow ‘Next Page’ or ‘Previous Page’ link
on the screen.
4. The student shall view more
information such as credits of the
course, faculty associated with the
course, faculty associated with the
course and time slot of the course by
clicking on a particular course from
the displayed list.
1. The student shall select ‘Select
courses’ option.
Alternate Flow 2. The system shall display the list of
first ‘n’ courses on the screen along
with an option to ‘search for courses.’

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester
3. The student shall search for a
particular course using the help of
‘search for courses’ option.
4. The system shall display the relevant
search results on the screen which
matching the user’s search
description.
Post Condition There is no post condition for this particular
use case scenario.

3.1.3 Register Courses

• This use case represents the functionality of selecting courses that the
student wishes to pursue.
• It also provides features for modifying the recorded choices within a
stipulated time period by methods of addition, deletion, withdrawl,
substitute etc.
• Only the registered user can make use of register functionality and
modify the system’s internal data.
Use Case Name Register Courses
This use case depicts the facility of
Brief Description registering for interested courses and
also for modifying the previously
made choices.
Actor Student
Pre Condition The student must be logged in.
1. The student chooses the desired
courses which he wishes to join.
2. The student shall add/delete the
courses.
3. The system displays the courses
chosen by the student.
Basic Flow 4. The student selects the
“Register” option after
finalizing his/her choices.
5. The system shall validate the
courses selected for eligibility
verification and if the validation
stands corrected, the selected
courses shall be registered.
Alternate Flow For every invalidated condition, “Not
Allowed” message is displayed.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester
Post Condition The final schedule is created.

3.1.4 Generate Course Schedule

Use case name Generate Course Schedule
This use case will facilitate the student
Brief Description to see his/her course schedule for the
selected courses
Actor Student
• The student must be logged
into the system
Pre Condition • The student should have
registered for the desired
courses.
1. The student shall select ‘My
courses’ option.
2. The system shall display the list
of courses previously selected
by the user.
3. The student shall select ‘View
Coursse Schedule’ option.
4. The system shall display a
timetable whose rows
comprises of days from Mon-
Sat and columns comprise of
Basic Flow 1hr time slots from 8:00 am to
5:00 pm. The selected course
will be displayed in the
appropriate cells of the table
which match the day and time of
the particular weekly course
schedule.
5. The user shall observe his/her
weekly course schedule for the
selected courses.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

3.1.5 Recommend Courses

• This Use case provides the functionality of providing suggestions for
the choice of electives or courses on the basis of pre-requisites/past
academic credentials of the student.
• The student user has the option of choosing this use case for suggestions
or directly choosing the third (Register Courses) Use case.
• This use case interacts with the database of the system that stores the
information about the students academic details.
Use Case Name Recommend Course
This use case is responsible for
Brief Description providing the recommendation
functionality of the Smart Course
Advisor software.
Actor Student
The user is logged into the system and
Preconditions opts for this use case to initialize the
recommendation module.
1. The user opts for
recommendation module.
2. System retrieves academic
details of the student from the
Basic Flow database.
3. Based on the data, system
provides recommendations
using appropriate
computational algorithm.
If satisfied with recommendation, the
Post Conditions student registers for the course. Else
student is free to select courses based
on eligibility.

3.1.6 Maintain Student Information

Use case name Maintain Student Information
This use case describes the scenario of
Brief Description maintaining student info such as name,
ID, phone number, email, selected
courses, etc. by the system registrar.
Actor System registrar

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester
Precondition The system registrar student must be
logged into the system.
1) The system registrar shall select
'List of Students' option.
2) The system shall display the list of
students on the screen along with
his/her personal details such as name,
Student ID, Phone number, email ID,
selected courses, etc. on the screen.
Only 'n' records shall be displayed per
page.
3) The system registrar student shall
Basic flow browse through the list of student
records by clicking on 'Previous page'
or 'Next Page' option on the screen or
(optional) by searching for a particular
student using the 'Search student'
option.
4) The system registrar shall select any
particular desired student from the
above specified list and
add/delete/update the personal details
of the user.
5) The student records database would
be updated accordingly.
The changes made in the student
Post Condition records data by the system registrar
would be reflected in the updated
student records databse.
constraints Each student must be associated with
a unique student ID.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

3.1.7 Maintain Course Catlog

Use case name Maintain course catalog
This use case describes the scenario of
maintaining/updating any changes in
any of the offered courses. It includes
Brief Description adding/deleting a course, modifying
course details, modify course
schedule, etc. this would be done by
the system registrar.
Actor System Registrar
Precondition The system registrar student must be
logged into the system.
1) The system registrar shall view the
offered courses section.
2) The system registrar shall select the
"Edit Course Catalog" option.
3) The system shall provide an option
to add a new course, delete any
existing course, modify the course
Basic Flow attributes such as name, course
schedule, etc.
4) The system registrar shall make the
desired modifications to the course
curriculum and select the "Save"
option.
5)The system shall return to the
offered courses section displaying the
updated course offerings.
The changes made in the course
Post Condition catalog by the system registrar would
be reflected in the course catalog
database.

3.1.8 Validate choices

• This use case depicts the generation of final schedule selected by the
registrar.
• The validation procedure employed while selecting or registering for
the courses is also done through interaction of this use case with other
use cases.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

Use Case Name Validate choices

The Use Case depicts if any
Brief Description discrepancy is found while making
registration choices.
Actor Student
Preconditions The student is logged into the system.
1) The student selects the "Register"
option after selecting the desired
courses.
2) The system shall validate the
Basic Flow student's choices and the
corresponding schedule.
3) The system displays "Successfully
Registered" if no discrepancies are
found.
Alternate Flow The system displays “Not Allowed”
message if any discrepancy is found.
Post Condition The courses selected by the student
would be successfully registered in the
success scenario.

3.2 Performance Requirements

3.2.1 Number of simultaneous users:
The SHMS can allow only a limited number of users to monitor and
control the appliances. Not more than 5 users should be allowed to log into the
system at a time.
3.2.2 Usage of the Graphical User Interface (GUI):
The GUI should be user friendly and easy to use. The hardware on which
the GUI is running should have enough memory and performance bandwidth
to allow smooth and fast access.
3.2.3 Response Time:
Response time i.e. the time taken by the system to respond to user
commands should be as fast as possible.
Wish: not more than 3 seconds 100% of the time.
Must: not more than 5 seconds 100% of the time.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

3.2.4 Recovery Time

The time taken by the system to recover to its previous known state after
a system crash should be as fast as possible.
Wish: not more than 30 seconds 100% of the time.
Must: not more than 60 seconds 100% of the time.

3.3 Design Constraints

3.3.1 Application Memory Usage
The application should not use more than 20MB of system memory.
3.3.2 Scalability
The system is implemented in such a way that it allows easy addition of
many devices and sensors into the SHMS and easy connection of the new
devices to the wireless network.
3.4 System Attributes
3.4.1 Availability
The SHMS should be available to the user at all times, otherwise the user
would not be able to manage the environment and appliances in case of system
unavailability.
3.4.2 Security
Security of the communication between the sensors and the central
controller.
The messages should be encrypted so that hackers cannot get access to
user-name, passwords or any other private information about the resident user.
Communication messages between the GUI application and the central
controller should also be encrypted.
The Databases should also be secured to prevent any third party access
of private data.

|Page 2203031240959
 FACULTY OF ENGINEERING & TECHNOLOGY
Sub name: Software Engineering -(303105254)
B. Tech. 2nd Year/4th semester

3.4.3 Recoverability
The system should be recovered quickly to its last known state as soon
as possible in case any system failure occurs.
For this to be possible, the system would periodically store it’s state in
an external database accessible to central controller.
3.4.4 Reliability
We intend to build a system that will not go down crashing frequently
and no loss of information shall be allowed.

|Page 2203031240959