Requirements Engineering for Software and Systems

203

Appendix

Software Requirements

Specification 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

SAN—Storage Area Network

SRS—System Requirements Specification

WPA—Wi-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