Software Requirements
Specication for
a Smart Home
Version 2.0
September 20, 2008
1 Introduction
1.1 Purpose: Mission Statement
Making residential enhancements that will pave the way for an easy and relaxed
transition into retired life.
Document prepared for the Smith family home, a pre-existing building.
1.2 Scope
e “Smart Home” system, herein referred to as “e System,will be a combina-
tion of hardware and software that will provide an escape from daily routines and
mundane tasks. is product seeks out the items that consume the most time but
do not need to. e goal is to automate that which does not really need human
interaction, to free the occupants to enjoy themselves in their retirement. e sys-
tem will not free the mundane household chores from any human interaction, but
it will require only as little as needed.
204 Software Requirements Specification for a Smart Home
1.3 Definitions, Acronyms, and Abbreviations
pH—see http://en.wikipedia.org/wiki/PH
RFID—Radio Frequency Identification
SH—Smart Home
SANStorage Area Network
SRSSystem Requirements Specification
WPAWi-Fi Protected Access
WEP—Wired Equivalent Privacy
USB—Universal Serial Bus
1.4 References
802.11 IEEE Specification http://ieeexplore.ieee.org/servlet/opac?punumber=4248376
1.5 Overview
Requirements have been divided into key functional areas, which are decom-
posed into features within those functional areas. Functional and nonfunc-
tional requirements exist within the laid-out document format. e order of
the leading sections and the corresponding requirements should be interpreted
as priority.
2 Overall Description
2.1 Product Perspective
is system consists of many standalone devices. At this time it is not known if
these devices exist in the commercial market or not. e document has a holistic
approach, intermingling the demand for devices with the functions of the system.
e first step in continuing with this project would be to decide on feasibility and
do some cost analysis for some of the requirements contained herein.
is document seeks to lay out areas where all interfaces are abstracted. ere
are areas where there would clearly need to be communication between the vari-
ous interfaces, but since there is no targeted device, there is no known protocol for
speaking with that device.
2.2 Product Functions
e functions of this product will be divided into six categories. Accessibility is
the first and most highly desired by the customer. is functional category seeks
to improve the user experience of the system by providing various benchmarks for

Get Requirements Engineering for Software and Systems now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.