Software Requirements

Specification
for

Smart Home Management System

Prepared by:
Gouranshu Grover(2018H1120279P)
Nimit Jain(2018H1120278P)
 Table of Contents

1. Introduction
1.1 Purpose………………………………………………………….3
1.2 Scope…………………………………………………………….3
1.3 Definitions, Acronyms and Abbreviations…………………… 4
1.4 References………………………………………………………4
1.5 Overview…………………………………………………………6
2. Overall Description
2.1 Product Perspective…………………………………………….7
2.2 Product Functions…………………………………………….. .7
2.3 User Characteristics…………………………………………….8
2.4 Constraints……………………………………………………….9
2.5 Dependencies and assumptions………………………………9
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Login……………………………………………………..8
3.1.2 Explore Courses………………………………………..9
3.1.3 Register Courses………………………………………10
3.1.4 Generate Course Schedule…………..……………….11
3.1.5 Recommend Courses………………………………….12
3.1.6 Maintain Student information………………………….12
3.1.7 Maintain Course Catalog………………………………13
3.1.8 Validate Choices..……………………………………...14
3.2 Non-Functional Requirements
3.1.1 Accuracy………………………………………………...15
3.1.2 Security………………………………………………….15
3.2 System Attributes
3.2.1 Scalability………………………………………………..16
3.2.2 Reliability………………………………………………...16

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 Management Sytsem (SHMS) will reduce the physical
interaction of homeowners with the various appliances like TV, fan, lights,
thermostat, AC, etc. SMART here stands for Self-Monitoring Analysis and
Reporting Technology. The SHHM will blend in the Internet Of Things (IOT)
technology into our homes. Currently, majority of the homes continue to remain
apart from the smart technology. All the tasks are continued to be performed
manually. Every appliance like TV, AC, home theatre, etc. comes with its own
unique 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.
Even to turn on or off a light or fan, a person has to walk till the switch and press
it manually. In order to enhance the ways of living, the SHMS can be
incorporated into the residences. 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 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. The SHMS would need to tackle with the issues of security,
reliability, cost of ownership and inflexibility caused due to lack of
standardization. The installation of SHMS does not mean that the existing
appliances and electrical wiring of the home would have to be discarded and the
new ‘smart’ appliances and wiring would replace it. The Home can be managed
manually as before, or in an automated mode, depending on the user’s wish.
Therefore, the SHMS would sit on top of the existing home structure and not as a
replacement.

1.3 Definitions, Acronyms and Abbreviations

TERM DEFINITION

SHMS Smart Home Management System

RFID Radio Frequency Identification

DBMS Database Management Sytem

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.4References (chicago)

[1] IEEE Software Engineering Standards Committee, “IEEE Std 830-1998, IEEE
Recommended Practice for Software Requirements Specifications”, October 20,
1998

[2] Ficocelli, Maurizio, and Goldie Nejat. "The design of an interactive assistive
kitchen system." Assistive Technology 24, no. 4 (2012): 246-258.

[3] Barbato, Antimo, Luca Borsani, Antonio Capone, and Stefano Melzi. "Home
energy saving through a user profiling system based on wireless sensors."
In Proceedings of the first ACM workshop on embedded sensing systems for
energy-efficiency in buildings, pp. 49-54. ACM, 2009.

[4] Brush, A. J., Bongshin Lee, Ratul Mahajan, Sharad Agarwal, Stefan Saroiu,
and Colin Dixon. "Home automation in the wild: challenges and opportunities."
In proceedings of the SIGCHI Conference on Human Factors in Computing
Systems, pp. 2115-2124. ACM, 2011.

[5] King, Samuel. "Smart fire alarm and gas detection system." U.S. Patent
7,005,994, issued February 28, 2006.

[6] Colens, Andre. "Automatic machine and device for floor dusting." U.S. Patent
5,787,545, issued August 4, 1998.

[7] Robles, Rosslin John, Tai-hoon Kim, D. Cook, and S. Das. "A review on
security in smart home development." International Journal of Advanced Science
and Technology 15 (2010).

[8] Jahn, Marco, Marc Jentsch, Christian R. Prause, Ferry Pramudianto, Amro Al-
Akkad, and Rene Reiners. "The energy aware smart home." In Future
Information Technology (FutureTech), 2010 5th International Conference on, pp.
1-8. IEEE, 2010.
 [9] Gill, Khusvinder, Shuang-Hua Yang, Fang Yao, and Xin Lu. "A zigbee-based
home automation system." IEEE Transactions on consumer Electronics 55, no. 2
(2009).

[10] Monaco, Pietro A. "Smart garage door opener." U.S. Patent Application
13/084,617, filed October 18, 2012.

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 different types of
actors and their interaction with the system. Further, the chapter 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 Smart Home Management System 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.

The system will comprise of majorly four components: Electronic devices and
sensors, Wireless Network, Central Controller and the UI. The sensors will
monitor the Electronic Devices and also monitor the intended environmental
parameters and send that data to the Central Controller over the established
Wireless Network. The Central Controller can operate in two modes: manual or
automatic. In manual mode, the central controller on/off/adjusts the appliances
based on the user requests. However, in automatic mode, the Central Controller
receives streaming data from the sensors and controls the appliances based on
the user comfort range. Wi-Fi would be used as the Wireless Network. The user
can login on the GUI which would be an application and can check the
environmental status and other parameters of the SHMS. The user can also
configure his/her preferences and the system will adjust accordingly to those
choices. The user can file a complaint in case of system failure or provide any
feedback to the system admin. The system admin can add/remove devices and
sensors and associate each appliance with RFID to uniquely identify them. Since
information about user preferences and system and environment status is
required to be stored, therefore, the system would need some database and all
of the database communication would happen over the internet.

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 as 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.
● 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
item 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,etc. They
just need to follow the user guidelines for the product.
● The system is especially attractive to users who wish for a more secure
and safe home and also to old age people who sometimes lack the
physical capabilities to perform day to day tasks.

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.
● 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.
 ● Another assumption is that the residents (users) have the knowledge and
awareness i.e. enough know-how to interact with the GUI in order to use the
functionalities offered by the SHMS.
● Every device is assigned a unique RFID tag.

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 signing 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 backdrop.

Use case Name Login

Brief Description This use case provides interface for signing

in the system to interact with internal
interfaces.

Actor Student

PreCondition No pre condition

Basic Flow 1) The user enters his username.

2) The user enters the password.
3) Generate OTP(optional)
4) The system validates the details.
4) If new user, goto SignUp interface.
 5) The user fills in registration details

Alternate Flow In case the user forgets his password, 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

Brief Description In this use case scenario, the student can 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 credentials.

Basic Flow 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 ‘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 and time slot of the course by clicking on a
particular course from the displayed list.
 Alternate Flow 1. The student shall select ‘Select courses’ option.
2. The system shall display the list of first ‘n’ courses
on the screen along with an option to ‘search for
courses’.
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 the 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, withdrawal,
substitute etc.
● Only the registered users can make use of register functionality and
modify the system’s internal data

Use Case Name Register Courses

Brief Description This use case depicts the facility of registering for
interested courses and also for modifying the
previously made choices.

Actor Student

Pre Condition The student must be logged in.

Basic Flow 1. The student chooses the desired courses which

he wishes to register for.
2. The student shall add/delete the courses.
3. The system displays the courses chosen by the
student.
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.

Post Condition The final schedule is created.

.

3.1.4 Generate Course Schedule

Use case name Generate Course Schedule

Brief Description This use case will facilitate the student to see
his/her course schedule for the selected courses

Actor Student

Precondition ● The student must be logged into the system

● The student should have registered for the
desired courses

Basic Flow 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 Course
Schedule” option.
4. The system shall display a timetable whose
rows comprise of days from Mon-Sat and
columns comprise of 1 hour time slots from
8:00 a.m. to 5 p.m. The selected courses 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.

Post Condition There is no post condition for this particular use

case scenario.

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

Brief Description This use case is responsible for providing

the recommendation functionality of the
Smart Course Advisor software.

Actor Student

Preconditions The user is logged into the system and

opts for this use case to initialise the
recommendation module.

Basic Flow 1. The user opts for recommendation

module
2. System retrieves academic details of
the student from the database.
3. Based on the data, system provides
recommendations using appropriate
computational algorithm.

Post Conditions If satisfied with the recommendation, the

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

 Brief Description This use case describes the scenario of
maintaining student information such as
name, student ID, phone number, email,
selected courses, etc. by the system
registrar.

Actor System registrar

Precondition The system registrar student must be

logged into the system

Basic Flow 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
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

Post Condition The changes made in the student records

data by the system registrar would be
reflected in the updated student records
database.

Constraints Each student must be associated with a

unique student ID.

3.1.7 Maintain Course Catalog

 Use case name Maintain course catalog

Brief Description This use case describes the scenario of

maintaining/updating any changes in any of
the offered courses. It includes
adding/deleting a course, modify 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

Basic Flow 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 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.

Post Condition The changes made in the course 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.
 Use Case Name Validate choices

Brief Description The Use Case depicts if any discrepancy is

found while making registration choices.

Actor Student

Preconditions The student is logged into the system.

Basic Flow 1. The student selects the ”Register” option

after selecting the desired courses.
2. The system shall validate the 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:

 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.3.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

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 new 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 home 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
owner.
 ● 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.

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 the 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.