# 1 Introduction
[NULL]

## 1.1 Purpose
This document specifies the requirements for the development of a “Smart House” system, called DigitalHome (DH). The DigitalHome system is a home management system that allows residents to manage their daily lives by providing a lifestyle that brings together security, environmental and energy management (temperature, humidity, and lighting), entertainment, and communications.

This initial version of DigitalHome will be a limited prototype, which will be used by HomeOwner management to make business decisions about the future commercial development of DigitalHomeOwner products and services.

## 1.2 Scope
This document specifies the requirements for a limited prototype version of a "Smart House" system, named DigitalHome (DH).

The DigitalHome software will allow a home user to manage devices that control the environment of a home. The scope of this prototype is limited to the management of devices which control temperature, humidity, security, and power to small appliances and lighting units. Users will interact with the system through a web-ready device, such as a computer, cell phone, or PDA.

The application of the software is to provide a home management system that allows residents to easily manage their daily lives by providing for a lifestyle that brings together security, environmental, and energy management. The primary objective of this initial version is to serve as a prototype that will be used by HomeOwner management to make business decisions about the future commercial development of DigitalHome products and services. The prototype system will be situated in a simulated environment.

This specification is based on the DigitalHome Customer Need Statement and the Digital Home High Level Requirements Definition [HLRD 2010].

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The DigitalHome (DH) system is a home management system that allows a home user to manage devices that control the environment of a home. The software is one component of the larger DH system, which also consists of household devices (e.g., a heating and air conditioning unit, a security system, small appliances, and lighting units), sensors and controllers for the devices, and communication links between the components. This software requirements specification is based on the DigitalHome Customer Need Statement and the Digital Home High Level Requirements Definition [HLRD 2010].

The product is a limited prototype version that will be used to make business decisions about future commercial development. The prototype DH software system will be situated in a simulated environment where all sensors and controllers will be simulated.

#### System interfaces
The DH software system interfaces with various sensors and controllers in the home via a DH Gateway device. These include:
*   Digital programmable thermostats
*   Digital programmable humidistats
*   Magnetic alarm contact switches
*   Security sound and light alarms
*   Digital programmable power switches

#### User interfaces
The user communicates with the system through a personal web page on the DigitalHome web server or on a local home server. This web interface is accessible via a web-ready computer, cell phone, or PDA. Users are expected to be familiar with simple web operations such as logging in, browsing web pages, and submitting information and requests.

#### Hardware interfaces
The software interfaces with the following hardware elements:
*   A DH home web server hosted on a home computer.
*   A DH Gateway device that connects to a broadband Internet connection and contains an RF Module for wireless communication with other devices.
*   Environmental sensors and controllers, including thermostats, humidistats, contact switches, alarms, and power switches.

#### Software interfaces
*   The system shall provide for authentication and information encryption through a recognized, reliable, and effective security technology, such as Transport Layer Security.
*   The development will use object-oriented methods with UML 2.0.
*   The project will employ widely used, accepted, and available software technology and standards.

#### Communications interfaces
*   The system requires a broadband Internet connection from an Internet Service Provider (ISP), such as a cable modem or high-speed DSL.
*   The DH Gateway device uses wireless communication to send and receive signals between the gateway and the other DigitalHome devices (sensors and controllers). The gateway shall operate up to a 1000-foot range for indoor transmission.

#### Memory constraints
[N/A]

#### Operations
*   Users can monitor and control home devices, create and modify monthly plans for environmental settings, and override planned settings.
*   A Master User or DH Technician can perform system configuration, including setting system parameters, establishing user accounts, and starting and stopping the system.
*   The system will perform a daily backup of all system data, including configuration, default parameter settings, planning, and usage data.
*   In case of system failure, a recovery mechanism shall restore system data from the most recent backup.

#### Site adaptation requirements
A DH Technician is responsible for the initial setup and configuration of a DH system at a specific site. This includes setting system parameters and establishing user accounts.

#### Interfaces with services
The system requires an Internet Service Provider (ISP) for internet connectivity.

### 1.3.2 Product functions
The DigitalHome (DH) system will provide users with the capability to monitor and control their home's environment using a web-ready computer, cell phone, or PDA. The major functions of the system are summarized below:

*   **Environmental Management:** The system will allow a user to monitor and control the temperature and humidity in different spaces within the home.
*   **Security Management:** The system will monitor door and window contact sensors and activate light and sound alarms when a security breach is detected.
*   **Appliance and Lighting Management:** The system will allow a user to turn small appliances and lighting units on or off.
*   **Planning:** The system will provide a planner for users to create and modify monthly schedules that specify environmental parameter settings for different time periods.
*   **Reporting:** The system will generate monthly reports on the management and control of the home, including average environmental values, security breach logs, and system operational status.

A supplementary Use Case Model provides additional detail and an overview of the system functionality.

### 1.3.3 User characteristics
There are two main groups of users for the DigitalHome system: DigitalHome Users and DigitalHome Technicians.

*   **DigitalHome User**: This is the general user of the system.
    *   They are familiar with the layout of their home and the location of sensor and control devices.
    *   They are not required to have technical knowledge of the DigitalHome system but are expected to be familiar with using a web interface for tasks such as logging in, browsing web pages, and submitting information.
    *   A designated **Master User** will have the same rights as a DH Technician and shall be able to change the system's configuration, such as adding a user account or changing default parameter settings.

*   **DigitalHome Technician**: This user is responsible for setting up and maintaining the configuration of a DigitalHome system.
    *   They have experience with the type of hardware, software, and web services associated with the system.
    *   They are specially trained by DigitalHomeOwner to be familiar with the functionality, architecture, and operation of the product.
    *   They have administrative rights to set up and change the system configuration, establish user accounts, and start and stop the system's operation.

### 1.3.4 Limitations
*   The DigitalHome system specified in this document is a limited prototype version intended to inform business decisions, not a comprehensive specification for a commercial product.
*   The prototype system will be situated in a simulated environment. There will be no actual physical home, and all sensors and controllers will be simulated.
*   The system requires a broadband Internet connection from a third-party Internet Service Provider (ISP).
*   The system must adhere to the standards, policies, and procedures of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE).
*   Development must use object-oriented methods with UML 2.0, and adhere to specified IEEE standards and the HomeOwner Coding Standard.
*   The Gateway device has an operational range of up to 1000 feet for indoor transmission; sensors and controllers must be within this range to communicate with the system.
*   The thermostat's temperature sensor has a sensitivity range between 14°F and 104°F (-10°C and 40°C).
*   The system is limited to managing the following maximum number of devices:
    *   Eight thermostats
    *   Eight humidistats
    *   Fifty door and window contact sensors
    *   One sound alarm and one light alarm subsystem
    *   One hundred 115 volt, 10 amp power switches
*   User-configurable set points are limited to the following ranges:
    *   Temperature: 60°F to 80°F
    *   Humidity: 30% to 60%
*   The system must achieve a reliability of no more than one failure per 10,000 hours of operation.
*   Historical data for reports is only retained for the past two years.
*   System access requires user authentication, and communications must be encrypted using a recognized technology such as Transport Layer Security.

## 1.4 Definitions
- **ASHRAE:** American Society of Heating, Refrigerating and Air-Conditioning Engineers.
- **Authentication:** Any process by which it is verified that someone is who they claim they are. This typically involves submission and verification of a username and a password.
- **Broadband Internet:** A high data rate Internet access, typically contrasted with slower dial-up access.
- **DH (Digital Home):** The name of the prototype smart home product that is to be produced by DigitalHomeOwner.
- **DigitalHomeOwner:** The division of HomeOwner Inc. responsible for producing DigitalHome products.
- **DSL (Digital Subscriber Line):** A family of technologies that provides digital data transmission over the wires of a local telephone network.
- **Encryption:** The process of transforming information (referred to as plaintext) using an algorithm (called a cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.
- **FAQ:** Frequently asked question.
- **Gateway Device:** A home networking device used to connect devices in the home to the Internet or other Wide Area Networks.
- **HomeOwner Inc.:** The largest national retail chain serving the needs of home owners in building, furnishing, repairing, and improving their homes.
- **HVAC:** Heating, Ventilation and Air Conditioning.
- **Humidistat:** An instrument that measures and controls relative humidity.
- **ISP:** Internet Service Provider.
- **PDA:** Personal Digital Assistant.
- **RF:** Radio Frequency.
- **Security Breach:** An external act that bypasses or contravenes the digital home security system. For example, if an intruder opens a door where the contact sensor is set to “on”, the system will sense a ‘security breach”.
- **Set Point:** A numeric value that establishes the desired value of an environmental quality (e.g., a temperature value of 70° F).
- **SRS:** Software Requirements Specification.
- **Transport Layer Security:** Cryptographic protocols that provide security for communications over networks such as the Internet.

# 2 References
## Compliance

*   *Digital Home High Level Requirements Definition*, HLRD 2010, September 2010, DigitalHomeOwner Division, Homeowner Inc.
*   *Guidelines for Developing HomeOwner Technical Reports*, HO2305, March 2002, Homeowner Inc. Authored by J. Sykes and R. Rook.
*   *HomeOwner Coding Standard*, HO4710, August 2009, Homeowner Inc. Authored by S. Kramer.
*   *IEEE Recommended Practice for Software Requirements Specifications*, IEEE Std 830-1998, 1998, Institute of Electrical and Electronics Engineers, Inc.
*   *IEEE Standard for Software Unit Testing*, ANSI/IEEE Std 1008-1987, 1987, Institute of Electrical and Electronics Engineers, Inc.
*   *IEEE Standard for Software Verification and Validation*, IEEE Std 1012-2004, 2004, Institute of Electrical and Electronics Engineers, Inc.
*   *IEEE Standard for Information Technology - Systems Design - Software Design Descriptions*, IEEE Std 1016-2009, 2009, Institute of Electrical and Electronics Engineers, Inc.
*   *IEEE Standard for Software Reviews and Audits*, IEEE Std 1028-2008, 2008, Institute of Electrical and Electronics Engineers, Inc.
*   Website for American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), accessed October 2010. Source: http://www.ashrae.org/

## Guidance

*   *Digital Home Use Case Model*, HO2010, October 24, 2010, DigitalHomeOwner Division, HomeOwner Inc.
*   *Smart Home Hacks: Tips & Tools for Automating Your House*, 2004, O’Reilly. Authored by G. Meyer.

# 3 Requirements
[NULL]

## 3.1 Functions
### 3.1.1 General Functions
*   The system shall allow a user to monitor and control a home's temperature, humidity, lights, security, and the state of small appliances using a web-ready computer, cell phone, or PDA.
*   The system shall read sensor values and save them in a home database.
*   The system shall send controller values to devices to change the home environment.

### 3.1.2 User and System Management
*   A Master User or DigitalHome Technician shall be able to change the system configuration, such as adding a user account or changing default parameter settings.
*   A DigitalHome Technician shall be able to start and stop the operation of the system.
*   The system shall provide user authentication, requiring an account name and password for login.

### 3.1.3 Thermostat Control
*   The system shall allow a user to read the current temperature from any of the up to eight thermostats.
*   The system shall allow a user to set the temperature for each thermostat individually or for all thermostats collectively.
    *   Validity checks on inputs: The temperature setting must be between 60°F and 80°F, inclusive, and set in one-degree increments.
*   The system shall support both Fahrenheit and Celsius temperature values.

### 3.1.4 Humidistat Control
*   The system shall allow a user to read the current humidity from any of the up to eight humidistats.
*   The system shall allow a user to set the humidity level for each humidistat.
    *   Validity checks on inputs: The humidity setting must be between 30% and 60%, inclusive, and set in 1% increments.

### 3.1.5 Security System Control
*   The system shall manage up to fifty door and window contact sensors.
*   Sequence of operations: When a security breach occurs (a contact sensor is set to OPEN), the system shall activate one sound alarm and one light alarm subsystem.

### 3.1.6 Appliance and Lighting Control
*   The system shall manage up to one hundred power switches for small appliances and lighting units.
*   The system shall provide the current state (ON or OFF) of any power switch.
*   The system shall allow a user to change the state of a power switch (from OFF to ON, or ON to OFF).

### 3.1.7 Planning and Reporting
*   The system shall provide a planner for a user to create or modify a monthly plan.
    *   The plan shall specify environmental parameter settings (temperature, humidity, security contacts, and appliance/light status) for up to four daily time periods for each day of the month.
    *   The system shall also allow scheduling of up to twenty-four one-hour settings per day for each thermostat and humidistat.
*   The system shall allow a user to override any planned parameter values.
    *   Effect of parameters: A manual override shall remain in effect until the end of the current planned time period, at which point the planned or default setting for the next time period will be used.
*   The system shall generate a monthly report for any month within the past two years. The report shall contain:
    *   Daily average, maximum (with time), and minimum (with time) values of temperature and humidity for each sensor.
    *   The day and time for any security breaches.
    *   The periods of time when the system was not in operation.

### 3.1.8 Responses to Abnormal Situations
*   Error handling and recovery:
    *   The system shall perform a daily backup of all system data (configuration, default settings, plans, and usage data).
    *   If the system fails (due to power loss, loss of internet access, or other failures), a recovery mechanism shall restore system data from the most recent backup.
    *   The system shall incorporate exception handling and respond to the user with a clear, descriptive message when an error or exceptional condition occurs.
*   Overflow: [N/A]
*   Communication facilities: [N/A]
*   Hardware faults and failures: [N/A]

### 3.1.9 Input/Output Relationships
*   Input/output sequences:
    *   A user request to change a controller's set point (e.g., temperature) results in a command being sent to the corresponding controller device.
    *   A user request for a sensor's status results in the system reading the value from the sensor and displaying it to the user.
*   Formulas for input to output conversion: [N/A]

## 3.2 Performance requirements
Displays of environmental conditions, including temperature, humidity, contact sensors, and power switches, shall be updated at least every two seconds.

Sensors for temperature, humidity, contact status, and power state shall have a minimum data acquisition rate of 10 Hz.

An environmental sensor or controller device must be within 1000 feet of the master control device to communicate with the system.

The system shall support the following number of devices:
*   Up to eight thermostats.
*   Up to eight humidistats.
*   Up to fifty door and window contact sensors.
*   Up to one hundred power switches.

The system shall be able to provide reports on the management and control of the home for any month in the past two years.

## 3.3 Usability requirements
The general user is not expected to be familiar with the technical features of the DigitalHome system. However, they are expected to be familiar with the use of a web interface and able to perform simple web operations such as logging in, logging out, browsing web pages, and submitting information and requests.

All DigitalHome operations shall incorporate exception handling so that the system responds to a user with a clear, descriptive message when an error or an exceptional condition occurs.

The DigitalHome System shall provide users with online documentation about the system installed in their home. The user documentation shall include the following:
*   An FAQ section with frequently asked questions about the use and maintenance of the system.
*   A section that explains how system parameters are set and sensor values are read, including information on limitations and constraints on parameter settings and sensor reading accuracy.
*   A section that describes how to use the DigitalHome Planner.

## 3.5 Logical database requirements
The DigitalHome system shall maintain a home database on the home web server for storing user, configuration, and operational data.

The logical requirements for this database are as follows:
*   **Types of Information:** The database shall store the following types of information:
    *   User account information, including account names and passwords.
    *   System configuration and default parameter settings.
    *   User-created monthly plans, which specify environmental parameter settings (temperature, humidity, contact sensors, power switches) for up to four daily time periods.
    *   Current sensor values from thermostats, humidistats, contact sensors, and power switches.
    *   Historical usage data for reporting, including daily average, maximum, and minimum values for temperature and humidity with timestamps, and timestamps for any security breaches.
*   **Frequency of Use:**
    *   Sensor values shall be acquired at a minimum rate of 10 Hz and saved to the database.
    *   Displays of environmental conditions shall be updated from the database at least every two seconds.
    *   All system data (configuration, settings, planning, and usage data) shall be backed up on a daily basis.
*   **Accessing Capabilities:**
    *   General users shall be able to read sensor data and create or modify their own plans.
    *   A Master User and a DH Technician shall have rights to establish and maintain user accounts and change system configuration and default parameter settings.
*   **Data Entities and Their Relationships:**
    *   The system shall manage data entities for user accounts, plans, and devices.
    *   Each user account can have associated plans.
    *   Each plan contains settings for multiple devices (thermostats, humidistats, sensors, switches) for specified time periods.
    *   Devices generate historical data, such as sensor readings and security breach events, which are logged for reporting.
*   **Integrity Constraints:**
    *   Thermostat temperature settings must be between 60°F and 80°F, inclusive.
    *   Humidistat humidity settings must be between 30% and 60%, inclusive.
*   **Security:**
    *   Access to user account information shall be protected by an account name and password.
    *   The system shall use a recognized security technology, such as Transport Layer Security, for authentication and information encryption.
*   **Data Retention Requirements:**
    *   The system shall retain historical data on temperature, humidity, and security breaches for at least the past two years to support reporting functions.
    *   In case of system failure, data shall be restored from the most recent daily backup.

## 3.6 Design constraints
*   The system shall adhere to the standards, policies, and procedures of the American Society of Heating, Refrigerating and Air-Conditioning Engineers [ASHRAE 2010].
*   The development team shall use the development process specified by DigitalHomeOwner Inc.
*   Object-oriented development using UML 2.0 is the designated method for software development.
*   The project shall employ widely used, accepted, and available hardware and software technology and standards for both product elements and development tools.
*   All modules and components of the prototype shall be designed and implemented for potential incorporation into a fully specified commercial version of the DigitalHome System.
*   The development shall adhere to the following documentation and coding standards:
    *   IEEE standards [IEEE830, IEEE1008, IEEE1016, IEEE1028].
    *   The HomeOwner Coding Standard [HO4710].
    *   The Homeowner document format [HO2305] for all system documents.
*   The prototype must be completed within twelve months of inception.
*   The development team will consist of five engineers.
*   The cost of system elements (sensors, controllers, server, tools, etc.) should be minimized.
*   The system will be tested in a simulated environment where all sensors and controllers are simulated. The simulated environment must be realistic and adhere to the physical properties and constraints of an actual home and real devices.

## 3.7 Software system attributes
### Reliability
The DigitalHome System must be highly reliable with no more than 1 failure per 10,000 hours of operation.

All DigitalHome operations shall incorporate exception handling so that the system responds to a user with a clear, descriptive message when an error or an exceptional condition occurs.

### Availability
The Digital Home System shall incorporate backup and recovery mechanisms.

The system will back up all system data (configuration, default parameter settings, planning, and usage data) on a daily basis. The backup time is set by the DH Technician at system set up.

If the system fails due to power loss, loss of internet access, or other software or hardware failure, the system recovery mechanism shall restore system data from the most recent backup.

### Security
Upon installation, a DigitalHome user account shall be established.

The DigitalHome web system shall provide for authentication and information encryption through a recognized reliable and effective security technology, such as Transport Layer Security.

Log in to an account shall require entry of an account name and a password.

### Maintainability
The development of the system shall use methods and techniques to support system maintenance, including:
*   Documentation of requirements, design, and code.
*   Use of abstraction, information hiding and module independence in system design.
*   Use of IEEE standards and the HomeOwner Coding Standard.

All modules and components of the prototype version shall be designed and implemented in such a manner that they may be incorporated in a fully specified commercial version of the DigitalHome System.

### Portability
[N/A]

## 3.8 Supporting information
A supplementary document, the Digital Home Use Case Model [HO2010], provides additional detail, an overview of the system functionality, and shows the relationships between the DigitalHome System entities.

As part of the final project report, the development team is required to describe their efforts to minimize costs, including price comparisons between DigitalHome elements and comparable/competitive elements.

The DigitalHome system is intended to solve the problem of allowing home residents to easily manage their daily lives by providing a unified system for security, environmental and energy management (temperature, humidity, and lighting), and control of small appliances.

Sample input/output formats, results of user surveys, and special packaging instructions are not specified in this document.

The SRS does not explicitly state whether these information items are to be considered part of the requirements.

# 4 Verification
[NULL]

## 4.1 Functions
All functional requirements will be verified through system testing and acceptance testing. The testing will be conducted in a simulated environment where the physical home, sensors, and controllers are simulated. This simulated environment will be realistic and adhere to the physical properties and constraints of an actual home and real devices. Software unit testing will be conducted in accordance with the IEEE 1008 standard.

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
[N/A]

## 4.5 Logical database requirements
Verification of the logical database requirements will be performed through a combination of inspection, analysis, and testing.

*   Verification of the types of information stored will be accomplished by inspection of the database schema and by testing system functions. This includes creating user accounts, saving system configurations, creating monthly plans, and triggering security events, then querying the database to confirm that all data (user accounts, plans, sensor values, usage data, configuration settings) is stored correctly.
*   Verification of data access capabilities will be performed by demonstration. Testers will execute functions to create and modify plans, generate monthly reports from historical data, and restore the system from a backup to confirm that data can be accessed and manipulated as required.
*   Verification of data retention requirements will be performed by testing. The database will be populated with simulated data spanning more than two years. The reporting function will then be tested to ensure it can successfully generate reports using data from two years prior. The daily backup process will be verified by checking system logs and the backup location to confirm a backup is created each day.
*   Verification of security requirements for the database will be performed by testing the user authentication system with valid and invalid credentials. Network traffic analysis will be used to confirm that data is encrypted during transmission.

## 4.6 Design constraints
- Adherence to the standards of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) will be verified. [N/A]
- Adherence to specified IEEE standards and the HomeOwner Coding Standard will be verified through software reviews, audits, and unit testing conducted in accordance with IEEE 1028 and IEEE 1008.
- Adherence to the Homeowner document format and archival requirements will be verified. [N/A]
- The use of object-oriented development with UML 2.0 will be verified. [N/A]
- The use of widely accepted and available hardware and software technology will be verified. [N/A]
- Efforts to minimize project costs will be verified through a review of the final project report, which must describe these efforts and include price comparisons.

## 4.7 Software system attributes
Verification of software system attributes will be conducted through a combination of testing, demonstration, inspection, and analysis.

### Reliability and Availability
*   The requirement for a maximum of one failure per 10,000 hours of operation will be verified by analysis of system test logs conducted over an extended period.
*   The daily backup mechanism will be verified by inspection of system logs and backup files to confirm successful daily execution at the configured time.
*   The system recovery mechanism will be verified by demonstration. A system failure will be simulated, and the recovery process will be initiated. Verification will be successful if the system is restored to its state from the most recent backup.
*   Exception handling will be verified by testing. Test cases will be designed to introduce errors and exceptional conditions, and the system's response messages will be inspected to ensure they are clear and descriptive.

### Security
*   The user authentication requirement will be verified by testing. Test cases will confirm that a valid account name and password are required for access and that access is denied for invalid credentials.
*   The information encryption requirement will be verified by inspection of the design and analysis of network traffic to confirm that a recognized security technology, such as Transport Layer Security, is used to encrypt communications.

### Maintainability
*   Maintainability requirements will be verified by a series of audits and inspections.
*   All project documentation will be inspected to ensure it is complete, up-to-date, and conforms to the Homeowner document format.
*   The system design and source code will be inspected to verify the use of abstraction, information hiding, and module independence.
*   The source code will be audited to ensure compliance with the HomeOwner Coding Standard.
*   The design and implementation of modules will be reviewed to ensure they are suitable for incorporation into a future commercial version of the system.

### Portability
[N/A]

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
*   The system will be developed for and tested in a simulated environment. All physical components such as the home, sensors, and controllers will be simulated.
*   The user is assumed to have a home computer capable of hosting the DigitalHome web server.
*   The user is assumed to have a broadband internet connection, such as a cable modem or high-speed DSL.
*   The requirements specified in this document are based on the Digital Home High Level Requirements Definition [HLRD 2010] and the Digital Home Use Case Model [HO2010].
*   The system's compatibility with HVAC systems is dependent on adhering to the standards of the American Society of Heating, Refrigerating and Air-Conditioning Engineers [ASHRAE 2010].

## 5.2 Acronyms and abbreviations
*   ASHRAE - American Society of Heating, Refrigerating and Air-Conditioning Engineers
*   DH - Digital Home
*   DSL - Digital Subscriber Line
*   FAQ - Frequently asked question
*   HVAC - Heating, Ventilation and Air Conditioning
*   ISP - Internet Service Provider
*   PDA - Personal Digital Assistant
*   RF - Radio Frequency
*   SRS - Software Requirements Specification
