TGViewer
ITMINE: о бизнес-анализе ITMINE: о бизнес-анализе @itmineba · 1.28K subscribers
Post #207 764
UseCasesMethods.png104.4 KB
Последние пара советов по юз кейсам (ВИ, варианты использования) из области не очень очевидных — на этот раз даже с картинками 🙂

5. Осознанная “игра” UI в сценариях юз кейсов. Периодически вижу безапелляционную рекомендацию не затрагивать UI в формулировке шагов юз кейсов. Мне это кажется слишком ограничивающим, и больше по душе два варианта: “интерфейсозависимые” (это когда мы оперируем нашим UI в шагах и иных параметрах ВИ) и “интерфейсонезависимые” (когда сознательно абстрагируемся от UI) юз кейсы. Термины, если что, собственные. По аналогии с User Stories это один из способов сделать юз кейсы negotiable, т. е. сознательно пожертвовать детализацией во имя благих целей.

Два ключевых фактора, которые влияют на выбор подхода: задачи, которые мы решаем с помощью ВИ, и зона ответственности аналитика (проще говоря, входит ли проработка UI в работу аналитика или нет). Обе эти вещи часто варьируются от проекта к проекту, в особенности при смене заказчика и команд. Примеры ситуаций:

1) Юз кейсы прорабатываются уже на этапе общения с пользователями, и мы хотим вначале постичь полную картину user requirements. В этом случае, дабы не привязываться ментально к на ходу спроектированному UI, а сфокусироваться на user flows, я использовал бы интерфейсонезависимые юз кейсы.

2) Юз кейсы — техника спецификации требований, и функциональные требования не описаны где-либо еще. В таком случае, добавив макеты, я однозначно пользовал бы UI в шагах таких юз кейсов. В комбинации получается вполне себе рабочий способ подачи требований.

3) Вариант, аналогичный предыдущему, но представим, что помимо юз кейсов мы документируем UI где-то еще — например, описываем контролы где-то отдельно. Тут я бы не использовал UI внутри юз кейсов, т. к. мы придем к дублированию информации и усложнению поддержки требований. Т. е. ВИ тут служили бы описанием user flows для понимания контекста, а описание UI — детальной спецификацией для команды.

4) Вариант, аналогичный предыдущим двум, но с дополнительным контекстом: UI — не на плечах аналитика, т. е. есть дизайнер, юиксер и иже с ними, чьи руки заточены под эту задачу. В этом случае во всех своих требованиях я осознанно абстрагировался бы от UI, чтобы не лезть не в свое дело и не налагать лишних ограничений на работу экспертов.

На картинке — пример одного и того же ВИ в обоих форматах.
  • ❤ 5
  • 👍 2
More from @itmineba
  1. Sep 21, 2026Салют! Пара вакансий с прицелом на выпускников ITMINE: 1. Компания Slotegrator в поиске не…
  2. Sep 9, 2026Интересно описанный кейс настройки процессов БА с ядром в виде Клода: https://www.artofba.…
  3. Aug 25, 2026В LI сейчас активно встречаю цикл советов по тестированию от Артема Русова. Возникла шальн…
  4. Aug 23, 2026Интересная авторская рассуждалка на тему ИИ (транскрипт доклада с NDC). Как минимум с пози…
  5. Aug 21, 2026Интересная заметка про путь в бизнес-анализе: https://habr.com/ru/companies/svoi_ru/articl…
  6. Aug 21, 2026ITMINE: о бизнес-анализе pinned «Тэкс, кому обучение/систематизация знаний/практика? 🙂 Мы…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →