Team Skill 5: Refining the System Definition


HOLIS Sample Use Case: Control Light








Initial creation of Control Light use case




Added second pre-condition to clarify operation

Gavin, QA lead

Brief Description

This use case prescribes the way in which lights are turned on and off and also how they are dimmed and brightened in accordance with how long the user presses a button on the Control Switch.

Basic Flow

Basic flow begins when the Resident presses the On/Off/Dim button on the Control Switch. When the Resident removes pressure on the On/Off/Dim button within the timer period, the system "toggles" the state of the light as follows .

  • If the light is On, the light is then turned Off, and there is no illumination .

  • If the light is Off, the light is then turned On to the last remembered brightness level.

End of basic flow.

Alternative Flow of Events

When the Resident holds down the On/Off/Dim button for more than 1 second, the system initiates a brightening/ dimming activity for the room's Light Bank.

While the Resident continues to press the On/Off/Dim button:

  1. The brightness of the controlled light is smoothly increased to a system-wide maximum value at a rate of 10 percent per second.

  2. When the brightness reaches its maximum value, the brightness of the controlled light is then smoothly decreased to a system-wide minimum value at a rate of 10 percent per second.

  3. When the brightness reaches its minimum value, the use case continues at subflow step 1.

When the Resident releases the On/Off/Dim button:

  1. The use case terminates and the brightness stays at the current level.

Pre-conditions for Control Light Use Case
  • The selected On/Off/Dim button must be Dim Enabled.

  • The selected On/Off/Dim button must be preprogrammed to control a Light Bank.

Post-condition for Control Light Use Case

On leaving this use case, the system remembers the current brightness level for the selected On/Off/Dim button.

Extension Points


Special Requirements

Performance : For any action that is perceptible to the Resident, the response time from a control panel action to system response must be less than 50 milliseconds .

HOLIS Central Control Unit Supplementary Specification

For brevity, we present excerpts from the HOLIS supplementary specification here. Appendix D in this book contains a generic, annotated supplementary specification template you might wish to adopt.


1 Introduction

1.1 Purpose

This is the supplementary specification for the v1.0 release of the HOLIS Central Control Unit (CCU) subsystem.

1.2 Scope

This specification is for the CCU only

1.3 References

  • HOLIS Vision Document

  • HOLIS System Level Hardware Specification

  • HOLIS System-Level Use-Case Model

  • HOLIS Control Switch Use-Case Model and Supplementary Specification

  • HOLIS PC Programmer Use-Case Model and Supplementary Specification

1.4 Assumptions and Dependencies

2 Functionality

SR1. OnLevel illumination parameter. Each controlled lighting bank that is Dim Enabled is controlled by the parameter OnLevel, which controls the percent of illumination to the light. The nine possible OnLevel settings are 10%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, and 90%.

SR2. The system supports up to 255 event-time schedules. The allowable programming precision of an event-time schedule shall be 1 minute.

SR3. Event-time schedules can be programmed on either a 12-hour or a 24- hour clock. The user shall enter the data in the following format:

 Event number (1256), Time of day (in 24-hour HH:MM format) 

SR4. Message protocol from Control Switch. Each button press on the control initiates a single 4-byte message to the CCU. The message protocol is as follows.

Address of sending device

Message number



The data fields in the message are mapped as follows.

SR4.1. Address 0 “254, the logical address of the specific control switch sending the message

SR4.2. Message Number 0 “255. Message numbers supported are

  1. Normal key press

  2. Emergency

  3. Held down for the last 0.5 second

SR4.3. graphics/bit_icon.gif Data , each bit corresponding to a specific button on the key switch.

SR4.4. Message Acknowledgment. In reply to the message from the Control Switch, the CCU shall respond with the following message.



Received data


where 55 (hex) is the dedicated address of the CCU, FF (hex) is the Acknowledge Message code, Received data returns the data byte received from the CCU, and Checksum is the calculated checksum for the returned message.

3 Usability

4 Reliability

SR9. System availability must be greater than or equal to 99.99%.

SR10. The CCU shall have no defects that can interfere with normal operation of the homeowner 's residence.

5 Performance

SR11. HOLIS shall execute event-time schedules with an accuracy of 1 minute ±5 seconds as measured by the system clock.

6 Supportability

7 Design Constraints

DC1. Control subsystem design is based on the controller module from the ALSP product line. BIOS should not be modified unless absolutely necessary.

DC2. The use case and supporting infrastructure for the emergency sequence must be validated to the highest reasonable commercial reliability standards.

8 Documentation Requirements

SR27. HOLIS ships with a Product Guide. The Product Guide contains all application guides, process guides, installation guides, tutorials, and glossary. The Product Guide is created as an HTML online guide. All applications needing to reference help link to the Product Guide. Microsoft Word copies of each of the guide sections are also shipped with the product.

SR29. The Installation Guide found in the Product Guide is also printed and shipped with the CD-ROM.

9 Purchased Components

10 Interfaces

10.1 User Interfaces

10.2 Hardware Interfaces

10.3 Software Interfaces

10.4 Communications Interfaces

11 Licensing, Security, and Installation Requirements

11.1 CCU Licensing Requirements

SR53. CCU software is factory installed and there are no user licensing or installation requirements.

11.2 Sublicensing Requirements

SR54. The Datamatch Java Library from the Oxford Foundation is incorporated in the application. The end user documentation included with the redistribution must include the following acknowledgment.

This product includes software developed by the Oxford Software Foundation ( ).

Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.

12 Legal, Copyright, and Other Notices

SR72. All code, product documents, online help, user interfaces, and About dialogs must contain the following copyright message.

Copyright 2003-2004 Lumenations, Ltd. All rights reserved.

SR75. Flash the standard corporate copyright notice, corporate logo, and HOLIS product logo for a minimum of 5 seconds during startup mode.

SR76. In idle mode, (when no programming is active), the display shall show the HOLIS logo.

13 Applicable Standards

14 Internationalization and Localization

SR89. All data processing components support UTF-8 character encoding.

SR90. All output text files must be ISO-8859-1 and “2 encoded. This supports all Latin-1 and Cyrillic languages.

SR97. The following are acceptable input content text file encodings: ASCII, Latin-1&2 (ISO-8859-1&2), UTF-8.

15 Physical Deliverables

16 Installation and Deployment

Appendix A Glossary


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: