Professional Documents
Culture Documents
SRS
SRS
Specification
for
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.
TERM DEFINITION
UI User Interface
IR Infrared
FR Functional Requirement
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 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
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.
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.4 Constraints
● 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
● 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.
Actor Student
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
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.
● 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
Brief Description This use case depicts the facility of registering for
interested courses and also for modifying the
previously made choices.
Actor Student
Brief Description This use case will facilitate the student to see
his/her course schedule for the selected courses
Actor Student
Actor Student
● 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
Actor Student
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.
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.
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
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
The application should not use more than 20MB of system memory.
3.3.2 Scalability
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
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.