у нас на проекте это документ, описывающий обмен данными между системами

зачем в рамках ТЗ UC и US я не очень понимаю

не понятно кому его показывать в таком виде

и это будет такой прям увесистый документик, можно заказчиков им убивать будет :)

одним видом

Наверное это зависит от того кто смотрит и согласует доки.
В моем случае доки смотрели в т.ч. и люди далёкие от ИТ.
И им нужно было максимально просто и понятно. Т.е. UC и US идеально для этого подошли

вот это как раз я и писал выше

ну я человек простой и если вомневаюсь - иду сначала в вики, а потом по остальным ресурсам для уточнения)) https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F

Чисто в моей голове Спецификация - это хрень, которая опишет всю подноготную проекта/продукта, но, возможно, весьма поверхностно(хотя это вариативно вполне). а вот ТЗ это уже что-то направленное именно на разработку, сделанное для разработчиков

под разные нужды на проекте используются разные документы

это какая то общая спецификация всего и всюду

Вы не поняли :о) в ТЗ были UC и US как раз для того, что бы было понятно далеким от ИТ людям тк деньги на проект выделяли они

это ж сколько там страниц то было?

если абстрагироваться от конкретного примера, то вроде как для далеких от разработки как раз пишется некая поверхностная спецификация требований. а вот ТЗ, которое содержит разжеванную инфу для бизнеса, это что-то новенькое для меня)) зачем?

А так да,выбор вида, в котором пишутся требования зависит от  контекста, в котором приходится работать

Много)))

Возможно, стоит поставить вопрос в другой проекции?
Для какой ситуации какая дока нужна, почему именно такая и в каких ситуациях какое содержимое доки важно?

Мол если говорить о "вендорах" - вполне нормально им отдать спецификацию требований к системе и ждать результатов. Далеко не все вендоры позволят ставить им прямые задачи с ТЗ.

В тоже время в инхаус разработке вполне нормален вопрос, как писать доки с как отдавать фитчи в разработку/доработку, чтобы и бизнес был доволен и разрабы с тестерами не повесились?

Или я мимо темы ушел?

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

я считаю, что спецификация с ТЗ не должна быть смешана. это немного разные вещи в концептуальном плане. не факт, что я прав)

Для большинства случаев вы правы.
Но в моём случае это не сработало :о)
Если кратко о контексте в котором работал - это представители церкви)) и они хотели что бы работа системы была описана для них подробно.

неплохо))
но тогда можно было бы в теории описать верхнеуровневую доку бизнесу, в каждом разделе бизнес-функции сослаться на то, что "данная функциональность будет реализована посредством таких-то ТЗ"
Отдельно описать ТЗ

хотя если заказчик скажет "я нихрена не понял из ТЗ, а хочу понимать" - нужно или валить с проекта или делать тз в максимально отрешенном от it стиле. хз какая ценность такого тз будет для разраба, если честно( "масло масляное" какое-то получается