## 1.1 Purpose

The DigitalHome (DH) software is a prototype smart-home management system whose purpose is to enable home residents to remotely monitor and control key home functions—environmental conditions (temperature and humidity), security (door/window contact sensors and alarms), and power to small appliances and lighting—through a web interface via a home web server and a wireless gateway communicating with sensors and controllers.

This prototype operates in a simulated home environment and focuses on the principal features needed to demonstrate feasibility. It is intended to support HomeOwner Inc. in evaluating capabilities and making business decisions about future commercial development of DigitalHome products and services.

## 1.2 Scope

This SRS defines the scope of the DigitalHome (DH) prototype smart home management software to be produced by the DigitalHomeOwner Division of HomeOwner Inc. The prototype is based on the Digital Home High Level Requirements Definition [HLRD 2010] and will operate in a simulated home environment (no physical home; all sensors and controllers are simulated). It will be used by HomeOwner management to make business decisions about future commercial development of DigitalHome products and services.

- Software products to be produced
  - DigitalHome System (prototype)
  - DH home web server providing user web pages, interaction with and control of DH elements, storage of DH plans and data, user account management, and backup of user and system data
  - Thermostat and humidistat management services
  - DigitalHome security system management (door/window contact sensors, light and sound alarms)
  - Appliance Manager for power switches (including lighting units)
  - DigitalHome Planner (monthly scheduler)
  - Reporting function (monthly reports)

- What the software will do
  - Allow a user, via a web‑ready device (computer, cell phone, PDA), to monitor and control:
    - Temperature (thermostats; Fahrenheit and Celsius supported)
    - Humidity (humidistats)
    - Security (up to fifty contact sensors; activation of one sound and one light alarm subsystem with multiple lights)
    - Power to small appliances and lighting units (up to one hundred power switches; read and change OFF/ON state)
  - Schedule and manage environmental settings using a monthly planner (for each day, up to four daily time periods; up to 24 one‑hour settings per day for thermostats and humidistats)
  - Allow manual overrides that persist until the next planned or default time period
  - Collect, store, and report usage and environmental data (monthly reports for the past two years, including temperature/humidity statistics, security breach times, and system downtime)
  - Provide user authentication and information encryption, and daily backup and recovery of configuration, defaults, planning, and usage data
  - Communicate with simulated home devices via the DH Gateway using wireless signals

- Application, benefits, objectives, and goals
  - Application: residential home environment management through a centralized web-accessible system
  - Benefits: improved convenience, security, and environmental/energy management through remote monitoring, control, planning, and reporting
  - Objectives/goals: demonstrate and validate core capabilities for managing temperature, humidity, security contacts/alarms, and power to small appliances and lighting; provide planning and reporting to inform future product decisions; employ widely used, accepted technologies and operate within a realistic simulated environment

- Scope limitations
  - The prototype scope is limited to managing temperature, humidity, security contacts/alarms, and power to small appliances and lighting units through a web interface
  - All device interactions occur in a simulated environment
  - Entertainment and communications beyond these functions are out of scope for this prototype

This scope is consistent with higher-level descriptions in [HLRD 2010] and the Digital Home Use Case Model [HO2010].

### 1.3.1 Product perspective

DigitalHome (DH) is a prototype smart-home management subsystem that integrates household devices (HVAC, humidifiers/dehumidifiers, entry sensors, alarms, small appliances and lighting) with sensors/controllers, a home wireless gateway, and a DH home web server. Users access the system via a personal web page hosted either on a DH home web server (preferred and required as the communication center) or on a DigitalHome web server. DH relies on a broadband Internet Service Provider (ISP) for remote access. All physical devices may be simulated in the prototype environment.

At a high level, the major elements and interconnections are:
- User web-ready device (computer, cell phone, PDA) ↔ ISP/Internet ↔ DH home web server (or DigitalHome web server) ↔ DH home wireless gateway ↔ wireless sensors and controllers (thermostats, humidistats, magnetic contact switches, power switches, security alarms) ↔ household systems (e.g., centralized HVAC, small appliances, lighting).
- DH home web server ↔ home database (plans, configuration, sensor/usage data) with daily backups and recovery.

The DH product is the software that runs the DH home web server (and associated data) to monitor, plan, and control the home environment. It interfaces upward to users (web UI) and outward to the ISP and, through the gateway, downward to in-home devices.

#### System interfaces

- User device ↔ DH web server
  - Functionality: Authenticate users; display current conditions (temperature, humidity, contact status, power state); accept control inputs (setpoints, on/off); support planning (monthly schedules) and reporting (monthly summaries); provide online documentation.
  - Interface description: Web-based interaction over an authenticated, encrypted session (e.g., TLS). Message content includes user credentials, commands (setpoints, switch states), and query responses (sensor readings, reports). Message formats: [N/A].

- DH web server ↔ DH home wireless gateway
  - Functionality: Dispatch controller values (temperature/humidity setpoints, switch on/off); receive sensor values and contact events; maintain device association/configuration.
  - Interface description: Local network connection to the gateway, which bridges to in-home RF communications. Message types include sensor readings (≥10 Hz acquisition capability) and actuator commands. Protocols and formats: [N/A].

- DH gateway ↔ sensors/controllers (thermostats, humidistats, contact sensors, alarms, power switches)
  - Functionality: Wireless transport of sensor measurements and control commands within up to 1000 feet indoors.
  - Interface description: RF wireless; device addressing and pairing: [N/A]; protocol/encoding: [N/A].

- DH web server ↔ home database
  - Functionality: Persist configuration, default parameter settings, plans, sensor histories, and usage data; support daily backup and recovery.
  - Interface description: Data schema and storage technology: [N/A].

- DH web server ↔ ISP/Internet (for remote access)
  - Functionality: Provide remote user access to the DH web UI.
  - Interface description: Broadband Internet connectivity via widely available ISP (e.g., cable modem, high-speed DSL). Ports/protocols: [N/A].

#### User interfaces

- Web user interface accessible from a web-ready computer, cell phone, or PDA.
- Capabilities:
  - Authentication (account name and password) with encrypted sessions (e.g., TLS).
  - Real-time monitoring views for temperature, humidity, contact sensor status, and power switch states, updated at least every two seconds.
  - Control views to set thermostat and humidistat setpoints, and switch appliances/lights on/off; support both individual and collective control (e.g., per room).
  - Planning interface: monthly planner allowing up to four daily time periods per day with parameter settings for each controlled element.
  - Reporting interface: monthly reports (daily average/min/max with times for temperature/humidity per device; security breach date/time; DH system downtime periods for the past two years).
  - Online user documentation, including FAQ, parameter-setting guidance/limitations, and planner usage.
- UI style guide: [N/A].

#### Hardware interfaces

- DH home wireless gateway:
  - RF module for wireless communication with in-home devices; indoor range up to 1000 feet.
  - Broadband Internet connection to the ISP.
  - Ports/instruction sets/configuration details: [N/A].

- Supported device types and capacities:
  - Thermostats: up to 8; one per enclosed space; schedule up to 24 one-hour settings per day; manual override valid until next period.
  - Humidistats: up to 8; one per enclosed space; schedule up to 24 one-hour settings per day; manual override valid until next period.
  - Contact sensors (doors/windows): up to 50; OPEN state triggers alarm.
  - Security alarms: one sound alarm and one light alarm subsystem (multiple lights).
  - Power switches: up to 100 at 115V, 10A; report OFF/ON; remotely change state; manual override valid until next period.
  - Centralized HVAC compatibility: gas, oil, electricity, solar, or combinations; adheres to ASHRAE standards.

- Physical connectors, power requirements, device protocols: [N/A].

#### Software interfaces

- Web browser
  - Name/mnemonic/spec/version/source: [N/A].
  - Purpose: Access the DH web UI for monitoring, control, planning, reporting, and documentation.
  - Interface definition: Standard web interactions; specific message formats: [N/A].

- Transport Layer Security
  - Name: Transport Layer Security; Mnemonic: TLS; Specification number: [N/A]; Version: [N/A]; Source: [N/A].
  - Purpose: Provide encrypted, authenticated sessions for user access.
  - Interface definition: Use of a recognized security technology (e.g., TLS); detailed profiles: [N/A].

- Home database
  - Name/mnemonic/spec/version/source: [N/A].
  - Purpose: Persist configuration, plans, sensor and usage data; support backup/recovery.
  - Interface definition: Data model, APIs, and formats: [N/A].

- Operating system and middleware requirements: [N/A].
- Interfaces with other application systems: [N/A].

#### Communications interfaces

- Broadband ISP connectivity (e.g., cable modem, high-speed DSL) for remote web access.
- Local RF wireless between the gateway and in-home devices; protocol details: [N/A].
- Network protocols/ports for web access (e.g., HTTPS over TLS): [N/A].

#### Memory constraints

- Primary and secondary memory characteristics and limits: [N/A].

#### Operations

- Modes of operation:
  - User-initiated interactive operation via web UI (monitor/control/planning/reporting).
  - Unattended scheduled operation via monthly planner (up to four time periods per day) controlling temperature, humidity, contact sensor arming, and power switches.
  - Manual device overrides (thermostats, humidistats, power switches) remain in effect until the next planned/default period.
  - Technician operations: system setup, configuration changes (parameters, user accounts), and starting/stopping DH system operation.

- Data processing support:
  - Acquisition of sensor data (minimum 10 Hz), storage in the home database.
  - Monthly report generation for the past two years.

- Backup and recovery:
  - Daily backup of all system data (configuration, defaults, planning, usage) at a time set during system setup by the DH Technician.
  - Recovery restores from the most recent backup after failures (power loss, loss of Internet, software/hardware failure).
  - Exception handling provides clear, descriptive user messages on errors or exceptional conditions.

#### Site adaptation requirements

- Site-specific initialization/configuration:
  - Definition of home spaces and placement of devices (thermostats, humidistats, contact sensors, power switches, alarms).
  - Default parameter settings (temperature units and ranges; humidity ranges).
  - User accounts and roles (General User, Master User).
  - Backup schedule time set at system setup by the DH Technician.
  - ISP selection and broadband connectivity setup.
  - Device counts and identifiers (up to specified maxima) and association with rooms/zones.

- Mission/site features to be modified per installation: [N/A] beyond the above.

#### Interfaces with services

- Internet Service Provider (ISP): required for broadband connectivity enabling remote access.
- Optional hosting on a DigitalHome web server for the user’s personal web page (as an alternative to a local home server); service characteristics: [N/A].
- Cloud/SaaS dependencies beyond the above: [N/A].

### 1.3.2 Product functions

- Remote access and user interaction
  - Provide web-based access from a computer, cell phone, or PDA to monitor and control the home’s temperature, humidity, lights, security, and small appliances.
  - Authenticate users via account name and password with secure (e.g., TLS) communication.
  - Support roles: General User; Master User (can change configuration and accounts); DH Technician (can set system parameters, establish user accounts, and start/stop the system).

- System orchestration and device communications
  - Use a DH home web server as the communication center to interact with home devices and systems.
  - Communicate via a home gateway using wireless RF to read sensor values and send controller commands.
  - Store plans and sensor/controller data in a home database and provide backup services for accounts, plans, and data.

- Temperature management (thermostats)
  - Monitor room temperature at thermostat locations; display in Fahrenheit and Celsius.
  - Control set points remotely (within specified range and increments).
  - Support up to eight thermostats; control individually or collectively by space.
  - Schedule up to twenty-four one-hour settings per day for each day of the week.
  - Allow manual overrides that persist until the next planned or default period.

- Humidity management (humidistats)
  - Monitor relative humidity at humidistat locations.
  - Control humidity set points remotely (within specified range and increments).
  - Support up to eight humidistats, one per controlled space.
  - Schedule up to twenty-four one-hour settings per day for each day of the week.
  - Allow manual overrides that persist until the next planned or default period.

- Security monitoring and alarms
  - Manage up to fifty door and window contact sensors.
  - Detect security breaches (e.g., contact set to OPEN) and activate alarms.
  - Control a security alarm subsystem with one sound alarm and multiple lights.

- Appliance and lighting management
  - Manage up to one hundred power switches for small appliances and lighting.
  - Monitor switch state (OFF/ON) and change state remotely.
  - Respect manual overrides until the next planned or default period.

- Planning and scheduling
  - Provide a monthly planner.
  - For a selected month and year, define for each day up to four daily time periods specifying temperature, humidity, security contact status, and appliance/light on/off settings.
  - Permit overrides via the website or device manual controls.

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

- Data management, backup, and recovery
  - Perform daily backups of configuration, default settings, planning, and usage data (backup time set during setup).
  - Restore the most recent backup after failures such as power loss or loss of Internet access.

- Online user support
  - Provide online user documentation, including FAQs, explanations of parameter setting and sensor reading limitations, and guidance for using the planner.

### 1.3.3 User characteristics

DigitalHome serves household residents and support personnel who interact primarily through a web interface on a web-ready device (computer, cell phone, or PDA).

- General users (household residents)
  - Role and tasks: Monitor and control temperature, humidity, lights, security, and small appliances.
  - Domain knowledge: Familiar with their home’s layout and the locations of sensors and control devices.
  - Technical expertise: Not familiar with DH technical features; capable of basic web operations (log in/out, browse pages, submit requests).
  - Experience: Basic web literacy; routine interaction with simple web-based controls.
  - Educational level: [N/A]
  - Disabilities/accessibility needs: [N/A]

- Master user (designated household administrator)
  - Role and tasks: All general user activities plus configuration (e.g., add user accounts, change default parameters) and start/stop system operation.
  - Technical expertise: Not specified beyond ability to perform administrative tasks; possesses the same system rights as a DH Technician for configuration.
  - Experience: General user experience plus routine administrative use of DH configuration features.
  - Educational level: [N/A]
  - Disabilities/accessibility needs: [N/A]

- DigitalHome Technician (support personnel)
  - Role and tasks: System setup, configuration, and maintenance; establish user accounts; set system parameters; start/stop system operation.
  - 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; formal product-specific training.
  - Educational level: [N/A]
  - Disabilities/accessibility needs: [N/A]

### 1.3.4 Limitations

- a) Regulatory requirements and policies
  - Must adhere to ASHRAE standards, policies, and procedures for HVAC.
  - Use IEEE standards [IEEE830, IEEE1008, IEEE1012, IEEE1016, IEEE1028] and HomeOwner Coding Standard [HO4710]; documentation must follow HomeOwner format [HO2305].
  - Object-oriented development using UML 2.0 is designated by HomeOwner; exceptions require CIO approval.
  - The development process is that specified by HomeOwner Inc.; major SRS changes require approval by the DigitalHomeOwner Director.
  - Preference for widely used, accepted, and available hardware/software technologies; costs should be minimized.

- b) Hardware limitations
  - Wireless communication range up to 1000 feet indoors; sensors/controllers must be within 1000 feet of the master control (gateway).
  - Gateway contains an RF module and connects to broadband Internet.
  - Power switches: up to 100 units, 115V, 10A.
  - Thermostats: up to 8 units; sensor sensitivity 14°F to 104°F; setpoints limited to 60°F–80°F (1°F increments).
  - Humidistats: up to 8 units; setpoints limited to 30%–60% RH (1% increments).
  - Security contacts: up to 50 door/window sensors; one sound alarm subsystem and one light alarm subsystem with multiple lights.
  - HVAC compatibility limited to centralized systems (gas, oil, electricity, solar, or combinations).
  - Home requires a broadband ISP.

- c) Interfaces to other applications
  - [N/A]

- d) Parallel operation
  - [N/A]

- e) Audit functions
  - Daily system data backups (configuration, defaults, planning, usage) with technician-set backup time; recovery restores from most recent backup after failures.
  - Monthly reports include, per month:
    - Daily average, max (with time), and min (with time) for temperature and humidity per device.
    - Day/time of security breaches (alarm activations).
    - Periods when the DH system was not in operation.

- f) Control functions
  - Scope limited to monitoring and controlling temperature, humidity, security contacts/alarms, and appliance/light power (ON/OFF).
  - Scheduling limits:
    - Thermostat/humidistat: up to 24 one-hour settings per day for each device.
    - Planner: up to four daily time periods per day in a monthly plan.
  - Manual overrides persist only until the end of the current planned/default time period.
  - Master User/DH Technician can configure system parameters, establish user accounts, and start/stop system operation.

- g) Higher-order language requirements
  - [N/A]

- h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK)
  - [N/A]

- i) Quality requirements
  - Reliability target: no more than 1 failure per 10,000 hours of operation.
  - Performance: environmental displays updated at least every 2 seconds; sensor data acquisition minimum 10 Hz.
  - Exception handling must provide clear, descriptive user messages.
  - Backup and recovery mechanisms required.

- j) Criticality of the application
  - Although a prototype, failures can impact safety and well-being (e.g., security breaches, inadequate lighting, inappropriate temperature/humidity), necessitating high reliability.

- k) Safety and security considerations
  - User authentication required (account name and password).
  - Information security via a recognized technology such as Transport Layer Security.
  - Security system activates alarms upon contact sensor breaches.

- l) Physical/mental considerations
  - General users are non-technical and only familiar with basic web operations; they rely on a simple web interface and knowledge of home layout.
  - A Master User is designated for configuration tasks beyond general user capability.

- m) Limitations sourced from other systems (including real-time interface requirements)
  - Dependence on availability and performance of a broadband ISP for remote access.
  - Real-time constraints from device interfaces: ≥10 Hz sensor acquisition and ≤2-second display update cadence.
  - Prototype operates in a simulated environment with simulated sensors/controllers; no physical home is present.

## 1.4 Definitions

- ASHRAE: American Society of Heating, Refrigerating and Air-Conditioning Engineers.
- Authentication: A process that verifies a person is who they claim to be, typically by submitting and verifying a username and password.
- Broadband Internet: High data rate Internet access, contrasted with slower dial-up access.
- DH (DigitalHome): The prototype smart home product produced by DigitalHomeOwner.
- DigitalHomeOwner: The division of HomeOwner Inc. responsible for producing DigitalHome products.
- DSL (Digital Subscriber Line): A family of technologies that provides digital data transmission over the wires of a local telephone network.
- Encryption: The process of transforming information (plaintext) using an algorithm (cipher) to make it unreadable to anyone except those possessing a key.
- FAQ: Frequently Asked Question.
- Gateway Device: A home networking device used to connect devices in the home to the Internet or other Wide Area Networks.
- HomeOwner Inc.: The largest national retail chain serving the needs of home owners in building, furnishing, repairing, and improving their homes.
- HVAC: Heating, Ventilation and Air Conditioning.
- Humidistat: An instrument that measures and controls relative humidity.
- ISP: Internet Service Provider.
- PDA: Personal Digital Assistant.
- RF: Radio Frequency.
- Security Breach: An external act that bypasses or contravenes the DigitalHome security system (e.g., opening a door when the contact sensor is set to on).
- Set Point: A numeric value that establishes the desired value of an environmental quality (e.g., a temperature value of 70°F).
- SRS: Software Requirements Specification.
- Transport Layer Security: Cryptographic protocols that provide security for communications over networks such as the Internet.
- DH Home Web Server: An individual home web server 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 service.
- DH Gateway Device: The master control device that connects to the home’s broadband Internet connection and uses wireless communication (via an RF module) to send and receive communications with DH sensors and controllers; operates up to a 1000-foot indoor range.
- General User: A DH user who can monitor and control the home environment, is familiar with the home layout and device locations, and can use a web interface to perform basic operations.
- Master User: A designated user who can change system configuration (e.g., add user accounts, change default parameter settings) and has the same rights as a DH Technician.
- DigitalHome Technician (DH Technician): A role responsible for setting up and maintaining DH system configuration; experienced with relevant hardware, software, and web services; specially trained by DigitalHomeOwner; has rights beyond the general user to set system parameters, establish user accounts, and start/stop DH system operation.
- DigitalHome Planner: The capability that lets a user direct the system to apply preset home parameters (temperature, humidity, security contacts, and appliance/light on/off status) for specified time periods; includes a monthly planner with up to four daily time periods and supports overrides via the DH website or manual device switches.
- Appliance Manager: The capability that manages small appliances and lighting via power switches, providing the ability to report and change a switch’s state (off/on); manual state changes persist until the end of the planned or default time period.

# 2 References

## Compliance

- American Society of Heating, Refrigerating and Air-Conditioning Engineers (website)
  - Report number: [N/A]
  - Date: October 2010 (accessed)
  - Publishing organization: American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE)
  - Source: http://www.ashrae.org/
- IEEE Recommended Practice for Software Requirements Specifications
  - Report number: IEEE Std 830-1998
  - Date: 1998
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc.
  - Source: Institute of Electrical and Electronics Engineers, Inc.
- IEEE Standard for Software Unit Testing
  - Report number: ANSI/IEEE Std 1008-1987
  - Date: 1987
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc.
  - Source: Institute of Electrical and Electronics Engineers, Inc.
- 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.
  - Source: Institute of Electrical and Electronics Engineers, Inc.
- IEEE Standard for Software Reviews and Audits
  - Report number: IEEE Std 1028-2008
  - Date: 2008
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc.
  - Source: Institute of Electrical and Electronics Engineers, Inc.
- Guidelines for Developing HomeOwner Technical Reports
  - Report number: HO2305
  - Date: March 2002
  - Publishing organization: HomeOwner Inc.
  - Source: HomeOwner Inc.
- HomeOwner Coding Standard
  - Report number: HO4710
  - Date: August 2009
  - Publishing organization: HomeOwner Inc.
  - Source: HomeOwner Inc.

## Guidance

- Digital Home High Level Requirements Definition
  - Report number: [N/A]
  - Date: September 2010
  - Publishing organization: HomeOwner Inc.
  - Source: HomeOwner Inc.
- Digital Home Use Case Model
  - Report number: [N/A]
  - Date: October 24, 2010
  - Publishing organization: HomeOwner Inc., DigitalHomeOwner Division
  - Source: HomeOwner Inc., DigitalHomeOwner Division
- IEEE Standard for Software Verification and Validation
  - Report number: IEEE Std 1012-2004
  - Date: 2004
  - Publishing organization: Institute of Electrical and Electronics Engineers, Inc.
  - Source: Institute of Electrical and Electronics Engineers, Inc.
- 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 inputs from authenticated users and in-home devices, processes those inputs through the DH home web server and gateway, and produces outputs to device controllers, alarms, data storage, and user-facing displays and reports. The following sub-functions describe inputs, processing sequences, outputs, input validity, abnormal-condition handling, parameter effects, and input/output relationships.

- Access and session control
  - Inputs:
    - Account name and password.
  - Processing sequence:
    1) Receive credentials via the DH web interface.
    2) Authenticate the user; provide encryption through a recognized security technology.
  - Outputs:
    - Authorized access to monitoring and control capabilities, or an error message on failure.

- Sensor monitoring and data acquisition
  - Inputs:
    - Wireless sensor readings: temperature, humidity, contact sensor state, power switch state.
  - Processing sequence:
    1) Acquire sensor data at a minimum rate of 10 Hz via the gateway within the specified wireless range.
    2) Store readings in the home database.
    3) Update user displays of environmental conditions at least every two seconds.
  - Outputs:
    - Persisted sensor data and refreshed displays.

- Thermostat monitoring and control
  - Inputs:
    - Current temperature at each thermostat.
    - User-set thermostat setpoints.
    - Scheduled setpoints (up to 24 one-hour settings per day per thermostat).
  - Processing sequence:
    1) Read current temperature at each thermostat location.
    2) Determine the active setpoint from either the schedule, default, or a manual override.
    3) Validate requested setpoint is within 60 °F to 80 °F, inclusive, at one-degree increments.
    4) If valid, send controller values via wireless to achieve the setpoint; otherwise, reject and notify the user.
    5) Apply manual settings until the end of the current planned or default time period, then revert to planned/default settings.
  - Outputs:
    - Controller commands to heating/cooling devices and updated temperature displays.
  - Additional characteristics:
    - Up to eight thermostats; may be controlled individually or collectively.
    - Fahrenheit and Celsius values are supported.
    - Thermostat sensor sensitivity range: 14 °F to 104 °F.

- Humidistat monitoring and control
  - Inputs:
    - Current humidity at each humidistat.
    - User-set humidity setpoints.
    - Scheduled setpoints (up to 24 one-hour settings per day per humidistat).
  - Processing sequence:
    1) Read current humidity.
    2) Determine the active setpoint from schedule, default, or manual override.
    3) Validate requested setpoint is within 30% to 60%, inclusive, at 1% increments.
    4) If valid, send controller values via wireless to achieve the setpoint; otherwise, reject and notify the user.
    5) Apply manual settings until the end of the current planned or default time period, then revert to planned/default settings.
  - Outputs:
    - Controller commands to humidifier/dehumidifier devices and updated humidity displays.
  - Additional characteristics:
    - Up to eight humidistats; one per enclosed space.

- Security monitoring and alarm activation
  - Inputs:
    - Door/window contact sensor states.
  - Processing sequence:
    1) Monitor up to fifty contact sensors.
    2) When a security breach occurs and a contact sensor is set OPEN, activate the alarm system.
  - Outputs:
    - Activation of one sound alarm and one light alarm subsystem (with multiple lights) and recording of breach time.

- Appliance and lighting power management
  - Inputs:
    - Power switch states (OFF/ON).
    - User commands to change state.
    - Planned states from the planner.
  - Processing sequence:
    1) Monitor the current state of up to one hundred 115V, 10A power switches.
    2) On valid user or planned command, change a switch state (OFF to ON, or ON to OFF).
    3) If a device is changed manually, retain that state until the end of the current planned or default time period, then revert to planned/default settings.
  - Outputs:
    - Power switch state changes and updated status displays.

- Planning and scheduling
  - Inputs:
    - Monthly plan for a given month and year specifying, for each day, up to four daily time periods and associated parameter settings (temperature, humidity, contact sensors, and power switches).
  - Processing sequence:
    1) Store or modify the monthly plan.
    2) At the start of each defined time period, apply the planned parameter settings to the relevant devices and sensors.
    3) Permit user overrides via the website or device manual controls; overrides persist until the end of the current time period.
  - Outputs:
    - Time-based application of temperature, humidity, security contact states, and power switch states.

- Reporting
  - Inputs:
    - Stored sensor and system operation data for the past two years.
  - Processing sequence:
    1) For a requested month and year, compute per device:
       - Daily average, maximum (with time), and minimum (with time) values of temperature and humidity for each thermostat and humidistat, respectively.
    2) Retrieve the day and time of any security breaches (alarm activations).
    3) Identify periods when the DH System was not in operation.
  - Outputs:
    - Monthly report containing the computed statistics, breach times, and downtime periods.

- Configuration and system control
  - Inputs:
    - Technician or Master User actions to set system parameters, establish user accounts, and start/stop system operation.
  - Processing sequence:
    1) Apply configuration changes.
    2) Start or stop DH System operation as requested.
  - Outputs:
    - Updated configuration, user accounts, and system operational state.

Input validity checks

- Authentication:
  - Log in requires entry of an account name and a password.
- Thermostat setpoints:
  - Must be within 60 °F to 80 °F, inclusive, at one-degree increments.
- Humidistat setpoints:
  - Must be within 30% to 60%, inclusive, at 1% increments.
- Scheduling limits:
  - Thermostat/humidistat: up to twenty-four one-hour settings per day per device.
  - Planner: up to four daily time periods per day per month plan.
- Device counts:
  - Thermostats: up to eight.
  - Humidistats: up to eight.
  - Contact sensors: up to fifty.
  - Power switches: up to one hundred.
- Communication range:
  - Environmental sensors and controllers must be within 1000 feet of the master control (gateway) device.

Responses to abnormal situations

- Overflow
  - [N/A]
- Communication facilities
  - If the DH System fails due to loss of internet access, recovery shall restore system data from the most recent backup when the system is restored.
- Hardware faults and failures
  - If the DH System fails due to power loss or other hardware or software failure, recovery shall restore configuration, default parameter settings, planning, and usage data from the most recent backup.
- Error handling and recovery
  - All operations shall incorporate exception handling that responds with a clear, descriptive message when an error or exceptional condition occurs.
  - System data are backed up daily at a technician-configured time; on recovery, the most recent backup is restored.

Effect of parameters

- Temperature and humidity setpoints:
  - Control signals are sent to heating/cooling and humidifying/dehumidifying devices to achieve and maintain the active setpoints.
  - Manual overrides supersede planned/default settings until the end of the current time period, after which planned/default values take effect.
- Planner-defined states:
  - Planned values determine device behavior during specified time periods for temperature, humidity, contact sensors, and power switches.
- Unit system:
  - The system supports Fahrenheit and Celsius temperature values.

Relationship of outputs to inputs

- Input/output sequences
  - User credentials → authentication check → grant or deny access with message.
  - Sensor readings → acquisition and storage → display refresh at least every two seconds.
  - Thermostat setpoint request → range/increment validation → send controller values → updated device state and displays; reject with message if invalid.
  - Humidistat setpoint request → range/increment validation → send controller values → updated device state and displays; reject with message if invalid.
  - Scheduled period start → apply planned settings → device commands issued → displays and states updated.
  - Manual device change during a period → maintain manual state until period end → revert to planned/default at next period.
  - Contact sensor OPEN (breach) → activate sound and light alarms → log day and time.
  - Monthly report request (month/year within past two years) → compute specified statistics and retrieve events → generate report.
  - System failure (power/internet/software/hardware) → on recovery, restore most recent backup → record downtime for reporting.
- Formulas for input to output conversion
  - [N/A]

## 3.2 Performance requirements

- Static (capacity) requirements
  - Supported device counts
    - Thermostats: up to 8 per home.
    - Humidistats: up to 8 per home.
    - Door/window contact sensors: up to 50 per home.
    - Power switches (115 V, 10 A): up to 100 per home.
    - Alarms: one sound alarm and one light alarm subsystem (with multiple lights).
  - Planning and scheduling data
    - Thermostat schedules: up to 24 one-hour settings per day per thermostat.
    - Humidistat schedules: up to 24 one-hour settings per day per humidistat.
    - Monthly planner: up to 4 daily time periods per day.
  - Reporting/history
    - Monthly reports available for any month in the past 2 years.
  - Number of terminals to be supported: [N/A]
  - Number of simultaneous users to be supported: [N/A]
  - Amount of information to be handled (storage/throughput): [N/A]

- Dynamic performance requirements
  - Display refresh
    - Environmental condition displays (temperature, humidity, contact sensors, power switches) shall be updated at least every 2 seconds.
  - Data acquisition
    - Sensor data acquisition rate (temperature, humidity, contact state, power state) shall be at least 10 Hz.
  - Wireless communication range
    - To maintain communication, each environmental sensor or controller device shall be within 1000 feet of the master control (gateway) device for indoor transmission.
  - Backup frequency
    - System data (configuration, default parameter settings, planning, and usage data) shall be backed up daily at a technician-configured time.
  - Normal/peak transaction volumes and processing times: [N/A]
  - Command/actuation latency: [N/A]
  - Report generation time: [N/A]
  - Performance under simultaneous web sessions: [N/A]

## 3.3 Usability requirements

- Contexts of use
  - General users shall operate the system via a web interface and are assumed to be familiar with basic web operations (logging in/out, browsing, submitting information and requests).
  - A Master User and a DH Technician may perform configuration and administration tasks.
  - The system shall be usable from a web-ready computer, cell phone, or PDA, through a personal web page on the DigitalHome web server (or local home server).

- Effectiveness (quality in use)
  - The system shall allow users to monitor and control home temperature, humidity, lights, security, and the state of small appliances through the web interface.
  - Users shall be able to read sensor values and set controller values relevant to their home environment.
  - The system shall support both Fahrenheit and Celsius temperature values.
  - Users shall be able to override planned parameter values through the DH website (and, if available, via manual device switches).
  - Measurable effectiveness criteria: [N/A]

- Efficiency (quality in use)
  - Displays of environmental conditions (temperature, humidity, contact sensors, power switches) shall be updated at least every two seconds.
  - Sensor data (temperature, humidity, contact sensor, power state) shall have a minimum acquisition rate of 10 Hz to support timely UI updates.
  - Measurable task-time or productivity criteria: [N/A]

- Error prevention, feedback, and recovery
  - All operations shall provide clear, descriptive messages to users when an error or exceptional condition occurs.
  - The system shall incorporate backup and recovery mechanisms to restore configuration, default parameter settings, planning, and usage data from the most recent backup if a failure occurs.
  - User documentation shall be available online and include:
    - An FAQ section about use and maintenance (e.g., password changes, support).
    - Explanations of how parameters are set and how sensor values are read, including limitations and accuracy.
    - Instructions for using the DH Planner.

- Satisfaction
  - Explicit measurable satisfaction targets (e.g., user satisfaction scores): [N/A]

- Avoidance of harm (freedom from risk in use)
  - High system reliability is required to help ensure user requests are carried out without failure, reducing risks such as security breaches, inadequate lighting, inappropriate temperature/humidity, or unintended powering of appliances when children are present.
  - Specific measurable harm-avoidance/usability risk criteria: [N/A]

- Accessibility and inclusivity
  - Accessibility requirements (e.g., support for assistive technologies, contrast, localization beyond temperature units): [N/A]

## 3.5 Logical database requirements

a) Types of information used by various functions
- User accounts and roles: account name, password credential, role (General User, Master User, DH Technician).
- Device registry and configuration: device type (thermostat, humidistat, contact sensor, power switch, sound alarm, light alarm), identifier, location/space, default parameter settings, capability ranges.
- Environmental schedules and plans:
  - Monthly planner: for each month/year, per day up to four daily time periods, desired parameter settings (temperature, humidity, contact sensors armed state, power switch on/off).
  - Per-device schedules: for each thermostat and humidistat, up to twenty-four one-hour settings per day.
- Sensor readings and device states: temperature readings, humidity readings, contact sensor state (open/closed), power switch state (off/on), with timestamps and device association.
- Security events: security breaches with day and time.
- System operation status: periods when the DH System was not in operation.
- Backup configuration: daily backup time set by the DH Technician; backup scope (configuration, default parameter settings, planning, usage data).

b) Frequency of use
- Sensor data acquisition/write: minimum 10 Hz for temperature, humidity, contact sensor, and power state.
- Data display/read: updates at least every two seconds for environmental conditions.
- Planning data read/write: on demand when users create or modify month plans and per-device schedules.
- Reporting read: on demand for any month/year within the past two years.
- Backup write: daily at a configured time.

c) Accessing capabilities
- Access is via the DH home web server:
  - Authenticated users can read current and historical environmental data and device states.
  - Authenticated users can create/modify month plans (planner) and per-device schedules.
  - Master User and DH Technician can establish and maintain user accounts, set default parameters, and change system configuration.
- Queries shall support:
  - Time-based retrieval (by time range, day, month, year) for sensor data and events.
  - Device-based retrieval (by device or device type).
  - Computation or retrieval of daily averages, minima/maxima with times for temperature and humidity.
  - Retrieval of security breach timestamps and system downtime periods.

d) Data entities and their relationships
- UserAccount — has one Role; may create/modify MonthPlans and per-device schedules.
- Role — values: General User, Master User, DH Technician.
- Home — hosts Devices; has MonthPlans; has BackupConfiguration.
- Device (abstract) — specialized as Thermostat, Humidistat, ContactSensor, PowerSwitch, SoundAlarm, LightAlarm; each Device is located in one Space/Room.
- Space/Room — contains zero or more Devices.
- Thermostat — has ThermostatSchedule (per-day one-hour settings); produces TemperatureReadings.
- Humidistat — has HumidistatSchedule (per-day one-hour settings); produces HumidityReadings.
- ContactSensor — produces ContactEvents (open/closed with timestamps).
- PowerSwitch — has state changes (on/off with timestamps).
- MonthPlan — for a specific month/year; contains DayPlans; each DayPlan has up to four TimePeriodSettings (temperature, humidity, contact sensor arming, power switch states).
- SecurityBreachEvent — linked to one or more ContactSensors; stored with timestamp.
- SystemOperationInterval — indicates system up/down periods with start/end timestamps.
- BackupConfiguration — stores daily backup time and scope.

e) Integrity constraints
- Temperature setpoints: 60°F to 80°F inclusive, in 1-degree increments; system supports both Fahrenheit and Celsius values.
- Humidity setpoints: 30% to 60% inclusive, in 1% increments.
- Thermostat sensor reading capability: 14°F to 104°F.
- Per-device scheduling:
  - ThermostatSchedule and HumidistatSchedule: up to 24 one-hour settings per day per device.
- Monthly planner:
  - MonthPlan: for each day, up to four daily time periods with parameter settings.
- Device population limits per home:
  - Up to eight thermostats.
  - Up to eight humidistats.
  - Up to fifty door/window contact sensors.
  - Up to one hundred 115V, 10A power switches.
  - One sound alarm subsystem and one light alarm subsystem (with multiple lights).
- Enumerated states:
  - ContactSensor: OPEN or CLOSED.
  - PowerSwitch: OFF or ON.
- Manual overrides:
  - For thermostat, humidistat, and power switch devices, a manual setting/state change remains in effect until the end of the planned or default time period; the database shall support representing the effective setting accordingly.

f) Security
- Authentication: login requires account name and password.
- Communication security: information encryption via a recognized technology such as Transport Layer Security when accessing the DH web system.
- Authorization: role-based access control aligned with user roles (e.g., only Master User or DH Technician may establish user accounts and change configuration/default parameters).

g) Data retention requirements
- The system shall retain data necessary to generate month reports for any month and year within the past two years, including:
  - Daily average, maximum (with time), and minimum (with time) values for temperature and humidity per thermostat and humidistat.
  - Day and time of any security breaches.
  - Periods when the DH System was not in operation.
- Backups of all system data (configuration, default parameter settings, planning, and usage data) shall be performed daily at the configured time.

## 3.6 Design constraints

- External standards and compliance
  - HVAC-related functions shall adhere to the standards, policies, and procedures of the American Society of Heating, Refrigerating and Air-Conditioning Engineers [ASHRAE 2010].
  - Authentication and information encryption shall use a recognized, reliable security technology such as Transport Layer Security (TLS).
  - Development and documentation shall conform to HomeOwner and IEEE standards: HomeOwner Coding Standard [HO4710], HomeOwner document format [HO2305], and IEEE standards [IEEE830, IEEE1008, IEEE1016, IEEE1028]. Object-oriented development using UML 2.0 is designated as the preferred method; exceptions require CIO approval.
  - The development process specified by DigitalHomeOwner Inc. shall be used.

- Project limitations
  - The prototype version must be completed within twelve months of inception.
  - The development team will consist of five engineers (with management/communication support from the DigitalHomeOwner Director).
  - Where possible, widely used, accepted, and available hardware/software technologies and standards shall be employed.
  - Costs of DigitalHome elements (sensors, controllers, server, tools, etc.) shall be minimized; cost comparisons with competitive elements shall be provided in the final report.
  - The system shall be developed and tested in a simulated environment; there will be no physical home and all sensors/controllers will be simulated. The simulation must be realistic and adhere to physical properties and constraints of an actual home and real devices.
  - Major changes to requirements must be approved by the Director of the DigitalHomeOwner Division.

- Environmental and external interface constraints
  - The home system requires a broadband Internet Service Provider (e.g., cable modem or high-speed DSL).
  - The DH Gateway device shall include an RF module to communicate wirelessly with DigitalHome devices and shall connect to a broadband Internet connection.
  - Wireless operation shall support up to a 1000-foot indoor range; environmental sensors and controller devices must be within 1000 feet of the master control device.

## 3.7 Software system attributes

### Reliability
- 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.
- 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.
- Upon failure (including power loss, loss of internet access, or other software or hardware failure), the system recovery mechanism shall restore system data from the most recent backup.
- All operations shall incorporate exception handling so that the system responds to a user with a clear, descriptive message when an error or an exceptional condition occurs.

### Availability
- [N/A] Target availability level (e.g., uptime percentage) is not specified.
- The system shall provide daily backups and recovery to restore operation from the most recent backup.
- [N/A] Checkpointing and automatic restart procedures are not specified.
- [N/A] Redundancy and failover requirements are not specified.
- The system shall require an Internet Service Provider; availability is contingent on broadband connectivity.

### Security
- The system shall establish a DigitalHome user account upon installation.
- The system shall require authentication; login shall require entry of an account name and a password.
- The system shall provide authentication and information encryption using a recognized security technology, such as Transport Layer Security.
- Authorization shall reflect user roles: a Master User and a DH Technician shall have rights beyond a General User, including configuration and operational controls.
- [N/A] Security logging and audit trail requirements are not specified.
- [N/A] Module-level segregation to enforce least privilege (beyond role distinctions) is not specified.
- [N/A] Restrictions on inter-module communications are not specified.
- [N/A] Data integrity checks for critical variables are not specified.
- [N/A] Data privacy at rest requirements are not specified.

### Maintainability
- The system development shall include documentation of requirements, design, and code.
- The design shall employ abstraction, information hiding, and module independence.
- The project shall use IEEE standards [IEEE830, IEEE1008, IEEE1016, IEEE1028] and the HomeOwner Coding Standard [HO4710].
- HomeOwner designates object-oriented development using UML 2.0 as the preferred method; exceptions require CIO approval.
- Although a prototype, all modules and components shall be designed and implemented so they may be incorporated into a fully specified commercial version.
- All system documents shall be up-to-date, use the HomeOwner document format [HO2305], and reside in the HomeOwner Document Archive at project completion.
- [N/A] Quantitative complexity limits and maintainability metrics are not specified.
- [N/A] Interface/API versioning and deprecation policies are not specified.

### Portability
- Where possible, the project shall employ widely used, accepted, and available hardware and software technology and standards for product elements and development tools.
- User access shall be via web-ready devices (computer, cell phone, PDA), implying client-side platform independence for access.
- [N/A] Percentage of elements or code that are host-dependent is not specified.
- [N/A] Specific programming language, compiler, or language subset to ensure portability is not specified.
- [N/A] Target operating systems and portability constraints are not specified.
- [N/A] Build and packaging requirements for multiple platforms are not specified.

## 3.8 Supporting information

This section provides supplemental information to aid understanding. Unless explicitly noted as a requirement elsewhere in Section 3, the items below are not to be considered part of the binding requirements.

- Sample input/output formats
  - [N/A]

- Cost analysis studies and user surveys
  - [N/A]
  - Note: Cost minimization is a project constraint, and comparative pricing is to be documented in the final project report outside this SRS.

- Supporting/background information
  - Product nature and scope:
    - Prototype intended to inform business decisions; functionality limited to environmental control (temperature, humidity), security monitoring, and power control of small appliances and lighting.
    - Operation in a simulated home environment; all sensors and controllers are simulated but must reflect realistic physical properties and constraints.
  - Operational context:
    - Home system requires an ISP (e.g., cable or DSL).
    - Architecture includes a home web server, a wireless gateway, and wireless sensors/controllers (thermostats, humidistats, contact sensors, alarms, power switches).
    - Thermostat compatibility with centralized HVAC; ASHRAE standards referenced.
  - Users and roles:
    - General User (monitors/controls), Master User (configuration rights), and DH Technician (setup, maintenance, start/stop, configuration).
  - Security and reliability posture:
    - Authentication with username/password; communications protected with a recognized protocol such as TLS.
    - Daily backups and recovery from most recent backup; exception handling for clear error messages.
  - Documentation and standards:
    - Use of IEEE and HomeOwner standards for documentation, design, testing, coding; object-oriented development with UML preferred.
    - Online user documentation to include FAQ, parameter setting/reading guidance (including limitations), and planner usage.

- Problems to be solved by the software
  - Enable remote monitoring and control of temperature, humidity, security contacts, and appliance/light power states via web-capable devices.
  - Provide planning/scheduling for environmental settings and device states, including controlled manual overrides.
  - Aggregate and report historical environmental data and security events for specified months within the past two years.
  - Coordinate wireless communication between a home gateway and multiple sensors/controllers across the home.
  - Maintain reliable operation with backup/recovery to prevent loss of configuration, plans, and usage data.

- Special packaging instructions (code/media)
  - [N/A]
  - Related notes:
    - All project documents must follow HomeOwner formats and be archived upon project completion.
    - Initial installation establishes at least one user account; no export-control or media packaging requirements are specified in the source material.

Normative status: The information in this subsection is provided for context and guidance and is not a requirement unless restated as such in Sections 3.1–3.7 of this SRS.

## 4.1 Functions

This section defines the planned verification approaches for the functional capabilities, aligned with the functional areas stated in the requirements. Verification will be performed in the simulated environment described for the prototype, using inspection, analysis, demonstration, and test (including boundary-value, equivalence-partition, and fault-injection techniques). Where the specification does not define formulas or detailed behaviors, the entry is marked [N/A].

- General control and communications (refs: 4.1.1–4.1.6; 3.4.2–3.4.4)
  - Input validity checks
    - Verify only supported device categories (temperature, humidity, lights, security, power switches) are addressable (test).
    - Verify device identifiers and locations correspond to configured devices (inspection/test).
  - Exact sequence of operations
    - Verify that a user command via the DH web server results in: command acceptance on the server, wireless transmission via the Gateway, device action, and persistence of any resulting sensor values in the home database (demonstration/test with log inspection).
  - Responses to abnormal situations
    - Overflow: attempt to register or address devices beyond stated maxima (thermostats ≤8, humidistats ≤8, contact sensors ≤50, power switches ≤100) and verify clear error messages per exception handling (test; refs: 4.2.2, 4.3.2, 4.4.1.1, 4.5.2, 5.2.3).
    - Communication facilities: induce loss of Internet access and loss of RF link and verify user receives clear, descriptive messages; verify no undefined behavior occurs (fault injection test; refs: 3.4.3, 5.2.3).
    - Hardware faults and failures: simulate device unavailability and system power loss; verify backup/restore behavior upon restart per recovery requirement (fault injection test; refs: 5.2.2, 5.2.3).
    - Error handling and recovery: verify all failed commands and data-read attempts return descriptive messages without system crash and that recovery restores most recent backup (test; refs: 5.2.2, 5.2.3).
  - Effect of parameters
    - Verify that configured default parameter settings and user-defined settings influence device control as specified (test/inspection; refs: 3.2.1.4, 5.2.2).
  - Relationship of outputs to inputs
    - Input/output sequences: verify that user inputs through the web interface produce corresponding device actions and updated displays; verify sensor reads are stored (test/demonstration; refs: 4.1.5–4.1.6).
    - Formulas for input to output conversion: [N/A].

- Thermostats (refs: 4.2)
  - Input validity checks
    - Verify setpoint range enforcement 60–80 °F inclusive with 1-degree increments; verify rejection of out-of-range and non-increment inputs with clear messages (boundary-value test; ref: 4.2.1.2, 5.2.3).
    - Verify unit selection supports Fahrenheit and Celsius (test; ref: 4.2.4). Formulas for conversion: [N/A].
  - Exact sequence of operations
    - Verify reading current temperature at a thermostat position and displaying it (test; ref: 4.2.1.1).
    - Verify setting a thermostat remotely results in a control signal to the HVAC via wireless link (demonstration/test; refs: 4.2.1, 4.2.3).
    - Verify scheduled settings (up to 24 one-hour settings/day, per day of week) are applied at the correct times (schedule-driven test; ref: 4.2.2.3).
    - Verify collective vs. individual control operates as specified (test; ref: 4.2.2.1).
    - Verify manual setting persists until end of planned/default period, after which planned/default resumes (temporal sequence test; ref: 4.2.2.4).
  - Responses to abnormal situations
    - Overflow: exceeding 8 thermostats or 24 hourly settings/day is prevented with clear messaging (test; refs: 4.2.2, 4.2.2.3, 5.2.3).
    - Communication facilities/hardware faults: simulate RF link loss; verify clear error and no unintended control; restore and verify normal operation (fault injection test; refs: 4.2.3, 5.2.3).
    - Error handling and recovery: after system failure, verify thermostat plans and defaults are restored from most recent backup (recovery test; ref: 5.2.2).
  - Effect of parameters
    - Verify setpoints and schedules directly determine control signals to achieve the setpoint (functional test; refs: 4.2.1–4.2.2.3).
  - Relationship of outputs to inputs
    - Input/output sequences: verify that input setpoints produce controller commands and status feedback; verify temperature reads update displays (test/demonstration; refs: 4.2.1, 4.2.1.1).
    - Formulas for input to output conversion: [N/A].

- Humidistats (refs: 4.3)
  - Input validity checks
    - Verify humidity setpoint range 30–60% inclusive with 1% increments; verify rejection of out-of-range/non-increment values with clear messages (boundary-value test; refs: 4.3.1.2, 5.2.3).
  - Exact sequence of operations
    - Verify reading humidity and display (test; ref: 4.3.1.1).
    - Verify remote setting results in control actions via wireless (demonstration/test; ref: 4.3.3).
    - Verify scheduling up to 24 hourly settings/day and application at correct times (test; ref: 4.3.2.3).
    - Verify manual setting persists until end of planned/default period (temporal test; ref: 4.3.2.2).
  - Responses to abnormal situations
    - Overflow: exceeding 8 humidistats or 24 hourly settings/day is prevented with clear error messaging (test; refs: 4.3.2, 4.3.2.3, 5.2.3).
    - Communication facilities/hardware faults: simulate link/device failure; verify clear error and recovery (fault injection test; refs: 4.3.3, 5.2.3).
  - Effect of parameters
    - Verify setpoints and schedules determine control actions (functional test; refs: 4.3.1–4.3.2.3).
  - Relationship of outputs to inputs
    - Input/output sequences: verify input setpoints produce controller commands and status feedback (test/demonstration).
    - Formulas for input to output conversion: [N/A].

- Security system (refs: 4.4)
  - Input validity checks
    - Verify contact sensor registration and status values are valid; reject unsupported sensor identifiers with clear messages (test/inspection; refs: 4.4.1, 5.2.3).
  - Exact sequence of operations
    - Verify that when a monitored entry’s contact sensor transitions to OPEN, the system activates one sound alarm and the configured light alarm subsystem (sequence test; refs: 4.4.1.2, 4.4.2).
  - Responses to abnormal situations
    - Overflow: prevent configuration beyond 50 contact sensors with clear messaging (test; ref: 4.4.1.1).
    - Communication facilities/hardware faults: simulate sensor link loss and verify clear notification; verify no spurious alarm without OPEN status (fault injection test; ref: 5.2.3).
  - Effect of parameters
    - Verify any configuration parameters for alarm subsystems take effect (inspection/test; ref: 4.4.1.2).
  - Relationship of outputs to inputs
    - Input/output sequences: verify OPEN input leads to alarm outputs; verify closed state does not (test; refs: 4.4.2).
    - Formulas for input to output conversion: [N/A].

- Appliance management (refs: 4.5)
  - Input validity checks
    - Verify only registered power switches (≤100) are controllable; invalid IDs are rejected with clear messages (boundary test; refs: 4.5.2, 5.2.3).
  - Exact sequence of operations
    - Verify reading current switch state (OFF/ON) and displaying it (test; ref: 4.5.3).
    - Verify changing switch state results in device state change (test/demonstration; ref: 4.5.4).
    - Verify manual change persists until end of planned/default period (temporal test; ref: 4.5.5).
  - Responses to abnormal situations
    - Overflow: attempts to exceed 100 switches are rejected with clear messages (test; ref: 4.5.2).
    - Communication facilities/hardware faults: simulate switch device failure or link loss; verify clear error and no undefined state (fault injection test; ref: 5.2.3).
  - Effect of parameters
    - Verify planned on/off settings and defaults affect device state as scheduled (test; refs: 4.6.1–4.6.2.1).
  - Relationship of outputs to inputs
    - Input/output sequences: verify command inputs produce state changes and status feedback (test; refs: 4.5.3–4.5.4).
    - Formulas for input to output conversion: [N/A].

- Planning and reporting (refs: 4.6)
  - Input validity checks
    - Planner: verify month/year accepted; per-day, up to four daily time periods; reject more than four with clear messages (boundary test; ref: 4.6.2.1).
    - Override: verify both web and manual overrides are accepted (test; ref: 4.6.2.2).
    - Reporting: verify month/year requested is within the past two years; reject older requests with clear message (boundary test; ref: 4.6.3).
  - Exact sequence of operations
    - Verify creation/modification of a month plan persists and is applied by devices at the specified time periods (end-to-end schedule test; ref: 4.6.2.1).
    - Verify override precedence over planned values until end of the period, after which planned/default resumes (temporal precedence test; ref: 4.6.2.2, 4.2.2.4, 4.3.2.2, 4.5.5).
  - Responses to abnormal situations
    - Communication/hardware failures during scheduled actions: simulate failures and verify clear messages, no undefined device state, and correct resumption when service returns (fault injection test; ref: 5.2.3).
    - System downtime: induce downtime and verify reporting includes “periods when the DH System was not in operation” (recovery/report test; ref: 4.6.3.3).
  - Effect of parameters
    - Verify changes to planned parameters (temperature, humidity, contact monitoring, on/off states) produce corresponding device behaviors in the specified periods (end-to-end test; ref: 4.6.1–4.6.2.1).
  - Relationship of outputs to inputs
    - Input/output sequences: verify that plans generate scheduled commands and that reports accurately reflect collected data and events (test; refs: 4.6.3.1–4.6.3.3).
    - Formulas for input to output conversion: [N/A].

- Authentication prerequisite to control (refs: 5.4.1–5.4.2)
  - Input validity checks
    - Verify that login requires account name and password and that unauthenticated requests to control devices are rejected (test/inspection).
  - Exact sequence of operations
    - Verify that authentication occurs before any control or planning action can be submitted (demonstration/test).
  - Responses to abnormal situations
    - Invalid credentials and session failures yield clear, descriptive messages (test; ref: 5.2.3).
  - Effect of parameters
    - Verify that user accounts and permissions affect access to configuration and control (inspection/test; refs: 3.2.1.4, 3.2.2.4).
  - Relationship of outputs to inputs
    - Input/output sequences: verify that successful login enables subsequent functional flows; failed login blocks them (test).
    - Formulas for input to output conversion: [N/A].

## 4.2 Performance requirements

This section defines how the performance requirements in Section 3.2 will be verified. Verification will be performed in the DH simulated home environment described in the SRS, using time-stamped instrumentation, controlled workloads, and repeatable scenarios. Unless otherwise noted, the verification method is test with measurement; supporting analysis and inspection will be used where physical constraints are simulated.

- Display refresh interval (maps to 3.2 Performance requirements: UI updates at least every 2 s)
  - Method: Test and measurement.
  - Setup: Full-capacity device configuration (8 thermostats, 8 humidistats, 50 contact sensors, 100 power switches). Sensors publish data at ≥10 Hz. Typical and peak background activities enabled (planning service active, logging enabled).
  - Procedure: For each displayed environmental condition (temperature, humidity, contact state, power switch state), log the time of successive on-screen value updates over a continuous 60-minute run under both normal and peak workloads.
  - Acceptance: For every displayed item, the inter-update interval shall be ≤ 2.0 seconds for the entire test duration.

- Sensor data acquisition rate (maps to 3.2 Performance requirements: minimum 10 Hz acquisition)
  - Method: Test and measurement.
  - Setup: For each sensor type (temperature, humidity, contact, power state) and for the maximum number of instances, drive simulated sensors to produce time-stamped readings at 10 Hz.
  - Procedure: Measure, per sensor, the number of samples received and stored by the system in each contiguous 1-second window over a 30-minute run; repeat under peak device counts.
  - Acceptance: For every sensor, in every 1-second window, the system shall acquire and persist at least 10 samples (≥10 Hz) with no missed windows.

- Wireless communication range (maps to 3.2 Performance requirements: ≤1000 ft operating range)
  - Method: Test, demonstration, and analysis (RF behavior emulated).
  - Setup: RF propagation emulator configured with indoor attenuation; device positions swept from 200 ft to 1200 ft relative to the Gateway.
  - Procedure: At each distance point, attempt bidirectional command/telemetry exchange and log success, latency, and packet loss.
  - Acceptance: At distances ≤ 1000 ft, the system shall establish and maintain bidirectional communication for all device types; at > 1000 ft, the system shall not maintain communication. Evidence includes successful command acknowledgments and sensor telemetry receipt within the UI refresh constraint.

- Capacity under peak device counts (cross-check that performance holds at maxima stated elsewhere)
  - Method: Test and measurement.
  - Setup: Configure the system with the maximum numbers specified: up to 8 thermostats, 8 humidistats, 50 contact sensors, and 100 power switches; all active concurrently.
  - Procedure: Run combined workloads (scheduled updates, manual overrides, security events) and measure UI refresh intervals and acquisition rates as above.
  - Acceptance: All performance acceptances above (UI ≤ 2 s; acquisition ≥ 10 Hz) shall be met concurrently under peak device counts.

- Static numerical performance: number of terminals supported
  - [N/A]

- Static numerical performance: number of simultaneous users supported
  - [N/A]

- Static numerical performance: amount and type of information to be handled (throughput/volume limits)
  - [N/A]

- Test artifacts and evidence
  - Collected logs of time-stamped sensor ingress, database persistence timestamps, UI update timestamps, and RF emulator configurations will be retained as verification evidence.
  - Any deviations or jitter characteristics observed will be analyzed; acceptance requires full compliance with the stated thresholds.

## 4.3 Usability requirements

This section defines the verification approaches and methods to qualify usability and quality-in-use aspects traceable to the original SRS. Where measurable effectiveness, efficiency, satisfaction criteria, or specific avoidance-of-harm targets are not stated in the SRS, acceptance thresholds are [N/A]. All interactive evaluations will be executed in the simulated home environment specified for testing.

- General user web interaction (3.2.1.1–3.2.1.3; 4.1.1–4.1.6)
  - Methods: scenario-based usability testing and cognitive walkthroughs covering login/logout, browsing, monitoring sensor values, and issuing control actions via the web interface on a web-ready computer, cell phone, and PDA.
  - Participants: representative general users per 3.2.1.3.
  - Environment: DH simulated home; DH web server and gateway in place.
  - Evidence: task scripts, completion logs, observed issues, screen captures.
  - Acceptance criteria: [N/A].

- Role-based configuration by Master User and DH Technician (3.2.1.4; 3.2.2.1–3.2.2.4)
  - Methods: role-specific task testing and guided walkthroughs to add user accounts, set default parameters, start/stop the DH system.
  - Participants: Master User proxy and DH Technician proxy with stated experience/training.
  - Evidence: task completion records, configuration change audit logs.
  - Acceptance criteria: [N/A].

- Planner usability for scheduling and overrides (4.6.1–4.6.2.2)
  - Methods: scenario-based usability testing to create/modify a month plan (up to four daily time periods) and to override planned values via the website; observation of user flow and error recovery.
  - Participants: representative general users.
  - Evidence: saved plans, override logs, observer notes.
  - Acceptance criteria: [N/A].

- Retrieval and comprehension of reports (4.6.3–4.6.3.3)
  - Methods: task-based testing to locate and interpret monthly reports, identify daily average/max/min temperature and humidity per device, and find security breach times and system downtime periods.
  - Participants: representative general users.
  - Evidence: think-aloud notes, artifact reviews, time-stamped user actions.
  - Acceptance criteria: [N/A].

- Error and exception message clarity (5.2.3)
  - Methods: fault injection during typical tasks (e.g., network loss, invalid inputs) to elicit exceptions; heuristic evaluation of message content; user comprehension checks (users restate issue and next steps).
  - Participants: representative general users; usability reviewer.
  - Evidence: list of triggered exceptions, message screenshots, comprehension outcomes.
  - Acceptance criteria: [N/A].

- Discoverability and adequacy of online user documentation (5.7.1–5.7.1.3)
  - Methods: documentation inspection against SRS coverage (FAQ, parameter setting/limitations, planner use); findability tests where users locate answers to example questions (e.g., password change, support).
  - Participants: representative general users.
  - Evidence: inspection checklist results, user task outcomes.
  - Acceptance criteria: [N/A].

- Perceived responsiveness of status displays (supports usability; measured in performance) (5.1.1)
  - Methods: observational confirmation during usability sessions that on-screen environmental conditions refresh without confusing lag; cross-reference to performance verification of 2-second update.
  - Participants: representative general users.
  - Evidence: session recordings; linkage to performance test results.
  - Acceptance criteria: [N/A] for usability perception; timing verified under performance.

- Cross-device usability in stated contexts of use (4.1.1)
  - Methods: repeat key tasks on a web-ready computer, cell phone, and PDA; note any layout or interaction issues preventing task completion.
  - Participants: representative general users.
  - Evidence: per-device task logs and issue lists.
  - Acceptance criteria: [N/A].

- Safety-related usability considerations (5.3.1)
  - Methods: scenario-based evaluation focusing on tasks where misuse could plausibly affect safety (e.g., security arming, lighting control), assessing whether UI labeling and flows help avoid user-induced harm in the simulated environment.
  - Participants: representative general users; safety-aware reviewer.
  - Evidence: scenario outcomes, identified usability risks, mitigation recommendations.
  - Acceptance criteria: [N/A].

- Effectiveness targets (task success rates) [N/A]
  - Verification methods and acceptance thresholds: [N/A].

- Efficiency targets (task times, interaction counts) [N/A]
  - Verification methods and acceptance thresholds: [N/A].

- User satisfaction targets (ratings, SUS or equivalent) [N/A]
  - Verification methods and acceptance thresholds: [N/A].

- Accessibility targets (e.g., assistive technology support, contrast) [N/A]
  - Verification methods and acceptance thresholds: [N/A].

## 4.5 Logical database requirements

This section defines the planned verification approaches and methods for the software’s logical database requirements, aligned with the information items a)–g). All verification will be performed using the simulated environment specified for the prototype.

- a) Types of information used by various functions
  - Method: requirements-to-data-model inspection and traceability review.
    - Trace functions to data: thermostat/humidistat monitoring and control (4.2, 4.3), security events and alarms (4.4), appliance power states (4.5), planning and reporting (4.6), user accounts and configuration (3.2, 5.4), backups and recovery (5.2).
    - Verify the schema or data model contains entities/fields to store: user accounts and roles (General, Master, Technician), device definitions (thermostat, humidistat, contact sensor, power switch, alarms), device placement (room/space), gateway/home, sensor readings (temperature, humidity, contact state, power state), controller settings/setpoints, schedules and plans (up to four periods/day for planning; up to 24 hourly settings/day for device schedules), security breach events (day/time), system operation status periods, and backup sets.
  - Evidence: approved traceability matrix linking each functional requirement to specific data entities/attributes; schema review report.

- b) Frequency of use
  - Method: performance and endurance tests focused on read/write rates implied by requirements.
    - Write throughput: simulate up to 8 thermostats, 8 humidistats, 50 contact sensors, and 100 power switches, each providing data at a minimum acquisition rate of 10 Hz (5.1.2), and verify the database layer persists all incoming data without loss.
    - Read refresh: verify views of environmental conditions update at least every 2 seconds (5.1.1) by reading the latest stored values for all configured devices.
    - Scheduled operations: verify creation/modification of daily/hourly schedules (4.2.2.3, 4.3.2.3) and monthly plans (4.6.2.1) at typical user frequencies.
    - Backup operations: verify daily backup execution at the configured time (5.2.2.1).
  - Pass criteria: no data loss at required acquisition rates; read paths sustain update cadence; scheduled and backup operations complete within their time windows with data persisted.

- c) Accessing capabilities
  - Method: functional tests of CRUD and query capabilities via the application interfaces that exercise the database.
    - Create/Read/Update/Delete: user accounts; device records; schedules/plans; controller setpoints; power switch states; alarm configurations; backup configuration.
    - Queries/Reports: generate monthly reports for any month in the past two years (4.6.3), returning for each thermostat/humidistat the daily average, min (with time), and max (with time) (4.6.3.1); list security breaches with day/time (4.6.3.2); list periods when the system was not in operation (4.6.3.3).
    - Overrides: verify that manual/user overrides are reflected and persisted and that the next planned/default period resumes as specified (4.2.2.4, 4.3.2.2, 4.5.5, 4.6.2.2).
  - Pass criteria: all specified operations succeed with persisted, retrievable results; reports match the simulated input data and timing.

- d) Data entities and their relationships
  - Method: data model review and relational integrity testing.
    - Verify entities and relationships support: Home ↔ Gateway ↔ Devices; Device ↔ Readings (time-stamped); Device ↔ Schedules; User ↔ Accounts/Roles; User/Home ↔ Month Plans; Contact Sensor ↔ Security Events; System Operation Status logs; Backup Sets.
    - Cardinalities and maxima: verify the model can represent and the system enforces maxima where specified (up to 8 thermostats; up to 8 humidistats; up to 50 contact sensors; up to 100 power switches; one sound alarm and one light alarm subsystem) and one device per enclosed space for thermostats/humidistats (4.2.2.2, 4.3.2.1).
  - Pass criteria: schema supports all relationships; attempts to exceed specified maxima or violate one-per-space constraints are rejected by the system or prevented by database constraints.

- e) Integrity constraints
  - Method: boundary, negative, and consistency tests; schema constraint inspection.
    - Value ranges: thermostat setpoints 60–80 °F in 1-degree increments (4.2.1.2); humidistat setpoints 30–60% in 1% increments (4.3.1.2); thermostat sensor operating range 14–104 °F (3.4.4.1.c); support for Fahrenheit and Celsius values (4.2.4).
    - Enumerations: power switch states OFF/ON (4.5.3–4.5.4); contact sensor states CLOSED/OPEN triggering alarms (4.4.2).
    - Scheduling limits: up to 24 one-hour settings per day for thermostats/humidistats (4.2.2.3, 4.3.2.3); up to four daily periods in month plans (4.6.2.1); override persistence until end of current period (4.2.2.4, 4.3.2.2, 4.5.5).
    - Uniqueness: user account name uniqueness (5.4.2).
  - Pass criteria: out-of-range values, invalid enumerations, and excess schedule entries are rejected before persistence or by database-level constraints; units are stored/converted consistently to meet display/processing needs. Canonical storage format for temperature units: [N/A].

- f) Security
  - Method: security testing focused on database access paths as driven by system security requirements.
    - Authentication: verify that only authenticated sessions can perform database-affecting operations (5.4.1, 5.4.2).
    - Authorization: verify role-based access aligned with user types—only Technician/Master can change configuration and user accounts; General users limited to permitted operations (3.2.1.4, 3.2.2.4).
    - Transport protection: verify data in transit between web client and server is protected via TLS (5.4.1); confirm no direct database access is exposed.
    - At-rest protection and database-level encryption: [N/A].
    - Password storage method (e.g., hashing) and database hardening details: [N/A].
  - Pass criteria: unauthorized access attempts are denied; authorized operations succeed; all client–server interactions occur over TLS.

- g) Data retention requirements
  - Method: retention and recoverability tests.
    - Reporting horizon: populate the database with simulated data covering more than two years; verify the system can generate required monthly reports for any month within the past two years (4.6.3–4.6.3.3).
    - Backups and recovery: verify daily backups execute and that recovery restores configuration, default settings, planning, and usage data from the most recent backup after simulated failures (5.2.2–5.2.2.2).
    - Retention period for raw sensor data, events, and backups beyond what is required to support two-year reporting: [N/A].
  - Pass criteria: reports are available and correct for any month within the two-year window; successful restore yields complete, consistent data as specified.

## 4.6 Design constraints

This section verifies the design-constraint requirements by reviews, audits, analysis, and tests, aligned with the constraints specified in the Requirements section.

- External standards compliance
  - ASHRAE 2010 adherence for HVAC compatibility (Req 4.2.5)
    - Verification approach: compliance review and audit per IEEE 1028 against [ASHRAE 2010]; inspection of HVAC interface specifications and supported configurations.
  - Use of recognized security technology (e.g., TLS) for authentication and encryption (Req 5.4.1)
    - Verification approach: inspection of deployed protocols and configurations; evidence of TLS negotiation on secured endpoints; security review per IEEE 1028.

- Corporate/engineering standards and conventions
  - Use of IEEE standards (Req 5.5.1.3): IEEE 830 (SRS), IEEE 1008 (unit testing), IEEE 1016 (design description), IEEE 1028 (reviews and audits)
    - Verification approach: process and artifact audits per IEEE 1028; inspection that SRS, unit tests, and design descriptions conform to the cited IEEE standards.
  - HomeOwner Coding Standard HO4710 (Req 5.5.1.3)
    - Verification approach: code inspections and static analysis for HO4710 conformance; audit of coding checklists.
  - HomeOwner document format HO2305 (Req 5.6.1)
    - Verification approach: document inspections for format/style compliance prior to archive submission.
  - Object-oriented development using UML 2.0 (Req 5.6.2)
    - Verification approach: design reviews of UML 2.0 artifacts (use cases, class/sequence diagrams) to confirm OO modeling.

- Project and process limitations (Development Constraints, Sec 3.3)
  - Prototype completion within twelve months (Req 3.3.1)
    - Verification approach: schedule audits against the milestone plan in Section 2; variance reporting.
  - Team composition and roles (Req 3.3.2)
    - Verification approach: organizational roster and responsibility matrix review.
  - Use widely used, accepted, available technologies and standards (Req 3.3.4)
    - Verification approach: architecture and technology selection reviews; justification records audited per IEEE 1028.
  - Cost minimization with comparative pricing in final report (Req 3.3.5)
    - Verification approach: audit of the final project report to confirm inclusion of price comparisons and cost-minimization rationale.
  - Testing in a simulated environment only (Req 3.3.6)
    - Verification approach: test-environment readiness review confirming simulated sensors/controllers; execution of system tests within the simulation; analysis that simulation constraints reflect stated physical properties.
  - Change control approvals for major requirement changes (Req 3.3.7)
    - Verification approach: configuration management audit of change requests showing Director approval.

- Operational environment constraints (Sec 3.4)
  - Broadband ISP requirement (Req 3.4.1)
    - Verification approach: environment configuration review demonstrating provisioned broadband connectivity.
  - Home web server capability (Req 3.4.2)
    - Verification approach: demonstration/tests showing local server supports interaction, storage, account management, and backups.
  - Gateway device with RF module and indoor range up to 1000 feet (Reqs 3.4.3.2–3.4.3.3; see also Perf Req 5.1.3)
    - Verification approach: analysis/test within the simulated environment for communication coverage and RF module behavior; review of configuration parameters.

- Maintainability and future incorporation constraint (Req 5.5.2)
  - Prototype modules designed for incorporation into a commercial version
    - Verification approach: architecture/design reviews for modularity, abstraction, and information hiding; inspection of interfaces and dependency structure.

- Documentation and archival constraints (Req 5.6.1)
  - All required documents up-to-date, using HO2305 format, stored in HomeOwner Document Archive
    - Verification approach: final documentation audit for completeness, format compliance, and archival records.

- Evidence and records
  - Reviews and audits will be conducted per IEEE 1028; unit tests per IEEE 1008; design descriptions per IEEE 1016; SRS conformance per IEEE 830.
  - Detailed acceptance criteria and test procedures for the above constraints: [N/A]

## 4.7 Software system attributes

This section defines the verification approaches and methods to qualify the software against the software system attributes specified in Requirements section 3.7 (as derived from the original SRS).

### Reliability

- Related requirements
  - 5.2.1 High reliability target (≤1 failure per 10,000 hours of operation)
  - 5.2.2 Backup and recovery mechanisms (5.2.2.1 daily backup; 5.2.2.2 restore from most recent backup)
  - 5.2.3 Exception handling with clear, descriptive error messages
  - 3.3.6 Testing in a realistic simulated environment
- Verification methods
  - Endurance and stress testing in the simulated home environment to observe failure occurrence and estimate failure rate against 5.2.1.
  - Backup function tests: configure backup time and verify daily backup creation and integrity (5.2.2.1).
  - Recovery tests with fault injection: simulate power loss, loss of Internet access, and software/hardware faults; verify restoration of data from the most recent backup (5.2.2.2).
  - Exception handling tests: trigger representative error and exceptional conditions; verify user-facing messages are clear and descriptive (5.2.3).
  - Test reports will document test duration, failure counts, recovery outcomes, and message content, all executed within the simulated environment (3.3.6).

### Availability

- Related requirements
  - 5.2.2 Backup and recovery (checkpoint/restore)
  - 4.6.3.3 Reporting of periods when the DH System was not in operation
  - 3.2.2.4 Ability to start and stop operation of the DH System (by DH Technician)
- Verification methods
  - Recovery and restart tests: verify successful system restart after failures and that operation resumes with restored data (5.2.2.2).
  - Operational continuity tests: perform controlled start/stop by a DH Technician and verify no loss of persisted configuration/planning data (3.2.2.4).
  - Availability reporting tests: induce known downtime periods and verify that monthly reports accurately include those periods (4.6.3.3).
  - Defined availability level: [N/A].

### Security

- Related requirements
  - 5.4.1 Authentication and information encryption using a recognized technology such as TLS
  - 5.4.2 Login requires account name and password
  - 5.4.1 Account establishment upon installation
  - 3.2.1.4, 3.2.2.4 Role-based capabilities (Master User and DH Technician rights)
- Verification methods
  - Cryptography (item 1): configuration and runtime inspection to confirm TLS is enforced for all web interactions; certificate validation tests; packet capture to confirm credentials and sensitive data are not transmitted in plaintext (5.4.1).
  - Authentication tests: positive/negative login scenarios, credential handling, and session management; verify account creation during installation enables secure initial access (5.4.1, 5.4.2).
  - Authorization tests: verify that only Master Users and DH Technicians can perform configuration/start/stop operations; general users lack these capabilities (3.2.1.4, 3.2.2.4).
  - Logs/history (item 2): [N/A].
  - Function/module separation (item 3): [N/A].
  - Communication restrictions between program areas (item 4): [N/A].
  - Data integrity checks for critical variables (item 5): [N/A].
  - Data privacy assurance (item 6): verified via TLS enforcement and absence of plaintext sensitive data in transit (5.4.1).

### Maintainability

- Related requirements
  - 5.5.1 Use of documentation, abstraction, information hiding, and module independence
  - 5.5.1.3 Use of IEEE standards [IEEE830, IEEE1008, IEEE1016, IEEE1028] and HomeOwner Coding Standard [HO4710]
  - 5.5.2 Prototype modules designed/implemented to be incorporable into a commercial version
  - 5.6.1 Documentation currency, format [HO2305], and archival in HomeOwner Document Archive
  - 5.6.2 Object-oriented development using UML 2.0 (exceptions require CIO approval)
- Verification methods
  - Document reviews and audits (per IEEE 1028): verify presence, currency, and conformance of SRS, design descriptions (IEEE 1016), unit test plans (IEEE 1008), and source code documentation; confirm storage in the designated archive and use of [HO2305] format (5.6.1).
  - Design inspections: assess evidence of abstraction, information hiding, and module independence in architecture and detailed design; verify UML 2.0 models are used (5.5.1, 5.6.2).
  - Code reviews and static analysis: check compliance with HomeOwner Coding Standard [HO4710] and trace alignment with design (5.5.1.3).
  - Incorporability assessment: architectural/design review to confirm interfaces and modularization support incorporation into a fully specified commercial product (5.5.2).

### Portability

- Related requirements
  - 3.3.4 Use widely used, accepted, and available hardware/software technology and standards where possible
- Verification methods
  - Technology selection review: inspect that chosen languages, frameworks, and tools meet the “widely used/accepted/available” criterion (3.3.4).
  - Host-dependent elements percentage (item 1): [N/A].
  - Host-dependent code percentage (item 2): [N/A].
  - Proven portable language usage (item 3): [N/A].
  - Particular compiler/language subset (item 4): [N/A].
  - Particular operating system (item 5): [N/A].

## 5.1 Assumptions and dependencies

- Prototype scope and simulated environment: All devices, sensors, controllers, and the home are simulated for this initial version. If a physical deployment is required, functional and non-functional requirements (e.g., device interfaces, safety) would change.
- Internet connectivity: A broadband ISP connection (e.g., cable/DSL) is available at the home with sufficient reliability and bandwidth. Loss or change of connectivity assumptions would alter access, performance, and security requirements.
- Hosting model: A DigitalHome web server (central) and/or a local home web server is available to host user pages, data storage, user accounts, and backups. Changes to hosting availability or model affect access, data management, and security requirements.
- Home gateway availability: A DH Gateway device is present, connected to broadband, and operational as the master control. Its absence or changes in capabilities would alter system communication and control requirements.
- Wireless communications: RF wireless links are used between the gateway and devices, with up to 1000 feet indoor range. Different media, range, or reliability would impact performance, device counts, and placement requirements.
- Device availability and compatibility: Programmable thermostats, humidistats, magnetic contact sensors, alarms, and 115V/10A power switches are available, compatible, and support the stated counts (thermostats up to 8, humidistats up to 8, contacts up to 50, switches up to 100). Variations affect functional limits and planning/reporting requirements.
- Measurement units and ranges: Temperature is supported in °F and °C with thermostat setpoints 60–80 °F; humidity setpoints 30–60% at 1% increments; sensors meet stated sensitivity ranges. Different units, ranges, or accuracies would change control and reporting requirements.
- HVAC configuration and standards: Homes use centralized HVAC systems compatible with the DH system and ASHRAE practices. Different HVAC types or regulatory requirements would affect interfaces and control logic.
- Electrical standards: Managed switches and appliances conform to 115V, 10A US standards. Other regional power standards would change device specifications and related requirements.
- User access channels: Users have web-ready devices (computer, cell phone, PDA) and can perform basic web operations. If alternative channels or different user capabilities are needed, usability and access requirements would change.
- Security technology: Authentication via account/password and transport security (e.g., TLS) are available and acceptable. Stronger/different security policies or unavailable TLS would change security requirements.
- Data acquisition and update capability: Sensors/controllers support at least 10 Hz acquisition and the system can update displays at least every two seconds. If devices or network cannot meet these rates, performance requirements must change.
- Data storage capacity: Sufficient storage exists for daily backups and retention to support reports for any month in the past two years. Different retention or storage constraints would alter reporting and backup requirements.
- Operational roles: A DH Technician and a designated Master User are available to perform setup, configuration, and maintenance. If these roles are unavailable or differ, configuration and administrative requirements would change.
- Cost and technology availability: The system uses widely available, accepted, and cost-minimized components and standards. Changes in market availability or budget could affect device choices, counts, and performance targets.
- Physical home characteristics: Assumes typical residential indoor environments consistent with the stated wireless range and device placement (e.g., one thermostat/humidistat per enclosed space). Unusual layouts or larger properties would affect device counts and communication requirements.
- Scheduling capabilities: Devices support up to 24 hourly settings per day and manual overrides that persist until the next period. If device firmware does not support these behaviors, scheduling requirements must change.

## 5.2 Acronyms and abbreviations

The following acronyms and abbreviations are used. Where available, definitions are taken from the original SRS Glossary (Section 6) and References (Section 7).

- 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
- HVAC — Heating, Ventilation and Air Conditioning
- IEEE — Institute of Electrical and Electronics Engineers
- ISP — Internet Service Provider
- PDA — Personal Digital Assistant
- RF — Radio Frequency
- SRS — Software Requirements Specification
- UML — [N/A]