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

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

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

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

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

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

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