то есть всё, что вы сейчас привели - это формат ТЗ?

да, с разной индивидуальной структурой)) но внутри по смыслу одно и тоже. еще забыл.. Functional Requirements, Non-Functional Requirements

Если интересуют форматы документов для проектов - посмотрите на шаблоны RUP: Vision и SRS
https://sceweb.uhcl.edu/helm/RUP_school_example/wcsoftwareprocessweb/templates/requirem/pt_vision.htm

да, как один из частных случаев.. Но слишком громоздко по объёму..

ТЗ по госту тоже громоздко.
Но, не все разделы обязательны для заполнения.

в ТЗ по ГОСТу очень много воды, и больше для формальностей, плюс информация часто дублируется

Дублирование это от плохого наполнения. И вода от того, что тот кто заполнял разделы не знает чего хочет.

Если составитель может чётко изложить свою мысль то он может и без воды составить ТЗ

по ГОСТу норм шаблон, чтобы ниче не забыть.. в коммерческих конторах не готовы столько тратить времени на написание документации, поэтому идет упрощение и акцент на ЧТО нужно сделать..

Есть замечательная (но старая и несколько не актуальная) книга Deadline.

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

Демарко? Почему показалась вам неактуальной? Интересно) Я как хороший производственный роман с ит спецификой прочёл, ничего такого из анахронизмов в глаза не бросилось.

*частично неактуальной

из за появления конфлюенса и прочих ресурсов для ведения проектной документации.. нормальных ТЗ давно не видел.. Функциональные Требования обычно все пишут с использованием структуры Use Case... Интеграции - таблица с Rq, Rs. Ui - таблица с элементами нв форме и поведением каждого элемента. а из UML самое ходовое Sequence Diagram.. остальные диаграммы встречаются очень редко.. а диаграммы класов и компонент выгружаются из ПО, как reverse engineering

Спецификацию на 300 листов можно создавать поэтапно, как базу знаний по решению.

вы реверс не путайте с системной инженерией, потому как реверс обычно  бинарники выгружает

Ну он в этой книге позиционировал, как наиболее лучши вариант разработки системы - водопад, так как там было примерно следующее: одна команда которая уделила большое внимание проектированию, а не написанию кода в итоге сделала все быстрее, чем те кто брался быстрее за код.

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

Так это не про водопад как таковой по-моему, а про то что грамотное проектирование сильно экономит время на переделки и героическое преодоление арх долга.

Бэклог проекта в скраме ж тоже не из магической пентаграммы появляется. :)

чтобы его не преодолевать, надо обьявить систему как Legacy)))

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

То есть если бы нужно было собирать требования и они менялись по ходу, то книга скорее была бы про итерационную разработку