Хотя вести его оказалось не очень выгодно, потому, что читатель твоего ТР будет искать ответы в ТР, а не чёрте знает где в meeting notes.
Либо проставлять ссылки везде. Но зачем? Проще всё вывести в restrictions конкретно в той части, которая меняется. Тогда и контекст будет собираться проще.
https://coub.com/view/2r1wxu

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

Делаешь раздел ограничений на всё техрешение, туда обычно идут принятые решения на весь проект + архитектурные решения уровня приложения.

На каждый метод или юзкейс (если метода нет), делаешь свой список ограничений.

Нет, причинами я иное называю

Ссылаешься на ограничения либо из валидации

Либо прямо в доке. Даже линковать не надо.

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

Чиркаешь где надо:

А, ну это должно быть отображено в бизнес-требованиях, на которые ссылается техническое решение.

В целом у юзкейса, процесса, юзерстори тоже есть ограничения.

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

Причины чего? Есть причины появления именно таких БТ, есть причины конкретных архрешений, есть причины техничческих требований. Бизнес-требования - это тоже следствие каких-то решений
Формулировка  “Так решил архитектор” не дает мне понимания его решения. При одних и тех же БТ технические решения могут быть разными. И через год мне бы вспомнить, почему они были такими.

Ну, о том и речь. Есть бизнес-требование, у него есть ограничения.
Ограничением может быть также выбор бизнесоидом решения своей проблемы путём Х.
Предположим у тебя уже есть описание бизнес-требования. Тебе остаётся только его скорректировать, а в ограничениях указать, что бишь бизнесоид Пётр Иванович с подачи Николая Петровича пришли к выводу, что им будет удобно работать вот так.
И из места изменения указываешь пункт ограничения.

Meeting notes или ADR нужны только тебе, чтобы контролировать внесение изменения в БТ/ТТ.

Это прости какие ограничения могут быть у БТ?)

Например, если бизнес решил отказаться от создания того или иного документа в том или ином процессе.
Или если, например, бизнес согласовал определённый путь решения своей проблемы, хотя вариантов было много.

А причём тут БТ?

Ты сейчас про методологию ПО говоришь

Ну, у меня это всё на уровне ограничений технической реализации описано.