Пользовательские цели и возможности системы
После первичного списка требований полезно перейти к вопросу: какие цели пользователи будут достигать с помощью системы? Функциональное требование может быть написано как возможность системы, но пользователю важен не сам механизм, а результат.
Пользовательская цель должна быть сформулирована на уровне результата, а не на уровне интерфейсного действия. “Нажать кнопку отправки” — это действие в интерфейсе, но не цель. “Отправить заявку на согласование” — цель, потому что после неё меняется состояние работы и появляется ожидаемый результат.
Системная возможность описывает, что система предоставляет для достижения этой цели. Для цели “получить консультацию” возможностями могут быть просмотр свободных интервалов, создание записи, отмена записи, получение уведомления и просмотр истории. Одна цель может требовать нескольких возможностей, а одна возможность может поддерживать разные цели.
Пример разложения:
| Пользовательская потребность | Пользовательская цель | Возможность системы |
|---|---|---|
| студенту нужно попасть на консультацию | записаться на подходящее время | показать свободные интервалы и создать запись |
| преподавателю нужно управлять нагрузкой | открыть интервалы консультаций | создать, изменить или закрыть интервал |
| сотруднику нужно контролировать процесс | увидеть проблемные записи | сформировать список отмен и конфликтов |
| пользователю нужно не забыть о консультации | получить напоминание | отправить уведомление до начала события |
Такой переход важен для дальнейшей модели. Если цель сформулирована слишком технически, сценарии превратятся в описание интерфейса. Если цель слишком общая, процесс и предметная модель будут расплывчатыми. Хорошая пользовательская цель удерживает баланс между смыслом для участника и достаточной конкретностью для проектирования.
Вариант использования в аналитическом смысле связывает актора, цель и результат. Важно, что это ещё не обязательно диаграмма. Овал на UML-диаграмме является компактной визуальной фиксацией, но смысл появляется в тексте: кто инициирует взаимодействие, что хочет получить, какие условия должны быть выполнены и какой результат считается успешным.
Для отбора целей можно использовать несколько вопросов:
- меняется ли состояние важного объекта после достижения цели;
- получает ли участник самостоятельный полезный результат;
- можно ли описать успешный сценарий достижения цели;
- есть ли альтернативы или ошибки;
- связана ли цель с одним или несколькими требованиями;
- находится ли цель внутри границы проектируемой системы.
Если цель не проходит эти проверки, возможно, это не самостоятельный вариант использования, а шаг внутри другого сценария. Например, “выбрать дату” обычно является шагом цели “записаться на консультацию”, а не отдельной целью пользователя.
Типичная ошибка — записывать как цель слишком мелкое действие. “Открыть форму”, “ввести фамилию”, “нажать кнопку поиска” обычно являются шагами внутри цели “найти нужную запись”. Другая ошибка — формулировать цель слишком широко: “управлять учебным процессом” не даёт понятного сценария и должно быть разложено на более конкретные результаты.
Хорошая цель находится между этими крайностями. Она достаточно крупная, чтобы иметь ценность для участника, и достаточно конкретная, чтобы по ней можно было описать успешный и альтернативные сценарии.