Техники Руководство BABOK v3, 10.47
Варианты использования и сценарии
Коротко Вариант использования описывает, как действующее лицо — человек или другая система — достигает цели с помощью решения: пронумерованный основной сценарий плюс альтернативные пути и пути отказа. Так получаются функциональные требования, которые могут прочитать представители бизнеса и превратить в тесты тестировщики.
По материалам: IIBA, Руководство BABOK® v3, техника 10.47 «Варианты использования и сценарии»; А. Коберн, «Современные методы описания функциональных требований к системам», гл. 2, 5, 11; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., гл. 11; Ю. А. Маглинец, «Анализ требований к информационным системам», лекции 4–5; шаблоны документов RUP.
На этой странице
Что это#
В Руководстве BABOK® вариант использования (use case) описывает, как действующее лицо (actor) взаимодействует с решением, чтобы достичь цели, — через основную последовательность шагов и альтернативные последовательности. Сценарий — один путь через вариант использования: основной успешный сценарий либо один из альтернативных путей или путей отказа.
Соглашение о поведении. Алистер Коберн (гл. 2) рассматривает вариант использования как соглашение между заинтересованными сторонами, у которых есть интересы в системе. Одни взаимодействуют с ней напрямую — прежде всего основное действующее лицо, которому нужна цель. Другие остаются «за сценой», например регулятор или финансовая служба, но система всё равно должна защищать их интересы. Каждый вариант использования заканчивается успехом или неудачей в достижении цели, поэтому в шаблоне Коберна две гарантии: минимальные гарантии (что защищено, даже если цель не достигнута) и гарантии успеха (что истинно, когда цель достигнута).
Уровень цели. Коберн (гл. 5) называет уровни: обобщённый, уровень цели пользователя («уровень моря») и подфункция. Большинство вариантов использования пишите на уровне цели пользователя: это то, что основное действующее лицо выполняет за один подход и уходит удовлетворённым. «Войти в систему» — не цель пользователя. В хорошо выверенном варианте использования примерно от 3 до 10 шагов. Подробнее — на странице «Три уровня целей по Коберну».
Диаграмма. Книга BCS (гл. 11) описывает UML-диаграмму вариантов использования: действующие лица изображаются человечками (внешняя система — прямоугольником с пометкой <<actor>>; действующим лицом может быть и время), варианты использования — овалами с названием по схеме «глагол + существительное»; есть граница системы, за которой находятся действующие лица, и линии ассоциаций. <<include>> выносит общие шаги в отдельный вариант использования, который используют несколько других; <<extend>> выносит необязательный объёмный фрагмент поведения в собственный вариант использования. Диаграмма не показывает порядок вариантов использования. Она полезна на семинарах и для приоритизации всего, что входит в границы.
Форматы. В основе шаблона ниже — полный («полностью оформленный») шаблон Коберна (гл. 11). Шаблон RUP компактнее: название и описание, поток событий, специальные требования, предусловия, постусловия, точки расширения. Подходят и таблицы в две или три колонки (шаг, действующее лицо, система). Маглинец, пересказывая Коберна, связывает формальность с критичностью: чем дороже обойдётся сбой — вплоть до угрозы жизни, — тем формальнее должно быть описание.
Когда применять#
- Интерактивная функциональность с ветвлениями и обработкой ошибок.
- Когда нужна стабильная, удобочитаемая спецификация: SRS, договор, регулируемая система.
- Чтобы найти пропущенные требования: расширения выявляют случаи «а что, если».
- Задачи BABOK 7.1 «Спецификация и моделирование требований» и 5.2 «Поддержание требований».
Пользовательские истории предпочтительнее для небольших приращений, которые гибкая команда обсуждает непосредственно перед реализацией; модели процессов — для работы, которая охватывает многих участников и много дней; таблицы решений — для сложных условий.
Как это делать#
- Найдите действующих лиц по модели границ и реестру заинтересованных сторон.
- Перечислите цели каждого действующего лица и назовите варианты использования по схеме «глагол + объект» на уровне цели пользователя.
- Нарисуйте диаграмму вариантов использования, чтобы согласовать границы.
- Напишите основной успешный сценарий: 3–10 шагов, в каждом — кто что делает, без подробностей экранов.
- Проведите мозговой штурм по расширениям: на каждом шаге спросите, что может пойти иначе или сорваться. Нумеруйте расширения по шагу (3a, 3b).
- Добавьте предусловия, триггер и гарантии.
- Вынесите общие шаги во включаемые варианты использования, а правила — в каталог правил.
- Проверьте с пользователями и тестировщиками и выведите по одному тестовому сценарию на каждый путь.
Шаблон#
Вариант использования: UC-<id> <Глагол + объект>
Уровень: цель пользователя | обобщённый | подфункция Область действия: <система>
Основное действующее лицо: <роль>
Заинтересованные стороны и интересы:
- <заинтересованная сторона>: <что нужно обеспечить или защитить>
Предусловия: <что уже истинно>
Триггер: <событие, которое запускает вариант использования>
Минимальные гарантии: <истинно, даже если цель не достигнута>
Гарантии успеха: <истинно, когда цель достигнута>
Основной успешный сценарий:
1. <Действующее лицо> <делает что-то>.
2. Система <реагирует>.
3. ...
Расширения:
2a. <Условие>:
2a1. <Шаг>.
2a2. <Возврат к шагу n / вариант использования завершается>.
Специальные требования: <нефункциональные требования к этому варианту использования>
Открытые вопросы: <список>
Пример#
Вариант использования для «Мастерской», вымышленной сети веломастерских (сравните с пользовательской историей для связанной функции на странице «Пользовательские истории»):
Вариант использования: UC-03 Записаться на ремонт Уровень: цель пользователя
Основное действующее лицо: Клиент
Заинтересованные стороны и интересы:
- Управляющий мастерской: никаких двойных записей
- Стойка приёма: каждая запись попадает в расписание дня
Предусловия: нет (можно записаться без учётной записи)
Триггер: Клиент выбирает «Записаться на ремонт»
Минимальные гарантии: никакое время не остаётся зарезервированным без подтверждённой записи
Гарантии успеха: время зарезервировано, запись в расписании, подтверждение отправлено
Основной успешный сценарий:
1. Клиент выбирает мастерскую и вид ремонта.
2. Система показывает свободное время на ближайшие две недели.
3. Клиент выбирает время и вводит имя, телефон и данные велосипеда.
4. Система временно резервирует время и показывает сводку.
5. Клиент подтверждает запись.
6. Система регистрирует запись и отправляет подтверждение.
Расширения:
2a. Свободного времени нет: Система предлагает ближайшую мастерскую со свободным временем;
клиент выбирает её (возврат к шагу 2) или уходит (вариант использования завершается).
3a. Выбранное время уже заняли: Система сообщает об этом; возврат к шагу 2.
5a. Клиент не подтверждает запись в течение 10 минут: Система освобождает время.
6a. Подтверждение не удаётся доставить: Система показывает номер записи
на экране и помечает запись для звонка со стойки приёма.
Частые ошибки#
- Подробности экрана в шагах («нажимает зелёную кнопку») → описывайте намерение («клиент выбирает время»).
- Неверный уровень цели → включите подфункции вроде «Войти в систему» или «Ввести номер телефона» в варианты использования уровня цели пользователя.
- Слишком много шагов → больше десяти обычно означает подробности экрана или слишком низкий уровень.
- Нет расширений → именно в них прячется большая часть пропущенных требований.
- Только успешный исход → укажите и минимальные гарантии на случай неудачи.
- Злоупотребление include и extend → сохраняйте диаграмму читаемой; подробности несёт текст.
- Диаграмма без текста → одни овалы — ещё не требования.
Источники и что почитать#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.47 «Варианты использования и сценарии».
- A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000. Рус. изд.: А. Коберн. Современные методы описания функциональных требований к системам. Гл. 2 (вариант использования как соглашение о поведении), гл. 5 (уровни целей), гл. 11, разд. 11.1 (полный шаблон).
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Гл. 11 (диаграммы вариантов использования, include и extend).
- Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекции 4–5.
- Шаблоны документов IBM Rational Unified Process (RUP): Vision, Software Requirements Specification, Requirements Management Plan.
- Учебные материалы по бизнес-анализу (парный пример: вариант использования и пользовательская история).