Таблицы «событие - реакция»

Есть еще один способ систематизации и документации пользовательских требований: определить внешние события, на которые система должна реагировать. Событием (event) называется какое-либо изменение или действие в среде пользователя, вызывающее реакцию системы ПО (McMenamin и Palmer, 1984; Wiley, 2000). В таблице «событие-реакция» ( event-response table) [ее также называют таблицей событий (event table) или списком событий (event list)] перечислены все такие события и ожидаемое поведение системы, которое должно последовать, как реакция на каждое событие. Существует несколько типов системных событий, они показаны на рис. 8-9 и описаны далее:

· взаимодействие пользователя с ПО, как когда он, например, вызывает вариант использования [иногда называется бизнес-событием (business event)]. Последовательность событий и реакций соответствует этапам взаимодействия для этого варианта использования, В отличие от вариантов использования, в таблице «событие - реакция» не описываются цели пользователя при работе с системой и не приводятся причины, по которым эта последовательность событий и реакций имеет значение для пользователя;

· контрольный сигнал, чтение данных или прерывание, полученное от внешнего аппаратного устройства, например при изменении положения выключателя, изменении напряжения или перемещении мыши пользователем;

· событие инициируется в определенный момент времени (скажем, автоматический запуск экспорта данных в полночь) или когда истекает предварительно заданный период времени с момента определенного события (например, система фиксирует температуру, считываемую сенсором каждые 10 секунд).

Рис. 8-9. Примеры системных событий и реакций.

Таблицы «событие - реакция» особенно хороши для управления системами, работающими в режиме реального времени. Табл. 8-1 представляет собой простую таблицу «событие — реакция», в которой частично описано поведение очистителей ветрового стекла автомобиля. Обратите внимание, что ожидаемая реакция зависит не только от события, но и от состояния, в котором находится система во время события. Например, результаты событий 4 и 5.1 в табл. 8-1 различаются из-за того, были ли включены «дворники» в момент, когда пользователь настроил управление «дворниками» на периодический режим. Реакция может просто изменить некоторую внутреннюю системную информацию (события 4 и 7.1 в таблице) или привести к результату, заметному извне (большинство других событий).

Информация в таблице «событие — реакция» фиксируется на уровне пользовательских требований. Если в таблице определены и названы все возможные комбинации событий, состояний и реакций (включая условия исключений), таблица также может служить частью функциональных требований для этого фрагмента системы. Однако аналитик должен добавить дополнительные функциональные и нефункциональные требования в спецификацию требований к ПО. Например, сколько «взмахов» в минуту делают «дворники» в быстром и медленном режиме очищения? В быстром или медленном режиме выполняется периодическая очистка? Является ли периодический режим непрерывно изменяющимся или он работает дискретно? Каковы максимальный и минимальный интервал времени при работе в периодическом режиме? Если вы закончите работу на уровне пользовательских требований, разработчику самому придется выяснять эту информацию. Помните, ваша цель - сформулировать требования настолько точно, чтобы разработчик знал, что строить.

Обратите внимание, что события перечисленные в табл. 8-1 записаны на важнейшем (абстрактном) уровне (описывается суть события), а не на уровне реализации (описываются особенности реализации). В табл. 8-1 ничего не говорится о том, как выглядит элемент управления «дворниками» или о том, как пользователь управляет ими. Дизайнер может реализовать эти требования как угодно — от традиционных элементов управления «дворниками», как в современных автомобилях, до системы распознавания голоса, реагирующей на произносимые команды: «включить дворники», «выключить дворники», «быстрая очистка», «очистить один раз» и т.д. Записывая пользовательские требования на важнейшем (абстрактном) уровне, вы избежите введения ненужных ограничений проектных решений. Однако следует фиксировать все известные ограничения по дизайну (проектированию), чтобы заставить разработчика думать.

Таблица 8-1. Таблица «событие - реакция» для автомобильных «дворников»