Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 85
Текст из файла (страница 85)
° ЯКЗ. Поддержка до 255 зависящих от времени графиков событий (етепп11пэе.асЬес$п1ея). ЗК3.1. Допустимая программируемая точность временных графиков со. бытий должна составлять 1 минуту. ЗК3.2. НОБ13 должна выполнять временной график событий с точно. стью до 1 минуты хб секунд по системным часам. ЗВЗ.З.
Графики могут программироваться как для 12, так и для 24 часовых форматов. Пользователь должен вводить данные в следующем формате. 396 Пряложеиия ЗК3.3.1. Номер события (1-256), Время дия (в 24-х часовом Формате НН:ММ). ЗК3.3.2. Затем для каждого осветительного банка, на который повлияет событие, пользователь должен указать следующие данные, чтобы завершить создание графика. 1Росветнтельиого Действие(вкл, выкл, ОпЬете1) (вводится как% баыка от максимального с 10%-прирыцеииями) Выкл 54 73 ЗКЗД.З.
После окончания введения даыных пользователь должен нажать клавишу <Епс)>, чтобы сигнализировать, что задание графикаокончено. ° ЗК4, Протокол сообпзеиий от "Управления включением" (пульта), Каждое нажатие кнопки пульта инициирует 4-байтовое сообщение ЦБУ. Ниже представлено, как выглядит протокол сообщения. Адрес устройства- Номер сообщения Данные Контрольная сумма отправителя Поля сообщения иытерпретируются следующим образом.
ЗК4.1. Адрес 0-254, логический адрес конкретной кнопки пульта, от которой исходит сообщение. ЗК4.2. Номер сообщения 0-255. Осуществляется поддержка следующих номеров сообщеыий. 1. Нажатие обычыой клавиши 2. Чрезвычайная ситуация 3. Была в нажатом состоянии последние 0.5 секунды ЬК4.3. Поле данных, где каждый бит соответствует определенной кнопке пульта. ЗК4.4.
Подтверждение приема сообщения. В ответ на сообщение от пульта, ЦБУ должен послать следующее ссюбщение. ]55] (гг] Полученные данные Контрольная сумма Здесь 55(шестнадцатеричное) — это адрес ЦБУ, ГГ (шестнадцатеричное)— код подтверждающего сообщения, полученные данные возвращают полученыый ЦБУ байт данных, а Контрольная сумма — это вычисленная контрольная сумма возвращаемого сообщения.
Приложение А. Артефакты системы НО1Л8 399 (Все остальные требования ие приводятся иэ соображений краткости.) 5.2. Нефункциональные требования 5.2.1. Практичносзь 5.2.2. Надежность ° Заказчики системы НО1ДБ требовали, чтобы ее надежность была максимально возможно приближена к 100%. ° ЯК5. ЦБУ не должен иметь дефектов, которые могут повлиять на нормальное использование жилья домовладельцем.
5.2.3. Эффективность 5.2.4. Возможность сопровождения 6. Требовании к интерактивной документации пользователя н системе подсказок 7. Ограничения проектирования 11С1. Проект управляющей подсистемы основывается на модуле контроллера из семейства продуктов А1ЬР. В10$ не должен модифицироваться беэ крайней необходимости. 11С2. Прецедент и поддерживающая его инфраструктура для последовательности действий в чрезвычайной ситуации должны быть подвергнуты испытаниям на уровне наивысших коммерческих стандартов. 8. Закупаемые компоненты 9. Интерфейсы 9.1. Интерфейсы пользователя 9.2.
Интерфейсы аппаратуры 9.3. Интерфейсы программного обеспечения 9.4. Интерфейсы связи 10, Требовании лицензировании Для ЦБУ нет требований лицензирования. 11. Замечании, касающиеся авторских прав, юридических аспектов и т.п. ° 8Кб. Предусмотреть отображение на экране извещения о корпоративном авторском праве, символики компании и продукта НО1.18 2000 в течение не менее 5 секунд в режиме начала работы. ° ЯК7.
В режиме постоянной работы, когда ие производятся действия по программированию, дисплей должен все время отображать логотип НО. 1.18 2000. 12, Применяемые стандарты ЯК8-индекс ЯК8.глоссарий ВКЗ.приложение. Спецификации прецедентов подсистемы ЦБУ 400 Приложения Набор приемов 6. Построение правильной системы НОЯБ 2000. Образец тестового примера 01: тест прецедента "Управление освещением" История изменений Дата Описание Первая версия Версия Автор Джек Бнгриг 14.04.99 1.0 15.04.99 Коррекция для увеличения/уменьшения яркости Джин Мак-Билл Описание. Данный тестовый пример, предназначенный для тестирования экземпляров прецедента Управление освещением, используется для тестирования только предварительно приписанных к осветительному банку клавиш пульта, для которых возможен режим изменения яркости.
1В собьггия Описание Ввод 1 Ввод 2 Ожидаемый события результат Основаой гюгжж 200! Перед нажатием кнопки свет был Жилец нажимает кнопку пульта Любая до- пустимая кнопка Свет выключается 2002 Перед нажатием кнопки свет был Свет включается с прежним уровнем ярко- сти Оп1.сгс) выключен Свет выключен 2009 Жилец отпус.
кает кнопку в течение 1с Остается выключенным 2000 Остается включенным с прежним уровнем ярко- сти (Оп1.осе1) Свет включен Жилец нажима- Та же Перед зтим свет Свет включается с тем выключен же уровнем яркости, что и а 2002 2006 кнопка, что и в 2003 ет кнопку снова и отпускает в те- чей шс 1с Жилец отгбскаст ююпку в тсчспне ! с (Этим эаканчнваегся первый цугь прецедента.) включен (тестолог должен запомнить тровень) Приложение А.
Артефакты системы НОБ18 401 Иу события Описание Ввод 1 Ввод 2 Ожидаемый события результат Жзиец нажима- ет кнопку вновь и счпусюит в тс. чсние 1с Перед этим свет Свет выключается включен Ллыэеряаши внмй веток Кнопка удер- живается в на- 2007 Допустилгая кнопка Перед этим свет выключен Свет включается. Я р- кость возрастает до мак. симального уровня со скоростью 10% в секун- ду, а затем уменьшается со скорситью 10% в се- лунду до минимального уровня, после чего сно. ва возрастает.
Циклы продолжаются, поки нажата кнопка жатом состоянии дольше 1с 2008 Жилец отпус- кает кнопку Яркость остается на по- следнем достигнутом уровне Заэичакис. Тест выполняется много раз при различных вариантах нажатия кнопки для проверки того, что система правильно запоминает уровень яркости Оп Сете1. НОЕ1Я 2000. Образец тестового примера 021 тест протокола обмена сообщениями История изменений Дата 14.04.99 Версия Описание Исходный план Автор Джин Мак-Билл 1.0 Описание. Данный тестовый пример служит для проверки протокола обмена саоо.
щеннями между 11БУ и "Управлением включением" (УВ, пультом). При этом тестируются следзющце требования из БКБ к ЦБУ и УВ. БКБ ЦБУ 884, 884.1, 884.2, 884.3, 884.4 БКБ УВ СББ88, СББк91-97, СББЯ100-107 (Зцчэчаяис Данную таблицу можно удалить после задания матрицы трассировки. Для миниииза.
ции усилий по сопровождению подобные связи поддерживаются только в матрице трассировки.) События 1В события Описание события Ввод 1 Одна кнопка 5500 [01] [01) [01) [5А] 5501 [55][РР)[01][Р7] 5502 ЗЗОЗ [01) [01][ЗР][ЗС] 402 Приломсеиия Намить на пульте 1 кнопку 0 и инициировать сообщение от УВ ЦБУ Проверить полученное сообщение па строке ди- агностики дисплея ЦБУ Проверить посланное сообщение на дисплее ЦБУ Нажать кнопки пульта 0-5 одновременно и держать в таком поло- жении Зс Проверить сообщение 1 (Остальные события не приводятся из сообра- жений краткости) Все кнопки нажаты З и более секунд Ввод 2 Омсидаемый результат Горят ЦБУ-иидикатор приема сообщения н УВ- индикатор приема сообщения ЦБУ-инднкатор приема сообгцения горит.
В буфе- ре сообщений дисплея должно находиться З со- общения Приложение Б Образец документа-концепции Название компании Документ. концепция 1Название проекта) © 1999 Название компании История исправлений Онисаиие Исходная версия Версия Автор Имя автора 29/06/99 1.0 число/месяп/год Содержание 1. Введение В данном разделе необходимо представить общую характеристику документа- концепции в целом; наряду с этим он должен содержать следующие подразделы, К К Цель документа-концепции Цель данного документа состоит в сборе, анализе и определении высокоуровневых потребностей пользователей и функций продукта.
Основное внимание уделяется возможностям, в которых нуждаются будущие пользователи, и причинам существо. ванна этих потребностей. Конкретные требования, касающиеся того, как приложение выполняет этн потребности, должны быть представлены в слевк9гкковнял яфе бований к ярофанмяаму айомчению или пмвкфихапиях гфевадэнаам. 1.2. Общая характеристика продукта Исключительную важность для успеха проекта имеет документ концепция, в котором представлены высокоуровневые потребности пользователя и функции приложения. Этот документ по мере необходимости обновляется и доводится до сведения членов команды разработчиков и других участников проекта. Предлагаемый ниже образец документа можно использовать в качестве отправной точки и модифицировать в соответст.