USE CASE — что это, из чего состоит и как избежать ошибок при написании

27 июня 2024

Академия разработки MediaSoft

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

 

В статье разберемся, что такое Use Case, из каких элементов состоит, как написать сценарии использования и не допустить ошибок. 

ЧТО ТАКОЕ USE CASE И ЗАЧЕМ НУЖЕН?

Use Case (вариант использования, ВИ, Прецедент) — это сценарная техника описания взаимодействия. С его помощью может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни. 

 

Зачем нужны варианты использования:

  • Составить общее представление о продукте.

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

  • Показать разработчикам что система должна сделать (именно что, а не как).

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

  • Сэкономить время тестировщика на проработку тест-кейсов.

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

  • Использовать как скелет для описания технического сценария.

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

КАК ГРАФИЧЕСКИ ОТОБРАЗИТЬ USE CASE

Графическое отображение Use Case можно выполнить с помощью диаграммы Use Case. Это распространенный способ визуализации функциональных требований системы. Диаграмма Use Case состоит из двух основных элементов: участник (actor) и прецедент (вариант).  

 

На схеме участник изображается «человечком»; прецедент — в виде эллипса, внутри которого указано его название; а стрелки показывают объединение и декомпозицию вариантов использования.

КАК ОПИСАТЬ USE CASE С ПОМОЩЬЮ ТЕКСТА

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

Название поля Что содержит

Заголовок 

 Название варианта использования.

Участники варианта использования		 Основное действующее лицо (actor) и все дополнительные участники.

Предусловия

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

Например, вариант использования: заказать такси в приложении.
Обязательное предусловие: пользователь должен быть авторизован.
Триггер Что провоцирует выполнение этого сценария. Например, пользователь попал на страницу сайта для заказа такси через баннер.

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

Описание (основной сценарий)		 Что должно произойти, чтобы пользователь пришёл от триггера к результату. 
Например:
1. Пользователь вводит начальную и конечную точку маршрута.
2. Система подбирает доступную машину в радиусе 1 км.
3. Пользователь получает оповещение о времени прибытия машины.

Расширения (альтернативный сценарий)

Строится из основного сценария. К каждому пункту основного сценария нужно задать вопрос «А что если?». Если альтернативный сценарий использования возможен, описать его по шагам как основной.

Например:

3.1. Пользователь получает оповещение о том, что в радиусе 1 км нет доступных машин.

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

ОШИБКИ, КОТОРЫЕ ДОПУСКАЮТ АНАЛИТИКИ ПРИ НАПИСАНИИ USE CASE, И КАК ИХ ИЗБЕЖАТЬ

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

 

Ошибка №1 — Отсутствие системы 

Вариант использования: снять наличные со счета
Область действия: банкомат
Уровень: цель пользователя
Основное действующее лицо: клиент

Плохо

Хорошо

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

1. Клиент вводит карточку и PIN.

2. Клиент вводит «снять деньги» и количество.

3. Клиент забирает карточку, наличные и квитанцию.

4. Клиент уходит.

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

1. Клиент пропускает карточку для банкомата через считывающее устройство.

2. Банкомат считывает с карточки ID банка номер счета, зашифрованный PIN, подтверждает ID банка и номер счета с помощью главной банковской системы.

3. Клиент вводит PIN. Банкомат сверяет его с зашифрованным PIN, считанным с карточки.

4. Клиент выбирает «быстрое снятие наличности» и указывает сумму в купюрах по 500 руб.

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

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

7. Банкомат регистрирует транзакцию.

 

 

Ошибка №2 — Отсутствие основного действующего лица

Вариант использования: снять наличные со счета
Область действия: банкомат
Уровень: цель пользователя
Основное действующее лицо: клиент

Плохо

Хорошо

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

1. Получает карточку для банкомата, PIN.

2. Получает в качестве типа транзакции «снять наличные».

3. Получает требуемую сумму.

4. Удостоверяется, что на счете достаточно денег.

5. Выдает, деньги, квитанцию, карточку.

6. Возвращается в исходное состояние. 

Исправление: указать каждое  действующее лицо и действие.

Исправленный вариант — тот же, что и  в предыдущем кейсе.


 

 

Ошибка №3 — Слишком много деталей интерфейса пользователя

Вариант использования: совершить покупку
Область действия: приложение
Уровень: цель пользователя
Основное действующее лицо: клиент

Плохо

Хорошо

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

1. Система устанавливает экран для ввода ID и пароля.

2. Клиент вводит ID и пароль, щелкает по кнопке «ОК».

3. Система подтверждает ID и пароль, отображает персональные данные.

4. Клиент вводит имя и фамилию, номер дома, название улицы, города, области, почтовый индекс, номер телефона и щелкает по кнопке «ОК».

5. И т.д.



 

Исправление: отказываемся от детализации

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

1. Клиент регистрируется в системе с помощью ID и пароля.

2. Система подтверждает ID и пароль пользователя.

3. Клиент вводит адрес, имя, номер телефона.

4. Система подтверждает, что пользователь ей известен.

5. Клиент указывает товар и его количество.

6. И т.д.

 

Ошибка №4 — Низкие уровни целей

Вариант использования: совершить покупку
Область действия: приложение
Уровень: цель пользователя
Основное действующее лицо: клиент

Плохо

Хорошо

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

1. Пользователь регистрируется в системе с помощью ID и пароля.

2. Система подтверждает ID и пароль.

3. Пользователь вводит имя.

4. Пользователь вводит адрес.

5. Пользователь вводит номер телефона.

6. Пользователь указывает товар.

7. Пользователь указывает количество товара.

8. Система подтверждает, что пользователь ей известен.

9. И т.д.

Исправление: объединяем шаги.

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

1. Пользователь регистрируется в системе с помощью ID и пароля.

2. Система подтверждает ID и пароль пользователя.

3. Пользователь вводит персональные данные (имя, адрес, номер телефона), указывает товар и количество.

4. Система подтверждает, что пользователь ей известен.

5. Система удостоверяется при помощи системы управления складами, что на складе есть достаточное количество товара.

6. И т.д.

 

 

Ошибки №5-10 

Помимо вышеупомянутых на практике встречается еще несколько ошибок, который допускают аналитики при составлении Use Case:

5. Не прорабатывают расширения.
6. Не указывают альтернативные сценарии.
7. Считают, что Альтернативные сценарии = Расширения.
8. Забывают про предусловие и триггеры.
9. Относятся к системе не как к «черному ящику».
10. Не реализуют нумерацию шагов.

ИТОГО

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