Несмотря на всю полезность вариантов использования, иногда более эффективным методом выявления требований является анализ событий. 

С тех пор как я открыл для себя столь ценный инструмент выявления требований, как варианты использования (use case), я стал их ярым приверженцем. Варианты использования смещают фокус внимания с продукта и его возможностей на результат, который пользователи хотят получить от продукта. Акцент на использовании приводит к пониманию необходимых возможностей и характеристик решения.

Варианты использования описывают цели, которые пользователи хотят достичь через взаимодействие с системой. Центральным элементом в описании варианта использования является пошаговый диалог, происходящий между основным пользователем и проектируемой системой, а также между дополнительными пользователями, внешними системами и компонентами. Благодаря такой структуре варианты использования являются эффективным инструментом исследования интерактивных систем, в которых пользователь инициирует сеанс для достижения своей цели.

Но несмотря на эффективность вариантов использования, они — не идеальный инструмент для любых ситуаций. Дополнительной стратегией выявления требований может быть изучение событий, происходящих в системе или продукте, и реакций системы на них. Реакция зависит от того, в каком состоянии находится система в момент события. Подход с анализом событий особенно хорошо подходит для связующего программного обеспечения (middleware) и систем реального времени, состоящих как из программных, так и аппаратных компонент.

Ненавистная касса самообслуживания

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

Выявление требований к продукту лучше всего начинать с определения классов пользователей. Основные пользователи касс самообслуживания — это покупатели. Помимо них, пользователями будут сотрудники магазина, помогающие в решении проблем и вопросов покупателей, а также все, кто устанавливает, настраивает и тестирует оборудование. Давайте сосредоточимся на покупателях.

Для покупателей мне приходит в голову только один вариант использования: "Покупка товаров". Это единственная цель покупателя. Отдельные действия, функциональность или проблемы, с которыми пользователь может столкнуться во время сеанса, такие как, сканирование товара или оплата кредитной картой, не являются вариантами использования. Они являются лишь этапами процесса достижения цели пользователя — покупки одного или нескольких товаров. Вариант использования — это отдельная задача, по завершении которой пользователь получает некоторую ценность.

Конечно, бизнес-аналитик мог бы обсудить с некоторыми покупателями вариант использования "Покупка товаров", чтобы узнать, как они представляют себе взаимодействие с кассой. И это будет огромный и очень сложный вариант использования! При покупке возникает множество вариантов развития событий, называемых альтернативными потоками. Также бывают различные исключительные ситуации, когда что-то идёт не так и мешает достижению цели (это всем хорошо известно, кто пользовался подобными устройствами). Кроме того, изучение представления покупателя о покупке товара не даёт достаточной информации по функциональности кассы самообслуживания — мы узнаем только о видимых покупателю функциях. Есть ли лучший способ понять требования к такому продукту?

События при использовании кассы самообслуживании

Анализ событий — альтернативный метод выявления требований, хорошо работающий с системами реального времени, такими как кассы самообслуживания. Событие — это изменение, произошедшее в окружении приложения и стимулирующее определённую реакцию. Можно выделить следующие классы событий: бизнес-событие, сигнал, временнóе событие.

Бизнес-событие (Business Event) — кто-то или что-то (пользователи не обязательно должны быть людьми) за пределами бизнес-домена запрашивает сервис в домене. Запрос часто запускает выполнение варианта использования. Например, бизнес-событие инициирует покупатель, решивший воспользоваться кассой самообслуживания.

Сигнал (Signal Event) — входные данные извне, такие как, управляющие сигналы от датчиков или какие-то данные из внешних систем. Для кассы самообслуживания это будет, например, обнаружение бесконтактного платёжного средства (кредитной карты или телефона).

Временнóе событие (Temporal Event) — наступление заданного момента времени или прошествие какого-то интервала времени с предыдущего события или с момента перехода системы в определённое состояние. Например, вы положили в сумку (на весовую платформу) не отсканированный товар. Система самообслуживания напомнит вам о необходимости его отсканировать. Если вы не уберёте товар в течение определённого времени, касса приостановит процесс оформления заказа, подаст сигнал помощи или выполнит какое-либо другое действие. 

Давайте посмотрим, поможет ли рассмотрение событий, которые система должна обнаружить и обработать, более глубокому пониманию требований. Вот неполный список событий, связанных с самообслуживанием.

• система обнаруживает находящегося рядом покупателя;

• покупатель сканирует свою карту лояльности;

• покупатель указывает, что использует свою сумку;

• покупатель сканирует штрихкод товара;

• покупатель сканирует весовой товар;

• система обнаруживает несоответствие веса в сумке;

• покупатель сканирует купон;

• покупатель запрашивает оплату наличными;

• в течение X секунд не происходит никаких действий со стороны покупателя.

Составление простого списка, подобного этому, — первый этап анализа событий. Такой перечень событий даёт некоторое представление о возможностях и компонентах системы. Например, для определения, что покупатель находится поблизости, потребуется видеокамера или детектор движения.

Анализ реакций на события

На следующем этапе строим таблицу реакций системы на события. В таблице указываем состояние, в котором находится система во время события, и ожидаемую реакцию системы. 

Таблица 1. Примеры событий и реакций на события.

Изучите каждое событие на предмет возможных исключительных ситуаций. Что, если покупатель сканирует штрихкод товара, но товар не найден в базе данных? Со мной такое случалось. А если покупатель заметит, что цена, отображаемая после сканирования, не соответствует цене, указанной на ценнике или в рекламе? Проработанный набор требований предусматривает как можно больше исключений и определяет, как система должна их обнаруживать, реагировать и пытаться восстановить работоспособность.

Хотя эти примеры упрощены и неполны, вы можете увидеть, как анализ переходов состояний раскрывает необходимую функциональность системы. Например, если необходимо звуковое оповещение, то необходимы синтезатор речи и динамик. Детали, касающиеся громкости, тембра голоса и других характеристик, будут уточняться в ходе последующих обсуждений требований или оставлены на усмотрение разработчика, который, как можно надеяться, будет использовать прототипы для оценки предлагаемых вариантов.

Для визуализации состояний системы, событий и условий, которые приводят к переходу из одного состояния в другое, помимо текстового описания часто используют диаграмму состояний.

В самом начале своей карьеры разработчика я понял — нет одной-единственной формы описания требований, в которой было бы представлено всё, что нужно знать, сразу всем стейкхолдерам. Диаграммы позволяют абстрагироваться от деталей, содержащихся в таблице реакций на события, наборе функциональных требований или стопке пользовательских историй, чтобы увидеть общую картину на более высоком уровне абстракции. Сочетание текстовых и визуальных представлений передаёт знания наиболее эффективно.

Пользователи не могут знать всего

Даже если бизнес-аналитик эффективно поработал с представителями всех классов пользователей, он не сможет получить всю необходимую информацию для полной спецификации продукта. Вероятно, покупателю и в голову не придёт сказать: "Если касса самообслуживания обнаружит в моей сумке товар, который не был отсканирован, она должна сообщить об этом". Точно так же покупатель не скажет: "Если в автомате меньше 99 центов монетами и необходимо выдать сдачу, то не должно быть возможности расплатиться наличными". Работа бизнес-аналитика как раз и заключается в заполнении подобных пробелов.

Не забывайте про тайм-ауты, такие как "В течение X секунд не происходит никаких действий со стороны покупателя". Тайм-аут — это, по сути, отрицательное временное событие. Система определяет, что в течение определённого периода времени или с момента предыдущего события ничего не происходило, и должна предпринять какие-то действия. Покупатель в ходе обсуждения требований вряд ли скажет: "Если я ничего не делаю в течение некоторого времени, то система должна спросить, на месте ли я или сделать что-то в этом роде”.

К слову, тайм-ауты для касс самообслуживания в моём местном супермаркете, на мой взгляд, слишком коротки. Более тщательное прототипирование с привлечением более широкого круга репрезентативных покупателей могло бы привести к лучшему проектному решению, которое не заставляло бы автомат так часто жаловаться покупателям.

Также много чего происходит за сценой, о чём покупатель не знает и что его не волнует. Например, управление запасами (inventory management) — обновление информации о наличии товаров. Также обеспечение безопасности — оснащение касс самообслуживания видеокамерами для поиска (или отпугивания) покупателей, которые уходят не заплатив. О такой неочевидной функциональности бизнес-аналитик должен узнать от других стейкхолдеров и экспертов в предметной области, а не от непосредственных пользователей касс самообслуживания. Чтобы не упустить важную информацию, бизнес-аналитик должен охватывать широкую аудиторию при выявлении требований.

Взаимодополняющие техники

Как видите, изучение событий, происходящих в системе, и реакций системы на каждое из них, иногда более информативно, чем анализ вариантов использования. Структурированные методы, такие как таблицы реакций на события и диаграммы состояний, представляют определённую информацию более эффективно, чем потокоориентированные варианты использования.

Итак, что должен применять добросовестный бизнес-аналитик: варианты использования или анализ событий? Зависит от природы вашего продукта. Если вы можете выделить несколько классов пользователей с разными целями использования системы, тогда, возможно, стоит начать с вариантов использования. Если же продукт предполагает ограниченное количество сложных взаимодействий, в нём задействованы аппаратные компоненты и происходит множество событий, которые пользователь не видит напрямую, то в этом случае лучше использовать анализ событий. Эти техники не взаимоисключающие. Вы можете начать с изучения вариантов использования, а затем перейти к событиям. Сравните результаты и посмотрите, не упустили ли вы что-нибудь.

Разработчики не реализуют варианты использования, пользовательские истории или события. Они реализуют функциональность, заставляющую решение вести себя необходимым образом при возникновении определённых событий. Помните как при анализе вариантов использования, так и при анализе событий бизнес-аналитик должен в нужный момент перейти на более глубокий уровень детализации, определяя ту конкретную функциональность, которую будут реализовывать разработчики.

Например, в последней строке таблицы 1 говорится, что система завершает сеанс. Но что включает в себя завершение сеанса? Кто-то должен выяснить эти детали. Если эта информация в итоге не будет включена в требования, не удивляйтесь тому, какой результат вы получите от разработчиков.

Обратите внимание, что ни одна из описанных здесь реакций системы не содержит фразу "тратить время покупателя впустую". Вы получаете это бесплатно.

Материал подготовлен в рамках специализации «Системный аналитик и бизнес-аналитик».