Пользовательские требования в виде Use Case

В прошлом уроке вы успели познакомиться с различными моделями требований и узнали про Use Case Diagram UML. В этом уроке мы подробнее поговорим о том, что такое варианты использования, какими они бывают и как самостоятельно составить Use Case.

Даня

Артём, а как думаешь, пользователям Chatty нужна возможность добавлять слова в раздел «Избранное»?

Артём

Чтобы корректно ответить на этот вопрос, нужно понять, как именно пользователи Chatty хотят пользоваться словарём.

Даня

Нужно ещё раз связаться с пользователями? Я думал, что мы уже закончили со сбором требований.

Артём

Нет, мы сами продумаем шаги пользователя и составим Use Case.

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

Как вы помните, требования подразделяются на уровни: сверху находятся бизнес-требования, из них выделяются пользовательские требования, а затем функциональные.

После определения бизнес-требований системный аналитик взаимодействует с заинтересованными лицами для уточнения пользовательских требований к будущей системе.

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

Use Case

Как зафиксировать пользовательские требования так, чтобы всем было понятно, что именно пользователь будет делать в системе и какие шаги ему для этого надо пройти? В этом помогут варианты использования, которые применяются для представления пользовательских требований.

Вариант использования (Use Case) описывает взаимодействие между действующим лицом и системой для получения определённого значимого результата.

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

Выделить акторов, которые участвуют в описании вариантов использования, помогут такие вопросы:

Кто (или что) уведомляется, если что-то происходит внутри системы?
Кто (или что) предоставляет системе информацию и сервисы?
Кто (или что) помогает системе среагировать и выполнить задачу?

Варианты использования нацелены именно на взаимодействие пользователя и системы. Это значит, что их можно применить при разработке систем, где возможны различные сценарии её использования. Но Use Case не подойдут при анализе приложений для формирования отчётов или хранения каких-либо данных, поскольку в этом случае варианты использования ограничатся лишь несколькими простыми сценариями.

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

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

Графическая форма вариантов использования

Начнём с графической формы. В прошлом уроке вы уже познакомились с этой диаграммой. Вспомним определение:

Use Case Diagram UML — нотация для моделирования вариантов использования системы пользователями. Она позволяет изучить требование, ответив на вопрос: «Как пользователь может воздействовать на систему?»

Use Case Diagram UML также называют диаграммой вариантов использования или диаграммой прецедентов. С её помощью можно получить высокоуровневое представление о том, как пользователь или другое приложение взаимодействует с системой. Для построения данной диаграммы используется нотация UML.

Диаграмма состоит из:

Акторов
Вариантов использования
Границы системы
Связей между элементами

Подробнее о том, как правильно строить диаграмму, вы узнаете из практической части данного урока. А пока рассмотрим простую диаграмму Use Case на примере интернет-магазина.

Изучив диаграмму, мы можем понять, как актор может взаимодействовать с нашей системой.

Табличная форма вариантов использования

Иногда лишь определения вариантов использования, как представлено в диаграмме Use Case, недостаточно. В таких случаях может пригодиться умение представлять варианты использования в табличной форме, которая позволит разобраться в том, что именно происходит внутри одного варианта использования.

Табличная форма представления фокусируется на детальном рассмотрении последовательности действий. Эта последовательность описывает взаимодействия актора и системы в рамках одного варианта использования (или сценария).

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

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

Рассмотрим, из чего состоит табличная форма:

Вариант использования
Контекст использования
Область действия
Уровень
Основное действующее лицо (основной актор)
Участники (дополнительные действующие лица)
Предусловие
Минимальные гарантии успеха
Гарантии успеха
Триггер
Описание (основной сценарий)
Расширения (альтернативные сценарии)
Изменения в технологиях и данных

Как правильно заполнить табличную часть, мы рассмотрим в практической части данного урока. Пока предлагаем рассмотреть простой пример. Возьмём один из вариантов использования «Войти в личный кабинет» и распишем его в таблице.

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

Рассмотрев две формы представления вариантов использования, можно сделать вывод, что одно не заменяет другое, а таблица расширяет понимание диаграммы. Всё это можно представить в виде картинки:

А теперь перейдём к практической части нашего урока и разберёмся, как составить диаграмму Use Case и заполнить табличку с Use Case.

Как построить диаграмму Use Case

Актор

Первое, что нам необходимо сделать при построении диаграммы Use Case, — выделить акторов. То есть определить тех, кто будет пользоваться нашей системой. Если вернуться к примеру выше, у нас есть пользователь сайта, который на диаграмме изображается как человечек с подписью внизу.

Варианты использования

Следующим шагом нам необходимо выделить варианты использования. Для этого ответим на вопрос: «Что актор хочет делать в нашей системе?». В нашем примере он хочет заходить на сайт и иметь возможность оформлять заказ. На диаграмме варианты использования изображаются в форме овала, внутри которого написан вариант использования в формате «глагол + существительное». Посмотрим на пример:

Границы системы

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

Типы связей

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

Связь ассоциации

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

В нашем примере актор связан с двумя вариантами использования.

Связь обобщения

Эта связь обозначается на диаграмме стрелкой с пустым наконечником и направляется от частного к общему. Стрелка может объединять как акторов, так и варианты использования по какому-либо признаку. Важно понимать, что связь обобщения между вариантами использования подразумевает, что дочерний вариант использования содержит все атрибуты и шаги из родительского варианта использования.

Посмотрим на примере, как ребёнка и взрослого (акторов) можно обобщить до пользователя сайта.

Теперь давайте посмотрим на пример обобщения вариантов. Варианты использования «купить персик» и «купить нектарин» можно обобщить до простого варианта «купить фрукты».

Связь включения

Эта связь обозначается на диаграмме пунктирной стрелкой с подписью include. Стрелка показывает, что какой-то вариант использования включает в себя другие варианты. Важно обратить внимание, что стрелка направлена от одного варианта использования на те варианты использования, которые включаются в него.

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

Связь расширения

Эта связь обозначается на диаграмме пунктирной стрелкой с подписью extend. Стрелка показывает, что один вариант использования опционально может расширять другой. Чтобы лучше понять, как это работает, давайте разберём эту связь, сравнив её со связью включения. В связи включения один вариант использования обязательно включается в другой, в связи расширения это необязательно.

Рассмотрим на примере. Актор хочет купить продукты. Скорее всего, на кассе ему предложат купить пакет, товары по акции, что расширит список покупок актора. Однако важно понимать, что эти опции могут и не предложить, то есть такие варианты использования необязательны.

Вы — системный аналитик, и за помощью с диаграммой Use Case к вам обратился младший коллега из команды разработки интернет-магазина. Она реализует новый функционал по поиску товаров. Внизу представлена картинка. Давайте поможем вашему коллеге разобраться, где какая связь нужна.

Связь между актором — пользователем сайта и вариантом использования «Поиск товара»

Связь ассоциации

Связь ассоциации. Осуществляется связь между вариантом использования и актором. Пользователь сайта может искать товары на сайте.

Связь между вариантами «Поиск товара» и «Настройка фильтров для поиска»

Связь включения

Связь включения. Настройка фильтров для поиска включается в вариант «Поиск товара». Ведь в процессе поиска товара пользователь может фильтровать отображаемые позиции, как ему удобно.

Связь между вариантами «Поиск товара» и «Поиск соуса»

Связь обобщения

Связь обобщения. Поиск соуса можно обобщить до варианта использования «Поиск товаров».

Связь между вариантами «Поиск товара» и «Просмотр похожих товаров»

Связь расширения

Связь расширения. Просмотр похожих товаров в рамках поиска будет необязательным пунктом в рамках расширения функционала.

Полный шаблон

Для начала познакомимся с полным шаблоном, представленным в книге Алистера Коберна. Выше вы уже видели заполненную таблицу с примерами. Теперь давайте посмотрим на неё ещё раз и проясним, как заполнять. Перед вами пустой шаблон таблицы, а ниже вы найдёте пояснение каждого пункта, чтобы вам было понятно, что и куда нужно вписывать.

Вариант использования

Название одного варианта использования, которое вы хотите описать, в формате «глагол + существительное». Это то, что представлено в графическом формате в виде овала.

Контекст использования

Заполняется для полного понимания контекста использования, то есть понимания цели актора в данном варианте использования. Поле может остаться незаполненным, если его суть понятна команде разработки и заинтересованным лицам из названия варианта использования.

Область действия

Границы системы. В графическом формате представлены в виде рамки.

Уровень

Имеет одно из следующих значений:

Обобщённый. Выбирается, если вариант использования покрывает несколько целей актора.
Цели пользователя. Выбирается, если вариант использования покрывает одну цель актора.
Подфункции. Выбирается, если вариант использования покрывает цель, которая в дальнейшем необходима для достижения цели актора. Такой уровень редко используется, это скорее техническая задача, где нет непосредственного участия пользователя. Примером такого варианта использования может быть: «Найти изделие», «Сохранить в файле».

Основное действующее лицо

Кто запускает вариант использования, то есть актор данного варианта использования. Можно записать имя пользователя или добавить его описание. В графическом формате представлено в виде человечка.

Участники

Перечень дополнительных действующих лиц и их целей в рамках варианта использования. Записывается в формате: [Актор] — [его цель]. В графическом формате представлено в виде человечка.

Предусловие

Описание того, что должно произойти, чтобы актор мог воспроизвести данный вариант использования.

Минимальные гарантии успеха

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

Гарантии успеха

Описание успешного завершения сценария варианта использования.

Триггер

Определяет событие, которое запускает сценарий варианта использования. Иногда предшествует первому шагу сценария.

Описание

Основной сценарий. Пошаговое описание действий актора и системы. Указывается номер шага и действия.

Расширения

Альтернативные сценарии. Шаги с действиями при ответвлении от основного сценария (который дан в «Описании»).

Изменения в технологиях и данных

Фиксируется список изменений в системе, которые необходимо будет реализовать, исходя из вашего основного или альтернативного сценария. Например, в основном сценарии у вас прописан шаг 1 — «Пользователь идентифицирует себя». Тогда в данной графе вы можете уточнить 1а — «Использовать банковскую карту, сканирование отпечатка пальца».

Вы системный аналитик и участвуете в разработке банковского приложения для клиентов. У вас есть сформулированный по шаблону выше текст Use Case «Просмотр баланса карты», но кто-то случайно стёр в нём первую колонку, а значит, определение каждого блока потерялось. Соотнесите текст из шаблона Use Case с его названием.

Клиент зашёл в приложение

Предусловие

Указано предусловие, а именно — что должно быть сделано, чтобы актор мог воспроизвести Use Case.Предусловие. В данном пункте описано то, что должно быть сделано, чтобы актор мог воспроизвести ваш Use Case.

Клиент банка

Основное действующее лицо

Указан актор варианта использования «Просмотр баланса карты».

Клиент банка видит баланс выбранной карты

Гарантии успеха

Указано, что именно актор получит при успешном выполнении Use Case «Просмотр баланса карты».

Клиент получает сообщение об ошибке — неправильный пароль

Расширения

Указана возможная ошибка, которая может встретиться клиенту в данном варианте использования.

Мобильное приложение банка

Область действия

Указана система, в которой актор будет производить действия.

Основной сценарий

Вы уже знаете, что такое основной сценарий. Давайте теперь разберём, из чего он состоит и как правильно его описать.

Сценарий состоит из последовательных действий. При их описании старайтесь придерживаться следующих правил:

Используйте простые предложения.
Ясно указывайте, кто является действующим лицом на каждом шаге.
Показывайте продвижение процесса, но не углубляйтесь в мелкие детали. Например, при описании шагов «Пользователь вводит электронный адрес» и «Пользователь вводит пароль» не нужно добавлять между этими двумя шагами новый — «Пользователь перешёл в поле „пароль”».
Не перегружайте сценарий описанием деталей интерфейса. Например, по примеру выше можно понять, что он как раз перегружен деталями. Проще было бы написать: «Пользователь вводит электронный адрес и пароль».
Предпочитайте глагол «подтверждает», а не «проверяет». Например, вместо «Система проверяет введённые данные» лучше указать: «Система подтверждает введённые данные».
Новый шаг может содержать повторение предыдущих шагов. Например, «Пользователь повторяет шаги 1–3 до тех пор, пока не войдёт в личный кабинет».
Для удобства и более чёткого понимания последовательности шагов можно пронумеровать их.

Альтернативные сценарии

Теперь вы знаете, как правильно писать основной сценарий, но нужно помнить и об альтернативных сценариях, ведь никто не застрахован от ошибок пользователей. Понять, что вам нужен альтернативный сценарий, поможет ситуация, при которой, описывая основной сценарий, вы часто используете слово «если». Но в любом случае, сначала вам нужно описать основной сценарий, а затем в блоке «Расширения» — альтернативный.

Вот список всех возможных причин, которые могут приводить к альтернативным сценариям:

Альтернативные пути к успеху
Актор действует некорректно
Бездействие актора
Каждый раз, когда вы прописываете фразу «система подтверждает», нужно учесть сценарий, при котором обрабатываются неверные данные
Внутренние ошибки системы
Критические недостатки в производительности системы

Чаще всего альтернативный сценарий не выделяется в отдельный вариант использования. Поэтому для альтернативного сценария используется нумерация. Указывается номер шага, где может быть обнаружено условие из основного сценария и добавляется ещё одна цифра (так, в примере выше альтернативный сценарий подписан цифрами 4.1). Однако, если необходимо, альтернативный сценарий всё же можно выделить в отдельный вариант использования, который будет находиться на уровне подфункции.

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

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

Сотрудник оформляет отпуск. Заявка на отпуск отправляется на согласование руководителю.

Основной сценарий

На основе этого можно расписать основной сценарий работы системы. В нём отражён часто используемый вариант использования системы.

При выборе дат отпуска сотрудник указывает прошедшие даты.

Альтернативный сценарий

Альтернативный сценарий. В варианте отражено некорректное поведение пользователя при взаимодействии с системой.

Сотрудник распечатывает согласованное заявление на отпуск.

Основной сценарий

Базовый сценарий. Показан шаг сценария из основного варианта использования системы.

Сотрудник не может авторизоваться в системе для оформления отпуска.

Альтернативный сценарий

Альтернативный сценарий. Отражён вариант использования, когда пользователь не может авторизоваться, а такой сценарий возможен не так часто.

Отпуск был согласован. Сотрудник получает уведомление.

Основной сценарий

Базовый сценарий. Показаны шаги сценария из основного варианта использования системы, которые ведут к успешному результату.

Свободный формат записи

Если у вас небольшой проект, вы можете постоянно взаимодействовать с заинтересованными лицами и варианты использования — не единственное описание будущих требований к системе, можно не использовать полный шаблон записи вариантов использования и обойтись свободным форматом. Например, из полного шаблона вы можете оставить только следующие пункты:

Вариант использования
Область действия
Актор
Предусловие
Описание
Расширение

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

Подведём итоги

В этом уроке мы познакомились с вариантами использования (Use Case), которые нужны для описания пользовательских требований.

Варианты использования могут быть представлены в графической или табличной форме.

Графическая форма представлена в виде Use Case Diagram UML. С её помощью мы можем получить высокоуровневое представление о том, как пользователь или другое приложение взаимодействует с системой. Она состоит из актора и набора возможных вариантов использования.

Табличная форма представлена в виде описания по шаблону Алистера Коберна. Варианты использования можно описывать по всему шаблону или в свободной форме. Табличная форма представления фокусируется на детальном рассмотрении последовательности действий, которая описывает взаимодействие актора и системы в рамках одного варианта использования. В ней мы описываем основные и альтернативные сценарии.