Use-case 3.0: краткое руководство
В феврале 2024 года Ивар Якобсон и Алистер Кокберн опубликовали набор принципов и ключевых концепций, лежащих в основе всех успешных применений вариантов использования. Документ был назван The Use-Case Foundation.
В декабре 2024 года Ивар Якобсон опубликовал руководство Use cases 3.0, которое дополняет The Use-Case Foundation, а также является полноценным руководством для успешного применения вариантов использования.
В рамках текущей статьи, приведено основное, краткое содержание руководства Use-Case 3.0, — без отступлений, и дополнительных пояснений по тому или иному пункту.
Что есть Use-case 3.0?
Ключевые концепции
Принципы
Практики
Анатомия Use-Case 3.0
Карта Альф Use-Case 3.0
Жизненный цикл альфы — Вариант использования
Жизненный цикл альфы — Срез варианта использования
Результаты работ — артефакты (Work products)
Деятельность (Activities)
Нефункциональные требования
Жизненные циклы разработки
Рабочий стол (Workbench)
В заключении
Что есть Use-Case 3.0?
Use-Case 3.0 — это масштабируемое и гибкое семейство практик для сбора требований и управления инкрементальной разработкой системы с целью выполнения требований.
Семейство практик Use case 3.0 обладает следующими свойствами:
Легкое — как по определению, так и по применению.
Масштабируемое — подходит для команд и систем любого размера.
Адаптируемое — подходит для всех типов систем и подходов к разработке.
Простое в использовании — практики Use cases 3.0 могут быть быстро внедрены в рабочий процесс.
Простой пример варианта использования:
Ключевые концепции
Ключевые концепции лежат в основе всей методологии. В конкретных практиках есть дополнительные концепции, которые относятся к данным практикам.
Вариант использования — это все способы использования системы для достижения одной цели пользователя:
Сюда входят все успешные и неудачные пути.
Он может быть описан текстом или визуально.
Он не зависит от реализации, технологии и платформы.
Целевая система (система интереса) — система, используемая для достижения поставленной цели.
Актор — роль, выполняемая при взаимодействии с системой. Это может быть человек, организация, программное обеспечение или их комбинация. Вариант использования может включать множество акторов:
Актор, который инициирует вариант использования, называется «основным актором» или «главным актором».
Акторы, к которым система обращается в ходе выполнения варианта использования, называются «вспомогательными акторами».
Цель — причина, по которой пользователь будет использовать систему, и ценность, которую он получит при успешном использовании системы.
Сценарий — это полная последовательность шагов через весь вариант использования — от момента, когда Актор инициирует Вариант использования, до момента его завершения. Сценарий описывается как простая последовательность шагов, каждый из которых включает выполнение действий системой и/или одним из акторов. Примеры сценариев для варианта использования «Снять наличные» из банкомата:
Сценарий 1: Пользователь вводит правильные учетные данные и снимает наличные.
Сценарий 2: Пользователь вводит неверные учётные данные три раза, и счет блокируется.
Сценарий 3: Пользователь забывает учетные данные, сбрасывает пароль перед входом в систему и снимает наличные.
Базовый сценарий — это нормальный, успешный путь к достижению ценности, часто называемый «основным сценарием», или «успешным путём» (happy path). В примере с банкоматом это сценарий 1.
Расширения — это список всех особых случаев, альтернативных путей, необязательных шагов и ошибок, которые необходимо обработать. Есть два типа расширений:
Первый тип — это альтернативный путь варианта использования, который отклоняется от базового сценария для выполнения одного или нескольких альтернативных шагов, и затем возвращается для завершения базового сценария.
Второй тип расширения отклоняется от базового сценария из-за возникающих ошибок, в этом случае пользователь не может достичь своей цели при завершении сценария.
Модель вариантов использования — это модель, которая фиксирует и визуализирует все полезные способы использования системы. Она позволяет очень быстро определить границы системы — что включено, а что исключено — и предоставить команде целостное представление о том, что будет делать система.
Срез варианта использования — это часть варианта использования, которая приносит очевидную ценность заинтересованным сторонам разработки. Срезы используются для поэтапной разработки варианта использования. Каждый срез варианта использования выступает в качестве placeholder (заполнителя) для всей работы (дизайн, код, тесты) необходимой для поставки ценности, заложенной в этом срезе.
Пример разбиения варианта использования на срезы:
Элемент работы — для планирования и выполнения каждого среза команда создаёт один или несколько рабочих элементов. Это могут быть пользовательские истории, задачи или фичи — в зависимости от процесса разработки, используемого в команде.
Принципы
Принцип 1: Универсально применимы
«Варианты использования применимы к системам всех типов и размеров: бизнес-системам, информационным системам, физическим системам или любым их комбинациям».
Принцип 2: Начните с общей картины
«Варианты использования помогают понять общую картину: цель системы и то, как она будет использоваться».
Принцип 3: Сосредоточьтесь на ценности
«Варианты использования фокусируются на ценности: целях пользователей и том, как лучше всего их достичь».
Принцип 4: Привлеките заинтересованные стороны
«Привлечение заинтересованных сторон необходимо: соберите все заинтересованные стороны, чтобы определить цель и масштаб системы».
Принцип 5: Расскажите всю историю
«Вариант использования рассказывает всю историю, как рассказ, от начального события до достижения цели или неудачи — если цель не может быть достигнута. Он включает в себя описание того, как справляться с проблемами и альтернативами, которые могут возникнуть в процессе».
Принцип 6: Инициируйте обсуждения
«Варианты использования запускают обсуждения: Обсуждая возможные сценарии, вы и ваши соавторы вспомните о пропущенных шагах и альтернативных сценариях. Эти обсуждения помогают выявить ситуации, которые часто остаются незамеченными».
Принцип 7: Отдавайте приоритет читаемости
«Отдавайте приоритет читаемости: цель — донести общую картину до всех участников, генерируя комментарии, выявляя пробелы и получая поддержку участников».
Принцип 8: Ровно столько — сколько нужно, ровно тогда — когда нужно
«Количество деталей и используемый формат будут варьироваться в зависимости от ваших обстоятельств: вы можете начать с наброска последовательности событий и добавлять детали по мере необходимости».
Принцип 9: Реализуйте поэтапно
«Вариант использования можно реализовывать поэтапно: разработать и внедрить несколько ключевых сценариев варианта использования на раннем этапе, чтобы получить ценность и обратную связь, а затем добавлять менее используемые или менее критичные сценарии по мере необходимости».
Принцип 10: Создавайте систему срезами
«Систему можно разрабатывать по срезам, где каждый срез представляет собой один или несколько путей через один из вариантов использования системы, а также соответствующий дизайн, код и тесты, используемые для их реализации и проверки».
Практики Use-Case 3.0
В зависимости от предметной области системы, и ее критичности, необходимость в моделировании и степени проработки деталей может быть разной. Чтобы способствовать этому разнообразию, руководство Use-case 3.0 предоставляет набор практик.
Взаимосвязь практик Use-Case 3.0
Практика «Use case 3.0 Foundation»
Данная практика не является конкретной практикой и не содержит в себе каких-либо активностей, это набор принципов и концепций, изложенный ранее.Все остальные практики от неё наследуются. Выделение Use case 3.0 Foundation было нужно, чтобы просто ограничить количество концепций и элементов, которые необходимо определить в других практиках UseCase 3.0.
Практика повествования (Use-Case Storytelling)
В рамках данной практики создаётся простое текстовое описание вариантов использования (Use-Case Narrative). Также может использоваться дополнительная концепция — Ограничения (Constraints) — фиксация предварительных условий, постусловий и т. д.
Практика авторства (Use-Case Authoring)
Практика применяется при работе со сложными бизнес-областями и системами. В этом случае описание (в том числе Use-Case Narrative) должно обеспечивать формальную, подробную спецификацию наиболее важных вариантов использования вашей системы.
Практика упрощённого моделирования (Use-Case Light Modeling)
В рамках практики создаётся простая визуальная модель, которая определяет и фокусируется на самых ценных аспектах вашей системы — кратко передает ценность всем заинтересованным сторонам. В рамках практики добавляются дополнительные концепции: Вспомогательные варианты использования, Диаграмма вариантов использования.
Практика структурированного моделирования (Use-Case Structured Modeling)
Практика применяется, когда вы хотите увидеть границы и масштаб системы. В этом случае вам нужно отразить всех акторов и все варианты использования. Для повышения точности и достоверности визуальной модели, вы можете использовать такие концепции как: Включение (Include), Расширение (Extends), Обобщение акторов (Actor Generalization), Обобщение вариантов использования (Use-Case Generalization.)
Композиция практик
Каждая из практик может быть использована в отдельности, однако для достижения наилучшего результата, вы можете комбинировать их в зависимости от своих потребностей. Например использовать практику повествования (Storytelling practice) в сочетании с практикой упрощённого моделирования (Light Modeling practice). Также вы можете выбрать разные практики ни только в рамках всего проекта, но и в рамках отдельного варианта использования. На диаграмме ниже, каждый вариант подписан той практикой в рамках которой он фиксируется.
Пример использования разных практик для вариантов использования
Степень проработки артефактов в практиках
Степень проработки артефактов в практиках
Подробнее об уровнях проработки в разделе «Результаты работ — артефакты (work products)».
Резюме по практикам:
Практика | Тип | Детализация | Артефакты |
Практика повествования | Текстовая | Простая | • Сопроводительная информация |
Практика авторства | Текстовая, сценарная | Высокая | • Сопроводительная информация |
Практика упрощённого моделирования | Визуальная | Простая | • Сопроводительная информация |
Практика структурированного моделирования | Визуальная | Высокая | • Сопроводительная информация |
Анатомия Use-case 3.0
Самый большой раздел руководства, в котором подробно описывается как работает, и каким образом элементы методологии Use case 3.0 связаны между собой. Для описания используется The Essence language (язык моделирования).
The essence language: ключевые концепции
Карта Альф Use-Case 3.0
В Use-Case 3.0 требования фиксируются как набор вариантов использования, которые определяют границы системы и рассматриваются как набор слайсов вариантов использования. Любые изменения, запрошенные заинтересованными сторонами, приводят к дополнению или изменению набора вариантов использования и слайсов вариантов использования.
Карта альф Use-Case 3.0
Жизненный цикл альфы — Вариант использования (Use-Сase Alpha)
Жизненный цикл Варианта использования
Цель установлена (Goal Established): цель варианта использования установлена, ценность для пользователя и других заинтересованных сторон ясна.
Сценарии понятны (Scenarios Understood:): структура варианта использования достаточно понятна для того, чтобы команда могла начать работу по реализации первых срезов варианта использования.
Базовый сценарий реализован (Basic Scenario Enabled): базовый сценарий может быть успешно пройден от начала до конца.
Достаточное количество сценариев реализовано (Sufficient Scenarios Fulfilled): система выполняет достаточное количество сценариев использования, чтобы предоставить пригодное для использования решение.
Все сценарии выполнены (All Scenarios Fulfilled): система выполняет все сценарии варианта использования.
Жизненный цикл альфы — Срез варианта использования (Use-Case Slice Alpha)
Жизненный цикл Среза Варианта использования
Идентифицирован (Identified): определены границы среза и перечень сценариев.
Определён (Defined): объем среза был уточнен путем проработки сценариев. Определён набор тестовых случаев для четкого определения того, что означает успешная реализация среза. Была сделана общая оценка работ, необходимых для подготовки, реализации и тестирования среза.
Подготовлен (Prepared): рабочие элементы (задачи или пользовательские истории), необходимые для реализации среза, были оценены и добавлены в бэклог команды и/ или планы.
Реализован (Implemented): срез готов к тестированию.
Проверен (Verified): срез проверен и готов к релизу.
Результаты работ — артефакты (work products)
Взаимосвязь результатов работы в Use-Case 3.0
Сопроводительная информация (supporting information)
Цель сопроводительной информации — зафиксировать важные термины, используемые для описания системы, а также любые требования, которые не вписываются в описание вариантов использования.
Уровни проработки
Уровень | Описание |
Сделаны заметки | Базовый уровень детализации. Представляет собой лишь краткое изложение наиболее очевидных терминов и областей, которые необходимо рассмотреть. |
Определена в простом виде | Все термины, на которые ссылаются описания вариантов использования, должны быть определены. А также должны быть указаны атрибуты качества системы. На этом уровне они фиксируются как простые списки декларативных утверждений. |
Смоделирована и проиллюстрирована | На этом уровне используются дополнительные методы, такие как каталог бизнес-правил, модели предметной области. |
Всесторонне определена | На этом уровне предоставляются исчерпывающие примеры из предметной области, а также фиксируются дополнительные выводы. Документация содержит перекрёстные ссылки. |
Тест-кейс (Test-Case)
Целью тест-кейса является предоставление четкого определения того, что означает выполнение части требований. Тест-кейс определяет набор входных данных и ожидаемых результатов с целью оценки того, правильно ли работает система.
Уровни проработки
Уровень | Описание |
Сформулированы идеи | Зафиксированы первоначальные идеи, которые будут лежать в основе тест-кейсов. |
Сценарий выбран | Выбраны сценарии варианта использования для покрытия тест-кейсами. Тест-кейс описан в достаточной степени для дальнейшего тестирования и сопровождения системы. |
Переменные определены | Определены возможные значения, — диапазоны данных для тестирования. Уровень может быть полезен в тех ситуациях, когда требуется проводить исследовательское тестирование. |
Подготовлен набор данных | Подготовлены наборы данных для тестирования с учётом специфики задачи. |
Автоматизирован | Тест-кейс запускается без ручного вмешательства. |
Модель вариантов использования (Use-Case Model)
Цель модели вариантов использования — охватить все полезные способы использования системы в доступном формате, который отражает требования системы и может использоваться для управления разработкой.
Уровни проработки
Уровень | Описание |
Ценность определена | Определены наиболее важные акторы и варианты использования — те, которые обеспечивают ценность системы. |
Границы системы определены | Все акторы и все варианты использования определены. |
Модель структурирована | Модель структурирована, на ней отсутствуют дубликаты информации. Отображены и выделены общие варианты использования, которые являются расширениями для других вариантов использования. |
Описание варианта использования (Use-Case Narrative)
Целью описания варианта использования является рассказ о том, как система и ее участники работают вместе для достижения определенной цели.
Уровни проработки
Уровень | Описание |
Кратко описан | Зафиксированы цель и актор, который инициирует запуск варианта использования. |
Маркированный набросок | Зафиксированы маркированный список шагов базового сценария и названия расширений. Подходит для команд, которые тесно сотрудничают со своими пользователями и могут восполнить любые недостающие детали через живое общения. |
Необходимый набросок | Зафиксирована и разграничена ответственность между пользователем и системой при выполнении варианта использования. На этом уровне детализации описание является диалогом между системой и ее акторами. |
Всесторонне описан | Наиболее подробный уровень детализации. Содержит формальное описание с учётом всех деталей, и возможных ошибок. |
Деятельность (Activities)
Виды деятельности распределены по двум группам: 1) те, которые работают с требованиями; 2) те, которые непосредственно связаны с реализацией системы.
Виды деятельности в Use-Case 3.0
Найдите Акторов и Варианты использования (Find Actors and Use Cases)
Для этого:
Согласуйте цели системы.
Согласуйте новое поведение системы и ценность, которую система предоставляет пользователям.
Определите объем релизов системы.
Определить способы использования и тестирования системы.
Опишите и разделите Вариант использования на Срезы (Describe and Slice a Use Case)
В рамках данного вида деятельности вам нужно сформировать понимание относительно варианта использования и создать первые срезы варианта использования.
Для этого
Согласуйте с пользователями границы варианта использования и его сценарии.
Создайте рабочие элементы (work items) подходящего размера для работы команды.
Убедитесь, что работа соответствует установленным срокам и бюджету.
Продемонстрируйте прогресс и понимание потребностей.
Подготовьте Срез Варианта использования (Prepare a Use-Case Slice)
Для этого
Подготовьте срез к реализации.
Оцените трудозатраты для реализации и тестирования среза.
Точно определите, что означает успешная реализация среза.
Определите нефункциональные требования.
Сосредоточьте разработку системы на тестах.
Разделите работу на набор более мелких рабочих элементов (например, пользовательских историй, функций или задач), которые могут быть добавлены в бэклог или план команды.
Наблюдайте и адаптируйте (Inspect and Adapt the Use Cases)
Чтобы управлять изменениями, отслеживать прогресс, укладывать работу в рамки доступного времени и бюджета необходимо постоянно улучшать модель вариантов использования, варианты использования и срезы вариантов использования.
Для этого
Поддерживайте актуальность модели вариантов использования.
Настраивайте размер срезов для увеличения пропускной способности.
Нефункциональные требования
Нефункциональные требования могут быть указаны прямо внутри описания варианта использования, например применимо к отдельному шагу сценария или ко всему сценарию. Если нефункциональные требования имеют широкое применение, то можно создать отдельные инфраструктурные варианты использования (infrastructure use cases), которые будут рассматриваться как сквозные, общие для всей системы.
Жизненные циклы разработки
Use-Case 3.0 работает со всеми популярными жизненными циклами разработки программного обеспечения. В руководстве содержатся комментарии о применении Use-Case 3.0 с такими подходами как: backlog-driven iterations, one-piece flow, waterfall.
Пользовательская история как элемент работы (work item)
Из срезов варианта использования можно получить пользовательские истории (user stories) и создать их карту.
Выявление пользовательских историй из среза варианта использования
Шаги среза предоставляют входные данные для дальнейшего мозгового штурма и выявления пользовательских историй. На красных карточках расположены — технические истории. На фиолетовых — инициирующее событие слева, — и достигнутые цели справа. На зелёных — шаги сценария среза, на синих — пользовательские истории.
Рабочий стол (Workbench)
На сайте Ивара Якобсона есть доска с описанием всех сущностей Use case 3.0, которые имеют перекрёстные ссылки и содержат короткое ясное описание (инструмент требует авторизации).
Шаги
Внизу панели, вы можете выбрать конкретную практику.
Cправа отобразится описание практики со всеми видами деятельности и результатами работ, предусмотренными в рамках данной практики. При клике далее, можно увидеть чек-лист для каждого артефакта с учётом уровня его проработки.
В заключении
В руководстве Use-case 3.0, Ивар Якобсон выделяет и формально описывает четыре конкретные практики под разные нужды команд (упрощённые практики для простых систем и более детальные для сложных систем). Часто на этом уровне, при отсутствии явного разграничения, происходила путаница: на сколько детальными должны быть варианты использования? Является ли построение визуальной модели, без их текстового описания, практикой Use-case? В остальном автор обобщает и дополняет уже известные, во многом устоявшиеся концепции.
