Критика описания Use Case

Канал о системном и бизнес-анализе, продуктовом мышлении и архитектуре. Как выявлять реальные проблемы, строить работающие решения и не терять здравый смысл в IT. Все вопросы - @innokentyB

use caseтребованиябизнес-процесс

Уже не первый раз вижу публикации данного автора и вынужден рекомендовать относиться к ним с определенной долей скепсиса.

  1. Во-первых, само описание Use Case как средства моделирования и проектирования в корне не верно, Use Case это средство фиксации требований к взаимодействию. Тот же Коберн предостерегал от детального описания интерфейсов и привнесения деталей реализации в интерфейс. Тем самым вы сильно сужаете возможности реализации для команды разработки.
  2. Во-вторых, фраза "Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс," сразу говорит о том, что автор не понимает принципиальных различий бизнес-процесса, как последовательности взаимодействия нескольких акторов, и Use Case как средства описания взаимодействия конкретного актора с системой.
  3. В-третьих, указание на то, что пользователь должен именно нажимать кнопку, а не просто добавить товар в корзину сразу лишает ваш документ гибкости и делает хрупким.

В целом подобный подход может быть оправдан только в том случае, если у вас есть практически неограниченный ресурс даже не аналитика, а техписа. Но подобное описание на мой вкус избыточно.

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

https://habr.com/ru/post/699522/

#badsmell #article

Дискуссия

Сергей Исаков :
Там в статье упоминался системный вариант использования UC с погружением в тех. Детали, что вы думаете о пользе такого подхода
Analysis.PRO Group
Сергей Исаков :
Там в статье упоминался системный вариант использования UC с погружением в тех. Детали, что вы думаете о пользе такого подхода
это огромные трудозатраты, которые еще надо окупить, поэтому в общем случае я считаю такой вариант избыточным. Оправдан только в случае с крайне неадекватным заказчиком или с совсем низкоквалифицированной командой разработки. В любом другом случае не окупится
Сергей Исаков :
Analysis.PRO Group
это огромные трудозатраты, которые еще надо окупить, поэтому в общем случае я считаю такой вариант избыточным. Оправдан только в случае с крайне неадекватным заказчиком или с совсем низкоквалифицированной командой разработки. В любом другом случае не окупится
Как вы посоветуете документировать тех план реализации?
Analysis.PRO Group
Сергей Исаков :
Как вы посоветуете документировать тех план реализации?
а зачем его документировать? Я имею ввиду конкретно вы какие цели этим преследуете?
Сергей Исаков :
Синхронизация между несколькими разрабами которые могут отвечать разные фт , вытекающие из одного UC за форму регистрации отвечает один, за отправку смс с кодом второй, за success уведомление третий
Analysis.PRO Group
Сергей Исаков :
Синхронизация между несколькими разрабами которые могут отвечать разные фт , вытекающие из одного UC за форму регистрации отвечает один, за отправку смс с кодом второй, за success уведомление третий
А чем задачи в трекере не устраивают?
Сергей Исаков :
Сергей Исаков :
Синхронизация между несколькими разрабами которые могут отвечать разные фт , вытекающие из одного UC за форму регистрации отвечает один, за отправку смс с кодом второй, за success уведомление третий
постановка задач в трекере это весьма ответственная умственная деятельность некоего техкомпетентного лица по разделению целого на части , которые при сборке дадут результат, с той степенью детальности, которая необходима, чтобы части были совместимы друг с другом. Вопрос кто производит (читай тратит время) и отвечает за это. Архитектор? СА? и как это потом трассируется с исходными UC? Нужно ли вообще поддерживать трассируемость тех задач с требованиями (уровнем спецификации) ? Пример: решили поменять подтверждение регистрации аккаунта с СМС-уведомления на емейл -уведомление. требуется ли трассируемость чтобы разраб увидел что его задача на настройку СМС увед уже ненужна. П.С. когда пишем статичные UC - все понятно, вот что делать в изменяющемся окружении.
Присоединиться к обсуждению →

Читайте так же