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

А вот в лице LLM мы находим благодарного читателя. Он читает быстро, и ему не лень перелопатить десяток сценариев. А польза несомненна — например, интерфейсы и клиентов на основе сценариев ИИ генерирует замечательно. В принципе, на основе сценариев много что можно создать — и структуру API, и модель данных, и для разбивки на микросервисы они очень помогают: отлично работают, как формализация Event Storming, и дальше удобно анализировать по ним потоки данных, границы сервисов и нагрузку.

Писать самому сценарии тоже не нужно, пусть машина пишет, а мы поправим. И тут возникает ещё одна вещь, никогда ранее никем не виданная: fully dressed use case. У Коберна описана структура полного описания юскейса, примерно страницы на две. Мы же обычно в практике ограничиваемся коротким набором:
* Код
* Название
* Действующие лица
* Предусловия
* Триггер
* Постусловия
* Шаги основного сценария
* Альтернативы / Исключения / Расширения

А можно ещё так много дописать! Вот смотрите, что у Коберна:
* Действующие лица разделены на Главное действующее лицо и Второстепенных действующих лиц
* Есть область действия (Scope): проект и система
* Уровень (от бизнес-юскейса до взаимодействия модулей)
* Стейкхолдеры и их интересы: кому нужен этот юскейс и в чем их интерес?
* Минимальные гарантии: даже если юскейс не будет выполнен, что гарантируется? (в каком состоянии будет система)
* Гарантии при успехе (отдельно)
* Соответствие бизнес-правилам (ссылки на бизнес-правила)
* Используемые технологии и форматы данных, их варианты
* Приоритет
* Целевой релиз
* Частота использования
* Ожидаемое время отклика / время выполнения
* Каналы взаимодействия для главного действующего лица / второстепенных действующих лиц
* Открытые вопросы

А вот что ещё можно добавить:
* Автор
* Источник
* Статус
* Версия
* Дата последнего изменения
* Уровень архитектуры
* Требования безопасности
* Требования локализации / i18n
* Требования к доступности (WCAG / ГОСТ Р 52872-2019)
* Масштабируемость: число конкурирующих запросов
* Нефункциональные требования (прочие)
* Спецификация данных (словарь) для хранения / ввода / вывода
* Интерфейсные решения / прототипы интерфейсов
* Допущения и предположения
* Ссылки на связанные требования
* Рекомендации по тестированию

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

А вот машине всё равно — она и написать не затруднится, и прочитать не поленится. А самое главное — она же для себя пишет, и действительно может использовать всё написанное. А другая машина может проконтролировать, и тут чем детальнее описано, тем проще проконтролировать. На месте Коберна я бы сейчас активно продвигал какой-нибудь фреймворк для AI SDD на основе юскейсов.