## 1.1 Purpose

The purpose of the DigitalHome (DH) software is to provide a prototype Smart House management system that enables home residents to monitor and control key aspects of their home environment. Specifically, the software will:
- Allow users to remotely monitor and control temperature, humidity, security (door/window contacts and alarms), and power to small appliances and lighting via a web interface on a computer, cell phone, or PDA.
- Coordinate communication between a DH home web server, a home wireless gateway, and simulated sensors and controllers to manage home devices.
- Demonstrate the principal features and feasibility of a Smart House solution to support HomeOwner Inc.’s business decisions regarding future commercial development.

This initial version is a limited prototype operating in a simulated environment with no physical home hardware.

## 1.2 Scope

This Software Requirements Specification defines the scope of the DigitalHome (DH) prototype software system to be produced by the DigitalHomeOwner Division of HomeOwner Inc., consistent with the Digital Home High Level Requirements Definition [HLRD 2010] and the Digital Home Use Case Model [HO2010].

Products to be produced
- DigitalHome (DH) prototype software system, comprising:
  - DH Home Web Server and web user interface
  - Thermostat control functionality
  - Humidistat control functionality
  - Security system management (contact sensors, light/sound alarms)
  - Appliance Manager (for power switches, including lighting units)
  - DigitalHome Planner (monthly scheduler)
  - Reporting (monthly reports on environmental values, security events, and system operation periods)
  - User account and authentication services
  - Backup and recovery mechanisms
  - Simulated device layer and home database services

What the software will do
- Enable a user, via a personal web page on a DigitalHome web server or a local home server, to:
  - Monitor and control temperature (Fahrenheit and Celsius) through programmable thermostats, including scheduling and manual overrides
  - Monitor and control humidity through programmable humidistats, including scheduling and manual overrides
  - Monitor door/window contact sensors and activate security alarms upon breaches
  - Monitor and change the ON/OFF state of small appliances and lighting via power switches, including scheduling and manual overrides
  - Create and manage a monthly plan specifying environmental settings for up to four daily time periods per day
  - View monthly reports of temperature/humidity statistics, security breach times, and system downtime (for the past two years)
  - Manage user accounts (including authentication)
- Acquire, store, and retrieve sensor and controller data in a home database
- Communicate with home devices via a gateway over wireless links (in this prototype, all devices and the home environment are simulated)
- Perform daily backups and support recovery using the most recent backup

Application, benefits, objectives, and goals
- Application domain: residential smart-home environmental and security management
- Benefits:
  - Convenience and remote access to home environmental controls
  - Improved energy management through planning and scheduling
  - Enhanced home security monitoring and alerting
  - Centralized visibility of environmental conditions and device states
- Objectives and goals:
  - Deliver a limited prototype to validate feasibility and support HomeOwner management decisions on future commercial development
  - Demonstrate end-to-end monitoring, control, planning, and reporting across temperature, humidity, security contacts/alarms, and small appliances/lighting
  - Operate entirely within a realistic simulated home environment (no physical home or devices)

In scope
- Monitoring and control of temperature, humidity, security contacts/alarms, and power switches for small appliances and lighting
- Web-based user interaction from a web-ready device (computer, cell phone, PDA)
- Scheduling (monthly planner), reporting, user authentication, backup/recovery
- Communication via a gateway to simulated sensors and controllers; storage in a home database

Out of scope
- Entertainment and general communications features beyond those explicitly listed above
- Installation, procurement, or operation of physical home devices (all devices are simulated for this prototype)
- Comprehensive commercialization features beyond the prototype’s limited, decision-support purpose

### 1.3.1 Product perspective

DigitalHome (DH) is a prototype smart home management system produced by the DigitalHomeOwner Division of HomeOwner Inc. It is a standalone system that enables residents to monitor and control environmental conditions and selected devices in a home. The product interacts with external network services (an Internet Service Provider), user web clients, and (in production scenarios) household sensors/controllers via a home gateway. For this prototype, all sensors and controllers operate in a simulated environment; no physical home is required.

Major elements and interconnections:
- User web-ready device (computer, cell phone, PDA) ↔ DigitalHome web server (hosted or local home web server).
- DigitalHome web server ↔ home database (plans, configuration, usage data).
- DigitalHome web server ↔ home wireless gateway (broadband internet connection).
- Home wireless gateway (RF module) ↔ thermostats, humidistats, contact sensors, alarms, and power switches (wireless up to 1000 feet indoors).
- External Internet Service Provider provides connectivity between user devices and the DH system.

Relationships to other products/systems:
- The DH system relies on an Internet Service Provider for connectivity (e.g., cable modem, high-speed DSL).
- The DH thermostat functionality must be compatible with centralized HVAC systems and adhere to ASHRAE standards.
- No other parent system is defined; DH is not specified as a component of a larger integrated system.

Interfaces with the larger environment:
- User-facing web interface delivered by the DH web server (or a local home server).
- Network interface between the DH web server and the home gateway over broadband internet.
- Wireless RF interface between the home gateway and household devices.
- Security (authentication and encryption) provided via Transport Layer Security.

System interfaces
- DigitalHome web server ↔ user web client
  - Functionality: user login/logout; browse status; submit monitoring/control requests; planning and reporting.
  - Interface description: web interface secured with authentication and encryption (Transport Layer Security).
- DigitalHome web server ↔ home database
  - Functionality: store/retrieve configuration, default parameter settings, planning data, sensor readings, usage data; support daily backups and recovery.
  - Interface description: [N/A].
- DigitalHome web server ↔ home wireless gateway
  - Functionality: send controller commands (temperature, humidity, power switches, security alarms); receive sensor values (temperature, humidity, contact states, power states).
  - Interface description: broadband-connected link between server and gateway; specific protocols [N/A].
- Home wireless gateway ↔ sensors/controllers
  - Functionality: two-way wireless communication for sensing and actuation.
  - Interface description: RF wireless up to 1000-foot indoor range; specific RF protocols [N/A].
- DigitalHome web server ↔ authentication/security services
  - Functionality: user authentication and encrypted communication.
  - Interface description: Transport Layer Security (TLS); further details [N/A].
- DigitalHome system ↔ Internet Service Provider
  - Functionality: provide network connectivity to the DH web server and home gateway.
  - Interface description: broadband internet (e.g., cable modem, high-speed DSL); specific provider protocols [N/A].

User interfaces
- Web-based user interface accessible from web-ready computers, cell phones, and PDAs.
- Supported interactions:
  - Login/logout with account name and password.
  - Monitor temperature, humidity, contact sensor states, and power switch states (display updates at least every two seconds).
  - Control thermostat setpoints (60–80 °F, 1 ° increments) and humidistat setpoints (30–60% RH, 1% increments); Fahrenheit and Celsius supported for temperature values.
  - Manage security (arm/disarm via contact sensor activation policies) and alarms.
  - Toggle power switches (115V, 10A) for appliances and lighting.
  - Use the DH Planner to create/modify monthly plans (up to four daily time periods per day; up to 24 one-hour settings per device per day where applicable).
  - Override planned values (via website or manual device switches, when available).
  - View monthly reports (daily averages, maxima/minima with times for temperature and humidity; security breach date/time; system downtime periods for the past two years).
  - Access online user documentation (FAQ; explanations of parameters, limitations, and planner usage).
- Error handling: clear, descriptive messages for errors and exceptional conditions.
- Style guide and UI standards: [N/A].

Hardware interfaces
- Home wireless gateway:
  - Broadband internet connection; RF module for wireless communication with devices.
  - Indoor RF operating range up to 1000 feet.
  - Configuration details (ports, instruction sets): [N/A].
- Thermostats (up to 8):
  - Temperature sensing (14 °F to 104 °F sensor range); setpoint control (60–80 °F inclusive, 1 ° increments); individual or collective control; one thermostat per enclosed space; wireless communication with gateway.
  - Compatibility with centralized HVAC systems (gas, oil, electricity, solar, or combinations) per ASHRAE standards.
- Humidistats (up to 8):
  - Humidity sensing and setpoint control (30–60% inclusive, 1% increments); one humidistat per enclosed space; wireless communication with gateway.
- Contact sensors:
  - Magnetic door/window switches (up to 50); monitored when active; trigger security breach events.
- Alarms:
  - One sound alarm subsystem; one light alarm subsystem with multiple lights; activate on security breach.
- Power switches:
  - Up to 100 switches (115V, 10A); monitor and change ON/OFF state of connected appliances/lights.
- For this prototype, physical devices and the home environment are simulated; interfaces must reflect realistic physical properties and constraints.

Software interfaces
- Transport Layer Security
  - Name: Transport Layer Security
  - Mnemonic: TLS
  - Specification number: [N/A]
  - Version number: [N/A]
  - Source: [N/A]
  - Purpose: provide authentication and encryption for the DH web interface and data in transit.
  - Interface definition (message content/format): see TLS standard; additional DH-specific details [N/A].
- Required operating systems, databases, middleware, and browser versions: [N/A].
- Interfaces to other application systems: [N/A].

Communications interfaces
- Broadband internet connectivity via an Internet Service Provider (e.g., cable modem, high-speed DSL). Specific network protocols: [N/A].
- RF wireless communications between gateway and devices (indoor range up to 1000 feet). Specific RF protocols: [N/A].
- Performance characteristics:
  - Sensor data acquisition at minimum 10 Hz.
  - Display updates at least every two seconds.

Memory constraints
- Data retention sufficient to produce month reports for any month within the past two years.
- Primary/secondary memory size limits and storage media specifications: [N/A].

Operations
- Modes of operation:
  - User-initiated interactive operation via the web interface (monitoring, control, planning, reporting).
  - Unattended scheduled operation based on monthly plans (thermostat, humidistat, security contacts, power switches).
  - Manual device overrides persist until the end of the current planned/default time period.
  - Technician-controlled start/stop of system operation.
- Periods of operation:
  - Continuous operation with periodic display updates; continuous data acquisition from sensors.
  - Unattended operation for scheduled actions; interactive sessions as initiated by users.
- Data processing support:
  - Planning (monthly planner), monitoring and control, and reporting (monthly summaries).
- Backup and recovery:
  - Daily backups of configuration, default parameter settings, planning, and usage data (backup time set by DH Technician).
  - Recovery restores data from the most recent backup upon failure (e.g., power loss, internet loss, software/hardware failure).

Site adaptation requirements
- Site-specific configuration performed by a DH Technician (or Master User):
  - Establish user accounts and roles.
  - Define device inventory and placement (thermostats, humidistats, contact sensors, alarms, power switches) per enclosed spaces in the home.
  - Set default parameter settings and units (Fahrenheit/Celsius).
  - Configure backup schedule/time.
- Initialization data or limits (e.g., allowable setpoint ranges) are as specified; site-specific modifications beyond these ranges: [N/A].
- Mission- or installation-specific modifications beyond the above configuration: [N/A].

Interfaces with services
- Internet Service Provider: required for connectivity; specific providers and service-level agreements: [N/A].
- Hosted DigitalHome web server (when not using a local home server): details of hosting environment and service characteristics: [N/A].
- Other SaaS/cloud services: [N/A].

### 1.3.2 Product functions

- Access and account security
  - Establish DigitalHome user accounts.
  - Authenticate users with account name and password; protect sessions with recognized encryption (e.g., TLS).

- Home status monitoring
  - Read and display current temperature at each thermostat location.
  - Read and display current humidity at each humidistat location.
  - Read and display door/window contact sensor states.
  - Read and display the ON/OFF state of each managed power switch (appliances and lighting).
  - Persist sensor values to the home database.

- Environmental temperature control (thermostats)
  - Set thermostat target temperatures (60–80 °F inclusive) with 1-degree increments; support Fahrenheit and Celsius display/entry.
  - Individually or collectively control up to eight thermostats, one per enclosed space.
  - Schedule up to twenty-four one-hour settings per day for each thermostat.
  - Honor manual overrides until the end of the current planned/default time period.
  - Communicate thermostat commands and readings via wireless through the master control unit.

- Environmental humidity control (humidistats)
  - Set humidistat target humidity (30%–60% inclusive) with 1% increments.
  - Control up to eight humidistats, one per enclosed space.
  - Schedule up to twenty-four one-hour settings per day for each humidistat.
  - Honor manual overrides until the end of the current planned/default time period.
  - Communicate humidistat commands and readings via wireless through the master control unit.

- Security monitoring and alarm activation
  - Manage up to fifty door/window contact sensors.
  - Activate one sound alarm and one light alarm subsystem (with multiple lights) when a monitored contact is open and a breach is detected.

- Appliance and lighting power control
  - Manage up to one hundred 115V, 10A power switches for small appliances and lighting.
  - Report current switch state (OFF/ON).
  - Change switch state (OFF to ON, ON to OFF).
  - Honor manual overrides until the end of the current planned/default time period.

- Planning and scheduling
  - Provide a monthly planner to create/modify plans that, for each day and up to four daily time periods, specify temperature, humidity, contact sensor status, and power switch states.
  - Allow planned parameter overrides via the DH website or available device manual controls.

- Reporting and history
  - Generate a monthly report for any month in the past two years, including:
    - Daily average, maximum (with time), and minimum (with time) temperature per thermostat and humidity per humidistat.
    - Dates/times of security breaches (alarm activations).
    - Periods when the DH system was not in operation.

- System configuration and administration
  - Configure system parameters and default settings.
  - Establish and maintain user accounts.
  - Start and stop DH system operation.
  - Set the daily backup time during system setup.

- Data management, backup, and recovery
  - Store configuration, default parameter settings, planning data, and usage data.
  - Perform daily backups of all system data.
  - Restore system data from the most recent backup after failures (e.g., power or internet loss).

- Communications and device integration
  - Operate a home web server that mediates user interaction, data storage, and device control.
  - Coordinate wireless communication between the DH gateway and sensors/controllers.

- Online user assistance
  - Provide online documentation, including FAQs, explanations of parameter setting and sensor accuracy/limitations, and guidance for using the DH Planner.

### 1.3.3 User characteristics

The product is intended for two primary user groups: home residents (general users, including a designated Master user) and DigitalHome Technicians. Users interact primarily through a web interface on a web-ready computer, cell phone, or PDA.

- General users (home residents)
  - Purpose of use: Monitor and control home environment (temperature, humidity, security contacts, and power to small appliances/lighting).
  - Technical expertise: Not familiar with technical features of the DH system; able to perform basic web operations (log in/out, browse pages, submit information/requests via a web interface).
  - Domain knowledge: Familiar with the layout of the home and locations of sensors and control devices.
  - Access devices: Web-ready computer, cell phone, or PDA.
  - Experience: Familiarity with basic web usage; other experience details [N/A].
  - Educational level: [N/A]
  - Disabilities: [N/A]

- Master user (designated resident with elevated privileges)
  - Role and authority: May change system configuration (e.g., add user accounts, change default parameter settings); has the same rights as a DH Technician.
  - Technical expertise: Not specified beyond having technician-equivalent rights; detailed expertise level [N/A].
  - Experience: [N/A]
  - Educational level: [N/A]
  - Disabilities: [N/A]

- DigitalHome Technicians
  - Role and authority: Set up and maintain system configuration; establish user accounts and system parameters; start and stop operation of the DH system.
  - Technical expertise: Experienced with relevant hardware, software, and web services; specially trained by DigitalHomeOwner; familiar with DH functionality, architecture, and operation.
  - Experience: Professional experience with systems like DH; specific years/credentials [N/A].
  - Educational level: [N/A]
  - Disabilities: [N/A]

### 1.3.4 Limitations

The following items limit solution options for the supplier.

- a) Regulatory requirements and policies
  - The system shall adhere to ASHRAE standards for HVAC compatibility.
  - Development and documentation shall follow IEEE standards and HomeOwner Inc. policies (HomeOwner Coding Standard, HomeOwner document format, use of UML 2.0 for object-oriented development; exceptions require CIO approval).
  - Security for remote access shall use recognized technologies such as Transport Layer Security (TLS).
  - Where possible, widely used, accepted, and available hardware/software technologies and standards shall be employed.
  - Project cost for DH elements should be minimized.
- b) Hardware limitations
  - Wireless communication range: devices must be within 1000 feet of the DH Gateway; the Gateway operates up to a 1000-foot indoor transmission range.
  - RF module is required in the Gateway to communicate with sensors/controllers.
  - Device capacities: up to 8 thermostats; up to 8 humidistats; up to 50 door/window contact sensors; up to 100 power switches.
  - Electrical rating: power switches are limited to 115 V, 10 A.
  - Setpoint ranges: thermostats 60–80 °F (inclusive) in 1 ° increments; humidistats 30%–60% RH (inclusive) in 1% increments.
  - Thermostat sensor operating range: 14 °F to 104 °F (−10 °C to 40 °C).
- c) Interfaces to other applications
  - The system depends on a web interface accessed via web-ready devices (computer, cell phone, PDA) and an ISP for connectivity.
  - Interfaces to third-party applications beyond the above are [N/A].
- d) Parallel operation
  - [N/A]
- e) Audit functions
  - Daily backups of configuration, default settings, planning, and usage data; recovery restores from the most recent backup.
  - Exception handling shall provide clear, descriptive messages upon errors or exceptional conditions.
  - Historical reporting is limited to the past two years and includes daily environmental summaries, times of security breaches, and periods when the system was not in operation.
- f) Control functions
  - A DH Technician and the designated Master user may configure the system, establish user accounts, set default parameters, and start/stop system operation.
  - Manual overrides on devices persist only until the end of the current planned/default time period.
  - Security alarms are automatically activated when an active contact sensor is opened.
- g) Higher-order language requirements
  - HomeOwner policy designates object-oriented development using UML 2.0; specific programming languages are [N/A].
- h) Signal handshake protocols
  - Specific handshake protocols for wireless communication (e.g., XON–XOFF, ACK–NACK) are [N/A].
- i) Quality requirements
  - Reliability: no more than 1 failure per 10,000 hours of operation.
  - Performance: sensor data acquisition minimum 10 Hz; environmental displays updated at least every 2 seconds.
  - Backup and recovery mechanisms are required.
- j) Criticality of the application
  - Although a prototype intended to inform business decisions, failures may affect occupant safety and security (e.g., security breaches, inadequate lighting, inappropriate temperature/humidity), necessitating high reliability.
- k) Safety and security considerations
  - Authentication and encryption via TLS; login requires account name and password.
  - No specific safety requirements are mandated; emphasis is on reliability to prevent conditions that could impact safety.
- l) Physical/mental considerations
  - General users are expected to be familiar with web interfaces and the layout of their home devices; additional accessibility or cognitive requirements are [N/A].
- m) Limitations sourced from other systems, including real-time requirements through interfaces
  - Dependence on an ISP (e.g., cable modem or high-speed DSL) for remote connectivity; loss of Internet access is a defined failure mode with recovery from the latest backup upon restoration.
  - Prototype operates in a simulated environment; no physical home or real sensors/controllers are included in this version.
  - HVAC compatibility is limited to centralized systems (gas, oil, electricity, solar, or combinations) and associated standards.
  - Real-time constraints include 10 Hz sensor acquisition and ≤2-second update intervals for displays.

## 1.4 Definitions

- DigitalHome (DH): The prototype smart home system defined in this SRS that enables residents to monitor and control a home’s environment and selected devices via a web-ready interface.

- DH Home Web Server: The communication center for a DH system, hosted on a home computer, that provides interaction with and control of DH elements, storage of DH plans and data, user account management, and backup of user accounts, plans, and the home database.

- DH Gateway Device: The master control device in a DH system that connects to the home’s broadband Internet connection and uses wireless (RF) communication to send and receive data to and from DH sensors and controllers; operates up to a 1000-foot indoor range.

- General User: A home resident who uses the DH system to monitor and control the home environment through a web interface.

- Master User: A designated user with configuration rights equivalent to a DH Technician, including adding user accounts and changing default parameter settings.

- DH Technician: A trained specialist responsible for setting up, configuring, maintaining, and starting/stopping a DH system; has rights beyond those of a General User (e.g., setting system parameters and establishing user accounts).

- Thermostat (DH): A digital, programmable controller-sensor used by the DH system to read current temperature and regulate it to a user-specified set point.

- Humidistat (DH): A digital, programmable controller-sensor used by the DH system to read current relative humidity and regulate it to a user-specified set point.

- Power Switch (DH): A digital, programmable switch used by the DH system to monitor and change the on/off state of small appliances and lighting units.

- Contact Sensor (Magnetic Contact): A sensor used by the DH security subsystem to detect the open/closed state of doors and windows when armed.

- Security Alarms: The DH security subsystem’s sound and light alarms that can be activated upon a detected security breach.

- Security Breach: An external act that bypasses or contravenes the DH security system, such as opening a door or window monitored by an active contact sensor.

- Set Point: A numeric value that establishes the desired value of an environmental quality (e.g., temperature or humidity) for DH control.

- DigitalHome Planner: The DH capability that allows users to schedule preset home parameters (temperature, humidity, security contacts, and power switch states) for specified time periods, including a monthly planner.

- Appliance Manager: The DH subsystem that manages small appliances and lighting by monitoring and controlling their power state (on/off) through power switches.

# 2 References

The following references are subdivided into Compliance (normative) and Guidance (informative). Each item identifies title, report number (if applicable), date, publishing organization, and the source from which it can be obtained.

## Compliance

- [ASHRAE 2010]
  - Title: Website for American Society of Heating, Refrigerating and Air-Conditioning Engineers
  - Report number: [N/A]
  - Date: Accessed October 2010
  - Publishing organization: American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE)
  - Source: http://www.ashrae.org/
- [HO2305]
  - Title: Guidelines for Developing HomeOwner Technical Reports
  - Report number: HO2305
  - Date: March 2002
  - Publishing organization: HomeOwner Inc.
  - Source: HomeOwner Document Archive
- [HO4710]
  - Title: HomeOwner Coding Standard
  - Report number: HO4710
  - Date: August 2009
  - Publishing organization: HomeOwner Inc.
  - Source: HomeOwner Document Archive
- [IEEE830]
  - Title: IEEE Recommended Practice for Software Requirements Specifications
  - Report number: IEEE Std 830-1998
  - Date: 1998
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc. (IEEE)
  - Source: IEEE
- [IEEE 1008]
  - Title: IEEE Standard for Software Unit Testing
  - Report number: ANSI/IEEE Std 1008-1987
  - Date: 1987
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc. (IEEE)
  - Source: IEEE
- [IEEE1016]
  - Title: IEEE Standard for Information Technology - Systems Design - Software Design Descriptions
  - Report number: IEEE Std 1016-2009
  - Date: 2009
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc. (IEEE)
  - Source: IEEE
- [IEEE1028]
  - Title: IEEE Standard for Software Reviews and Audits
  - Report number: IEEE Std 1028-2008
  - Date: 2008
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc. (IEEE)
  - Source: IEEE

## Guidance

- [HLRD 2010]
  - Title: Digital Home High Level Requirements Definition
  - Report number: [N/A]
  - Date: September 2010
  - Publishing organization: HomeOwner Inc., DigitalHomeOwner Division
  - Source: HomeOwner Document Archive
- [HO2010]
  - Title: Digital Home Use Case Model
  - Report number: [N/A]
  - Date: October 24, 2010
  - Publishing organization: HomeOwner Inc., DigitalHomeOwner Division
  - Source: HomeOwner Document Archive
- [IEEE 1012]
  - Title: IEEE Standard for Software Verification and Validation
  - Report number: IEEE Std 1012-2004
  - Date: 2004
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc. (IEEE)
  - Source: IEEE
- [Meyer 2004]
  - Title: Smart Home Hacks: Tips & Tools for Automating Your House
  - Report number: [N/A]
  - Date: 2004
  - Publishing organization: O’Reilly
  - Source: O’Reilly

## 3.1 Functions

The DigitalHome (DH) software accepts user and device inputs, validates and processes them through the DH web server and home gateway, and generates outputs that monitor and control home environment, security, and appliances.

- Authentication and access
  - Inputs: account name, password.
  - Validity checks: account name and password are required; authentication is enforced; communication is secured via a recognized protocol (e.g., TLS).
  - Sequence:
    1. User navigates to the DH web server (home or hosted).
    2. User submits account name and password.
    3. System authenticates the user and grants access to permitted functions.
  - Outputs: access granted or denied message.
  - Abnormal responses:
    - Error handling and recovery: clear, descriptive message on authentication failure.
    - Communication facilities: if secure channel cannot be established, present error; recovery behavior not further specified.
    - Hardware faults and failures: on failure leading to service interruption, recovery restores data from most recent backup after service resumes.
    - Overflow: [N/A]
  - Effect of parameters: user accounts and roles (General User, Master User, DH Technician) constrain available functions.

- Sensor data acquisition and display
  - Inputs: wireless sensor readings (temperature, humidity, contact state, power state).
  - Validity checks: sensor data are acquired at a minimum of 10 Hz; devices must be within 1000 feet of the gateway to communicate; only configured sensors are accepted.
  - Sequence:
    1. Gateway receives wireless readings from sensors.
    2. Server stores readings in the home database.
    3. Displays of environmental conditions are refreshed at least every two seconds.
  - Outputs: updated UI values; persisted readings.
  - Abnormal responses:
    - Communication facilities: loss of wireless or Internet connection triggers a clear, descriptive error to the user.
    - Hardware faults and failures: on failure (power loss, loss of Internet access, or other failures), system restores data from the most recent backup after recovery.
    - Overflow: [N/A]
  - Effect of parameters: device registration and configuration determine which readings are accepted and displayed.

- Thermostat monitoring and control
  - Inputs: user requests to read temperature and set a temperature setpoint; scheduled setpoints; manual device adjustments (if available).
  - Validity checks:
    - Setpoint must be between 60 °F and 80 °F, inclusive, in 1 ° increments.
    - Support for Fahrenheit and Celsius units; exact conversion formulas are not specified.
    - Up to eight thermostats; one thermostat per enclosed space.
    - Up to twenty-four one-hour settings per day per thermostat.
  - Sequence:
    1. User reads current temperature at a thermostat position.
    2. User sets a thermostat setpoint or defines a per-thermostat daily schedule.
    3. Server sends controller values via the gateway to the thermostat/HVAC controller.
    4. Device switches heating/cooling on or off as needed to achieve the setpoint.
    5. If a manual setpoint is made on the device, it remains until the end of the current planned or default time period; then the planned/default setting takes effect.
  - Outputs: current temperature readings; confirmation of setpoint/schedule; HVAC actuation commands.
  - Abnormal responses:
    - Input outside allowed ranges is rejected with a clear, descriptive message.
    - Communication facilities: loss of communication results in error notification; data are restored from backup after recovery.
    - Hardware faults and failures: recovery from most recent backup.
    - Overflow: [N/A]
  - Effect of parameters: selected unit (°F/°C), per-thermostat schedules, and default settings determine control behavior.

- Humidistat monitoring and control
  - Inputs: user requests to read humidity and set a humidity setpoint; scheduled setpoints; manual device adjustments (if available).
  - Validity checks:
    - Setpoint must be between 30% and 60% relative humidity, inclusive, in 1% increments.
    - Up to eight humidistats; one per enclosed space.
    - Up to twenty-four one-hour settings per day per humidistat.
  - Sequence:
    1. User reads current humidity at a humidistat position.
    2. User sets a humidistat setpoint or defines a per-humidistat daily schedule.
    3. Server sends controller values via the gateway to control humidifiers/dehumidifiers.
    4. If a manual setting is made on the device, it remains until the end of the current planned or default time period; then the planned/default setting takes effect.
  - Outputs: current humidity readings; confirmation of setpoint/schedule; control commands to humidity equipment.
  - Abnormal responses:
    - Input outside allowed ranges is rejected with a clear, descriptive message.
    - Communication facilities and hardware failures: as above; data restored from backup after recovery.
    - Overflow: [N/A]
  - Effect of parameters: setpoints and schedules determine control actions.

- Security monitoring and alarms
  - Inputs: door/window contact sensor states; arming status per planner; user queries.
  - Validity checks:
    - Up to fifty contact sensors managed.
    - Contact sensors report OPEN/CLOSED; only configured sensors are processed.
  - Sequence:
    1. System monitors contact sensors via wireless input.
    2. When a security breach occurs and a contact sensor is set OPEN, the alarm system is activated.
    3. Planner can enable/disable contact sensors per time period.
  - Outputs: alarm activation (sound and light); security breach logs with date and time.
  - Abnormal responses:
    - Communication facilities: loss of sensor link produces a clear error.
    - Hardware faults and failures: on failure, data and configuration restored from backup.
    - Overflow: [N/A]
  - Effect of parameters: arming status from the planner controls whether a sensor triggers alarms.

- Appliance and lighting management
  - Inputs: user commands to read or change power switch state; planner-based on/off settings; manual device toggles.
  - Validity checks:
    - Up to one hundred power switches (115 V, 10 A) managed.
    - Power state is OFF or ON only.
  - Sequence:
    1. User queries current power state of a switch.
    2. User or planner issues a command to change state.
    3. System sends command via gateway; device changes state.
    4. If a manual change is made, it persists until the end of the current planned or default time period; then the planned/default setting takes effect.
  - Outputs: reported power state; confirmation of state changes; device control signals.
  - Abnormal responses:
    - Invalid device selection or state rejected with a clear message.
    - Communication facilities and hardware failures: as above; data restored from backup after recovery.
    - Overflow: [N/A]
  - Effect of parameters: planner schedules and default settings determine automatic on/off behavior.

- Planning and scheduling
  - Inputs: month and year; per-day environmental parameter settings for up to four daily time periods; device-specific daily schedules (up to twenty-four one-hour settings for thermostats and humidistats).
  - Validity checks:
    - Planner accepts at most four periods per day per month plan.
    - Device-specific schedules accept at most twenty-four one-hour entries per day for each thermostat/humidistat.
  - Sequence:
    1. User creates or modifies a month plan for a given month and year.
    2. For each day, user specifies temperature, humidity, contact sensor arming, and power switch states for up to four time periods.
    3. System stores the plan and applies settings at the start of each time period.
    4. Manual overrides via website or device controls persist until the end of the current time period, after which planned/default values resume.
  - Outputs: confirmation of saved plans; automatic application of settings at time boundaries.
  - Abnormal responses:
    - Invalid plans (exceeding period limits or invalid values) are rejected with a clear message.
    - Communication facilities and hardware failures: as above; plans persist via backup and are restored after recovery.
    - Overflow: [N/A]
  - Effect of parameters: planned values and default settings drive device commands at scheduled times.

- Reporting
  - Inputs: report request for a given month and year within the past two years.
  - Validity checks: requested month must be within the past two years; target period must exist in stored data.
  - Sequence:
    1. User requests a month report.
    2. System aggregates stored data for the requested period.
    3. System compiles daily average, maximum (with time), and minimum (with time) temperature and humidity per thermostat/humidistat; security breach dates/times; and periods when the DH System was not in operation.
  - Outputs: month report containing specified aggregates and event times.
  - Abnormal responses:
    - Missing data or out-of-range periods yield a clear message.
    - Hardware/communication failures do not affect previously stored data; recovery restores access to data from backup.
    - Overflow: [N/A]
  - Effect of parameters: none beyond the report time window.

- Backup and recovery
  - Inputs: backup time set by DH Technician; system state and data.
  - Validity checks: backup schedule is required.
  - Sequence:
    1. System performs daily backups of configuration, default parameter settings, planning, and usage data at the configured time.
    2. On failure (power loss, loss of Internet access, or other software/hardware failure), the system recovery mechanism restores system data from the most recent backup.
  - Outputs: backed-up data; restored system state after failure.
  - Abnormal responses:
    - Communication facilities and hardware failures trigger recovery from backup and clear user notifications.
    - Overflow: [N/A]
  - Effect of parameters: technician-defined backup time determines when backups execute.

Relationship of outputs to inputs
- Input/output sequences:
  - Reading sensors results in stored readings and refreshed displays (at least every two seconds).
  - Changing a setpoint or power state results in controller commands sent via the gateway, followed by updated device state and UI confirmation.
  - Opening a contact sensor when armed results in immediate alarm activation and a logged breach entry with date and time.
  - Manual overrides remain in effect until the end of the current planned or default time period; then planned/default values resume.
- Formulas for input to output conversion: [N/A]

## 3.2 Performance requirements

This section consolidates quantitative performance requirements for the system. Where the original SRS does not provide a quantitative limit, [N/A] is specified.

### Static numerical requirements (capacity)
- Terminals supported: [N/A]
- Simultaneous users supported: [N/A]
- Device capacities:
  - Up to 8 thermostats per home.
  - Up to 8 humidistats per home.
  - Up to 50 door/window contact sensors per home.
  - One sound alarm and one light alarm subsystem (with multiple lights).
  - Up to 100 power switches (115 V, 10 A).
- Scheduling capacities:
  - Thermostats: up to 24 one-hour settings per day for each day of the week (per thermostat).
  - Humidistats: up to 24 one-hour settings per day for each day of the week (per humidistat).
  - Planner: up to 4 daily time periods per day in a monthly plan.
- Reporting/history capacity:
  - Monthly reports shall be available for any month within the past 2 years.
- Communication capacity:
  - Indoor wireless communication range up to 1000 feet between the master control (Gateway) and sensors/controllers.
- Information handled:
  - Types: environmental sensor readings (temperature, humidity), security contact states, alarm states, power switch states, user plans, configuration and usage data.
  - Amount (volume/size): [N/A]

### Dynamic numerical requirements (throughput and timing)
- Display refresh: environmental conditions (temperature, humidity, contact sensors, power switches) shall be updated at least every 2 seconds.
- Sensor data acquisition: minimum sampling rate of 10 Hz for sensors (temperature, humidity, contact sensor, power state).
- Backup frequency: all system data (configuration, default parameter settings, planning, usage data) shall be backed up daily; backup time set during system setup.
- Transaction/command response times (e.g., setpoint changes, switch toggles): [N/A]
- Alarm activation/notification latency: [N/A]
- Normal and peak workload throughput limits (transactions per interval, data processed per interval): [N/A]

## 3.3 Usability requirements

### Contexts of use
- General users are familiar with web interfaces and can perform simple web operations (logging in and logging out, browsing web pages, and submitting information and requests via a web interface).
- A designated Master user can change the configuration of the system (e.g., add user accounts, change default parameter settings). A DH Technician has rights beyond the general user to set up, change configuration, and start/stop the system.
- Users access and control the system via a web-ready computer, cell phone, or PDA.

### Effectiveness
- The system shall allow users to monitor and control a home’s temperature, humidity, lights, security, and the state of small appliances via the DH home web server.
- Users shall be able to read environmental conditions (temperature at thermostat positions, humidity at humidistat positions, and power switch states) and change controller values (thermostat temperatures, humidity set points, and power switch states).
- The system shall support both Fahrenheit and Celsius temperature values.
- Users shall be able to override planned parameter values through the DH website (or via manual device switches where available).

### Efficiency
- Displays of environmental conditions (temperature, humidity, contact sensors, and power switches) shall be updated at least every two seconds.
- Sensors (temperature, humidity, contact sensor, power state) shall have a minimum data acquisition rate of 10 Hz.

### Satisfaction
- [N/A]

### Error management, feedback, and support
- All operations shall incorporate exception handling so that the system responds to a user with clear, descriptive messages when an error or exceptional condition occurs.
- The system shall provide online user documentation, including:
  - An FAQ section about use and maintenance (e.g., password changes, obtaining support).
  - Explanations of how DH parameters are set and how sensor values are read, including limitations and constraints on settings and sensor accuracy.
  - Instructions for using the DH Planner.

### Avoidance of harm (quality in use: safety and security)
- The system shall be highly reliable, with no more than 1 failure per 10,000 hours of operation.
- The system shall incorporate backup and recovery mechanisms to restore configuration, default parameter settings, planning, and usage data from the most recent backup after failures (e.g., power loss, loss of internet access, hardware/software failure).
- The system shall protect user accounts via authentication and information encryption using a recognized, reliable security technology (e.g., Transport Layer Security); login requires account name and password.
- Role-based rights shall restrict configuration changes to the Master user and DH Technician, reducing the risk of inadvertent or unauthorized changes that could affect home safety (e.g., security, lighting, temperature, humidity).

## 3.5 Logical database requirements

The DigitalHome home web server stores user accounts, configuration/default parameters, plans, sensor/controller values, usage data, and events. Sensor values can be read and saved in the home database. Monthly reports for any month in the past two years must be produced from stored data. Daily backups of all system data are required.

- a) Types of information used by various functions
  - User and configuration
    - User accounts and roles: General User, Master User, DH Technician.
    - System configuration and default parameter settings.
    - Backup configuration (backup time set by DH Technician).
  - Device registry and locations
    - Registered devices: Gateway, Thermostats (up to 8), Humidistats (up to 8), Door/Window Contact Sensors (up to 50), Power Switches (up to 100), Alarm subsystem (one sound alarm, one light alarm subsystem with multiple lights).
    - Device attributes: type, identifier, location (enclosed space/room), capabilities (e.g., setpoint, schedule support), and current operational state.
  - Thermostat function
    - Current temperature readings at each thermostat position.
    - Temperature setpoints (supports Fahrenheit and Celsius).
    - Per-thermostat daily schedules (up to 24 one-hour settings per day, for each day of the week).
    - Manual override status and timing.
  - Humidistat function
    - Current humidity readings at each humidistat position.
    - Humidity setpoints.
    - Per-humidistat daily schedules (up to 24 one-hour settings per day, for each day of the week).
    - Manual override status and timing.
  - Security function
    - Contact sensor states (OPEN/CLOSED).
    - Security breach events (with date/time).
    - Alarm activations (sound/light) and their timing.
  - Appliance management function
    - Power switch states (OFF/ON) and changes.
  - Planning function
    - Monthly plans by month/year.
    - For each day: up to four daily time periods specifying parameter settings (temperature, humidity, contact sensors, power switches).
    - Overrides of planned parameter values (including source: website or device manual switches).
  - Reporting function
    - For each thermostat/humidistat: daily average, maximum with time, minimum with time (per reported month).
    - Security breach day/time entries (per reported month).
    - Periods when the DH System was not in operation (per reported month).
- b) Frequency of use
  - Sensor data acquisition: minimum 10 Hz for temperature, humidity, contact sensors, and power state measurements.
  - Display refresh: at least every 2 seconds (requires timely reads from stored/streamed values).
  - Backups: daily at a technician-configured time.
  - Planning: monthly plans created/modified as needed; per-day time periods applied as scheduled.
  - Reporting: on demand for any month in the past two years.
  - Exact database write frequencies for raw sensor logging: [N/A].
- c) Accessing capabilities
  - Access via the DH home web server from web-ready devices (computer, cell phone, PDA).
  - General Users
    - Read current environmental conditions and device states.
    - Request control actions (e.g., change setpoints, switch states).
    - View reports.
  - Master Users and DH Technicians
    - All General User capabilities.
    - Manage configuration and default parameters.
    - Establish and maintain user accounts.
    - Start/stop system operation and set backup time.
  - System services
    - Persist sensor values and device states.
    - Apply scheduled plan settings.
    - Generate monthly reports from stored data.
    - Perform daily backups and enable recovery.
- d) Data entities and their relationships
  - Home: owns Users, Devices, Plans, Sensor/State Logs, Events, and Backups.
  - UserAccount: associated with a Role; may create/modify Plans and issue Control Requests.
  - Role: General User, Master User, DH Technician.
  - EnclosedSpace (Room): may contain at most one Thermostat and at most one Humidistat.
  - Device (abstract): specialized as Thermostat, Humidistat, ContactSensor, PowerSwitch, Alarm, Gateway; each assigned to a Home and optionally to an EnclosedSpace.
  - ThermostatReading and HumidistatReading: time-stamped sensor readings linked to the respective device.
  - DeviceStateChange: time-stamped state transitions (e.g., PowerSwitch ON/OFF, ContactSensor OPEN/CLOSED, Alarm activation).
  - Setpoint: time-stamped setpoint values linked to Thermostat/Humidistat.
  - DeviceSchedule: per-device schedule (up to 24 one-hour settings per day, per day of week) for Thermostats/Humidistats.
  - MonthlyPlan: for a given month/year; contains DailyTimePeriods (up to four per day) with parameter settings covering temperature, humidity, contact sensors, and power switches.
  - Override: time-bounded override applied to planned settings; records source (website or manual device control).
  - SecurityEvent: records security breaches and associated sensors/alarms with timestamps.
  - SystemOutagePeriod: periods when the system was not in operation.
  - BackupJob: records backup time and scope (configuration, default settings, planning, usage data).
- e) Integrity constraints
  - Device and count limits per Home:
    - Thermostats: up to 8; at most one per EnclosedSpace.
    - Humidistats: up to 8; at most one per EnclosedSpace.
    - Contact Sensors: up to 50.
    - Power Switches: up to 100.
    - Alarm subsystem: exactly one sound alarm and one light alarm subsystem (with multiple lights allowed).
  - Setpoint ranges and increments:
    - Thermostat setpoints: 60°F to 80°F inclusive, in 1°F increments.
    - Humidistat setpoints: 30% to 60% inclusive, in 1% increments.
    - Celsius setpoint limits: [N/A].
  - Schedules and planning:
    - DeviceSchedule: up to 24 one-hour settings per day for each day of the week (per Thermostat/Humidistat).
    - MonthlyPlan: up to four daily time periods per day specifying parameter settings.
    - Manual device changes remain in effect until the end of the current planned or default time period.
  - State/value domains:
    - ContactSensor state ∈ {OPEN, CLOSED}.
    - PowerSwitch state ∈ {OFF, ON}.
  - Reporting support:
    - All sensor readings, setpoints, state changes, security events, and outages must be time-stamped to support max/min “with time” and event time reporting.
  - Identifier uniqueness (e.g., device identifiers, account names): [N/A].
- f) Security
  - Account-based authentication (account name and password) required for access.
  - Communication security: use Transport Layer Security for authentication and information encryption.
  - Authorization enforced via roles (General User, Master User, DH Technician); only Master Users and DH Technicians may change configuration and user accounts.
  - Database encryption at rest, password storage method, auditing, and access logging: [N/A].
- g) Data retention requirements
  - Retain data necessary to generate monthly reports for any month in the past two years, including:
    - Time-stamped sensor readings or derived aggregates sufficient to compute daily averages, maxima with times, and minima with times for each thermostat and humidistat.
    - Security breach occurrences (day/time) and alarm activations.
    - System not-in-operation periods.
  - Retain configuration, default parameter settings, planning data, and usage data to support daily backups and recovery.
  - Backup frequency: daily; recovery restores from the most recent backup.
  - Archival/purging policy beyond two years: [N/A].

## 3.6 Design constraints

- Standards and compliance
  - HVAC compliance: The system shall be compatible with centralized HVAC systems (gas, oil, electricity, solar, or combinations) and adhere to the standards, policies, and procedures of the American Society of Heating, Refrigerating and Air-Conditioning Engineers [ASHRAE 2010].
  - Security protocol: Authentication and information encryption shall use a recognized, reliable security technology, such as Transport Layer Security (TLS).
  - Corporate engineering standards:
    - The development process specified by HomeOwner Inc. shall be used.
    - Object-oriented development using UML 2.0 is mandated; exceptions require CIO approval.
    - Documentation and engineering standards shall be followed: IEEE 830 (SRS), IEEE 1008 (Unit Testing), IEEE 1016 (Software Design Descriptions), IEEE 1028 (Reviews and Audits), and the HomeOwner Coding Standard [HO4710].
    - All system documents shall use the HomeOwner document format [HO2305] and reside in the HomeOwner Document Archive at project completion.

- Project limitations
  - Prototype scope: This initial version is a limited prototype intended for business decision-making; it is not a comprehensive or complete specification of all product requirements.
  - Simulated environment: The system shall operate and be tested entirely in a simulated environment; there will be no physical home and all sensors and controllers will be simulated. The simulation shall be realistic and adhere to the physical properties and constraints of an actual home and real devices.
  - Schedule and resources: The prototype shall be completed within twelve months of inception, by a development team of five engineers (with management and communication support from the DigitalHomeOwner Director).
  - Cost constraints: Costs of system elements (sensors, controllers, servers, tools, etc.) shall be minimized; price comparisons with competitive elements shall be documented in the final project report.
  - Technology choices: Where possible, widely used, accepted, and available hardware/software technologies and standards shall be employed for both product elements and development tools.
  - Change control: Major requirement changes must be approved by the Director of the DigitalHomeOwner Division.

- Operational environment constraints impacting design
  - Network access: The home system requires a widely available ISP (e.g., cable modem, high-speed DSL).
  - Hosting: The system shall support an individual home web server hosted on a home computer to provide interaction/control of DH elements, storage of plans and data, user account management, and backup service.
  - Gateway and wireless: A DH Gateway device shall connect to a broadband Internet connection and include an RF module to communicate with sensors and controllers; indoor wireless operation shall support up to a 1000-foot range.

## 3.7 Software system attributes

### Reliability
- The system shall be highly reliable with no more than 1 failure per 10,000 hours of operation.
- All operations shall incorporate exception handling so that the system responds to a user with a clear, descriptive message when an error or exceptional condition occurs.

### Availability
- The system shall incorporate backup and recovery mechanisms to support restart after failures.
- The system shall back up all system data (configuration, default parameter settings, planning, and usage data) on a daily basis; the backup time shall be set by the DH Technician at system setup.
- In the event of power loss, loss of internet access, or other software or hardware failure, the system shall restore system data from the most recent backup.
- A DH Technician shall be able to start and stop operation of the DH System.

### Security
- Upon installation, a DigitalHome user account shall be established.
- Login shall require entry of an account name and a password.
- The web system shall provide authentication and information encryption through a recognized reliable and effective security technology, such as Transport Layer Security.
- Role-based access shall be enforced: a Master User and a DH Technician shall have rights beyond a General User, including establishing user accounts, setting system parameters, and starting/stopping the system; General Users shall not change system configuration.
- The system shall record the day and time of security breaches (alarm activations) to support reporting.

### Maintainability
- The system shall be supported by documentation of requirements, design, and code.
- The design shall employ abstraction, information hiding, and module independence.
- Development shall use IEEE standards [IEEE830, IEEE1008, IEEE1016, IEEE1028] and the HomeOwner Coding Standard [HO4710].
- Although a prototype, all modules and components shall be designed and implemented so they may be incorporated into a fully specified commercial version of the DigitalHome System.

### Portability
- Where possible, the system shall employ widely used, accepted, and available hardware and software technology and standards for both product elements and development tools to facilitate portability.
- The user interface shall be web-based and accessible via web-ready devices (computer, cell phone, PDA), supporting client-side portability across common platforms.
- Specific measures such as percentage of host-dependent code, specific programming languages/compilers, or designated operating systems: [N/A]

## 3.8 Supporting information

- Sample input/output formats: [N/A]
- Descriptions of cost analysis studies: [N/A]
- Results of user surveys: [N/A]

Supporting and background information extracted from the original SRS:
- Purpose and scope
  - Prototype “Smart House” system to help HomeOwner Inc. make business decisions about future products.
  - Scope limited to managing temperature, humidity, security (door/window contacts with alarms), and power to small appliances and lighting via a web-ready device.
  - All devices and the physical home are simulated; the environment should be realistic and adhere to physical properties and constraints.
- System context and architecture
  - Users interact through a personal web page on a DigitalHome web server or a local home server.
  - A home gateway connects to broadband Internet and uses RF wireless communication with sensors and controllers; indoor transmission up to 1000 feet.
  - System components: household devices (HVAC-related, humidifiers/dehumidifiers, security alarms, power switches), sensors and controllers, communication links, and a managing computer system.
  - ISP required; examples include cable modem or high-speed DSL.
- Users and roles
  - General users monitor and control the home environment via web interfaces.
  - A Master user can change configuration (e.g., add accounts, change default parameters), with rights equivalent to a DH Technician.
  - DH Technicians set up, configure, start/stop, and maintain the system; trained by DigitalHomeOwner and experienced with related technologies.
- Planning and reporting
  - Monthly planner: for each day, up to four daily time periods with parameter settings (temperature, humidity, contacts, power switches); users may override.
  - Monthly reports (for past two years): daily average, max/min (with times) for temperature and humidity per device; timestamps of security breaches; periods when the system was not in operation.
- Reliability, security, and maintenance
  - Backup and recovery: daily backups at a configurable time; recovery restores configuration, defaults, planning, and usage data from the most recent backup.
  - Authentication with account name and password; communication security via a recognized technology such as Transport Layer Security.
  - Development and documentation follow HomeOwner standards and IEEE standards; object-oriented development using UML 2.0 preferred.
- Standards and compatibility
  - HVAC compatibility: gas, oil, electricity, solar, or combinations; adheres to ASHRAE standards.
  - Use of widely used, accepted, and available technologies and standards where possible.
- Cost considerations
  - Costs of sensors, controllers, server, tools, etc., should be minimized; final project report should describe cost minimization efforts, including price comparisons.
- Additional artifacts
  - A Digital Home Use Case Model provides an overview of functionality and relationships between system entities.

Description of the problems to be solved by the software:
- Enable remote monitoring and control of home environmental conditions: read sensor values (temperature, humidity, contact state, power state) and send controller commands (thermostat set points, humidistat levels, power switch states).
- Detect and respond to security breaches by monitoring door/window contacts and activating light and sound alarms.
- Schedule environmental parameters and device states over days and months and support manual overrides.
- Generate historical reports for environmental conditions, security events, and system downtime periods.
- Provide reliable operation with backup and recovery, and secure access via authentication and encrypted communications.
- Operate through a web interface backed by a home web server and a wireless gateway that connects to simulated home devices.

Special packaging instructions for code and media (security, export, initial loading, or other requirements): [N/A]

Whether the above supporting information items are to be considered part of the requirements: [N/A]

## 4.1 Functions

This subsection defines the verification approaches and methods planned to qualify the functional behavior of the software, mirroring the information items in 3.1 Functions: a) input validity checks; b) exact sequence of operations; c) responses to abnormal situations (overflow, communication facilities, hardware faults/failures, error handling and recovery); d) effect of parameters; and e) relationship of outputs to inputs (input/output sequences, formulas). The planned methods are inspection, analysis, test, demonstration, and simulation in a realistic, fully simulated home environment as specified.

General environmental control and communications
- Methods: inspection, analysis, test, simulation.
- Input validity checks:
  - Verify that only supported client types (web-ready computer, cell phone, PDA) can submit commands via authenticated sessions; reject unauthenticated requests. Evidence: request logs and server responses.
  - Validate device identifiers, room/zone identifiers, and command schemas against configuration. Attempt invalid IDs and malformed payloads to confirm rejection with clear messages.
- Exact sequence of operations:
  - Confirm that web request → home server processing → gateway transmission → device actuation → acknowledgement → state persistence occurs in order with no reordering in single requests.
  - Verify that reads (sensor polling) precede state display updates and that updates occur at least every two seconds. Sequence traces captured in logs.
- Responses to abnormal situations:
  - Overflow: exceed maximum managed counts (thermostats, humidistats, contact sensors, power switches) and confirm graceful rejection and messaging without data corruption.
  - Communication facilities: simulate loss and restoration of Internet or wireless links; verify queued or retried operations per design or clear failures with user-visible messages; ensure no stale state is silently accepted.
  - Hardware faults and failures: simulate unreachable sensors/controllers; verify timeouts, degraded-mode behavior, and user notification.
  - Error handling and recovery: trigger server restart during operations; verify resumption without losing last committed configuration and plan data after recovery.
- Effect of parameters:
  - Confirm that unit selection (Fahrenheit/Celsius) affects display and input interpretation consistently across UI and APIs.
- Relationship of outputs to inputs:
  - Input/output sequences: validate that a control request yields the corresponding device state change and that subsequent reads reflect it.
  - Formulas: [N/A]

Thermostat control (temperature)
- Methods: inspection, analysis, test, simulation.
- Input validity checks:
  - Accept only setpoints 60–80 °F inclusive in 1-degree increments; reject out-of-range or non-integer values with clear messages.
  - Validate placement constraints: one thermostat per enclosed space; attempts to register duplicates are rejected.
- Exact sequence of operations:
  - Verify that manual changes remain effective until the end of the current planned or default time period, after which planned/default settings take effect.
  - Confirm independent and collective control of up to eight thermostats, ensuring group operations do not alter unrelated thermostats.
  - Confirm that wireless communication from thermostat to master control is established before state changes are persisted.
- Responses to abnormal situations:
  - Overflow: attempt to add a ninth thermostat; verify rejection and stability.
  - Communication: simulate loss of wireless connectivity; verify user notification and that stale values are not displayed as current.
  - Hardware faults: simulate sensor failure (no temperature reading); verify fallback behavior and error messages.
  - Error handling and recovery: after system recovery, verify last planned schedules and setpoints are restored from backup.
- Effect of parameters:
  - Verify that setpoint changes alter HVAC control outputs consistent with setpoint and schedule priority rules.
  - Verify Fahrenheit/Celsius support produces consistent behavior when switching units.
- Relationship of outputs to inputs:
  - Input/output sequences: setpoint request leads to controller command then observed device response and updated UI in correct order.
  - Formulas: [N/A]

Humidistat control (humidity)
- Methods: inspection, analysis, test, simulation.
- Input validity checks:
  - Accept only setpoints 30–60% inclusive in 1% increments; reject others with clear messages.
  - Enforce one humidistat per enclosed space.
- Exact sequence of operations:
  - Verify scheduling of up to twenty-four one-hour settings per day for each day of the week.
  - Confirm manual changes persist until the end of the current planned or default time period, then planned/default resumes.
- Responses to abnormal situations:
  - Overflow: attempt to register more than eight humidistats; verify rejection.
  - Communication: simulate intermittent wireless; verify retries or errors without silent failures.
  - Hardware faults: simulate sensor providing no humidity data; verify notification.
  - Error handling and recovery: verify restoration of humidity schedules post-restart from latest backup.
- Effect of parameters:
  - Confirm setpoint changes drive humidifier/dehumidifier control as specified.
- Relationship of outputs to inputs:
  - Input/output sequences: verify request → command → actuator response → state confirmation ordering.
  - Formulas: [N/A]

Security system (contact sensors and alarms)
- Methods: inspection, analysis, test, simulation.
- Input validity checks:
  - Validate contact sensor registration up to fifty; reject duplicates and malformed IDs.
  - Ensure alarm subsystem configuration accepts exactly one sound alarm and one light alarm subsystem with multiple lights; reject unsupported configurations.
- Exact sequence of operations:
  - Verify that when a security breach occurs and a contact sensor is set OPEN, the alarm system is activated, and corresponding notifications/logs are recorded before UI update.
- Responses to abnormal situations:
  - Overflow: attempt to add a fifty-first contact sensor; verify rejection.
  - Communication: simulate contact state changes during gateway outage; verify missed events are handled per design (queued or logged as unavailable) and users are notified.
  - Hardware faults: simulate alarm device failure; verify detection and error reporting.
  - Error handling and recovery: verify that after recovery, alarm states are consistent and breach logs are intact from last backup.
- Effect of parameters:
  - Confirm that enabling/disabling sensors within plans affects breach detection accordingly.
- Relationship of outputs to inputs:
  - Input/output sequences: OPEN event → alarm activation → event logging → UI/report update.
  - Formulas: [N/A]

Appliance and lighting management (power switches)
- Methods: inspection, analysis, test, simulation.
- Input validity checks:
  - Accept control only for registered power switches up to one hundred; validate switch ratings as configured; reject invalid IDs.
- Exact sequence of operations:
  - Verify that state-change commands transition OFF↔ON and that the resulting state is reported back and persisted.
  - Confirm manual changes at the device remain in effect until the end of the current planned or default time period, after which planned/default resumes.
- Responses to abnormal situations:
  - Overflow: attempt to register 101st switch; verify rejection.
  - Communication: simulate missed acknowledgements; verify retry or error propagation to user.
  - Hardware faults: simulate switch failing to change state; verify discrepancy detection and messaging.
  - Error handling and recovery: confirm restoration of last planned state after recovery.
- Effect of parameters:
  - Confirm plan parameters directly affect ON/OFF outcomes at scheduled times and that overrides take precedence as specified.
- Relationship of outputs to inputs:
  - Input/output sequences: user command → switch actuation → state confirmation → UI update.
  - Formulas: [N/A]

Planning and reporting
- Methods: inspection, analysis, test, simulation.
- Input validity checks:
  - Validate month plan creation/modification for up to four daily time periods per day and correct parameter domains per device type; reject overlaps or invalid time ranges.
  - Validate report request dates limited to the past two years.
- Exact sequence of operations:
  - Verify plan evaluation at scheduled boundaries, with correct precedence: manual override until the end of the current time period, then planned/default resumes.
  - Confirm report generation compiles daily average, maximum (with time), and minimum (with time) for each thermostat and humidistat; includes breach times and system downtime periods.
- Responses to abnormal situations:
  - Overflow: attempt more than four daily time periods; verify rejection and message.
  - Communication: simulate missing sensor data intervals; verify reports indicate gaps without fabricating readings.
  - Hardware faults: simulate system downtime; verify downtime periods are captured and reported.
  - Error handling and recovery: simulate crash during report generation; verify safe retry and no partial or corrupted output persists.
- Effect of parameters:
  - Verify that changing planned values changes subsequent device behavior at the next scheduled boundary, without retroactive effects.
- Relationship of outputs to inputs:
  - Input/output sequences: plan definition → schedule execution → device state changes → data collection → reporting pipeline.
  - Formulas: [N/A]

Backup, recovery, and exception handling (functional responses to abnormal situations)
- Methods: inspection, analysis, test, demonstration.
- Input validity checks:
  - Validate technician-configured backup time is accepted only in valid formats; reject invalid times.
- Exact sequence of operations:
  - Verify daily backups occur at configured time; on failure events (power loss, internet loss, software/hardware failure), recovery restores configuration, default parameter settings, planning, and usage data from the most recent backup before resuming normal operation.
- Responses to abnormal situations:
  - Overflow: [N/A]
  - Communication: simulate backup attempts during network outages; verify local fallback or error recording.
  - Hardware faults: simulate storage failure; verify error reporting and that the system continues safe operation without claiming a successful backup.
  - Error handling and recovery: verify all operations present clear, descriptive messages to users upon errors and exceptions.
- Effect of parameters:
  - Confirm that backup schedule parameter affects when backups occur.
- Relationship of outputs to inputs:
  - Input/output sequences: backup initiation → data capture → persistence → verification → status reporting.
  - Formulas: [N/A]

## 4.2 Performance requirements

This subsection defines how the performance requirements will be verified. Tests will be executed in the simulated home environment described for the prototype (simulated sensors/controllers with realistic physical constraints). Unless otherwise stated, tests pass if all measured values meet or exceed the stated numerical limits with no violations observed during the test window.

- Static (capacity) verification
  - Thermostats supported (up to 8)
    - Method: Configure 8 thermostats; stream simulated temperature at 10 Hz; exercise independent and collective control and scheduling.
    - Evidence: All 8 appear in UI and API, accept settings, and maintain required dynamic update rates without loss.
  - Humidistats supported (up to 8)
    - Method: Configure 8 humidistats; stream simulated humidity at 10 Hz; exercise control and scheduling.
    - Evidence: All 8 appear in UI and API, accept settings, and maintain required dynamic update rates without loss.
  - Door/window contact sensors supported (up to 50)
    - Method: Register 50 contacts; generate open/close events; verify alarm integration.
    - Evidence: All 50 report state changes; no missed events at specified display/update rates.
  - Power switches supported (up to 100)
    - Method: Register 100 switches; toggle states according to plans and manual commands.
    - Evidence: All 100 report and change state reliably; no backlog; required display/update rates maintained.
  - Per-device scheduling capacity (thermostats/humidistats: up to 24 one-hour settings per day)
    - Method: Populate all 24 hourly entries for each device across a full week; persist, reload, and simulate a full day rollover.
    - Evidence: All entries saved, reloaded, and applied at scheduled times.
  - Planner capacity (up to 4 daily time periods per day in a month plan)
    - Method: Create a month plan with 4 periods per day; persist, reload; simulate day transitions.
    - Evidence: All periods applied and traceable in logs for the full month.
  - Reporting history (up to 2 years)
    - Method: Preload database with 24 months of synthetic telemetry and events; generate month reports for multiple months.
    - Evidence: Reports include specified aggregates and sections for the requested past months without timeouts or omissions.
  - Wireless/communication range (up to 1000 ft indoors; devices must be within 1000 ft of the master control)
    - Method: In simulation, vary device “distance” parameter; test at and around 1000 ft boundary.
    - Evidence: Communication succeeds at ≤1000 ft and fails/degrades in a defined manner beyond 1000 ft.
  - Number of terminals to be supported
    - [N/A]
  - Number of simultaneous users to be supported
    - [N/A]
  - Amount/type of information to be handled
    - Method: Use full-capacity device set streaming temperature, humidity, contact, and power-state data per requirements; sustain for test window.
    - Evidence: No data loss; storage and retrieval support planner and reporting features as specified.

- Dynamic performance verification
  - Display update interval for environmental conditions (≤ 2 s)
    - Method: With the system loaded to full device capacity and sensors streaming at required rates, measure UI and API output timestamps over a continuous 30-minute window under normal and peak simulated activity.
    - Acceptance: No display/update interval exceeds 2.0 seconds for any monitored temperature, humidity, contact sensor, or power switch.
  - Sensor data acquisition rate (≥ 10 Hz per sensor)
    - Method: For each sensor type, inject timestamped samples at 10 Hz; instrument ingestion timestamps end-to-end.
    - Acceptance: Effective per-sensor acquisition rate is ≥ 10.0 samples/second with no gaps or reordering beyond one sample interval.
  - End-to-end stability at capacity
    - Method: Run a 60-minute soak with maximum configured devices, full scheduling activity, continuous sensor streaming at 10 Hz, and frequent user interactions (view dashboards, issue control commands).
    - Acceptance: All dynamic limits above are met for the entire duration; no missed schedule triggers; no backlog accumulation.

- Test environment and instrumentation
  - Environment: Simulated home, simulated sensors/controllers, DH home web server, and DH Gateway as per operational constraints.
  - Instrumentation: Timestamped logs at data source, gateway, server, and UI; automated probes to compute intervals and rates; reproducible data sets.
  - Pass/fail reporting: For each item above, provide measured min/avg/max, violation count (must be zero unless otherwise noted), and test artifacts.

## 4.3 Usability requirements

This SRS does not define an explicit set of usability and quality-in-use requirements (see 3.3). Therefore, verification will focus on usability-related items explicitly specified elsewhere in the SRS. Where measurable effectiveness, efficiency, satisfaction criteria, or explicit avoidance-of-harm-in-use objectives are not stated, they are marked as [N/A].

- Effectiveness
  - Planned verification approach:
    - Reviews and walkthroughs (IEEE 1028) of user interface flows for the tasks the General User is expected to perform via the DH website (e.g., log in/log out, browse pages, submit requests) and for core operations specified in the functional requirements (read/set thermostat and humidistat values; schedule settings; override planned values; read/change appliance power state; use the monthly planner; retrieve monthly reports; trigger and observe security alarms).
    - V&V activities (IEEE 1012) to confirm that the Master User and DH Technician can perform configuration and operation tasks granted to their roles.
  - Measurable criteria: [N/A]

- Efficiency
  - Planned verification approach:
    - [N/A] (No usability-specific efficiency criteria are defined; note that display update frequency is specified as a performance requirement, not a usability criterion.)
  - Measurable criteria: [N/A]

- Satisfaction
  - Planned verification approach: [N/A]
  - Measurable criteria: [N/A]

- Avoidance of harm in use
  - Planned verification approach:
    - Test that clear, descriptive error/exception messages are presented to users when errors or exceptional conditions occur, as required (5.2.3), via reviews (IEEE 1028) and tests (IEEE 1012, IEEE 1008).
    - Demonstrate that security alarms are activated upon a security breach (4.4.2), supporting safe use.
    - Verify backup and recovery mechanisms (5.2.2.1–5.2.2.2) to reduce risk of harmful outcomes from loss of operation or data.
  - Measurable criteria: [N/A]

- Contexts of use and accessibility of the interface
  - Planned verification approach:
    - Demonstrate that a web-ready computer, cell phone, or PDA can be used to operate the system via the DH website as specified (4.1.1).
  - Measurable criteria: [N/A]

- User support and learnability
  - Planned verification approach:
    - Review online user documentation for completeness and required content (FAQ, parameter setting and sensor reading explanations including limitations, planner usage) per 5.7.1.1–5.7.1.3 through document reviews and audits (IEEE 1028).
    - Confirm that all user documentation is up-to-date and archived per business rules (5.6.1).
  - Measurable criteria: [N/A]

- Error prevention and recovery feedback
  - Planned verification approach:
    - Inspect the user interface to confirm presence of clear, descriptive messages for error and exceptional conditions (5.2.3) using review checklists (IEEE 1028) and targeted test scenarios (IEEE 1012, IEEE 1008).
  - Measurable criteria: [N/A]

- Process and standards conformance supporting usability
  - Planned verification approach:
    - Confirm use of the referenced standards for reviews and audits (IEEE 1028), V&V (IEEE 1012), and unit testing (IEEE 1008) as part of the project’s verification evidence (5.5.1.3).
  - Measurable criteria: [N/A]

## 4.5 Logical database requirements

This subsection defines the verification approaches and methods for the logical database requirements, organized in parallel with the information items a)–g).

- a) Types of information used by various functions
  - Verification approach:
    - Requirements and schema review to confirm presence of data structures for:
      - User accounts and roles (Master user, DH Technician, General user) per 3.2.1.4, 3.2.2.4, 5.4.1–5.4.2.
      - Devices and configuration (thermostats, humidistats, contact sensors, alarms, power switches, gateway) per 3.4.3–3.4.4, 4.1.4, 4.2–4.5.
      - Sensor readings and controller setpoints (temperature, humidity, contact OPEN/CLOSED, power OFF/ON) per 4.1.5–4.1.6, 4.2.1.1–4.2.1.2, 4.3.1.1–4.3.1.2, 4.5.3–4.5.4.
      - Planning data (monthly plan; up to four daily time periods; per-parameter targets) and overrides per 4.6.1–4.6.2.2.
      - Security events and alarm activations per 4.4.2, 4.6.3.2.
      - System operation status for downtime reporting per 4.6.3.3.
      - Backup and recovery metadata per 5.2.2.1–5.2.2.2.
    - Functional tests (create/read/update/delete) through the DH web server (4.1.2) to validate each data category can be persisted and retrieved as required.
    - Negative tests to confirm restricted items (e.g., configuration settings) cannot be altered by unauthorized roles (3.2.1.4, 3.2.2.4).

- b) Frequency of use
  - Verification approach:
    - Performance testing with simulated sensor inputs at ≥10 Hz per sensor (5.1.2) and UI refresh at ≤2 s (5.1.1), verifying sustained database write/read throughput without data loss.
    - Workload tests for planning and reporting operations representative of monthly use (4.6.2–4.6.3), verifying query execution completes within acceptable time bounds. Specific target latencies: [N/A].

- c) Accessing capabilities
  - Verification approach:
    - End-to-end tests via the DH web server (4.1.2) to confirm:
      - Users can read current values and historical readings; set controller values (4.1.5–4.1.6, 4.2.1, 4.3.1, 4.5.1–4.5.4).
      - Creation and modification of monthly plans and per-day time periods (4.6.1–4.6.2.1); submission of overrides and correct persistence until the end of the planned/default period (4.6.2.2).
      - Generation of month reports for any month in the past two years (4.6.3–4.6.3.3).
      - Technician-configured backup time is stored and used by the system (5.2.2.1).
    - API and database interface tests to ensure required query/filter capabilities (by device, time range, day/period, event type) are supported. Additional access modes: [N/A].

- d) Data entities and their relationships
  - Verification approach:
    - Schema inspection to confirm entities and referential links inferred from requirements exist, including:
      - Home, UserAccount (with role), Device (Thermostat, Humidistat, ContactSensor, PowerSwitch, Alarm, Gateway) (3.4.3–3.4.4, 3.2, 4.1.4).
      - Reading (TemperatureReading, HumidityReading, ContactState, PowerState) linked to Device with timestamps (4.1.5, 4.2.1.1, 4.3.1.1, 4.5.3).
      - ControllerSetting/Setpoint linked to Device and time period (4.1.6, 4.2.1.2, 4.3.1.2).
      - MonthlyPlan linked to Home and composed of up to four PlanPeriods per day with parameter targets (4.6.1–4.6.2.1).
      - Override linked to affected parameter and period (4.6.2.2).
      - SecurityEvent linked to ContactSensor and Alarm activation time (4.4.2, 4.6.3.2).
      - SystemDowntime intervals (4.6.3.3).
      - BackupJob and BackupInstance linked to Home (5.2.2.1–5.2.2.2).
    - Referential integrity tests:
      - Reject readings/settings referencing non-existent devices.
      - Prevent orphan plan periods; ensure cascade rules behave as intended.
      - Verify one-to-many and composition constraints through insertion and deletion scenarios.
    - Any additional entities/relationships not derivable from the SRS: [N/A].

- e) Integrity constraints
  - Verification approach:
    - Boundary and negative tests on persisted values:
      - Temperature setpoints accepted only in 60–80 °F inclusive, 1 ° increments; Celsius support verified for equivalence (4.2.1.2, 4.2.4).
      - Humidity setpoints accepted only in 30–60% inclusive, 1% increments (4.3.1.2).
      - Power state values restricted to OFF/ON; contact sensor states restricted to OPEN/CLOSED; alarm states as specified (4.5.3–4.5.4, 4.4.1–4.4.2).
      - Thermostat sensor values recorded within device sensitivity range where applicable (14 °F to 104 °F) or flagged per design (3.4.4.1.c). Handling beyond-range readings: [N/A].
    - Cardinality limits enforced:
      - Max 8 thermostats (4.2.2), 8 humidistats (4.3.2), 50 contact sensors (4.4.1.1), 100 power switches (4.5.2); attempts to exceed are rejected.
    - Scheduling constraints:
      - Thermostat/humidistat schedules up to 24 one-hour settings per day (4.2.2.3, 4.3.2.3).
      - Monthly planner: up to four time periods per day (4.6.2.1).
      - Manual overrides persist until end of current planned/default period (4.2.2.4, 4.3.2.2, 4.5.5, 4.6.2.2).
    - Time integrity:
      - All readings and events carry timestamps; min/max with time appear in reports (4.6.3.1).
    - Error handling messages validated per 5.2.3 when constraints are violated.

- f) Security
  - Verification approach:
    - Authentication and session control:
      - Confirm that access to database-backed functions requires login with account name and password (5.4.2) and that user accounts exist (5.4.1).
    - Transport security:
      - Verify all web interactions that transmit or retrieve database-resident information use TLS or equivalent per 5.4.1.
    - Authorization:
      - Role-based tests to ensure only Master users and DH Technicians can perform configuration data changes (e.g., system parameters, user accounts), and General users are limited to monitor/control per their rights (3.2.1.4, 3.2.2.4).
    - Database at-rest encryption and direct database access controls: [N/A].

- g) Data retention requirements
  - Verification approach:
    - Reporting data horizon:
      - Seed data across >24 months and confirm reports can be generated for any month and year in the past two years (4.6.3–4.6.3.3); define behavior for data older than two years: [N/A].
    - Backup and recovery:
      - Configure daily backups at a technician-specified time; verify backup execution and contents daily (5.2.2.1).
      - Induce failure scenarios (power loss, loss of internet access, software/hardware fault) and validate recovery restores configuration, default parameter settings, planning, and usage data from the most recent backup (5.2.2.2).
    - Retention duration and storage location/policy for backups beyond functional recovery: [N/A].

## 4.6 Design constraints

- Compliance with HVAC standards (ASHRAE 2010)
  - Verification methods: architecture/design review for conformance to ASHRAE guidance; compatibility assessment of supported centralized HVAC types (gas, oil, electricity, solar, combinations) against stated requirements; test evidence from simulated integration showing correct thermostat control behavior across supported systems.

- Use of recognized security technology for authentication and encryption (e.g., TLS)
  - Verification methods: configuration and code inspection confirming use of a recognized protocol (certificate presence, cipher suites); network trace analysis to verify TLS session establishment and encrypted credential exchange; security test of login flow to ensure no plaintext credentials are transmitted.

- Adoption of IEEE and corporate engineering standards (IEEE 830, 1008, 1016, 1028; HO4710; HO2305)
  - Verification methods: process and artifact audits to check:
    - Requirements specification compliance with IEEE 830 and HO2305 format.
    - Design description compliance with IEEE 1016; UML 2.0 modeling present as mandated by business rules.
    - Review records and procedures aligned to IEEE 1028.
    - Unit test plans and execution aligned to IEEE 1008.
    - Code reviews against HomeOwner Coding Standard HO4710 (with review logs or static analysis reports).

- Mandated development approach (object-oriented with UML 2.0)
  - Verification methods: design artifact inspection to confirm UML 2.0 models (class, sequence, state) exist and trace to implementation; peer review checklists confirming OO principles (abstraction, information hiding, module independence) are applied.

- Corporate development process usage (HomeOwner Inc. process)
  - Verification methods: process compliance audits at milestones; review of required process deliverables and approvals; traceable checklists indicating each prescribed activity completed.

- Prototype scope and simulated environment only
  - Verification methods: test environment review confirming all devices are simulated; simulation model validation against stated physical properties and constraints; test reports demonstrating end-to-end scenarios executed entirely within the simulator; configuration management records showing no physical device dependencies.

- Use of widely used, accepted, available technologies and standards; cost minimization
  - Verification methods: technology selection review with justification and market availability evidence; procurement and design BoM review; final cost comparison report (as required) examined for competitive alternatives and minimization rationale.

- Operational environment constraints (broadband ISP; home web server; gateway with RF module)
  - Verification methods: deployment diagram and configuration inspection confirming ISP dependency and home server role; integration test in the lab/testbed demonstrating gateway RF communication with simulated sensors/controllers; inspection of gateway design/BOM for RF module presence and broadband connectivity.

- Maintainability and future incorporation into a commercial version
  - Verification methods: architecture review for modularity and clear interfaces; code and design inspections for abstraction and information hiding; maintainability checklist outcomes; evidence that modules can be integrated without refactoring beyond interface contracts.

- Documentation and archival requirements (HO2305 format; placement in HomeOwner Document Archive)
  - Verification methods: document format checks; archive completeness review at project closeout; inventory of delivered artifacts matched to required set (SRS, design, code, test plans).

- Schedule and team-size limitations
  - Verification methods: management reviews of milestone attainment and resource plans; traceable project reports confirming adherence.

## 4.7 Software system attributes

This section defines the verification approaches and methods to qualify the software system attributes. All verification will be performed in the simulated environment defined for the prototype.

### Reliability
- Failure rate target (no more than 1 failure per 10,000 operating hours):
  - Method: long-duration reliability demonstration in the simulated environment using an agreed operational profile; log all failures; estimate MTBF from observed failure data and project to confirm the target is met. If full-time demonstration is infeasible, use statistical projection from accelerated and continuous operation runs.
- Backup creation (daily, technician-configurable time):
  - Method: configuration inspection and timed functional test; verify backup schedule can be set; confirm backup artifacts are produced at the configured time with complete data (configuration, default parameter settings, planning, usage data).
- Recovery after failure (power loss, loss of Internet access, other software/hardware failures):
  - Method: fault-injection tests for each failure mode; verify system restarts and restores all relevant data from the most recent backup; verify normal operations resume without manual data repair.
- Exception handling (clear, descriptive user messages on errors/exceptional conditions):
  - Method: systematic negative testing and fault injection across UI and services (e.g., network down, device offline, invalid inputs); review and observe user-facing messages for clarity and specificity; verify no unhandled exceptions are exposed to users.

### Availability
- Defined availability level: [N/A]
- Restart/recovery capability:
  - Method: verified under Reliability (backup and recovery tests) to demonstrate system can restart and recover to an operational state after defined failures.

### Security
- Account creation at installation:
  - Method: installation test; confirm a DigitalHome user account is established as specified.
- Authentication (account name and password required):
  - Method: functional tests for successful login; negative tests for incorrect credentials and unauthorized access attempts; verify no access is granted without proper authentication.
- Information encryption using a recognized reliable and effective security technology (e.g., TLS):
  - Method: configuration inspection and network traffic analysis during authentication and session use; verify encryption is active end-to-end; verify certificates/keys are correctly applied.
- Role-based access to configuration (Master User and DH Technician vs. General User):
  - Method: authorization tests exercising configuration functions (e.g., establishing accounts, setting system parameters, starting/stopping the system); verify access is denied to General Users and allowed to Master User/DH Technician as specified.

### Maintainability
- Documentation of requirements, design, code; use of HomeOwner document format; documents archived:
  - Method: document reviews at milestones; checklist-based conformance to [HO2305]; final audit to confirm all required artifacts are present and stored in the HomeOwner Document Archive.
- Use of abstraction, information hiding, module independence in design:
  - Method: design reviews of architecture and detailed design; static analysis and code inspection for coupling/cohesion indicators; verify interfaces are well-defined and hide implementation details.
- Use of IEEE and HomeOwner standards (IEEE830, IEEE1008, IEEE1016, IEEE1028, HO4710):
  - Method: process and artifact compliance audits; unit test plan/reports reviewed against IEEE1008; design descriptions reviewed against IEEE1016; reviews/audits conducted per IEEE1028; source code style and practices checked against HO4710.
- Object-oriented development with UML 2.0 (exceptions require CIO approval):
  - Method: artifact inspection of UML 2.0 models (use case, class, sequence, etc.); verify OO principles applied; verify any deviations have documented CIO approval.
- Prototype modules suitable for incorporation into a commercial version:
  - Method: architecture and code reviews to confirm modularity, stable interfaces, and low host-specific coupling; verify absence of prototype-only shortcuts in shared components or presence of isolation and clear TODO annotations for replacement.

### Portability
- Host-dependent elements and constraints: [N/A]
- Target operating systems, compilers/language subsets: [N/A]
- Proven portable language requirement: [N/A]

### Safety
- Explicit safety attributes: [N/A]
- Indirect qualification:
  - Method: rely on Reliability and Security verification and functional tests for security alarms, lighting control, and environmental control to mitigate the safety concerns described (e.g., prompt alarm activation on breaches; adequate control of lighting and environmental set points).

## 5.1 Assumptions and dependencies

- Availability of a broadband Internet Service Provider for the home (e.g., cable modem or high-speed DSL) to enable remote access and communications.
- Installation and operation of a DH Gateway device connected to the home’s broadband network, equipped with an RF module that provides wireless communication within up to 1000 feet indoors.
- Presence and compatibility of physical devices with the DH wireless gateway, including:
  - Programmable thermostats and humidistats,
  - Door/window magnetic contact sensors,
  - Security sound and light alarms,
  - Programmable power switches (115V, 10A).
- Existence of a DH web server environment, either:
  - A home-hosted DH Home Web Server on a home computer providing device interaction, data storage, user account management, and backups, or
  - The DigitalHome web server hosting the user’s personal web interface.
- The prototype operates entirely in a simulated environment with no physical home; the simulator adheres to realistic physical properties and constraints of actual homes and devices.
- Users possess and can use web-ready devices (computer, cell phone, or PDA) and are familiar with basic web operations (login/logout, browsing, submitting requests).
- A designated Master User and a trained DH Technician are available to configure the system (establish user accounts, set default parameters, set backup schedules) and to start/stop system operation.
- The home has a compatible centralized HVAC system (gas, oil, electricity, solar, or combinations), and HVAC-related operation adheres to ASHRAE standards.
- Household electrical infrastructure supports the specified power switches (115V, 10A) for appliances and lighting.
- The number of field devices to be managed does not exceed the stated maxima (up to eight thermostats, eight humidistats, fifty contact sensors, one sound alarm, one light alarm subsystem with multiple lights, and up to one hundred power switches).
- Environmental conditions at sensor locations remain within stated sensor operating ranges (e.g., thermostat sensor sensitivity between 14°F and 104°F).
- A persistent “home database” exists to store configuration, plans, and usage data; storage capacity is sufficient to:
  - Retain up to the past two years of data for reporting, and
  - Perform and retain daily backups of configuration, default parameter settings, planning, and usage data.
- Availability and correct configuration of Transport Layer Security to provide authentication and encryption for the DH web system.
- Sensors and controllers support the required minimum data acquisition rate (10 Hz) and can reliably communicate wirelessly with the gateway within the specified range.
- Physical placement and home layout allow one thermostat or humidistat per enclosed space as assumed by the control and scheduling requirements.

## 5.2 Acronyms and abbreviations

The following acronyms and abbreviations are used. Where available, definitions are drawn from Section 6 Glossary and the References.

- ANSI — [N/A]
- ASHRAE — American Society of Heating, Refrigerating and Air-Conditioning Engineers
- CIO — [N/A]
- DH — Digital Home; the name of the prototype smart home product produced by DigitalHomeOwner
- DSL — Digital Subscriber Line; a family of technologies that provides digital data transmission over the wires of a local telephone network
- FAQ — Frequently Asked Question
- HLRD — Digital Home High Level Requirements Definition
- HVAC — Heating, Ventilation and Air Conditioning
- IEEE — Institute of Electrical and Electronics Engineers, Inc.
- ISP — Internet Service Provider
- PDA — Personal Digital Assistant
- RF — Radio Frequency
- SRS — Software Requirements Specification
- UML — [N/A]