## 1.1 Purpose

The purpose of the DigitalHome (DH) software is to provide a prototype smart home management system that allows residents to remotely monitor and control key aspects of their home environment using a web-ready device.

Specifically, the software aims to:
- Monitor and control temperature and humidity.
- Manage security via door/window contact sensors and activate light/sound alarms.
- Control power to small appliances and lighting units (on/off).

This prototype is intended to demonstrate feasibility and support HomeOwner Inc. management in making business decisions about future commercial development of DigitalHome products and services. It operates in a simulated environment with simulated sensors and controllers and is not a comprehensive or complete commercial solution.

## 1.2 Scope

This Software Requirements Specification defines the prototype DigitalHome (DH) software system.

- Software products to be produced
  - DigitalHome web system (DH web server and web user interface), hosted on a home computer or a DH web server.
  - Device management services for:
    - Thermostats (temperature control and monitoring).
    - Humidistats (humidity control and monitoring).
    - Security contacts and alarms (door/window contacts; light and sound alarms).
    - Power switches for small appliances and lighting units (on/off management and status).
  - DigitalHome Planner (monthly scheduling of environmental parameters).
  - Reporting capability (monthly reports of temperatures, humidity, security breaches, and system downtime).
  - Configuration and user account management, including authentication and backup/recovery of system data.

- What the software will do
  - Allow a user, via a web-ready device, to monitor and control home temperature, humidity, security contacts/alarms, and the on/off state of small appliances and lights.
  - Read sensor values and store them; send controller values to change the home environment.
  - Support scheduling (up to four daily time periods per day) and manual overrides for thermostats, humidistats, and power switches.
  - Manage up to eight thermostats, eight humidistats, fifty contact sensors, and one hundred power switches.
  - Provide monthly reports for the past two years including environmental statistics, security events, and periods when the system was not in operation.
  - Provide user authentication and daily backup of configuration, defaults, plans, and usage data, with recovery from the most recent backup.

- Application, benefits, objectives, and goals
  - Application domain: smart home management focused on environmental control (temperature and humidity), security monitoring, and power management of small appliances and lighting.
  - Benefits: improved convenience, comfort, safety, and energy/environmental management through remote access, centralized control, planning, and reporting.
  - Objectives/goals:
    - Deliver a “proof of concept” prototype to support HomeOwner Inc. business decisions about future commercial development.
    - Demonstrate reliable remote monitoring/control, scheduling, and reporting over a home wireless gateway.
    - Operate in a realistic simulated home environment with simulated sensors and controllers.

- Scope boundaries
  - In scope: web-based control and monitoring of temperature, humidity, security contacts/alarms, and appliance/light power states; planning/scheduling; reporting; user account management; data backup/recovery; simulated device communications via a home gateway.
  - Out of scope: physical installation and operation with real (non-simulated) homes, sensors, and controllers; features beyond the stated domains (e.g., entertainment and general communications).

- Consistency with higher-level specifications
  - The scope is consistent with the Digital Home High Level Requirements Definition [HLRD 2010] and the Digital Home Use Case Model [HO2010], and reflects the prototype focus and functional limits stated therein.

### 1.3.1 Product perspective

DigitalHome (DH) is the software element of a Smart House system. It is the computer-based management layer that monitors and controls in-home devices (thermostats, humidistats, contact sensors, alarms, and controllable power switches) via a home wireless gateway. Users access DH through a web interface hosted either on a DigitalHome web server or on a local home web server. For the prototype, all home, sensors, and controllers are simulated, but operational constraints reflect realistic properties.

Major elements and interconnections:
- User web-ready device (computer, cell phone, PDA) ↔ DH web interface (DigitalHome web server or local home web server).
- DH web server ↔ DH home database/storage (plans, configuration, usage data; daily backup).
- DH web server ↔ DH home wireless gateway device (command/control and telemetry).
- DH gateway (RF) ↔ in-home devices: thermostats (HVAC), humidistats, door/window contact sensors, sound and light alarms, power switches.
- DH gateway ↔ broadband Internet via ISP.
- HVAC plant (gas, oil, electricity, solar, or combinations) under control per ASHRAE guidance.

Interfaces to the larger system:
- DH fulfills Smart House requirements for environmental control (temperature, humidity), security monitoring, and small appliance/lighting management, including scheduling, overrides, and reporting.
- Interfaces include the home gateway (RF link to devices), ISP connectivity, the HVAC system, and user-facing web interaction.

#### System interfaces
- Internet Service Provider (ISP)
  - Purpose: Provides broadband connectivity required by DH for remote access and communications.
  - Interface: Broadband Internet access; provider examples given; protocol details [N/A].
- DigitalHome web server or local home web server
  - Purpose: Communication center for monitoring/control, account management, data storage, and backup.
  - Interface: Web-based interaction with users; server-to-gateway communications; data persistence; specifics [N/A].
- DH home wireless gateway device
  - Purpose: Master control link to all DH devices; bridges server to in-home RF network.
  - Interface: Broadband connection and RF module; indoor range up to 1000 feet.
- Environmental and security devices
  - Thermostats (up to 8): Read temperature; set setpoints; scheduling; Fahrenheit/Celsius; wireless to master.
  - Humidistats (up to 8): Read humidity; set setpoints; scheduling; wireless to master.
  - Contact sensors (up to 50): Door/window open/close reporting.
  - Alarms (sound and light): Activation upon security breach.
  - Power switches (up to 100; 115V, 10A): State reporting and remote on/off.
- HVAC system
  - Purpose: Heating/cooling actuation under thermostat control.
  - Interface: Compatibility with centralized HVAC (gas, oil, electricity, solar, or combinations) per ASHRAE; control signaling specifics [N/A].
- Simulated environment (prototype only)
  - Purpose: Provides realistic simulated sensors/controllers and home physics for testing.
  - Interface: Simulation hooks [N/A].

#### User interfaces
- Web interface accessible via web-ready computer, cell phone, or PDA.
- Capabilities: Login/logout; monitor current status (temperature, humidity, contact sensors, power states); control setpoints and device states; monthly planner (up to four time periods/day); reporting for past two years; configuration by Master User/DH Technician (accounts, defaults).
- Feedback: Status displays updated at least every two seconds; clear error/exception messages; online documentation (FAQ, parameter setting/reading explanations, planner usage).
- Style guide and detailed UI standards [N/A].

#### Hardware interfaces
- DH gateway: RF module for in-home wireless; indoor range up to 1000 feet; broadband port; detailed port/configuration specs [N/A].
- Thermostats: Wireless communication with master; temperature sensor sensitivity −10°C to 40°C (14°F to 104°F); setpoints 60–80°F inclusive, 1°F increments; Fahrenheit and Celsius supported.
- Humidistats: Wireless communication with master; setpoints 30%–60% inclusive, 1% increments.
- Contact sensors: Magnetic door/window switches; OPEN state triggers alarms when armed.
- Alarms: Sound and light subsystems; activation interface [N/A].
- Power switches: Digital programmable switches; 115V, 10A; on/off sensing and control.
- HVAC: Interfaces consistent with centralized systems per ASHRAE; signaling details [N/A].

#### Software interfaces
- Web server software
  - Name/mnemonic/spec/version/source: [N/A]
  - Purpose: Hosts DH web interface and application logic.
  - Interface definition (APIs/message formats): [N/A]
- Database/storage
  - Name/mnemonic/spec/version/source: [N/A]
  - Purpose: Stores configuration, defaults, planning, and usage data; supports daily backups.
  - Interface definition: [N/A]
- Operating system/platform
  - Name/mnemonic/spec/version/source: [N/A]
  - Purpose: Hosts server components.
- Web browser (client)
  - Name/mnemonic/spec/version/source: [N/A]
  - Purpose: User interaction with DH web pages.
- Security protocol
  - Name: Transport Layer Security; mnemonic: TLS; specification number/version/source: [N/A]
  - Purpose: Authentication and information encryption for web access.
  - Interface definition: Referenced generally; specific document reference [N/A]
- Interfaces to other application systems: [N/A]

#### Communications interfaces
- In-home wireless: RF communications between gateway and devices; indoor range up to 1000 feet; data acquisition minimum 10 Hz from sensors; protocols and frequency bands [N/A].
- Internet connectivity: Broadband via ISP; secure communications using a recognized technology such as TLS; specific protocols, ports, and formats [N/A].

#### Memory constraints
- [N/A]

#### Operations
- Modes:
  - User-initiated interactive operations via web UI (monitoring, control, planning, reporting).
  - Technician/Master User operations (system setup, parameter defaults, user account management, start/stop system).
- Interactive vs. unattended:
  - Interactive monitoring/control; unattended scheduled execution of plans (thermostats, humidistats, power switches, security arming) and continuous data collection.
- Data processing support:
  - Store sensor readings; maintain monthly plans; generate reports (daily average/max with time/min with time for temperature/humidity; security breach times; system downtime periods for past two years).
- Backup and recovery:
  - Daily backup of system data at technician-set time; recovery restores from most recent backup upon failure (power loss, loss of Internet access, hardware/software failure).

#### Site adaptation requirements
- Site-specific initialization:
  - Device inventory and placement (rooms/zones for up to 8 thermostats and 8 humidistats; mapping of up to 50 contact sensors; alarms; up to 100 power switches).
  - Default parameter settings (temperature/humidity setpoints; security arming behavior; planner defaults).
  - Unit selection (Fahrenheit/Celsius).
  - User accounts and roles (General, Master User); backup time configuration.
  - Gateway installation and ISP provisioning.
- Features to adapt:
  - Choice between local home web server vs. DigitalHome web server; device counts within specified maxima; naming and organization of home spaces; HVAC type compatibility per ASHRAE.
- Site-specific data formats or import/export mechanisms: [N/A]

#### Interfaces with services
- DigitalHome web server (if hosted as a service): Provides user web pages, device control/monitoring, account management, storage, and backup; service endpoints and SLAs [N/A].
- Internet Service Provider: Provides broadband connectivity required by DH; service management interfaces [N/A].
- Other SaaS/cloud services: [N/A]

### 1.3.2 Product functions

- User access and interaction
  - Provide a web interface (via web-ready computer, cell phone, or PDA) to monitor and control the home environment remotely.
  - Present current status of environmental conditions and device states.

- Core device management
  - Temperature management
    - Read temperature from thermostats and display values.
    - Set and adjust thermostat set-points; support individual or collective control of multiple thermostats.
    - Support per-thermostat daily scheduling; honor manual overrides until the next scheduled period.
    - Support Fahrenheit and Celsius values.
  - Humidity management
    - Read humidity from humidistats and display values.
    - Set and adjust humidistat set-points; manage multiple humidistats.
    - Support per-humidistat daily scheduling; honor manual overrides until the next scheduled period.
  - Security monitoring and alarms
    - Monitor door and window contact sensors.
    - Detect security breaches and activate sound and light alarm subsystems.
  - Appliance and lighting control
    - Monitor power switch states (ON/OFF) for small appliances and lighting units.
    - Change power switch states (turn devices ON/OFF); honor manual overrides until the next scheduled period.

- Planning and automation
  - Monthly planning
    - Create and modify a monthly plan specifying, for each day and up to four time periods, the desired temperature, humidity, contact sensor status, and power switch states.
  - Per-device scheduling
    - Configure up to 24 one-hour settings per day for thermostats and humidistats.
  - Overrides
    - Allow users to override planned values via the website or available manual device controls.

- Monitoring, history, and reporting
  - Collect and store sensor readings and device states in the home database.
  - Generate monthly reports (for any month in the past two years) including:
    - Daily average, maximum (with time), and minimum (with time) temperature and humidity per device.
    - Dates and times of security breaches (alarm activations).
    - Periods when the DH system was not in operation.

- System administration and configuration
  - User and role management
    - Establish user accounts; authenticate users with account name and password.
    - Support a Master User and DH Technician roles to configure the system (e.g., defaults, user accounts) and start/stop operation.
  - System configuration
    - Set system parameters, device configurations, and default settings.

- Communications and infrastructure services
  - Operate a DH home web server to mediate user interactions, data storage, and backups.
  - Communicate with home devices via a wireless gateway; acquire sensor data and send controller commands.
  - Secure communications using recognized encryption (e.g., Transport Layer Security).
  - Perform daily backups of configuration, defaults, plans, and usage data; restore from the most recent backup on failure.
  - Provide clear error and exception messages to users.

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

### 1.3.3 User characteristics

- General user (home resident)
  - Familiar with the layout of the home and locations of sensor and control devices.
  - Capable of basic web operations: logging in/out, browsing pages, and submitting information via a web interface.
  - Not familiar with the technical features of the DigitalHome system.
  - Uses a web-ready device (computer, cell phone, or PDA) to monitor and control environmental settings.
  - Educational level: [N/A]
  - Disabilities and accessibility needs: [N/A]
  - Technical expertise: basic end-user proficiency with web interfaces.

- Master user (designated home administrator)
  - A designated user with rights to change system configuration (e.g., add user accounts, change default parameter settings).
  - Has the same rights as the DigitalHome Technician to set parameters and manage accounts.
  - Educational level: [N/A]
  - Disabilities and accessibility needs: [N/A]
  - Technical expertise: administrative-level proficiency sufficient to configure the system.

- DigitalHome Technician
  - Responsible for setting up, configuring, maintaining, and starting/stopping operation of the system.
  - Experienced with relevant hardware, software, and web services.
  - Specially trained by DigitalHomeOwner; familiar with the system’s functionality, architecture, and operation.
  - Holds rights beyond the general user for configuration and operational control.
  - Educational level: [N/A]
  - Disabilities and accessibility needs: [N/A]
  - Technical expertise: advanced, including installation and maintenance of system components.

### 1.3.4 Limitations

The following items constrain the supplier’s options for the DigitalHome prototype:

- (a) Regulatory requirements and policies
  - Adherence to ASHRAE standards for HVAC.
  - Use of IEEE standards [IEEE830, IEEE1008, IEEE1012, IEEE1016, IEEE1028], HomeOwner Coding Standard [HO4710], and HomeOwner document format [HO2305].
  - Use of the development process specified by HomeOwner Inc.; major requirement changes require approval by the DigitalHomeOwner Director.
  - Authentication and encryption via recognized technologies (e.g., TLS).
  - Object-oriented development using UML 2.0 is the preferred method; exceptions require CIO approval.
  - Cost minimization for system elements is required.

- (b) Hardware limitations
  - Wireless communication via a gateway RF module; indoor operating range up to 1000 feet; devices must be within 1000 feet of the master control device.
  - Thermostat sensor sensitivity 14°F–104°F (-10°C to 40°C); user setpoints 60°F–80°F in 1°F increments; Fahrenheit and Celsius supported.
  - Humidistat setpoints 30%–60% in 1% increments.
  - Appliance switches limited to 115 V, 10 A.
  - Maximum device counts: up to 8 thermostats; up to 8 humidistats; up to 50 contact sensors; up to 100 power switches.
  - One thermostat or humidistat per enclosed space.

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

- (d) Parallel operation
  - [N/A]

- (e) Audit functions
  - Monthly reports available only for the past two years.
  - Month report includes daily average/min/max (with time) temperature and humidity per device, times of security breaches, and periods when the DH system was not in operation.
  - Daily system backups; recovery uses most recent backup.

- (f) Control functions
  - Technician and designated Master User can configure the system (parameters, user accounts) and start/stop operation.
  - Scheduling limits: up to 24 one-hour settings per day per thermostat/humidistat; monthly planner supports up to four daily time periods per day.
  - Manual overrides persist until the end of the current planned/default period.
  - Security alarms activate when a monitored contact is opened.

- (g) Higher-order language requirements
  - Object-oriented development preferred; UML 2.0 for modeling.
  - No specific programming language mandated. [N/A]

- (h) Signal handshake protocols
  - [N/A]

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

- (j) Criticality of the application
  - Prototype intended to support business decisions; however, failures can affect occupant safety (security, lighting, temperature/humidity, appliance power).

- (k) Safety and security considerations
  - Although no specific safety requirements are detailed, high reliability is required to avoid unsafe conditions.
  - Security: account-based access with authentication (username/password) and encrypted communications (e.g., TLS).

- (l) Physical/mental considerations
  - General users are not expected to know technical system details; they are limited to simple web operations and rely on familiarity with the home layout and device locations.
  - DH Technician is trained and experienced; configuration and maintenance rely on this role.

- (m) Limitations sourced from other systems (including real-time via interfaces)
  - Dependence on an ISP and broadband connectivity (e.g., cable modem, high-speed DSL).
  - Home web server and gateway required for operation.
  - System tested and operated in a simulated environment for the prototype; all sensors and controllers are simulated but must adhere to realistic physical properties.
  - Real-time limits: display refresh ≥ every 2 seconds; sensor acquisition ≥ 10 Hz.

## 1.4 Definitions

- ASHRAE – American Society of Heating, Refrigerating and Air-Conditioning Engineers.
- Authentication – any process by which it is verified that someone is who they claim they are; typically involves submission and verification of a username and a password.
- Broadband Internet – a high data rate Internet access, typically contrasted with slower dial-up access.
- DH (Digital Home) – the name of the prototype smart home product 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 special knowledge (a key).
- FAQ – frequently asked question.
- Gateway Device – a home networking device used to connect devices in the home to the Internet or other Wide Area Networks.
- HomeOwner Inc. – the largest national retail chain serving the needs of home owners in building, furnishing, repairing, and improving their homes.
- HVAC – Heating, Ventilation and Air Conditioning.
- Humidistat – an instrument that measures and controls relative humidity.
- ISP – Internet Service Provider.
- PDA – Personal Digital Assistant.
- RF – Radio Frequency.
- Security Breach – an external act that bypasses or contravenes the digital home security system (e.g., opening a door where 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.

# 2 References

## Compliance

- American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) website
  - Report number: [N/A]
  - Date: accessed October 2010
  - Publishing organization: American Society of Heating, Refrigerating and Air-Conditioning Engineers
  - Source: http://www.ashrae.org/
- Guidelines for Developing HomeOwner Technical Reports
  - Report number: HO2305
  - Date: March 2002
  - Publishing organization: Homeowner Inc.
  - Source: [N/A]

## Guidance

- Digital Home High Level Requirements Definition
  - Report number: [N/A]
  - Date: September 2010
  - Publishing organization: Homeowner Inc., DigitalHomeOwner Division
  - Source: [N/A]
- Digital Home Use Case Model
  - Report number: [N/A]
  - Date: October 24, 2010
  - Publishing organization: HomeOwner Inc., DigitalHomeOwner Division
  - Source: [N/A]
- HomeOwner Coding Standard
  - Report number: HO4710
  - Date: August 2009
  - Publishing organization: Homeowner Inc.
  - Source: [N/A]
- 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: [N/A]
- 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: [N/A]
- 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: [N/A]
- 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: [N/A]

## 3.1 Functions

This section partitions the DigitalHome (DH) functional behavior into sub-functions. For each, it identifies inputs, processing (including sequence), outputs, validity checks, effects of parameters, relationships between inputs and outputs, and responses to abnormal situations. Where required content is not present in the source SRS, [N/A] is indicated.

- Authentication and session management
  - Inputs:
    - Account name and password (user login).
  - Processing and sequence:
    - User connects to DH web server over a secure channel.
    - User submits account name and password.
    - System authenticates the credentials.
    - On success, a session is established; on failure, an error is returned.
  - Outputs:
    - Authenticated session granting access to DH functions, or an authentication error message.
  - Validity checks on inputs:
    - Login must include both account name and password.
  - Responses to abnormal situations:
    - Communication facilities: If a system failure occurs due to loss of Internet access, recovery is handled as described under Backup and recovery.
    - Error handling: Clear, descriptive error messages are provided on authentication failure.
    - Overflow: [N/A]
    - Hardware faults and failures: Recovery as per Backup and recovery.
  - Effect of parameters:
    - None beyond user account configuration.
  - Relationship of outputs to inputs:
    - Input/output sequence: Credentials → authentication → session granted/denied.
    - Formulas: [N/A]

- System setup and configuration (Technician/Master user)
  - Inputs:
    - Configuration parameters, default parameter settings, user account definitions; start/stop commands.
  - Processing and sequence:
    - Technician/Master establishes user accounts and default settings.
    - Technician/Master starts or stops DH system operation.
  - Outputs:
    - Persisted configuration; system operational state change.
  - Validity checks on inputs:
    - [N/A] (no explicit constraints beyond role authorization).
  - Responses to abnormal situations:
    - Error handling: Clear messages on configuration errors.
    - Backup and recovery: Configuration is included in daily backups and is restored after failures.
    - Overflow/hardware/communications specifics: [N/A] (beyond recovery).
  - Effect of parameters:
    - Defaults influence device behavior when no plan is active or after manual overrides expire.
  - Relationship of outputs to inputs:
    - Configuration inputs determine subsequent control outputs applied by planning and manual commands.
    - Formulas: [N/A]

- Device communication via home gateway
  - Inputs:
    - Wireless signals to/from thermostats, humidistats, contact sensors, alarms, and power switches.
  - Processing and sequence:
    - DH web server sends/receives device commands and readings via the DH Gateway’s RF module.
    - Sensor values are read and saved in the home database.
  - Outputs:
    - Updated device states and stored sensor/controller data.
  - Validity checks on inputs:
    - Devices must be within 1000 feet of the master control device.
    - System supports up to: 8 thermostats, 8 humidistats, 50 contact sensors, 100 power switches.
  - Responses to abnormal situations:
    - Communication facilities: Loss of Internet access triggers recovery as per Backup and recovery; clear error messages are presented during exceptional conditions.
    - Hardware faults and failures: Recovery as per Backup and recovery.
    - Overflow: [N/A]
    - Error handling: Clear, descriptive messages on communication errors.
  - Effect of parameters:
    - None beyond device addressing and counts.
  - Relationship of outputs to inputs:
    - Input/output sequence: Command/read request → RF transmission → device action/reading → acknowledgment/data stored.
    - Formulas: [N/A]

- Sensor data acquisition and display
  - Inputs:
    - Temperature, humidity, contact status, and power state readings from devices.
  - Processing and sequence:
    - Acquire sensor data at a minimum of 10 Hz.
    - Persist data in the home database.
    - Update environmental condition displays at least every two seconds.
  - Outputs:
    - Persisted time-stamped readings; refreshed UI displays.
  - Validity checks on inputs:
    - Thermostat sensor operating range: 14°F to 104°F (−10°C to 40°C).
  - Responses to abnormal situations:
    - Error handling: Clear messages when acquisition or display updates fail.
    - Backup and recovery covers persisted data.
    - Communication/hardware/overflow specifics: [N/A] (beyond recovery).
  - Effect of parameters:
    - Temperature unit selection (Fahrenheit/Celsius) affects display values only.
  - Relationship of outputs to inputs:
    - Input/output sequence: Device reading → validate range (if applicable) → store → display refresh.
    - Formulas for conversion:
      - [N/A] (system supports both units; conversion formulas not specified).

- Thermostat monitoring and control
  - Inputs:
    - User-set temperature setpoints; planned setpoints from the monthly plan; manual device adjustments; unit selection (F/°C).
  - Processing and sequence:
    - User selects thermostat(s) (individual or collective).
    - Input setpoint is validated.
    - Valid setpoint is sent wirelessly to the thermostat controller.
    - Controller actuates heating/cooling to achieve the setpoint.
    - Manual device adjustments, if made, remain effective until the end of the current planned or default time period, then planned/default values resume.
  - Outputs:
    - Updated thermostat setpoints; HVAC actuation; confirmation/status in UI and database.
  - Validity checks on inputs:
    - Setpoint range: 60°F to 80°F inclusive, in 1°F increments.
    - Up to 8 thermostats total; one thermostat per enclosed space.
    - Scheduling: up to 24 one-hour settings per day per thermostat.
  - Responses to abnormal situations:
    - Error handling: Clear messages for out-of-range setpoints or invalid selections.
    - Communication/hardware faults: Recovery per Backup and recovery.
    - Overflow: [N/A]
  - Effect of parameters:
    - Setpoint values directly influence HVAC control; unit selection affects setpoint interpretation and display.
  - Relationship of outputs to inputs:
    - Input/output sequence: Select thermostat(s) → enter setpoint → validate → send control → update status/log.
    - Formulas: [N/A]

- Humidistat monitoring and control
  - Inputs:
    - User-set humidity setpoints; planned setpoints; manual device adjustments.
  - Processing and sequence:
    - User selects humidistat(s).
    - Validate setpoint.
    - Send valid setpoint wirelessly via master control unit.
    - Controller actuates humidification/dehumidification to achieve setpoint.
    - Manual adjustments remain in effect until the end of the current planned or default period, then planned/default values resume.
  - Outputs:
    - Updated humidity setpoints; device actuation; confirmation/status in UI and database.
  - Validity checks on inputs:
    - Setpoint range: 30% to 60% inclusive, in 1% increments.
    - Up to 8 humidistats total; one per enclosed space.
    - Scheduling: up to 24 one-hour settings per day per humidistat.
  - Responses to abnormal situations:
    - Error handling: Clear messages for invalid ranges or selections.
    - Communication/hardware faults: Recovery per Backup and recovery.
    - Overflow: [N/A]
  - Effect of parameters:
    - Setpoint values directly influence humidifier/dehumidifier control.
  - Relationship of outputs to inputs:
    - Input/output sequence: Select humidistat(s) → enter setpoint → validate → send control → update status/log.
    - Formulas: [N/A]

- Security monitoring and alarm activation
  - Inputs:
    - Door/window contact sensor states (OPEN/CLOSED).
  - Processing and sequence:
    - Monitor up to 50 contact sensors.
    - When a security breach occurs and a contact sensor is OPEN, activate the alarm system.
  - Outputs:
    - Activation of one sound alarm and one light alarm subsystem (with multiple lights); log entries with breach day/time.
  - Validity checks on inputs:
    - Sensor identifiers must reference configured sensors within the allowed maximum.
  - Responses to abnormal situations:
    - Error handling: Clear messages on sensor faults or invalid states.
    - Communication/hardware faults: Recovery per Backup and recovery.
    - Overflow: [N/A]
  - Effect of parameters:
    - Alarm enablement status (if part of system defaults/plans) determines whether alarms are actionable.
  - Relationship of outputs to inputs:
    - Input/output sequence: Sensor state change to OPEN → detect breach → trigger alarms → record event.
    - Formulas: [N/A]

- Appliance and lighting management
  - Inputs:
    - User on/off commands; planned on/off states; manual device toggles.
  - Processing and sequence:
    - Validate target power switch and desired state.
    - Change power switch state accordingly.
    - Manual state changes remain in effect until the end of the current planned or default period, then planned/default values resume.
  - Outputs:
    - Power switch state (OFF/ON); updated appliance/light state; confirmation/status in UI and database.
  - Validity checks on inputs:
    - Manage up to 100 power switches (115 V, 10 A).
  - Responses to abnormal situations:
    - Error handling: Clear messages for invalid switch references or states.
    - Communication/hardware faults: Recovery per Backup and recovery.
    - Overflow: [N/A]
  - Effect of parameters:
    - Planned/default states govern automatic switching at time boundaries.
  - Relationship of outputs to inputs:
    - Input/output sequence: Select switch → request state change → validate → actuate → update status/log.
    - Formulas: [N/A]

- Planning and scheduling
  - Inputs:
    - Monthly plan for a given month and year: up to four daily time periods per day specifying temperature, humidity, contact sensor status, and power switch states.
  - Processing and sequence:
    - For each day and each defined time period, apply planned parameter settings to the corresponding devices at the start of the period.
    - Allow user overrides via website or device manual controls; overrides persist until the end of the current planned/default period.
  - Outputs:
    - Time-triggered control commands; applied device states; persisted plan data.
  - Validity checks on inputs:
    - For each day, at most four daily time periods may be defined.
  - Responses to abnormal situations:
    - Error handling: Clear messages for invalid plans (e.g., period count violations).
    - Overflow/communication/hardware specifics: [N/A] (beyond recovery).
  - Effect of parameters:
    - Planned parameters directly determine device setpoints and states during their effective periods.
  - Relationship of outputs to inputs:
    - Input/output sequence: Create/modify plan → validate → store → scheduler triggers at boundaries → issue device commands → log results.
    - Formulas: [N/A]

- Reporting
  - Inputs:
    - Request for a month report for a given month and year within the past two years.
  - Processing and sequence:
    - Retrieve stored data for the requested month.
    - Compute, per thermostat and humidistat, daily average, maximum (with time), and minimum (with time).
    - Retrieve day and time for any security breaches.
    - Determine periods when the DH System was not in operation.
  - Outputs:
    - Month report containing the above data.
  - Validity checks on inputs:
    - Month/year must be within the past two years.
  - Responses to abnormal situations:
    - Error handling: Clear messages for out-of-range report requests or missing data.
    - Overflow/communication/hardware specifics: [N/A] (beyond recovery).
  - Effect of parameters:
    - None.
  - Relationship of outputs to inputs:
    - Input/output sequence: Report request → validate timeframe → retrieve/aggregate data → present report.
    - Formulas for aggregation:
      - [N/A] (aggregation required but formulas not specified).

- Backup and recovery
  - Inputs:
    - System failure events (power loss, loss of Internet access, other software/hardware failures); configured daily backup time.
  - Processing and sequence:
    - Perform daily backup of all system data (configuration, default parameter settings, planning, usage data) at the configured time.
    - Upon failure, restore system data from the most recent backup.
  - Outputs:
    - Backup archives; restored system state after recovery.
  - Validity checks on inputs:
    - Backup time must be set by DH Technician at setup.
  - Responses to abnormal situations:
    - This sub-function is the response for communication, hardware, and other failures.
    - Overflow: [N/A]
    - Error handling: Clear messages on backup/restore success or failure.
  - Effect of parameters:
    - Backup schedule determines when backups occur.
  - Relationship of outputs to inputs:
    - Input/output sequence: Scheduled time → execute backup → on failure → execute restore → resume operation.
    - Formulas: [N/A]

- General exception handling
  - Inputs:
    - Errors and exceptional conditions across all operations.
  - Processing and sequence:
    - Detect exceptions; generate clear, descriptive messages; prevent undefined behavior.
  - Outputs:
    - User-visible error messages; safe termination or continuation of operations as appropriate.
  - Validity checks on inputs:
    - [N/A]
  - Responses to abnormal situations:
    - As above; integrates with Backup and recovery for fault scenarios.
    - Overflow: [N/A]
    - Communication facilities: Covered via error messaging and recovery.
    - Hardware faults and failures: Covered via recovery.
  - Effect of parameters:
    - [N/A]
  - Relationship of outputs to inputs:
    - Input/output sequence: Operation → exception → message/handling → operation continues or aborts.
    - Formulas: [N/A]

## 3.2 Performance requirements

The following requirements specify system-wide static capacity and dynamic timing/throughput characteristics in measurable terms.

### Static capacity (numerical)
- Terminals/end-user devices supported: [N/A]
- Simultaneous users supported: [N/A]
- Information types handled:
  - Environmental sensor readings: temperature (Fahrenheit and Celsius), humidity (% RH), door/window contact state (OPEN/CLOSED), power switch state (OFF/ON).
  - Control commands: thermostat setpoint, humidistat setpoint, power switch ON/OFF, alarm activation.
- Maximum device counts per home:
  - Up to 8 thermostats.
  - Up to 8 humidistats.
  - Up to 50 door/window contact sensors.
  - One sound alarm and one light alarm subsystem (with multiple lights).
  - Up to 100 power switches (115 V, 10 A).
- Scheduling capacity:
  - For each thermostat: up to 24 one-hour settings per day for each day of the week.
  - For each humidistat: up to 24 one-hour settings per day for each day of the week.
  - Monthly planner: up to 4 daily time periods for each day of the month.
- Historical reporting window: Month reports shall be available for any month within the past 2 years.
- Wireless communication coverage: Indoor transmission between the gateway and DH devices up to 1000 feet; sensors and controllers shall be within 1000 feet of the master control device to communicate.
- Data storage volume: [N/A]

### Dynamic performance (timing and throughput)
- Display refresh: Displays of temperature, humidity, contact sensors, and power switches shall be updated at least every 2 seconds.
- Sensor data acquisition: Temperature, humidity, contact sensor, and power state data shall be acquired at a minimum rate of 10 Hz.
- Backup cadence: All system data (configuration, default parameter settings, planning, and usage data) shall be backed up daily at a technician-configured time.
- Transaction/throughput under normal and peak loads: [N/A]
- End-to-end command latency (e.g., setpoint change or switch toggle to device effect/acknowledgment): [N/A]

## 3.3 Usability requirements

This section specifies usability and quality-in-use requirements for DigitalHome in the context of home residents and DH Technicians operating the system via a web interface on web-ready devices (computer, cell phone, PDA) through the DH web server or a local home server.

- Contexts of use and user characteristics
  - General user operates the system via a personal web page and can perform basic web operations (log in/out, browse, submit requests).
  - A Master user and a DH Technician can configure the system (establish accounts, set parameters, start/stop operation).

- Effectiveness (user goals supported)
  - Users can monitor and control temperature, humidity, lights, security, and the state of small appliances from any location using web-ready devices.
  - Users can read sensor values (temperature, humidity, contact sensors, power state) and send controller values to change the environment; manual overrides are supported and remain in effect until the end of the planned or default period.
  - Temperature can be viewed/controlled in Fahrenheit and Celsius.
  - Planning functions allow users to set preset parameters for defined time periods and create/modify a monthly plan with daily settings.
  - Measurable task completion targets (e.g., time-on-task, error rates): [N/A]

- Efficiency (time and resource use)
  - Displays of environmental conditions (temperature, humidity, contact sensors, power switches) are updated at least every two seconds.
  - Sensor data acquisition rate is at least 10 Hz to support responsive displays and timely control.
  - Environmental devices must be within 1000 feet of the master control device to maintain communication and responsiveness.
  - Measurable UI interaction efficiency targets beyond the above (e.g., clicks/steps per task): [N/A]

- Satisfaction, learnability, and operability
  - The system provides clear, descriptive user-facing messages when errors or exceptional conditions occur.
  - Online user documentation is available, including:
    - FAQ on use and maintenance (e.g., password changes, support).
    - Explanation of parameter setting and sensor reading limitations/accuracy.
    - Instructions for using the DH Planner.
  - Security mechanisms (authentication with account/password and encryption via Transport Layer Security) support user trust in remote operation.
  - Explicit user satisfaction targets (e.g., user ratings, SUS scores): [N/A]
  - Accessibility, localization, and language requirements: [N/A]

- Avoidance of harm in use (quality in use: safety)
  - High reliability (no more than 1 failure per 10,000 hours of operation) to reduce the risk of unsafe states (e.g., security breaches, inadequate lighting, inappropriate temperature/humidity).
  - Backup and recovery mechanisms restore configuration, defaults, plans, and usage data from the most recent backup after failures (e.g., power loss, loss of Internet access), minimizing disruption that could lead to unsafe conditions.
  - Security breach handling activates alarms when a monitored contact is opened while armed.
  - Authentication and encryption reduce risks associated with remote control of household systems.
  - Additional user error protection or hazard notices presented in the UI: [N/A]

## 3.5 Logical database requirements

a) Types of information used by various functions
- User and configuration
  - User accounts (account name, password), user roles (General User, Master User, DH Technician).
  - System configuration and default parameter settings.
  - Device inventory and configuration (thermostats, humidistats, contact sensors, power switches, alarms, gateway).
- Thermostat management
  - Current temperature readings per thermostat.
  - Temperature set points and schedules (up to twenty-four one-hour settings per day per thermostat).
  - Manual override settings and their effective periods.
  - Temperature units (Fahrenheit and Celsius).
- Humidistat management
  - Current humidity readings per humidistat.
  - Humidity set points and schedules (up to twenty-four one-hour settings per day per humidistat).
  - Manual override settings and their effective periods.
- Security system
  - Contact sensor states (e.g., OPEN/CLOSED) and timestamps.
  - Alarm activation events (sound and light) and timestamps.
- Appliance management
  - Power switch states (OFF/ON) and timestamps.
  - Manual changes and their effective periods.
- Planning
  - Monthly plan: for a given month/year, per day, up to four daily time periods with parameter settings (temperature, humidity, contact sensors, power switches).
- Reporting
  - For each thermostat and humidistat: daily average, maximum (with time), and minimum (with time) values.
  - Security breaches (day and time).
  - Periods when the DH System was not in operation.
- Operations and backup
  - Backup scheduling time (set at system setup).
  - Backup and recovery status metadata as needed to restore system data.

b) Frequency of use
- Sensor data acquisition at a minimum of 10 Hz.
- Displays of environmental conditions updated at least every two seconds.
- Planning data created/modified per month; overrides may occur at any time.
- Month reports generated on demand for a given month and year within the past two years.
- System data backed up daily at a time set by the DH Technician.

c) Accessing capabilities
- Authenticated users access data via the DH web server using a web-ready device.
- General Users
  - Read current sensor values and device states.
  - Submit controller changes (set points, power switch states).
  - Create/view month plans and override planned values.
  - Request month reports (within the past two years).
- Master Users and DH Technicians
  - All General User capabilities.
  - Create/modify user accounts.
  - Set default parameters and system configuration.
  - Start/stop system operation.
- The database shall support queries by device, location (enclosed space), date/time ranges (including month/year), and by plan period.

d) Data entities and their relationships
- Home
  - Has one DH Gateway Device.
  - Contains multiple enclosed spaces (rooms).
- Device (abstract)
  - Specializations: Thermostat, Humidistat, Contact Sensor, Power Switch, Sound Alarm, Light Alarm.
  - Each device is associated with one enclosed space (where applicable) and one Home.
- UserAccount
  - Attributes include account name, password, role.
- Thermostat
  - Has many TemperatureReadings (timestamped).
  - Has many ThermostatSchedules (up to 24 one-hour settings per day).
- Humidistat
  - Has many HumidityReadings (timestamped).
  - Has many HumidistatSchedules (up to 24 one-hour settings per day).
- ContactSensor
  - Has many ContactEvents (state changes with timestamps).
- PowerSwitch
  - Has many PowerSwitchStateChanges (OFF/ON with timestamps).
- Alarm (Sound, Light)
  - Linked to SecurityEvents (activations with timestamps).
- MonthlyPlan
  - For one month/year, has 28–31 DayPlans.
  - Each DayPlan has up to four PlanPeriods.
  - Each PlanPeriod specifies parameter settings for temperature, humidity, contact sensors, and power switches.
- SystemOperationInterval
  - Records intervals when the DH System was not in operation.
- ReportData
  - Stores or references computed daily averages, maxima (with time), and minima (with time) per thermostat/humidistat for reporting.
- BackupRecord
  - Records backup occurrences (timestamp) per Home.

e) Integrity constraints
- Device counts per Home
  - Up to 8 thermostats; up to 8 humidistats.
  - Up to 50 door/window contact sensors.
  - Up to 100 power switches (115V, 10A).
  - One sound alarm and one light alarm subsystem (with multiple lights).
- Placement
  - One thermostat per enclosed space for which air temperature is controlled.
  - One humidistat per enclosed space for which humidity is controlled.
- Value ranges and increments
  - Thermostat set points: 60°F to 80°F inclusive, at 1° increments; Celsius supported.
  - Thermostat sensor range: 14°F to 104°F (-10°C to 40°C).
  - Humidistat set points: 30% to 60% inclusive, at 1% increments.
  - Power switch states: OFF or ON.
  - Contact sensor states: OPEN/CLOSED (active when set).
- Scheduling limits
  - Per thermostat/humidistat: up to twenty-four one-hour settings per day.
  - MonthlyPlan: up to four daily time periods per day.
- Overrides
  - Manual settings remain in effect until the end of the planned or default time period, after which the planned/default setting resumes.
- Reporting completeness
  - For each day in a reported month, store/compute average, maximum (with time), and minimum (with time) per thermostat and humidistat; store day/time of security breaches; store system non-operation periods.

f) Security
- Access to database-resident information shall occur through authenticated user accounts.
- The web system shall provide authentication and information encryption through Transport Layer Security.
- Login requires account name and password.
- Role-based access consistent with user descriptions (General User, Master User, DH Technician).
- [N/A] (database-level encryption at rest, detailed authorization model, and audit logging policies are not specified).

g) Data retention requirements
- The system shall retain the data necessary to provide month reports for any given month and year within the past two years (including daily averages, maxima/minima with times, security breaches with times, and system non-operation intervals).
- User account information, user plans, and home database content shall be backed up daily at a time set by the DH Technician; recovery shall restore from the most recent backup.
- [N/A] (retention of raw high-frequency sensor data beyond what is required to generate the specified reports is not specified).

## 3.6 Design constraints

The DigitalHome design is constrained by the following external standards, security requirements, operational environment, and project limitations:

- External standards and compliance:
  - HVAC-related functionality shall adhere to the standards, policies, and procedures of the American Society of Heating, Refrigerating and Air-Conditioning Engineers [ASHRAE 2010].
  - Development and documentation shall conform to IEEE and HomeOwner standards: IEEE 830, IEEE 1008, IEEE 1016, IEEE 1028, and the HomeOwner Coding Standard [HO4710]; documents shall use the HomeOwner report format [HO2305].
  - HomeOwner has designated object-oriented development using UML 2.0 as the preferred method; exceptions require CIO approval.

- Security and privacy:
  - The web system shall provide authentication and information encryption using a recognized, reliable security technology such as Transport Layer Security (TLS).
  - Account access requires an account name and password.

- Operational and technology environment:
  - The system requires an Internet Service Provider offering widely available broadband access (e.g., cable modem or high-speed DSL).
  - The architecture shall include a DH home web server for device interaction, data storage, user account management, and backup services.
  - A DH Gateway device with an RF module shall provide wireless communications between the gateway and in-home devices and shall connect to the broadband Internet.
  - Wireless communication constraints: the gateway shall operate up to a 1000-foot indoor transmission range; environmental sensors and controllers must be within 1000 feet of the master control device.

- Device capability constraints impacting design:
  - Thermostat sensors operate within a sensitivity range of 14°F to 104°F (-10°C to 40°C); the system shall support Fahrenheit and Celsius.
  - Humidistat control setpoint range is 30% to 60% relative humidity (1% increments).
  - Capacity limits: up to eight thermostats; up to eight humidistats; up to fifty door/window contact sensors; one sound alarm and one light alarm subsystem (with multiple lights); up to one hundred 115V, 10A power switches.

- Project and product limitations:
  - The product is a prototype to be completed within twelve months of inception and developed by a team of five engineers using the DigitalHomeOwner development process.
  - Cost minimization is required for all system elements (sensors, controllers, server, tools, etc.).
  - The system shall be tested and operated in a simulated environment; no physical home or devices are used. Simulations must reflect realistic physical properties and the constraints of actual homes, sensors, and controllers.
  - Major changes to requirements must be approved by the Director of the DigitalHomeOwner Division.

## 3.7 Software system attributes

### Reliability
- The system shall have no more than 1 failure per 10,000 hours of operation.
- All operations shall incorporate exception handling that returns clear, descriptive messages to the user when errors or exceptional conditions occur.

### Availability
- 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 DigitalHome Technician at system setup.
  - Upon failure (including power loss, loss of internet access, or other software/hardware failure), the recovery mechanism shall restore system data from the most recent backup.
- [N/A] Defined quantitative availability target (e.g., uptime percentage).

### Security
- Authentication and access control:
  - A DigitalHome user account shall be established upon installation.
  - Log in shall require entry of an account name and a password.
  - Role-based access shall be enforced: a Master User and a DigitalHome Technician shall have rights beyond a General User, including establishing user accounts, setting system parameters, and starting/stopping operation of the system.
- Communication security:
  - The web system shall provide authentication and information encryption through a recognized reliable and effective security technology, such as Transport Layer Security (TLS).
- Security monitoring and history:
  - The system shall retain data necessary to produce monthly reports for the past two years, including day and time of any security breaches (alarm activations).

### Maintainability
- The system shall be developed to support maintenance through:
  - Documentation of requirements, design, and code.
  - Use of abstraction, information hiding, and module independence in system design.
  - Conformance to IEEE standards [IEEE830, IEEE1008, IEEE1016, IEEE1028] and the HomeOwner Coding Standard [HO4710].
  - Design and implementation of prototype modules and components such that they may be incorporated into a fully specified commercial version.
  - Use of object-oriented development with UML 2.0 as the preferred method (exceptions require CIO approval).

### Safety
- Although no specific safety functions are mandated, high system reliability is required to avoid failures that could affect occupant safety (e.g., security breaches, inadequate lighting, inappropriate temperature/humidity for vulnerable individuals, or powering certain appliances when young children are present).

### Portability
- [N/A]

## 3.8 Supporting information

- Item a) Sample input/output formats, cost analysis studies, user surveys
  - Sample input formats: [N/A]
  - Sample output formats: [N/A]
  - Cost analysis studies or results: The project shall minimize costs of DH elements; the final project report shall describe efforts to minimize costs, including price comparisons between DH elements and comparable/competitive elements (3.3.5).
  - User surveys: [N/A]

- Item b) Supporting/background information to aid readers
  - Product intent and scope: Initial version is a limited prototype to support business decisions and is not a comprehensive or complete specification (Introduction; 3.1). Scope is limited to managing temperature, humidity, security, and power to small appliances and lighting via a web-ready device (3.1).
  - Operational context: User interacts via a personal web page on a DH web server or a local home server; the DH web server communicates through a home wireless gateway with sensors and controllers (3.1). An ISP is required (3.4.1). A DH home web server may be hosted on a home computer to provide interaction, data storage, user account management, and backups (3.4.2). The Gateway includes an RF module and operates up to a 1000-foot indoor range (3.4.3).
  - Environment/simulation: The prototype will be situated in a simulated environment; no physical home and all sensors/controllers are simulated, adhering to realistic properties and constraints (3.1; 3.3.6).
  - Key system elements: Thermostats, humidistats, magnetic contact switches, security sound/light alarms, and digital power switches (3.4.4).
  - Users and roles: General user; Master user with configuration rights; DH Technician responsible for setup/maintenance and with elevated rights (3.2.1–3.2.2).
  - Standards and practices: Compliance with ASHRAE standards for HVAC (4.2.5). Use of IEEE standards and HomeOwner Coding Standard; object-oriented development with UML 2.0 preferred (5.5.1; 5.6.2). Security via authentication and encryption (e.g., TLS) (5.4.1–5.4.2).
  - Supplementary documents: Digital Home Use Case Model [HO2010]; Digital Home High Level Requirements Definition [HLRD 2010].

- Item c) Problems to be solved by the software
  - Enable remote monitoring and control of home environmental parameters (temperature, humidity), security contacts/alarms, and the on/off state of small appliances and lighting via web-ready devices (4.1.1; 4.2; 4.3; 4.4; 4.5).
  - Provide scheduling of parameter settings (up to 24 hourly settings per day; monthly planner with up to four daily periods) and allow manual overrides (4.2.2.3; 4.3.2.3; 4.6.2.1–4.6.2.2).
  - Collect, store, and report historical data (daily averages, minima/maxima with times; security breach times; periods when the system was not in operation) for the past two years (4.6.3–4.6.3.3).
  - Ensure timely data acquisition and display updates; support wireless communication between devices and the master control; maintain a home database (4.1.5–4.1.6; 5.1.1–5.1.3).
  - Provide secure, reliable operation with authentication/encryption, backups, and recovery to mitigate safety impacts from failures (5.2; 5.3; 5.4).

- Item d) Special packaging instructions for code/media (security, export, initial loading, other)
  - [N/A]

- Status of whether the above supporting information items are part of the requirements
  - [N/A]

## 4.1 Functions

This section defines the planned verification approaches to qualify functional behavior. Verification will be conducted in the simulated environment defined for the prototype (no physical home; all sensors and controllers simulated). Methods include reviews and audits (IEEE 1028), V&V activities (IEEE 1012), and unit/component tests (IEEE 1008). Test cases are use-case driven (per Digital Home Use Case Model [HO2010]) and trace to the functional requirements for:
- General system functions (Sections 4.1.1–4.1.6)
- Thermostats (Section 4.2)
- Humidistats (Section 4.3)
- Security system (Section 4.4)
- Appliance management (Section 4.5)
- Planning and reporting (Section 4.6)

For each function group below, verification covers: a) input validity checks; b) operation sequences; c) abnormal situations; d) parameter effects; and e) input/output relationships.

- General system functions (web control, gateway communications, sensing, actuation, data storage)
  - a) Input validity checks
    - Authenticate login with account name and password; verify TLS-based protection is active when required.
    - Reject unsupported device types or unknown device identifiers.
    - Verify only authorized roles (Master User/Technician) can perform configuration actions.
  - b) Exact sequence of operations
    - Use-case tests validate end-to-end flows: user authentication → device selection → read/write request → gateway exchange → database persistence for readings/commands.
    - Verify sensor reads are stored before any derived reporting uses them.
  - c) Responses to abnormal situations
    - 1) Overflow: [N/A]
    - 2) Communication facilities: simulate loss of Internet access and wireless link drop; verify clear user-facing error messages (per 5.2.3) and no undefined actions occur while links are unavailable; verify recovery of operation after connectivity returns.
    - 3) Hardware faults and failures: simulate unreachable sensors/controllers; verify error is surfaced to the user and affected operations are skipped without side effects.
    - 4) Error handling and recovery: induce system failure scenarios (power loss, loss of Internet) and verify restoration from the most recent backup (per 5.2.2.2) and daily backup execution (per 5.2.2.1).
  - d) Effect of parameters
    - Verify configuration changes (default parameter settings, user accounts) take effect and are persisted.
  - e) Relationship of outputs to inputs
    - 1) Input/output sequences: verify that read requests return current device values and write requests result in corresponding controller commands via the gateway; verify values read are saved in the home database (4.1.5) prior to report generation.
    - 2) Formulas for input to output conversion: [N/A]

- Thermostat functions
  - a) Input validity checks
    - Boundary tests: reject setpoints outside 60–80 °F inclusive; accept one-degree increments only.
    - Verify Celsius/Fahrenheit mode selection is honored; reject invalid unit specifications.
    - Enforce at most eight thermostats and one thermostat per enclosed space.
  - b) Exact sequence of operations
    - Schedule tests: up to 24 one-hour settings per day, seven days; verify application at scheduled boundaries.
    - Manual override tests: verify manual setpoint holds until the end of the current planned/default period, then planned/default resumes.
    - Collective vs. individual control: verify independent and grouped operations behave as specified.
  - c) Responses to abnormal situations
    - 1) Overflow: [N/A]
    - 2) Communication facilities: simulate wireless loss during setpoint update; verify error message and no partial/duplicate application.
    - 3) Hardware faults and failures: simulate thermostat offline; verify status indicates unavailable and no control is attempted.
    - 4) Error handling and recovery: after failure and recovery, verify planned schedules and default settings are restored from backup.
  - d) Effect of parameters
    - Verify setpoint changes impact controller commands; verify unit toggling does not alter underlying setpoint intent.
  - e) Relationship of outputs to inputs
    - 1) Input/output sequences: setpoint input results in controller command dispatch and updated displayed temperature readings; scheduling input results in timed dispatches.
    - 2) Formulas for input to output conversion: [N/A]

- Humidistat functions
  - a) Input validity checks
    - Boundary tests: reject humidity setpoints outside 30–60% inclusive; accept 1% increments only.
    - Enforce at most eight humidistats and one per enclosed space.
  - b) Exact sequence of operations
    - Schedule tests: up to 24 one-hour settings per day; verify application timing.
    - Manual override tests: verify override holds until the end of the current planned/default period, then planned/default resumes.
  - c) Responses to abnormal situations
    - 1) Overflow: [N/A]
    - 2) Communication facilities: simulate wireless interruption; verify graceful failure and clear messaging.
    - 3) Hardware faults and failures: simulate humidistat offline; verify detection and safe behavior.
    - 4) Error handling and recovery: verify restoration of schedules/defaults from backup after recovery.
  - d) Effect of parameters
    - Verify humidity setpoints drive appropriate control commands to humidification/dehumidification.
  - e) Relationship of outputs to inputs
    - 1) Input/output sequences: setpoint and schedule inputs produce timely controller actions and updated readings.
    - 2) Formulas for input to output conversion: [N/A]

- Security system functions
  - a) Input validity checks
    - Enforce limits: up to 50 door/window contact sensors; reject registrations beyond the limit.
    - Verify valid sensor states (OPEN/CLOSED); reject malformed states.
  - b) Exact sequence of operations
    - Verify that when a monitored contact is set OPEN while active, the alarm system is activated (one sound alarm and one light alarm subsystem with multiple lights).
  - c) Responses to abnormal situations
    - 1) Overflow: [N/A]
    - 2) Communication facilities: simulate missed sensor transmissions; verify alarm is not triggered without a valid OPEN event and that a communication error is reported.
    - 3) Hardware faults and failures: simulate failed contact sensor; verify its status is reported and system continues monitoring others.
    - 4) Error handling and recovery: verify alarm state consistency across failures and accurate restoration from backup; verify report of breach times remains accurate.
  - d) Effect of parameters
    - Verify planner-configured arming/monitoring periods affect which contacts trigger alarms.
  - e) Relationship of outputs to inputs
    - 1) Input/output sequences: OPEN input during active monitoring leads to immediate alarm activation; CLOSED clears only per system rules.
    - 2) Formulas for input to output conversion: [N/A]

- Appliance management functions
  - a) Input validity checks
    - Enforce up to 100 power switches at 115V/10A; reject excess devices.
    - Accept only OFF/ON commands and states; reject invalid commands.
  - b) Exact sequence of operations
    - Verify command to change state propagates to the correct switch and confirms the new state.
    - Manual override tests: verify manual state holds until the end of the current planned/default period, then planned/default resumes.
  - c) Responses to abnormal situations
    - 1) Overflow: [N/A]
    - 2) Communication facilities: simulate command transmission failure; verify error is shown and no unintended toggling occurs.
    - 3) Hardware faults and failures: simulate switch device failure; verify detection and safe reporting of unknown state.
    - 4) Error handling and recovery: verify switch states and plans are consistent with restored data after recovery.
  - d) Effect of parameters
    - Verify planned time periods change appliance states as specified.
  - e) Relationship of outputs to inputs
    - 1) Input/output sequences: OFF→ON and ON→OFF commands update reported state and, in simulation, the connected appliance state.
    - 2) Formulas for input to output conversion: [N/A]

- Planning and reporting functions
  - a) Input validity checks
    - Verify monthly plan creation/modification only for valid month/year; enforce up to four daily time periods; reject ill-formed plans.
    - Verify overrides via website or manual devices are captured and marked as overrides.
  - b) Exact sequence of operations
    - Verify execution order: plan evaluation at time boundaries → command dispatch → data logging; verify override precedence until period end, then return to planned/default values.
  - c) Responses to abnormal situations
    - 1) Overflow: [N/A]
    - 2) Communication facilities: during plan execution with connectivity loss, verify errors are reported and missed actions are evident in the monthly report’s “system not in operation” periods.
    - 3) Hardware faults and failures: simulate unavailable devices during scheduled actions; verify failures are recorded and do not block other scheduled actions.
    - 4) Error handling and recovery: verify daily backups occur; after failure, verify plans and historical data restore from the most recent backup; verify report section indicating periods when the DH System was not in operation (4.6.3.3).
  - d) Effect of parameters
    - Verify that plan parameters (temperature, humidity, contact sensors, power switches) drive the corresponding subsystem behaviors at the specified times.
  - e) Relationship of outputs to inputs
    - 1) Input/output sequences: month plan inputs yield time-ordered device commands and expected state/readout changes; overrides alter the sequence until the current period ends.
    - 2) Formulas for input to output conversion: [N/A] (daily averages, maxima/minima are required, but specific formulas are not provided in the SRS; verification will compare outputs to known injected datasets without prescribing formulas)

All functional tests will include positive, boundary, and negative cases and will verify the presence of clear, descriptive error messages per 5.2.3.

## 4.2 Performance requirements

The following verification activities and acceptance criteria qualify the performance requirements in Section 3.2 (as derived from original SRS 5.1 Performance Requirements and related constraints). Tests are executed in the simulated home environment defined in the SRS.

- PR-1: Display refresh period ≤ 2 s
  - Requirement source: 5.1.1
  - Method: System test. Drive sensor/controller state changes at known times; observe UI/API displays on a web-ready client connected to the DH web server and gateway.
  - Measurement: Timestamp successive value presentations per environmental variable (temperature, humidity, contact sensors, power switches) and compute inter-update intervals.
  - Acceptance: For each displayed environmental condition, the interval between successive updates is ≤ 2 seconds while the system is operational.

- PR-2: Sensor data acquisition rate ≥ 10 Hz
  - Requirement source: 5.1.2
  - Method: Integration test at gateway/controller boundary. Inject a time-stamped stimulus (e.g., step or waveform) from the sensor simulators; record acquisition timestamps in the home database or gateway logs.
  - Measurement: Compute intervals between consecutive acquisitions per sensor stream over a continuous run.
  - Acceptance: For each sensor type, the time between consecutive acquired samples is ≤ 100 ms (i.e., ≥ 10 Hz) for the duration of the test.

- PR-3: Wireless communication range up to 1000 ft (indoor)
  - Requirement sources: 5.1.3, 3.4.3.3
  - Method: System test in a simulated indoor RF environment adhering to home physical constraints (per 3.3.6). Emulate/path-loss equivalent to distances from near to 1000 ft between gateway and each device type; execute read (sensor) and write (controller) operations.
  - Measurement: Successful completion of command/telemetry exchanges at test distances; log connectivity status and message success.
  - Acceptance: At all distances ≤ 1000 ft, the system establishes and maintains communications and successfully reads sensor values and applies controller commands.

- Capacity and workload items (static/dynamic) not specified in the SRS requirements baseline
  - Number of terminals to be supported: [N/A]
  - Number of simultaneous users to be supported: [N/A]
  - Amount and type of information to be handled (throughput/volume constraints): [N/A]
  - Normal and peak transaction/task rates and data volumes: [N/A]

General verification notes:
- Evidence: Time-synchronized logs, test scripts, and summary reports capturing methods, raw measurements, and pass/fail determinations against the stated acceptance criteria.
- Environment: Simulated home and device environment as mandated by the SRS; no physical home is required.

## 4.3 Usability requirements

This section describes the planned verification approaches and methods to qualify usability and quality-in-use aspects explicitly stated in the SRS. Where the SRS does not define measurable usability objectives, [N/A] is recorded.

- Task-based usability evaluation of core user tasks (related to 3.2.1.3, 4.1.1, 4.2, 4.3, 4.4, 4.5, 4.6)
  - Method: Conduct moderated usability sessions with representative General Users performing primary tasks via the web interface on a web-ready device, including:
    - Read/set thermostat temperature; schedule hourly settings; switch between Fahrenheit/Celsius.
    - Read/set humidity; schedule hourly settings.
    - Arm/disarm security; interpret and respond to a breach notification.
    - View/toggle appliance power switch states.
    - Create/modify a month plan; override planned parameters via the website.
  - Evidence: Task scripts, observation notes, recordings, issues list, and qualitative user feedback.
  - Outcome assessed: Task completion and user-reported ease of use in the supported contexts of use.

- Error and exception message clarity (5.2.3)
  - Method: Fault-injection test cases across UI workflows to trigger representative errors and exceptional conditions; expert UI text review for clarity and actionability; think-aloud tests with users encountering injected errors.
  - Evidence: Test logs, screenshots of messages, review checklists, user feedback summaries.
  - Outcome assessed: Messages are clear and descriptive to users.

- Online user documentation presence and content (5.7.1, 5.7.1.1–5.7.1.3)
  - Method: Documentation inspection against a checklist verifying:
    - Availability of online documentation within the system.
    - Presence of an FAQ section.
    - Presence of explanations of how parameters are set and sensor values are read, including stated limitations and constraints.
    - Presence of instructions for using the DH Planner.
  - Method: UI findability check to ensure documentation is accessible from relevant screens.
  - Evidence: Completed checklists, URLs/links captured, screenshots.
  - Outcome assessed: Required documentation exists, is accessible, and covers the specified content.

- Usability to support avoidance of harm in use (5.3, with supporting behaviors from 5.2.2, 5.2.3, 4.6.2.2)
  - Method: Scenario-based walkthroughs and dry runs of risk-relevant contexts (e.g., security breaches, inadequate lighting, temperature/humidity overrides), verifying that the UI communicates conditions, warnings, and next steps clearly and that overrides are understandable.
  - Method: Recovery/drift scenarios (e.g., after backup/restore or recovery from failure) to verify that the user can understand system state and safely resume operation.
  - Evidence: Scenario descriptions, walkthrough notes, identified usability risks and mitigations.
  - Outcome assessed: User-facing guidance supports safe user action in the specified contexts.

- Quantitative usability targets for effectiveness (task success criteria) [N/A]

- Quantitative usability targets for efficiency (time-on-task, steps) [N/A]

- Quantitative satisfaction targets (ratings, SUS/NPS) [N/A]

- Accessibility requirements (e.g., conformance levels, assistive technology support) [N/A]

## 4.5 Logical database requirements

This subsection defines how the logical database requirements will be verified. The methods are aligned to the information items a) through g) and will be conducted in the simulated environment specified for the prototype.

General verification approach
- Techniques: document inspection/review, schema validation, functional tests, data-driven tests (boundary and negative), performance tests, and backup/restore drills.
- Environment: DH home web server and simulated sensors/controllers per 3.3.6; communication via the DH Gateway; user access via web UI.
- Test data: simulated streams for temperature, humidity, contact sensors, and power switches at rates required by 5.1.2; plans and overrides created through the Planner.

a) Types of information used by various functions
- Review: Inspect the data model/data dictionary to confirm presence of entities required by functions in 4.1–4.6, including at least: user accounts, device registry (thermostats, humidistats, contact sensors, alarms, power switches), environmental readings, schedules/plans, overrides, security events/alarms, monthly report aggregates, backup metadata, and system downtime periods (4.6.3.3).
- Tests: For each function that stores or reads data (monitor/control, planning, reporting, backup), execute CRUD scenarios through the web interface and APIs. Verify that:
  - Sensor values are persisted when read (4.1.5).
  - Controller settings and overrides are stored and later take effect as specified (4.2.2.4, 4.3.2.2, 4.6.2.2).
  - Planner data (temperature, humidity, contact sensors, power switches) is stored per 4.6.2.1.
  - Security breaches generate alarm events (4.4.2) and are recorded for reporting (4.6.3.2).
- Acceptance: All required information types are represented in the schema and persist/retrieve correctly to support the corresponding functions.

b) Frequency of use
- Performance/data-rate tests: Simulate up to the maximum counts (thermostats ≤8, humidistats ≤8, contact sensors ≤50, power switches ≤100) with sensor acquisition at ≥10 Hz (5.1.2) and verify the database can sustain write throughput without loss or reordering; verify displays update at least every 2 seconds (5.1.1) when reading from stored data.
- Backup schedule: Configure daily backup (5.2.2.1); verify backups occur at the configured time and contain all required data.
- Acceptance: No dropped or late writes under the specified loads; timestamp ordering preserved; backup artifacts produced daily.

c) Accessing capabilities
- Functional tests:
  - Latest-value access: Retrieve most recent readings per device for UI updates (4.1.1, 5.1.1).
  - Historical/time-window access: Query readings and events over arbitrary day/month windows to support reporting (4.6.3, 4.6.3.1–4.6.3.3).
  - Aggregations: Compute daily averages, maxima with times, and minima with times per device and compare to independently computed results (4.6.3.1).
  - Configuration access: Create/modify user accounts and system parameters (3.4.2.1.c, 3.2.1.4, 3.2.2.4).
  - Backup/restore access: Execute backup and restore operations (5.2.2.1–5.2.2.2).
- Acceptance: All access patterns return complete and correct results; backup and restore interfaces are operable and produce consistent data.

d) Data entities and their relationships
- Schema review: Validate entity relationships needed by the functions, including:
  - Each reading references exactly one valid device; each device belongs to one DigitalHome installation.
  - Plans/schedules associate with specific devices and time periods (4.2.2.3, 4.3.2.3, 4.6.2.1).
  - Security events link to the triggering contact sensor and to the corresponding alarms (4.4.1–4.4.2).
  - Downtime intervals are linked to the system installation for reporting (4.6.3.3).
- Referential integrity tests: Attempt to create orphaned readings/events; attempt to delete devices with dependent data; verify schema prevents referential breaks.
- Acceptance: All critical relationships are present and enforced; no orphaned or dangling references are possible through application interfaces.

e) Integrity constraints
- Boundary and enumeration tests:
  - Thermostat set points: enforce 60–80 °F inclusive at 1 ° increments or valid Celsius equivalent (4.2.1.2, 4.2.4).
  - Humidity set points: enforce 30%–60% inclusive at 1% increments (4.3.1.2).
  - Sensor physical ranges: accept/store temperatures within 14–104 °F; handle out-of-range inputs with exceptions logged (3.4.4.1.c, 5.2.3).
  - Device counts: enforce maxima for thermostats (≤8), humidistats (≤8), contact sensors (≤50), power switches (≤100) per installation (4.2.2, 4.3.2, 4.4.1.1, 4.5.2).
  - Schedules: enforce up to 24 one-hour settings per day per thermostat/humidistat (4.2.2.3, 4.3.2.3) and up to four daily time periods in the monthly planner (4.6.2.1).
  - States/enums: OFF/ON for power switches (4.5.3–4.5.4); OPEN/CLOSED for contacts.
- Temporal rules:
  - Manual overrides persist until the end of the current planned/default period (4.2.2.4, 4.3.2.2, 4.5.5, 4.6.2.2). Verify by recording state transitions and effective intervals.
- Acceptance: Database constraints and application logic prevent invalid inserts/updates; boundary values are accepted; out-of-range values are rejected with clear error messages (5.2.3).

f) Security
- Authentication: Verify that login (account name and password) is required before any database-backed operation (5.4.2). Attempt unauthorized operations and confirm denial.
- Transport security: Verify that all web interactions that transmit or mutate DH data are protected with Transport Layer Security or equivalent (5.4.1).
- Authorization/roles: Verify that only the Master User and DH Technician can create user accounts, change configuration, set system parameters, or start/stop operation (3.2.1.4, 3.2.2.4); general users cannot.
- Backup access control: Verify that backup/restore functions are available only to authorized roles (3.4.2.1.d, 5.2.2.1–5.2.2.2).
- Data-at-rest protection: [N/A]
- Acceptance: All specified security controls function as required; unauthorized access is prevented; secure transport is enforced.

g) Data retention requirements
- Historical availability: Populate simulated data and verify that monthly reports can be generated for any month/year within the past two years and contain all required metrics and events (4.6.3, 4.6.3.1–4.6.3.3).
- Backup/restore: Execute a failure simulation (power loss or network loss) and verify restoration from the most recent daily backup with no loss beyond that point (5.2.2.2).
- Retention/archival beyond two years: [N/A]
- Acceptance: Required two-year reporting horizon is met; recovery meets the daily backup objective.

## 4.6 Design constraints

This section defines how the project will verify compliance with the design constraints defined for the system.

- Development timeline and team composition
  - Constraint: Prototype completion within twelve months; five-engineer team with provided management support.
  - Verification methods: Schedule and milestone reviews; progress audits; delivery acceptance by planned completion date; staffing roster audits.
  - Evidence: Approved project plan and baseline; milestone review minutes; release/delivery record dated within the 12-month window; staffing logs.

- Use of DigitalHomeOwner development process
  - Constraint: Use the development process specified by DigitalHomeOwner Inc.
  - Verification methods: Process compliance audits; artifact inspections against prescribed process templates and checkpoints.
  - Evidence: Approved SOP/process checklist; completed phase-gate checklists; SQA audit reports.

- Use of widely used, accepted, and available technology and standards
  - Constraint: Employ widely used, accepted, and available hardware/software technology and standards for product elements and development tools.
  - Verification methods: Design and toolchain reviews against a compliance checklist; market availability check; COTS selection justification review.
  - Evidence: Technology selection reports; standards references cited in design; BOM/tool list with availability notes; review sign-offs.

- Cost minimization of DH elements
  - Constraint: Minimize costs of sensors, controllers, server, tools; provide price comparisons in the final report.
  - Verification methods: Management review of cost analysis; procurement audit; comparison analysis inspection.
  - Evidence: Cost comparison matrices; procurement records; final report section on cost minimization with approvals.

- Simulated test environment
  - Constraint: All testing in a realistic simulated environment with no physical home; simulations adhere to physical properties and constraints of actual homes and devices.
  - Verification methods: Simulation model validation (SMV) review; test environment qualification; targeted tests showing adherence (e.g., signal range, sensor accuracy).
  - Evidence: Simulation design and validation documentation; environment qualification report; test results demonstrating modeled constraints.

- Change control governance
  - Constraint: Major requirements changes must be approved by the Director of the DigitalHomeOwner Division.
  - Verification methods: Configuration management (CM) audits; change request (CR) sampling; traceability checks for approvals.
  - Evidence: CR records with Director approval; CCB minutes; CM audit reports.

- Operational dependence on ISP
  - Constraint: Home system requires a widely available ISP (e.g., cable, high-speed DSL).
  - Verification methods: Integration tests over representative ISP configurations or emulations; connectivity and throughput demonstrations.
  - Evidence: Test reports showing successful operation over sample ISP conditions; network configuration logs.

- Gateway device communications and RF constraints
  - Constraint: Gateway connects to broadband Internet; contains RF module; supports indoor transmission up to 1000 feet.
  - Verification methods: Communication tests (Internet and RF) in simulation with distance modeling; boundary and degradation tests near 1000 feet.
  - Evidence: RF/communication test results; simulation configuration showing range enforcement; test logs.

- Sensor and controller physical constraints
  - Constraint: Thermostat sensor sensitivity 14°F to 104°F; humidistat setpoint 30%–60% with 1% increments; capability/use constraints for contacts, alarms, and power switches as specified.
  - Verification methods: Unit and integration tests using simulated inputs across specified ranges; setpoint boundary tests; negative tests for out-of-range values.
  - Evidence: Test cases and results covering min/nominal/max and out-of-range; requirements-to-test traceability.

- HVAC standards compliance
  - Constraint: Compatibility with centralized HVAC (gas, oil, electricity, solar, or combinations); adherence to ASHRAE standards, policies, and procedures.
  - Verification methods: Compliance matrix mapping design/operation to applicable ASHRAE items; expert/peer review; supplier interface specification review.
  - Evidence: Approved ASHRAE compliance matrix; review minutes with sign-off; interface specifications.

- Security protocol use
  - Constraint: Authentication and information encryption via a recognized technology such as TLS.
  - Verification methods: Configuration and code inspection; protocol scans; penetration testing of authentication and transport security; cipher configuration review.
  - Evidence: Security test reports; TLS scan outputs; configuration files/screenshots; security review sign-offs.

- Engineering standards and coding/documentation rules
  - Constraint: Use IEEE standards (e.g., IEEE 830/1008/1016/1028/1012) and HomeOwner Coding Standard HO4710; documentation follows HO2305 and is archived.
  - Verification methods: SQA audits of documents and code; design and code reviews against standards checklists; archive verification.
  - Evidence: Completed checklists; review minutes; archive index entries; compliance audit reports.

- Development methodology constraints
  - Constraint: Object-oriented development using UML 2.0 is preferred; exceptions require CIO approval.
  - Verification methods: Design artifact inspection for UML 2.0 models; exception register review for CIO approvals.
  - Evidence: UML model repository; exception approvals; methodology compliance report.

- User documentation content
  - Constraint: Online user documentation must include FAQ, parameter setting/reading explanations (including limits/accuracy), and DH Planner usage.
  - Verification methods: Documentation content review against checklist; usability walkthroughs; publication check.
  - Evidence: Published help/FAQ; documentation review checklist with approvals.

- Wireless communication distance for devices
  - Constraint: Environmental devices must be within 1000 feet of the master control device to communicate.
  - Verification methods: Simulation-based communication tests across distance; boundary and failure behavior tests beyond 1000 feet.
  - Evidence: Test logs showing success within and failure beyond the range; simulation parameters.

- Backup and recovery approach documentation
  - Constraint: Incorporate backup and recovery mechanisms (daily backups; restore from most recent backup after failures).
  - Verification methods: Procedural review; backup/restore drills; failure injection tests.
  - Evidence: Backup schedule/configuration; drill reports; recovery test results.

[N/A]

## 4.7 Software system attributes

This section defines the planned verification approaches and methods to qualify the software system attributes in parallel with the corresponding requirements. All dynamic tests will be executed in the simulated environment described for this prototype.

### a) Reliability

- 5.2.1 MTBF (≤ 1 failure per 10,000 operating hours)
  - Method: long-duration soak testing in the simulator under typical and stress workloads; failure logging and classification; statistical analysis of aggregated operating hours across test instances.
  - Evidence: test logs of operating time and failure events; analysis report estimating failure rate versus the stated limit.
  - Acceptance: no more than one software failure observed per 10,000 aggregate operating hours, or analytical demonstration consistent with this requirement.

- 5.2.2 Backup and recovery
  - 5.2.2.1 Daily backup
    - Method: configuration of backup time; observation of at least seven consecutive daily backup executions; content verification for configuration, default parameter settings, planning, and usage data.
    - Evidence: scheduled task configuration, backup artifacts with timestamps, content checklists or checksums.
    - Acceptance: backups occur once per day at the configured time and include all required data categories.
  - 5.2.2.2 Recovery from most recent backup
    - Method: fault injection covering power loss, loss of Internet access, and controlled software/hardware failure in the simulator; system restart and data restoration procedure execution.
    - Evidence: recovery logs; pre-/post-failure data comparisons showing restoration from the most recent backup.
    - Acceptance: after each induced failure, the system restores required data from the most recent backup.

- 5.2.3 Exception handling with clear, descriptive messages
  - Method: negative and fault-injection tests across operations (e.g., invalid inputs, device unavailability, network faults); UI/API message inspection.
  - Evidence: catalog of triggered exceptions and corresponding user-facing messages.
  - Acceptance: each exercised exceptional condition results in a non-ambiguous, descriptive message; no unhandled exceptions or crashes.

### b) Availability

- Defined availability level and mechanisms beyond backup/recovery: [N/A]

(Note: restart and recovery behaviors are verified under reliability, per 5.2.2.)

### c) Security

- 5.4.1 Account establishment at installation; authentication and encryption via a recognized technology (e.g., TLS)
  - Method: installation procedure test to confirm creation of a user account; connection security testing to ensure all authenticated sessions use TLS; inspection of certificate handling; attempt cleartext access to confirm rejection.
  - Evidence: installation logs showing account creation; network captures confirming TLS in use; server configuration evidencing TLS enablement.
  - Acceptance: at least one user account exists post-installation; all authenticated traffic is protected by TLS; non-TLS access is rejected for authentication and session traffic.

- 5.4.2 Login requires account name and password
  - Method: functional positive/negative tests (valid, invalid, empty, and malformed credentials); session management checks.
  - Evidence: authentication test logs; defect logs for any bypass attempts.
  - Acceptance: access is granted only with valid account name and password; all other attempts are denied.

- Additional security items (logs/history, module separation of duties, restricted inter-module communications, integrity checks for critical variables, explicit data privacy requirements): [N/A]

### d) Maintainability

- 5.5.1 Methods and techniques for maintainability
  - 5.5.1.1 Documentation of requirements, design, and code
    - Method: document audits at milestones and at completion for presence, completeness, and consistency of SRS, design descriptions, and source documentation.
    - Evidence: approved document checklist; traceability between requirements, design, and code.
    - Acceptance: all required documents exist, are current, and mutually consistent.
  - 5.5.1.2 Use of abstraction, information hiding, and module independence
    - Method: architecture and design reviews; code inspections focusing on coupling/cohesion and encapsulation; static analysis for dependency structure.
    - Evidence: review records with findings/resolutions; static analysis reports.
    - Acceptance: design and code demonstrate low coupling, adequate cohesion, and encapsulation consistent with the stated practices.
  - 5.5.1.3 Use of IEEE standards and HomeOwner Coding Standard [HO4710]
    - Method: process and artifact compliance audits against cited standards; automated and manual code style checks.
    - Evidence: compliance audit reports; code style analysis outputs.
    - Acceptance: no material nonconformities to referenced standards and coding guidelines.

- 5.5.2 Prototype components suitable for incorporation in a commercial version
  - Method: architectural conformance review for separable modules, clean interfaces, and absence of prototype-only dependencies; build/packaging tests demonstrating modular reuse.
  - Evidence: design review records; build artifacts showing modules can be integrated independently.
  - Acceptance: modules exhibit clear interfaces and no hard-wired prototype constraints that would preclude reuse.

- 5.6 Business rules (documentation archive and format; OO development with UML 2.0; exceptions approval)
  - Method: end-of-project artifact audit for presence in the HomeOwner Document Archive and compliance with [HO2305]; design artifact review verifying UML 2.0 usage; verification of any approved exceptions by the CIO if applicable.
  - Evidence: archive index, document metadata, UML models.
  - Acceptance: all specified artifacts archived in the required format; UML 2.0 used; any deviations carry documented approval.

- 5.7 User documentation (online help, FAQ, parameter setting/limitations, planner usage)
  - Method: content inspection against the specified topics; link and context checks from the UI; usability spot-checks for findability.
  - Evidence: documentation content checklist; screenshots or captures.
  - Acceptance: all required topics are present, accurate, and accessible from the system.

### e) Portability

- Host/OS/compiler/language portability targets and measures: [N/A]

## 5.1 Assumptions and dependencies

- Prototype and simulation context: The initial release is a limited prototype operated in a simulated home; all sensors and controllers are simulated and the simulation adheres to realistic physical properties. Moving to a physical deployment would change requirements (e.g., device interfacing, safety, certification).
- Scope limitation: Functionality is limited to managing temperature, humidity, security (contacts/alarms), and power to small appliances and lighting. Expanding or reducing scope would alter functional requirements.
- User access model: All interaction occurs via a web interface served by a DigitalHome web server or an optional home web server; users have web-ready devices (computer, cell phone, PDA) and are familiar with basic web operations. Changes to the access model (e.g., native apps, voice, offline UI) would affect requirements.
- Internet connectivity: A broadband ISP is available at the home to support remote access and server communications. Loss or unavailability of broadband would necessitate different connectivity and availability requirements.
- Gateway and wireless communication: A DH Gateway device with an RF module is available and provides indoor wireless communication up to 1000 feet; all devices reside within this range. Different wireless technologies, ranges, or home layouts would change communication and performance requirements.
- Device capacity limits: Maximum device counts (up to 8 thermostats, 8 humidistats, 50 contact sensors, 100 power switches) reflect expected residential scale. Larger or smaller deployments would require revised capacity and possibly performance requirements.
- HVAC environment: Homes use centralized HVAC systems (gas, oil, electric, solar, or combinations) and ASHRAE practices apply. Non-centralized or incompatible HVAC types would change control and compatibility requirements.
- Electrical standards: Managed power switches are 115V, 10A. Different regional electrical standards or appliance loads would change device management and safety requirements.
- Environmental ranges: Thermostat sensor sensitivity (14°F to 104°F) and control range (60°F–80°F), and humidistat control range (30%–60%) match typical residential conditions. Different climate or comfort targets would alter control ranges and sensor requirements.
- Data storage and retention: The home (or DH) server stores configurations, backups, plans, and at least two years of historical data for reporting. Adequate persistent storage and reliable backup facilities are assumed; different retention or storage capabilities would change requirements.
- Security technology: Authentication and encryption rely on Transport Layer Security (TLS) supported by the servers and user devices. If TLS is unavailable or policies mandate alternative technologies, security requirements would change.
- Roles and setup: A trained DH Technician (or designated Master user) is available to install, configure, and maintain the system, including setting backup schedules and user accounts. Absence of this role would require additional self-service setup and support requirements.
- Technology availability and standards: The solution relies on widely used, accepted, and available hardware/software and standards. Unavailability or substitution of technologies or standards would impact interfacing and possibly functional requirements.
- Performance dependencies: Achieving a 10 Hz sensor acquisition rate and updating displays at least every two seconds depends on sensor hardware capabilities and home/network throughput. Different hardware/network performance would require revising performance requirements.
- Planning/reporting granularity: The monthly planner with up to four daily periods and the two-year reporting horizon are assumed sufficient for user needs. Different planning granularity or reporting horizons would change functional and storage requirements.

## 5.2 Acronyms and abbreviations

- ANSI — American National Standards Institute
- ASHRAE — American Society of Heating, Refrigerating and Air-Conditioning Engineers
- CIO — Chief Information Officer
- DH — Digital Home (prototype smart home product)
- DSL — Digital Subscriber Line
- FAQ — Frequently Asked Questions
- HLRD — High Level Requirements Definition
- 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
- TLS — Transport Layer Security
- UML — Unified Modeling Language
- °C — degrees Celsius
- °F — degrees Fahrenheit
- Hz — Hertz