Relic Hunter,
Забыли дополнить, потом уволили всех разработчиков и закрыли/обанкротили фирму - т.к. что наделали разработчики осталось великой тайной - зачем оно вообще
бизнесу и как это поддерживать/дорабатывать после ухода "аксакалов".
Без USE CASE в первую очередь выгодно разработчикам - т.к. они становятся "незаменимыми", от части это решает "микросервисная ахитертура" - когда в случае чего просто выкидывают "поделие" без особых затрат заменяют другим не затрагивая остальные системы.
USE CASE - по факту основа любого ТЗ (и предварительно сбора требований) если вы делаете что-то для
бизнеса .
Возмём для примера:
https://habr.com/en/company/yandex/blog/442762/ - интересны в первую очередь "комменты".
И смотрим, как при появлении 100/500 вопросов автор приходит сам того не осознавая к необходимости выделения "Кейсов/Сценариев использования". Ведь можно "не потом", а сразу - описать возможные кейсы (да возможно не все будет определено на начальном этапе - на этом кстати базируется оценка). И вот тут будет очень кстати UML activity/sequence. Чтобы была возможность у "предлагающих" "решения" - прогнать его по "кейсам".
jirfagЕсть следующий кейс:
1. клиент отправляет заявку, заявка создается, но ответ от сервера не был получен, интернет вообще пропал на какое-то время
2. проходит какое-то время
3. сервер начинает шедулить заявки: искать дубли заявок и выбирать исполнителя.
4. сервер назначает водителя
5. у клиента отвисает интернет и он повторяет исходный запрос создания заявки
6. создается дублирующая заявка
7. по этой дублирующей заявке позже приезжает второе такси
Не понимаю идеи, чем заявки на создание заказа помогают?
