Use Cases (сценарии использования, И. Якобсон, А. Кокберн)

Весной 1986 года инженер шведской Ericsson Ивар Якобсон бился над задачей, которая сегодня кажется очевидной: как описать, что должна делать огромная система телефонных станций AXE, так, чтобы это одинаково понимали заказчики-операторы, проектировщики и испытатели. В телефонии уже существовали «случаи трафика» — описания того, как проходит вызов от снятия трубки до разговора. Якобсон обобщил их: любая система нужна для того, чтобы кто-то снаружи достиг с её помощью своей цели, и каждую такую цель можно описать как сценарий взаимодействия. В 1987 году на конференции OOPSLA он представил первую статью о сценариях использования (use cases), а через пять лет книга «Object-Oriented Software Engineering: A Use Case Driven Approach» сделала их главным способом записывать функциональные требования. Спустя три десятилетия исследователи Люксембургского университета показали в двух промышленных проектах, что из хорошо написанных сценариев использования можно автоматически получать приёмочные тесты: 95 % шагов сценариев были переведены в формальные условия, а сгенерированные тесты покрыли не только все сценарии, которые вручную написали эксперты, но и критические случаи, о которых эксперты не подумали.

Функциональные требования и сценарии использования (Use Cases) — методика описания того, что должна делать система, через цели её пользователей. Сценарий использования рассказывает историю: кто (актор) хочет чего добиться (цель), что должно быть верно в начале (предусловие), как проходит успешный путь (основной сценарий), что может пойти не так и как система на это реагирует (расширения), что гарантированно верно в конце (гарантия успеха). Функциональные требования выводятся из шагов сценариев: каждое отвечает на вопрос «что система должна сделать», имеет источник — бизнес-требование или заинтересованную сторону, — и способ проверки. Требование, у которого нет источника, некому уточнить и принять; требование без проверки невозможно закрыть.

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

Происхождение и исследовательская база сценариев использования (Use Cases)

Ивар Якобсон: от случаев трафика к объектно-ориентированной инженерии

Ивар Якобсон пришёл к сценариям использования из практики Ericsson, где с конца 1960-х развивал компонентную архитектуру телефонных станций. Работая весной 1986 года над тем, как отобразить случаи трафика на функции системы, он сформулировал понятие use case. Первая публикация — доклад на OOPSLA в 1987 году. В 1992 году вышла книга «Object-Oriented Software Engineering: A Use Case Driven Approach» (соавторы — Кристерсон, Йонссон и Эвергорд), которая заложила метод OOSE: модель сценариев использования становится центром разработки, от неё строятся модель анализа, проектирование и тестирование. В 1994 году Якобсон перенёс подход на бизнес-процессы (книга «The Object Advantage»), введя бизнес-сценарии использования. В середине 1990-х вместе с Грейди Бучем и Джеймсом Рамбо он создал язык UML, стандартизованный консорциумом OMG в 1997 году, — диаграмма вариантов использования стала его частью.

Алистер Кокберн: текст важнее диаграммы

Алистер Кокберн в книге «Writing Effective Use Cases» (Addison-Wesley, 2001; премия Jolt) сместил акцент: главное в сценарии использования — текст, а не рисунок с человечками и овалами. Кокберн ввёл ключевые понятия, без которых сейчас не обходится ни один шаблон. Основной актор — тот, у кого есть цель и кто инициирует взаимодействие; второстепенный актор — внешняя система или человек, от которого система получает помощь. Заинтересованные стороны и их интересы — сценарий защищает интересы не только основного актора, но и всех, кого затрагивает результат. Область проектирования — что считается «системой»: вся организация, программная система или подсистема. Уровни целей — обобщённый уровень («облако» и «воздушный змей»), уровень цели пользователя («уровень моря») и уровень подфункции («рыба» и «моллюск»). Предусловие, триггер и гарантии — минимальная гарантия, которая верна при любом исходе, и гарантия успеха. Основной сценарий успеха и расширения — ответвления, привязанные к номерам шагов.

Уровни точности Кокберна

Кокберн предлагает писать сценарии использования «вширь, а не вглубь» — сначала по всем целям с низкой точностью, затем углубляя. Уровень точности 1 — основной актор и его цель; уровень 2 — краткое описание или основной сценарий; уровень 3 — условия расширений; уровень 4 — шаги обработки расширений. Такой порядок позволяет рано увидеть всю картину функциональности, оценить проект и не тратить время на детали сценариев, которые потом окажутся не нужны.

Use-Case 2.0: сценарии использования в гибкой разработке

В 2011 году Якобсон, Ян Спенс и Курт Битнер опубликовали руководство «Use-Case 2.0: The Guide to Succeeding with Use Cases», адаптировав метод к итеративной разработке. Ключевое понятие — срез сценария использования (use-case slice): одна или несколько историй сценария вместе с тестами, которые можно реализовать за одну итерацию. Срезы становятся элементами бэклога. Руководство формулирует шесть принципов: держать всё простым, рассказывая истории; понимать общую картину; фокусироваться на ценности; строить систему срезами; поставлять систему инкрементами; адаптировать практику под команду. В статье «Use-Case 2.0: The Hub of Software Development» (ACM Queue, 2016) Якобсон, Спенс и Брайан Керр описали сценарии использования как центр, вокруг которого строятся требования, архитектура, тестирование и планирование.

Стандарт и проверяемость требований

Международный стандарт ISO/IEC/IEEE 29148:2018 задаёт характеристики хорошего требования — необходимость, однозначность, полнота, единичность, выполнимость, проверяемость, корректность и трассируемость. Для подтверждения требований в системной инженерии используют четыре метода: тест (выполнение с измерением результата), демонстрация (показ работы без измерений), анализ (расчёт или моделирование) и инспекция (осмотр документа, кода или изделия). Если для требования невозможно назвать ни метод, ни наблюдаемый критерий приёмки, оно сформулировано плохо и должно быть переписано.

Эмпирическая база

Бенте Анда, Кай Хансен и Гуннар Санд в работе «An investigation of use case quality in a large safety-critical software development project» (Information and Software Technology, 2009) проследили изменения моделей сценариев использования на этапе анализа крупного проекта с повышенными требованиями к безопасности и показали, как моделирование сценариев улучшало корректность, полноту и ясность функциональных требований — и какие аспекты моделирования давались команде труднее всего. Чунхуэй Ван, Фабрицио Пасторе, Арда Гёкнил и Лионель Бриан («Automatic Generation of Acceptance Test Cases From Use Case Specifications: An NLP-Based Approach», IEEE Transactions on Software Engineering, 2020) построили подход UMTG, который генерирует приёмочные тесты из спецификаций сценариев использования, — именно его результаты на двух промышленных проектах приведены во вступлении.

Ключевые идеи и принципы сценариев использования (Use Cases)

Функциональное требование без источника и без проверки — это пожелание, а не требование.

Принцип: сценарий назван целью актора

Название сценария использования — цель основного актора в форме «глагол + объект»: «Оформить заказ», «Вернуть товар», «Согласовать договор». Не «Модуль заказов» и не «Экран корзины». Если название не формулируется как цель — это не сценарий использования, а функция или экран, и её место внутри другого сценария.

Принцип: уровень цели пользователя — главный

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

Принцип: основной сценарий — успешный путь без ветвлений

Основной сценарий успеха — пронумерованные шаги от триггера до достижения цели, обычно от 3 до 9. Каждый шаг — одно действие актора или системы, сформулированное простым предложением: кто что делает. В основном сценарии нет «если»: все ветвления уходят в расширения.

Принцип: расширения — там, где живут требования

Расширение привязано к номеру шага и начинается с условия: «3а. Товара нет на складе», «5б. Платёж отклонён». Опыт Кокберна и последующих исследований показывает, что именно в расширениях обнаруживается большая часть пропущенных требований: что система делает при ошибке, отказе внешней системы, неполных данных. Расширения пишутся мозговым штурмом — сначала все условия, затем обработка каждого.

Принцип: акторы — роли, а не люди

Актор — роль по отношению к системе: «Менеджер по продажам», «Платёжный шлюз», «Покупатель». Один человек может выступать в нескольких ролях, одна роль — объединять многих людей. Внешние системы тоже акторы. Список акторов задаёт границу системы: всё, что за ней, описывается только через взаимодействие.

Принцип: предусловие и гарантии ограничивают сценарий

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

Принцип: каждое функциональное требование имеет источник

Функциональное требование выводится из шага или расширения сценария и ссылается на то, ради чего существует: бизнес-требование из документа бизнес-требований (BRD) или потребность конкретной заинтересованной стороны. Источник нужен, чтобы знать, у кого уточнять требование, кто его принимает и что произойдёт с требованием, если исходная потребность отпадёт.

Принцип: каждое функциональное требование проверяемо

Для каждого требования задаются метод проверки — тест, демонстрация, анализ или инспекция — и критерий приёмки: наблюдаемый результат, при котором требование считается выполненным. «Система должна быстро искать товар» непроверяемо; «поиск по артикулу возвращает результат не дольше 2 секунд при каталоге до 100 тысяч позиций» — проверяемо тестом.

Принцип: трассируемость в обе стороны

Цепочка «бизнес-требование → сценарий использования → функциональное требование → тест» позволяет ответить на два вопроса: зачем существует эта функция и как мы узнаем, что она работает. При изменении бизнес-требования сразу видно, какие сценарии и требования затронуты, а при падении теста — какая потребность бизнеса не выполнена.

Шаблон сценария использования

Полный шаблон в стиле Кокберна (fully dressed) содержит:

1. Название — цель основного актора.

2. Область проектирования и уровень цели.

3. Основной актор и второстепенные акторы.

4. Заинтересованные стороны и их интересы.

5. Предусловие и триггер.

6. Минимальная гарантия и гарантия успеха.

7. Основной сценарий успеха — пронумерованные шаги.

8. Расширения — условие и обработка, привязанные к шагам.

9. Технологические варианты и открытые вопросы.

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

Ограничения, слепые зоны и критика сценариев использования (Use Cases)

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

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

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

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

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

Чем методика не является. Сценарии использования — не пользовательские истории: история — короткое обещание разговора, сценарий — полное описание взаимодействия с ветвлениями. Это и не описание интерфейса: в хорошем сценарии нет кнопок и полей, только намерения и ответы системы. И это не бизнес-требования: «зачем» описывается в BRD, а сценарии описывают «как актор достигает цели с помощью системы».

Типовые ошибки при написании сценариев использования и функциональных требований

Ошибка 1: описание интерфейса вместо намерения.

В шагах появляются кнопки, поля и экраны: «пользователь нажимает "Сохранить" в правом верхнем углу». Сценарий привязывается к дизайну, который ещё изменится, а суть взаимодействия теряется.

Как избежать: пишите намерения — «менеджер подтверждает заказ», «система сохраняет заказ и показывает его номер». Детали интерфейса — в макетах.

Ошибка 2: сценарии-функции вместо целей.

Модель состоит из «Создать запись», «Редактировать запись», «Удалить запись». Ни один сценарий не отвечает на вопрос, зачем актору система, а проверить достижение бизнес-целей невозможно.

Как избежать: называйте сценарии целями уровня моря. Операции CRUD объединяйте в один сценарий «Управлять каталогом» или выносите в подфункции.

Ошибка 3: нет расширений.

Описан только успешный путь. Всё, что происходит при ошибках, отказах внешних систем и неполных данных, разработчики придумывают сами — по-разному.

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

Ошибка 4: требование без источника.

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

Как избежать: у каждого требования — ссылка на бизнес-требование или заинтересованную сторону. Требования без источника выносите на согласование отдельным списком.

Ошибка 5: требование нельзя проверить.

«Удобно», «быстро», «надёжно», «по возможности» — формулировки, которые невозможно закрыть. Приёмка превращается в спор, а тестировщик пишет тесты на собственное понимание.

Как избежать: для каждого требования задайте метод проверки (тест, демонстрация, анализ, инспекция) и критерий приёмки — наблюдаемый результат с числами там, где они уместны.

Ошибка 6: путаница уровней.

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

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

Ошибка 7: слишком подробно слишком рано.

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

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

Главное, что нужно знать о сценариях использования (Use Cases)

• Сценарий использования описывает, как актор достигает своей цели с помощью системы: предусловие, основной сценарий, расширения, гарантии.

• Метод создан Иваром Якобсоном (Ericsson, OOPSLA'87, книга 1992 года), текстовый шаблон и уровни целей предложил Алистер Кокберн (2001), гибкую версию — Якобсон, Спенс и Битнер (Use-Case 2.0, 2011).

• Главный уровень — цель пользователя («уровень моря»); название сценария — глагол и объект.

• Большая часть требований скрыта в расширениях — что происходит, когда шаг пошёл не так.

• Каждое функциональное требование имеет источник (бизнес-требование или заинтересованную сторону), метод проверки и критерий приёмки.

• Цепочка «BRD → сценарий → функциональное требование → тест» делает требования трассируемыми, а приёмку — объективной.

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

План внедрения сценариев использования (Use Cases)

Неделя 1. Акторы и цели. По бизнес-требованиям и интервью составьте список акторов — ролей людей и внешних систем. Для каждого основного актора выпишите цели уровня моря. Утвердите список целей с заинтересованными сторонами — это карта всей функциональности.

Неделя 2. Основные сценарии. Для приоритетных целей напишите основные сценарии успеха: 3–9 шагов, каждый — одно действие актора или системы. Добавьте предусловия и гарантии успеха. Проверьте, что ни в одном шаге нет кнопок и полей.

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

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

Далее: поддержание. При изменении бизнес-требований обновляйте связанные сценарии и требования по цепочке трассировки. Новые цели добавляйте сначала в карту целей, затем углубляйте по уровням точности.

Как реализовать этот план с помощью фрейма «Функциональные требования и сценарии использования (Use Cases)» в OrgDevTools

Фрейм «Функциональные требования и сценарии использования (Use Cases)» — бесплатный тренажёр на странице методики. Он ведёт от акторов к сценариям и требованиям и на ходу проверяет главное: у каждого требования есть источник и проверка. Над вкладками всегда видна строка из шести проверок, которые загораются зелёным: у сценариев есть основной актор, основной сценарий от трёх шагов, у сценариев есть расширения, у требований есть источник, у требований есть проверка, каждое требование выведено из сценария.

Вкладка «1. Акторы» — неделя 1 плана

Слева — список акторов: каждый пункт отдельной строкой, новый добавляется клавишей Enter или ссылкой «+ добавить». Справа — памятка по трём уровням целей Кокберна (обобщённый, цель пользователя, подфункция) с пояснением каждого.

Вкладка «2. Сценарии» — недели 2–3 плана

Каждый сценарий — карточка: название-цель, выбор основного актора из списка первой вкладки, выбор уровня цели (по умолчанию — цель пользователя). Кнопка со счётчиком «шаги · расширения» раскрывает карточку: предусловие, гарантия успеха, список шагов основного сценария и список расширений — каждый пункт отдельной строкой. Сценарий без актора или с основным сценарием короче трёх шагов подсвечивается красной рамкой.

Вкладка «3. Требования и проверка» — недели 3–4 плана

Каждое функциональное требование — карточка: текст, выбор сценария, из которого оно выведено, поле источника (бизнес-требование или заинтересованная сторона), четыре кнопки метода проверки (тест, демонстрация, анализ, инспекция) и поле критерия приёмки. Требование без источника, метода или критерия подсвечивается красной рамкой.

Вкладка «Визуализация»

Полоса готовности показывает, сколько из шести проверок пройдено. Ниже — трассировка: по каждому сценарию (цвет — уровень цели) метки его требований, зелёные — если у требования есть источник, метод и критерий, красные — если чего-то не хватает; отдельная строка «Без сценария» для непривязанных требований. Внизу — счётчики требований по методам проверки.

Вкладка «Итоги»

Вердикт вычисляется автоматически и называет первую проблему по порядку: нет сценариев → первый сценарий без актора → первый основной сценарий короче трёх шагов → нет требований → первое требование без источника → первое требование без проверки → первое требование без сценария → первый сценарий без расширений. Когда всё пройдено — вердикт сообщает, что требования готовы к передаче в разработку и тестирование, с числом сценариев и требований. Под вердиктом — список шести проверок, в рабочей тетради — кнопка создания задачи со списком непройденных проверок.

Чего фрейм не делает

Фрейм не оценивает качество формулировок: не ловит интерфейсные детали в шагах, расплывчатые слова в требованиях и неверный уровень цели. Он не нумерует шаги и не привязывает расширения к номерам шагов — это делается в тексте расширения. Источник — свободный текст, а не ссылка на конкретное требование BRD. Фрейм не рисует диаграмму вариантов использования UML и не генерирует тесты. Печатный документ — шаблон «Функциональные требования (спецификация сценариев использования)» в разделе «Шаблоны» Библиотеки: его можно забрать к себе в Базу знаний, заполнить, распечатать или сохранить в PDF. Нефункциональные требования и полную спецификацию ведите по методике спецификации требований к ПО (SRS).