Все зависит от того, кем вы являетесь в процессе разработки)). Если вы заказчик - ТЗ вне вашей компетенции, вы обязаны предоставить требования к системе, на базе которых уже будет делаться ТЗ специалистом. Дело тут в следующем: не специалист 100% захочет отстрелить себе ногу за свои же деньги.
Например недавно был вопрос про то, что бы использовать redis как единственную БД, т.е. и платежные транзакции там хранить и все остальное. С точки зрения скорости - да, работать будет быстрее, но в случае любого чиха - система ляжет.
Или еще, вопрос на этом же сайте: какой язык взять, что бы вот конкуренты вообще-вообще не просекли, что бы сложный такой был и бла-бла-бла. Это просто глупость.
Само ТЗ обычно состоит из:
1. Терминологии.
2. Общих требований к системе по принципу установки и производительности. Например: ОС: debian, ЯП: Golang,..
3. Описание структуры проекта и основных модулей с точки зрения их предназначения. Например: модуль новостей предназначен для бла-бла-бла...
4. Описание каждого модуля постранично с обязательным указанием выводимых данных и управляющих элементов. Типовые блоки (например сокращенный блок новости) стоит рассматривать отдельно, ссылаясь на них в модуле.
5. Подписанные реквизиты обоих сторон.
ТЗ нельзя вот так взять и сделать, это процесс, в котором обязательно согласование с заказчиком. Дело в том, что после подписания - правки в ТЗ НЕ ВНОСЯТСЯ.
Средний
Средний
