Полностью согласен, не проработанные требования -- отвратительная разработка, где главный принцип -- лишь бы работало)

Хорошо написаное ТЗ и бизнес логика 70% сделанной работы

Откуда тебе приходит ТЗ?

Павел, от требований к тому что разрабатывается)

Как может ТЗ приходить от требований? У ТЗ и требований к разработке есть автор или они из космоса приходят? Что ты имеешь ввиду под требованиям к разработке? Продуктовые требования или технические?

Странный вопрос: впервые слышу, чтобы y ТЗ был автор) Особенно, разделение требований на продуктовые и технические ?)

Как я вижу процесс запрос фичи->реализованная фича: 1. Приходит продуктовый фич реквест (у него очевидно есть автор) 2. Технический специалист прорабатывает техническое решение фич реквеста, уточняя детали у автора реквеста. дает оценку ресурсов необходимых для реализации фичи 3. Техническое решение уходит в реализацию

Любое требования не с потолка падает, кто то сказал что должно быть сделано таким то образом

Хорошо, разберемся что такое feature request?!

Автором такого запроса по классике является SaaS-менеджер продукта  , который на основе исследования маркетинга и пользовательского опыта и предпочтений выносит на обсуждение предложение по доработке уже существующего программного продукта.

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

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

Соответственно, выработанное техническое решение СОГЛАСУЕТСЯ не только с указанным менеджером, но и другими участниками жизненного цикла програмного продукта, так чтобы не съесть бюджет, насколько  все только что перечисленное реализуемо.

И только после утверждения, что эта доработка коммерчески привлекательна и технически возможна, запускается в работу)

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

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

Ну а какая разница то по итогу у ТЗ на разработку и ТЗ на доработку? И там и там есть тех специалист который его составлял, с которым можно поговорить и узнать почему в ТЗ неточности возникли