шо, опять спорить о том, кто такой СА и границы его ответственности?  :( Не, увольте

Системный аналитик - это про гармоничность взаимодействия систем. Это если объяснять ребёнку 7-ми лет. Это теория систем, это подходы и принципы.
При чём тут вообще бизнес-требования?

А что делать, если ты снова начинаешь эту тему?

Если твоя цель - гармоничная техническая реализация без несоответствия точек зрения стейкхолдеров, то ты системный аналитик.
Если твоя цель - определение пути преумножения денег в компании, то ты продуктовый аналитик.
Если твоя цель - выявление и структурирование требований от стейкхолдеров (дабы ничего не пропустить), то ты бизнес-аналитик.

Если ты пытаешься в себе совместить всё вместе, то ты зерг-гибрид итить! Несите огнемёт!

И я, как аналитик, не понимаю, почему архитектор принял такое решение. А там можте быть полезная для смежных задач инфа. Я стремлюсь к максимальной прозрачности на всех уровнях, это дает людям пониание проекта в целом. Это профит не только к процессу, но и к мотивации людей.

Как и откуда возникают требования бизнеса?

Какая тебе разница? Если ты бизнес-аналитик, то тебе не важно что там на уровне решения.
Если ты системный аналитик, то для тебя решение архитектора - это ограничение.
Конечно можно описать "почему" или поспорить с ним. Но это стоит делать только в случае, если выявлены явные несоответствия.
А причины принятия тех или иных архитектурных решений должно быть описано в артефактах архитектора. На них можно дать ссылку.
В целом это не работа аналитика как по мне.

Почему была выбрана БД MS SQL а не Postgres?
Кто к вам придёт с этим вопросом? Скорее всего с этим вопросом придут к архитектору.

Серьзно? Понимание потребностей бизнеса не важно для технического решения?
Причина, по которой мы используем веб-сервис А вместо отправки сообщений в сервис Б не важна для детализации технических требований?

Т.е. надо описать:
1. Какие варианты были?
2. Какие у  вариантов плюсы и минусы?
3. Какой был вариант выбран и почему?
4. Кто выбрал?
5. С кем было согласовано решение?

Это не арх требования

Арх требования формируются в рамках определённых бизнес-требованиями каналов взаимодействия с пользователями.

Вот как ты будешь отправлять сообщения - это вопрос архитектора:
- какой сервис будет это делать?
- какие нфт?
- может быть использовать готовое стороннее решение или писать самим?
- на каком языке это будет написано?

- И что? Это не отменяет того, что мне полезно понимать, почему именно тот сервис реализует эту функциональность.
- Какие НФТ - как раз вопрос аналитика, архитектор определяет, каких реализовать

До момента возникновения несоответствия - нет не полезно. Работа уже проделана, зачем опять идти с вопросами в архитектора?

Архитектор принимает НФТ на вход, чтобы принять решение о выборе технологии и арх концепции.
Аналитику НФТ постольку-поскольку. И генерируются они не им. Да, записать можно, чтобы их тестировать.
Вы оба потребители НФТ.

Господа, можно немного офтопа. У меня один вопрос — вторник 16:32. Дискуссии идут уже пару часов. Когда вы работаете?

Я хотела высказать еще одно (возможно никому не нужное) мнение, но поняла, что времени на формулировки нет)

Без понимания причин решений несоответствия не возникнут.
Аналитик выявляет НФТ. Если генерит их не он, и не архитектор, то кто? Бизнес аккуратно расписывает что ли?

я не работаю, все просто))

Я на встречах, могу писать в промежутках.