— У нас протечка.
— Протечка чего?
— У меня всё сиденье мокрое.
— Должно быть, это абстракции протекли.

К дискуссии о границах ролей. Кажется, границы ролей должны проходить по границам абстракций. Пока тебе не нужно думать о том, как это на самом деле работает — ты остаешься в рамках одной роли.

В институте нас очень аккуратно провели по всем уровням абстракций при создании электронной аппаратуры:

Сначала ты анализируешь задачу — твоё устройство вообще зачем? Какие функции оно будет выполнять?

Потом строишь алгоритм, или, например, карту Карно. Или целую функциональную схему (для цифровых схем — логическую), где только нолики и единички бегают.

Потом — принципиальную электрическую, и тут выясняется, что постоянный ток не очень-то постоянный, нолики не совсем нолики, а единички — совсем не единички, и что при нажатии кнопки бывает дребезг контактов, который может вызвать 3-5 ложных срабатываний. Причем обрабатывать это нужно либо на логическом уровне, либо вообще на программном — а вот вам и протечка абстракции!

Потом нужно развести плату (и расположение элементов на ней может сильно отличаться от принципиальной схемы!), а потом внезапно выясняется, что значки на принципиальной схеме на самом деле имеют размер, высоту, они греются, пылятся, трескаются на холоде, испускают электромагнитное излучение, а ещё имеют собственную частоту (и ваша плата может треснуть, войдя в резонанс при размещении, например, на автомобиле), при пайке их нельзя перегревать, а при креплении платы винтами — перетягивать.

Кое-что из этого можно и нужно решать программно — например, нагрев. Опять протечка!

И эти протечки нам могут подсказать границы ролей. Если в бизнес-процессе участвует смежная система — какое у аналитика предположение о её ответе? Она всегда доступна и отвечает мгновенно? Это бизнес-анализ. Ответ занимает столько-то миллисекунд в 95% случаев? При получении ответа 500 мы ждем 3 секунды и пытаемся выполнить запрос повторно? Это системный анализ/проектирование. Что мы показываем пользователю во время этого ожидания, чтобы он не нажал ещё несколько раз, не видя отклика? Это протечка абстракции: мы должны учесть детали реализации. В устранении протечки должны участвовать две роли. Перекладывать на бизнес-аналитика задачу "представить себе, как это будет реализовано" — это с больной головы на здоровую, не его зона ответственности, не его уровень абстракции. Мы же стараемся, чтобы более верхний уровень не знал о деталях реализации нижележащего.

Можно попробовать ещё накидать типовых точек протечек:
— Поиск/фильтрация по большому объему данных. А вы об индексах подумали? А может, запретим выдачу без фильтров, а то слишком много результатов, это full scan — протечка! Мы не должны думать об устройстве базы. Нужна совместная работа двух ролей. Сюда же — пагинация, поэтому её так часто БА забывают.
— Форматы данных при передаче. JSON? XML? Avro?
— Парадигма хранилища (реляционное, колоночное, документарное)
— Домены данных в хранилище (типы + ограничения на формат/диапазон, а вот бизнес-правила — это уже уровень выше)
— Кэширование, управление кэшированием (это и для системного аналитика часто вне рассмотрения)
— Распределение обращений по однотипным узлам, балансировка нагрузки
— Стратегии обеспечения согласованности, CAP/PACELC, уровни согласованности данных
— Развертывание, обновление
— Поддержка разных окружений (браузеры, ОС, оборудование, подключение к сети)

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

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

В конечном итоге, кажется, всё это укладывается в проверочный вопрос "если системы нет, то как это будет исполняться?" Пока нет конкретной реализации системы — это бизнес-анализ, нужно учитывать особенности реализации — системный.