Нельзя сказать, что в методах системного анализа ничего не происходит. Вот, например, Ивар Якобсон совместно с Алистером Коберном на днях выпустили новое(!) руководство по юскейсам: Use Cases 3.0 (pdf)Версия 3.0! Кто-то слышал про Use Cases 2.0? Там появилась такая идея, как "слайсы" — срезы юскейсов, напоминаюшие чем-то разбивку юзер-сторей, про которую я рассказывал на Flow в 2022 году.Вообще, я и Ивара и Алистера очень уважаю, но ещё первая книге Коберна звучала как монолог из советского фильма: "Не будет ни театра, ни кино — одно сплошное телевидение одни сплошые use cases!", ничего, кроме юскейсов, вам для описания системы не нужно, и юскейсами можно описывать всё на любом уровне — от бизнеса до глубоко внутренних процессов внутри системы, и, конечно же, интеграции.Собственно, Use Cases 3.0 ровно об этом. Они вводят 10 принципов:1. Юзкейсами можно описывать любые системы: и бизнес, и ИТ-системы, и физические;2. Юзкейсы помогают увидеть "картину в целом": назначение системы и как ей пользоваться;3. Юзкейсы фокусируются на ценностях: целях пользователя и как лучше всего достичь их;4. Вовлечение стейкхолдеров обязательно: соберите их всех;5. Юзкейс рассказывает историю, от начального события до получения ценности или неудачи, включая все альтернативы и проблемы;6. Юзкейс должен вызывать обсуждения — только так вы обнаружите все пропущенные шаги и расширения;7. Приоритет — удобство чтения. Цель — представить общую картину всем вовлеченным сторонам, получить комментарии, подсветить все пробелы, получить все согласия;8. Формат юзкейса и уровень детализации может быть очень разным: вы можете начать с наброска последовательности событий и добавлять детали постепенно;9. Юзкейс реализуется поэтапно: сначала разрабатываются ключевые сценарии, потом более редкие и менее критичные;10. Система может быть разработана через "слайсы" юзкейсов, каждый слайс добавляет свою часть архитектуры, кода и тестов.Ну, если не брать слайсы, ничего особо нового тут нет — всё это и раньше говорилось. Разве что подчеркну акцент на сторителлинге, принцип 5: юзкейс — это история. Поэтому, собственно, не может быть юзкейса "отредактировать заявку" или "удалить документ" — сложно про такие элементарные действия рассказать историю. А начнете рассказывать — уровень формулировки юзкейса сразу повысится.Что ещё нового: использование юзкейсов описано в терминах Essence, как практика (с Альфами, их состояниями — жизненным циклом — и всяким таким). А вот что на самом деле интересно: авторы наконец-то дают ответ на вопрос, как юзкейсы связаны с user story.Оказывается, вот как: диаграмма юзкейсов описывает всю систему, отдельный юзкейс описывает одну цель пользователя, слайс юзкейса описывает один из способов достижения этой цели с возможными ограничениями, а user story — это, оказывается, единица работы, которую нужно выполнить, чтобы реализовать этот слайс (на один слайс может приходиться несколько юзер сторей). Единицей работы может быть также задача (task) или фича.В общем, для меня вся эта история выглядит, как попытка объяснить всем, что наш метод ещё ого-го! И вовсе он не устарел! И очень даже он крутой! А то, что вы там какие-то юзер-стори наизобретали, или job story, или ещё какой хипстерский способ описания — мы сейчас вам докажем, что это ерунда, и нужно использовать проверенный дедовский метод.Впрочем, если брать не юзер стори как таковые, а User Story Map — то там как раз довольно явно становятся видны юзкейсы (как шаги процесса в шапке карты), и юзер-стори, представляющие собой отдельные шаги или требования к шагам. Возможно, что-то в этом есть, и в руководстве приводится даже пример такого сочетания слайса и USM.Заодно обращу внимание, что никаких "пакетов юзкейсов" или "системных юзкейсов" в этом руководстве нет (но есть "инфраструктурные юзкейсы"!)В общем, если вы интенсивно используете в работе юзкейсы — вам должно быть любопытно, как их создатели видят их на исходе 2024 года (почти через 30 лет после изобретения).UPD: Добавил картинку с юзкейсом и юзер-сторями
